AndroidManifest.xml — ano ito, pangunahing bahagi at configuration ng manifest

Ano ang AndroidManifest.xml

Ang AndroidManifest.xml ay ang pangunahing configuration file sa XML format na dapat taglayin ng bawat Android project sa app/src/main directory. Sinusuri ito ng Android system bago magpatakbo ng anumang code ng app — sa yugto ng pag-parse ng APK sa pag-install. Kung may syntax error sa manifest o kulang ang sapilitang deklarasyon, ang pag-install ay ititigil na may mensahe ng error.

Ang file ay naglalaman ng kumpletong deklarasyon ng app: listahan ng lahat ng bahagi (Activity, Service, BroadcastReceiver, ContentProvider), hinihinging pahintulot, minimum na bersyon ng SDK, mga kinakailangan sa hardware, at configuration ng mga tema at estilo. Bawat bahagi na maaaring tawagin ng system o ng ibang apps ay dapat na eksplisitong ideklara sa manifest. Ito ay isang kinakailangan sa seguridad: nang walang eksplisitong deklarasyon, ang bahagi ay hindi available para sa pagtawag.

Kung walang tamang na-configure na manifest, ang app ay hindi mai-install sa pamamagitan ng Google Play o sideloading. Sinusuri ng system ang manifest sa yugto ng pag-parse ng APK at tinatanggihan ang pag-install kung may mga error. Ini-scan din ng Google Play ang manifest para sa mga hindi ligtas na configuration: para sa exported=true sa isang bahagi na walang intent-filter ay magbibigay ng babala, at kung walang sapilitang pahintulot para sa targetSdk 34+, ang publikasyon ay haharangin. Kaya ang pag-unawa sa istruktura ng manifest ay isang sapilitang kasanayan para sa Android developer.

Mga bahagi ng app sa manifest

Bawat bahagi ng Android app ay dapat na eksplisitong irehistro sa manifest. Ito ay isang sapilitang kinakailangan ng platform para sa lahat ng apat na uri ng bahagi. Nang walang pagpaparehistro, ang bahagi ay hindi maaaring gawin ng system, at ang pagtatangkang patakbuhin ito ay magdudulot ng ActivityNotFoundException o katulad na exception. Ang mga bahagi ay nirerehistro sa loob ng application tag sa pagkakasunod-sunod na hindi nakakaapekto sa kanilang operasyon.

Activity

Ang activity tag ay nagrerehistro ng screen ng app. Tinutukoy ng exported attribute kung maaaring ilunsad ng ibang apps ang Activity na ito. Simula Android 12, ang kawalan ng exported sa presensya ng intent-filter ay nagdudulot ng compilation error — ito ay isang kinakailangan sa seguridad. Ang entry point ay itinakda sa pamamagitan ng intent-filter na may action MAIN at category LAUNCHER. Bawat Activity ay dapat may natatanging android:name na tumutugma sa buo o relatibong pangalan ng klase.

<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

Ang service tag ay tumutukoy ng background service. Simula Android 8, ang mga background service ay may mahigpit na limitasyon: ang foreground service ay nangangailangan ng sapilitang notipikasyon na may icon na nakikita ng user, at ang bound service ay nabubuhay lamang kung may konektadong client. Ang mga service na tumatakbo sa background nang walang notipikasyon ay awtomatikong tinatapos ng system ilang minuto pagkatapos lumipat ang app sa background mode. Para sa mga pangmatagalang gawain, gamitin ang WorkManager sa halip na Service.

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

BroadcastReceiver

Ang receiver tag ay nagdedeklara ng receiver ng system o custom na broadcast message. Simula Android 8, karamihan ng mga implicit broadcast ay hindi na naihahatid sa mga receiver na statikong idineklara sa manifest. Sa halip, inirerekomenda ang dynamic na pagpaparehistro ng mga receiver sa pamamagitan ng Context.registerReceiver sa code. Ang exception ay ilang system broadcast, tulad ng BOOT_COMPLETED, na nangangailangan pa rin ng static na pagpaparehistro sa manifest.

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

Mga pahintulot (Permissions) sa Android

Bawat mapanganib na pahintulot sa Android ay nangangailangan ng deklarasyon sa manifest sa pamamagitan ng tag na uses-permission. Simula Android 6, ang mga mapanganib na pahintulot ay hinihiling sa runtime sa pamamagitan ng dialog sa user, ngunit ang deklarasyon sa manifest ay nananatiling sapilitan. Kung wala ito, ang paraang requestPermissions ay magtatapon ng SecurityException. Ang mga pahintulot sa normal na antas, tulad ng INTERNET at ACCESS_NETWORK_STATE, ay awtomatikong ibinibigay sa pag-install.

Ang tag na uses-permission-sdk-23 ay tumutukoy ng mga pahintulot na kailangan lamang sa Android 6.0+. Ito ay nagbibigay-daan upang mapanatili ang compatibility sa mga lumang bersyon nang hindi humihiling ng mga hindi umiiral na pahintulot. Halimbawa, ang POST_NOTIFICATIONS ay available lamang sa Android 13+, kaya dapat itong tukuyin sa pamamagitan ng uses-permission-sdk-33 upang sa mga lumang device ay walang error na hindi kilalang pahintulot. Ang maxSdkVersion attribute sa uses-permission ay nagbibigay-daan sa awtomatikong pagbawi ng mga hindi kinakailangang pahintulot kapag nag-a-update ng app sa mga bagong bersyon ng Android.

