Android SDK作用和结构

本文主要介绍一下SDK目录结构！

现在对SDK目录做一下总结阐述！

SDK目录

add-ons

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

docs

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

extras

该文件夹下存放了Android support v4，v7，v13，v17包；
还有google提供额USB驱动、Intel提供的硬件加速等附加工具包，
和market_licensing作为AndroidMarket版权保护组件，一般发布付费应用到电子市场可以用它来反盗版。

platforms

是每个平台的SDK真正的文件，存放了不同版本的android系统。里面会根据APILevel划分的SDK版本，这里就以Android2.2来说，进入后有 一个android-8的文件夹，android-8进入后是Android2.2SDK的主要文件，其中ant为ant编译脚本，data保存着一些系 统资源，images是模拟器映像文件，skins则是Android模拟器的皮肤，templates是工程创建的默认模板，android.jar则 是该版本的主要framework文件，tools目录里面包含了重要的编译工具，比如aapt、aidl、逆向调试工具dexdump和编译脚本dx。

samples

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

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

platform-tools

保存着一些Android平台相关通用工具，比如adb、和aapt、aidl、dx等文件，这里和platforms目录中tools文件夹有些重复，主要是从android2.3开始这些工具被划分为通用了。Fastboot 刷机工具。

tools

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

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

compileSdkVersion 告诉 Gradle 用哪个 Android SDK 版本编译你的应用。使用任何新添加的 API 就需要使用对应等级的 Android SDK。
需要强调的是修改 compileSdkVersion 不会改变运行时的行为。当你修改了 compileSdkVersion 的时候，可能会出现新的编译警告、编译错误，但新的 compileSdkVersion 不会被包含到 APK 中：它纯粹只是在编译的时候使用。（你真的应该修复这些警告，他们的出现一定是有原因的！）
因此我们强烈推荐你总是使用最新的 SDK 进行编译。在现有代码上使用新的编译检查可以获得很多好处，避免新弃用的 API ，并且为使用新的 API 做好准备。
注意，如果使用 Support Library ，那么使用最新发布的 Support Library 就需要使用最新的 SDK 编译。例如，要使用 25.3.1 版本的 Support Library，compileSdkVersion 就必需至少是 23 （大版本号要一致！）。

如果你的compileSdkVersion 是 25 ，那就要求 SDK Tools 和 SDK Platforms 有对应的版本，Android Studio 3.2以上貌似没有要求（即时你的 SDK Tools 为 24）。

通常，新版的 Support Library 随着新的系统版本而发布，它为系统新增加的 API 和新特性提供兼容性支持。

minSdkVersion

指明应用程序运行所需的最小API level。如果不指明的话，默认是1。也就是说该应用兼容所有的android版本。我们应该总是声明这个属性。如果系统的API level低于android:minSdkVersion设定的值，那么android系统会阻止用户安装这个应用。如果指明了这个属性，并且在项目中使用了高于这个API level的特有方法， 那么会在编译时报错。
如果 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 不是吗？）。compileSdkVersion 不能小于 targetSdkVersion 。

如果平台的API Level高于你的应用程序中的targetSdkVersion属性指定的值，系统会开启兼容行为来确保你的应用程序继续以期望的形式来运行。你可以通过指定targetSdkVersion来匹配运行程序的平台的API level来禁用这种兼容性行为。举例来说，设置这个值为11或更高，当你的应用运行在Android3.0或更高的系统上时，系统会为你的应用使用新的默认主题（Holo主题），并且当运行在大屏幕的设备上时会禁用屏幕兼容模式（screen compatibility mode），因为支持了 API level 11就暗示了支持大屏幕。
targetSdkVersion 所暗示的许多行为变化都记录在 VERSION_CODES 文档中了，但是所有恐怖的细节也都列在每次发布的平台亮点中了，在这个 API Level 表中可以方便地找到相应的链接。

例如，《Android 6.0 的变化》中谈了 target 为 API 23 时会如何把你的应用转换到运行时权限模型上，《Android 4.4 的行为变化》阐述了 target 为 API 19 及以上时使用 set() 和 setRepeating() 设置 alarm 会有怎样的行为变化。
由于某些行为的变化对用户是非常明显的（弃用的 menu 按钮，运行时权限等），所以将 target 更新为最新的 SDK 是所有应用都应该优先处理的事情。但这不意味着你一定要使用所有新引入的功能，也不意味着你可以不做任何测试就盲目地更新 targetSdkVersion ，请一定在更新 targetSdkVersion 之前做测试！你的用户会感谢你的。

Android 高版本API方法在低版本系统上的兼容性处理

1.使用@TargeApi($API_LEVEL)可以编译通过，不建议使用@SuppressLint("NewApi");

两者区别：

