Neue Features von Android Marshmallow Teil 1

Berechtigungskonzept in Android Marshmallow: Das müssen Entwickler wissen

Michael Gruczel

©Shutterstock / Asif Islam

Android 6.0, von Google liebevoll „Marshmallow“ genannt, wird derzeit auf Millionen von Android-Devices ausgerollt. Wir betrachten in einer Artikelserie, welche spannenden Neuerungen Marshmallow aus Entwickler-Sicht mitbringt. Den Anfang macht eines der wohl interessantesten Features: das nun viel mächtiger gewordene Berechtigungssystem.

Mit dem neuen Berechtigungskonzept von Android Marshmallow lassen sich Berechtigungen zur Laufzeit abfragen. Damit hat der Anwender mehr Kontrolle über seine Apps. Entwickler müssen dafür sorgen, dass ihre Apps auch mit abgelehnten Berechtigungen klarkommen.

Das neue Berechtigungskonzept greift erst, wenn die App auch mit dem Marsmallow SDK als Target gebaut wird. Damit laufen die bisherigen Apps erstmal wie gewohnt weiter und fragen die Berechtigungen zum Installationszeitpunkt ab. Dies gibt den Entwicklern die notwendige Zeit, nach eigenen Ermessen die Apps umzubauen, zu testen und neu zu releasen.

Mit Android Marshmallow gibt es die Möglichkeit, bestimmte Berechtigungen zur Laufzeit abzufragen. Diese muss der Anwender dann zum Installationszeitpunkt nicht mehr bestätigen. Hierbei handelt es sich um Berechtigungen, die Zugriff auf private Daten des Anwenders ermöglichen oder potenziell den Speicher anderer Apps manipulieren könnten.

Man stelle sich eine App vor, in der Konzerte aufgelistet und Karten für die Konzerte bestellt werden können. Die Funktion, eine Karte zu bestellen, braucht möglicherweise die Berechtigung, die Kontaktdaten zu lesen, um mit eben diesen Informationen die Bestellung durchzuführen. Die Anzeige der Konzerte greift möglicherweise auf das Internet zu. Will man eine derartige App anbieten, so muss die Berechtigung für den Internetzugriff und die Berechtigung für das Lesen der Kontaktdaten in der Manifestdatei angeben werden.

Abbildung 1 zeigt den unveränderlichen Dialog beim ersten Anfragen der Rechte aus diesem Beispiel. Abbildung 2 zeigt den Erklärungstext, der in diesem Beispiel angezeigt wird, wenn der Anwender vorher die Berechtigung abgelehnt hat. Abbildung 3 entspricht dem unveränderlichen Dialog bei der zweiten Abfrage. ©Michael Gruczel

Abbildung 1 zeigt den unveränderlichen Dialog beim ersten Anfragen der Rechte aus diesem Beispiel. Abbildung 2 zeigt den Erklärungstext, der in diesem Beispiel angezeigt wird, wenn der Anwender vorher die Berechtigung abgelehnt hat. Abbildung 3 entspricht dem unveränderlichen Dialog bei der zweiten Abfrage. ©Michael Gruczel

Vor Android Marshmallow hätte der Anwender beiden Berechtigungen bereits bei der Installation zustimmen müssen, obwohl der Anwender eventuell nur an der Ansicht der Konzerte interessiert ist. Der Zugriff auf die Kontaktdaten wäre erst bei der Buchung nötig und könnte unter Marshmallow genau dann abgefragt und dem Anwender begründet werden. Der Anwender kann dann entscheiden, ob er diese Berechtigung frei gibt oder auf die Funktionalität verzichten will. Für Entwickler hat dies den Vorteil, dass Anwender bei der Installation nicht schon mit Berechtigungen verschreckt werden, die dem Anwender nicht logisch erscheinen. Dieser Vorteil bedeutet im Umkehrschluss aber, dass die Anwendungen damit umgehen müssen, dass bestimmte Berechtigungen zur Laufzeit nicht zur Verfügung stehen.

Die Berechtigungen können vom Anwender innerhalb der allgemeinen Einstellungen jederzeit editiert werden wie Abbildung 4 und 5 zeigen. ©Michael Gruczel

Die Berechtigungen können vom Anwender innerhalb der allgemeinen Einstellungen jederzeit editiert werden wie Abbildung 4 und 5 zeigen. ©Michael Gruczel

Die Entscheidung, ob eine Berechtigung freigegeben wird, trifft der Anwender unter Android Marshmallow in einem nicht veränderlichen Dialog. Bei der ersten Abfrage der Berechtigung kann der Anwender zwischen Akzeptieren und nicht Akzeptieren wählen. In folgenden Abfragen kann der Anwender zudem die Entscheidung als dauerhaft markieren. Mittels ActivityCompat.requestPermissions(…) lässt sich abwärtskompatibel die eigentliche Berechtigung abfragen. Die Antwort kommt dann asynchron über ein Callback. Hierzu muss die Methode onRequestPermissionsResult überschrieben werden. Der Entwickler kann mittels ContextCompat.checkSelfPermission() überprüfen, ob die Berechtigung bereits vorliegt.

