Лекция__.Этапы разработки android-приложений.
План лекции:
1. Процесс загрузки Android
2. Основы создания Android приложения
1. Процесс загрузки ОС Android
Давайте узнаем о нюансах загрузки андроид ОС и пройдем все этапы от BIOS-а до загрузки Android-приложения.
На картинке ниже представлен краткий процесс загрузки ОС Android. Но как видно на картинке, процесс останавливается на запуске Launcher-а. Мы же пройдем весь процесс, вплоть до запуска обычного приложения.
Этап 1. Bootrom
Bootrom — это небольшой кусочек защищенной от записи флеш-памяти, встроенный в процессорный чип. Он содержит самый первый код, который выполняется процессором при его включении. Далее, он запускает BootLoader.
Этап 2. BootLoader (работа BIOS’а)
BootLoader выполняет первичный запуск специфичных настроек перед запуском ядра. То есть дословно, копирует файлы в рабочую память устройства и передает управление коду, расположенному в разделе boot, что по сути есть ядро Linux.
Этап 3. Ядро
Ядро запускает настройку кэша, защищенную память, планировщик задач и загружает драйверы. Когда ядро завершит настройку и запуск своих подсистем, он первым делом запустить корневой и самый главный процесс init(). Все процессы запускаемые после него являются дочерними.
Этап 4. init()
Процесс init() подключает директории /sys, /dev, /proc и запускает службы(daemon), которые указаны в файле init.rc. Например, Service Manager, Media Server. Формат init.rc достаточно простой и по сути представляет собой набор команд, разделенных на блоки. Каждый блок определяет стадию загрузки или, выражаясь языком разработчиков Android, действие. И наконец init() доходит до запуска среды выполнения Android путем запуска службы Zygote.
Этап 5. Среда выполнения Android
Zygote — ключевой компонент любой Android-системы, который ответственен за инициализацию, старт системных служб, запуск и остановку пользовательских приложений и многие другие задачи. Zygote запускается с помощью небольшого приложения /system/bin/app_process. Задача app_proccess — запустить виртуальную машину Art/Dalvik, код которой располагается в разделяемой библиотеке /system/lib/libandroid_runtime.so, а затем поверх нее запустить Zygote.
Когда все это будет сделано и Zygote получит управление, он начинает формирование среды исполнения Java-приложений с помощью загрузки всех Java-классов фреймворка (сейчас их более 2000).
Этап 6. system_server
Затем Zygote запускает system_server, включающий в себя большинство высокоуровневых (написанных на Java) системных сервисов, в том числе Window Manager, Status Bar, Package Manager и, что самое важное, Activity Manager, который в будущем будет ответственен за получение сигналов о старте и завершении приложений.
Этап 7. Activity Manager
После этого Zygote открывает сокет /dev/socket/zygote и уходит в сон, ожидая данные. В это время запущенный ранее Activity Manager посылает широковещательный интент Intent.CATEGORY_HOME, чтобы найти Launcher-приложение, отвечающее за формирование рабочего стола, и отдает его имя Zygote через сокет. Zygote, в свою очередь, форкается и запускает Launcher-приложение поверх виртуальной машины. Вуаля, у нас на экране появляется рабочий стол, найденный Activity Manager и запущенный Zygote, и статусная строка, запущенная system_server в рамках службы Status Bar.
Этап 8. Запуск «своего» приложения
А теперь давайте запустим свое приложение(например, Telegram), которое мы установили из Google Play Store. После тапа по иконке искомого приложения Launcher-приложение пошлет интент с именем этого приложения, его примет Activity Manager и передаст команду на старт приложения демону Zygote.
Когда Zygote получает запрос на старт приложения от Activity Manager, он не запускает новую виртуальную машину, а просто форкается, то есть копирует самого себя и затем запускает поверх полученной копии виртуальной машины нужное приложение. Копия ART/Dalvik VM создаёт главный поток приложения(MainThread).
2. Основы создания приложений
Приложения для Android пишутся на языке программирования Java. Инструменты Android SDK (Software Development Kit – комплект разработки программного обеспечения) компилируют написанный вами код — и все требуемые файлы данных и ресурсов — в файл APK – программный пакет Android A ndroid P ac k age, который представляет собой файл архива с расширением.apk. В файле APK находится все, что требуется для работы Android-приложения, и он позволяет установить приложение на любом устройстве под управлением системы Android.
Каждое приложение Android, установленное на устройстве, работает в собственной "песочнице" (изолированной программной среде):
· операционная система Android представляет собой многопользовательскую систему Linux, в которой каждое приложение является отдельным пользователем;
· по умолчанию система назначает каждому приложению уникальный идентификатор пользователя Linux (этот идентификатор используется только системой и неизвестен приложению); система устанавливает полномочия для всех файлов в приложении, с тем чтобы доступ к ним был разрешен только пользователю с идентификатором, назначенным этому приложению;
· у каждого процесса имеется собственная виртуальная машина (ВМ), так что код приложения выполняется изолированно от других приложений;
· по умолчанию каждое приложение выполняется в собственном процессе Linux. Android запускает процесс, когда требуется выполнить какой-либо компонент приложения, а затем завершает процесс, когда он больше не нужен либо когда системе требуется освободить память для других приложений.
Таким образом система Android реализует принцип предоставления минимальных прав. То есть каждое приложение по умолчанию имеет доступ только к тем компонентам, которые ему необходимы для работы, и ни к каким другим. Благодаря этому формируется исключительно безопасная среда, в которой приложение не имеет доступа к недозволенным областям системы.
Однако у приложения есть варианты предоставления своих данных другим приложениям и доступа к системным службам:
· двум приложениям можно назначить один идентификатор пользователя Linux. В этом случае каждый из них сможет обращаться к файлам другого приложения. Для экономии ресурсов системы также можно сделать так, чтобы приложения с одинаковым идентификатором пользователя выполнялись в одном процессе Linux и использовали одну ВМ (приложения также должны быть подписаны одним сертификатом);
· приложение может запросить разрешение на доступ к данным устройства, например к контактам пользователя, SMS-сообщениям, подключаемой карте памяти (SD-карте), камере, Bluetooth и др. Все разрешения должны предоставляться приложению при его установке.
Это основные сведения о том, каким образом приложение Android существует в системе. В остальной части этого документа раскрываются следующие темы:
· базовые компоненты, которые определяют приложение;
· файл манифеста, в котором объявляются компоненты и функции устройства, необходимые для приложения;
· ресурсы, которые существуют отдельно от кода приложения и позволяют приложению адаптировать свою работу к устройствам с различными конфигурациями.
Компоненты приложения
Компоненты приложения являются кирпичиками, из которых состоит приложение для Android. Каждый компонент представляет собой отдельную точку, через которую система может войти в приложение. Не все компоненты являются точками входа для пользователя, а некоторые из них зависят друг от друга. При этом каждый компонент является самостоятельной структурной единицей и играет определенную роль — каждый из них представляет собой уникальный элемент структуры, который определяет работу приложения в целом.
Компоненты приложения можно отнести к одному из четырех типов. Компоненты каждого типа предназначены для определенной цели, они имеют собственный жизненный цикл, который определяет способ создания и прекращения существования компонента.
Четыре типа компонентов:
1) Операции
Операция (Activity) представляет собой один экран с пользовательским интерфейсом. Например, в приложении для работы с электронной почтой одна операция может служить для отображения списка новых сообщений, другая – для составления сообщения и третья операция – для чтения сообщений. Несмотря на то что операции совместно формируют связное взаимодействие пользователя с приложением по работе с электронной почтой, каждая из них не зависит от других операций. Любые из этих операций могут быть запущены другим приложением (если это позволяет приложение по работе с электронной почтой). Например, приложение для камеры может запустить операцию в приложении по работе с электронной почтой, которая составляет новое сообщение, чтобы пользователь мог отослать фотографию.
Операция относится к подклассу класса Activity. Подробные сведения об этом можно найти в руководстве для разработчиков в статье Операции.
Жизненный цикл Activity
2) Службы
Служба (Service) представляет собой компонент, который работает в фоновом режиме и выполняет длительные операции, связанные с работой удаленных процессов. Служба не имеет пользовательского интерфейса. Например, она может воспроизводить музыку в фоновом режиме, пока пользователь работает в другом приложении, или же она может получать данные по сети, не блокируя взаимодействие пользователя с операцией. Служба может быть запущена другим компонентом, который затем будут взаимодействовать с ней, – например операцией.
Служба относится к подклассу класса Service. Подробные сведения об этом можно найти в руководстве для разработчиков в статье Службы.
3) Поставщики контента
Поставщик контента (Content provider) управляет общим набором данных приложения. Данные можно хранить в файловой системе, базе данных SQLite, в Интернете или любом другом постоянном месте хранения, к которому у вашего приложения имеется доступ. Посредством поставщика контента другие приложения могут запрашивать или даже изменять данные (если поставщик контента позволяет делать это). Например, в системе Android есть поставщик контента, который управляет информацией контактов пользователя. Любое приложение, получившее соответствующие разрешения, может запросить часть этого поставщика контента (например ContactsContract.Data), для чтения и записи сведений об определенном человеке.
Поставщики контента также используются для чтения и записи данных, доступ к которым внешним компонентам приложение не предоставляет. Например, в образце приложения Note Pad с помощью поставщика контента выполняется сохранение заметок.
Поставщик контента относится к подклассу класса ContentProvider. Он должен реализовывать стандартный набор API-интерфейсов, с помощью которых другие приложения будут выполнять транзакции. Подробные сведения можно найти в руководстве для разработчиков в статье Поставщики контента.
4) Приемники широковещательных сообщений
Приемник широковещательных сообщений (Broadcast receiver) представляет собой компонент, который реагирует на объявления распространяемые по всей системе. Многие из этих объявлений рассылает система — например объявление о том, что экран выключился, аккумулятор разряжен или был сделан фотоснимок. Объявления также могут рассылаться приложениями, — например, чтобы сообщить другим приложениям о том, что какие-то данные были загружены на устройство и теперь готовы для использования. Несмотря на то что приемники широковещательных сообщений не имеют пользовательского интерфейса, они могутсоздавать уведомления в строке состояния, чтобы предупредить пользователя о событии "рассылка объявления". Однако чаще всего они являются просто "шлюзом" для других компонентов и предназначены для выполнения минимального объема работы. Например, они могут инициировать выполнение службой определенных действий при возникновении события.
Приемник широковещательных сообщений относится к подклассу класса BroadcastReceiver, а каждое такое сообщение предоставляется как объект Intent. Подробные сведения изложены в руководстве, посвященном классу BroadcastReceiver.
Уникальной особенностью системы Android является то, что любое приложение может запустить компонент другого приложения. Например, если вы хотите дать пользователю возможность фотографировать, используя камеру устройства, то, поскольку наверняка имеется другое приложение, которое может выполнить это действие, вместо того чтобы разработать операцию фотографирования в своем приложении, вы можете вызвать такое приложение. Вам не нужно внедрять код из приложения для камеры или даже устанавливать на него ссылку. Вместо этого вы можете просто запустить операцию фотографирования из приложения для камеры. По завершении этой операции фотография будет возвращена в ваше приложение, и ее можно будет использовать. Для пользователя это будет выглядеть как одно приложение.
Когда система запускает компонент, она запускает процесс для этого приложения (если он еще не был запущен) и создает экземпляры классов, которые требуются этому компоненту. Например, если ваше приложение запустит операцию фотографирования в приложении для камеры, эта операция будет выполняться в процессе, который относится к этому стороннему приложению, а не в процессе вашего приложения. Поэтому, в отличие от приложений для большинства других систем, в приложениях для Android отсутствует единая точка входа (например, в них нет функции main()).
Поскольку система выполняет каждое приложение в отдельном процессе с такими правами доступа к файлам, которые ограничивают доступ в другие приложения, ваше приложение не может напрямую вызвать компонент из другого приложения. Это может сделать сама система Android. Поэтому, чтобы вызвать компонент в другом приложении, необходимо сообщить системе о своем намерении (Intent) запустить определенный компонент. После этого система активирует для вас этот компонент.
Активация компонентов
Компоненты трех из четырех возможных типов — операции, службы и приемники широковещательных сообщений — активируются асинхронным сообщением, которое называется Intent (намерение). Объекты Intent связывают друг с другом отдельные компоненты во время выполнения, будь то это компоненты вашего или стороннего приложения (эти объекты Intent можно представить себе в виде мессенджеров, которые посылают другим компонентам запрос на выполнение действий).
Объект Intent создается с помощью объекта Intent, который описывает запрос на активацию либо конкретного компонента, либо компонента конкретного типа — соответственно, намерение Intent может быть явным или неявным.
Для операций и служб Объект Intent определяет действие, которое требуется выполнить (например, просмотреть (view) или отправить (send) что-то), а также может указывать URI (Uniform Resource Identifier – унифицированный идентификатор ресурса) данных, с которыми это действие нужно выполнить (помимо прочих сведений, которые нужно знать запускаемому компоненту). Например, объект Intent может передавать запрос на выполнение операции "показать изображение" или "открыть веб-страницу". В некоторых ситуациях операцию можно запустить, чтобы получить результат. В этом случае операция возвращает результат также в виде объекта Intent (например, можно отправить сообщение Intent, чтобы дать пользователю возможность выбрать контакт и вернуть его вам — в ответном сообщении Intent будет содержаться URI, указывающий на выбранный контакт).
Для приемников широковещательных сообщений Intent просто определяет передаваемое объявление (например, широковещательное сообщение о низком уровне заряда аккумулятора содержит только строку "аккумулятор разряжен").
Компоненты четвертого типа – поставщики контента – сообщениями Intent не активируются. Они активируются по запросу от ContentResolver. Процедура определения контента (content resolver) обрабатывает все прямые транзакции с поставщиком контента, с тем чтобы этого не пришлось делать компоненту, который выполняет транзакции с поставщиком. Вместо этого он вызывает методы для объекта ContentResolver. Это формирует слой, абстрагирующий (в целях безопасности) поставщика контента от компонента, запрашивающего информацию.
Для активации компонентов каждого типа имеются отдельные методы:
· Можно запустить операцию (или определить для нее какое-то новое действие), передав объект Intent методу startActivity() или startActivityForResult() (если требуется, чтобы операция вернула результат).
· Можно запустить службу (либо выдать работающей службе новые инструкции), передав объект Intent методу startService(). Либо можно установить привязку к службе, передав объектIntent методу bindService().
· Можно инициировать рассылку сообщений, передав объект Intent таким методам, как sendBroadcast(), sendOrderedBroadcast() и sendStickyBroadcast().
· Можно выполнить запрос к поставщику контента, вызвав метод query() для объекта ContentResolver.
· Подробные сведения об использовании объектов Intent приведены в документе Объекты Intent и фильтры объектов Intent. Более подробная информация об активации определенных компонентов также приведена в следующих документах: Операции, Службы, BroadcastReceiver и Поставщики контента.
Файл манифеста
Для запуска компонента приложения системе Android необходимо знать, что компонент существует. Для этого она читает файл AndroidManifest.xml приложения (файл манифеста).
Помимо объявления компонентов приложения, манифест служит и для других целей, среди которых:
· указание всех полномочий пользователя, которые требуются приложению, например разрешения на доступ в Интернет или на чтение контактов пользователя;
· объявление минимальногоуровня API, требуемого приложению, с учетом того, какие API-интерфейсы оно использует;
· объявление аппаратных и программных функций, которые нужны приложению или используются им, например камеры, службы Bluetooth или сенсорного экрана;
· указание библиотек API, с которыми необходимо связать приложение (отличные от API-интерфейсов платформы Android), например библиотеки Google Maps.
В корневой папке каждого приложения должен находиться файл AndroidManifest.xml (который именно так и называется). Файл манифеста содержит важную информацию о приложении, которая требуется системе Android. Только получив эту информацию, система может выполнить какой-либо код приложения. Среди прочего файл манифеста выполняет следующие действия:
Он задает имя пакета Java для приложения. Это имя пакета служит уникальным идентификатором приложения.
Он описывает компоненты приложения — операции, службы, приемники широковещательных сообщений и поставщиков контента, из которых состоит приложение. Он содержит имена классов, которые реализуют каждый компонент, и публикует их возможности (указывает, например, какие сообщения Intent они могут принимать). На основании этих деклараций система Android может определить, из каких компонентов состоит приложение и при каких условиях их можно запускать.
Он определяет, в каких процессах будут размещаться компоненты приложения.
Он объявляет, какие разрешения должны быть выданы приложению, чтобы оно могло получить доступ к защищенным частям API-интерфейса и взаимодействовать с другими приложениями.
Он также объявляет разрешения, требуемые для взаимодействия с компонентами данного приложения.
Он содержит список классов Instrumentation, которые при выполнении приложения предоставляют сведения о профиле и прочую информацию. Эти объявления присутствуют в файле манифеста только во время разработки и отладки приложения и удаляются перед его публикацией.
Он объявляет минимальный уровень 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> и <service> можно указать в любой последовательности. (Элемент <activity-alias> является исключением из этого правила. Он должен следовать за элементом <activity>, псевдонимом которого он является.)
Атрибуты
Формально все атрибуты являются необязательными. Однако некоторые их них указывать необходимо, чтобы файл мог выполнять свое предназначение. В качестве руководства используйте эту документацию. В отношении атрибутов, которые являются и вправду необязательными, в ней указывается значение, используемое по умолчанию, или говорится, что произойдет, если такой атрибут не будет указан.
За исключением некоторых атрибутов корневого элемента <manifest>, имена всех атрибутов должны начинаться с префикса android: — например, android:alwaysRetainTaskState. Поскольку этот префикс является универсальным, в документации при указании атрибутов по имени он обычно опускается.
Объявление имен классов
Многие элементы соответствуют объектам Java, в том числе элементы для самого приложения (элемент <application>) и основных его компонентов — операций (<activity>), служб (<service>), приемников широковещательных сообщений (<receiver>) и поставщиков контента (<provider>).
Если вы определяете подкласс, а это практически всегда делается для классов компонентов (Activity, Service, BroadcastReceiver и ContentProvider), выполняется это с помощью атрибута name. В состав имени должно входить полное обозначение пакета. Например, подкласс 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 может быть перечислено несколько действий:
<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>
Значения ресурсов
Значения некоторых атрибутов могут отображаться на экране — например, метка и значок операции. Значения этих атрибутов следует локализовать, поэтому они должны задаваться в ресурсе или теме. Значения ресурсов выражаются в следующем формате:
@[<i>пакет</i>:]<i>тип</i>:<i>имя</i>
где имя пакета можно опустить, если ресурс находится в одном пакете с приложением, тип — это тип ресурса, — например "string" или "drawable", — а имя — это имя, определяющее ресурс. Например:
<activity android:icon="@drawable/smallPic"... >
Значения из темы выражаются схожим образом, только в начале у них идет "?", а не "@":
?[<i>пакет</i>:]<i>тип</i>:<i>имя</i>
Строковые значения
Когда значением атрибута является строка, следует использовать двойную обратную косую черту ("\\") для выделения управляющей последовательности символов, — например "\\n" для новой строки или "\\uxxxx" для символа Юникода.
Отображение функций в файле
В следующих разделах описано, как некоторые функции Android отображаются в файле манифеста.
Фильтры объектов Intent
Базовые компоненты приложения (его операции, службы и приемники широковещательных сообщений) активируются объектами Intent. Intent — это совокупность информации (объект Intent), описывающей требуемое действие, — в том числе в ней указаны данные, с которыми следует выполнить это действие, категория компонентов, которые должны выполнять это действие, и другие уместные инструкции. Система Android находит компонент, который отреагирует на объект Intent, запускает новый экземпляр компонента, если он требуется, и передает ему объект Intent.
Компоненты объявляют свои возможности — виды объектов Intent, на которые они могут реагировать, — с помощью фильтров Intent. Поскольку система Android должна узнать, какие объекты Intent может обрабатывать тот или иной компонент, до того как она его запустит, фильтры Intent указываются в файле манифеста как элементы <intent-filter>. Компонент может иметь любое количество фильтров, каждый из которых описывает отдельную возможность компонента.
Объект Intent, в котором целевой компонент явно указан по имени, активирует этот компонент, и фильтр при этом не учитывается. Но объект Intent, в котором имя целевого компонента не указано, может активировать компонент, только если он может пройти через один из фильтров компонента.
Сведения о том, каким образом объекты Intent проверяются по фильтрам Intent, см. в отдельном документе Объекты Intent и фильтры объектов Intent.
Значки и метки
У ряда элементов есть атрибуты icon и label для небольшого значка и текстовой метки, которые могут отображаться на экране. У некоторых из них также есть атрибут description для более длинного описательного текста, который также может отображаться на экране. Например, элемент <permission> имеет все три таких атрибута, поэтому, когда пользователю задается вопрос, предоставить ли разрешение запросившему его приложению, на экране может отображаться значок, представляющий разрешение, имя разрешения и описание того, что оно за собой влечет.
В любом случае значок и метка, заданные в элементе-контейнере, становятся параметрами icon и label, используемыми по умолчанию для всех вложенных в этот контейнер дочерних элементов. Так, значок и метка, заданные в элементе <application>, являются значком и меткой, используемыми по умолчанию для каждого компонента приложения. Точно так же, значок и метка, заданные для компонента, — например элемента <activity>, — являются параметрами, используемыми по умолчанию для каждого элемента <intent-filter> компонента. Если в элементе <application> задана метка, а в операции и ее фильтре Intent — нет, метка приложения будет считаться меткой и для операции, и для фильтра Intent.
Значок и метка, заданные для фильтра Intent, используются для обозначения компонента, когда он представляется пользователю, для указания функции, которую анонсирует фильтр. Например, фильтр с параметрами "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-permission> в файле манифеста. Затем, когда приложение устанавливается на устройство, установщик определяет, выдать ли запрошенное разрешение, проверяя полномочия органов, подписавших сертификаты приложения, а также, в некоторых случаях, спрашивая об этом пользователя. Если разрешение предоставляется, приложение сможет использовать защищенные функции. В противном случае его попытки доступа к этим функциям будут безуспешными, причем пользователь не получит никакого уведомления об этом.
Приложение также может защищать с помощью разрешений собственные компоненты (операции, службы, приемники широковещательных сообщений и поставщиков контента). Оно может использовать любые разрешения, определенные системой Android (они приведены в объекте 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>
Обратите внимание, что в этом примере разрешение DEBIT_ACCT не только объявляется с помощью элемента <permission>, его использование также запрашивается с помощью элемента <uses-permission>. Чтобы другие компоненты приложения запускали защищенную операцию, ее использование должно быть запрошено, даже несмотря на то, что защита наложена самим приложением.
В этом же примере: если атрибут permission был бы задан как разрешение, объявленное где-то еще (например, 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> для указания имени каждой библиотеки. (Имя библиотеки можно найти в документации по пакету.)
Объявление компонентов
Основная задача манифеста – это информировать систему о компонентах приложения. Например, файл манифеста может объявлять операцию следующим образом:
<?xml version="1.0" encoding="utf-8"?><manifest... >
<application android:icon="@drawable/app_icon.png"... >
<activity android:name="com.example.project.ExampleActivity"
android:label="@string/example_label"... >
</activity>
...
</application>
</manifest>
Атрибут android:icon в элементе <application> указывает на ресурсы для значка, который обозначает приложение.
Атрибут android:name в элементе <activity> указывает полное имя класса подкласса Activity, а атрибут android:label указывает строку, которую необходимо использовать в качестве метки операции, отображаемой для пользователя.
Все компоненты приложения необходимо объявлять следующим образом:
· элементы <activity> для операций;
· элементы <service> для служб;
· элементы <receiver> для приемников широковещательных сообщений;
· элементы <provider> для поставщиков контента
Системе не видны операции, службы и поставщики контента, которые имеются в исходном коде, но не объявлены в манифесте, поэтому они не могут быть запущены. А вот приемники широковещательных сообщений можно либо объявить в манифесте, либо создать динамически в коде (как объекты BroadcastReceiver) и зарегистрировать в системе путем вызова registerReceiver().
Подробные сведения о структуризации файла манифеста для приложения см. в документе Файл AndroidManifest.xml.