AndroidManifest.xml — wat is het, belangrijkste componenten en manifestconfiguratie

Wat is AndroidManifest.xml

AndroidManifest.xml is het belangrijkste configuratiebestand in XML-formaat dat elk Android-project in de map app/src/main moet bevatten. Het Android-systeem analyseert het voordat er code van de app wordt uitgevoerd — in de APK-parsingfase bij installatie. Als er een syntaxisfout in het manifest staat of een verplichte declaratie ontbreekt, wordt de installatie onderbroken met een foutmelding.

Het bestand bevat de volledige declaratie van de app: een lijst van alle componenten (Activity, Service, BroadcastReceiver, ContentProvider), gevraagde machtigingen, minimale SDK-versie, hardwarevereisten en configuratie van thema's en stijlen. Elke component die door het systeem of andere apps kan worden aangeroepen, moet expliciet in het manifest worden gedeclareerd. Dit is een veiligheidsvereiste: zonder expliciete declaratie is de component niet beschikbaar voor aanroep.

Zonder correct geconfigureerd manifest kan de app niet worden geïnstalleerd via Google Play of sideloading. Het systeem controleert het manifest in de APK-parsingfase en weigert installatie bij fouten. Google Play scant ook het manifest op onveilige configuraties: voor exported=true op een component zonder intent-filter wordt een waarschuwing gegeven en bij ontbreken van verplichte machtigingen voor targetSdk 34+ wordt publicatie geblokkeerd. Daarom is begrip van de manifeststructuur een verplichte vaardigheid voor Android-ontwikkelaars.

App-componenten in het manifest

Elke component van een Android-app moet expliciet in het manifest worden geregistreerd. Dit is een verplichte vereiste van het platform voor alle vier typen componenten. Zonder registratie kan de component niet door het systeem worden gemaakt en een poging om deze te starten leidt tot een ActivityNotFoundException of een vergelijkbare uitzondering. Componenten worden binnen de application-tag geregistreerd in een volgorde die hun werking niet beïnvloedt.

Activity

De activity-tag registreert het scherm van de app. Het attribuut exported bepaalt of andere apps deze Activity kunnen starten. Vanaf Android 12 veroorzaakt het ontbreken van exported in aanwezigheid van een intent-filter een compilatiefout — dit is een veiligheidsvereiste. Het startpunt wordt ingesteld via een intent-filter met action MAIN en category LAUNCHER. Elke Activity moet een unieke android:name hebben die overeenkomt met de volledige of relatieve klassenaam.

<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

De service-tag definieert een achtergrondservice. Vanaf Android 8 hebben achtergrondservices strikte beperkingen: een foreground service vereist een verplichte melding met een voor de gebruiker zichtbaar pictogram, en een bound service leeft alleen zolang er een verbonden client is. Services die op de achtergrond zonder melding draaien, worden automatisch door het systeem beëindigd enkele minuten nadat de app naar de achtergrond gaat. Gebruik WorkManager in plaats van Service voor langdurige taken.

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

BroadcastReceiver

De receiver-tag declareert een ontvanger van systeem- of aangepaste broadcastberichten. Vanaf Android 8 worden de meeste impliciete broadcasts niet meer afgeleverd aan statisch in het manifest gedeclareerde ontvangers. In plaats daarvan wordt aanbevolen ontvangers dynamisch te registreren via Context.registerReceiver in de code. Uitzonderingen zijn bepaalde systeembroadcasts, zoals BOOT_COMPLETED, die nog steeds statische registratie in het manifest vereisen.

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

Machtigingen (Permissions) in Android

Elke gevaarlijke machtiging in Android vereist declaratie in het manifest via de tag uses-permission. Vanaf Android 6 worden gevaarlijke machtigingen tijdens runtime via een dialoog met de gebruiker aangevraagd, maar declaratie in het manifest blijft verplicht. Zonder declaratie gooit de methode requestPermissions een SecurityException. Normale machtigingen zoals INTERNET en ACCESS_NETWORK_STATE worden automatisch bij installatie verleend.

De tag uses-permission-sdk-23 specificeert machtigingen die alleen op Android 6.0+ nodig zijn. Dit maakt het mogelijk compatibiliteit met oudere versies te behouden zonder niet-bestaande machtigingen aan te vragen. POST_NOTIFICATIONS is bijvoorbeeld alleen beschikbaar op Android 13+, dus het moet worden opgegeven via uses-permission-sdk-33 om te voorkomen dat op oudere apparaten een foutmelding over een onbekende machtiging verschijnt. Het attribuut maxSdkVersion in uses-permission maakt het mogelijk onnodige machtigingen automatisch in te trekken bij het bijwerken van de app op nieuwere Android-versies.

