In allen Versionen vor Android 6 wurde nach der Erlaubnis, auf was die jeweilige App zugreifen darf, beim Herunterladen und Installieren vom AppStore gefragt. Das hat sich jetzt geändert. Der User wird nun bei jedem einzelnen Zugriff die eine App vorhat gefragt. Wie der User sich entscheidet, ob er ablehnt oder zusagt, kann auch in den Einstellungen gefunden werden. Im Prinzip gleicht das System dem von iOS, wer es kennt. Ein schönes System für den User also, aber eine mögliche Hürde für den Entwickler einer App, dessen Hauptfeature möglicherweise der Zugriff auf z.B. Kontaktdaten aus dem Adressbuch ist. Daher möchte ich hier das Thema kurz zusammenfassen.

Die Erlaubnis wird für jeden Typ (z.B. Kontakte, Kalendar,…) zur Runtime (während die App läuft) einzeln eingeholt. Es wird jedoch kein automatischer Dialog angezeigt, dieser muss vom Entwickler explizit aufgerufen werden. Alles andere führt zu einem Absturz der App (SecurityException), falls es noch keine Zusage gab. Zusätzlich kann der User, wie bereits erwähnt, jederzeit eine Zusage in den Einstellungen wieder rückgängig machen.

Man muss also als Entwickler darauf gefasst sein jede betreffende Funktion in der App um diese Permission Abfrage zu erweitern. Dabei kann der User für einen Fall einmalig eine Zustimmung geben oder auf Dauer zustimmen, was in den System-Einstellungen gespeichert wird, die aber wiederum jederzeit vom User und außerhalb der eigenen App geändert werden können.

Betreffen tut dieser Mechanismus nur Apps die mit einer targetSDK 23 auf einem Android 6 Gerät gelauncht werden. Ältere Apps die auf einem Android 6 Gerät bereits installiert sind, werden mit dem alten System behandelt. Die Permission-Abfrage wird wie vor Android 6 bei der Installation durchgeführt. Dadurch werden alle Zusagen folglich automatisch in den System-Einstellungen gespeichert. Gefahr besteht dann, wenn der User dennoch seine Zusage in den System-Einstellungen zurücknimmt. Hier warnt das System den User jedoch selbstständig vor der Gefahr, dass die App dann zum Absturz gebracht werden kann. Hat man also seine aktuelle in Entwicklung befindliche App noch nicht Permission-sicher umgestellt, sollte man die tagetSdkVersion vorerst auf 22 belassen.

Nicht alle Permissions fallen in dieses neue Permission-System. Einige werden automatisch bei der Installation der App akzeptiert und scheinen in den System-Einstellungen nicht auf, womit sie auch nie zurückgenommen werden können. Daher braucht man sich um sie nicht kümmern:

android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
android.permission.ACCESS_NETWORK_STATE
android.permission.ACCESS_NOTIFICATION_POLICY
android.permission.ACCESS_WIFI_STATE
android.permission.ACCESS_WIMAX_STATE
android.permission.BLUETOOTH
android.permission.BLUETOOTH_ADMIN
android.permission.BROADCAST_STICKY
android.permission.CHANGE_NETWORK_STATE
android.permission.CHANGE_WIFI_MULTICAST_STATE
android.permission.CHANGE_WIFI_STATE
android.permission.CHANGE_WIMAX_STATE
android.permission.DISABLE_KEYGUARD
android.permission.EXPAND_STATUS_BAR
android.permission.FLASHLIGHT
android.permission.GET_ACCOUNTS
android.permission.GET_PACKAGE_SIZE
android.permission.INTERNET
android.permission.KILL_BACKGROUND_PROCESSES
android.permission.MODIFY_AUDIO_SETTINGS
android.permission.NFC
android.permission.READ_SYNC_SETTINGS
android.permission.READ_SYNC_STATS
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.REORDER_TASKS
android.permission.REQUEST_INSTALL_PACKAGES
android.permission.SET_TIME_ZONE
android.permission.SET_WALLPAPER
android.permission.SET_WALLPAPER_HINTS
android.permission.SUBSCRIBED_FEEDS_READ
android.permission.TRANSMIT_IR
android.permission.USE_FINGERPRINT
android.permission.VIBRATE
android.permission.WAKE_LOCK
android.permission.WRITE_SYNC_SETTINGS
com.android.alarm.permission.SET_ALARM
com.android.launcher.permission.INSTALL_SHORTCUT
com.android.launcher.permission.UNINSTALL_SHORTCUT

Stellen wir uns also vor wir schreiben eine Funktion die alle Kontakte aus dem Adressbuch des Users auslesen soll. Nächster Schritt ist also nach diesem neuen System, dass wir eine zweite Funktion schreiben, die überprüft ob eine Erlaubnis für Kontakte bereits vorhanden ist. Wenn nicht, dann soll ein Dialog angezeigt werden, der den User fragt ob er diese Erlaubnis meiner App geben will. Interessanterweise reicht schon eine Zustimmung das Kontakte gelesen (android.permission.READ_CONTACTS) werden dürfen um auch Kontakte zu ändern/erstellen (android.permission.WRITE_CONTACTS) da dieses Permissions sich in der gleichen Gruppe (android.permission-group.CONTACTS) befinden.

Alle Details zur Implementierung finden sich hier: http://developer.android.com/training/permissions/requesting.html

Funktionen für die Support-Libary sind vorhanden.

Wem die normale Vorgehensweise zu komplex ist, der kann sich auch eine 3rd Party Libary zur Hilfe nehmen. Diese arbeitet z.B. einfach mit dem Annotieren von Funktionen: http://hotchemi.github.io/PermissionsDispatcher/

Abschließender Gedanke: Greift man in seiner App auf mehr externe Resourcen als nur Kontakte zu, sollte man sich überlegen wie die App dennoch nützlich sein kann, wenn der User zwar die Erlaubnis für Kontakte gibt, aber nicht für Telefon.