Otherwise, it gets confusing what is the action the user should do. Perhaps
the Action Mode "Done" button should always trigger the "Update Repo"
action, right now it means do nothing and return.
Since we have the packageName, we can just fetch the Drawables directly.
This uses some shortcuts to try to make things run faster. For example,
the ImageView does not have an ID, instead it is references by the index
number within the LinearLayout.
When you visit LocalRepoActivity, the swapping webserver is automatically
turned on, since it is required for any swapping to happen. When it was
automatically turned on, it will automatically turn itself off after 15
minutes to make sure that it doesn't stay running forever. If the user
manually turns it off, that cancels the automatic stop.
This forces the use of the Application's Context, so we can be sure the
webserver will run as long as FDroid is running. It also checks to make
sure whether the webserver is running before trying to start it.
This implements live filtering in a SearchView so that it is easy to search
for the apps you want to include in your Local Repo. This requires some
newer stuff, so I switched it to the android-11 Activity until appcompat-v7
is included. All this functionality will work fine with appcompat-v7.
This allows for searching installed app names for ones which match
a string. It searches based on the "label" as declared in the
manifest in the <application> tag as "android:label".
Most people are going to know the "label" i.e. the display name rather than
the packageName/id. So also store the label in the database and make it
accessible via InstalledAppsProvider so SelectLocalAppsFragment can show a
list of friendly names rather than packageNames.
The zxing library includes some Java 7 features, so it will only work on
Android SDK 8 (2.1) or above. FDroid supports SDK 7 (2.0), so on 7, do not
try to generate QR Codes.
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
