android_SDK_API

1.android中SDK和API。

首先：

SDK 顾名思义就是android的开发专属工具包（software development kit）。

API是android系统不断的升级所产生的产物，API为开发者提供了实现功能该调用的接口和说明。

其次：

其中google提供了V4，v7，V13支持包。

意思就是：在低的平台（如：android 1.6平台）上开发，但是想使用更高版本持有的功能，这个时候就需要用到支持包了。

V4 是最早的支持包，主要用在1.6或者更高的版本上，它包含了Fragment，NotifycationCompat，LoadBroadCastManager，

Viewpager，PageTabAtrip，Loader，FileProvider这个功能。

V7 是考虑到2.1及以上的版本，使用V7必须要依赖以V4这个包，也就是两个要同时用，如V7支持了actionbar。

然后：

我们需要明白andorid开发有两种开发环境。

A：android studio 安装sdk进行开发，针对单个app模块进行开发，这种开发不涉及硬件，底层信息，只需要熟悉各种SDK jdk的各种接口调用。

B：android  源码开发，这种模式开发可以篡改系统本身的应用程序，会涉及到底层C语言，及硬件例如sensor，蓝牙，驱动.

2.解析SDK包

2.1.add-ons :

这里面保存着一些附加库，第三方公司提供给google的附件功能系统，例如googlemaps。

2.2.docs：

这里面是android sdk  API的参考文档。

2.3.platforms：

这里是每个平台的真正文件，存放着不同版本的android系统，里面会根据API level划分SDK的版本，例如：拿android2.2来说，

进入后有一个android-8文件夹，android-8进入后是android-2.2SDK的主要文件：

2.3.1：ant：ant编译脚本

2.3.2：data：里面保存着一个系统的资源。

2.3.3：images：是模拟器的映像文件。

2.3.4：skins：是模拟器的皮肤

2.3.5：android.jar则是该版本的主要的framework文件

2.3.6：tools：目录里面包含了重要的编译工具，如：aapt，aidl，逆向调试工具dexdump和编译脚本dx

2.4.platform-tools：

保存着一些Android平台相关通用工具，比如adb、和aapt、aidl、dx等文件，这里和platforms目录中tools文件夹有些重复。

2.5.tools：

作为SDK根目录下的tools文件夹，这里包含了android 开发和调试的工具，比如ddms用于启动Android调试工具，比如logcat、屏幕截图和文件管理器，而draw9patch则是绘制android平台的可缩放png图片的工具，sqlite3可以在PC上操作SQLite数据库， 而monkeyrunner则是一个不错的压力测试应用，模拟用户随机按键，mksdcard则是模拟器SD映像的创建工具，emulator是 Android SDK模拟器主程序，不过从android 1.5开始，需要输入合适的参数才能启动模拟器，traceview作为android平台上重要的调试工具。

2.6.build-tools:

保存着一些Android平台相关通用工具，比如adb、和aapt、aidl、dx等文件。

aapt即Android Asset Packaging Tool , 在SDK的build-tools目录下. 该工具可以查看, 创建, 更新ZIP格式的文档附件(zip, jar, apk). 也可将资源文件编译成二进制文件.

Adb 即android debug bridge 管理模拟器和真机的万能工具，ddms 调试环境

AIDL 即 Android Interface definition language 它是一种android内部进程通信接口的描述语言，通过它我们可以定义进程间的通信接口

Emulator即android 的模拟器

dx：转化.class中间代码为dvlik中间代码,所有经过Java编译的生成.class文件都需要此工具进行转换,最后打包进apk文件中.

Dexdump 即Android Emulator中可以找到一个名为dexdump的程序，通过dexdump可以查看出apk文件中的dex执行情况，粗略分析出原始java代码是什 么样的和Dot Net中的Reflector很像。

注意：这里会涉及到一个问题，就是build-tools后边会有不同的api版本号！

2.6.1:buildeToolVersion是你构建工具的版本，这个版本号一般是API-LEVEL.0.0。 例如I/O2014大会上发布了API20对应的build-tool的版本就是20.0.0，在这之间可能有小版本，例如20.0.1等等。

2.6.2:在ecplise的project.properties中可以设置sdk.buildtools=20.0.0。也可以不设置，不设置的话就是指定最新版本。而在android studio中是必须在build.gradle中设置。

2.6.3:Android都是向下兼容的，你可以用高版本的build-tool去构建一个低版本的sdk工程，例如build-tool的版本为20，去构建一个sdk版本为18的工程！

2.7.项目中minsdkversion、compilesdkversion、targetsdkversion的区别:

compileSdkVersion, minSdkVersion 和 targetSdkVersion 的作用：他们分别控制可以使用哪些 API ，要求的 API 级别是什么，以及应用的兼容模式。

compileSdkVersion

compileSdkVersion 告诉 Gradle 用哪个 Android SDK 版本编译你的应用。使用任何新添加的 API 就需要使用对应等级的 Android SDK。

需要强调的是修改 compileSdkVersion 不会改变运行时的行为。当你修改了 compileSdkVersion 的时候，可能会出现新的编译警告、编译错误，但新的 compileSdkVersion 不会被包含到 APK 中：它纯粹只是在编译的时候使用。（你真的应该修复这些警告，他们的出现一定是有原因的！）

因此我们强烈推荐你总是使用最新的 SDK 进行编译。在现有代码上使用新的编译检查可以获得很多好处，避免新弃用的 API ，并且为使用新的 API 做好准备。

注意，如果使用 Support Library ，那么使用最新发布的 Support Library 就需要使用最新的 SDK 编译。例如，要使用 23.1.1 版本的 Support Library，compileSdkVersion 就必需至少是 23 （大版本号要一致！）。通常，新版的 Support Library 随着新的系统版本而发布，它为系统新增加的 API 和新特性提供兼容性支持。

minSdkVersion

如果 compileSdkVersion 设置为可用的最新 API，那么 minSdkVersion 则是应用可以运行的最低要求。minSdkVersion 是 Google Play 商店用来判断用户设备是否可以安装某个应用的标志之一。

在开发时 minSdkVersion 也起到一个重要角色：lint 默认会在项目中运行，它在你使用了高于 minSdkVersion 的 API 时会警告你，帮你避免调用不存在的 API 的运行时问题。如果只在较高版本的系统上才使用某些 API，通常使用“运行时检查系统版本”的方式解决。

请记住，你所使用的库，如 Support Library 或 Google Play services，可能有他们自己的 minSdkVersion 。你的应用设置的 minSdkVersion 必须大于等于这些库的 minSdkVersion 。例如有三个库，它们的 minSdkVersion 分别是 4, 7 和 9 ，那么你的 minSdkVersion 必需至少是 9 才能使用它们。在少数情况下，你仍然想用一个比你应用的 minSdkVersion 还高的库（处理所有的边缘情况，确保它只在较新的平台上使用），你可以使用 tools:overrideLibrary 标记，但请做彻底的测试！

targetSdkVersion

三个版本号中最有趣的就是 targetSdkVersion 了。 targetSdkVersion 是 Android 提供向前兼容的主要依据，在应用的 targetSdkVersion 没有更新之前系统不会应用最新的行为变化。这允许你在适应新的行为变化之前就可以使用新的 API （因为你已经更新了 compileSdkVersion 不是吗？）。

targetSdkVersion 所暗示的许多行为变化都记录在 VERSION_CODES 文档中了，但是所有恐怖的细节也都列在每次发布的平台亮点中了，在这个 API Level 表中可以方便地找到相应的链接。