Normale machtigingen (INTERNET, ACCESS_NETWORK_STATE) worden automatisch bij installatie verleend en vereisen geen runtime-aanvraag. Ze worden ook via uses-permission gedeclareerd, maar worden niet aan de gebruiker getoond in een dialoog. Voor toegangscontrole tot app-componenten vanuit andere apps wordt het mechanisme van permission-protected components gebruikt: er kan een aangepaste machtiging op Activity- of Service-niveau worden ingesteld die door het systeem wordt gecontroleerd wanneer de component van buitenaf wordt aangeroepen. Dit biedt een extra beveiligingsniveau voor interprocescommunicatie.

Intent Filters en diepe links

De intent-filter-tag in het manifest declareert welke impliciete intents een component kan verwerken. Dit is het mechanisme waarmee Android systeem- of aangepaste acties aan de app koppelt. Een intent filter bestaat uit drie elementen: action (actie), category (categorie) en data (gegevens). Alle drie kunnen worden gecombineerd om nauwkeurig te beschrijven welke intents de component moet ontvangen. Het systeem selecteert de juiste component op basis van de meest specifieke 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>

Het attribuut autoVerify schakelt verificatie van Android App Links in: het systeem neemt contact op met de server om domeineigendom te bevestigen. Zonder verificatie werken diepe links via de standaard kiezersdialoog, waarin de gebruiker selecteert met welke app de link moet worden geopend. Na succesvolle verificatie worden links direct in de app geopend zonder dialoog. Google Search Console gebruikt ook autoVerify voor het indexeren van deep links en het weergeven ervan in zoekresultaten.

Filters met action.VIEW en de categorieën DEFAULT en BROWSABLE verwerken links van browsers, e-mail en andere apps. Dit is het belangrijkste mechanisme voor het implementeren van diepe links in Android. Voor ondersteuning van aangepaste URL-schema's, zoals myapp://, volstaat het om scheme zonder host op te geven. Google raadt echter aan HTTPS-diepe links te gebruiken in plaats van aangepaste schema's, omdat deze veiliger zijn en geen extra machtigingen vereisen. Aangepaste schema's kunnen worden onderschept door elke app die hetzelfde schema heeft geregistreerd.

App-attributen en metadata

De root manifest-tag bevat de attributen van het pakket, de versie en SDK. De application-tag slaat globale instellingen op: thema, pictogram, label en foutopsporingsvlaggen. Manifest-attributen bepalen versionering op pakketniveau, en application-attributen definiëren het uiterlijk en gedrag van de app als geheel. Waarden kunnen verwijzingen naar bronnen zijn via @-syntaxis of tekenreeksen.

<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">
        <!--  App-componenten  -->
    </application>
</manifest>

De meta-data-tag binnen application maakt het mogelijk willekeurige sleutel-waardeparen op te slaan. Dit is handig voor het configureren van bibliotheken van derden: API-sleutels, endpoint-adressen en functionaliteitsvlaggen. Gegevens uit meta-data zijn tijdens runtime beschikbaar via PackageManager.getApplicationInfo().metaData. Firebase en Google Maps gebruiken bijvoorbeeld meta-data om toegangssleutels door te geven zonder hardcoding in de broncode. De sleutels worden in het manifest opgegeven en kunnen verschillen voor verschillende compilatievarianten.

Het attribuut android:extractNativeLibs beheert het uitpakken van native bibliotheken uit het APK. Voor apps met targetSdk 34+ moet dit attribuut expliciet worden opgegeven, anders kan de compilatie mislukken met foutmelding INSTALL_FAILED_INVALID_APK. Als extractNativeLibs=false is, blijven native bibliotheken zonder uitpakken in het APK, wat de grootte van de geïnstalleerde app verkleint maar de laadtijd van bibliotheken vergroot. Voor de meeste moderne apps wordt extractNativeLibs=false aanbevolen om schijfruimte op het apparaat van de gebruiker te besparen.

Het attribuut android:networkSecurityConfig maakt het mogelijk een configuratiebestand voor netwerkbeveiliging op te geven. Dit is vooral belangrijk voor apps met targetSdk 28+, waar HTTP-verkeer standaard is geblokkeerd. Het configuratiebestand bepaalt vertrouwde certificaten, domeinen voor HTTP-verbindingen en regels voor certificaat-pinning. Dit vervangt het verouderde attribuut android:usesCleartextTraffic en biedt een flexibeler mechanisme voor het beheren van verbindingsbeveiliging op besturingssysteemniveau.

Het attribuut android:largeHeap vraagt een vergrote heapgrootte aan voor de app. Standaard wijst Android elke app een beperkte hoeveelheid geheugen toe, afhankelijk van het apparaat en de OS-versie. Als de app werkt met zware afbeeldingen, video of grote gegevenssets, kan largeHeap OutOfMemoryError voorkomen. Misbruik van dit attribuut is echter schadelijk: een app met hoog geheugengebruik wordt sneller door het systeem beëindigd bij gebrek aan resources. Gebruik largeHeap alleen na profilering en bevestiging van noodzaak.