Safer and less error-prone because:
* Always checks for null
* Checks for sizes
* Inits App/Apk lists at known capacity
* Properly closes all cursors
There are still one or two cursors that are not closed correctly and show
things like these:
W/CursorWrapperInner(19973): Cursor finalized without prior close()
The Activity.getActionBar() method can only be called after
setContentView() has been invoked, as described here:
http://blog.perpetumdesign.com/2011/08/strange-case-of-dr-action-and-mr-bar.html
I couldn't think of any way to enforce this safely
(i.e. make the compiler kick up a stink if we didn't do it). As such,
I just put a comment above each usage of the ActionBarCompat class.
Another outstanding issue is a duplicate of 474, where it crashes when you
press the "Up" button from ManageRepos, but I'll create a different issue
for that.
The cryptographically secure random number generator exposed to Android
through the Java Cryptography Architecture is not properly initialized
on some older unpatched versions of Android. Google provides
a PRNGFixes.java class to force secure seeding of the CSRNG on all
platform versions. This comment adds the PRNGFixes class & and a call to
invoke the fixes from the FDroidApp class.
More detail is available from the Google Android Developers blogpost on
the subject:
http://android-developers.blogspot.ca/2013/08/some-securerandom-thoughts.html
When adding "default_repo_priority", it was copy/pasted from
"default_repo_pubkey" without changing the name, and so
tried to cast the string value into an int and failed.
Related to the last bug with the update notify count. This one is
also due to the fact we didn't ask for the right data from the
provider. If these bugs keep coming in over time, I will seriously
consider guarding access to each variable with a check, and throwing
an exception if the variable hasn't been initialized. For now I'll
see if it was a once off. Hopefullly tests will catch these issues
in the future.
This property will be ignored if f-droid is not installed as priv-app,
but it _will_ skip the "you have to enable unknown sources" dialog if
f-droid is installed as priv-app.
There is thus no gain in keeping it as is (false).
This patch iterates over the configured list of repos and adds them to
the db on create. This means that the initial list of repositories is
now fully configurable. Added the guardian project repo (disabled) as a
testcase.
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.
