If anything wants to craft an Intent to send directly to F-Droid with an
arbitrary but valid path, that seems like a fine thing to support. The
IntentFilters will still only match on the well known paths, so that the
user doesn't see F-Droid claiming all HTTP URLs.
The repo instance variable has long since been unused, but has just been
left there as a vestige. Now its presence is blocking RepoUpdater.
getSigningCertFromJar() from being a static method that can be reused when
checking for repos on SD Cards and other removable storage devices.
This saves the levels of indirection that leads to a FileInputStream being
created in LocalFileDownloader. Since there are already special cases for
assets:// and drawable://, it seems a natural place to put the file://
case. Also, since this is used to load icons when scrolling through lists
of apps, this is particularly sensitive to inefficient loading.
This also removes custom code that UIL provides better.
This uses the total RAM that the device comes with as a rough measure of
the devices capabilities. That is then used to set how many parallel
threads UIL can use.
Instead of setting the same thing at each place its used, this puts all the
settings in one place. For the most part, they are the same everywhere.
This makes it a lot easier to optimize how UIL works since all the settings
are in one place.
No need to slow down UIL by making it do a cache check since
CleanCacheService already does that in a low priority background service.
The default FileNameGenerator just uses imageUri.hashCode() so its safe an
faster than ours. So just use the default.
Also, no need to set threadPriority() since we are using the default
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.
