Fixes this crash:
dalvikvm W threadid=1: thread exiting with uncaught exception (group=0xb68df4f0)
AndroidRuntime E FATAL EXCEPTION: main
E java.lang.RuntimeException: Unable to resume activity {org.fdroid.fdroid/org.fdroid.fdroid.views.ManageReposActivity}: java.lang.NullPointerException
E at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2120)
E at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2135)
E at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1668)
E at android.app.ActivityThread.access$1500(ActivityThread.java:117)
E at android.app.ActivityThread$H.handleMessage(ActivityThread.java:931)
E at android.os.Handler.dispatchMessage(Handler.java:99)
E at android.os.Looper.loop(Looper.java:130)
E at android.app.ActivityThread.main(ActivityThread.java:3683)
E at java.lang.reflect.Method.invokeNative(Native Method)
E at java.lang.reflect.Method.invoke(Method.java:507)
E at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
E at dalvik.system.NativeStart.main(Native Method)
E Caused by: java.lang.NullPointerException
E at org.fdroid.fdroid.views.ManageReposActivity.checkIfNewRepoOnSameWifi(ManageReposActivity.java:466)
E at org.fdroid.fdroid.views.ManageReposActivity.addRepoFromIntent(ManageReposActivity.java:455)
E at org.fdroid.fdroid.views.ManageReposActivity.onResume(ManageReposActivity.java:144)
E at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1150)
E at android.app.Activity.performResume(Activity.java:3832)
E at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2110)
E ... 12 more
README: more on installation and troubleshooting
android SDK commands to compare locally installed targets with git fetched libraries and additional code snippets to install missing targets.
See merge request !38
do not run proguard in `ant debug` builds, it breaks the tests
The whole Android ant build system was built around the assumption that proguard is only run on the release builds. Running proguard on the debug builds breaks the test instrumentation, which does something like insert the emma methods into each class. In theory, this could be fixed, but I think its a bad idea to heavily customize the ant build system since its basically deprecated in favor of gradle.
Here's the proguard warning message:
`[proguard] Warning: can't find referenced class com.vladium.emma.rt.RT`
Instead, there is probably a way to test the release build. For example, in the Jenkins build, I added `ant clean release`, then it installs the APK, and runs the "monkey tester" on it.
See merge request !36
Rather, only show 25 progress events. I went with "25 events" rather
than "every X apps" because then it will be nice for both large repos
(e.g. F-Droid will update every ~50 apps) and small repos (something
with 20 apps will update for every one, but not add much overhead).
On my testing with an API 11 emulator here, it went from ~32s to
process ~1100 apps to ~20s. When no progress events are sent, then it
also takes ~20s, so this essentially is a 50% improvement for this part
of the update process.
The whole ant build system was built around the assumption that proguard is
only run on the release builds. Running proguard on the debug builds
breaks the test instrumentation, which does something like insert the emma
methods into each class. In theory, this could be fixed, but I think its a
bad idea to heavily customize the ant build system since its basically
deprecated in favor of gradle.
Here's the proguard warning message:
[proguard] Warning: can't find referenced class com.vladium.emma.rt.RT
Saves the new data for the repo at the end of the update process to enable the user to re-trigger the update in case the update exited prematurely.
Fixes#84.
There is a bug where the android.support.widget.SearchView gets
removed by proguard which causes breakage. This prevents that
from occuring by a bit of a brute force approach. While it would
be possible to keep only the class in question, this may leave
us open to other bugs in the future. Better to be safe than sorry.
http://stackoverflow.com/questions/22136032/action-bar-search-view-android-null-error
When the user updates the repo and all packages are recent, the update dialog exited so fast, that some users might have thought that the repo didn't update. To notify them that no new updates were found, the user now gets a toast.
Proguard removed the method org.fdroid.fdroid.installer.SystemInstaller$PackageInstallObserver$packageInstalled,
resulting in an AbstractMethodError crash.
Fixes issue [79](https://gitlab.com/fdroid/fdroidclient/issues/79).
This increases the size of the .apk by ~800kb, which is clearly
undesirable. However, the nature of the Java security suite
implementations are that they use a lot of reflection to instantiate
classes. The end result is that proguard excludes classes which
may be required, depending on the security algorithms required
by certain certificates.
Fixes issue #88
revert to plain CA-based HTTPS verification
This is to address #80 so we can get a stable release out. Then we should revisit #80 and actually get the pinning and TOFU working properly.
See merge request !30
This reverts to only using standard HTTPS verification based on Certificate
Authorities. This means that self-signed certificates will not work at all
since that is what MemorizingTrustManager was providing. It seems to me
that this was originally working because MemorizingTrustManager was not
correctly validating. I couldn't figure out why PinningTrustManager alone
was not working. But we need to get good stable release out!
I'm leaving all the plumbing in place because this stuff should be included
once its all fixed and working properly. You can see where it was added
here: 254327f9a7700c8196e61f53801f1f12ac825806
refs #80https://gitlab.com/fdroid/fdroidclient/issues/80
The problem arose when we start with no categories other than the
three defaults, then add a repo with multiple categories. The exact
issue was that although the category spinner itself was updated,
the listener for onChange was referencing the list of categories
from before (with only three categories). Changed it to use data
from the category spinner adapter, that way it is always up to
date.
Also fixed some warnings in the file. Instance access of a static
object, and deprecated method warning.
Fix issue #56 -- update.zip
Creates a script create a update.zip file that installs F-Droid to `/system/app` or `/system/priv-app` depending on the android version. Also creates a remove.zip to remove F-Droid. Generates a zip file for every apk in the bin directory, to work with both signed and unsigned apks. Fixes issue #56.
See merge request !29
Fix issues #74 and #75
The indeterminent progress indicator in the `AppDetails` view is now hidden by default on Android 4.0.3 (which is the only reproducing device I had access to). Had to replace a bunch of calls with those provided by appcompat.
As for the "(De-)Installation Error" message when using the root installer, it was due to the timeout being set to 5 seconds for the superuser shell. Note that just accepting the super user prompt takes a minimum of 3 seconds, plus the install time. I changed the timeout to 30 seconds, for reasons explained in the commit.
NOTE: @mvdan, I noted that you mentioned you were not interested in client development any more, so I'm not quite sure if it is worthwhile me submitting this as a MR (FYI - thanks for all the help on the client, also happy that your able to spend more time on build recipies and fdroidserver stuff. Great to see all that moving along). Perhaps @CiaranG, if you had the time to review it you could give it the thumbs up or down? Otherwise, I'll merge it myself.
See merge request !27
The superuser shell has a timeout that can be specified. The timeout
was set to 5 seconds, thus the exit code from the shell is -1 (a
reserved exit code used by libsuperuse to indicate timeout).
By my estimate, it is more likely that a user will hit this error
message and get annoyed, compared to actually hitting a genuine timeout
because of some issue with superuser. Especially when we factor in slow
devices and large apps to install. Thus, the timeout has been bumped
to a more generous 30 seconds.
Replaced progress indicator methods with their "support" equivalents.
Also, it seems that on Android 4.0.4 and 4.0.3 if you request a
progress indicator in your ActionBarActivity (from the support
library), that it is set to visible to begin with. At least, that is
the conclusion I have come to, seeing as the only places it is set to
visible is on installApk() and removeApk(). Setting it to hidden in
onCreate seemed to do the trick (Couldn't use onResume, because we come
back from the "Request super user permissions" dialog, which causes
onResume to be invoked).
