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
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.
Rather large rewrite, basically doing:
* Always show incompatible apps
* Don't fetch incompatible apks if the new setting is off
* Start using result codes when returning from PreferencesActivity
Also, move visibility stuff from onResume to onCreate (they are only affected
by preferences, i.e. onCreate will always be run since the preferences button
is only in our main activity).
* Add paddings.
* Don't use hard-coded pixel sizes.
* Don't use white color directly (this would soon break the white holo theme)
* Don't use an "empty" textview to force a vertical space.
Looks much cleaner now, and the code is easier on the eyes.
"All" kinda made sense in the context of internal workings
(fetch package list from several repos, then process compatibility of
all apps), but superfluous from user's perspective.
Changed strings.xml to reflect the multi-repo nature of updating.
Also refactored progress events to make them more generic and
easier to nest deeply down the call stack. The ProgressListener
now just expects a ProgressListener.Event, which in addition to
statically typed type and progress info, also has an associated
Bundle which can store arbitrary data.
