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: можна вказати кастомний дозвіл на рівні 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 обробляють посилання з браузера, електронної пошти та інших застосунків. Це основний механізм реалізації діплінків в 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-з’єднань та правила піннінгу сертифікатів. Це замінює застарілий атрибут android:usesCleartextTraffic та надає більш гнучкий механізм керування безпекою з’єднань на рівні ОС.

Атрибут android:largeHeap запитує збільшений розмір купи для застосунку. За замовчуванням Android виділяє кожному застосунку обмежений об’єм пам’яті, який залежить від пристрою та версії ОС. Якщо застосунок працює з важкими зображеннями, відео або великими наборами даних, largeHeap може запобігти OutOfMemoryError. Однак зловживання цим атрибутом шкідливе: застосунок з великим споживанням пам’яті швидше завершується системою при нестачі ресурсів. Використовуйте largeHeap тільки після профілювання та підтвердження необхідності.