If an application was installed via ADB, then it won't have an installer
package/name set. Therefore, looking up the label will cause a
NameNotFoundException, which should be ignored and not passed to the method
that called App() since it does not refer to the packageName that the
method is trying to look up, but instead the packageName of the missing
installer app.
This then serves to represent the APK that is installed for this app. It
needs to be filled out by the Providers then also. This then becomes a
place for data specific to the an installed App, like installedVersionCode
and installedVersionName, instead of having it both stored in an App
instance and a related Apk instance.
First try to get the description from APK, which is seems that no one sets
so it is usually null. Then get info about how it was installed, like
which app store, when it was installed and upgraded.
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.
