The real solution would involve figuring out where to handle this in the
right spot in the lifecycle. Since AppDetails is being totally replaced,
this is just to stop the crashing.
closes#802
InstalledAppProviderService tries to keep a running log of what is actually
installed on the device. It seems that ApplicationInfo.sourceDir and
related things sometimes returns a dir rather than an APK. So try to find
an APK in that folder.
closes#801
Store categories in separate category table
Currently, the category that an app is in is recorded in the database via the `fdroid_app.categories` column, containing a comma separated list of strings. This makes it hard to query. The existing code to get a list of categories was pretty bad as a result.
This moves to a different data model whereby categories are stored in a separate table. Each repo is free to specify that an app is in arbitray caregories (as with before). This is represented by a join table between categories and app metadata.
The end result is that categories are much more a first class citizen than before, and they will be able to be queried easier - which is important for the new UI.
Note that the categories table need never be emptied, it can keep being appended to. The reason is that if there are no apps in a particular category (represented by no corresponding rows in the join table) then the category will not be shown to the user.
See merge request !409
Improve performance when changing "Unstable Updates" preference
This is only a partial solution to #520.
It does as I suggested in the issue comments, by doing less work when the preference is checked. The proper solution is an `IntentService` which queues requests to update these details, but that is a (slightly) larger change for the future.
I also noticed it wasn't correctly notifying the UI of the change, so this now notifies the list of apps which can be updated. That was hard to test though, so not sure if it updates the UI correctly or not. It shouldn't do it _incorrectly_, but it may not work. The reason it should work is because the `AppListFragment` (baseclass of `CanUpdateAppsFragment`) uses a cursor loader with the `AppProvider.getCanUpdateUri()` URI. This `CursorLoader` should automatically attach an observer for that URI and requery if required.
See merge request !414
Fall back to InstalledAppProvider when trying to identify the apk to uninstall.
Extracted `getInstalledApk()` method so that it could be better documented, and
makes the `uninstallApk()` more consise. It will now throw an `IllegalStateException`
if no apk is found, because as issue #800 shows we will end up with a NPE otherwise.
Fixes issue #800.
See merge request !413
Extracted `getInstalledApk()` method so that it could be better documented, and
makes the `uninstallApk()` more consise. It will now throw an `IllegalStateException`
if no apk is found, because as issue #800 shows we will end up with a NPE otherwise.
Fixes issue #800.
During development of a new feature, I noticed a bug occuring only after using
the new feature for several days. This was because the metadata only infrequently
changes in ways which cause certain code paths to be hit. By having the f-droid.org
metadata from several days apart in the test suite, it allows for testing more
of these cases. In the future, even later versions of the metadata can be added
to ensure that we can update happily from old to new metadata.
This ensures that all of the relevant joins are in place, so that when
the updater asks to `queryPackageName()` then it can assume that we have
already joined onto the `Schema.PackageTable`.
Renamed the `Schema.AppMetadata.Categories.CATEGORIES` constant into the
`Schema.AppMetadata.ForWriting.Categories.CATEGORIES` constant. This is
to make it very clear that it is not for reading from the database.
When updating existing apps or inserting new apps, instead of splatting
a comma separated list into a single sqlite3 column, we now put it into
several rows in the `CatJoinTable`. This is done after deleting existing
categories, to make sure that if the app has been removed from a category,
then this is reflected during the update.
It was hidden some time ago, and nobody seems to miss it.
Also, we will be redoing this view soon anyway. In the meantime,
this category stuff is changing and this view should be removed.
Be a little more concise about when we need to run migration for v64.
Before it is not apparant that the migration introduced for v64 is associated with that particular version. This is because the guard condition used to bail out from the upgrade is more closely related to a previous migration.
This is due to a flaw with the desigh of `resetTransient()`, whereby it always resets the database to the schema _of the current F-Droid version being run_, not of the tables as they stood at the time of the particular migration being introduced.
This clarifies the guard condition for v64 by allowing it to query whether the schema has been created fresh or not during this particular invocation of `onUpgrade()`
**Note:** this is less to do with the v64 migration, but rather I came across the exact same issue while working on category table related changes. At that point I realised I made a slight mistake with the `resetTransient()` method.
**Also:** I'm happy to entertain other designs if anybody is that interested. One other approach is to change the guard condition to:
```
if (version >= 64 || fieldExists(db, ApkTable.NAME, "...")) {
... add field ....
}
```
However that suffers a little bit when the migration is a little more complex and checking if a field exists may not be enough.
See merge request !408
For some reason, the existing approach of "select * and then see if the
column of interest is in the results set" didn't work as expected under
tests. Perhaps SQLite is caching the list of columns for the purpose of
`select *` even after running an `alter table add column` query?
Either way, I couldn't figure out why it wasn't working as expected.
This left us with two options:
* Try to `select columnToCheck` and see if it throws an exception
* Query columns using `PRAGMA table_info.
The exception thrown when a column doesn't exist is not specific enough
for our code to check that this is the exact exception that occured. It
is not possible to say: `try { ... } catch (SQLiteColumnNotFound e) { ...}`
unfotunately. Also, there is a cost associated with unwinding the stack
to process an exception, which means exceptions probably shouldn't be
used in unexceptional circumstances such as this.
This change instead uses `PRAGMA table_info(tableOfInterest)` and then
iterates over the cursor looking for the relevant column. Even if the
performance is worse than the stack unwinding of an exception, it is
more concise and less hacky.
The fact there are arbitrary migrations at the top of the file (between
`onCreate()` and `onUpdate()` makes it harder to scan this file.
This changeset moves these methods verbatim, without changing any of
the method bodies or signatures.
Before it is not apparant that the migration introduced for v64 is
associated with that particular version. This is because the guard
condition used to bail out from the upgrade is more closely related
to a previous migration.
This is due to a flaw with the desigh of `resetTransient()`, whereby
it always resets the database to the schema _of the current F-Droid
version being run_, not of the tables as they stood at the time of
the particular migration being introduced.
This clarifies the guard condition for v64 by instead explicitly asking
if the columns of interest exist yet in this particular invocation of
`onUpgrade()`.
Fix npe verifying perms
Fixed a NPE for apps with no permissions.
Here is an example of the logging output for a couple of apps too after my change:
```
D/ApkVerifier(10929): Checking permissions
D/ApkVerifier(10929): Actual:
D/ApkVerifier(10929): None
D/ApkVerifier(10929): Expected:
D/ApkVerifier(10929): None
```
and
```
D/ApkVerifier(10929): Checking permissions
D/ApkVerifier(10929): Actual:
D/ApkVerifier(10929): android.permission.READ_EXTERNAL_STORAGE
D/ApkVerifier(10929): android.permission.WRITE_EXTERNAL_STORAGE
D/ApkVerifier(10929): android.permission.SET_WALLPAPER
D/ApkVerifier(10929): android.permission.SET_WALLPAPER_HINTS
D/ApkVerifier(10929): android.permission.WRITE_SETTINGS
D/ApkVerifier(10929): Expected:
D/ApkVerifier(10929): android.permission.SET_WALLPAPER
D/ApkVerifier(10929): android.permission.READ_EXTERNAL_STORAGE
D/ApkVerifier(10929): android.permission.SET_WALLPAPER_HINTS
D/ApkVerifier(10929): android.permission.WRITE_SETTINGS
D/ApkVerifier(10929): android.permission.WRITE_EXTERNAL_STORAGE
```
See merge request !407
This wouldn'tve actually found the problem in the previous commit,
due to the null happening before checking permissions while logging perms.
However, still seems like a nice test to have so that the method itself
handles nulls correctly.
Improved category tests
In preparation for implementing the [new category UI](https://gitlab.com/fdroid/fdroidclient/uploads/01d865e65604c41b0a472f0d39e7f1a7/Categories.png) I will be refactoring the database so that categories get their own table. In preparation for that, this MR improves the categories tests so that they also test the ability to query apps based on their categories.
See merge request !406
The previous category tests only checked that certain categories
would indeed find their way into the database if certain app metadata
is saved. It didn't check the other direction, using these categories
in queries.
Support extended <uses-permissions/> tags
`<uses-permission-sdk-23>` is a new tag for requesting permissions on _android-23_ and above. `<uses-permission/>` and `<uses-permission-sdk-23>` both can have optional _maxSdkVersion_ values, and these need to be fully supported in order for the Privileged Extension to be able to check the APK permissions against the index.xml permissions. This is needed so that it can prompt the user once, then download and install the APK after that. Its also needed for transparent background updates to check if the permissions have changed in the update.
This gets closer to the complete support, really the full permissions should be stored in the database. Then the only
conversion would happen ewhen parsing the XML. Right now, it still stores the old F-Droid permissions names, i.e. without
`android.permission.`. Then those are converted when they are loaded from the DB into an Apk instance.
See merge request !402
<uses-permissions/> tags can have min and max SDK to take effect. This is
not supported currently, and it necessary especially with the privileged
installer so it can properly represent the permissions that an APK is
requesting.
For example:
<uses-permission
android:name="android.permission.MANAGE_ACCOUNTS"
android:maxSdkVersion="22" />
<uses-permission-sdk-23
android:name="android.permission.CAMERA" />
<uses-permission-sdk-23
android:name="android.permission.CALL_PHONE"
android:maxSdkVersion="23" />
android.content.pm.PackageInfo is the Android class for representing data
about an APK/package. Since Apk.permission is the same thing, we should
use the same name.
Android won't protect us from other apps sending other Intents to these
receivers, so at least check that the action string matches what its
looking for. This is based on a lint recommendation.
