This reverts commit 47e065442edc108d4bb38f9daaa7cdb3fff26b49.
Now that the ContentObserver is created when activity is started (even if not
resumed), then it will be non-null during onActivityResult(). Therefore,
the calls to onChange() will not lead to NullPointerException anymore.
The reason why we want to manually call onChange() is that the
ContentObserver notifications may happen several seconds later:
https://gitlab.com/fdroid/fdroidclient/merge_requests/58#note_948719
The ContentObserver was registered only when the activity was in resumed
state. However, in started but paused state (when the activity is
visible but not in focus), we still want to receive these notifications
to update the view.
Therefore, register it on start and unregister it on stop.
As a consequence, myAppObserver will be non-null during
onActivityResult().
If the AppDetails activity has been destroyed by the system during an
application installation/remove, it is recreated once it should be
displayed again (this behavior can be forced by enabling "Don't keep
activities" in Android developer options).
In onCreate(), it passes its instance of myInstallerCallback to an
Installer. In onActivityResult() (which is called before onResume()),
this installer calls a method (onSuccess() or onError()) on this
callback. The implementation of these methods (the anonymous inner class
assigned to myInstallerCallback) dereference myAppObserver, which is
still null, because it will be initialized in onResume(), so a
NullPointerException is thrown.
However, the problem is not only that myAppObserver.onChange() is called
when myAppObserver is null, but that it should not be called manually at
all: it is a ContentObserver, so it is automatically called when
registered to the content resolver. As a consequence, this callback was
called twice.
Removing these calls fix both problems.
Should fix issue #135https://gitlab.com/fdroid/fdroidclient/issues/135
Immediately after an app uninstall, the associated App will be updated
by a call to reset() in the AppObserver.onChange().
But before receiving this event, the activity and the fragments resume,
leading to a call to getInstalledStatus(…). At this stage, we don't know
that the app has been removed yet, but the package manager already
removed it. Therefore, PackageManager.getInstallerPackageName(…) throws
an IllegalArgumentException.
In that case, consider that the application has been uninstalled.
Should fix issue #167https://gitlab.com/fdroid/fdroidclient/issues/167
Classes which contain calls to platform specific methods cause
problems, because the dexer will go looking for that method even
if you put a guard condition checking the build number. However,
if you lazily load a class depdending on the version number, then
older API devices wont try and load it, and no VerifyError occurs.
* Android-21 introduced an API for symlinking.
* Android-19 has an API which can be used via reflection.
* Earlier versions use Runtime.exec('/system/bin/ln')
This also extends the SanitizedFile stuff so that the android < 19 can
safely use Runtime.exec() with less fear of command injection vulnerabilities.
Finally, some tests for the SanitizedFile and symlink stuff was added.
This prevents an app with "write external storage" permission from
being able to switch the legit app with a dodgey one between F-Droid
requesting an install, and the package manager actually showing the
install dialog to the user.
In order to make the file in private internal storage readable by
the package manager, its parent directories need to be world-executable,
and the file itself needs to be world-readable. It seems that the
"/data/data/org.fdroid.fdroid/cache" dir provided by the Context is
already world executable, but the "apks" subdirectory does not default
to this.
Also, to be compatible with android-8, a Runtime.getRuntime().exec()
call was added for such devices, which invokes /system/bin/chmod.
The effect of this was to require some level of file sanitization to
be made available using the Java type system to prevent command injection
attacks from weird apk names (as people are free to download metadata
from random internet people).
Also, start using String[] like Android's SUPPORTED_ABIS instead of
Set<String>. Said list of ABIs will always be very short, at most containing a
handful of elements.
