Benutzerdefinierte App-Berechtigung festlegen

In diesem Dokument wird beschrieben, wie App-Entwickler die Sicherheitsfunktionen von Android, um eigene Berechtigungen zu definieren. Von indem benutzerdefinierte Berechtigungen festgelegt werden, kann eine App ihre Ressourcen und Funktionen freigeben. mit anderen Apps. Weitere Informationen zu Berechtigungen finden Sie in der Berechtigungsübersicht.

Hintergrund

Android ist ein privilegiertes Betriebssystem, App wird mit einer eindeutigen Systemidentität ausgeführt (Linux-Nutzer-ID und -Gruppe) ID). Teile des Systems werden ebenfalls in verschiedene Identitäten unterteilt. Auf diese Weise isoliert Linux Apps voneinander und vom System.

Durch das Definieren von Berechtigungen können Apps ihre Funktionen für andere Apps freigeben die andere Apps anfordern können. Sie können auch Berechtigungen definieren, werden automatisch auch anderen Apps zur Verfügung gestellt, die mit dem über dasselbe Zertifikat.

App-Signatur

Alle APKs müssen mit einem Zertifikat signiert werden. dessen privater Schlüssel vom Entwickler verwaltet wird. Das Zertifikat enthält nicht von einer Zertifizierungsstelle signiert sein. Es ist zulässig und Üblicherweise verwenden Android-Apps selbstsignierte Zertifikate. Der Zweck der um App-Autoren zu unterscheiden. Dadurch können Apps Zugriff auf Signaturebene gewähren oder verweigern. Berechtigungen und gewähren oder lehnen Sie die Anfrage einer App zum Erteilen dieselbe Linux-Identität wie eine andere Anwendung.

Signaturberechtigungen nach der Herstellung des Geräts erteilen

Ab Android 12 (API-Level 31) Attribut knownCerts für Mit Berechtigungen auf Signaturebene können Sie auf die Digests bekannter Signaturen Bescheinigungen bei der Erklärung .

Sie können das Attribut knownCerts deklarieren und das Flag knownSigner verwenden in der protectionLevel Ihrer App Attribut für eine bestimmte Berechtigung auf Signaturebene. Dann wird das System gewährt einer anfragenden App diese Berechtigung, wenn ein Unterzeichner in der Signatur Lineage, einschließlich des aktuellen Unterzeichners, stimmt mit einer der Digests überein, mit der Berechtigung im Attribut knownCerts deklariert.

Mit dem Flag knownSigner können Geräte und Apps Berechtigungen für Signaturen erteilen andere Apps verwenden, ohne sie bei der Geräteherstellung signieren zu müssen und Versand.

Nutzer-IDs und Dateizugriff

Bei der Installation weist Android jedem Paket eine eigene Linux-Nutzer-ID zu. Die Identität für die Lebensdauer des Pakets auf dieser Seite konstant bleibt. . Auf einem anderen Gerät hat dasselbe Paket möglicherweise ein anderes UID: Wichtig ist, dass jedes Paket eine eigene UID auf einer bestimmten .

Die Sicherheitsdurchsetzung erfolgt kann der Code zweier Pakete normalerweise nicht im selben Prozess ausgeführt werden, da sie als verschiedene Linux-Nutzer ausgeführt werden müssen.

Alle von einer App gespeicherten Daten werden dem Nutzer dieser App zugewiesen ID und ist normalerweise für andere Pakete nicht zugänglich.

Weitere Informationen zum Sicherheitsmodell von Android finden Sie unter Sicherheit bei Android Übersicht.

Berechtigungen definieren und erzwingen

Um Ihre eigenen Berechtigungen zu erzwingen, müssen Sie diese zuerst in Ihren AndroidManifest.xml mit einem oder mehreren <permission>-Elemente.

Namenskonvention

Das System lässt nicht zu, dass mehrere Pakete deklariert werden. eine Berechtigung mit demselben Namen, es sei denn, alle Pakete sind mit dem über dasselbe Zertifikat. Wenn ein Paket eine Berechtigung deklariert, kann das System auch keine Nutzern erlauben, andere Pakete mit demselben Berechtigungsnamen zu installieren, es sei denn, diese Pakete mit demselben Zertifikat wie das erste Paket signiert sind.

Wir empfehlen, den Berechtigungen den Paketnamen einer App voranzustellen. Verwenden Sie dazu Reverse-Domain-ähnliche Benennung, gefolgt von .permission. und eine Beschreibung der Capability, die die Berechtigung repräsentiert, SNAKE_CASE oben. Beispiel: com.example.myapp.permission.ENGAGE_HYPERSPACE

Wenn Sie diese Empfehlung befolgen, vermeiden Sie Konflikte bei der Benennung den Inhaber und die Absicht einer benutzerdefinierten Berechtigung ermitteln.

Beispiel

Beispiel: Eine App, die steuern muss, welche anderen Apps eine solche App starten können, seiner Aktivitäten kann wie folgt eine Berechtigung für diesen Vorgang deklarieren:

