There is only ever a single service to advertise via mDNS, so when a new
registration is requested, remove any existing ones. This should eliminate
these stacktraces:
java.lang.IllegalStateException: A service information can only be registered with a single instamce of JmDNS.
at javax.jmdns.impl.JmDNSImpl.registerService(JmDNSImpl.java:1005)
at org.fdroid.fdroid.localrepo.LocalRepoService$5.run(LocalRepoService.java:239)
at java.lang.Thread.run(Thread.java:856)
WifiStateChangeService handles updating lots of IP-related things, then
things that depend on it listen to the broadcast from that Service. The
most straightforward way to update HTTPS or HTTP throughout the app is to
trigger this Service. It runs its stuff in an AsyncTask so it is all low
priority.
We only ever want a single LocalRepoService. Use the values returned by
the standard methods for start/stop and bind/unbind as the test for whether
the Service is indeed running.
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
ApkDownloaders keep track of a unique id. This id is passed through with
each event coming from the downloader. When progress events are received,
if they don't have the same id as the current downloader, they are ignored.
When returning to the app details screen after leaving, if a download
completed in the mean time, automatically show the install screen. Otherwise,
when you, e.g. return to your devices home screen during a download, the
download keeps occuring in the background, but we are unable to make use of
the resulting downloaded file.
The ApkDownloader now returns true or false depending on whether it
is using a cached version on disk, or hitting the network.
I was also a little more defensive about checking for if downloadHandler
is null before deciding to show a progress dialog.
Previously it was in the org.fdroid.fdroid package, along with
most other things. As such, it only need a package-local constructor.
However, now it has moved to the .net subpackage, and needs to be
made public.
Keep track of the downloader after an orientation change, and
make sure that there is always UI feedback beeing shown.
Removed resetRequired after merge conflict (the content observer
now deals with this for us in a much nicer way).
Conflicts:
src/org/fdroid/fdroid/AppDetails.java
One thing that still annoys me is that indeterminate progress dialog
still shows "0/100" due to the number formatter being used to display
the values in the TextView. Solution (from http://stackoverflow.com/a/6784180)
is to either make a custom dialog, or at the very least, in API 11 or higher
we can set the number formatter to display nothing.
Don't show the full download path of repo.
The full path includes the path to the index.jar, as well as ?clientVersion=*.
This is undesirable, the main purpose of even showing where we are downloading
from is to differentiate between multiple repos being updated at once.
This has a very different interface to the Downloader class, because
a handful of operations need to be run off the main thread (not just
download, but also totalDownloadSize and perhaps cache tag related
stuff). The AsyncDownloadWrapper provides its own listener, more
specific than just the progress listener, which invokes functions
at different points in time (e.g. download failed, completed, cancelled).
Refactored progress events to use string types instead of ints.
This way, it is less likely that two different events from
different processes will clash with each other.
Conflicts:
src/org/fdroid/fdroid/AppDetails.java
It still executes the download on another thread, and receives progress
events on that thread. However it now posts those events to the main UI
thread for them to get handled.
Also refactored Downloader/HttpDownloader a tad further. Some caching
stuff was pushed down from HttpDownloader -> Downloader (renamed from
eTag to just cacheTag). HttpDownloader.download() was recursively calling
itself, so I made the base class download() method abstract, and instead
the stream downloading is done in "protected void downloadFromStream()"
Other minor stuff:
* Prefixed some log TAGs with package names, to make them easier to grep.
* Removed a little bit of unused code (parameter to DownloadHandler).
This is the beginning of moving to a Downloader class and subclasses that
are used everywhere for downloading APKs, indexes, and icons.
I think that the ETag value can probably be used everywhere as the
unique ID for testing whether to download content, so I moved that to the
super class Downloader. But that's just a guess as of now...
This will allow the more general, non HTTP related stuff (progress events,
stream copying) to occur in a separate base class. HTTP specific stuff
(HTTP status codes, etag cache checking) is done in the HTTPDownloader
base class.
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...
