How Gradle Scripts works

Question

I’ve read several topics regarding the 'backward compatibility' of Android and its versions, including the documentation of it. But I still don’t understand one thing:

I guarantee that my application will fully work in an earlier version, API 19 - Android Kitkat for example, just specifying my minSdkVersion as 19 in the build.gradle(Module:app)?

And as for the buildToolsVersion and compileSdkVersion, What’s the difference between the two? I read in Stackoverflow North American an explanation, and even then it wasn’t very clear to me. Could someone clear their head?

Answer 1

Yes, with minSdkVersion you guarantee part of the backward compatibility. I will explain further why only part of it.

By quickly answering the first question, yes, not only with the minSdkVersion being 19, but any value less than or equal to 19 you guarantee compatibility with Kitkat.

---

Explaining some names raised:

buildToolsVersion

The buildToolsVersion is the version of build, some are: aapt (that processes the resources and generates the class R), the aidl (which processes its service interfaces), the dx (who catches the bytecodes and generates the Dex), the zipalign (aligning resources to 4 bytes of addressing) and more recent jack and the jill. The value of buildToolsVersion is almost independent of SDK versions.

Jack and jill in theory came a while ago to replace the aapt, the dx and the zipalign and the proguard, making the build process in just one or two steps. This can be seen in more detail here. They work but do not meet some cases where the use of Annotation Processing, who is usually the one who uses the Androidannotations or Dagger2 and others...

compileSdkVersion

The compileSdkVersion is the version you will compile the code from. You can compile using version 23, but have the minSdkVersion being 14. That’s no problem.

A normal setting is that the targetSdkVersion is equal to compileSdkVersion but that you choose a reasonable value for the minSdkVersion. The choice of minSdkVersion in general should be taken into account the percentage of devices on the market with a certain version and the technical difficulties of using that version. In this line, it is always good to consult the Dashboard with the version usage data.

targetSdkVersion

Take some care with the targetSdkVersion, because some versions have different behavior if you use a value of targetSdkVersion device version. This can be seen in more detail in the release of each version.

The second point about compatibility is the most important. It is very common to use the targetSdkVersion and the compileSdkVersion the most recent version, 23 at this time. That’s cool, but we have to be very careful with the Apis we’re using, because if we’re using something that’s not available on minSdkVersion which has been defined, will give crash at runtime (alias NoSuchMethodException) either it has a different behavior than expected or it is "discontinued" in newer versions.

For such cases, the lint alerts us during development and build. But it’s good to always make sure before using.