<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example.myapp" >
    
    <permission
      android:name="com.example.myapp.permission.DEADLY_ACTIVITY"
      android:label="@string/permlab_deadlyActivity"
      android:description="@string/permdesc_deadlyActivity"
      android:permissionGroup="android.permission-group.COST_MONEY"
      android:protectionLevel="dangerous" />
    ...
</manifest>

Das Attribut protectionLevel ist erforderlich und teilt dem System mit, wie Nutzer über Apps informieren, für die eine Berechtigung erforderlich ist, oder darüber, welche Apps die Berechtigung haben, wie in der verlinkten Dokumentation beschrieben.

Die android:permissionGroup ist optional und dient nur dazu, dem System die Anzeige von Berechtigungen zu erleichtern. für den Nutzer. In den meisten Fällen legen Sie ein Standardsystem fest, Gruppe (aufgeführt in android.Manifest.permission_group), obwohl Sie eine Gruppe selbst definieren können, wie im folgenden Abschnitt beschrieben. Wir empfehlen die Verwendung einer vorhandenen Gruppe, da dies die Berechtigungs-UI, die dem Nutzer angezeigt wird.

Sie müssen sowohl ein Label als auch eine Beschreibung für die Berechtigung. Dies sind String-Ressourcen, die der Nutzer sehen kann, sehen sie sich eine Liste mit Berechtigungen an (android:label) oder Details zu einer Berechtigung, (android:description) Das Label ist kurz: ein paar Wörter, die das Wichtigste Funktionen, die durch die Berechtigung geschützt werden. Die Beschreibung ist ein beschreiben, was der Inhaber mit der Berechtigung tun lässt. Unsere ist eine Beschreibung aus zwei Sätzen, wobei der erste Satz Mit der Berechtigung wird der Nutzer im zweiten Satz darauf hingewiesen, die schiefgehen können, wenn einer App die Berechtigung gewährt wird.

Hier sehen Sie ein Beispiel für ein Label und eine Beschreibung für die CALL_PHONE Berechtigung:

<string name="permlab_callPhone">directly call phone numbers</string>
<string name="permdesc_callPhone">Allows the app to call non-emergency
phone numbers without your intervention. Malicious apps may cause unexpected
calls on your phone bill.</string>

Berechtigungsgruppe erstellen

Wie im vorherigen Abschnitt gezeigt, können Sie android:permissionGroup-Attribut zum Beschreiben von Berechtigungen für den Nutzer zu gewähren. In den meisten Fällen legen Sie dafür eine Standard- Systemgruppe (aufgeführt in android.Manifest.permission_group) Sie können aber auch Ihre eigene Gruppe mit <permission-group>.

Das Element <permission-group> definiert ein Label für eine Gruppe. der im Manifest deklarierten Berechtigungen <permission> und an anderer Stelle deklarierte Elemente. Dies wirkt sich nur auf die Berechtigungen aus, gruppiert werden, wenn sie dem Nutzer präsentiert werden. Die <permission-group> nicht die Berechtigungen angibt, die zur Gruppe gehören, aber erhält die Gruppe einen Namen.

Sie können der Gruppe eine Berechtigung zuweisen, indem Sie den Gruppennamen <permission> des Elements permissionGroup .

Die <permission-tree> deklariert einen Namespace für eine Gruppe von Berechtigungen, die in Code.

Benutzerdefinierte Empfehlungen für Berechtigungen

Sie können benutzerdefinierte Berechtigungen für Ihre Apps festlegen und benutzerdefinierte Berechtigungen anfordern durch die Definition von <uses-permission>-Elementen aus anderen Apps. Sie sollten jedoch sorgfältig abwägen, ob dies erforderlich ist.

• Wenn Sie eine Suite von Apps entwerfen, Versuchen Sie, die Apps so zu gestalten, dass jede Berechtigung nur definiert ist, einmal. Dieser Schritt ist erforderlich, wenn die Apps nicht alle mit demselben Zertifikat. Auch wenn alle Apps mit demselben Zertifikat signiert sind, Es empfiehlt sich, jede Berechtigung nur einmal zu definieren.
• Wenn die Funktion nur für Apps verfügbar ist, die mit demselben als bereitstellende App verwenden möchten, müssen Sie möglicherweise keine benutzerdefinierten mithilfe von Signaturprüfungen. Wenn eine Ihrer Apps eine Anfrage stellt deiner anderen Apps überprüft, kann die zweite App prüfen, ob beide Apps signiert sind. das gleiche Zertifikat erhalten, bevor Sie der Anfrage nachkommen.

Wenn eine benutzerdefinierte Berechtigung erforderlich ist, überlegen Sie, ob nur Anwendungen vom selben Entwickler wie die App, die die Berechtigungsprüfung durchführt, z. B. bei der Implementierung einer sicheren prozessübergreifenden Kommunikation zwischen zwei Apps vom selben Entwickler. In diesem Fall sollten Sie Signaturberechtigungen. Signaturberechtigungen sind für den Nutzer transparent und müssen nicht bestätigt werden was für Nutzer verwirrend sein kann.