Berechtigungen in Xamarin.Android

Übersicht

Android-Anwendungen werden in ihrer eigenen Sandbox ausgeführt und haben aus Sicherheitsgründen keinen Zugriff auf bestimmte Systemressourcen oder Hardware auf dem Gerät. Der Benutzer muss der App explizit berechtigungen erteilen, bevor sie diese Ressourcen verwenden kann. Beispielsweise kann eine Anwendung nicht ohne explizite Zustimmung des Benutzers auf das GPS auf einem Gerät zugreifen. Android löst einen aus Java.Lang.SecurityException , wenn eine App versucht, ohne Berechtigung auf eine geschützte Ressource zuzugreifen.

Berechtigungen werden in der AndroidManifest.xml vom Anwendungsentwickler deklariert, wenn die App entwickelt wird. Android verfügt über zwei unterschiedliche Workflows, um die Zustimmung des Benutzers für diese Berechtigungen einzuholen:

• Für Apps, die Android 5.1 (API-Ebene 22) oder niedriger als Ziel haben, ist die Berechtigungsanforderung bei der Installation der App aufgetreten. Wenn der Benutzer die Berechtigungen nicht erteilt hat, wird die App nicht installiert. Sobald die App installiert wurde, gibt es keine Möglichkeit, die Berechtigungen zu widerrufen, außer durch Deinstallieren der App.
• Ab Android 6.0 (API-Ebene 23) erhielten Benutzer mehr Kontrolle über Berechtigungen; Sie können Berechtigungen erteilen oder widerrufen, solange die App auf dem Gerät installiert ist. Dieser Screenshot zeigt die Berechtigungseinstellungen für die Google Contacts-App. Sie listet die verschiedenen Berechtigungen auf und ermöglicht dem Benutzer, Berechtigungen zu aktivieren oder zu deaktivieren:

Android-Apps müssen zur Laufzeit überprüfen, ob sie über die Berechtigung für den Zugriff auf eine geschützte Ressource verfügen. Wenn die App nicht über die Berechtigung verfügt, muss sie Anforderungen mithilfe der neuen APIs stellen, die vom Android SDK bereitgestellt werden, damit der Benutzer die Berechtigungen erteilen kann. Berechtigungen sind in zwei Kategorien unterteilt:

• Normale Berechtigungen : Dies sind Berechtigungen, die ein geringes Sicherheitsrisiko für die Sicherheit oder den Datenschutz des Benutzers darstellen. Android 6.0 erteilt zum Zeitpunkt der Installation automatisch normale Berechtigungen. Eine vollständige Liste der normalen Berechtigungen finden Sie in der Android-Dokumentation.
• Gefährliche Berechtigungen : Im Gegensatz zu normalen Berechtigungen sind gefährliche Berechtigungen diejenigen, die die Sicherheit oder privatsphäre des Benutzers schützen. Diese müssen vom Benutzer explizit gewährt werden. Das Senden oder Empfangen einer SMS-Nachricht ist ein Beispiel für eine Aktion, die eine gefährliche Berechtigung erfordert.

Gefährliche Berechtigungen werden weiter in Berechtigungsgruppen unterteilt. Eine Berechtigungsgruppe enthält Berechtigungen, die logisch miteinander verknüpft sind. Wenn der Benutzer einem Mitglied einer Berechtigungsgruppe die Berechtigung erteilt, erteilt Android automatisch allen Mitgliedern dieser Gruppe die Berechtigung. Beispielsweise enthält die STORAGE Berechtigungsgruppe sowohl die WRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGE Berechtigungen als auch die Berechtigungen. Wenn der Benutzer die Berechtigung erteilt READ_EXTERNAL_STORAGE, wird die WRITE_EXTERNAL_STORAGE Berechtigung automatisch gleichzeitig erteilt.

Bevor Sie eine oder mehrere Berechtigungen anfordern, empfiehlt es sich, eine Begründung dafür bereitzustellen, warum die App die Berechtigung benötigt, bevor Sie die Berechtigung anfordern. Sobald der Benutzer die Gründe verstanden hat, kann die App die Berechtigung vom Benutzer anfordern. Wenn der Benutzer die Gründe versteht, kann er eine fundierte Entscheidung treffen, wenn er die Genehmigung erteilen möchte, und die Auswirkungen verstehen, wenn er dies nicht tut.

Der gesamte Workflow zum Überprüfen und Anfordern von Berechtigungen wird als Laufzeitberechtigungsprüfung bezeichnet und kann im folgenden Diagramm zusammengefasst werden:

Die Android-Supportbibliothek gibt einige der neuen APIs für Berechtigungen für ältere Versionen von Android zurück. Diese backportierten APIs überprüfen automatisch die Android-Version auf dem Gerät, sodass es nicht jedes Mal erforderlich ist, eine Überprüfung auf API-Ebene durchzuführen.

