In order to save disk space and memory, at a cost of some CPU time,
this makes sure that all downloaded images are not bigger than the
device can support. A nice side effect of this process is that EXIF
information is stripped from JPEG files since they are read into a
Bitmap, then written out as a PNG. This should complete the JPEG EXIF
stripping started in 2a3aaacf2347679f30e2c8feffb92f25bb882c8b with
considerExifParams(false)
!653
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.
