Android-Rollen

Eine Rolle ist ein eindeutiger Name im System, der mit bestimmten Berechtigungen und Privilegien verknüpft ist. Apps können über die Android API bestimmte Rollen anfordern, insbesondere durch Aufrufen von Methoden in der Klasse RoleManager.

In der folgenden Liste finden Sie die verfügbaren Rollen und die entsprechenden Anforderungen:

Rolle Voraussetzungen
ASSISTANT Mindestens eines der folgenden Elemente:
  • Die App hat eine Aktivität, die Assist-Aktionen ausführt, wenn die Informationen zum Kontext des Nutzers bei der Anfrage des Nutzers vorliegen (z. B. der Paketname der aktuellen Vordergrund-App und die zugehörigen Kontextinformationen).
  • Die App hat einen Always-On-Sprachinteraktionsdienst, der durch die Berechtigung android.permission.BIND_VOICE_INTERACTION geschützt ist und Sprachinteraktionssitzungen hosten und Sprache erkennen kann. Außerdem hat die App ein explizites Flag, das angibt, dass der Dienst die Assist-Aktion ausführen kann.
BROWSER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App hat eine Aktivität, die über Anfragen mit impliziten Intents aufgerufen werden kann und die eine Webseite anzeigt, die einer http://-Adresse entspricht.
  • Die App muss die Navigation zwischen Links ermöglichen. Wenn der Nutzer also eine Webseite aufruft und im Text auf eine http://-Adresse klickt, muss die App die Inhalte, die dem ausgewählten Link entsprechen, ohne zusätzliche Nutzerinteraktion anzeigen können.
  • Die App muss in der Lage sein, die aktuellen Geolocation-Informationen des Geräts für Webseiten bereitzustellen, wenn dies angefordert wird und der Nutzer die Anfrage genehmigt.
DIALER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App hat eine Aktivität, die über Anfragen mit implizitem Intent aufgerufen werden kann und die Benutzeroberfläche für Anrufe bereitstellt, während auf dem Gerät ein Anruf läuft.
  • Die App kann Intents für eingehende Anrufe verarbeiten, dem Nutzer Informationen zum Anruf (z. B. die Telefonnummer des Anrufers) anzeigen und dem Nutzer ermöglichen, den Anruf anzunehmen oder abzulehnen.
  • Die App bietet dem Nutzer die Möglichkeit, Anrufe zu starten und einen Anrufverlauf auf seinem Gerät einzusehen.
SMS Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App erfüllt alle Anforderungen an SMS-Apps.
  • Die App hat eine Aktivität, die von Apps über Anfragen mit implizitem Intent aufgerufen werden kann, wodurch eine Nachricht an eine Telefonnummer gesendet werden kann.
  • Die App hat einen Dienst, der durch die Berechtigung android.permission.SEND_RESPOND_VIA_MESSAGE geschützt ist und durch implizite Intents aufgerufen werden kann. Über diesen Dienst können Nachrichten, die von der Telefon App empfangen wurden, zugestellt werden, wenn der Nutzer bei einem eingehenden Anruf die Option „Per SMS antworten“ auswählt. Die App kann Nachrichten über ihr eigenes Nachrichtensystem senden.
  • Die App hat zwei Broadcast-Empfänger, einer mit der Berechtigung android.permission.BROADCAST_SMS und einer mit der Berechtigung android.permission.BROADCAST_WAP_PUSH, die jeweils auf textbasierte SMS- und MMS-Nachrichten hören können, die an das Gerät gesendet werden. Die App ist dann dafür verantwortlich, die Nachrichten an den SMS-Anbieter zu senden und die Nutzer zu benachrichtigen.
EMERGENCY Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Die App hat eine Aktivität, in der die Notfallinformationen des Nutzers angezeigt werden. Jeder kann über die Schaltfläche „Notfall“ in der Aktivität „Notruf“ zu diesem Bildschirm navigieren.
HOME Die App hat eine Aktivität, die den Startbildschirm starten kann, wenn der Nutzer den Home-Button drückt. Auf dem Startbildschirm sollten App-Symbole und Widgets angezeigt werden. Die Navigation sollte über Schaltflächen oder Gesten erfolgen (z. B. durch Wischen nach oben, um alle Apps zu sehen).
CALL_REDIRECTION Die App hat einen Dienst, der durch die Berechtigung android.permission.BIND_CALL_REDIRECTION_SERVICE geschützt ist und an den das Telekommunikations-Framework gebunden werden kann. Der Dienst empfängt die abgehende Telefonnummer vom Telekommunikations-Framework und führt eine der folgenden Aktionen aus:
  • Anruf wie geplant durchstellen.
  • Ändern Sie die ausgehende Nummer so, dass sie über eine Proxy-Nummer weitergeleitet wird.
  • Brechen Sie den Anruf ab.
