Урок 10: AndroidManifest.xml (андройд манифест)

Введение

Программирование и разработка приложений это не только написание кода, но и конфигурация приложения. Сейчас мы познакомимся с содержимым важнейшего файла проекта – AndroidManifest. Я расскажу про всего его теги и конфиги, а также покажу как выглядит финальный манифест после сборки приложения. В нем тоже много чего интересного.

Отображение иерархии проектов

Для начала обратимся к настройке вида проекта. Здесь есть выпадающий список. Как правило по-умолчанию студия отображает файлы с фильтром Android. При фильтрации отображения Android он выводит только файлы с кодом, ресурсы и манифест. И как будто больше ничего не должно нас волновать. Но на самом деле, чтобы лучше понимать, как работает наш проект рекомендую всегда переключать вид на Project. Во-первых он отображает все файлы, во-вторых он отображает их точно в такой же иерархии, в какой они располагаются в вашей системе.

AndroidManifest.xml

Окей. Что такое AndroidManifest? Это одно из самых важных мест в вашем приложении. Это декларация всех возможностей и информация о вашем приложении для системы. Это такой мостик для общения вашего приложения и системы.

По сути — текстовый файл формата XML. Файл открывается тегом <manifest> и в нем заключен самый основной и обязательный тег <application>. В котором перечисляются атрибуты для нашего приложения.

Если вы создаете проект с нуля, то здесь вы увидите ряд тегов, которые в целом не всегда нужны. Атрибуты связанные с бэкапом — это конфигурационные файлы, предназначенные для того, чтобы указать как приложение будет бэкапить свои данные. Например, сервисы гугла умеют бэкапить данные вашего приложения и восстанавливать их на других устройствах.

• android:allowBackup — указывает разрешается ли системе создавать резервную копию данных вашего приложения
• android:dataExtractionRules — определяет правила для извлечения данных из приложения в целях анализа или использования в других приложениях
• android:fullBackupContent — определяет список файлов и папок, которые будут включены в резервное копирование

Следующие атрибуты:

• android:icon — устанавливает иконку приложения. Ту иконку, которая будет отображаться на рабочем столе. На самом деле в Android рабочий стол — это специальное приложение Launcher. Они бывают разные, но практически любой из них может показывать список приложений.
• android:label — задает название приложения. То, что указывается под иконкой приложения на рабочем столе или в списке приложений в настройках. Это обычный строковый ресурс, а значит он подвержен локализации. То есть название можно указывать на разных языках.
• android:roundIcon — еще одна разновидность иконки, которая предназначена для устройств, которые рисуют иконки в виде кружков. Возможно, вы такое видели на устройствах Xiaomi.
• android:supportRtl — включение поддержки для языков, которые пишутся и читаются справа-налево. По умолчанию она включена.
• android:theme — задает основной файл с настройками темы вашего приложения.
• tools:targetApi — как помним из уроков по XML разметке, это необязательный атрибут, который не попадает в финальную APK сборку.

Тег <application>

Внутри тега <application> мы указываем те компоненты, которые использует наше приложение. К таким компонентам относится:

• Activity — некоторое представление экрана пользователя.
• Service — компоненты, которые позволяют осуществлять фоновую работу, какую-то не визуальную часть работы в системе.
• Provider — можно перевести, как “поставщик”. Это штука, предоставляющая доступ к каким-то внутренним данным приложения. Часто через провайдер, например, предоставляют доступ к списку контактов приложения “Контакты”.
• Receiver — переводится, как “получатель”. Еще один часто используемый компонент, который позволяет подписаться на получение каких-то сообщений системы. Или ваше приложение может являться источником таким сообщений. Например, при интеграции пуш-уведомлений в систему, мы указываем Receiver, который будет отлавливать и обрабатывать эти сообщения в своем методе onReceive().

Еще их называют основными компонентами Android-приложения. Базовый вопрос на собеседовании. Мы еще вернемся к каждому из них в будущем и изучим подробнее.

<uses-permission> (пермишены)

Помимо компонентов AndroidManifest позволяет указать “пермишены”. Они присутствуют практически во всех приложениях. Устанавливаются с помощью <uses-permission>. Дело в том, что приложение должно явно рассказать системе о том, что оно будет пользоваться тем или иным ресурсом устройства.

<uses-permission android:name="android.permission.INTERNET"/>

Например, здесь я говорю системе, что данное приложение будет осуществлять запросы в сеть. Если же этого “пермишена” не будет, то любой запрос, который вы попытаетесь сделать из вашего приложения при помощи кода — он будет падать с ошибкой. Это относится практически ко всем операциям, которые требуют взаимодействия с устройством.

Не путайте с тегом <permission> — он используется для создания кастомных “пермишенов”. Вы просто задаете имя в виде константы и какое-то другое приложение сможет получить к нему доступ. Но мы с вами таким заниматься не будем.

Merged Manifest

Если используете какие-то сторонние зависимости (или библиотеки), то они могут добавлять в манифест свои компоненты, “пермишены” и так далее. Чтобы посмотреть актуальное состояние манифеста, можно нажать на кнопку Merged Manifest и увидеть здесь список того, что было добавлено в финальный манифест.

В частности здесь можно увидеть, что докинуто versionCode, versionName и packageName — на самом деле это три обязательных атрибута манифеста. Они как раз нужны системе, чтобы идентифицировать уникальным образом эту сборку. Система смотрит только на versionCode и packageName. И если версия кода ниже с таким же packageName, то при установке будет ошибка. versionName — это имя версии, которая отображается для пользователей, то, что вы видите на странице приложения в Google Play Market.

Здесь же появились minSdk и targetSdk (о них будет ниже). Не смотря на то, что они прописываются в gradle файле, они также попадают в финальный файл AndroidManifest. Если вы видите какой-то компонент, который вы явно сами не добавляли, можно провалиться в него и посмотреть кто его добавил.

В следующей экскурсионной статье я познакомлю вас с Gradle. Будет про конфигурацию сборщика, гладл-плагины и все такое. Короче про все остальные файлы проекта с непонятными названиями. Чтобы немного лучше ориентироваться в процессах, которые происходят под капотом проекта.