Notify user about downloaded but not installed apps

In 0.103, the Updates tab has been much improved. It now:

• Shows progress of currently downloading items.
• Show the list of apps with updates available.
• Shows apps which updates have been downloaded but not yet installed (and prompts the user to install them).

This last step is one of the best features (given the manual intervention required for most F-Droid users after downloading). However, it only works correctly for a subset of all app downloads and in certain situations.

One of the main problems is in the following (not uncommon) scenario:

• User initiates an install for a new app.
• This begins a download from the server.
• Upon completion, it correctly displays it in the "Updates" tab with:
  • A badge on top of the "Updates" tab alerting the user that manual action is required.
  • An inline "Install" button once they navigate to the "Updates" tab.
• The user then closes F-Droid before completing the install
• Upon opening F-Droid again, there is no indication that an app has been downloading awaiting install.

Expected behaviour

F-Droid should be able to scan the cached apks which have been downloaded. If it finds an app which is downloaded, but not yet installed, then it should notify the user as if the app had just been downloaded.

I have a fix for this, but I'm struggling with the following:

• User downloads + installs an app (resulting in an .apk file ending up in the cache)
• User uninstalls the app
• User opens F-Droid
• F-Droid scans cache, sees the .apk file from before, and presumes it is a newly downloaded apk ready to be installed.

There is no way for me to tell whether the app is for a new install (which we care about), or whether it is in the cache because of a previous install (in which case we don't care about it).

I'd like to solve this without having to persist extra info to disk (through shared preferences or the database) about whether a download+install was initiated or not. But I can't think of a way.

Use a shared preference, separate from the Preferences one, to store the list of install requests. This is so simple, using the database seems like overkill.

added bazaar label

The cache data and the database data is not enough to reliably derive the list of install requests.

mentioned in merge request !488 (merged)

closed via merge request !488 (merged)