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.
Android.mk is needed to build F-Droid as part of other ROMs. A ROM would
have to emulate the .gitmodules with repo.
Note: the build will fail until AndroidPinning pulls a trivial fix for
super(null). There is also a layout bug that is fixed by the next
commit.
Inconsistent formatting types for argument #1 in format string
searchres_napps ('%s'): Found both 'd' and 's' (in values/strings.xml)
This lint check ensures the following: (1) If there are multiple
translations of the format string, then all translations use the same type
for the same numbered arguments (2) The usage of the format string in Java
consistent with the format string, meaning that the parameter types passed
to String.format matches those in the format string.
<string name="searchres_napps">Sa gasit o aplicatie potrivita cu %s\'</string>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
