AndroidManifest Permissions: Schlüsselkonzepte, Deklaration und Arten von Berechtigungen

Was sind AndroidManifest Permissions?

AndroidManifest Permissions ist der Sicherheitsmechanismus von Android, der den Zugriff von Anwendungen auf geschützte Daten und Systemfunktionen steuert. Jede Anwendung muss die erforderlichen Berechtigungen in der Datei AndroidManifest.xml mit dem Element deklarieren. Ohne Deklaration führt der Aufruf der entsprechenden API zu einem Sicherheitsfehler SecurityException.

Das Android-Berechtigungsmodell hat mehrere Entwicklungsstufen durchlaufen. Vor Android 6.0 (API 23) wurden alle Berechtigungen bei der Installation erteilt — der Benutzer sah die vollständige Liste und stimmte der Installation der Anwendung zu oder lehnte sie ab. Ab Android 6.0 werden Berechtigungen der Stufe dangerous zur Laufzeit (Runtime Permissions) angefordert, was dem Benutzer eine flexiblere Kontrolle gibt.

Berechtigungen werden in vier Schutzstufen unterteilt: normal (automatisch bei Installation erteilt), dangerous (erfordern Laufzeitanforderung), signature (nur für Anwendungen verfügbar, die mit demselben Zertifikat signiert sind) und special (erfordern separate Aktivierung in den Einstellungen). Jede Stufe hat ihren eigenen Gewährungs- und Widerrufsmechanismus.

Laut Google I/O 2024 plant Android 15 die Einführung granularerer Berechtigungen — der Benutzer kann den Zugriff nur auf bestimmte Dateien in der Medienbibliothek gewähren, nicht auf die gesamte Sammlung. Dies setzt den Trend von Android fort, die standardmäßig bereitgestellte Datenmenge zu minimieren.

Unterschied zum iOS-Berechtigungsmodell

Im Gegensatz zu iOS, wo alle Berechtigungen zur Laufzeit angefordert werden, unterteilt Android Berechtigungen in Installationszeit- und Laufzeitberechtigungen. Die Stufe normal wird automatisch bei der Installation ohne Benachrichtigung des Benutzers erteilt. Die Stufe dangerous erfordert einen expliziten Dialog, ähnlich wie bei iOS.

Ein weiterer Unterschied: In Android sind Berechtigungen in Berechtigungsgruppen zusammengefasst. Wenn der Benutzer dem Kamerazugriff zustimmt, erhält die Anwendung automatisch Zugriff auf das Mikrofon — sie befinden sich in derselben MICROPHONE-Gruppe. In iOS wird jede Berechtigung unabhängig von Gruppen separat angefordert.

Entwicklung der Berechtigungen nach Android-Versionen

Welche Arten von Berechtigungen gibt es?

Android definiert vier Schutzstufen für Berechtigungen, jede mit eigenen Gewährungsregeln. Sehen wir uns jede Stufe im Detail an.

Normal-Berechtigungen (Installationszeit)

Normal-Berechtigungen werden automatisch bei der Installation der Anwendung ohne Benachrichtigung oder Aufforderung an den Benutzer erteilt. Sie decken risikoarme Funktionen ab, die die Privatsphäre des Benutzers nicht gefährden: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. Der Benutzer sieht keinen Zustimmungsdialog — die Berechtigung gilt ab der Installation als erteilt.

Der Entwickler muss für Normal-Berechtigungen keine Anfrage im Code behandeln — die Deklaration im Manifest ist ausreichend. Allerdings sieht der Benutzer ab Android 12+ bei der Installation aus Google Play einen Tab „Berechtigungen“ mit Auflistung aller Normal-Berechtigungen, was die Transparenz erhöht. Laut Statista (2024) verwenden über 90% der Apps bei Google Play INTERNET als häufigste Normal-Berechtigung.

Dangerous-Berechtigungen (Laufzeit)

Dangerous-Berechtigungen decken den Zugriff auf Daten und Funktionen ab, die die Privatsphäre gefährden können: Kamera, Mikrofon, Geolokalisierung, Kontakte, SMS, Telefon, Kalender, Körpersensoren. Diese Berechtigungen erfordern einen zweistufigen Mechanismus: Deklaration im Manifest + Laufzeitanforderung über ActivityCompat.requestPermissions().