CALL_SCREENING Die App hat einen Dienst, der durch die Berechtigung android.permission.BIND_SCREENING_SERVICE geschützt ist und zwei Funktionen ausführt:
  • Anrufblockierung und ‑filterung:Der Dienst kann auswählen, welche Anrufe an die Telefon-App auf dem Smartphone gesendet werden sollen (und je nach „Bitte nicht stören“-Modus oder Lautstärke möglicherweise klingeln) und welche stumm an die Mailbox weitergeleitet werden sollen.
  • Anrufer-ID:Der Dienst kann Informationen zu einem Anruf über eine Benutzeroberfläche identifizieren und anzeigen.
SYSTEM_GALLERY Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App bietet eine Benutzeroberfläche, über die Nutzer ihre Videos und Bilder speichern, organisieren und anzeigen können.
SYSTEM_AUTOMOTIVE_CLUSTER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App für Automotive.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App bietet die Möglichkeit, auf einem Automotive-Cluster-Display (in der Regel neben dem Lenkrad) Anrufe anzunehmen und auf Kontaktlisten und Anruflisten zuzugreifen.
COMPANION_DEVICE_WATCH Die App kann Anfragen senden, um einem Smartwatch-Gerät zugeordnet zu werden und es zu verwalten (mit der API, die von der Klasse CompanionDeviceManager bereitgestellt wird). Wenn die Smartwatch und die App über die von der App bereitgestellte Benutzeroberfläche verbunden sind, können Nutzer ihre Smartwatch über die App verwalten, einschließlich der Synchronisierung von Kontakten und Kalender sowie der Verwaltung von Benachrichtigungen und Anrufen.
SYSTEM_AUTOMOTIVE_PROJECTION Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App ermöglicht die Übertragung des Smartphone-Displays auf das Display im Fahrzeug. Damit können Fahrer über Eingabemechanismen im Fahrzeug, z. B. Touchscreen, Lenkradsteuerung und Sprachbefehle, auf Apps auf Android-Smartphones zugreifen und diese steuern, darunter Musik, Navigation, Telefonanrufe und Suche.
SYSTEM_SHELL Alle von:
  • Die App ist eine System-App, der die UID Process.SHELL_UID zugewiesen ist.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App bietet eine Schnittstelle, die auf der Befehlszeilenebene funktioniert, sodass Nutzer mit dem Android-Betriebssystem interagieren können. Beispiele: Anzeigen des Inhalts eines Ordners oder Starten von Apps. Shell-Befehle können programmatisch von Apps (sofern die erforderlichen Berechtigungen erteilt wurden) oder über das ADB-Tool ausgeführt werden.
SYSTEM_CONTACTS Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App bietet eine Benutzeroberfläche, über die Nutzer ihre Kontakte verwalten können, z. B. Kontakte ansehen, teilen, hinzufügen, entfernen oder suchen. Die App aktualisiert den Kontakteanbieter, wenn der Nutzer seine Kontakte über die App aktualisiert. Nutzer können ihre Kontakte auch über die App anrufen, ihnen E‑Mails senden oder Nachrichten schreiben.
SYSTEM_SPEECH_RECOGNIZER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App bietet einen Dienst, der Spracherkennung durchführen kann.
  • Wenn die App Live-Mikrofonstreams von einer anderen App zur Spracherkennung empfängt, wird die Mikrofonnutzung der Anruf-App korrekt zugeordnet und die Statistiken zum App-Betrieb werden entsprechend aktualisiert.
