—————————————————————————————————————————————————————————————————————————————
在Android系統啟動一個應用程序的部件之前，系統必須通過閱讀該應用程序的AndroidManifes.xml文件來確定該部件是存在的。應用程序必須在該文件中聲明其所有的部件。該文件位於應用程序工程目錄的根目錄下。
除瞭聲明應用程序的部件之外，該文件中還有其它的信息：
標明瞭應用程序所需的用戶許可，比如訪問或者是讀取用戶的通訊錄。
聲明瞭應用程序所需的最小API的級別。
聲明瞭應用程序所需的硬件和軟件特性，比如攝像頭，藍牙，服務，或者是多點觸控屏幕。
應用程序所需的瞭出Android框架提供的API之外的其它API庫。比如 Google Maps library(谷歌地圖庫)
其它一些信息
聲明部件
manifest文件的首要任務就是告訴系統應用程序有哪些部件。例如，manifest文件中可以聲明如下的活動：
[html]
<?xml version="1.0" encoding="utf-8"?>
<manifest … >
<application android:icon="@drawable/app_icon.png" … >
<activity android:name="com.example.project.ExampleActivity"
android:label="@string/example_label" … >
</activity>
…
</application>
</manifest>
在<application>元素中，屬性android:icon指明瞭應用程序的圖標。
在<activity>元素中，屬性android:name闡明瞭Activity派生類的全名；屬性android:label闡明瞭該活動的可見的標簽字符串。
所有的應用程序部件都必須以如下的方式進行聲明：
<activity> 元素用來聲明活動
<service> 元素用來聲明服務
<receiver> 元素用來聲明廣播接收器
<provider> 元素用來聲明內容提供者
在代碼中的活動，服務以及內容提供者如果沒有在manifest文件中進行聲明，則它們對於系統來說就是不可見的，因此也是不會運行的。然而，廣播接收器是既可以在manifest文件中進行聲明，又可以在代碼中動態創建的（作為BraodcastReceive對象），並通過registerReceiver()向系統註冊的。
更多關於應用程序中manifest文件結構的信息，請參閱文檔：AndroidManifest.xml 文件。
聲明部件的能力
正如我們在前面討論的那樣，在“激活部件”小節中，我們說到可以使用Intent來啟動活動，服務和廣播接收器。我們可以通過在Intent中明確指定目標部件的名稱（使用部件類的名稱）來達到啟動部件的目的。然而，intents的真正能力在於intent action。使用intent action，我們隻要描述期望王城的動作（action），而讓系統來查找設備上可以完成該動作的部件並啟動之。如果在設備上存在多個可以完成指定intent中動作（action）的部件，那就由用戶來選擇使用哪個部件。
系統判斷部件是否能響應intent的方式就是把接收到的intent和設備上的其它程序的manifest文件中提供的intent filters（意圖過濾器）進行比較。
當我們在應用程序的manifest文件中聲明部件的時候，我們可以選擇性的聲明部件能力，以便部件可以對其它應用程序的intents做出響應。為應用程序聲明意圖過濾器是通過在部件聲明中增加<intent-filter>子元素來完成的。
例如，就電子郵件程序來說，在其manifest文件中，有聲明用於編輯郵件的活動，可以通過其子項來聲明一個intent filter，以便響應“發送（send）”意圖，也就是發送電子郵件。這樣，我們的程序就可以創建一個帶有動作為“send”的intent，而系統則會將電子郵件程序和send活動相匹配上，從而在我們調用startActivity()並傳入該intent的時候啟動電子郵件程序。
更多關於創建intent filter的信息，請參閱Intents and Intent Filters 文檔。
聲明應用程序的要求
搭載Android系統的設備數量眾多，並不是全部的Android設備都能提供相同的特性和擁有相同的能力。為瞭避免應用程序被安裝在缺少該應用程序所需特性的設備上，明確地定義應用程序所支持的設備類型的檔案文件就顯得十分重要。這點就是通過在manifest文件中聲明設備和軟件要求來完成的。這種聲明在大多數情況下隻是提供瞭一種信息，而系統並不會去閱讀這些信心，但是一些諸如Google Play的外部的服務確實會讀取這些信息，以便在用戶查找設備上的應用程序的時候提供過濾功能。
例如，如果我們的應用程序要求設備擁有攝像頭，並且使用的是Android 2.1版本的API，那麼我們就應該在manifest文件中對此要求進行聲明。這樣，Google Play 就不會在不滿足這些要求的設備上安裝我們的應用程序。
然而，我們可以聲明應用程序會使用攝像頭，但是這不是必須的。此時，應用程序必須在運行時進行檢查，判斷設備是否有攝像頭，以便決定是否需要顯示使用攝像頭的那些程序特性。
以下是一些重要的設備特征，我們應該在設計和開發應用程序把這些設備特征都考慮進去：
屏幕大小和密度
為瞭能夠根據屏幕大小來對設備進行分類，Android為每個設備都定義瞭兩種特征：屏幕大小（也就是屏幕的物理尺寸）和屏幕密度（屏幕上像素的密度，或者是dpi，即每英寸上的點數）。為瞭簡化針對不同類型屏幕的配置，Android系統將不同類型的屏幕泛化為不同的組，以方便適配。
屏幕的大小劃分為：小，一般，大，特大。
屏幕目的劃分為：低密度，中等密度，高密度和特高密度。
缺省情況下，應用程序是和所有大小和密度的屏幕保持兼容的，這是因為Android系統對軟件的UI佈局和圖像資源都進行瞭適當的調整。然而，在manifest文件中可以使用 <supports-screens> 元素來為某個指定大小的屏幕創建特殊的佈局和為某個指定密度的屏幕提供特定的圖像，也就是針對性地使用另外的佈局。
更多信息，請參閱 Supporting Multiple Screens 文檔。
輸入配置
眾多的Android設備提供瞭多種的輸入方式。如物理鍵盤，軌跡球或者是五向導航板。如果我們的應用程序需要某種特定的輸入硬件，那麼我們應該在manifest文件中使用 <uses-configuration> 元素來對其進行聲明。然而，應用程序需要特定的輸入配置的情況是很少見的。
設備特性
對於某個指定的Android設備，可能有多個硬件或者軟件特性在該設備上是沒有的，比如攝像頭，光感應器，藍牙或者是某個指定版本的OpenGL，或者是指定叫你精度觸控屏。我們不應該認為某個特性在所有的Android設備上都是存在的，因此我們應該在manifest文件中使用<user-feature>元素來聲明應用程序所需的特性。
平臺版本
不同的Android設備通常都是運行的不同版本的Android平臺，比如，Android 1.6 或者是Android 2.3。每一個後續的版本中都含有之前版本中不曾含有的API。為瞭標明那個版本的API可能，每個平臺版本中都標明瞭API級別。如果我們使用瞭任何在版本1.0之後增加的API，那麼我們就應該使用<users-sdk>元素對引入聲明引入瞭這些API的最小的API級別。
很重要的一點是：這些要求的聲明都是為瞭我們自己的應用程序。這是因為當我們在Google Play上發佈我們的應用程序時，應用商店使用這些聲明來就每個設備對應用程序進行過濾。這樣，我們的應用程序就隻能在那些滿足其要求的設備上才是可用的。
更多關於Google Play是如何基於這些要求來過濾應用程序的信息，請參閱Filters on Google Play 文檔。
