* 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
There was a bug where the repo with the highest priority would be
responsible for specifying the suggested version code. When doing so, it
would only select from the list of apks available in that repo. This
improves the calculation so that when any given repos app gets a
suggested version code assigned, it selects from _all_ available apks,
not just those from the repository in question.
Fixes#974.
This allows us to test "installing" Adaway, which has a native code
dependency that the default Robolectric setup doesn't support (defaults
to armeabi-v7a).
The version check guarded against downgrades, and would not notify the
user if it found a downgrade in the apk cache. However this was from
before we could ask `AppUpdateStatusManager#isPendingInstall(hash)`. Now
we don't need to care whether it is an upgrade or a downgrade, because
there is a more authoritative source as to whether this apk is
interesting to us or not.
There may be multiple apk files with the same hash. Although it is not a
security issue to install one or the other (they are exactly the same
binary), they may have different metadata to display in the client.
Thus, it may result in weirdness if one has a different
name/description/summary etc).
This change takes each of the matching Apk objects from the database,
then asks them where they expect to be downloaded. It matches this
against the File that we are looking at and only returns if they match.
According to the following this is not supported:
* http://stackoverflow.com/a/13471695/2391921
This uses the approach in that SO answer, by extracting the attribute to
instead point at a drawable, and have one drawable for each theme.
Fixes#979.
PMD does not like manually throwing NPEs, even if they have more verbose
information than the default NPE. As such, use an
`IllegalArgumentException` instead.
Instead of showing them below the icon, it now puts the icon + name +
author + last updated into a single layout which can grow if the app
name or author wraps to a second line. The buttons are now below this
additional layout.
Although I'm unsure of exactly why this is `null`, it seems sensible
that there is a possibility of null icons (e.g. for .zip files or other
media). As such, this just adds a guard condition to ensure that the
`iconUrl` is not null.
Fixes#981.
Received the following crash report, where the user said it crashed
while trying to install the priviledged extension:
```
java.lang.NullPointerException: Attempt to read from field 'android.content.pm.Signature[] android.content.pm.PackageInfo.signatures' on a null object reference
at org.fdroid.fdroid.installer.ApkSignatureVerifier.getApkSignature(ApkSignatureVerifier.java:70)
at org.fdroid.fdroid.installer.ApkSignatureVerifier.hasFDroidSignature(ApkSignatureVerifier.java:54)
at org.fdroid.fdroid.installer.ExtensionInstaller.installPackageInternal(ExtensionInstaller.java:53)
at org.fdroid.fdroid.installer.Installer.installPackage(Installer.java:265)
at org.fdroid.fdroid.installer.InstallerService.onHandleIntent(InstallerService.java:77)
at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
at android.os.Handler.dispatchMessage(Handler.java:111)
at android.os.Looper.loop(Looper.java:194)
at android.os.HandlerThread.run(HandlerThread.java:61)
```
Not sure how to address it yet, so adding more specific excetpion for
if it happens in the future.
This pulls all the categories out of the database at once for sorting,
rather than sorting in SQLite. This is to prevent having to store the
localized category names in the database (and hence having to update
them when the locale is changed).
Fixes#967.
Previously they were left to be sorted however SQLite parsed the query.
This turned out to result in them beign sorted by repos first, then
names. For example, all of the GP apps would be at the bottom of the
list.
Fixes#965.
Use SharedPreferences to keep track of whether we are in the middle of
an install for a particular apk or not. If sothen the presence of an
.apk file in the cache means we need to tell the user (in the updates
tab) that a file is ready to install.
Previously this only worked for apps which were being upgraded to the
latest available version. Now it works for apks being upgraded from an
old version to a newer-but-not-newest version. Perhaps more importantly,
it also now works for newly installed apps.
This has a problem where if a user installs, then uninstalls an app,
they are still notified about installing it. This is because the apk
is in the cache and the code doesn't know whether it is there from
the initial install, or because it has been redownloaded by the user
to install some time after uninstalling.
The only pending intents that were not explicit were the four from
the NotificationHelper class. These now explicitly specify the
NotificationBroadcastReceiver as their destination, which is not
exported. That then forwards the intents onto relevant methods of
AppUpdateStatusManager.
