AndroidManifest.xml — vad är det, huvudkomponenter och manifestkonfiguration

Vad är AndroidManifest.xml

AndroidManifest.xml är den huvudsakliga konfigurationsfilen i XML-format som varje Android-projekt måste innehålla i katalogen app/src/main. Android-systemet analyserar den innan någon app-kod körs — i APK-tolkningsfasen vid installation. Om det finns ett syntaxfel i manifestet eller en obligatorisk deklaration saknas, avbryts installationen med ett felmeddelande.

Filen innehåller appens fullständiga deklaration: lista över alla komponenter (Activity, Service, BroadcastReceiver, ContentProvider), begärda behörigheter, lägsta SDK-version, hårdvarukrav och konfiguration av teman och stilar. Varje komponent som kan anropas av systemet eller andra appar måste deklareras explicit i manifestet. Detta är ett säkerhetskrav: utan explicit deklaration är komponenten inte tillgänglig för anrop.

Utan ett korrekt konfigurerat manifest kan appen inte installeras via Google Play eller sidladdning. Systemet kontrollerar manifestet i APK-tolkningsfasen och avvisar installation vid fel. Google Play skannar också manifestet efter osäkra konfigurationer: för exported=true på en komponent utan intent-filter utfärdas en varning, och om obligatoriska behörigheter för targetSdk 34+ saknas blockeras publicering. Därför är förståelse av manifeststrukturen en obligatorisk färdighet för Android-utvecklare.

Appkomponenter i manifestet

Varje komponent i en Android-app måste explicit registreras i manifestet. Detta är ett obligatoriskt krav från plattformen för alla fyra komponenttyper. Utan registrering kan komponenten inte skapas av systemet, och ett försök att starta den leder till ett ActivityNotFoundException eller liknande undantag. Komponenter registreras inuti application-taggen i en ordning som inte påverkar deras funktion.

Activity

Taggen activity registrerar appens skärm. Attributet exported avgör om andra appar kan starta denna Activity. Från Android 12 orsakar frånvaro av exported i närvaro av intent-filter ett kompileringsfel — detta är ett säkerhetskrav. Startpunkten ställs in via intent-filter med action MAIN och category LAUNCHER. Varje Activity måste ha ett unikt android:name som motsvarar klassens fullständiga eller relativa namn.

<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

Taggen service definierar en bakgrundstjänst. Från Android 8 har bakgrundstjänster strikta begränsningar: foreground service kräver en obligatorisk notifiering med en ikon synlig för användaren, och bound service lever bara när det finns en ansluten klient. Tjänster som körs i bakgrunden utan notifiering avslutas automatiskt av systemet några minuter efter att appen går i bakgrundsläge. För långvariga uppgifter, använd WorkManager istället för Service.

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

BroadcastReceiver

Taggen receiver deklarerar en mottagare av system- eller anpassade broadcastmeddelanden. Från Android 8 levereras de flesta implicita broadcasts inte längre till statiskt deklarerade mottagare i manifestet. Istället rekommenderas dynamisk registrering av mottagare via Context.registerReceiver i koden. Undantag är vissa system-broadcasts, som BOOT_COMPLETED, som fortfarande kräver statisk registrering i manifestet.

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

Behörigheter (Permissions) i Android

Varje farlig behörighet i Android kräver deklaration i manifestet via taggen uses-permission. Från Android 6 begärs farliga behörigheter under körning via en dialog med användaren, men deklaration i manifestet förblir obligatorisk. Utan den kastar metoden requestPermissions ett SecurityException. Behörigheter på normal nivå, som INTERNET och ACCESS_NETWORK_STATE, beviljas automatiskt vid installation.

Taggen uses-permission-sdk-23 anger behörigheter som endast behövs på Android 6.0+. Detta gör det möjligt att behålla kompatibilitet med äldre versioner utan att begära icke-existerande behörigheter. Till exempel är POST_NOTIFICATIONS endast tillgängligt på Android 13+, så det måste anges via uses-permission-sdk-33 för att undvika fel om okänd behörighet på äldre enheter. Attributet maxSdkVersion i uses-permission möjliggör automatisk återkallelse av onödiga behörigheter vid uppdatering av appen på nyare Android-versioner.

