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.
This patch makes F-Droid register with Android that it accepts the URI
schemes of fdroidrepo (HTTP) and fdroidrepos(HTTPS). When F-Droid receives
one of these URIs, it launches the ManageRepo Activity and then launches
the New Repository dialog.
refs #2454
This allows us to add new ones without making a mess in the client.
Prior to this change it would add empty lines, and also if the only
antifeature was an unrecognised one, would enable the antifeature view
box but with nothing in it. It should now ignore them completely.
finish() may be called from reset() which sets app to null. This issues
hits for example when clicking on wiki-link of an app which doesn't
currenty exist in client index, throws:
E/AndroidRuntime(17630): java.lang.RuntimeException: Unable to start activity ComponentInfo{org.fdroid.fdroid/org.fdroid.fdroid.AppDetails}: java.lang.NullPointerException
E/AndroidRuntime(17630): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1651)
E/AndroidRuntime(17630): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1667)
E/AndroidRuntime(17630): at android.app.ActivityThread.access$1500(ActivityThread.java:117)
E/AndroidRuntime(17630): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:935)
E/AndroidRuntime(17630): at android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime(17630): at android.os.Looper.loop(Looper.java:130)
E/AndroidRuntime(17630): at android.app.ActivityThread.main(ActivityThread.java:3691)
E/AndroidRuntime(17630): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(17630): at java.lang.reflect.Method.invoke(Method.java:507)
E/AndroidRuntime(17630): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:907)
E/AndroidRuntime(17630): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:665)
E/AndroidRuntime(17630): at dalvik.system.NativeStart.main(Native Method)
E/AndroidRuntime(17630): Caused by: java.lang.NullPointerException
E/AndroidRuntime(17630): at org.fdroid.fdroid.AppDetails.finish(AppDetails.java:1012)
E/AndroidRuntime(17630): at org.fdroid.fdroid.AppDetails.reset(AppDetails.java:353)
E/AndroidRuntime(17630): at org.fdroid.fdroid.AppDetails.onCreate(AppDetails.java:243)
E/AndroidRuntime(17630): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
E/AndroidRuntime(17630): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1615)
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
* Only change compact layout stuff when really needed
* No need to use StringBuilders in some cases
* No need to keep setting status and license to "" when in compact