Das Beispiel in Listing 1 soll ein mögliches Vorgehen verdeutlichen. Im Beispiel wird zudem geprüft, ob die Berechtigung bereits einmal abgelehnt wurde.

Die Abfrage ActivityCompat.shouldShowRequestPermissionRationale(…) liefert genau dann true zurück, wenn der Anwender die Berechtigung einmalig abgelehnt hat. Sollte der Anwender noch nicht entschieden haben oder die Berechtigung dauerhaft abgelehnt haben, wird false als Ergebnis zurückgegeben. In dem Fall einer bereits erfolgten einmaligen Ablehnung, wird in diesem Beispiel ein Dialog geöffnet, der dem Anwender den Grund für die Verwendung der Berechtigung erklären soll. Nach dem Schließen des Dialogs wird dann die Berechtigung nochmals angefragt. Sollte der Anwender die Berechtigung bereits bestätigt haben, so wird die eigentliche Aktion gestartet.

public class PermissionActivity ... {

...

@OnClick(R.id.requestContacts)

public void requestContacts(View view) {

// der Anwender möchte eine Funktion nutzen, die auf Kontaktdaten
// zugreift, deshalb prüfen wir ob die Berechtigung bereits gegeben ist

if (ContextCompat.checkSelfPermission(

getApplicationContext(),Manifest.permission.READ_CONTACTS)

!= PackageManager.PERMISSION_GRANTED) {

// Berechtigung ist noch nicht gegeben
// Hat der Anwender die Berechtigung bereits einmalig abgelehnt ?

if(ActivityCompat.shouldShowRequestPermissionRationale(

PermissionActivity.this, Manifest.permission.READ_CONTACTS)) {

// Der Anwender hat die Berechtigung schon einmal abgelehnt,
// Dialog anzeigen um den Zugriff zu erklären

showExplanationDialog();

} else {

// Berechtigung wurde evt noch gar nicht abgefragt,
// Berechtigung jetzt anfragen

ActivityCompat.requestPermissions(PermissionActivity.this,

new String[]{Manifest.permission.READ_CONTACTS},

MY_REQUEST_CODE_FOR_READ_CONTACTS);

}

} else {

// Zugriff bereits gewährt

loadContacts();

}

}

private void showExplanationDialog() {

// Diesen Code würde man so nicht im Produktionscode
// haben wollen, sondern dient nur der Erklärung

AlertDialog.Builder builder =

new AlertDialog.Builder(getApplicationContext());

builder.setMessage("Wenn sie ihre Kontakdaten sehen wollen,

müssen sie den Zugriff erlauben");

builder.setPositiveButton("Verstanden",

new DialogInterface.OnClickListener() {

public void onClick(DialogInterface dialog, int id) {

ActivityCompat.requestPermissions(PermissionActivity.this,

new String[]{Manifest.permission.READ_CONTACTS},

MY_REQUEST_CODE_FOR_READ_CONTACTS);

}

});

AlertDialog dialog = builder.create();

dialog.show();

}

@Override

public void onRequestPermissionsResult(int requestCode,

String permissions[],

int[] grantResults) {

// Ergebnis der Berechtigungsanfrage

switch (requestCode) {

case MY_REQUEST_CODE_FOR_READ_CONTACTS: {

if (grantResults.length > 0

&& grantResults[0] == PackageManager.PERMISSION_GRANTED)

// Zugriff gewährt, Zugriff auf Kontakdaten jetzt möglich

loadContacts();

} else {

// Zugriff auf Berechtigung verweigert
// Informiere den User, dass Funktionalität nicht
// verfügbar ist oder deaktivere die Funktionalität

}

return;

}

}

}
 
private void loadContacts() {

// … Zugriff auf Kontaktdaten

}

...

}

In der nächsten Folge dieser Serie wenden wir uns einem weiteren spannenden Feature in Android 6.0 zu: dem Doze-Modus, mit dem sich vor allem die Akkulaufzeiten deutlich verlängern lassen sollen. Bis dahin: Viel Spaß beim Entwickeln für Marshmallow!

Highlights in Android Marshmallow
Teil 1: Berechtigungskonzept in Android Marshmallow: Das müssen Entwickler wissen
Teil 2: Doze und App Standby in Android Marshmallow: Das müssen Entwickler wissen
Teil 3: Autobackup in Android Marshmallow: Das müssen Entwickler wissen
Teil 4: Fingerprint-Sensor in Android Marshmallow: Das müssen Entwickler wissen

Aufmacherbild: Mountain View von Shutterstock / Urheberrecht: Asif Islam

Verwandte Themen:

Geschrieben von
Michael Gruczel
Michael Gruczel
Michael Gruczel ist seit 2008 als Berater und Entwickler im Bereich Java und DevOps tätig. Als Advisory Consultant von DellEmc berät er Firmen in der Modernisierung von Infrastruktur, Software-Stacks, Softwarearchitekturen und der Optimierung von Strukturen. Dazu gehört der volle Entwicklungszyklus: Von der Discovery, über die Entwicklung, das Testen, das Veröffentlichen bis hin zum Betreiben von Software.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: