Correct meeting time
With the discussion on IRC [starting here](https://botbot.me/freenode/fdroid-dev/2016-11-14/?msg=76442333&page=1), the time in `README.md` is wrong.
> We are on `#fdroid` and `#fdroid-dev` on Freenode. We hold weekly dev meetings on `#fdroid-dev` on Tuesdays at 20h UTC, which usually last half an hour.
[It should be](https://botbot.me/freenode/fdroid-dev/2016-11-15/?msg=76516527&page=1) be:
> We are on `#fdroid` and `#fdroid-dev` on Freenode. We hold weekly dev meetings on `#fdroid-dev` on Thursdays at 8:30h UTC, which usually last half an hour.
See merge request !424
Translators:
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
Andreas Nordal Norwegian Bokmål
Clara Chido Shona
Enol P Asturian
E T Turkish
ezjerry liao Chinese (Traditional)
Licaon Kter Romanian
naofum Japanese
Nebojsa Tausanov Macedonian
Nutchanon Wetchasit Thai
Osoitz Basque
Sylvia van Os Dutch
Tawanda Mugari Shona
Verdulo Esperanto
Verdulo Polish
Yaron Shahrabani Hebrew
YFdyh000 Chinese (Simplified)
zmni Indonesian
Ensure categories are not shown unless there are apps in them
**Note: To be hot fixed into 0.102.1 also when merged.**
Fixes#806. Also adds tests to hopefully prevent this from regressing in the future.
Ensure app-category join table is cleared out properly upon disabling repo.
There are certain things we can leave in the database even when they are not being used. The criteria for this is:
* Could it be used again in the future?
* Can it be excluded from queries easily while it is unused?
Examples are entries in the package table, and entries in the category table.
This fixes a problem where entries in the category-app join table stayed in the database, causing categories to be considered as "in use" when really there were no apps in those categories. These rows need to be removed, because when new apps are added again in the future, they will have different primary keys. These different primary keys mean that the rows in the category-app table will never be useful again, and thus should be removed.
See merge request !418
Unfortunately, something in the way that the docker image is created is
making it impossible to run `android update sdk`. Even though it runs as
root, it cannot upgrade things, and in the process, it seems to break the
Android SDK bits that are there.
Installing Android Support Repository, revision 40
Failed to rename directory /android-sdk/extras/android/m2repository to /android-sdk/temp/ExtraPackage.old01.
Failed to create directory /android-sdk/extras/android/m2repository
Done. Nothing was installed.
A problem occurred configuring project ':app'.
> Failed to notify project evaluation listener.
> You have not accepted the license agreements of the following SDK components:
[Android Support Repository].
Before building your project, you need to accept the license agreements and complete the installation of the missing components using the Android Studio SDK Manager.
Alternatively, to learn how to transfer the license agreements from one workstation to another, go to http://d.android.com/r/studio-ui/export-licenses.html
> Could not resolve all dependencies for configuration ':app:compile'.
> Could not find com.android.support:support-v4:24.2.1.
Required by:
project :app
> Could not find com.android.support:appcompat-v7:24.2.1.
Required by:
project :app
> Could not find com.android.support:support-annotations:24.2.1.
Required by:
project :app
There are certain things we can leave in the database even when they
are not being used. The criteria for this is:
* Could it be used again in the future?
* Can it be excluded from queries easily while it is unused?
Examples are entries in the package table, and entries in the category table.
This fixes a problem where entries in the category-app join table stayed in
the database, causing categories to be considered as "in use" when really there
were no apps in those categories. These rows need to be removed, because when
new apps are added again in the future, they will have different primary keys.
These different primary keys mean that the rows in the category-app table will
never be useful again, and thus should be removed.
Fixes#806.
Fixed long version overriding app name (issue #322)
Also, fixed deprecated "singleLine" property to "maxLines="1"".
Also removed reduntant (legacy) padding declarations, for the files used exclusively by newer APIs which override those declarations with new ones.
See merge request !417
Rework net for 0.102
This is a collection of targeted fixes for the %"0.102" release. Most of them are quite narrowly targeted bug fixes. I couldn't avoid reworking the update scheduling in order to fix some of the listed bugs. This is the only part that seems possible to have regressions. In any case, if there are regressions, they will be in a very limited chunk of the code, in `UpdateService`, which we have no plans to touch in %"0.103 - UX Overhaul" so it'll be easy to do a 0.102.1 release.
See merge request !415
Also, fixed deprecated "singleLine" property to "maxLines="1"".
Also removed reduntant (legacy) padding declarations, for the files
used exclusively by newer APIs which override those declarations with new ones.
This introduces three network states:
1. completely disconnected
2. connected only via metered networks
3. connected via unlimited networks
This allows the update process to use bandwidth better, especially when the
user has enabled the "Only on WiFi" setting. It also helps prevent silly,
cryptic error messages in the update process is triggered when there isn't
internet available.
I tested this with:
* 4G only, but not set up for internet
* 4G only, with internet
* 4G + WiFi
* WiFi only airplane mode
* no internet at all, full airplane mode
closes#793closes#774
Its really easy to use USB Ethernet devices with ChromeOS and some Android
devices like Android TV. ChromeOS now supports Android apps. Since really
the goal is to avoid metered networks, and ethernet is very rarely metered,
this fits in with the user expectations around the preference. And if it
doesn't, there are very few people using Ethernet with F-Droid right now,
so whatever harm does happen will affect an extremely limited number of
people.
First, this is more honest than just using the default since it is saying
what the actual software is. Second, it protects identity, since the
default User Agent on Android can have a lot of info in it, for example:
"Dalvik/2.1.0 (Linux; U; Android 5.1; XT1039 Build/LPBS23.13-17.3-1)"
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