In diesem Dokument wird erläutert, wie Einer Xamarin.Android-Anwendung Berechtigungen hinzugefügt werden und wie Apps, die android 6.0 (API-Ebene 23) oder höher als Ziel haben, eine Laufzeitberechtigungsprüfung durchführen sollten.

Anforderungen

Es wird dringend empfohlen, dass Xamarin.Android-Projekte das NuGet-Paket Xamarin.Android.Support.Compat enthalten. Mit diesem Paket werden berechtigungsspezifische APIs auf ältere Versionen von Android zurückportiert und eine gemeinsame Schnittstelle bereitgestellt, ohne dass die Android-Version, auf der die App ausgeführt wird, ständig überprüft werden muss.

Anfordern von Systemberechtigungen

Der erste Schritt beim Arbeiten mit Android-Berechtigungen besteht darin, die Berechtigungen in der Android-Manifestdatei zu deklarieren. Dies muss unabhängig von der API-Ebene erfolgen, auf die die App ausgerichtet ist.

Apps, die auf Android 6.0 oder höher abzielen, können nicht davon ausgehen, dass die Berechtigung beim nächsten Mal gültig ist, da der Benutzer die Berechtigung zu einem bestimmten Zeitpunkt in der Vergangenheit erteilt hat. Eine App für Android 6.0 muss immer eine Laufzeitberechtigungsprüfung durchführen. Apps für Android 5.1 oder niedriger müssen keine Laufzeitberechtigungsprüfung durchführen.

Deklarieren von Berechtigungen im Manifest

Berechtigungen werden dem AndroidManifest.xml mit dem uses-permission -Element hinzugefügt. Wenn eine Anwendung z. B. die Position des Geräts ermitteln soll, benötigt sie berechtigungen und Kursstandort. Dem Manifest werden die folgenden beiden Elemente hinzugefügt:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

Xamarin.Android fügt automatisch einige Berechtigungen zur Buildzeit zum Debuggen von Builds hinzu. Dadurch wird das Debuggen der Anwendung vereinfacht. Insbesondere sind INTERNET zwei bemerkenswerte Berechtigungen und READ_EXTERNAL_STORAGE. Diese automatisch festgelegten Berechtigungen werden in der Liste Erforderliche Berechtigungen nicht aktiviert. Releasebuilds verwenden jedoch nur die Berechtigungen, die explizit in der Liste Erforderliche Berechtigungen festgelegt sind.

Für Apps, die auf Android 5.1 (API-Ebene 22) oder niedriger abzielen, muss nichts mehr getan werden. Apps, die unter Android 6.0 (API 23 Level 23) oder höher ausgeführt werden, sollten mit dem nächsten Abschnitt über die Ausführung von Laufzeitberechtigungsprüfungen fortfahren.

Laufzeitberechtigungsprüfungen in Android 6.0

Die ContextCompat.CheckSelfPermission -Methode (verfügbar in der Android-Supportbibliothek) wird verwendet, um zu überprüfen, ob eine bestimmte Berechtigung erteilt wurde. Diese Methode gibt eine Android.Content.PM.Permission Enumeration zurück, die einen von zwei Werten aufweist:

• Permission.Granted – Die angegebene Berechtigung wurde erteilt.
• Permission.Denied – Die angegebene Berechtigung wurde nicht erteilt.

Dieser Codeausschnitt ist ein Beispiel für das Überprüfen der Kameraberechtigung in einer Aktivität:

if (ContextCompat.CheckSelfPermission(this, Manifest.Permission.Camera) == (int)Permission.Granted) 
{
    // We have permission, go ahead and use the camera.
} 
else 
{
    // Camera permission is not granted. If necessary display rationale & request.
}

Es ist eine bewährte Methode, den Benutzer darüber zu informieren, warum eine Berechtigung für eine Anwendung erforderlich ist, damit eine informierte Entscheidung getroffen werden kann, die Berechtigung zu erteilen. Ein Beispiel hierfür wäre eine App, die Fotos aufnimmt und diese geotags markiert. Für den Benutzer ist klar, dass die Kameraberechtigung erforderlich ist, aber es ist möglicherweise nicht klar, warum die App auch den Standort des Geräts benötigt. In der Begründung sollte eine Meldung angezeigt werden, die dem Benutzer hilft zu verstehen, warum die Standortberechtigung wünschenswert ist und dass die Kameraberechtigung erforderlich ist.

Die ActivityCompat.ShouldShowRequestPermissionRationale Methode wird verwendet, um zu bestimmen, ob dem Benutzer die Begründung angezeigt werden soll. Diese Methode gibt zurück true , wenn die Begründung für eine bestimmte Berechtigung angezeigt werden soll. Dieser Screenshot zeigt ein Beispiel für eine Snackbar, die von einer Anwendung angezeigt wird und erklärt, warum die App den Standort des Geräts kennen muss:

