The update notification was not taking ignored apps into account.
This is the first manifestation of a class of bug I feared whereby
the properties of an App object are not initialized, but no error
is thrown. It occured because we were iterating over apps that were
created from the index file, rather than our database. Hence, they
had no knowledge about whether they should be ignored or not.
Also took the chance to perform a minor refactor of UpdateService
class. The onHandleIntent method was getting huge, so I extracted
two methods: verifyIsTimeForScheduledRun() and
performUpdateNotification(), as well as removing the unused "success"
flag.
The two methods should theoretically make the class more testable
later, as we can test the scheduled run code, and the update notification
code in separate tests, but we'll wait and see if that eventuates.
Not sure that the "parent" activity of ManageRepos is required in
the manifest any more, due to the fact that the main use seems
to be to direct the "NavUtils.navigateUpSameTask" method uses it,
but this change switches to "NavUtils.navigateUpTo" and specifies
the activity explicitly.
In order to support suggested version, I didn't want to have both
suggested version + versionCode in the App table. Rather, just the
code, and then use that (and the apps id) to join onto the apk table.
This is something we wanted to do elsewhere, so I refactored the
QueryBuilder class from the ApkProvider so that it can also be used
by the AppProvider.
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.
