This is thinking of the future, when new AFs are added and the installed
client doens't know about them yet. Showing the name is better than not
showing anything at all.
Translators:
Adrià García-Alzórriz Catalan
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
Allan Nordhøy Norwegian Bokmål
Enol Puente Asturian
Kalle Lampila Finnish
Marcelo Santana Portuguese (Brazil)
Mladen Pejaković Serbian
naofum Japanese
Tobias Bannert German
Андрій Бандура Ukrainian
Саша Петровић Serbian
Add opt-in crash reporting via ACRA
Fixes#398.
Screenshot: https://imgur.com/E3uNIBY
E-mails to team@, so the reports are somewhat private yet still available to developers.
Using e-mail over POST has two advantages:
* Doesn't require a specific server handling the form submits
* Makes interaction with users who reported issues easy (we can just reply to the e-mail to ask for more info, etc)
It also has a disadvantage, though:
* It requires an e-mail app to be present and set up in the device
Most phones are already logged in to user's Google accounts, though, and a large part of those have the gmail app or the stock mail app installed. Those who don't have Google installed are probably technical enough to have set up a mail client like K9 on their own.
See merge request !185
Renaming id -> packageName in local variables/method args/comments/etc.
Building on the previous MR. This finishes renaming "id" in the Java code to "package name" where appropriate. It still leaves the database symbols as "id" because they are not worth the effort to rename at this point in time.
See merge request !184
Rename id to package name
As suggested in issue #37, "id" is not the correct terminology to use in the code base. Instead, it should use "package name". I'm doing this now before I begin work on #511, where it is helpful to recoup the "id" name, as "rowid" in sqlite refers to a row's integer primary key.
This changes the following Java symbols:
* `Apk.id` -> `Apk.packageName`
* `App.id` -> `App.packageName`
* `ApkProvider.DataColumns.ID` -> `ApkProvider.DataColumns.PACKAGE_NAME`
* `AppProvider.DataColumns.ID` -> `AppProvider.DataColumns.PACKAGE_NAME`
* A small number of comments referring to `id`.
It does _not_ change (and likely will not benefit from changing):
* Any database columns, these are all still `id`.
* Anything pertaining to the index, which still uses `id`.
It does _not_ change (but future MR's will change):
* Local variables referring to `id`
* Method names referring to `id`
By not changing any string literals, only changing the name of variables and constants, and ensuring that the original variables/constants are no longer present, then in theory if this compiles is should be good to merge.
See merge request !183
Make sure to insert, rather than update apks when updating repo.
(Actually) fixes#517. I had a hunch the other bug (though problematic) wasn't actually the fix for #517. I am confident that this one _is_ the fix, although I am still struggling to reproduce specific circumstances reported by others. I tracked this down when I did an update this morning and noticed a new app without any versions - so in a way I kind of reproduced it, but I can't reproduce it at will.
The problem was that again, only the `vercode`s of apks were being
compared to see if they were the same, rather than `vercode` and `id`.
The result is that some new apks will incorrectly be asked to execute
an `UPDATE` query rather than an `INSERT`. As such, they don't end
up in our database at all because the `UPDATE` will not run against
any row at all.
See merge request !182
Fixes#517.
The problem was that again, only the `vercode`s of apks were being
compared to see if they were the same, rather than `vercode` and `id`.
The result is that some new apks will incorrectly be asked to execute
an `UPDATE` query rather than an `INSERT`. As such, they don't end
up in our database at all because the `UPDATE` will not run against
any row at all.
Correctly purge removed apks.
There were two bugs in this code that have been fixed. Both were
introduced while moving to a lower memory consumption version of
the repo updater for #324.
They were found while investigating #517, although I'm not confident
that they are to do with the specific problem in that issue. It is
possible, because it is part of the code to do with purging apks
from the database, but I'd like to do further investigations into
the code before declaring that this is actually related to that issue.
In the mean time, this includes important fixes, and should probably
go out in an alpha once merged.
The first is that for each app which is updated by a particular repo,
it was not correctly asking the question: "Which apks belonging to
this apk, and provided by this repo, are no longer provided by this
repo?". It was accidentally only comparing the version number of
existing apks in the DB and new apks from the index. This ensures
that the apks being checked to see if they need to be removed or
not are those with the same package name AND the same version code
(provided by the same repo).
The second bug is that when it was persisting a set of apps + apks
to the database, it would ask for existing apks already in the
database for these apps. In this case, there was a bug where of
the 50 apps being persisted, it would only retrieve the first of
these 50 apps from the database to decide if it needed to be
cleaned up or not. Now, it correctly retrieves data from the DB
belonging to all 50 apps.
See merge request !181
There were two bugs in this code that have been fixed. Both were
introduced while moving to a lower memory consumption version of
the repo updater.
The first is that for each app which is updated by a particular repo,
it was not correctly asking the question: "Which apks belonging to
this apk, and provided by this repo, are no longer provided by this
repo?". It was accidentally only comparing the version number of
existing apks in the DB and new apks from the index. This ensures
that the apks being checked to see if they need to be removed or
not are those with the same package name AND the same version code
(provided by the same repo).
The second bug is that when it was persisting a set of apps + apks
to the database, it would ask for existing apks already in the
database for these apps. In this case, there was a bug where of
the 50 apps being persisted, it would only retrieve the first of
these 50 apps from the database to decide if it needed to be
cleaned up or not. Now, it correctly retrieves data from the DB
belonging to all 50 apps.
Add HTTP Basic Authentication to ApkDownloader
In order to download protected files, the APKDownloader must be able to supply HTTP Basic Authentication headers to the server.
See merge request !178
Translators:
Ajeje Brazorf Sardinian
Green Lunar Hebrew
Ldm Public French
lucnsy Chinese (China)
Massimiliano Caniparoli Italian
Mladen Pejaković Serbian
naofum Japanese
Nordlenningen Norwegian Bokmål
Sérgio Marques Portuguese (Portugal)
Tobias Bannert German
Vdragon, Ｖ字龍 Chinese (Taiwan)
Search as the user types
Fixes#323.
This does away with the separate `SearchResult` and instead applies the search to the currently viewed tab on the main screen (Available, Installed, Updates). When filtering the Available list, it filters the currently selected category.
Note however that there are still times when the old style `SearchDialog` will be shown over the top of the action bar rather than the `SearchView` within the action bar. These times include:
* When a user with a hardware keyboard starts typing from the main screen.
* On older devices with a "search" hardware button.
* Probably some other cases (I think when there is not enough screen real estate, but haven't seen that happen).
In cases where this dialog is shown, filtering the lists as you type does not seem to be an option. I tried to figure out how to do that, but failed. If someone else figures it out, that would be great. However, when the search is submitted, it will hide the `SearchDialog` and populate the `SearchView`, focus it, and apply the search appropriately.
There is a script in the `F-Droid/tools/` subdirectory which will consecutively send various intents to F-Droid relating to search. This includes Play, market, Amazon search links. For good measure, I also made it send intents to do with viewing app details. This should probably be made into a proper instrumented test at some point, but I didn't have the time to figure out how to do that. Maybe a project for future @pserwylo.
One unknown is the performance implications. There is no problems on my Nexus 4 with Android 5.0. My Chinese/ebay/$30/Android 2.3.4 device seems good enough too.
See merge request !177
The system's are sometimes wrong, e.g. unexpected names. This also helps
our support across different Android versions without having to worry as
much about the system's language support.
Fixes#503.
Translators:
Dario Tordoni Italian
Elia Argentieri Italian
Enol Puente Asturian
halcyonest Korean
M2ck French
relan Russian
Tobias Bannert German
Дмитрий Михирев Russian
In addition, added a @Nullable constraint on the categorySpinner
and a null guard when resuming the fragment to handle possible
null cases (though I don't think there will be any).
This caused the entire list view to e animated when navigating
back to the Available tab. Tried switching the `animateLayoutChanged=true`
to a child view only containing the category spinner, but this is not how
the animation handling works. It needs to animate both the thing being
hidden/shown, and also the next sibling of that thing to work properly.
Thus, moving the spinner to its own child and leaving the list didn't work.
Speed up "Saving Application Details" part of repo update
Fixes 506.
This does the thing mentioned in 506 (renaming temp table, rather than copying data). In the process, I also identified that the temp tables were missing key indexes which slowed the process down. This fix took the update time from ~100 seconds to ~60 seconds on my Nexus 4.
Below are a couple of log cats from before and after the change (this logging is not part of this MR, it was just for diagnosing the problem).
*Before change:*
```
AppProvider D Calculating whether apps are compatible, based on whether any of their apks are compatible
D Update compatible flags took 20244ms
D Calculating suggested versions for all apps which specify an upstream version code.
D Update suggested from upstream took 17808ms
D Calculating suggested versions for all apps which don't specify an upstream version code.
D Update suggested from latest took 129ms
AppProvider D Update icon URLs took 7879ms
UpdateService I Updating repo(s) complete, took 104 seconds to complete.
```
*After change:*
```
AppProvider D Calculating whether apps are compatible, based on whether any of their apks are compatible
D Update compatible flags took 1047ms
D Calculating suggested versions for all apps which specify an upstream version code.
D Update suggested from upstream took 601ms
D Calculating suggested versions for all apps which don't specify an upstream version code.
D Update suggested from latest took 136ms
D Update icon URLs took 887ms
UpdateService I Updating repo(s) complete, took 63 seconds to complete.
```
See merge request !179
The idnexes which are added are for those columns which
are used to calculate information such as latest upstream version.
These queries use subqueries which seemed to be adversely
impacted by the lack of indexes.
In total, reduced update time on test device from just over 100 seconds
to just over 60 seconds.
