Fix/update notification
In addition to making update notifications work again (fixing issue #20) I also removed an unused class, and made the update count easily accessible from the AppProvider.Helper class.
If a repo was configured with a fingerprint, but it has not yet updated and
gotten the pubkey from the index.jar, then it will be in an "unverified"
state, i.e. the signing key fingerprint is stored, but it has not yet been
used to check against the pubkey in the index.jar
The logic here is crufty, so I slapped a flag in there to make sure that
the pubkey gets stored when someone configures a repo and includes the
fingerprint. When the fingerprint is set, it will first download the
index.jar and verify it against that fingerprint. The logic for storing
the pubkey permanently happens later in the XML parsing, so there needs to
be a flag to signal to store the pubkey in this case.
Before the flow was always index.xml -> get pubkey -> index.jar. Really,
there should no longer be support for unsigned repos, then all of this
stuff can be dramatically simplified.
fixes#2924https://dev.guardianproject.info/issues/2924
refs #2960https://dev.guardianproject.info/issues/2960
This was causing the first byte of the signature to be chopped off, so
therefore it would not validate since the fingerprint of the cert from
the net connection had the right fingerprint, but it was compared to the
stored, truncated version.
This also means that the database version needs to be bumped to trigger an
upgrade so that the bad 62 char fingerprints are removed from the database.
Since before, incoming repo Intents where handled in the Fragment's
onCreate(), an Intent that was received while the Fragment was visible was
just ignored. Activities have onNewIntent() for that, but Fragments don't
so the repo Intent handling had to be moved to the ManageRepo Activity.
That makes for a more direct relationship anyway, since ManageRepo is what
is configured as receiving all those Intents in AndroidManifest.xml.
There were some weird edge cases that couldn't quite be pinned down,
whereby installing an app would result in a unique key violation being
hit. One example was when somebody was installing an apk from a file
manager. It seems that this doesn't trigger a PACKAGE_CHANGED, but
rather a PACKAGE_INSTALLED. The end result is that it attempts to insert
a record that already exists in the installed apps table. Because we
have a unique key constraing on the appId, it breaks.
This commit changes the way that we insert installed app details.
Instead of inserting some times, and updating other times, we always
insert. If we hit a unique key violation, the row is deleted, and then
the new values are reinserted.
This takes the code used for sending the FDroid.apk and applies it to any
installed app. So the user can go to the AppDetails for any installed app
and select "Send via Bluetooth" from the menu, and send the app to another
phone.
If you are viewing the AppDetails screen for an installed app, this code
configures Android Beam to send the APK for that installed app if the you
initiate via NFC.
Also move the SDK checks into each method so that they are easier to use
without doing the wrong thing.
Previously the data was not stored anywhere, and each time we wanted
to know about all installed apps, we built a ridiculously long SQL
query. The query had essentially one "OR" clause for each installed
app. To make matters worse, it also required one parameter for each
of these, so we could bind the installed app name to a "?" in the query.
SQL has a limit of (usually) 999 parameters which can be provided to
a query, which meant it would fall over if the user had more than
1000 apps installed.
This change introduces a new table called "fdroid_installedApps".
It is initialized on first run, by iterating over the installed apps
as given by the PackageManager. It is subsequenty kept up to date
by a set of BroadcastReceivers, which listen for apps being
uninstalled/installed/upgraded.
It also includes tests to verify that queries of installed apps,
when there are more than 1000 apps installed, don't break.
Finally, tests are also now able to to insert into providers other
than the one under test. This is due to the fact that the providers
often join onto tables managed by other providers.
This allows you to specify the Uri of a single apk, and
it will return it. Right now it is just used in a test, but
hopefully it will be useful in other situations too.
I forgot to commit this last time, and didn't review my patch
well enough before submitting.
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.
