AndroidManifest Permissions: nyckelbegrepp, deklaration och typer av behörigheter

Vad är AndroidManifest Permissions?

AndroidManifest Permissions är Androids säkerhetsmekanism som kontrollerar appars åtkomst till skyddade data och systemfunktioner. Varje app måste deklarera nödvändiga behörigheter i filen AndroidManifest.xml med elementet <uses-permission>. Utan deklaration misslyckas anropet av motsvarande API med säkerhetsfelet SecurityException.

Androids behörighetsmodell har gått igenom flera utvecklingsstadier. Före Android 6.0 (API 23) beviljades alla behörigheter vid installation — användaren såg hela listan och accepterade eller avböjde installationen av appen. Från och med Android 6.0 begärs dangerous-nivåns behörigheter under körning (Runtime Permissions), vilket ger användaren mer flexibel kontroll.

Behörigheter delas in i fyra skyddsnivåer: normal (beviljas automatiskt vid installation), dangerous (kräver begäran under körning), signature (endast tillgängliga för appar signerade med samma certifikat) och special (kräver separat aktivering i inställningar). Varje nivå har sin egen mekanism för beviljande och återkallelse.

Enligt Google I/O 2024 planeras införandet av mer detaljerade behörigheter i Android 15 — användaren kommer att kunna ge åtkomst endast till specifika filer i mediebiblioteket, inte hela biblioteket. Detta fortsätter Androids trend att minimera mängden data som tillhandahålls som standard.

Skillnad från iOS behörighetsmodell

Till skillnad från iOS, där alla behörigheter begärs under körning (runtime), delar Android upp behörigheter i installations- (install-time) och körningsbaserade (runtime). Normal-nivån beviljas automatiskt vid installation utan att användaren meddelas. Dangerous-nivån kräver en explicit dialog, precis som i iOS.

En annan skillnad: i Android grupperas behörigheter i grupper (permission groups). Om användaren har accepterat åtkomst till kameran får appen automatiskt åtkomst till mikrofonen — de är i samma MICROPHONE-grupp. I iOS begärs varje behörighet separat, oberoende av grupp.

Utveckling av behörigheter per Android-version

Vilka typer av behörigheter finns

Android definierar fyra skyddsnivåer (protection levels) för behörigheter, var och en med egna regler för beviljande. Låt oss granska varje nivå i detalj.

Normal Permissions (install-time)

Normal-behörigheter beviljas automatiskt vid installation av appen utan meddelande eller begäran från användaren. De täcker åtkomst till lågriskfunktioner som inte hotar användarens integritet: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. Användaren ser ingen samtyckesdialog — behörigheten anses beviljad genom själva installationen.

Utvecklaren behöver inte hantera någon begäran i koden för normal-behörigheter — det räcker att deklarera dem i manifestet. I Android 12+ vid installation från Google Play ser användaren dock fliken ”Behörigheter” med en lista över alla normal-behörigheter, vilket ökar transparensen. Enligt Statista (2024) använder över 90% av apparna i Google Play INTERNET som den vanligaste normal-behörigheten.

Dangerous Permissions (runtime)

Dangerous-behörigheter täcker åtkomst till data och funktioner som kan kränka integriteten: kamera, mikrofon, geolokalisering, kontakter, SMS, telefon, kalender, kroppssensorer. Dessa behörigheter kräver en tvåstegs-mekanism: deklaration i manifestet + begäran under körning via ActivityCompat.requestPermissions().

Användaren kan vägra att bevilja en dangerous-behörighet, och appen måste hantera detta scenario korrekt. I Android 11+, om användaren har nekat två gånger, visar efterföljande begäranden ingen systemdialog — systemet returnerar automatiskt DENIED. I detta fall måste användaren dirigeras till inställningarna.

Signature och Special Permissions

Signature-nivån — behörigheten beviljas automatiskt om appen är signerad med samma certifikat som systemet eller en annan app som definierade behörigheten. Används för system- och företagsappar. Exempel: BIND_ACCESSIBILITY_SERVICE — endast tillgänglig för systemappar.