Der Benutzer kann eine dangerous-Berechtigung verweigern, und die Anwendung muss dieses Szenario korrekt behandeln. Unter Android 11+ wird bei zweimaliger Verweigerung der Systemdialog bei nachfolgenden Anfragen nicht mehr angezeigt — das System gibt automatisch DENIED zurück. In diesem Fall sollte die Anwendung den Benutzer zu den Einstellungen führen.

Signature- und Special-Berechtigungen

Die signature-Stufe — die Berechtigung wird automatisch erteilt, wenn die Anwendung mit demselben Zertifikat signiert ist wie das System oder eine andere Anwendung, die die Berechtigung definiert hat. Wird für System- und Unternehmensanwendungen verwendet. Beispiel: BIND_ACCESSIBILITY_SERVICE — nur für Systemanwendungen verfügbar.

Die special-Stufe (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — erfordert eine explizite Benutzeraktion über die Systemeinstellungen. Die Anwendung kann die Einstellungsseite mit Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION) öffnen. Google Play schränkt die Verwendung von special-Berechtigungen ein und verlangt bei der Veröffentlichung eine Begründung im Formular.

Runtime Permission: Arbeiten mit dangerous-Berechtigungen

Seit Android 6.0 erfordern alle dangerous-Berechtigungen eine Laufzeitanforderung. Sehen wir uns den vollständigen Arbeitszyklus mit Runtime Permissions in Kotlin an.

Prüfen und Anfordern von Berechtigungen

Prüfen Sie vor dem Aufruf einer API, die eine dangerous-Berechtigung erfordert, immer den aktuellen Status über ContextCompat.checkSelfPermission(). Bei Status PERMISSION_GRANTED können Sie die API aufrufen. Bei PERMISSION_DENIED müssen Sie die Berechtigung über ActivityResultContract RequestPermission (AndroidX) oder das veraltete requestPermissions() anfordern.

Es wird empfohlen, ActivityResultContracts.RequestMultiplePermissions zu verwenden, um mehrere Berechtigungen gleichzeitig anzufordern. Google empfiehlt, zusammengehörige Berechtigungen (z.B. Kamera + Mikrofon für Videoaufnahmen) in einem Dialog zu gruppieren, damit der Benutzer den vollständigen Anforderungskontext sieht.

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

Behandlung der Verweigerung „Nicht erneut fragen“

Wenn der Benutzer zweimal verweigert, versetzt Android die Anfrage in den Status „Never ask again“. In diesem Fall gibt shouldShowRequestPermissionRationale() false zurück, und der Systemdialog wird nicht angezeigt. Die Anwendung sollte den Benutzer über Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS) zu den Systemeinstellungen führen.

Wichtig: Zeigen Sie nicht sofort nach der ersten Verweigerung einen Dialog an, der zum Öffnen der Einstellungen auffordert — dies wird als aggressives Verhalten wahrgenommen. Verwenden Sie shouldShowRequestPermissionRationale(), um zu bestimmen, ob eine Erklärung erforderlich ist. Die Material Design Guidelines empfehlen, einen Bildschirm mit einer Erklärung des Werts des Zugriffs anzuzeigen, nicht nur eine Schaltfläche „Einstellungen öffnen“.

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("Kamerazugriff")
        .setMessage("Kamerazugriff in den Einstellungen erlauben, "
            + "um Profilfotos aufzunehmen")
        .setPositiveButton("Einstellungen öffnen") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("Abbrechen", null)
        .show()
}

Deklaration von Berechtigungen in AndroidManifest.xml

Die Datei AndroidManifest.xml enthält das Element für jede Berechtigung, die die Anwendung verwendet. Berechtigungen werden auf der Ebene vor dem Element deklariert.

Deklarationssyntax

Jede Berechtigung wird mit einem separaten -Element mit dem Attribut android:name deklariert, das den vollständigen Berechtigungsnamen angibt. Für Berechtigungen, die in bestimmten Android-Versionen eingeführt wurden, verwenden Sie das Attribut maxSdkVersion, um die Deklaration auf die erforderlichen Versionen zu beschränken — dies verbessert die Kompatibilität.

Beispielsweise wird die Berechtigung WRITE_EXTERNAL_STORAGE unter Android 10+ (Scoped Storage) nicht benötigt, geben Sie also maxSdkVersion="28" (Android 9) an. Dies verhindert unnötige Fragen von Benutzern auf neueren Versionen. Android Studio warnt über Lint vor empfohlenen maxSdkVersion.

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

Verwendung von zur Filterung

