Android SDK Directory and version number difference

Today, someone asked Tools,build-tools,platform-tools what is the difference, what is it?
Now to the SDK directory to do a summary of the elaboration!

SDK Directory Add-ons

This contains additional libraries, and third-party companies develop additional functional systems for the Android platform. such as GoogleMaps, of course, if you install OPHONESDK, there will be some class library inside.

Docs

This is the Android Sdkapi reference document, all the APIs can be found here.

Extras

The folder contains the Android support V4,V7,V13,V17 package;
There are additional toolkits such as Google's USB drive and Intel's hardware acceleration.
and market_licensing as a androidmarket copyright protection component, the general release paid application to the electronic market can use it to anti-piracy.

Platforms

The SDK for each platform is the real file that stores different versions of the Android system. It will be based on APILevel division of the SDK version, here to Android2.2, enter after a android-8 folder, Android-8 into the ANDROID2.2SDK is the main file, where Ant is the ant compilation script, data holds some system resources, images is the emulator image file, skins is the skin of the Android simulator, Templates is the default template for project creation, Android.jar is the main framework file for this version, and the Tools directory contains important compilation tools such as AAPT, Aidl, reverse Debugging Tools Dexdump, and compile-script dx.

Samples

Is the Android SDK comes with the default example project, the inside of the Apidemos strongly recommend the beginner to run learning, for SQLite database operation can see Notepad This example, for game development Snake, Lunarlander is a good example, Developing home for Android theme is the theme design principle of ANDROIDM5 era.

Here are the highlights of these 3!!!! Platform-tools

There are some common Android platform related tools , such as ADB, and AAPT, Aidl, DX and other files, here and platforms directory of tools folder duplication, mainly from the beginning of android2.3 these tools are divided into universal. FastBoot Brush Machine tool.

Tools

As the Tools folder in the SDK root directory, this includes the Android development and debugging tool , such as DDMS for launching Android debugging tools such as logcat, screen, and file Manager, While Draw9patch is the tool to draw a scalable PNG image on the Android platform, Sqlite3 can manipulate the SQLite database on a PC, while Monkeyrunner is a good stress test application that simulates user random keys, Mksdcard is the simulator SD image creation tool, emulator is the Android SDK emulator main program, but starting from Android 1.5, you need to enter the appropriate parameters to start the simulator, TraceView as an important debugging tool on the Android platform.

Build-tools

The

holds some common tools related to the Android platform , such as ADB, AAPT, aidl, DX, and so on. The
aapt is the Android Asset Packaging tool, in the Build-tools directory of the SDK. The tool can view, create, update zip-format document attachments (Zip, jar, apk). The resource file can be compiled into a binary file.
Adb is the Universal tool for Android Debug Bridge Management simulator and real machine, DDMS debug Environment
Aidl that is Android Interface Definition language It is a description language of the internal process communication interface of Android, through which we can define the communication interface between processes
Emulator that is, Android emulator
DX : Conversion. Class intermediate Code is the Dvlik intermediate code, all Java-compiled build. class files require this tool to be converted and then packaged into the APK file.
Dexdump that is, the Android emulator can find a program called Dexdump, through Dexdump can see out the apk file in the Dex execution, a rough analysis of the original Java code is what It's like the reflector in dot net.

Note: There is a problem here, that is, there will be a different API version number behind the Build-tools!
①buildetoolversion is the version of your build tool, and this version is typically api-level.0.0. For example, the I/O2014 conference released the API20 corresponding to the Build-tool version is 20.0.0, there may be a small version between this, such as 20.0.1 and so on.
② can be set sdk.buildtools=20.0.0 in the project.properties of Ecplise. You can also not set, if not set to specify the latest version. And in Android Studio, it must be set in Build.gradle.
③android are backwards compatible, you can use the higher version of Build-tool to build a lower version of the SDK project, such as the Build-tool version of 20, to build an SDK version of 18 Project!

Speaking of this, you have to mention, the project Minsdkversion, compilesdkversion, targetsdkversion difference!!

Min, compile, target version of the difference

take a look at Google Developer's push article here! It's a very detailed story.
The role of Compilesdkversion, Minsdkversion and targetsdkversion: they control which APIs they can use, what API levels are required, and the compatibility mode of the application.

Compilesdkversion

