Listen for a new intent, show a screen to the user mentioning
they are about to start a swap. Make FDroid receive repo intents,
then dispatch to relevant Activity.
Previously manage repo always got the intents. Now FDroid does, and
chooses whether to give to ManageRepos or Client connect.
Not sure if it is required to do it this way or not, but it seems to
work.
I had a bit of an issue getting the "Welcome to F-Droid" string to
fit on one line, because it was breaking on the hyphen. That is still
not resolved in this commit.
Still need to:
* Show error messages instead of the "connect" description
* Jar signing seems not to work when connecting to other repo.
In order to handle returning to F-Droid after connecting (or saying no)
I tagged the intent with a "handled" extra value. That way, I can ignore
trying to connect to a repo if we've already handled that event.
Finally, I also fixed an issue regarding downloading of signed
index.jar files with an uppercase fingerprint.
The fingerprint from the jar differed from that in the swap url,
in that one was upper case and the other was lower case.
This uses an .equalsIgnoreCase check instead. It also adds an
extra guard in case the repo doesn't have a fingerprint. Although
it may not even use the signed repo updater if both the pubkey
and fingerprint are null, it is nice to have the extra assurance.
Fixes issue #19.
I also left some more TODO's around. I should put them in issues,
but I'm in a bit of a hurry.
Along with a bunch of networking stuff, a lot of UI to do with selecting
apps to swap was also moved. The background on the list is transparent,
which allows blue to shine through. Also, the text on the list items is
white, which will not work with a white background.
I've temporarily dropped support for searching this list too, until
I get some feedback from carrie et al.
NOTE: This stuff was written before hans fixed apcompat problems with
LocalRepoActivity, but then rebased over it later. As such, it doesn't
contain his fixes. Will need to do that before a stable release. i.e.
Still has a bit of a dependency on API 11 which needs to be resolved.
The Fragments and an Activity which tie all of the swap views together
has begun. The first bit of implementation is to get the current
wifi network displayed, which worked out alright.
This commit contains a lot of theme related stuff, particularly
involving taking assets from carries mockups and making them suitable
to use as drawables. The process for doing this is a story for another
day, but I'll document it and put it on the wiki in the future. carrie
showed me a script that a mate of hers used on another project, and
I've adapted it a little to make it work nicely here (note - it isn't
in this commit).
The button is blue, and always shown with associated text in the
ActionBar. This required a custom drawable which was set as the
background in the styles.xml.
When the user updates the repo and all packages are recent, the update dialog exited so fast, that some users might have thought that the repo didn't update. To notify them that no new updates were found, the user now gets a toast.
default_repo_count is not used at all, and the numbering scheme is just a
vestige of that. This switches all the variables to have clear names of
what they are representing.
This was a bit more complex than all the other views, because it supports
rotation, and different views for when it is rotated. The end result is
that the way in which the views were constructed needed to be completely
redone.
In the process, I also moved the layout of the app summary to a Relative
Layout. This adds more flexibility, and is also the suggested layout
for complex views (as apposed to nested linear layouts). I believe this
is due to the performance of relative vs linear layotus.
It was aprticularly hard to figure out what was going on
when rotating an Activity which had a list fragment
that had another fragment as a header. I don't think fragments
were designed to work like this, but I believe it is all working
as expected now.
Conflicts:
src/org/fdroid/fdroid/Preferences.java
NOTE: I don't know how android will go with adding a new property
to a string-array resource, but not having it translated everywhere.
Will it struggle because the EN version has three values for "theme",
but other translations only have two?
There is no longer a reason to expose writeIndexXML() since FDroid should
always generate a signed repo. So make writeIndexXML() be called as part
of writeIndexJar().
Allow the local repo to use HTTPS:// instead of HTTP://. This is currently
default off since handling the self-signed certificate is not currently
graceful. In the future, the SPKI that AndroidPinning uses should be
included in the repo meta data, then when someone marks a repo as trusted,
that local repo's SPKI should be added to the list of trusted keys in
AndroidPinning.
fixes#2960https://dev.guardianproject.info/issues/2960
This makes it so the local repo is always signed by a locally generated and
stored key. That key will become the unique ID that represents a given
local repo. It should seamlessly upgrade any existing unsigned local repo
next time that the user makes any changes to their local repo.
fixes#3380https://dev.guardianproject.info/issues/3380
The local repo generation code will take the description from the manifest
and include it in the repo meta data. So FDroid itself should also include
this description. Indeed every app should... perhaps this should also be
an `fdroid lint` item.
This name is used in the RepoList, the local repo website title, the
Bonjour broadcast, etc. By default, a name is generated using the make and
model of the phone plus a random number.
This adds support for registering the local repo with Bonjour/mDNS so that
it is broadcast out to all devices on the local network. This makes it
easy to discover and add local repos on the same wifi.
refs #2900https://dev.guardianproject.info/issues/2900
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
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
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
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.
