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.
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.
improved, but still rudimentary, hotspot handling in swap
My previous merge request fdroid/fdroidclient!78 was based on one broken assumption: `WIFI_STATE_UNKNOWN` means that the hotspot is active. Apparently, that's not always the case. Also, sometimes when the hotspot is active, its `WIFI_STATE_DISABLED`. Even worse, there is no broadcast message sent on final config of the hotspot. There is only a `WIFI_STATE_DISABLING` from turning off the wifi, but then never a broadcast for `WIFI_STATE_UNKNOWN` and/or `WIFI_STATE_DISABLED`. But I found some tricks that seem to work for now. We'll need to use your library, @mvdan, to really get good support of hotspots.
This also includes some basic UI tweaks to represent the hotspot mode in the swap wifi screen.
See merge request !79
Removes trailing slashes from URLs, replaces multiple consecutive forward
slashes in the path with a single slash. Canonicalizes the URL.
If the URL is invalid, display a message to the user and don't let it get
added.
NOTE: This does *not* normalize existing URLs in the database.
Previously it would only compare the details of a new repo to existing
ones if the new repo came via an intent. Now it does it whenever you
change the text in the new repo dialog (shouldn't be too much of a
performance hit, it isn't doing very much).
The things it (still) doesn't do is:
* verify that the url looks like a url
* sanitize the newly input uri and compare it to sanitized saved repos
The second point means that you can end up with:
http://10.0.1.50/ and
http://10.0.1.50
both in the list. I'm going to log an issue for this, because it should
be fixed, but doesn't need to hold this up.
This is really just a placeholder, there is lots of work to be done here.
Really, this screen should have the SSID of the hotspot, but we need to use
a private API to get that. Coming soon...
The icon is free software from:
https://commons.wikimedia.org/wiki/File:Wifi.svg
hotspot mode is not well represented with the WifiState stuff. It can be
active when the WifiState is DISABLED or UNKNOWN. Also, when switching
from active wifi to hotspot mode, WIFI_STATE_DISABLING broadcasts will be
sent, but WIFI_STATE_DISABLED/WIFI_STATE_UNKNOWN will not.
When a device is setup as a WiFi Access Point aka "hotspot", the standard
API for getting the WiFi settings returns nothing. We have to use a
separate API to get the IP address of the WiFi AP. As far as I could tell,
there is no public API for getting the SSID/BSSID of the WiFi AP, so for
now that is left blank. That means the wifi screen in swap is confusing
because it will say it is not attached when the device is a hotspot
@mvdan's https://github.com/mvdan/libaccesspoint should help there
#193https://gitlab.com/fdroid/fdroidclient/issues/193
To handle hotspots, this code will become more complicated. Therefore,
first simplify things by putting all of the logic into one place, rather
than spread out across FDroidApp, the receiver, and the service
On launch, we need to get the current state of the Wifi. We only need to
start the WifiStateChangeService on WIFI_STATE_ENABLED, since any other
wifi state will be received by WifiStateChangeReceiver, which will launch
WifiStateChangeService when appropriate.
This reduces the chance that WifiStateChangeService will start when it is
not needed.
I was getting frequent crash-on-rotate NullPointerExceptions after scanning
QR Codes. This fixes it for me.
ConfirmReceiveSwapFragment is only ever used once in ConnectSwapActivity,
so it is a pointless abstraction. It makes the code a lot more complicated
and also creates very complicated situations to handle when the screen is
rotated. All of this gets much easier when everything is just included in
the Activity, since there is no problem being solved by the Fragments.
Fragments are for reusing chunks of UI in multiple places, or for showing
multiple chunks of UI in the same Activity. Both of those cases can also
be handled, arguably better, without using Fragments:
https://corner.squareup.com/2014/10/advocating-against-android-fragments.html
