Some QR Code scanners don't respect custom schemes like fdroidrepo://, so
this is a workaround, since the local repo URI is all uppercase in the QR
Code for sending the local repo to another device. This way, the QR Code
can still be all uppercase and use HTTP:// and Android will still route it
to FDroid, but via the Just Once/Always chooser (fdroidrepo:// goes
directly to FDroid with no prompt, when it works)
* Don't hard-code ellipsis in the code
* Separate the two rows into two linear layouts
* Don't abuse relative layouts
* Use ellipsize with weights to achieve best results
Previously, I accidentally made the repo updater presume that it
had access to all apps in a big fat list. This meant that I was iterating
over that list, performing calculations, etc, rather than actually
querying the entire database.
The solution was to bundled all update-service related processing to one
process in AppProvider (I didn't want to have to pull every single app/apk
out of the database in order to perform the update, because that will become
more and more burdensom as the repo grows).
There is a method calcDetailsFromIndex() in the AppProvider.Helper class.
It now does three things:
* updates compatibility flag.
* updates suggested version (outstanding issue is documented in gitlab issue #1)
* updates iconsUrl (fixed in this commit)
Icons from old repos will just have icons in an "icons" dir
in the same folder as the index.jar. New repos have density
specific icon dirs (e.g. "icons-240") which depend on the
device F-Droid is running on.
The archive repo was getting updated after the regular repo.
In these situations, we didn't have every single app/apk in
memory in order to calculate the suggested version. As a
result, F-Droid ended up choosing a suggested version from
the archived versions, when terhere was actually a newer version
in the database.
This change does all of the calculations in two database queries
now. Although the implementation of the query is not hackey,
they way I get to the code in order to execute the query
is a bit hacky, so most of the implementation is private.
It adds an extra 600ms on my Nexus 4 with ~2000 apks from the
F-Droid index. But I think it is the only way, as we really need
to iterate over every single installed apk, to see if it is still
wanted. The up side is that we can query for a large amount of
them, rather than quering individually for each apk.
NOTE: I haven't added a new status message yet, because we are
about to do a stable release. After the stable release, I'll
add a new status message to cover for this > half a second
(on my relatively fast device). This will probably be part of
an overhaul of the update process in general, including a
proper progress dialog.
This can later be removed again if the user still has a way to easily update
repos manually without having to enter "Manage Repos" and exit again. A good
option would be a pull-to-refresh action.
The problem was that they defaulted to 0 if not specified, however
the code checking for current version was looking for -1 for a "no upstream version".
The idea was good: reduce the amount of copied/pasted code
where ContentValues were initialized, populated, then inserted.
I've kept the idea, by putting it in its own method which is
called twice. But the resources are not loaded dynamically any
more. This is so that the compiler will be able to pick up if
we reference a missing resource. Also, I took the opportunity
to replace the field name string literals with references to
RepoProvider.DataColumns.* constants.
Finally, changed the tests around because now we need to
have the "getInteger()" call mocked in resources correctly
(for priority/inUse).
From before content providers, where we rolled our own update notification
system for when data changed in the database. I also removed the property
"ctx", because it is availble in getApplicationContext(). As a general rule,
it is usually safer to not use a member field if not neccesary. That way,
there doesn't need to be any assumptions about when it is set and what value
it has. In this case, it was only set half way through onCreate, and therefore
usage before then would break.
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.
