Updated the README with details of how to run the tests. Also added a
minor fix to allow tests to run on pre-honeycomb devices. However their
behaviour may not be 100% defined - because the contentproviders are
not shuttind down correctly due to lack of an API to do so.
It broke with a recent support lib update that made the binary library be an
.aar instead of a .jar. Besides, the ant plugin has been buggy and unsupported
for a very long time.
Also dropping support for eclipse in the process, which lets us get rid of the
nasty symlinks.
Fixes#240.
To make this easier, I added a script to aid in downloading icons.
Checkout F-Droid/tools/download-material-icon.sh for more details.
The icons are licensed under the CCv4 attribution license, which I
added a shout out to under "License" in the README.md.
- App icon is now 72dp x 72dp
- Description is expandable
- License, categories, Website, Source Code, Issues and Donate (#232) are moved from header to summary
- Buttons to install, update and run are moved from action bar to header
- Permissions are expandable and always shown
- Add myself to copyright holders of "F-Droid/res/layout/app_details_header.xml", "F-Droid/res/layout/app_details_summary.xml" and
"F-Droid/src/org/fdroid/fdroid/AppDetails.java"
The README documentation was not updated after the move of the f-droid client
code to the F-Droid directory. The instruction where therefore wrong
The troubleshooting documentation about determining the used Android versions
in the project was also outdated. While the script was made functional the tip
to install the various sdk from the command line did does not work for me.
* The repo instructions are just a duplicate of the simple git submodules
* The Android.mk build instructions don't work and will never support what
e.g. gradle does
Anyone wanting to bundle F-Droid in a ROM can build it with git and gradle,
and then including the resulting apk.
In order to support F-droid repositories hosted with HTTPS using
a self-signed certificate the f-droid client should prompt the user to
trust or 'memorize' the certificate presented by a repository. The
MemorizingTrustManager[0] project enables easy integration of
a prompting activity and corresponding trust manager implementation.
This behaviour is useful to projects such as Kerplapp[1] that boostrap
an F-droid repository on a user's device where it isn't possible to
acquire a long lived CA vetted TLS certificate.
In addition to Trust-on-First-Use (TOFU) behaviour, this patch
integrates the PinningTrustManager [2] project by Moxie Marlinspike to
allow the FDroid client to ship a hardcoded set of Subject Public Key
Identifier pins [3] for the official FDroid repository TLS certificate,
and the Guardian Project TLS certificate. Additional pins can be added
to the FDroidPins.java class.
The upstream release of AndroidPinning by moxie0 uses a minsdk value of
8. The Fdroid client has a minsdk of 5, presenting compatibility issues
using the AndroidPinning lib as a submodule. Fortunately it seems there
is no technical reason preventing using a minSDK of 5 with
AndroidPinning. I have created a fork with this change and submitted
a pull req upstream. Until this pull is merged we can use my fork of
AndroidPinning as the submodule.
The new 'flow' for deciding if a repositories presented TLS certificate
should be trusted is as follows:
1) If the certificate was previously trusted by a TOFU action, then the
certificate is accepted as trusted
2) If the certificate wasn't previously trusted by a TOFU action but
there is a matching SPKI pin then the certificate is accepted as
trusted
3) If the certificate wasn't previously trusted by a TOFU action and
there is no SPKI pin but the certificate is signed by a trusted
Certificate Authority it is accepted as trusted (This is the
behaviour of the FDroid client prior to this patch with all other
conditions being a hard-fail).
4) If the certificate wasn't previously trusted by a TOFU action and
there is no SPKI pin and the certificate is not signed by a trusted
CA (i.e. self signed or otherwise) then the user is prompted to TOFU
the certificate. The user may choose to trust the certificate for the
current connection or forever. If the user chooses an option other
than "deny" the certificate is accepted as trusted for the specified
duration.
Users currently using a TLS protected repository will see *no
difference* in user experience after this patch is merged as the only
TLS protected repositories that would function prior to this patch were
providing certificates that match condition #3.
[0] https://github.com/ge0rg/MemorizingTrustManager/wiki/Integration
[1] https://github.com/guardianproject/kerplapp
[2] https://github.com/moxie0/AndroidPinning
[3] https://www.imperialviolet.org/2011/05/04/pinning.html
