AndroidManifest Permissions: kulcsfogalmak, deklarálás és engedélytípusok

Mik az AndroidManifest Permissions?

Az AndroidManifest Permissions az Android biztonsági mechanizmusa, amely szabályozza az alkalmazások hozzáférését a védett adatokhoz és rendszerfunkciókhoz. Minden alkalmazásnak deklarálnia kell a szükséges engedélyeket az AndroidManifest.xml fájlban a <uses-permission> elem segítségével. Deklaráció nélkül a megfelelő API meghívása SecurityException biztonsági hibával végződik.

Az Android engedélymodell több fejlődési szakaszon ment keresztül. Az Android 6.0 (API 23) előtt minden engedélyt telepítéskor adtak meg — a felhasználó látta a teljes listát, és elfogadta vagy elutasította az alkalmazás telepítését. Az Android 6.0-tól kezdve a dangerous szintű engedélyek futásidőben (Runtime Permissions) kérendők, ami rugalmasabb ellenőrzést biztosít a felhasználónak.

Az engedélyek négy védelmi szintre oszlanak: normal (automatikusan megadva telepítéskor), dangerous (futásidejű kérést igényel), signature (csak azonos tanúsítvánnyal aláírt alkalmazások számára elérhető) és special (külön engedélyezést igényel a beállításokban). Minden szintnek megvan a saját megadási és visszavonási mechanizmusa.

A Google I/O 2024 szerint az Android 15-ben részletesebb engedélyek bevezetését tervezik — a felhasználó csak bizonyos fájlokhoz adhat hozzáférést a médiatárban, nem a teljes könyvtárhoz. Ez folytatja az Android azon trendjét, hogy minimalizálja az alapértelmezetten megadott adatok mennyiségét.

Különbség az iOS engedélymodelltől

Az iOS-szel ellentétben, ahol minden engedély futásidőben (runtime) kérendő, az Android az engedélyeket telepítési (install-time) és futásidejű (runtime) kategóriákra osztja. A normal szint automatikusan megadásra kerül telepítéskor, a felhasználó értesítése nélkül. A dangerous szint kifejezett párbeszédablakot igényel, mint az iOS-ben.

Egy másik különbség: az Androidban az engedélyek csoportokba (permission groups) vannak rendezve. Ha a felhasználó elfogadta a kamerához való hozzáférést, az alkalmazás automatikusan hozzáfér a mikrofonhoz — ugyanabban a MICROPHONE csoportban vannak. Az iOS-ben minden engedély külön-külön kérendő, a csoporttól függetlenül.

Az engedélyek fejlődése Android-verziónként

Milyen engedélytípusok léteznek

Az Android négy védelmi szintet (protection levels) határoz meg az engedélyekhez, mindegyik saját megadási szabályokkal. Vizsgáljuk meg részletesen az egyes szinteket.

Normal Permissions (install-time)

A normal engedélyek automatikusan megadásra kerülnek az alkalmazás telepítésekor, a felhasználó értesítése vagy kérése nélkül. Ezek alacsony kockázatú funkciókhoz való hozzáférést fednek le, amelyek nem veszélyeztetik a felhasználó adatvédelmét: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. A felhasználó nem lát hozzájárulási párbeszédablakot — az engedély a telepítés tényével megadottnak tekintendő.

A fejlesztőnek nem kell feldolgoznia a kérést a kódban a normal engedélyekhez — elég deklarálni azokat a manifestben. Az Android 12+-ban azonban a Google Play-ből történő telepítéskor a felhasználó látja az „Engedélyek” fület az összes normal engedély listájával, ami növeli az átláthatóságot. A Statista (2024) szerint a Google Play alkalmazásainak több mint 90%-a használja az INTERNET-et a leggyakoribb normal engedélyként.

Dangerous Permissions (runtime)

A dangerous engedélyek olyan adatokhoz és funkciókhoz való hozzáférést fednek le, amelyek sérthetik a magánéletet: kamera, mikrofon, geolokáció, névjegyek, SMS, telefon, naptár, testérzékelők. Ezek az engedélyek kétlépcsős mechanizmust igényelnek: deklarálást a manifestben + futásidejű kérést az ActivityCompat.requestPermissions() segítségével.

