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

Какво е AndroidManifest.xml

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

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

Без правилно конфигуриран манифест приложението не може да бъде инсталирано чрез Google Play или странично зареждане. Системата проверява манифеста на етапа на парсване на 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, повечето имплицитни излъчвания вече не се доставят на статично декларирани в манифеста приемници. Вместо това се препоръчва динамична регистрация на приемници чрез 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) се предоставят автоматично при инсталиране и не изискват искане по време на изпълнение. Те също се декларират чрез uses-permission, но не се показват на потребителя в диалог. За контрол на достъпа до компоненти на приложението от други приложения се използва механизмът permission-protected components: може да се зададе персонализирано разрешение на ниво Activity или Service, което системата ще провери при извикване на компонента отвън. Това осигурява допълнително ниво на сигурност за междупроцесна комуникация.

Intent Filters и дълбоки връзки

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

<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: системата се свързва със сървъра за потвърждение на собствеността върху домейна. Без проверка дълбоките връзки работят чрез стандартния диалог за избор, където потребителят избира с кое приложение да отвори връзката. След успешна проверка връзките се отварят директно в приложението без диалог. Google Search Console също използва autoVerify за индексиране на дълбоки връзки и показването им в резултатите от търсенето.

Филтрите с action.VIEW и категориите DEFAULT и BROWSABLE обработват връзки от браузър, имейл и други приложения. Това е основният механизъм за реализация на дълбоки връзки в Android. За поддръжка на персонализирани URL схеми, например myapp://, е достатъчно да се укаже scheme без host. Google обаче препоръчва използването на HTTPS дълбоки връзки вместо персонализирани схеми, тъй като те са по-сигурни и не изискват допълнителни разрешения. Персонализираните схеми могат да бъдат прихванати от всяко приложение, регистрирало същата схема.

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

Коренният таг manifest съдържа атрибутите на пакета, версията и SDK. Тагът application съхранява глобални настройки: тема, икона, етикет и флагове за отстраняване на грешки. Атрибутите на 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 по време на изпълнение. Например 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 само след профилиране и потвърждение на необходимостта.