Never fallback to UIL for handling image downloads, only use for displaying.
@relan picked up a bug I introduced while refactoring the icon downloading code in !139 (merged). This fixes that bug.
Our IconDownloader
extended BaseImageDownloader
from UIL. There was an
explicit check in the F-Droid IconDownloader
which looks for
HTTP/HTTPS/Bluetooth schemes. If it wasn't one of these, it fell back
to the base class. This was what was happening for local cached image
files. As such, when the getInputStream(...)
method was refactored
to only use F-Droids DownloadFactory
and not delegate to the base class,
it failed on local "file://" URLs.
This change introduces a LocalFileDownloader
and makes the DownloaderFactory
aware of it.
The BaseImageDownloader
class only provides support for the following schemes:
- HTTP
- HTTPS
- File
- Android content providers
- Android assets
- Android drawables
F-Droid now supports HTTP, HTTPS, and File URLs. There is not currently any
need for content proiders, assets or drawables to get icons for apps in F-Droid.
If there is a need in the future (e.g. an issue currently discusses loading
icons from installed apps if possible) then that specific Downloader
can get
introduced to solve the problem.