Кожна програма повинна містити файл AndoidManifest.xml (саме з таким ім'ям) у її кореневій директорії проекту. Даний файл представляє важливу інформацію про вашу програму для системи Android, яку вона повинна мати перед тим, як запустити код програми на виконання. Разом з іншими складовими, маніфест файл виконує наступні ролі:
- Називає Java-пакунок програми. Ім'я пакету відіграє роль унікального ідентифікатора для програми.
- Описує компоненти програми — дії (activities), сервіси, отримувачі повідомлень, і постачальники контенту, з яких складається програма. Файл вказує на імена класів, які реалізовують кожен з компонентів і публікує їхні можливості (наприклад, повідомлення намірів (Intent), які програма може обробити). Ці оголошення дозволяють системі Android дізнатись, які компоненти існують у програмі і за яких умов вони можуть бути запущеними.
- Визначає які процеси будуть утримувати компоненти програми.
- Оголошує які дозволи програма повинна мати, щоб мати можливість отримати доступ до захищених частин API і взаємодіяти з іншими програмами.
- Вона також оголошує права, які повинні мати інші програми, щоб взаємодіяти з її компонентами.
- Утримує список класів Instrumentation, які забезпечують профілювання і іншу інформацію під час виконання програми. Дані оголошення присутні у маніфесті тільки під час розробки і тестування програми — вони видаляються з програми, яка публікується.
-
Визначає мінімальний рівень інтерфейсу Android API, який необхідний для роботи програми.
Вміщує список бібліотек, з якими програма повинна зв'язуватись під час виконання.
Структура маніфест файлу Android
Нижченаведена діаграма показує загальну структуру маніфест файлу і кожного елементу, який він може містити.
<?xml version="1.0" encoding="utf-8"?>
<manifest>
<uses-permission />
<permission />
<permission-tree />
<permission-group />
<instrumentation />
<uses-sdk />
<uses-configuration />
<uses-feature />
<supports-screens />
<compatible-screens />
<supports-gl-texture />
<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 />
<path-permission />
</provider>
<uses-library />
</application>
</manifest>
Усі дозволені елементи, які можуть бути присутніми в маніфест файлі перелічені нижче в алфавітному порядку. Це єдині елементи які можуть вказуватись в маніфесті — ви не можете додавати свої елементи чи атрибути.
<action>
<activity>
<activity-alias>
<application>
<category>
<data>
<grant-uri-permission>
<instrumentation>
<intent-filter>
<manifest>
<meta-data>
<permission>
<permission-group>
<permission-tree>
<provider>
<receiver>
<service>
<supports-screens>
<uses-configuration>
<uses-feature>
<uses-library>
<uses-permission>
<uses-sdk>
Умовні позначення маніфест файлу
Деякі правила і позначення застосовуються до усіх елементів і атрибутів у маніфесті:
Елементи. Вимагається тільки присутність елементів <manifest> і <application>, кожен з них повинен бути вказаним у маніфесті і можу вказуватись тільки один раз. Більшість інших може з'являтися в маніфесті багато разів або взагалі в ньому не бути. Якщо елемент містить будь-що взагалі, він містить інші елементи. Усі значення встановлюються через атрибути, а не символьні дані всередині елементу. Елементи на одному рівні зазвичай не впорядковані. Наприклад, елементи <activity>, <provider> i <service> можуть бути перемішані у будь-якому порядку. (Елемент <activity-alias> являється виключенням з цього правила — він повинен бути наступним після елементу <activity>, до якого він оголошує псевдонім).
Атрибути. Формально усі атрибути являються необов'язковими. Однак, існують деякі, що повинні бути вказаними в елементах для виконання їхньої ролі. Використовуйте документацію як джерело інформації про такі нюанси. Для справжніх необов'язкових атрибутів, вказуються їхнє значення за умовчанням, або вказується що трапляється при їхній відсутності. На відміну від деяких атрибутів кореневого елементу <manifest>, усі інші починаються з префіксу android: — наприклад, android:alwaysRetainTaskState. Через те що префікс являється універсальним, документація в загальному пропускає його, коли вказується атрибут по імені.
Оголошення імен класів. Велика кількість елементів відповідають об'єктам Java, включаючи елементів для самої програми (елемент <application>) і головних компонентів — дій (<activity>), сервісів (<service>), отримувачів повідомлень (<receiver>) і постачальників контенту (<provider>).
Якщо ви оголошуєте потомок, що ви майже завжди будете робити для класів компонентів (Activity, Service, BroadcastReceiver i ContentProvider), потомок оголошується через атрибут name. Даний атрибут повинен містити повний шлях крізь пакети програми. Наприклад, потомок класу Service може бути оголошений наступним чином:
<manifest . . . >
<application . . . >
<service android:name="com.example.project.SecretService" . . . >
. . .
</service>
. . .
</application>
</manifest>
Однак, якщо перший символ рядка являється крапкою, рядок додається до імені пакету програми (який вказаний у атрибуті package елементу <manifest>). Наступне оголошення є аналогічне наведеному вище:
<manifest package="com.example.project" . . . >
<application . . . >
<service android:name=".SecretService" . . . >
. . .
</service>
. . .
</application>
</manifest>
Під час запуску компонента, Android створює примірник іменованого потомка класу. Якщо клас не вказано, він створює примірник базового класу.
Множинні значення. Якщо більш ніж одне значення може бути вказаним для елементу, елемент майже завжди повторно вказується з іншим значенням. Наприклад, фільтр намірів може мати декілька правил:
<intent-filter . . . >
<action android:name="android.intent.action.EDIT" />
<action android:name="android.intent.action.INSERT" />
<action android:name="android.intent.action.DELETE" />
. . .
</intent-filter>
Значення ресурсів. Деякі атрибути мають значення, які можуть бути відображеними для користувачів — наприклад, мітка і іконка для дії. Значення цих атрибутів повинні бути локалізовані і після цього встановленими з ресурсу або теми. Значення ресурсів відображаються у наступному форматі:
@[пакет:]тип/ім'я
Де “пакет” може бути опущеним, якщо ресурс знаходиться у тому самому пакеті, що й програма, “тип” являється типом ресурсу — на подобі “string” або “drawable” і “ім'я” являється ім'ям, яке ідентифікує даний ресурс. Наприклад:
Значення з теми виражені подібним шляхом, але за допомогою символу “?”:
?[пакет:]тип/ім'я
Рядкові значення. Якщо значення атрибуту являється рядком символів, необхідно, щоб спеціальним системним символам передували два символи похилих ліній (backslash) - “\\”, наприклад, для символу нового рядка “\\n” або “\\uxxxx” для символу Юнікод.
Особливості файлу
Фільтри намірів
Компоненти ядра програми (її дії, сервіси і отримувачі повідомлень) активізуються за допомогою намірів. Намір являється пакетом інформації (об'єкт класу Intent), який описує необхідну дію — включаючи дані, категорію компоненту, який повинен виконати дію, і інші інструкції. Android знаходить відповідні компоненти для відповіді на намір, запускає новий примірник компоненту, якщо потрібно, і передає йому даний примірник класу Intent.
Компоненти оповіщають про свої можливості — типи намірів, на які вони можуть відповісти через фільтри намірів. Оскільки система Android повинна знати, які наміри компонент може обробити перед тим як його запустити, фільтри намірів вказуються у маніфест-файлі в якості елементів <intent-filters>. Компонент може мати будь-яку кількість фільтрів, кожен з яких описує іншу можливість.
Наміри які явно вказують цільовий компонент активізують цей компонент. Але намір, який не вказує ім'я цільового компоненту — можуть активувати компонент тільки якщо вони можуть пройти через один з його фільтрів.
Іконки і рядкові мітки
Деякі елементи мають атрибути icon i label для малих іконок і текстових міток, які можуть бути відображеними для користувачів. Деякі також мають атрибут description для довшого тексту опису, який також може бути відображеним на екран. Наприклад, елемент <permission> має усі ці три атрибути, отож коли користувач опитується чи надавати права для програми, яка потребує їх, іконка представляє права, ім'я права доступу, і опис того, які наслідки можуть виявитись для користувача.
Для кожного випадку встановлення іконки і мітки для елементу, вони стають стандартними налаштуваннями для усіх піделементів контейнеру. Тобто, іконка і мітка встановлені у елементі <applocation> являються стандартними іконкою і міткою для кожного компоненту програми. Подібно, встановлені іконка і мітка встановлені для компоненту, наприклад, для елементу являються стандартними налаштуваннями для кожного дочірнього елементу <intent-filter>. Якщо елемент <application> встановлює мітку, але дія і її фільтр намірів не мають таких налаштувань, мітка програми трактується як міткою для дії і для фільтрів намірів.
Іконка і текстова мітка, встановлена для фільтрів намірів використовуються для представлення компонентів, там де він представляє для користувача пропоновану фільтром функцію. Наприклад, фільтр з встановленим значенням у "android.intent.action.MAIN" і "android.intent.category.LAUNCHER", афішує дію, яка ініціює програму, тобто як така, яка повинна бути відображеною у списку програм системи. Іконка і текстова мітка встановлені у фільтрі також відображаються у списку програм системи.
Дозволи
Дозвіл являється обмеженням, яке регулює доступ до частин коду або до даних пристрою. Обмеження накладені для захисту даних і коду, які можуть бути помилково використані і призвести до негативного досвіду користувача.
Кожний дозвіл має свій унікальний ідентифікатор у вигляді текстової мітки. Часто мітка показує дію, яка є недоступною. Наприклад, ось деякі дозволи з імен, які визначені у Android:
android.permission.CALL_EMERGENCY_NUMBERS
android.permission.READ_OWNER_DATA
android.permission.SET_WALLPAPER
android.permission.DEVICE_POWER
Функція може бути захищеною одним дозволом.
Якщо програма потребує дозвіл для захищеної функції, вона повинна оголосити цю вимогу у елементі <uses-prermission> у маніфест-файлі. Тоді, коли програма встановлена на пристрої, інсталятор визначає чи надавати необхідні права програмі, перевіряючи власників, які підписали сертифікати програми, і у деяких випадках, опитуванням користувача. Якщо права доступу надані, програмі дозволено використовувати захищені функції. Якщо ні, її спроби отримати доступ до цих функцій просто закінчаться провалом без будь-яких сповіщень користувачу.
Програма може також захистити свої компоненти за допомогою прав доступу. Вона може використовувати будь-які права доступу, які визначені у Android або оголошені іншими програмами. Або вона може оголосити власні. Нові права оголошуються за допомогою елементу . Наприклад, дія може бути захищеною наступним чином:
<manifest . . . >
<permission android:name="com.example.project.DEBIT_ACCT" . . . />
<uses-permission android:name="com.example.project.DEBIT_ACCT" />
. . .
<application . . .>
<activity android:name="com.example.project.FreneticActivity"
android:permission="com.example.project.DEBIT_ACCT"
. . . >
. . .
</activity>
</application>
</manifest>
Зверніть увагу, що у даному прикладі, дозвіл DEBIT_ACCT оголошується не тільки у елементі <permission>, він також розміщений у елементі <uses-permission>. Його використання повинно бути дозволене користувачем, щоб інші компоненти програми мали право запустити компонент, незважаючи на те, що захист походить від самої програми.
Якщо, у даному прикладі, атрибут permission буде встановлено у дозвіл оголошений у іншому місці (на подобі android.permission.CALL_EMERGENCY_NUMBERS) не обов'язково, щоб він був оголошений знову в елементі . Однак, все-одно необхідно зробити запит на їх використання за допомогою <uses-permission>.
Елемент оголошує простір елементів для групування, які будуть визначеними у коді. Елемент визначає мітку для групи дозволів. Він впливає на те, як дозволи будуть згрупованими, під час представлення користувачу. Елемент <permission-group> не вказує які дозволи відносяться до групи; вони просто дають ім'я групі. Дозвіл поміщається у групу за допомогою присвоєння імені групи для атрибуту permissionGroup елементу .
Бібліотеки
Кожна програма з'єднується з стандартною бібліотекою Android, яка включає базовий пакет для побудови програм і загальними класами.
Однак деякі пакети розміщуються у їхніх власних бібліотеках. Якщо програма використовує код з будь-якої з даних бібліотек, вона повинна явно вказати потрібність компонування з ними. Маніфест повинен містити окремі елементи для вказування на кожну з таких бібліотек.