This automatically creates a repo with only FDroid in it the first time the
user goes to the Local Repo view. Having an empty repo is useless if the
user is trying to swap with someone. Having FDroid in there is not a
privacy leak since FDroid is needed for the swap process, and it will then
enable people to automatically get updates from each other, and do the
bootstrap process from the web browser.
fixes#2954https://dev.guardianproject.info/issues/2954
When FDroid has been started, this checks the symlinked APKs in the local
repo and uses those package names to build up the list of selected local
apps. This gives the SelectLocalApps experience continuity across app
restarts.
refs #3204https://dev.guardianproject.info/issues/3204
This gets the data about which apps are installed from the ContentProvider
that pserwylo recently added for data about "Installed Apps" and presents
a list view for the user to select from by touching each line. Then if the
user chooses "Update Repo", it will regenerate the local repo based on the
current selection. It will always include FDroid in the local repo.
fixes#3232https://dev.guardianproject.info/issues/3232
refs #3204https://dev.guardianproject.info/issues/3204
In order to use the data from InstalledAppProvider in a lot of the high
level classes provided by Android, like CursorLoader, SimpleCursorLoader,
etc, there must be an _ID row.
This is a little helper to direct people to get a new device to download
FDroid from another device that already has it. It first prompts them to
join the same wifi network, and offers a QR Code to associate to the same
wifi. The next step is a QR Code for getting the URL to the local repo.
The index.html on that local repo includes a download link for FDroid and
a repo link to the local repo.
refs #3204https://dev.guardianproject.info/issues/3204
Wire up the "Setup Repo" button on the Local Repo view to generate an
FDroid repo on the device that is hosted with the local webserver. This
also generates an index.html for when people navigate to the local repo via
a browser. This index.html will allow them to both download FDroid and to
setup the repo on the device running the webserver on the local FDroid.
refs #3204https://dev.guardianproject.info/issues/3204
refs #2668https://dev.guardianproject.info/issues/2668
This is a skeleton for the upcoming local repo (aka swap aka Kerplapp).
Right now, it just provides an Activity for controlling a Service which
manages a local webserver (nanohttpd). Next, it will be wired up to the
local repo created via a dedicated Activity for managing the list of apps
included in the local repo.
refs #3204https://dev.guardianproject.info/issues/3204
The local repo will need to both have current wifi settings in order to
send the correct IP address, SSID, etc. Also, this could be used to handle
interrupted downloads and updates, but that is not included in this commit.
refs #3204https://dev.guardianproject.info/issues/3204
This webserver is the core of the kerplapp swap local repo when used over
IP connections (WiFi). It is the smallest Java webserver we could find. It
is included as a git submodule, but then only the actual source files that
are needed are included. They are symlinked in src/.
The git repo used is the one that we submitted upstream as a pull request.
The pull request contains changes required to support https://. It has not
yet been accepted, so we cannot yet use the official repo. Once the pull
request is included, this should be switched to the latest release in the
official git repo.
https://github.com/eighthave/nanohttpdhttps://github.com/NanoHttpd/nanohttpd/pull/107
refs #3204https://dev.guardianproject.info/issues/3204
This app needs to be able to generate QR Codes regardless of what other
app might be installed, so zxing's core.jar needs to be embedded in this
app.
This also includes two classes which are modified versions of ZXing classes
that allow the generation of QR Codes without the Barcode Scanner app being
installed:
https://stackoverflow.com/questions/4782543/integration-zxing-library-directly-into-my-android-application
The classes are src/com/google/zxing/encode/Contents.java which is a copy
of zxing/android/src/com/google/zxing/client/android/Contents.java; and
src/com/google/zxing/encode/QRCodeEncoder.java which is a heavily stripped
and modified version of
zxing/android/src/com/google/zxing/client/android/encode/QRCodeEncoder.java
refs #3204https://dev.guardianproject.info/issues/3204
refs #2470https://dev.guardianproject.info/issues/2470
The receiver of this can at least make some sense of it, versus null or a
blank string. This prevents crashes where FDroid.repo.address is not yet
set since the wifi was never enabled or it does not have an IP address yet.
For some reason, on some emulators, it is failing to find a place to write
the test index files. But on most setups, it works fine. So instead try
writing the files to the cacheDir of FDroid itself rather than the test app
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
