Android Manifest.xml檔案的結構及作用

林堯彬發表於2020-04-04

原文連結:http://android.eoe.cn/topic/android_sdk

 

每一個應用程式在工程的根目錄下必須要有一個AndroidManifest.xml檔案(一定要用這個名稱)。這個清單檔案向安卓系統提供關於該應用的重要資訊,這些資訊在它執行任何應用程式碼之前是必須要有的。除了其他方面,清單檔案執行以下操作:
:* 它列出了應用程式的包名。這個包名充當這個應用程式的唯一的識別符號。
:* 它描述了這個應用程式的元件 :活動、服務、廣播接收者和內容提供者。它列舉了每一個元件的級別和這些元件所具有的能力(例如,它們能操作哪一類意圖)。這些宣告讓安卓系統知道這些元件具體是哪個及在什麼樣的條件下它們能被啟動。

:* 它決定了哪個程式將會使用這些應用元件。
:* 它宣告瞭應用程式一定要有的許可權,如果打算訪問API受保護的部分或者與其他程式進行互動。
:* 它也宣告瞭其他應用程式需要訪問這個應用程式元件的許可權。
:* 它列出了Instrumentation類,這個類提供了程式執行時候的效能分析和其他資訊。這些宣告要存在於清單中,僅當這個應用程式正在被開發和測試,在釋出應用程式之前應該將它們移除掉。
:* 它宣告瞭這個應用程式的最小的Android API級別。
:* 它列出了這個應用程式一定會被連結到的庫。

清單檔案的結構

:下圖展示了清單的通用結構和它能包含的每一元素。每一元素與它們的屬性一起被記錄在一個單獨的檔案中。為了觀察到每一元素的詳細資訊,點選圖中每一元素的名字,跟隨下圖中的字母列表元素,或者其他任何提及到的元素名。

<?xml version"utf-8"?>









 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<application>

    <activity>
        <intent-filter>
            <action />
            <category />
            <data />
        </intent-filter>
        <meta-data />
    </activity>

    <activity-alias>
        <intent-filter> . . . </intent-filter>
        <meta-data />
    </activity-alias>

    <service>
        <intent-filter> . . . </intent-filter>
        <meta-data/>
    </service>

    <receiver>
        <intent-filter> . . . </intent-filter>
        <meta-data />
    </receiver>

    <provider>
        <grant-uri-permission />
        <meta-data />
    </provider>

    <uses-library />

</application>

:所有這些元素可能出現在清單檔案的,按照字母順序全被列出在下面。這些是唯一合法的元素,你不能新增你自己元素或屬性。