SYSTEM_WIFI_COEX_MANAGER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App hat einen Dienst, der dynamisch eine Liste von WLAN-Kanälen festlegt, die das Gerät aufgrund von Mobilfunkstörungen nicht verwenden sollte.
SYSTEM_WELLBEING Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App sollte Nutzern die Möglichkeit bieten, Ablenkungen zu reduzieren, und Statistiken zur Nutzung ihres Geräts liefern (z. B. die Bildschirmzeit pro Woche).
SYSTEM_TELEVISION_NOTIFICATION_HANDLER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App muss Nutzern auf TV-Geräten Pop-up-Benachrichtigungen anzeigen. Die App muss auch aktuelle aktive Benachrichtigungen anzeigen, wenn der android.app.action.TOGGLE_NOTIFICATION_HANDLER_PANEL-Intent (von SystemUI) gesendet wird.
SYSTEM_COMPANION_DEVICE_PROVIDER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App muss in der Lage sein, Peripheriegeräte in der Nähe zu erkennen. Sie muss eine Benutzeroberfläche haben, auf der der Nutzer bestätigen kann, dass ein bestimmtes Peripheriegerät mit einer App verknüpft und von ihr verwaltet werden soll. Wenn der Nutzer dies bestätigt, gewährt die verwaltende App der verknüpften App die Berechtigung, auf das Peripheriegerät zuzugreifen (z. B. auf seinen Namen, seine Adresse, seine Klasse und seinen Pairing-Status), und sie kann den Pairing-Vorgang starten.
SYSTEM_DOCUMENT_MANAGER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App enthält eine Aktivität, mit der Nutzer auf vorhandene Dokumente zugreifen und neue Dokumente auf dem Gerät erstellen können.
  • Die App muss alle Anforderungen erfüllen, die im Abschnitt 2.2.3 des Android CDD beschrieben sind. Software unter der Überschrift [3.2.3.1/H-0-1].
SYSTEM_ACTIVITY_RECOGNIZER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Die App hat einen Dienst, der durch android.permission.ACTIVITY_RECOGNITION geschützt ist und der die Aktivitätserkennung (z. B. Laufen oder Radfahren) durchführen kann.
SYSTEM_UI Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App bietet eine Benutzeroberfläche, über die Nutzer mit ihren Smartphones interagieren können. Dazu gehören beispielsweise der Hauptbildschirm des Smartphones, die Navigation, die Liste der zuletzt verwendeten Apps, die Schnelleinstellungen, die Benachrichtigungsleiste, der Sperrbildschirm und die Lautstärkeregelung.
SYSTEM_TELEVISION_REMOTE_SERVICE Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App auf Android TV.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App hat einen Dienst, der mit dem HID-Gerät der TV-Fernbedienung kommunizieren kann (z. B. über BLE), Ereignisse (z. B. Tastenklicks) in die Plattform einfügen und andere Daten (z. B. einen Audio-Stream von einem in die Fernbedienung eingebauten Mikrofon) an die Plattform senden kann.
SYSTEM_UI_INTELLIGENCE Alle der folgenden Bedingungen müssen erfüllt sein:
  • Es handelt sich um einen vorinstallierten Dienst, der über Framework-APIs (öffentliche oder System-APIs) einen intelligenten On-Device-Prozessor für System-UI-Funktionen bereitstellt, z. B. zum Vorhersagen und Anzeigen der nächsten Apps für die Nutzer.
  • Der Dienst muss alle Anforderungen erfüllen, die im Abschnitt 9.8.6 Content Capture des Android CDD beschrieben sind.
  • Der Dienst darf nicht die Berechtigung android.permission.INTERNET haben. Stattdessen muss über klar definierte APIs in einem Open-Source-Projekt auf das Internet zugegriffen werden.
  • Der Dienst kann nicht an Apps gebunden werden, mit Ausnahme der folgenden System-Apps: Bluetooth, Kontakte, Media, Telefonie, SystemUI und Komponenten, die Internet-APIs bereitstellen. Jede zulässige Bindung muss explizit über die <allow-association>-Konfiguration in der Systemkonfiguration eingerichtet werden.
  • Der Dienst darf Daten nur dann für Apps freigeben, wenn eine direkte Nutzeraktion erfolgt (z. B. wenn der Nutzer jedes Mal, wenn die Daten freigegeben werden, explizit auf eine Schaltfläche tippt).
SYSTEM_AMBIENT_AUDIO_INTELLIGENCE Alle der folgenden Bedingungen müssen erfüllt sein:
  • Identisch mit den Bedingungen für SYSTEM_UI_INTELLIGENCE, mit der Ausnahme, dass der vorinstallierte Dienst einen intelligenten On-Device-Prozessor für Umgebungsgeräusche bietet, z. B. zum Erkennen von Titeln, die in der Nähe des Geräts abgespielt werden.
