Previously the data was not stored anywhere, and each time we wanted
to know about all installed apps, we built a ridiculously long SQL
query. The query had essentially one "OR" clause for each installed
app. To make matters worse, it also required one parameter for each
of these, so we could bind the installed app name to a "?" in the query.
SQL has a limit of (usually) 999 parameters which can be provided to
a query, which meant it would fall over if the user had more than
1000 apps installed.
This change introduces a new table called "fdroid_installedApps".
It is initialized on first run, by iterating over the installed apps
as given by the PackageManager. It is subsequenty kept up to date
by a set of BroadcastReceivers, which listen for apps being
uninstalled/installed/upgraded.
It also includes tests to verify that queries of installed apps,
when there are more than 1000 apps installed, don't break.
Finally, tests are also now able to to insert into providers other
than the one under test. This is due to the fact that the providers
often join onto tables managed by other providers.
This allows you to specify the Uri of a single apk, and
it will return it. Right now it is just used in a test, but
hopefully it will be useful in other situations too.
I forgot to commit this last time, and didn't review my patch
well enough before submitting.
This was explicitly not-allowed previously, and so there was a
test that ensured it threw an exception when attempted on the
ApkProvider. However I implemented it for another feature, but
forgot to change the tests. Now the test no longer tests for
an exception. Rather, it properly tests for the correct execution
of the method.
run JUnit tests
It turns out that Jenkins was running the JUnit tests all along, but it just never reported on them. This adds a jar to the test project that makes JUnit reports that Jenkins can parse, and the report on the results. So now if the JUnit tests fail, people will be emailed just like build failures.
Also, I added a quick `ant javadoc` target to the main project in case anyone likes that kind of thing.
Jenkins needs some kind of report from the JUnit tests in order to tell
whether the tests succeeded or not. android-junit-report is a library to do
exactly that. With this setup, Jenkins should now successfully understand the
status of the JUnit tests, where before it just ran them and ignored the
results
fix two bugs
First bug is with lots of QR Code readers, they don't respect custom URI schemes like `fdroidrepo://` and just force all URIs to be `http://`. A slight tweak makes it possible to use a QRCode to configure a repo using all of the major ones I could find (I tested with 8 different apps).
The second bug is a simple crasher bug.
Some QR Code scanners don't respect custom schemes like fdroidrepo://, so
this is a workaround, since the local repo URI is all uppercase in the QR
Code for sending the local repo to another device. This way, the QR Code
can still be all uppercase and use HTTP:// and Android will still route it
to FDroid, but via the Just Once/Always chooser (fdroidrepo:// goes
directly to FDroid with no prompt, when it works)
* Don't hard-code ellipsis in the code
* Separate the two rows into two linear layouts
* Don't abuse relative layouts
* Use ellipsize with weights to achieve best results
Fix Multi Repo Updating Only One Repo
Java update logic has been moved to SQL, to prevent having to pull out apps fromt he database, and then iterate over them in Java.
Previously, I accidentally made the repo updater presume that it
had access to all apps in a big fat list. This meant that I was iterating
over that list, performing calculations, etc, rather than actually
querying the entire database.
The solution was to bundled all update-service related processing to one
process in AppProvider (I didn't want to have to pull every single app/apk
out of the database in order to perform the update, because that will become
more and more burdensom as the repo grows).
There is a method calcDetailsFromIndex() in the AppProvider.Helper class.
It now does three things:
* updates compatibility flag.
* updates suggested version (outstanding issue is documented in gitlab issue #1)
* updates iconsUrl (fixed in this commit)
Icons from old repos will just have icons in an "icons" dir
in the same folder as the index.jar. New repos have density
specific icon dirs (e.g. "icons-240") which depend on the
device F-Droid is running on.
The archive repo was getting updated after the regular repo.
In these situations, we didn't have every single app/apk in
memory in order to calculate the suggested version. As a
result, F-Droid ended up choosing a suggested version from
the archived versions, when terhere was actually a newer version
in the database.
This change does all of the calculations in two database queries
now. Although the implementation of the query is not hackey,
they way I get to the code in order to execute the query
is a bit hacky, so most of the implementation is private.
It adds an extra 600ms on my Nexus 4 with ~2000 apks from the
F-Droid index. But I think it is the only way, as we really need
to iterate over every single installed apk, to see if it is still
wanted. The up side is that we can query for a large amount of
them, rather than quering individually for each apk.
NOTE: I haven't added a new status message yet, because we are
about to do a stable release. After the stable release, I'll
add a new status message to cover for this > half a second
(on my relatively fast device). This will probably be part of
an overhaul of the update process in general, including a
proper progress dialog.
