AndroidManifest.xml — mi ez, fő komponensek és a manifest konfigurációja

Mi az AndroidManifest.xml

Az AndroidManifest.xml a fő konfigurációs fájl XML formátumban, amelyet minden Android projektnek tartalmaznia kell az app/src/main könyvtárban. Az Android rendszer elemzi azt bármilyen alkalmazáskód végrehajtása előtt — az APK elemzésének szakaszában a telepítéskor. Ha a manifestben szintaktikai hiba van, vagy hiányzik egy kötelező deklaráció, a telepítés megszakad egy hibaüzenettel.

A fájl tartalmazza az alkalmazás teljes deklarációját: az összes komponens listáját (Activity, Service, BroadcastReceiver, ContentProvider), a kért engedélyeket, a minimális SDK verziót, a hardverkövetelményeket, valamint a témák és stílusok konfigurációját. Minden olyan komponenst, amelyet a rendszer vagy más alkalmazások meghívhatnak, kifejezetten deklarálni kell a manifestben. Ez egy biztonsági követelmény: explicit deklaráció nélkül a komponens nem érhető el a meghíváshoz.

Helyesen konfigurált manifest nélkül az alkalmazás nem telepíthető Google Play áruházból vagy sideloading útján. A rendszer ellenőrzi a manifestet az APK elemzésének szakaszában, és hibák esetén elutasítja a telepítést. A Google Play szintén vizsgálja a manifestet a nem biztonságos konfigurációk miatt: az exported=true egy intent-filter nélküli komponensen figyelmeztetést vált ki, a targetSdk 34+ kötelező engedélyeinek hiánya pedig blokkolja a publikálást. Ezért a manifest szerkezetének megértése kötelező készség az Android fejlesztők számára.

Alkalmazás komponensek a manifestben

Az Android alkalmazás minden komponensét kifejezetten regisztrálni kell a manifestben. Ez a platform kötelező követelménye mind a négy komponenstípusra. Regisztráció nélkül a komponens nem hozható létre a rendszer által, és az indítási kísérlet ActivityNotFoundException vagy hasonló kivételt eredményez. A komponensek az application tagen belül kerülnek regisztrálásra olyan sorrendben, amely nem befolyásolja a működésüket.

Activity

Az activity tag regisztrálja az alkalmazás képernyőjét. Az exported attribútum határozza meg, hogy más alkalmazások indíthatják-e ezt az Activity-t. Android 12-től kezdve az exported hiánya intent-filter jelenlétében fordítási hibát okoz — ez egy biztonsági követelmény. A belépési pont egy MAIN action és LAUNCHER category értékű intent-filter segítségével kerül beállításra. Minden Activity-nek egyedi android:name értékkel kell rendelkeznie, amely megfelel az osztály teljes vagy relatív nevének.

<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

A service tag egy háttérszolgáltatást definiál. Android 8-tól kezdve a háttérszolgáltatások szigorú korlátozásokkal rendelkeznek: a foreground service kötelező, a felhasználó számára látható ikonnal ellátott értesítést igényel, a bound service pedig csak akkor él, ha van kapcsolódó kliens. Az értesítés nélkül a háttérben futó szolgáltatások automatikusan megszűnnek a rendszer által néhány perccel az alkalmazás háttérmódba lépése után. Hosszú távú feladatokhoz a Service helyett WorkManager-t használjon.

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

BroadcastReceiver

A receiver tag deklarálja a rendszer vagy egyéni broadcast üzenetek fogadóját. Android 8-tól kezdve a legtöbb implicit broadcast már nem kerül kézbesítésre a manifestben statikusan deklarált fogadóknak. Ehelyett ajánlott a fogadókat dinamikusan regisztrálni a Context.registerReceiver segítségével a kódban. Kivételt képez néhány rendszer broadcast, mint a BOOT_COMPLETED, amely továbbra is statikus regisztrációt igényel a manifestben.

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

Engedélyek (Permissions) Androidban

Minden veszélyes engedély Androidban deklarálást igényel a manifestben a uses-permission tagen keresztül. Android 6-tól kezdve a veszélyes engedélyek futásidőben kérhetők egy párbeszédablakon keresztül, de a manifestben való deklarálás továbbra is kötelező. Enélkül a requestPermissions metódus SecurityException kivételt dob. A normál szintű engedélyek, mint az INTERNET és ACCESS_NETWORK_STATE, automatikusan megadásra kerülnek a telepítéskor.

A uses-permission-sdk-23 tag azokat az engedélyeket adja meg, amelyek csak Android 6.0+ rendszeren szükségesek. Ez lehetővé teszi a kompatibilitás fenntartását a régebbi verziókkal anélkül, hogy nem létező engedélyeket kérnénk. Például a POST_NOTIFICATIONS csak Android 13+ rendszeren érhető el, ezért a uses-permission-sdk-33 segítségével kell megadni, hogy a régebbi eszközökön ne jelenjen meg ismeretlen engedély hiba. A maxSdkVersion attribútum a uses-permission-ben lehetővé teszi a szükségtelen engedélyek automatikus visszavonását az alkalmazás újabb Android verziókra történő frissítésekor.

