This adds some case normalization to both the scheme and the host. This was
previously messing up TreeUri content:// URLs like this:
content://com.android.externalstorage.documents/tree/1AFB-2402%3A/document/1AFB-2402%3Atesty.at.or.at%2Ffdroid%2Frepo
Turning them into:
content://com.android.externalstorage.documents/tree/1AFB-2402:/document/1AFB-2402:testy.at.or.at/fdroid/repo
java.net.URL barfs on custom URL schemes, and making it handle them is
really hard. Basically, there needs to be a Handler stub class, then
URL.setURLStreamHandlerFactory() must run when F-Droid starts, since
it has to be set before any URL instance is used. This all leaves
some weird logic that gives the false impression that URLConnection
will handle these custom schemes.
Switching to Uri/urlString throughout the code matches the other
classes that use urlString as the unique ID, and this doesn't add more
lines of code.
This was int because it was written arond UrlConnection.getContentLength()
which returns an int. But that doesn't make sense since this will
definitely handle files large than 16MB.
!647#1192
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.
