When a device is setup as a WiFi Access Point aka "hotspot", the standard
API for getting the WiFi settings returns nothing. We have to use a
separate API to get the IP address of the WiFi AP. As far as I could tell,
there is no public API for getting the SSID/BSSID of the WiFi AP, so for
now that is left blank. That means the wifi screen in swap is confusing
because it will say it is not attached when the device is a hotspot
@mvdan's https://github.com/mvdan/libaccesspoint should help there
#193https://gitlab.com/fdroid/fdroidclient/issues/193
To handle hotspots, this code will become more complicated. Therefore,
first simplify things by putting all of the logic into one place, rather
than spread out across FDroidApp, the receiver, and the service
On launch, we need to get the current state of the Wifi. We only need to
start the WifiStateChangeService on WIFI_STATE_ENABLED, since any other
wifi state will be received by WifiStateChangeReceiver, which will launch
WifiStateChangeService when appropriate.
This reduces the chance that WifiStateChangeService will start when it is
not needed.
I was getting frequent crash-on-rotate NullPointerExceptions after scanning
QR Codes. This fixes it for me.
ConfirmReceiveSwapFragment is only ever used once in ConnectSwapActivity,
so it is a pointless abstraction. It makes the code a lot more complicated
and also creates very complicated situations to handle when the screen is
rotated. All of this gets much easier when everything is just included in
the Activity, since there is no problem being solved by the Fragments.
Fragments are for reusing chunks of UI in multiple places, or for showing
multiple chunks of UI in the same Activity. Both of those cases can also
be handled, arguably better, without using Fragments:
https://corner.squareup.com/2014/10/advocating-against-android-fragments.html
On api 19 or later, writing to your own private directory on the SD doesn't
require any extra dependencies. We only ever store icons, apks and index stuff
on the private repo, so we never read/write anywhere else on the SD.
Fix issue #202 - crash due to sqlite parameter limit being hit.
*NOTE: Queuing here for merge after next stable.*
The queries which have the potential to cause crashes due to too many parameters in the `ApkProvider` are now encapsulated in `ApkProvider` and can only be accessed by safe helper methods, which alleviate the problem by breaking big requests down into many smaller requests.
This will probably have to be done for the `ApkProvider`, but leaving for now because the limit is twice as big.
See merge request !70
Cache files to SD card again (if preference set).
**NOTE: Queueing here to be merged after next stable**
A previous security fix meant we no longer stored apk files on the
SD card. However, this should still be a feature that people can opt
for if they want, without being insecure. As such the process is now:
* First download: put in internal storage (to ensure it can't be
modified before installing)
* After download: also copy to SD card for caching.
* On starting F-Droid:
+ Always delete internal storage apks.
+ Only delete other, cached apks if cache preference is false.
To make the code simpler and less prone to bugs, I had to consider
the fact that if people did not have an accessible SD card, then the
path to a cached apk and a "downloaded but transient" apk cannot be
the same. While possible, it means many checks to see if they are
the same, thorough permission management to prevent security issues,
and makes it harder to clear transient apks when F-Droid starts.
See merge request !71
Daniel Martí