關於那些Android中不經常使用的設置屬性

時間 2019-12-08

原文原文鏈接

不少在manifest中的屬性咱們常常遺忘了它們，或者常常看到但又不是很明白它的做用。那麼在這裏我就拿了一些屬性簡單的解釋一下，防止之後碰到殊不知道其中的意思。不是很全，之後會斷斷續續的補充吧html

1、android:installLocation="internalOnly"
android:installLocation隸屬於AndroidManifest.XML中的manifest節點.以下所示:android

<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),可是默認會被安裝到手機內存中.當手機內存爲空時,程序將被安裝到外部存儲介質上.當程序安裝到手機上後,用戶能夠決定把程序放在外部儲介質仍是內存中.app

internalOnly:默認值.當設置爲該值時,程序只能被安裝在內存中,若是內存爲空,則程序將不能成功安裝.函數

preferExternal:將程序安裝在外部存儲介質上,可是系統不保證程序必定會被安裝到外部存儲介質上.當外部存儲介質不能夠或空時,程序將被安裝到內存中.程序使用了forward-locking機制時也將被安裝到內存中,由於外部存儲不支持此機制.程序安裝後,用戶能夠自由切換程序應該在外部仍是內部存儲介質上.佈局

簡而言之，就是控制應用是安裝在外部存儲上仍是內存中，安裝在內存中
①Service性能

　　　　正在運行的服務將被終止,當外部存儲介質被從新加載時服務不會被重啓.ui

　　②Alarm Servicethis

　　　　鬧鐘服務將被取消,開發者必須在外部存儲介質從新加載後從新註冊鬧鐘服務.spa

　　③Input Method Engines

　　　　輸入法將被換成系統輸入法,當外部存儲介質被從新加載後用戶能夠經過系統設置來啓動咱們的輸入法

　　④Live Wallpapers

　　　　咱們的動態壁紙將被替換爲默認的動態壁紙.外部存儲介質重載後,用戶能夠更換回來.

　　⑤Live Folders

　　　　咱們的動態文件夾將被移出.

　　⑥App Widgets

　　　　咱們的小部件將被移出,一般只有系統重啓後咱們的小部件纔可用.

　　⑦Account Managers

　　　　使用AccountManager建立的帳戶將會消失,直至存儲介質被從新加載.

　　⑧Sync Adapters

　　　　只有外部存儲介質被從新加載時,咱們的同步功能纔可用

　　⑨Device Administrators

　　　　咱們的DeviceAdminReceiver將會失效

　　⑩監聽開機結束事件

　　　　系統會在加載外部存儲介質以前發送ACTION_BOOT_COMPLETED廣播.所以安裝在外部存儲介質的程序將不能接受開機廣播.

2、android:versionCode

Google爲APK定義了兩個關於版本屬性：VersionCode和VersionName，他們有不一樣的用途。

VersionCode：對消費者不可見，僅用於應用市場、程序內部識別版本，判斷新舊等用途。
VersionName：展現給消費者，消費者會經過它認知本身安裝的版本，下文提到的版本號都是說這個

3、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" />

4、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"/>

5、android:supportsRtl="true"

android4.2有一個新特性 layoutRtl，固然是對於開發者而言的，主要是方便開發者去支持阿拉伯語/波斯語等閱讀習慣是從右往左的。

能夠在manifest的application標籤添加：android:supportsRtl 取值：true/false

這樣就能夠打開layoutRtl這個功能。若是當前系統語言是阿拉伯語/波斯語，打開了這個功能的應用的佈局就會自動變成從右往左的，固然前提是佈局沒有寫死控件間的位置。

6、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標籤。

\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

7、android:settingsActivity

不知道怎麼用的==，這是在一個源碼裏看到

8、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不讓它進去。

9、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中,並實例化。

10、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

11、android:exported
這個屬性用於指示該服務是否可以被其餘應用程序組件調用或跟它交互。若是設置爲true，則可以被調用或交互，不然不能。設置爲false時，只有同一個應用程序的組件或帶有相同用戶ID的應用程序才能啓動或綁定該服務。它的默認值依賴與該服務所包含的過濾器。沒有過濾器則意味着該服務只能經過指定明確的類名來調用，這樣就是說該服務只能在應用程序的內部使用（由於其餘外部使用者不會知道該服務的類名），所以這種狀況下，這個屬性的默認值是false。另外一方面，若是至少包含了一個過濾器，則意味着該服務能夠給外部的其餘應用提供服務，所以默認值是true。
這個屬性不是限制把服務暴露給其餘應用程序的惟一方法。還可使用權限來限制可以跟該服務交互的外部實體。

12、android:immersive

貌似是全屏的設置，能夠用來隱藏標題欄和菜單欄。能夠經過代碼來實現不一樣的UI響應事件

十3、android:excludeFromRecents

控制在不在recent列表中顯示，就是使用該activity時app不會出如今最近使用app列表中

========================================

做者：cpacm
出處：（http://www.cnblogs.com/cpacm/p/4083443.html）