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.
Taken from the gradle plugin user guide:
With Android KitKat (buildToolsVersion 19) you can use the diamond operator,
multi-catch, strings in switches, try with resources, etc.
Note that you can use minSdkVersion with a value earlier than 19, for all
language features except try with resources. If you want to use try with
resources, you will need to also use a minSdkVersion of 19.
You also need to make sure that Gradle is using version 1.7 or later of the
JDK. (And version 0.6.1 or later of the Android Gradle plugin.)
Both preferencefragment and appcompat-v7 submodules need the
android-support-v4.jar to be included in their respective libs/ dirs in
order for ant to build those projects.
NOTE: I don't know how android will go with adding a new property
to a string-array resource, but not having it translated everywhere.
Will it struggle because the EN version has three values for "theme",
but other translations only have two?
Although Google is encouraging people to make old devices run apps
with the action bar (via appcompat-v7), they haven't provided a way
for people to create preference/setting screens with an action bar.
There are plenty of issues in the Android issue tracker relating
to this, but it doesn't yet seem to be on the radar of the Android
devs.
Until there is a native implementation of PreferenceFragment in
the appcompat-v7 support library, this submodule provides is a 3rd
party solution. It is actually a fork of the first repo in github,
though that was a bit of an upload and dump, without accepting MR's.
This fork includes gradle support.
Thanks to the awesome work of mvdan, this was mostly ready to roll.
However, I had to wrestle for a while for two reasons:
1) I forgot to add the dependency in the build.gradle file (it was
already present in settings.gradle)
2) My IDE was unable to read the ANDROID_HOME env variable, and
despite my internet-search-fu, I couldn't figure out how to
make IntelliJ specify env variables for a gradle build. It took
a while to figure out, because it was failing silently in weird
ways.
After slaving away on a nice method to parse both the ANDROID_HOME
and the local.properties file (looking for sdk.dir), and then emmiting
nice error messages if neither were found or pointed to an invalid
location, I discovered it had already be done:
android.plugin.sdkDirectory ends up here:
https://android.googlesource.com/platform/tools/build/+/master/gradle/src/main/groovy/com/android/build/gradle/internal/Sdk.groovy#161
Which does exactly all that and more. So now sdkLoc is initialized to
the value of android.plugin.sdkDirectory.