SYSTEM_AUDIO_INTELLIGENCE Alle der folgenden Bedingungen müssen erfüllt sein:
  • Identisch mit den Bedingungen für SYSTEM_UI_INTELLIGENCE, mit der Ausnahme, dass der vorinstallierte Dienst einen intelligenten Prozessor auf dem Gerät für Audioinhalte bietet (z. B. für die Untertitelung von Videos, Podcasts, Telefonanrufen, Videoanrufen und Sprachnachrichten).
SYSTEM_NOTIFICATION_INTELLIGENCE Alle der folgenden Bedingungen müssen erfüllt sein:
  • Identisch mit den Bedingungen für SYSTEM_UI_INTELLIGENCE, mit der Ausnahme, dass der vorinstallierte Dienst einen intelligenten Prozessor auf dem Gerät für Benachrichtigungen bereitstellt (z. B. Vorschläge für Antworten und Aktionen für Nachrichtenbenachrichtigungen).
SYSTEM_TEXT_INTELLIGENCE Alle der folgenden Bedingungen müssen erfüllt sein:
  • Identisch mit den Bedingungen für SYSTEM_UI_INTELLIGENCE, mit der Ausnahme, dass der vorinstallierte Dienst einen intelligenten On-Device-Prozessor für Text bereitstellt (z. B. für Live-Übersetzung oder AutoFill).
SYSTEM_VISUAL_INTELLIGENCE Alle der folgenden Bedingungen müssen erfüllt sein:
  • Identisch mit den Bedingungen für SYSTEM_UI_INTELLIGENCE, mit der Ausnahme, dass der vorinstallierte Dienst einen intelligenten On-Device-Prozessor für visuelle Funktionen bietet, bei dem Kameradaten analysiert werden. Beispiele: Das Display des Smartphones bleibt aktiv, solange der Nutzer darauf blickt. Die ideale Displayausrichtung wird anhand der Ausrichtung des Gesichts des Nutzers bestimmt, die von der nach vorn gerichteten Kamera des Geräts erfasst wird.