Special-nivån (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — kräver en separat åtgärd från användaren via systeminställningar. Appen kan öppna inställningssidan med Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION). Google Play begränsar användningen av special-behörigheter och kräver motivering i formuläret vid publicering.

Runtime Permission: arbeta med dangerous-behörigheter

Från och med Android 6.0 kräver alla dangerous-behörigheter begäran under körning. Låt oss gå igenom den fullständiga arbetscykeln med runtime permissions i Kotlin.

Kontroll och begäran av behörighet

Innan du anropar ett API som kräver en dangerous-behörighet, kontrollera alltid aktuell status via ContextCompat.checkSelfPermission(). Om statusen är PERMISSION_GRANTED — kan API:et anropas. Om den är PERMISSION_DENIED — måste behörigheten begäras via ActivityResultContract RequestPermission (AndroidX) eller föråldrade requestPermissions().

Det rekommenderas att använda ActivityResultContracts.RequestMultiplePermissions för att begära flera behörigheter samtidigt. Google rekommenderar att gruppera relaterade behörigheter (t.ex. kamera + mikrofon för videoinspelning) i en dialog, så att användaren ser hela sammanhanget för begäran.

import android.Manifest
import android.content.pm.PackageManager
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

class CameraActivity : AppCompatActivity() {
    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            if (isGranted) {
                openCamera()
            } else {
                explainWhyPermissionNeeded()
            }
        }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        checkCameraPermission()
    }

    private fun checkCameraPermission() {
        when {
            ContextCompat.checkSelfPermission(this,
                Manifest.permission.CAMERA
            ) == PackageManager.PERMISSION_GRANTED -> {
                openCamera()
            }
            shouldShowRequestPermissionRationale(
                Manifest.permission.CAMERA
            ) -> {
                showRationale()
            }
            else -> {
                requestPermissionLauncher.launch(
                    Manifest.permission.CAMERA
                )
            }
        }
    }
}

Hantering av ”Fråga inte igen”-vägran

Om användaren har nekat behörigheten två gånger, överför Android begäran till status ”Never ask again”. I detta fall returnerar shouldShowRequestPermissionRationale() false, och systemdialogen kommer inte att visas. Appen måste dirigera användaren till systeminställningarna via Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).

Viktigt: visa inte en dialog med förslag om att öppna inställningar direkt efter första vägran — detta uppfattas som aggressivt beteende. Använd shouldShowRequestPermissionRationale() för att avgöra om en förklaring behöver visas. Material Design Guidelines rekommenderar att visa en skärm med en förklaring av värdet av åtkomst, inte bara en knapp ”Öppna inställningar”.

private fun openAppSettings() {
    Intent(
        Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
        Uri.fromParts("package", packageName, null)
    ).also { intent ->
        startActivity(intent)
    }
}

private fun showPermissionSettings() {
    AlertDialog.Builder(this)
        .setTitle("Åtkomst till kamera")
        .setMessage("Tillåt åtkomst till kameran i Inställningar, "
            + "för att ta profilfoton")
        .setPositiveButton("Öppna inställningar") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("Avbryt", null)
        .show()
}

Deklaration av behörigheter i AndroidManifest.xml

Filen AndroidManifest.xml innehåller elementet <uses-permission> för varje behörighet som appen använder. Behörigheter deklareras på nivån <manifest> före elementet <application>.

Syntax för deklaration

Varje behörighet deklareras som ett separat element <uses-permission> med attributet android:name som anger behörighetens fullständiga namn. För behörigheter som har dykt upp i specifika Android-versioner, använd attributet maxSdkVersion för att begränsa deklarationen till endast nödvändiga versioner — detta förbättrar kompatibiliteten.

Till exempel behövs inte behörigheten WRITE_EXTERNAL_STORAGE på Android 10+ (Scoped Storage), så ange maxSdkVersion=”28” (Android 9). Detta förhindrar onödiga frågor från användare på nyare versioner. Android Studio varnar om rekommenderade maxSdkVersion via Lint.

