It seems that sometimes checking dialog.isShowing() is not enough. I got a
crash on dialog.dismiss(). But since the dialog is already gone in that
case, just catch the Exception and move on. Here's the stacktrace:
31760 FDroid D Update took 45 seconds.
31760 FDroid D Invalidating preference 'lastUpdateCheck'.
31760 AndroidRuntime D Shutting down VM
31760 AndroidRuntime E FATAL EXCEPTION: main
31760 AndroidRuntime E java.lang.IllegalArgumentException: View not attached to window manager
31760 AndroidRuntime E at android.view.WindowManagerImpl.findViewLocked(WindowManagerImpl.java:378)
31760 AndroidRuntime E at android.view.WindowManagerImpl.removeView(WindowManagerImpl.java:223)
31760 AndroidRuntime E at android.view.Window$LocalWindowManager.removeView(Window.java:432)
31760 AndroidRuntime E at android.app.Dialog.dismissDialog(Dialog.java:278)
31760 AndroidRuntime E at android.app.Dialog.access$000(Dialog.java:71)
31760 AndroidRuntime E at android.app.Dialog$1.run(Dialog.java:111)
31760 AndroidRuntime E at android.app.Dialog.dismiss(Dialog.java:268)
31760 AndroidRuntime E at org.fdroid.fdroid.UpdateService$UpdateReceiver.onReceiveResult(UpdateService.java:124)
31760 AndroidRuntime E at android.os.ResultReceiver$MyRunnable.run(ResultReceiver.java:43)
31760 AndroidRuntime E at android.os.Handler.handleCallback(Handler.java:587)
31760 AndroidRuntime E at android.os.Handler.dispatchMessage(Handler.java:92)
31760 AndroidRuntime E at android.os.Looper.loop(Looper.java:130)
31760 AndroidRuntime E at android.app.ActivityThread.main(ActivityThread.java:3687)
31760 AndroidRuntime E at java.lang.reflect.Method.invokeNative(Native Method)
31760 AndroidRuntime E at java.lang.reflect.Method.invoke(Method.java:507)
31760 AndroidRuntime E at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:842)
31760 AndroidRuntime E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:600)
31760 AndroidRuntime E at dalvik.system.NativeStart.main(Native Method)
119 E Dumpstate > /data/log/dumpstate_app_error
119 ActivityManager W Force finishing activity org.fdroid.fdroid/.views.RepoDetailsActivity
more info:
https://stackoverflow.com/questions/19538282/view-not-attached-to-window-manager-dialog-dismiss
This helps with dealing with listFragment being null after a rotation. That
was happening when an Intent was coming in from a QR Code scanner, and
the screen was rotated during the process. This snippet was taken from
SearchResults.java
This is Peter Serwylo's idea, I just typed it up and tested it :)
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.
security updates for added repos
These commits fix a couple of security issues with adding repos, they should be included in the 0.65 release. Here is the bug report from Adam Pritchard, these issues should be fixed:
2.
But wait, you say? Where's the "EF" at the start? F-Droid actually shows
(and takes) a version of the fingerprint with the first byte (first two
hex) dropped. Bwah?
You can see this with Guardian's fingerprint here:
https://guardianproject.info/2012/03/15/our-new-f-droid-app-repository/
len('050C8155DCA377F23D5A15B77D3713400CDBD8B42FBFBE0E3F38096E68CECE') / 2 *
8 == 248
...But it should be 256.
On purpose?
3.
And it seems like there's a bug in F-Droid. If you enter the fingerprint
when adding the repo, the repo gets flagged with "Unsigned", but if you add
the repo without entering the fingerprint it doesn't.
Reproduction:
- Add https://guardianproject.info/repo/ and enter
050C8155DCA377F23D5A15B77D3713400CDBD8B42FBFBE0E3F38096E68CECE
- Refresh
- It's say "Unsigned" in red text under the repo name
- Delete the repo
- Add it again, but without the fingerprint
- It won't have any red text
This is surely unintended?
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.
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.
