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.
The repo xml handler now has a different mechanism for returning
data about the parsed xml file. This is done via a callback, rather
than storing the data in member variables. The tests now deal with
this correctly.
The update/delete operations of the TempAp[pk]Provider's didn't
work, so that has now been fixed.
At the start of a repo update, it will create a copy of the apk table.
Throughout the update, it will query the original apk table for info.
All inserts and updates happen to the temp table. After the repo has been
verified as trusted, the original apk table is emptied, and all apks are
copied from the temp table to the real one.
I realise that the work done to query the apk table for info during the update
could happen against the temp table, but it was not neccesary to move all of
the queries that are required for this task to the temp apk provider.
Refactored repo update to stream apks from network -> jar file reader ->
xml parser -> database. No longer build up large lists of app metadata
to save. Saves memory, but is MUCH slower.
Does sig verification properly, but does it at the END of the process
and DOESN'T ROLL BACK on failure.
Quick and dirty benchmarks show an increase in time from ~25 seconds
to ~30 seconds on my Nexus 4 with Android 5.0. This doesn't seem so
bad to me, for the tradeoff that people on low end devices can actually
update now.
Also, as @eighthave pointed out, if we are able to stream the download
directly from the internet, then that time will drop to essentially
the time it takes to download the index.
Fix issue #202 - crash due to sqlite parameter limit being hit.
*NOTE: Queuing here for merge after next stable.*
The queries which have the potential to cause crashes due to too many parameters in the `ApkProvider` are now encapsulated in `ApkProvider` and can only be accessed by safe helper methods, which alleviate the problem by breaking big requests down into many smaller requests.
This will probably have to be done for the `ApkProvider`, but leaving for now because the limit is twice as big.
See merge request !70
Now the other content provider functions which can result in broken SQL
due to the number of arguments is private, and can only be accessed
from a public helper method which ensures that limit is never hit.
The static delete helper function in ApkProvider now supports
recursively reducing the size of the list of apks to delete, until
it is under the threshold that sqlite can handle.
