Skip to content

Fix notification problems

username-removed-25042 requested to merge pserwylo/fdroidclient:fix-notifications into master

AppDetails2 had several problems responding to download + install events, which allowed the system to get in weird states, which results in weird/unhelpful/annoying notifications. See my comment on #1034 for details.

This cleans up the logic in AppDetails so that it is more concise, using the AppUpdateStatusManager broadcasts in preference to the DownloaderService broadcasts. This results in a less-hacky solution, primarily because the "currently downloading apk URL" is no longer required, now replaced with the more semantic and helpful currentStatus from AppUpdateStatusManager. However it also has the important benefit of being able to query the current state upon returning to the app details activity. The behaviour in master now is broken because it only updates the activity in response to download service broadcasts. That meant that on a slow network, one could open the app details screen of a currently downloading apk and not see proper feedback about the apps download + install status for some seconds.

This also makes improvements to the AppUpdateStatusManager to make working with it easier and indeed more correct in the future. Firstly, Status.Unknown was renamed to Status.DownloadPending and a new Status.DownloadInterrupted was introduced, because the unknown status used to mean one of these two things and it was impossible to know which. Additionally, the workflow was improved from this:

  • Wait for broadcast from app update status manager.
  • Read APK_URL extra from the broadcast intent.
  • Ask the status manager for the status belonging to that URL.

This caused a bug whereby:

  • Two events are fired in the same event loop (Download started + Download completed for already cached apks).
  • The status manager receives the events, and updates the app status accordingly (respectively broadcasting a "DownloadPending" and "ReadyToInstall" intent).
  • These two events are received by app details, which needs to respectively show an indeterminate progress bar, then prompt the user to install.
  • Due to both being received in the same event loop, the first broadcast which is received (in response to "DownloadPending") asks for the APK_URL, then asks the download manager for the relevant status object.
  • This status object has already been updated to the "ReadyToInstall" status, resulting in two successive "ReadyToInstall" intents (rather than one "DownloadPending" and one "ReadyToInstall").

This is now fixed, because the actual status which triggered the broadcast is parcelable, and sent with the intent as its own extra. This is possible because of previous work to make Apk and App parcelable.

I haven't yet tested this with priv-ext. I'm going to try and install it on an emulator and test it, then report back. If I am unable, I'll request someone else to please test it.

Merge request reports