A felhasználó megtagadhatja a dangerous engedély megadását, és az alkalmazásnak megfelelően kell kezelnie ezt a forgatókönyvet. Az Android 11+-ban, ha a felhasználó kétszer elutasította, a későbbi kérések nem jelenítik meg a rendszer párbeszédablakát — a rendszer automatikusan DENIED értékkel tér vissza. Ebben az esetben a felhasználót a beállításokhoz kell irányítani.

Signature és Special Permissions

A signature szint — az engedély automatikusan megadásra kerül, ha az alkalmazás ugyanazzal a tanúsítvánnyal van aláírva, mint a rendszer vagy egy másik alkalmazás, amely meghatározta az engedélyt. Rendszer- és vállalati alkalmazásokhoz használatos. Példa: BIND_ACCESSIBILITY_SERVICE — csak rendszeralkalmazások számára elérhető.

A special szint (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — a felhasználó külön műveletét igényli a rendszerbeállításokon keresztül. Az alkalmazás megnyithatja a beállítások oldalát az Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION) segítségével. A Google Play korlátozza a special engedélyek használatát, és indoklást kér a közzétételkor.

Runtime Permission: munka dangerous engedélyekkel

Az Android 6.0-tól kezdve minden dangerous engedély futásidőben történő kérést igényel. Vizsgáljuk meg a runtime permissions teljes munkaciklusát Kotlinban.

Engedély ellenőrzése és kérése

Mielőtt meghívna egy olyan API-t, amely dangerous engedélyt igényel, mindig ellenőrizze az aktuális állapotot a ContextCompat.checkSelfPermission() segítségével. Ha az állapot PERMISSION_GRANTED — az API meghívható. Ha PERMISSION_DENIED — az engedélyt kérni kell az ActivityResultContract RequestPermission (AndroidX) vagy az elavult requestPermissions() segítségével.

Ajánlott a ActivityResultContracts.RequestMultiplePermissions használata több engedély egyidejű kéréséhez. A Google javasolja a kapcsolódó engedélyek (pl. kamera + mikrofon videófelvételhez) egy párbeszédablakba csoportosítását, hogy a felhasználó lássa a kérés teljes kontextusát.

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

A „Ne kérdezze újra” elutasítás kezelése

Ha a felhasználó kétszer elutasította az engedélyt, az Android „Never ask again” állapotba helyezi a kérést. Ebben az esetben a shouldShowRequestPermissionRationale() false értékkel tér vissza, és a rendszer párbeszédablaka nem jelenik meg. Az alkalmazásnak a Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS) segítségével a rendszerbeállításokhoz kell irányítania a felhasználót.

Fontos: ne jelenítsen meg párbeszédablakot a beállítások megnyitásának javaslatával közvetlenül az első elutasítás után — ez agresszív viselkedésnek minősül. Használja a shouldShowRequestPermissionRationale() függvényt annak meghatározására, hogy szükséges-e magyarázatot megjeleníteni. A Material Design Guidelines azt javasolja, hogy egy képernyőt jelenítsen meg a hozzáférés értékének magyarázatával, ne csak egy „Beállítások megnyitása” gombot.

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("Hozzáférés a kamerához")
        .setMessage("Engedélyezze a kamerához való hozzáférést a Beállításokban, "
            + "hogy profilfotót készíthessen")
        .setPositiveButton("Beállítások megnyitása") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("Mégse", null)
        .show()
}

Engedélyek deklarálása az AndroidManifest.xml fájlban

Az AndroidManifest.xml fájl tartalmazza a <uses-permission> elemet minden olyan engedélyhez, amelyet az alkalmazás használ. Az engedélyek a <manifest> szinten, a <application> elem előtt kerülnek deklarálásra.

A deklarálás szintaxisa

Minden engedély egy külön <uses-permission> elemként kerül deklarálásra az android:name attribútummal, amely az engedély teljes nevét jelöli. Azokhoz az engedélyekhez, amelyek bizonyos Android-verziókban jelentek meg, használja a maxSdkVersion attribútumot a deklarálás csak a szükséges verziókra korlátozásához — ez javítja a kompatibilitást.

Például a WRITE_EXTERNAL_STORAGE engedély nem szükséges Android 10+ (Scoped Storage) rendszeren, ezért adja meg a maxSdkVersion=„28” (Android 9) értéket. Ez megakadályozza a felesleges kérdéseket a felhasználóktól az újabb verziókon. Az Android Studio a Lint segítségével figyelmeztet az ajánlott maxSdkVersion értékekre.

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

A <uses-feature> használata szűréshez

