- Icon transition is no longer jumping in first frame (caused by different padding)
- Icon is no longer cropped at start of transition (caused by missing changeImageTransform)
- Toolbar icons are no longer animated. Introduced in !561 by changing the icons programmatically
This is not really a useful way to tell the user that the index might be
out of date. It just adds confusion and makes people think that F-Droid
isn't quite smart enough to know what's going on.
* This installer is invoked when for non-apk/media files, and
copies them to an appropriate folder on the sdcard.
* We also introduce a FileInstallerActivity to ask for storage
permissions at runtime, as needed by Android 6.0 and above,
and handle the install/uninstall process.
* A toast is shown with the install path after installation.
TODO:
* Manage Installed Apps screen doesn't show media files.
Reuses the "commiting" message to indicate how many apps have been
processed so far.
Refactors existing progress handling between `RepoUpdater` and
`UpdateService` to use `LocalBroadcastManager` in preference to
`ProgressListener`. Still needs to use `ProgressListener` to talk
between `RepoUpdater` and the `Downloader` +
`ProgressBufferedInputStream`.
The only change that is related to something more important than
notifications is the fact that now `IndexV1Updater` makes use of the
`indexUrl`. To do so, because it is final, the base class constructor
delegates to `getIndexUrl()` which is overriden by the v1 updater.
This is required because we want to differentiate between broadcasts
coming from different repo update processes.
Fixes#1054.
This breaks out subclasses for each specific type of app list item,
allowing for code reuse, but also letting the specific business logic
belonging to each different app list item to be separate.
This is particularly helpful in the following situation:
* In the search results, it is great to be able to render "App
downloaded, ready to install" in the same manner as the update tab.
* In the installed app list, this is not desired. Indeed, the status
text which should be shown should reference the currently installed
version and whether the user has ignored any updates.
By separating the AppListItemController into subclasses, it reduced the
need to handle several different types of text view (e.g.
"installedStatus", "status", "ignoredStatus", "downloadReady"), and
replace them all with a "status" and "secondaryStatus" TextView. What is
displayed in status and secondaryStatus is up to the individual
subclasses of AppListItemController.