This adds the F-Droid icon to the .idea directory which allows .idea applications to show it in several places, e.g. in the Toolbox app. This helps to find the correct project if you are working on the many projects. The file is a copy of /logo-icon.svg
Follow up for !1424
With the previous implementation getPercent(1, 200)` returned 1 and getPercent(199, 200) returned 100. The latter is quite misleading, especially when dealing with bigger numbers where the notification could show 100% although the file is still downloading.
Four fixes for acra issues
Closes acra-crash-reports#749, acra-crash-reports#748, acra-crash-reports#741, and acra-crash-reports#740
See merge request fdroid/fdroidclient!1423
The default `simple` tokenzier config used in Room/SQLite3 FTS4 makes only ASCII characters case insensitive. The SQLite FTS3/4 doc [1] says:
> All uppercase characters within the ASCII range (Unicode codepoints less than 128), are transformed to their lowercase equivalents as part of the tokenization process. Thus, full-text queries are case-insensitive when using the simple tokenizer.
> The remove_diacritics option may be set to "0", "1" or "2". The default value is "1". If it is set to "1" or "2", then diacritics are removed from Latin script characters as described above. However, if it is set to "1", then diacritics are not removed in the fairly uncommon case where a single unicode codepoint is used to represent a character with more that one diacritic. [...] This is technically a bug, but cannot be fixed without creating backwards compatibility problems. If this option is set to "2", then diacritics are correctly removed from all Latin characters.
This change makes use of the intended behaviour by using the `unicode61` tokenizer with the `diacritics="0"` option to keep the behaviour similar to the current one. This replaces the previously used `simple` tokenizer. A migration is necessary to recreate the AppMetadataFts table to make use of the different tokenizer.
[1] https://www.sqlite.org/fts3.html#tokenizer
This fixes an NPE that was triggered when deleting a repo via the RepoDetailsActivity. The repo is null after it has been deleted. The corresponding RepoDetails are now closed after the deletion.
When the scheduling time is in the past, our job should have run already, but did not, because conditions we require weren't fulfilled. Times in the past are confusing for users, so we just report that the next run is waiting for conditions to be fulfilled.
One known use-case for this is to do an initial repository update during SetupWizard, so app data is available when needed, e.g. for restoring app backups.
to replace UpdateService which is still based on deprecated JobService API and known to be unreliable.
This also introduces a new lean NotificationManager which can eventually supersede the old one.
This is mostly for efficiency, since it queries the DB for new updates anyway, so it can already enqueue those for auto-update if the respective settings allow.
If an update was available from a disabled repo with a higher priority, the update from an enabled repo with a lower priority would not be offered as an update (i.e. returned by DbUpdateChecker#getUpdatableApps()).
