Removed unused code from ApkProvider.Helper, made it throw proper
exceptions when trying unsupported operations. Refactored tests
a little bit to facilitate separate test cases for the provider
and its helper.
The bug is explained in detail in the issue tracker.
This change added guard condition to check for existence of the field
before adding.
While I was at it, I also guarded a bunch of other ALTER statements
with the if (!columnExists()) check. It turns out that many of them
break, but we only saw the first one because it threw an exception
before getting to the others.
This marks a method as overriding another method, and makes sure that it
matches the signature of the method it is supposed to be overriding,
otherwise it gives a warning.
Its a bit verbose, but can catch mistakes and save time. And the default
Android profile for Eclipse always adds them automatically...
Here's the crash dump:
java.lang.NullPointerException
at org.fdroid.fdroid.data.ValueObject.checkCursorPosition(ValueObject.java:13)
at org.fdroid.fdroid.data.Repo.<init>(Repo.java:37)
at org.fdroid.fdroid.views.fragments.RepoListFragment.onListItemClick(RepoListFragment.java:269)
at android.support.v4.app.ListFragment$2.onItemClick(ListFragment.java:58)
at android.widget.AdapterView.performItemClick(AdapterView.java:299)
at android.widget.AbsListView.performItemClick(AbsListView.java:1113)
at android.widget.AbsListView$PerformClick.run(AbsListView.java:2904)
at android.widget.AbsListView$3.run(AbsListView.java:3638)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5017)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
at dalvik.system.NativeStart.main(Native Method)
Categories can technically be null, so need to guard for that
when getting them from the ContentProvider. This occurred because
I had an old index from before the change from "category" to
"categories", so it indeed was null.
The other one was from when I added a new repo without a fingerprint.
The fingerprint gets changed to upper case, but if null, causes
a NPE.
If the device supports API level 16 (Android 4.1) then add a menu item
on the repository management screen to "Find Local Repos". Activating
this menu item will initiate NSD service discovery with the NsdHelper
class looking for 'fdroidrepo' and 'fdroidrepos' service types on the
local network. When one is found, the service is resolved and the name
& IP are populated into a list of discovered repositories. Clicking an
NSD discovered repo will prompt the user to add the repo.
For now it's enforced like minSdkVersion. It is possible to try and install
incompatible apks by enabling "Incompatible Versions" and agreeing to the
warning shown when clicking on such a version.
For now, the UpdateService ignores these fields when updating from
the index. There is no time that the index should specify what
versions to be ignored.
In the future, this will be done with a join table that stores
info about what to ignore. Another future improvement should also be
to make "App.toContentValues()" smarter. That is, make it only return
values which have been set since the object was created. However this
will add an overhead which may or may not be noticable.
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
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.
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.
Fixes issue #452. It turns out that recent versions of android do
this automatically, but my gingerbread emulator didn't.
In the process, I also refactored the getQuery method. It was previously
a void method that modified the state of the search view, which is a
bit counter-intuitive given it's name. Instead, I made it just a getter,
which calculates the query and returns it. That way, I was able to remove
mQuery from the fields in the search view. Generally, the less state we
need to worry about (e.g. fields in an object), the less assumptions we
need to make about whether that field has been set or not.
Solves issue # 453. Previously, it was reading one line at
a time of the index file. Turns out that the entire index is
only on about 5 lines, thus the 5th line is about 2mb. The
solution here is to switch to reading a fixed length of 4096
characters at a time rather than entire lines. This ends up
a bit more complex (because I wrote a custom tokenizer rather
than being able to use Java String methods such as indexOf).
There are still other memory issues on low memory devices,
to do with trying to parse ~1000 app value objects into memory,
each with numerous string objects associated with them. But
that particular issue will be solved in the future, with
the ContentProvider stuff.
A new repo can be added with only the fingerprint of the signing key, while
the regular tests are based on the entire public key (repo.pubkey). This
checks for the case when a repo only has the fingerprint and no pubkey yet.
In that case, it the pubkey presented by the index.jar file against the
stored fingerprint. If they match, then the whole pubkey in the index.jar
is stored.
The stored fingerprint is checked when a repo URI is received by FDroid to
prevent bad actors from overriding repo configs with other keys. So if the
fingerprint is not stored yet, calculate it and store it. If the fingerprint
is stored, then check it against the calculated fingerprint just to make sure
it is correct. If the fingerprint is empty, then store the calculated one.
This was in place before, but it needed to be updated for the new Repo
ContentProvider.
A repo URI can include info such as the current wifi SSID and BSSID that
the repo is hosted on. This is for when local repos are transmitted via
QRCode, NFC, etc. The receiver of this URI then checks to make sure it is
on the same wifi access point, and warns the user if not.
In the future, it should do more than just warn the user, but instead give
concrete actions for the user to take, like associating to that wifi.
Instead of ramming the fingerprint in the user field of the URI, use the
query string. Having the fingerprint in the user field was confusing some
browsers because it was trying to log in. The query string is the standard
place for such meta data, and has lots of room for expansion including
things like wifi network names. This will be useful later to determine if
both devices are currently on the same wifi network, and if they are local
repos, they should try syncing.
