This was only partially hooked up and often not even populated.
It was added in 4895e2d790ec3b91fa4271a24e1ea0ae69d362f4, but things have
changed a lot now. We should be moving towards preferring the drawable XML
vector icons, which will scale nicely for all DPIs.
The previous commit makes this issue a lot easier to see. ApkFileProvider
getSafeUri() was already making the right URI for SDK_INT < 24, but then
this bit of logic was using the original URI, which didn't work. Installing
from the app's cache dir triggered a "Parse Error". The Android default
installer API needs file:// URIs from getFiles().
closes#1310
This hopefully makes apparent which pieces are only related to APKs, and
which pieces are used for all installable file types (media, OTA ZIPs, etc)
ExtensionInstaller only works on < android-20 anyway, so that's self-
enforcing in terms of URI scheme: it'll only ever see file:// URIs.
This fixes the following crash:
* Install an app form F-Droid
* go to home screen
* uninstall app
* quickly switch to F-Droid the button will still show 'run' for a few
seconds
* launch the app you just uninstalled
As nice as it would be to help the users, F-Droid is not well positioned to
help the user with this problem. The Android OS itself should do it. Plus
this issue has been open a long time, without much work on it, and the
existing solution is causing crashes.
#855!440!581
Utils.getBinaryHash() is used in a lot of places in the code, so its not
easy to handle this specific issue. Here's one example:
org.fdroid.fdroid.Utils$PotentialFilesystemCorruptionException: java.io.IOException: read failed: EIO (I/O error)
at org.fdroid.fdroid.Utils.getBinaryHash(Utils.java:426)
at org.fdroid.fdroid.AppUpdateStatusService.findApkMatchingHash(AppUpdateStatusService.java:159)
at org.fdroid.fdroid.AppUpdateStatusService.processDownloadedApk(AppUpdateStatusService.java:110)
at org.fdroid.fdroid.AppUpdateStatusService.onHandleIntent(AppUpdateStatusService.java:65)
at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.os.HandlerThread.run(HandlerThread.java:60)
The NullPointerException fixed by the previous commit had a warning to that
effect. This fixes almost all the warnings to make the warnings clearer:
* unused method
* unused result of File.delete()
* can have reduced visibility
* single char static "" strings can be '' chars
* jif-afWarningQrCodeScan:
do not include english string in translations
Correct check style errors
Add style for the poor QR code scanning autofocus capability warning
Add 'poor QR code scanning capability' translations
Call to the camera autofocus checker in the view
Add camera characteristics checker
fdroid/fdroidclient!649
closes#260
Those classes consist of 1 abstract class, which provide a factory for
2 classes each of which implements different behaviors according to
the Android API version.
Files in the cache can be deleted at any time, without warning. F-Droid's
CleanCacheService can do it, the user can do it in Settings --> Apps, etc.
So when working with files from the cache, the methods need to be extra
defensive, checking that the file that they were given still exists.
closes#1305
extended info on things we already have:
* PRODUCT is another name for BRAND/PHONE_MODEL
* TOTAL_MEM_SIZE can be derived from hardware name
* DISPLAY is also available by looking up the hardware
* STACK_TRACE_HASH should make automated sorting easier
new info:
* PACKAGE_NAME is only new info if the user is using a whitelabel app
* AVAILABLE_MEM_SIZE can be used to track users, but only when provided at
high resolution, e.g. once per second or higher. Most users only send a
single crash report. High frequency reporters send under 100, which is
still orders of magnatude below what is needed to track users.
Things like permission support, locales, etc. can change when Android is
updated. So the database should be rebuilt from scratch with a fresh
download of the indexes.
closes#780
The database currently only stores the active language. So if the
user changes the system language of the phone, then the language of
all the app descriptions will be out of sync until the next update.
This forces an update when the locale is changed. This functionality
is also needed for events like OS upgrades.
closes#225
It was tried until it got an IP address, but that will only happen if there
is a wifi device configured. Since WifiStateChangeService is started when
F-Droid starts, WifiStateChangeService could run for days if someone never
connected to WiFi in that time.
WifiStateChangeService is also started by NETWORK_STATE_CHANGED_ACTION so
it should start each time there is a change to the WiFi connection.
It was already behaving like a singleton, but the code was spread around in
other classes. DBHelper does not use a private constructor though since
the tests prevent it.
Yes, this is an ugly and old style, but mixing styles only makes it worse.
Plus it breaks the tests in some cases, since it makes Preferences depend
on Resources.
