今天又有人問Tools，Build-Tools，Platform-tools有什麼區別，是幹嘛的？
現在對SDK目錄做一下總結闡述！

SDK目錄

add-ones

add-ones：裡面儲存著一些附加的庫，第三方公司為Android平臺開發的附加功能系統。比如GoogleMaps 。(一開始此包為空)

build-tools

build-tools：編譯工具目錄，包含了轉化為davlik虛擬機器的編譯工具。當建立Android專案(構建專案)的時候會用到這個包。在建立專案的時候如果沒有此包會報錯。 （隨著SDK版本的迭代，編譯工具也會有相應新版本，建議使用最新的編譯工具）

包括:
aidl.exe：把.aidl 介面轉換成java介面

dexdump.exe (逆向除錯工具) : dump devlik中間程式碼

aapt.exe（Android Asset Packaging Tool）：編譯應用程式的資原始檔（包括AndroidManifest.xml和你的Activities的xml檔案），生成R.java檔案，這樣你就可以從你的java程式碼中引用資源。

dx.bat(編譯指令碼)：  將.class中間程式碼轉化為dvlik中間程式碼,所有經過java編譯的生成.class檔案都需要此工具進行轉換,最後打包進apk檔案中.
 

docs

docs : docs這裡面是Android SDKAPI參考文件，所有的API都可以在這裡查到。

extras

extras：該檔案下存放了Google提供的USB驅動，Intel提供的硬體加速附件工具包。（後期存放了Android Support相容包，使用相容包版本時最好與SDK版本保持一致）

platforms

platforms：裡面是根據APILevel劃分的SDK版本/平臺，這個資料夾是SDK裡面最重要的檔案(每個平臺的SDK真正的檔案),這裡就以Android6.0為例，進入後有一個android-23的資料夾，android-23進入後是Android6.0 SDK的主要檔案，

其中
data:儲存著一些系統資源，
skins:Android模擬器的面板，
templates:是工程建立的預設模板，
android.jar:是該版本的主要framework檔案。

有時候我們在匯入專案的時候發現匯入後沒有SDK，就是因為這裡面沒有我們匯入專案編譯時的SDK 包括android的平臺。包含在android.jar庫中。你必須指一個平臺為你的編譯目標。
project.properties裡面將target改為platforms裡面有的版本重新編譯即可。這裡面有SDK不同的版本，每個版本下面又有許多檔案組成。還有就是如果你再佈局中如果編寫沒有錯誤，但是檢視預覽不了，可能是由於你SDK選擇的版本有問題。

platform-tools

platform-tools：該資料夾下放了Android平臺的相關開發和除錯工具,比如adb.exe、sqlite3.exe等。platform-tools儲存著一些通用工具，比如adb、和aapt、aidl、dx等檔案

注意:這裡和platforms目錄中tools資料夾有些重複，主要是從android2.3開始這些工具被劃分為通用了。

sources

sources：這個資料夾下面存放的是Android的原始碼。

system-images

system-images：存放的是建立Android虛擬機器時的映象檔案(已經編譯好的映象檔案,模擬器可以直接載入)。從android-14開始將模擬器映象檔案整理在這裡(原來放在platforms下)

temp

temp : 臨時目錄

tools

tools：這個資料夾下存放了大量Android開發、除錯的工具。包括測試、除錯、第三方工具。模擬器、資料管理工具等。比如ddms用於啟動Android除錯工具，比如logcat、螢幕截圖和檔案管理器，而draw9patch則是繪製android平臺的可縮放png圖片的工具，而monkeyrunner則是一個不錯的壓力測試應用，模擬使用者隨機按鍵，mksdcard則是模擬器SD映像的建立工具，emulator是Android SDK模擬器主程式，不過從android 1.5開始，需要輸入合適的引數才能啟動模擬器，traceview作為android平臺上重要的除錯工具。

AVD Manager.exe

AVD Manager.exe：虛擬機器管理工具，用於建立和管理虛擬機器。

SDK Manager.exe

SDK Manager.exe：sdk管理工具，用於管理、下載sdk、sdk工具，能及擴充套件工具

samples

samples：是Android SDK自帶的預設示例工程，裡面的apidemos強烈推薦初學者執行學習，對於SQLite資料庫操作可以檢視NotePad這個例子，對於遊戲開發Snake、LunarLander都是不錯的例子，對於Android主題開發Home則是androidm5時代的主題設計原理。

licenses

market_licensing作為AndroidMarket版權保護元件，一般釋出付費應用到電子市場可以用它來反盜版。

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的主要檔案，其中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

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 表中可以方便地找到相應的連結。

例如，《Android 6.0 的變化》中談了 target 為 API 23 時會如何把你的應用轉換到執行時許可權模型上，《Android 4.4 的行為變化》闡述了 target 為 API 19 及以上時使用 set() 和 setRepeating() 設定 alarm 會有怎樣的行為變化。
由於某些行為的變化對使用者是非常明顯的（棄用的 menu 按鈕，執行時許可權等），所以將 target 更新為最新的 SDK 是所有應用都應該優先處理的事情。但這不意味著你一定要使用所有新引入的功能，也不意味著你可以不做任何測試就盲目地更新 targetSdkVersion ，請一定在更新 targetSdkVersion 之前做測試！你的使用者會感謝你的。

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 檔案，你會看到類似下面這樣的標籤：

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

如果你在 manifest 檔案中手工設定，你會發現 Gradle 在構建時會忽略它們（儘管其它構建系統可能會明確依賴它們）。

綜合來看

如果你按照上面示例那樣配置，你會發現這三個值的關係是：

minSdkVersion <= targetSdkVersion <= compileSdkVersion

這種直覺是合理的，如果 compileSdkVersion 是你的最大值，minSdkVersion 是最小值，那麼最大值必需至少和最小值一樣大且 target 必需在二者之間。
理想上，在穩定狀態下三者的關係應該更像這樣：

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

用較低的 minSdkVersion 來覆蓋最大的人群，用最新的 SDK 設定 target 和 compile 來獲得最好的外觀和行為。