很多在manifest中的屬性我們經常遺忘了它們，或者經常看到但又不是很明白它的作用。那么在這里我就拿了一些屬性簡單的解釋一下，防止以后碰到卻不知道其中的意思。不是很全，以后會斷斷續續的補充吧
一、android:installLocation="internalOnly"
android:installLocation隸屬於AndroidManifest.XML中的manifest節點.如下所示:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="string" android:sharedUserId="string" android:sharedUserLabel="string resource" android:versionCode="integer" android:versionName="string" android:installLocation=["auto" | "internalOnly" | "preferExternal"] > . . . </manifest>
android:installLocation可以設置為"auto"、"internalOnly"、"preferExternal"三個值中的任何一個.
auto:程序可能被安裝在外部存儲介質上(例如:SD Card),但是默認會被安裝到手機內存中.當手機內存為空時,程序將被安裝到外部存儲介質上.當程序安裝到手機上后,用戶可以決定把程序放在外部儲介質還是內存中.
internalOnly:默認值.當設置為該值時,程序只能被安裝在內存中,如果內存為空,則程序將不能成功安裝.
preferExternal:將程序安裝在外部存儲介質上,但是系統不保證程序一定會被安裝到外部存儲介質上.當外部存儲介質不可以或空時,程序將被安裝到內存中.程序使用了forward-locking機制時也將被安裝到內存中,因為外部存儲不支持此機制.程序安裝后,用戶可以自由切換程序應該在外部還是內部存儲介質上.
簡而言之，就是控制應用是安裝在外部存儲上還是內存中，安裝在內存中
①Service
正在運行的服務將被終止,當外部存儲介質被重新加載時服務不會被重啟.
②Alarm Service
鬧鍾服務將被取消,開發者必須在外部存儲介質重新加載后重新注冊鬧鍾服務.
③Input Method Engines
輸入法將被換成系統輸入法,當外部存儲介質被重新加載后用戶可以通過系統設置來啟動我們的輸入法
④Live Wallpapers
我們的動態壁紙將被替換為默認的動態壁紙.外部存儲介質重載后,用戶可以更換回來.
⑤Live Folders
我們的動態文件夾將被移出.
⑥App Widgets
我們的小部件將被移出,通常只有系統重啟后我們的小部件才可用.
⑦Account Managers
使用AccountManager創建的賬戶將會消失,直至存儲介質被重新加載.
⑧Sync Adapters
只有外部存儲介質被重新加載時,我們的同步功能才可用
⑨Device Administrators
我們的DeviceAdminReceiver將會失效
⑩監聽開機結束事件
系統會在加載外部存儲介質之前發送ACTION_BOOT_COMPLETED廣播.因此安裝在外部存儲介質的程序將不能接受開機廣播.
二、android:versionCode
Google為APK定義了兩個關於版本屬性：VersionCode和VersionName，他們有不同的用途。
- VersionCode：對消費者不可見，僅用於應用市場、程序內部識別版本，判斷新舊等用途。
- VersionName：展示給消費者，消費者會通過它認知自己安裝的版本，下文提到的版本號都是說這個
三、android:protectionLevel="signature"
normal：低風險權限，只要申請了就可以使用（在AndroidManifest.xml中添加<uses-permission>標簽），安裝時不需要用戶確認；
dangerous：高風險權限，安裝時需要用戶的確認才可使用；
signature：只有當申請權限的應用程序的數字簽名與聲明此權限的應用程序的數字簽名相同時（如果是申請系統權限，則需要與系統簽名相同），才能將權限授給它；
signatureOrSystem：簽名相同，或者申請權限的應用為系統應用（在system image中）。
上述四類權限級別同樣可用於自定義權限中。如果開發者需要對自己的應用程序（或部分應用）進行訪問控制，則可以通過在AndroidManifest.xml中添加<permission>標簽，將其屬性中的protectionLevel設置為上述四類級別中的某一種來實現。
A方：
<!-- 聲明權限 --> <permission android:name="com.example.testbutton.RECEIVE" /> <!-- 注冊Broadcast Receiver，並指定了給當前Receiver發送消息方需要的權限 --> <receiver android:name="com.example.testbutton.TestButtonReceiver" android:permission="com.example.testbutton.RECEIVE" > <intent-filter> <action android:name="com.test.action" /> </intent-filter> </receiver>
B方：
<!-- 聲明使用指定的權限 --> <uses-permission android:name="com.example.testbutton.RECEIVE" />
四、uses-feature
Android Market會根據uses-feature過濾所有你設備不支持的應用。通過使用<uses-feature>元素，一個應用可以指定它所 支持的硬件型號，舉個例子，有些設備不支持多點觸控或者OpenGL ES 2.0，那么過濾器就會過濾需要這些硬件支持（多點觸控或者OpenGL ES 2.0）的應用，用戶就不會在android market上看到這些應用。
android.hardware.touchscreen.multitouch：它要求設備有一個多點觸控的屏幕以支持基本的多點觸控交互，就如收縮（放大）圖像比例。這些類型的屏幕跟蹤多個手指的能力都有所不同，所以你必須確保這個屏幕的性能是能夠支持的游戲進行。
android.hardware.touchscreen.multitouch.distinct: 這是一個多點觸控的兄弟屬性，它要求提設備供完整的多點觸控功能。
現在只要記住在當你的游戲需要一個支持多點觸控的屏幕的時候，我們可以使用 <uses-feature>元素來剔除所有不支持多點觸控的設備，就像下面這樣：
<uses-feature android:name="android.hardware.touchscreen.multitouch" android:required="true"/>
另外一個在游戲開發中非常有用的是去指定需要的OpenGL ES版本。如果你的游戲需要更強大的圖形處理能力，我們可以指定OpenGL ES 2.0，然后我們的游戲只會被支持OpenGL ES 2.0的設備所看見。注意，在本書中不會使用OPenGL ES 2.0, 我們只是過濾那些不能提供足夠圖形處理能力的設備。下面顯示了我們怎么去實現它。
<uses-feature android:glEsVersion="0x00020000" required="true"/>
五、android:supportsRtl="true"
android4.2有一個新特性 layoutRtl，當然是對於開發者而言的，主要是方便開發者去支持阿拉伯語/波斯語等閱讀習慣是從右往左的。
可以在manifest的application標簽添加：android:supportsRtl 取值：true/false
這樣就可以打開layoutRtl這個功能。如果當前系統語言是阿拉伯語/波斯語，打開了這個功能的應用的布局就會自動變成從右往左的，當然前提是布局沒有寫死控件間的位置。
六、android:sharedUserId
Android給每個APK進程分配一個單獨的空間,manifest中的userid就是對 應一個分配的Linux用戶ID，並且為它創建一個沙箱，以防止影響其他應用程序（或者其他應用程序影響它）。用戶ID 在應用程序安裝到設備中時被分配，並且在這個設備中保持它的永久性。
通常，不同的APK會具有不同的userId，因此運行時屬於不同的進程中，而不同進程中的資源是不共享的，在保障了程序運行的穩定。然后在有些時候，我們自己開發了多個APK並且需要他們之間互相共享資源，那么就需要通過設置shareUserId來實現這一目的。
通過Shared User id,擁有同一個User id的多個APK可以配置成運行在同一個進程中.所以默認就是可以互相訪問任意數據. 也可以配置成運行成不同的進程, 同時可以訪問其他APK的數據目錄下的數據庫和文件.就像訪問本程序的數據一樣。
shareUserId設置：
在需要共享資源的項目的每個AndroidMainfest.xml中添加shareuserId的標簽。
android:sharedUserId="com.example"
id名自由設置，但必須保證每個項目都使用了相同的sharedUserId。一個mainfest只能有一個Shareuserid標簽。
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.shareusertesta" android:versionCode="1" android:versionName="1.0" android:sharedUserId="com.example">
\data\data\自定義的package\ 路徑下的互相訪問
每個安裝的程序都會根據自己的包名在手機文件系統的data\data\your package\建立一個文件夾（需要su權限才能看見），用於存儲程序相關的數據。
在代碼中，我們通過context操作一些IO資源時，相關文件都在此路徑的相應文件夾中。比如默認不設置外部路徑的文件、DB等等。
正常情況下，不同的apk無法互相訪問對應的app文件夾。但通過設置相同的shareUserId后，就可以互相訪問了。
如：A程序中
//默認建立在data/data/xxx/file/ fOut = openFileOutput("settings.dat", MODE_PRIVATE);
osw = new OutputStreamWriter(fOut); osw.write(data); osw.flush();
B程序中
//獲取程序A的context Context ctx = this.createPackageContext("com.example.shareusertesta",Context.CONTEXT_IGNORE_SECURITY); String msg = ReadSettings(ctxDealFile); Toast.makeText(this, "DealFile2 Settings read" + msg,Toast.LENGTH_SHORT).show(); WriteSettings(ctx, "deal file2 write");
兩個程序就能互相的訪問資源了。（當然前提是都設置了相同的shareUserId）
Resources和SharedPreferences的共享
通過shareuserId共享，我們可獲取到程序A的context。因此，我們就可以通過context來獲取程序A對應的各種資源。比較常用的就是Raw資源的獲取，如一些軟件的apk皮膚包就是采用了這種技術，將主程序和皮膚資源包分在兩個apk中。
獲 取Resources很簡單，在程序A和B的mainfest中設置好相同的shareuserId后，通過createPackageContext獲 取context即可。之后就和原來的方式一樣，通過getResources函數獲取各種資源，只是此時的context環境是目標APP的 context環境。
看見程序A和B之間的聯系有三個：
1 mainfest中聲明shareuserId時需要知道一個共同的userId
2 createpackageContext時需要知道目標APK的package的name
3 獲取資源時需要知道該資源的對應ID
七、android:settingsActivity
不知道怎么用的==，這是在一個源碼里看到
八、android:launchMode="singleTop" <Activity節點下>
Activity一共有以下四種launchMode：
1.standard 2.singleTop 3.singleTask 4.singleInstance
（1）standard：系統默認的標准型，每次跳轉系統都會在task中生成一個新的Activity實例，並且放於棧結構的頂部，當我們按下后退鍵時，才能看到原來的Activity實例。
這就是standard啟動模式，不管有沒有已存在的實例，都生成新的實例。跟普通的棧一樣，先進后出。
（2）single:它是在standard的標准下加了一個屬性。即當你要跳轉的activity是位於棧頂時，它不會再new一個新的實例出來。但如果是firstactivity和secondactivity交替跳轉，那跟普通的standard模式一樣。
（3）singleTask。它的原理是保證這個activity實例生成后是不會再生成新的實例。比如說兩個activity,first和second。First設為singleTask，然后跳轉到second，再返回first時，first不會生成實例，而是從棧中取出first放在棧頂。還有一點比較重要的一點是，在first上的activity會全部移除出棧，不管你這個activitys是不是也是singleTask模式，一律移除。
（4）singleInstance。這個就比較特殊了，不過也比較簡單。就是新開一個task棧專門放這個activity,而其它activity不讓它進去。
九、android:taskAffinity
每 個Activity都有taskAffinity屬性，這個屬性指出了它希望進入的Task。如果一個Activity沒有顯式的指明該 Activity的taskAffinity，那么它的這個屬性就等於Application指明的taskAffinity，如果 Application也沒有指明，那么該taskAffinity的值就等於包名。而Task也有自己的affinity屬性，它的值等於它的根 Activity的taskAffinity的值。 一開始，創建的Activity都會在創建它的Task中，並且大部分都在這里度過了它的整個生命。
allowTaskReparenting用來標記Activity能否從啟動的Task移動到taskAffinity指定的Task，默認是繼承至 application中的allowTaskReparenting=false，如果為true，則表示可以更換；false表示不可以。
這兩個屬性通常是放在一起用的。
簡而言之，用了taskAffinity的activity實例化的時候會先看看有沒有與taskAffinity相同的task,如果有，則會跑到那邊的task中,並實例化。
十、android:configChanges
對android:configChanges屬性，一般認為有以下幾點：
1、不設置Activity的android:configChanges時，切屏會重新調用各個生命周期，切橫屏時會執行一次，切豎屏時會執行兩次
2、設置Activity的android:configChanges="orientation"時，切屏還是會重新調用各個生命周期，切橫、豎屏時只會執行一次
3、設置Activity的android:configChanges="orientation|keyboardHidden"時，切屏不會重新調用各個生命周期，只會執行onConfigurationChanged方法
但是，自從Android 3.2（API 13），在設置Activity的android:configChanges="orientation|keyboardHidden"后，還是一樣 會重新調用各個生命周期的。因為screen size也開始跟着設備的橫豎切換而改變。所以，在AndroidManifest.xml里設置的MiniSdkVersion和 TargetSdkVersion屬性大於等於13的情況下，如果你想阻止程序在運行時重新加載Activity，除了設置"orientation"， 你還必須設置"ScreenSize"。
http://www.cnblogs.com/adamzuocy/archive/2009/10/15/1583670.html
十一、android:exported
這個屬性用於指示該服務是否能夠被其他應用程序組件調用或跟它交互。如果設置為true，則能夠被調用或交互，否則不能。設置為false時，只有同一個應用程序的組件或帶有相同用戶ID的應用程序才能啟動或綁定該服務。它的默認值依賴與該服務所包含的過濾器。沒有過濾器則意味着該服務只能通過指定明確的類名來調用，這樣就是說該服務只能在應用程序的內部使用（因為其他外 部使用者不會知道該服務的類名），因此這種情況下，這個屬性的默認值是false。另一方面，如果至少包含了一個過濾器，則意味着該服務可以給外部的其他 應用提供服務，因此默認值是true。
這個屬性不是限制把服務暴露給其他應用程序的唯一方法。還可以使用權限來限制能夠跟該服務交互的外部實體。
十二、android:immersive
貌似是全屏的設置，可以用來隱藏標題欄和菜單欄。可以通過代碼來實現不同的UI響應事件
十三、android:excludeFromRecents
控制在不在recent列表中顯示，就是使用該activity時app不會出現在最近使用app列表中
========================================
作者：cpacm
出處：（http://www.cnblogs.com/cpacm/p/4083443.html）