COMPANION_DEVICE_APP_STREAMING Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Zulässige Anwendungsfälle:
    • Streaming, Casting oder Spiegelung von Apps, die das Streaming, Casting oder die Spiegelung von einem Android-Gerät wie einem Smartphone oder Tablet auf einen Desktop- oder Laptop-Computer ermöglichen.
  • So stellen Sie die erste Verbindung von Gerät A zu Gerät B her:
    • Die Kopplung MUSS durch einen Einmalcode autorisiert werden, der auf dem Quellgerät (A) angezeigt und auf dem verbundenen Gerät (B) eingegeben wird. Alternativ kann der Nutzer die Kopplung bestätigen, indem er das Kontopasswort auf dem verbundenen Gerät (B) eingibt, wenn auf beiden Geräten mindestens ein übereinstimmendes Konto im Android AccountManager vorhanden ist.
    • Beide Geräte müssen sich während des Kopplungsvorgangs in unmittelbarer Nähe 1 zueinander befinden.
  • Beide Geräte müssen sich während des Streamings in der Nähe 1 voneinander befinden.
  • Die App kann Kommunikationskanäle mit verbundenen Geräten erstellen und verwalten, damit die Geräte Daten austauschen können. Die App und die verbundenen Geräte MÜSSEN sich gegenseitig authentifizieren (z. B. durch den Nachweis, dass sie gemeinsame Schlüssel kennen), um diese Kommunikationskanäle einzurichten. Die Kommunikationskanäle MÜSSEN durch Ende-zu-Ende-Verschlüsselung geschützt sein.
  • Die App kann Benachrichtigungen vom Quellgerät (A) an das verbundene Gerät (B) senden, damit der Nutzer auf dem verbundenen Gerät (B) auf die Benachrichtigungen reagieren kann.
  • Die für das App-Streaming erforderlichen Metadaten, z. B. die Liste der auf dem Quellgerät (A) verfügbaren Apps, können auf das verbundene Gerät (B) gestreamt werden.
  • Apps vom Quellgerät (A) auf das verbundene Gerät (B) streamen können, nachdem der Nutzer seine entsprechende Präferenz mit ausdrücklicher Einwilligung (entweder auf dem Quellgerät (A) oder auf dem verbundenen Gerät (B)) angegeben hat.
  • Ereignisse, die in einer gestreamten App auf dem verbundenen Gerät (B) auftreten, auf dem Quellgerät (A) wiedergeben (einfügen) können. Beispiel: Ein Touch-Ereignis wird auf dem verbundenen Gerät (B) an denselben Koordinaten wie auf dem Quellgerät (A) wiedergegeben oder ein Eingabeereignis, das auf dem verbundenen Gerät (B) aufgetreten ist, wird mit derselben Eingabesemantik wie auf dem Quellgerät (A) wiedergegeben.
  • Die App kann den Mikrofonstream des Quellgeräts durch den Mikrofonstream eines verbundenen Geräts ersetzen, während eine gestreamte App das Mikrofon verwendet.
  • Die App nimmt Audioinhalte vom Quellgerät (A) auf und streamt sie zum verbundenen Gerät (B).
  • Es wird EMPFOHLEN, den Zugriff auf Einstellungs-Apps und App-Stores über das verbundene Gerät (B) zu blockieren.
  • Ab Android 16 muss auf dem verbundenen Gerät (B) verhindert werden, dass Screenshots und Screenreader für sensible Inhalte wie sichere Fenster und Oberflächen verwendet werden.
  • MUSS die Integrität des Betriebssystem-Builds des verbundenen Geräts überprüfen (z. B. durch Geräteattestierung wie in VerifiedBootState).
  • Streame nur Apps, für die auf beiden Geräten nur ein passendes Konto in der Kontoregistrierung auf dem Gerät vorhanden ist, z. B. die Klasse AccountManager unter Android. Ist dies nicht der Fall, MUSS das Streaming mit einem Einmalcode autorisiert werden, der auf dem Quellgerät (A) angezeigt und auf dem verbundenen Gerät (B) eingegeben wird. Bei Geräten, die mehrere Nutzer (aber nicht mehrere Konten) mit derselben zuverlässigen Datenisolation wie bei Android-Unterstützung mehrerer Nutzer unterstützen, zählt ein Nutzer als Gerät.
  • MUSS das Streaming beenden und die Verbindung zum verbundenen Gerät (B) sofort trennen, wenn die Authentifizierung des Kontos auf dem verbundenen Gerät (B) abläuft oder widerrufen wird.
  • MUSS das Streaming beenden und die Verbindung zum verbundenen Gerät (B) trennen, wenn das verbundene Gerät (B), auf dem die Inhalte angezeigt werden, inaktiv ist. MAY keep the connected device's screen on for cases such as WakeLock, that keep the Android device's screen on. Ein Leerlauf-Zeitlimit MUSS vorhanden sein. Wenn das verbundene Gerät (B) kein eigenes Zeitlimit für Inaktivität hat, MUSS ein Zeitlimit für Inaktivität von maximal 5 Minuten verwendet werden.
  • Wenn auf dem Quellgerät (A) der Lockscreen Knowledge Factor (LSKF) verwendet wird, DÜRFEN Apps bei gesperrtem Bildschirm NICHT auf ein verbundenes Gerät (B) gestreamt werden, es sei denn, das verbundene Gerät (B) hat einen Sperrbildschirm und ist entsperrt.
  • Wenn das Quellgerät (A) von einem Administrator verwaltet wird, MUSS die App die vom Administrator festgelegten Richtlinien zum Aktivieren oder Deaktivieren des Streamings auf Geräte in der Nähe (z. B. über DevicePolicyManager-Einstellungen in Android) berücksichtigen.
  • MUSS dafür sorgen, dass die Remote-Displays und alle Quellen für Remote-Eingabeereignisse aus Nutzersicht zum selben logischen Gerät gehören (z. B. ein Remote-Display und eine verbundene Tastatur) und Ereignisse entsprechend weitergeleitet werden.
  • Der Nutzer MUSS das Streaming auf dem Quellgerät (A) beenden können, z. B. über eine Schaltfläche in einer dauerhaften Benachrichtigung. Dieses Verhalten ist durch den Sperrbildschirm eingeschränkt, wenn auf dem Quellgerät (A) eine Displaysperre eingerichtet ist. MUSS diese dauerhafte Aufforderung auf dem Quellgerät (A) anzeigen, die immer sichtbar und „above the fold“ ist.
  • Auf dem Quellgerät (A) MUSS eine Aufforderung angezeigt werden, wenn das Streaming auf einem anderen Gerät erfolgt, z. B. ein Symbol in der Statusleiste oder eine dauerhafte Benachrichtigung.