A <uses-feature> elem meghatározza, hogy az alkalmazás bizonyos hardvert (kamera, GPS, NFC) igényel. Az android:required=„false” attribútum lehetővé teszi az alkalmazás telepítését az adott hardver nélküli eszközökre — az elérhetőség ellenőrzése a kódban történik. Ha a required=„true”, a Google Play szűri az alkalmazást, és az nem lesz elérhető a nem megfelelő eszközök számára.

Ajánlott minden hardverfunkcióhoz a required=„false” értéket megadni, és az elérhetőséget programozottan ellenőrizni a PackageManager.hasSystemFeature() segítségével. Ez bővíti az alkalmazás közönségét. Az egyetlen kivétel, ha a funkció kritikus az alkalmazás működése szempontjából (egy taxirendelő alkalmazás GPS nélkül értelmetlen).

Legjobb gyakorlatok és hibák

Az engedélyekkel való helyes munka az Android-alkalmazás minőségének kulcsfontosságú szempontja. Vizsgáljuk meg a főbb javaslatokat és tipikus hibákat.

A kérelmezett engedélyek minimalizálása

Csak azokat az engedélyeket kérelmezze, amelyek valóban szükségesek az alkalmazás működéséhez. Minden további engedély csökkenti a telepítési konverziót és növeli az elutasítások számát. A Google Play Console megmutatja, hány felhasználó állt el a telepítéstől az engedélykészlet miatt. A AppBrain (2024) szerint a 10+ dangerous engedéllyel rendelkező alkalmazásoknak 35%-kal kevesebb telepítésük van.

Rendszeresen tekintse át az engedélyek listáját. Távolítsa el a nem használtakat, különösen az újabb Android-verziókra való áttéréskor, ahol egyes engedélyek opcionálissá váltak. Például a fotóválasztó (ActivityResultContracts.PickVisualMedia) megjelenésével Android 13+-ban a médiatárhoz való hozzáférés a READ_MEDIA_IMAGES dangerous engedély nélkül is elérhető.

Indoklás megjelenítése a kérés előtt

A dangerous engedély kérelmezése előtt jelenítsen meg a felhasználónak egy képernyőt, amely elmagyarázza, miért van szükség erre az engedélyre, és milyen értéket nyújt. A Material Design egy alsó lap (bottom sheet) vagy párbeszédablak használatát javasolja ikonnal, rövid szöveggel és egy „Folytatás” gombbal. Az indoklás 20–30%-kal növeli a hozzájárulást a közvetlen kéréshez képest.

Ellenőrizze a shouldShowRequestPermissionRationale() függvényt a launch() meghívása előtt. Ha true — jelenítse meg az indoklást. Ha false — vagy az engedély már megadásra került, vagy a felhasználó végleg elutasította (never ask again). Az utóbbi esetben jelenítsen meg egy „Beállítások megnyitása” gombot, ne ismételje meg a kérést.

Az összes engedélyforgatókönyv tesztelése

Tesztelje az összes lehetséges forgatókönyvet: engedély megadása, elutasítás, végleges elutasítás, engedély visszavonása a beállításokban, engedélyek visszaállítása (Android 11+ auto-reset). Minden forgatókönyvet crash és adatvesztés nélkül kell kezelni. Az Android Testing Guide a TestPermission könyvtár használatát javasolja a tesztelés automatizálásához.

Különös figyelmet fordítson arra a forgatókönyvre, amikor a felhasználó visszavonja az engedélyt az alkalmazás működése közben (minimalizált alkalmazás → Beállítások → visszavonás). Az alkalmazásba való visszatéréskor ellenőrizze újra az összes engedélyt az onResume() segítségével. Ne támaszkodjon az engedélyállapot gyorsítótárazására — a felhasználó bármikor módosíthatja azokat.

Tipikus hibák

• Engedély kérése előzetes checkSelfPermission ellenőrzés nélkül — szükségtelen párbeszédablakot okoz
• A shouldShowRequestPermissionRationale figyelmen kívül hagyása — rontja a felhasználói élményt az első elutasítás után
• Engedély kérése kontextus nélkül (csak „Hozzáférés engedélyezése?”) — csökkenti a hozzájárulást
• A WRITE_EXTERNAL_STORAGE használata Android 10+-on maxSdkVersion nélkül — szükségtelen kérés
• Engedélyek ellenőrzésének hiánya az onResume-ban — az engedély beállításokban történő visszavonásának elmulasztása