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.
Doesn't work because:
* In this installer, we are not a system app
* Our intent action is of type ACTION_VIEW, not ACTION_INSTALL_PACKAGE
The equivalent of "we are not an unknown source" would be the other
installers, such as the Root and System ones.
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.
send any installed app via NFC/Beam or Bluetooth
Building upon the NFC+Bluetooth sending of the FDroid.apk, these two commits allow the user to send any installed app via Bluetooth or NFC/Android Beam.
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.
If a new repo comes in via Intent, like from clicking a link, scanning a QR
Code, etc., then stay in FDroid once the add dialog is complete.
Previously, it would sometimes stay in FDroid and sometimes go back to the
sending Activity, depending on the sending Activity. It was confusing and
annoying behavior.
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.
This was explicitly not-allowed previously, and so there was a
test that ensured it threw an exception when attempted on the
ApkProvider. However I implemented it for another feature, but
forgot to change the tests. Now the test no longer tests for
an exception. Rather, it properly tests for the correct execution
of the method.
run JUnit tests
It turns out that Jenkins was running the JUnit tests all along, but it just never reported on them. This adds a jar to the test project that makes JUnit reports that Jenkins can parse, and the report on the results. So now if the JUnit tests fail, people will be emailed just like build failures.
Also, I added a quick `ant javadoc` target to the main project in case anyone likes that kind of thing.
Jenkins needs some kind of report from the JUnit tests in order to tell
whether the tests succeeded or not. android-junit-report is a library to do
exactly that. With this setup, Jenkins should now successfully understand the
status of the JUnit tests, where before it just ran them and ignored the
results