DEVICE_POLICY_MANAGEMENT Alle der folgenden Bedingungen müssen erfüllt sein:
  • Nur OEMs können diese Rolle der App zuweisen. Apps können diese Rolle nicht anfordern, da sie dem vom OEM definierten Paketnamen bei der Auslieferung des Geräts zugewiesen werden soll.
  • Die App muss in der Lage sein, ein verwaltetes Profil (Profileigentümer) oder ein verwaltetes Gerät (Geräteeigentümer) bereitzustellen, einschließlich des Herunterladens und Installierens des entsprechenden Device Policy Client als Geräte-/Profileigentümer, falls erforderlich.
  • Die App kann optional Ressourcen wie Strings und Drawables, die für die Verwaltung von Geräterichtlinien verwendet werden, dynamisch aktualisieren.
  • Die App kann entweder eine vorinstallierte System-App sein oder vor der Bereitstellung heruntergeladen und installiert werden.
  • Bei der Bereitstellung des Profilinhabers muss die App des Rolleninhabers, wenn sie auf einem bestimmten Android-Nutzer installiert ist, auf allen anwendbaren Profilen für diesen Nutzer installiert sein.
SYSTEM_APP_PROTECTION_SERVICE Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Der einzige Zweck der App besteht darin, potenziell schädliche Apps zu erkennen (Apps, die eine Gefahr für Nutzer, Nutzerdaten oder Geräte darstellen könnten, z. B. Trojaner, Phishing- und Spyware-Apps) oder unerwünschte Software für Mobilgeräte.
  • Die App muss alle Anforderungen erfüllen, die im Android CDD im Abschnitt 9.8.6 beschrieben sind. Betriebssystemebene und Umgebungsdaten:
  • In der App darf die normale Berechtigung android.permission.INTERNET nicht deklariert sein. Stattdessen muss über klar definierte APIs in einem Open-Source-Projekt auf das Internet zugegriffen werden.
  • Die App darf keine Bindung an andere Apps herstellen, mit Ausnahme der folgenden System-Apps: Permission Controller und Komponenten, die Telefonie- und Internet-APIs bereitstellen. Jede zulässige Bindung muss explizit über die <allow-association>-Konfiguration in der Systemkonfiguration eingerichtet werden.
  • Die App darf Daten nur dann an andere Apps weitergeben, wenn der Nutzer eine direkte Aktion ausführt, z. B. jedes Mal explizit eine Schaltfläche drückt, wenn die Daten weitergegeben werden.
SYSTEM_AUTOMOTIVE_CALENDAR_SYNC_MANAGER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Die App muss Kalenderdaten vom iOS- oder Android-Smartphone des Nutzers auf das Android Auto-Gerät übertragen. Das Android Auto-Gerät muss diese Kalenderdaten im Kalenderanbieter speichern.
  • Die App muss auf dem Smartphone eine UI-Komponente bereitstellen, über die der Nutzer die Kalendersynchronisierung aktivieren und die zu synchronisierenden Kalender auswählen kann. Die App muss auf dem Smartphone eine UI-Komponente bereitstellen, über die der Nutzer die Kalendersynchronisierung deaktivieren kann.
  • Die App sollte ohne Internetverbindung funktionieren. z. B. über direkte kabelgebundene oder kabellose Verbindungen.
AUTOMOTIVE_NAVIGATION Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App hat eine Aktivität, die von anderen Apps über Anfragen mit implizitem Intent aufgerufen werden kann und die den aktuellen Standort und die Umgebung des Nutzers anzeigt.
  • Die App hat eine Aktivität, die über Anfragen mit impliziten Intents aufgerufen werden kann. So kann der Nutzer zu einem bestimmten geografischen Standort navigieren.
  • Die App hat eine Aktivität, die im Kombi-Instrument gestartet wird, wenn die App den Navigationsfokus hat. Die Aktivität muss den aktuellen Standort und die Umgebung des Nutzers anzeigen und es ihm ermöglichen, zu einem bestimmten geografischen Standort zu navigieren.
