I have read a number of topics regarding the 'backward compatibility' of Android and its versions, including its documentation. But I still do not understand one thing:
Home
I guarantee that my application will work completely in an earlier version, API 19 - Android KitKat for example, just specifying my minSdkVersion as 19 in build.gradle(Module:app) ?
Home
What about buildToolsVersion and compileSdkVersion , what's the difference between the two? I read in the North American StackOverflow an explanation, and yet it was not very clear to me. Could anyone clear the ideas?
Running Gradle Scripts
0
asked by anonymous 09.09.2015 / 08:22
1 answer
0
Yes, with minSdkVersion you guarantee part of the backward compatibility. I will explain later why it is only part of it.
Responding quickly to the first question, yes, not only with minSdkVersion being 19, but any value less than or equal to 19 ensures compatibility with KitKat.
Explaining some names raised:
buildToolsVersion
The buildToolsVersion is the version of the build tools, some are: aapt (which processes resources and generates class R ), aidl ), dx (which takes the bytecodes and generates the dex ), zipalign (which aligns resources to 4 bytes of addressing) and most recent jack and jill . The value of buildToolsVersion is almost independent of the versions of the SDK.
Jack and jill in theory came at a time ago to replace aapt , dx and zipalign and proguard , making the build process in only one or two steps. This can be seen more in detail here . They work, but they do not meet some cases where using annotation processing , which is usually who uses AndroidAnnotations or Dagger2 and others. ..
compileSdkVersion
The compileSdkVersion is the version you will compile the code. You can compile using version 23, but have minSdkVersion being 14. That's no problem.
A normal setting is that targetSdkVersion is equal to compileSdkVersion but that you choose a reasonable value for minSdkVersion . The choice of minSdkVersion in general should take into account the percentage of devices on the market with a particular version and the technical difficulties of using that version.
On this line, it's always good to check out the Dashboard with version usage data.
targetSdkVersion
Take some care with targetSdkVersion , because some versions have different behavior if you use a value of targetSdkVersion equal to the version of the device. This can be seen in more detail in the release notes of each release.
The second point on compatibility is the most important. It is very common to use targetSdkVersion and compileSdkVersion being the most recent version, 23 at the moment. This is cool, but we have to be very careful about the APIs we are using, because if we are using something that is not available in the minSdkVersion that has been defined, it will crash at runtime (common NoSuchMethodException ) or behaved differently than expected or is "discontinued" in newer versions.
For these cases, lint alerts us during development and during build. But it's good to always make sure before using.
09.09.2015 / 19:42