Cache files to SD card again (if preference set).
**NOTE: Queueing here to be merged after next stable**
A previous security fix meant we no longer stored apk files on the
SD card. However, this should still be a feature that people can opt
for if they want, without being insecure. As such the process is now:
* First download: put in internal storage (to ensure it can't be
modified before installing)
* After download: also copy to SD card for caching.
* On starting F-Droid:
+ Always delete internal storage apks.
+ Only delete other, cached apks if cache preference is false.
To make the code simpler and less prone to bugs, I had to consider
the fact that if people did not have an accessible SD card, then the
path to a cached apk and a "downloaded but transient" apk cannot be
the same. While possible, it means many checks to see if they are
the same, thorough permission management to prevent security issues,
and makes it harder to clear transient apks when F-Droid starts.
See merge request !71
A previous security fix meant we no longer stored apk files on the
SD card. However, this should still be a feature that people can opt
for if they want, without being insecure. As such the process is now:
* First download: put in internal storage (to ensure it can't be
modified before installing)
* After download: also copy to SD card for caching.
* On starting F-Droid:
+ Always delete internal storage apks.
+ Only delete other, cached apks if cache preference is false.
To make the code simpler and less prone to bugs, I had to consider
the fact that if people did not have an accessible SD card, then the
path to a cached apk and a "downloaded but transient" apk cannot be
the same. While possible, it means many checks to see if they are
the same, thorough permission management to prevent security issues,
and makes it harder to clear transient apks when F-Droid starts.
Now the other content provider functions which can result in broken SQL
due to the number of arguments is private, and can only be accessed
from a public helper method which ensures that limit is never hit.
The static delete helper function in ApkProvider now supports
recursively reducing the size of the list of apks to delete, until
it is under the threshold that sqlite can handle.
There are two places where translations get populated. One of them (when
the fragment is initialized) translates the categories. The other place
(when the "installed app cache" background process completes) did not
translate the category names. They are now both translated.
Change some "defaultValue"s
Key "theme": I also use the dark version of F-Droid but I think the most users would prefer the light version. This is also standard in the
most used apps on Android, I think, see GApps, Flym, K-9, Telegram, ...
Key "localRepoBonjour": I never used this function and I think it's better, if the user manually activates it when he wants to use it.
Key "localRepoHttps": I see no reason why it should not use https over http, it's better of security view, I think.
Key "cacheDownloaded": The most smartphones today have enough storage available to allow to enable this function. This would decrease the
traffic on both sides, as the user does not have to download a app and the F-Droid server does not have to send it multiple
times.
This is somehow related to #221, I think.
See merge request !67
The error below was happening on my crappy slow phone, I suspect because
the database upgrade check was locking the database, while this was
scheduled and started running on a different thread. Given it is a very
low priority task (it notifies F-Droid if apps were installed by a method
other than F-Droid) it is now delayed by 10 seconds.
E FATAL EXCEPTION: AsyncTask #1
E java.lang.RuntimeException: An error occured while executing doInBackground()
E at android.os.AsyncTask$3.done(AsyncTask.java:200)
E at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:274)
E at java.util.concurrent.FutureTask.setException(FutureTask.java:125)
E at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:308)
E at java.util.concurrent.FutureTask.run(FutureTask.java:138)
E at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1088)
E at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:581)
E at java.lang.Thread.run(Thread.java:1019)
E Caused by: android.database.sqlite.SQLiteException: database is locked: BEGIN EXCLUSIVE;
E at android.database.sqlite.SQLiteDatabase.native_execSQL(Native Method)
E at android.database.sqlite.SQLiteDatabase.execSQL(SQLiteDatabase.java:1763)
E at android.database.sqlite.SQLiteDatabase.beginTransactionWithListener(SQLiteDatabase.java:527)
E at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:481)
E at org.fdroid.fdroid.data.FDroidProvider.applyBatch(FDroidProvider.java:58)
E at android.content.ContentProvider$Transport.applyBatch(ContentProvider.java:217)
E at android.content.ContentProviderClient.applyBatch(ContentProviderClient.java:95)
E at android.content.ContentResolver.applyBatch(ContentResolver.java:639)
E at org.fdroid.fdroid.data.InstalledAppCacheUpdater.updateCache(InstalledAppCacheUpdater.java:98)
E at org.fdroid.fdroid.data.InstalledAppCacheUpdater.update(InstalledAppCacheUpdater.java:64)
E at org.fdroid.fdroid.data.InstalledAppCacheUpdater$Worker.doInBackground(InstalledAppCacheUpdater.java:163)
E at org.fdroid.fdroid.data.InstalledAppCacheUpdater$Worker.doInBackground(InstalledAppCacheUpdater.java:159)
E at android.os.AsyncTask$2.call(AsyncTask.java:185)
E at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:306)
E ... 4 more
Use custom code rather than "Locale.forLanguageTag" (which is android-21
specific). Also fixed the actual setting of the language, by modifying
the code in FDroidApp to respect the country code (rather than just the
language code).
Key "theme": I also use the dark version of F-Droid but I think the most users would prefer the light version. This is also standard in the
most used apps on Android, I think, see GApps, Flym, K-9, Telegram, ...
Key "localRepoBonjour": I never used this function and I think it's better, if the user manually activates it when he wants to use it.
Key "localRepoHttps": I see no reason why it should not use https over http, it's better of security view, I think.
Key "cacheDownloaded": The most smartphones today have enough storage available to allow to enable this function. This would decrease the
traffic on both sides, as the user does not have to download a app and the F-Droid server does not have to send it multiple
times.
Also forceably hid the "update all" button in the update tab.
This is because on my crapy LG Tracphone android-10 device, it is slow
enough that I can see that button appear and then disappear.
Also changed the way locales are loaded. Now it deals well with language
codes that are followed by country codes (e.g. "en-US" rather than just
"en").
Change client language from the app options (#155)
Bug: ActionBar Language does not change.
Edit: To make it more clear, you have to restart the app manually for the action bar language to be changed.
See merge request !65
It does this by sending a HTTP POST request to /request-swap on the
swap server. That listens for a POST to this path, and responds by
popping open a confirmation message to the user on the server device.
The categories were previously selected in the Spinner, then passed
directly to the database. Once the categories became translated, this
meant we were sending the translated category to the database.
However, the database only knows about English categories, and so we
instead need to look up the English translation for the selected
category before passing to the database. This is done by keeping
a list of original category names which is indexed the same as the
translated ones.
