* 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).
Superfdroid fixes
Package names and apk file names should only contain letters, numbers, dots,
and underscores. This is now checked in RootInstaller before executing 'pm
install' or 'pm uninstall'.
See merge request !48https://gitlab.com/fdroid/fdroidclient/merge_requests/48
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.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
The specific reason for this is that it provides @Null and @NotNull
annotations which should increase the safety of our code. Many of the
bugs which get filed are due to NullPointerExceptions, which could be
avoided by tooling using these annotations. The goal is to statically
catch this specific class of errors in as many situations as possible,
rather than waiting for them to occur at runtime.
