В корневой папке каждого приложения должен находиться файл AndroidManifest.xml (который именно так и называется ). Файл манифеста содержит важную информацию о приложении, которая требуется системе 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> и
<service>
можно указать в любой последовательности. (Элемент
<activity-alias>
является исключением из этого правила. Он должен следовать за элементом
<activity>,
псевдонимом которого он является.)
За исключением некоторых атрибутов корневого элемента
<manifest>
, имена всех атрибутов должны начинаться с префикса {@code android:} —
например, {@code android:alwaysRetainTaskState}. Поскольку этот префикс является
универсальным, в документации при указании атрибутов по имени
он обычно опускается.
<application>
) и основных его компонентов — операций
(<activity>),
служб
(<service>),
приемников широковещательных сообщений
(<receiver>)
и поставщиков контента
(<provider>).
Если вы определяете подкласс, а это практически всегда делается для классов компонентов ({@link android.app.Activity}, {@link android.app.Service}, {@link android.content.BroadcastReceiver} и {@link android.content.ContentProvider}), выполняется это с помощью атрибута {@code name}. В состав имени должно входить полное обозначение пакета. Например, подкласс {@link android.app.Service} можно объявить следующим образом:
<manifest . . . >
<application . . . >
<service android:name="com.example.project.SecretService" . . . >
. . .
</service>
. . .
</application>
</manifest>
Однако его можно укоротить. Если первым символом в строке указать точку, эта
строка будет добавляться к имени пакета приложения (указанного атрибутом
package
элемента
package
). Следующее назначение является таким же, как приведенное выше:
<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>{@code @[пакет:]тип:имя}
где имя пакета можно опустить, если ресурс находится в одном пакете с приложением, тип — это тип ресурса, — например "string" или "drawable", — а имя — это имя, определяющее ресурс. Например:
<activity android:icon="@drawable/smallPic" . . . >
Значения из темы выражаются схожим образом, только в начале у них идет "{@code ?}", а не "{@code @}":
{@code ?[пакет:]тип:имя}
В следующих разделах описано, как некоторые функции Android отображаются в файле манифеста.
Базовые компоненты приложения (его операции, службы и приемники широковещательных сообщений) активируются объектами Intent. Intent — это совокупность информации (объект {@link android.content.Intent}), описывающей требуемое действие, — в том числе в ней указаны данные, с которыми следует выполнить это действие, категория компонентов, которые должны выполнять это действие, и другие уместные инструкции. Система Android находит компонент, который отреагирует на объект Intent, запускает новый экземпляр компонента, если он требуется, и передает ему объект Intent.
Компоненты объявляют свои возможности — виды объектов Intent, на которые они могут
реагировать, — с помощью фильтров Intent. Поскольку система Android
должна узнать, какие объекты Intent может обрабатывать тот или иной компонент, до того как она его запустит,
фильтры Intent указываются в файле манифеста как
элементы <intent-filter>
. Компонент может иметь любое количество фильтров, каждый из которых описывает
отдельную возможность компонента.
Объект Intent, в котором целевой компонент явно указан по имени, активирует этот компонент, и фильтр при этом не учитывается. Но объект Intent, в котором имя целевого компонента не указано, может активировать компонент, только если он может пройти через один из фильтров компонента.
Сведения о том, каким образом объекты Intent проверяются по фильтрам Intent, см. в отдельном документе Объекты Intent и фильтры объектов Intent.
У ряда элементов есть атрибуты {@code icon} и {@code label} для
небольшого значка и текстовой метки, которые могут отображаться на экране. У некоторых из них также есть атрибут
{@code description} для более длинного описательного текста, который также может
отображаться на экране. Например, элемент
<permission>
имеет все три таких атрибута, поэтому, когда пользователю задается вопрос, предоставить ли
разрешение запросившему его приложению, на экране может отображаться значок,
представляющий разрешение, имя разрешения и описание того, что оно
за собой влечет.
В любом случае значок и метка, заданные в элементе-контейнере, становятся параметрами
{@code icon} и {@code label}, используемыми по умолчанию для всех вложенных в этот контейнер дочерних элементов.
Так, значок и метка, заданные в элементе
<application>,
являются значком и меткой, используемыми по умолчанию для каждого компонента приложения.
Точно так же, значок и метка, заданные для компонента, — например элемента
<activity>, —
являются параметрами, используемыми по умолчанию для каждого элемента
<intent-filter>
компонента. Если в элементе
<application>
задана метка, а в операции и ее фильтре Intent — нет,
метка приложения будет считаться меткой и для операции, и для
фильтра Intent.
Значок и метка, заданные для фильтра Intent, используются для обозначения компонента, когда он представляется пользователю, для указания функции, которую анонсирует фильтр. Например, фильтр с параметрами "{@code android.intent.action.MAIN}" и "{@code android.intent.category.LAUNCHER}" сообщает, что эта операция инициирует приложение, — то есть он обозначает ее как операцию, которая должна быть отображена в средстве запуска приложений. Отсюда следует, что значок и метка, заданные в фильтре, отображаются в средстве запуска.
Разрешение представляет собой ограничение на доступ к части кода или к данным, имеющимся на устройстве. Это ограничение накладывается для защиты важных данных и кода, ненадлежащее использование которых может пагубно сказаться на работе приложения.
Каждое разрешение обозначается уникальной меткой. Зачастую метка обозначает действие, выполнение которого ограничивается. Например, вот некоторые разрешения, определенные системой Android:
{@code android.permission.CALL_EMERGENCY_NUMBERS}
{@code android.permission.READ_OWNER_DATA}
{@code android.permission.SET_WALLPAPER}
{@code android.permission.DEVICE_POWER}
Функцию можно защитить не более чем одним разрешением.
Если приложению требуется доступ к функции, защищенной разрешением,
оно должно объявить, что ему необходимо это разрешение, с помощью элемента
<uses-permission>
в файле манифеста. Затем, когда приложение устанавливается на
устройство, установщик определяет, выдать ли запрошенное
разрешение, проверяя полномочия органов, подписавших сертификаты
приложения, а также, в некоторых случаях, спрашивая об этом пользователя.
Если разрешение предоставляется, приложение сможет использовать защищенные
функции. В противном случае его попытки доступа к этим функциям будут безуспешными,
причем пользователь не получит никакого уведомления об этом.
Приложение также может защищать с помощью разрешений собственные компоненты (операции, службы,
приемники широковещательных сообщений и поставщиков контента). Оно может использовать
любые разрешения, определенные системой Android (они приведены в объекте
{@link android.Manifest.permission android.Manifest.permission}) или объявленные
другими приложениями. Либо оно может определить разрешения самостоятельно. Новое разрешение объявляется
с помощью элемента
<permission>
. Например, операцию можно защитить следующим образом:
<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>
Обратите внимание, что в этом примере разрешение {@code DEBIT_ACCT} не только
объявляется с помощью элемента
<permission>
, его использование также запрашивается с помощью элемента
<uses-permission>
. Чтобы другие компоненты приложения запускали защищенную
операцию, ее использование должно быть запрошено, даже несмотря на то, что защита
наложена самим приложением.
В этом же примере: если атрибут {@code permission} был бы задан как
разрешение, объявленное где-то еще
(например, {@code android.permission.CALL_EMERGENCY_NUMBERS}), его бы не
нужно было объявлять еще раз с помощью элемента
<permission>
. Однако все равно нужно было бы запрашивать его использование с помощью
<uses-permission>.
Элемент
<permission-tree>
объявляет пространство имен для группы разрешений, которые будут определены в
коде. А элемент
<permission-group>
определяет метку для набора разрешений (как для разрешений, объявленных в файле манифеста с помощью элементов
<permission>
, так и для объявленных где-то еще). Это влияет только на то, каким образом разрешения
группируются, когда отображаются пользователю. Элемент
<permission-group>
не указывает, какие разрешения относятся к группе.
Он просто дает группе имя. Чтобы включить разрешение в группу,
атрибуту
permissionGroup
его элемента
<permission>
необходимо присвоить имя группы.
Каждое приложение связывается с используемой по умолчанию библиотекой Android, в которой имеются базовые пакеты для построения приложений (со стандартными классами, например Activity, Service, Intent, View, Button, Application, ContentProvider и так далее).
Однако некоторые пакеты находятся в собственных библиотеках. Если ваше приложение
использует код из одного из таких пакетов, оно должно в явном виде потребовать, чтобы его связали
с этим пакетом. Файл манифеста должен содержать отдельный элемент
<uses-library>
для указания имени каждой библиотеки. (Имя библиотеки можно найти в
документации по пакету.)