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.
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.
PMD does not like manually throwing NPEs, even if they have more verbose
information than the default NPE. As such, use an
`IllegalArgumentException` instead.
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.
With this, it was leaving the app's locale set to the last language on
the LOCALES_TO_TEST list, which is 'zu' (Zulu). For some dialogs, it
was actually using that locale, so showing OK/Cancel in Zulu despite
the app being in a different language.
#943
Java's Map.get() returns null if there is no match, so this was always
setting each entry to whatever value was in the highest priority
locale, whether it had contents or what null. Now, this will fall
through the priority list of locales until it finds actually contents.
A TreeSet apparently does not really maintain insertion order, while a
LinkedHashSet does. This ensures that the insertion order of locales
is preserved in localesToUse so that the prioritization is correct.
Just let the SecurityException be throwing where it originated.
From PMD: "A catch statement that catches an exception only to wrap it
in a new instance of the same type of exception and throw it should be
avoided".
This cleans up a little from !482. Ctrl-Alt-L and Ctrl-Alt-O before
committing! :-)
* On API >= 24, in cases when the installer package name is not set
to privext, the system won't let us uninstall.
* Fallback to the DefaultInstaller so that uninstall still works.
* When there's a permission mismatch (#951, #890), the fallback
DefaultInstaller is invoked, which enforces file and content schemes
for API < 24 and >= 24 respectively.
* Use content URI in that case, which allows the fallback to work.
<plurals> handles the grammar needed for numbers/quantities in various
languages. Like in a number of slavic languages, numbers ending in 0,
1 or others have separate grammar. In English, there is just 1 and
then all the rest (0 days, 2 days, 3 days, etc). <plurals> does not
handle multiple strings for different quantities, like having a
different string for each number case. For that, we have to do it in
Java and have multiple <strings>
!472
Prior to this, it would only update the "Uninstall"/"Run"/"Upgrade"
buttons after a fresh install, or an uninstall.
This change is a bit more liberal in how often we try to update the
view, due to a race condition with PackageManager and AppDetails2.
AppDetails2 listens for InstalledAppProviderService in onResume, but
sometimes that is too late (the notification has already fired).
fdroidserver currently only supports a single WhatsNew field that
comes from the CurrentVersionCode of the app. Google Play and
fastlane supply support a WhatsNew field per-release, but we don't use
that data anywhere, and implementing that in the data structures would
add a lot of complexity since Apk would then need to have its own
"localized" section like App does.
The "Video" field is just a URL pointing to a video.
closes#910
I added Esperanto because someone asked, and Shqip since it is not
available in Android 5.1 and people who speak Shqip would be likely to
open the language menu to switch away from English, then they'd see
Shqip as an option. This still won't take effect until those
languages are fully translated.
closes#941
The point here is to use the English work all lowercase, so make sure
that the English lowercasing rules are always active, regardless of
the system's locale.
The original single language description gets stuck straight into
App.description by Jackson. getLocalizedEntry() might return a null,
in which case it was overriding the original description. This only
overrides the original description if there is actually a localized
description.
* Replace hardcoded color values with references to style.xml,
which in turn has different values for light and dark theme.
* Force reload the activity to get the theme applied.
TODO:
* Swap uses it's own theme, need to figure out a way to
handle that. Currently the main Nearby screen which you get
to from the bottom navigation is ok, but anything after
that is light / custom themed.
Given the only feedback available to the user that they initiated a
download once clicking the version from the list is up top, this scrolls
the recycler view to the top to show that feedback.
Also shows the selectable background when they touch the version list
items.
Previously, it assumed that featureGraphic et al. were always present if
the localised entry was present. This is not the case, so we only return
a URL if we can actually find the entry we are looking for.
Prior to this it was black, which looked broken. This also ensures that
the blue is shown behind the dynamic colour when it is time to ease in
that colour.
