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.
Although the adapter tries to keep in sync with the app status update
manager, there may be times when this is not successful. In such
circumstances, it seems safe to just guard against invalid situations,
rather than trying to assert an error or fall over.
Fixes#922.
There was some confusion in the user tests about how to launch an app
once it was installed. Hopefully this small change goes towards fixing
some of that confusion. Instead of just showing "X installed
successfully" in the app list, it now shows a "Run" button next to it.
When navigating to Updates -> Show Apps and then downloading an item, it
shows the download progress inline for that item. After this is
complete, it then shows a tick icon next to the item. The long term goal
should be to remove the list item from under "Show Apps" so that it is
only shown at the top of the "Updates" view. However this will require
more work. In the meantime, we can alleviate some confusion by replacing
the "Tick" icon with a button that says "Update" (like the other buttons
in the Update view).
When dismissing an "X installed successfully" intent, it should also
dismiss the relevant item from the "Updates" screen. This was not
happening. Upon investigation, I noticed that when I dismissed a
notification, it was passing through the Apk which I installed over a
day ago. This is because it was reusing a previous pending intent rather
than creating a new one.
Now that we've moved the first screen to "Latest", we always want to do
our best to show something there. This preference is pretty redundant in
light of this.
Previously, the definition of "New" was whether or not the added and
last updated dates were the same. This made sense, because we only
showed apps from the past few weeks (depending on preferences) as new.
Now that we show up to 200 apps in the first screen, regardless of age,
this check is no longer helpful.
It seems pointless to only restrict "Latest" to items within the last X
days. When you only have the GP repo enabled, or other repos with less
apps that are updated less frequently than the main repo, this screen
always ends up empty. This change shows the last 200 updated items
instead of those updated in the last X days.
The text is more comprehensive on the main screen than on categories,
because this is the view that all users will see when they first open
F-Droid.
Fixes#879.
Previously this was only shown in the notifications.
This does not show the full progress of the update, but at least it
provides a rudimentary level of feedback. In the future it can be
modified to show more substantial feedback if required.
This results in a slightly larger apk (e.g. 500KiB), but it reduces the
scope for bugs greatly. We still get all the benefits of only having to
maintain a single density-independent vector (rather than several
density dependent PNGs and all the work that involves).
The class of bugs that it solves is that there are several places where
vectors cannot be used, and you wont notice when developing on a device
newer than 5.0. For example, notification icons, `TextView`
and its `android:drawableStart` attribute.
Fixes#913.
It was assuming there is always a priv ext preference. However, we
remove the priv ext preference the first time the fragment is opened. In
these circumstances, the preference no longer exists, resulting in a
NPE.
Unused for now, but like with the `LoggingQuery`, it is helpful to
be used for debugging purposes. For example, used this to quickly
figure out that it took 7 seconds to fix the PRNG stuff in FDroidApp
onCreate().
