Warum deine App niemals Zugriff auf die Kamera bekommt.
Permissions – der heilige Gral der Android-App-Entwicklung. Du kannst den Zugriff auf nahezu alles verlangen: das Mikrofon, den Standort, die Kamera. Aber die Antwort auf all diese Wünsche lautet immer: „Nein, nein und noch mal nein.“ Oder zumindest fühlt es sich so an, wenn du versuchst, die mysteriöse Welt der Berechtigungen zu entwirren.
In den ersten Tagen deiner App-Entwicklung magst du noch denken: „Ich frage einfach die Berechtigung an, und schon funktioniert alles!“ Aber keine Sorge, nach einigen Stunden voller Abstürze, bösem Code und einem gescheiterten Testlauf wirst du wissen: So einfach ist das nicht.
Die alte Welt: permissions.xml
Früher, als Android noch ein kleines, chaotisches Wildwestland war, genügte es, eine permissions.xml-Datei in deiner App zu haben und ein paar Zeilen in dein Manifest zu packen. Zack, fertig!
Du wolltest auf die Kamera zugreifen? Dann hast du einfach das CAMERA-Permission in dein Manifest eingefügt, und voilà – deine App konnte mit der Kamera kommunizieren, als wärst du der CEO von Android.
Aber der Wind hat sich gedreht. Und jetzt gibt es ein Problem: Runtime Permissions. Und mit denen hat Android dir so richtig eine reingewirkt.
Die neue Welt: Runtime Permissions
Seit Android 6.0 (Marshmallow) hat Google beschlossen, uns zu „beschützen“. Du kannst jetzt nicht einfach alle Berechtigungen verlangen und hoffen, dass der Nutzer dir vertraut. Nein, du musst ihm jedes Mal explizit zeigen, warum du eine Berechtigung brauchst. Und damit beginnt der Spaß.
Erst musst du herausfinden, ob du die Berechtigung bereits hast. Wenn ja, weiter geht’s! Wenn nein? Dann musst du eine „Berechtigungsanfrage“ starten – und das Ganze geht nicht einfach in einem Rutsch. Der Nutzer muss das explizit akzeptieren oder ablehnen. Und selbst dann gibt es noch den ominösen Fall von „Never Ask Again“.
Was bedeutet „Never Ask Again“?
Ganz einfach: Der Nutzer hat die Berechtigung einmal abgelehnt, und Android wird niemals wieder fragen. Wenn du Glück hast, wird er nie wieder auf die Funktion zugreifen können. Wenn du Pech hast, wirst du nie wieder wissen, wie du ihm beibringen sollst, dass seine Kamera und dein App-Traum eine perfekte Symbiose bilden können.
Der Ablauf: Ein typischer Permission-Wahnsinn
Nehmen wir an, du willst auf die Kamera zugreifen. Du denkst, das geht schnell, also hast du es in deinem Manifest und der App läuft. Aber du bist nicht im Wilden Westen mehr. Heute läuft es so:
Überprüfen der Berechtigung:
Du fängst an, indem du die Berechtigung überprüfst. Ist sie erteilt oder nicht? Wie im echten Leben, weißt du nie, ob dein Antrag angenommen wird – aber du kannst darauf hoffen.
if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) == PackageManager.PERMISSION_GRANTED) {
// Berechtigung erteilt, Kamera öffnen
}Wenn nicht, frage nach der Berechtigung:
Ist die Berechtigung nicht erteilt? Jetzt kommt der Moment der Wahrheit. Du kannst die Berechtigung anfordern und die Antwort in der Rückruffunktion onRequestPermissionsResult() abfangen.
ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.CAMERA}, REQUEST_CAMERA);Der Nutzer hat jetzt drei Optionen:
- Er gewährt die Berechtigung.
- Er lehnt sie ab.
- Er lehnt sie ab und wählt „Never Ask Again“.
Du wirst mit all diesen Optionen umgehen müssen. Dabei ist das Entscheidende: Sei vorsichtig, wie du es dem Nutzer präsentierst. Denn eine falsch formulierte Anfrage und eine verzweifelte App können dazu führen, dass der Nutzer einfach aufgibt und die Berechtigung ablehnt, ohne weiter nachzudenken.
Der schwierige Fall: “Never Ask Again”
Das „Never Ask Again“-Flag ist der Albtraum eines jeden Android-Entwicklers.
Stell dir vor, der Nutzer lehnt die Berechtigung ab – aus welchen Gründen auch immer – und setzt das Häkchen bei „Nie wieder fragen“. Und was passiert dann? Nichts.
In vielen Fällen bleibt der Button „Kamera verwenden“ in der App, aber der Nutzer kann ihn nicht mehr benutzen. Und du? Du kannst die Berechtigung nicht erneut anfordern. Das heißt, du kannst ihn nur zu den Einstellungen schicken, aber da sind wir wieder im Dschungel der App-Navigation. Denn weißt du, wie der Nutzer zu den App-Einstellungen kommt? Und noch viel wichtiger: Weiß der Nutzer, was er dort tun muss?
Deshalb: Wenn du den Nutzer zu den Einstellungen führst, erkläre ihm im Voraus, was er dort tun muss. Sonst landest du in der Nutzer-„Kehre-ich-mal-wieder-ab“-Hölle.
Die mysteriöse Welt der „Notwendigen Berechtigungen“
Manchmal kannst du mit einer Berechtigung in den App-Einstellungen landen und feststellen, dass sie dort in einer Liste von „Notwendigen Berechtigungen“ auftaucht. Dann beginnst du zu fragen: “Warum?” Und Android erklärt dir, dass es diese Berechtigungen tatsächlich nur in sehr speziellen Fällen benötigt. Deine App ist vielleicht eine von vielen, die dich bei jeder einzelnen Anfrage nerven. Vielleicht ein bisschen zu oft.
Die Lektion hier? Nimm keine Berechtigungen ohne Not. Sei dir der Auswirkungen bewusst, dass der Nutzer eine Menge Fragen stellen wird, wenn deine App ständig nach Berechtigungen fragt. Diese Fragen werden nicht immer nett sein.
Fazit: Permissions – Die Kunst des Überlebens
Permissions sind, mit anderen Worten, der große Test der Geduld und des Nutzerservices. Du musst sie geschickt verwenden und mit dem gleichen Respekt behandeln, wie ein nervöser Bankangestellter, der einen Kredit beantragt. Nutze sie nur, wenn es wirklich nötig ist, und immer mit einer klaren Erklärung, warum du sie brauchst. Und selbst dann bleib immer auf dem neuesten Stand der Android-Richtlinien, denn was gestern noch okay war, kann morgen ein Grund sein, deine App aus dem Play Store zu werfen.
Wenn du diese Regeln befolgst, hast du zumindest eine Chance, nicht mit einer „App wurde beendet“-Meldung konfrontiert zu werden – zumindest nicht aufgrund eines falschen Umgangs mit Berechtigungen.
Und am Ende wirst du feststellen: Ja, du hast die Kamera erhalten. Aber für einen Moment hast du geglaubt, sie wäre ein Mythos, wie der heilige Gral der Entwickler-Welt.
Über das Buch „Schöner sterben mit Android“
Ein satirischer Ratgeber für alle, die mutig genug sind, Android-Apps zu entwickeln – und dabei regelmäßig an Emulatoren, Lifecycles und Gradle zerbrechen. Mit bitterem Humor und liebevollem Spott schildert das Buch die kleinen Katastrophen des Entwickleralltags. Ideal für alle, die beim Debuggen lieber lachen als weinen wollen. Die Kapitel und Inhalte dieses Buches wurden mit der Unterstützung von KI erstellt.
Um das nächste Kapitel nicht zu verpassen, abonniere den Newsletter, oder schau auf meinem YouTube Kanal vorbei, um die Podcast-Variante nebenbei zu hören.