<!-- AndroidManifest.xml -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions (install-time) -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.ACCESS_NETWORK_STATE" />

    <!-- Dangerous permissions (runtime) -->
    <uses-permission
        android:name="android.permission.CAMERA" />
    <uses-permission
        android:name="android.permission.ACCESS_FINE_LOCATION" />

    <!-- Legacy storage permission limited to API 28 and below -->
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28" />

    <uses-feature
        android:name="android.hardware.camera"
        android:required="false" />

    <application>
        <!-- ... -->
    </application>
</manifest>

Användning av <uses-feature> för filtrering

Elementet <uses-feature> anger att appen kräver specifik hårdvara (kamera, GPS, NFC). Attributet android:required=”false” tillåter installation av appen på enheter utan denna hårdvara — tillgänglighetskontroll görs i koden. Om required=”true” filtrerar Google Play appen och den blir otillgänglig för olämpliga enheter.

Det rekommenderas att för alla hårdvarufunktioner ange required=”false” och kontrollera tillgängligheten programmatiskt via PackageManager.hasSystemFeature(). Detta utökar publiken för din app. Det enda undantaget är när funktionen är kritisk för appens funktion (en taxi-app utan GPS är meningslös).

Bästa praxis och misstag

Korrekt arbete med behörigheter är en nyckelaspekt av kvaliteten på en Android-app. Låt oss gå igenom de viktigaste rekommendationerna och typiska misstagen.

Minimera begärda behörigheter

Begär endast de behörigheter som verkligen är nödvändiga för appens funktion. Varje extra behörighet minskar installationskonverteringen och ökar antalet avslag. Google Play Console visar hur många användare som avstått från installation på grund av behörighetsuppsättningen. Enligt AppBrain (2024) har appar med 10+ dangerous-behörigheter 35% färre installationer.

Granska regelbundet listan över behörigheter. Ta bort oanvända, särskilt vid övergång till nyare Android-versioner där vissa behörigheter har blivit valfria. Till exempel med introduktionen av fotoväljaren (ActivityResultContracts.PickVisualMedia) i Android 13+ kan åtkomst till mediebiblioteket erhållas utan dangerous-behörigheten READ_MEDIA_IMAGES.

Visa rationale före begäran

Innan du begär en dangerous-behörighet, visa en skärm med en förklaring till varför denna behörighet behövs och vilket värde den ger. Material Design rekommenderar att använda en bottom sheet eller dialog med ikon, kort text och en knapp ”Fortsätt”. Rationale ökar samtycket med 20–30% jämfört med direkt begäran.

Kontrollera shouldShowRequestPermissionRationale() innan du anropar launch(). Om den är true — visa rationale. Om den är false — antingen har behörigheten redan beviljats eller så har användaren permanent nekat (never ask again). I det senare fallet, visa knappen ”Öppna inställningar”, upprepa inte begäran.

Testa alla behörighetsscenarier

Testa alla möjliga scenarier: beviljande av behörighet, avslag, permanent avslag, återkallelse av behörighet i inställningar, återställning av behörigheter (Android 11+ auto-reset). Varje scenario måste hanteras utan krasch och utan dataförlust. Android Testing Guide rekommenderar att använda biblioteket TestPermission för att automatisera testning.

Var särskilt uppmärksam på scenariot när användaren återkallar behörigheten medan appen körs (minimerad app → Inställningar → återkallelse). Vid återgång till appen, kontrollera alla behörigheter igen via onResume(). Lita inte på cachning av behörighetsstatus — användaren kan ändra dem när som helst.

Typiska misstag

• Begäran av behörighet utan föregående kontroll av checkSelfPermission — orsakar onödig dialog
• Ignorera shouldShowRequestPermissionRationale — försämrar användarupplevelsen efter första avslaget
• Begäran av behörighet utan sammanhang (endast ”Tillåt åtkomst?”) — minskar samtycke
• Användning av WRITE_EXTERNAL_STORAGE på Android 10+ utan maxSdkVersion — onödig begäran
• Brist på behörighetskontroll i onResume — missar återkallelse av behörighet i inställningar