Fix issue #202 - crash due to sqlite parameter limit being hit.
*NOTE: Queuing here for merge after next stable.*
The queries which have the potential to cause crashes due to too many parameters in the `ApkProvider` are now encapsulated in `ApkProvider` and can only be accessed by safe helper methods, which alleviate the problem by breaking big requests down into many smaller requests.
This will probably have to be done for the `ApkProvider`, but leaving for now because the limit is twice as big.
See merge request !70
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.
There was some confusion about the "SD Card" portion of the string.
Sometimes it will not store on the SD card, e.g. if the SD card is
not mounted, or inaccessible to F-Droid.
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).
Android's lint will give warnings for all strings that are not translatable
or translated. Some strings like repo name/description and language codes
should never be translated. Here's how to officially mark as "do not
translate":
* for individual strings, include: translatable="false"
* for the entire file, name it: donottranslate.xml
http://tools.android.com/recent/non-translatablestringshttps://code.google.com/p/android/issues/detail?id=75163
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.