COMPANION_DEVICE_COMPUTER Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Nutzer können Benachrichtigungen spiegeln und auf Fotos und Medien vom Smartphone auf einem verbundenen Computer zugreifen.
SYSTEM_SETTINGS_INTELLIGENCE Mindestens eines der folgenden Elemente:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Hat einen Dienst, der intelligente Funktionen für die Einstellungen-App bietet, z. B. Vorschläge und Suche.
NOTES Alle der folgenden Bedingungen müssen erfüllt sein:
COMPANION_DEVICE_GLASSES Die App kann Anfragen senden, um mit einem Brillen-Gerät verknüpft zu werden und es zu verwalten (über die API, die von der Klasse CompanionDeviceManager bereitgestellt wird). Wenn die Brille und die App über die von CDM bereitgestellte Benutzeroberfläche verbunden sind, können Nutzer ihre Brille verwalten, indem sie ihr Zugriff auf Kontakte und die Berechtigung zur Verwaltung von Benachrichtigungen und Telefonanrufen gewähren.
COMPANION_DEVICE_NEARBY_DEVICE_STREAMING Alle der folgenden Bedingungen müssen erfüllt sein:
  • Die App ist eine System-App.
  • Nur OEMs können diese Rolle für die App gewähren.
  • Zulässige Anwendungsfälle:
    • App-Streaming von einem Android-Gerät wie einem Smartphone oder Tablet auf ein Fahrzeug.
    • App-Streaming von einem Android-Gerät wie einem Smartphone oder Tablet auf ein XR-Gerät.
  • So stellen Sie die erste Verbindung von Gerät A zu Gerät B her:
    • Die Kopplung MUSS durch einen Einmalcode autorisiert werden, der auf dem Quellgerät (A) angezeigt und auf dem verbundenen Gerät (B) eingegeben wird. Alternativ kann der Nutzer die Kopplung bestätigen, indem er das Kontopasswort auf dem verbundenen Gerät (B) eingibt, wenn auf beiden Geräten mindestens ein übereinstimmendes Konto im Android AccountManager vorhanden ist.
    • Beide Geräte müssen sich während des Kopplungsvorgangs in unmittelbarer Nähe 1 zueinander befinden.
  • Beide Geräte müssen sich während des Streamings in der Nähe 1 voneinander befinden.
  • Die App kann Kommunikationskanäle mit verbundenen Geräten erstellen und verwalten, damit die Geräte Daten austauschen können. Die App und die verbundenen Geräte MÜSSEN sich gegenseitig authentifizieren (z. B. durch den Nachweis, dass sie gemeinsame Schlüssel kennen), um diese Kommunikationskanäle einzurichten. Die Kommunikationskanäle MÜSSEN durch Ende-zu-Ende-Verschlüsselung geschützt sein.
  • Die App kann Benachrichtigungen vom Quellgerät (A) an das verbundene Gerät (B) senden, damit der Nutzer auf dem verbundenen Gerät (B) auf die Benachrichtigungen reagieren kann.
  • Die für das App-Streaming erforderlichen Metadaten, z. B. die Liste der auf dem Quellgerät (A) verfügbaren Apps, können auf das verbundene Gerät (B) gestreamt werden.
  • Apps vom Quellgerät (A) auf das verbundene Gerät (B) streamen können, nachdem der Nutzer seine entsprechende Präferenz mit ausdrücklicher Einwilligung (entweder auf dem Quellgerät (A) oder auf dem verbundenen Gerät (B)) angegeben hat.
  • Ereignisse, die in einer gestreamten App auf dem verbundenen Gerät (B) auftreten, auf dem Quellgerät (A) wiedergeben (einfügen) können. Beispiel: Ein Touch-Ereignis wird auf dem verbundenen Gerät (B) an denselben Koordinaten wie auf dem Quellgerät (A) wiedergegeben oder ein Eingabeereignis, das auf dem verbundenen Gerät (B) aufgetreten ist, wird mit derselben Eingabesemantik wie auf dem Quellgerät (A) wiedergegeben.
  • Die App kann den Mikrofonstream des Quellgeräts durch den Mikrofonstream eines verbundenen Geräts ersetzen, während eine gestreamte App das Mikrofon verwendet.
  • Die App nimmt Audioinhalte vom Quellgerät (A) auf und streamt sie zum verbundenen Gerät (B).
  • Es wird EMPFOHLEN, den Zugriff auf Einstellungs-Apps und App-Stores über das verbundene Gerät (B) zu blockieren.
  • Ab Android 25Q2: Screenshots und Screenreading von vertraulichen Inhalten, z. B. sicheren Fenstern und Oberflächen, MÜSSEN auf dem verbundenen Gerät (B) verhindert werden.
  • MUSS die Integrität des Betriebssystem-Builds des verbundenen Geräts überprüfen (z. B. durch Geräteattestierung wie in VerifiedBootState).
  • Streame nur Apps, für die auf beiden Geräten nur ein passendes Konto in der Kontoregistrierung auf dem Gerät vorhanden ist, z. B. die Klasse AccountManager unter Android. Ist dies nicht der Fall, MUSS das Streaming mit einem Einmalcode autorisiert werden, der auf dem Quellgerät (A) angezeigt und auf dem verbundenen Gerät (B) eingegeben wird. Bei Geräten, die mehrere Nutzer (aber nicht mehrere Konten) mit derselben zuverlässigen Datenisolation wie bei Android-Unterstützung mehrerer Nutzer unterstützen, zählt ein Nutzer als Gerät.
  • MUSS das Streaming beenden und die Verbindung zum verbundenen Gerät (B) sofort trennen, wenn die Authentifizierung des Kontos auf dem verbundenen Gerät (B) abläuft oder widerrufen wird.
  • MUSS das Streaming beenden und die Verbindung zum verbundenen Gerät (B) trennen, wenn das verbundene Gerät (B), auf dem die Inhalte angezeigt werden, inaktiv ist. MAY keep the connected device's screen on for cases such as WakeLock, that keep the Android device's screen on. Ein Leerlauf-Zeitlimit MUSS vorhanden sein. Wenn das verbundene Gerät (B) kein eigenes Zeitlimit für Inaktivität hat, MUSS ein Zeitlimit für Inaktivität von maximal 5 Minuten verwendet werden.
  • Wenn auf dem Quellgerät (A) der Lockscreen Knowledge Factor (LSKF) verwendet wird, DÜRFEN Apps bei gesperrtem Bildschirm NICHT auf ein verbundenes Gerät (B) gestreamt werden, es sei denn, das verbundene Gerät (B) hat einen Sperrbildschirm und ist entsperrt.
  • Wenn das Quellgerät (A) von einem Administrator verwaltet wird, MUSS die App die vom Administrator festgelegten Richtlinien zum Aktivieren oder Deaktivieren des Streamings auf Geräte in der Nähe (z. B. über DevicePolicyManager-Einstellungen in Android) berücksichtigen.
  • MUSS dafür sorgen, dass die Remote-Displays und alle Quellen für Remote-Eingabeereignisse aus Nutzersicht zum selben logischen Gerät gehören (z. B. ein Remote-Display und eine verbundene Tastatur) und Ereignisse entsprechend weitergeleitet werden.
  • Der Nutzer MUSS das Streaming auf dem Quellgerät (A) beenden können, z. B. über eine Schaltfläche in einer dauerhaften Benachrichtigung. Dieses Verhalten ist durch den Sperrbildschirm eingeschränkt, wenn auf dem Quellgerät (A) eine Displaysperre eingerichtet ist. MUSS diese dauerhafte Aufforderung auf dem Quellgerät (A) anzeigen, die immer sichtbar und „above the fold“ ist.
  • Auf dem Quellgerät (A) MUSS eine Aufforderung angezeigt werden, wenn das Streaming auf einem anderen Gerät erfolgt, z. B. ein Symbol in der Statusleiste oder eine dauerhafte Benachrichtigung.
WALLET Eine der folgenden Möglichkeiten:
  • Die App hat einen NFC-APDU-Dienst, der mindestens eine AID in der Kategorie „PAYMENT“ statisch registriert.
  • Die App implementiert eine Instanz von QuickAccessWalletService.

1 Die Nähe wird dadurch definiert, dass sich die beiden Geräte in Bluetooth- oder WLAN-Reichweite voneinander befinden oder dass sie dasselbe lokale Netzwerk verwenden.