Instead of just sticking whatever URL is in the clipboard into the "Add
Repo" dialog, this attempts to sanitize the URL in case it has some garbage
or came from a QR Code, and therefore was all uppercase (that makes for
smaller QR Codes). It also checks if there is a fingerprint in the query
string of the URL, and sticks that into the fingerprint box.
fixes#50https://gitlab.com/fdroid/fdroidclient/issues/50
The swap stuff will also need to handle incoming Intents that represent
new repos, so the parsing logic is now its own class NewRepoConfig, which
is something like the Repo class, but using getters instead of properties.
Since the new repo data does not change once FDroid receives it, the only
way to set the values of a NewRepoConfig is via the constructor.
This is based on some incomplete work from @pserwylo:
71cb12ef5c (diff-6)
and
71cb12ef5c (diff-7)
AppListFragmentPageAdapter is a subclass of FragmentPagerAdapter, so it
should include the same spelling to make that clear and easy to trace,
grep for, etc.
Now that the Fragment is embedded in the Activity, and the menu has been
moved to the Activity in ActionBar style, most of the utility functions and
the Dialogs can be based out of the Activity, which is how they are
designed to work. This makes things work a lot easier.
fixes#3https://gitlab.com/fdroid/fdroidclient/issues/3
This allows the main menu to act like a proper ActionBar using appcompat.
It also allows for making the search happen live on the ListView, rather
than having to launch a separate Activity to show the results.
I went through all of the source code replacing anything that is now
possible using appcompat-v7. appcompat-v7 is the official way to handle
backwards compatibility, and it is supported by Google and others. Using it
as much as possible should make the code more maintainable and readable by
others since they'll be used to seeing the appcompat-v7 patterns from other
projects.
fixes#51https://gitlab.com/fdroid/fdroidclient/issues/51fixes#42https://gitlab.com/fdroid/fdroidclient/issues/42
Previously, it was using the native android.widget.SearchView.
Now it uses the widget from appcompat. For good measure, I also
made it so that the search button is always in the action bar,
rather than being hidden behind a menu sometimes.
Do so by:
- Making RepoDetailsFragment/RepoListFragment retain their instances
- Move the management of the update repo dialog to UpdateReceiver
- Let the fragments tell the UpdateReceiver when to show/hide
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?
The only remaining activity is the AppDetails acvitity, which will require
a little more than just making it extend ActionBarActivity. Currently,
it extends ListActivity. To support appcompat-v7, it really should have
two fragments - the details one and the list one. Then, when the orientation
is changed, it should load a different layout with the fragments side by side.
Although Google is encouraging people to make old devices run apps
with the action bar (via appcompat-v7), they haven't provided a way
for people to create preference/setting screens with an action bar.
There are plenty of issues in the Android issue tracker relating
to this, but it doesn't yet seem to be on the radar of the Android
devs.
Until there is a native implementation of PreferenceFragment in
the appcompat-v7 support library, this submodule provides is a 3rd
party solution. It is actually a fork of the first repo in github,
though that was a bit of an upload and dump, without accepting MR's.
This fork includes gradle support.
Tor Hidden Services are on domain names that always end in .onion, so there
is a URL pattern matcher that chooses which Downloader subclass to use
based on testing for .onion. This is a quick, dumb implementation. It
does make any attempt to see if Tor is running or even installed. That
can come once NetCipher is easy to handle in the context of FDroid.
refs #2367https://dev.guardianproject.info/issues/2367
This will ultimately be used to create the right Downloader subclass
instance based on the URL of the file to download (i.e. rfcomm://, .onion
address, ssh://, new socket protocols, etc).
Also delete unused constructors, they can trivially be readded if they are
ever used, and they are currently just clutter.
If a new "wifi connected" event comes in while a previous one is still
being processed, then cancel the current one as soon as possible. This
prevents the events from being processed in an interleaved manner, causing
chaos and crashes. Hopefully this will fix the jmdns crashes, since that
is triggered by onPostExecute() via FDroidApp.restartLocalRepoService().
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)
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
