getApplicationContext() returns the Context of the application, which is
guaranteed to have the same life as the app itself. Other Contexts, like
an Activity, might go away during runtime.
As far as I can tell, the 'url' metadata in index.xml is not used at all by
the client. In order to keep it up-to-date in the local repo, it would
have to regenerate index.xml and index.jar each time the IP address
changed. That would mean a decent amount of work happening in the
background, all the update an unused field in index.xml.
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().
Since the HTTPS certificate includes the current IP address in it, it needs
to be regenerated each time that the IP address changes. It also can take
a long time to run, especially on the first time, since it had to do things
like create a key pair and make the certificate. Therefore it should be in
a Service/AsyncTask.
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
Before, it didn't seem to find anything unless I ran this on my laptop:
`avahi-browse -a -v`
So added two recommended practices from other jmdns code for Android:
* force full resolution on receiving serviceAdded()
* feed the WiFi's IP address to jmdns when creating an instance
fixes#3379https://dev.guardianproject.info/issues/3379
FDroid repos are advertised via Bonjour as plain HTTP or HTTPS services,
since they are browseable with a standard Web Browser. The "Find Local
Repos" browser in FDroid should only show FDroid repos, not any website,
so that is detected using a "type" TXT record in the FDroid broadcasts.
Multicast transmission is subject to heavy power management on Android,
because it apparently can be a battery drain. mDNS/Bonjour is based
entirely on multicast, so in order to have good Bonjour performance, there
needs to be good multicast performance. MulticastLock provides that.
fixes#3381https://dev.guardianproject.info/issues/3381
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
When the "Add Repo" dialog was showing and the screen was rotated, it would
first leak the AlertDialog because it was not dismissed, then it would
crash after rotation, because the AlertDialog was trying to be restored but
no longer existed. That's what I think was happening at least... the
solution surprised me a bit here...
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.
