When the repository is updated, it will check if the "name" or "description"
have been modified (or learnt for the first time) and if so, update the DB and UI.
Phew, monster merge. Going to commit after *seemingly* resolving
conflicts, but it will no doubt take a few compile and runs to sort out
any funny stuff.
Conflicts:
AndroidManifest.xml
res/layout/addrepo.xml
res/layout/appdetails.xml
res/layout/repolisticons.xml
res/values/strings.xml
src/org/fdroid/fdroid/DB.java
src/org/fdroid/fdroid/FDroid.java
src/org/fdroid/fdroid/ManageRepo.java
src/org/fdroid/fdroid/UpdateService.java
SwitchCompat will return a Switch or a ToggleButton depending on the
platform (doesn't matter, both are CompoundButtons) and this will be
added to the repo_item view programatically.
I'm using some pretty specific listeners
to communicate between the details fragment and the repo list activity.
I've also split the functionality (e.g. for deleting) between the repo
list and the details view. In the future, when we have content providers
for repos, it will be easier to take care of everything from the details
screen, and automatically notify the repo list of changes.
Refactored update service.
Now has a static update method that can be called which
will setup the required intent to begin the update. It also deals with
progress listeners and dialogs for the user, so all of this is moved out
of FDroid. This was so that RepoDetailsFragment can now invoke the same
functionality.
When a new repo is being added, whether manually or via an incoming Intent,
check the address and fingerprint against repos in the DB. If the repo is
not in the DB, offer to add it. If the repo address is in the DB, then do
more checks:
* If that address has no fingerprint in the DB, then offer to add the new
repo including that fingerprint. This might happen when upgrading a repo
from unsigned to signed.
* if the incoming info matches a repo in the DB, offer to enable that repo
* if the address matches a repo in the DB but the incoming fingerprint does
not match the fingerprint in the DB, warn the user, and tell them to
delete the existing repo if they truly want to override the existing info
the Eclipse Android mode loves to remove all trailing whitespaces quite
religiously. This commit just removes trailing whitespace. It was done
by running this:
sed -i 's/[[:space:]]*$//' *.java */*.java
With so many patterns being matched, it is highly likely that there will be
false positives, i.e. random URLs will trigger the prompt of whether to use
F-Droid or not. The updated set of patterns narrowly tailors the matches
so that it is highly unlikely to match URLs that are not fdroid repos, yet
still makes it useful both as a generic repo and a peer-to-peer
bootstrapping repo.
This set of patterns only matches URLs like this:
https://foo.org/fdroid/repohttps://foo.org/fdroid/repo/https://foo.org/fdroid/repo/////
It does not match URLs like this:
https://f-droid.org/repohttps://myblog.com/thoughts-about-my-lovely-fdroid-repohttps://news.com/tag/repohttps://somesite.com/repo/this-is-my-stuff
It matches multiple slashes to since those are in effect the same URL, and
they sometimes show up as typos. This does not include mvdan's proposal
for the 'fdroid-bootstrap' tag on the end because its not something that I
would use in this current project, so I don't know how best to apply it. I
have no objection to the 'fdroid-bootstrap' proposal.
The stored fingerprint is needed for comparing new, incoming repos that are
in the Add Repo dialog. This is to prevent malicious use of the automated
adding of repos via QR Codes, NFC, etc. The only other option that I could
think of for handling this situation is for the Add Repo dialog to open a
socket to the proposed repo to get its pubkey. That seems much less
desirable than just storing the fingerprints in the database.
When the fingerprint is generated to be stored in the database in the repo
table, make it a single String that is a hex number. This is a natural
format for working with the fingerprints programmatically. The display
formatting can then be handled by the display code, and can freely change
without affecting the underlying function of the code.
* a number of sources have said to avoid SHA-1 in new implementations
* nothing currently depends on the SHA-1 fingerprint in the code, it is
only used to display on the repo list.
* Java 7 requires SHA-256 to be included
* keytool -list -v shows the SHA-256 fingerprint
Everytime I save a java file with Android ADT, it adds @Override decorators
and throws errors if a method is called that is not supported in API 4. My
setup might be more sensitive since its setup with the official Android
style plugin for Eclipse. But the decorators are "correct" Java style, so
it would be nice to have them in F-Droid.
Previously, anything added via the Add New Repository dialog would just
overwrite any existing repo config that was there. This has become a
bigger issue with the QR Code scanning since it could become an attack
vector. This is the first step towards making this Add Repo dialog give
more info to the user about the state of things, and what the user might
replace by clicking OK.
