Skip to content

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.

Merge request reports