Compilesdkversion tells Gradle which Android SDK version to use to compile your app. Using any of the newly added APIs requires a corresponding level of Android SDK.
It should be emphasized that modifying compilesdkversion does not alter the behavior of the runtime . When you modify the compilesdkversion, there may be a new compilation warning, a compilation error, but the new compilesdkversion will not be included in the APK: it is simply used at compile time. (You really should fix these warnings, there must be a reason for their presence!) ）
Therefore , we strongly recommend that you always compile with the latest SDK . Using the new compilation check on existing code can get many benefits, avoid new deprecated APIs, and prepare for the use of new APIs.
Note that if you use the support library, you will need to use the latest SDK compilation with the latest published support Library. For example, to use the 23.1.1 version of support library,compilesdkversion must be at least 23 (large version number to match!) ）。 Typically, the new version of the support Library is released with the latest system release, which provides compatibility for the new added APIs and features of the system.

Minsdkversion

If Compilesdkversion is set to the latest available API, then minsdkversion is the minimum requirement that the app can run . Minsdkversion is one of the logos that Google Play stores use to determine whether a user device can install an app.
Minsdkversion also plays an important role in development: Lint will run in the project by default, and it will warn you when you are using an API higher than minsdkversion, and help you avoid the runtime problem of calling an API that does not exist. If some APIs are used only on higher versions of the system, they are usually resolved using the runtime check system version.
Keep in mind that the libraries you use, such as the support library or Google Play services, may have their own minsdkversion. The minsdkversion of your app settings must be greater than or equal to the minsdkversion of these libraries. For example, there are three libraries, and their minsdkversion are 4, 7, and 9, so your minsdkversion must be at least 9 to use them. In a few cases, you still want to use a library that is higher than the one you applied (to handle all the edge situations and make sure it is only used on newer platforms), you can use the tools:overridelibrary tag, but do a thorough test minsdkversion!

Targetsdkversion

The most interesting of the three version numbers is targetsdkversion. Targetsdkversion is the primary basis for Android to provide forward compatibility, and the system does not apply the latest behavioral changes until the app's targetsdkversion is updated. This allows you to use the new API before adapting to new behavioral changes (because you've updated compilesdkversion, haven't you?). ）。
Many of the behavioral changes hinted at by Targetsdkversion are documented in the Version_codes documentation, but all the scary details are listed in the platform highlights of each release, which can be easily found in the API level table.

For example, "Android 6.0 Changes" talks about how target API 23 o'clock will convert your app to the runtime permissions model, "behavior changes in Android 4.4" illustrates the use of set () and Setrepe when Target is API 19 and above Ating () sets how the alarm will behave.
Since some behavior changes are very obvious to the user (Deprecated menu buttons, runtime permissions, etc.), updating target to the latest SDK is something that all applications should prioritize. But that doesn't mean you have to use all the newly introduced features, nor does it mean that you can blindly update targetsdkversion without doing any testing, and be sure to test before updating targetsdkversion! Your users will thank you for that.

Gradle and SDK versions

So it is important to set the correct compilesdkversion, minsdkversion and Targetsdkversion. As you can imagine, both Gradle and Android Studio integrate them in the build system. In your module's Build.gradle file (also available in the project structure options in Android Studio):

    android {      23      "23.0.1"      defaultConfig {        "com.example.checkyourtargetsdk"        7        23        1        versionName “1.0”      }    }

The compilesdkversion used at compile time is one of the Android settings set up with the build tool version. The other two are slightly different, they are declared there in the build variant (build variant). Defaultconfig is the basis for all build variants and is where these default values are set. You can imagine that in a more complex system, some versions of the app might have different minsdkversion.
Another difference between minsdkversion and Targetsdkversion and Compilesdkversion is that they will be included in the final APK file, if you view the generated Androidmanifest.xml file, You'll see a label like this:

<uses-sdk android:targetSdkVersion="23" android:minSdkVersion="7" />

If you set it up manually in the manifest file, you will find that Gradle ignores them when they are built (although other build systems may be explicitly dependent on them).

In a comprehensive view

If you configure as shown in the example above, you will find that the relationship between the three values is:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

This intuition is reasonable, if compilesdkversion is your maximum value, minsdkversion is the minimum value, then the maximum must be at least as large as the minimum value and target must be between the two.
Ideally, the three relationships should be more like this in a stable state:

minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)

Use the lower Minsdkversion to reach the largest crowd and set the target and compile with the latest SDK to get the best look and behavior.

Android SDK Directory and version number difference