The multiple occurances of "if (Build.SDK_INT < ... )" statements
hint at the prospect that there are a couple of different implementations
of this class which behave differently. The new classes start with
InstallFDroidAsSystem, and then there are SDK specific subclasses
which provide the customization relevant for those subclasses.
The NFC message now is handled by the FDroid activity, so it is treated
the same way as every other incoming repo URL. Because FDroid handles
incoming intents correctly, the NFC one just magically works when
the <intent-filter> is moved from ManageReposAcivity to FDroid without
further code changes.
The other change is that the two way swap only happens when both are
actually swapping. Otherwise, we will send a request for someone to
swap with us, when we are incapable of swapping with them.
Fixes#267.
Pretends that the swap repo never existed, by deleting it before adding
the new repo, and showing the same message that is shown when a new
repo is added. This does not change behaviour for existing non-swap
repos. They are not deleted before being added again, or else we would
lose the ability to verify the fingerprint of an existing repo is the
same as a newly added one with the same URL.
Note that this has the effect that the fingerprint/pubkey of the swap
repo is nuked when adding that repo manually.
Internationalised the string "BAD FINGERPRINT" while I was at it.
Force entire swap process to be portrait.
Although this is usually regarded as poor form, it is currently better
than the alternative which is the whole swap process poohing itself
when a device is rotated. In the future, it may be worthwhile investing
in designing a proper UX for landscape swap too. However the process
of swapping can be quite complex if not presented well, and so it might
end up being too much work to maintain two different UXes for landscape
and portrait.
See merge request !89
Although this is usually regarded as poor form, it is currently better
than the alternative which is the whole swap process poohing itself
when a device is rotated. In the future, it may be worthwhile investing
in designing a proper UX for landscape swap too. However the process
of swapping can be quite complex if not presented well, and so it might
end up being too much work to maintain two different UXes for landscape
and portrait.
The code for promoting an untrusted repo with no fingerprint, to
a repo with a pubkey and a fingerprint, was still there. The problem
was that it was being executed after we verified the index.jar cert
against the pubkey stored against the repo (which is empty for TOFU
repos).
This change makes it so that if we are updating a repo without a
fingerprint, then it is a TOFU request, and we don't try to verify
the certificates.
closes#85https://gitlab.com/fdroid/fdroidclient/merge_requests/85closes#254https://gitlab.com/fdroid/fdroidclient/issues/254
fix paths in Android.mk
It turned out i only tested the build with an outdated source tree so the last commit (38c25f0ecce48ef9cfe5b0b41956ac9a4e2047fd) broke the Android.mk build. Sorry for that.
See merge request !86
Brought in an Apache 2.0 licensed file from apache commons to help
with this, which is one of many similar classes online that do the
same thing. At this stage, didn't feel like pulling in all of apache
commons as a dependency.
Devices now make themselves discoverable, and the client sends a test ping.
They UI is not styles properly though, and it doesn't handle the case where
somebody chooses to make their device not-discoverable (because the desired
peer is already paired and it is unneccesary). It also doesn't handle failure
anywhere.
I'm not 100% sure it is the right architecture yet, there wil no doubt be
things that crop up as I continue to implement it. However it seems to
be alright to work with so far.
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.
