onNewIntent() is called because ManageReposActivity is set to "singleTask"
launchMode, but it is only called if ManageReposActivity is already
running. onResume() is always called, and called after onNewIntent() if it
is called, so use onNewIntent() only to set the current Intent, then parse
the Intent only in onResume().
Here is how to reproduce the original bug:
1. Close F-Droid properly and start it again.
2. Click on https://guardianproject.info/fdroid/repo in a browser (and tell
it to open with F-Droid)
3. Hit cancel on the add repo dialog
4. Leave F-Droid open and switch back to the browser
5. Open that link again.
This should result in two dialogs on top of one another. Happened from both
Firefox, Chrome, and Android browsers.
When someone clicks on a URL that F-Droid can accept, i.e. a repo URL, then
Android puts up a chooser where the user can select which app to VIEW the
URL with. That was showing up with the title "Repositories", which is the
title used for that Activity when viewing it. This keeps the Activity
title the same while changing the title in the chooser.
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
HTTP Proxy preference for Tor, I2P, etc; add jenkins script
This adds a preference to set the HTTP Proxy so that FDroid can funnel all traffic through Tor, I2P, psiphon, or any other HTTP proxy.
Also, there is a script for jenkins to run before calling `ant clean debug` for the whole setup process. This script sets the `versionCode` to the UNIX time in seconds, and adds the date/time to the `versionName` so that the debug builds are very clearly marked from real builds, and they will automatically update when included in a debug repo:
https://dev.guardianproject.info/issues/2601
Jenkins will then call ant directly after running this script. This then sets
the debug builds made by Jenkins to have a versionCode of the UNIX time in
seconds and adds the data to the versionName. This clearly marks these as
debug builds and also makes it possible to have an fdroid repo of debug builds
that will automatically update after each build.
Taken from the gradle plugin user guide:
With Android KitKat (buildToolsVersion 19) you can use the diamond operator,
multi-catch, strings in switches, try with resources, etc.
Note that you can use minSdkVersion with a value earlier than 19, for all
language features except try with resources. If you want to use try with
resources, you will need to also use a minSdkVersion of 19.
You also need to make sure that Gradle is using version 1.7 or later of the
JDK. (And version 0.6.1 or later of the Android Gradle plugin.)
Appcompat on top of pserwylo
This is a refactor of @pserwylo's !19 to get appcompat building with `ant` and Eclipse. I reviewed @pserwylo's commits and they are ready to go as they are in this merge request.
Both preferencefragment and appcompat-v7 submodules need the
android-support-v4.jar to be included in their respective libs/ dirs in
order for ant to build those projects.
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.
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.
Thanks to the awesome work of mvdan, this was mostly ready to roll.
However, I had to wrestle for a while for two reasons:
1) I forgot to add the dependency in the build.gradle file (it was
already present in settings.gradle)
2) My IDE was unable to read the ANDROID_HOME env variable, and
despite my internet-search-fu, I couldn't figure out how to
make IntelliJ specify env variables for a gradle build. It took
a while to figure out, because it was failing silently in weird
ways.
After slaving away on a nice method to parse both the ANDROID_HOME
and the local.properties file (looking for sdk.dir), and then emmiting
nice error messages if neither were found or pointed to an invalid
location, I discovered it had already be done:
android.plugin.sdkDirectory ends up here:
https://android.googlesource.com/platform/tools/build/+/master/gradle/src/main/groovy/com/android/build/gradle/internal/Sdk.groovy#161
Which does exactly all that and more. So now sdkLoc is initialized to
the value of android.plugin.sdkDirectory.
Jmdns fixes and tor onion support
There are three groups of work in this collection of commits:
* improvements to the `WifiStateChangeService` and related activities like JmDNS to eliminate problems that happen when there are a lot of wifi change events.
* add rework the `.net.Downloader` stuff to add Tor support and lay the groundwork for Bluetooth support
* add support for repos on Tor Hidden Service .onion addresses
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.
