Added comment about preventing addition of the same repo multiple
times.
More specific comment about pname et al, so that people don't think
they can use the regular search feature of F-Droid to search by
package name with a pname: prefix. Instead, it is only applicable to
incoming intents.
The categories were previously selected in the Spinner, then passed
directly to the database. Once the categories became translated, this
meant we were sending the translated category to the database.
However, the database only knows about English categories, and so we
instead need to look up the English translation for the selected
category before passing to the database. This is done by keeping
a list of original category names which is indexed the same as the
translated ones.
Shows an expandable notification on devices that support it (4.1+
I believe). The support library does most of the job of handling
incompatibilities between platforms.
NOTE: This commit does not touch the ant build system at all,
only gradle.
There are currently 23 gradle projects which require configuration,
let alone building, in order to build F-Droid. This takes a non-trivial
amount of time/memory/cpu. Additionally, it also provides difficulties
when importing the project into Android Studio - which is the IDE that
many potential contributors will be using. Finally, I have over 100mb
of data in the extern/ folder, and the support libraries require almost
every single Android SDK to be installed, which is several GB. This is
not a friendly environment to encourage people to submit merge requests.
However, I'm very mindful of the need for an open source project such
as F-Droid to be able to be built from source. So to make sure we have
the best of both worlds, I've ensured that building all dependencies
from source is still possible.
The F-Droid/libs/README.md file explains in greater detail how to
do this (i.e. "gradle -PsourceDeps build").
As much as possible, I've tried to make the binary dependencies fetched
from jcenter. However there are still libraries which either haven't
integrated required changes for F-Droid back upstream, or don't have
mavenCentral/jcenter binaries available.
Android preference fragment has been changed to the original
upstream repository. The one we had before was because upstream
hadn't merged a MR for gradfle support yet. However, that has
now been merged. This version still doesn't exist in jcenter though.
In order for libsuperuser to build from upstream, using
`gradle -PsourceDeps`, we need to include a few gradle plugins
from jcenter which are never actually used (used by upstream to
release to jcenter).
Even though support-v4 is included through jcenter, it is kept in
the libs directory, so that ./ant-prepare.sh can use it.
Update support preference fragment to newer version. There has been
bugfixes commited, so lets include them in the version we are using.
Rather, only show 25 progress events. I went with "25 events" rather
than "every X apps" because then it will be nice for both large repos
(e.g. F-Droid will update every ~50 apps) and small repos (something
with 20 apps will update for every one, but not add much overhead).
On my testing with an API 11 emulator here, it went from ~32s to
process ~1100 apps to ~20s. When no progress events are sent, then it
also takes ~20s, so this essentially is a 50% improvement for this part
of the update process.
This reverts to only using standard HTTPS verification based on Certificate
Authorities. This means that self-signed certificates will not work at all
since that is what MemorizingTrustManager was providing. It seems to me
that this was originally working because MemorizingTrustManager was not
correctly validating. I couldn't figure out why PinningTrustManager alone
was not working. But we need to get good stable release out!
I'm leaving all the plumbing in place because this stuff should be included
once its all fixed and working properly. You can see where it was added
here: 254327f9a7700c8196e61f53801f1f12ac825806
refs #80https://gitlab.com/fdroid/fdroidclient/issues/80
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