Ang mga pahintulot sa normal na antas (INTERNET, ACCESS_NETWORK_STATE) ay awtomatikong ibinibigay sa pag-install at hindi nangangailangan ng runtime request. Ang mga ito ay idinedeklara rin sa pamamagitan ng uses-permission, ngunit hindi ipinapakita sa user sa isang dialog. Para sa kontrol ng access sa mga bahagi ng app mula sa ibang apps, ginagamit ang mekanismo ng permission-protected components: maaaring tukuyin ang custom na pahintulot sa antas ng Activity o Service na susuriin ng system kapag ang bahagi ay tinawag mula sa labas. Ito ay nagbibigay ng karagdagang antas ng seguridad para sa interprocess communication.

Intent Filters at malalalim na link

Ang intent-filter tag sa manifest ay nagdedeklara kung anong mga implicit intent ang kayang iproseso ng isang bahagi. Ito ang mekanismo kung saan ikinokonekta ng Android ang system o custom na mga aksyon sa app. Ang intent filter ay binubuo ng tatlong elemento: action (aksyon), category (kategorya), at data (datos). Lahat ng tatlo ay maaaring pagsamahin upang tumpak na ilarawan kung anong mga intent ang dapat matanggap ng bahagi. Pinipili ng system ang angkop na bahagi batay sa pinaka-espesipikong filter.

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

Ang attribute na autoVerify ay nag-a-activate ng verification ng Android App Links: ang system ay nakikipag-ugnayan sa server upang kumpirmahin ang pagmamay-ari ng domain. Nang walang verification, ang malalalim na link ay gumagana sa pamamagitan ng standard chooser dialog, kung saan pinipili ng user kung aling app ang gagamitin para buksan ang link. Pagkatapos ng matagumpay na verification, ang mga link ay direktang bubukas sa app nang walang dialog. Ginagamit din ng Google Search Console ang autoVerify para sa pag-index ng malalalim na link at pagpapakita nito sa mga resulta ng paghahanap.

Ang mga filter na may action.VIEW at mga kategoryang DEFAULT at BROWSABLE ay humahawak ng mga link mula sa browser, email, at ibang apps. Ito ang pangunahing mekanismo ng pagpapatupad ng malalalim na link sa Android. Para sa suporta ng custom na URL scheme, halimbawa myapp://, sapat na ang tukuyin ang scheme nang walang host. Gayunpaman, inirerekomenda ng Google ang paggamit ng HTTPS deep link sa halip na custom na mga scheme, dahil mas ligtas ang mga ito at hindi nangangailangan ng karagdagang pahintulot. Ang custom na mga scheme ay maaaring maharang ng anumang app na nagrehistro ng parehong scheme.

Mga attribute ng app at metadata

Ang root na manifest tag ay naglalaman ng mga attribute ng package, bersyon, at SDK. Ang application tag ay nag-iimbak ng mga global na setting: tema, icon, label, at debugging flags. Ang mga attribute ng manifest ay nagtatakda ng versioning sa antas ng package, at ang mga attribute ng application ay tumutukoy sa hitsura at pag-uugali ng app sa kabuuan. Ang mga value ay maaaring mga reference sa resources sa pamamagitan ng @-syntax o string literals.

<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">
        <!--  Mga bahagi ng app  -->
    </application>
</manifest>

Ang meta-data tag sa loob ng application ay nagbibigay-daan sa pag-imbak ng arbitraryong key-value pairs. Ito ay maginhawa para sa configuration ng third-party libraries: API keys, endpoint address, at functionality flags. Ang data mula sa meta-data ay accessible sa pamamagitan ng PackageManager.getApplicationInfo().metaData sa runtime. Halimbawa, ang Firebase at Google Maps ay gumagamit ng meta-data upang maglipat ng access keys nang walang hardcoding sa source code. Ang mga key ay tinutukoy sa manifest at maaaring mag-iba para sa iba't ibang variant ng compilation.

Ang attribute na android:extractNativeLibs ay kumokontrol sa pag-extract ng native libraries mula sa APK. Para sa mga app na may targetSdk 34+, ang attribute na ito ay dapat na eksplisitong tukuyin, kung hindi, ang compilation ay maaaring mabigo sa error na INSTALL_FAILED_INVALID_APK. Kung extractNativeLibs=false, ang native libraries ay mananatili sa loob ng APK nang hindi nai-extract, na nagpapaliit sa laki ng naka-install na app ngunit nagpapataas ng oras ng pag-load ng libraries. Para sa karamihan ng modernong apps, ang extractNativeLibs=false ay inirerekomenda upang makatipid ng espasyo sa disk ng user.

Ang attribute na android:networkSecurityConfig ay nagbibigay-daan sa pagtukoy ng configuration file para sa network security. Ito ay lalong mahalaga para sa mga app na may targetSdk 28+, kung saan ang HTTP traffic ay naka-block bilang default. Ang configuration file ay tumutukoy ng mga pinagkakatiwalaang certificate, domain para sa HTTP connections, at mga patakaran ng certificate pinning. Ito ay pumapalit sa lumang attribute na android:usesCleartextTraffic at nagbibigay ng mas flexible na mekanismo para sa pamamahala ng seguridad ng koneksyon sa antas ng operating system.

Ang attribute na android:largeHeap ay humihiling ng pinalaking laki ng heap para sa app. Bilang default, ang Android ay naglalaan ng limitadong memorya sa bawat app, depende sa device at bersyon ng operating system. Kung ang app ay gumagana sa mabibigat na larawan, video, o malalaking dataset, ang largeHeap ay makakapigil sa OutOfMemoryError. Gayunpaman, ang pag-abuso sa attribute na ito ay nakakasama: ang app na may mataas na pagkonsumo ng memorya ay mas mabilis na tatapusin ng system kapag kulang ang resources. Gamitin ang largeHeap lamang pagkatapos ng profiling at kumpirmasyon ng pangangailangan.