AndroidManifest.xml — что это, основные компоненты и конфигурация манифеста

Что такое AndroidManifest.xml

AndroidManifest.xml — это корневой конфигурационный файл в формате XML, который каждый Android проект обязан содержать в директории app/src/main. Система Android анализирует его до запуска любого кода приложения — на этапе парсинга APK при установке. Если в манифесте есть синтаксическая ошибка или отсутствует обязательное объявление, установка прерывается с сообщением об ошибке.

Файл содержит полную декларацию приложения: список всех компонентов (Activity, Service, BroadcastReceiver, ContentProvider), запрашиваемые разрешения, минимальную версию SDK, аппаратные требования и конфигурацию тем и стилей. Каждый компонент, который может быть вызван системой или другими приложениями, должен быть явно объявлен в манифесте. Это требование безопасности: без явного объявления компонент недоступен для вызова.

Без правильно настроенного манифеста приложение не может быть установлено через Google Play или sideloading. Система проверяет манифест на этапе парсинга APK и отклоняет установку при ошибках. Google Play также сканирует манифест на предмет небезопасных конфигураций: при exported=true на компоненте без intent-filter выдаётся предупреждение, а при отсутствии обязательных разрешений для targetSdk 34+ публикация блокируется. Поэтому понимание структуры манифеста — обязательный навык Android-разработчика.

Компоненты приложения в манифесте

Каждый компонент Android приложения должен быть явно зарегистрирован в манифесте. Это обязательное требование платформы для всех четырёх типов компонентов. Без регистрации компонент не может быть создан системой, и попытка его запуска приведет к исключению ActivityNotFoundException или аналогичному. Компоненты регистрируются внутри тега application в порядке, не влияющем на их работу.

Activity

Тег activity регистрирует экран приложения. Атрибут exported определяет, могут ли другие приложения запускать эту Activity. Начиная с Android 12, отсутствие exported при наличии intent-filter вызывает ошибку сборки — это требование безопасности. Точка входа задаётся через intent-filter с action MAIN и category LAUNCHER. Каждое Activity должно иметь уникальное android:name, соответствующее полному или относительному имени класса.

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:windowSoftInputMode="adjustResize">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Service

Тег service определяет фоновый сервис. Начиная с Android 8, фоновые службы имеют строгие ограничения: foreground service требует обязательного уведомления с иконкой, видимого пользователю, а bound service живёт только при наличии связанного клиента. Сервисы, работающие в фоне без уведомления, автоматически завершаются системой через несколько минут после перехода приложения в фоновый режим. Для длительных задач используйте WorkManager вместо Service.

<service
    android:name=".SyncService"
    android:exported="false"
    android:foregroundServiceType="dataSync" />

BroadcastReceiver

Тег receiver объявляет приёмник системных или кастомных широковещательных сообщений. Начиная с Android 8, большинство неявных broadcast-рассылок больше не доставляются статически объявленным в манифесте приёмникам. Вместо этого рекомендуется регистрировать приёмники динамически через Context.registerReceiver в коде. Исключение составляют некоторые системные рассылки, например BOOT_COMPLETED, которые по-прежнему требуют статической регистрации в манифесте.

<receiver
    android:name=".ConnectivityReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>

Разрешения (Permissions) в Android

Каждое опасное разрешение в Android требует декларации в манифесте через тег uses-permission. Начиная с Android 6, опасные разрешения запрашиваются во время выполнения через диалог с пользователем, но декларация в манифесте остаётся обязательной. Без неё метод requestPermissions выбрасывает исключение SecurityException. Разрешения нормального уровня, такие как INTERNET и ACCESS_NETWORK_STATE, предоставляются автоматически при установке.

Тег uses-permission-sdk-23 указывает разрешения, необходимые только на Android 6.0+. Это позволяет сохранять совместимость со старыми версиями без запроса несуществующих разрешений. Например, POST_NOTIFICATIONS доступно только на Android 13+, поэтому его нужно указывать через uses-permission-sdk-33, чтобы на более старых устройствах не было ошибки неизвестного разрешения. Атрибут maxSdkVersion в uses-permission позволяет автоматически отзывать ненужные разрешения при обновлении приложения на новых версиях Android.

Разрешения нормального уровня (INTERNET, ACCESS_NETWORK_STATE) предоставляются автоматически при установке и не требуют runtime-запроса. Они также декларируются через uses-permission, но не показываются пользователю в диалоге. Для контроля доступа к компонентам приложения из других приложений используется механизм permission-protected components: можно указать custom permission на уровне Activity или Service, которое будет проверяться системой при вызове компонента извне. Это обеспечивает дополнительный уровень безопасности для межпроцессного взаимодействия.

Intent Filters и диплинки

Тег intent-filter в манифесте объявляет, какие неявные интенты может обрабатывать компонент. Это механизм, через который Android связывает системные или кастомные действия с приложением. Intent filter состоит из трёх элементов: action (действие), category (категория) и data (данные). Все три могут быть скомбинированы для точного описания, какие интенты должен получать компонент. Система выбирает подходящий компонент на основе наиболее специфичного фильтра.

<activity android:name=".DeepLinkActivity">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="https"
            android:host="itsectr.com"
            android:pathPrefix="/app" />
    </intent-filter>
</activity>

Атрибут autoVerify включает проверку Android App Links: система связывается с сервером для подтверждения владения доменом. Без верификации диплинки работают через стандартный chooser dialog, где пользователь выбирает, каким приложением открыть ссылку. После успешной верификации ссылки открываются напрямую в приложении без диалога. Google Search Console также использует autoVerify для индексации deep links и отображения их в результатах поиска.

Фильтры с action.VIEW и категориями DEFAULT и BROWSABLE обрабатывают ссылки из браузера, email и других приложений. Это основной механизм реализации диплинков в Android. Для поддержки кастомных URL-схем, например myapp://, достаточно указать scheme без host. Однако Google рекомендует использовать HTTPS-диплинки вместо кастомных схем, так как они более безопасны и не требуют дополнительных разрешений. Кастомные схемы могут быть перехвачены любым приложением, зарегистрировавшим ту же схему.

Атрибуты приложения и метаданные

Корневой тег manifest содержит атрибуты пакета, версии и SDK. Тег application хранит глобальные настройки: тему, иконку, label и флаги отладки. Атрибуты manifest задают версионирование на уровне пакета, а атрибуты application определяют внешний вид и поведение приложения в целом. Значения могут быть ссылками на ресурсы через @-синтаксис или строковыми литералами.

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.itsectr.myapp"

    <uses-sdk
        android:minSdkVersion="24"
        android:targetSdkVersion="34" />

    <application
        android:label="MyApp"
        android:icon="@mipmap/ic_launcher"
        android:theme="@style/Theme.MyApp"
        android:supportsRtl="true"
        android:allowBackup="true">
        <!-- Компоненты приложения -->
    </application>
</manifest>

Тег meta-data внутри application позволяет хранить произвольные пары ключ-значение. Это удобно для конфигурации сторонних библиотек: API-ключей, endpoint-адресов и флагов функциональности. Данные из meta-data доступны через PackageManager.getApplicationInfo().metaData в runtime. Например, Firebase и Google Maps используют meta-data для передачи ключей доступа без жёсткого кодирования в исходном коде. Вместо этого ключи задаются в манифесте и могут отличаться для разных флейворсов сборки.

Атрибут android:extractNativeLibs управляет извлечением нативных библиотек из APK. Для приложений с targetSdk 34+ этот атрибут должен быть явно указан, иначе сборка может упасть с ошибкой INSTALL_FAILED_INVALID_APK. Если extractNativeLibs=false, нативные библиотеки остаются внутри APK без распаковки, что уменьшает размер установленного приложения, но увеличивает время загрузки библиотек. Для большинства современных приложений рекомендуется extractNativeLibs=false для уменьшения занимаемого места на диске пользователя.

Атрибут android:networkSecurityConfig позволяет задать файл конфигурации сетевой безопасности. Это особенно важно для приложений с targetSdk 28+, где HTTP трафик по умолчанию заблокирован. Конфигурационный файл определяет доверенные сертификаты, домены для HTTP-соединений и правила pinning сертификатов. Это заменяет устаревший атрибут android:usesCleartextTraffic и предоставляет более гибкий механизм управления безопасностью соединений на уровне ОС.

Атрибут android:largeHeap запрашивает увеличенный размер кучи для приложения. По умолчанию Android выделяет каждому приложению ограниченный объём памяти, зависящий от устройства и версии ОС. Если приложение работает с тяжёлыми изображениями, видео или большими наборами данных, largeHeap может предотвратить OutOfMemoryError. Однако злоупотребление этим атрибутом вредно: приложение с большим потреблением памяти быстрее завершается системой при нехватке ресурсов. Используйте largeHeap только после профилирования и подтверждения необходимости.