Android SDK目录及版本号区别

SDK目录

add-ons

这里面保存着附加库，第三方公司为android 平台开发的附加功能系统。比如GoogleMaps，当然你如果安装了OphoneSDK，这里也会有一些类库在里面。

docs

这里面是Android SDKAPI参考文档，所有的API都可以在这里查到。

extras

platforms

是每个平台的SDK真正的文件，存放了不同版本的android系统。里面会根据APILevel划分的SDK版本，这里就以Android2.2来说，进入后有 一个android-8的文件夹，android-8进入后是Android2.2SDK的主要文件，其中data保存着一些系 统资源，images是模拟器映像文件，skins则是Android模拟器的皮肤，templates是工程创建的默认模板，android.jar则 是该版本的主要framework文件。

samples

是Android SDK自带的默认示例工程，里面的apidemos强烈推荐初学者运行学 习，对于SQLite数据库操作可以查看NotePad这个例子，对于游戏开发Snake、LunarLander都是不错的例子，对于Android主 题开发Home则是androidm5时代的主题设计原理。

下面重点介绍这3个！！！！

platform-tools

保存着一些Android不同平台相关工具，比如adb，sqlite3等文件。Fastboot 刷机工具。

tools

作为SDK根目录下的tools文件夹，这里包含了android 开发和调试的工具，比如ddms用于启动Android调试工具，比如logcat、屏幕截图和文件管理器，而draw9patch则是绘制android平台的可缩放png图片的工具， 而monkeyrunner则是一个不错的压力测试应用，模拟用户随机按键，mksdcard则是模拟器SD映像的创建工具，emulator是 Android SDK模拟器主程序，不过从android 1.5开始，需要输入合适的参数才能启动模拟器，traceview作为android平台上重要的调试工具。hierarchyviewer是一个很强大的对我们的布局文件进行分析的工具，可以看到我们的layout是否过度渲染！

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版本号！
①buildeToolVersion是你构建工具的版本，这个版本号一般是API-LEVEL.0.0。 例如I/O2014大会上发布了API20对应的build-tool的版本就是20.0.0，在这之间可能有小版本，例如20.0.1等等。
②在ecplise的project.properties中可以设置sdk.buildtools=20.0.0。也可以不设置，不设置的话就是指定最新版本。而在android studio中是必须在build.gradle中设置。
③Android都是向下兼容的，你可以用高版本的build-tool去构建一个低版本的sdk工程，例如build-tool的版本为20，去构建一个sdk版本为18的工程！

说到这，就不得不提一下，项目中minsdkversion、compilesdkversion、targetsdkversion的区别！！

min、compile、target版本的区别

这里参考一下谷歌开发者的一篇推送文章！讲的很详细
compileSdkVersion, minSdkVersion 和 targetSdkVersion 的作用：他们分别控制可以使用哪些 API ，要求的 API 级别是什么，以及应用的兼容模式。

compileSdkVersion

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

 android { compileSdkVersion 23 buildToolsVersion "23.0.1" defaultConfig { applicationId "com.example.checkyourtargetsdk" minSdkVersion 7 targetSdkVersion 23 versionCode 1 versionName “1.0” } } 

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

如果你在 manifest 文件中手工设置，你会发现 Gradle 在构建时会忽略它们（尽管其它构建系统可能会明确依赖它们）。

综合来看

如果你按照上面示例那样配置，你会发现这三个值的关系是：

minSdkVersion <= targetSdkVersion <= compileSdkVersion 

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

用较低的 minSdkVersion 来覆盖最大的人群，用最新的 SDK 设置 target 和 compile 来获得最好的外观和行为。