This lets people add any URL as a mirror to an existing repo. The UX is
people add URLs via any of the normal ways of adding a new repo via Intents,
like clicking URLs, QRCodes, etc.
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
This makes the build reproducible, and makes the files smaller.
metadata/en-US/images/phoneScreenshots/screenshot-dark-details.png | Bin 358916 -> 309386 bytes
metadata/en-US/images/phoneScreenshots/screenshot-dark-home.png | Bin 277413 -> 224844 bytes
metadata/en-US/images/phoneScreenshots/screenshot-dark-knownvuln.png | Bin 158903 -> 123484 bytes
metadata/en-US/images/phoneScreenshots/screenshot-knownvuln.png | Bin 66707 -> 41670 bytes
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
