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
Reuses the code that the installer uses, when it broadcasts to
the relevant installer that an Apk is available for install.
This used to do the following:
* Copy file to a private directory
* Make the file world readable (so that PM can access it)
* Send a file:// URI to the installer
The file:// URI is no longer supported for reasons explained in
the support lib FileProvider class. Now a content:// URI is required,
and that must explicitly grant permission to certain packages.
The existing code here used to grant permission to
org.fdroid.fdroid.privileged, and this code now also grants it to
com.android.bluetooth. I see no security threat with exposing these
files to both applications, because the .apk files only ever:
* Were downloaded from the public internet into a (potentially public)
cache dir.
* Were sourced from an `ApplicationInfo#publicSourceDir, in which
case any app can access that anyway.
Fises #837.
If the user can set the language using the Setting app, then there is
not reason to use the Languages hack. This then clears the preference
if it matches the language of the system-wide locale. This also
removes the current system-wide language from the Languages menu.
closes#943
All feature graphics are called `featureGraphic.png`, and so our cache
was presuming all feature graphics were the same image. By including
the full path from the server in the cached name, we don't overwrite
images any more.
Right now, org.fdroid.fdroid.privileged.ota and FFupdater do not
provide any icons and it seems that that triggers this crash:
ACRA caught a NullPointerException for org.fdroid.fdroid
java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.String.lastIndexOf(int)' on a null object reference
at org.fdroid.fdroid.FDroidApp$5.generate(FDroidApp.java:282)
at com.nostra13.universalimageloader.cache.disc.impl.BaseDiskCache.getFile(BaseDiskCache.java:167)
at com.nostra13.universalimageloader.cache.disc.impl.BaseDiskCache.get(BaseDiskCache.java:98)
at com.nostra13.universalimageloader.cache.disc.impl.LimitedAgeDiskCache.get(LimitedAgeDiskCache.java:74)
at com.nostra13.universalimageloader.utils.DiskCacheUtils.findInCache(DiskCacheUtils.java:36)
at org.fdroid.fdroid.NotificationHelper.getLargeIconForEntry(NotificationHelper.java:506)
at org.fdroid.fdroid.NotificationHelper.createUpdateNotification(NotificationHelper.java:300)
at org.fdroid.fdroid.NotificationHelper.createNotification(NotificationHelper.java:191)
at org.fdroid.fdroid.NotificationHelper.access$400(NotificationHelper.java:37)
at org.fdroid.fdroid.NotificationHelper$1.onReceive(NotificationHelper.java:106)
at android.support.v4.content.LocalBroadcastManager.executePendingBroadcasts(LocalBroadcastManager.java:297)
at android.support.v4.content.LocalBroadcastManager.access$000(LocalBroadcastManager.java:46)
at android.support.v4.content.LocalBroadcastManager$1.handleMessage(LocalBroadcastManager.java:116)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
* Avoids crashes when trying to treat non apk files, such as
privileged extension ota update.zip as apks
* Doesn't do anything at all for now.
One issue with this is the app is always in the not installed state,
so what would be appropriate here would be to change the text of the
install button to download, and update that accrodingly.
However that is outside of the scope of this change.
TODO:
Add toast indicating the user that they need to install
manually, in case of OTA update.zip
This zeros out the etag in the fdroid_repo table and then asks
the update service to perform an update.
The end result is that changing the language will result in the metadata
being shown in that language.
Note: This doesn't immediately work due to pending changes around
Locale.setDefault() and the change in case from Summary to summary in
the server metadata.
This reverts to the previous behaviour before 8faf151.
Then, the InstalledAppProviderService would queue up a series of
changes, and only notify after 1 second of nothing being added to
the queue. This was good because CursorAdapters and LoaderManagers
would not continually requery the database several times a second (only
once at the end), but it meant there was a lag in the AppDetails screen
getting updated after installing/upgrading/deleting packages.
This restores that behaviour where general events (e.g. "some misc apps
in the database were changed") are "debounced" for 1 second. However it
also emits a more specific "package org.blah.com was changed" instantly.
In the long term, it would be good to remove any dependency on
ContentObservers and `notifyChange()` altogether, in preference of
either LocalBroadcastManager or RxJava. However this will depend on how
we go about changing the database layer in the future. The fact we now
depend on ContentProviders means that it would be a big change to move
away from LoaderManager + notifyChange().
Fixes#986.
I have found no explanation of what should work and why, but language
choosers seem to always include this line. This also seems to fix the
bug:
closes#943
This makes the license a link to the spdx.org page for the app's
license. I think this is an improvement over the way the license was
displayed before 0.103 since it provides a direct link to the actual
text of the license.
The license icon is a modified version of the public domain icon:
https://commons.wikimedia.org/wiki/File:Cc-sa_white.svgcloses#960
* Addition: Try to get apk details via InstalledAppProvider too.
* In certain cases, such as the "UnifiedNlp (no GAPPS)" app on a device
with actualy GAPPS / GMS installed, apk can be null which leads
to a crash
* Ask InstalledAppProvider for the app's details too, like it
was done in the old UX AppDetails.
* Also seen when uninstalling app with a signing key different,
fixes#985
In android-24 and newer, the user can specify multiple languages in a
priority list. Therefore, the locale chooser logic here does not need
to work so hard to find a language match. For example, if the user
wanted to see country-specific variants, they would add them to the
preference list.
With older versions of Android, the pref is only a single locale. So
chances are that someone who specified de_AT would rather see de or
de_DE than en_US. Same goes for es_AR, ar_EG, etc. This could annoy
Chinese speakers, since someone who sets zh_TW could potentially see
zh_CN, which are written pretty differently.
Android 24 and later provides tons of languages, and a way to rank
multiple languages instead of choosing one. The Languages pref is a
big hack and can be problematic, so its better to disable it when its
not needed. This will make it so it is no longer possible to set
F-Droid to a language that the system does not support.
#943
