The response to receiving PendingDownload was always a more specific
case of the Downloading event. By removing it, the code which was listening
for Downloading events is capable of doing everything that the PendingDownloading
listeners were doing.
Same as how AppDetails2 was recently cleaned up to depend more on
AppUpdateStatusManager.
In addition, it also removes items from the "X apps can be updated"
lower part of the "Updates" view when they are present in the upper half
(i.e. the half showing feedback about the current download/install
progress).
No longer do we try to nicely maintain the state of the adapter in "Updates"
in order to notify the recycler view about changes to its underlying data.
Instead, we just rebuild the entire structure each time a new thing needs
to be shown/removed.
This means no more smooth scrolling to the relevant item after it is
changed, but it results in a far less buggy interface.
This means that we no longer need to receive an APK_URL and then
directly ask the status manager for the relevant status object.
This causes problems when consecutive updates happen in the same event
loop, e.g. download started + download complete. In this case, the
receiver will receive two events for the same app. When it asks for the
associated status object for the first (download started) event, it will
receive a status that says "download complete ready to install". This is
because the status object has already been updated by the second event.
Furthermore, the broadcast manager must receive a copy of the status
object, not the original object. This is because the broadcast manager
doesn't parcel the relevant extras until the end of the event loop. This
means that if the status is changed twice in one frame, then both
parcels will end up looking the same. By sending through a copy instead,
this ensures that any listener receives the statuses in the correct
order, rather than two parceled versions of the same status
notification.
Also, make sure to correctly update the app details view when te user
leaves then returns to the view. Prior to this, the user would need to
wait for a download event to be received. However even that was broken,
because the download listener was not being added correctly once the
user returned to the app details screen.
Even though the categoyr mage loader explicitly says not to cache
images on disk (because they are not coming from the network anyway),
UIL still uses the `FilenameGenerator` to come up with a disk cache name.
Because the file name generator takes the "path" of the URL being
downloaded, and the categories are loaded like "drawable://2134234",
there is no path. As such, the file name ends up being meaningless.
This results in the image loader testing for the existance of the file
on disk (even though we asked not to cache on disk), and then failing
with an IOException (that gets swallowed).
By providing a meaningful name from the file name generator, it now
works as expected.
Fixes#1039.
Lots of languages really need the <plurals> tags to make sense, so
this also makes lint exit with an error when it finds strings that
should be <plurals>
closes#883
Previously, it would either send "base.apk" (in earlier versions of
F-Droid when bluetoothing an apk from the /data/app/... dirs), or
"install-[random].apk" (if recent F-Droid when copying file to a safe
place to expose via a FileProvider.
This now writes the file to, e.g. "F-Droid-0.103.1.apk" before sending.
Note that this means files are more likely to be overridden when being
sent, if the same apk from two different repositories is either:
* Sent via bluetooth
* Prompted to install via the system package manager
However this should still never let malicious people write to that
folder.
This ensures that the `PendingIntent.FLAG_UPDATE_CURRENT` doesn't
continually override earlier intents with the last app to be notified.
This could probably equally be done by leaving the request code as 0 and
removing the FLAG_UPDATE_CURRENT out, however it seems much more
semantic to have a separate request code for each different pending
intent.
Fixes#1021.
The hack that goes through and checks whether a language is present in
the APK seems to cause random strings to switch to English when the
app is running. So this removes that hack, and instead switches the
Languages menu to a hard-coded list. Languages that are not present
or close to complete were removed from the old list.
closes#943closes#1010