Das Element gibt an, dass die Anwendung bestimmte Hardware (Kamera, GPS, NFC) benötigt. Das Attribut android:required="false" ermöglicht die Installation der Anwendung auf Geräten ohne diese Hardware — die Verfügbarkeit wird im Code geprüft. Bei required="true" filtert Google Play die Anwendung und macht sie für ungeeignete Geräte nicht verfügbar.

Es wird empfohlen, für alle Hardwarefunktionen required="false" zu setzen und die Verfügbarkeit programmatisch über PackageManager.hasSystemFeature() zu prüfen. Dies erweitert die Zielgruppe Ihrer Anwendung. Die einzige Ausnahme ist, wenn die Funktion für den Betrieb der Anwendung kritisch ist (eine Taxi-App ohne GPS ergibt keinen Sinn).

Bewährte Praktiken und Fehler

Der richtige Umgang mit Berechtigungen ist ein Schlüsselaspekt der Qualität von Android-Anwendungen. Sehen wir uns die wichtigsten Empfehlungen und typischen Fehler an.

Minimierung der angeforderten Berechtigungen

Fordern Sie nur die Berechtigungen an, die für den Betrieb der Anwendung wirklich notwendig sind. Jede zusätzliche Berechtigung senkt die Installationskonversionsrate und erhöht die Anzahl der Ablehnungen. Die Google Play Console zeigt, wie viele Benutzer die Installation aufgrund des Berechtigungssatzes abgelehnt haben. Laut AppBrain (2024) haben Anwendungen mit 10+ dangerous-Berechtigungen 35% weniger Installationen.

Prüfen Sie regelmäßig Ihre Berechtigungsliste. Entfernen Sie ungenutzte Berechtigungen, insbesondere bei der Migration auf neuere Android-Versionen, in denen einige Berechtigungen optional werden. Beispielsweise kann mit der Fotoauswahl (ActivityResultContracts.PickVisualMedia) unter Android 13+ der Medienbibliothekszugriff ohne die dangerous-Berechtigung READ_MEDIA_IMAGES erfolgen.

Erklärung vor der Anfrage anzeigen

Zeigen Sie dem Benutzer vor der Anforderung einer dangerous-Berechtigung einen Bildschirm, der erklärt, warum diese Berechtigung benötigt wird und welchen Nutzen sie bietet. Material Design empfiehlt die Verwendung eines Bottom Sheets oder Dialogs mit einem Symbol, kurzem Text und einer Schaltfläche „Fortfahren“. Eine Erklärung erhöht die Zustimmung um 20–30% im Vergleich zu einer direkten Anfrage.

Prüfen Sie shouldShowRequestPermissionRationale() vor dem Aufruf von launch(). Bei true zeigen Sie die Erklärung an. Bei false ist die Berechtigung entweder bereits erteilt oder der Benutzer hat sie dauerhaft verweigert (never ask again). Im letzteren Fall zeigen Sie eine Schaltfläche „Einstellungen öffnen“ an, anstatt die Anfrage zu wiederholen.

Testen aller Berechtigungsszenarien

Testen Sie alle möglichen Szenarien: Erteilen der Berechtigung, Verweigerung, dauerhafte Verweigerung, Widerruf der Berechtigung in den Einstellungen, Zurücksetzen von Berechtigungen (Auto-Reset ab Android 11+). Jedes Szenario sollte ohne Abstürze oder Datenverlust behandelt werden. Der Android Testing Guide empfiehlt die Verwendung der TestPermission-Bibliothek zur Automatisierung von Tests.

Besondere Aufmerksamkeit gilt dem Szenario, in dem der Benutzer eine Berechtigung während der Ausführung der Anwendung widerruft (Anwendung minimiert → Einstellungen → Widerruf). Prüfen Sie bei der Rückkehr zur Anwendung alle Berechtigungen in onResume(). Verlassen Sie sich nicht auf das Caching des Berechtigungsstatus — der Benutzer kann ihn jederzeit ändern.

Typische Fehler

• Anfordern einer Berechtigung ohne vorherige Prüfung von checkSelfPermission — löst unnötigen Dialog aus
• Ignorieren von shouldShowRequestPermissionRationale — verschlechtert UX nach erster Verweigerung
• Anfordern einer Berechtigung ohne Kontext (nur „Zugriff erlauben?“) — verringert Zustimmung
• Verwendung von WRITE_EXTERNAL_STORAGE unter Android 10+ ohne maxSdkVersion — unnötige Anfrage
• Fehlende Berechtigungsprüfung in onResume — Übersehen des Widerrufs von Berechtigungen in den Einstellungen