Wenn der Benutzer die Berechtigung erteilt, sollte die ActivityCompat.RequestPermissions(Activity activity, string[] permissions, int requestCode) Methode aufgerufen werden. Für diese Methode sind die folgenden Parameter erforderlich:

• Aktivität : Dies ist die Aktivität, die die Berechtigungen anfordert und von Android über die Ergebnisse informiert werden soll.
• permissions : Eine Liste der angeforderten Berechtigungen.
• requestCode : Ein ganzzahliger Wert, der verwendet wird, um die Ergebnisse der Berechtigungsanforderung einem RequestPermissions Aufruf zuzuordnen. Dieser Wert muss größer als null sein.

Dieser Codeausschnitt ist ein Beispiel für die beiden Methoden, die erläutert wurden. Zunächst wird überprüft, ob die Berechtigungsbegründung angezeigt werden soll. Wenn die Begründung angezeigt werden soll, wird eine Snackbar mit der Begründung angezeigt. Wenn der Benutzer in der Snackbar auf OK klickt, fordert die App die Berechtigungen an. Wenn der Benutzer die Begründung nicht akzeptiert, sollte die App nicht fortfahren, Berechtigungen anzufordern. Wenn die Begründung nicht angezeigt wird, fordert die Aktivität die Berechtigung an:

if (ActivityCompat.ShouldShowRequestPermissionRationale(this, Manifest.Permission.AccessFineLocation)) 
{
    // Provide an additional rationale to the user if the permission was not granted
    // and the user would benefit from additional context for the use of the permission.
    // For example if the user has previously denied the permission.
    Log.Info(TAG, "Displaying camera permission rationale to provide additional context.");

    var requiredPermissions = new String[] { Manifest.Permission.AccessFineLocation };
    Snackbar.Make(layout, 
                   Resource.String.permission_location_rationale,
                   Snackbar.LengthIndefinite)
            .SetAction(Resource.String.ok, 
                       new Action<View>(delegate(View obj) {
                           ActivityCompat.RequestPermissions(this, requiredPermissions, REQUEST_LOCATION);
                       }    
            )
    ).Show();
}
else 
{
    ActivityCompat.RequestPermissions(this, new String[] { Manifest.Permission.Camera }, REQUEST_LOCATION);
}

RequestPermission kann auch aufgerufen werden, wenn der Benutzer bereits die Berechtigung erteilt hat. Nachfolgende Aufrufe sind nicht erforderlich, bieten dem Benutzer jedoch die Möglichkeit, die Berechtigung zu bestätigen (oder zu widerrufen). Wenn RequestPermission aufgerufen wird, wird die Steuerung an das Betriebssystem übergeben, das eine Benutzeroberfläche zum Akzeptieren der Berechtigungen anzeigt:

Nachdem der Benutzer fertig ist, gibt Android die Ergebnisse über die Rückrufmethode OnRequestPermissionResultan die Aktivität zurück. Diese Methode ist Teil der -Schnittstelle ActivityCompat.IOnRequestPermissionsResultCallback , die von der -Aktivität implementiert werden muss. Diese Schnittstelle verfügt über eine einzelne Methode, OnRequestPermissionsResult, die von Android aufgerufen wird, um die Aktivität über die Auswahl des Benutzers zu informieren. Wenn der Benutzer die Berechtigung erteilt hat, kann die App die geschützte Ressource verwenden. Im Folgenden finden Sie ein Beispiel für die Implementierung OnRequestPermissionResult :

public override void OnRequestPermissionsResult(int requestCode, string[] permissions, Permission[] grantResults)
{
    if (requestCode == REQUEST_LOCATION) 
    {
        // Received permission result for camera permission.
        Log.Info(TAG, "Received response for Location permission request.");

        // Check if the only required permission has been granted
        if ((grantResults.Length == 1) && (grantResults[0] == Permission.Granted)) {
            // Location permission has been granted, okay to retrieve the location of the device.
            Log.Info(TAG, "Location permission has now been granted.");
            Snackbar.Make(layout, Resource.String.permission_available_camera, Snackbar.LengthShort).Show();            
        } 
        else 
        {
            Log.Info(TAG, "Location permission was NOT granted.");
            Snackbar.Make(layout, Resource.String.permissions_not_granted, Snackbar.LengthShort).Show();
        }
    } 
    else 
    {
        base.OnRequestPermissionsResult(requestCode, permissions, grantResults);
    }
}

Zusammenfassung

In diesem Leitfaden wurde das Hinzufügen und Überprüfen von Berechtigungen auf einem Android-Gerät erläutert. Unterschiede in der Funktionsweise von Berechtigungen zwischen alten Android-Apps (API-Ebene < 23) und neuen Android-Apps (API-Ebene > 22). Es wurde erläutert, wie Laufzeitberechtigungsprüfungen in Android 6.0 ausgeführt werden.

Ähnliche Themen

• Liste der normalen Berechtigungen
• Beispiel-App für Laufzeitberechtigungen
• Behandeln von Berechtigungen in Xamarin.Android