This is another easy method to send FDroid to a device that doesn't have it
yet. Unfortunately, stock Android blocks the receiving of APKs, but many
ROMs and even some Samsung devices do not have this block.
You can find the lengthy backstory on this work here:
https://dev.guardianproject.info/issues/2084
Setting android.permission.ACCESS_WIFI_STATE automatically sets up
uses-feature to require wifi. Therefore, we have to manually say that
wifi is not actually required.
This adds the command to update the embedded Android Test Project, so that
it can be run using `cd test/; ant clean emma debug install test`
It also changes -p to --path just to make things a little easier to read.
This pre-configures a file:// URI that points to the installed location of
the FDroid.apk. When users put two devices together, and touch the screen
on the device with FDroid on it, it will "beam" over the APK, and prompt
the user to install it.
To reproduce the crash:
0. click a fdroidrepo:// URI to bring up the "app repo" dialog
1. rotate the device
2. click back to make the keyboard go away
3. click back to make the dialog go away
4. click back on Manage Repos screen
5. boom!
Otherwise we get errors like this upon rotation:
"android.support.v4.app.Fragment$InstantiationException: Unable to
instantiate fragment org.fdroid.fdroid.RepoListFragment: make sure class
name exists, is public, and has an empty constructor that is public"
It is now possible to beam a repo config via NFC but just selecting the
repo in FDroid, then touching two NFC devices together, and clicking on the
FDroid one. There is no indication that NFC is off, so this commit adds a
menu item that makes it easy to enable the required NFC settings for
sending a repo to another device via NFC.
This is the framework for easily swapping repos. The idea is that a user
can send the URL with the fingerprint for trusted bootstrapping of the repo
on a new user's device. This will be essential for p2p repos provided
by Bazaar/Kerplapp.
The required NFC APIs were introduced in android-14. So android-14 and below
skip the NFC stuff.
this makes sure that the repo fingerprints are always going to have the
same case, no matter how they were added. Repo.fingerprint probably should
be converted to a BigInteger so that the comparison can be numeric rather
than String. Then when the fingerprint needs to be displayed, it can be
formatted appropriately.
This saves the currently selected category in the Available apps view, and
restores that category when the user returns to the Available screen. It
drives me totally nuts that it always forgets the category when I nav away
from that screen, always returning to What's New.
* If the info is taller than the icon, grow larger to fit it in
* Center icon vertically
* Move padding out of the header
* Revert some font sizes to how they were some time ago, a bit smaller
Yay!
As expected, a lot of the stuff in DB class is due to UpdateService
requiring it to process the downloaded indexes and insert data into
the database. Thus, this change is about removing that stuff from
the DB class and migrating to ContentProviders.
This required a bit of a change to the way that UpdateService decides
what to do with the data from indexes, but I hope it will make
understanding and changing UpdateService easier in the long term.
For example, it used to read the app details from database, then
if a repo wasn't updated (due to unchanged index) then it would take
the app details for that repo from the list of apps, and re-update
the database (or something like that).
Now, it has been refactored into the following methods:
* updateOrInsertApps(appsToUpdate);
* updateOrInsertApks(apksToUpdate);
* removeApksFromRepos(disabledRepos);
* removeApksNoLongerInRepo(appsToUpdate, updatedRepos);
* removeAppsWithoutApks();
* and probably some others...
Which hopefully are self-explanitory.
The recent change to implement single repo updates was re-implemented
with in light of the methods above. The interface to UpdateService for
scheduling a single repo update is the same as it was before, but
the implementation is completely different. Still works though.
Using batch content provider operations for repo updates,
but they suffer from the problem of not all being under the same
transaction, so if an insert/update stuffs up half way through, we
are left with only half of the update being complete. In the future,
if there is some way to implement notifications from the content provider's
applyBatch method, then we can do it all in the one transaction, and
still have notifications. Currently we break it into several calls
to applyBatch (and hence several transactions) to inform the user
of the progress.
Also adding the beginnings of some tests for AppProvider. In the future, I'll
work on adding better coverage, including instrumentation to test UI features.
==========================
Below is a list of many of the minor changes that also happened along the way
==========================
Make "Can update" tab stay up to date using content observer, rather
than manually deciding when to refresh the tab label as before.
The installed app list is now cached in Utils, because it is invoked
quite a few times, especially when rendering the app lists. The cache is
invalidated when PackageReceiver is notified of new apps.
The content providers don't notify changes if we are in batch mode.
I've left the notification at the end of the batch updates as the
responsibility of the UpdateService. However, it would be nice if this
was somehow handled by the content, as they are really the ones who
should worry about it.
Made curVersion, curVercode and curApk work with providers.
This was done by removing curApk (otherwise we'd need to query the db each
time we fetched one app to get a reference to that apk (resulting in hundreds
of queries). Instead, UpdateService now calculates curVercode and curVersion
and saves them to the database. We then use these where possible. If we really
need curApk (because we want info other than its version and code) we still have
the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered
putting this inside the app value object, e.g. in getCurApk() but thought
better of it as it will likely result in people invoking it all the time,
without realising it causes a DB query.
incompatibleReasons required a minor UI tweak, removing the "min sdk"
ui element from the Apk list. It is replaced by the "Requires: %s" view
(which only appears when the app is incompatible). In the process, and in
response to some feedback from mvdan, I left the min sdk in there, but
only made it show when in "expert mode", just like the architecture.
In order to make the "installed apps" query work under test conditions,
needed to change the way the InstalledApkCache be replaceable with a
mock object.
Pause UIL loading on fast scroll of list, as the list was very choppy for
some reason.
Re-added "Last repo scan" info to the Manage Repo list view.
Fixed up some misc TODO's, removed some unused/empty functions.