:[http://docs.eoeandroid.com/guide/topics/manifest/permission-tree-element.html]
:
:

檔案約定

清單中普遍適用於所有的元素和屬性的一些約定和規則。

  • 元素* :在所有的元素中,只有和元素是必需的。它們一定要在清單檔案中存在且只能出現一次。其他大多數可以出現多次或者不出現-儘管它們至少有一些一定要在清單中存在來完成一些有意義的事。

:如果一個元素包含任何東西,它當然也能包含其他元素。所有的值都是通過設定屬性,而不是僅將字元資料放在一個元素中。

:同一等級的元素通常都是無序的。例如、 和元素能以任意順序混雜在一起。(元素是這一規則的一個特例:它必須跟在該別名所指的之後。)

  • 屬性* :從正式的意義上來說,所有的屬性都是可選擇的。然而,有些屬性必須為元素指定其要完成的目標。把這篇文件作為指南。對於真正可選的屬性,即使沒指定它會發生什麼,也會有一個預設的值或者狀態。

:除了元素中的一些屬性,所有的屬性名字都是以android:作為字首。例如android:alwaysRetainTaskState.因為這個字首是通用的,當提及到屬性名時,這篇文件通常省略它。

  • 宣告類名* :許多對應於java物件的元素,包括應用程式的元素本身(元素)和它的重要元件——活動(),服務(),廣播接收者()和內容提供者().

:如果你定義一個子類,跟元件類(Activity,Service,BroadcastReceiver,和ContentProvider)一樣,這個子類通過一個name的屬性來宣告。這個名字必須包含完整的包名。例如,一個Service子類可能會被像下面宣告:




:然而,為了簡寫,如果字串的第一個字元是一個點號“.”,這個字串被附加到這個應用程式的包名上(例如通過元素的package屬性指定)。下面的寫法跟上面一個一樣的.



:當啟動一個元件時,安卓會建立這個被命令的子類的例項。如果沒有指定子類,它會建立一個基類的例項。

  • 多重值* :如果要指定元素的不只一個值,這個元素總是被重複宣告。而不是在單一的元素屬性中列出多個值。例如:一個意圖濾波器會列出多個動作。 . . .
  • 資源值* :一些屬性有一些可以展示給使用者看的值-----例如,活動的一個標籤和圖示。這些屬性的值應該被本地化的,從一個資源或主題設定。資源值的表現形式如下:

::@[package:]type:name

:如果資源在同一個應用的同一個包中,包名可以被省略。type是資源的型別----例如"string"或者"drawable"。name是用來標識特定資源名。例如:



:一個主題的值的也是以一個類似的方式來表示,但是是以?開頭而不是以@。

::?[package:]type:name

  • 字串值* :當一個屬性值是字串時,一定要用兩個反斜槓('\')表示''這個轉義字元。例如:"\n"表示換行或"\uxxxx"表示Unicode字元。

* 檔案特性*

以下幾段描述一些安卓特性是如何反映在清單檔案上。

意圖濾波器

應用程式的核心元件(活動,服務,廣播接收者)通過Intents被啟用。一個意圖是一捆的資訊(一個Intent物件),這些資訊描述了一個請求動作——包括有用的資料,用來執行動作的元件的類別,和其他相關的指令。安卓找到一個合適的元件來響應這個意圖,啟動一個新的元件例項,如果需要的話,並傳遞這個意圖物件。

元件公佈它們的能力--各種各樣的它們能響應的意圖--通過意圖濾波器。由於安卓系統在啟動一個元件之前必須瞭解這個元件能操作哪種意圖,意圖濾波器要在清單中的中被指定。一個元件可能有許多濾波器,每一個都描述一種不同的能力。

一個意圖顯式的命名一個目標元件將會啟用那個元件;這時濾波器不扮演任何角色。(濾波器無效)。
但是一個意圖不指明目標時,只有通過一個元件的濾波器時,才能啟用這個元件。

關於一個意圖物件怎樣通過意圖濾波器的測試,檢視單獨的文件:Intents and Intent Filters

圖示和標籤

許多元素都有icon和label屬性,這些屬性是為了向使用者展示一個小的圖示或者一個文字標籤。一些也有一個description 屬性,這個屬性是為了在螢幕上能顯示一些長的說明文字。例如元素有這三個屬性,所以當使用者被問及請求的應用程式是否授權,一個表示許可權的圖示,許可權的名稱,和一個描述它的細節都會被呈現給使用者。

在任何情況下,設定在一個包含元素裡的圖示和標籤會成為該容器所有子元素的預設設定。因此元素裡的圖示和標籤是每一個應用程式元件的預設圖示和標籤。同樣地,為一個元件設定的圖示和標籤——例如元素——是這個元件的元素的預設設定。如果一個元素設定一個標籤,但是一個活動和它的意圖濾波器沒有設定,這個應用程式的標籤被當作是這個活動和意圖濾波器的標籤。

這個意圖濾波器的圖示和標籤集被用來表示一個元件,無論何時這個元件通過一個濾波器來為使用者實現這個功能。例如,一個帶有"android.intent.action.MAIM"和"android.intent.category.LAUNCHER"設定的活動將會啟動一個應用----那就是,作為一個應該在啟動欄中被顯示的應用。濾波器中的這個圖示和標籤集因此也會在啟動欄中被顯示。

許可權

許可權是一種約束。限制對部分程式碼或者裝置的資料的訪問。這種限制用於保護關鍵資料和程式碼,這些東西有可能會被濫用
進而扭曲和損害使用者的體驗。

每一個許可權被唯一的標籤所標識。通常標籤宣告約束的動作。例如,這裡有一些安卓系統定義的許可權:
:android.permission.CALL_EMERGENCY_NUMBERS
:android.permission.READ_OWNER_DATA
:android.permission.SET_WALLPAPER
:android.permission.DEVICE_POWER

一個特性可以被至多一個許可權所保護。

如果一個應用程式需要訪問一個受保護的特性,它必須在清單中用元素宣告,以表明它需要這個許可權。這樣,當這個程式被安裝到裝置上時,安裝器決定是否授予請求的許可權,通過檢測相關許可權,這些許可權被應用程式的認證照所證明。在一些情況下,會詢問使用者。如果許可權被授予,這個應用程式將有能力去訪問這些受保護的特性。否則,它將嘗試去訪問那些特性,將會失敗用不會給使用者任何通知。

應用程式也能用許可權來保護它自己的元件(活動,服務,廣播接收者和內容提供者)。它可以使用安卓所定義的任何許可權(在android.Manifest.permission列出來了)或者通過其他應用來宣告。或者自己定義。一個新的許可權通過元素來宣告。例如,一個活動可以用下面方式保護:



注意,在這個例子中,DEBIT_ACCT許可權不僅僅被元素宣告,它還需要在元素中宣告。為了應用程式的其他元件可以啟動這個受保護的活動,必須請求它的許可權,即使這個保護是應用程式自己引入的。

同一個例子中,如果permission屬性已經在別處宣告瞭(例如android.permission.CALL_EMERGENCY_NUMBERS),那麼不必再次在元素中宣告它。但還要在來宣告。

元素為將被定義在程式碼中的一組許可權宣告一個命令空間。
宣告為一組許可權(用宣告的那些或者在別處宣告的那些)定義一個標籤。它隻影響許可權怎樣分組,當展示給使用者的時候元素並不指定哪個許可權屬於這一組;它僅僅給這個組一個名字。一個許可權要被放入這一組中,是通過分配這一組的名字給元素的permissionGroup屬性。

每一個應用程式被連結到預設的安卓庫,這個庫包含建立應用程式的基本包(有公共類如:活動,服務,意圖,檢視,按鈕,應用,內容提供者等等)。

然而,一些包擁有它自己的庫。如果你的應用程式使用這些包中的程式碼,則必須顯式地宣告來連結它們。這時清單一定要包含一個獨立的元素來標記每一個庫(這個庫名能在包中的檔案中找到。)

轉載於:https://www.cnblogs.com/vus520/p/3158748.html

相關文章