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
Since we have all these lovely scripts for cleaning up the
translations, gitlab-ci is a handy way to enforce that they get used.
Since weblate merges happen via merge requests, this will work nicely
now. I can't think of any false positives that will arise, but we
shall find out!
XML namespaces are a massive pain to deal with in, and they are totally
unneeded in the translation files. xmlns:tools is only needed in the
source file to ignore some lint warnings.