A normál szintű engedélyek (INTERNET, ACCESS_NETWORK_STATE) automatikusan megadásra kerülnek a telepítéskor, és nem igényelnek futásidejű kérést. Szintén a uses-permission segítségével kerülnek deklarálásra, de nem jelennek meg a felhasználónak párbeszédablakban. Más alkalmazások hozzáférésének szabályozásához az alkalmazás komponenseihez a permission-protected components mechanizmus használható: egyéni engedély adható meg Activity vagy Service szinten, amelyet a rendszer ellenőriz, ha a komponenst kívülről hívják meg. Ez további biztonsági szintet nyújt a folyamatközi kommunikációhoz.

Intent Filters és mély linkek

A manifestben található intent-filter tag deklarálja, hogy a komponens milyen implicit intenteket képes feldolgozni. Ez az a mechanizmus, amelyen keresztül az Android összekapcsolja a rendszer vagy egyéni műveleteket az alkalmazással. Az intent filter három elemből áll: action (művelet), category (kategória) és data (adatok). Mindhárom kombinálható a komponens által fogadandó intentek pontos leírásához. A rendszer a legspecifikusabb szűrő alapján választja ki a megfelelő komponenst.

<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>

Az autoVerify attribútum bekapcsolja az Android App Links ellenőrzést: a rendszer kapcsolatba lép a szerverrel a domain tulajdonjogának megerősítéséhez. Ellenőrzés nélkül a mély linkek a szabványos választó párbeszédablakon keresztül működnek, ahol a felhasználó kiválasztja, melyik alkalmazással nyissa meg a linket. Sikeres ellenőrzés után a linkek közvetlenül az alkalmazásban nyílnak meg párbeszédablak nélkül. A Google Search Console szintén az autoVerify-t használja a mély linkek indexeléséhez és megjelenítéséhez a keresési eredményekben.

A action.VIEW és a DEFAULT és BROWSABLE kategóriájú szűrők a böngészőből, e-mailből és más alkalmazásokból érkező linkeket dolgozzák fel. Ez a fő mechanizmus a mély linkek megvalósításához Androidban. Az egyéni URL sémák, például a myapp:// támogatásához elegendő a scheme megadása host nélkül. A Google azonban a HTTPS mély linkek használatát ajánlja az egyéni sémák helyett, mivel ezek biztonságosabbak és nem igényelnek további engedélyeket. Az egyéni sémákat bármely alkalmazás elkaphatja, amely regisztrálta ugyanazt a sémát.

Alkalmazás attribútumok és metaadatok

A gyökér manifest tag tartalmazza a csomag, verzió és SDK attribútumait. Az application tag tárolja a globális beállításokat: témát, ikont, címkét és hibakeresési jelzőket. A manifest attribútumok a csomagszintű verziókezelést határozzák meg, az application attribútumok pedig az alkalmazás általános megjelenését és viselkedését definiálják. Az értékek lehetnek @-szintaxisú erőforráshivatkozások vagy karakterlánc literálok.

<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">
        <!--  Alkalmazás komponensek  -->
    </application>
</manifest>

A meta-data tag az application-en belül lehetővé teszi tetszőleges kulcs-érték párok tárolását. Ez kényelmes a harmadik féltől származó könyvtárak konfigurálásához: API kulcsok, endpoint címek és funkcionalitás jelzők. A meta-data-ból származó adatok futásidőben a PackageManager.getApplicationInfo().metaData segítségével érhetők el. Például a Firebase és a Google Maps a meta-data-t használja a hozzáférési kulcsok továbbításához anélkül, hogy a forráskódba kellene azokat keménykódolni. A kulcsok a manifestben kerülnek megadásra, és eltérőek lehetnek a különböző fordítási változatokhoz.

Az android:extractNativeLibs attribútum szabályozza a natív könyvtárak APK-ból való kicsomagolását. A targetSdk 34+ rendelkező alkalmazások esetén ezt az attribútumot explicit módon meg kell adni, különben a fordítás INSTALL_FAILED_INVALID_APK hibával hiúsulhat meg. Ha az extractNativeLibs=false, a natív könyvtárak kicsomagolás nélkül az APK-n belül maradnak, ami csökkenti a telepített alkalmazás méretét, de növeli a könyvtárak betöltési idejét. A legtöbb modern alkalmazás esetén az extractNativeLibs=false ajánlott a felhasználó lemezterületének megtakarítása érdekében.

Az android:networkSecurityConfig attribútum lehetővé teszi egy hálózati biztonsági konfigurációs fájl megadását. Ez különösen fontos a targetSdk 28+ rendelkező alkalmazásoknál, ahol a HTTP forgalom alapértelmezés szerint blokkolva van. A konfigurációs fájl meghatározza a megbízható tanúsítványokat, a HTTP kapcsolatokhoz használható domaineket és a tanúsítvány rögzítés (pinning) szabályait. Ez felváltja az elavult android:usesCleartextTraffic attribútumot, és rugalmasabb mechanizmust biztosít a kapcsolatok biztonságának kezelésére az operációs rendszer szintjén.

Az android:largeHeap attribútum megnövelt heap méretet kér az alkalmazás számára. Alapértelmezés szerint az Android korlátozott memóriát allokál minden alkalmazásnak, az eszköztől és az operációs rendszer verziójától függően. Ha az alkalmazás nehéz képekkel, videóval vagy nagy adathalmazokkal dolgozik, a largeHeap megelőzheti az OutOfMemoryError hibát. Az attribútummal való visszaélés azonban káros: a nagy memóriafogyasztású alkalmazást a rendszer gyorsabban megszünteti erőforrás-hiány esetén. Csak profilalkotás és a szükségesség megerősítése után használja a largeHeap-et.