@SuppressLint("NewApi"）屏蔽一切新api中才能使用的方法报的android lint错误。@TargetApi() 只屏蔽某一新api中才能使用的方法报的android lint错误。

举个例子进行说明，某个方法中使用了API9新加入的方法，而项目设置的最小API Level为android:minSdkVersion=8，此时在方法上加@SuppressLint("NewApi"）和@TargetApi(Build.VERSION_CODES.GINGERBREAD)都可以，以上是通用的情况。而当你在此方法中又引用了一个API11才加入的方法时，@TargetApi(Build.VERSION_CODES.GINGERBREAD)注解的方法又报错了，而@SuppressLint("NewApi"）不会报错，这就是区别。

2.判断运行时版本，在低版本系统不调用此方法，同时为了保证功能的完整性，需要提供低版本功能实现。

minSdk和targetSdk的区别：

这两者相当于一个区间。你能够用到targetSDK中最新的API和最酷的新功能，但你又不得不向下兼容到minSDK，保证这个区间内的设备都能够正常的执行你的app。换句话说，你想使用Android刚刚推出的新特性。但这对于你的app又不是必须的。你就能够将targetSDK设置为你想使用新特性的SDK版本号，minSDK设置成低版本号保证全部人都能够使用你的app。

 

举一个样例：假如你想给你的app增加大量的手势操作（sdk 7才引入的），然而这些手势操作能够被Button啊或menu等取代，在这样的情况下，手势操作就是一个额外的加分功能，而不是一个必须的功能，因此你就须要把targetSDK设置为7，把minSDK设置为3（这是举个样例，如今没人还在用这么老的设备了）这样即使是使用老设备的用户也能够用你的app了。

然后你所要做的就是要在代码里推断版本号，假设是大于等于7的版本号中就使用手势操作，小于7的版本号中就使用button等取代，这样使用了新手机的用户就能够体验到你app中酷炫的新功能了。

另外一个样例：假设你想给你的项目增加Android 5.0的Material Design，有一些用户可能会升级到5.0而使用到你的新特性，而有一部分用户的手机硬件太老，不支持升级到5.0，除非他们换新手机。那么你就要为他们进行向下兼容，不至于损失这部分用户，这样你的targetSDK设置为21。minSDK能够设置为8

支持包

为什么官方向开发者在提供了 android sdk 之外，还要提供一些零碎的开发支持jar包，全部放在 framework 中不好吗？恩，不好！因为这不是好不好的问题，这是 Android 平台快速发展带来的必然产物，这张图罗列了已经发布的 Android 版本及其对应的开发 sdk 的级别。

至于为什么提供支持包官方给出了大致三个原因：

1. 向后兼容

比如，我们开的App需要支持的 minSdkVersion=9，targetSdkVersion=11，在程序里使用了android 3.0 (API level 11)提供的 ActionBar类，使用 compileSdkVersion=11 成功编译出apk。在 android 3.0 的设备上完美运行，但是app在 android 2.3 的设备就会 crash，报找不到 ActionBar 的错误。

这很好理解，因为旧版本上没有新版本里新增的类。为了避免使用了最新功能开发的app只能在最新系统的设备上运行的尴尬，官方把新版系统framework中新增加的接口提出来放到了 Android Support Library（支持包）中，开发者在遇到上面的情况时，就可以使用支持包中具有同样功能的 ActionBar类，这个支持包会打包进App里，这样使用了新版本系统上功能的App也可以向后兼容以前的老系统版本设备了。

使用支持包中的类除了让我们免于判断App运行的系统版本外，还可以使App在各个版本保持同样的用户体验。如在5.0以下系统使用 material design。

App编译时用的 android sdk（android.jar）不会打包进我们的App中。因为App编码是使用 android.jar 中的接口就是 android设备里系统框架层（framework）对外提供的接口。

2. 提供不适合打包进framework的功能

Android官方 对App开发提供了推荐设计，希望 Android应用 都有相对一致的交互设计来减少用户的使用成本，希望三方App类似系统应用从而完美融入到Android生态系统中。但是这都仅仅是推荐，不要求开发者一定要这样，如果有这种需求就可以使用官方支持包提供的这些功能，避免重复造轮子。如支持包中的 DrawerLayout、Snackbar 等类都是这种情况。

3. 为了支持不同形态的设备

通过使用支持包来在不同形态设备上提供功能，如手机、电视、可穿戴设备等。

Gradle 和 SDK 版本

所以设置正确的 compileSdkVersion, minSdkVersion 和 targetSdkVersion 很重要。如你所想，Gradle 和 Android Studio 都在构建系统中集成了它们。在你的模块的 build.gradle 文件中（也可以在 Android Studio 的项目结构选项中）设置：

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

编译时用到的 compileSdkVersion 是和构建工具版本一起设置的 Android 设置之一。其他两个稍有不同，他们在构建变体(build variant)的那里声明。defaultConfig 是所有构建变体的基础，也是设置这些默认值的地方。你可以想象在一个更复杂的系统中，应用的某些版本可能会有不同的 minSdkVersion 。
minSdkVersion 和 targetSdkVersion 与 compileSdkVersion 的另一个不同之处是它们会被包含进最终的 APK 文件中，如果你查看生成的 AndroidManifest.xml 文件，你会看到类似下面这样的标签：

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

综合来看

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

minSdkVersion <= targetSdkVersion <= compileSdkVersion

这种直觉是合理的，如果 compileSdkVersion 是你的最大值，minSdkVersion 是最小值，那么最大值必需至少和最小值一样大且 target 必需在二者之间。
理想上，在稳定状态下三者的关系应该更像这样：

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

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

          ok！关于SDK的目录结构就阐述到这里。

 

本文借鉴文章：

 https://blog.csdn.net/itluochen/article/details/52688935

https://mp.weixin.qq.com/s/IzOPQCQKoAjNrXmdzEb96g

https://blog.csdn.net/wangpf2011/article/details/80008887

https://www.cnblogs.com/mfmdaoyou/p/6922549.html