Behörigheter på normal nivå (INTERNET, ACCESS_NETWORK_STATE) beviljas automatiskt vid installation och kräver ingen begäran under körning. De deklareras också via uses-permission, men visas inte för användaren i en dialog. För åtkomstkontroll till appkomponenter från andra appar används mekanismen permission-protected components: en anpassad behörighet kan anges på Activity- eller Service-nivå som systemet kontrollerar när komponenten anropas utifrån. Detta ger en extra säkerhetsnivå för interprocesskommunikation.

Intent Filters och djupa länkar

Taggen intent-filter i manifestet deklarerar vilka implicita intent som en komponent kan hantera. Detta är mekanismen genom vilken Android kopplar system- eller anpassade åtgärder till appen. Intent filter består av tre element: action (åtgärd), category (kategori) och data (data). Alla tre kan kombineras för att exakt beskriva vilka intent komponenten ska ta emot. Systemet väljer lämplig komponent baserat på det mest specifika filtret.

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

Attributet autoVerify aktiverar verifiering av Android App Links: systemet kontaktar servern för att bekräfta domänägarskap. Utan verifiering fungerar djupa länkar via standardvalsdialogen, där användaren väljer vilken app som ska öppna länken. Efter lyckad verifiering öppnas länkar direkt i appen utan dialog. Google Search Console använder också autoVerify för indexering av djupa länkar och visning i sökresultat.

Filter med action.VIEW och kategorierna DEFAULT och BROWSABLE hanterar länkar från webbläsare, e-post och andra appar. Detta är den huvudsakliga mekanismen för implementering av djupa länkar i Android. För stöd av anpassade URL-scheman, till exempel myapp://, räcker det att ange scheme utan värd. Google rekommenderar dock att använda HTTPS-djupa länkar istället för anpassade scheman, eftersom de är säkrare och inte kräver extra behörigheter. Anpassade scheman kan fångas upp av vilken app som helst som har registrerat samma schema.

Appattribut och metadata

Rot manifest-taggen innehåller attribut för paket, version och SDK. Application-taggen lagrar globala inställningar: tema, ikon, etikett och felsökningsflaggor. Manifest-attribut anger versionering på paketnivå, medan application-attribut definierar appens utseende och beteende som helhet. Värden kan vara referenser till resurser via @-syntax eller strängliteral.

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

Taggen meta-data inuti application möjliggör lagring av godtyckliga nyckel-värdepar. Detta är praktiskt för konfiguration av tredjepartsbibliotek: API-nycklar, endpoint-adresser och funktionalitetsflaggor. Data från meta-data är tillgänglig via PackageManager.getApplicationInfo().metaData under körning. Till exempel använder Firebase och Google Maps meta-data för att överföra åtkomstnycklar utan hårdkodning i källkoden. Nycklarna anges i manifestet och kan skilja sig för olika kompileringsvarianter.

Attributet android:extractNativeLibs styr extrahering av naturliga bibliotek från APK. För appar med targetSdk 34+ måste detta attribut anges explicit, annars kan kompileringen misslyckas med felet INSTALL_FAILED_INVALID_APK. Om extractNativeLibs=false förblir naturliga bibliotek inuti APK utan extrahering, vilket minskar storleken på den installerade appen men ökar laddningstiden för bibliotek. För de flesta moderna appar rekommenderas extractNativeLibs=false för att spara utrymme på användarens disk.

Attributet android:networkSecurityConfig gör det möjligt att ange en konfigurationsfil för nätverkssäkerhet. Detta är särskilt viktigt för appar med targetSdk 28+, där HTTP-trafik är blockerad som standard. Konfigurationsfilen bestämmer betrodda certifikat, domäner för HTTP-anslutningar och regler för certifikatpinning. Detta ersätter det föråldrade attributet android:usesCleartextTraffic och ger en mer flexibel mekanism för hantering av anslutningssäkerhet på operativsystemsnivå.

Attributet android:largeHeap begär en förstorad heap-storlek för appen. Som standard tilldelar Android varje app en begränsad mängd minne, beroende på enheten och OS-versionen. Om appen arbetar med tunga bilder, video eller stora datamängder kan largeHeap förhindra OutOfMemoryError. Missbruk av detta attribut är dock skadligt: en app med hög minnesförbrukning avslutas snabbare av systemet vid resursbrist. Använd largeHeap endast efter profilering och bekräftelse av behov.