Kompatibilitätsdefinition für Android 17 [VORSCHAU]

1. Einführung

In diesem Dokument werden die Anforderungen aufgeführt, die erfüllt sein müssen, damit Geräte mit Android 17 kompatibel sind.

Die Verwendung von „MUSS“, „MÜSSEN“, „DARF NICHT“, „DÜRFEN NICHT“, „ERFORDERLICH“, „SOLLTE“, „SOLLTEN“, „SOLLTE NICHT“, „SOLLTEN NICHT“, „EMPFOHLEN“, „DARF“, „DÜRFEN“ und „OPTIONAL“ entspricht dem IETF-Standard RFC2119.

In diesem Dokument bezeichnet ein „Geräteimplementierer“ oder „Implementierer“ eine Person oder Organisation, die eine Hardware-/Softwarelösung entwickelt, auf der Android 17 ausgeführt wird. Eine „Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte Hardware-/Softwarelösung.

Damit ein Gerät als mit Android 17 kompatibel gilt, MUSS es die in dieser Kompatibilitätsdefinition festgelegten Anforderungen erfüllen, einschließlich aller per Verweis einbezogenen Dokumente.

Wenn diese Definition oder die in Abschnitt 10 beschriebenen Softwaretests nicht eindeutig, mehrdeutig oder unvollständig sind, liegt es in der Verantwortung des Geräteimplementierers, die Kompatibilität mit bestehenden Implementierungen sicherzustellen.

Aus diesem Grund ist das Open-Source-Projekt für Android sowohl die Referenz- als auch die bevorzugte Implementierung von Android. Geräteherstellern wird DRINGEND EMPFOHLEN, ihre Implementierungen so weit wie möglich auf dem „Upstream“-Quellcode zu basieren, der über das Open-Source-Projekt für Android verfügbar ist. Einige Komponenten können theoretisch durch alternative Implementierungen ersetzt werden. Es wird jedoch DRINGEND EMPFOHLEN, dies nicht zu tun, da das Bestehen der Softwaretests dadurch erheblich erschwert wird. Es liegt in der Verantwortung des Implementierers, für vollständige Verhaltenskompatibilität mit der Standard-Android-Implementierung zu sorgen, einschließlich und über die Compatibility Test Suite hinaus. Bestimmte Komponenten dürfen nicht ersetzt oder modifiziert werden.

Viele der in diesem Dokument verlinkten Ressourcen stammen direkt oder indirekt aus dem Android SDK und sind funktional identisch mit den Informationen in der Dokumentation dieses SDKs. In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Compatibility Test Suite von der SDK-Dokumentation abweicht, gilt die SDK-Dokumentation als maßgeblich. Alle technischen Details, die in den verlinkten Ressourcen in diesem Dokument angegeben sind, gelten durch die Einbeziehung als Teil dieser Kompatibilitätsdefinition.

1.1 Dokumentstruktur

1.1.1. Anforderungen nach Gerätetyp

Abschnitt 2 enthält alle Anforderungen, die für einen bestimmten Gerätetyp gelten. Jeder Unterabschnitt von Abschnitt 2 ist einem bestimmten Gerätetyp gewidmet.

Alle anderen Anforderungen, die universell für alle Android-Geräteimplementierungen gelten, sind in den Abschnitten nach Abschnitt 2 aufgeführt. In diesem Dokument werden diese Anforderungen als „Kernanforderungen“ bezeichnet.

1.1.2. Anforderungs-ID

Für MUST-Anforderungen wird eine Anforderungs-ID zugewiesen.

• Die ID wird nur für MUST-Anforderungen zugewiesen.
• STRONGLY RECOMMENDED-Anforderungen sind mit [SR] gekennzeichnet, aber es wird keine ID zugewiesen.
• Die ID besteht aus : Geräte-ID – Bedingungs-ID – Anforderungs-ID (z.B. C-0-1).

Jede ID wird so definiert:

• Gerätetyp-ID (siehe 2.) Gerätetypen)
  • C: Core (Anforderungen, die für alle Android-Geräteimplementierungen gelten)
  • H: Android-Mobilgerät
  • T: Android TV-Gerät
  • A: Android Automotive-Implementierung
  • W: Android-Smartwatch-Implementierung
  • Tab: Implementierung auf Android-Tablets
• Bedingungs-ID
  • Wenn die Anforderung bedingungslos ist, wird diese ID auf 0 gesetzt.
  • Wenn die Anforderung bedingt ist, wird für die erste Bedingung die Zahl 1 zugewiesen. Die Zahl wird innerhalb desselben Abschnitts und desselben Gerätetyps um 1 erhöht.
• Anforderungs-ID
  • Diese ID beginnt mit 1 und wird innerhalb desselben Abschnitts und derselben Bedingung um 1 erhöht.

1.1.3. Anforderungs-ID in Abschnitt 2

Die Anforderungs-IDs in Abschnitt 2 bestehen aus zwei Teilen. Die erste entspricht einer Abschnitts-ID, wie oben beschrieben. Der zweite Teil gibt den Formfaktor und die formfaktorspezifische Anforderung an.

Abschnitts-ID, gefolgt von der oben beschriebenen Anforderungs-ID.

• Die ID in Abschnitt 2 besteht aus: Abschnitts-ID / Geräte-ID – Bedingungs-ID – Anforderungs-ID (z.B. 7.4.3/A-0-1).

2. Gerätetypen

Das Open-Source-Projekt für Android bietet einen Software-Stack, der für eine Vielzahl von Gerätetypen und Formfaktoren verwendet werden kann. Zur Unterstützung der Sicherheit auf Geräten wird erwartet, dass der Software-Stack, einschließlich eines Ersatzbetriebssystems oder einer alternativen Kernel-Implementierung, in einer sicheren Umgebung ausgeführt wird, wie in Abschnitt 9 und an anderer Stelle in diesem CDD beschrieben. Für einige Gerätetypen gibt es ein relativ gut etabliertes Ökosystem für die App-Verteilung.

In diesem Abschnitt werden diese Gerätetypen sowie zusätzliche Anforderungen und Empfehlungen für die einzelnen Gerätetypen beschrieben.

Alle Android-Geräteimplementierungen, die nicht in einen der beschriebenen Gerätetypen passen, MÜSSEN dennoch alle Anforderungen in den anderen Abschnitten dieser Kompatibilitätsdefinition erfüllen.

2.1 Gerätekonfigurationen

Die wichtigsten Unterschiede in der Hardwarekonfiguration nach Gerätetyp finden Sie in den gerätespezifischen Anforderungen in diesem Abschnitt.

2.2. Anforderungen für Handheld-Geräte

Ein Android-Mobilgerät ist eine Android-Geräteimplementierung, die in der Regel in der Hand gehalten wird, z. B. ein MP3-Player, ein Smartphone oder ein Tablet.

Android-Geräteimplementierungen werden als Handheld klassifiziert, wenn sie alle folgenden Kriterien erfüllen:

• Eine Stromquelle, die Mobilität ermöglicht, z. B. ein Akku.
• Die physische diagonale Displaygröße muss zwischen 4 und 8 Zoll liegen.
• Es muss über eine Touchscreen-Eingabeschnittstelle verfügen.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Implementierungen auf Android-Mobilgeräten.

2.2.1. Hardware

Implementierungen für Mobilgeräte:

• [7.1.1.1/H-0-1] MUSS mindestens ein Android-kompatibles Display mit einer Mindestgröße von 5,6 cm an der kurzen und 8,6 cm an der langen Kante haben.

• [7.1.1.3/H-SR-1] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, die Anzeigegröße (Bildschirmdichte) zu ändern.

• [7.1.1.1/H-0-2] MÜSSEN die GPU-Zusammensetzung von Grafikpuffern unterstützen, die mindestens so groß sind wie die höchste Auflösung eines integrierten Displays.

• [7.1.1.1/H-0-3]^* MUSS jede UI_MODE_NORMAL-Anzeige, die für Drittanbieteranwendungen verfügbar gemacht wird, auf einen ungehinderten physischen Anzeigebereich abbilden, der an der kurzen Kante mindestens 2,2 Zoll und an der langen Kante mindestens 3,4 Zoll groß ist.

• [7.1.1.3/H-0-1]^* MUSS DENSITY_DEVICE_STABLE auf 92% oder mehr als die tatsächliche, physische Dichte des entsprechenden Displays festlegen.

Wenn Implementierungen von Mobilgeräten Vulkan unterstützen, gilt Folgendes:

• [7.1.4.2/H-1-1] MÜSSEN die im Android Baseline 2021-Profil angegebenen Anforderungen erfüllen.

Wenn Implementierungen von Mobilgeräten über Configuration.isScreenHdr() Unterstützung für HDR-Displays (High Dynamic Range) beanspruchen, gilt Folgendes:

• [7.1.4.5/H-1-1] MUSS die Unterstützung für die Erweiterungen EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace und VK_EXT_hdr_metadata bewerben.

Implementierungen für Mobilgeräte:

• [7.1.4.6/H-0-1] MUSS über eine Systemeigenschaft graphics.gpu.profiler.support melden, ob das Gerät die GPU-Profilerstellung unterstützt.

Wenn Handheld-Geräteimplementierungen die Unterstützung über eine Systemeigenschaft graphics.gpu.profiler.support deklarieren, gilt Folgendes:

• [7.1.4.6/H-1-1] MUSS als Ausgabe einen Protobuf-Trace ausgeben, der dem Schema für GPU-Zähler und GPU-Renderphasen entspricht, das in der Perfetto-Dokumentation definiert ist.

• [7.1.4.6/H-1-2] MUSS konforme Werte für die GPU-Zähler des Geräts gemäß dem gpu counter trace-Paket-Proto melden.

• [7.1.4.6/H-1-3] MUSS konforme Werte für die GPU-RenderStages des Geräts gemäß dem RenderStage-Trace-Paket-Proto melden.

• [7.1.4.6/H-1-4] MUSS einen GPU-Frequenz-Tracepoint gemäß dem Format power/gpu_frequency melden.

Implementierungen für Mobilgeräte:

• [7.1.5/H-0-1] MUSS die Unterstützung für den Legacy-Anwendungskompatibilitätsmodus enthalten, wie er im Upstream-Android-Open-Source-Code implementiert ist. Das bedeutet, dass Geräteimplementierungen die Trigger oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert wird, NICHT ändern dürfen und das Verhalten des Kompatibilitätsmodus selbst NICHT ändern dürfen.

• [7.2.1/H-0-1] MUSS Unterstützung für Drittanbieter-Apps für Eingabemethoden-Editoren (Input Method Editors, IMEs) enthalten.

• [7.2.3/H-0-2] MUSS sowohl das normale als auch das Ereignis bei langem Drücken der Zurück-Funktion (KEYCODE_BACK) an die Vordergrundanwendung senden. Diese Ereignisse DÜRFEN NICHT vom System verarbeitet werden und KÖNNEN außerhalb des Android-Geräts ausgelöst werden (z.B. über eine externe Hardwaretastatur, die mit dem Android-Gerät verbunden ist).

• [7.2.3/H-0-3] MÜSSEN die Startbildschirmfunktion auf allen Android-kompatiblen Displays bereitstellen, die den Startbildschirm anzeigen.

• [7.2.3/H-0-4] MÜSSEN die Zurück-Funktion auf allen Android-kompatiblen Displays und die Funktion „Letzte“ auf mindestens einem der Android-kompatiblen Displays bereitstellen.

• [7.2.4/H-0-1] MÜSSEN die Eingabe über den Touchscreen unterstützen.

• [7.2.4/H-SR-1] Es wird DRINGEND EMPFOHLEN, die vom Nutzer ausgewählte Assistenz-App zu starten, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die ACTION_ASSIST bei langem Drücken von KEYCODE_MEDIA_PLAY_PAUSE oder KEYCODE_HEADSETHOOK verarbeitet, wenn die Vordergrundaktivität diese Ereignisse bei langem Drücken nicht verarbeitet.

• [7.3.1/H-SR-1] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser einzubauen.

Wenn Mobilgeräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser enthalten,

• [7.3.1/H-1-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz melden können.

Wenn Implementierungen von Mobilgeräten einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps an Anwendungen melden, gilt Folgendes:

• [7.3.3/H-2-1] MÜSSEN GNSS-Messungen melden, sobald sie gefunden werden, auch wenn noch kein aus GPS/GNSS berechneter Standort gemeldet wurde.

• [7.3.3/H-2-2] MUSS GNSS-Pseudobereiche und ‑Pseudobereichsraten melden, die unter störungsfreien Bedingungen nach der Standortbestimmung im Stillstand oder bei einer Beschleunigung von weniger als 0,2 Metern pro Sekunde zum Quadrat in mindestens 95% der Fälle ausreichen, um die Position innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0,2 Metern pro Sekunde zu berechnen.

Wenn Mobilgeräteimplementierungen ein 3‑Achsen-Gyroskop enthalten, gilt Folgendes:

• [7.3.4/H-3-1] MUSS Ereignisse mit einer Frequenz von mindestens 100 Hz melden können.

• [7.3.4/H-3-2] MUSS Orientierungsänderungen von bis zu 1.000 Grad pro Sekunde messen können.

Implementierungen auf Mobilgeräten, die einen Sprachanruf starten und in getPhoneType einen anderen Wert als PHONE_TYPE_NONE angeben können:

• [7.3.8/H] SOLLTE einen Näherungssensor enthalten.

Implementierungen für Mobilgeräte:

• [7.3.11/H-SR-1] Es wird DRINGEND EMPFOHLEN, einen Lagesensor mit 6 Freiheitsgraden zu unterstützen.

Implementierungen für Mobilgeräte, die Bluetooth LE unterstützen:

• [7.4.3/H-SR-1] Es wird DRINGEND EMPFOHLEN, die Bluetooth LE-Datenpaketlängen-Erweiterung zu unterstützen.

Wenn Geräteimplementierungen Unterstützung für 802.11 (WLAN) enthalten, gilt Folgendes:

• [7.4.2.4/H-1-1] MUSS die Unterstützung für Wi-Fi Passpoint enthalten.

Wenn Geräte das NAN‑Protokoll (Neighbor Awareness Networking) für WLAN durch Deklarieren von PackageManager.FEATURE_WIFI_AWARE und den WLAN‑Standort (WLAN‑RTT) durch Deklarieren von PackageManager.FEATURE_WIFI_RTT unterstützen, gilt Folgendes:

• [7.4.2.5/H-1-1] MUSS die Entfernung bei einer Bandbreite von 160 MHz im 68. Perzentil (berechnet mit der kumulativen Verteilungsfunktion) auf +/-1 Meter genau, bei einer Bandbreite von 80 MHz im 68. Perzentil auf +/-2 Meter genau, bei einer Bandbreite von 40 MHz im 68. Perzentil auf +/-4 Meter genau und bei einer Bandbreite von 20 MHz im 68. Perzentil auf +/-8 Meter genau angeben, wenn die Entfernung 10 cm, 1 m, 3 m und 5 m beträgt. Dies muss über die Android-API WifiRttManager#startRanging beobachtet werden.

• [7.4.2.5/H-SR-1] Es wird DRINGEND EMPFOHLEN, den Bereich bei einer Bandbreite von 160 MHz im 90. Perzentil (berechnet mit der kumulativen Verteilungsfunktion) auf +/-1 Meter genau anzugeben, bei einer Bandbreite von 80 MHz im 90. Perzentil auf +/-2 Meter, bei einer Bandbreite von 40 MHz im 90. Perzentil auf +/-4 Meter und bei einer Bandbreite von 20 MHz im 90. Perzentil auf +/-8 Meter bei Entfernungen von 10 cm, wie über die Android API WifiRttManager#startRanging beobachtet.

Es wird DRINGEND EMPFOHLEN, die in der Anwesenheitskalibrierung beschriebenen Schritte zur Einrichtung der Messung auszuführen.

Wenn Implementierungen von Mobilgeräten FEATURE_BLUETOOTH_LE deklarieren, gilt Folgendes:

• [7.4.3/H-1-3] Der Rx-Offset MUSS gemessen und ausgeglichen werden, damit der mediane BLE-RSSI bei einem Abstand von 1 m von einem Referenzgerät, das mit ADVERTISE_TX_POWER_HIGH sendet, -50 dBm ±15 dB beträgt.

• [7.4.3/H-1-4] Der Tx-Offset MUSS gemessen und kompensiert werden, damit der Median des BLE-RSSI bei ‑50 dBm ±15 dB liegt, wenn das Scannen von einem Referenzgerät aus erfolgt, das sich in 1 m Entfernung befindet und mit ADVERTISE_TX_POWER_HIGH sendet.

Wenn Mobilgerät-Implementierungen ein logisches Kameragerät enthalten, in dem Funktionen mit CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA aufgeführt werden, gilt Folgendes:

• [7.5.4/H-1-1] MUSS standardmäßig ein normales Sichtfeld haben und zwischen 50 und 70 Grad liegen.

Implementierungen für Mobilgeräte:

• [7.6.1/H-0-1] MUSS mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als /data-Partition bezeichnet) zur Verfügung haben.

• [7.6.1/H-0-2] MUSS für ActivityManager.isLowRamDevice() „true“ zurückgeben, wenn für den Kernel und den Userspace weniger als 1 GB Arbeitsspeicher verfügbar ist.

Wenn in Implementierungen von Mobilgeräten nur ein 32‑Bit-ABI deklariert wird:

• [7.6.1/H-1-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 416 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu qHD (z.B. FWVGA) verwendet.

• [7.6.1/H-2-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 592 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu HD+ (z.B. HD, WSVGA) verwendet.

• [7.6.1/H-3-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 896 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu FHD (z.B. WSXGA+) verwendet.

• [7.6.1/H-4-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.344 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu QHD (z. B. QWXGA) verwendet.

Wenn in Implementierungen von Mobilgeräten die Unterstützung von 64‑Bit-ABIs (mit oder ohne 32‑Bit-ABIs) deklariert wird:

• [7.6.1/H-5-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 816 MB betragen, wenn für das Standarddisplay Framebuffer-Auflösungen bis zu qHD (z.B. FWVGA) verwendet werden.

• [7.6.1/H-6-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 944 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu HD+ (z.B. HD, WSVGA) verwendet.

• [7.6.1/H-7-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 1280 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu FHD (z.B. WSXGA+) verwendet.

• [7.6.1/H-8-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.824 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu QHD (z. B. QWXGA) verwendet.

Der oben erwähnte „für den Kernel und den Userspace verfügbare Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicher, der zusätzlich zu dem Arbeitsspeicher bereitgestellt wird, der bereits für Hardwarekomponenten wie Funk, Video usw. reserviert ist, die in Geräteimplementierungen nicht der Kontrolle des Kernels unterliegen.

Wenn Implementierungen für Mobilgeräte weniger als oder gleich 1 GB Arbeitsspeicher für den Kernel und den Userspace umfassen, gilt Folgendes:

• [7.6.1/H-9-1] MUSS das Funktions-Flag android.hardware.ram.low deklarieren.

• [7.6.1/H-9-2] MUSS mindestens 1,1 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) haben.

Wenn Implementierungen von Mobilgeräten mehr als 1 GB Arbeitsspeicher für den Kernel und den Userspace enthalten, gilt Folgendes:

• [7.6.1/H-10-1] MUSS mindestens 4 GB nicht flüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) zur Verfügung haben.

• SOLLTEN das Funktions-Flag android.hardware.ram.normal deklarieren.

Wenn Implementierungen von Mobilgeräten mindestens 2 GB und weniger als 4 GB Arbeitsspeicher für den Kernel und den Nutzerbereich umfassen, gilt Folgendes:

• [7.6.1/H-SR-1] Es wird DRINGEND EMPFOHLEN, nur 32-Bit-Userspace zu unterstützen (sowohl Apps als auch Systemcode).

Wenn Implementierungen für Mobilgeräte weniger als 2 GB Arbeitsspeicher für den Kernel und den Userspace umfassen, gilt Folgendes:

• [7.6.1/H-1-1] MUSS nur ein einzelnes ABI unterstützen (entweder nur 64-Bit oder nur 32-Bit).

Implementierungen für Mobilgeräte:

• [7.6.2/H-0-1] DÜRFEN keinen gemeinsamen Anwendungsspeicher mit einer Größe von weniger als 1 GiB bereitstellen.

• [7.7.1/H] SOLLTE einen USB-Anschluss enthalten, der den Peripheriemodus unterstützt.

Wenn Mobilgeräteimplementierungen einen USB-Anschluss mit einem Controller im Peripheriemodus enthalten, gilt Folgendes:

• [7.7.1/H-1-1] MUSS die Android Open Accessory (AOA)-API implementieren.

Wenn Mobilgerät-Implementierungen einen USB-Anschluss enthalten, der den Hostmodus unterstützt, gilt Folgendes:

• [7.7.2/H-1-1] MUSS die USB-Audioklasse implementieren, wie in der Android SDK-Dokumentation beschrieben.

Implementierungen für Mobilgeräte:

• [7.8.1/H-0-1] MUSS ein Mikrofon enthalten.

• [7.8.2/H-0-1] MÜSSEN eine Audioausgabe haben und android.hardware.audio.output deklarieren.

Wenn Implementierungen für Mobilgeräte alle Leistungsanforderungen für die Unterstützung des VR-Modus erfüllen und diesen unterstützen, gilt Folgendes:

• [7.9.1/H-1-1] MUSS das Funktions-Flag android.hardware.vr.high_performance deklarieren.

• [7.9.1/H-1-2] MUSS eine Anwendung enthalten, die android.service.vr.VrListenerService implementiert und von VR-Anwendungen über android.app.Activity#setVrModeEnabled aktiviert werden kann.

Wenn Mobilgeräteimplementierungen einen oder mehrere USB‑C-Anschlüsse im Hostmodus enthalten und (USB-Audioklasse) implementieren, müssen sie zusätzlich zu den Anforderungen in Abschnitt 7.7.2 Folgendes erfüllen:

• [7.8.2.2/H-1-1] MUSS die folgende Softwarezuordnung von HID-Codes bereitstellen:

Funktion	Zuordnungen	Kontext	Verhalten
A	HID-Verwendungsseite: 0x0C HID-Verwendung: 0x0CD Kernel-Schlüssel: KEY_PLAYPAUSE Android-Schlüssel: KEYCODE_MEDIA_PLAY_PAUSE	Medienwiedergabe	Eingabe: Kurz drücken Ausgabe: Wiedergabe oder Pause
			Eingabe: Lange drücken Ausgabe: Sprachbefehl starten Wird gesendet: android.speech.action.VOICE_SEARCH_HANDS_FREE, wenn das Gerät gesperrt ist oder das Display ausgeschaltet ist. Andernfalls wird android.speech.RecognizerIntent.ACTION_WEB_SEARCH gesendet.
		Eingehender Anruf	Eingabe: Kurz drücken Ausgabe: Anruf annehmen
			Eingabe: Lange drücken Ausgabe: Anruf ablehnen
		Aktiver Anruf	Eingabe: Kurz drücken Ausgabe: Anruf beenden
			Eingabe: Lange drücken Ausgabe: Mikrofon stummschalten oder Stummschaltung aufheben
B	HID-Verwendungsseite: 0x0C HID-Verwendung: 0x0E9 Kernel-Schlüssel: KEY_VOLUMEUP Android-Schlüssel: VOLUME_UP	Medienwiedergabe, aktiver Anruf	Eingabe: Kurz oder lang drücken Ausgabe: Erhöht die Lautstärke des Systems oder Headsets
C	HID-Verwendungsseite: 0x0C HID-Verwendung: 0x0EA Kernel-Schlüssel: KEY_VOLUMEDOWN Android-Schlüssel: VOLUME_DOWN	Medienwiedergabe, aktiver Anruf	Eingabe: Kurz oder lang drücken Ausgabe: Verringert die System- oder Headset-Lautstärke
D	HID-Verwendungsseite: 0x0C HID-Verwendung: 0x0CF Kernel-Schlüssel: KEY_VOICECOMMAND Android-Schlüssel: KEYCODE_VOICE_ASSIST	Alle. Kann in jeder Instanz ausgelöst werden.	Eingabe: Kurz oder lang drücken Ausgabe: Sprachbefehl starten

• [7.8.2.2/H-1-2] MUSS bei einem Einstecken des Steckers ACTION_HEADSET_PLUG auslösen, jedoch erst, nachdem die USB-Audioschnittstellen und ‑Endpunkte ordnungsgemäß aufgelistet wurden, um den Typ des angeschlossenen Terminals zu ermitteln.

Wenn die USB-Audio-Terminaltypen 0x0302 erkannt werden, gilt Folgendes:

• [7.8.2.2/H-2-1] MUSS Intent ACTION_HEADSET_PLUG mit dem Extra „microphone“ (Mikrofon) auf 0 übertragen.

Wenn die USB-Audio-Terminaltypen 0x0402 erkannt werden, gilt Folgendes:

• [7.8.2.2/H-3-1] MUSS den Intent ACTION_HEADSET_PLUG mit dem Extra „microphone“ (Mikrofon) auf 1 übertragen.

Wenn die API AudioManager.getDevices() aufgerufen wird, während das USB-Peripheriegerät angeschlossen ist, gilt Folgendes:

• [7.8.2.2/H-4-1] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_HEADSET und der Rolle isSink() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x0302 ist.

• [7.8.2.2/H-4-2] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_HEADSET und der Rolle isSink() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x0402 ist.

• [7.8.2.2/H-4-3] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_HEADSET und der Rolle isSource() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x0402 ist.

• [7.8.2.2/H-4-4] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_DEVICE und der Rolle isSink() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x603 ist.

• [7.8.2.2/H-4-5] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_DEVICE und der Rolle isSource() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x604 ist.

• [7.8.2.2/H-4-6] MUSS ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE und mit der Rolle isSink() aufgeführt werden, wenn das Feld „USB-Audio-Terminaltyp“ 0x400 ist.

• [7.8.2.2/H-4-7] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_DEVICE und der Rolle isSource() auflisten, wenn das Feld „USB-Audioanschluss-Typ“ 0x400 ist.

• [7.8.2.2/H-SR-1] Es wird DRINGEND EMPFOHLEN, beim Anschließen eines USB‑C-Audio-Peripheriegeräts die USB-Deskriptoren aufzulisten, die Terminaltypen zu identifizieren und den Intent ACTION_HEADSET_PLUG in weniger als 1.000 Millisekunden zu übertragen.

Informationen zu Implementierungen auf Mobilgeräten, die android.hardware.audio.output und android.hardware.microphone deklarieren, finden Sie in Abschnitt 5.6 zu den Anforderungen an RTL und TTL.

Ein linearer Resonanzaktuator (Linear Resonant Actuator, LRA) ist ein Einmassen-Feder-System mit einer dominanten Resonanzfrequenz, bei der sich die Masse in Richtung der gewünschten Bewegung bewegt.

Wenn Implementierungen von Mobilgeräten mindestens einen 7.10-Linearantrieb für allgemeine Zwecke enthalten, gilt Folgendes:

• [7.10/H] Der Aktuator SOLLTE in der Nähe der Stelle platziert werden, an der das Gerät normalerweise gehalten oder mit den Händen berührt wird.

• [7.10/H] SHOULD den haptischen Aktuator auf der X-Achse (links-rechts) der natürlichen Ausrichtung des Geräts bewegen.

Wenn Mobilgeräteimplementierungen einen Mehrzweck-Haptik-Aktuator haben, der ein linearer Resonanzaktuator (Linear Resonant Actuator, LRA) für die X-Achse ist, gilt Folgendes:

• [7.10/H] Die Resonanzfrequenz des LRA der X‑Achse SOLLTE unter 200 Hz liegen.

Wenn Implementierungen für Mobilgeräte der Zuordnung von haptischen Konstanten folgen, gilt Folgendes:

• [7.10/H]^* SHOULD den Implementierungsstatus durch Ausführen der APIs android.os.Vibrator.areAllEffectsSupported() und android.os.Vibrator.arePrimitivesSupported() überprüfen.

• [7.10/H]^* SOLLTE eine Qualitätsbewertung für haptische Konstanten durchführen.

• [7.10/H]^* SOLLTE die Fallback-Konfiguration für nicht unterstützte Primitiven wie in der Implementierungsanleitung> für Konstanten beschrieben überprüft und bei Bedarf aktualisiert werden.

2.2.2. Multimedia

Implementierungen auf Mobilgeräten MÜSSEN die folgenden Audio-Codierungs- und ‑Decodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] MPEG-4 AAC-Profil (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC-Profil (AAC+)
• [5.1/H-0-5] AAC ELD (Enhanced Low Delay AAC)

2.2.3. Software

Implementierungen auf Mobilgeräten MÜSSEN die folgenden Video-Codierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

• [5.2/H-0-1] H.264 AVC
• [5.2/H-0-2] VP8
• [5.2/H-0-3] AV1

Implementierungen auf Mobilgeräten MÜSSEN die folgenden Videodecodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

• [5.3/H-0-1] H.264 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9
• [5.3/H-0-6] AV1

2.2.3. Software

Implementierungen für Mobilgeräte:

• [3.2.3.1/H-0-1] MUSS eine Anwendung haben, die die Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE und ACTION_CREATE_DOCUMENT wie in der SDK-Dokumentation beschrieben verarbeitet und dem Nutzer die Möglichkeit bietet, über die DocumentsProvider-API auf die Daten des Dokumentanbieters zuzugreifen.

• [3.2.3.1/H-SR-1] Es wird DRINGEND EMPFOHLEN, eine E‑Mail-Anwendung vorzuladen, die ACTION_SENDTO- oder ACTION_SEND- oder ACTION_SEND_MULTIPLE-Intents zum Senden einer E‑Mail verarbeiten kann.

• [3.4.1/H-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API bereitstellen.

• [3.4.2/H-0-1] MUSS eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten.

• [3.8.1/H-SR-1] Es wird DRINGEND EMPFOHLEN, einen Standard-Launcher zu implementieren, der das Anpinnen von Verknüpfungen, Widgets und widgetFeatures in Apps unterstützt.

• [3.8.1/H-SR-2] Es wird DRINGEND EMPFOHLEN, einen Standard-Launcher zu implementieren, der über die ShortcutManager API schnellen Zugriff auf die zusätzlichen Verknüpfungen bietet, die von Drittanbieter-Apps bereitgestellt werden.

• [3.8.1/H-SR-3] Es wird DRINGEND EMPFOHLEN, eine Standard-Launcher-App einzubinden, in der Badges für die App-Symbole angezeigt werden.

• [3.8.3/H-0-1] MÜSSEN Drittanbieter-Apps ermöglichen, Nutzer über wichtige Ereignisse über die API-Klassen Notification und NotificationManager zu benachrichtigen.

• [3.8.3/H-0-2] MÜSSEN Rich Notifications unterstützen.

• [3.8.3/H-0-3] MÜSSEN Pop-up-Benachrichtigungen unterstützen.

• [3.8.3/H-0-4] MUSS eine Benachrichtigungsleiste enthalten, über die der Nutzer Benachrichtigungen direkt steuern kann (z. B. antworten, pausieren, schließen, blockieren). Dazu muss er die vom Nutzer bereitgestellten Funktionen wie Aktionsschaltflächen oder das Steuerfeld verwenden, wie im AOSP implementiert.

• [3.8.3/H-0-5] MÜSSEN die über RemoteInput.Builder setChoices() bereitgestellten Optionen in der Benachrichtigungsleiste angezeigt werden.

• [3.8.3/H-SR-1] Es wird DRINGEND EMPFOHLEN, die erste über RemoteInput.Builder setChoices() bereitgestellte Auswahl in der Benachrichtigungsleiste ohne zusätzliche Nutzerinteraktion anzuzeigen.

• [3.8.3/H-SR-2] Es wird DRINGEND EMPFOHLEN, alle über RemoteInput.Builder setChoices() bereitgestellten Optionen in der Benachrichtigungsleiste anzuzeigen, wenn der Nutzer alle Benachrichtigungen in der Benachrichtigungsleiste maximiert.

• [3.8.3.1/H-SR-1] Es wird DRINGEND EMPFOHLEN, Aktionen, für die Notification.Action.Builder.setContextual als true festgelegt ist, inline mit den von Notification.Remoteinput.Builder.setChoices angezeigten Antworten zu präsentieren.

• [3.8.4/H-SR-1] Es wird DRINGEND EMPFOHLEN, einen Assistenten auf dem Gerät zu implementieren, der die Assist-Aktion verarbeitet.

Wenn Implementierungen von Mobilgeräten MediaStyle-Benachrichtigungen unterstützen, gilt Folgendes:

• [3.8.3.1/H-SR-2] Es wird DRINGEND EMPFOHLEN, über die System-UI eine Benutzeroberfläche (z. B. eine Ausgabeauswahl) bereitzustellen, über die Nutzer zwischen geeigneten verfügbaren Media-Routen (z. B. Bluetooth-Geräten und Routen, die für MediaRouter2Manager bereitgestellt werden) wechseln können, wenn eine App eine MediaStyle-Benachrichtigung mit einem MediaSession-Token sendet.

Die Benachrichtigung über Live-Updates einer App kann beworben werden, wenn die App alle Werbemerkmale erfüllt. Eine solche Benachrichtigung wird in diesem Dokument als „Promoted Live Update Notification“ (Benachrichtigung für beworbene Live-Updates) bezeichnet. Auf Mobilgeräten MUSS die Benachrichtigung für beworbene Live-Updates gemäß den folgenden Anforderungen deutlich angezeigt werden.

Wenn Implementierungen von Mobilgeräten API‑Level 36.1 oder höher deklarieren, gilt Folgendes:

• [3.8.3.1/H-0-1] MUSS eine Benachrichtigung für beworbene Live-Updates an einer gut sichtbaren Stelle auf dem Sperrbildschirm anzeigen.

• [3.8.3.1/H-0-12] MUSS oben im Benachrichtigungsstapel angezeigt werden Heads-up-Benachrichtigung und über farbigen Benachrichtigungen (wobei setColorized = true), wenn die beworbene Live-Update-Benachrichtigung zusammen mit anderen Benachrichtigungen angezeigt wird.

  • MAY bestimmt die Reihenfolge der Benachrichtigungen zu beworbenen Live-Updates, die in der Benachrichtigungsleiste und auf dem Sperrbildschirm angezeigt werden, wenn mehr als eine App für eine Benachrichtigung zu beworbenen Live-Updates infrage kommt.

• [3.8.3.1/H-0-2] MUSS eine Benachrichtigung für beworbene Live-Updates im maximierten Zustand anzeigen.

• [3.8.3.1/H-0-3] Es DARF keine Möglichkeit für Nutzer geben, die oben erweiterte Benachrichtigung zu minimieren.

• [3.8.3.1/H-0-4] MÜSSEN die grundlegenden Formatierungen (fett, kursiv und unterstrichen) von Textinhalten in einer Benachrichtigung für beworbene Live-Updates anzeigen, wie sie von StyleSpan oder UnderlineSpan bereitgestellt werden.

• [3.8.3.1/H-0-5] In einer beworbenen Live-Update-Benachrichtigung DÜRFEN nur Standardaktionsobjekte (über Notification.Action) angezeigt werden. Nicht standardmäßige Aktionsobjekte wie Eingabefelder, Antwortschaltflächen und kontextbezogene Aktionen (über addRemoteInput() und setContextual()) MÜSSEN ausgeblendet werden, auch wenn die Benachrichtigung sie enthält.

• [3.8.3.1/H-0-6] Für eine Benachrichtigung über ein beworbenes Live-Update, die Notification.getSmallIcon() enthalten MUSS, MUSS eine kompakte Darstellung, auch als Status-Chip in der SDK-Dokumentation bezeichnet, angezeigt werden.

  • [3.8.3.1/H-0-7] Andere Felder sind für die kompakte Darstellung optional. Wenn die kompakte Darstellung jedoch maximiert werden kann, MUSS Notification.getShortCriticalText() (falls vorhanden) oder Notification.when (falls Notification.getShortCriticalText nicht vorhanden ist) angezeigt werden.

  • [3.8.3.1/H-0-8] Wenn mehrere Benachrichtigungen für beworbene Live-Updates vorhanden sind, MUSS mindestens eine davon in der Statusleiste als kompakte Darstellung angezeigt werden.

  • [3.8.3.1/H-0-9] Beim Tippen auf die kompakte Darstellung MUSS entweder die zugehörige Benachrichtigung angezeigt (bevorzugt) oder die zugehörige App (über Notification.contentIntent) geöffnet werden.

  • [3.8.3.1/H-0-13] MUSS in der zugehörigen Benachrichtigung dieselben Inhalte wie in der Benachrichtigungsleiste anzeigen.

• [3.8.3.1/H-0-10] MUSS eine Möglichkeit für Nutzer bieten, die beworbene Anzeige von Benachrichtigungen einzelner Apps zu deaktivieren und zu aktivieren.

• [3.8.3.1/H-0-11] MUSS alle Live-Update-Benachrichtigungen korrekt rendern, einschließlich, aber nicht beschränkt auf nicht beworbene Live-Update-Benachrichtigungen, die die Werbemerkmale nicht oder nur teilweise erfüllen. Solche nicht beworbenen Benachrichtigungen MÜSSEN in einem nicht beworbenen Zustand angezeigt werden.

Wenn Geräteimplementierungen, die den Navigationsschlüssel für die Funktion „Letzte Apps“ enthalten, wie in Abschnitt 7.2.3 beschrieben, die Benutzeroberfläche ändern, gilt Folgendes:

• [3.8.3/H-1-1] MUSS das Verhalten für das Anpinnen von Bildschirmen implementieren und dem Nutzer ein Einstellungsmenü zum Aktivieren und Deaktivieren der Funktion zur Verfügung stellen.

Wenn Mobilgeräteimplementierungen die Assist-Aktion unterstützen, gilt Folgendes:

• [3.8.4/H-SR-2] Es wird DRINGEND EMPFOHLEN, das lange Drücken der HOME-Taste als die vorgesehene Interaktion zum Starten der Assist-App zu verwenden, wie in Abschnitt 7.2.3 beschrieben. MUSS die vom Nutzer ausgewählte Assistenz-App starten, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die den Intent ACTION_ASSIST verarbeitet.

Wenn Implementierungen von Mobilgeräten conversation notifications unterstützen und sie in einem separaten Bereich von Benachrichtigungen für Warnungen und lautlosen Benachrichtigungen, die nicht zu Unterhaltungen gehören, gruppieren, gilt Folgendes:

• [3.8.4/H-1-1]^* MÜSSEN Konversationsbenachrichtigungen vor anderen Benachrichtigungen angezeigt werden, mit Ausnahme von Benachrichtigungen für laufende Dienste im Vordergrund und Benachrichtigungen mit importance:high.

Wenn Android-Mobilgeräteimplementierungen einen Sperrbildschirm unterstützen, gilt Folgendes:

• [3.8.10/H-1-1] MUSS Sperrbildschirm-Benachrichtigungen einschließlich der Media Notification Template anzeigen.

Wenn Implementierungen von Mobilgeräten einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:

• [3.9/H-1-1] MÜSSEN alle in der Android SDK-Dokumentation definierten Richtlinien zur Geräteverwaltung implementieren.

Wenn Mobilgerät-Implementierungen Unterstützung für die APIs ControlsProviderService und Control enthalten und Drittanbieteranwendungen Gerätesteuerungen veröffentlichen dürfen, gilt Folgendes:

• [3.8.16/H-1-1] MUSS das Feature-Flag android.software.controls deklarieren und auf true setzen.

• [3.8.16/H-1-2] MUSS eine Benutzeroberfläche bieten, über die Nutzer die von Drittanbieteranwendungen über die APIs ControlsProviderService und Control registrierten Lieblingsgerätesteuerungen hinzufügen, bearbeiten, auswählen und bedienen können.

• [3.8.16/H-1-3] MUSS innerhalb von drei Interaktionen über einen Standard-Launcher Zugriff auf diese Nutzerfunktion bieten.

• [3.8.16/H-1-4] MUSS in dieser Benutzeroberfläche den Namen und das Symbol jeder Drittanbieter-App, die Steuerelemente über die ControlsProviderService-API bereitstellt, sowie alle angegebenen Felder, die von den Control-APIs bereitgestellt werden, korrekt rendern.

• [3.8.16/H-1-5] Der Nutzer MUSS die Möglichkeit haben, die von Drittanbieteranwendungen über die ControlsProviderService- und die Control-Control.isAuthRequired-API registrierten trivialen Geräte-Steuerelemente für die App zu deaktivieren.

• [3.8.16/H-1-6] Geräteimplementierungen MÜSSEN den Angebotscharakter für den Nutzer wie folgt korrekt rendern:

  • Wenn für das Gerät config_supportsMultiWindow=true festgelegt ist und die App die Metadaten META_DATA_PANEL_ACTIVITY in der Deklaration ControlsProviderService deklariert, einschließlich des ComponentName einer gültigen Activity (wie von der API definiert), MUSS die App diese Activity in diese Nutzerfunktion einbetten.
  • Wenn in der App keine Metadaten META_DATA_PANEL_ACTIVITY deklariert sind, MÜSSEN die angegebenen Felder, die von der ControlsProviderService API bereitgestellt werden, sowie alle angegebenen Felder, die von den Control APIs bereitgestellt werden, gerendert werden.

• [3.8.16/H-1-7] Wenn die App die Metadaten META_DATA_PANEL_ACTIVITY deklariert, MUSS sie die in [3.8.16/H-1-5] definierte Einstellung beim Starten der eingebetteten Aktivität über EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS übergeben.

Wenn auf einem Mobilgerät keine solchen Steuerelemente implementiert sind, gilt Folgendes:

• [3.8.16/H-2-1] MUSS null für die APIs ControlsProviderService und Control gemeldet werden.

• [3.8.16/H-2-2] MUSS das Funktions-Flag android.software.controls deklarieren und auf false festlegen.

Wenn Implementierungen auf Mobilgeräten nicht im Modus „gesperrte Aufgabe“ ausgeführt werden und Inhalte in die Zwischenablage kopiert werden, gilt Folgendes:

• [3.8.17/H-1-1] MUSS dem Nutzer eine Bestätigung präsentieren, dass Daten in die Zwischenablage kopiert wurden (z. B. eine Miniaturansicht oder eine Benachrichtigung mit dem Text „Inhalte kopiert“). Geben Sie außerdem an, ob Daten aus der Zwischenablage geräteübergreifend synchronisiert werden.

Implementierungen für Mobilgeräte:

• [3.10/H-0-1] MUSS Barrierefreiheitsdienste von Drittanbietern unterstützen.

• [3.10/H-SR-1] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorzuinstallieren, die mit dem Schalterzugriff und TalkBack vergleichbar sind oder deren Funktionen übertreffen (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden), wie sie im TalkBack-Open-Source-Projekt bereitgestellt werden.

• [3.11/H-0-1] MUSS die Installation von TTS-Engines von Drittanbietern unterstützen.

• [3.11/H-SR-1] Es wird DRINGEND EMPFOHLEN, eine TTS-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.

• [3.13/H-SR-1] Es wird DRINGEND EMPFOHLEN, eine Benutzeroberflächenkomponente für die Schnelleinstellungen einzubinden.

Wenn Android-Mobilgeräteimplementierungen die Unterstützung von FEATURE_BLUETOOTH oder FEATURE_WIFI deklarieren, gilt Folgendes:

• [3.16/H-1-1] MUSS die Funktion zur Gerätekopplung unterstützen.

Wenn die Navigationsfunktion als Aktion auf dem Bildschirm oder als Geste bereitgestellt wird:

• [7.2.3/H] Der Bereich für die Gestenerkennung für die Home-Funktion SOLLTE nicht höher als 32 dp vom unteren Bildschirmrand sein.

Wenn auf Mobilgeräten eine Navigationsfunktion als Geste von einer beliebigen Stelle am linken und rechten Displayrand bereitgestellt wird:

• [7.2.3/H-0-1] Der Touchgestenbereich der Navigationsfunktion MUSS auf jeder Seite weniger als 40 dp breit sein. Die Breite des Gestenbereichs SOLLTE standardmäßig 24 dp betragen.

Wenn Mobilgeräte einen sicheren Sperrbildschirm unterstützen und mindestens 2 GB Arbeitsspeicher für den Kernel und den Nutzerbereich verfügbar haben, gilt Folgendes:

• [3.9/H-1-2] MÜSSEN die Unterstützung von verwalteten Profilen über das Funktions-Flag android.software.managed_users deklarieren.

Wenn in Implementierungen von tragbaren Android-Geräten die Unterstützung für die Kamera über android.hardware.camera.any deklariert wird, gilt Folgendes:

• [7.5.4/H-1-1] MUSS die Intention von android.media.action.STILL_IMAGE_CAMERA und android.media.action.STILL_IMAGE_CAMERA_SECURE berücksichtigen und die Kamera wie im SDK beschrieben im Standbildmodus starten.

• [7.5.4/H-1-2] MUSS den Intent android.media.action.VIDEO_CAMERA zum Starten der Kamera im Videomodus wie im SDK beschrieben berücksichtigen.

Wenn die Einstellungen-App einer Geräteimplementierung eine Split-Funktion mit Activity Embedding implementiert, gilt Folgendes:

• [3.2.3.1/ H-1-1] Es MUSS eine Aktivität geben, die den Intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY verarbeitet, wenn die Split-Funktion aktiviert ist. Die Aktivität MUSS durch android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK geschützt sein und die Aktivität des Intents starten, der aus Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI geparst wurde.

2.2.4. Leistung und Energie

• [8.1/H-0-1] Konsistente Frame-Latenz. Inkonsistente Frame-Latenz oder eine Verzögerung beim Rendern von Frames DÜRFEN nicht häufiger als 5 Frames pro Sekunde auftreten und SOLLTEN weniger als 1 Frame pro Sekunde betragen.

• [8.1/H-0-2] Latenz der Benutzeroberfläche. Geräteimplementierungen MÜSSEN für eine Nutzererfahrung mit geringer Latenz sorgen, indem sie eine Liste mit 10.000 Listeneinträgen, wie in der Android Compatibility Test Suite (CTS) definiert, in weniger als 36 Sekunden scrollen.

• [8.1/H-0-3] Task Switching. Wenn mehrere Anwendungen gestartet wurden, muss das erneute Starten einer bereits laufenden Anwendung nach dem Start weniger als 1 Sekunde dauern.

Implementierungen für Mobilgeräte:

• [8.2/H-0-1] MÜSSEN eine sequenzielle Schreibleistung von mindestens 5 MB/s bieten.

• [8.2/H-0-2] MÜSSEN eine zufällige Schreibleistung von mindestens 0,5 MB/s gewährleisten.

• [8.2/H-0-3] MUSS eine sequenzielle Leseleistung von mindestens 15 MB/s gewährleisten.

• [8.2/H-0-4] MUSS eine zufällige Leseleistung von mindestens 3,5 MB/s bieten.

Wenn Implementierungen von Mobilgeräten Funktionen zur Verbesserung der Energieverwaltung des Geräts enthalten, die in AOSP enthalten sind oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:

• [8.3/H-1-1] MUSS dem Nutzer die Möglichkeit bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.

• [8.3/H-1-2] Es MUSS eine Möglichkeit für Nutzer geben, alle Apps anzuzeigen, die vom App-Standby und vom Stromsparmodus ausgenommen sind.

Implementierungen für Mobilgeräte:

• [8.4/H-0-1] MUSS ein Energieprofil pro Komponente bereitstellen, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch durch die Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.

• [8.4/H-0-2] MÜSSEN alle Werte zum Stromverbrauch in Milliamperestunden (mAh) angegeben werden.

• [8.4/H-0-3] MUSS den CPU-Stromverbrauch für jede Prozess-UID melden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.

• [8.4/H-0-4] MUSS diese Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.

• [8.4/H] SOLLTE der Hardwarekomponente selbst zugeschrieben werden, wenn der Stromverbrauch der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.

Wenn Implementierungen von Mobilgeräten einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

• [8.4/H-1-1] MUSS die android.intent.action.POWER_USAGE_SUMMARY-Intention berücksichtigen und ein Einstellungsmenü anzeigen, in dem dieser Stromverbrauch zu sehen ist.

Implementierungen für Mobilgeräte:

• [8.5/H-0-1] MUSS eine Benutzeroberfläche bereitstellen, über die alle Apps mit aktiven Diensten im Vordergrund oder vom Nutzer initiierten Jobs angezeigt werden können, einschließlich der Dauer der einzelnen Dienste seit ihrem Start, wie im SDK-Dokument beschrieben.

• [8.5/H-0-2]Es MUSS eine Möglichkeit für Nutzer geben, eine App zu beenden, die einen Dienst im Vordergrund oder einen vom Nutzer initiierten Job ausführt.

2.2.5. Sicherheitsmodell

Implementierungen für Mobilgeräte:

• [9/H-0-1] MÜSSEN die android.hardware.security.model.compatible-Funktion deklarieren.

• [9.1/H-0-1] Drittanbieter-Apps MÜSSEN über die Berechtigung android.permission.PACKAGE_USAGE_STATS auf die Nutzungsstatistiken zugreifen können. Außerdem MUSS ein für Nutzer zugänglicher Mechanismus vorhanden sein, mit dem der Zugriff auf solche Apps als Reaktion auf die Intention android.settings.ACTION_USAGE_ACCESS_SETTINGS gewährt oder widerrufen werden kann.

Wenn Mobilgeräteimplementierungen eine Standardanwendung zur Unterstützung von VoiceInteractionService enthalten, gilt Folgendes:

• [9.1/H-0-2] DARF ACCESS_FINE_LOCATION NICHT als Standard für diese Anwendung gewähren.

Geräteimplementierungen MÜSSEN die Unterstützung für android.software.credentials deklarieren und:

• [9/H-0-2] MUSS die android.settings.CREDENTIAL_PROVIDER-Absicht berücksichtigen, damit ein bevorzugter Anbieter für den Credential Manager ausgewählt werden kann. Dieser Anbieter wird für Autofill aktiviert und ist auch der standardmäßige Standort zum Speichern neuer Anmeldedaten, die über den Credential Manager eingegeben werden.

• [9/H-0-3] Es MÜSSEN mindestens zwei gleichzeitige Anmeldedatenanbieter unterstützt werden und in den Einstellungen muss eine Möglichkeit für Nutzer vorhanden sein, Anbieter zu aktivieren oder zu deaktivieren.

• [9.5/H-1-1] Anforderung in Android 16 entfernt.

Implementierungen für Mobilgeräte:

• [9.11/H-0-2] Die Schlüsselspeicher-Implementierung MUSS durch eine isolierte Ausführungsumgebung gesichert werden.

• [9.11/H-0-3] MÜSSEN Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie der Hash-Funktionen der MD5-, SHA-1- und SHA-2-Familie enthalten, um die unterstützten Algorithmen des Android-Schlüsselspeichersystems in einem Bereich, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird, ordnungsgemäß zu unterstützen. Die sichere Isolation MUSS alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer geeigneten hypervisorbasierten Isolation sind alternative Optionen.

• [9.11/H-0-4] Die Sperrbildschirmauthentifizierung MUSS in der isolierten Ausführungsumgebung erfolgen und die Verwendung der an die Authentifizierung gebundenen Schlüssel DARF NUR bei erfolgreicher Authentifizierung zugelassen werden. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Authentifizierung auf dem Sperrbildschirm durchführen kann. Das Upstream-Android-Open-Source-Projekt bietet die Gatekeeper-Hardwareabstraktionsschicht (HAL) und Trusty, die verwendet werden können, um diese Anforderung zu erfüllen.

• [9.11/H-0-5] MÜSSEN die Schlüsselattestierung unterstützen, wobei der Attestationssignierschlüssel durch sichere Hardware geschützt ist und die Signierung in sicherer Hardware erfolgt. Die Attestierungssignaturschlüssel DÜRFEN NICHT als dauerhafte Geräte-IDs verwendet werden.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version eingeführt wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen durch eine isolierte Ausführungsumgebung gesicherten Schlüsselspeicher zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert das android.hardware.fingerprint-Feature, das einen durch eine isolierte Ausführungsumgebung gesicherten Schlüsselspeicher erfordert.

Wenn Mobilgeräte einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:

• [9.11/H-1-1] Der Nutzer MUSS das kürzeste Zeitlimit für den Ruhemodus auswählen können, d. h. eine Übergangszeit vom entsperrten zum gesperrten Zustand von 15 Sekunden oder weniger.

• [9.11/H-1-2] MUSS dem Nutzer die Möglichkeit bieten, Benachrichtigungen auszublenden und alle Formen der Authentifizierung zu deaktivieren, mit Ausnahme der primären Authentifizierung, die in 9.11.1 Sicherer Sperrbildschirm beschrieben wird. AOSP erfüllt die Anforderung als Sperrmodus.

Wenn Implementierungen für Mobilgeräte mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony nicht deklariert wird, gilt Folgendes:

• [9.5/H-2-1] Das Gerät MUSS eingeschränkte Profile unterstützen. Mit dieser Funktion können Geräteinhaber zusätzliche Nutzer und ihre Funktionen auf dem Gerät verwalten. Mit eingeschränkten Profilen können Geräteinhaber schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen für die in diesen Umgebungen verfügbaren Apps verwalten.

Wenn Implementierungen für Mobilgeräte mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony deklarieren, gilt Folgendes:

• [9.5/H-3-1] MUSS eingeschränkte Profile unterstützen, MUSS aber mit der AOSP-Implementierung von Steuerelementen übereinstimmen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen bzw. zu verwehren.

• [9.5/H-4-1] Anforderung in Android 16 entfernt.

• [9.5/H-4-2] Anforderung in Android 16 entfernt.

Eingeschränkte Einstellungen

Bei eingeschränkten Einstellungen werden dem Nutzer sichtbare Warnungen angezeigt und er wird um Bestätigung gebeten, um Berechtigungen für jede Anwendung zu erteilen, die entweder:

• Die Installation erfolgt nach dem Herunterladen über eine andere Anwendung als eine „App-Store“-Anwendung, die durch PackageManager als PACKAGE_DOWNLOADED_FILE identifiziert wird, z. B. über eine Messaging-Anwendung oder einen Browser.

• Die App wurde aus einer lokalen Datei installiert (z. B. per Sideloading). Sie wird durch PackageManager als PACKAGE_SOURCE_LOCAL_FILE identifiziert.

Für alle erzwungenen Berechtigungen und die zugehörigen Kennungen, die unten in [9.8/H-0-5] aufgeführt sind.

Solche Anwendungen werden für die in diesem Abschnitt aufgeführten Anforderungen als „Abgedeckte Anwendungen“ gekennzeichnet.

Geräteimplementierungen:

• [9.8/H-0-1] MUSS die oben beschriebenen eingeschränkten Einstellungen für Folgendes implementieren:

  • Besondere Berechtigungen

    • Bedienungshilfen (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
    • Benachrichtigungs-Listener (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
    • Geräteadministrator-Apps (Manifest.permission.BIND_DEVICE_ADMIN)
    • Über anderen Apps einblenden (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
    • Zugriff auf Nutzungsdaten (AppOpsManager.OPSTR_GET_USAGE_STATS)

  • Rollen (Standard-Apps)

    • Telefon (RoleManager.ROLE_DIALER)
    • SMS (RoleManager.ROLE_SMS)

  • Laufzeitberechtigungen

    • SMS-Laufzeit (Manifest.permission_group.SMS)

• [9.8/H-0-2] Eingeschränkte Einstellungen MÜSSEN standardmäßig aktiviert sein und es wird DRINGEND EMPFOHLEN, keine Nutzerfunktion anzubieten, mit der ein Nutzer eingeschränkte Einstellungen für alle Anwendungen deaktivieren kann.

• [9.8/H-0-3] MUSS sicherstellen, dass für jede abgedeckte Anwendung eine Nutzerbestätigung eingeholt wird, bevor eine der erzwungenen Berechtigungen gewährt werden kann.

• [9.8/H-0-4] MUSS nur die Nutzerbestätigung zulassen, damit eingeschränkte Einstellungen über die AppInfo-Seite der abgedeckten Anwendung mit der EnhancedConfirmationManager API abgerufen werden können.

• [9.8/H-0-5] Es wird DRINGEND EMPFOHLEN, EnhancedConfirmationManager für alle speziellen Berechtigungen zu integrieren und aufzurufen, um dynamisch zu ermitteln, ob es sich um eine eingeschränkte Einstellung handelt.

  • Wecker und Erinnerungen: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • Zugriff auf alle Dateien: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • Über anderen Apps einblenden: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • Unbekannte Apps installieren: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • Medien verwalten: AppOpsManager.OPSTR_MANAGE_MEDIA
  • Systemeinstellungen ändern: AppOpsManager.OPSTR_WRITE_SETTINGS
  • Bild im Bild: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • Display aktivieren: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • Vollbildbenachrichtigungen: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • WLAN-Steuerung: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • Bedienungshilfen: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • Benachrichtigungs-Listener: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • Zugriff auf Nutzungsdaten: AppOpsManager.OPSTR_GET_USAGE_STATS
  • Geräteadministrator: Manifest.permission.BIND_DEVICE_ADMIN
  • „Bitte nicht stören“: Manifest.permission.MANAGE_NOTIFICATIONS

Android unterstützt über die System-API „VoiceInteractionService“ einen Mechanismus für die sichere Always-on-Hotword-Erkennung ohne Hinweis auf den Mikrofonzugriff und die Always-on-Suchanfrageerkennung ohne Hinweis auf den Mikrofon- oder Kamerazugriff.

Wenn Implementierungen für Mobilgeräte die System-API HotwordDetectionService oder einen anderen Mechanismus zur Hotword-Erkennung ohne Mikrofonzugriffsanzeige unterstützen, gilt Folgendes:

• [9.8/H-1-1] MUSS dafür sorgen, dass der Hotword-Erkennungsdienst Daten nur an das System, ContentCaptureService oder den On-Device-Spracherkennungsdienst übertragen kann, der von SpeechRecognizer#createOnDeviceSpeechRecognizer() erstellt wurde.

• [9.8/H-1-2] Der Hotword-Erkennungsdienst MUSS dafür sorgen, dass Mikrofonaudiodaten oder daraus abgeleitete Daten nur über die HotwordDetectionService API an den Systemserver oder über die ContentCaptureManager API an ContentCaptureService übertragen werden können.

• [9.8/H-1-3] MUSS für eine einzelne, durch Hardware ausgelöste Anfrage an den Hotword-Erkennungsdienst kein Mikrofon-Audio liefern, das länger als 30 Sekunden ist.

• [9.8/H-1-4] MUSS für eine einzelne Anfrage an den Hotword-Erkennungsdienst keinen gepufferten Mikrofonaudio bereitstellen, der älter als 8 Sekunden ist.

• [9.8/H-1-5] MUSS dem Sprachinteraktionsdienst oder einer ähnlichen Einheit KEINEN gepufferten Mikrofonaudio bereitstellen, der älter als 30 Sekunden ist.

• [9.8/H-1-6] DÜRFEN bei jedem erfolgreichen Hotword-Ergebnis nicht mehr als 100 Byte Daten (ohne Audiostreams) aus dem Hotword-Erkennungsdienst übertragen werden.

• [9.8/H-1-7] DARF bei jedem negativen Hotword-Ergebnis nicht mehr als 5 Bit Daten aus dem Hotword-Erkennungsdienst übertragen.

• [9.8/H-1-8] Die Übertragung von Daten aus dem Hotword-Erkennungsdienst MUSS nur bei einer Hotword-Validierungsanfrage vom Systemserver zulässig sein.

• [9.8/H-1-9] Eine vom Nutzer installierbare Anwendung DARF NICHT den Hotword-Erkennungsdienst bereitstellen.

• [9.8/H-1-10] In der Benutzeroberfläche DÜRFEN KEINE quantitativen Daten zur Mikrofonnutzung durch den Hotword-Erkennungsdienst angezeigt werden.

• [9.8/H-1-11] Die Anzahl der Byte, die in jeder Übertragung vom Hotword-Erkennungsdienst enthalten sind, MUSS protokolliert werden, damit Sicherheitsforscher sie prüfen können.

• [9.8/H-1-12] MUSS einen Debug-Modus unterstützen, in dem der Rohinhalt jeder Übertragung vom Hotword-Erkennungsdienst protokolliert wird, damit Sicherheitsforscher ihn prüfen können.

• [9.8/H-1-14] Die Mikrofonanzeige MUSS wie in Abschnitt 9.8.2 beschrieben angezeigt werden, wenn ein erfolgreiches Hotword-Ergebnis an den Sprachinteraktionsdienst oder eine ähnliche Einheit übertragen wird.

• [9.8/H-1-15] MUSS dafür sorgen, dass Audiostreams, die bei erfolgreichen Hotword-Ergebnissen bereitgestellt werden, unidirektional vom Hotword-Erkennungsdienst zum Sprachinteraktionsdienst übertragen werden.

• [9.8/H-SR-1] Es wird DRINGEND EMPFOHLEN, Nutzer zu benachrichtigen, bevor eine Anwendung als Anbieter des Hotword-Erkennungsdienstes festgelegt wird.

• [9.8/H-SR-2] Es wird DRINGEND EMPFOHLEN, die Übertragung unstrukturierter Daten aus dem Hotword-Erkennungsdienst zu unterbinden.

• [9.8/H-SR-3] Es wird DRINGEND EMPFOHLEN, den Prozess, der den Hotword-Erkennungsdienst hostet, mindestens einmal pro Stunde oder alle 30 Hardware-Trigger-Ereignisse neu zu starten, je nachdem, was zuerst eintritt.

Wenn Geräteimplementierungen eine Anwendung enthalten, die die System-API HotwordDetectionService oder einen ähnlichen Mechanismus zur Hotword-Erkennung ohne Mikrofonnutzungsanzeige verwendet, muss die Anwendung:

• [9.8/H-2-1] Der Nutzer MUSS für jede unterstützte Hotword-Phrase explizit benachrichtigt werden.

• [9.8/H-2-2] Rohaudiodaten oder daraus abgeleitete Daten DÜRFEN NICHT über den Hotword-Erkennungsdienst gespeichert werden.

• [9.8/H-2-3] Es DÜRFEN keine Audiodaten, Daten, die verwendet werden können, um das Audio (ganz oder teilweise) zu rekonstruieren, oder Audioinhalte, die nicht mit dem Hotword selbst zusammenhängen, vom Hotword-Erkennungsdienst übertragen werden, außer an den ContentCaptureService oder den On-Device-Spracherkennungsdienst.

Wenn Implementierungen von Mobilgeräten die System-API VisualQueryDetectionService oder einen anderen Mechanismus zur Erkennung von Anfragen ohne Anzeige des Mikrofon- und/oder Kamerazugriffs unterstützen, gilt Folgendes:

• [9.8/H-3-1] MUSS dafür sorgen, dass der Dienst zur Erkennung von Anfragen Daten nur an das System, an ContentCaptureService oder an den On-Device-Spracherkennungsdienst (erstellt von SpeechRecognizer#createOnDeviceSpeechRecognizer()) übertragen kann.

• [9.8/H-3-2] Es DARF NICHT zugelassen werden, dass Audio- oder Videoinformationen aus dem VisualQueryDetectionService übertragen werden, außer an ContentCaptureService oder den On-Device-Spracherkennungsdienst.

• [9.8/H-3-3] Es MUSS eine Nutzerbenachrichtigung in der System-UI angezeigt werden, wenn das Gerät die Absicht des Nutzers erkennt, mit der Digital Assistant-App zu interagieren (z. B. durch Erkennen der Anwesenheit des Nutzers über die Kamera).

• [9.8/H-3-4] Es MUSS ein Mikrofonsymbol angezeigt werden und die erkannte Nutzeranfrage MUSS direkt nach der Erkennung in der Benutzeroberfläche angezeigt werden.

• [9.8/H-3-5] Eine vom Nutzer installierbare Anwendung DARF den Dienst zur Erkennung visueller Anfragen NICHT bereitstellen.

Wenn Implementierungen von Mobilgeräten android.hardware.microphone deklarieren, gilt Folgendes:

• [9.8.2/H-4-1] Die Mikrofonanzeige MUSS angezeigt werden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 mit der CDD-Kennzeichnung [C-4-X] genannten Rollen auf das Mikrofon zugreifen.

• [9.8.2/H-4-2] MUSS die Liste der zuletzt verwendeten und aktiven Apps, die das Mikrofon verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen anzeigen.

• [9.8.2/H-4-3] Das Mikrofonsymbol darf nicht für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Nutzerinteraktion ausgeblendet werden.

• [9.8.2/H-4-4] MUSS die Liste der zuletzt verwendeten und aktiven Apps, die das Mikrofon verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen zugehörigen Attributionshinweisen anzeigen.

Wenn Implementierungen von Mobilgeräten android.hardware.camera.any deklarieren, gilt Folgendes:

• [9.8.2/H-5-1] MUSS den Kamerazugriff-Hinweis anzeigen, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn auf die Kamera nur von Apps mit den in Abschnitt 9.1 mit der CDD-Kennung [C-4-X] genannten Rollen zugegriffen wird.

• [9.8.2/H-5-2] MÜSSEN die letzten und aktiven Apps, die die Kamera verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen angezeigt werden.

• [9.8.2/H-5-3] DARF den Kamerazugriff-Hinweis für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Nutzerinteraktion nicht ausblenden.

Der Bootmodus mit Verifikation ist eine Funktion, die die Integrität der Gerätesoftware sicherstellt. Wenn Geräteimplementierungen die Funktion unterstützen, gilt Folgendes:

• [9.10/H-1-1] ALLE schreibgeschützten Partitionen, die während der Android-Bootsequenz eingebunden werden, MÜSSEN überprüft werden und der VBMeta-Digest MUSS alle diese überprüften Partitionen in seine Berechnung einbeziehen.

2.2.6. Kompatibilität von Entwicklertools und -optionen

Implementierungen für Mobilgeräte (* Nicht anwendbar für Tablets):

• [6.1/H-0-1]* MÜSSEN den Shell-Befehl cmd testharness unterstützen.

Implementierungen für Mobilgeräte:

• Perfetto

  • [6.1/H-0-2] MUSS dem Shell-Nutzer eine /system/bin/perfetto-Binärdatei zur Verfügung stellen, deren Befehlszeile der Perfetto-Dokumentation entspricht.

  • [6.1/H-0-3] Die binäre Datei von Perfetto MUSS eine Protobuf-Konfiguration als Eingabe akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.

  • [6.1/H-0-4] Die binäre Datei „perfetto“ MUSS als Ausgabe einen Protobuf-Trace schreiben, der dem in der Perfetto-Dokumentation definierten Schema entspricht.

  • [6.1/H-0-5] MÜSSEN über die Binärdatei „perfetto“ mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitstellen.

  • [6.1/H-0-6] Der Perfetto-Tracing-Daemon MUSS standardmäßig aktiviert sein (Systemeigenschaft persist.traced.enable).

2.2.7. Handheld Media Performance Class

Die Definition der Media Performance Class finden Sie in Abschnitt 7.11 und die Definition aller Messwerte in der Definition der Media Performance Class.

2.2.7.1. Medien

Wenn Implementierungen für Mobilgeräte einen Wert ungleich null für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

• MUSS alle in Android 17 CDD, Abschnitt 2.2.7.1 aufgeführten Media-Anforderungen erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.1/H-1-1] Die maximale Anzahl von Hardware-Videodecodersitzungen, die in einer beliebigen Codec-Kombination gleichzeitig ausgeführt werden können, MUSS über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() entsprechend der deklarierten Media Performance Class Level des Geräts beworben werden.

• [5.1/H-1-2] MÜSSEN Hardware-Videodecoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher), gleichzeitige Instanzen und Frame-Drops entsprechend der deklarierten Media Performance Class Level des Geräts unterstützen.

• [5.1/H-1-3] Die maximale Anzahl von Hardware-Video-Encoder-Sitzungen, die in einer beliebigen Codec-Kombination gleichzeitig ausgeführt werden können, MUSS über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() entsprechend der deklarierten Media Performance Class Level des Geräts beworben werden.

• [5.1/H-1-4] MUSS Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher), gleichzeitige Instanzen und Frame-Drops entsprechend der deklarierten Media Performance Class Level des Geräts unterstützen.

• [5.1/H-1-5] Die maximale Anzahl gleichzeitiger Hardware-Video-Encoder- und ‑Decoder-Sitzungen in einer beliebigen Codec-Kombination MUSS über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() beworben werden, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.1/H-1-6] MUSS Hardware-Videodecoder- und Hardware-Videoencoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher), gleichzeitige Instanzen und Frame-Drops entsprechend der deklarierten Media Performance Class Level des Geräts unterstützen.

• [5.1/H-1-7] MUSS für alle Hardware-Video-Encoder bei einer Belastung, die der deklarierten Media Performance Class Level des Geräts entspricht, eine Latenz bei der Codec-Initialisierung für eine Video-Codierungssitzung mit 1080p oder weniger haben.

• [5.1/H-1-8] MUSS für alle Audio-Encoder bei einer Belastung, die der deklarierten Media Performance Class Level des Geräts entspricht, eine Codec-Initialisierungslatenz für eine Audio-Codierungssitzung mit einer Bitrate von 128 kbit/s oder weniger aufweisen.

• [5.1/H-1-9] MUSS zwei Instanzen von sicheren Hardware-Videodecoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) und Frame-Drops entsprechend dem deklarierten Media Performance Class Level des Geräts unterstützen.

• [5.1/H-1-10] MUSS 3 Instanzen von nicht sicheren Hardware-Videodecoder-Sitzungen zusammen mit 1 Instanz einer sicheren Hardware-Videodecoder-Sitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, AV1 oder höher), Auflösungen und Frame-Drops entsprechend der deklarierten Media Performance Class Level des Geräts unterstützen.

• [5.1/H-1-11] MUSS einen sicheren Decoder für jeden AVC-, HEVC-, VP9- oder AV1‑Hardware-Decoder unterstützen, der dem deklarierten Media Performance Class Level des Geräts entspricht.

• [5.1/H-1-12] MUSS eine Codec-Initialisierungslatenz für eine Videodecodierungssitzung mit 1080p oder weniger für alle Hardware-Videodecoder haben, wenn die Last dem deklarierten Media Performance Class Level des Geräts entspricht.

• [5.1/H-1-13] MUSS eine Codec-Initialisierungslatenz für eine Audio-Decodierungssitzung mit einer Bitrate von 128 kbit/s oder weniger für alle Audio-Decoder unter Last entsprechend der deklarierten Media Performance Class Level des Geräts haben.

• [5.1/H-1-14] MÜSSEN das AV1-Hardware-Decoderprofil, die Funktion und die Anzeigemethode unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.1/H-1-15] MUSS mindestens einen Hardware-Videodecoder haben, der 4K60 unterstützt und der deklarierten Media Performance Class Level des Geräts entspricht.

• [5.1/H-1-16] MUSS mindestens einen Hardware-Video-Encoder haben, der 4K60 unterstützt und der deklarierten Media Performance Class Level des Geräts entspricht.

• [5.1/H-1-17] MUSS mindestens einen Hardware-Bilddecoder haben, der das AVIF-Baseline-Profil entsprechend der deklarierten Media Performance Class Level des Geräts unterstützt.

• [5.1/H-1-18] MUSS einen AV1-Encoder unterstützen, der die Anforderungen an Bitrate, Bilder pro Sekunde und Auflösung erfüllt, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.1/H-1-19] MUSS drei Instanzen von 10‑Bit-Hardware-Videodecoder- und Hardware-Videoencoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher), Auflösung und Frame-Drops entsprechend der deklarierten Media Performance Class Level des Geräts unterstützen.

• [5.1/H-1-20] MÜSSEN die Funktion Feature_HdrEditing für alle AV1- und HEVC-Hardware-Encoder auf dem Gerät unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.1/H-1-21] MUSS FEATURE_DynamicColorAspect für alle Hardware-Video-Decoder (AVC, HEVC, VP9, AV1 oder höher) unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.1/H-1-22] Das Gerät MUSS das Codieren, Decodieren, Bearbeiten mit der GPU und Anzeigen von Videoinhalten im Hochformat entsprechend der deklarierten Media Performance Class Level des Geräts unterstützen.

• [5.2/H-2-1] Wenn die Geräteimplementierung Hardware-AVC- oder HEVC-Encoder unterstützt, MUSS sie das Mindestqualitätsziel erfüllen, das durch die Raten-Verzerrungs-Kurven des Video-Encoders für diese Codecs definiert ist und der deklarierten Media Performance Class Level des Geräts entspricht.

• [5.3/H-1-1] MUSS die Leistungsanforderungen für Videositzungen und Frame-Drops erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.3/H-1-2] MUSS die Leistungsanforderungen für die Änderung der Videoauflösung erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.6/H-1-1] MUSS die Anforderungen an die Latenz von Tippen zu Ton entsprechend der deklarierten Media Performance Class Level des Geräts erfüllen.

• [5.6/H-1-2] MUSS die Anforderungen an die Audio-Latenzzeit für Hin- und Rücklauf entsprechend der deklarierten Media Performance Class Level des Geräts erfüllen.

• [5.6/H-1-3] MUSS die 24‑Bit-Audioanforderungen erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.6/H-1-4] MUSS USB-Audiogeräte mit mindestens 4 Kanälen unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.6/H-1-5] MUSS Class-Compliant-MIDI-Geräte unterstützen und das MIDI-Feature-Flag deklarieren, das der deklarierten Media Performance Class Level des Geräts entspricht.

• [5.6/H-1-9] MUSS mindestens 12 Channel-Mixing entsprechend der deklarierten Media Performance Class Level des Geräts unterstützen.

• [5.6/H-SR-1] Es wird DRINGEND EMPFOHLEN, das Mischen von Audio-Channels entsprechend der deklarierten Media Performance Class Level des Geräts zu unterstützen.

• [5.7/H-1-2] MUSS MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL mit den Entschlüsselungsfunktionen unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.12/H-1-2] MÜSSEN die Anforderungen an das Farbformat für Hardware-AV1- und HEVC-Encoder erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [5.12/H-1-3] MUSS Unterstützung für die EXT_YUV_target-Erweiterung entsprechend der deklarierten Media Performance Class Level des Geräts offenlegen.

• [7.1.4/H-1-1] MUSS die Anforderungen an die Display Processing Unit (DPU) erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

2.2.7.2. Kamera

Wenn Implementierungen für Mobilgeräte einen Wert ungleich null für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

• MUSS die in Android 17 CDD, Abschnitt 2.2.7.2 aufgeführten Kameraanforderungen erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

Wenn Implementierungen für Mobilgeräte einen Wert ungleich null für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

• [7.5/H-1-1] MUSS die Anforderungen an die Auflösung der primären rückseitigen Kamera und die Videoaufnahme erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-2] MUSS die Anforderungen an die Auflösung der primären Frontkamera und die Videoaufnahme erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-3] MUSS die Anforderungen an die android.info.supportedHardwareLevel-Eigenschaft entsprechend dem deklarierten Media Performance Class Level des Geräts unterstützen.

• [7.5/H-1-4] MUSS CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME für beide primären Kameras unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-5] MUSS die Anforderungen an die JPEG-Aufnahmelatenz von Camera2 erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-6] MUSS die Anforderungen an die Startlatenz von camera2 erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-8] MUSS die Anforderungen für die RAW-Kameraaufnahme erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-9] MUSS die Anforderungen an die Hochgeschwindigkeits-Videoaufnahme der primären Kamera auf der Rückseite erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-10] MUSS die Mindestanforderungen für das Zoomverhältnis erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-11] MUSS die gleichzeitige Streamingfunktion für Vorder- und Rückkamera auf Primärkameras implementieren, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-12] MUSS die Videostabilisierung für die primäre Rückkamera entsprechend dem deklarierten Media Performance Class Level des Geräts unterstützen.

• [7.5/H-1-13] MUSS die LOGICAL_MULTI_CAMERA-Funktion für die primäre rückseitige Kamera unterstützen, die der deklarierten Media Performance Class Level des Geräts entspricht.

• [7.5/H-1-14] MUSS die STREAM_USE_CASE-Funktion sowohl für die primäre Front- als auch für die primäre Rückkamera entsprechend dem deklarierten Media Performance Class Level des Geräts unterstützen.

• [7.5/H-1-15] MUSS Nachtsichtmodus-Erweiterungen sowohl über CameraX- als auch über Camera2-Erweiterungen für Primärkameras unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-16] MUSS die DYNAMIC_RANGE_TEN_BIT-Funktion für die primären Kameras unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-17] MUSS Funktionen zur Gesichtserkennung für die primären Kameras unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.5/H-1-18] MUSS JPEG_R für die primären Rück- und Frontkameras entsprechend der deklarierten Media Performance Class Level des Geräts unterstützen.

• [7.5/H-1-19] MUSS CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION für die primäre Rückkamera unterstützen, die der deklarierten Media Performance Class Level des Geräts entspricht.

• [7.5/H-1-20] Die native Kamera-App MUSS standardmäßig JPEG_R für die primäre Rückkamera und die primäre Frontkamera entsprechend der deklarierten Media Performance Class Level des Geräts ausgeben.

2.2.7.3. Hardware

Wenn Implementierungen für Mobilgeräte einen Wert ungleich null für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

• MUSS die in Android 17 CDD, Abschnitt 2.2.7.3 aufgeführten Hardwareanforderungen erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

Wenn Implementierungen für Mobilgeräte einen Wert ungleich null für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

• [7.1.1.1/H-1-1] Dieser Punkt wird absichtlich übersprungen.

• [7.1.1.1/H-2-1] MUSS eine Bildschirmauflösung haben, die der deklarierten Media Performance Class Level des Geräts entspricht.

• [7.1.1.3/H-1-1] Dieser Punkt wird absichtlich übersprungen.

• [7.1.1.3/H-2-1] Die Displaydichte MUSS der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.1.1.3/H-3-1] MUSS die HDR-Displayanforderungen entsprechend dem deklarierten Media Performance Class Level des Geräts unterstützen.

• [7.6.1/H-1-1] Dieser Punkt wird absichtlich übersprungen.

• [7.6.1/H-2-1] MUSS die Speicheranforderungen erfüllen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

2.2.7.4. Leistung

Wenn Implementierungen für Mobilgeräte einen Wert ungleich null für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

• MUSS die Leistungsanforderungen erfüllen, die in Android 17 CDD-Abschnitt 2.2.7.4 für die deklarierte Media Performance Class Level des Geräts aufgeführt sind.

Wenn Implementierungen für Mobilgeräte einen Wert ungleich null für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

• [8.2/H-1-1] MUSS eine sequentielle Schreibleistung entsprechend der deklarierten Media Performance Class Level des Geräts gewährleisten.

• [8.2/H-1-2] MUSS eine zufällige Schreibleistung entsprechend der deklarierten Media Performance Class Level des Geräts gewährleisten.

• [8.2/H-1-3] MUSS eine sequentielle Leseleistung entsprechend der deklarierten Media Performance Class Level des Geräts gewährleisten.

• [8.2/H-1-4] MUSS eine zufällige Leseleistung entsprechend der deklarierten Media Performance Class Level des Geräts gewährleisten.

• [8.2/H-1-5] MUSS eine parallele sequenzielle Lese- und Schreibleistung entsprechend der deklarierten Media Performance Class Level des Geräts gewährleisten.

2.2.7.5. Grafik

Wenn Implementierungen für Mobilgeräte einen Wert ungleich null für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

• [7.1.4.1/H-1-2] MUSS die erforderlichen EGL-Erweiterungen unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

• [7.1.4.1/H-1-3] MUSS die erforderlichen Vulkan-Funktionen unterstützen, die der deklarierten Media Performance Class Level des Geräts entsprechen.

2.3. Anforderungen an das Fernsehgerät

Ein Android-TV-Gerät ist eine Android-Geräteimplementierung, die eine Unterhaltungsschnittstelle für die Nutzung digitaler Medien, Filme, Spiele, Apps und/oder Live-TV für Nutzer ist, die etwa drei Meter entfernt sitzen (eine „Lean-back“- oder „3-Meter-Benutzeroberfläche“).

Android-Geräteimplementierungen werden als Fernseher klassifiziert, wenn sie alle folgenden Kriterien erfüllen:

• Sie haben einen Mechanismus zur Fernsteuerung der gerenderten Benutzeroberfläche auf dem Display bereitgestellt, das sich möglicherweise in drei Metern Entfernung vom Nutzer befindet.
• Das Gerät muss ein eingebettetes Display mit einer Diagonale von mehr als 24 Zoll haben ODER einen Videoausgang wie VGA, HDMI, DisplayPort oder einen drahtlosen Port für die Anzeige enthalten.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Android TV-Geräteimplementierungen.

2.3.1. Hardware

Implementierungen für Fernsehgeräte:

• [7.2.2/T-0-1] MUSS das Steuerkreuz unterstützen.
• [7.2.3/T-0-1] MUSS die Funktionen „Home“ und „Zurück“ bieten.
• [7.2.3/T-0-2] MUSS sowohl das normale als auch das Ereignis bei langem Drücken der Zurück-Funktion (KEYCODE_BACK) an die im Vordergrund ausgeführte Anwendung senden.
• [7.2.6.1/T-0-1] MUSS Unterstützung für Gamecontroller enthalten und das android.hardware.gamepad-Funktions-Flag deklarieren.
• [7.2.7/T] SOLLTE eine Fernbedienung bereitstellen, über die Nutzer auf Navigation ohne Touchbedienung und Eingaben über die wichtigsten Navigationstasten zugreifen können.

Wenn Fernsehgeräteimplementierungen ein 3‑Achsen-Gyroskop enthalten, gilt Folgendes:

• [7.3.4/T-1-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz melden können.
• [7.3.4/T-1-2] MUSS in der Lage sein, Änderungen der Ausrichtung von bis zu 1.000 Grad pro Sekunde zu messen.

Implementierungen für Fernsehgeräte:

• [7.4.3/T-0-1] MÜSSEN Bluetooth und Bluetooth LE unterstützen.
• [7.6.1/T-0-1] MUSS mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) zur Verfügung haben.

Wenn Implementierungen von Fernsehgeräten einen USB-Anschluss enthalten, der den Hostmodus unterstützt, gilt Folgendes:

• [7.5.3/T-1-1] MUSS die Unterstützung einer externen Kamera umfassen, die über diesen USB-Anschluss verbunden wird, aber nicht unbedingt immer verbunden ist.

Wenn TV-Geräteimplementierungen 32-Bit-Implementierungen sind:

• [7.6.1/T-1-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 896 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 400 dpi oder höher auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tv‑dpi oder höher auf besonders großen Bildschirmen

Wenn TV-Geräteimplementierungen 64‑Bit-fähig sind:

• [7.6.1/T-2-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 1280 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 400 dpi oder höher auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tv‑dpi oder höher auf besonders großen Bildschirmen

Der oben erwähnte „für den Kernel und den Userspace verfügbare Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicher, der zusätzlich zu dem Arbeitsspeicher bereitgestellt wird, der bereits Hardwarekomponenten wie Funk, Video usw. zugewiesen ist, die in Geräteimplementierungen nicht unter der Kontrolle des Kernels stehen.

Implementierungen für Fernsehgeräte:

• [7.8.1/T] SOLLTE ein Mikrofon enthalten.
• [7.8.2/T-0-1] MÜSSEN eine Audioausgabe haben und android.hardware.audio.output deklarieren.

2.3.2. Multimedia

Implementierungen von Fernsehgeräten MÜSSEN die folgenden Audio-Codierungs- und ‑Decodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

• [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/T-0-3] AAC ELD (Enhanced Low Delay AAC)

Implementierungen von Fernsehgeräten MÜSSEN die folgenden Video-Codierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

• [5.2/T-0-1] H.264
• [5.2/T-0-2] VP8
• [5.2/T-0-3] AV1

Implementierungen für Fernsehgeräte:

• [5.2.2/T-SR-1] Das Unterstützen der H.264-Codierung von Videos mit einer Auflösung von 720p und 1080p bei 30 Bildern pro Sekunde wird DRINGEND EMPFOHLEN.

Implementierungen von Fernsehgeräten MÜSSEN die folgenden Videodecodierungsformate unterstützen und Drittanbieteranwendungen zur Verfügung stellen:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2
• [5.3.2/T-0-7] AV1

Implementierungen auf Fernsehgeräten MÜSSEN die MPEG‑2-Decodierung unterstützen, wie in Abschnitt 5.3.1 beschrieben, bei Standard-Videoframerate und ‑auflösung bis zu und einschließlich:

• [5.3.1/T-1-1] HD 1080p bei 29,97 Bildern pro Sekunde mit Main Profile High Level.
• [5.3.1/T-1-2] HD 1080i bei 59,94 Bildern pro Sekunde mit Main Profile High Level. Sie MÜSSEN verschachtelte MPEG‑2-Videos deinterlacen und Drittanbieteranwendungen zur Verfügung stellen.

Implementierungen auf Fernsehgeräten MÜSSEN die H.264-Decodierung unterstützen, wie in Abschnitt 5.3.4 beschrieben, bei Standard-Videoframerate und -Auflösung bis zu und einschließlich:

• [5.3.4/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Baseline-Profil
• [5.3.4/T-1-2] HD 1080p bei 60 Bildern pro Sekunde mit Main Profile
• [5.3.4/T-1-3] HD 1080p bei 60 Bildern pro Sekunde mit High Profile Level 4.2

Implementierungen von Fernsehgeräten mit H.265-Hardwaredecodern MÜSSEN die H.265-Decodierung gemäß Abschnitt 5.3.5 bei Standard-Videobildraten und Auflösungen bis einschließlich der folgenden unterstützen:

• [5.3.5/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Main Profile Level 4.1

Wenn Fernsehgeräte mit H.265-Hardwaredecodern die H.265-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:

• [5.3.5/T-2-1] MUSS das UHD-Decodierungsprofil bei 60 Bildern pro Sekunde mit dem Main10 Level 5 Main Tier-Profil unterstützen.

Implementierungen von Fernsehgeräten MÜSSEN die VP8-Decodierung unterstützen, wie in Abschnitt 5.3.6 beschrieben, bei Standard-Videoframerate und ‑auflösung bis zu und einschließlich:

• [5.3.6/T-1-1] HD 1080p bei 60 Bildern pro Sekunde (fps) Dekodierungsprofil

Implementierungen von Fernsehgeräten mit VP9-Hardware-Decodern MÜSSEN die VP9-Decodierung gemäß Abschnitt 5.3.7 bei Standard-Videobildraten und ‑auflösungen bis einschließlich der folgenden unterstützen:

• [5.3.7/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Profil 0 (8-Bit-Farbtiefe)

Wenn Fernsehgeräteimplementierungen mit VP9-Hardware-Decodern die VP9-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:

• [5.3.7/T-2-1] MUSS das UHD-Decodierungsprofil mit 60 Bildern pro Sekunde mit Profil 0 (8-Bit-Farbtiefe) unterstützen.
• [5.3.7/T-SR1] Es wird DRINGEND EMPFOHLEN, das UHD-Decodierungsprofil mit 60 Bildern pro Sekunde mit Profil 2 (10-Bit-Farbtiefe) zu unterstützen.

Implementierungen für Fernsehgeräte:

• [5.5/T-0-1] MUSS die Unterstützung für die Systemlautstärke und die Lautstärkeanpassung der digitalen Audioausgabe auf unterstützten Ausgängen enthalten, mit Ausnahme der Ausgabe für die Passthrough-Übertragung von komprimiertem Audio (bei der keine Audiodecodierung auf dem Gerät erfolgt).

Wenn Fernsehgeräteimplementierungen kein integriertes Display haben, sondern stattdessen ein externes Display unterstützen, das über HDMI angeschlossen wird, gilt Folgendes:

• [5.8/T-0-1] Der HDMI-Ausgabemodus MUSS auf die höchste Auflösung für das ausgewählte Pixelformat eingestellt werden, die mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz für das externe Display funktioniert, je nach der Videobildwiederholfrequenz für die Region, in der das Gerät verkauft wird.
• [5.8/T-SR-1] Es wird DRINGEND EMPFOHLEN, eine vom Nutzer konfigurierbare Auswahl für die HDMI-Aktualisierungsrate bereitzustellen.
• [5.8] Die Aktualisierungsrate des HDMI-Ausgabemodus SOLLTE je nach Videobildrate für die Region, in der das Gerät verkauft wird, auf 50 Hz oder 60 Hz eingestellt werden.

Wenn Fernsehgeräteimplementierungen kein integriertes Display haben, sondern stattdessen ein externes Display unterstützen, das über HDMI angeschlossen wird, gilt Folgendes:

• [5.8/T-1-1] MUSS HDCP 2.2 unterstützen.

Wenn Fernsehgeräteimplementierungen die UHD-Decodierung nicht unterstützen, sondern stattdessen ein über HDMI angeschlossenes externes Display, gilt Folgendes:

• [5.8/T-2-1] MUSS HDCP 1.4 unterstützen

2.3.3. Software

Implementierungen für Fernsehgeräte:

• [3/T-0-1] MÜSSEN die Funktionen android.software.leanback und android.hardware.type.television deklarieren.
• [3.2.3.1/T-0-1] MUSS eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorab laden, die durch die folgenden hier aufgeführten Anwendungs-Intents definiert werden.
• [3.4.1/T-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API bereitstellen.

Wenn Android TV-Geräteimplementierungen einen Sperrbildschirm unterstützen, gilt Folgendes:

• [3.8.10/T-1-1] MÜSSEN Sperrbildschirm-Benachrichtigungen einschließlich der Media-Benachrichtigungsvorlage angezeigt werden.

Implementierungen für Fernsehgeräte:

• [3.8.14/T-SR-1] Es wird DRINGEND EMPFOHLEN, den Bild-im-Bild-Modus (BiB) im Mehrfenstermodus zu unterstützen.
• [3.10/T-0-1] MUSS Barrierefreiheitsdienste von Drittanbietern unterstützen.
• [3.10/T-SR-1] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorzuinstallieren, die mit den Bedienungshilfen für den Schalterzugriff und TalkBack (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden) vergleichbar sind oder deren Funktionalität übertreffen, wie sie im TalkBack-Open-Source-Projekt bereitgestellt werden.

Wenn Fernsehgeräteimplementierungen das Feature android.hardware.audio.output melden, müssen sie:

• [3.11/T-SR-1] Es wird DRINGEND EMPFOHLEN, eine TTS-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
• [3.11/T-1-1] MUSS die Installation von TTS-Engines von Drittanbietern unterstützen.

Das Android Television Input Framework (TIF) vereinfacht die Bereitstellung von Live-Inhalten auf Android-Fernsehern. TIF bietet eine Standard-API zum Erstellen von Eingabemodulen, mit denen Android-TV-Geräte gesteuert werden.

Implementierungen für Fernsehgeräte:

• [3/T-0-2] MÜSSEN die Plattformfunktion android.software.live_tv deklarieren.
• [3/T-0-3] MUSS alle TIF-APIs unterstützen, sodass eine Anwendung, die diese APIs und den TIF-basierten Drittanbieter-Eingabedienst verwendet, auf dem Gerät installiert und verwendet werden kann.

Das Android Television Tuner Framework (TF) vereinheitlicht die Verarbeitung von Liveinhalten vom Tuner mit Streaminginhalten von IP auf Android-Fernsehern. Das Tuner Framework bietet eine Standard-API zum Erstellen von Eingabediensten, die den Android-TV-Tuner verwenden.

Wenn Geräteimplementierungen den Tuner unterstützen, gilt Folgendes:

• [3/T-1-1] MUSS alle Tuner Framework APIs unterstützen, sodass eine Anwendung, die diese APIs verwendet, auf dem Gerät installiert und verwendet werden kann.

2.3.4. Leistung und Energie

• [8.1/T-0-1] Konsistente Frame-Latenz. Inkonsistente Frame-Latenz oder eine Verzögerung beim Rendern von Frames DÜRFEN nicht häufiger als 5 Frames pro Sekunde auftreten und SOLLTEN weniger als 1 Frame pro Sekunde betragen.
• [8.2/T-0-1] MUSS eine sequenzielle Schreibleistung von mindestens 5 MB/s gewährleisten.
• [8.2/T-0-2] MUSS eine zufällige Schreibleistung von mindestens 0,5 MB/s bieten.
• [8.2/T-0-3] MUSS eine sequenzielle Leseleistung von mindestens 15 MB/s gewährleisten.
• [8.2/T-0-4] MUSS eine zufällige Leseleistung von mindestens 3,5 MB/s bieten.

Wenn Implementierungen von Fernsehgeräten Funktionen zur Verbesserung der Energieverwaltung des Geräts enthalten, die in AOSP enthalten sind oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:

• [8.3/T-1-1] MUSS dem Nutzer die Möglichkeit bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.

Wenn Fernsehgeräte keinen Akku haben, gilt Folgendes:

• [8.3/T-1-2] Das Gerät MUSS als Gerät ohne Akku registriert werden, wie unter Geräte ohne Akku unterstützen beschrieben.

Wenn Fernsehgeräteimplementierungen einen Akku haben, gilt Folgendes:

• [8.3/T-1-3] MUSS dem Nutzer die Möglichkeit bieten, alle Apps anzuzeigen, die von den Stromsparmodi „App-Standby“ und „Stromsparmodus“ ausgenommen sind.

Implementierungen für Fernsehgeräte:

• [8.4/T-0-1] MUSS ein Energieprofil pro Komponente bereitstellen, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch durch die Komponenten im Zeitverlauf definiert, wie auf der AOSP-Website dokumentiert.
• [8.4/T-0-2] MÜSSEN alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angegeben werden.
• [8.4/T-0-3] MUSS den CPU-Stromverbrauch für die UID jedes Prozesses melden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• [8.4/T] SOLLTE der Hardwarekomponente selbst zugewiesen werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugewiesen werden kann.
• [8.4/T-0-4] MUSS diese Stromnutzung über den Shell-Befehl adb shell dumpsys batterystats für den App-Entwickler verfügbar machen.

2.3.5. Sicherheitsmodell

Implementierungen für Fernsehgeräte:

• [9/T-0-1] MÜSSEN die android.hardware.security.model.compatible-Funktion deklarieren.

Wenn Fernsehgeräteimplementierungen eine Standardanwendung zur Unterstützung von VoiceInteractionService enthalten, gilt Folgendes:

• [9.1/T-0-1] DARF ACCESS_FINE_LOCATION NICHT als Standard für diese Anwendung gewähren.

Implementierungen für Fernsehgeräte:

• [9.11/T-0-1] Die Schlüsselspeicher-Implementierung MUSS durch eine isolierte Ausführungsumgebung gesichert werden.
• [9.11/T-0-2] MUSS Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie der Hash-Funktionen der MD5-, SHA-1- und SHA-2-Familie haben, um die vom Android Keystore-System unterstützten Algorithmen in einem Bereich, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird, ordnungsgemäß zu unterstützen. Die sichere Isolation MUSS alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen könnte, einschließlich DMA. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer geeigneten hypervisorbasierten Isolation sind alternative Optionen.
• [9.11/T-0-3] MUSS die Authentifizierung auf dem Sperrbildschirm in der isolierten Ausführungsumgebung durchführen und die Verwendung der authentifizierungsgebundenen Schlüssel nur bei Erfolg zulassen. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Authentifizierung über den Sperrbildschirm durchführen kann. Das Upstream-Android Open Source Project bietet die Gatekeeper Hardwareabstraktionsschicht (HAL) und Trusty, die verwendet werden können, um diese Anforderung zu erfüllen.

• [9.11/T-0-4] MUSS die Schlüsselattestierung unterstützen, bei der der Attestierungssignierschlüssel durch sichere Hardware geschützt ist und die Signierung in sicherer Hardware erfolgt. Die Attestierungssignaturschlüssel DÜRFEN NICHT als dauerhafte Geräte-IDs verwendet werden.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version eingeführt wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen durch eine isolierte Ausführungsumgebung gesicherten Schlüsselspeicher zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert das android.hardware.fingerprint-Feature, das einen durch eine isolierte Ausführungsumgebung gesicherten Schlüsselspeicher erfordert.

Wenn Fernsehgeräteimplementierungen einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:

• [9.11/T-1-1] Der Nutzer MUSS das Zeitlimit für den Übergang vom entsperrten in den gesperrten Zustand auswählen können. Das Mindestzeitlimit darf bis zu 15 Sekunden oder weniger betragen.

Wenn Fernsehgeräteimplementierungen mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony nicht deklarieren, gilt Folgendes:

• [9.5/T-2-1] MUSS eingeschränkte Profile unterstützen. Mit dieser Funktion können Geräteinhaber zusätzliche Nutzer und ihre Funktionen auf dem Gerät verwalten. Mit eingeschränkten Profilen können Geräteinhaber schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen für die in diesen Umgebungen verfügbaren Apps verwalten.

Wenn Fernsehgeräteimplementierungen mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony deklarieren, gilt Folgendes:

• [9.5/T-3-1] MUSS eingeschränkte Profile unterstützen, MUSS aber mit der AOSP-Implementierung von Steuerelementen übereinstimmen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen bzw. zu verwehren.

Wenn in Implementierungen von Fernsehgeräten android.hardware.microphone deklariert wird, gilt Folgendes:

• [9.8.2/T-4-1] Die Mikrofonanzeige MUSS angezeigt werden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 Berechtigungen mit CDD-Kennung C-3-X genannten Rollen auf das Mikrofon zugreifen.
• [9.8.2/T-4-2] MUSS die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Nutzerinteraktion anzeigen.

Wenn in Implementierungen von Fernsehgeräten android.hardware.camera.any deklariert wird, gilt Folgendes:

• [9.8.2/T-5-1] Der Kamerazugriff-Hinweis MUSS angezeigt werden, wenn eine App auf Live-Kameradaten zugreift, nicht jedoch, wenn auf die Kamera nur von Apps mit den in Abschnitt 9.1 Berechtigungen mit CDD-Kennung [C-3-X] genannten Rollen zugegriffen wird.
• [9.8.2/T-5-2] DARF den Kamerazugriff-Hinweis für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Nutzerinteraktion NICHT ausblenden.

2.3.6. Kompatibilität von Entwicklertools und -optionen

Implementierungen für Fernsehgeräte:

• Perfetto

  • [6.1/T-0-1] MUSS dem Shell-Nutzer ein /system/bin/perfetto-Binärprogramm zur Verfügung stellen, dessen Befehlszeile der Perfetto-Dokumentation entspricht.
  • [6.1/T-0-2] Die Binärdatei für Perfetto MUSS eine Protobuf-Konfiguration als Eingabe akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
  • [6.1/T-0-3] Die binäre Datei „perfetto“ MUSS als Ausgabe einen Protobuf-Trace schreiben, der dem in der Perfetto-Dokumentation definierten Schema entspricht.
  • [6.1/T-0-4] MÜSSEN über die Binärdatei „perfetto“ mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitstellen.
  • [6.1/T-0-5] Der Perfetto-Trace-Daemon MUSS standardmäßig aktiviert sein (Systemeigenschaft persist.traced.enable).

2.4 Smartwatch-Anforderungen

Ein Android-Smartwatch-Gerät ist eine Android-Geräteimplementierung, die für das Tragen am Körper, z. B. am Handgelenk, vorgesehen ist.

Android-Geräteimplementierungen werden als Smartwatch klassifiziert, wenn sie alle folgenden Kriterien erfüllen:

• Das Display muss eine physische diagonale Länge zwischen 1,1 und 2,5 Zoll haben.
• Es muss einen Mechanismus geben, mit dem das Gerät am Körper getragen werden kann.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Android-Smartwatch-Implementierungen.

2.4.1. Hardware

Smartwatch-Geräteimplementierungen:

• [7.1.1.1/W-0-1] MUSS ein Display mit einer physischen Diagonale zwischen 1,1 und 2,5 Zoll haben.

• [7.2.3/W-0-1] MUSS die Home-Funktion für den Nutzer verfügbar sein und die Zurück-Funktion, außer wenn sie sich in UI_MODE_TYPE_WATCH befindet.

• [7.2.4/W-0-1] MÜSSEN Touchscreen-Eingabe unterstützen.

• [7.3.1/W-SR-1] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser einzubauen.

Wenn Watch-Geräteimplementierungen einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps an Anwendungen melden, gilt Folgendes:

• [7.3.3/W-1-1] MÜSSEN GNSS-Messungen melden, sobald sie gefunden werden, auch wenn noch kein aus GPS/GNSS berechneter Standort gemeldet wurde.
• [7.3.3/W-1-2] Die HU MUSS GNSS-Pseudobereiche und ‑Pseudobereichsraten melden, die unter störungsfreien Bedingungen nach der Standortbestimmung im Ruhezustand oder bei einer Beschleunigung von weniger als 0,2 Metern pro Sekunde zum Quadrat in mindestens 95% der Fälle ausreichen, um die Position innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0,2 Metern pro Sekunde zu berechnen.

Wenn Watch-Geräteimplementierungen ein 3‑Achsen-Gyroskop enthalten, gilt Folgendes:

• [7.3.4/W-2-1] MUSS in der Lage sein, Änderungen der Ausrichtung von bis zu 1.000 Grad pro Sekunde zu messen.

Smartwatch-Geräteimplementierungen:

• [7.4.3/W-0-1] MÜSSEN Bluetooth unterstützen.

• [7.6.1/W-0-1] MUSS mindestens 1 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) zur Verfügung haben.

• [7.6.1/W-0-2] MÜSSEN mindestens 416 MB Speicher für den Kernel und den Nutzerbereich verfügbar haben.

• [7.8.1/W-0-1] MÜSSEN ein Mikrofon enthalten.

• [7.8.2/W] MAY have Audioausgabe.

2.4.2. Multimedia

Keine zusätzlichen Anforderungen.

2.4.3. Software

Smartwatch-Geräteimplementierungen:

• [3/W-0-1] MÜSSEN die Funktion android.hardware.type.watch deklarieren.
• [3/W-0-2] MUSS uiMode = UI_MODE_TYPE_WATCH unterstützen.
• [3.2.3.1/W-0-1] Es MUSS mindestens eine Anwendung oder Dienstkomponente mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorinstalliert sein, die durch die folgenden hier aufgeführten Anwendungs-Intents definiert werden.

Smartwatch-Geräteimplementierungen:

• [3.8.4/W-SR-1] Es wird DRINGEND EMPFOHLEN, einen Assistenten auf dem Gerät zu implementieren, der die Assist-Aktion verarbeitet.

Für Smartwatch-Implementierungen, die das Funktions-Flag android.hardware.audio.output deklarieren, gilt Folgendes:

• [3.10/W-1-1] MUSS Barrierefreiheitsdienste von Drittanbietern unterstützen.
• [3.10/W-SR-1] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorab zu laden, die mit den Funktionen des Schalterzugriffs und von TalkBack vergleichbar sind oder diese übertreffen (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden), wie im TalkBack-Open-Source-Projekt bereitgestellt.

Wenn Watch-Geräteimplementierungen die Funktion „android.hardware.audio.output“ melden, gilt Folgendes:

• [3.11/W-SR-1] Es wird DRINGEND EMPFOHLEN, eine TTS-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.

• [3.11/W-0-1] MUSS die Installation von TTS-Engines von Drittanbietern unterstützen.

2.4.4. Leistung und Energie

Wenn Watch-Geräteimplementierungen Funktionen zur Verbesserung der Geräte-Energieverwaltung enthalten, die in AOSP enthalten sind oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:

• [8.3/W-SR-1] Es wird DRINGEND EMPFOHLEN, eine Benutzeroberfläche bereitzustellen, auf der alle Apps angezeigt werden, die von den Energiesparmodi „App-Standby“ und „Stromsparmodus“ ausgenommen sind.
• [8.3/W-SR-2] Es wird DRINGEND EMPFOHLEN, dem Nutzer die Möglichkeit zu geben, den Energiesparmodus zu aktivieren und zu deaktivieren.

Smartwatch-Geräteimplementierungen:

• [8.4/W-0-1] MUSS ein Energieprofil für jede Komponente bereitstellen, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch der Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.
• [8.4/W-0-2] MUSS alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angeben.
• [8.4/W-0-3] MUSS den CPU-Stromverbrauch für die UID jedes Prozesses melden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• [8.4/W-0-4] MUSS diese Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.
• [8.4/W] SOLLTE der Hardwarekomponente selbst zugewiesen werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugewiesen werden kann.

2.4.5. Sicherheitsmodell

Smartwatch-Geräteimplementierungen:

• [9/W-0-1] MÜSSEN die android.hardware.security.model.compatible-Funktion deklarieren.

Wenn Watch-Geräteimplementierungen eine Standardanwendung zur Unterstützung von VoiceInteractionService enthalten, gilt Folgendes:

• [9.1/W-0-1] DARF ACCESS_FINE_LOCATION NICHT als Standard für diese Anwendung gewähren.

Wenn Watch-Geräteimplementierungen mehrere Nutzer umfassen und das android.hardware.telephony-Funktionsflag nicht deklariert wird, gilt Folgendes:

• [9.5/W-1-1] MUSS eingeschränkte Profile unterstützen. Mit dieser Funktion können Geräteinhaber zusätzliche Nutzer und ihre Funktionen auf dem Gerät verwalten. Mit eingeschränkten Profilen können Geräteinhaber schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen für die in diesen Umgebungen verfügbaren Apps verwalten.

Wenn Watch-Geräteimplementierungen mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony deklarieren, gilt Folgendes:

• [9.5/W-2-1] MUSS eingeschränkte Profile unterstützen, MUSS aber mit der AOSP-Implementierung von Steuerelementen übereinstimmen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen bzw. zu verwehren.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agents enthalten, die die TrustAgentServiceSystem-API implementieren, gilt Folgendes:

2.5 Anforderungen für die Automobilbranche

Android Automotive-Implementierung bezieht sich auf ein Infotainmentsystem im Fahrzeug, auf dem Android als Betriebssystem für einen Teil oder das gesamte System und/oder die Infotainmentfunktionen ausgeführt wird.

Android-Geräteimplementierungen werden als Automotive klassifiziert, wenn sie das Feature android.hardware.type.automotive deklarieren oder alle folgenden Kriterien erfüllen.

• Sie sind in ein Kraftfahrzeug eingebettet oder können daran angeschlossen werden.

• Sie verwenden einen Bildschirm in der Fahrerreihe als primäres Display.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Android Automotive-Geräteimplementierungen.

2.5.1. Hardware

Automotive-Geräteimplementierungen:

• [7.1.1.1/A-0-1] MUSS ein Display mit einer physischen Diagonale von mindestens 6 Zoll haben.

• [7.1.1.1/A-0-2] MUSS ein Layout mit einer Bildschirmgröße von mindestens 750 dp × 480 dp haben.

• [7.1.1.1/A-0-3] MÜSSEN die GPU-Zusammensetzung von Grafikpuffern unterstützen, die mindestens so groß sind wie die höchste Auflösung eines integrierten Displays.

Wenn Automotive-Geräteimplementierungen die gleichzeitige Nutzung durch mehrere Nutzer unterstützen (mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren und jeder nutzt sein eigenes Display, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

• [7.1.1.1/A-1-1] MUSS für jede Insassenzone ein separates Display mit einer physischen Diagonalen von mindestens 6 Zoll für das Hauptdisplay haben. Jede Zone für Insassen sollte mit CarOccupantZoneManager.DISPLAY_TYPE_MAIN gekennzeichnet werden.

• [7.1.1.1/A-1-2] MUSS für jedes Hauptdisplay ein Layout mit einer Bildschirmgröße von mindestens 750 dp × 480 dp haben.

Wenn Automotive-Geräteimplementierungen OpenGL ES 3.1 unterstützen, gilt Folgendes:

• [7.1.4.1/A-0-1] MUSS OpenGL ES 3.1 oder höher deklarieren.

• [7.1.4.1/A-0-2] MÜSSEN Vulkan 1.1 unterstützen.

• [7.1.4.1/A-0-3] MUSS den Vulkan-Loader enthalten und alle Symbole exportieren.

Wenn Automotive-Geräteimplementierungen Unterstützung für Vulkan bieten, gilt Folgendes:

• [7.1.4.2/A-1-1] MUSS die im Android Baseline 2021-Profil angegebenen Anforderungen erfüllen.

Wenn Automotive-Geräteimplementierungen über Configuration.isScreenHdr() Unterstützung für HDR-Displays (High Dynamic Range) beanspruchen, gilt Folgendes:

• [7.1.4.5/A-1-1] MUSS die Unterstützung für die Erweiterungen EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace und VK_EXT_hdr_metadata bewerben.

Automotive-Geräteimplementierungen:

• [7.1.4.6/A-0-1] MUSS über die Systemeigenschaft graphics.gpu.profiler.support angeben, ob das Gerät die GPU-Profilerstellung unterstützt.

Wenn Automotive-Geräteimplementierungen die Unterstützung über eine Systemeigenschaft graphics.gpu.profiler.support deklarieren, gilt Folgendes:

• [7.1.4.6/A-1-1] MUSS als Ausgabe einen Protobuf-Trace ausgeben, der dem Schema für GPU-Zähler und GPU-RenderStages entspricht, das in der Perfetto-Dokumentation definiert ist.

• [7.1.4.6/A-1-2] MUSS konforme Werte für die GPU-Zähler des Geräts gemäß dem gpu counter trace-Paket-Proto melden.

• [7.1.4.6/A-1-3] MUSS konforme Werte für die GPU-RenderStages des Geräts gemäß dem RenderStage-Trace-Paket-Proto melden.

• [7.1.4.6/A-1-4] MUSS einen GPU-Frequenz-Tracepoint im folgenden Format melden: power/gpu_frequency.

Automotive-Geräteimplementierungen:

• [7.1.5/A-0-1] MUSS die Unterstützung für den Legacy-App-Kompatibilitätsmodus enthalten, wie er vom Upstream-Android-Open-Source-Code implementiert wird. Das bedeutet, dass Geräteimplementierungen die Trigger oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert wird, NICHT ändern dürfen und das Verhalten des Kompatibilitätsmodus selbst NICHT ändern dürfen.

Automotive-Geräteimplementierungen:

• [7.1.7/A-0-1] MÜSSEN sekundäre Displays im Sichtfeld des Fahrers als FLAG_PRIVATE konfiguriert werden.

• [7.2.3/A-0-1] MUSS die Home-Funktion bereitstellen und DARF die Funktionen „Zurück“ und „Zuletzt verwendet“ bereitstellen.

• [7.2.3/A-0-2] MÜSSEN sowohl das normale als auch das Langdruckereignis der Zurück-Funktion (KEYCODE_BACK) an die im Vordergrund ausgeführte Anwendung senden.

• [7.3/A-0-1] MUSS GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED und PARKING_BRAKE_ON implementieren und melden.

• [7.3/A-0-2] Der Wert des Flags NIGHT_MODE MUSS mit dem Tag-/Nachtmodus des Dashboards übereinstimmen und SOLLTE auf der Eingabe des Umgebungslichtsensors basieren. Der zugrunde liegende Umgebungslichtsensor KANN derselbe wie das Fotometer sein.

• [7.3/A-0-3] MUSS das Feld „Zusätzliche Sensorinformationen“ TYPE_SENSOR_PLACEMENT als Teil von „SensorAdditionalInfo“ für jeden bereitgestellten Sensor angeben.

• [7.3/A-SR1] KANN nach dem Koppelnavigationsverfahren bestimmte Standorte ermitteln, indem GPS/GNSS mit zusätzlichen Sensoren kombiniert wird. Wenn der Standort per Koppelnavigationsverfahren ermittelt wird, wird DRINGEND EMPFOHLEN, die entsprechenden verwendeten Sensortypen und/oder Fahrzeugeigenschafts-IDs zu implementieren und zu melden.

• [7.3/A-0-4] Der über LocationManager#requestLocationUpdates() angeforderte Standort darf NICHT auf eine Karte abgestimmt werden.

• [7.3.1/A-0-4] MÜSSEN dem Koordinatensystem für Autosensoren unter Android entsprechen.

• [7.3/A-SR-1] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser und ein 3‑Achsen-Gyroskop einzubauen.

• [7.3/A-SR-2] Es wird DRINGEND EMPFOHLEN, den TYPE_HEADING-Sensor zu implementieren und zu melden.

Wenn Automotive-Geräteimplementierungen die gleichzeitige Nutzung durch mehrere Nutzer unterstützen (mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren und jeder nutzt sein eigenes Display, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

• [7.3/A-1-1] Der Flag-Wert NIGHT_MODE MUSS auf allen Displays, einschließlich der Displays auf den Rücksitzen, einheitlich mit dem Tag-/Nachtmodus des Dashboards festgelegt werden.

Wenn Automotive-Geräteimplementierungen einen Beschleunigungsmesser enthalten, gilt Folgendes:

• [7.3.1/A-1-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz melden können.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser enthalten, gilt Folgendes:

• [7.3.1/A-SR-1] Es wird DRINGEND EMPFOHLEN, den Verbundsensor für den Beschleunigungsmesser mit eingeschränkten Achsen zu implementieren.

Wenn Automotive-Geräteimplementierungen einen Beschleunigungsmesser mit weniger als 3 Achsen enthalten, gilt Folgendes:

• [7.3.1/A-1-3] MÜSSEN den TYPE_ACCELEROMETER_LIMITED_AXES-Sensor implementieren und melden.

• [7.3.1/A-1-4] MÜSSEN den TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED-Sensor implementieren und melden.

Wenn Automotive-Geräteimplementierungen ein Gyroskop enthalten, gilt Folgendes:

• [7.3.4/A-2-1] MUSS Ereignisse mit einer Frequenz von mindestens 100 Hz melden können.

• [7.3.4/A-2-3] MUSS in der Lage sein, Änderungen der Ausrichtung von bis zu 250 Grad pro Sekunde zu messen.

• [7.3.4/A-SR-1] Es wird DRINGEND EMPFOHLEN, den Messbereich des Gyroskops auf +/-250 dps zu konfigurieren, um die höchstmögliche Auflösung zu erzielen.

Wenn Automotive-Geräteimplementierungen ein 3‑Achsen-Gyroskop enthalten, gilt Folgendes:

• [7.3.4/A-SR-2] Es wird DRINGEND EMPFOHLEN, den Verbundsensor für das Gyroskop mit eingeschränkten Achsen zu implementieren.

Wenn Automotive-Geräteimplementierungen ein Gyroskop mit weniger als 3 Achsen enthalten,

• [7.3.4/A-4-1] MÜSSEN den TYPE_GYROSCOPE_LIMITED_AXES-Sensor implementieren und melden.

• [7.3.4/A-4-2] MÜSSEN den TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED-Sensor implementieren und melden.

Wenn Automotive-Geräteimplementierungen einen GPS-/GNSS-Empfänger, aber keine auf Mobilfunknetz basierende Datenverbindung enthalten, gilt Folgendes:

• [7.3.3/A-3-1] MUSS den Standort beim ersten Einschalten des GPS-/GNSS-Empfängers oder nach mindestens vier Tagen innerhalb von 60 Sekunden ermitteln.

• [7.3.3/A-3-2] MUSS die Kriterien für die Zeit bis zur ersten Positionsbestimmung erfüllen, die in 7.3.3/C-1-2 und 7.3.3/C-1-6 für alle anderen Standortanfragen beschrieben sind (d. h. Anfragen, die nicht zum ersten Mal oder nach mehr als 4 Tagen erfolgen). Die Anforderung 7.3.3/C-1-2 wird in Fahrzeugen ohne datenbasierte Mobilfunknetzverbindung in der Regel erfüllt, indem GNSS-Umlaufbahnvorhersagen verwendet werden, die auf dem Empfänger berechnet werden, oder indem der letzte bekannte Fahrzeugstandort zusammen mit der Möglichkeit verwendet wird, mindestens 60 Sekunden lang mit einer Positionsgenauigkeit zu schätzen, die 7.3.3/C-1-3 entspricht, oder durch eine Kombination aus beidem.

Wenn Automotive-Geräteimplementierungen einen TYPE_HEADING-Sensor enthalten, gilt Folgendes:

• [7.3.4/A-4-3] MUSS Ereignisse mit einer Häufigkeit von mindestens 1 Hz melden können.

• [7.3.4/A-SR-3] Es wird DRINGEND EMPFOHLEN, Ereignisse mit einer Häufigkeit von mindestens 10 Hz zu melden.

• Sollte sich auf den geografischen Norden beziehen.

• Sollte auch dann verfügbar sein, wenn das Fahrzeug steht.

• SOLLTE eine Auflösung von mindestens 1 Grad haben.

Automotive-Geräteimplementierungen:

• [7.4.3/A-0-1] MÜSSEN Bluetooth unterstützen und SOLLTEN Bluetooth LE unterstützen.

• [7.4.3/A-0-2] Android Automotive-Implementierungen MÜSSEN die folgenden Bluetooth-Profile unterstützen:

  • Telefonieren über das Hands-Free Profile (HFP).
  • Medienwiedergabe über das Audio Distribution Profile (A2DP).
  • Steuerung der Medienwiedergabe über das Remote Control Profile (AVRCP)
  • Kontaktfreigabe anhand des Phone Book Access Profile (PBAP).

• [7.4.3/A-SR-1] Es wird DRINGEND EMPFOHLEN, das Message Access Profile (MAP) zu unterstützen, wenn das Gerät die Fahrerzone hat.

Wenn Automotive-Geräteimplementierungen die gleichzeitige Nutzung durch mehrere Nutzer unterstützen (mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren und jeder nutzt sein eigenes Display, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

• [7.4.3/A-1-1] MUSS unabhängig sein und darf die Bluetooth-Nutzung anderer Nutzer NICHT beeinträchtigen.

Automotive-Geräteimplementierungen:

• [7.4.5/A] SOLLTE die Unterstützung für die datenbasierte Verbindung über Mobilfunknetze umfassen.

• [7.4.5/A] MAY use the System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID constant for networks that should be available to system apps.

Wenn Geräteimplementierungen die Unterstützung für AM/FM-Rundfunk enthalten und die Funktion für jede Anwendung verfügbar machen, gilt Folgendes:

• [7.4/A-1-1] MUSS die Unterstützung für FEATURE_BROADCAST_RADIO deklarieren.

Eine nach hinten gerichtete Kamera ist eine nach außen gerichtete Kamera, die sich an einer beliebigen Stelle des Fahrzeugs befinden kann und auf die Außenseite der Fahrgastzelle gerichtet ist. Sie bildet also Szenen auf der gegenüberliegenden Seite der Karosserie ab, wie die Rückfahrkamera.

Eine nach vorn gerichtete Kamera ist eine auf den Nutzer ausgerichtete Kamera, die sich an einer beliebigen Stelle im Fahrzeug befinden kann und auf das Innere des Fahrzeugs gerichtet ist. Sie nimmt Bilder des Nutzers auf, z. B. für Videokonferenzen und ähnliche Anwendungen.

Automotive-Geräteimplementierungen:

• [7.5/A-SR-1] Es wird DRINGEND EMPFOHLEN, eine oder mehrere nach außen gerichtete Kameras einzubauen.

• KANN eine oder mehrere nach vorn gerichtete Kameras enthalten.

• [7.5/A-SR-2] Es wird DRINGEND EMPFOHLEN, das gleichzeitige Streaming von mehreren Kameras zu unterstützen.

Wenn Automotive-Geräteimplementierungen mindestens eine nach außen gerichtete Kamera enthalten, gilt für diese Kamera Folgendes:

• [7.5/A-1-1] MUSS so ausgerichtet sein, dass die lange Seite der Kamera mit der XY-Ebene der Android Automotive-Sensorachsen übereinstimmt.

• [7.5/A-SR-3] Es wird DRINGEND EMPFOHLEN, entweder Hardware mit Fixfokus oder EDOF (Extended Depth of Field) zu verwenden.

• [7.5/A-1-2] Die primäre nach außen gerichtete Kamera MUSS die nach außen gerichtete Kamera mit der niedrigsten Kamera-ID sein.

Wenn Automotive-Geräteimplementierungen mindestens eine nach vorn gerichtete Kamera enthalten, gilt für diese Kamera Folgendes:

• [7.5/A-2-1] Die primäre nach vorn gerichtete Kamera MUSS die nach vorn gerichtete Kamera mit der niedrigsten Kamera-ID sein.

• KANN so ausgerichtet sein, dass die lange Seite der Kamera mit der XY-Ebene der Android Automotive-Sensorachsen übereinstimmt.

Wenn Automotive-Geräteimplementierungen eine Kamera enthalten, auf die über die API android.hardware.Camera oder android.hardware.camera2 zugegriffen werden kann, gilt Folgendes:

• [7.5/A-3-1] MUSS den Anforderungen an die Hauptkamera in Abschnitt 7.5 entsprechen.

Wenn Automotive-Geräteimplementierungen eine oder mehrere Kameras enthalten, auf die über den Extended View System Service zugegriffen werden kann, gilt für diese Kameras Folgendes:

• [7.5/A-5-1] Die Kameravorschau darf nicht gedreht oder horizontal gespiegelt werden.

• [7.5/A-SR-4] Es wird DRINGEND EMPFOHLEN, dass die Auflösung mindestens 1,3 Megapixel beträgt.

Wenn in Automotive-Geräteimplementierungen eine oder mehrere Kameras enthalten sind, auf die sowohl über den Extended View System Service als auch über die android.hardware.Camera- oder android.hardware.Camera2-API zugegriffen werden kann, gilt für diese Kameras Folgendes:

• [7.5/A-6-1] MUSS dieselbe Kamera-ID melden.

Wenn Automotive-Geräteimplementierungen eine proprietäre Kamera-API bereitstellen, gilt Folgendes:

• [7.5/A-7-1] MUSS eine solche Kamera-API mit der android.hardware.camera2-API oder der Extended View System API implementieren.

Automotive-Geräteimplementierungen:

• [7.6.1/A-0-1] MÜSSEN mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (/data-Partition) zur Verfügung haben.

• [7.6.1/A] SOLLTE die Datenpartition formatieren, um die Leistung und Lebensdauer des Flash-Speichers zu verbessern (z. B. mit dem f2fs-Dateisystem).

Wenn Automotive-Geräteimplementierungen gemeinsam genutzten externen Speicher über einen Teil des internen, nicht entfernbaren Speichers bereitstellen, gilt Folgendes:

• [7.6.1/A-SR-1] Es wird DRINGEND EMPFOHLEN, den E/A-Aufwand bei Vorgängen zu reduzieren, die auf dem externen Speicher ausgeführt werden, z. B. durch die Verwendung von SDCardFS.

Wenn Automotive-Geräteimplementierungen die gleichzeitige Nutzung durch mehrere Nutzer unterstützen (mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren und jeder nutzt sein eigenes Display, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

• [7.6.1/A-1-1] MUSS auf einer einzelnen AAOS-Instanz mindestens 4 GB nichtflüchtigen Speicherplatz für private Anwendungsdaten (/data-Partition) für jeden gleichzeitigen Android-Nutzer haben.

Wenn Automotive-Geräteimplementierungen 64‑Bit-Implementierungen sind:

• [7.6.1/A-2-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 816 MB pro Hauptdisplay betragen, wenn eine der folgenden Dichten verwendet wird:

  • 280 dpi oder weniger auf kleinen/normalen Bildschirmen
  • ldpi oder niedriger auf extragroßen Bildschirmen
  • mdpi oder niedriger auf großen Bildschirmen

• [7.6.1/A-2-2] Der für den Kernel und den Nutzerbereich verfügbare Speicher muss mindestens 944 MB pro Hauptdisplay betragen, wenn eine der folgenden Dichten verwendet wird:

  • xhdpi oder höher auf kleinen/normalen Displays
  • hdpi oder höher auf großen Bildschirmen
  • mdpi oder höher auf besonders großen Bildschirmen

• [7.6.1/A-2-3] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 1.280 MB pro Hauptdisplay betragen, wenn eine der folgenden Dichten verwendet wird:

  • 400 dpi oder höher auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tv‑dpi oder höher auf besonders großen Bildschirmen

• [7.6.1/A-2-4] Der für den Kernel und den Userspace verfügbare Speicher MUSS mindestens 1.824 MB pro Hauptdisplay betragen, wenn eine der folgenden Dichten verwendet wird:

  • 560 dpi oder höher auf kleinen/normalen Bildschirmen
  • 400 dpi oder höher auf großen Bildschirmen
  • xhdpi oder höher auf besonders großen Bildschirmen

Der oben erwähnte „für den Kernel und den Userspace verfügbare Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicher, der zusätzlich zu dem Arbeitsspeicher bereitgestellt wird, der bereits für Hardwarekomponenten wie Funk, Video usw. reserviert ist, die in Geräteimplementierungen nicht der Kontrolle des Kernels unterliegen.

Automotive-Geräteimplementierungen:

• [7.7.1/A] SOLLTE einen USB-Anschluss für den Peripheriemodus enthalten.

Wenn Automotive-Geräteimplementierungen einen USB-Anschluss mit einem Controller im Peripheriemodus enthalten, gilt Folgendes:

• [7.7.1/A-1-1] MUSS die Android Open Accessory (AOA) API implementieren.

Wenn Automotive-Geräteimplementierungen einen USB-Anschluss mit Unterstützung für den Hostmodus enthalten, gilt Folgendes:

• [7.7.2/A-1-1] MUSS die USB-Audioklasse implementieren, wie in der Android SDK-Dokumentation beschrieben.

Automotive-Geräteimplementierungen:

• [7.8.1/A-0-1] MUSS ein Mikrofon enthalten.

Automotive-Geräteimplementierungen:

• [7.8.2/A-0-1] MÜSSEN eine Audioausgabe haben und android.hardware.audio.output deklarieren.

Wenn Automotive-Geräteimplementierungen die gleichzeitige Nutzung durch mehrere Nutzer unterstützen (mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren und jeder nutzt sein eigenes Display, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

• [7.8.2/A-1-1] MUSS für jedes Hauptdisplay ein Audioausgabegerät für gleichzeitige Mehrbenutzersysteme haben.

• [7.8.2/A-1-2] MUSS eine Audiozone für den Fahrer haben, die den globalen Kabinenlautsprecher abdeckt. Die Audiozone des Beifahrers kann mit der Audiozone des Fahrers geteilt werden oder einen eigenen Audioausgang haben.

Wenn die AudioManager.getDevices() API aufgerufen wird, während das USB-Peripheriegerät verbunden ist, passiert Folgendes:

• [7.8.2.2/A-1-1] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_HEADSET und der Rolle isSink() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x0302 ist.

• [7.8.2.2/A-1-2] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_HEADSET und der Rolle isSink() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x0402 ist.

• [7.8.2.2/A-1-3] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_HEADSET und der Rolle isSink() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x0603 ist.

• [7.8.2.2/A-1-4] MUSS ein Gerät des Typs AudioDeviceInfo.TYPE_USB_HEADSET und der Rolle isSink() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x0400 ist.

2.5.2. Multimedia

Automotive-Geräteimplementierungen MÜSSEN die folgenden Audio-Codierungs- und ‑Decodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

• [5.1/A-0-1] MPEG-4 AAC-Profil (AAC LC)

• [5.1/A-0-2] MPEG-4 HE AAC-Profil (AAC+)

• [5.1/A-0-3] AAC ELD (Enhanced Low Delay AAC)

Automotive-Geräteimplementierungen MÜSSEN die folgenden Video-Codierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

• [5.2/A-0-1] H.264 AVC

• [5.2/A-0-2] VP8

Automotive-Geräteimplementierungen MÜSSEN die folgenden Videodecodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

• [5.3/A-0-1] H.264 AVC

• [5.3/A-0-2] MPEG-4 SP

• [5.3/A-0-3] VP8

• [5.3/A-0-4] VP9

Für Automotive-Geräteimplementierungen wird DRINGEND empfohlen, die folgenden Videodecodierungen zu unterstützen:

• [5.3/A-SR-1] H.265 HEVC

Wenn Automotive-Geräteimplementierungen die gleichzeitige Nutzung durch mehrere Nutzer unterstützen (mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren und jeder nutzt sein eigenes Display, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

• [5.5.3/A-1-1] MÜSSEN identische Lautstärkekurven für alle Audioausgabestreams definiert werden, die derselben Lautstärkegruppe zugeordnet sind, wie in der Konfigurationsdatei für Car-Audio definiert.

2.5.3. Software

Automotive-Geräteimplementierungen:

• [3/A-0-1] MÜSSEN die Funktion android.hardware.type.automotive deklarieren.

• [3/A-0-2] MÜSSEN uiMode = UI_MODE_TYPE_CAR unterstützen.

• [3/A-0-3] MÜSSEN alle öffentlichen APIs im Namespace android.car.* unterstützen.

Wenn Automotive-Geräteimplementierungen eine proprietäre API mit android.car.CarPropertyManager und android.car.VehiclePropertyIds bereitstellen, gilt Folgendes:

• [3/A-1-1] Die Verwendung dieser Eigenschaften durch Systemanwendungen darf NICHT mit besonderen Berechtigungen verbunden sein und Drittanbieteranwendungen dürfen NICHT daran gehindert werden, diese Eigenschaften zu verwenden.

• [3/A-1-2] Eine Fahrzeugeigenschaft, die bereits im SDK vorhanden ist, darf NICHT repliziert werden.

Automotive-Geräteimplementierungen:

• [3.2.1/A-0-1] MÜSSEN alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der Referenzseite für Automotive-Berechtigungen dokumentiert.

• [3.2.3.1/A-0-1] MUSS eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorladen, die durch die folgenden hier aufgeführten Anwendungs-Intents definiert sind.

• [3.2.3.1/A-0-2] Die App MUSS die Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE und ACTION_CREATE_DOCUMENT wie in der SDK-Dokumentation beschrieben verarbeiten und dem Nutzer die Möglichkeit bieten, über die DocumentsProvider-API auf die Daten des Dokumentanbieters zuzugreifen.

Wenn die Einstellungen-App einer Automotive-Geräteimplementierung eine Split-Funktion mit Activity Embedding implementiert, gilt Folgendes:

• [3.2.3.1/A-1-1] MUSS eine Aktivität haben, die den Intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY verarbeitet, wenn die Split-Funktion aktiviert ist. Die Aktivität MUSS durch android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK geschützt sein und die Aktivität des Intents starten, der aus Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI geparst wurde.

• [3.4.1/A-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API bereitstellen.

Wenn Automotive-Geräteimplementierungen die gleichzeitige Nutzung durch mehrere Nutzer unterstützen (mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren und jeder nutzt sein eigenes Display, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

• [3.8/A-1-1] MUSS die folgende vordefinierte Liste von UserRestrictions für sekundäre Nutzer implementieren, die nicht der aktuelle Vordergrundnutzer sind, aber UI-Zugriff auf das ihnen zugewiesene Display haben. Die Liste der UserRestrictions lautet: DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE, und DISALLOW_MICROPHONE_TOGGLE.

• [3.8/A-1-2] Es DARF NICHT zugelassen werden, dass sekundäre Nutzer, die nicht der aktuelle Vordergrundnutzer sind, aber über die Benutzeroberfläche Zugriff auf das ihnen zugewiesene Display haben, den Tag-/Nachtmodus, das Gebietsschema, das Datum, die Uhrzeit, die Zeitzone oder die Displayfarben (einschließlich Helligkeit, Nachtlicht, Graustufen für Digital Wellbeing und „Helle Farben reduzieren“) für einen anderen Nutzer über die Einstellungen oder über eine API ändern.

Automotive-Geräteimplementierungen:

• [3.8.3/A-0-1] MÜSSEN Benachrichtigungen angezeigt werden, die die Notification.CarExtender-API verwenden, wenn sie von Drittanbieteranwendungen angefordert werden.

• [3.8.4/A-SR-1] Es wird DRINGEND EMPFOHLEN, einen Assistenten auf dem Gerät zu implementieren, der die Assist-Aktion verarbeitet.

Wenn Automotive-Geräteimplementierungen eine Push-to-Talk-Taste enthalten, gilt Folgendes:

• [3.8.4/A-1-1] Bei einem kurzen Drücken der Push-to-Talk-Taste MUSS die vom Nutzer ausgewählte Assistenz-App gestartet werden, d. h. die App, die VoiceInteractionService implementiert.

Automotive-Geräteimplementierungen:

• [3.8.3.1/A-0-1] MUSS Ressourcen wie in der Notifications on Automotive OS-SDK-Dokumentation beschrieben korrekt rendern.

• [3.8.3.1/A-0-2] MUSS für Benachrichtigungsaktionen PLAY und MUTE anstelle der über Notification.Builder.addAction() bereitgestellten Optionen anzeigen.

• [3.8.3.1/A] SOLLTE die Verwendung von umfangreichen Verwaltungsaufgaben wie Steuerelementen pro Benachrichtigungskanal einschränken. MAY use UI affordance per application to reduce controls.

Wenn Automotive-Geräteimplementierungen User HAL-Properties unterstützen, gilt Folgendes:

• [3.9.3/A-1-1] MUSS alle Properties für den Nutzerlebenszyklus implementieren: INITIAL_USER_INFO, SWITCH_USER, CREATE_USER und REMOVE_USER.

Automotive-Geräteimplementierungen:

• [3.14/A-0-1] MUSS ein UI-Framework enthalten, um Drittanbieter-Apps zu unterstützen, die die Media APIs gemäß Abschnitt 3.14 verwenden.

• [3.14/A-0-2] Der Nutzer MUSS während der Fahrt sicher mit Media-Apps interagieren können.

• [3.14/A-0-3] MÜSSEN die implizite Intent-Aktion CAR_INTENT_ACTION_MEDIA_TEMPLATE mit dem Extra CAR_EXTRA_MEDIA_PACKAGE unterstützen.

• [3.14/A-0-4] Es MUSS eine Möglichkeit geben, zur Einstellungsaktivität einer Media-App zu navigieren. Dies DARF jedoch nur möglich sein, wenn keine Einschränkungen der Car UX gelten.

• [3.14/A-0-5] MÜSSEN von Media-Apps festgelegte Fehlermeldungen anzeigen und die optionalen Extras ERROR_RESOLUTION_ACTION_LABEL und ERROR_RESOLUTION_ACTION_INTENT unterstützen.

• [3.14/A-0-6] Apps, die die Suche unterstützen, MÜSSEN eine Möglichkeit zur Suche in der App bieten.

• [3.14/A-0-7] MUSS die Definitionen von CONTENT_STYLE_BROWSABLE_HINT und CONTENT_STYLE_PLAYABLE_HINT bei der Anzeige der MediaBrowser-Hierarchie berücksichtigen.

Wenn Automotive-Geräteimplementierungen eine Standard-Launcher-App enthalten, gilt Folgendes:

• [3.14/A-1-1] MUSS Mediendienste enthalten und mit dem Intent CAR_INTENT_ACTION_MEDIA_TEMPLATE geöffnet werden.

Automotive-Geräteimplementierungen:

• [3.8/A] MAY restrict the application requests to enter a full screen mode as described in immersive documentation.

• [3.8/A] Die Statusleiste und die Navigationsleiste DÜRFEN jederzeit sichtbar sein.

• [3.8/A] MAY restrict the application requests to change the colors behind the system UI elements, to ensure those elements are clearly visible at all times.

2.5.4. Leistung und Energie

• [8.1/A-0-1] Konsistente Frame-Latenz. Inkonsistente Frame-Latenz oder eine Verzögerung beim Rendern von Frames DÜRFEN nicht häufiger als 5 Frames pro Sekunde auftreten und SOLLTEN weniger als 1 Frame pro Sekunde betragen.

• [8.1/A-0-2] Latenz der Benutzeroberfläche. Bei Geräteimplementierungen MUSS eine geringe Latenz für Nutzer gewährleistet werden, indem eine Liste mit 10.000 Listeneinträgen, wie in der Android Compatibility Test Suite (CTS) definiert, in weniger als 36 Sekunden gescrollt wird.

• [8.1/A-0-3] Wechseln zwischen Aufgaben. Wenn mehrere Apps gestartet wurden, muss das erneute Starten einer bereits laufenden Anwendung nach dem Starten weniger als 1 Sekunde dauern.

Automotive-Geräteimplementierungen:

• [8.2/A-0-1] Die Anzahl der gelesenen und geschriebenen Bytes im nichtflüchtigen Speicher muss für jede Prozess-UID gemeldet werden, damit die Statistiken für Entwickler über die System-API android.car.storagemonitoring.CarStorageMonitoringManager verfügbar sind. Das Open-Source-Projekt für Android erfüllt die Anforderung durch das uid_sys_stats-Kernelmodul.

• [8.2/A-0-2] MUSS eine sequenzielle Schreibleistung von mindestens 5 MB/s bieten.

• [8.2/A-0-3] MÜSSEN eine zufällige Schreibleistung von mindestens 0,5 MB/s bieten.

• [8.2/A-0-4] MÜSSEN eine sequenzielle Leseleistung von mindestens 15 MB/s bieten.

• [8.2/A-0-5] MÜSSEN eine zufällige Leseleistung von mindestens 3,5 MB/s bieten.

Wenn Automotive-Geräteimplementierungen für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS android.os.Build.VERSION_CODES.U oder höher zurückgeben, gilt Folgendes:

• [8.2/A-1-1] MUSS eine sequenzielle Schreibleistung von mindestens 150 MB/s bieten.

• [8.2/A-1-2] MÜSSEN eine zufällige Schreibleistung von mindestens 10 MB/s gewährleisten.

• [8.2/A-1-3] MUSS eine sequenzielle Leseleistung von mindestens 250 MB/s bieten.

• [8.2/A-1-4] MUSS eine zufällige Leseleistung von mindestens 100 MB/s gewährleisten.

• [8.2/A-1-5] MUSS eine parallele sequentielle Lese- und Schreibleistung mit einer 2-fachen Lese- und einer 1-fachen Schreibleistung von mindestens 50 MB/s gewährleisten.

• [8.3/A-1-3] MUSS den Garagenmodus unterstützen.

• [8.3/A] Das Gerät SOLLTE nach jeder Fahrt mindestens 15 Minuten lang im Garagenmodus sein, es sei denn:

  • Der Akku ist leer.
  • Es sind keine Leerlaufjobs geplant.
  • Der Fahrer verlässt den Garagenmodus.

• [8.4/A-0-1] MUSS ein Energieprofil pro Komponente bereitstellen, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch der Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.

• [8.4/A-0-2] MÜSSEN alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angegeben werden.

• [8.4/A-0-3] MUSS den CPU-Stromverbrauch für die UID jedes Prozesses melden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.

• [8.4/A] SOLLTE der Hardwarekomponente selbst zugeschrieben werden, wenn der Stromverbrauch der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.

• [8.4/A-0-4] MUSS diese Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.

2.5.5. Sicherheitsmodell

Wenn Automotive-Geräteimplementierungen mehrere Nutzer unterstützen, gilt Folgendes:

• [9.5/A-1-1] Nutzer DÜRFEN NICHT mit dem Headless System User interagieren oder zu diesem wechseln, außer für die Gerätebereitstellung.

• [9.5/A-1-2] MUSS vor BOOT_COMPLETED in einen sekundären Nutzer wechseln.

• [9.5/A-1-3] Es MUSS möglich sein, einen Gastnutzer zu erstellen, auch wenn die maximale Anzahl von Nutzern auf einem Gerät erreicht wurde.

Wenn Automotive-Geräteimplementierungen die System-API VisualQueryDetectionService oder einen anderen Mechanismus zur Erkennung von Anfragen ohne Anzeige des Mikrofon- und/oder Kamerazugriffs unterstützen, gilt Folgendes:

• [9.8/A-1-1] MUSS dafür sorgen, dass der Dienst zur Erkennung von Anfragen Daten nur an das System, ContentCaptureService oder den On-Device-Spracherkennungsdienst (erstellt von SpeechRecognizer#createOnDeviceSpeechRecognizer()) übertragen kann.

• [9.8/A-1-2] Es DÜRFEN keine Audio- oder Videoinformationen aus dem VisualQueryDetectionService übertragen werden, außer an ContentCaptureService oder den On-Device-Spracherkennungsdienst.

• [9.8/A-1-3] MUSS in der System-UI eine Nutzerbenachrichtigung anzeigen, wenn das Gerät eine Nutzerabsicht zur Interaktion mit der Digital Assistant-App erkennt (z. B. durch Erkennen der Nutzeranwesenheit über die Kamera).

• [9.8/A-1-4] Es MUSS eine Mikrofonanzeige angezeigt werden und die erkannte Nutzeranfrage MUSS sofort nach der Erkennung in der Benutzeroberfläche angezeigt werden.

• [9.8/A-1-5] Eine vom Nutzer installierbare Anwendung DARF NICHT den Dienst zur Erkennung visueller Anfragen bereitstellen.

Wenn in Automotive-Geräteimplementierungen android.hardware.microphone deklariert wird, gilt Folgendes:

• [9.8.2/A-1-1] Die Mikrofonanzeige MUSS angezeigt werden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 mit CDD-Kennung [C-4-X] genannten Rollen auf das Mikrofon zugreifen.

• [9.8.2/A-1-2] DARF die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Nutzerinteraktion NICHT ausblenden.

• [9.8.2/A-1-3] MUSS eine Möglichkeit für den Nutzer bieten, das Mikrofon in den Einstellungen zu aktivieren oder zu deaktivieren.

Wenn in Automotive-Geräteimplementierungen android.hardware.camera.any deklariert wird, gilt Folgendes:

• [9.8.2/A-2-1] Die Kamerazugriff-Hinweis MUSS angezeigt werden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn nur von Apps mit den in Abschnitt 9.1 Berechtigungen definierten Rollen mit der CDD-Kennung [C-4-X] auf die Kamera zugegriffen wird.

• [9.8.2/A-2-2] DARF den Kamerazugriff-Hinweis für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Nutzerinteraktion NICHT ausblenden.

• [9.8.2/A-2-3] MUSS eine Möglichkeit für Nutzer bieten, die Kamera in den Einstellungen zu aktivieren oder zu deaktivieren.

• [9.8.2/A-2-4] MÜSSEN die zuletzt verwendeten und aktiven Apps, die die Kamera verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen angezeigt werden.

Automotive-Geräteimplementierungen:

• [9/A-0-1] MÜSSEN die android.hardware.security.model.compatible-Funktion deklarieren.

• [9.11/A-0-1] Die Keystore-Implementierung MUSS durch eine isolierte Ausführungsumgebung gesichert werden.

• [9.11/A-0-2] MÜSSEN Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie der Hash-Funktionen der MD5-, SHA-1- und SHA-2-Familie enthalten, um die unterstützten Algorithmen des Android-Schlüsselspeichersystems in einem Bereich, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird, ordnungsgemäß zu unterstützen. Die sichere Isolation MUSS alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer geeigneten hypervisorbasierten Isolation sind alternative Optionen.

• [9.11/A-0-3] Die Authentifizierung über den Sperrbildschirm MUSS in der isolierten Ausführungsumgebung erfolgen und die Verwendung der an die Authentifizierung gebundenen Schlüssel DARF nur bei erfolgreicher Authentifizierung zugelassen werden. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Authentifizierung auf dem Sperrbildschirm durchführen kann. Das Upstream-Android-Open-Source-Projekt bietet die Gatekeeper-Hardwareabstraktionsschicht (HAL) und Trusty, die verwendet werden können, um diese Anforderung zu erfüllen.

• [9.11/A-0-4] MUSS die Schlüsselattestierung unterstützen, bei der der Attestationssignaturschlüssel durch sichere Hardware geschützt ist und die Signierung in sicherer Hardware erfolgt. Die Attestierungssignaturschlüssel DÜRFEN NICHT als dauerhafte Geräte-IDs verwendet werden.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version eingeführt wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen durch eine isolierte Ausführungsumgebung gesicherten Schlüsselspeicher zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert das android.hardware.fingerprint-Feature, das einen durch eine isolierte Ausführungsumgebung gesicherten Schlüsselspeicher erfordert.

Automotive-Geräteimplementierungen:

• [9.14/A-0-1] MÜSSEN Nachrichten von Android-Framework-Fahrzeugsubsystemen filtern (z.B. durch Zulassen von zulässigen Nachrichtentypen und Nachrichtenquellen).

• [9.14/A-0-2] MUSS vor Denial-of-Service-Angriffen durch das Android-Framework oder Drittanbieter-Apps geschützt sein. Dies schützt vor schädlicher Software, die das Fahrzeugnetzwerk mit Traffic überflutet, was zu Fehlfunktionen von Fahrzeugsubsystemen führen kann.

2.5.6. Kompatibilität von Entwicklertools und -optionen

Automotive-Geräteimplementierungen:

• Perfetto

  • [6.1/A-0-1] MUSS ein /system/bin/perfetto-Binärprogramm für den Shell-Nutzer bereitstellen, dessen Befehlszeile der Perfetto-Dokumentation entspricht.

  • [6.1/A-0-2] Die Binärdatei „perfetto“ MUSS eine Protobuf-Konfiguration als Eingabe akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.

  • [6.1/A-0-3] Die Binärdatei „perfetto“ MUSS als Ausgabe einen Protobuf-Trace schreiben, der dem in der Perfetto-Dokumentation definierten Schema entspricht.

  • [6.1/A-0-4] MÜSSEN über die Binärdatei „perfetto“ mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitstellen.

  • [6.1/A-0-5] Der Perfetto-Trace-Daemon MUSS standardmäßig aktiviert sein (Systemeigenschaft persist.traced.enable).

2.6. Tablet-Anforderungen

Ein Android-Tablet ist eine Android-Geräteimplementierung, die in der Regel alle folgenden Kriterien erfüllt:

• Wird mit beiden Händen gehalten.
• Das Gerät hat kein Clamshell- oder Convertible-Design.
• Physische Tastaturen, die mit dem Gerät verwendet werden, werden über eine Standardverbindung (z.B. USB, Bluetooth) angeschlossen.
• Das Gerät hat eine Stromquelle, die Mobilität ermöglicht, z. B. einen Akku.
• Die Bildschirmgröße beträgt diagonal gemessen mehr als 7 Zoll und weniger als 18 Zoll.

Für Tablet-Geräteimplementierungen gelten ähnliche Anforderungen wie für Mobilgeräteimplementierungen. Die Ausnahmen sind in diesem Abschnitt mit einem Sternchen (*) gekennzeichnet und zur Referenz aufgeführt.

2.6.1. Hardware

Gyroskop

Wenn Tablet-Geräteimplementierungen ein 3‑Achsen-Gyroskop enthalten, gilt Folgendes:

• [7.3.4/Tab-1-1] MUSS in der Lage sein, Änderungen der Ausrichtung von bis zu 1.000 Grad pro Sekunde zu messen.

Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)

Die für kleine/normale Displays in den Anforderungen für Handheld-Geräte aufgeführten Displaydichten gelten nicht für Tablets.

Virtual Reality Mode (Abschnitt 7.9.1)

Hohe Leistung bei Virtual Reality (Abschnitt 7.9.2)

Die Anforderungen für Virtual Reality gelten nicht für Tablets.

2.6.2. Sicherheitsmodell

Schlüssel und Anmeldedaten (Abschnitt 9.11)

Weitere Informationen finden Sie im Abschnitt [9.11].

Wenn Tablet-Geräteimplementierungen mehrere Nutzer umfassen und das android.hardware.telephony-Funktions-Flag nicht deklarieren, gilt Folgendes:

• [9.5/T-1-1] MUSS eingeschränkte Profile unterstützen. Mit dieser Funktion können Geräteinhaber zusätzliche Nutzer und ihre Funktionen auf dem Gerät verwalten. Mit eingeschränkten Profilen können Geräteinhaber schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen für die in diesen Umgebungen verfügbaren Apps verwalten.

Wenn Tablet-Geräteimplementierungen mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony deklarieren, gilt Folgendes:

• [9.5/T-2-1] MUSS eingeschränkte Profile unterstützen, aber MUSS der AOSP-Implementierung von Steuerelementen entsprechen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen /zu verweigern.

2.6.2. Software

• [3.2.3.1/Tab-0-1] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorab laden, die durch die folgenden Anwendungs-Intents definiert sind, die hier aufgeführt sind.

3. Software

3.1 Verwaltete API-Kompatibilität

Die verwaltete Dalvik-Bytecode-Ausführungsumgebung ist das primäre Mittel für Android-Anwendungen. Die Android-API (Application Programming Interface) ist die Gruppe von Android-Plattform-Schnittstellen, die für Anwendungen verfügbar sind, die in der verwalteten Laufzeitumgebung ausgeführt werden.

Geräteimplementierungen:

• [C-0-1] MÜSSEN vollständige Implementierungen aller dokumentierten APIs bereitstellen, die vom Android SDK oder einer API, die im Upstream-Android-Quellcode mit dem Marker „@SystemApi“ versehen ist, bereitgestellt werden, einschließlich aller dokumentierten Verhaltensweisen.

• [C-0-2] MUSS alle Klassen, Methoden und zugehörigen Elemente unterstützen/beibehalten, die mit der TestApi-Annotation (@TestApi) gekennzeichnet sind.

• [C-0-3] Es DÜRFEN keine verwalteten APIs ausgelassen, API-Schnittstellen oder ‑Signaturen geändert, vom dokumentierten Verhalten abgewichen oder managementfreie Umgebungen eingeschlossen werden, es sei denn, dies ist in dieser Kompatibilitätsdefinition ausdrücklich zulässig.

• [C-0-4] Die APIs MÜSSEN weiterhin vorhanden sein und sich angemessen verhalten, auch wenn einige Hardwarefunktionen, für die Android APIs enthält, weggelassen werden. Abschnitt 7 enthält spezifische Anforderungen für dieses Szenario.

• [C-0-5] DÜRFEN Drittanbieter-Apps NICHT die Verwendung von Nicht-SDK-Schnittstellen erlauben. Diese sind als Methoden und Felder in den Java-Sprachpaketen definiert, die sich im Boot-Klassenpfad in AOSP befinden und nicht Teil des öffentlichen SDK sind. Dazu gehören APIs, die mit der Annotation @hide, aber nicht mit @SystemAPI versehen sind, wie in der SDK-Dokumentation beschrieben, sowie private und package-private Klassenmember.

• [C-0-6] MUSS mit jeder Nicht-SDK-Schnittstelle auf denselben eingeschränkten Listen ausgeliefert werden, die über die vorläufigen und Denylist-Flags im Pfad prebuilts/runtime/appcompat/hiddenapi-flags.csv für den entsprechenden API-Level-Zweig im AOSP bereitgestellt werden.

• [C-0-7] MUSS den dynamischen Aktualisierungsmechanismus für signierte Konfigurationen unterstützen, um Nicht-SDK-Schnittstellen aus einer eingeschränkten Liste zu entfernen. Dazu muss die signierte Konfiguration in eine beliebige APK eingebettet werden. Die vorhandenen öffentlichen Schlüssel in AOSP müssen verwendet werden.

  Allerdings:

  • MAY: Wenn eine verborgene API in der Geräteimplementierung fehlt oder anders implementiert ist, verschieben Sie die verborgene API in die Denylist oder lassen Sie sie in allen eingeschränkten Listen weg.
  • MAI: Wenn eine verborgene API noch nicht in AOSP vorhanden ist, fügen Sie sie einer der eingeschränkten Listen hinzu.

3.1.1. Android-Erweiterungen

Unter Android kann die verwaltete API-Oberfläche eines bestimmten API-Levels erweitert werden, indem die Erweiterungsversion für dieses API-Level aktualisiert wird. Die android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API gibt die Erweiterungsversion des bereitgestellten apiLevel zurück, sofern Erweiterungen für diese API-Ebene vorhanden sind.

Android-Geräteimplementierungen:

• [C-0-1] Die AOSP-Implementierung der freigegebenen Bibliothek ExtShared und der Dienste ExtServices mit Versionen, die mindestens den für die einzelnen API-Levels zulässigen Mindestversionen entsprechen, MUSS vorab geladen werden. Bei Geräteimplementierungen mit Android 7.0, auf denen API-Level 24 ausgeführt wird, MUSS mindestens Version 1 enthalten sein.

• [C-0-2] MUSS nur gültige Versionsnummern für Erweiterungen zurückgeben, die vom AOSP definiert wurden.

• [C-0-3] MÜSSEN alle APIs unterstützen, die von den Erweiterungsversionen definiert werden, die von android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) zurückgegeben werden, und zwar auf dieselbe Weise wie andere verwaltete APIs, gemäß den Anforderungen in Abschnitt 3.1.

3.1.2. Android-Bibliothek

Aufgrund der Einstellung des Apache HTTP-Clients gilt für Geräteimplementierungen Folgendes:

• [C-0-1] Die org.apache.http.legacy-Bibliothek DARF NICHT im Bootclasspath platziert werden.
• [C-0-2] MUSS die org.apache.http.legacy-Bibliothek nur dann dem Klassenpfad der Anwendung hinzugefügt werden, wenn die App eine der folgenden Bedingungen erfüllt:
  • Die App ist auf API-Level 28 oder niedriger ausgerichtet.
  • In seinem Manifest wird deklariert, dass die Bibliothek benötigt wird. Dazu wird das Attribut android:name von <uses-library> auf org.apache.http.legacy gesetzt.

Die AOSP-Implementierung erfüllt diese Anforderungen.

3.2 Soft API Compatibility

Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 enthält Android auch eine wichtige „weiche“ API, die nur zur Laufzeit verfügbar ist. Dazu gehören unter anderem Intents, Berechtigungen und ähnliche Aspekte von Android-Anwendungen, die zur Kompilierungszeit der Anwendung nicht erzwungen werden können.

3.2.1. Berechtigungen

• [C-0-1] Geräteimplementierer MÜSSEN alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der Seite mit Berechtigungsreferenzen dokumentiert. Abschnitt 9 enthält zusätzliche Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell.

3.2.2. Build-Parameter

Die Android-APIs enthalten eine Reihe von Konstanten in der android.os.Build-Klasse, die das aktuelle Gerät beschreiben sollen.

3.2.3. Intent-Kompatibilität

3.2.3.1. Häufig verwendete App-Intents

Mit Android-Intents können Anwendungskomponenten Funktionen von anderen Android-Komponenten anfordern. Das Android-Upstream-Projekt enthält eine Liste von Anwendungen, die verschiedene Intent-Muster zur Ausführung allgemeiner Aktionen implementieren.

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorzuladen, die durch die folgenden hier aufgeführten Anwendungs-Intents definiert sind, und die Erfüllung bereitzustellen, d.h. die Erwartungen des Entwicklers für diese gängigen Anwendungs-Intents zu erfüllen, wie im SDK beschrieben.

Abschnitt 2 enthält die erforderlichen Anwendungs-Intents für jeden Gerätetyp.

3.2.3.2. Intent-Auflösung

• [C-0-1] Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen es ermöglichen, dass jedes in Abschnitt 3.2.3.1 referenzierte Intent-Muster, mit Ausnahme von Einstellungen, von Drittanbieteranwendungen überschrieben werden kann. Die Upstream-Android-Open-Source-Implementierung ermöglicht dies standardmäßig.

• [C-0-2] Geräteimplementierer DÜRFEN die Verwendung dieser Intent-Muster durch Systemanwendungen NICHT mit besonderen Berechtigungen verknüpfen oder verhindern, dass Drittanbieteranwendungen eine Bindung an diese Muster herstellen und die Kontrolle über sie übernehmen. Dieses Verbot umfasst insbesondere, aber nicht ausschließlich, das Deaktivieren der Benutzeroberfläche „Chooser“, über die der Nutzer zwischen mehreren Anwendungen auswählen kann, die alle dasselbe Intent-Muster verarbeiten.

• [C-0-3] Geräteimplementierungen MÜSSEN eine Benutzeroberfläche für Nutzer bereitstellen, über die die Standardaktivität für Intents geändert werden kann.

• Geräteimplementierungen KÖNNEN jedoch Standardaktivitäten für bestimmte URI-Muster (z.B. http://play.google.com) bereitstellen, wenn die Standardaktivität ein spezifischeres Attribut für den Daten-URI bietet. Beispielsweise ist ein Intent-Filtermuster, das den Daten-URI „http://www.android.com“ angibt, spezifischer als das Core-Intent-Muster des Browsers für „http://“.

Android bietet auch einen Mechanismus für Drittanbieter-Apps, um ein autoritatives Standardverhalten für App-Links für bestimmte Arten von Web-URI-Intents zu deklarieren. Wenn solche autoritativen Deklarationen in den Intent-Filtermustern einer App definiert sind, gilt für Geräteimplementierungen Folgendes:

• [C-0-4] MUSS versuchen, alle Intent-Filter zu validieren, indem die in der Digital Asset Links-Spezifikation definierten Validierungsschritte ausgeführt werden, wie sie vom Paketmanager im Upstream-Android Open Source Project implementiert sind.
• [C-0-5] MUSS versuchen, die Intent-Filter während der Installation der Anwendung zu validieren, und alle erfolgreich validierten URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen.
• Sie KÖNNEN bestimmte URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen, wenn sie erfolgreich überprüft wurden, aber andere infrage kommende URI-Filter die Überprüfung nicht bestehen. Wenn ein Gerät dies tut, MUSS es dem Nutzer im Einstellungsmenü geeignete Überschreibungen pro URI-Muster zur Verfügung stellen.
• Der Nutzer MUSS in den Einstellungen die folgenden App-Link-Einstellungen für jede App vorfinden:
  • [C-0-6] Der Nutzer MUSS das Standardverhalten für App-Links für eine App als Ganzes überschreiben können, sodass die App immer geöffnet wird, immer gefragt wird oder nie geöffnet wird. Dies muss für alle infrage kommenden URI-Intent-Filter gleichermaßen gelten.
  • [C-0-7] Der Nutzer MUSS eine Liste der infrage kommenden URI-Intent-Filter sehen können.
  • Die Geräteimplementierung KANN dem Nutzer die Möglichkeit bieten, bestimmte Intent-Filter für Kandidaten-URIs, die erfolgreich überprüft wurden, auf Intent-Filter-Basis zu überschreiben.
  • [C-0-8] Die Geräteimplementierung MUSS Nutzern die Möglichkeit bieten, bestimmte Kandidaten-URI-Intent-Filter anzusehen und zu überschreiben, wenn bei der Geräteimplementierung einige Kandidaten-URI-Intent-Filter die Überprüfung bestehen, andere jedoch nicht.

3.2.3.3. Intent-Namespaces

• [C-0-1] Geräteimplementierungen DÜRFEN keine Android-Komponente enthalten, die neue Intent- oder Broadcast-Intent-Muster mit einem ACTION-, CATEGORY- oder anderen Schlüsselstring im Namespace „android.*“ oder „com.android.*“ berücksichtigt.
• [C-0-2] Geräteimplementierer DÜRFEN keine Android-Komponenten einbinden, die neue Intent- oder Broadcast-Intent-Muster mit einem ACTION-, CATEGORY- oder anderen Schlüsselstring in einem Paketbereich einer anderen Organisation berücksichtigen.
• [C-0-3] Geräteimplementierer DÜRFEN keines der in Abschnitt 3.2.3.1 aufgeführten Intent-Muster ändern oder erweitern.
• Geräteimplementierungen KÖNNEN Intent-Muster mit Namespaces enthalten, die eindeutig und offensichtlich mit der eigenen Organisation verknüpft sind. Dieses Verbot entspricht dem für Java-Sprachklassen in Abschnitt 3.6.

3.2.3.4. Broadcast-Intents

Drittanbieteranwendungen sind darauf angewiesen, dass die Plattform bestimmte Intents überträgt, um sie über Änderungen in der Hardware- oder Softwareumgebung zu informieren.

Geräteimplementierungen:

• [C-0-1] MUSS die hier aufgeführten öffentlichen Broadcast-Intents als Reaktion auf entsprechende Systemereignisse wie in der SDK-Dokumentation beschrieben übertragen. Diese Anforderung steht nicht im Widerspruch zu Abschnitt 3.5, da die Einschränkung für Hintergrundanwendungen auch in der SDK-Dokumentation beschrieben wird. Bestimmte Broadcast-Intents sind auch von der Hardwareunterstützung abhängig. Wenn das Gerät die erforderliche Hardware unterstützt, MUSS es die Intents übertragen und das Verhalten gemäß der SDK-Dokumentation bereitstellen.

3.2.3.5. Bedingte Anwendungs-Intents

Android bietet Einstellungen, mit denen Nutzer auf einfache Weise ihre Standardanwendungen auswählen können, z. B. für den Startbildschirm oder SMS.

Sofern sinnvoll, MUSS in Geräteimplementierungen ein ähnliches Einstellungsmenü vorhanden sein und die Geräteimplementierungen MÜSSEN mit dem Intent-Filtermuster und den API-Methoden kompatibel sein, die in der SDK-Dokumentation unten beschrieben werden.

Wenn Geräteimplementierungen android.software.home_screen melden, gilt Folgendes:

• [C-1-1] MUSS den Intent android.settings.HOME_SETTINGS berücksichtigen, um ein Standardmenü für App-Einstellungen für den Startbildschirm anzuzeigen.

Wenn Geräteimplementierungen android.hardware.telephony.calling melden, gilt Folgendes:

• [C-2-1] MUSS ein Einstellungsmenü bereitstellen, das den Intent android.provider.Telephony.ACTION_CHANGE_DEFAULT aufruft, um ein Dialogfeld zum Ändern der Standard-SMS-App anzuzeigen.

• [C-2-2] MUSS den Intent android.telecom.action.CHANGE_DEFAULT_DIALER berücksichtigen, um ein Dialogfeld anzuzeigen, in dem der Nutzer die Standard-Telefon-App ändern kann.

  • Die Benutzeroberfläche der vom Nutzer ausgewählten Standard-Telefonie-App MUSS für eingehende und ausgehende Anrufe verwendet werden, mit Ausnahme von Notrufen, für die die vorinstallierte Telefonie-App verwendet wird.

• [C-2-3] MUSS den Intent android.telecom.action.CHANGE_PHONE_ACCOUNTS berücksichtigen, um dem Nutzer die Möglichkeit zu geben, das ConnectionServices zu konfigurieren, das mit dem PhoneAccounts verknüpft ist, sowie ein Standard-PhoneAccount, das der Telekommunikationsanbieter für ausgehende Anrufe verwendet. Die AOSP-Implementierung erfüllt diese Anforderung, indem sie im Menü „Anrufe“ in den Einstellungen das Menü „Anrufkonten“ enthält.

• [C-2-4] MUSS android.telecom.CallRedirectionService für eine App zulassen, die die Rolle android.app.role.CALL_REDIRECTION hat.

• [C-2-5] Der Nutzer MUSS die Möglichkeit haben, eine App mit der Rolle android.app.role.CALL_REDIRECTION auszuwählen.

• [C-2-6] MUSS die Intents android.intent.action.SENDTO und android.intent.action.VIEW unterstützen und eine Aktivität zum Senden/Anzeigen von SMS-Nachrichten bereitstellen.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die Intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW und android.intent.action.DIAL mit einer vorinstallierten Dialer-App zu verarbeiten, die diese Intents verarbeiten und die im SDK beschriebene Ausführung ermöglichen kann.

Wenn Geräteimplementierungen android.hardware.nfc.hce melden, gilt Folgendes:

• [C-3-1] MUSS den Intent android.settings.NFC_PAYMENT_SETTINGS berücksichtigen, um ein Menü mit Standard-App-Einstellungen für das kontaktlose Bezahlen anzuzeigen.
• [C-3-2] MUSS den Intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT berücksichtigen, um eine Aktivität anzuzeigen, die ein Dialogfeld öffnet, in dem der Nutzer aufgefordert wird, den Standarddienst für die Kartensimulation für eine bestimmte Kategorie zu ändern, wie im SDK beschrieben.

Wenn Geräteimplementierungen android.hardware.nfc melden, gilt Folgendes:

• [C-4-1] MUSS diese Intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED und android.nfc.action.TECH_DISCOVERED berücksichtigen, um eine Aktivität anzuzeigen, die den Erwartungen der Entwickler für diese Intents entspricht, wie im SDK beschrieben.

Wenn Geräteimplementierungen android.hardware.bluetooth melden, gilt Folgendes:

• [C-5-1] MUSS den Intent 'android.bluetooth.adapter.action.REQUEST_ENABLE' berücksichtigen und eine Systemaktivität anzeigen, damit der Nutzer Bluetooth aktivieren kann.
• [C-5-2] Das Gerät MUSS den Intent android.bluetooth.adapter.action.REQUEST_DISCOVERABLE berücksichtigen und eine Systemaktivität anzeigen, die den auffindbaren Modus anfordert.

Wenn Geräteimplementierungen die Funktion „Bitte nicht stören“ unterstützen, gilt Folgendes:

• [C-6-1] Es MUSS eine Aktivität implementiert werden, die auf die Intention ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS reagiert. Bei Implementierungen mit UI_MODE_TYPE_NORMAL MUSS es sich um eine Aktivität handeln, in der der Nutzer der App Zugriff auf die Konfigurationen der Funktion „Bitte nicht stören“ gewähren oder verweigern kann.

Wenn Geräteimplementierungen es Nutzern ermöglichen, Eingabemethoden von Drittanbietern auf dem Gerät zu verwenden, gilt Folgendes:

• [C-7-1] MUSS einen für Nutzer zugänglichen Mechanismus zum Hinzufügen und Konfigurieren von Drittanbieter-Eingabemethoden als Reaktion auf den Intent android.settings.INPUT_METHOD_SETTINGS bereitstellen.

Wenn Geräteimplementierungen Bedienungshilfen von Drittanbietern unterstützen, gilt Folgendes:

• [C-8-1] MUSS die Intention android.settings.ACCESSIBILITY_SETTINGS berücksichtigen, einen für Nutzer zugänglichen Mechanismus zum Aktivieren und Deaktivieren der Bedienungshilfen von Drittanbietern sowie der vorinstallierten Bedienungshilfen bereitzustellen.

Wenn Geräteimplementierungen Unterstützung für Wi‑Fi Easy Connect enthalten und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-9-1] MUSS die Intent-APIs Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI wie in der SDK-Dokumentation beschrieben implementieren.

Wenn Geräteimplementierungen den Datensparmodus bieten, gilt Folgendes:

• [C-10-1] Es MUSS eine Benutzeroberfläche in den Einstellungen vorhanden sein, die den Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS verarbeitet und es Nutzern ermöglicht, Anwendungen zur Zulassungsliste hinzuzufügen oder aus der Zulassungsliste zu entfernen.

Wenn Geräteimplementierungen den Datensparmodus nicht unterstützen, gilt Folgendes:

• [C-11-1] MUSS eine Aktivität haben, die den Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS verarbeitet, kann ihn aber als No-Op implementieren.

Wenn Geräteimplementierungen die Unterstützung der Kamera über android.hardware.camera.any deklarieren, gilt Folgendes:

• [C-12-3] MÜSSEN die folgenden Intents verarbeiten und DÜRFEN nur vorinstallierten Android-Anwendungen erlauben, sie zu verarbeiten: MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE und MediaStore.ACTION_VIDEO_CAPTURE, wie im SDK-Dokument beschrieben.

Wenn Geräteimplementierungen android.software.device_admin melden, gilt Folgendes:

• [C-13-1] Die Absicht android.app.action.ADD_DEVICE_ADMIN, eine Benutzeroberfläche aufzurufen, um den Nutzer durch das Hinzufügen des Geräteadministrators zum System zu führen (oder ihm zu erlauben, dies abzulehnen), MUSS berücksichtigt werden.

• [C-13-2] MUSS die Intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD und android.app.action.START_ENCRYPTION verarbeiten und eine Aktivität haben, die diese Intents wie im SDK hier beschrieben ausführt.

Wenn Geräteimplementierungen das Funktions-Flag android.software.autofill deklarieren, gilt Folgendes:

• [C-14-1] MUSS die APIs AutofillService und AutofillManager vollständig implementieren und den Intent android.settings.REQUEST_SET_AUTOFILL_SERVICE berücksichtigen, um ein Standardmenü für App-Einstellungen anzuzeigen, in dem der Nutzer die Autofill-Funktion aktivieren und deaktivieren und den Standard-Autofill-Service ändern kann.

Wenn Geräteimplementierungen eine vorinstallierte App enthalten oder Drittanbieter-Apps den Zugriff auf die Nutzungsstatistiken ermöglichen möchten, müssen sie:

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, einen für Nutzer zugänglichen Mechanismus bereitzustellen, mit dem der Zugriff auf die Nutzungsstatistiken als Reaktion auf den Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS für Apps, die die Berechtigung android.permission.PACKAGE_USAGE_STATS deklarieren, gewährt oder widerrufen werden kann.

Wenn Geräteimplementierungen den Zugriff auf die Nutzungsstatistiken für Apps, einschließlich vorinstallierter Apps, nicht zulassen sollen, gilt Folgendes:

• [C-15-1] MUSS weiterhin eine Aktivität haben, die das Intent-Muster android.settings.ACTION_USAGE_ACCESS_SETTINGS verarbeitet, MUSS es aber als No-Op implementieren, d. h. ein Verhalten haben, das dem entspricht, wenn dem Nutzer der Zugriff verweigert wird.

Wenn in Geräteimplementierungen Links zu den Aktivitäten, die durch AutofillService_passwordsActivity angegeben werden, in den Einstellungen oder Links zu Nutzerpasswörtern über einen ähnlichen Mechanismus angezeigt werden, gilt Folgendes:

• [C-16-1] Solche Links MÜSSEN für alle installierten Dienste für automatisches Ausfüllen angezeigt werden.

Wenn Geräteimplementierungen die VoiceInteractionService unterstützen und mehr als eine Anwendung, die diese API verwendet, gleichzeitig installiert ist, gilt Folgendes:

• [C-18-1] Der android.settings.ACTION_VOICE_INPUT_SETTINGS-Intent MUSS berücksichtigt werden, um ein Standardmenü mit App-Einstellungen für die Spracheingabe und den Assistenten anzuzeigen.

Wenn Geräteimplementierungen das Feature android.hardware.audio.output melden, müssen sie folgende Anforderungen erfüllen:

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, die Intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA und android.speech.tts.engine.GET_SAMPLE_TEXT mit einer Aktivität zu verarbeiten, die die Anforderungen dieser Intents wie im SDK hier beschrieben erfüllt.

Android unterstützt interaktive Bildschirmschoner, die früher als „Dreams“ bezeichnet wurden. Mit Bildschirmschonern können Nutzer mit Anwendungen interagieren, wenn ein Gerät, das an eine Stromquelle angeschlossen ist, inaktiv ist oder in einer Dockingstation steht. Geräteimplementierungen:

• MUSS Unterstützung für Bildschirmschoner enthalten und eine Einstellungsoption für Nutzer bieten, um Bildschirmschoner als Reaktion auf den Intent android.settings.DREAM_SETTINGS zu konfigurieren.

Wenn Geräteimplementierungen android.hardware.nfc.uicc oder android.hardware.nfc.ese melden, gilt Folgendes:

• [C-19-1] MUSS die Intent API NfcAdapter.ACTION_TRANSACTION_DETECTED (als „EVT_TRANSACTION“ gemäß der GSM Association-Spezifikation TS.26 – NFC Handset Requirements) implementieren.

3.2.4. Aktivitäten auf sekundären/mehreren Displays

Wenn Geräteimplementierungen das Starten normaler Android-Aktivitäten auf mehr als einem Display zulassen, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag android.software.activities_on_secondary_displays gesetzt werden.
• [C-1-2] MUSS API-Kompatibilität ähnlich einer Aktivität auf dem primären Display garantieren.
• [C-1-3] Die neue Aktivität MUSS auf demselben Display wie die Aktivität angezeigt werden, die sie gestartet hat, wenn die neue Aktivität ohne Angabe eines Zieldisplays über die ActivityOptions.setLaunchDisplayId()-API gestartet wird.
• [C-1-4] ALLE Aktivitäten MÜSSEN beendet werden, wenn ein Display mit dem Flag Display.FLAG_PRIVATE entfernt wird.
• [C-1-5] Inhalte MÜSSEN auf allen Bildschirmen sicher verborgen werden, wenn das Gerät mit einem sicheren Sperrbildschirm gesperrt ist, es sei denn, die App hat sich für die Anzeige über dem Sperrbildschirm mit der Activity#setShowWhenLocked()-API entschieden.
• Sollte android.content.res.Configuration haben, das dem Display entspricht, damit es angezeigt wird, richtig funktioniert und die Kompatibilität beibehalten wird, wenn eine Aktivität auf dem sekundären Display gestartet wird.

Wenn Geräteimplementierungen das Starten normaler Android-Aktivitäten auf sekundären Displays zulassen und ein sekundäres Display das Flag android.view.Display.FLAG_PRIVATE hat:

• [C-3-1] Nur der Inhaber des Displays, des Systems und der Aktivitäten, die sich bereits auf dem Display befinden, DARF die Wiedergabe auf dem Display starten. Jeder kann auf einem Display starten, das das Flag android.view.Display.FLAG_PUBLIC hat.

3.3 Kompatibilität mit nativen APIs

Die Kompatibilität mit nativem Code ist eine Herausforderung. Aus diesem Grund sind Geräteimplementierer:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die Implementierungen der unten aufgeführten Bibliotheken aus dem Open-Source-Projekt für Android zu verwenden.

3.3.1. Binärschnittstellen

Verwalteter Dalvik-Bytecode kann nativen Code aufrufen, der in der .apk-Datei der Anwendung als ELF-Datei .so für die entsprechende Gerätehardwarearchitektur kompiliert ist. Da nativer Code stark von der zugrunde liegenden Prozessortechnologie abhängt, definiert Android im Android NDK eine Reihe von Application Binary Interfaces (ABIs).

Geräteimplementierungen:

• [C-0-1] MUSS mit einem oder mehreren definierten Android NDK-ABIs kompatibel sein.
• [C-0-2] MUSS Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code aufzurufen, wobei die standardmäßige Java Native Interface-Semantik (JNI) verwendet wird.
• [C-0-3] MUSS mit jeder erforderlichen Bibliothek in der Liste unten quellcodekompatibel (d.h. headerkompatibel) und binärkompatibel (für die ABI) sein.

• [C-0-5] MUSS die vom Gerät unterstützte native Binärschnittstelle (ABI) über die Parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS und android.os.Build.SUPPORTED_64_BIT_ABIS genau angeben. Jeder Parameter ist eine durch Kommas getrennte Liste von ABIs, die vom bevorzugtesten zum am wenigsten bevorzugten ABI sortiert ist.

• [C-0-6] MUSS über die oben genannten Parameter eine Teilmenge der folgenden Liste von ABIs melden und DARF keine ABI melden, die nicht in der Liste enthalten ist.

  • armeabi (wird vom NDK nicht mehr als Ziel unterstützt)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64
  • riscv64

• [C-0-7] MÜSSEN alle folgenden Bibliotheken, die native APIs bereitstellen, für Apps mit nativem Code verfügbar sein:

  • libaaudio.so (native AAudio-Audiounterstützung)
  • libamidi.so (native MIDI-Unterstützung, wenn das Feature android.software.midi wie in Abschnitt 5.9 beschrieben beansprucht wird)
  • libandroid.so (Unterstützung nativer Android-Aktivitäten)
  • libc (C-Bibliothek)
  • libcamera2ndk.so
  • libdl (dynamischer Linker)
  • libEGL.so (native OpenGL-Oberflächenverwaltung)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (Android-Protokollierung)
  • libmediandk.so (Unterstützung für native Media-APIs)
  • libm (Mathematikbibliothek)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (Unterstützung für OpenMAX AL 1.0.1)
  • libOpenSLES.so (OpenSL ES 1.0.1-Audio-Unterstützung)
  • libRS.so
  • libstdc++ (minimale Unterstützung für C++)
  • libvulkan.so (Vulkan)
  • libz (Zlib-Komprimierung)
  • JNI-Schnittstelle

• [C-0-8] Die oben aufgeführten öffentlichen Funktionen für die nativen Bibliotheken dürfen NICHT hinzugefügt oder entfernt werden.

• [C-0-9] Zusätzliche Nicht-AOSP-Bibliotheken, die Drittanbieter-Apps direkt zur Verfügung gestellt werden, MÜSSEN in /vendor/etc/public.libraries.txt aufgeführt werden.

• [C-0-10] DÜRFEN keine anderen nativen Bibliotheken, die in AOSP als Systembibliotheken implementiert und bereitgestellt werden, für Drittanbieter-Apps mit API-Level 24 oder höher verfügbar gemacht werden, da sie reserviert sind.

• [C-0-11] MÜSSEN alle Funktionssymbole von OpenGL ES 3.1 und dem Android Extension Pack, wie im NDK definiert, über die libGLESv3.so-Bibliothek exportiert werden. Alle Symbole MÜSSEN vorhanden sein. In Abschnitt 7.1.4.1 werden die Anforderungen für die vollständige Implementierung der einzelnen entsprechenden Funktionen genauer beschrieben.

• [C-0-12] MUSS Funktionssymbole für die Kernfunktionssymbole von Vulkan 1.1 sowie die Erweiterungen VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 und VK_KHR_get_physical_device_properties2 über die libvulkan.so-Bibliothek exportieren. Alle Symbole MÜSSEN vorhanden sein. In Abschnitt 7.1.4.2 werden die Anforderungen für die vollständige Implementierung der einzelnen entsprechenden Funktionen genauer beschrieben.

• Sollte mit dem Quellcode und den Headerdateien erstellt werden, die im Upstream Open-Source-Projekt für Android verfügbar sind.

Beachten Sie, dass zukünftige Android-Versionen möglicherweise zusätzliche ABIs unterstützen.

3.3.2 Kompatibilität mit nativem 32-Bit-ARM-Code

Wenn Geräteimplementierungen die Unterstützung des armeabi-ABI melden, gilt Folgendes:

• [C-3-1] MUSS auch armeabi-v7a unterstützen und die Unterstützung melden, da armeabi nur zur Abwärtskompatibilität mit älteren Apps dient.

Wenn Geräteimplementierungen die Unterstützung der armeabi-v7a-ABI melden, gilt für Apps, die diese ABI verwenden:

• [C-2-1] MUSS die folgenden Zeilen in /proc/cpuinfo enthalten und SOLLTE die Werte auf demselben Gerät nicht ändern, auch wenn sie von anderen ABIs gelesen werden.

  • Features:, gefolgt von einer Liste aller optionalen ARMv7-CPU-Funktionen, die vom Gerät unterstützt werden.
  • CPU architecture:, gefolgt von einer Ganzzahl, die die höchste unterstützte ARM-Architektur des Geräts beschreibt (z.B. „8“ für ARMv8-Geräte).

• [C-2-2] Die folgenden Vorgänge MÜSSEN immer verfügbar sein, auch wenn die ABI auf einer ARMv8-Architektur implementiert ist, entweder durch native CPU-Unterstützung oder durch Software-Emulation:

  • Anleitungen für SWP und SWPB
  • CP15ISB-, CP15DSB- und CP15DMB-Barrierevorgänge.

• [C-2-3] MUSS die Advanced SIMD-Erweiterung (auch NEON genannt) unterstützen.

3.4 Webkompatibilität

3.4.1. WebView-Kompatibilität

Wenn Geräteimplementierungen eine vollständige Implementierung der android.webkit.Webview API bieten, gilt Folgendes:

• [C-1-1] MÜSSEN android.software.webview melden.

• [C-1-2] MUSS den Chromium-Projekt-Build aus dem Upstream Open-Source-Projekt für Android im Android 17-Branch für die Implementierung der android.webkit.WebView-API verwenden.

• [C-1-3] Der User-Agent-String, der von der WebView für Apps mit SDK-Zielversion 35 und niedriger gemeldet wird, MUSS das folgende Format haben:

  Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • Der Wert des $(VERSION)-Strings MUSS mit dem Wert für android.os.Build.VERSION.RELEASE übereinstimmen.

  • Der String $(MODEL) DARF leer sein. Wenn er nicht leer ist, MUSS er denselben Wert wie android.os.Build.MODEL haben.

  • „Build/$(BUILD)“ KANN weggelassen werden. Wenn es jedoch vorhanden ist, MUSS der $(BUILD)-String mit dem Wert für android.os.Build.ID übereinstimmen.

  • Der Wert des $(CHROMIUM_VER)-Strings MUSS die Version von Chromium im Upstream-Open-Source-Projekt für Android sein.

  • Bei Geräteimplementierungen KANN „Mobile“ im User-Agent-String weggelassen werden.

• Die WebView-Komponente SOLLTE so viele HTML5-Funktionen wie möglich unterstützen und, falls sie die Funktion unterstützt, der HTML5-Spezifikation entsprechen.

• [C-1-4] Die bereitgestellten Inhalte oder Inhalte der Remote-URL MÜSSEN in einem Prozess gerendert werden, der sich von der Anwendung unterscheidet, die die WebView instanziiert. Der separate Renderer-Prozess MUSS mit geringeren Berechtigungen ausgeführt werden, eine separate Nutzer-ID haben, keinen Zugriff auf das Datenverzeichnis der App und keinen direkten Netzwerkzugriff haben und nur über Binder auf die minimal erforderlichen Systemdienste zugreifen können. Die AOSP-Implementierung von WebView erfüllt diese Anforderung.

Beachten Sie, dass Geräteimplementierungen, die 32 Bit haben oder das Funktions-Flag android.hardware.ram.low deklarieren, von C-1-3 ausgenommen sind.

3.4.2. Browserkompatibilität

Wenn Geräteimplementierungen eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten, gilt Folgendes:

• [C-1-1] MUSS jede dieser APIs unterstützen, die mit HTML5 verknüpft sind:

  • Anwendungscache/Offlinebetrieb
  • <video>-Tag
  • Standortbestimmung

• [C-1-2] MUSS die HTML5-/W3C-Web Storage API unterstützen und SOLLTE die HTML5-/W3C-IndexedDB API unterstützen. Da die Gremien für Webentwicklungsstandards auf IndexedDB anstelle von Web Storage umstellen, wird IndexedDB voraussichtlich in einer zukünftigen Version von Android eine erforderliche Komponente sein.

• MAY ship a custom user agent string in the standalone Browser application.

• Die eigenständige Browseranwendung (unabhängig davon, ob sie auf der Upstream-WebKit-Browseranwendung oder einem Ersatz von Drittanbietern basiert) SOLLTE so viel HTML5 wie möglich unterstützen.

Wenn Geräteimplementierungen jedoch keine eigenständige Browseranwendung enthalten, gilt Folgendes:

• [C-2-1] MUSS weiterhin die öffentlichen Intent-Muster unterstützen, wie in Abschnitt 3.2.3.1 beschrieben.

3.5 Verhaltenskompatibilität der API

Geräteimplementierungen:

• [C-0-9] MUSS dafür sorgen, dass die API-Verhaltenskompatibilität für alle installierten Apps angewendet wird, sofern sie nicht wie in Abschnitt 3.5.1 beschrieben eingeschränkt sind.
• [C-0-10] Es DARF NICHT der Ansatz der Zulassungsliste implementiert werden, der die Verhaltenskompatibilität der API nur für Apps gewährleistet, die von Geräteimplementierern ausgewählt werden.

Das Verhalten der einzelnen API-Typen (verwaltet, Soft, nativ und Web) muss mit der bevorzugten Implementierung des Upstream-Open-Source-Projekts für Android übereinstimmen. Hier einige konkrete Beispiele:

• [C-0-1] Geräte DÜRFEN das Verhalten oder die Semantik einer Standard-Intention NICHT ändern.
• [C-0-2] Geräte DÜRFEN den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, ContentProvider usw.) NICHT ändern.
• [C-0-3] Geräte DÜRFEN die Semantik einer Standardberechtigung NICHT ändern.
• Geräte DÜRFEN die für Hintergrundanwendungen geltenden Einschränkungen NICHT ändern. Konkret für Hintergrund-Apps:
  • [C-0-4] MÜSSEN die Ausführung von Callbacks beenden, die von der App registriert wurden, um Ausgaben von GnssMeasurement und GnssNavigationMessage zu empfangen.
  • [C-0-5] Sie MÜSSEN die Häufigkeit von Aktualisierungen, die der App über die API-Klasse LocationManager oder die Methode WifiManager.startScan() bereitgestellt werden, begrenzen.
  • [C-0-6] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, DÜRFEN keine Broadcast-Empfänger für die impliziten Broadcasts von Standard-Android-Intents im Manifest der App registriert werden, es sei denn, für den Broadcast-Intent ist eine "signature"- oder "signatureOrSystem"-protectionLevel-Berechtigung erforderlich oder er steht auf der Ausnahmeliste.
  • [C-0-7] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN die Hintergrunddienste der App beendet werden, so als hätte die App die Methode stopSelf() der Dienste aufgerufen, es sei denn, die App wird auf eine temporäre Zulassungsliste gesetzt, um eine für den Nutzer sichtbare Aufgabe auszuführen.
  • [C-0-8] Wenn die App auf API‑Level 25 oder höher ausgerichtet ist, MÜSSEN die von der App gehaltenen Wakelocks freigegeben werden.
• [C-0-11] Geräte MÜSSEN die folgenden Sicherheitsanbieter als die ersten sieben Arraywerte aus der Methode Security.getProviders() zurückgeben, in der angegebenen Reihenfolge und mit den angegebenen Namen (wie von Provider.getName() zurückgegeben) und Klassen, es sei denn, die App hat die Liste über insertProviderAt() oder removeProvider() geändert. Geräte DÜRFEN nach der unten angegebenen Liste zusätzlicher Anbieter zurückgeben.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC: com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

Die obige Liste ist nicht vollständig. Die Compatibility Test Suite (CTS) testet wichtige Teile der Plattform auf Verhaltenskompatibilität, aber nicht alle. Der Implementierer ist dafür verantwortlich, die Verhaltenskompatibilität mit dem Open-Source-Projekt für Android sicherzustellen. Aus diesem Grund SOLLTEN Gerätehersteller nach Möglichkeit den über das Open-Source-Projekt für Android verfügbaren Quellcode verwenden, anstatt wichtige Teile des Systems neu zu implementieren.

3.5.1. Anwendungseinschränkung

Wenn in Geräteimplementierungen ein proprietärer Mechanismus zum Einschränken von Apps implementiert wird (z.B. durch Ändern oder Einschränken von API-Verhaltensweisen, die im SDK beschrieben sind) und dieser Mechanismus restriktiver ist als der App-Standby-Bucket für eingeschränkte Apps, gilt Folgendes:

• [C-1-1] Der Nutzer MUSS die Liste der eingeschränkten Apps sehen können.
• [C-1-2] Der Nutzer muss die Möglichkeit haben, alle diese proprietären Einschränkungen für jede App zu aktivieren bzw. zu deaktivieren.

• [C-1-3] Diese proprietären Einschränkungen DÜRFEN NICHT automatisch ohne Nachweis eines schlechten Systemzustands angewendet werden. Sie DÜRFEN jedoch auf Apps angewendet werden, wenn ein schlechter Systemzustand wie blockierte Wakelocks, Dienste mit langer Laufzeit und andere Kriterien erkannt werden. Die Kriterien KÖNNEN von Geräteimplementierern festgelegt werden, MÜSSEN sich aber auf die Auswirkungen der App auf die Systemintegrität beziehen. Andere Kriterien, die nicht ausschließlich mit dem Systemzustand zusammenhängen, z. B. die mangelnde Beliebtheit der App auf dem Markt, DÜRFEN NICHT als Kriterien verwendet werden.

• [C-1-4] Diese proprietären Einschränkungen dürfen für Apps NICHT automatisch angewendet werden, wenn ein Nutzer App-Einschränkungen manuell deaktiviert hat. Es DARF dem Nutzer jedoch vorgeschlagen werden, diese proprietären Einschränkungen anzuwenden.

• [C-1-5] MUSS Nutzer darüber informieren, wenn diese proprietären Einschränkungen automatisch auf eine App angewendet werden. Diese Informationen MÜSSEN innerhalb von 24 Stunden vor der Anwendung dieser proprietären Einschränkungen bereitgestellt werden.

• [C-1-6] MUSS für alle API-Aufrufe einer App „true“ für die Methode ActivityManager.isBackgroundRestricted() zurückgeben.

• [C-1-7] Die oberste App im Vordergrund, die vom Nutzer explizit verwendet wird, DARF NICHT eingeschränkt werden.

• [C-1-8] Diese proprietären Einschränkungen MÜSSEN für eine App aufgehoben werden, sobald ein Nutzer die App explizit verwendet und sie zur obersten Vordergrundanwendung macht.

• [C-1-10] Es MUSS ein öffentliches und eindeutiges Dokument oder eine Website bereitgestellt werden, in dem/der beschrieben wird, wie proprietäre Einschränkungen angewendet werden. Dieses Dokument oder diese Website MUSS über die Android SDK-Dokumente verlinkt werden können und Folgendes enthalten:

  • Auslösende Bedingungen für proprietäre Einschränkungen.
  • Was und wie eine App eingeschränkt werden kann.
  • Wie eine App von solchen Einschränkungen ausgenommen werden kann.
  • Wie eine App eine Ausnahme von den proprietären Einschränkungen beantragen kann, wenn sie eine solche Ausnahme für Apps unterstützt, die der Nutzer installieren kann.

Wenn eine App auf dem Gerät vorinstalliert ist und noch nie von einem Nutzer über einen Zeitraum von mehr als 30 Tagen verwendet wurde, gelten die Ausnahmen [C-1-3] und [C-1-5].

Wenn Geräteimplementierungen die in AOSP implementierten App-Einschränkungen erweitern, gilt Folgendes:

• [C-2-1]MÜSSEN der in diesem Dokument beschriebenen Implementierung folgen.

3.5.2. App-Ruhezustand

Wenn Geräteimplementierungen den in AOSP enthaltenen App-Ruhezustand enthalten oder die in AOSP enthaltene Funktion erweitern, müssen sie:

• [C-1-1] MUSS alle Anforderungen in Abschnitt 3.5.1 erfüllen, mit Ausnahme von [C-1-6] und [C-1-3].
• [C-1-2] Die Einschränkung für die App darf nur dann auf einen Nutzer angewendet werden, wenn es Beweise dafür gibt, dass der Nutzer die App seit einiger Zeit nicht mehr verwendet hat. Es wird DRINGEND EMPFOHLEN, dass dieser Zeitraum mindestens einen Monat beträgt. Die Nutzung MUSS entweder durch eine explizite Nutzerinteraktion über die API UsageStats#getLastTimeVisible() oder durch etwas definiert werden, das dazu führt, dass eine App den Status „erzwungen beendet“ verlässt, einschließlich Dienstbindungen, Contentanbieterbindungen, explizite Broadcasts usw., die von einer neuen API UsageStats#getLastTimeAnyComponentUsed() erfasst werden.
• [C-1-3] Einschränkungen, die alle Gerätenutzer betreffen, DÜRFEN NUR angewendet werden, wenn es Hinweise darauf gibt, dass das Paket seit einiger Zeit von KEINEM Nutzer verwendet wurde. Es wird DRINGEND EMPFOHLEN, dass dieser Zeitraum mindestens einen Monat beträgt.
• [C-1-4] Die App DARF NICHT so gerendert werden, dass sie nicht mehr auf Aktivitäts-Intents, Dienstbindungen, Anfragen von Contentanbietern oder explizite Broadcasts reagieren kann.

Der App-Ruhezustand in AOSP erfüllt die oben genannten Anforderungen.

3.6 API-Namespaces

Android folgt den von der Programmiersprache Java definierten Konventionen für Paket- und Klassen-Namespaces. Um die Kompatibilität mit Drittanbieteranwendungen zu gewährleisten, DÜRFEN Gerätehersteller keine verbotenen Änderungen (siehe unten) an diesen Paket-Namespaces vornehmen:

• java.*
• javax.*
• sun.*
• android.*
• androidx.*
• com.android.*

Das bedeutet:

• [C-0-1] Öffentlich zugängliche APIs auf der Android-Plattform DÜRFEN NICHT geändert werden, indem Methoden- oder Klassensignaturen geändert oder Klassen oder Klassenfelder entfernt werden.
• [C-0-2] Es DÜRFEN KEINE öffentlich zugänglichen Elemente (z. B. Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) oder Test- oder System-APIs zu den APIs in den oben genannten Namespaces hinzugefügt werden. Ein „öffentlich zugängliches Element“ ist jedes Konstrukt, das nicht mit dem Marker „@hide“ versehen ist, wie er im Upstream-Android-Quellcode verwendet wird.

Gerätehersteller DÜRFEN die zugrunde liegende Implementierung der APIs ändern, aber solche Änderungen:

• [C-0-3] Das angegebene Verhalten und die Java-Sprachsignatur öffentlich verfügbarer APIs dürfen NICHT beeinträchtigt werden.
• [C-0-4] DARF NICHT beworben oder Entwicklern auf andere Weise präsentiert werden.

Gerätehersteller DÜRFEN jedoch benutzerdefinierte APIs außerhalb des Standard-Android-Namespace hinzufügen. Die benutzerdefinierten APIs müssen jedoch folgende Anforderungen erfüllen:

• [C-0-5] DARF NICHT in einem Namespace enthalten sein, der einer anderen Organisation gehört oder sich auf eine andere Organisation bezieht. Gerätehersteller DÜRFEN beispielsweise KEINE APIs zum Namespace com.google.* oder einem ähnlichen Namespace hinzufügen. Das ist nur Google erlaubt. Ebenso DÜRFEN Google KEINE APIs zu den Namespaces anderer Unternehmen hinzufügen.
• [C-0-6] MUSS in einer gemeinsam genutzten Android-Bibliothek verpackt werden, damit nur Apps, die sie explizit verwenden (über den Mechanismus <uses-library>), von der erhöhten Arbeitsspeichernutzung solcher APIs betroffen sind.

Gerätehersteller DÜRFEN benutzerdefinierte APIs in nativen Sprachen außerhalb der NDK-APIs hinzufügen. Die benutzerdefinierten APIs:

• [C-1-1] DARF NICHT in einer NDK-Bibliothek oder einer Bibliothek enthalten sein, die einer anderen Organisation gehört, wie hier beschrieben.

Wenn ein Geräteimplementierer vorschlägt, einen der oben genannten Paket-Namespaces zu verbessern (z. B. durch Hinzufügen nützlicher neuer Funktionen zu einer vorhandenen API oder durch Hinzufügen einer neuen API), SOLLTE der Implementierer source.android.com aufrufen und den Prozess zum Beitragen von Änderungen und Code gemäß den Informationen auf dieser Website starten.

Beachten Sie, dass die oben genannten Einschränkungen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java entsprechen. In diesem Abschnitt sollen diese Konventionen lediglich verstärkt und durch die Aufnahme in diese Kompatibilitätsdefinition verbindlich gemacht werden.

3.7 Laufzeitkompatibilität

Geräteimplementierungen:

• [C-0-1] MÜSSEN das vollständige Dalvik Executable-Format (DEX) und die Dalvik-Bytecode-Spezifikation und -Semantik unterstützen.

• [C-0-2] MÜSSEN Dalvik-Laufzeitumgebungen so konfiguriert werden, dass Speicher gemäß der Upstream-Android-Plattform und wie in der folgenden Tabelle angegeben zugewiesen wird. (Siehe Abschnitt 7.1.1 für Definitionen von Bildschirmgröße und ‑dichte.)

• Sollte Android RunTime (ART), die Referenz-Upstream-Implementierung des Dalvik Executable-Formats, und das Paketverwaltungssystem der Referenzimplementierung verwenden.

• Es SOLLTEN Fuzz-Tests in verschiedenen Ausführungsmodi und Zielarchitekturen ausgeführt werden, um die Stabilität der Laufzeit zu gewährleisten. Weitere Informationen finden Sie auf der Website des Open-Source-Projekts für Android unter JFuzz und DexFuzz.

Die unten angegebenen Arbeitsspeicherwerte sind Mindestwerte. Geräteimplementierungen KÖNNEN mehr Arbeitsspeicher pro Anwendung zuweisen.

Bildschirmlayout	Bildschirmdichte	Mindestspeicher für die App
Android-Uhr	120 dpi (ldpi)	32 MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)	36 MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	48 MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56 MB
	420 dpi (420dpi)	64 MB
	480 dpi (xxhdpi)	88 MB
	560 dpi (560dpi)	112 MB
	640 dpi (xxxhdpi)	154 MB
Klein/Normal	120 dpi (ldpi)	32 MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48 MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80 MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96 MB
	420 dpi (420dpi)	112 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi (560dpi)	192 MB
	640 dpi (xxxhdpi)	256 MB
Groß	120 dpi (ldpi)	32 MB
	140 dpi (140dpi)	48 MB
	160 dpi (mdpi)
	180 dpi (180dpi)	80 MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	96 MB
	320 dpi (xhdpi)	128 MB
	360 dpi (360dpi)	160 MB
	400 dpi (400dpi)	192 MB
	420 dpi (420dpi)	228 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi (560dpi)	384 MB
	640 dpi (xxxhdpi)	512 MB
xlarge	120 dpi (ldpi)	48 MB
	140 dpi (140dpi)	80 MB
	160 dpi (mdpi)
	180 dpi (180dpi)	96 MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	144 MB
	320 dpi (xhdpi)	192 MB
	360 dpi (360dpi)	240 MB
	400 dpi (400dpi)	288 MB
	420 dpi (420dpi)	336 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi (560dpi)	576 MB
	640 dpi (xxxhdpi)	768 MB

3.8. Kompatibilität der Benutzeroberfläche

3.8.1. Launcher (Startbildschirm)

Android enthält eine Launcher-Anwendung (Startbildschirm) und unterstützt Drittanbieteranwendungen, die den Geräte-Launcher (Startbildschirm) ersetzen.

Wenn Geräteimplementierungen es Drittanbieteranwendungen ermöglichen, den Startbildschirm des Geräts zu ersetzen, gilt Folgendes:

• [C-1-1] MUSS die Plattformfunktion android.software.home_screen deklarieren.

• [C-1-2] MUSS das AdaptiveIconDrawable-Objekt zurückgeben, wenn die Drittanbieteranwendung das <adaptive-icon>-Tag verwendet, um ihr Symbol bereitzustellen, und die PackageManager-Methoden zum Abrufen von Symbolen aufgerufen werden.

Wenn Geräteimplementierungen einen Standard-Launcher enthalten, der das Anpinnen von Verknüpfungen in der App unterstützt, gilt Folgendes:

• [C-2-1] MÜSSEN true für ShortcutManager.isRequestPinShortcutSupported() melden.

• [C-2-2] Es MUSS eine Benachrichtigung für den Nutzer angezeigt werden, in der er gefragt wird, ob er eine von Apps über die API-Methode ShortcutManager.requestPinShortcut() angeforderte Verknüpfung hinzufügen möchte.

• [C-2-3] MUSS angepinnte Verknüpfungen sowie dynamische und statische Verknüpfungen unterstützen, wie auf der Seite „App-Verknüpfungen“ dokumentiert.

Wenn Geräteimplementierungen das Anpinnen von Verknüpfungen in Apps nicht unterstützen, gilt Folgendes:

• [C-3-1] MÜSSEN false für ShortcutManager.isRequestPinShortcutSupported() melden.

Wenn in Geräteimplementierungen ein Standard-Launcher implementiert ist, der über die ShortcutManager-API schnellen Zugriff auf die zusätzlichen Verknüpfungen bietet, die von Drittanbieter-Apps bereitgestellt werden, gilt Folgendes:

• [C-4-1] MUSS alle dokumentierten Shortcut-Funktionen unterstützen (z.B. statische und dynamische Shortcuts, das Anpinnen von Shortcuts) und die APIs der ShortcutManager-API-Klasse vollständig implementieren.

Wenn Geräteimplementierungen eine Standard-Launcher-App enthalten, in der Badges für die App-Symbole angezeigt werden, gilt Folgendes:

• [C-5-1] MUSS die API-Methode NotificationChannel.setShowBadge() respektieren. Mit anderen Worten: Zeigen Sie eine visuelle Aufforderung an, die mit dem App-Symbol verknüpft ist, wenn der Wert auf true festgelegt ist. Zeigen Sie kein App-Symbol-Badging-Schema an, wenn für alle Benachrichtigungschannels der App der Wert false festgelegt ist.

• MAY überschreibt die App-Symbol-Badges mit dem eigenen Badging-Schema, wenn Drittanbieteranwendungen die Unterstützung des eigenen Badging-Schemas durch die Verwendung eigener APIs angeben, SHOULD verwendet jedoch die Ressourcen und Werte, die über die in dem SDK beschriebenen Benachrichtigungs-Badges-APIs bereitgestellt werden, z. B. die Notification.Builder.setNumber()- und die Notification.Builder.setBadgeIconType()-API.

Wenn Geräteimplementierungen monochrome Symbole unterstützen, gilt für diese Symbole Folgendes:

• [C-6-1] MÜSSEN nur verwendet werden, wenn ein Nutzer sie explizit aktiviert (z.B. über die Einstellungen oder das Menü zur Auswahl des Hintergrundbilds).

3.8.2. Widgets

Android unterstützt App-Widgets von Drittanbietern, indem ein Komponententyp und eine entsprechende API und ein entsprechender Lebenszyklus definiert werden, mit denen Anwendungen ein AppWidget für den Endnutzer bereitstellen können.

Wenn Geräteimplementierungen App-Widgets von Drittanbietern unterstützen, gilt Folgendes:

• MAY unterstützt App-Widgets auf dem Sperrbildschirm.

Wenn Geräteimplementierungen App-Widgets von Drittanbietern und das Anpinnen von Verknüpfungen in Apps unterstützen, gilt Folgendes:

• [C-2-1] MÜSSEN true für AppWidgetManager.html.isRequestPinAppWidgetSupported() melden.

• [C-2-2] Es MUSS eine Benachrichtigung für den Nutzer angezeigt werden, in der er gefragt wird, ob er eine von Apps über die API-Methode AppWidgetManager.requestPinAppWidget() angeforderte Verknüpfung hinzufügen möchte.

3.8.3. Benachrichtigungen

Android umfasst die APIs Notification und NotificationManager, mit denen Drittanbieter-App-Entwickler Nutzer über wichtige Ereignisse benachrichtigen und die Aufmerksamkeit der Nutzer mithilfe der Hardwarekomponenten (z.B. Ton, Vibration und Licht) und Softwarefunktionen (z.B. Benachrichtigungsleiste, Systemleiste) des Geräts auf sich ziehen können.

3.8.3.1. Darstellung von Benachrichtigungen

Wenn Geräteimplementierungen es Drittanbieter-Apps ermöglichen, Nutzer über wichtige Ereignisse zu benachrichtigen, gilt Folgendes:

• [C-1-1] MUSS Benachrichtigungen unterstützen, die Hardwarefunktionen verwenden, wie in der SDK-Dokumentation beschrieben und soweit dies mit der Hardware des Geräts möglich ist. Wenn eine Geräteimplementierung beispielsweise einen Vibrator enthält, MUSS sie die Vibrations-APIs korrekt implementieren. Wenn in einer Geräteimplementierung Hardware fehlt, MÜSSEN die entsprechenden APIs als No-Ops implementiert werden. Dieses Verhalten wird in Abschnitt 7 genauer beschrieben.

• [C-1-2] ALLE in den APIs oder im Symbol-Styleguide für die Status-/Systemleiste bereitgestellten Ressourcen (Symbole, Animationsdateien usw.) MÜSSEN korrekt gerendert werden. Es DARF jedoch eine alternative Nutzererfahrung für Benachrichtigungen als die von der Android Open Source-Referenzimplementierung bereitgestellte angeboten werden.

• [C-1-3] MUSS das in den APIs beschriebene Verhalten zum Aktualisieren, Entfernen und Gruppieren von Benachrichtigungen korrekt berücksichtigen und implementieren.

• [C-1-4] MUSS das vollständige Verhalten der NotificationChannel-API bereitstellen, das im SDK dokumentiert ist.

• [C-1-5] Es MUSS eine Möglichkeit für Nutzer geben, Benachrichtigungen einer bestimmten Drittanbieter-App auf Kanal- und App-Paketebene zu blockieren und zu ändern.

• [C-1-6] MUSS auch eine Möglichkeit für Nutzer bieten, gelöschte Benachrichtigungskanäle aufzurufen.

• [C-1-7] ALLE über Notification.MessagingStyle bereitgestellten Ressourcen (Bilder, Sticker, Symbole usw.) MÜSSEN zusammen mit dem Benachrichtigungstext ohne zusätzliche Nutzerinteraktion korrekt gerendert werden. Beispielsweise MÜSSEN alle Ressourcen, einschließlich der über android.app.Person bereitgestellten Symbole, in einer Gruppenunterhaltung angezeigt werden, die über setGroupConversation festgelegt wird.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, dem Nutzer die Möglichkeit zu geben, die Benachrichtigungen zu steuern, die Apps mit der Berechtigung „Benachrichtigungs-Listener“ angezeigt werden. Die Granularität MUSS so sein, dass der Nutzer für jeden solchen Benachrichtigungs-Listener steuern kann, welche Benachrichtigungstypen an diesen Listener weitergeleitet werden. Die Typen MÜSSEN „Unterhaltungen“, „Benachrichtigungen“, „Lautlos“ und „Wichtige fortlaufende“ Benachrichtigungen enthalten.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, Apps anzugeben, die keine Benachrichtigungen an einen bestimmten Benachrichtigungs-Listener senden dürfen.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, automatisch eine Nutzeroption zum Blockieren der Benachrichtigung einer bestimmten Drittanbieter-App pro Kanal und App-Paketebene anzuzeigen, nachdem der Nutzer diese Benachrichtigung mehrmals geschlossen hat.

• Sollte umfassende Benachrichtigungen unterstützen.

• Sollte einige Benachrichtigungen mit höherer Priorität als Vorabbenachrichtigungen präsentieren.

• Es SOLLTE eine Möglichkeit für Nutzer geben, Benachrichtigungen zurückzustellen.

• MAY kann nur die Sichtbarkeit und den Zeitpunkt verwalten, zu dem Drittanbieter-Apps Nutzer über wichtige Ereignisse benachrichtigen können, um Sicherheitsprobleme wie Ablenkung des Fahrers zu minimieren.

Android 11 bietet Unterstützung für Benachrichtigungen zu Unterhaltungen, die MessagingStyle verwenden und eine veröffentlichte People-Shortcut-ID enthalten.

Geräteimplementierungen:

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, conversation notifications vor Benachrichtigungen, die nicht mit Unterhaltungen zusammenhängen, zu gruppieren und anzuzeigen. Ausgenommen sind Benachrichtigungen zu laufenden Vordergrunddiensten und importance:high-Benachrichtigungen.

Wenn Geräteimplementierungen conversation notifications unterstützen und die App die erforderlichen Daten für bubbles bereitstellt, gilt Folgendes:

• [C-SR-5] Es wird DRINGEND EMPFOHLEN, diese Unterhaltung als Blase anzuzeigen. Die AOSP-Implementierung erfüllt diese Anforderungen mit der standardmäßigen System-UI, den Einstellungen und dem Launcher.

Wenn Geräteimplementierungen Rich Notifications unterstützen, gilt Folgendes:

• [C-2-1] Für die präsentierten Ressourcenelemente MUSS die Notification.Style-API-Klasse und ihre Unterklassen verwendet werden.

• Jedes in der API-Klasse Notification.Style und ihren Unterklassen definierte Ressourcenelement (z.B. Symbol, Titel und Zusammenfassungstext) SOLLTE dargestellt werden.

Pop-up-Benachrichtigungen werden dem Nutzer unabhängig davon angezeigt, auf welcher Oberfläche er sich gerade befindet. Wenn Geräteimplementierungen Pop-up-Benachrichtigungen unterstützen, gilt Folgendes:

• [C-3-1] Bei der Darstellung von wichtigen Benachrichtigungen muss die Ansicht und die Ressourcen für wichtige Benachrichtigungen verwendet werden, die in der API-Klasse Notification.Builder beschrieben sind.

• [C-3-2] Die über Notification.Builder.addAction() bereitgestellten Aktionen MÜSSEN zusammen mit dem Benachrichtigungsinhalt ohne zusätzliche Nutzerinteraktion wie im SDK beschrieben angezeigt werden.

3.8.3.2. Mitteilungs-Listener-Dienst

Android enthält die NotificationListenerService-APIs, mit denen Apps (sofern vom Nutzer explizit aktiviert) eine Kopie aller Benachrichtigungen erhalten können, sobald sie gesendet oder aktualisiert werden.

Geräteimplementierungen:

• [C-0-1] MUSS Benachrichtigungen vollständig und zeitnah für alle installierten und vom Nutzer aktivierten Listener-Dienste aktualisieren, einschließlich aller Metadaten, die an das Notification-Objekt angehängt sind.

• [C-0-2] MUSS den API-Aufruf snoozeNotification() berücksichtigen, die Benachrichtigung schließen und nach dem im API-Aufruf festgelegten Zeitraum einen Callback ausführen.

Wenn Geräteimplementierungen eine Möglichkeit zum Zurückstellen von Benachrichtigungen bieten, müssen sie:

• [C-1-1] MUSS den Status von pausierten Benachrichtigungen über die Standard-APIs wie NotificationListenerService.getSnoozedNotifications() korrekt widerspiegeln.

• [C-1-2] MUSS diese Nutzerfunktion zum Schlummern von Benachrichtigungen aus jeder installierten Drittanbieter-App zur Verfügung stellen, sofern sie nicht von persistenten/Vordergrunddiensten stammen.

3.8.3.3. „Bitte nicht stören“ / Prioritätsmodus

Wenn Geräteimplementierungen die Funktion „Bitte nicht stören“ (auch „Prioritätsmodus“ genannt) unterstützen, gilt Folgendes:

• [C-1-1] MUSS: Wenn die Geräteimplementierung eine Möglichkeit für den Nutzer bietet, Drittanbieter-Apps den Zugriff auf die Konfiguration der Funktion „Bitte nicht stören“ zu gewähren oder zu verweigern, müssen die von Anwendungen erstellten Automatischen Regeln für „Bitte nicht stören“ neben den vom Nutzer erstellten und vordefinierten Regeln angezeigt werden.

• [C-1-3] MUSS die Werte suppressedVisualEffects berücksichtigen, die über NotificationManager.Policy übergeben werden. Wenn eine App eines der Flags SUPPRESSED_EFFECT_SCREEN_OFF oder SUPPRESSED_EFFECT_SCREEN_ON festgelegt hat, SOLLTE dem Nutzer im Menü „Bitte nicht stören“ angezeigt werden, dass die visuellen Effekte unterdrückt werden.

3.8.3.4. Schutz sensibler Benachrichtigungen

Zu vertraulichen Benachrichtigungsinformationen gehören Inhalte wie Einmalpasswörter, Einmalbestätigungscodes und ähnliche Authentifizierungs- oder Zurücksetzungscodes, die in Benachrichtigungen für Nutzer angezeigt werden können.

Wenn Geräteimplementierungen es Drittanbieter-Apps ermöglichen, Nutzer über wichtige Ereignisse zu benachrichtigen, gilt Folgendes:

• [C-1-1] SENSIBLE Benachrichtigungsinformationen DÜRFEN NICHT an Benachrichtigungs-Listener übergeben werden, es sei denn, der Listener-Dienst ist einer der folgenden:

  • Vom System signierte Apps mit einer uid < 10.000
  • System-UI
  • Muschel
  • Designierte Companion-Geräte-App (definiert durch CompanionDeviceManager)
  • Rolle SYSTEM_AUTOMOTIVE_PROJECTION
  • Rolle SYSTEM_NOTIFICATION_INTELLIGENCE
  • Rolle „Zuhause“

Die AOSP-Implementierung von NotificationAssistantServices erfüllt diese Anforderungen. Ein Beispiel finden Sie unter android.ext.services.notification.

3.8.4. Assist-APIs

Android enthält die Assist APIs, mit denen Anwendungen festlegen können, wie viele Informationen des aktuellen Kontexts mit dem Assistenten auf dem Gerät geteilt werden.

• [C-2-2] Durch die festgelegte Interaktion zum Starten der Assistenz-App gemäß Abschnitt 7.2.3 MUSS die vom Nutzer ausgewählte Assistenz-App gestartet werden, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die den ACTION_ASSIST-Intent verarbeitet.

3.8.5. Benachrichtigungen und Pop-up-Meldungen

Anwendungen können die Toast-API verwenden, um dem Endnutzer kurze, nicht modale Strings anzuzeigen, die nach kurzer Zeit wieder verschwinden. Mit der API für den Fenstertyp TYPE_APPLICATION_OVERLAY können Warnfenster als Overlay über anderen Apps angezeigt werden.

Wenn Geräteimplementierungen einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

• [C-1-1] Es MUSS eine Möglichkeit für Nutzer geben, zu verhindern, dass eine App Warnfenster mit TYPE_APPLICATION_OVERLAY anzeigt. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente in der Benachrichtigungsleiste.

• [C-1-2] MUSS die Toast API berücksichtigen und Toasts von Anwendungen für Endnutzer auf gut sichtbare Weise anzeigen.

3.8.6. Designs

Android bietet „Themes“ als Mechanismus, mit dem Anwendungen Stile für eine gesamte Aktivität oder Anwendung anwenden können.

Android enthält die Theme-Familien „Holo“ und „Material“ als eine Reihe definierter Stile, die von App-Entwicklern verwendet werden können, wenn sie das Holo-Theme-Look-and-Feel, wie im Android SDK definiert, verwenden möchten.

Wenn Geräteimplementierungen einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

• [C-1-1] DÜRFEN NICHT die Attribute des Holo-Designs ändern, die für Anwendungen verfügbar sind.

• [C-1-2] MUSS die Theme-Familie „Material“ unterstützen und DARF KEINE der Material-Theme-Attribute oder die für Anwendungen bereitgestellten Assets ändern.

• [C-1-3] Die Schriftfamilie „sans-serif“ MUSS entweder für die von Roboto unterstützten Sprachen auf Roboto Version 2.x festgelegt werden oder es MUSS eine Möglichkeit für Nutzer geben, die für die Schriftfamilie „sans-serif“ verwendete Schriftart für die von Roboto unterstützten Sprachen in Roboto Version 2.x zu ändern.

• [C-1-4] MUSS dynamische Farbtonpaletten gemäß der AOSP-Dokumentation von Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES generieren (siehe android.theme.customization.system_palette und android.theme.customization.theme_style).

• [C-1-5] MUSS dynamische Farbtonpaletten mit den in der Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES-Dokumentation aufgeführten Farbschemastilen (siehe android.theme.customization.theme_styles) generieren, nämlich TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD und MONOCHROMATIC.

  „Quellfarbe“ zum Generieren dynamischer Farbtonpaletten, wenn sie mit android.theme.customization.system_palette gesendet wird (wie in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES beschrieben).

• [C-1-6] MUSS einen CAM16-Chroma-Wert von mindestens 5 haben.

  • Sollte über com.android.systemui.monet.ColorScheme#getSeedColors aus dem Hintergrundbild abgeleitet werden. Diese API bietet mehrere gültige Quellfarben, aus denen eine ausgewählt werden kann.

  • Sollte der Wert 0xFF1B6EF3 verwendet werden, wenn keine der angegebenen Farben die oben genannte Anforderung an die Quellfarbe erfüllt.

Android enthält auch die Designfamilie „Gerätestandard“ als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Erscheinungsbild des vom Geräteimplementierer definierten Gerätedesigns übernehmen möchten.

• Bei Geräteimplementierungen KÖNNEN die für Anwendungen verfügbaren Attribute des Standarddesigns des Geräts geändert werden.

Android unterstützt ein Variantenthema mit durchscheinenden Systemleisten, sodass App-Entwickler den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten füllen können. Damit Entwickler in dieser Konfiguration eine einheitliche Umgebung haben, ist es wichtig, dass der Stil des Symbols in der Statusleiste auf verschiedenen Geräteimplementierungen beibehalten wird.

Wenn Geräteimplementierungen eine Systemstatusleiste enthalten, gilt Folgendes:

• [C-2-1] Für Systemstatussymbole (z. B. Signalstärke und Akkustand) und Benachrichtigungen, die vom System ausgegeben werden, MUSS Weiß verwendet werden, es sei denn, das Symbol weist auf einen problematischen Status hin oder eine App fordert eine helle Statusleiste mit dem Flag WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS an.

• [C-2-2] Android-Geräteimplementierungen MÜSSEN die Farbe der Systemstatussymbole in Schwarz ändern (weitere Informationen finden Sie unter R.style), wenn eine App eine helle Statusleiste anfordert.

3.8.7. Live-Hintergründe

Android definiert einen Komponententyp und eine entsprechende API und einen entsprechenden Lebenszyklus, mit denen Anwendungen dem Endnutzer ein oder mehrere Live-Hintergründe zur Verfügung stellen können. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabefunktionen, die als Hintergrund hinter anderen Anwendungen angezeigt werden.

Hardware gilt als geeignet für die zuverlässige Ausführung von Live-Hintergründen, wenn sie alle Live-Hintergründe ohne Einschränkungen der Funktionalität mit einer angemessenen Framerate und ohne negative Auswirkungen auf andere Anwendungen ausführen kann. Wenn Einschränkungen in der Hardware dazu führen, dass Hintergrundbilder und/oder Anwendungen abstürzen, nicht richtig funktionieren, übermäßig viel CPU- oder Akkuleistung verbrauchen oder mit einer unannehmbar niedrigen Framerate ausgeführt werden, gilt die Hardware als nicht geeignet für Live-Hintergrundbilder. Einige Live-Hintergründe verwenden beispielsweise einen OpenGL 2.0- oder 3.x-Kontext, um ihre Inhalte zu rendern. Live-Hintergründe laufen nicht zuverlässig auf Hardware, die mehrere OpenGL-Kontexte nicht unterstützt, da die Verwendung eines OpenGL-Kontexts durch den Live-Hintergrund mit anderen Anwendungen, die ebenfalls einen OpenGL-Kontext verwenden, in Konflikt geraten kann.

• Geräteimplementierungen, auf denen Live-Hintergründe wie oben beschrieben zuverlässig ausgeführt werden können, SOLLTEN Live-Hintergründe implementieren.

Wenn Geräteimplementierungen Live-Hintergründe implementieren, gilt Folgendes:

• [C-1-1] MÜSSEN das Plattform-Funktions-Flag android.software.live_wallpaper melden.

3.8.8. Aktivitätswechsel

Der Upstream-Android-Quellcode enthält den Übersichtsbildschirm, eine Benutzeroberfläche auf Systemebene für den Aufgabenwechsel und die Anzeige von zuletzt aufgerufenen Aktivitäten und Aufgaben mithilfe eines Miniaturbilds des grafischen Zustands der Anwendung zu dem Zeitpunkt, als der Nutzer die Anwendung zuletzt verlassen hat.

Bei Geräteimplementierungen, die den Navigationsschlüssel für die Funktion „Zuletzt verwendet“ enthalten, wie in Abschnitt 7.2.3 beschrieben, KANN die Benutzeroberfläche geändert werden.

Wenn Geräteimplementierungen, die die Navigationsschaltfläche für die Funktion „Letzte Apps“ enthalten, wie in Abschnitt 7.2.3 beschrieben, die Benutzeroberfläche ändern, gilt Folgendes:

• [C-1-1] Es MÜSSEN mindestens bis zu 7 angezeigte Aktivitäten unterstützt werden.

• Es SOLLTEN mindestens die Titel von vier Aktivitäten gleichzeitig angezeigt werden.

• Die Farbe der Hervorhebung, das Symbol und der Bildschirmtitel sollten in den letzten Aktionen angezeigt werden.

• Es SOLLTE eine Schließfunktion („x“) angezeigt werden, dies KANN jedoch verzögert werden, bis der Nutzer mit den Bildschirmen interagiert.

• Es SOLLTE einen Kurzbefehl geben, um einfach zur vorherigen Aktivität zu wechseln.

• SOLLTE die Schnellwechselaktion zwischen den beiden zuletzt verwendeten Apps auslösen, wenn zweimal auf die Taste für zuletzt verwendete Apps getippt wird.

• SOLLTE den Splitscreen-Multifenstermodus auslösen, sofern unterstützt, wenn die Taste für die Übersicht lange gedrückt wird.

• Möglicherweise werden zugehörige kürzlich angesehene Inhalte als Gruppe angezeigt, die sich gemeinsam bewegt.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die Upstream-Android-Benutzeroberfläche (oder eine ähnliche Miniaturbild-basierte Benutzeroberfläche) für den Übersichtsbildschirm zu verwenden.

3.8.9. Eingabeverwaltung

Android bietet Unterstützung für die Eingabeverwaltung und für IME-Apps von Drittanbietern.

Wenn Geräteimplementierungen es Nutzern ermöglichen, Eingabemethoden von Drittanbietern auf dem Gerät zu verwenden, gilt Folgendes:

• [C-1-1] MUSS die Plattformfunktion android.software.input_methods deklarieren und IME-APIs gemäß der Android SDK-Dokumentation unterstützen.

3.8.10. Mediensteuerung auf dem Sperrbildschirm

Die Remote Control Client API ist ab Android 5.0 zugunsten der Media Notification Template (Benachrichtigungsvorlage für Medien) veraltet. Diese ermöglicht es Medienanwendungen, Wiedergabesteuerelemente zu integrieren, die auf dem Sperrbildschirm angezeigt werden.

3.8.11. Bildschirmschoner (ehemals Dreams)

Informationen zum Einrichten von Bildschirmschonern finden Sie in Abschnitt 3.2.3.5.

3.8.12. Standort

Wenn Geräteimplementierungen einen Hardwaresensor (z.B. GPS) enthalten, der die Standortkoordinaten liefern kann, gilt Folgendes:

• [C-1-2] Der aktuelle Standortstatus MUSS im Menü „Standort“ in den Einstellungen angezeigt werden.

• [C-1-3] Standortmodi DÜRFEN im Menü „Standort“ in den Einstellungen NICHT angezeigt werden.

3.8.13. Unicode und Schriftart

Android unterstützt die in Unicode 10.0 definierten Emoji-Zeichen.

Wenn Geräteimplementierungen einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

• [C-1-1] MUSS diese Emojis als farbige Glyphen darstellen können.

• [C-1-2] MUSS Folgendes unterstützen:

  • Roboto 2-Schriftart mit verschiedenen Strichstärken: „sans-serif-thin“, „sans-serif-light“, „sans-serif-medium“, „sans-serif-black“, „sans-serif-condensed“, „sans-serif-condensed-light“ für die auf dem Gerät verfügbaren Sprachen.

  • Vollständige Unicode 7.0-Abdeckung von Lateinisch, Griechisch und Kyrillisch, einschließlich der Bereiche „Latin Extended A“, „B“, „C“ und „D“ sowie aller Glyphen im Block „Currency Symbols“ von Unicode 7.0.

• [C-1-3] NotoColorEmoji.tff darf im System-Image NICHT entfernt oder geändert werden. (Es ist zulässig, eine neue Emoji-Schriftart hinzuzufügen, um Emojis in NotoColorEmoji.tff zu überschreiben.)

• Sollte die im Unicode Technical Report #51 angegebenen Emojis für Hauttöne und diverse Familien unterstützen.

Wenn Geräteimplementierungen eine IME enthalten, müssen sie folgende Anforderungen erfüllen:

• Es SOLLTE eine Eingabemethode für diese Emoji-Zeichen für den Nutzer bereitgestellt werden.

Android unterstützt das Rendern von Myanmar-Schriftarten. In Myanmar gibt es mehrere nicht Unicode-konforme Schriftarten, die allgemein als „Zawgyi“ bekannt sind und zum Rendern von Sprachen in Myanmar verwendet werden.

Wenn Geräteimplementierungen Unterstützung für Birmanisch enthalten, gilt Folgendes:

• [C-2-1] Text muss standardmäßig mit einer Unicode-kompatiblen Schriftart gerendert werden. Eine nicht Unicode-kompatible Schriftart darf nicht als Standardschriftart festgelegt werden, es sei denn, der Nutzer wählt sie in der Sprachauswahl aus.

• [C-2-2] MUSS eine Unicode-Schriftart und eine nicht Unicode-kompatible Schriftart unterstützen, wenn eine nicht Unicode-kompatible Schriftart auf dem Gerät unterstützt wird. Bei einer Schriftart, die nicht Unicode-kompatibel ist, darf die Unicode-Schriftart NICHT entfernt oder überschrieben werden.

• [C-2-3] Text muss mit einer nicht Unicode-kompatiblen Schriftart gerendert werden, NUR wenn ein Sprachcode mit dem Scriptcode Qaag angegeben ist (z.B. my-Qaag). Es dürfen keine anderen ISO-Sprach- oder ‑Regionscodes (zugewiesen, nicht zugewiesen oder reserviert) verwendet werden, um auf eine nicht Unicode-kompatible Schriftart für Myanmar zu verweisen. App-Entwickler und Webseitenautoren können „my-Qaag“ als den vorgesehenen Sprachcode angeben, wie sie es für jede andere Sprache tun würden.

3.8.14. Mehrfenstermodus

Wenn Geräteimplementierungen mehrere Aktivitäten gleichzeitig anzeigen können, gilt Folgendes:

• [C-1-1] MUSS solche Mehrfenstermodi gemäß den in der Dokumentation zur Unterstützung des Mehrfenstermodus des Android SDK beschriebenen Anwendungsverhaltens und APIs implementieren und die folgenden Anforderungen erfüllen:

• [C-1-2] Anforderung in Android 16 entfernt.

• [C-1-3] Der Splitscreen- oder Freiformmodus darf NICHT angeboten werden, wenn die Bildschirmhöhe weniger als 440 dp und die Bildschirmbreite weniger als 440 dp beträgt.

• [C-1-4] Eine Aktivität DARF in anderen Mehrfenstermodi als dem Bild-im-Bild-Modus NICHT auf eine Größe von weniger als 220 dp skaliert werden.

• Geräteimplementierungen mit einer Bildschirmgröße von xlarge SOLLTEN den Freiformmodus unterstützen.

Wenn Geräteimplementierungen den Mehrfenstermodus und den Splitscreen-Modus unterstützen, gilt Folgendes:

• [C-2-2] MUSS die angedockte Activity eines Splitscreen-Mehrfenstermodus zuschneiden, SOLLTE aber einige Inhalte davon anzeigen, wenn die Launcher-App das fokussierte Fenster ist.

• [C-2-3] MUSS die deklarierten AndroidManifestLayout_minWidth- und AndroidManifestLayout_minHeight-Werte der Launcher-App eines Drittanbieters berücksichtigen und diese Werte nicht überschreiben, wenn Inhalte der angedockten Aktivität angezeigt werden.

Wenn Geräteimplementierungen den Mehrfenstermodus und den Bild-im-Bild-Mehrfenstermodus unterstützen, gilt Folgendes:

• [C-3-1] Aktivitäten MÜSSEN im Bild-im-Bild-Mehrfenstermodus gestartet werden, wenn die App:

  • Die App ist auf API-Level 26 oder höher ausgerichtet und deklariert android:supportsPictureInPicture.

  • Die App ist auf API-Level 25 oder niedriger ausgerichtet und deklariert sowohl android:resizeableActivity als auch android:supportsPictureInPicture.

• [C-3-2] MUSS die Aktionen in der SystemUI gemäß der aktuellen PIP-Aktivität über die setActions()-API bereitstellen.

• [C-3-3] MUSS Seitenverhältnisse von mindestens 1:2,39 und höchstens 2,39:1 unterstützen, wie durch die PIP-Aktivität über die setAspectRatio()-API angegeben.

• [C-3-4] KeyEvent.KEYCODE_WINDOW MUSS zum Steuern des BiB-Fensters verwendet werden. Wenn der BiB-Modus nicht implementiert ist, MUSS der Schlüssel für die Vordergrundaktivität verfügbar sein.

• [C-3-5] Es MUSS eine Möglichkeit für Nutzer geben, die Anzeige einer App im BiB-Modus zu blockieren. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente in der Benachrichtigungsleiste.

• [C-3-6] Die folgenden Mindestbreiten und ‑höhen MÜSSEN für das BiB-Fenster zugewiesen werden, wenn eine Anwendung keinen Wert für AndroidManifestLayout_minWidth und AndroidManifestLayout_minHeight deklariert:

  • Geräte mit dem Configuration.uiMode, der nicht auf UI_MODE_TYPE_TELEVISION festgelegt ist, MÜSSEN eine Mindestbreite und ‑höhe von 108 dp zuweisen.

  • Geräte mit dem Configuration.uiMode, der auf UI_MODE_TYPE_TELEVISION festgelegt ist, MÜSSEN eine Mindestbreite von 240 dp und eine Mindesthöhe von 135 dp zuweisen.

Wenn Geräteimplementierungen mehr als einen Android-kompatiblen Displaybereich enthalten und solche Bereiche für Apps verfügbar machen, gilt Folgendes:

• [C-4-1] MUSS den Mehrfenstermodus unterstützen.

Wenn Geräteimplementierungen den Mehrfenstermodus unterstützen, gilt Folgendes:

• [C-5-1] MUSS die richtige Version der Window Manager Extensions-API-Ebene implementieren, wie unter WindowManager-Erweiterungen beschrieben.

3.8.15. Display-Aussparung

Android unterstützt ein Display-Ausschnitt wie im SDK-Dokument beschrieben. Die DisplayCutout-API definiert einen Bereich am Rand des Displays, der aufgrund einer Display-Aussparung oder eines gekrümmten Displays am Rand für eine Anwendung möglicherweise nicht funktionsfähig ist.

Wenn Geräteimplementierungen Display-Aussparung(en) enthalten, gilt Folgendes:

• [C-1-5] Das Gerät DARF KEINE Aussparungen haben, wenn das Seitenverhältnis des Geräts 1,0 (1:1) ist.

• [C-1-2] Es darf nicht mehr als einen Ausschnitt pro Kante geben.

• [C-1-3] MUSS die von der App über die WindowManager.LayoutParams-API festgelegten Flags für die Display-Aussparung gemäß Beschreibung im SDK berücksichtigen.

• [C-1-4] MUSS korrekte Werte für alle in der DisplayCutout-API definierten Ausschnittmesswerte zurückgeben.

3.8.16. Gerätesteuerung

Android enthält die APIs ControlsProviderService und Control, mit denen Drittanbieter-Apps Gerätesteuerungen für schnelle Status- und Aktionsinformationen für Nutzer veröffentlichen können.

Gerätespezifische Anforderungen finden Sie im Abschnitt 2_2_3.

3.8.17. Zwischenablage

Geräteimplementierungen:

• [C-0-1] DARF KEINE Zwischenablagedaten ohne ausdrückliche Nutzeraktion (z.B. durch Drücken einer Schaltfläche im Overlay) oder Angabe der gesendeten Inhalte an eine Komponente, Aktivität oder einen Dienst oder über eine Netzwerkverbindung senden, mit Ausnahme der in 9.8.6 Inhalte erfassen und App-Suche genannten Dienste.

Wenn bei Geräteimplementierungen eine für den Nutzer sichtbare Vorschau generiert wird, wenn Inhalte für ein beliebiges ClipData-Element in die Zwischenablage kopiert werden, wobei ClipData.getDescription().getExtras() android.content.extra.IS_SENSITIVE enthält, gilt Folgendes:

• [C-1-1] Die für Nutzer sichtbare Vorschau MUSS geschwärzt werden.

Die AOSP-Referenzimplementierung erfüllt diese Anforderungen an die Zwischenablage.

3.8.18. Schaltfläche „Standort“

3.9. Geräteverwaltung

Android bietet Funktionen, mit denen Device Policy Controller-Apps (Kontrollmechanismen für Geräterichtlinien) über die Device Policy Manager APIs (APIs für Geräterichtlinien-Manager) Geräteverwaltungsfunktionen auf Systemebene ausführen können, z. B. das Erzwingen von Passwortrichtlinien oder das Ausführen von Remote-Löschungen.

3.9.1. Gerätebereitstellung

3.9.1.1. Bereitstellung des Geräteeigentümers

Wenn Geräteimplementierungen android.software.device_admin deklarieren, gilt Folgendes:

• [C-1-1] MUSS die Registrierung eines Device Policy Controller (DPC) als App für Geräteinhaber wie unten beschrieben unterstützen:

  • Wenn in der Geräteimplementierung weder Nutzer noch Nutzerdaten konfiguriert sind, gilt Folgendes:

    • [C-1-5] Die DPC-Anwendung MUSS als Geräteinhaber-App registriert werden oder die DPC-App MUSS die Möglichkeit haben, auszuwählen, ob sie Geräteinhaber oder Profilinhaber werden soll, wenn das Gerät die Unterstützung von Near Field Communication (NFC) über das Funktions-Flag android.hardware.nfc deklariert und eine NFC-Nachricht mit einem Datensatz mit dem MIME-Typ MIME_TYPE_PROVISIONING_NFC empfängt.

    • [C-1-8] MUSS den Intent ACTION_GET_PROVISIONING_MODE senden, nachdem die Bereitstellung des Geräteinhabers ausgelöst wurde, damit die DPC-App je nach den Werten von android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES auswählen kann, ob sie Geräteinhaber oder Profilinhaber werden soll, es sei denn, aus dem Kontext geht hervor, dass es nur eine gültige Option gibt.

    • [C-1-9] MUSS den Intent ACTION_ADMIN_POLICY_COMPLIANCE an die Geräteinhaber-App senden, wenn während der Bereitstellung ein Geräteinhaber festgelegt wird, unabhängig von der verwendeten Bereitstellungsmethode. Der Nutzer darf den Einrichtungsassistenten erst fortsetzen, wenn die Geräteinhaber-App abgeschlossen ist.

  • Wenn die Geräteimplementierung Nutzer oder Nutzerdaten enthält, gilt Folgendes:

    • [C-1-7] DPC-Anwendungen dürfen nicht mehr als Geräteinhaber-App registriert werden.

• [C-1-2] Anforderung in Android 15 entfernt.

• [C-2-1] Anforderung in Android 15 entfernt.

• [C-2-2] Anforderung in Android 15 entfernt.

• [C-2-3] Anforderung in Android 15 entfernt.

3.9.1.2. Bereitstellung verwalteter Profile

Wenn Geräteimplementierungen android.software.managed_users deklarieren, gilt Folgendes:

• [C-1-1] MUSS android.software.device_admin deklarieren und die APIs implementieren, damit eine DPC-Anwendung (Device Policy Controller) Inhaber eines neuen verwalteten Profils werden kann.

• [C-1-2] Anforderung in Android 16 entfernt.

• [C-1-3] MUSS in den Einstellungen die folgenden Informationen für den Nutzer bereitstellen, um ihn darüber zu informieren, wann eine bestimmte Systemfunktion vom Geräteinhaber (Device Policy Controller, DPC) deaktiviert wurde:

  • Ein einheitliches Symbol oder eine andere Nutzerhilfe (z. B. das AOSP-Infobutton für Upstream), um darzustellen, wenn eine bestimmte Einstellung durch einen Geräteadministrator eingeschränkt wird.
  • Eine kurze Erläuterung, die vom Geräteadministrator über die setShortSupportMessage bereitgestellt wird.
  • Das Symbol der DPC-Anwendung.

• [C-1-4] Der Handler für die Intention ACTION_PROVISIONING_SUCCESSFUL MUSS im Arbeitsprofil gestartet werden, wenn ein Profilinhaber eingerichtet wird, wenn die Bereitstellung durch die Intention android.app.action.PROVISION_MANAGED_PROFILE initiiert wird und der DPC den Handler implementiert hat.

• [C-1-5] MUSS den Broadcast ACTION_PROFILE_PROVISIONING_COMPLETE an den DPC des Arbeitsprofils senden, wenn die Bereitstellung durch den Intent android.app.action.PROVISION_MANAGED_PROFILE initiiert wird.

• [C-1-6] MUSS den Intent ACTION_GET_PROVISIONING_MODE senden, nachdem die Bereitstellung des Profilinhabers ausgelöst wurde, damit die DPC-App auswählen kann, ob sie Geräteinhaber oder Profilinhaber werden soll. Dies gilt nicht, wenn die Bereitstellung durch den Intent android.app.action.PROVISION_MANAGED_PROFILE ausgelöst wird.

• [C-1-7] Der Intent ACTION_ADMIN_POLICY_COMPLIANCE MUSS an das Arbeitsprofil gesendet werden, wenn während der Bereitstellung ein Profilinhaber eingerichtet wird, unabhängig davon, welche Bereitstellungsmethode verwendet wird, es sei denn, die Bereitstellung wird durch den Intent android.app.action.PROVISION_MANAGED_PROFILE ausgelöst. Der Nutzer darf den Einrichtungsassistenten erst fortsetzen, wenn die Profilinhaber-App abgeschlossen ist.

• [C-1-8] MUSS die Broadcast-Nachricht ACTION_MANAGED_PROFILE_PROVISIONED an den DPC des persönlichen Profils senden, wenn ein Profilinhaber eingerichtet wird, unabhängig von der verwendeten Bereitstellungsmethode.

3.9.2. Unterstützung für verwaltete Profile

Wenn Geräteimplementierungen android.software.managed_users deklarieren, gilt Folgendes:

• [C-1-1] MUSS verwaltete Profile über die android.app.admin.DevicePolicyManager-APIs unterstützen.

• [C-1-2] Es MUSS möglich sein, genau ein verwaltetes Profil zu erstellen.

• [C-1-3] Für verwaltete Anwendungen, Widgets und andere UI-Elemente mit Badge wie „Letzte Apps und Benachrichtigungen“ MUSS ein Symbol-Badge verwendet werden, das dem AOSP-Upstream-Arbeitsbadge ähnelt.

• [C-1-4] Es MUSS ein Benachrichtigungssymbol (ähnlich dem AOSP-Upstream-Arbeitsbadge) angezeigt werden, um anzugeben, wann sich der Nutzer in einer Anwendung des verwalteten Profils befindet.

• [C-1-5] Es MUSS ein Hinweis angezeigt werden, dass sich der Nutzer im verwalteten Profil befindet, wenn das Gerät aktiviert wird (ACTION_USER_PRESENT) und die Vordergrundanwendung sich im verwalteten Profil befindet.

• [C-1-6] Wenn ein verwaltetes Profil vorhanden ist, MUSS im Intent-Chooser eine visuelle Möglichkeit angezeigt werden, damit der Nutzer den Intent vom verwalteten Profil an den Hauptnutzer weiterleiten kann oder umgekehrt, sofern dies vom Device Policy Controller aktiviert wurde.

• [C-1-7] Wenn ein verwaltetes Profil vorhanden ist, MUSS für den Hauptnutzer und das verwaltete Profil Folgendes angezeigt werden:

  • Separate Ressourcenerfassung für Akku-, Standort-, mobile Daten- und Speichernutzung für den Hauptnutzer und das verwaltete Profil.
  • Unabhängige Verwaltung von VPN-Apps, die im primären Nutzerprofil oder im verwalteten Profil installiert sind.
  • Unabhängige Verwaltung von Anwendungen, die im Hauptnutzerprofil oder im verwalteten Profil installiert sind.
  • Unabhängige Verwaltung von Konten im Hauptnutzerprofil oder im verwalteten Profil.

• [C-1-8] MUSS dafür sorgen, dass in den vorinstallierten Dialer-, Kontakte- und Messaging-Apps neben den Informationen aus dem primären Profil auch Anruferinformationen aus dem verwalteten Profil (falls vorhanden) gesucht und nachgeschlagen werden können, sofern der Device Policy Controller dies zulässt.

• [C-1-9] MUSS alle Sicherheitsanforderungen erfüllen, die für ein Gerät mit mehreren aktivierten Nutzern gelten (siehe Abschnitt 9.5), auch wenn das verwaltete Profil nicht als zusätzlicher Nutzer neben dem Hauptnutzer gezählt wird.

• [C-1-10] MUSS dafür sorgen, dass die Screenshot-Daten im Speicher des Arbeitsprofils gespeichert werden, wenn ein Screenshot mit einem topActivity-Fenster aufgenommen wird, das den Fokus hat (das Fenster, mit dem der Nutzer zuletzt unter allen Aktivitäten interagiert hat) und zu einer Arbeitsprofil-App gehört.

• [C-1-11] Es dürfen keine anderen Bildschirminhalte (Systemleiste, Benachrichtigungen oder Inhalte des privaten Profils) als das Fenster/die Fenster der Arbeitsprofilanwendung erfasst werden, wenn ein Screenshot im Arbeitsprofil gespeichert wird (um sicherzustellen, dass keine Daten des privaten Profils im Arbeitsprofil gespeichert werden).

Wenn Geräteimplementierungen android.software.managed_users und android.software.secure_lock_screen deklarieren, gilt Folgendes:

• [C-2-1] Es MUSS möglich sein, ein separates Meeting auf dem Sperrbildschirm anzugeben, das die folgenden Anforderungen erfüllt, um nur Apps, die in einem verwalteten Profil ausgeführt werden, Zugriff zu gewähren.

  • Geräteimplementierungen MÜSSEN den Intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD berücksichtigen und eine Benutzeroberfläche zum Konfigurieren separater Sperrbildschirm-Anmeldedaten für das verwaltete Profil anzeigen.

  • Die Anmeldedaten für den Sperrbildschirm des verwalteten Profils MÜSSEN dieselben Mechanismen für den Anmeldedatenspeicher und die Verwaltung wie das übergeordnete Profil verwenden, wie auf der Open-Source-Projekt für Android-Website dokumentiert.

  • Die Passwortrichtlinien des Geräteinhabers müssen sich NUR auf die Anmeldedaten für den Sperrbildschirm des verwalteten Profils beziehen, es sei denn, sie werden für die DevicePolicyManager-Instanz aufgerufen, die von getParentProfileInstance zurückgegeben wird.

• Wenn Kontakte aus dem verwalteten Profil im vorinstallierten Anruflisten-UI, im In-Call-UI, in Benachrichtigungen über laufende und verpasste Anrufe, in Kontakten und in Messaging-Apps angezeigt werden, SOLLTEN sie mit demselben Symbol gekennzeichnet werden, das für Anwendungen im verwalteten Profil verwendet wird.

3.9.3. Support für verwaltete Nutzer

Wenn Geräteimplementierungen android.software.managed_users deklarieren, gilt Folgendes:

• [C-1-1] Es MUSS eine Möglichkeit für Nutzer geben, sich vom aktuellen Nutzer abzumelden und in einer Sitzung mit mehreren Nutzern zum primären Nutzer zurückzukehren, wenn isLogoutEnabled true zurückgibt. Die Nutzeraktion MUSS über den Sperrbildschirm zugänglich sein, ohne dass das Gerät entsperrt werden muss.

Wenn in Geräteimplementierungen android.software.device_admin deklariert wird und eine On-Device-Benutzereingabe zum Hinzufügen zusätzlicher sekundärer Nutzer bereitgestellt wird, gilt Folgendes:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, dieselben Offenlegungen zur Einwilligung des AOSP-Geräteinhabers anzuzeigen, die im Ablauf angezeigt wurden, der durch android.app.action.PROVISION_MANAGED_DEVICE initiiert wurde, bevor Konten im neuen sekundären Nutzer hinzugefügt werden dürfen. So wird den Nutzern verdeutlicht, dass das Gerät verwaltet wird.

3.9.4. Rollenanforderungen für die Geräteverwaltung

Wenn Geräteimplementierungen android.software.device_admin deklarieren, gilt Folgendes:

• [C-1-1] MUSS die Rolle „Geräterichtlinienverwaltung“ gemäß Abschnitt 9.1 unterstützen. Die Anwendung, die die Rolle für die Verwaltung von Geräterichtlinien innehat, KANN definiert werden, indem config_devicePolicyManagement auf den Paketnamen festgelegt wird. Auf den Paketnamen MUSS ein Doppelpunkt (:) und das Signaturzertifikat folgen, sofern die Anwendung nicht vorab geladen wird.

Wenn für config_devicePolicyManagement kein Paketname wie oben beschrieben definiert ist:

• [C-2-1] Geräteimplementierungen MÜSSEN die Bereitstellung ohne eine Anwendung mit der Rolle „Inhaber der Geräte-Policy-Verwaltung“ unterstützen (AOSP bietet eine Referenzimplementierung).

Wenn für config_devicePolicyManagement ein Paketname definiert ist, wie oben beschrieben:

• [C-3-1] Die Anwendung MUSS auf allen Profilen eines Nutzers installiert sein.

• [C-3-2] Geräteimplementierungen KÖNNEN eine Anwendung definieren, die den Inhaber der Geräteverwaltungsrolle vor der Bereitstellung aktualisiert, indem config_devicePolicyManagementUpdater festgelegt wird.

Wenn für config_devicePolicyManagementUpdater wie oben beschrieben ein Paketname definiert ist:

• [C-4-1] Die Anwendung MUSS auf dem Gerät vorinstalliert sein.

• [C-4-2] Die Anwendung MUSS einen Intent-Filter implementieren, der android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER auflöst.

3.9.5. Framework zur Auflösung von Geräterichtlinien

Wenn Geräteimplementierungen android.software.device_admin deklarieren, gilt Folgendes:

• [C-1-1] Geräterichtlinienkonflikte MÜSSEN gemäß der Dokumentation zum Framework zur Behebung von Geräterichtlinienkonflikten behoben werden.

3.10. Bedienungshilfen

Android bietet eine Bedienungshilfenschicht, die Nutzern mit Beeinträchtigungen die Bedienung ihrer Geräte erleichtert. Außerdem bietet Android Plattform-APIs, mit denen Implementierungen von Bedienungshilfen Rückrufe für Nutzer- und Systemereignisse empfangen und alternative Feedbackmechanismen wie Text-zu-Sprache, haptisches Feedback und Trackball-/Steuerkreuz-Navigation generieren können.

Wenn Geräteimplementierungen Bedienungshilfen von Drittanbietern unterstützen, gilt Folgendes:

• [C-1-1] MUSS eine Implementierung des Android-Frameworks für Barrierefreiheit gemäß der SDK-Dokumentation zu den Accessibility APIs bereitstellen.
• [C-1-2] MUSS Barrierefreiheitsereignisse generieren und die entsprechenden AccessibilityEvent an alle registrierten AccessibilityService-Implementierungen senden, wie im SDK dokumentiert.
• [C-1-4] MUSS eine Möglichkeit für Nutzer bieten, um Bedienungshilfen zu steuern, die AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON deklarieren. Bei Geräteimplementierungen mit einer Systemnavigationsleiste SOLLTE der Nutzer die Möglichkeit haben, diese Dienste über eine Schaltfläche in der Navigationsleiste des Systems zu steuern.

Wenn Geräteimplementierungen vorinstallierte Dienste für Barrierefreiheit enthalten, gilt Folgendes:

• [C-2-1] Diese vorinstallierten Bedienungshilfen MÜSSEN als Direct Boot Aware-Apps implementiert werden, wenn der Datenspeicher mit File Based Encryption (FBE) verschlüsselt ist.
• Es SOLLTE einen Mechanismus im Einrichtungsablauf geben, mit dem Nutzer relevante Bedienungshilfen aktivieren sowie die Schriftgröße, die Anzeigegröße und die Vergrößerungsgesten anpassen können.

3.11. Text-to-Speech

Android enthält APIs, mit denen Anwendungen Text-to-Speech-Dienste (TTS) nutzen können, und ermöglicht Dienstanbietern, Implementierungen von TTS-Diensten bereitzustellen.

Wenn Geräteimplementierungen die Funktion „android.hardware.audio.output“ melden, gilt Folgendes:

• [C-1-1] MUSS die APIs des Android TTS-Frameworks unterstützen.

Wenn Geräteimplementierungen die Installation von TTS-Engines von Drittanbietern unterstützen, gilt Folgendes:

• [C-2-1] MUSS dem Nutzer die Möglichkeit bieten, eine TTS-Engine für die Verwendung auf Systemebene auszuwählen.

3.12. –

3.13. Schnelleinstellungen

Android bietet eine UI-Komponente für die Schnelleinstellungen, die schnellen Zugriff auf häufig verwendete oder dringend benötigte Aktionen ermöglicht.

Wenn Geräteimplementierungen eine UI-Komponente für die Schnelleinstellungen enthalten und Drittanbieter-Schnelleinstellungen unterstützen, gilt Folgendes:

• [C-1-1] Der Nutzer MUSS die Möglichkeit haben, die über die quicksettings-APIs bereitgestellten Kacheln in einer Drittanbieter-App hinzuzufügen oder zu entfernen.
• [C-1-2] Eine Kachel aus einer Drittanbieter-App DARF NICHT automatisch direkt den Schnelleinstellungen hinzugefügt werden.
• [C-1-3] ALLE vom Nutzer hinzugefügten Kacheln von Drittanbieter-Apps MÜSSEN neben den vom System bereitgestellten Kacheln für die Schnelleinstellungen angezeigt werden.

3.14. Media-UI

Wenn Geräteimplementierungen nicht sprachaktivierte Anwendungen (die Apps) enthalten, die über MediaBrowser oder MediaSession mit Drittanbieteranwendungen interagieren, müssen die Apps:

• [C-1-2] Symbole, die über getIconBitmap() oder getIconUri() abgerufen werden, und Titel, die über getTitle() abgerufen werden, MÜSSEN gemäß MediaDescription deutlich angezeigt werden. Titel können gekürzt werden, um Sicherheitsbestimmungen einzuhalten (z.B. Ablenkung des Fahrers).

• [C-1-3] Das Symbol der Drittanbieteranwendung MUSS immer angezeigt werden, wenn Inhalte aus dieser Drittanbieteranwendung präsentiert werden.

• [C-1-4] Der Nutzer MUSS mit der gesamten MediaBrowser-Hierarchie interagieren können. KANN den Zugriff auf einen Teil der Hierarchie einschränken, um Sicherheitsbestimmungen einzuhalten (z.B. Ablenkung des Fahrers), DARF aber keine bevorzugte Behandlung aufgrund von Inhalten oder Inhaltsanbietern vornehmen.

• [C-1-5] Das Doppeltippen auf KEYCODE_HEADSETHOOK oder KEYCODE_MEDIA_PLAY_PAUSE MUSS als KEYCODE_MEDIA_NEXT für MediaSession.Callback#onMediaButtonEvent betrachtet werden.

3.15. Instant Apps

Wenn Geräteimplementierungen Instant Apps unterstützen, MÜSSEN sie die folgenden Anforderungen erfüllen:

• [C-1-1] Instant Apps DÜRFEN nur Berechtigungen erhalten, für die android:protectionLevel auf "instant" festgelegt ist.
• [C-1-2] Instant-Apps DÜRFEN NICHT über implizite Intents mit installierten Apps interagieren, es sei denn, eine der folgenden Bedingungen ist erfüllt:
  • Der Intent-Musterfilter der Komponente ist verfügbar und enthält CATEGORY_BROWSABLE.
  • Die Aktion ist eine von ACTION_SEND, ACTION_SENDTO oder ACTION_SEND_MULTIPLE.
  • Das Ziel wird explizit mit android:visibleToInstantApps verfügbar gemacht.
• [C-1-3] Instant-Apps DÜRFEN NICHT explizit mit installierten Apps interagieren, es sei denn, die Komponente wird über „android:visibleToInstantApps“ verfügbar gemacht.
• [C-1-4] Installierte Apps DÜRFEN KEINE Details zu Instant Apps auf dem Gerät sehen, es sei denn, die Instant App stellt explizit eine Verbindung zur installierten App her.

• Geräteimplementierungen MÜSSEN die folgenden Möglichkeiten für die Interaktion mit Instant-Apps bieten. Das AOSP erfüllt die Anforderungen mit der Standard-System-UI, den Einstellungen und dem Launcher. Geräteimplementierungen:

  • [C-1-5] Es MUSS eine Möglichkeit für Nutzer geben, lokal im Cache gespeicherte Instant Apps für jedes einzelne App-Paket anzusehen und zu löschen.
  • [C-1-6] MUSS eine dauerhafte Nutzerbenachrichtigung bereitstellen, die minimiert werden kann, während eine Instant-App im Vordergrund ausgeführt wird. Diese Nutzerbenachrichtigung MUSS darauf hinweisen, dass Instant-Apps keine Installation erfordern, und dem Nutzer eine Möglichkeit bieten, den Bildschirm mit den App-Informationen in den Einstellungen aufzurufen. Bei Instant-Apps, die über Web-Intents gestartet werden, wie durch die Verwendung eines Intents mit der auf Intent.ACTION_VIEW festgelegten Aktion und einem Schema von „http“ oder „https“ definiert, SOLLTE eine zusätzliche Nutzeraktion es dem Nutzer ermöglichen, die Instant-App nicht zu starten und den zugehörigen Link mit dem konfigurierten Webbrowser zu öffnen, sofern ein Browser auf dem Gerät verfügbar ist.
  • [C-1-7] MUSS den Zugriff auf Instant Apps über die Funktion „Letzte“ ermöglichen, wenn diese Funktion auf dem Gerät verfügbar ist.

• [C-1-8] Es MUSS mindestens eine Anwendung oder Dienstkomponente mit einem Intent-Handler für die im SDK hier aufgeführten Intents vorinstalliert werden und die Intents müssen für Instant Apps sichtbar sein.

3.16. Kopplung von Begleitgeräten

Android unterstützt die Gerätekopplung von Begleitgeräten, um die Zuordnung zu Begleitgeräten effektiver zu verwalten. Außerdem wird die CompanionDeviceManager API bereitgestellt, damit Apps auf diese Funktion zugreifen können.

Wenn Geräteimplementierungen die Funktion zur Kopplung von Companion-Geräten unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag FEATURE_COMPANION_DEVICE_SETUP deklarieren.

• [C-1-2] MUSS dafür sorgen, dass die APIs im Paket android.companion vollständig implementiert sind.

• [C-1-3] MUSS dem Nutzer die Möglichkeit bieten, ein Companion-Gerät auszuwählen/zu bestätigen, das vorhanden und betriebsbereit ist. Dabei MUSS dieselbe Meldung wie in AOSP verwendet werden, ohne dass etwas hinzugefügt oder geändert wird.

3:17. Umfangreiche Apps

Wenn in Geräteimplementierungen das Feature FEATURE_CANT_SAVE_STATE deklariert wird, gilt Folgendes:

• [C-1-1] Es DARF jeweils nur eine installierte App mit der Angabe cantSaveState im System ausgeführt werden. Wenn der Nutzer eine solche App verlässt, ohne sie explizit zu beenden (z. B. durch Drücken der Home-Taste, während eine aktive Aktivität im System ausgeführt wird, anstatt die Zurück-Taste zu drücken, wenn keine aktiven Aktivitäten mehr im System vorhanden sind), MÜSSEN Geräteimplementierungen diese App im RAM priorisieren, wie sie es auch für andere Dinge tun, die voraussichtlich weiterhin ausgeführt werden, z. B. Vordergrunddienste. Wenn eine solche App im Hintergrund ausgeführt wird, kann das System weiterhin Funktionen zur Energieverwaltung darauf anwenden, z. B. den CPU- und Netzwerkzugriff einschränken.
• [C-1-2] Es MUSS eine Benutzeroberflächenfunktion bereitgestellt werden, mit der der Nutzer die App auswählen kann, die nicht am normalen Speichern/Wiederherstellen des Status beteiligt ist, sobald er eine zweite App startet, die mit dem Attribut cantSaveState deklariert ist.
• [C-1-3] Es DÜRFEN keine anderen Richtlinienänderungen auf Apps angewendet werden, die cantSaveState angeben, z. B. Änderungen an der CPU-Leistung oder Änderungen an der Priorisierung der Planung.

Wenn in Geräteimplementierungen das Feature FEATURE_CANT_SAVE_STATE nicht deklariert wird, gilt Folgendes:

• [C-1-1] MUSS das von Apps festgelegte Attribut cantSaveState ignorieren und DARF das App-Verhalten nicht auf Grundlage dieses Attributs ändern.

3.18. Kontakte

Android enthält Contacts Provider-APIs, mit denen Anwendungen auf dem Gerät gespeicherte Kontaktinformationen verwalten können. Kontaktdaten, die direkt auf dem Gerät eingegeben werden, werden in der Regel mit einem Webdienst synchronisiert. Die Daten KÖNNEN aber auch nur lokal auf dem Gerät gespeichert werden. Kontakte, die nur auf dem Gerät gespeichert sind, werden als lokale Kontakte bezeichnet.

RawContacts sind „mit“ einem Account „verknüpft“ oder „in“ einem Account „gespeichert“, wenn die Spalten ACCOUNT_NAME und ACCOUNT_TYPE für die Rohkontakte mit den entsprechenden Feldern Account.name und Account.type des Kontos übereinstimmen.

Standardkonto für lokale Kontakte: Ein Konto für Rohkontakte, die nur auf dem Gerät gespeichert und nicht mit einem Konto im AccountManager verknüpft sind. Sie werden mit null-Werten für die Spalten ACCOUNT_NAME und ACCOUNT_TYPEACCOUNT_TYPE erstellt.

Benutzerdefiniertes lokales Konto: Ein Konto für Rohkontakte, die nur auf dem Gerät gespeichert sind und nicht mit einem Konto im AccountManager verknüpft sind. Sie werden mit Nicht-Null-Werten für die Spalten ACCOUNT_NAME und ACCOUNT_TYPE erstellt.

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, KEINE benutzerdefinierten lokalen Konten zu erstellen.

Wenn in Geräteimplementierungen ein benutzerdefiniertes lokales Konto verwendet wird:

• [C-1-1] Die ACCOUNT_NAME> des benutzerdefinierten lokalen Kontos MUSS von ContactsContract.RawContacts.getLocalAccountName zurückgegeben werden.

• [C-1-2] Die ACCOUNT_TYPE des benutzerdefinierten lokalen Kontos MUSS von ContactsContract.RawContacts.getLocalAccountType zurückgegeben werden.

• [C-1-3] Von Drittanbieteranwendungen eingefügte Rohkontakte ohne Angabe eines Kontos MÜSSEN in das Standardkontaktkonto des Geräts eingefügt werden. Wenn das Standardkonto für Kontakte DEFAULT_ACCOUNT_STATE_LOCAL oder DEFAULT_ACCOUNT_STATE_NOT_SET ist, MÜSSEN diese Rohkontakte im benutzerdefinierten lokalen Konto gespeichert werden.

• [C-1-4] Rohkontakte, die in das benutzerdefinierte lokale Konto eingefügt werden, DÜRFEN NICHT entfernt werden, wenn Konten hinzugefügt oder entfernt werden.

• [C-1-5] Löschvorgänge für das benutzerdefinierte lokale Konto MÜSSEN dazu führen, dass Rohkontakte sofort gelöscht werden (als ob der Parameter CALLER_IS_SYNCADAPTER auf „true“ gesetzt wäre), auch wenn der Parameter CALLER_IS_SYNCADAPTER auf „false“ gesetzt oder nicht angegeben wurde.

3.18.2. Systemkontaktauswahl

3.19. Spracheinstellungen

Geräteimplementierungen:

• [C-0-1] Es DARF keine Möglichkeit für Nutzer geben, eine geschlechtsspezifische Sprachbehandlung für Sprachen auszuwählen, die keine geschlechtsspezifischen Übersetzungen unterstützen. Weitere Informationen finden Sie unter Grammatische Ressourcen.

3.20. Assistant-basierte Funktionen

3.20.1. Anforderungen an Assistant-Audiostreams

3.21. Unterstützung von Funktionen zur Synchronisierung von Begleitgeräten

3.22. ComputerControls API

4. Kompatibilität von Anwendungspaketen

Geräteimplementierungen:

• [C-0-1] MUSS in der Lage sein, Android-„.apk“-Dateien zu installieren und auszuführen, die vom „aapt“-Tool generiert wurden, das im offiziellen Android SDK enthalten ist.
  • Da die oben genannte Anforderung schwierig zu erfüllen sein kann, wird empfohlen, dass Geräteimplementierungen das Paketverwaltungssystem der AOSP-Referenzimplementierung verwenden.

• [C-0-3] Die Formate .apk, Android-Manifest, Dalvik-Bytecode oder RenderScript-Bytecode dürfen nicht so erweitert werden, dass die Dateien nicht korrekt auf anderen kompatiblen Geräten installiert und ausgeführt werden können.

• [C-0-4] Apps, die nicht der aktuelle „Installer of Record“ für das Paket sind, DÜRFEN die App nicht ohne Bestätigung des Nutzers im Hintergrund deinstallieren, wie im SDK für die Berechtigung DELETE_PACKAGE dokumentiert. Die einzigen Ausnahmen sind die System-App zur Paketüberprüfung, die den Intent PACKAGE_NEEDS_VERIFICATION verarbeitet, und die Speichermanager-App, die den Intent ACTION_MANAGE_STORAGE verarbeitet.

• [C-0-5] Es MUSS eine Aktivität geben, die den Intent android.settings.MANAGE_UNKNOWN_APP_SOURCES verarbeitet.

• [C-0-6] Es DÜRFEN KEINE App-Pakete aus unbekannten Quellen installiert werden, es sei denn, die App, die die Installation anfordert, erfüllt alle folgenden Anforderungen:

  • Es MUSS die Berechtigung REQUEST_INSTALL_PACKAGES deklarieren oder android:targetSdkVersion muss auf 24 oder niedriger festgelegt sein.
  • Der Nutzer MUSS die Berechtigung zum Installieren von Apps aus unbekannten Quellen erteilt haben.

• Es SOLLTE eine Möglichkeit für Nutzer geben, die Berechtigung zum Installieren von Apps aus Unbekannten Quellen pro Anwendung zu erteilen/zu widerrufen. Es KANN jedoch auch als No-Op implementiert und RESULT_CANCELED für startActivityForResult() zurückgegeben werden, wenn die Geräteimplementierung Nutzern diese Wahl nicht ermöglichen soll. Auch in solchen Fällen SOLLTEN sie dem Nutzer jedoch mitteilen, warum keine solche Auswahlmöglichkeit angezeigt wird.

• [C-0-7] Vor dem Starten einer Aktivität in einer Anwendung, die von derselben System-API PackageManager.setHarmfulAppWarning als potenziell schädlich gekennzeichnet wurde, MUSS dem Nutzer ein Warndialog mit dem Warnstring angezeigt werden, der über die System-API PackageManager.setHarmfulAppWarning bereitgestellt wird.

• Es SOLLTE eine Möglichkeit für den Nutzer geben, die Anwendung im Warndialog zu deinstallieren oder zu starten.

• [C-0-8] MÜSSEN die Unterstützung für das inkrementelle Dateisystem implementieren, wie hier dokumentiert.

• [C-0-9] MUSS die Überprüfung von APK-Dateien mit dem APK-Signaturschema v4 und dem APK-Signaturschema v4.1 unterstützen.

5. Multimedia-Kompatibilität

Geräteimplementierungen:

• [C-0-1] MUSS die in Abschnitt 5.1 definierten Mediaformate, Encoder, Decoder, Dateitypen und Containerformate für jeden von MediaCodecList deklarierten Codec unterstützen.
• [C-0-2] MUSS die Unterstützung der Encoder und Decoder, die Drittanbieteranwendungen über MediaCodecList zur Verfügung stehen, deklarieren und melden.
• [C-0-3] MUSS alle Formate, die es codieren kann, richtig decodieren und Drittanbieter-Apps zur Verfügung stellen können. Dazu gehören alle Bitstreams, die von den Encodern generiert werden, und die Profile, die in der CamcorderProfile gemeldet werden.

Geräteimplementierungen:

• SHOULD aim for minimum codec latency, in others words, they
  • Eingabepuffer sollten NICHT verarbeitet und gespeichert werden. Eingabepuffer sollten erst nach der Verarbeitung zurückgegeben werden.
  • Decodierte Puffer sollten nicht länger als im Standard (z.B. SPS) angegeben aufbewahrt werden.
  • Sollte codierte Puffer nicht länger als für die GOP-Struktur erforderlich beibehalten.

Alle im Abschnitt unten aufgeführten Codecs werden als Softwareimplementierungen in der bevorzugten Android-Implementierung aus dem Android Open Source Project bereitgestellt.

Weder Google noch die Open Handset Alliance geben eine Zusicherung ab, dass diese Codecs frei von Patenten Dritter sind. Personen, die diesen Quellcode in Hardware- oder Softwareprodukten verwenden möchten, wird geraten, sich bei den entsprechenden Patentinhabern über die erforderlichen Patentlizenzen zu informieren. Dies gilt auch für die Verwendung in Open-Source-Software oder Shareware.

5.1 Media-Codecs

5.1.1. Audiocodierung

Weitere Informationen finden Sie in Abschnitt 5.1.3. Details zu Audio-Codecs.

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, MÜSSEN sie die Codierung der folgenden Audioformate unterstützen und sie für Drittanbieter-Apps verfügbar machen:

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

Alle Audio-Encoder MÜSSEN Folgendes unterstützen:

• [C-3-1] PCM-Audio-Frames mit 16 Bit in der nativen Byte-Reihenfolge über die android.media.MediaCodec API.

5.1.2. Audiodecodierung

Weitere Informationen finden Sie in Abschnitt 5.1.3. Details zu Audio-Codecs.

Wenn Geräteimplementierungen Unterstützung für die Funktion android.hardware.audio.output deklarieren, müssen sie die Dekodierung der folgenden Audioformate unterstützen:

• [C-1-1] MPEG-4 AAC-Profil (AAC LC)
• [C-1-2] MPEG-4 HE AAC Profile (AAC+)
• [C-1-3] MPEG-4 HE AACv2-Profil (Enhanced AAC+)
• [C-1-4] AAC ELD (Enhanced Low Delay AAC)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, einschließlich hochauflösender Audioformate mit bis zu 24 Bit, 192 kHz Abtastrate und 8 Kanälen. Diese Anforderung gilt nur für die Dekodierung. Ein Gerät darf während der Wiedergabe Downsampling und Downmixing durchführen.
• [C-1-10] Opus
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, das das USAC Baseline Profile und das ISO/IEC 23003-4 Dynamic Range Control Profile umfasst)

Wenn Geräteimplementierungen die Decodierung von AAC-Eingabepuffern von Mehrkanal-Streams (d.h. mehr als zwei Kanäle) zu PCM über den standardmäßigen AAC-Audio-Decoder in der android.media.MediaCodec API unterstützen, MUSS Folgendes unterstützt werden:

• [C-2-1] Die Decodierung MUSS ohne Downmixing erfolgen (z.B. muss ein 5.0-AAC-Stream in fünf PCM-Kanäle und ein 5.1-AAC-Stream in sechs PCM-Kanäle decodiert werden).

• [C-2-2] Metadaten für den dynamischen Bereich MÜSSEN gemäß „Dynamic Range Control (DRC)“ in ISO/IEC 14496-3 definiert sein und die android.media.MediaFormat-DRC-Schlüssel zum Konfigurieren des Verhaltens des Audio-Decoders in Bezug auf den dynamischen Bereich. Die AAC DRC-Schlüssel wurden in API 21 eingeführt und sind: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL und KEY_AAC_ENCODED_TARGET_LEVEL.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, dass alle AAC-Audio-Decodierer die Anforderungen C-2-1 und C-2-2 oben erfüllen.

Beim Decodieren von USAC-Audio, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Metadaten für Lautstärke und DRC MÜSSEN gemäß MPEG-D DRC Dynamic Range Control Profile Level 1 interpretiert und angewendet werden.

• [C-3-2] Der Decoder MUSS sich gemäß der Konfiguration verhalten, die mit den folgenden android.media.MediaFormat-Schlüsseln festgelegt wurde: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL und KEY_AAC_DRC_EFFECT_TYPE.

MPEG-4-AAC-, HE-AAC- und HE-AACv2-Profildecoder:

• MAY unterstützt möglicherweise die Steuerung von Lautstärke und Dynamikumfang mit dem ISO/IEC 23003-4-Profil für die Steuerung des Dynamikumfangs.

Wenn ISO/IEC 23003-4 unterstützt wird und sowohl ISO/IEC 23003-4- als auch ISO/IEC 14496-3-Metadaten in einem decodierten Bitstream vorhanden sind, gilt Folgendes:

• Die Metadaten gemäß ISO/IEC 23003-4 haben Vorrang.

Alle Audio-Decoder MÜSSEN die folgenden Ausgaben unterstützen:

• [C-6-1] PCM-Audio-Frames mit 16 Bit in der nativen Byte-Reihenfolge über die android.media.MediaCodec API.

Wenn Geräteimplementierungen die Decodierung von AAC-Eingabepuffern von Mehrkanal-Streams (d.h. mehr als zwei Kanäle) zu PCM über den standardmäßigen AAC-Audio-Decoder in der android.media.MediaCodec API unterstützen, MUSS Folgendes unterstützt werden:

• [C-7-1] MUSS von der Anwendung über die Dekodierung mit dem Schlüssel KEY_MAX_OUTPUT_CHANNEL_COUNT konfiguriert werden können, um zu steuern, ob der Inhalt auf Stereo downmixed wird (bei Verwendung des Werts 2) oder mit der nativen Anzahl von Kanälen ausgegeben wird (bei Verwendung eines Werts, der gleich oder größer als diese Anzahl ist). Bei einem Wert von 6 oder höher würde ein Decoder beispielsweise 6 Kanäle ausgeben, wenn er mit 5.1-Inhalten gefüttert wird.

• [C-7-2] Bei der Decodierung MUSS der Decoder die im Ausgabeforamt verwendete Channelmaske mit dem Schlüssel KEY_CHANNEL_MASK unter Verwendung der android.media.AudioFormat-Konstanten (Beispiel: CHANNEL_OUT_5POINT1) angeben.

Wenn Geräteimplementierungen andere Audio-Decoder als den standardmäßigen AAC-Audio-Decoder unterstützen und in der Lage sind, Mehrkanal-Audio (d.h. mehr als 2 Kanäle) auszugeben, wenn sie mit komprimierten Mehrkanal-Inhalten versorgt werden, gilt Folgendes:

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, dass der Decoder von der Anwendung mit dem Schlüssel KEY_MAX_OUTPUT_CHANNEL_COUNT konfiguriert werden kann, um zu steuern, ob der Inhalt auf Stereo downmixed wird (bei Verwendung des Werts 2) oder mit der nativen Anzahl von Kanälen ausgegeben wird (bei Verwendung eines Werts, der gleich oder größer als diese Anzahl ist). Bei einem Wert von 6 oder höher würde ein Decoder beispielsweise 6 Kanäle ausgeben, wenn er mit 5.1-Inhalten gefüttert wird.

• [C-SR-3] Beim Decodieren wird DRINGEND EMPFOHLEN, dass der Decoder die im Ausgabeforamt verwendete Channelmaske mit dem Schlüssel KEY_CHANNEL_MASK unter Verwendung der android.media.AudioFormat-Konstanten angibt (Beispiel: CHANNEL_OUT_5POINT1).

5.1.3. Details zu Audio-Codecs

5.1.4. Bildcodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Bild-Codecs

Geräteimplementierungen MÜSSEN die Codierung der folgenden Bildcodierung unterstützen:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP
• [C-0-4] AVIF
  • Die Geräte müssen BITRATE_MODE_CQ und das Baseline-Profil unterstützen.

Wenn Geräteimplementierungen die HEIC-Codierung über android.media.MediaCodec für den Medientyp MIMETYPE_IMAGE_ANDROID_HEIC unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN einen hardwarebeschleunigten HEVC-Encoder-Codec bereitstellen, der den Bitratensteuerungsmodus BITRATE_MODE_CQ, das Profil HEVCProfileMainStill und die Framegröße 512 × 512 Pixel unterstützt.

5.1.5. Bilddecodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Bild-Codecs

Geräteimplementierungen MÜSSEN die Decodierung der folgenden Bildcodierung unterstützen:

• [C-0-1] JPEG

• [C-0-2] GIF

• [C-0-3] PNG

• [C-0-4] BMP

• [C-0-5] WebP

• [C-0-6] Roh

• [C-0-7] AVIF (Baseline-Profil)

Wenn Geräteimplementierungen die HEVC-Videodecodierung unterstützen,

• [C-1-1] MUSS die HEIF-Bilddecodierung (HEIC) unterstützen.

Bilddecoder, die ein Format mit hoher Bittiefe (mindestens 9 Bit pro Kanal) unterstützen:

• [C-2-1] MUSS die Ausgabe eines 8‑Bit-Äquivalentformats unterstützen, wenn dies von der Anwendung angefordert wird, z. B. über die ARGB_8888-Konfiguration von android.graphics.Bitmap.

5.1.6. Details zu Bild-Codecs

Format/Codec	Details	Unterstützte Dateitypen/Containerformate
JPEG	Grundpreis + progressiv	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Raw		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Bild, Bildsammlung, Bildsequenz	HEIF (.heif), HEIC (.heic)
AVIF (Baseline-Profil)	Baseline-Profil für Bild, Bildsammlung und Bildsequenz	HEIF-Container (.avif)

Bild-Encoder und ‑Decoder, die über die MediaCodec API verfügbar gemacht werden

• [C-1-1] MÜSSEN das flexible Farbformat YUV420 8:8:8 (COLOR_FormatYUV420Flexible) über CodecCapabilities unterstützen.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, das RGB888-Farbformat für den Eingabe-Surface-Modus zu unterstützen.

• [C-1-3] MUSS mindestens eines der planaren oder semiplanaren YUV420-Farbformate mit 8:8:8-Bit unterstützen: COLOR_FormatYUV420PackedPlanar (entspricht COLOR_FormatYUV420Planar) oder COLOR_FormatYUV420PackedSemiPlanar (entspricht COLOR_FormatYUV420SemiPlanar). Es wird DRINGEND EMPFOHLEN, beide zu unterstützen.

5.1.7. Video-Codecs

• Für eine akzeptable Qualität von Webvideostreaming- und Videokonferenzdiensten SOLLTEN Geräteimplementierungen einen Hardware-VP8-Codec verwenden, der die Anforderungen erfüllt.

Wenn Geräteimplementierungen einen Videodecoder oder ‑encoder enthalten:

• [C-1-1] Videocodecs MÜSSEN Ausgabebytebuffer- und Eingabebytebuffergrößen unterstützen, die das größtmögliche komprimierte und unkomprimierte Frame gemäß Standard und Konfiguration aufnehmen können, ohne jedoch zu viel Speicherplatz zu belegen.

• [C-1-2] Video-Encoder und ‑Decoder MÜSSEN flexible YUV420 8:8:8-Farbformate (COLOR_FormatYUV420Flexible) über CodecCapabilities unterstützen.

• [C-1-3] Video-Encoder und ‑Decoder MÜSSEN mindestens eines der planaren oder semiplanaren YUV420-Farbformate 8:8:8 unterstützen: COLOR_FormatYUV420PackedPlanar (entspricht COLOR_FormatYUV420Planar) oder COLOR_FormatYUV420PackedSemiPlanar (entspricht COLOR_FormatYUV420SemiPlanar). Es wird DRINGEND EMPFOHLEN, beide zu unterstützen.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, dass Video-Encoder und ‑Decoder mindestens eines der folgenden hardwareoptimierten planaren oder semiplanaren YUV420-8:8:8-Farbformate unterstützen: YV12, NV12, NV21 oder ein entsprechendes anbieteroptimiertes Format.

• [C-1-5] Videodecoder, die ein Format mit hoher Bittiefe (mindestens 9 Bit pro Kanal) unterstützen, MÜSSEN ein entsprechendes 8‑Bit-Format ausgeben können, wenn dies von der Anwendung angefordert wird. Dies MUSS durch die Unterstützung eines YUV420-Farbformats mit 8:8:8 über android.media.MediaCodecInfo abgebildet werden.

Wenn Geräteimplementierungen die Unterstützung von HDR-Profilen über Display.HdrCapabilities ankündigen, gilt Folgendes:

• [C-2-1] MUSS das Parsen und die Verarbeitung statischer HDR-Metadaten unterstützen.

Wenn Geräteimplementierungen die Unterstützung von Intra-Refresh über FEATURE_IntraRefresh in der Klasse MediaCodecInfo.CodecCapabilities ankündigen, gilt Folgendes:

• [C-3-1] MUSS Aktualisierungszeiträume im Bereich von 10 bis 60 Frames unterstützen und innerhalb von 20% des konfigurierten Aktualisierungszeitraums genau arbeiten.

Sofern die Anwendung nicht anders angibt (mit dem Formatierungsschlüssel KEY_COLOR_FORMAT), gilt für Implementierungen von Videodecodern Folgendes:

• [C-4-1] MUSS standardmäßig das für die Hardwareanzeige optimierte Farbformat verwenden, wenn die Konfiguration über die Surface-Ausgabe erfolgt.

• [C-4-2] MUSS standardmäßig ein für das CPU-Lesen optimiertes YUV420-Farbformat mit 8:8:8 verwenden, wenn die Ausgabe nicht über eine Oberfläche erfolgt.

5.1.8. Liste der Video-Codecs

Format/Codec	Details	Unterstützte Dateitypen/Containerformate
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, nur Decodierung)
H.264 AVC	Weitere Informationen finden Sie in Abschnitt 5.2 und 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, nicht suchbar) Matroska (.mkv, nur Decodierung)
H.265 HEVC	Weitere Informationen finden Sie in Abschnitt 5.3.	MPEG-4 (.mp4) Matroska (.mkv, nur Decodierung)
MPEG-2	Profil "Main"	MPEG2-TS (.ts, nicht suchbar) MPEG-4 (.mp4, nur Dekodierung) Matroska (.mkv, nur Decodierung)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, nur Decodierung)
VP8	Weitere Informationen finden Sie in Abschnitt 5.2 und 5.3.	WebM (.webm) Matroska (.mkv)
VP9	Weitere Informationen finden Sie in Abschnitt 5.3.	WebM (.webm) Matroska (.mkv)
AV1	Weitere Informationen finden Sie in Abschnitt 5.2 und Abschnitt 5.3.	MPEG-4 (.mp4) Matroska (.mkv, nur Decodierung)

5.1.9. Sicherheit von Media-Codecs

Geräteimplementierungen MÜSSEN die unten beschriebenen Sicherheitsfunktionen für Media-Codecs einhalten.

Android unterstützt OMX, eine plattformübergreifende API zur Multimedia-Beschleunigung, sowie Codec 2.0, eine API zur Multimedia-Beschleunigung mit geringem Overhead.

Wenn Geräteimplementierungen Multimedia unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN Unterstützung für Media-Codecs entweder über OMX- oder Codec 2.0-APIs (oder beides) wie im Open-Source-Projekt für Android bieten und die Sicherheitsvorkehrungen nicht deaktivieren oder umgehen. Das bedeutet nicht, dass jeder Codec entweder die OMX- oder die Codec 2.0-API verwenden MUSS, sondern nur, dass die Unterstützung für mindestens eine dieser APIs verfügbar sein MUSS und die Unterstützung für die verfügbaren APIs die vorhandenen Sicherheitsvorkehrungen umfassen MUSS.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die Codec 2.0 API zu unterstützen.

Wenn Geräteimplementierungen die Codec 2.0 API nicht unterstützen, gilt Folgendes:

• [C-2-1] MUSS für jedes vom Gerät unterstützte Mediaformat und jeden Mediatyp (Encoder oder Decoder) den entsprechenden OMX-Softwarecodec aus dem Android Open Source Project (falls verfügbar) enthalten.

• [C-2-2] Codecs, deren Namen mit „OMX.google.“ beginnen MUSS auf dem Quellcode des Open-Source-Projekts für Android basieren.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, dass die OMX-Software-Codecs in einem Codec-Prozess ausgeführt werden, der keinen Zugriff auf Hardwaretreiber außer Memory-Mappern hat.

Wenn Geräteimplementierungen die Codec 2.0 API unterstützen, gilt Folgendes:

• [C-3-1] MUSS für jedes vom Gerät unterstützte Mediaformat und jeden Typ (Encoder oder Decoder) den entsprechenden Codec 2.0-Softwarecodec aus dem Open-Source-Projekt für Android enthalten (sofern verfügbar).

• [C-3-2] MUSS die Codec 2.0-Software-Codecs im Software-Codec-Prozess unterbringen, wie im Open-Source-Projekt für Android vorgesehen, um den Zugriff auf Software-Codecs genauer zu gewähren.

• [C-3-3] Codecs, deren Namen mit „c2.android.“ beginnen MUSS auf dem Quellcode des Open-Source-Projekts für Android basieren.

5.1.10. Media-Codec-Charakterisierung

Wenn Geräteimplementierungen Media-Codecs unterstützen, gilt Folgendes:

• [C-1-1] MUSS über die API MediaCodecInfo korrekte Werte für die Media-Codec-Charakterisierung zurückgeben.

Insbesondere:

• [C-1-2] Codecs mit Namen, die mit „OMX.“ beginnen. MÜSSEN die OMX-APIs verwenden und Namen haben, die den OMX IL-Namensrichtlinien entsprechen.

• [C-1-3] Codecs, deren Namen mit „c2.“ beginnen MÜSSEN die Codec 2.0 API verwenden und Namen haben, die den Codec 2.0-Namensrichtlinien für Android entsprechen.

• [C-1-4] Codecs mit Namen, die mit „OMX.google.“ oder „c2.android.“ beginnen DARF NICHT als anbieter- oder hardwarebeschleunigt gekennzeichnet werden.

• [C-1-5] Codecs, die in einem Codec-Prozess (Anbieter oder System) ausgeführt werden, der Zugriff auf andere Hardwaretreiber als Speicherzuweiser und Mapper hat, DÜRFEN NICHT als reine Software gekennzeichnet werden.

• [C-1-6] Codecs, die nicht im Open-Source-Projekt für Android enthalten sind oder nicht auf dem Quellcode in diesem Projekt basieren, MÜSSEN als Anbieter gekennzeichnet werden.

• [C-1-7] Codecs, die Hardwarebeschleunigung nutzen, MÜSSEN als hardwarebeschleunigt gekennzeichnet werden.

• [C-1-8] Codec-Namen DÜRFEN NICHT irreführend sein. Codecs mit dem Namen „decoders“ MÜSSEN beispielsweise die Decodierung unterstützen und Codecs mit dem Namen „encoders“ MÜSSEN die Codierung unterstützen. Codecs mit Namen, die Medienformate enthalten, MÜSSEN diese Formate unterstützen.

Wenn Geräteimplementierungen Videocodecs unterstützen:

• [C-2-1] Für alle Videocodecs MUSS die erreichbare Framerate für die folgenden Größen angegeben werden, sofern der Codec diese unterstützt:

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	176 × 144 Pixel (H263, MPEG2, MPEG4) 352 × 288 Pixel (MPEG4-Encoder, H263, MPEG2) 320 × 180 px (VP8, VP8) 320 × 240 Pixel (andere)	704 × 576 Pixel (H263) 640 × 360 px (VP8, VP9) 640 × 480 Pixel (MPEG4-Encoder) 720 × 480 Pixel (andere, AV1)	1408 × 1152 Pixel (H263) 1280 × 720 Pixel (andere, AV1)	1920 × 1080 Pixel (außer MPEG4, AV1)	3840 × 2160 px (HEVC, VP9, AV1)

• [C-2-2] Für Videocodecs, die als hardwarebeschleunigt gekennzeichnet sind, MUSS die Leistungspunktinformation veröffentlicht werden. Sie MÜSSEN jeweils alle unterstützten Standard-Leistungspunkte (in der PerformancePoint-API aufgeführt) auflisten, sofern sie nicht von einem anderen unterstützten Standard-Leistungspunkt abgedeckt werden.

• Außerdem SOLLTEN sie erweiterte Leistungspunkte veröffentlichen, wenn sie eine nachhaltige Videoleistung unterstützen, die nicht zu den aufgeführten Standardleistungen gehört.

5.2 Videocodierung

Wenn Geräteimplementierungen einen beliebigen Video-Encoder unterstützen und ihn für Drittanbieter-Apps verfügbar machen und
MediaFormat.KEY_BITRATE_MODE auf BITRATE_MODE_VBR festlegen, damit der Encoder im Modus mit variabler Bitrate arbeitet, dann gilt für die codierte Bitrate Folgendes, sofern dies nicht die Mindestqualitätsgrenze beeinträchtigt :

• Sollte in einem gleitenden Fenster nicht mehr als 15% über der Bitrate zwischen Intraframe-Intervallen (I-Frame) liegen.
• Sollte in einem gleitenden Fenster von 1 Sekunde NICHT mehr als 100% über der Bitrate liegen.

Wenn Geräteimplementierungen einen beliebigen Video-Encoder unterstützen und ihn für Drittanbieter-Apps verfügbar machen und MediaFormat.KEY_BITRATE_MODE auf BITRATE_MODE_CBR gesetzt ist, sodass der Encoder im Modus mit konstanter Bitrate arbeitet, gilt für die codierte Bitrate Folgendes:

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, dass die Bitrate in einem gleitenden Fenster von 1 Sekunde NICHT mehr als 15% über der Zielbitrate liegt.

Wenn Geräteimplementierungen ein eingebettetes Display mit einer Diagonale von mindestens 6,35 cm (2,5 Zoll) oder einen Videoausgangsport enthalten oder die Unterstützung einer Kamera über das android.hardware.camera.any-Funktions-Flag deklarieren, gilt Folgendes:

• [C-1-1] MUSS mindestens einen der Video-Encoder VP8 oder H.264 unterstützen und für Drittanbieteranwendungen verfügbar machen.
• SOLLTEN sowohl VP8- als auch H.264-Video-Encoder unterstützen und für Drittanbieteranwendungen verfügbar machen.

Wenn Geräteimplementierungen einen der Video-Encoder für H.264, VP8, VP9 oder HEVC unterstützen und für Drittanbieteranwendungen verfügbar machen, gilt Folgendes:

• [C-2-1] MUSS dynamisch konfigurierbare Bitraten unterstützen.
• SOLLTE variable Frameraten unterstützen, wobei der Video-Encoder die sofortige Framedauer anhand der Zeitstempel der Eingabepuffer bestimmen und seinen Bit-Bucket basierend auf dieser Framedauer zuweisen SOLLTE.

Wenn Geräteimplementierungen den MPEG-4 SP-Video-Encoder unterstützen und ihn für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• SOLLTE dynamisch konfigurierbare Bitraten für den unterstützten Encoder unterstützen.

Wenn Geräteimplementierungen hardwarebeschleunigte Video- oder Bild-Encoder bieten und eine oder mehrere angeschlossene oder einsteckbare Hardwarekameras unterstützen, die über die android.camera-APIs verfügbar gemacht werden:

• [C-4-1] Alle hardwarebeschleunigten Video- und Bild-Encoder MÜSSEN das Codieren von Frames von den Hardwarekameras unterstützen.
• SOLLTE das Codieren von Frames von den Hardwarekameras über alle Video- oder Bild-Encoder unterstützen.

Wenn Geräteimplementierungen die HDR-Codierung unterstützen, gilt Folgendes:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, ein Plug-in für die Seamless Transcoding API bereitzustellen, um vom HDR-Format ins SDR-Format zu konvertieren.

5.2.1. H.263

Wenn Geräteimplementierungen H.263-Encoder unterstützen und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS die QCIF-Auflösung (176 × 144) mit Baseline Profile Level 45 unterstützen. Die SQCIF-Auflösung ist optional.

5.2.2. H.264

Wenn Geräteimplementierungen den H.264-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Baseline-Profil Level 3 unterstützen. Die Unterstützung für ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist jedoch OPTIONAL. Außerdem wird empfohlen, ASO, FMO und RS für das Baseline-Profil von Encodern nicht zu verwenden, um die Kompatibilität mit anderen Android-Geräten aufrechtzuerhalten.
• [C-1-2] MUSS die SD-Videocodierungsprofile (Standard Definition) in der folgenden Tabelle unterstützen.
• SOLLTE Main Profile Level 4 unterstützen.
• SOLLTE die HD-Videocodierungsprofile (High Definition) gemäß der folgenden Tabelle unterstützen.

Wenn Geräteimplementierungen über die Media APIs die Unterstützung der H.264-Codierung für Videos mit einer Auflösung von 720p oder 1080p melden, gilt Folgendes:

• [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 240 px	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel
Video-Framerate	20 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	384 kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.3. VP8

Wenn Geräteimplementierungen den VP8-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS die SD-Videocodierungsprofile unterstützen.
• SOLLTE die folgenden HD-Videocodierungsprofile (High Definition) unterstützen.
• [C-1-2] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
• Sollte einen Hardware-VP8-Codec bereitstellen, der die Hardware-Codierungsanforderungen für RTC-Projekte von WebM erfüllt, um eine akzeptable Qualität von Web-Videostreaming- und Videokonferenzdiensten zu gewährleisten.

Wenn Geräteimplementierungen über die Media APIs die Unterstützung der VP8-Codierung für Videos mit einer Auflösung von 720p oder 1080p melden, gilt Folgendes:

• [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 180 px	640 × 360 px	1280 × 720 Pixel	1.920 × 1.080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	800 kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.4. VP9

Wenn Geräteimplementierungen den VP9-Codec unterstützen, gilt Folgendes:

• [C-1-2] MUSS Profil 0, Level 3 unterstützen.
• [C-1-1] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
• [C-1-3] MUSS CodecPrivate-Daten generieren.
• Sollte die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die in der folgenden Tabelle angegebenen HD-Decodierungsprofile zu unterstützen, wenn ein Hardware-Encoder vorhanden ist.

	SD	HD 720p	HD 1080p	UHD
Videoauflösung	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel	3840 × 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Wenn Geräteimplementierungen über die Media APIs die Unterstützung von Profil 2 oder Profil 3 angeben:

• Die Unterstützung des 12-Bit-Formats ist OPTIONAL.

5.2.5. H.265

Wenn Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Main Profile Level 3 bis zu einer Auflösung von 512 × 512 unterstützen.
• [C-SR-1] Es wird DRINGEND EMPFOHLEN, das SD-Profil mit 720 × 480 und die HD-Codierungsprofile zu unterstützen, die in der folgenden Tabelle aufgeführt sind, wenn ein Hardware-Encoder vorhanden ist.

	SD	HD 720p	HD 1080p	UHD
Videoauflösung	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel	3840 × 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

5.2.6. AV1

Wenn Geräteimplementierungen den AV1-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Main Profile unterstützen, einschließlich 8‑Bit- und 10‑Bit-Inhalten.

• [C-1-2] MUSS Leistungsdaten veröffentlichen, d.h. Leistungsdaten über die APIs getSupportedFrameRatesFor() oder getSupportedPerformancePoints() für unterstützte Auflösungen in der Tabelle unten melden.

• [C-1-3] MUSS HDR-Metadaten akzeptieren und in den Bitstream ausgeben

Wenn der AV1-Encoder hardwarebeschleunigt ist, gilt Folgendes:

• [C-2-1] MUSS das Codierungsprofil bis einschließlich HD1080p aus der Tabelle unten unterstützen:

	SD	HD 720p	HD 1080p	UHD
Videoauflösung	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel	3840 × 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	5 Mbit/s	8 Mbit/s	16 Mbit/s	50 Mbit/s

5.3 Videodecodierung

5.3.1. MPEG-2

Wenn Geräteimplementierungen MPEG‑2-Decoder unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Main Profile High Level unterstützen.

5.3.2. H.263

Wenn Geräteimplementierungen H.263-Decoder unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Baseline-Profil Level 30 (CIF-, QCIF- und SQCIF-Auflösungen bei 30 fps und 384 kbit/s) und Level 45 (QCIF- und SQCIF-Auflösungen bei 30 fps und 128 kbit/s) unterstützen.

5.3.3. MPEG-4

Wenn Geräteimplementierungen MPEG‑4-Decoder enthalten, gilt Folgendes:

• [C-1-1] MUSS das Simple Profile Level 3 unterstützen.

5.3.4. H.264

Wenn Geräteimplementierungen H.264-Decoder unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Main Profile Level 3.1 und das Baseline Profile unterstützen. Die Unterstützung von ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist OPTIONAL.
• [C-1-2] Das Gerät MUSS Videos mit den in der folgenden Tabelle aufgeführten SD-Profilen (Standard Definition) decodieren können, die mit dem Baseline Profile und Main Profile Level 3.1 (einschließlich 720p30) codiert sind.
• Sollte Videos mit den HD-Profilen (High Definition) gemäß der folgenden Tabelle decodieren können.

Wenn die Höhe, die von der Methode Display.getSupportedModes() gemeldet wird, gleich oder größer als die Videoauflösung ist, gilt für Geräteimplementierungen Folgendes:

• [C-2-1] MUSS die HD 720p-Videodecodierungsprofile in der folgenden Tabelle unterstützen.
• [C-2-2] MUSS die HD‑Videodecodierungsprofile mit 1080p in der folgenden Tabelle unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 240 px	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	60 fps	30 fps (60 fpsFernsehen)
Video-Bitrate	800 kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.3.5. H.265 (HEVC)

Wenn Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Main Profile Level 3 Main Tier und die SD-Videodecodierungsprofile gemäß der folgenden Tabelle unterstützen.
• Sollte die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
• [C-1-2] MÜSSEN die in der folgenden Tabelle angegebenen HD-Decodierungsprofile unterstützt werden, wenn ein Hardware-Decoder vorhanden ist.

Wenn die Höhe, die von der Methode Display.getSupportedModes() zurückgegeben wird, gleich oder größer als die Videoauflösung ist, gilt Folgendes:

• [C-2-1] Geräteimplementierungen MÜSSEN mindestens eine der folgenden Optionen unterstützen: H.265- oder VP9-Decodierung von 720-, 1080- und UHD-Profilen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	352 × 288 px	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel	3840 × 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30/60 fps (60 fpsFernseher mit H.265-Hardwaredecodierung)	60 fps
Video-Bitrate	600 Kbit/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Wenn Geräteimplementierungen angeben, dass sie ein HDR-Profil über die Media APIs unterstützen:

• [C-3-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR‑Metadaten von der Anwendung akzeptieren sowie das Extrahieren und Ausgeben der erforderlichen HDR‑Metadaten aus dem Bitstream und/oder Container unterstützen.
• [C-3-2] Geräteimplementierungen MÜSSEN HDR-Inhalte auf dem Gerätebildschirm oder an einem Standard-Videoausgang (z.B. HDMI) korrekt anzeigen.

5.3.6. VP8

Wenn Geräteimplementierungen den VP8-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS die SD-Decodierungsprofile in der folgenden Tabelle unterstützen.
• Es SOLLTE ein Hardware-VP8-Codec verwendet werden, der die Anforderungen erfüllt.
• Sollte die HD-Decodierungsprofile in der folgenden Tabelle unterstützen.

Wenn die mit der Methode Display.getSupportedModes() gemeldete Höhe gleich oder größer als die Videoauflösung ist, gilt Folgendes:

• [C-2-1] Geräteimplementierungen MÜSSEN die 720p-Profile in der folgenden Tabelle unterstützen.
• [C-2-2] Geräteimplementierungen MÜSSEN 1080p-Profile in der folgenden Tabelle unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 180 px	640 × 360 px	1280 × 720 Pixel	1.920 × 1.080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30 fps (60 fpsFernsehen)	30 (60 fpsFernsehen)
Video-Bitrate	800 kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.3.7. VP9

Wenn Geräteimplementierungen den VP9-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS die in der folgenden Tabelle angegebenen SD-Videodecodierungsprofile unterstützen.
• Sollte die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.

Wenn Geräteimplementierungen den VP9-Codec und einen Hardware-Decoder unterstützen, gilt Folgendes:

• [C-2-1] MUSS die HD-Decodierungsprofile gemäß der folgenden Tabelle unterstützen.

Wenn die Höhe, die von der Methode Display.getSupportedModes() zurückgegeben wird, gleich oder größer als die Videoauflösung ist, gilt Folgendes:

• [C-3-1] Geräteimplementierungen MÜSSEN mindestens eine der folgenden Decodierungen für die Profile mit 720p, 1080p und UHD unterstützen: VP9 oder H.265.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	320 × 180 px	640 × 360 px	1280 × 720 Pixel	1.920 × 1.080 Pixel	3840 × 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30 fps (60 fpsFernseher mit VP9-Hardware-Decodierung)	60 fps
Video-Bitrate	600 Kbit/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Wenn Geräteimplementierungen über die Media APIs CodecProfileLevel die Unterstützung von VP9Profile2 oder VP9Profile3 angeben:

• Die Unterstützung des 12-Bit-Formats ist OPTIONAL.

Wenn Geräteimplementierungen über die Media APIs die Unterstützung eines HDR-Profils (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) angeben:

• [C-4-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR‑Metadaten (KEY_HDR_STATIC_INFO für alle HDR‑Profile sowie 'KEY_HDR10_PLUS_INFO' für HDR10Plus-Profile) von der Anwendung akzeptieren. Sie MÜSSEN außerdem das Extrahieren und Ausgeben der erforderlichen HDR‑Metadaten aus dem Bitstream und/oder Container unterstützen.
• [C-4-2] Geräteimplementierungen MÜSSEN HDR-Inhalte auf dem Gerätebildschirm oder an einem Standard-Videoausgang (z.B. HDMI) korrekt anzeigen.

5.3.8. Dolby Vision

Wenn Geräteimplementierungen die Unterstützung für den Dolby Vision-Decoder über HDR_TYPE_DOLBY_VISION deklarieren, gilt Folgendes:

• [C-1-1] MUSS einen Extraktor mit Dolby Vision-Unterstützung bereitstellen.

• [C-1-2] Dolby Vision-Inhalte MÜSSEN entweder auf dem Gerätebildschirm oder auf einem externen Bildschirm, der über einen Standard-Videoausgang (z. B. HDMI) angeschlossen ist, richtig angezeigt werden.

• [C-1-3] Die Track-ID der abwärtskompatiblen Basisebene(n) (falls vorhanden) MUSS mit der Track-ID der kombinierten Dolby Vision-Ebene übereinstimmen.

5.3.9. AV1

Wenn Geräteimplementierungen den AV1-Codec unterstützen und ihn für Drittanbieteranwendungen verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS das Main Profile unterstützen, einschließlich 8‑Bit- und 10‑Bit-Inhalten.

Wenn Geräteimplementierungen den AV1-Codec mit einem hardwarebeschleunigten Decoder unterstützen, gilt Folgendes:

• [C-2-1] MUSS mindestens HD-Videodecodierungsprofile mit 720p aus der Tabelle unten decodieren können, wenn die von der Methode Display.getSupportedModes() gemeldete Höhe gleich oder größer als 720p ist.
• [C-2-2] MUSS mindestens HD-Videodecodierungsprofile (1080p) aus der Tabelle unten decodieren können, wenn die von der Methode Display.getSupportedModes() gemeldete Höhe gleich oder größer als 1080p ist.

	SD	HD 720p	HD 1080p	UHD
Videoauflösung	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel	3840 × 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	5 Mbit/s	8 Mbit/s	16 Mbit/s	50 Mbit/s

Wenn Geräteimplementierungen das HDR-Profil über die Media APIs unterstützen, gilt Folgendes:

• [C-3-1] MUSS das Extrahieren und Ausgeben von HDR‑Metadaten aus dem Bitstream und/oder Container unterstützen.

• [C-3-2] HDR-Inhalte MÜSSEN auf dem Gerätebildschirm oder über einen Standard-Videoausgang (z. B. HDMI) korrekt angezeigt werden.

5.4. Audioaufnahmen

Einige der in diesem Abschnitt beschriebenen Anforderungen sind seit Android 4.3 als SHOULD aufgeführt. Die Kompatibilitätsdefinition für zukünftige Versionen wird diese jedoch in MUST ändern. Bestehende und neue Android-Geräte SOLLTEN diese Anforderungen erfüllen, da sie sonst nach einem Upgrade auf die zukünftige Version nicht mit Android kompatibel sind.

5.4.1. Rohdaten der Audioaufnahme und Mikrofoninformationen

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, gilt Folgendes:

• [C-1-1] MUSS die Erfassung von rohen Audioinhalten für jeden AudioRecord- oder AAudio-Eingabestream ermöglichen, der erfolgreich geöffnet wird. Mindestens die folgenden Merkmale MÜSSEN unterstützt werden:

  • Format:Lineare PCM, 16 Bit
  • Abtastraten:8.000, 11.025, 16.000, 44.100, 48.000 Hz
  • Kanäle:Mono
  • Audioquellen:DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, oder VOICE_PERFORMANCE. Dies gilt auch für die entsprechenden Eingabe-Voreinstellungen in AAudio, z. B. AAUDIO_INPUT_PRESET_CAMCORDER.

• Sollte die Aufnahme von Audio-Rohinhalten mit den folgenden Merkmalen ermöglichen:

  • Format: Lineare PCM, 16 Bit und 24 Bit
  • Abtastraten: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 Hz
  • Kanäle: So viele Kanäle wie Mikrofone auf dem Gerät

• [C-1-2] MUSS mit den oben genannten Abtastraten ohne Upsampling erfasst werden.

• [C-1-3] MUSS einen geeigneten Anti-Aliasing-Filter enthalten, wenn die oben genannten Samplingraten durch Downsampling erfasst werden.

• Sollte die Aufnahme von rohen Audioinhalten in AM-Radio- und DVD-Qualität ermöglichen, was die folgenden Merkmale bedeutet:

  • Format: Lineare PCM, 16 Bit
  • Abtastraten: 22.050, 48.000 Hz
  • Kanäle: Stereo

• [C-1-4] MUSS die MicrophoneInfo API berücksichtigen und Informationen zu den verfügbaren Mikrofonen auf dem Gerät, auf die Drittanbieteranwendungen über die AudioManager.getMicrophones() API zugreifen können, für aktive AudioRecord-Vorgänge mit MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED oder VOICE_PERFORMANCE korrekt ausfüllen. Wenn Geräteimplementierungen AM-Radio und die Aufnahme von Rohaudioinhalten in DVD-Qualität ermöglichen, müssen sie:

• [C-2-1] MUSS ohne Upsampling bei einem Verhältnis über 16.000:22.050 oder 44.100:48.000 aufgenommen werden.

• [C-2-2] MUSS für jedes Upsampling oder Downsampling einen geeigneten Anti-Aliasing-Filter enthalten.

5.4.2. Aufnahme für die Spracherkennung

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, gilt Folgendes:

• [C-1-1] MUSS die Audioquelle android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION mit einer der Abtastraten 44.100 und 48.000 aufnehmen.
• [C-1-2] MUSS standardmäßig jegliche Audioverarbeitung zur Rauschunterdrückung deaktivieren, wenn ein Audiostream von der Audioquelle AudioSource.VOICE_RECOGNITION aufgezeichnet wird.

• [C-1-3] MUSS standardmäßig die automatische Verstärkungsregelung deaktivieren, wenn ein Audiostream von der Audioquelle AudioSource.VOICE_RECOGNITION aufgezeichnet wird.

• SOLLTE im mittleren Frequenzbereich einen ungefähr flachen Amplituden-Frequenz-Verlauf aufweisen, insbesondere ±3 dB von 100 Hz bis 4.000 Hz für jedes Mikrofon, das zum Aufzeichnen der Audioquelle für die Spracherkennung verwendet wird.

• [C-SR-1] ES WIRD DRINGEND EMPFOHLEN, dass die Amplitudenpegel im niedrigen Frequenzbereich liegen, insbesondere ±20 dB von 30 Hz bis 100 Hz im Vergleich zum mittleren Frequenzbereich für jedes Mikrofon, das zum Aufzeichnen der Audioquelle für die Spracherkennung verwendet wird.

• [C-SR-2] ES WIRD DRINGEND EMPFOHLEN, dass die Amplitude im Hochfrequenzbereich ±30 dB zwischen 4.000 Hz und 22 kHz im Vergleich zum Mittelfrequenzbereich für jedes Mikrofon beträgt, das zum Aufzeichnen der Audioquelle für die Spracherkennung verwendet wird.

• Die Audioeingabeempfindlichkeit SOLLTE so eingestellt werden, dass eine 1000 Hz-Sinustonquelle, die mit einem Schalldruckpegel von 90 dB (SPL) (gemessen neben dem Mikrofon) wiedergegeben wird, eine ideale Reaktion von RMS 2500 innerhalb eines Bereichs von 1770 und 3530 für 16-Bit-Samples (oder -22,35 dB ±3 dB Full Scale für Gleitkomma-/Doppelpräzisions-Samples) für jedes Mikrofon ergibt, das zum Aufzeichnen der Audioquelle für die Spracherkennung verwendet wird.

• Der Audio-Stream für die Spracherkennung SOLLTE so aufgezeichnet werden, dass die PCM-Amplitudenpegel die Änderungen des Eingabe-SPL über mindestens einen Bereich von 30 dB linear verfolgen, von -18 dB bis +12 dB re 90 dB SPL am Mikrofon.

• SOLLTE den Audio-Stream für die Spracherkennung mit einem THD‑Wert (Total Harmonic Distortion) von unter 1% für 1 kHz bei einem Eingangspegel von 90 dB SPL am Mikrofon aufzeichnen.

Wenn Geräteimplementierungen android.hardware.microphone- und Rauschunterdrückungstechnologien deklarieren, die für die Spracherkennung optimiert sind, gilt Folgendes:

• [C-2-1] Dieser Audioeffekt MUSS über die android.media.audiofx.NoiseSuppressor API gesteuert werden können.
• [C-2-2] Jede Implementierung der Technologie zur Rauschunterdrückung MUSS über das Feld AudioEffect.Descriptor.uuid eindeutig identifiziert werden.

5.4.3. Aufnahme für die Umleitung der Wiedergabe

Die Klasse android.media.MediaRecorder.AudioSource enthält die Audioquelle REMOTE_SUBMIX.

Wenn Geräteimplementierungen sowohl android.hardware.audio.output als auch android.hardware.microphone deklarieren, gilt Folgendes:

• [C-1-1] Die Audioquelle REMOTE_SUBMIX MUSS korrekt implementiert werden, sodass bei der Aufzeichnung über die android.media.AudioRecord API aus dieser Audioquelle ein Mix aller Audiostreams erfasst wird, mit Ausnahme der folgenden:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. Echounterdrückung

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, gilt Folgendes:

• Es SOLLTE eine Acoustic Echo Canceler-Technologie (AEC) implementiert werden, die für die Sprachkommunikation optimiert ist und auf den Erfassungspfad angewendet wird, wenn die Erfassung mit AudioSource.VOICE_COMMUNICATION erfolgt.

5.4.5. Gleichzeitige Aufnahme

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, MÜSSEN sie die gleichzeitige Aufnahme wie in diesem Dokument beschrieben implementieren. Im Detail:

• [C-1-1] Der gleichzeitige Zugriff auf das Mikrofon durch einen Barrierefreiheitsdienst, der mit AudioSource.VOICE_RECOGNITION aufzeichnet, und mindestens eine Anwendung, die mit einem beliebigen AudioSource aufzeichnet, MUSS möglich sein.
• [C-1-2] MUSS den gleichzeitigen Zugriff auf das Mikrofon durch eine vorinstallierte Anwendung mit einer Assistant-Rolle und mindestens eine Anwendung, die mit einem beliebigen AudioSource außer AudioSource.VOICE_COMMUNICATION oder AudioSource.CAMCORDER aufnimmt, ermöglichen.
• [C-1-3] Die Audioaufnahme MUSS für alle anderen Anwendungen außer für einen Bedienungshilfe stummgeschaltet werden, während eine Anwendung mit AudioSource.VOICE_COMMUNICATION oder AudioSource.CAMCORDER aufnimmt. Wenn eine App jedoch über AudioSource.VOICE_COMMUNICATION aufzeichnet, kann eine andere App den Sprachanruf aufzeichnen, wenn es sich um eine privilegierte (vorinstallierte) App mit der Berechtigung CAPTURE_AUDIO_OUTPUT handelt.

• [C-1-4] Wenn zwei oder mehr Anwendungen gleichzeitig aufzeichnen und keine der Apps eine Benutzeroberfläche im Vordergrund hat, empfängt die App, die die Aufzeichnung zuletzt gestartet hat, Audio.

5.5. Audiowiedergabe

Android unterstützt die Audiowiedergabe von Apps über das in Abschnitt 7.8.2 definierte Audioausgabegerät.

5.5.1. Wiedergabe von Rohaudio

Wenn Geräteimplementierungen android.hardware.audio.output deklarieren, gilt Folgendes:

• [C-1-1] Die Wiedergabe von rohen Audioinhalten mit den folgenden Merkmalen MUSS möglich sein:

  • Quellformate: Lineare PCM, 16 Bit, 8 Bit, Gleitkomma
  • Kanäle: Mono, Stereo, gültige Mehrkanal-Konfigurationen mit bis zu 8 Kanälen
  • Abtastraten (in Hz):
    • 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 bei den oben aufgeführten Channelkonfigurationen
    • 96.000 Hz in Mono und Stereo

5.5.2. Audioeffekte

Android bietet eine API für Audioeffekte für Geräteimplementierungen.

Wenn Geräteimplementierungen das Feature android.hardware.audio.output deklarieren, gilt Folgendes:

• [C-1-1] MUSS die Implementierungen von EFFECT_TYPE_EQUALIZER und EFFECT_TYPE_LOUDNESS_ENHANCER unterstützen, die über die AudioEffect-Unterklassen Equalizer und LoudnessEnhancer gesteuert werden können.

• [C-1-2] MUSS die Implementierung der Visualizer API unterstützen, die über die Klasse Visualizer gesteuert werden kann.

• [C-1-3] MUSS die EFFECT_TYPE_DYNAMICS_PROCESSING-Implementierung unterstützen, die über die AudioEffect-Unterklasse DynamicsProcessing gesteuert werden kann.

• [C-1-4] MUSS Audioeffekte mit Gleitkomma-Ein- und ‑Ausgabe unterstützen, wenn die Effektergebnisse an die Audio-Pipeline des Frameworks zurückgegeben werden. Damit sind typische Insert- oder Aux-Effekte wie der Equalizer gemeint. Ein gleichwertiges Verhalten wird dringend empfohlen, wenn die Effektergebnisse nicht über die Audio-Pipeline des Frameworks sichtbar sind, z. B. bei der Nachbearbeitung oder ausgelagerten Effekten.

• [C-1-5] MUSS dafür sorgen, dass Audioeffekte mehrere Kanäle bis zur Anzahl der Mixerkanäle unterstützen, auch bekannt als FCC_LIMIT, wenn die Effektergebnisse an die Audio-Pipeline des Frameworks zurückgegeben werden. Dies bezieht sich auf typische Insert- oder Aux-Effekte, schließt jedoch Spezialeffekte wie Downmix-, Upmix- oder Spatialisierungseffekte aus, die die Anzahl der Kanäle ändern. Ein ähnliches Verhalten wird empfohlen, wenn die Effekte nicht über die Audio-Pipeline des Frameworks sichtbar sind, z. B. bei der Nachbearbeitung oder bei ausgelagerten Effekten.

• Sollte die Implementierungen EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB und EFFECT_TYPE_VIRTUALIZER unterstützen, die über die AudioEffect-Unterklassen BassBoost, EnvironmentalReverb, PresetReverb und Virtualizer gesteuert werden können.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, Effekte in Gleitkomma- und Mehrkanalformaten zu unterstützen.

5.5.3. Audioausgabelautstärke

Automotive-Geräteimplementierungen:

• Die Lautstärke sollte für jeden Audiostream separat angepasst werden können. Dazu werden der Inhaltstyp oder die Verwendung gemäß AudioAttributes und die Verwendung von Audio im Auto gemäß android.car.CarAudioManager verwendet.

5.5.4. Audio-Offload

Wenn Geräteimplementierungen die Audio-Offload-Wiedergabe unterstützen, gilt Folgendes:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die wiedergegebenen lückenlosen Audioinhalte zwischen zwei Clips mit demselben Format zu kürzen, wenn dies durch die AudioTrack gapless API und den Media-Container für MediaPlayer angegeben wird.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, die Offload-Wiedergabe für die Formate AAC, MP3, OPUS und PCM zu implementieren.

5.5.5. Wiedergabeparameter

5.6. Audiolatenz

Die Audiolatenz ist die Zeitverzögerung, die auftritt, wenn ein Audiosignal ein System durchläuft. Viele Arten von Anwendungen sind auf kurze Latenzzeiten angewiesen, um Echtzeit-Soundeffekte zu erzielen.

Im Zusammenhang mit diesem Abschnitt gelten die folgenden Definitionen:

• Ausgabelatenz. Das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung einen Frame mit PCM-codierten Daten schreibt, und dem Zeitpunkt, zu dem der entsprechende Ton über einen Wandler auf dem Gerät an die Umgebung ausgegeben wird oder das Signal das Gerät über einen Port verlässt und extern beobachtet werden kann.

• Kaltstartlatenz Die Zeit zwischen dem Starten eines Ausgabestreams und der Präsentationszeit des ersten Frames basierend auf Zeitstempeln, wenn das Audioausgabesystem vor der Anfrage inaktiv und heruntergefahren war.

• Latenz der kontinuierlichen Ausgabe. Die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät Audio wiedergegeben hat.

• Eingabelatenz. Das Intervall zwischen dem Zeitpunkt, zu dem ein Schall vom Gerät über einen On-Device-Wandler wiedergegeben wird oder ein Signal über einen Port in das Gerät gelangt, und dem Zeitpunkt, zu dem eine Anwendung den entsprechenden Frame von PCM-codierten Daten liest.

• Verlorene Eingabe Der erste Teil eines Eingangssignals, der nicht verwendet werden kann oder nicht verfügbar ist.

• Kaltstartlatenz. Die Zeit zwischen dem Start des Streams und dem Empfang des ersten gültigen Frames, wenn das Audioeingabesystem vor der Anfrage inaktiv war und heruntergefahren wurde.

• Kontinuierliche Eingabelatenz: Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufnimmt.

• kontinuierliche Roundtrip-Latenz. Die Summe aus kontinuierlicher Eingabelatenz, kontinuierlicher Ausgabelatenz und einem Pufferzeitraum. Der Pufferzeitraum gibt der App Zeit, das Signal zu verarbeiten und die Phasendifferenz zwischen Ein- und Ausgabestreams zu verringern.

• OpenSL ES PCM-Pufferwarteschlangen-API. Die Gruppe der PCM-bezogenen OpenSL ES-APIs im Android NDK.

• AAudio Native Audio API Die Gruppe der AAudio-APIs im Android NDK.

• Timestamp. Ein Paar aus einer relativen Frame-Position in einem Stream und der geschätzten Zeit, zu der dieser Frame in die Audioverarbeitungs-Pipeline auf dem zugehörigen Endpunkt eintritt oder diese verlässt. Siehe auch AudioTimestamp.

• glitch. Eine vorübergehende Unterbrechung oder ein falscher Sample-Wert im Audiosignal, der in der Regel durch einen Buffer-Underrun für die Ausgabe, einen Buffer-Overrun für die Eingabe oder eine andere Quelle für digitales oder analoges Rauschen verursacht wird.

• Mittlere absolute Abweichung vom Medianwert Der Durchschnitt des Absolutwerts der Abweichungen vom Mittelwert für eine Reihe von Werten.

• Die Tap-to-Tone-Latenz (TTL), gemessen von CTS Verifier, ist die Zeit zwischen dem Tippen auf den Bildschirm und dem Zeitpunkt, zu dem ein durch das Tippen erzeugter Ton über den Lautsprecher zu hören ist. Der Wert wird über fünf Messungen mit der nativen AAudio-Audio-API für die Ausgabe gemittelt.

• Die Round-Trip-Latenz (RTL), gemessen vom CTS-Verifier, ist die durchschnittliche kontinuierliche Latenz über 5 Messungen, gemessen über einen Loopback-Pfad, der die Ausgabe über die native AAudio-Audio-API zurück zur Eingabe leitet.

  Die Loopback-Pfade sind:

  • Lautsprecher/Mikrofon: Integrierter Lautsprecher bis integriertes Mikrofon.
  • Analog: 3,5-mm-Analoganschluss und ein Loopback-Adapter.
  • USB: USB-auf-3,5-mm-Adapter und Loopback-Adapter oder USB-Audio-Interface und Loopback-Kabel.

• FEATURE_AUDIO_LOW_LATENCY Das Feature android.hardware.audio.low_latency ist deklariert.

• FEATURE_AUDIO_PRO. Das Feature android.hardware.audio.pro ist deklariert.

• MPC Media Performance Class

• Latenz des Head-Trackings: Die Zeit, die vergeht, bis die durch die Inertiale Messeinheit (IMU) erfasste Kopfbewegung von den Kopfhörer-Schallwandlern als Änderung des durch diese Bewegung verursachten Klangs erkannt wird.

Wenn Geräteimplementierungen android.hardware.audio.output deklarieren, MÜSSEN sie die folgenden Anforderungen erfüllen oder übertreffen:

• [C-1-1] Anforderung in Android 15 entfernt.

• [C-1-2] Die Latenz der Ausgabe bei Kaltstart beträgt maximal 500 Millisekunden.

• [C-1-3] Das Öffnen eines Ausgabestreams mit AAudioStreamBuilder_openStream() DARF nicht länger als 1.000 Millisekunden dauern.

• [C-1-4] Die berechneten Umlaufzeiten auf Grundlage der von AAudioStream_getTimestamp zurückgegebenen Ein- und Ausgabestempel MÜSSEN innerhalb von 200 ms der gemessenen Umlaufzeit für AAUDIO_PERFORMANCE_MODE_NONE und AAUDIO_PERFORMANCE_MODE_LOW_LATENCY für Lautsprecher, kabelgebundene Headsets und kabellose Headsets liegen.

• [C-SR-1] Anforderung in Android 15 entfernt.

• [C-SR-2] Anforderung in Android 15 entfernt.

• [C-SR-4] Anforderung in Android 15 entfernt.

• [C-SR-5] Anforderung in Android 15 entfernt.

• [C-SR-6] Anforderung in Android 15 entfernt.

• [C-SR-7] Anforderung in Android 15 entfernt.

• [C-2-1] Anforderung in Android 15 entfernt.

Wenn Geräteimplementierungen android.hardware.microphone enthalten, MÜSSEN sie die folgenden Anforderungen an die Audioeingabe erfüllen:

• [C-3-1] Anforderung in Android 15 entfernt.

• [C-3-2] Die Latenz der Eingabe bei Kaltstart beträgt maximal 500 Millisekunden.

• [C-3-3] Das Öffnen eines Eingabestreams mit AAudioStreamBuilder_openStream() MUSS weniger als 1.000 Millisekunden dauern.

• [C-SR-8] Anforderung in Android 15 entfernt.

• [C-SR-11] Anforderung in Android 15 entfernt.

• [C-SR-12] Anforderung in Android 15 entfernt.

In der folgenden Tabelle sind die Anforderungen für RTL für Implementierungen von Mobilgeräten gemäß 2.2.1 definiert, die android.hardware.audio.output und android.hardware.microphone deklarieren.

In der folgenden Tabelle sind die Anforderungen für TTL für Implementierungen von Mobilgeräten gemäß 2.2.1 definiert, die android.hardware.audio.output und android.hardware.microphone deklarieren.

Wenn Geräteimplementierungen die Unterstützung für spatial audio mit Erfassung von Kopfbewegungen enthalten und das Flag PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY deklarieren, gilt Folgendes:

• [C-4-1] Die maximale Latenz zwischen Head-Tracking und Audio-Update MUSS 300 ms betragen.

5.7. Netzwerkprotokolle

Geräteimplementierungen MÜSSEN die Media-Netzwerkprotokolle für die Audio- und Videowiedergabe unterstützen, wie in der Android SDK-Dokumentation angegeben.

Für jeden Codec und jedes Containerformat, das eine Geräteimplementierung unterstützen muss, gilt Folgendes:

• [C-1-1] MUSS diesen Codec oder Container über HTTP und HTTPS unterstützen.

• [C-1-2] MUSS die entsprechenden Media-Segmentformate gemäß der Tabelle unten über das HTTP Live Streaming-Protokollentwurf, Version 7 unterstützen.

• [C-1-3] MUSS die entsprechenden RTSP-Nutzlastformate unterstützen, wie in der RTSP-Tabelle unten dargestellt. Ausnahmen finden Sie in den Tabellenfußnoten in Abschnitt 5.1.

Formate für Media-Segmente

Segmentformate	Referenz(en)	Erforderliche Codec-Unterstützung
MPEG-2-Transportstrom	ISO 13818	Video-Codecs: H264 AVC MPEG-4 SP MPEG-2 Weitere Informationen zu H264 AVC, MPEG2-4 SP und MPEG-2 finden Sie im Abschnitt 5.1.8. Audio-Codecs: AAC Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.3.
AAC mit ADTS-Framing und ID3-Tags	ISO 13818-7	Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1 .
WebVTT	WebVTT

RTSP (RTP, SDP)

Profilname	Referenz(en)	Erforderliche Codec-Unterstützung
H264 AVC	RFC 6184	Weitere Informationen zu H264 AVC finden Sie in Abschnitt 5.1.8.
MP4A-LATM	RFC 6416	Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.3.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Weitere Informationen zu H263 finden Sie in Abschnitt 5.1.8.
H263-2000	RFC 4629	Weitere Informationen zu H263 finden Sie in Abschnitt 5.1.8.
AMR	RFC 4867	Weitere Informationen zu AMR-NB finden Sie in Abschnitt 5.1.3.
AMR-WB	RFC 4867	Weitere Informationen zu AMR-WB finden Sie in Abschnitt 5.1.3.
MP4V-ES	RFC 6416	Weitere Informationen zu MPEG-4 SP finden Sie Abschnitt 5.1.8.
mpeg4-generic	RFC 3640	Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.3.
MP2T	RFC 2250	Weitere Informationen finden Sie unter MPEG-2 Transport Stream unter HTTP Live Streaming.

5.8. Sichere Medien

Wenn Geräteimplementierungen die sichere Videoausgabe unterstützen und sichere Oberflächen unterstützen können, gilt Folgendes:

• [C-1-1] MÜSSEN die Unterstützung für Display.FLAG_SECURE deklarieren.

Wenn Geräteimplementierungen die Unterstützung für Display.FLAG_SECURE und das Protokoll für die kabellose Übertragung deklarieren, gilt Folgendes:

• [C-2-1] Die Verbindung MUSS mit einem kryptografisch starken Mechanismus wie HDCP 2.x oder höher für die über drahtlose Protokolle wie Miracast verbundenen Displays gesichert werden.

Wenn Geräteimplementierungen Unterstützung für Display.FLAG_SECURE und kabelgebundene externe Displays deklarieren, gilt Folgendes:

• [C-3-1] MUSS HDCP 1.2 oder höher für alle externen Displays unterstützen, die über einen für Nutzer zugänglichen kabelgebundenen Port angeschlossen sind.

5.9. Musical Instrument Digital Interface (MIDI)

Wenn Geräteimplementierungen die Unterstützung für das Feature android.software.midi über die Klasse android.content.pm.PackageManager melden, müssen sie:

• [C-1-1] MUSS MIDI über alle MIDI-fähigen Hardware-Transports unterstützen, für die sie eine generische Nicht-MIDI-Verbindung bereitstellen, wobei diese Transports Folgendes sind:

  • USB-Hostmodus, Abschnitt 7.7
  • MIDI über Bluetooth LE in zentraler Rolle, Abschnitt 7.4.3

• [C-1-2] MUSS den Software-Transport für MIDI zwischen Apps (virtuelle MIDI-Geräte) unterstützen.

• [C-1-3] MUSS libamidi.so (native MIDI-Unterstützung) enthalten

• SOLLTE den MIDI-über-USB-Peripheriemodus unterstützen, Abschnitt 7.7

5.10. Professionelles Audio

Wenn Geräteimplementierungen die Unterstützung für das Feature android.hardware.audio.pro über die Klasse android.content.pm.PackageManager melden, gilt Folgendes:

• [C-1-1] MÜSSEN die Unterstützung für die Funktion android.hardware.audio.low_latency melden.

• [C-1-2] MUSS die Latenzanforderungen für FEATURE_AUDIO_PRO gemäß Abschnitt 5.6 Audio-Latenz erfüllen .

• [C-1-3] MUSS einen oder mehrere USB-Ports enthalten, die den USB-Host-Modus und den USB-Peripheriemodus unterstützen.

• [C-1-4] MÜSSEN die Unterstützung für die Funktion android.software.midi melden.

• [C-1-5] Die Anforderungen an die USB-Audio-Latenz müssen mit der AAudio Native Audio API und AAUDIO_PERFORMANCE_MODE_LOW_LATENCY erfüllt werden.

• [C-1-6] Die Kaltstartlatenz der Ausgabe MUSS 200 Millisekunden oder weniger betragen.

• [C-1-7] MUSS eine Kaltstart-Eingabelatenz von höchstens 200 Millisekunden haben.

Wenn Geräteimplementierungen einen 3,5‑mm-Audioanschluss mit 4 Leitern enthalten, gilt Folgendes:

• [C-2-2] MUSS dem Abschnitt Mobile device (jack) specifications der Wired Audio Headset Specification (v1.1) entsprechen.

Wenn in Geräteimplementierungen eine 3,5‑mm-Audiobuchse mit 4 Leitern fehlt und USB-Ports enthalten sind, die den USB-Hostmodus unterstützen, gilt Folgendes:

• [C-3-1] MÜSSEN die USB-Audioklasse implementieren.

5.11. Aufnahme für „Unprocessed“

Android unterstützt die Aufnahme von unbearbeitetem Audio über die Audioquelle android.media.MediaRecorder.AudioSource.UNPROCESSED. In OpenSL ES kann darauf mit dem Aufnahmepreset SL_ANDROID_RECORDING_PRESET_UNPROCESSED zugegriffen werden.

Wenn Geräteimplementierungen eine unverarbeitete Audioquelle unterstützen und Drittanbieter-Apps zur Verfügung stellen möchten, müssen sie:

• [C-1-1] MUSS die Unterstützung über die Eigenschaft android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED melden.

• [C-1-2] MUSS im mittleren Frequenzbereich ungefähr flache Amplituden-Frequenz-Eigenschaften aufweisen, d. h. ±10 dB von 100 Hz bis 7.000 Hz für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird.

• [C-1-3] MUSS Amplitudenpegel im Niederfrequenzbereich aufweisen, insbesondere ±20 dB von 5 Hz bis 100 Hz im Vergleich zum Mittelfrequenzbereich für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird.

• [C-1-4] MUSS Amplitudenpegel im Hochfrequenzbereich aufweisen, insbesondere ±30 dB von 7.000 Hz bis 22 kHz im Vergleich zum Mittelfrequenzbereich für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird.

• [C-1-5] Die Empfindlichkeit des Audioeingangs MUSS so eingestellt sein, dass eine bei 94 dB Schalldruckpegel (SPL) wiedergegebene 1.000 Hz-Sinustonquelle eine Reaktion mit einem RMS-Wert von 520 für 16-Bit-Samples (oder -36 dB Full Scale für Gleitkomma-/Double-Precision-Samples) für jedes Mikrofon ergibt, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird.

• [C-1-6] MUSS für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird, einen Rauschabstand (Signal-to-Noise Ratio, SNR) von mindestens 60 dB haben. Das SNR wird als Differenz zwischen 94 dB SPL und dem äquivalenten SPL des Eigenrauschens (A-gewichtet) gemessen.

• [C-1-7] MUSS für 1 kHz bei einem Eingangspegel von 90 dB SPL an jedem Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird, eine Gesamtharmonisierungsunterbrechung (Total Harmonic Distortion, THD) von weniger als 1% aufweisen.

• [C-1-8] Es dürfen keine anderen Signalverarbeitungen (z.B. automatische Verstärkungsregelung, Hochpassfilter oder Echounterdrückung) im Pfad vorhanden sein, außer einem Pegelmultiplikator, um den Pegel in den gewünschten Bereich zu bringen. Dies bedeutet:

  • [C-1-9] Wenn in der Architektur aus irgendeinem Grund eine Signalverarbeitung vorhanden ist, MUSS sie deaktiviert werden und darf keine Verzögerung oder zusätzliche Latenz im Signalpfad verursachen.
  • [C-1-10] Der Pegelmultiplikator darf sich zwar auf dem Signalweg befinden, darf aber KEINE Verzögerung oder Latenz auf dem Signalweg verursachen.

Alle SPL-Messungen werden direkt neben dem zu testenden Mikrofon durchgeführt. Bei Konfigurationen mit mehreren Mikrofonen gelten diese Anforderungen für jedes Mikrofon.

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, aber keine Audioquelle ohne Verarbeitung unterstützen, gilt Folgendes:

• [C-2-1] Die AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)-API-Methode MUSS null zurückgeben, um das Fehlen von Unterstützung richtig anzugeben.

• [C-SR-1] wird DRINGEND EMPFOHLEN, um so viele Anforderungen wie möglich an den Signalpfad für die unverarbeitete Aufnahmequelle zu erfüllen.

5.12. HDR-Video

Android 13 unterstützt die HDR-Technologien, die in einem demnächst erscheinenden Dokument beschrieben werden.

Pixelformat

Wenn ein Videodecoder die Unterstützung für COLOR_FormatYUVP010 angibt, gilt Folgendes:

• [C-1-1] MUSS das P010-Format für das Lesen durch die CPU unterstützen (ImageReader, MediaImage, ByteBuffer). In Android 13 wurde P010 gelockert, um einen beliebigen Stride für die Y- und UV-Ebenen zu ermöglichen.

• [C-1-2] Der P010-Ausgabepuffer MUSS von der GPU abgetastet werden können (wenn er mit GPU_SAMPLING-Verwendung zugewiesen wird). Dies ermöglicht die GPU-Zusammensetzung und das benutzerdefinierte Tone Mapping durch Apps.

Wenn ein Videodecoder die Unterstützung von COLOR_Format32bitABGR2101010 angibt, gilt Folgendes:

• [C-2-1] MUSS das Format RGBA_1010102 für die Ausgabefläche und die CPU-lesbare Ausgabe (ByteBuffer-Ausgabe) unterstützen.

Wenn ein Video-Encoder mit der Unterstützung von COLOR_FormatYUVP010 wirbt, gilt Folgendes:

• [C-3-1] Das P010-Format muss für die Eingabeoberfläche und die CPU-schreibbare Eingabe (ImageWriter, MediaImage, ByteBuffer) unterstützt werden.

Wenn ein Video-Encoder mit der Unterstützung von COLOR_Format32bitABGR2101010 wirbt, gilt Folgendes:

• [C-4-1] MUSS das RGBA_1010102-Format für die Eingabeoberfläche und die CPU-schreibbare Eingabe (ImageWriter, ByteBuffer) unterstützen. Hinweis: Für Encoder ist KEINE Konvertierung zwischen verschiedenen Transferkurven erforderlich.

Anforderungen für HDR-Aufnahmen

Für alle Video-Encoder, die HDR-Profile unterstützen, gilt für Geräteimplementierungen:

• [C-5-1] Es DARF NICHT davon ausgegangen werden, dass die HDR-Metadaten präzise sind. Beispielsweise können im codierten Frame Pixel mit einer Helligkeit über dem Spitzenwert vorhanden sein oder das Histogramm ist nicht repräsentativ für den Frame.

• Sie SOLLTEN dynamische HDR-Metadaten aggregieren, um geeignete statische HDR-Metadaten für codierte Streams zu generieren, und sie am Ende jeder Codierungssitzung ausgeben.

Wenn Geräteimplementierungen die HDR-Aufnahme mit den CamcorderProfile-APIs unterstützen, gilt Folgendes:

• [C-6-1] MUSS die HDR-Aufnahme auch über die Camera2-APIs unterstützen.

• [C-6-2] MUSS mindestens einen hardwarebeschleunigten Video-Encoder für jede unterstützte HDR-Technologie unterstützen.

• [C-6-3] MUSS (mindestens) die HLG-Aufnahme unterstützen.

• [C-6-4] Die HDR-Metadaten (falls für die HDR-Technologie zutreffend) MÜSSEN in die aufgenommene Videodatei geschrieben werden. Bei AV1, HEVC und DolbyVision bedeutet das, dass die Metadaten in den codierten Bitstream aufgenommen werden.

• [C-6-5] MUSS P010 und COLOR_FormatYUVP010 unterstützen.

• [C-6-6] MUSS HDR-zu-SDR-Tone-Mapping im standardmäßigen hardwarebeschleunigten Decoder für das erfasste Profil unterstützen. Mit anderen Worten: Wenn ein Gerät HDR10+ HEVC aufzeichnen kann, MUSS der Standard-HEVC-Decoder den aufgezeichneten Stream in SDR decodieren können.

Anforderungen für die HDR-Bearbeitung

Wenn Geräteimplementierungen Video-Encoder enthalten, die die HDR-Bearbeitung unterstützen, gilt Folgendes:

• Sollte eine minimale Latenz für die Generierung der HDR-Metadaten verwenden, wenn diese nicht vorhanden sind, und sollte Situationen, in denen die Metadaten für einige Frames und nicht für andere vorhanden sind, ordnungsgemäß verarbeiten. Diese Metadaten SOLLTEN präzise sein (z. B. die tatsächliche Spitzenluminanz und das Histogramm des Frames darstellen).

Wenn die Geräteimplementierung Codecs enthält, die FEATURE_HdrEditing unterstützen, gilt für diese Codecs Folgendes:

• [C-7-1] MUSS mindestens ein HDR-Profil unterstützen.

• [C-7-2] MÜSSEN FEATURE_HdrEditing für alle HDR-Profile unterstützen, die von diesem Codec beworben werden. Das heißt, sie MÜSSEN HDR-Metadaten generieren, wenn sie für alle unterstützten HDR-Profile, die HDR-Metadaten verwenden, nicht vorhanden sind.

• [C-7-3] MÜSSEN die folgenden Eingabeformate für Video-Encoder unterstützen, die das HDR‑decodierte Signal vollständig erhalten:

  • RGBA_1010102 (bereits in der Zielübertragungskurve) für die Eingabeoberfläche und den ByteBuffer und MUSS die Unterstützung für COLOR_Format32bitABGR2101010 angeben.

Wenn die Geräteimplementierung Codecs enthält, die FEATURE_HdrEditing unterstützen, gilt Folgendes:

• [C-7-4] MUSS Unterstützung für die EXT_YUV_target-OpenGL-Erweiterung offenlegen.

Anforderungen an HDR-Displays

Wenn Geräteimplementierungen Pufferinhalte empfangen, die mit ADATASPACE_TRANSFER_HLG codiert sind, und diese Inhalte über SurfaceControl.Transaction#setBuffer an das Display gesendet werden, gilt Folgendes:

• [C-8-1] MUSS der Empfehlung für Grafiken in Weiß in BT.2408-7 folgen und Inhalte nur dann anzeigen, wenn sie maximal 4,926-mal heller sind als SDR-Inhalte.

6. Kompatibilität von Entwicklertools und -optionen

6.1. Entwicklertools

Geräteimplementierungen:

• [C-0-1] MÜSSEN die im Android SDK bereitgestellten Android-Entwicklertools unterstützen.

• Android Debug Bridge (ADB)

• [C-0-2] MUSS adb wie im Android SDK dokumentiert und die in AOSP bereitgestellten Shell-Befehle unterstützen, die von App-Entwicklern verwendet werden können, einschließlich dumpsys, cmd stats und Simpleperf.

• [C-0-11] MUSS den Shell-Befehl cmd testharness unterstützen. Das Aktualisieren von Geräteimplementierungen von einer früheren Android-Version ohne persistenten Datenblock kann von C-0-11 ausgenommen werden.

• [C-0-3] Das Format oder der Inhalt von Gerätesystemereignissen (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats), die über den Befehl „dumpsys“ protokolliert werden, DÜRFEN NICHT geändert werden.

• [C-0-10] MUSS die folgenden Ereignisse ohne Auslassung aufzeichnen und für den Shell-Befehl cmd stats und die System-API-Klasse StatsManager zugänglich und verfügbar machen.

  • ActivityForegroundStateChanged
  • AnomalyDetected
  • AppBreadcrumbReported
  • AppCrashOccurred
  • AppStartOccurred
  • BatteryLevelChanged
  • BatterySaverModeStateChanged
  • BleScanResultReceived
  • BleScanStateChanged
  • ChargingStateChanged
  • DeviceIdleModeStateChanged
  • ForegroundServiceStateChanged
  • GpsScanStateChanged
  • InputDeviceUsageReported
  • JobStateChanged
  • KeyboardConfigured
  • KeyboardSystemsEventReported
  • PluggedStateChanged
  • PressureStallInformation
  • ScheduledJobStateChanged
  • ScreenStateChanged
  • SyncStateChanged
  • SystemElapsedRealtime
  • TouchpadUsage
  • UidProcessStateChanged
  • WakelockStateChanged
  • WakeupAlarmOccurred
  • WifiLockStateChanged
  • WifiMulticastLockStateChanged
  • WifiScanStateChanged

• [C-0-4] MUSS der geräteseitige ADB-Daemon standardmäßig inaktiv sein und es MUSS einen für Nutzer zugänglichen Mechanismus zum Aktivieren der Android Debug Bridge geben.

• [C-0-5] MÜSSEN sicheres ADB unterstützen. Android unterstützt sicheres adb. „Sicheres adb“ ermöglicht adb auf bekannten authentifizierten Hosts.

• [C-0-6] Es MUSS ein Mechanismus bereitgestellt werden, der es ermöglicht, eine Verbindung zu adb von einem Hostcomputer aus herzustellen. Im Detail:

Wenn Geräteimplementierungen ohne USB-Anschluss den Peripheriemodus unterstützen, gilt Folgendes:

• [C-3-1] MUSS „adb“ über ein lokales Netzwerk (z. B. Ethernet oder WLAN) implementieren.

• [C-3-2] MUSS Treiber für Windows 7, 8 und 10 bereitstellen, damit Entwickler über das ADB-Protokoll eine Verbindung zum Gerät herstellen können.

Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet unterstützen, gilt Folgendes:

• [C-4-1] Die Methode AdbManager#isAdbWifiSupported() MUSS true zurückgeben.

Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet unterstützen und mindestens eine Kamera enthalten, gilt Folgendes:

• [C-5-1] MUSS die Methode AdbManager#isAdbWifiQrSupported() true zurückgeben.

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] MÜSSEN alle DDMS-Funktionen unterstützen, die im Android SDK dokumentiert sind. Da ddms adb verwendet, SOLLTE die Unterstützung für ddms standardmäßig inaktiv sein, MUSS aber unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben beschrieben aktiviert hat.

• SysTrace

  • [C-0-9] MÜSSEN das Systrace-Tool unterstützen, wie im Android SDK dokumentiert. Systrace muss standardmäßig inaktiv sein und es MUSS einen für Nutzer zugänglichen Mechanismus zum Aktivieren von Systrace geben.

• Perfetto

  • [C-SR-1] Es wird DRINGEND EMPFOHLEN, dem Shell-Nutzer ein /system/bin/perfetto-Binärprogramm zur Verfügung zu stellen, dessen Befehlszeile der Perfetto-Dokumentation entspricht.

  • [C-SR-2] Es wird DRINGEND EMPFOHLEN, dass die Binärdatei „perfetto“ eine Protobuf-Konfiguration als Eingabe akzeptiert, die dem in der Perfetto-Dokumentation definierten Schema entspricht.

  • [C-SR-3] Es wird DRINGEND EMPFOHLEN, dass die binäre Datei „perfetto“ als Ausgabe einen Protobuf-Trace schreibt, der dem in der Perfetto-Dokumentation definierten Schema entspricht.

  • [C-SR-4] Es wird DRINGEND EMPFOHLEN, über die Binärdatei „perfetto“ mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitzustellen.

• Low Memory Killer

  • [C-0-12] Es MUSS ein LMK_KILL_OCCURRED_FIELD_NUMBER-Atom in das statsd-Log geschrieben werden, wenn eine App vom Low Memory Killer beendet wird.

• Test-Harnischmodus

  Wenn Geräteimplementierungen den Shell-Befehl cmd testharness unterstützen und cmd testharness enable ausführen, gilt Folgendes:

  • [C-2-1] MUSS true für ActivityManager.isRunningInUserTestHarness() zurückgeben

  • [C-2-2] MÜSSEN den Test-Harnischmodus wie in der Dokumentation zum Test-Harnischmodus beschrieben implementieren.

• Informationen zur GPU-Arbeit

  Geräteimplementierungen:

  • [C-0-13] MUSS den Shell-Befehl dumpsys gpu --gpuwork implementieren, um die aggregierten GPU-Arbeitsdaten anzuzeigen, die vom Kernel-Tracepoint power/gpu_work_period zurückgegeben werden, oder keine Daten anzuzeigen, wenn der Tracepoint nicht unterstützt wird. Die AOSP-Implementierung ist frameworks/native/services/gpuservice/gpuwork/.

Wenn Geräteimplementierungen die Unterstützung von Vulkan 1.0 oder höher über die Funktions-Flags android.hardware.vulkan.version melden, gilt Folgendes:

• [C-1-1] MUSS dem App-Entwickler die Möglichkeit bieten, GPU-Debug-Ebenen zu aktivieren/deaktivieren.

• [C-1-2] MUSS, wenn die GPU-Debug-Ebenen aktiviert sind, Ebenen in Bibliotheken, die von externen Tools bereitgestellt werden (d.h. nicht Teil des Plattform- oder Anwendungspakets), im Basisverzeichnis von debugfähigen Anwendungen auflisten, um die API-Methoden vkEnumerateInstanceLayerProperties() und vkCreateInstance() zu unterstützen.

6.2. Entwickleroptionen

Android bietet Entwicklern die Möglichkeit, Einstellungen für die App-Entwicklung zu konfigurieren.

Geräteimplementierungen MÜSSEN eine einheitliche Erfahrung für Entwickleroptionen bieten. Sie:

• [C-0-1] MUSS den Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS berücksichtigen, um Einstellungen im Zusammenhang mit der App-Entwicklung anzuzeigen. In der Upstream-Android-Implementierung ist das Optionsmenü „Entwickleroptionen“ standardmäßig ausgeblendet. Nutzer können es aufrufen, indem sie siebenmal auf das Menüelement Einstellungen > Über das Gerät > Build-Nummer tippen.
• [C-0-2] Die Entwickleroptionen MÜSSEN standardmäßig ausgeblendet sein.
• [C-0-3] Es MUSS einen eindeutigen Mechanismus geben, der nicht eine Drittanbieter-App gegenüber einer anderen bevorzugt, um die Entwickleroptionen zu aktivieren. Es MUSS ein öffentlich sichtbares Dokument oder eine Website bereitgestellt werden, in dem beschrieben wird, wie die Entwickleroptionen aktiviert werden. Dieses Dokument oder diese Website MUSS über die Android SDK-Dokumente verlinkt werden können.
• Es SOLLTE eine fortlaufende visuelle Benachrichtigung für den Nutzer angezeigt werden, wenn die Entwickleroptionen aktiviert sind und die Sicherheit des Nutzers gefährdet ist.
• Der Zugriff auf das Menü „Entwickleroptionen“ KANN vorübergehend eingeschränkt werden, indem das Menü visuell ausgeblendet oder deaktiviert wird, um Ablenkungen in Situationen zu vermeiden, in denen die Sicherheit des Nutzers gefährdet ist.

7. Hardwarekompatibilität

Wenn ein Gerät eine bestimmte Hardwarekomponente enthält, für die es eine entsprechende API für Drittanbieterentwickler gibt:

• [C-0-1] Die Geräteimplementierung MUSS diese API wie in der Android SDK-Dokumentation beschrieben implementieren.

Wenn eine API im SDK mit einer Hardwarekomponente interagiert, die als optional angegeben ist, und die Geräteimplementierung diese Komponente nicht enthält:

• [C-0-2] Vollständige Klassendefinitionen (wie im SDK dokumentiert) für die Komponenten-APIs MÜSSEN weiterhin angegeben werden.
• [C-0-3] Das Verhalten der API MUSS in angemessener Weise als No-Op implementiert werden.
• [C-0-4] API-Methoden MÜSSEN Nullwerte zurückgeben, sofern dies in der SDK-Dokumentation zulässig ist.
• [C-0-5] API-Methoden MÜSSEN No-op-Implementierungen von Klassen zurückgeben, in denen Nullwerte gemäß SDK-Dokumentation nicht zulässig sind.
• [C-0-6] API-Methoden DÜRFEN KEINE Ausnahmen auslösen, die nicht in der SDK-Dokumentation dokumentiert sind.
• [C-0-7] Geräteimplementierungen MÜSSEN für denselben Build-Fingerabdruck über die Methoden getSystemAvailableFeatures() und hasSystemFeature(String) der Klasse android.content.pm.PackageManager konsistent genaue Informationen zur Hardwarekonfiguration melden.

Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telephony API: Auch auf Geräten, die keine Smartphones sind, müssen diese APIs als angemessene No-Ops implementiert werden.

7.1. Display und Grafik

Android bietet Funktionen, mit denen Anwendungs-Assets und UI-Layouts automatisch an das Gerät angepasst werden, damit Drittanbieteranwendungen auf einer Vielzahl von Hardware-Displays und ‑Konfigurationen gut ausgeführt werden. Ein Android-kompatibles Display ist ein Bildschirm, der alle Verhaltensweisen und APIs implementiert, die in Android Developers – Screen compatibility overview, diesem Abschnitt (7.1) und seinen Unterabschnitten sowie alle zusätzlichen gerätespezifischen Verhaltensweisen beschrieben sind, die in Abschnitt 2 dieses CDD dokumentiert sind.

Geräteimplementierungen:

• [C-0-1] MUSS Drittanbieteranwendungen standardmäßig nur auf Android-kompatiblen Displays rendern.

Die Einheiten, auf die in den Anforderungen in diesem Abschnitt verwiesen wird, sind so definiert:

• physische Diagonale. Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Teils des Displays.

• density. Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1 Zoll abgedeckt werden, ausgedrückt als Pixel pro Zoll (ppi oder dpi). Wenn PPI- und DPI-Werte angegeben sind, müssen sowohl die horizontalen als auch die vertikalen DPI-Werte im angegebenen Bereich liegen.

• Seitenverhältnis. Das Verhältnis der Pixel der längeren Dimension zur kürzeren Dimension des Displays. Ein Display mit 480 × 854 Pixeln hat beispielsweise ein Seitenverhältnis von 854 / 480 = 1,779 oder ungefähr „16:9“.

• Dichteunabhängige Pixel (dp). Eine virtuelle Pixeleinheit, die auf eine Bildschirmdichte von 160 DPI normalisiert ist. Für eine bestimmte Dichte d und eine bestimmte Anzahl von Pixeln p wird die Anzahl der dichteunabhängigen Pixel dp so berechnet: dp = (160 / d) * p.

7.1.1. Bildschirmkonfiguration

7.1.1.1. Displaygröße und ‑form

Das Android-UI-Framework unterstützt eine Vielzahl verschiedener logischer Bildschirmgrößen und ermöglicht es Anwendungen, die Bildschirmgröße der aktuellen Konfiguration über Configuration.screenLayout mit SCREENLAYOUT_SIZE_MASK und Configuration.smallestScreenWidthDp abzufragen.

Geräteimplementierungen:

• [C-0-1] MUSS die korrekte Layoutgröße für Configuration.screenLayout gemäß der Android SDK-Dokumentation melden. Geräteimplementierungen MÜSSEN die korrekten logischen, dichteunabhängigen Pixel (dp) für die Bildschirmabmessungen wie unten angegeben melden:

  • Geräte, bei denen Configuration.uiMode auf einen anderen Wert als UI_MODE_TYPE_WATCH festgelegt ist und für die Configuration.screenLayout eine Größe von small gemeldet wird, MÜSSEN mindestens 426 dp × 320 dp groß sein.

  • Geräte, die eine normal-Größe für die Configuration.screenLayout melden, MÜSSEN mindestens 480 dp × 320 dp haben.

  • Geräte, die für Configuration.screenLayout eine Größe von large melden, MÜSSEN mindestens 640 × 480 dp haben.

  • Geräte, die eine xlarge-Größe für Configuration.screenLayout melden, MÜSSEN mindestens 960 dp × 720 dp haben.

• [C-0-2] MUSS die angegebene Unterstützung von Bildschirmgrößen durch Anwendungen über das Attribut <supports-screens> in der AndroidManifest.xml korrekt berücksichtigen, wie in der Android SDK-Dokumentation beschrieben.

• MAY have the Android-compatible display(s) with rounded corners.

Wenn Geräteimplementierungen Bildschirme unterstützen, die die UI_MODE_TYPE_NORMAL-Größenkonfiguration ermöglichen, und physische Displays mit abgerundeten Ecken zum Rendern dieser Bildschirme verwendet werden, gilt Folgendes:

• [C-1-1] MUSS dafür sorgen, dass für jede solche Anzeige mindestens eine der folgenden Anforderungen erfüllt ist:

  • Der Radius der abgerundeten Ecken ist kleiner oder gleich 38 dp.

  • Wenn an jeder Ecke des logischen Displays ein 18 × 18 dp großer Bereich verankert ist, ist mindestens ein Pixel jedes Bereichs auf dem Bildschirm sichtbar.

• Es SOLLTE eine Möglichkeit für den Nutzer geben, zum Anzeigemodus mit den rechteckigen Ecken zu wechseln.

Wenn Geräteimplementierungen nur die NO_KEYS-Tastaturkonfiguration unterstützen und die Unterstützung für die UI_MODE_TYPE_NORMAL-UI-Moduskonfiguration melden möchten, müssen sie:

• [C-4-1] MUSS eine Layoutgröße von mindestens 596 dp × 384 dp haben, wobei alle Displayausschnitte ausgeschlossen sind.

Details zur korrekten Implementierung der Sidecar- oder Erweiterungs-APIs finden Sie in der öffentlichen Dokumentation von Window Manager Jetpack.

• [C-4-1] Anforderung in Android 15 entfernt.

7.1.1.2. Seitenverhältnis des Bildschirms

Dieser Abschnitt wurde in Android 14 entfernt.

7.1.1.3. Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe von logischen Standarddichten, um Anwendungsentwicklern bei der Ausrichtung von Anwendungsressourcen zu helfen.

Geräteimplementierungen:

• [C-0-1] MUSS eine der Android-Framework-Dichten, die unter DisplayMetrics aufgeführt sind, über die DENSITY_DEVICE_STABLE API melden. Dieser Wert muss für jedes physische Display ein statischer Wert sein. Das Gerät KANN jedoch einen anderen DisplayMetrics.density melden, je nach den vom Nutzer vorgenommenen Änderungen der Displaykonfiguration (z. B. Anzeigegröße), die nach dem ersten Start festgelegt wurden.

• Sollte die Standarddichte des Android-Frameworks definieren, die numerisch der physischen Dichte des Bildschirms am nächsten kommt, oder einen Wert, der den gleichen äquivalenten Winkel-Sichtfeldmessungen eines tragbaren Geräts entspricht.

Wenn Geräteimplementierungen eine Möglichkeit bieten, die Anzeigegröße des Geräts zu ändern, gilt Folgendes:

• [C-1-1] Die Anzeige darf nicht auf mehr als das 1,5-Fache der DENSITY_DEVICE_STABLE skaliert werden oder eine effektive Mindestbildschirmdimension von weniger als 320 dp (entspricht dem Ressourcenqualifizierer sw320dp) aufweisen, je nachdem, was zuerst eintritt.

• [C-1-2] Das Display darf nicht auf weniger als 0,85 × DENSITY_DEVICE_STABLE skaliert werden.

• Um eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen zu gewährleisten, wird EMPFOHLEN, die folgenden Skalierungen der nativen Anzeigeoptionen bereitzustellen (unter Einhaltung der oben genannten Grenzwerte):

  • Klein: 0,85x
  • Standard: 1x (native Anzeigeskalierung)
  • Groß: 1,15‑fach
  • Größer: 1,3-fach
  • Größte 1,45‑fach

7.1.2. Messwerte für Displaykampagnen

Wenn Geräteimplementierungen die Android-kompatiblen Displays oder die Videoausgabe auf die Android-kompatiblen Displays enthalten, gilt Folgendes:

• [C-1-1] MUSS korrekte Werte für alle Android-kompatiblen Displaymesswerte melden, die in der android.util.DisplayMetrics-API definiert sind.

Wenn Geräteimplementierungen keinen eingebetteten Bildschirm oder keine Videoausgabe enthalten, gilt Folgendes:

• [C-2-1] MUSS korrekte Werte für das Android-kompatible Display gemäß der Definition in der android.util.DisplayMetrics-API für die emulierte Standard-view.Display melden.

7.1.3. Displayausrichtung

Geräteimplementierungen:

• [C-0-1] MUSS angeben, welche Bildschirmausrichtungen unterstützt werden (android.hardware.screen.portrait und/oder android.hardware.screen.landscape), und MUSS mindestens eine unterstützte Ausrichtung angeben. Ein Gerät mit einem Bildschirm mit fester Ausrichtung im Querformat, z. B. ein Fernseher oder Laptop, SOLLTE nur android.hardware.screen.landscape melden.

• [C-0-2] MUSS den korrekten Wert für die aktuelle Ausrichtung des Geräts zurückgeben, wenn er über android.content.res.Configuration.orientation, android.view.Display.getOrientation() oder andere APIs abgefragt wird.

Wenn Geräteimplementierungen beide Bildschirmausrichtungen unterstützen, gilt Folgendes:

• [C-1-1] Anforderung in Android 16 entfernt.

• [C-1-2] Die gemeldete Bildschirmgröße oder ‑dichte darf beim Ändern der Ausrichtung NICHT geändert werden.

• MAY kann entweder das Hoch- oder das Querformat als Standard auswählen.

7.1.4. 2D- und 3D-Grafikbeschleunigung

7.1.4.1. OpenGL ES

Geräteimplementierungen:

• [C-0-1] MUSS die unterstützten OpenGL ES-Versionen (1.1, 2.0, 3.0, 3.1, 3.2) über die verwalteten APIs (z. B. über die GLES10.getString()-Methode) und die nativen APIs korrekt identifizieren.

• [C-0-2] MÜSSEN die Unterstützung für alle entsprechenden verwalteten APIs und nativen APIs für jede OpenGL ES-Version enthalten, die sie unterstützen.

Wenn Geräteimplementierungen einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN OpenGL ES 1.1, 2.0, 3.0 und 3.1 unterstützen, wie in der Android SDK-Dokumentation beschrieben.

• [C-SR-1] Anforderung in Android 15 entfernt.

• SOLLTEN OpenGL ES 3.2 unterstützen.

Die OpenGL ES-dEQP-Tests sind in eine Reihe von Testlisten unterteilt, die jeweils ein zugehöriges Datum bzw. eine zugehörige Versionsnummer haben. Sie befinden sich im Android-Quellbaum unter external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Ein Gerät, das OpenGL ES auf einer selbst gemeldeten Ebene unterstützt, kann die dEQP-Tests in allen Testlisten ab dieser Ebene und früher bestehen.

Wenn Geräteimplementierungen eine der OpenGL ES-Versionen unterstützen, gilt Folgendes:

• [C-2-1] MÜSSEN alle anderen implementierten OpenGL ES-Erweiterungen über die verwalteten OpenGL ES-APIs und nativen APIs gemeldet werden. Umgekehrt DÜRFEN keine Erweiterungsstrings gemeldet werden, die nicht unterstützt werden.

• [C-2-2] MUSS die Erweiterungen EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable und EGL_ANDROID_GLES_layers unterstützen.

• [C-2-3] MÜSSEN die maximale Version der unterstützten OpenGL ES dEQP-Tests über das Funktions-Flag android.software.opengles.deqp.level melden.

• [C-2-4] MÜSSEN mindestens Version 132383489 (ab 1. März 2020) unterstützen, wie im android.software.opengles.deqp.level-Funktions-Flag angegeben.

• [C-2-5] MUSS alle OpenGL ES dEQP-Tests in den Testlisten zwischen Version 132383489 und der im Funktions-Flag android.software.opengles.deqp.level angegebenen Version für jede unterstützte OpenGL ES-Version bestehen.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, die EGL_KHR_partial_update- und OES_EGL_image_external-Erweiterungen zu unterstützen.

• Sollten alle von ihnen unterstützten Texturkomprimierungsformate, die in der Regel anbieterspezifisch sind, über die Methode getString() genau melden.

• SOLLTEN die EGL_IMG_context_priority- und EGL_EXT_protected_content-Erweiterungen unterstützen.

Wenn Geräteimplementierungen Unterstützung für OpenGL ES 3.0, 3.1 oder 3.2 deklarieren, gilt Folgendes:

• [C-3-1] MUSS die entsprechenden Funktionssymbole für diese Versionen zusätzlich zu den OpenGL ES 2.0-Funktionssymbolen in der libGLESv2.so-Bibliothek exportieren.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, die OES_EGL_image_external_essl3-Erweiterung zu unterstützen.

Wenn Geräteimplementierungen OpenGL ES 3.2 unterstützen, gilt Folgendes:

• [C-4-1] MUSS das OpenGL ES Android Extension Pack vollständig unterstützen.

Wenn Geräteimplementierungen das Android Extension Pack für OpenGL ES vollständig unterstützen, gilt Folgendes:

• [C-5-1] MUSS die Unterstützung über das Funktions-Flag android.hardware.opengles.aep identifizieren.

Wenn Geräteimplementierungen Unterstützung für die Erweiterung EGL_KHR_mutable_render_buffer bieten, gilt Folgendes:

• [C-6-1] MUSS auch die EGL_ANDROID_front_buffer_auto_refresh-Erweiterung unterstützen.

7.1.4.2. Vulkan

Android unterstützt Vulkan, eine plattformübergreifende API mit geringem Aufwand für leistungsstarke 3D-Grafiken.

Wenn Geräteimplementierungen OpenGL ES 3.1 unterstützen, gilt Folgendes:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, Unterstützung für Vulkan 1.3 einzubauen.

• [C-4-1] DÜRFEN keine Vulkan-Variantenversion unterstützen (d.h. der Variantenanteil der Vulkan-Kernversion MUSS null sein).

Wenn Geräteimplementierungen einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, Unterstützung für Vulkan 1.3 einzubauen.

Die Vulkan dEQP-Tests sind in eine Reihe von Testlisten unterteilt, die jeweils ein zugehöriges Datum/eine zugehörige Version haben. Sie befinden sich im Android-Quellbaum unter external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Ein Gerät, das Vulkan auf einer selbst gemeldeten Ebene unterstützt, kann die dEQP-Tests in allen Testlisten dieser und früherer Ebenen bestehen.

Wenn Geräteimplementierungen Unterstützung für Vulkan enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN den richtigen Ganzzahlwert mit den Funktions-Flags android.hardware.vulkan.level und android.hardware.vulkan.version melden.

• [C-1-2] MÜSSEN mindestens eine VkPhysicalDevice für die native Vulkan-API vkEnumeratePhysicalDevices() aufzählen.

• [C-1-3] MÜSSEN die Vulkan 1.1-APIs für jedes aufgeführte VkPhysicalDevice vollständig implementieren.

• [C-1-4] MUSS die Ebenen auflisten, die in nativen Bibliotheken mit dem Namen libVkLayer*.so im Verzeichnis der nativen Bibliotheken des Anwendungspakets enthalten sind, und zwar über die nativen Vulkan-APIs vkEnumerateInstanceLayerProperties() und vkEnumerateDeviceLayerProperties().

• [C-1-6] MUSS alle Erweiterungs-Strings, die unterstützt werden, über die nativen Vulkan-APIs melden und umgekehrt KEINE Erweiterungs-Strings melden, die nicht korrekt unterstützt werden.

• [C-1-8] MÜSSEN die maximale Version der unterstützten Vulkan dEQP-Tests über das Funktions-Flag android.software.vulkan.deqp.level melden.

• [C-1-9] MÜSSEN mindestens die Version 132317953 (ab 1. März 2019) unterstützen, wie im android.software.vulkan.deqp.level-Funktions-Flag angegeben.

• [C-1-10] ALLE Vulkan-dEQP-Tests in den Testlisten zwischen Version 132317953 und der im Feature-Flag android.software.vulkan.deqp.level angegebenen Version MÜSSEN bestanden werden.

• [C-1-11] DÜRFEN die Unterstützung für die Erweiterungen VK_KHR_video_queue, VK_KHR_video_decode_queue oder VK_KHR_video_encode_queue NICHT aufzählen.

• [C-1-12] DÜRFEN die Unterstützung für die VK_KHR_performance_query-Erweiterung NICHT auflisten.

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, die im Android Baseline 2022-Profil angegebenen Anforderungen zu erfüllen.

• [C-SR-5] Es wird DRINGEND EMPFOHLEN, VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory und VK_EXT_global_priority zu unterstützen.

• [C-SR-6] Es wird DRINGEND EMPFOHLEN, SkiaVk mit HWUI zu verwenden.

Wenn Geräteimplementierungen Unterstützung für Vulkan enthalten, gilt Folgendes:

• [C-SR-8] Es wird DRINGEND EMPFOHLEN, das Vulkan-Ladeprogramm nicht zu ändern.

• [C-1-14] Vulkan-Geräteerweiterungen vom Typ „KHR“, „GOOGLE“ oder „ANDROID“ DÜRFEN NICHT aufgelistet werden, sofern diese Erweiterungen nicht im Funktions-Flag android.software.vulkan.deqp.level enthalten sind.

Wenn Geräteimplementierungen keine Unterstützung für Vulkan 1.0 enthalten, gilt Folgendes:

• [C-2-1] DÜRFEN KEINE der Vulkan-Feature-Flags deklarieren (z.B. android.hardware.vulkan.level, android.hardware.vulkan.version).

• [C-2-2] DÜRFEN keine VkPhysicalDevice für die native Vulkan API vkEnumeratePhysicalDevices() aufzählen.

7.1.4.3. RenderScript

Geräteimplementierungen:

• [C-0-1] MÜSSEN Android RenderScript unterstützen, wie in der Android SDK-Dokumentation beschrieben.

7.1.4.4. 2D-Grafikbeschleunigung

Android bietet einen Mechanismus, mit dem Anwendungen deklarieren können, dass sie die Hardwarebeschleunigung für 2D-Grafiken auf Anwendungs-, Aktivitäts-, Fenster- oder Ansichtsebene über ein Manifest-Tag android:hardwareAccelerated oder direkte API-Aufrufe aktivieren möchten.

Geräteimplementierungen:

• [C-0-1] Die Hardwarebeschleunigung MUSS standardmäßig aktiviert sein und MUSS deaktiviert werden, wenn der Entwickler dies durch Festlegen von android:hardwareAccelerated="false" oder durch direktes Deaktivieren der Hardwarebeschleunigung über die Android View-APIs anfordert.

• [C-0-2] MUSS sich gemäß der Android SDK-Dokumentation zur Hardwarebeschleunigung verhalten.

Android enthält ein TextureView-Objekt, mit dem Entwickler hardwarebeschleunigte OpenGL ES-Texturen direkt als Rendering-Ziele in eine UI-Hierarchie einbinden können.

Geräteimplementierungen:

• [C-0-3] MÜSSEN die TextureView API unterstützen und sich konsistent mit der Upstream-Android-Implementierung verhalten.

7.1.4.5. Displays mit breiter Farbskala

Wenn Geräteimplementierungen die Unterstützung von Displays mit großem Farbraum über Configuration.isScreenWideColorGamut() beanspruchen, müssen sie:

• [C-1-1] MUSS ein farbkalibriertes Display haben.

• [C-1-2] MUSS ein Display haben, dessen Farbumfang den sRGB-Farbumfang im CIE 1931 xyY-Raum vollständig abdeckt.

• [C-1-3] MUSS ein Display haben, dessen Farbraum im CIE 1931 xyY-Raum eine Fläche von mindestens 90% von DCI-P3 umfasst.

• [C-1-4] MUSS OpenGL ES 3.1 oder 3.2 unterstützen und dies korrekt melden.

• [C-1-5] MUSS die Unterstützung für die Erweiterungen EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear und EGL_EXT_gl_colorspace_display_p3_passthrough bewerben.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, GL_EXT_sRGB zu unterstützen.

Wenn Geräteimplementierungen keine Displays mit großem Farbraum unterstützen, gilt Folgendes:

• [C-2-1] Sollte mindestens 100% des sRGB-Farbraums im CIE 1931 xyY-Farbraum abdecken, obwohl der Farbumfang des Displays nicht definiert ist.

7.1.5. Kompatibilitätsmodus für alte Anwendungen

Android bietet einen „Kompatibilitätsmodus“, in dem das Framework in einem Modus mit einer „normalen“ Bildschirmgröße (320 dp Breite) für ältere Anwendungen ausgeführt wird, die nicht für alte Android-Versionen entwickelt wurden, die vor der Unabhängigkeit von der Bildschirmgröße eingeführt wurden.

7.1.6. Displaytechnologie

Die Android-Plattform enthält APIs, mit denen Anwendungen umfangreiche Grafiken auf einem Android-kompatiblen Display rendern können. Geräte MÜSSEN alle diese APIs unterstützen, wie im Android SDK definiert, sofern in diesem Dokument nicht ausdrücklich etwas anderes erlaubt ist.

Alle Android-kompatiblen Displays einer Geräteimplementierung:

• [C-0-1] MUSS 16‑Bit-Farbgrafiken rendern können.

• Sollte Displays unterstützen, die 24‑Bit-Farbgrafiken darstellen können.

• [C-0-2] MUSS Animationen rendern können.

• [C-0-3] MUSS ein Pixel-Seitenverhältnis (PAR) zwischen 0,9 und 1,15 haben. Das Pixel-Seitenverhältnis MUSS also nahezu quadratisch (1,0) sein, mit einer Toleranz von 10 bis 15 %.

7.1.7. Sekundäre Displays

Android unterstützt sekundäre Android-kompatible Displays, um die Medienfreigabe zu ermöglichen, und bietet Entwickler-APIs für den Zugriff auf externe Displays.

Wenn Geräteimplementierungen ein externes Display über eine kabelgebundene, kabellose oder eingebettete zusätzliche Displayverbindung unterstützen, gilt Folgendes:

• [C-1-1] MUSS den Systemdienst und die API DisplayManager wie in der Android SDK-Dokumentation beschrieben implementieren.

7.2. Eingabegeräte

Geräteimplementierungen:

• [C-0-1] MUSS einen Eingabemechanismus wie einen Touchscreen oder eine Navigation ohne Touchbedienung enthalten, um zwischen den UI-Elementen zu navigieren.

7.2.1. Tastatur

Wenn Geräteimplementierungen Unterstützung für Eingabemethoden-Editor (IME)-Apps von Drittanbietern enthalten, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag android.software.input_methods deklarieren.
• [C-1-2] MÜSSEN Input Management Framework vollständig implementieren.
• [C-1-3] MUSS eine vorinstallierte Softwaretastatur haben.

Geräteimplementierungen:

• [C-0-1] DARF keine Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard (QWERTY oder 12-Tasten) angegebenen Formate entspricht.
• Sollte zusätzliche Implementierungen für die Bildschirmtastatur enthalten.
• KANN eine Hardwaretastatur enthalten.

7.2.2. Bedienung ohne Touch

Android unterstützt das Steuerkreuz, den Trackball und das Rad als Mechanismen für die Navigation ohne Touch.

Geräteimplementierungen:

• [C-0-1] MÜSSEN den richtigen Wert für android.content.res.Configuration.navigation melden.

Wenn Geräteimplementierungen keine Navigation ohne Berührung bieten, gilt Folgendes:

• [C-1-1] MUSS einen angemessenen alternativen Benutzeroberflächenmechanismus für die Auswahl und Bearbeitung von Text bereitstellen, der mit Input Management Engines kompatibel ist. Die Upstream-Implementierung von Android Open Source umfasst einen Auswahlmechanismus, der für Geräte ohne Touch-Navigationseingaben geeignet ist.

7.2.3. Navigationstasten

Die Funktionen Startbildschirm, Letzte Apps und Zurück, die normalerweise über eine Interaktion mit einer speziellen physischen Taste oder einem bestimmten Bereich des Touchscreens bereitgestellt werden, sind für das Android-Navigationsparadigma unerlässlich. Daher müssen Geräteimplementierungen:

• [C-0-1] MUSS eine Möglichkeit für Nutzer bieten, installierte Anwendungen zu starten, die eine Activity mit dem <intent-filter> haben, das mit ACTION=MAIN und CATEGORY=LAUNCHER oder CATEGORY=LEANBACK_LAUNCHER für die Implementierung auf Fernsehgeräten festgelegt ist. Die Funktion „Zuhause“ SOLLTE der Mechanismus für diese Nutzerfreundlichkeit sein.
• Es SOLLTEN Schaltflächen für die Funktionen „Letzte“ und „Zurück“ vorhanden sein.

Wenn die Funktionen „Home“, „Letzte“ oder „Zurück“ bereitgestellt werden, gilt Folgendes:

• [C-1-1] MUSS mit einer einzigen Aktion (z.B. Tippen, Doppelklicken oder Geste) zugänglich sein, wenn eine der Aktionen zugänglich ist.
• [C-1-2] Es MUSS klar angegeben werden, welche einzelne Aktion jede Funktion auslöst. Ein sichtbares Symbol auf der Schaltfläche, ein Softwaresymbol im Navigationsleistenbereich des Bildschirms oder eine Schritt-für-Schritt-Demo während der Einrichtung sind Beispiele für solche Hinweise.

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, den Eingabemechanismus für die Menüfunktion nicht bereitzustellen, da sie seit Android 4.0 zugunsten der Aktionsleiste eingestellt wurde.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, alle Navigationsfunktionen als abbrechbar anzubieten. „Abbrechbar“ bedeutet, dass der Nutzer die Ausführung der Navigationsfunktion (z. B. „Zurück“, „Zum Startbildschirm“) verhindern kann, wenn er das Wischen nicht über einen bestimmten Schwellenwert hinaus loslässt.

Wenn Geräteimplementierungen die Menüfunktion bieten, gilt Folgendes:

• [C-2-1] Die Schaltfläche für das Aktionsüberlaufmenü MUSS angezeigt werden, wenn das Pop-up-Menü für das Aktionsüberlaufmenü nicht leer und die Aktionsleiste sichtbar ist.
• [C-2-2] Das Kontextmenü für Aktionen, das durch Auswahl der Overflow--Schaltfläche in der Aktionsleiste angezeigt wird, DARF NICHT an einer anderen Position als der Standardposition gerendert werden. Das Kontextmenü für Aktionen, das durch Auswahl der Menüfunktion angezeigt wird, DARF an einer anderen Position auf dem Bildschirm gerendert werden.

Wenn Geräteimplementierungen die Menüfunktion nicht bieten, gilt aus Gründen der Abwärtskompatibilität Folgendes:

• [C-3-1] Die Menüfunktion MUSS für Anwendungen verfügbar sein, wenn targetSdkVersion kleiner als 10 ist. Dies kann über eine physische Taste, eine Softwaretaste oder Gesten erfolgen. Diese Menüfunktion sollte zugänglich sein, sofern sie nicht zusammen mit anderen Navigationsfunktionen ausgeblendet wird.

Wenn Geräteimplementierungen die Assist-Funktion bereitstellen, gilt Folgendes:

• [C-4-1] Die Assist-Funktion MUSS mit einer einzigen Aktion (z.B. Tippen, Doppelklicken oder Geste) zugänglich sein, wenn andere Navigationstasten zugänglich sind.
• [C-SR-3] Es wird DRINGEND EMPFOHLEN, langes Drücken auf die HOME-Funktion als diese vorgesehene Interaktion zu verwenden.

Wenn Geräteimplementierungen einen bestimmten Teil des Displays zum Anzeigen der Navigationstasten verwenden, gilt Folgendes:

• [C-5-1] Die Navigationstasten MÜSSEN einen separaten Bereich des Bildschirms verwenden, der für Anwendungen nicht verfügbar ist, und DÜRFEN den für Anwendungen verfügbaren Bereich des Bildschirms nicht verdecken oder anderweitig beeinträchtigen.
• [C-5-2] MUSS einen Teil des Displays für Anwendungen zur Verfügung stellen, der den in Abschnitt 7.1.1 definierten Anforderungen entspricht.
• [C-5-3] MUSS die von der App über die API-Methode View.setSystemUiVisibility() festgelegten Flags berücksichtigen, damit dieser separate Bereich des Bildschirms (die Navigationsleiste) wie im SDK dokumentiert ordnungsgemäß ausgeblendet wird.

Wenn die Navigationsfunktion als Aktion auf dem Bildschirm oder als Geste bereitgestellt wird:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() MUSS nur zum Melden des Bereichs für die Erkennung von Home-Gesten verwendet werden.
• [C-6-2] Gesten, die innerhalb eines Ausschlussrechtecks beginnen, das von der Vordergrundanwendung über View#setSystemGestureExclusionRects() bereitgestellt wird, aber außerhalb von WindowInsets#getMandatorySystemGestureInsets() liegen, DÜRFEN NICHT für die Navigationsfunktion abgefangen werden, solange das Ausschlussrechteck innerhalb des maximalen Ausschlusslimits liegt, das in der Dokumentation für View#setSystemGestureExclusionRects() angegeben ist.
• [C-6-3] Die App im Vordergrund MUSS ein MotionEvent.ACTION_CANCEL-Ereignis senden, sobald Berührungen für eine Systemgeste abgefangen werden, wenn der App im Vordergrund zuvor ein MotionEvent.ACTION_DOWN-Ereignis gesendet wurde.
• [C-6-4] MUSS eine Möglichkeit für Nutzer bieten, zur On-Screen-Navigation mit Tasten zu wechseln (z. B. in den Einstellungen).
• Die Startbildschirmfunktion SOLLTE durch Wischen vom unteren Rand des Bildschirms in der aktuellen Ausrichtung aufgerufen werden können.
• Die Funktion „Zuletzt verwendet“ SOLLTE durch Wischen nach oben und Halten vor dem Loslassen aus demselben Bereich wie die Home-Geste bereitgestellt werden.
• Gesten, die innerhalb von WindowInsets#getMandatorySystemGestureInsets() beginnen, DÜRFEN NICHT durch Ausschlussrechtecke beeinflusst werden, die von der Vordergrundanwendung über View#setSystemGestureExclusionRects() bereitgestellt werden.

Wenn eine Navigationsfunktion an einer beliebigen Stelle am linken und rechten Rand der aktuellen Ausrichtung des Bildschirms verfügbar ist:

• [C-7-1] Die Navigationsfunktion MUSS „Zurück“ sein und durch Wischen vom linken und rechten Rand der aktuellen Ausrichtung des Displays aus aufgerufen werden können.
• [C-7-2] Wenn benutzerdefinierte wischbare Systembereiche am linken oder rechten Rand bereitgestellt werden, MÜSSEN sie im oberen Drittel des Bildschirms platziert werden. Außerdem MUSS es eine deutliche, dauerhafte visuelle Anzeige geben, dass durch Ziehen in den Bildschirm die oben genannten Bereiche und nicht die Zurück-Funktion aufgerufen werden. Ein Systemfeld KANN von einem Nutzer so konfiguriert werden, dass es unter dem oberen Drittel des Bildschirmrands angezeigt wird. Es DARF aber nicht länger als ein Drittel des Rands sein.
• [C-7-3] Wenn für die Vordergrund-App die Flags „View.SYSTEM_UI_FLAG_IMMERSIVE“, „View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY“, „WindowInsetsController.BEHAVIOR_DEFAULT“ oder „WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE“ festgelegt sind, MUSS das Wischen vom Rand aus wie in AOSP implementiert funktionieren. Dies ist im SDK dokumentiert.
• [C-7-4] Wenn für die Vordergrund-App die Flags „View.SYSTEM_UI_FLAG_IMMERSIVE“, „View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY“, „WindowInsetsController.BEHAVIOR_DEFAULT“ oder „WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE“ festgelegt sind, MÜSSEN benutzerdefinierte wischbare Systemleisten ausgeblendet werden, bis der Nutzer die Systemleisten (Navigations- und Statusleiste) einblendet oder die Helligkeit der Systemleisten erhöht, wie in AOSP implementiert.

Wenn die Funktion zur Rückwärtsnavigation bereitgestellt wird und der Nutzer die Zurück-Geste abbricht, gilt Folgendes:

• [C-8-1] OnBackInvokedCallback.onBackCancelled() MUSS aufgerufen werden.
• [C-8-2] OnBackInvokedCallback.onBackInvoked() DARF NICHT aufgerufen werden.
• [C-8-3] Das KEYCODE_BACK-Ereignis DARF NICHT gesendet werden.

Wenn die Funktion zur Rückwärtsnavigation bereitgestellt wird, die Vordergrundanwendung aber KEINE OnBackInvokedCallback registriert hat, gilt Folgendes:

• Das System SOLLTE eine Animation für die Vordergrundanwendung bereitstellen, die darauf hinweist, dass der Nutzer zurückgeht, wie in AOSP beschrieben.

Wenn Geräteimplementierungen die System-API setNavBarMode unterstützen, damit jede System-App mit der Berechtigung android.permission.STATUS_BAR den Navigationsleistenmodus festlegen kann, gilt Folgendes:

• [C-9-1] MUSS Unterstützung für kinderfreundliche Symbole oder eine schaltflächenbasierte Navigation bieten, wie im AOSP-Code angegeben.

7.2.4. Touchscreen-Eingabe

Android unterstützt eine Vielzahl von Zeigereingabesystemen, z. B. Touchscreens, Touchpads und Geräte für die simulierte Toucheingabe. Touchscreen-basierte Geräteimplementierungen sind mit einem Display verbunden, sodass der Nutzer den Eindruck hat, Elemente auf dem Bildschirm direkt zu bearbeiten. Da der Nutzer das Display direkt berührt, sind keine zusätzlichen Angebotscharaktere erforderlich, um die manipulierten Objekte zu kennzeichnen.

Geräteimplementierungen:

• Sollte ein Zeigereingabesystem haben (entweder mausähnlich oder per Touch).
• Sollte vollständig unabhängig verfolgte Zeiger unterstützen.

Wenn Geräteimplementierungen einen Touchscreen (Single-Touch oder besser) auf einem primären Android-kompatiblen Display enthalten, gilt Folgendes:

• [C-1-1] MUSS TOUCHSCREEN_FINGER für das API-Feld Configuration.touchscreen melden.
• [C-1-2] MÜSSEN die Funktions-Flags android.hardware.touchscreen und android.hardware.faketouch gemeldet werden.

Wenn Geräteimplementierungen einen Touchscreen enthalten, der mehr als eine Berührung auf einem primären Android-kompatiblen Display erkennen kann, gilt Folgendes:

• [C-2-1] MÜSSEN die entsprechenden Feature-Flags android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand entsprechend dem Typ des jeweiligen Touchscreens auf dem Gerät gemeldet werden.

Wenn Geräteimplementierungen für die Eingabe auf einem primären Android-kompatiblen Display auf ein externes Eingabegerät wie eine Maus oder einen Trackball angewiesen sind (d.h. das Display nicht direkt berührt wird) und die Anforderungen für Fake-Touch-Eingaben in Abschnitt 7.2.5 erfüllen, gilt Folgendes:

• [C-3-1] DÜRFEN keine Funktions-Flags melden, die mit android.hardware.touchscreen beginnen.
• [C-3-2] MUSS nur android.hardware.faketouch melden.
• [C-3-3] TOUCHSCREEN_NOTOUCH MUSS für das API-Feld Configuration.touchscreen gemeldet werden.

7.2.5. Gefälschte Eingabe per Berührung

Eine unechte Touch-Oberfläche bietet ein Nutzereingabesystem, das eine Teilmenge der Touchscreen-Funktionen annähert. Eine Maus oder Fernbedienung, mit der ein Cursor auf dem Bildschirm bewegt wird, ähnelt der Touch-Bedienung, erfordert aber, dass der Nutzer zuerst auf ein Element zeigt oder es fokussiert und dann klickt. Zahlreiche Eingabegeräte wie Maus, Touchpad, gyroskopbasierte Air Mouse, Gyro-Pointer, Joystick und Multi-Touch-Touchpad können gefälschte Touch-Interaktionen unterstützen. Android enthält die Feature-Konstante android.hardware.faketouch, die einem hochpräzisen Eingabegerät ohne Touch-Funktion (zeigerbasiert) wie einer Maus oder einem Trackpad entspricht, das Touch-basierte Eingaben (einschließlich grundlegender Gestenunterstützung) angemessen emulieren kann. Sie gibt an, dass das Gerät eine emulierte Teilmenge der Touchscreen-Funktionalität unterstützt.

Wenn Geräteimplementierungen keinen Touchscreen, aber ein anderes Zeigereingabesystem enthalten, das sie zur Verfügung stellen möchten, müssen sie:

• SOLLTEN die Unterstützung für das android.hardware.faketouch-Funktions-Flag deklarieren.

Wenn Geräteimplementierungen Unterstützung für android.hardware.faketouch deklarieren, gilt Folgendes:

• [C-1-1] MUSS die absoluten X- und Y-Bildschirmpositionen der Zeigerposition melden und einen visuellen Zeiger auf dem Bildschirm anzeigen.
• [C-1-2] MUSS das Touch-Ereignis mit dem Aktionscode melden, der die Statusänderung angibt, die auftritt, wenn der Zeiger auf dem Bildschirm nach unten oder oben bewegt wird.
• [C-1-3] Das Gerät MUSS das Herunter- und Hochbewegen des Mauszeigers auf einem Objekt auf dem Bildschirm unterstützen, damit Nutzer das Tippen auf ein Objekt auf dem Bildschirm simulieren können.
• [C-1-4] MUSS die folgenden Aktionen unterstützen: Zeiger nach unten, Zeiger nach oben, Zeiger nach unten und dann Zeiger nach oben. Diese Aktionen müssen innerhalb eines Zeitlimits an derselben Stelle auf einem Objekt auf dem Bildschirm ausgeführt werden. So können Nutzer Doppeltippen auf einem Objekt auf dem Bildschirm emulieren.
• [C-1-5] MUSS das Herunterdrücken des Zeigers an einem beliebigen Punkt auf dem Bildschirm, das Bewegen des Zeigers zu einem beliebigen anderen Punkt auf dem Bildschirm und das anschließende Loslassen des Zeigers unterstützen, damit Nutzer ein Ziehen per Touchscreen simulieren können.
• [C-1-6] MUSS das Herunterdrücken des Zeigers unterstützen und es Nutzern ermöglichen, das Objekt schnell an eine andere Position auf dem Bildschirm zu verschieben und dann den Zeiger auf dem Bildschirm loszulassen, sodass Nutzer ein Objekt auf dem Bildschirm zügig wischen können.

Wenn Geräteimplementierungen Unterstützung für android.hardware.faketouch.multitouch.distinct deklarieren, gilt Folgendes:

• [C-2-1] MÜSSEN die Unterstützung für android.hardware.faketouch deklarieren.
• [C-2-2] MUSS die separate Erfassung von zwei oder mehr unabhängigen Zeigereingaben unterstützen.

Wenn Geräteimplementierungen Unterstützung für android.hardware.faketouch.multitouch.jazzhand deklarieren, gilt Folgendes:

• [C-3-1] MÜSSEN die Unterstützung für android.hardware.faketouch deklarieren.
• [C-3-2] MUSS die separate Erfassung von mindestens fünf Zeigereingaben (Erfassung einer Hand mit Fingern) vollständig unabhängig unterstützen.

7.2.6. Unterstützung für Controller

7.2.6.1. Tastenzuordnungen

Geräteimplementierungen:

• [C-1-1] MUSS HID-Ereignisse den entsprechenden InputEvent-Konstanten zuordnen können, wie in den folgenden Tabellen aufgeführt. Die Upstream-Android-Implementierung erfüllt diese Anforderung.

Wenn in Geräteimplementierungen ein Controller eingebettet ist oder ein separater Controller im Lieferumfang enthalten ist, mit dem alle in den folgenden Tabellen aufgeführten Ereignisse eingegeben werden können, gilt Folgendes:

• [C-2-1] MUSS das Funktions-Flag android.hardware.gamepad deklarieren.

Button	HID-Nutzung2	Android-Schaltfläche
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Steuerkreuz nach oben1 Steuerkreuz nach unten1	0x01 0x00393	AXIS_HAT_Y4
Steuerkreuz links1 Steuerkreuz rechts1	0x01 0x00393	AXIS_HAT_X4
Linke Schultertaste1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Rechte Schultertaste1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Mit linkem Stick klicken1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Mit rechtem Stick klicken1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Zurück1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Die oben genannten HID-Verwendungen müssen in einer Gamepad-CA (0x01 0x0005) deklariert werden.

3 Diese Verwendung muss ein logisches Minimum von 0, ein logisches Maximum von 7, ein physisches Minimum von 0, ein physisches Maximum von 315, Einheiten in Grad und eine Berichtsgröße von 4 haben. Der logische Wert wird als Drehung im Uhrzeigersinn von der vertikalen Achse aus definiert. Ein logischer Wert von 0 entspricht beispielsweise keiner Drehung und dem Drücken der Aufwärtstaste, während ein logischer Wert von 1 einer Drehung um 45 Grad und dem Drücken der Aufwärts- und der linken Taste entspricht.

4 MotionEvent

Analoge Steuerung1	HID-Nutzung	Android-Schaltfläche
Linker Trigger	0x02 0x00C5	AXIS_LTRIGGER
Rechter Trigger	0x02 0x00C4	AXIS_RTRIGGER
Linker Joystick	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Rechter Joystick	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Fernbedienung

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.3.1.

7.3. Sensoren

Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, für den eine entsprechende API für Drittentwickler verfügbar ist, MUSS die Geräteimplementierung diese API wie in der Android SDK-Dokumentation und der Android Open Source-Dokumentation zu Sensoren beschrieben implementieren.

Geräteimplementierungen:

• [C-0-1] MUSS das Vorhandensein oder Fehlen von Sensoren gemäß der Klasse android.content.pm.PackageManager genau melden.

• [C-0-2] MUSS über die Methode SensorManager.getSensorList() und ähnliche Methoden eine genaue Liste der unterstützten Sensoren zurückgeben.

• [C-0-3] MUSS sich für alle anderen Sensor-APIs angemessen verhalten, z. B. true oder false zurückgeben, wenn Anwendungen versuchen, Listener zu registrieren, und keine Sensor-Listener aufrufen, wenn die entsprechenden Sensoren nicht vorhanden sind.

Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, für den es eine entsprechende API für Drittanbieterentwickler gibt, gilt Folgendes:

• [C-1-1] MUSS alle Sensormessungen mit den relevanten Werten des Internationalen Einheitensystems (metrisch) für jeden Sensortyp gemäß der Android SDK-Dokumentation melden.

• [C-1-2] Sensordaten MÜSSEN mit einer maximalen Latenz von 100 Millisekunden + 2 * sample_time für den Fall eines Sensorstreams mit einer maximalen angeforderten Latenz von 0 ms gemeldet werden, wenn der Anwendungsprozessor aktiv ist. Diese Verzögerung beinhaltet keine Filterverzögerungen.

• [C-1-3] MUSS die erste Sensorprobe innerhalb von 400 Millisekunden + 2 * sample_time nach Aktivierung des Sensors melden. Für dieses Beispiel ist eine Genauigkeit von 0 zulässig.

• [C-1-4] Für jede API, die in der Android SDK-Dokumentation als kontinuierlicher Sensor angegeben ist, MÜSSEN Geräteimplementierungen kontinuierlich periodische Datenproben bereitstellen, die ein Jitter unter 3 % haben SOLLTEN. Jitter ist definiert als die Standardabweichung der Differenz der gemeldeten Zeitstempelwerte zwischen aufeinanderfolgenden Ereignissen.

• [C-1-5] MUSS dafür sorgen, dass der Sensorereignisstream die Geräte-CPU NICHT daran hindert, in den Ruhezustand zu wechseln oder aus dem Ruhezustand aufzuwachen.

• [C-1-6] MUSS die Ereigniszeit in Nanosekunden gemäß der Android SDK-Dokumentation angeben. Sie gibt den Zeitpunkt an, zu dem das Ereignis stattgefunden hat, und wird mit der SystemClock.elapsedRealtimeNano()-Uhr synchronisiert.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, dass der Zeitstempelsynchronisierungsfehler unter 100 Millisekunden liegt, und er SOLLTE unter 1 Millisekunde liegen.

• Wenn mehrere Sensoren aktiviert sind, DARF der Stromverbrauch NICHT die Summe der angegebenen Stromverbräuche der einzelnen Sensoren überschreiten.

Die obige Liste ist nicht vollständig. Das dokumentierte Verhalten des Android SDK und die Android Open Source-Dokumentation zu Sensoren sind maßgeblich.

Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, für den es eine entsprechende API für Drittanbieterentwickler gibt, gilt Folgendes:

• [C-1-6] Für alle Sensoren MUSS eine Auflösung ungleich null festgelegt und der Wert über die API-Methode Sensor.getResolution() gemeldet werden.

Einige Sensortypen sind zusammengesetzt. Das bedeutet, dass sie aus Daten abgeleitet werden können, die von einem oder mehreren anderen Sensoren bereitgestellt werden. Beispiele sind der Orientierungssensor und der Sensor für lineare Beschleunigung.

Geräteimplementierungen:

• SOLLTEN diese Sensortypen implementiert werden, wenn sie die erforderlichen physischen Sensoren enthalten, wie in Sensortypen beschrieben.

Wenn Geräteimplementierungen einen zusammengesetzten Sensor enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN den Sensor wie in der Android Open Source-Dokumentation zu Verbundsensoren beschrieben implementieren.

Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, für den es eine entsprechende API für Drittanbieterentwickler gibt und der Sensor nur einen Wert meldet, gilt Folgendes:

• [C-3-1] MUSS die Auflösung des Sensors auf 1 festlegen und den Wert über die API-Methode Sensor.getResolution() melden.

Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, der SensorAdditionalInfo#TYPE_VEC3_CALIBRATION unterstützt und der Sensor für Drittentwickler verfügbar ist, gilt Folgendes:

• [C-4-1] Die bereitgestellten Daten DÜRFEN keine festen, werkseitig festgelegten Kalibrierungsparameter enthalten.

Wenn Geräteimplementierungen eine Kombination aus einem 3‑Achsen-Beschleunigungsmesser, einem 3‑Achsen-Gyroskop-Sensor oder einem Magnetometer-Sensor enthalten, gilt Folgendes:

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, dafür zu sorgen, dass Beschleunigungsmesser, Gyroskop und Magnetometer eine feste relative Position haben. Wenn das Gerät transformierbar ist (z. B. faltbar), müssen die Sensorachsen in allen möglichen Transformationszuständen des Geräts ausgerichtet und mit dem Sensorkoordinatensystem konsistent sein.

7.3.1. Beschleunigungsmesser

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser einzubauen.

Wenn Geräteimplementierungen einen Beschleunigungsmesser enthalten, gilt Folgendes:

• [C-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 50 Hz melden können.

• [C-1-3] MUSS dem Android-Sensor-Koordinatensystem entsprechen, wie in den Android-APIs beschrieben.

• [C-1-4] MUSS in der Lage sein, Messungen vom freien Fall bis zum Vierfachen des gravity(4g) oder mehr auf jeder Achse durchzuführen.

• [C-1-5] MUSS eine Auflösung von mindestens 12 Bit haben.

• [C-1-6] MUSS eine Standardabweichung von höchstens 0,05 m/s^ haben.Die Standardabweichung sollte achsenweise auf der Grundlage von Stichproben berechnet werden, die über einen Zeitraum von mindestens 3 Sekunden bei der schnellsten Samplingrate erfasst wurden.

• Sollte Ereignisse mit einer Frequenz von mindestens 200 Hz melden.

• SOLLTE eine Auflösung von mindestens 16 Bit haben.

• Sollte während der Verwendung kalibriert werden, wenn sich die Eigenschaften im Laufe des Lebenszyklus ändern, und kompensiert werden. Die Kompensationsparameter sollten zwischen Geräte-Neustarts beibehalten werden.

• Sollte temperaturkompensiert sein.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN den TYPE_ACCELEROMETER-Sensor implementieren und melden.

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, den TYPE_SIGNIFICANT_MOTION-Verbundsensor zu implementieren.

• [C-SR-5] Das Implementieren und Melden des TYPE_ACCELEROMETER_UNCALIBRATED-Sensors wird DRINGEND EMPFOHLEN. Android-Geräte SOLLTEN diese Anforderung unbedingt erfüllen, damit sie auf die zukünftige Plattformversion aktualisiert werden können, in der diese Anforderung möglicherweise ERFORDERLICH wird.

• Sollte die zusammengesetzten Sensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR und TYPE_STEP_COUNTER wie im Android SDK-Dokument beschrieben implementieren.

Wenn Geräteimplementierungen einen Beschleunigungsmesser mit weniger als 3 Achsen enthalten, gilt Folgendes:

• [C-3-1] MÜSSEN den TYPE_ACCELEROMETER_LIMITED_AXES-Sensor implementieren und melden.

• [C-SR-6] Das Implementieren und Melden des TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED-Sensors wird DRINGEND EMPFOHLEN.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser und einen der zusammengesetzten Sensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR oder TYPE_STEP_COUNTER enthalten:

• [C-4-1] Die Summe des Stromverbrauchs MUSS immer unter 4 mW liegen.

• Sollte jeweils unter 2 mW und 0,5 mW liegen, wenn sich das Gerät in einem dynamischen oder statischen Zustand befindet.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser und einen 3‑Achsen-Gyroskop-Sensor enthalten, gilt Folgendes:

• [C-5-1] MÜSSEN die Verbundsensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren.

• [C-SR-7] Es wird DRINGEND EMPFOHLEN, den TYPE_GAME_ROTATION_VECTOR-Verbundsensor zu implementieren.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser, einen 3‑Achsen-Gyroskop-Sensor und einen Magnetometer-Sensor enthalten, gilt Folgendes:

• [C-6-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Verbundsensor implementieren.

7.3.2. Magnetometer

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, ein 3‑Achsen-Magnetometer (Kompass) einzubauen.

Wenn Geräteimplementierungen einen 3‑Achsen-Magnetometer enthalten,

• [C-1-1] MÜSSEN den TYPE_MAGNETIC_FIELD-Sensor implementieren.

• [C-1-2] MUSS Ereignisse mit einer Häufigkeit von mindestens 10 Hz melden können und SOLLTE Ereignisse mit einer Häufigkeit von mindestens 50 Hz melden können.

• [C-1-3] MUSS dem Android-Sensor-Koordinatensystem entsprechen, wie in den Android-APIs beschrieben.

• [C-1-4] MUSS in der Lage sein, auf jeder Achse Werte zwischen -900 µT und +900 µT zu messen, bevor es zur Sättigung kommt.

• [C-1-5] MUSS einen Hard-Iron-Offsetwert von weniger als 700 µT haben und SOLLTE einen Wert von unter 200 µT haben. Dazu muss das Magnetometer weit entfernt von dynamischen (strominduzierten) und statischen (magnetinduzierten) Magnetfeldern platziert werden.

• [C-1-6] MUSS eine Auflösung von mindestens 0,6 µT haben.

• [C-1-7] MUSS die Online-Kalibrierung und ‑Kompensation des Hard-Iron-Bias unterstützen und die Kompensationsparameter zwischen Geräteneustarts beibehalten.

• [C-1-8] Die Kompensation für weiches Eisen MUSS angewendet werden. Die Kalibrierung kann entweder während der Verwendung oder während der Produktion des Geräts erfolgen.

• [C-1-9] MUSS eine Standardabweichung haben, die achsenweise auf der Grundlage von Stichproben berechnet wird, die über einen Zeitraum von mindestens 3 Sekunden bei der schnellsten Samplingrate erfasst werden und nicht größer als 1,5 µT sein DARF; SOLLTE eine Standardabweichung von höchstens 0,5 µT haben.

• [C-1-10] MÜSSEN den TYPE_MAGNETIC_FIELD_UNCALIBRATED-Sensor implementieren.

Wenn Geräteimplementierungen ein 3‑Achsen-Magnetometer, einen Beschleunigungsmesser und einen 3‑Achsen-Gyroskopsensor enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Verbundsensor implementieren.

Wenn Geräteimplementierungen ein 3‑Achsen-Magnetometer und einen Beschleunigungsmesser enthalten,

• KANN den TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor implementieren.

Wenn Geräteimplementierungen ein 3‑Achsen-Magnetometer, einen Beschleunigungsmesser und einen TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor enthalten, gilt Folgendes:

• [C-3-1] MUSS weniger als 10 mW verbrauchen.

• Sollte weniger als 3 mW verbrauchen, wenn der Sensor für den Batchmodus bei 10 Hz registriert ist.

7.3.3. GPS

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, einen GPS-/GNSS-Empfänger einzubauen.

Wenn Geräteimplementierungen einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps an Anwendungen melden, gilt Folgendes:

• [C-1-1] MUSS Standortausgaben mit einer Rate von mindestens 1 Hz unterstützen, wenn sie über LocationManager#requestLocationUpdate angefordert werden.

• [C-1-2] Die HU MUSS unter störungsfreien Bedingungen (starke Signale, vernachlässigbarer Mehrwegeeffekt, HDOP < 2) innerhalb von 10 Sekunden (Zeit bis zur ersten Standortbestimmung) den Standort bestimmen können, wenn eine Internetverbindung mit einer Datenübertragungsgeschwindigkeit von mindestens 0,5 Mbit/s besteht. Diese Anforderung wird in der Regel durch die Verwendung einer Form von Assisted oder Predicted GPS/GNSS erfüllt, um die GPS/GNSS-Verbindungszeit zu minimieren. Zu den Hilfsdaten gehören Referenzzeit, Referenzstandort und Satellitenephemeriden/-uhr.

  • [C-1-6] Nach einer solchen Standortberechnung MÜSSEN Geräteimplementierungen ihren Standort unter störungsfreien Bedingungen innerhalb von 5 Sekunden bestimmen, wenn Standortanfragen neu gestartet werden, und zwar bis zu einer Stunde nach der ersten Standortberechnung, auch wenn die nachfolgende Anfrage ohne Datenverbindung und/oder nach einem Neustart erfolgt.

• Unter störungsfreien Bedingungen nach der Standortbestimmung, wenn das Gerät stillsteht oder sich mit einer Beschleunigung von weniger als 1 Meter pro Sekunde im Quadrat bewegt:

  • [C-1-3] Die HU MUSS in mindestens 95% der Fälle den Standort in einem Radius von 20 Metern und die Geschwindigkeit mit einer Genauigkeit von 0,5 Metern pro Sekunde bestimmen können.

  • [C-1-4] Die HU MUSS gleichzeitig mindestens 8 Satelliten aus einer Konstellation verfolgen und über GnssStatus.Callback melden.

  • Die HU SOLLTE mindestens 24 Satelliten aus mehreren Konstellationen gleichzeitig verfolgen können (z.B. GPS und entweder Glonass, Beidou oder Galileo).

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, während eines Notrufs weiterhin normale GPS/GNSS-Standortausgaben über die GNSS Location Provider APIs bereitzustellen.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, GNSS-Messungen von allen verfolgten Konstellationen (wie in GnssStatus-Nachrichten angegeben) mit Ausnahme von SBAS zu melden.

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, AGC und die Häufigkeit von GNSS-Messungen zu melden.

• [C-SR-5] Es wird DRINGEND EMPFOHLEN, alle Genauigkeitsschätzungen (einschließlich Toleranz, Geschwindigkeit und Höhe) als Teil jeder GPS-/GNSS-Positionsangabe zu melden.

• [C-SR-6] Es wird DRINGEND EMPFOHLEN, GNSS-Messungen zu melden, sobald sie gefunden werden, auch wenn noch kein aus GPS/GNSS berechneter Standort gemeldet wurde.

• [C-SR-7] Es WIRD DRINGEND EMPFOHLEN, GNSS-Pseudobereiche und ‑Pseudobereichsraten zu melden, die unter störungsfreien Bedingungen nach der Standortbestimmung im Stillstand oder bei einer Beschleunigung von weniger als 0,2 m/s² in mindestens 95% der Fälle ausreichen, um die Position mit einer Genauigkeit von 20 Metern und die Geschwindigkeit mit einer Genauigkeit von 0,2 m/s zu berechnen.

7.3.4. Gyroskop

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, einen Gyroskopsensor einzubauen.

Wenn Geräteimplementierungen ein Gyroskop enthalten, gilt Folgendes:

• [C-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 50 Hz melden können.

• [C-1-4] MUSS eine Auflösung von mindestens 12 Bit haben.

• [C-1-5] MUSS temperaturkompensiert sein.

• [C-1-6] MUSS während der Verwendung kalibriert und kompensiert werden und die Kompensationsparameter zwischen Geräte-Neustarts beibehalten.

• [C-1-7] Die Varianz darf nicht größer als 1e-7 rad^2 / s^2 pro Hz sein (Varianz pro Hz oder rad^2 / s). Die Varianz darf sich mit der Stichprobenrate ändern, MUSS aber durch diesen Wert begrenzt werden. Wenn Sie die Varianz des Gyroskops bei einer Abtastrate von 1 Hz messen, SOLLTE sie nicht größer als 1e-7 rad²/s² sein.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, dass der Kalibrierungsfehler weniger als 0,01 rad/s beträgt, wenn das Gerät bei Raumtemperatur stillsteht.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, eine Auflösung von mindestens 16 Bit zu verwenden.

• Sollte Ereignisse mit einer Frequenz von mindestens 200 Hz melden.

Wenn Geräteimplementierungen ein 3‑Achsen-Gyroskop enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN den TYPE_GYROSCOPE-Sensor implementieren.

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, den TYPE_GYROSCOPE_UNCALIBRATED-Sensor zu implementieren.

Wenn Geräteimplementierungen ein Gyroskop mit weniger als 3 Achsen enthalten, gilt Folgendes:

• [C-3-1] MÜSSEN den TYPE_GYROSCOPE_LIMITED_AXES-Sensor implementieren und melden.

• [C-SR-5] Das Implementieren und Melden des TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED-Sensors wird DRINGEND EMPFOHLEN.

Wenn Geräteimplementierungen ein 3‑Achsen-Gyroskop, einen Beschleunigungsmesser und einen Magnetometer-Sensor enthalten, gilt Folgendes:

• [C-4-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Verbundsensor implementieren.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser und einen 3‑Achsen-Gyroskop-Sensor enthalten, gilt Folgendes:

• [C-5-1] MÜSSEN die Verbundsensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren.

• [C-SR-6] Es wird DRINGEND EMPFOHLEN, den TYPE_GAME_ROTATION_VECTOR-Verbundsensor zu implementieren.

7.3.5. Barometer

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, ein Barometer (Sensor für den Umgebungsdruck) einzubauen.

Wenn Geräteimplementierungen ein Barometer enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN den TYPE_PRESSURE-Sensor implementieren und melden.

• [C-1-2] MUSS Ereignisse mit mindestens 5 Hz liefern können.

• [C-1-3] MUSS temperaturkompensiert sein.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, Druckmessungen im Bereich von 300 hPa bis 1.100 hPa melden zu können.

• SOLLTE eine absolute Genauigkeit von 1 hPa haben.

• SOLLTE eine relative Genauigkeit von 0,12 hPa über einen Bereich von 20 hPa haben (entspricht einer Genauigkeit von etwa 1 m über eine Änderung von etwa 200 m auf Meereshöhe).

Geräteimplementierungen, die die Systemeigenschaft sensor.barometer.high_quality.implemented deklarieren:

• [C-2-1] MUSS Druckmessungen im Bereich von 300 hPa bis 1.100 hPa mit einer absoluten Genauigkeit von +/- 1 hPa melden.

• [C-2-2] MUSS eine relative Genauigkeit von 0,15 hPa über einen Bereich von 100 hPa haben, was einer Genauigkeit von etwa 1 m über eine Änderung von etwa 1.000 m auf Meereshöhe entspricht.

• [C-2-3] MUSS innerhalb von ±0,5 hPa stabil sein, wenn der Nutzer auf das Gerät tippt, es drückt oder zusammendrückt.

• [C-2-4] MUSS innerhalb von ±0,15 hPa stabil sein, wenn der Nutzer das Gerät in der Hand oder in der Tasche trägt.

• [C-2-5] MUSS bei Aktivierungen über 5 Hz mit einer Zeitkonstante von höchstens 300 ms geglättet werden und die Glättung DARF NICHT über Sensoraktivierungen hinweg erfolgen.

• [C-2-6] MUSS bei normaler Beleuchtung und Funkfrequenzen, die von gängigen Quellen wie Bluetooth, Mobilfunkverbindung oder WLAN ausgehen, innerhalb von ±0,15 hPa stabil sein.

7.3.6. Thermometer

Wenn Geräteimplementierungen ein Umgebungsthermometer (Temperatursensor) enthalten, gilt Folgendes:

• [C-1-1] SENSOR_TYPE_AMBIENT_TEMPERATURE MUSS für den Umgebungstemperatursensor definiert werden und der Sensor MUSS die Umgebungstemperatur (Raum-/Fahrzeugkabine) in Grad Celsius messen, von der aus der Nutzer mit dem Gerät interagiert.

Wenn Geräteimplementierungen einen Thermometersensor enthalten, der eine andere Temperatur als die Umgebungstemperatur misst, z. B. die CPU-Temperatur, gilt Folgendes:

• [C-2-1] Für den Temperatursensor darf SENSOR_TYPE_AMBIENT_TEMPERATURE NICHT definiert werden.

Wenn Geräteimplementierungen einen Sensor zur Überwachung der Hauttemperatur enthalten, gilt Folgendes:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die PowerManager.getThermalHeadroom API zu unterstützen.

7.3.7. Photometer

• Geräteimplementierungen KÖNNEN ein Fotometer (Umgebungslicht-Sensor) enthalten.

7.3.8. Näherungssensor

• Geräteimplementierungen KÖNNEN einen Näherungssensor enthalten.

Wenn Geräteimplementierungen einen Näherungssensor enthalten und nur einen binären „near“- oder „far“-Wert melden, gilt Folgendes:

• [C-1-1] Die Nähe eines Objekts muss in derselben Richtung wie der Bildschirm gemessen werden. Das heißt, der Näherungssensor MUSS so ausgerichtet sein, dass er Objekte in der Nähe des Displays erkennt, da der primäre Zweck dieses Sensortyps darin besteht, ein Smartphone zu erkennen, das vom Nutzer verwendet wird. Wenn Geräteimplementierungen einen Näherungssensor mit einer anderen Ausrichtung enthalten, DARF er NICHT über diese API zugänglich sein.

• [C-1-2] MUSS eine Genauigkeit von mindestens 1 Bit haben.

• [C-1-3] Es MUSS 0 cm als Nahmessung und 5 cm als Fernmessung verwendet werden.

• [C-1-4] MUSS einen maximalen Bereich und eine Auflösung von 5 melden.

7.3.9. Zuverlässige Sensoren

Wenn Geräteimplementierungen eine Reihe von Sensoren höherer Qualität enthalten, wie in diesem Abschnitt definiert, und diese für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS die Funktion über das Funktions-Flag android.hardware.sensor.hifi_sensors identifizieren.

Wenn Geräteimplementierungen android.hardware.sensor.hifi_sensors deklarieren, gilt Folgendes:

• [C-2-1] MUSS einen TYPE_ACCELEROMETER-Sensor haben, der:

  • MUSS einen Messbereich zwischen mindestens -8 g und +8 g haben und es wird DRINGEND EMPFOHLEN, einen Messbereich zwischen mindestens -16 g und +16 g zu haben.

  • MUSS eine Messauflösung von mindestens 2048 LSB/g haben.

  • Die Mindestmesshäufigkeit MUSS 12,5 Hz oder weniger betragen.

  • MUSS eine maximale Messfrequenz von mindestens 400 Hz haben; SOLLTE den SensorDirectChannel RATE_VERY_FAST unterstützen.

  • Das Messrauschen darf nicht über 400 μg/√Hz liegen.

  • MUSS eine nicht aufweckende Form dieses Sensors mit einer Pufferkapazität von mindestens 3.000 Sensorereignissen implementieren.

  • Der Stromverbrauch für Batching darf nicht höher als 3 mW sein.

  • [C-SR-1] Es wird DRINGEND EMPFOHLEN, eine 3‑dB-Messbandbreite von mindestens 80% der Nyquist-Frequenz und ein weißes Rauschspektrum innerhalb dieser Bandbreite zu haben.

  • SOLLTE bei Raumtemperatur einen zufälligen Gang der Beschleunigung von weniger als 30 μg √Hz aufweisen.

  • Die Bias-Änderung im Vergleich zur Temperatur SOLLTE ≤ +/- 1 mg/°C betragen.

  • Die Nichtlinearität der Best-Fit-Linie SOLLTE ≤ 0,5 % betragen und die Empfindlichkeitsänderung im Verhältnis zur Temperatur SOLLTE ≤ 0,03%/C° betragen.

  • Sollte eine Querachsensensitivität von < 2,5 % und eine Variation der Querachsensensitivität von < 0,2% im Betriebstemperaturbereich des Geräts aufweisen.

• [C-2-2] MUSS ein TYPE_ACCELEROMETER_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_ACCELEROMETER haben.

• [C-2-3] MUSS einen TYPE_GYROSCOPE-Sensor haben, der:

  • MUSS einen Messbereich von mindestens -1.000 bis +1.000 dps haben.

  • MUSS eine Messauflösung von mindestens 16 LSB/dps haben.

  • Die Mindestmesshäufigkeit MUSS 12,5 Hz oder weniger betragen.

  • MUSS eine maximale Messfrequenz von mindestens 400 Hz haben; SOLLTE den SensorDirectChannel RATE_VERY_FAST unterstützen.

  • MUSS ein Messrauschen von höchstens 0,014 °/s/√Hz haben.

  • [C-SR-2] Es wird DRINGEND EMPFOHLEN, dass die 3‑dB-Messbandbreite mindestens 80% der Nyquist-Frequenz beträgt und das weiße Rauschen in diesem Frequenzbereich weiß ist.

  • SOLLTE einen Raten-Random-Walk von weniger als 0,001°/s √Hz bei Raumtemperatur haben.

  • Die Bias-Änderung im Vergleich zur Temperatur SOLLTE ≤ +/- 0,05 °/ s / °C betragen.

  • Die Empfindlichkeit sollte sich im Vergleich zur Temperatur um höchstens 0,02% / °C ändern.

  • SOLLTE eine Nichtlinearität der Ausgleichsgeraden von ≤ 0,2 % aufweisen.

  • SOLLTE eine Rauschdichte von ≤ 0,007°/s/√Hz haben.

  • Der Kalibrierungsfehler SOLLTE im Temperaturbereich von 10 bis 40 °C weniger als 0,002 rad/s betragen, wenn das Gerät nicht bewegt wird.

  • SOLLTE eine G-Empfindlichkeit von weniger als 0,1 °/s/g haben.

  • Sollte eine Querachsensensitivität von < 4,0 % und eine Querachsensensitivitätsabweichung von < 0,3% im Betriebstemperaturbereich des Geräts aufweisen.

• [C-2-4] MUSS ein TYPE_GYROSCOPE_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_GYROSCOPE haben.

• [C-2-5] MUSS einen TYPE_GEOMAGNETIC_FIELD-Sensor haben, der

  • MUSS einen Messbereich von mindestens -900 bis +900 μT haben.

  • MUSS eine Messauflösung von mindestens 5 LSB/uT haben.

  • Die Mindestmesshäufigkeit MUSS 5 Hz oder weniger betragen.

  • MUSS eine maximale Messfrequenz von mindestens 50 Hz haben.

  • MUSS ein Messrauschen von höchstens 0,5 µT aufweisen.

• [C-2-6] MUSS ein TYPE_MAGNETIC_FIELD_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_GEOMAGNETIC_FIELD haben und zusätzlich:

  • MUSS eine nicht aufweckende Form dieses Sensors mit einer Pufferkapazität von mindestens 600 Sensorereignissen implementieren.

  • [C-SR-3] Es wird DRINGEND EMPFOHLEN, ein Rauschen mit einem Spektrum von 1 Hz bis mindestens 10 Hz zu verwenden, wenn die Berichtsrate 50 Hz oder höher ist.

• [C-2-7] MUSS einen TYPE_PRESSURE-Sensor haben, der:

  • MUSS einen Messbereich zwischen mindestens 300 und 1.100 hPa haben.

  • MUSS eine Messauflösung von mindestens 80 LSB/hPa haben.

  • Die Mindestmesshäufigkeit MUSS 1 Hz oder weniger betragen.

  • MUSS eine maximale Messfrequenz von mindestens 10 Hz haben.

  • MUSS ein Messrauschen von höchstens 2 Pa/√Hz aufweisen.

  • MUSS eine nicht aufweckende Form dieses Sensors mit einer Pufferkapazität von mindestens 300 Sensorereignissen implementieren.

  • Der Stromverbrauch für das Batching darf nicht höher als 2 mW sein.

• [C-2-8] MUSS einen TYPE_GAME_ROTATION_VECTOR-Sensor haben.

• [C-2-9] MUSS einen TYPE_SIGNIFICANT_MOTION-Sensor haben, der:

  • Der Stromverbrauch darf nicht höher als 0,5 mW sein, wenn das Gerät statisch ist, und nicht höher als 1,5 mW, wenn es sich bewegt.

• [C-2-10] MUSS einen TYPE_STEP_DETECTOR-Sensor haben, der:

  • MUSS eine nicht aufweckende Form dieses Sensors mit einer Pufferkapazität von mindestens 100 Sensorereignissen implementieren.

  • Der Stromverbrauch darf nicht höher als 0,5 mW sein, wenn das Gerät statisch ist, und nicht höher als 1,5 mW, wenn es sich bewegt.

  • Der Stromverbrauch beim Batching MUSS unter 4 mW liegen.

• [C-2-11] MUSS einen TYPE_STEP_COUNTER-Sensor haben, der:

  • Der Stromverbrauch darf nicht höher als 0,5 mW sein, wenn das Gerät statisch ist, und nicht höher als 1,5 mW, wenn es sich bewegt.

• [C-2-12] MUSS einen TILT_DETECTOR-Sensor haben, der:

  • Der Stromverbrauch darf nicht höher als 0,5 mW sein, wenn das Gerät statisch ist, und nicht höher als 1,5 mW, wenn es sich bewegt.

• [C-2-13] Der Ereigniszeitstempel desselben physischen Ereignisses, das vom Beschleunigungsmesser, Gyroskop und Magnetometer gemeldet wird, MUSS innerhalb von 2,5 Millisekunden voneinander liegen. Der Ereigniszeitstempel desselben physischen Ereignisses, das vom Beschleunigungsmesser und vom Gyroskop gemeldet wird, SOLLTE innerhalb von 0,25 Millisekunden liegen.

• [C-2-14] MUSS Zeitstempel für Gyroskopsensorereignisse auf derselben Zeitbasis wie das Kamerasubsystem und mit einem Fehler von maximal 1 Millisekunde haben.

• [C-2-15] MUSS innerhalb von 5 Millisekunden nach dem Zeitpunkt, zu dem die Daten auf einem der oben genannten physischen Sensoren für die Anwendung verfügbar sind, Stichproben an Anwendungen liefern.

• [C-2-16] DARF bei statischem Gerät nicht mehr als 0,5 mW und bei bewegtem Gerät nicht mehr als 2,0 mW verbrauchen, wenn eine beliebige Kombination der folgenden Sensoren aktiviert ist:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] MAY have a TYPE_PROXIMITY sensor, but if present MUST have a minimum buffer capability of 100 sensor events.

Beachte, dass alle Anforderungen an den Stromverbrauch in diesem Abschnitt nicht den Stromverbrauch des Anwendungsprozessors umfassen. Dazu gehört auch die Leistung, die von der gesamten Sensorkette aufgenommen wird, also vom Sensor, von der unterstützenden Elektronik, von einem dedizierten Sensorverarbeitungssystem usw.

Wenn Geräteimplementierungen eine direkte Sensorunterstützung enthalten, gilt Folgendes:

• [C-3-1] MUSS die Unterstützung von direkten Kanaltypen und die Ebene der direkten Melderaten über die API isDirectChannelTypeSupported und getHighestDirectReportRateLevel korrekt deklarieren.

• [C-3-2] MUSS mindestens einen der beiden direkten Sensor-Kanaltypen für alle Sensoren unterstützen, die die Unterstützung für den direkten Sensor-Kanal deklarieren.

  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE

• Sollte die Ereignisberichterstellung über den direkten Sensorchannel für den primären Sensor (Nicht-Wakeup-Variante) der folgenden Typen unterstützen:

  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Biometrische Sensoren

Weitere Informationen zum Messen der Sicherheit beim biometrischen Entsperren finden Sie in der Dokumentation zum Messen der biometrischen Sicherheit.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm enthalten, gilt Folgendes:

• SOLLTE einen biometrischen Sensor enthalten

Biometrische Sensoren können als Klasse 3 (früher Stark) klassifiziert werden.

Klasse 2 (früher Schwach) oder Klasse 1 (früher Nutzerfreundlichkeit) basierend auf den Akzeptanzraten für Spoofing und Identitätsdiebstahl sowie auf der Sicherheit der biometrischen Pipeline. Diese Klassifizierung bestimmt die Funktionen, die der biometrische Sensor für die Interaktion mit der Plattform und mit Drittanbieteranwendungen hat. Sensoren müssen zusätzliche Anforderungen erfüllen, die unten aufgeführt sind, wenn sie als Klasse 1, Klasse 2 oder Klasse 3 eingestuft werden sollen. Sowohl Biometrie der Klasse 2 als auch Biometrie der Klasse 3 erhalten zusätzliche Funktionen, wie unten beschrieben.

Wenn Geräteimplementierungen einen biometrischen Sensor für Drittanbieteranwendungen über android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt und android.provider.Settings.ACTION_BIOMETRIC_ENROLL verfügbar machen, gilt Folgendes:

• [C-4-1] MÜSSEN die in diesem Dokument definierten Anforderungen für biometrische Daten der Klasse 3 oder Klasse 2 erfüllen.

• [C-4-2] MUSS jeden Parameternamen, der als Konstante in der Klasse Authenticators definiert ist, und alle Kombinationen davon erkennen und berücksichtigen. Umgekehrt DÜRFEN keine Integer-Konstanten berücksichtigt oder erkannt werden, die an die Methoden canAuthenticate(int) und setAllowedAuthenticators(int) übergeben werden, die nicht als öffentliche Konstanten in Authenticators und Kombinationen davon dokumentiert sind.

• [C-4-3] Die Aktion ACTION_BIOMETRIC_ENROLL MUSS auf Geräten mit biometrischen Verfahren der Klasse 3 oder Klasse 2 implementiert werden. Bei dieser Aktion DÜRFEN NUR die Registrierungspunkte für biometrische Verfahren der Klasse 3 oder Klasse 2 angezeigt werden.

• [C-4-4] Anwendungen MÜSSEN es ermöglichen, BiometricPrompt benutzerdefinierte Inhalte hinzuzufügen, indem die PromptContentView-Inhaltsanzeigeformate verwendet werden. Die Formate für die Inhaltsdarstellung DÜRFEN NICHT erweitert werden, um Bilder, Links, interaktive Inhalte oder andere Medien zu ermöglichen, die nicht bereits Teil der BiometricPrompt-API sind. Stilistische Anpassungen, die diese Inhalte nicht verändern, verdecken oder abschneiden, sind zulässig (z. B. Änderung von Position, Innenabstand, Rändern und Typografie).

Wenn Geräteimplementierungen passive Biometrie unterstützen, gilt Folgendes:

• [C-5-1] MUSS standardmäßig einen zusätzlichen Bestätigungsschritt erfordern (z.B. das Drücken einer Schaltfläche).

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, eine Einstellung zu haben, mit der Nutzer die Anwendungseinstellung überschreiben und immer einen begleitenden Bestätigungsschritt benötigen können.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, die Bestätigungsaktion so zu sichern, dass sie nicht durch eine Kompromittierung des Betriebssystems oder des Kernels gefälscht werden kann. Das bedeutet beispielsweise, dass die Bestätigungsaktion, die auf einer physischen Taste basiert, über einen reinen Eingabe-GPIO-Pin (General-Purpose Input/Output) eines Secure Elements (SE) geleitet wird, der nur durch Drücken einer physischen Taste ausgelöst werden kann.

• [C-5-2] Es MUSS zusätzlich ein impliziter Authentifizierungsablauf (ohne Bestätigungsschritt) entsprechend setConfirmationRequired(boolean) implementiert werden, der von Anwendungen für Anmeldeabläufe verwendet werden kann.

Wenn Geräteimplementierungen mehrere biometrische Sensoren haben, gilt Folgendes:

• [C-7-1] MUSS, wenn eine biometrische Methode gesperrt ist (d.h. die biometrische Methode ist deaktiviert, bis der Nutzer die primäre Authentifizierung verwendet) oder eine zeitgebundene Sperrung vorliegt (d.h. die biometrische Methode ist vorübergehend deaktiviert, bis der Nutzer ein Zeitintervall abwartet) aufgrund zu vieler fehlgeschlagener Versuche, auch alle anderen biometrischen Methoden einer niedrigeren biometrischen Klasse sperren. Im Falle einer zeitgebundenen Sperrung MUSS die Backoff-Zeit für die biometrische Bestätigung die maximale Backoff-Zeit aller biometrischen Verfahren in der zeitgebundenen Sperrung sein.

• [C-SR-12] Es wird DRINGEND EMPFOHLEN, bei einer biometrischen Sperrung (d.h. die biometrische Authentifizierung ist deaktiviert, bis der Nutzer die primäre Authentifizierung verwendet) oder einer zeitgebundenen Sperrung (d.h. die biometrische Authentifizierung ist vorübergehend deaktiviert, bis der Nutzer ein Zeitintervall abwartet) aufgrund zu vieler fehlgeschlagener Versuche auch alle anderen biometrischen Authentifizierungen derselben biometrischen Klasse zu sperren. Bei einer zeitgebundenen Sperrung wird DRINGEND EMPFOHLEN, dass die Backoff-Zeit für die biometrische Bestätigung der maximalen Backoff-Zeit aller biometrischen Verfahren bei einer zeitgebundenen Sperrung entspricht.

• [C-7-2] MUSS den Nutzer zur Eingabe der empfohlenen primären Authentifizierung (z. B. PIN, Muster oder Passwort) auffordern, um den Sperrzähler für ein gesperrtes biometrisches Verfahren zurückzusetzen. Biometrische Daten der Klasse 3 DÜRFEN verwendet werden, um den Sperrzähler für biometrische Daten derselben oder einer niedrigeren Klasse zurückzusetzen. Biometrische Daten der Klasse 2 oder Klasse 1 DÜRFEN NICHT verwendet werden, um die Zurücksetzung der Sperre für biometrische Daten abzuschließen.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, dass bei der Authentifizierung nur ein biometrisches Verfahren bestätigt werden muss (wenn auf dem Gerät sowohl Fingerabdruck- als auch Gesichtssensoren verfügbar sind, sollte onAuthenticationSucceeded gesendet werden, nachdem eines der beiden Verfahren bestätigt wurde).

Damit Geräteimplementierungen den Zugriff auf Schlüsselspeicher-Schlüssel für Drittanbieteranwendungen ermöglichen, müssen sie:

• [C-6-1] MUSS die Anforderungen für Klasse 3 erfüllen, wie in diesem Abschnitt unten definiert.

• [C-6-2] Es DÜRFEN nur biometrische Verfahren der Klasse 3 präsentiert werden, wenn für die Authentifizierung BIOMETRIC_STRONG erforderlich ist oder die Authentifizierung mit einem CryptoObject aufgerufen wird.

Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 1 (früher Nutzerfreundlichkeit) behandeln möchten, müssen sie Folgendes beachten:

• [C-1-1] MUSS eine Falschakzeptanzrate von unter 0,002 % haben.

• [C-1-2] Es MUSS offengelegt werden, dass dieser Modus möglicherweise weniger sicher ist als eine komplexe PIN, ein komplexes Muster oder ein komplexes Passwort, und die Risiken der Aktivierung müssen klar aufgeführt werden, wenn die Akzeptanzraten für Spoofing und Identitätsdiebstahl gemäß den Android Biometrics Test Protocols höher als 7% sind.

• [C-1-9] Der Nutzer MUSS nach höchstens 20 Fehlversuchen und einer Backoff-Zeit von mindestens 90 Sekunden für die biometrische Überprüfung zur Eingabe der empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden. Ein Fehlversuch ist ein Versuch mit einer angemessenen Erfassungsqualität (BIOMETRIC_ACQUIRED_GOOD), der nicht mit einem registrierten biometrischen Merkmal übereinstimmt.

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, die in [C-1-9] angegebene Gesamtzahl der Falschversuche für die biometrische Überprüfung zu senken, wenn die Akzeptanzraten für Spoofing und Betrüger gemäß den Android Biometrics Test Protocols höher als 7% sind.

• [C-1-3] Es MUSS eine Ratenbegrenzung für Versuche zur biometrischen Überprüfung geben. Ein Fehlversuch ist ein Versuch mit einer angemessenen Erfassungsqualität (BIOMETRIC_ACQUIRED_GOOD), der nicht mit einem registrierten biometrischen Merkmal übereinstimmt.

• [C-SR-5] Es wird DRINGEND EMPFOHLEN, Versuche zur biometrischen Bestätigung nach fünf Fehlversuchen für mindestens 30 Sekunden zu begrenzen. Die maximale Anzahl von Fehlversuchen pro [C-1-9] ist dabei zu berücksichtigen. Ein Fehlversuch ist ein Versuch mit einer angemessenen Erfassungsqualität (BIOMETRIC_ACQUIRED_GOOD), der nicht mit einer registrierten biometrischen Methode übereinstimmt.

• [C-SR-6] Es wird DRINGEND EMPFOHLEN, die gesamte Ratenbegrenzungslogik im TEE zu implementieren.

• [C-1-10] Die biometrische Authentifizierung MUSS deaktiviert werden, sobald der primäre Authentifizierungs-Backoff wie in [C-0-2] von Abschnitt 9.11 beschrieben ausgelöst wurde.

• [C-1-11] MUSS eine Akzeptanzrate für Spoofing und Identitätsdiebstahl von höchstens 30 % haben, wobei (1) die Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten (Presentation Attack Instrument) der Stufe A höchstens 30 % und (2) die Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten der Stufe B höchstens 40 % betragen darf, wie in den Android Biometrics Test Protocols (Android-Biometrie-Testprotokollen) gemessen.

• [C-1-4] Es MUSS verhindert werden, dass neue biometrische Daten hinzugefügt werden, ohne dass zuerst eine Vertrauenskette aufgebaut wird, indem der Nutzer ein vorhandenes oder neues Geräte-Anmeldedatum (PIN/Muster/Passwort) bestätigt, das durch die TEE geschützt ist. Die Android Open Source Project-Implementierung bietet den Mechanismus im Framework, um dies zu tun.

• [C-1-5] ALLE identifizierbaren biometrischen Daten eines Nutzers MÜSSEN vollständig entfernt werden, wenn das Konto des Nutzers entfernt wird (auch durch Zurücksetzen auf die Werkseinstellungen) oder wenn die empfohlene primäre Authentifizierung (z. B. PIN, Muster, Passwort) entfernt wird.

• [C-1-6] MUSS das individuelle Flag für das jeweilige biometrische Verfahren berücksichtigen (d.h. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE oder DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

• [C-1-7] Der Nutzer MUSS mindestens alle 24 Stunden zur empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden.

• [C-1-8] Der Nutzer MUSS zur Eingabe der empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) oder der biometrischen Authentifizierung der Klasse 3 (STRONG) aufgefordert werden, wenn einer der folgenden Fälle eintritt:

  • Ein Zeitlimit von 4 Stunden bei Inaktivität.
  • 3 fehlgeschlagene Versuche zur biometrischen Authentifizierung.
  • Die Zeitüberschreitung bei Inaktivität und die Anzahl der fehlgeschlagenen Authentifizierungen werden nach jeder erfolgreichen Bestätigung der Geräteanmeldedaten zurückgesetzt.

• [C-SR-7] Es wird DRINGEND EMPFOHLEN, die Logik im Framework zu verwenden, das vom Open-Source-Projekt für Android bereitgestellt wird, um die in [C-1-7] und [C-1-8] angegebenen Einschränkungen für neue Geräte durchzusetzen.

• [C-SR-8] Es wird DRINGEND EMPFOHLEN, dass die Falsch-Zurückweisungsrate auf dem Gerät gemessen weniger als 10 % beträgt.

• [C-SR-9] Es wird DRINGEND EMPFOHLEN, dass die Latenz für jedes registrierte biometrische Verfahren unter 1 Sekunde liegt. Die Latenz wird ab dem Zeitpunkt gemessen, an dem die biometrischen Daten erkannt werden, bis der Bildschirm entsperrt wird.

• [C-1-12] MUSS eine Akzeptanzrate für Spoofing und Identitätsdiebstahl von höchstens 40 % pro Art von Präsentationsangriffsinstrument (Presentation Attack Instrument, PAI) aufweisen, gemessen anhand der Android Biometrics Test Protocols.

• [C-SR-13] Es wird DRINGEND EMPFOHLEN, dass die Akzeptanzrate von Spoofing und Identitätsdiebstahl nicht höher als 30 % pro Art von PAI (Presentation Attack Instrument) ist, gemessen anhand der Android Biometrics Test Protocols.

• [C-SR-8] Es wird DRINGEND EMPFOHLEN, dass die Falsch-Zurückweisungsrate auf dem Gerät gemessen weniger als 10 % beträgt.

• [C-1-15] Nutzer MÜSSEN einzelne oder mehrere biometrische Registrierungen entfernen können.

• [C-SR-14] Es wird DRINGEND EMPFOHLEN, die biometrische Klasse des biometrischen Sensors und die entsprechenden Risiken bei der Aktivierung anzugeben.

• [C-SR-17] Es wird DRINGEND EMPFOHLEN, die neuen AIDL-Schnittstellen (z. B. IFace.aidl und IFingerprint.aidl) zu implementieren.

Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 2 (früher Schwach) behandeln möchten, müssen sie Folgendes tun:

• [C-2-1] MUSS alle Anforderungen für Klasse 1 oben erfüllen.

• [C-2-2] MUSS eine Akzeptanzrate für Spoofing und Identitätsdiebstahl von höchstens 20 % haben, mit (1) einer Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten (Presentation Attack Instrument) der Stufe A von höchstens 20 % und (2) einer Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten der Stufe B von höchstens 30%, gemessen anhand der Android Biometrics Test Protocols.

• [C-SR-15] Es wird DRINGEND EMPFOHLEN, dass die Akzeptanzrate von Spoofing und Identitätsdiebstahl pro Art von PAI (Presentation Attack Instrument) nicht höher als 20 % ist, wie in den Android Biometrics Test Protocols (Android-Biometrie-Testprotokollen) gemessen.

• [C-2-3] MUSS den biometrischen Abgleich in einer isolierten Ausführungsumgebung außerhalb des Android-Nutzer- oder Kernelbereichs durchführen, z. B. in der vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) auf einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder auf einer geschützten virtuellen Maschine, die die Anforderungen in Abschnitt 9.17 erfüllt.

• [C-2-4] ALLE identifizierbaren Daten MÜSSEN verschlüsselt und kryptografisch authentifiziert werden, sodass sie nicht außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal zur isolierten Ausführungsumgebung erfasst, gelesen oder geändert werden können. Dies muss gemäß der Implementierungsrichtlinien auf der Open-Source-Projekt für Android-Website oder einer geschützten virtuellen Maschine, die von einem Hypervisor gesteuert wird, der die Anforderungen in Abschnitt 9.17 erfüllt, dokumentiert werden.

• [C-2-5] Bei kamerabasierter Biometrie während der biometrischen Authentifizierung oder Registrierung:

  • Die Kamera MUSS in einem Modus betrieben werden, der verhindert, dass Kamerabilder außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder einer geschützten virtuellen Maschine, die von einem Hypervisor gesteuert wird, der die Anforderungen in Abschnitt 9.17 erfüllt, gelesen oder geändert werden.

  • Bei RGB-Einzelkameralösungen können die Kamerabilder außerhalb der isolierten Ausführungsumgebung lesbar sein, um Vorgänge wie die Vorschau für die Registrierung zu unterstützen. Sie dürfen jedoch nicht geändert werden.

• [C-2-6] Drittanbieteranwendungen DÜRFEN nicht in der Lage sein, zwischen einzelnen biometrischen Registrierungen zu unterscheiden.

• [C-2-7] Der Zugriff auf identifizierbare biometrische Daten oder daraus abgeleitete Daten (z. B. Einbettungen) darf dem Anwendungsprozessor außerhalb des Kontexts des TEE oder der geschützten virtuellen Maschine, die vom Hypervisor gesteuert wird, der die Anforderungen in Abschnitt 9.17 erfüllt, NICHT unverschlüsselt gestattet werden. Geräte, die mit Android 9 oder niedriger auf den Markt gekommen sind, sind nicht von [C-2-7] ausgenommen.

• [C-2-8] Es MUSS eine sichere Verarbeitungspipeline vorhanden sein, sodass durch eine Kompromittierung des Betriebssystems oder des Kernels keine Daten direkt eingefügt werden können, um sich fälschlicherweise als Nutzer zu authentifizieren.

• [C-SR-10] Es wird DRINGEND EMPFOHLEN, eine Lebenderkennung für alle biometrischen Modalitäten und eine Aufmerksamkeitserkennung für die Gesichtserkennung einzubauen.

• [C-2-9] MUSS den biometrischen Sensor für Drittanbieteranwendungen zur Verfügung stellen.

Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 3 (früher Stark) behandeln möchten, müssen sie:

• [C-3-1] MUSS alle Anforderungen von Klasse 2 oben erfüllen, mit Ausnahme von [C-1-7] und [C-1-8].

• [C-3-2] MUSS eine hardwaregestützte Keystore-Implementierung haben.

• [C-3-3] MUSS eine Akzeptanzrate für Spoofing und Identitätsdiebstahl von höchstens 7 % aufweisen, mit (1) einer Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten (Presentation Attack Instrument) der Stufe A von höchstens 7 % und (2) einer Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten der Stufe B von höchstens 20%, gemessen anhand der Android Biometrics Test Protocols.

• [C-3-4] Der Nutzer MUSS mindestens alle 72 Stunden zur primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden.

• [C-3-5] MUSS die Authenticator-ID für alle auf dem Gerät unterstützten biometrischen Verfahren der Klasse 3 neu generieren, wenn eines davon neu registriert wird.

• [C-3-6] Biometriebasierte Keystore-Schlüssel müssen für Drittanbieteranwendungen aktiviert werden.

• [C-SR-16] Es wird DRINGEND EMPFOHLEN, dass die Akzeptanzrate für Spoofing und Identitätsdiebstahl nicht höher als 7% pro Art von PAI (Presentation Attack Instrument) ist, gemessen anhand der Android Biometrics Test Protocols.

Wenn Geräteimplementierungen einen Fingerabdrucksensor unter dem Display enthalten, gilt Folgendes:

• [C-SR-11] Es wird DRINGEND EMPFOHLEN, zu verhindern, dass der berührbare Bereich des Fingerabdrucksensors unter dem Display die Bedienung über 3 Buttons beeinträchtigt (die einige Nutzer möglicherweise aus Gründen der Barrierefreiheit benötigen).

7.3.11. Pose-Sensor

Geräteimplementierungen:

• Unterstützt möglicherweise den Lagesensor mit 6 Freiheitsgraden.

Wenn Geräteimplementierungen den Lagesensor mit 6 Freiheitsgraden unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN den TYPE_POSE_6DOF-Sensor implementieren und melden.

• [C-1-2] MUSS genauer sein als der Rotationsvektor allein.

7.3.12. Sensor für Scharnierwinkel

Wenn Geräteimplementierungen einen Scharnierwinkelsensor unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN TYPE_HINGE_ANGLE implementieren und melden.

• [C-1-2] MUSS mindestens zwei Messwerte zwischen 0 und 360 Grad (einschließlich 0 und 360 Grad) unterstützen.

• [C-1-3] MÜSSEN für getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) einen Wake-up-Sensor zurückgeben.

7.3.13. IEEE 802.1.15.4 (UWB)

Wenn Geräteimplementierungen Unterstützung für 802.1.15.4 enthalten und die Funktionalität für eine Drittanbieteranwendung verfügbar machen, gilt Folgendes:

• [C-1-2] MUSS das Hardware-Funktions-Flag android.hardware.uwb melden.

• [C-1-3] MUSS alle folgenden Konfigurationssätze (vordefinierte Kombinationen von FIRA UCI-Parametern) unterstützen, die in der AOSP-Implementierung definiert sind.

  • CONFIG_ID_1: Von FiRa definierte Unicast-STATIC STS DS-TWR-Entfernungsmessung, verzögerter Modus, Entfernungsmessungsintervall 240 ms.

  • CONFIG_ID_2: Von FiRa definierte STATIC STS DS-TWR-Entfernungsmessung (One-to-Many), verzögerter Modus, Entfernungsmessungsintervall 200 ms. Typischer Anwendungsfall: Smartphone interagiert mit vielen Smart-Home-Geräten.

  • CONFIG_ID_3: Wie CONFIG_ID_1, nur dass keine Daten zum Einfallswinkel (Angle-of-Arrival, AoA) erfasst werden.

  • CONFIG_ID_4: Wie CONFIG_ID_1, aber mit aktiviertem P-STS-Sicherheitsmodus.

  • CONFIG_ID_5: Wie CONFIG_ID_2, aber mit aktiviertem P-STS-Sicherheitsmodus.

  • CONFIG_ID_6: Wie CONFIG_ID_3, aber mit aktiviertem P-STS-Sicherheitsmodus.

  • CONFIG_ID_7: Wie CONFIG_ID_2, aber der Modus für individuelle Kontrollvariablenschlüssel für P-STS ist aktiviert.

• [C-1-4] Es MUSS eine Möglichkeit für den Nutzer geben, den Status des UWB-Funkmoduls zu ändern.

• [C-1-5] MUSS dafür sorgen, dass Apps, die UWB-Funk verwenden, die Berechtigung UWB_RANGING (in der Berechtigungsgruppe NEARBY_DEVICES) haben.

Das Bestehen der relevanten Konformitäts- und Zertifizierungstests, die von Standardorganisationen wie FIRA, CCC und CSA definiert werden, trägt dazu bei, dass 802.1.15.4 ordnungsgemäß funktioniert.

7.3.14. Benutzerdefinierte Sensoren

Um eine differenzierte Nutzung zu ermöglichen, KÖNNEN Geräteimplementierungen zusätzliche Sensoren enthalten, die nicht von Android oder Wear OS abgedeckt werden und auf die vorinstallierte Apps zugreifen können.

Bei solchen Sensoren gilt für die Sensor-ID:

• [C-0-1] MUSS größer als 65.536 sein.

Wenn der benutzerdefinierte Sensor für Gesundheits- oder Fitnesszwecke vorgesehen ist, gilt Folgendes:

• [C-0-2] MUSS entweder durch eine Plattformberechtigung oder eine Systemberechtigung geschützt werden.

7.4. Datenverbindung

7.4.1. Telefonie

Der Begriff „Telefonie“ in den Android-APIs und in diesem Dokument bezieht sich speziell auf Hardware, die zum Tätigen von Sprachanrufen und zum Senden von SMS oder zum Herstellen einer mobilen Datenverbindung über ein mobiles (z.B. GSM, CDMA, LTE, NR) GSM- oder CDMA-Netzwerk verwendet wird. Ein Gerät, das „Telefonie“ unterstützt, kann einige oder alle Anruf-, Messaging- und Datendienste anbieten, je nach Produkt.

• Android KANN auf Geräten verwendet werden, die keine Telefonie-Hardware enthalten. Android ist also mit Geräten kompatibel, die keine Smartphones sind.

Wenn Geräteimplementierungen GSM- oder CDMA-Telefonie umfassen, müssen sie:

• [C-1-1] MÜSSEN das Funktions-Flag android.hardware.telephony und andere Unterfunktions-Flags entsprechend der Technologie deklarieren.

• [C-1-2] MUSS die API für diese Technologie vollständig unterstützen.

• Sollte alle verfügbaren Mobilfunkdienste (2G, 3G, 4G, 5G usw.) während Notrufen zulassen (unabhängig von den von SetAllowedNetworkTypeBitmap() festgelegten Netzwerktypen).

Wenn Geräteimplementierungen keine Telefoniehardware enthalten, müssen sie:

• [C-2-1] MUSS die vollständigen APIs als No-Ops implementieren.

Wenn Geräteimplementierungen eUICCs oder eSIMs/eingebettete SIMs unterstützen und einen proprietären Mechanismus enthalten, um die eSIM-Funktionalität für Drittanbieterentwickler verfügbar zu machen, gilt Folgendes:

• [C-3-1] MUSS das Funktions-Flag android.hardware.telephony.euicc deklarieren.

Wenn in Geräteimplementierungen die System-Property ro.telephony.iwlan_operation_mode nicht auf legacy gesetzt ist, gilt Folgendes:

• [C-4-1] NETWORK_TYPE_IWLAN darf nicht über NetworkRegistrationInfo#getAccessNetworkTechnology() gemeldet werden, wenn NetworkRegistrationInfo#getTransportType() für dieselbe NetworkRegistrationInfo-Instanz als TRANSPORT_TYPE_WWAN gemeldet wird.

Wenn Geräteimplementierungen eine einzelne IMS-Registrierung (IP Multimedia Subsystem) für MMTEL-Funktionen (Multimedia Telephony Service) und RCS-Funktionen (Rich Communication Service) unterstützen und die Anforderungen von Mobilfunkanbietern bezüglich der Verwendung einer einzelnen IMS-Registrierung für den gesamten IMS-Signalisierungstraffic erfüllen müssen, gilt Folgendes:

• [C-5-1] MUSS das Funktions-Flag android.hardware.telephony.ims deklarieren und eine vollständige Implementierung der ImsService API für MMTEL und RCS User Capability Exchange API bereitstellen.

• [C-5-2] MUSS das Feature-Flag android.hardware.telephony.ims.singlereg deklarieren und eine vollständige Implementierung der SipTransport API, der GbaService API, dedizierter Bearer-Anzeigen mit dem IRadio 1.6 HAL und der Bereitstellung über den Auto Configuration Server (ACS) oder einen anderen proprietären Bereitstellungsmechanismus mit der IMS Configuration API bereitstellen.

Wenn Geräteimplementierungen die android.hardware.telephony-Funktion melden, gilt Folgendes:

• [C-6-1] Die SmsManager#sendTextMessage- und SmsManager#sendMultipartTextMessage-Funktionen MÜSSEN zu entsprechenden Aufrufen von CarrierMessagingService führen, um SMS-Funktionen bereitzustellen. SmsManager#sendMultimediaMessage und SmsManager#downloadMultimediaMessage MÜSSEN zu entsprechenden Aufrufen von CarrierMessagingService führen, um Multimedia-Messaging-Funktionen bereitzustellen.

• [C-6-2] Die von android.provider.Telephony.Sms#getDefaultSmsPackage angegebene Anwendung MUSS SmsManager-APIs zum Senden und Empfangen von SMS- und MMS-Nachrichten verwenden. Die AOSP-Referenzimplementierung in packages/apps/Messaging erfüllt diese Anforderung.

• [C-6-3] Die Anwendung, die auf Intent#ACTION_DIAL antwortet, MUSS die Eingabe beliebiger Wählertastencodes im Format *#*#CODE#*#* unterstützen und einen entsprechenden TelephonyManager#ACTION_SECRET_CODE-Broadcast auslösen.

• [C-6-4] Die Anwendung, die auf Intent#ACTION_DIAL antwortet, MUSS VoicemailContract.Voicemails#TRANSCRIPTION verwenden, um Nutzern die visuelle Mailbox-Transkription anzuzeigen, wenn sie visuelle Mailbox-Transkriptionen unterstützt.

• [C-6-5] MUSS alle SubscriptionInfo mit entsprechenden Gruppen-UUIDs als einzelnes Abo in allen für Nutzer sichtbaren Elementen darstellen, in denen SIM-Karteninformationen angezeigt und gesteuert werden. Beispiele für solche Affordances sind Einstellungs-Benutzeroberflächen, die Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS oder EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS entsprechen.

• [C-6-6] Es ist NICHT ZULÄSSIG, SubscriptionInfo mit einer nicht leeren group UUID und einem opportunistic bit in nutzersichtbaren Elementen anzuzeigen oder zu steuern, die die Konfiguration oder Steuerung von SIM-Karteneinstellungen ermöglichen.

Wenn die Geräteimplementierungen das android.hardware.telephony-Feature melden und eine Systemstatusleiste bereitstellen, gilt Folgendes:

• [C-7-1] Es MUSS ein repräsentatives aktives Abo für eine bestimmte Gruppen-UUID ausgewählt werden, das dem Nutzer in allen Benachrichtigungen mit Informationen zum SIM-Status angezeigt wird. Beispiele für solche Möglichkeiten sind das Symbol für das Mobilfunksignal in der Statusleiste oder die Kachel für die Schnelleinstellungen.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, das repräsentative Abo als aktives Datenabo auszuwählen, es sei denn, das Gerät befindet sich in einem Sprachanruf. In diesem Fall wird DRINGEND EMPFOHLEN, das repräsentative Abo als aktives Sprachabo auszuwählen.

Wenn Geräteimplementierungen die android.hardware.telephony-Funktion melden, gilt Folgendes:

• [C-6-7] MUSS in der Lage sein, die maximale Anzahl logischer Kanäle (insgesamt 20) für jede UICC gemäß ETSI TS 102 221 zu öffnen und gleichzeitig zu nutzen.

• [C-6-8] Die folgenden Verhaltensweisen DÜRFEN NICHT automatisch oder ohne ausdrückliche Nutzerbestätigung auf aktive Carrier-Apps (wie durch TelephonyManager#getCarrierServicePackageName gekennzeichnet) angewendet werden:

  • Netzwerkzugriff widerrufen oder einschränken
  • Berechtigungen widerrufen
  • Ausführung von Apps im Hintergrund oder Vordergrund über die in AOSP enthaltenen Funktionen zur Energieverwaltung hinaus einschränken
  • App deaktivieren oder deinstallieren

Wenn Geräteimplementierungen das android.hardware.telephony-Feature melden und alle aktiven nicht opportunistischen Abos, die eine Gruppen-UUID gemeinsam nutzen, deaktiviert, physisch vom Gerät entfernt oder als opportunistisch gekennzeichnet sind, gilt Folgendes:

• [C-8-1] ALLE verbleibenden aktiven opportunistischen Abos in derselben Gruppe MÜSSEN automatisch deaktiviert werden.

Wenn Geräteimplementierungen GSM-Telefonie, aber keine CDMA-Telefonie umfassen, gilt Folgendes:

• [C-9-1] DÜRFEN PackageManager#FEATURE_TELEPHONY_CDMA NICHT deklarieren.

• [C-9-2] Bei Versuchen, 3GPP2-Netzwerktypen in Bitmasken für bevorzugte oder zulässige Netzwerktypen festzulegen, MUSS eine IllegalArgumentException ausgelöst werden.

• [C-9-3] MUSS einen leeren String von TelephonyManager#getMeid zurückgeben.

Wenn die Geräteimplementierungen eUICCs mit mehreren Ports und Profilen unterstützen, gilt Folgendes:

• [C-10-1] MUSS das Funktions-Flag android.hardware.telephony.euicc.mep deklarieren.

7.4.1.1. Kompatibilität der Nummernblockierung

Wenn Geräteimplementierungen das android.hardware.telephony.calling-Feature melden, gilt Folgendes:

• [C-1-1] MUSS die Blockierung von Nummern unterstützen

• [C-1-2] MUSS BlockedNumberContract und die entsprechende API vollständig implementieren, wie in der SDK-Dokumentation beschrieben.

• [C-1-3] MUSS alle Anrufe und Nachrichten von einer Telefonnummer in BlockedNumberProvider ohne Interaktion mit Apps blockieren. Die einzige Ausnahme ist, wenn die Nummernsperrung vorübergehend aufgehoben wird, wie in der SDK-Dokumentation beschrieben.

• [C-1-4] Bei einem blockierten Anruf MUSS in den Plattformanruflistenanbieter geschrieben werden und Anrufe mit BLOCKED_TYPE MÜSSEN aus der Standardansicht der Anrufliste in der vorinstallierten Telefon-App herausgefiltert werden.

• [C-1-5] Es DARF NICHT an den Telefonieanbieter für eine blockierte Nachricht geschrieben werden.

• [C-1-6] Es MUSS eine Benutzeroberfläche zur Verwaltung blockierter Nummern implementiert werden, die mit der von der Methode TelecomManager.createManageBlockedNumbersIntent() zurückgegebenen Absicht geöffnet wird.

• [C-1-7] Sekundärnutzer DÜRFEN die blockierten Nummern auf dem Gerät NICHT ansehen oder bearbeiten können, da die Android-Plattform davon ausgeht, dass der Hauptnutzer die vollständige Kontrolle über die Telefoniedienste auf dem Gerät hat. Die gesamte Benutzeroberfläche für die Blockierung MUSS für untergeordnete Nutzer ausgeblendet werden und die Liste der blockierten Nutzer MUSS weiterhin berücksichtigt werden.

• Die blockierten Nummern SOLLTEN in den Anbieter migriert werden, wenn ein Gerät auf Android 7.0 aktualisiert wird.

• Es SOLLTE eine Möglichkeit für Nutzer geben, blockierte Anrufe in der vorinstallierten Dialer-App anzuzeigen.

7.4.1.2. Telecom API

Wenn Geräteimplementierungen android.hardware.telephony.calling melden, gilt Folgendes:

• [C-1-1] MUSS die im SDK beschriebenen ConnectionService-APIs unterstützen.

• [C-1-2] Ein neuer eingehender Anruf MUSS angezeigt werden und der Nutzer MUSS die Möglichkeit haben, den eingehenden Anruf anzunehmen oder abzulehnen, wenn er sich in einem laufenden Anruf befindet, der von einer Drittanbieter-App getätigt wurde, die die über CAPABILITY_SUPPORT_HOLD angegebene Funktion zum Halten von Anrufen nicht unterstützt.

• [C-1-3] MUSS eine Anwendung haben, die InCallService implementiert.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, den Nutzer darüber zu informieren, dass ein laufender Anruf beendet wird, wenn er einen eingehenden Anruf annimmt.

  Die AOSP-Implementierung erfüllt diese Anforderungen durch eine wichtige Benachrichtigung, die den Nutzer darüber informiert, dass durch das Annehmen eines eingehenden Anrufs der andere Anruf beendet wird.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, die Standard-Dialer-App vorzuinstallieren, in deren Anrufliste ein Logeintrag und der Name einer Drittanbieter-App angezeigt werden, wenn die Drittanbieter-App den Extras-Schlüssel EXTRA_LOG_SELF_MANAGED_CALLS in ihrem PhoneAccount auf true festlegt.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, die KEYCODE_MEDIA_PLAY_PAUSE- und KEYCODE_HEADSETHOOK-Ereignisse des Audio-Headsets für die android.telecom-APIs wie unten beschrieben zu verarbeiten:

  • Rufen Sie Connection.onDisconnect() auf, wenn während eines laufenden Anrufs ein kurzes Drücken des Schlüsselereignisses erkannt wird.

  • Rufen Sie Connection.onAnswer() auf, wenn während eines eingehenden Anrufs ein kurzer Tastendruck erkannt wird.

  • Rufen Sie Connection.onReject() auf, wenn während eines eingehenden Anrufs ein langes Drücken des Schlüsselereignisses erkannt wird.

  • Stummschaltung des CallAudioState aktivieren oder deaktivieren.

7.4.1.3. Mobilfunk-NAT‑T-Keepalive-Entlastung

Geräteimplementierungen:

• SOLLTE die Auslagerung von Cellular Keepalive unterstützen.

Wenn Geräteimplementierungen die Unterstützung für das Auslagern von Cellular Keepalive umfassen und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS die SocketKeepAlive API unterstützen.

• [C-1-2] MUSS mindestens einen gleichzeitigen Keep-Alive-Slot über das Mobilfunknetz unterstützen.

• [C-1-3] MUSS so viele gleichzeitige Mobilfunk-Keepalive-Slots unterstützen, wie von der Cellular Radio HAL unterstützt werden.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, mindestens drei Keep-Alive-Slots für Mobilfunk pro Funkinstanz zu unterstützen.

Wenn Geräteimplementierungen keine Unterstützung für das Offloaden von Mobilfunk-Keep-Alive-Vorgängen enthalten,

• [C-2-1] MUSS ERROR_UNSUPPORTED zurückgeben.

7.4.2. IEEE 802.11 (WLAN)

Geräteimplementierungen:

• Sollte Unterstützung für eine oder mehrere Formen von 802.11 enthalten.

Wenn Geräteimplementierungen Unterstützung für 802.11 enthalten und die Funktionalität für eine Drittanbieteranwendung verfügbar machen, gilt Folgendes:

• [C-1-1] MÜSSEN die entsprechende Android-API implementieren.

• [C-1-2] MUSS das Hardware-Funktions-Flag android.hardware.wifi melden.

• [C-1-3] MUSS die Multicast-API wie in der SDK-Dokumentation beschrieben implementieren.

• [C-1-4] mDNS MUSS unterstützt werden und mDNS-Pakete (224.0.0.251 oder ff02::fb) DÜRFEN zu keinem Zeitpunkt des Betriebs gefiltert werden, auch nicht, wenn der Bildschirm nicht aktiv ist, es sei denn, die Multicast-Sperre ist nicht aktiv und die Pakete werden von APF gefiltert. Die Pakete müssen keine mDNS-Vorgänge erfüllen, die derzeit von Anwendungen über die NsdManager-APIs angefordert werden. Das Gerät KANN jedoch mDNS-Pakete filtern, wenn dies erforderlich ist, um die für den Zielmarkt geltenden behördlichen Anforderungen an den Stromverbrauch einzuhalten.

• [C-1-5] Der Aufruf der API-Methode WifiManager.enableNetwork() darf NICHT als ausreichender Hinweis darauf gewertet werden, dass die aktuell aktive Network, die standardmäßig für Anwendungs-Traffic verwendet und von ConnectivityManager-API-Methoden wie getActiveNetwork und registerDefaultNetworkCallback zurückgegeben wird, gewechselt werden muss. Das heißt, sie DÜRFEN den Internetzugang, der von einem anderen Netzwerkanbieter (z.B. mobile Daten) bereitgestellt wird, NUR deaktivieren, wenn sie erfolgreich validieren, dass das WLAN einen Internetzugang bietet.

• [C-1-6] Es wird DRINGEND EMPFOHLEN, bei Aufruf der API-Methode ConnectivityManager.reportNetworkConnectivity() den Internetzugriff auf dem Network neu zu bewerten und, sobald die Bewertung ergibt, dass das aktuelle Network keinen Internetzugriff mehr bietet, zu einem anderen verfügbaren Netzwerk (z.B. mobilen Daten) zu wechseln, das Internetzugriff bietet.

• [C-1-7] MUSS die MAC‑Quelladresse und Sequenznummer von Frames zur Prüfungsanfrage randomisieren, einmal zu Beginn aller Scans, während STA getrennt ist.

• [C-1-8] MUSS eine gleichbleibende MAC‑Adresse verwenden (SOLLTE die MAC‑Adresse nicht nach der Hälfte des Scans randomisieren).

• [C-1-9] MUSS die Sequenznummer der Prüfungsanfrage zwischen den Prüfungsanfragen in einem Scan als normal (sequenziell) iterieren.

• [C-1-10] Die Sequenznummer der Prüfungsanfrage MUSS zwischen der letzten Prüfungsanfrage eines Scans und der ersten Prüfungsanfrage des nächsten Scans randomisiert werden.

• [C-SR-1] SOLLTEN die für jegliche STA-Kommunikation mit einem Zugangspunkt (ZP) verwendete MAC‑Quelladresse während und nach der Verknüpfung randomisieren.

  • Das Gerät MUSS für jede SSID (FQDN für Passpoint), mit der es kommuniziert, eine andere randomisierte MAC‑Adresse verwenden.

  • Das Gerät MUSS dem Nutzer für jede SSID (FQDN für Passpoint) die Möglichkeit geben, die Randomisierung zu steuern, mit nicht randomisierten und randomisierten Optionen, und MUSS den Standardmodus für neue WLAN-Konfigurationen auf randomisiert festlegen.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, eine zufällige BSSID für alle ZPs zu verwenden, die sie erstellen.

  • Die MAC‑Adresse MUSS für jede SSID, die vom ZP verwendet wird, randomisiert und gespeichert werden.

  • Das GERÄT DARF dem Nutzer die Option geben, diese Funktion zu deaktivieren. Wenn eine solche Option bereitgestellt wird, MUSS die Randomisierung standardmäßig aktiviert sein.

Wenn Geräteimplementierungen die Unterstützung des WLAN-Energiesparmodus gemäß IEEE 802.11-Standard umfassen, gilt Folgendes:

• Der WLAN-Energiesparmodus SOLLTE deaktiviert werden, wenn eine App über die APIs WifiManager.createWifiLock() und WifiManager.WifiLock.acquire() die Sperre WIFI_MODE_FULL_HIGH_PERF oder WIFI_MODE_FULL_LOW_LATENCY erhält und die Sperre aktiv ist.

• [C-3-2] Die durchschnittliche Round-Trip-Latenz zwischen dem Gerät und einem Zugangspunkt, während sich das Gerät im WLAN-Modus mit niedriger Latenz (WIFI_MODE_FULL_LOW_LATENCY) befindet, MUSS geringer sein als die Latenz im WLAN-Modus mit hoher Leistung (WIFI_MODE_FULL_HIGH_PERF).

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, die WLAN-Roundtrip-Latenz zu minimieren, wenn ein Low-Latency-Lock (WIFI_MODE_FULL_LOW_LATENCY) erworben wird und wirksam wird.

Wenn Geräteimplementierungen WLAN unterstützen und WLAN für die Standortermittlung verwenden, gilt Folgendes:

• [C-2-1] Es MUSS eine Möglichkeit für Nutzer geben, das Lesen von Werten über die API-Methode WifiManager.isScanAlwaysAvailable zu aktivieren/deaktivieren.

7.4.2.1. Wi-Fi Direct

Geräteimplementierungen:

• SOLLTE Unterstützung für Wi‑Fi Direct (Wi‑Fi Peer-to-Peer) enthalten.

Wenn Geräteimplementierungen Unterstützung für Wi‑Fi Direct enthalten, gilt Folgendes:

• [C-1-1] MUSS die entsprechende Android-API wie in der SDK-Dokumentation beschrieben implementieren.

• [C-1-2] MÜSSEN die Hardwarefunktion android.hardware.wifi.direct melden.

• [C-1-3] MUSS den regulären WLAN-Betrieb unterstützen.

• [C-1-4] MÜSSEN WLAN- und Wi‑Fi Direct-Vorgänge gleichzeitig unterstützt werden.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die MAC‑Quelladresse für alle neu aufgebauten Wi‑Fi Direct-Verbindungen zu randomisieren.

7.4.2.2. Einrichtung von Wi-Fi Tunneled Direct Link

Geräteimplementierungen:

• Sollte Unterstützung für Wi-Fi Tunneled Direct Link Setup (TDLS) enthalten, wie in der Android SDK-Dokumentation beschrieben.

Wenn Geräteimplementierungen Unterstützung für TDLS enthalten und TDLS über die WiFiManager API aktiviert ist, gilt Folgendes:

• [C-1-1] MUSS die Unterstützung für TDLS über WifiManager.isTdlsSupported deklarieren.

• TDLS sollte nur verwendet werden, wenn es möglich UND von Vorteil ist.

• Sollte eine Heuristik verwenden und TDLS NICHT verwenden, wenn die Leistung schlechter sein könnte als über den WLAN-Zugangspunkt.

7.4.2.3. Wi‑Fi Aware

Geräteimplementierungen:

• SOLLTE Unterstützung für Wi‑Fi Aware enthalten.

Wenn Geräteimplementierungen Unterstützung für Wi-Fi Aware enthalten und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS die WifiAwareManager-APIs wie in der SDK-Dokumentation beschrieben implementieren.

• [C-1-2] MUSS das Funktions-Flag android.hardware.wifi.aware deklarieren.

• [C-1-3] MUSS WLAN- und Wi-Fi Aware-Vorgänge gleichzeitig unterstützen.

• [C-1-4] Die Adresse der Wi-Fi Aware-Verwaltungsschnittstelle MUSS in Intervallen von höchstens 30 Minuten und immer dann, wenn Wi-Fi Aware aktiviert ist, zufällig generiert werden, es sei denn, es läuft gerade ein Aware-Entfernungsvorgang oder ein Aware-Datenpfad ist aktiv (die Zufallsgenerierung wird nicht erwartet, solange der Datenpfad aktiv ist).

Wenn Geräteimplementierungen Unterstützung für Wi-Fi Aware und Wi-Fi-Standort wie in Abschnitt 7.4.2.5 beschrieben enthalten und diese Funktionen für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-2-1] MUSS die standortbezogenen Discovery APIs implementieren: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm und onServiceDiscoveredWithinRange.

7.4.2.4. WLAN-Passpoint

Wenn Geräteimplementierungen Unterstützung für 802.11 (WLAN) enthalten, gilt Folgendes:

• Sollte Unterstützung für Wi‑Fi Passpoint enthalten.

Wenn Geräteimplementierungen Unterstützung für Wi‑Fi Passpoint enthalten, gilt Folgendes:

• [C-1-2] MUSS die Passpoint-bezogenen WifiManager-APIs wie in der SDK-Dokumentation beschrieben implementieren.

• [C-1-3] MUSS den IEEE 802.11u-Standard unterstützen, insbesondere in Bezug auf die Netzwerkerkennung und ‑auswahl, z. B. Generic Advertisement Service (GAS) und Access Network Query Protocol (ANQP).

• [C-1-4] MUSS das Funktions-Flag android.hardware.wifi.passpoint deklarieren.

• [C-1-5] Das Gerät MUSS der AOSP-Implementierung folgen, um Passpoint-Netzwerke zu erkennen, abzugleichen und zuzuordnen.

• [C-1-6] MUSS mindestens die folgende Teilmenge von Gerätebereitstellungsprotokollen unterstützen, wie in der Wi-Fi Alliance Passpoint R2 definiert: EAP-TTLS-Authentifizierung und SOAP-XML.

• [C-1-7] MUSS das AAA-Serverzertifikat gemäß der Hotspot 2.0 R3-Spezifikation verarbeiten.

• [C-1-8] Die Bereitstellung MUSS über die WLAN-Auswahl vom Nutzer gesteuert werden können.

• [C-1-9] Passpoint-Konfigurationen MÜSSEN auch nach Neustarts beibehalten werden.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die Funktion zum Akzeptieren der Nutzungsbedingungen zu unterstützen.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, die Funktion für Informationen zum Veranstaltungsort zu unterstützen.

Wenn ein globaler Schalter zum Deaktivieren von Passpoint für Nutzer bereitgestellt wird, müssen Implementierungen:

• [C-3-1] Passpoint MUSS standardmäßig aktiviert sein.

7.4.2.5. WLAN-Standort (WLAN-Umlaufzeit – RTT)

Geräteimplementierungen:

• SOLLTE Unterstützung für WLAN-Standort enthalten.

Wenn Geräteimplementierungen Unterstützung für die WLAN-Standortbestimmung enthalten und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS die WifiRttManager-APIs wie in der SDK-Dokumentation beschrieben implementieren.

• [C-1-2] MUSS das Funktions-Flag android.hardware.wifi.rtt deklarieren.

• [C-1-3] MUSS die MAC‑Quelladresse für jeden RTT-Burst randomisieren, der ausgeführt wird, während die WLAN-Schnittstelle, auf der der RTT ausgeführt wird, nicht mit einem Zugangspunkt verknüpft ist.

• [C-1-4] MUSS bei einer Bandbreite von 80 MHz im 68. Perzentil (berechnet mit der kumulativen Verteilungsfunktion) auf 2 Meter genau sein.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die Position mit einer Genauigkeit von 1,5 Metern bei einer Bandbreite von 80 MHz im 68.Perzentil (berechnet mit der kumulativen Verteilungsfunktion) anzugeben.

7.4.2.6. WLAN-Keepalive-Entlastung

Geräteimplementierungen:

• SOLLTE Unterstützung für die WLAN-Keepalive-Entlastung enthalten.

Wenn Geräteimplementierungen die Unterstützung für Wi‑Fi-Keepalive-Offload umfassen und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS die SocketKeepAlive API unterstützen.

• [C-1-2] MÜSSEN mindestens drei gleichzeitige Keep-Alive-Slots über WLAN unterstützt werden.

Wenn Geräteimplementierungen keine Unterstützung für Wi‑Fi-Keep-Alive-Offload enthalten, gilt Folgendes:

• [C-2-1] MUSS ERROR_UNSUPPORTED zurückgeben.

7.4.2.7. Wi-Fi Easy Connect (Device Provisioning Protocol)

Geräteimplementierungen:

• Sollte Unterstützung für Wi-Fi Easy Connect (DPP) enthalten.

Wenn Geräteimplementierungen Unterstützung für Wi‑Fi Easy Connect enthalten und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] Die Methode WifiManager#isEasyConnectSupported() MUSS true zurückgeben.

7.4.2.8. Validierung von Unternehmens-WLAN-Serverzertifikaten

Wenn das WLAN-Serverzertifikat nicht validiert wird oder der Domainname des WLAN-Servers nicht festgelegt ist, gilt für Geräteimplementierungen Folgendes:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, dem Nutzer in der Einstellungs-App keine Option zum manuellen Hinzufügen eines WLANs für Unternehmen anzubieten.

7.4.2.9. Trust On First Use (TOFU)

Wenn Geräteimplementierungen Trust on First Use (TOFU) unterstützen und es dem Nutzer ermöglichen, WPA-/WPA2-/WPA3-Enterprise-Konfigurationen zu definieren, gilt Folgendes:

• [C-4-1] Der Nutzer MUSS die Möglichkeit haben, TOFU auszuwählen.

7.4.2.10. WLAN-Erkennung in der Nähe

7.4.3. Bluetooth

Wenn Geräteimplementierungen das Bluetooth-Audioprofil unterstützen, gilt Folgendes:

• SOLLTEN Advanced Audio Codecs und Bluetooth-Audio-Codecs (z.B. LDAC) unterstützen.

Wenn Geräteimplementierungen HFP, A2DP und AVRCP unterstützen, gilt Folgendes:

• Es SOLLTE mindestens 5 verbundene Geräte unterstützen.

Wenn Geräteimplementierungen die Funktion android.hardware.vr.high_performance deklarieren, gilt Folgendes:

• [C-1-1] MÜSSEN Bluetooth 4.2 und die Bluetooth LE Data Length Extension unterstützen.

Android unterstützt Bluetooth und Bluetooth Low Energy.

Wenn Geräteimplementierungen Unterstützung für Bluetooth und Bluetooth Low Energy enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN die relevanten Plattformfunktionen (android.hardware.bluetooth bzw. android.hardware.bluetooth_le) deklarieren und die Plattform-APIs implementieren.

• Es SOLLTEN relevante Bluetooth-Profile wie A2DP, AVRCP, OBEX, HFP usw. implementiert werden, je nach Gerät.

Wenn Geräteimplementierungen Unterstützung für Bluetooth Low Energy (BLE) enthalten, gilt Folgendes:

• [C-3-1] MÜSSEN die Hardwarefunktion android.hardware.bluetooth_le deklarieren.

• [C-3-2] MUSS die GATT-basierten (Generic Attribute Profile) Bluetooth-APIs wie in der SDK-Dokumentation und android.bluetooth beschrieben aktivieren.

• [C-3-3] MUSS den richtigen Wert für BluetoothAdapter.isOffloadedFilteringSupported() melden, um anzugeben, ob die Filterlogik für die API-Klassen ScanFilter implementiert ist.

• [C-3-4] MUSS den richtigen Wert für BluetoothAdapter.isMultipleAdvertisementSupported() angeben, um anzugeben, ob Low Energy Advertising unterstützt wird.

• [C-3-5] Es MUSS ein Zeitlimit für die auflösbare private Adresse (Resolvable Private Address, RPA) von höchstens 15 Minuten implementiert werden. Die Adresse MUSS bei einem Zeitlimit rotiert werden, um den Datenschutz der Nutzer zu schützen, wenn das Gerät BLE aktiv zum Scannen oder für Werbung verwendet. Um Timing-Angriffe zu verhindern, MÜSSEN die Zeitlimitintervalle auch zwischen 5 und 15 Minuten zufällig ausgewählt werden.

• Die Auslagerung der Filterlogik auf den Bluetooth-Chipsatz SOLLTE unterstützt werden, wenn die ScanFilter API implementiert wird.

• Sollte das Auslagern des Batch-Scannens an den Bluetooth-Chipsatz unterstützen.

• Es SOLLTE die Anzeige mehrerer Werbebotschaften mit mindestens vier Slots unterstützt werden.

Wenn Geräteimplementierungen Bluetooth LE unterstützen und Bluetooth LE für die Standortsuche verwenden, gilt Folgendes:

• [C-4-1] MUSS eine Möglichkeit für den Nutzer bieten, das Lesen des Werts über die System-API BluetoothAdapter.isBleScanAlwaysAvailable() zu aktivieren/deaktivieren.

Wenn Geräteimplementierungen Unterstützung für Bluetooth LE und das Hörgeräteprofil enthalten, wie in Unterstützung von Hörgeräte-Audio über Bluetooth LE beschrieben, gilt Folgendes:

• [C-5-1] MUSS true für BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) zurückgeben.

Wenn Geräteimplementierungen Unterstützung für Bluetooth oder Bluetooth Low Energy enthalten, gilt Folgendes:

• [C-6-1] Der Zugriff auf Bluetooth-Metadaten (z. B. Scanergebnisse), die zur Ermittlung des Standorts des Geräts verwendet werden könnten, MUSS eingeschränkt werden, es sei denn, die anfragende App besteht einen android.permission.ACCESS_FINE_LOCATION-Berechtigungscheck basierend auf ihrem aktuellen Vordergrund-/Hintergrundstatus.

Wenn Geräteimplementierungen Unterstützung für Bluetooth oder Bluetooth Low Energy enthalten und das App-Manifest keine Erklärung des Entwicklers enthält, in der er angibt, dass er den Standort nicht über Bluetooth ermittelt, gilt Folgendes:

• [C-6-2] Der Bluetooth-Zugriff MUSS durch die android.permission.ACCESS_FINE_LOCATION eingeschränkt werden.

Wenn Geräteimplementierungen true für die BluetoothAdapter.isLeAudioSupported() API zurückgeben,

• [C-7-1] MUSS Unicast-Client unterstützen.

• [C-7-2] MÜSSEN 2M PHY unterstützen.

• [C-7-3] MUSS LE Extended Advertising unterstützen.

• [C-7-4] MUSS mindestens zwei CIS-Verbindungen in einem CIG unterstützen.

• [C-7-5] BAP-Unicast-Client, CSIP-Set-Coordinator, MCP-Server, VCP-Controller und CCP-Server MÜSSEN gleichzeitig aktiviert werden.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, den HAP-Unicast-Client zu aktivieren.

Wenn Geräteimplementierungen true für die BluetoothAdapter.isLeAudioBroadcastSourceSupported() API zurückgeben,

• [C-8-1] MUSS mindestens zwei BIS-Links in einem BIG unterstützen.

• [C-8-2] MÜSSEN die BAP-Broadcast-Quelle und den BAP-Broadcast-Assistenten gleichzeitig aktivieren.

• [C-8-3] MUSS LE Periodic Advertising unterstützen.

Wenn Geräteimplementierungen true für die BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API zurückgeben,

• [C-9-1] MUSS PAST (Periodic Advertising Sync Transfer) unterstützen.

• [C-9-2] MUSS LE Periodic Advertising unterstützen.

Wenn Geräteimplementierungen FEATURE_BLUETOOTH_LE deklarieren, gilt Folgendes:

• [C-10-1] RSSI-Messungen MÜSSEN bei 95% der Messungen in einer Sichtverbindungsumgebung in einem Abstand von 1 m von einem Referenzgerät, das mit ADVERTISE_TX_POWER_HIGH sendet, innerhalb von +/-9 dB liegen.

• [C-10-2] MUSS Rx/Tx-Korrekturen enthalten, um die Abweichungen pro Channel zu reduzieren, sodass die Messungen auf jedem der drei Channels und auf jeder der Antennen (falls mehrere verwendet werden) bei 95% der Messungen innerhalb von +/-3 dB liegen.

Wenn Geräteimplementierungen FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING deklarieren, gilt Folgendes:

• [C-11-1] MÜSSEN das Hardware-Funktions-Flag android.hardware.bluetooth_le.channel_sounding melden.

• [C-11-2] MUSS den Bereich mit einer Genauigkeit von +/- 0, 5 m im 90.Perzentil angeben, wie mit der kumulativen Verteilungsfunktion bei einer Entfernung von 1 m berechnet.

Wenn Geräteimplementierungen FEATURE_BLUETOOTH_LE deklarieren, gilt Folgendes:

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, den Rx-Offset zu messen und zu kompensieren, um sicherzustellen, dass der Medianwert des BLE-RSSI bei einem Abstand von 1 m von einem Referenzgerät, das bei ADVERTISE_TX_POWER_HIGH sendet, -60 dBm +/-10 dB beträgt. Dabei müssen die Geräte so ausgerichtet sein, dass sie sich auf „parallelen Ebenen“ befinden und die Bildschirme in dieselbe Richtung zeigen.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, den TX-Offset zu messen und zu kompensieren, um sicherzustellen, dass der mediane BLE-RSSI -60 dBm +/-10 dB beträgt, wenn von einem Referenzgerät gescannt wird, das sich in einem Abstand von 1 m befindet und bei ADVERTISE_TX_POWER_HIGH sendet. Die Geräte müssen so ausgerichtet sein, dass sie sich auf „parallelen Ebenen“ befinden und die Bildschirme in dieselbe Richtung zeigen.

Es wird DRINGEND EMPFOHLEN, die in den Anforderungen für die Anwesenheitskalibrierung beschriebenen Schritte zur Einrichtung der Messung auszuführen.

7.4.4. Nahfeldkommunikation

Geräteimplementierungen:

• Sollte einen Transceiver und die zugehörige Hardware für die Nahfeldkommunikation (Near Field Communication, NFC) enthalten.

• [C-0-1] android.nfc.NdefMessage- und android.nfc.NdefRecord-APIs MÜSSEN implementiert werden, auch wenn sie keine Unterstützung für NFC enthalten oder das android.hardware.nfc-Feature deklarieren, da die Klassen ein protokollunabhängiges Datenformat darstellen.

Wenn Geräteimplementierungen NFC-Hardware enthalten und diese für Drittanbieter-Apps verfügbar gemacht werden soll, gilt Folgendes:

• [C-1-1] MÜSSEN die android.hardware.nfc-Funktion über die android.content.pm.PackageManager.hasSystemFeature()-Methode melden.

• MUSS NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können:

• [C-1-2] MUSS als NFC-Forum-Lesegerät/Schreibgerät fungieren können (gemäß der technischen Spezifikation des NFC-Forums NFCForum-TS-DigitalProtocol-1.0) über die folgenden NFC-Standards:

  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • NFC-Forum-Tag-Typen 2, 3, 4, 5 (definiert vom NFC-Forum)

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, NDEF-Nachrichten und Rohdaten über die folgenden NFC-Standards lesen und schreiben zu können. Die NFC-Standards werden zwar als STRONGLY RECOMMENDED (DRINGEND EMPFOHLEN) angegeben, aber in der Kompatibilitätsdefinition für eine zukünftige Version sollen sie in MUST (ERFORDERLICH) geändert werden. Diese Standards sind in dieser Version optional, werden aber in zukünftigen Versionen erforderlich sein. Es wird dringend empfohlen, dass bestehende und neue Geräte, auf denen diese Version von Android ausgeführt wird, diese Anforderungen jetzt erfüllen, damit sie auf zukünftige Plattform-Releases aktualisiert werden können.

• [C-1-13] MUSS im NFC-Erkennungsmodus alle unterstützten Technologien abfragen.

• Das Gerät SOLLTE sich im NFC-Erkennungsmodus befinden, während es aktiv ist, der Bildschirm aktiv ist und der Sperrbildschirm entsperrt ist.

• Sollte in der Lage sein, den Barcode und die URL (falls codiert) von Thinfilm NFC Barcode-Produkten zu lesen.

Beachten Sie, dass öffentlich verfügbare Links für die oben genannten Spezifikationen von JIS, ISO und NFC Forum nicht verfügbar sind.

Android unterstützt den NFC-HCE-Modus (Host Card Emulation).

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz (für NfcA und/oder NfcB) enthalten und das Routing von Anwendungs-IDs (Application IDs, AIDs) unterstützen, gilt Folgendes:

• [C-2-1] MÜSSEN die android.hardware.nfc.hce-Funktionskonstante melden.

• [C-2-2] MUSS die NFC HCE-APIs unterstützen, wie im Android SDK definiert.

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz für NfcF enthalten und die Funktion für Drittanbieteranwendungen implementieren, gilt Folgendes:

• [C-3-1] MÜSSEN die android.hardware.nfc.hcef-Funktionskonstante melden.

• [C-3-2] MUSS die NfcF Card Emulation APIs (NfcF-Kartenemulations-APIs) wie im Android SDK definiert implementieren.

Wenn Geräteimplementierungen die allgemeine NFC-Unterstützung wie in diesem Abschnitt beschrieben und die MIFARE-Technologien (MIFARE Classic, MIFARE Ultralight, NDEF auf MIFARE Classic) in der Reader-/Writer-Rolle unterstützen, gilt Folgendes:

• [C-4-1] MÜSSEN die entsprechenden Android-APIs implementieren, wie im Android-SDK dokumentiert.

• [C-4-2] MÜSSEN die Funktion com.nxp.mifare über die Methode android.content.pm.PackageManager.hasSystemFeature() melden. Hinweis: Dies ist keine Standardfunktion von Android und wird daher nicht als Konstante in der Klasse android.content.pm.PackageManager angezeigt.

7.4.5. Netzwerkprotokolle und APIs

7.4.5.1. Mindestanforderungen an die Netzwerkfähigkeit

Geräteimplementierungen:

• [C-0-1] MUSS Unterstützung für mindestens eine Form der Datenvernetzung enthalten. Geräteimplementierungen MÜSSEN mindestens einen Datenstandard unterstützen, der 200 Kbit/s oder mehr ermöglicht. Beispiele für Technologien, die diese Anforderung erfüllen, sind EDGE, HSPA, EV-DO, 802.11g, Ethernet und Bluetooth PAN.

• SOLLTE auch die Unterstützung für mindestens einen gängigen drahtlosen Datenstandard wie 802.11 (WLAN) enthalten, wenn ein physischer Netzwerkstandard (z. B. Ethernet) die primäre Datenverbindung ist.

• MAY implement more than one form of data connectivity.

7.4.5.2. IPv6

Geräteimplementierungen:

• [C-0-2] MUSS einen IPv6-Netzwerkstack enthalten und die IPv6-Kommunikation über die verwalteten APIs wie java.net.Socket und java.net.URLConnection sowie die nativen APIs wie AF_INET6-Sockets unterstützen.

• [C-0-3] MUSS IPv6 standardmäßig aktivieren.

• MUSS dafür sorgen, dass die IPv6-Kommunikation genauso zuverlässig ist wie IPv4, z. B.:

• [C-0-4] MÜSSEN die IPv6-Verbindung im Inaktivmodus aufrechterhalten.

• [C-0-5] Durch die Ratenbegrenzung darf das Gerät in keinem IPv6-kompatiblen Netzwerk, das RA-Gültigkeitsdauern von mindestens 180 Sekunden verwendet, die IPv6-Konnektivität verlieren.

• [C-0-6] Drittanbieteranwendungen MÜSSEN eine direkte IPv6-Verbindung zum Netzwerk bereitstellen, wenn sie mit einem IPv6-Netzwerk verbunden sind, ohne dass eine Adress- oder Portübersetzung lokal auf dem Gerät erfolgt. Sowohl verwaltete APIs wie Socket#getLocalAddress oder Socket#getLocalPort als auch NDK-APIs wie getsockname() oder IPV6_PKTINFO MÜSSEN die IP-Adresse und den Port zurückgeben, die tatsächlich zum Senden und Empfangen von Paketen im Netzwerk verwendet werden und als Quell-IP und -Port für Internet- (Web-)Server sichtbar sind.

Das erforderliche Maß an IPv6-Unterstützung hängt vom Netzwerktyp ab, wie in den folgenden Anforderungen beschrieben.

Wenn Geräteimplementierungen WLAN unterstützen, gilt Folgendes:

• [C-1-1] MUSS Dual-Stack- und Nur-IPv6-Betrieb über WLAN unterstützen.

Wenn Geräteimplementierungen Ethernet unterstützen, gilt Folgendes:

• [C-2-1] MUSS Dual-Stack- und Nur-IPv6-Betrieb über Ethernet unterstützen.

Wenn Geräteimplementierungen Mobilfunkdaten unterstützen, gilt Folgendes:

• [C-3-1] MUSS den IPv6-Betrieb (nur IPv6 und möglicherweise Dual-Stack) über Mobilfunk unterstützen.

Wenn Geräteimplementierungen mehr als einen Netzwerktyp unterstützen (z.B. WLAN und Mobilfunkdaten), gilt Folgendes:

• [C-4-1] MUSS gleichzeitig die oben genannten Anforderungen in jedem Netzwerk erfüllen, wenn das Gerät gleichzeitig mit mehr als einem Netzwerktyp verbunden ist.

7.4.5.3. Captive Portals

Ein Captive Portal ist ein Netzwerk, für das eine Anmeldung erforderlich ist, um auf das Internet zuzugreifen.

Wenn Geräteimplementierungen eine vollständige Implementierung von android.webkit.Webview API bereitstellen, gilt Folgendes:

• [C-1-1] MUSS eine Captive-Portal-Anwendung bereitstellen, um den Intent ACTION_CAPTIVE_PORTAL_SIGN_IN zu verarbeiten und die Anmeldeseite des Captive Portals anzuzeigen. Dazu muss dieser Intent beim Aufruf der System-API ConnectivityManager#startCaptivePortalApp(Network, Bundle) gesendet werden.

• [C-1-2] MUSS Captive Portals erkennen und die Anmeldung über die Captive Portal-App unterstützen, wenn das Gerät mit einem beliebigen Netzwerktyp verbunden ist, einschließlich Mobilfunknetz, WLAN, Ethernet oder Bluetooth.

• [C-1-3] Das Gerät MUSS die Anmeldung bei Captive Portals über Klartext-DNS unterstützen, wenn es für die Verwendung des strikten Modus für privates DNS konfiguriert ist.

• [C-1-4] MUSS verschlüsseltes DNS gemäß der SDK-Dokumentation für android.net.LinkProperties.getPrivateDnsServerName und android.net.LinkProperties.isPrivateDnsActive für allen Netzwerk-Traffic verwenden, der nicht explizit mit dem Captive Portal kommuniziert.

• [C-1-5] MUSS dafür sorgen, dass während der Anmeldung des Nutzers in einem Captive Portal das von Anwendungen verwendete Standardnetzwerk (wie von ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback zurückgegeben und standardmäßig von Java-Netzwerk-APIs wie java.net.Socket und nativen APIs wie connect() verwendet) ein anderes verfügbares Netzwerk ist, das Internetzugriff bietet, sofern verfügbar.

7.4.6. Synchronisierungseinstellungen

Geräteimplementierungen:

• [C-0-1] Die automatische Synchronisierung muss standardmäßig aktiviert sein, damit die Methode getMasterSyncAutomatically() „true“ zurückgibt.

7.4.7. Datensparmodus

Wenn Geräteimplementierungen eine Verbindung mit beschränktem Datenvolumen enthalten, sind sie:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, den Datensparmodus bereitzustellen.

Wenn Geräteimplementierungen den Datensparmodus bieten, gilt Folgendes:

• [C-1-1] MUSS alle APIs in der Klasse ConnectivityManager unterstützen, wie in der SDK-Dokumentation beschrieben.

Wenn Geräteimplementierungen den Datensparmodus nicht unterstützen, gilt Folgendes:

• [C-2-1] MUSS für ConnectivityManager.getRestrictBackgroundStatus() den Wert RESTRICT_BACKGROUND_STATUS_DISABLED zurückgeben.

• [C-2-2] MUST NOT broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Secure Elements

Wenn Geräteimplementierungen Open Mobile API-kompatible Secure Elements unterstützen und sie für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] Die verfügbaren Leser für sichere Elemente MÜSSEN über die android.se.omapi.SEService.getReaders()-API aufgelistet werden.

• [C-1-2] Die korrekten Feature-Flags MÜSSEN über android.hardware.se.omapi.uicc für das Gerät mit UICC-basierten Secure Elements, android.hardware.se.omapi.ese für das Gerät mit eSE-basierten Secure Elements und android.hardware.se.omapi.sd für das Gerät mit SD-basierten Secure Elements deklariert werden.

7.4.9. UWB

Wenn Geräteimplementierungen die Unterstützung für 802.1.15.4 umfassen und die Funktionalität für eine Drittanbieteranwendung verfügbar machen, müssen sie:

• [C-1-1] MUSS die entsprechende Android-API in android.uwb implementieren.

• [C-1-2] MUSS das Hardware-Funktions-Flag android.hardware.uwb melden.

• [C-1-3] MUSS alle relevanten UWB-Profile unterstützen, die in der Android-Implementierung definiert sind.

• [C-1-4] Es MUSS eine Möglichkeit für den Nutzer geben, den Status des UWB-Funkmoduls zu ändern.

• [C-1-5] Apps, die UWB-Funkschnittstelle verwenden, MÜSSEN die Berechtigung UWB_RANGING (in der Berechtigungsgruppe NEARBY_DEVICES) haben.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die relevanten Konformitäts- und Zertifizierungstests zu bestehen, die von Standardorganisationen wie FIRA, CCC und CSA definiert werden.

• [C-1-6] MUSS sicherstellen, dass die Entfernungsmessungen in einer nicht reflektierenden Kammer bei einer Entfernung von 1 m in einer Umgebung mit Sichtlinie bei 95% der Messungen innerhalb von +/-15 cm liegen.

• [C-1-7] Der Median der Entfernungsmessungen in 1 m Entfernung vom Referenzgerät MUSS im Bereich [0,75 m, 1,25 m] liegen. Die tatsächliche Entfernung wird von der Oberkante des zu prüfenden Geräts gemessen.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, die in den Anforderungen für die Anwesenheitskalibrierung angegebenen Schritte zur Einrichtung der Analyse zu befolgen.

7.5. Kameras

Wenn Geräteimplementierungen mindestens eine Kamera enthalten, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag android.hardware.camera.any deklarieren.

• [C-1-2] Eine Anwendung MUSS gleichzeitig 3 RGBA_8888-Bitmaps in der Größe der Bilder zuweisen können, die vom Kamerasensor mit der höchsten Auflösung auf dem Gerät erzeugt werden, während die Kamera für die grundlegende Vorschau und die Aufnahme von Standbildern geöffnet ist.

• [C-1-3] MUSS dafür sorgen, dass die vorinstallierte Standardkameraanwendung, die Intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE oder MediaStore.ACTION_VIDEO_CAPTURE verarbeitet, den Standort des Nutzers aus den Bildmetadaten entfernt, bevor sie die Daten an die empfangende Anwendung sendet, wenn die empfangende Anwendung nicht über ACCESS_FINE_LOCATION verfügt.

Wenn Geräteimplementierungen mindestens eine Kamera enthalten und die vorinstallierte Kamera-App die Intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE oder MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE verarbeitet, gilt Folgendes:

• [C-1-4] MUSS dafür sorgen, dass die vorinstallierte Kamera-App bei der Verarbeitung dieser Intents den Standort des Nutzers aus den Bildmetadaten entfernt, bevor sie ihn an empfangende Anwendungen sendet, die nicht über ACCESS_FINE_LOCATION verfügen.

• [C-1-5] MUSS dafür sorgen, dass das zurückgegebene Foto mit Bewegtbild der Spezifikation für das Format „Foto mit Bewegtbild 1.0“ entspricht.

Wenn Geräteimplementierungen die HDR-10-Bit-Ausgabe unterstützen, gilt Folgendes:

• [C-2-1] MUSS mindestens das HLG-HDR-Profil für jedes Kameragerät unterstützen, das 10‑Bit-Ausgabe unterstützt.

• [C-2-2] MUSS die 10‑Bit-Ausgabe für die primäre Rückkamera oder die primäre Frontkamera unterstützen.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, 10‑Bit-Ausgabe für beide primären Kameras zu unterstützen.

• [C-2-3] MUSS dieselben HDR-Profile für alle BACKWARD_COMPATIBLE-fähigen physischen Unterkameras einer logischen Kamera und für die logische Kamera selbst unterstützen.

Für logische Kamerageräte, die 10‑Bit-HDR unterstützen und die android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API implementieren, gilt Folgendes:

• [C-3-1] MUSS das Umschalten zwischen allen abwärtskompatiblen physischen Kameras über das CONTROL_ZOOM_RATIO-Steuerelement auf der logischen Kamera unterstützen.

7.5.1. Rückkamera

Eine nach hinten gerichtete Kamera ist eine Kamera, die Szenen auf der gegenüberliegenden Seite des Geräts aufnimmt, wie eine herkömmliche Kamera. Bei Mobilgeräten befindet sie sich auf der Seite des Geräts, die dem Display gegenüberliegt.

Geräteimplementierungen:

• MUSS eine nach hinten gerichtete Kamera haben.

Wenn Geräteimplementierungen mindestens eine nach hinten gerichtete Kamera enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN das Funktions-Flag android.hardware.camera und android.hardware.camera.any melden.

• Sollte entweder Hardware-Autofokus oder Software-Autofokus im Kameratreiber implementiert haben (transparent für Anwendungssoftware).

• MAY have fixed-focus or EDOF (extended depth of field) hardware.

• KANN einen Blitz enthalten.

Wenn die Kamera einen Blitz hat:

• [C-2-1] Die Blitzlampe DARF NICHT leuchten, wenn eine android.hardware.Camera.PreviewCallback-Instanz auf einer Kamera-Vorschauoberfläche registriert wurde, es sei denn, die Anwendung hat den Blitz explizit durch Aktivieren der Attribute FLASH_MODE_AUTO oder FLASH_MODE_ON eines Camera.Parameters-Objekts aktiviert. Diese Einschränkung gilt nicht für die integrierte Systemkamera-App des Geräts, sondern nur für Drittanbieter-Apps, die Camera.PreviewCallback verwenden.

7.5.2. Frontkamera

Eine nach vorn gerichtete Kamera ist eine Kamera, die auf den Nutzer gerichtet ist und in der Regel verwendet wird, um den Nutzer zu filmen, z. B. für Videokonferenzen und ähnliche Anwendungen. Bei Handheld-Geräten befindet sich die Kamera auf derselben Seite des Geräts wie das Display.

Geräteimplementierungen:

• MAY include a front-facing camera.

Wenn Geräteimplementierungen mindestens eine nach vorn gerichtete Kamera enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN das Funktions-Flag android.hardware.camera.any und android.hardware.camera.front melden.

• [C-1-2] MUSS eine Auflösung von mindestens VGA (640 × 480 Pixel) haben.

• [C-1-3] Die Frontkamera darf NICHT als Standard für die Camera API verwendet werden und die API darf NICHT so konfiguriert werden, dass eine Frontkamera als Standard-Rückkamera behandelt wird, auch wenn sie die einzige Kamera auf dem Gerät ist.

• [C-1-4] Die Kameravorschau MUSS horizontal gespiegelt werden, wenn die aktuelle Anwendung über einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() explizit angefordert hat, dass die Kameraanzeige gedreht wird. Umgekehrt MUSS die Vorschau an der standardmäßigen horizontalen Achse des Geräts gespiegelt werden, wenn die aktuelle Anwendung nicht explizit anfordert, dass die Kameraanzeige durch einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() gedreht wird.

• [C-1-5] Das endgültige aufgenommene Standbild oder die Videostreams, die an Anwendungs-Callbacks zurückgegeben oder im Medienspeicher gespeichert werden, DÜRFEN NICHT gespiegelt werden.

• [C-1-6] MUSS das von der Postview angezeigte Bild auf dieselbe Weise spiegeln wie den Kameravorschaubildstream.

• KANN Funktionen (z. B. Autofokus, Blitz usw.) enthalten, die für nach hinten gerichtete Kameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.

Wenn Geräteimplementierungen vom Nutzer gedreht werden können (z. B. automatisch über einen Beschleunigungsmesser oder manuell über die Nutzereingabe):

• [C-2-1] Die Kameravorschau MUSS horizontal relativ zur aktuellen Ausrichtung des Geräts gespiegelt werden.

7.5.3. Externe Kamera

Eine externe Kamera ist eine Kamera, die jederzeit physisch an das Gerät angebracht oder davon getrennt werden kann und in jede Richtung ausgerichtet werden kann, z. B. USB-Kameras.

Geräteimplementierungen:

• MAY include support for an external camera that is not necessarily always connected.

Wenn Geräteimplementierungen Unterstützung für eine externe Kamera enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN die Plattform-Funktions-Flags android.hardware.camera.external und android.hardware camera.any deklarieren.

• [C-1-2] Das Gerät MUSS die USB Video Class (UVC 1.0 oder höher) unterstützen, wenn die externe Kamera über den USB-Host-Port angeschlossen wird.

• [C-1-3] MUSS die CTS-Kameratests mit einem physischen externen Kameragerät bestehen. Details zum CTS-Test für Kameras sind unter source.android.com verfügbar.

• Sollte Videokomprimierungen wie MJPEG unterstützen, um die Übertragung von uncodierten Streams in hoher Qualität (d.h. Rohbild- oder unabhängig komprimierte Bildstreams) zu ermöglichen.

• MAY unterstützt möglicherweise mehrere Kameras.

• MAY support camera-based video encoding.

Wenn die kamerabasierte Videocodierung unterstützt wird:

• [C-2-1] Ein gleichzeitiger uncodierter / MJPEG-Stream (QVGA oder höhere Auflösung) MUSS für die Geräteimplementierung zugänglich sein.

7.5.4. Verhalten der Camera API

Android umfasst zwei API-Pakete für den Zugriff auf die Kamera. Die neuere android.hardware.camera2-API bietet der App eine Kamera-Steuerung auf niedrigerer Ebene, einschließlich effizienter Burst-/Streaming-Abläufe ohne Kopieren und Steuerung von Belichtung, Verstärkung, Weißabgleich, Farbkonvertierung, Rauschunterdrückung und Schärfen pro Frame.

Das ältere API-Paket android.hardware.Camera ist in Android 5.0 als veraltet markiert, sollte aber weiterhin für Apps verfügbar sein. Android-Geräte müssen die API wie in diesem Abschnitt und im Android SDK beschrieben weiterhin unterstützen.

Alle Funktionen, die sowohl in der eingestellten Klasse android.hardware.Camera als auch im neueren Paket android.hardware.camera2 vorhanden sind, MÜSSEN in beiden APIs eine gleichwertige Leistung und Qualität aufweisen. Bei gleichwertigen Einstellungen müssen beispielsweise Autofokusgeschwindigkeit und ‑genauigkeit identisch sein und die Qualität der aufgenommenen Bilder muss gleich sein. Funktionen, die von der unterschiedlichen Semantik der beiden APIs abhängen, müssen nicht die gleiche Geschwindigkeit oder Qualität haben, SOLLTEN aber so gut wie möglich übereinstimmen.

Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs für alle verfügbaren Kameras implementieren. Geräteimplementierungen:

• [C-0-1] android.hardware.PixelFormat.YCbCr_420_SP MUSS für Vorschau-Daten verwendet werden, die für Anwendungs-Callbacks bereitgestellt werden, wenn eine Anwendung android.hardware.Camera.Parameters.setPreviewFormat(int) noch nie aufgerufen hat.

• [C-0-2] MUSS außerdem das NV21-Codierungsformat haben, wenn eine Anwendung eine android.hardware.Camera.PreviewCallback-Instanz registriert und das System die onPreviewFrame()-Methode aufruft und das Vorschauformat YCbCr_420_SP ist, die Daten im Byte[] werden an onPreviewFrame() übergeben. NV21 MUSS der Standard sein.

• [C-0-3] MUSS das YV12-Format (angegeben durch die Konstante android.graphics.ImageFormat.YV12) für Kameravorschauen für Front- und Rückkameras für android.hardware.Camera unterstützen. Der Hardware-Video-Encoder und die Kamera können ein beliebiges natives Pixelformat verwenden, die Geräteimplementierung MUSS jedoch die Konvertierung in YV12 unterstützen.

• [C-0-4] MÜSSEN die Formate android.hardware.ImageFormat.YUV_420_888 und android.hardware.ImageFormat.JPEG als Ausgaben über die android.media.ImageReader API für android.hardware.camera2-Geräte unterstützen, die die Funktion REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities bewerben.

• [C-0-5] Die vollständige Camera API, die in der Android SDK-Dokumentation enthalten ist, MUSS weiterhin implementiert werden, unabhängig davon, ob das Gerät einen Hardware-Autofokus oder andere Funktionen bietet. Kameras ohne Autofokus MÜSSEN beispielsweise trotzdem alle registrierten android.hardware.Camera.AutoFocusCallback-Instanzen aufrufen, auch wenn dies für eine Kamera ohne Autofokus nicht relevant ist. Das gilt auch für Frontkameras. Auch wenn die meisten Frontkameras keinen Autofokus unterstützen, müssen die API-Callbacks wie beschrieben „gefälscht“ werden.

• [C-0-6] MUSS jeden Parameternamen erkennen und berücksichtigen, der als Konstante in der Klasse android.hardware.Camera.Parameters und der Klasse android.hardware.camera2.CaptureRequest definiert ist. Umgekehrt DÜRFEN Geräteimplementierungen keine Stringkonstanten berücksichtigen oder erkennen, die an die android.hardware.Camera.setParameters()-Methode übergeben werden, mit Ausnahme der Konstanten, die in der android.hardware.Camera.Parameters dokumentiert sind. Das bedeutet, dass Geräteimplementierungen alle Standard-Kameraparameter unterstützen MÜSSEN, sofern die Hardware dies zulässt, und KEINE benutzerdefinierten Kameraparametertypen unterstützen DÜRFEN. Beispielsweise MÜSSEN Geräteimplementierungen, die die Aufnahme von Bildern mit HDR-Bildgebungstechniken (High Dynamic Range) unterstützen, den Kameraparameter Camera.SCENE_MODE_HDR unterstützen.

• [C-0-7] MUSS das richtige Unterstützungsniveau mit dem Attribut android.info.supportedHardwareLevel wie im Android SDK beschrieben melden und die entsprechenden Framework-Funktions-Flags melden.

• [C-0-8] MÜSSEN auch die einzelnen Kamerafunktionen von android.hardware.camera2 über die Eigenschaft android.request.availableCapabilities deklarieren und die entsprechenden Funktions-Flags deklarieren. Das Funktions-Flag MUSS definiert werden, wenn eines der angehängten Kamerageräte die Funktion unterstützt.

• [C-0-9] MUSS den Intent Camera.ACTION_NEW_PICTURE übertragen, wenn ein neues Bild von der Kamera aufgenommen und der Eintrag des Bildes dem Media Store hinzugefügt wurde.

• [C-0-10] MUSS den Intent Camera.ACTION_NEW_VIDEO übertragen, wenn ein neues Video von der Kamera aufgenommen und der Eintrag des Bildes dem Medienspeicher hinzugefügt wurde.

• [C-0-11] ALLE Kameras, auf die über die eingestellte android.hardware.Camera API zugegriffen werden kann, MÜSSEN auch über die android.hardware.camera2 API zugänglich sein.

• [C-0-12] MUSS sicherstellen, dass das Aussehen des Gesichts NICHT verändert wird, einschließlich, aber nicht beschränkt auf die Veränderung der Gesichtsgeometrie, des Hauttons des Gesichts oder der Glättung der Gesichtshaut für eine beliebige android.hardware.camera2- oder android.hardware.Camera-API.

• [C-SR-1] Bei Geräten mit mehreren RGB-Kameras, die sich in unmittelbarer Nähe befinden und in dieselbe Richtung ausgerichtet sind, wird DRINGEND EMPFOHLEN, ein logisches Kameragerät zu unterstützen, das die Funktion CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA enthält und aus allen RGB-Kameras besteht, die in diese Richtung ausgerichtet sind.

Wenn Geräteimplementierungen Drittanbieter-Apps eine proprietäre Kamera-API zur Verfügung stellen, gilt Folgendes:

• [C-1-1] MUSS eine solche Kamera-API mit der android.hardware.camera2-API implementieren.

• KANN Anbietertags und/oder Erweiterungen für die android.hardware.camera2-API bereitstellen.

7.5.5. Kameraausrichtung

Wenn Geräteimplementierungen eine Front- oder Rückkamera haben, müssen diese Kameras:

• [C-1-1] MUSS so ausgerichtet sein, dass die lange Seite der Kamera mit der langen Seite des Bildschirms übereinstimmt. Das heißt, wenn das Gerät im Querformat gehalten wird, MÜSSEN Kameras Bilder im Querformat aufnehmen. Dies gilt unabhängig von der natürlichen Ausrichtung des Geräts, also sowohl für Geräte, die primär im Querformat verwendet werden, als auch für Geräte, die primär im Hochformat verwendet werden.

  Geräte, die eines der folgenden Kriterien erfüllen, sind von dieser Anforderung ausgenommen:

  • Das Gerät hat Bildschirme mit variabler Geometrie, z. B. faltbare oder klappbare Displays, UND wenn sich der Falt- oder Klappzustand des Geräts ändert, wechselt das Gerät zwischen Hochformat und Querformat (oder umgekehrt).

  • Geräteimplementierungen, die nicht vom Nutzer gedreht werden können, z. B. Automotive-Geräte.

7.6. Arbeitsspeicher und Datenspeicher

7.6.1. Mindestspeicher

Geräteimplementierungen:

• [C-0-1] MUSS einen Download-Manager enthalten, den Anwendungen zum Herunterladen von Datendateien verwenden KÖNNEN. Er MUSS in der Lage sein, einzelne Dateien mit einer Größe von mindestens 100 MB an den standardmäßigen „Cache“-Speicherort herunterzuladen.

7.6.2. Shared Storage für Anwendungen

Geräteimplementierungen:

• [C-0-1] MUSS einen Speicher anbieten, der von Anwendungen gemeinsam genutzt werden kann. Dieser wird auch oft als „gemeinsam genutzter externer Speicher“, „von Anwendungen gemeinsam genutzter Speicher“ oder als der Linux-Pfad „/sdcard“ bezeichnet, auf dem er bereitgestellt wird.
• [C-0-2] MUSS standardmäßig mit eingebundenem freigegebenen Speicher konfiguriert sein, d. h. „out of the box“, unabhängig davon, ob der Speicher auf einer internen Speicherkomponente oder einem Wechseldatenträger (z. B. einem SD-Kartensteckplatz) implementiert ist.
• [C-0-3] Der freigegebene Speicher der Anwendung MUSS direkt auf dem Linux-Pfad sdcard gemountet werden oder einen symbolischen Linux-Link von sdcard zum tatsächlichen Mount-Punkt enthalten.
• [C-0-4] MÜSSEN begrenzter Speicher standardmäßig für alle Apps aktivieren, die auf API-Level 29 oder höher ausgerichtet sind, außer in der folgenden Situation:
  • Wenn die App android:requestLegacyExternalStorage="true" in ihrem Manifest angefordert hat.
• [C-0-5] Standortmetadaten wie GPS-EXIF-Tags, die in Mediendateien gespeichert sind, MÜSSEN entfernt werden, wenn auf diese Dateien über MediaStore zugegriffen wird, es sei denn, die aufrufende App hat die Berechtigung ACCESS_MEDIA_LOCATION.

Geräteimplementierungen KÖNNEN die oben genannten Anforderungen mit einer der folgenden Methoden erfüllen:

• Vom Nutzer zugänglicher Wechselspeicher, z. B. ein SD-Kartensteckplatz (Secure Digital).
• Ein Teil des internen (nicht entfernbaren) Speichers, wie im Open-Source-Projekt für Android (AOSP) implementiert.

Wenn Geräteimplementierungen Wechselspeicher verwenden, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

• [C-1-1] MUSS eine Toast- oder Pop-up-Benutzeroberfläche implementieren, die den Nutzer warnt, wenn kein Speichermedium in den Steckplatz eingesetzt ist.
• [C-1-2] MUSS ein FAT-formatiertes Speichermedium (z.B. eine SD-Karte) enthalten oder auf der Verpackung und anderem Material, das zum Zeitpunkt des Kaufs verfügbar ist, muss darauf hingewiesen werden, dass das Speichermedium separat erworben werden muss.

Wenn Geräteimplementierungen einen Teil des nicht entfernbaren Speichers verwenden, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

• Sollte die AOSP-Implementierung des internen freigegebenen Anwendungsspeichers verwenden.
• MAY share the storage space with the application private data.

Wenn Geräteimplementierungen einen USB-Anschluss mit Unterstützung für den USB-Peripheriemodus haben, gilt Folgendes:

• [C-3-1] Es MUSS einen Mechanismus geben, mit dem von einem Hostcomputer aus auf die Daten im freigegebenen Speicher der Anwendung zugegriffen werden kann.
• Sollte Inhalte aus beiden Speicherpfaden transparent über den Media Scanner-Dienst von Android und android.provider.MediaStore verfügbar machen.
• MAY use USB mass storage, but SHOULD use Media Transfer Protocol to satisfy this requirement.

Wenn Geräteimplementierungen einen USB-Anschluss mit USB-Peripheriemodus haben und das Media Transfer Protocol unterstützen, gilt Folgendes:

• Sollte mit dem Android-MTP-Referenzhost Android File Transfer kompatibel sein.
• Sollte die USB-Geräteklasse 0x00 melden.
• Sollte den Namen der USB-Schnittstelle „MTP“ melden.

7.6.3. Verwendbarer Speicher

Wenn das Gerät voraussichtlich mobil ist, im Gegensatz zu einem Fernseher, sind Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, den adoptable Speicher an einem langfristig stabilen Ort zu implementieren, da ein versehentliches Trennen zu Datenverlust oder ‑beschädigung führen kann.

Wenn sich der Anschluss für das Wechselspeichergerät an einem langfristig stabilen Ort befindet, z. B. im Akkufach oder in einer anderen Schutzabdeckung, gilt für Geräteimplementierungen Folgendes:

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, adoptable storage zu implementieren.

7.7. USB

Wenn Geräteimplementierungen einen USB-Anschluss haben, müssen sie:

• Sollte den USB-Gerätemodus unterstützen.

• Sollte den USB-Hostmodus unterstützen.

• Sollte die Deaktivierung der Datensignalisierung über USB unterstützen.

7.7.1. USB-Gerätemodus

Wenn Geräteimplementierungen einen USB-Anschluss enthalten und die AOA-Spezifikation implementieren, gilt Folgendes:

• [C-2-1] MÜSSEN die Unterstützung für die Hardwarefunktion android.hardware.usb.accessory deklarieren.
• [C-2-2] Die USB-Massenspeicherklasse MUSS den String „android“ am Ende des iInterface-Strings der Schnittstellenbeschreibung des USB-Massenspeichers enthalten.

7.7.2. USB-Hostmodus

Wenn Geräteimplementierungen einen USB-Anschluss enthalten, der den Hostmodus unterstützt, gilt Folgendes:

• [C-1-1] MUSS die Android-USB-Host-API implementieren, wie im Android SDK dokumentiert, und MUSS die Unterstützung für die Hardwarefunktion android.hardware.usb.host deklarieren.
• [C-1-2] MUSS die Verbindung von Standard-USB-Peripheriegeräten unterstützen. Sie MÜSSEN eines der folgenden Dokumente vorlegen:
  • Ein USB‑Typ‑C-Anschluss am Gerät oder ein mitgeliefertes Kabel, das einen proprietären Anschluss am Gerät in einen standardmäßigen USB‑Typ‑C-Anschluss umwandelt (USB‑Typ‑C-Gerät).
  • Ein USB‑Typ‑A-Anschluss am Gerät oder ein Kabel, das einen proprietären Anschluss am Gerät in einen standardmäßigen USB‑Typ‑A-Anschluss umwandelt.
  • Ein Micro-AB-USB-Anschluss am Gerät, der mit einem Kabel geliefert werden SOLLTE, das an einen Standard-USB-Typ-A-Anschluss angepasst ist.
• [C-1-3] Das Gerät darf nicht mit einem Adapter ausgeliefert werden, der USB Typ A- oder Micro-AB-Ports in einen USB Typ C-Port (Buchse) umwandelt.
• [C-SR-1] Das Implementieren der USB-Audio-Klasse, wie in der Android SDK-Dokumentation beschrieben, wird DRINGEND EMPFOHLEN.
• Das angeschlossene USB-Peripheriegerät SOLLTE im Hostmodus geladen werden können.Dazu muss ein Quellstrom von mindestens 1,5 A gemäß dem Abschnitt „Termination Parameters“ der USB Type-C Cable and Connector Specification Revision 1.2 für USB-Typ-C-Anschlüsse angegeben werden oder der Ausgangsstrombereich des Charging Downstream Port (CDP) gemäß den USB Battery Charging specifications, revision 1.2 für Micro-AB-Anschlüsse verwendet werden.
• Sollte USB Typ-C-Standards implementieren und unterstützen.

Wenn Geräteimplementierungen einen USB-Anschluss enthalten, der den Hostmodus und die USB-Audioklasse unterstützt, gilt Folgendes:

• [C-2-1] MUSS die USB HID-Klasse unterstützen.
• [C-2-2] MUSS die Erkennung und Zuordnung der folgenden HID-Datenfelder unterstützen, die in den USB HID Usage Tables und der Voice Command Usage Request zu den KeyEvent-Konstanten wie unten angegeben sind:
  • Verwendungsseite (0xC) – Verwendungs-ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Verwendungsseite (0xC) – Verwendungs-ID (0x0E9): KEYCODE_VOLUME_UP
  • Verwendungsseite (0xC) – Verwendungs-ID (0x0EA): KEYCODE_VOLUME_DOWN
  • Verwendungsseite (0xC) – Verwendungs-ID (0x0CF): KEYCODE_VOICE_ASSIST

Wenn Geräteimplementierungen einen USB-Anschluss enthalten, der den Hostmodus und das Storage Access Framework (SAF) unterstützt, gilt Folgendes:

• [C-3-1] MUSS alle per Remote-Verbindung verbundenen MTP-Geräte (Media Transfer Protocol) erkennen und ihre Inhalte über die Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT und ACTION_CREATE_DOCUMENT zugänglich machen.

Wenn Geräteimplementierungen einen USB-Port enthalten, der den Hostmodus und USB Type-C unterstützt, gilt Folgendes:

• [C-4-1] MUSS die DRP-Funktionalität (Dual Role Power) gemäß der USB Typ‑C-Spezifikation (Abschnitt 4.5.1.3.3) implementieren. Bei DRP-Ports auf Geräten mit einer 3,5‑mm-Audiobuchse ist die USB-Stromsenkenerkennung (Hostmodus) möglicherweise standardmäßig deaktiviert, der Nutzer MUSS sie jedoch aktivieren können.
• [C-SR-2] Es wird DRINGEND EMPFOHLEN, DisplayPort zu unterstützen.
  • SOLLTE USB-SuperSpeed-Datenraten unterstützen.
  • WIRD DRINGEND EMPFOHLEN, um Power Delivery für Daten und Rollentausch für die Stromversorgung zu unterstützen.
• [C-SR-3] Es wird DRINGEND EMPFOHLEN, den Zubehör-Modus für Audioadapter gemäß Anhang A der USB Type-C Cable and Connector Specification Revision 1.2 NICHT zu unterstützen.
• Sollte das Try.*-Modell implementieren, das für den Geräteformfaktor am besten geeignet ist. Ein Mobilgerät SOLLTE beispielsweise das Try.SNK-Modell implementieren.

7.7.3. USB Power Delivery

7.8. Audio

7.8.1. Mikrofon

Wenn Geräteimplementierungen ein Mikrofon enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN die android.hardware.microphone-Funktionskonstante melden.
• [C-1-2] MUSS den Anforderungen für Audioaufnahmen in Abschnitt 5.4 entsprechen.
• [C-1-3] MUSS die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die Aufzeichnung von Nah-Ultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen.

Wenn in Geräteimplementierungen kein Mikrofon vorhanden ist, gilt Folgendes:

• [C-2-1] DÜRFEN die android.hardware.microphone-Funktionskonstante NICHT melden.
• [C-2-2] MUSS die Audioaufzeichnungs-API mindestens als No-Op-Vorgänge gemäß Abschnitt 7 implementieren.

7.8.2. Audioausgabe

Wenn Geräteimplementierungen einen Lautsprecher oder einen Audio-/Multimedia-Ausgangsanschluss für ein Audioausgabe-Peripheriegerät wie eine 3,5-mm-Audiobuchse mit 4 Leitern oder einen USB-Hostmodus-Anschluss mit USB-Audioklasse enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN die android.hardware.audio.output-Funktionskonstante melden.
• [C-1-2] MUSS die Anforderungen an die Audiowiedergabe in Abschnitt 5.5 erfüllen.
• [C-1-3] MUSS die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die Wiedergabe von Nah-Ultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen.

Wenn Geräteimplementierungen keinen Lautsprecher oder Audioausgabeanschluss enthalten, gilt Folgendes:

• [C-2-1] DÜRFEN die android.hardware.audio.output-Funktion NICHT melden.
• [C-2-2] Die APIs für die Audioausgabe MÜSSEN zumindest als No-Ops implementiert werden.

Im Sinne dieses Abschnitts ist ein „Ausgangsport“ eine physische Schnittstelle wie ein 3,5‑mm-Audioanschluss, HDMI oder ein USB-Hostmodus-Port mit USB-Audioklasse. Die Unterstützung der Audioausgabe über funkbasierte Protokolle wie Bluetooth, WLAN oder Mobilfunknetz gilt nicht als „Ausgangsanschluss“.

7.8.2.1. Analoge Audioanschlüsse

Damit Geräte mit Headsets und anderem Audiozubehör kompatibel sind, die den 3,5‑mm-Audioanschluss im gesamten Android-Ökosystem verwenden, gilt Folgendes, wenn Geräteimplementierungen einen oder mehrere analoge Audioanschlüsse enthalten:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, dass mindestens einer der Audioanschlüsse eine 3,5-mm-Audiobuchse mit vier Leitern ist.

Wenn Geräteimplementierungen eine 3,5‑mm-Audiobuchse mit 4 Leitern haben, gilt Folgendes:

• [C-1-1] MUSS die Audiowiedergabe über Stereokopfhörer und Stereo-Headsets mit Mikrofon unterstützen.
• [C-1-2] MÜSSEN TRRS-Audiostecker mit der CTIA-Pinbelegung unterstützen.
• [C-1-3] MÜSSEN die Erkennung und Zuordnung zu den Tastencodes für die folgenden drei Bereiche der entsprechenden Impedanz zwischen dem Mikrofon und den Masseleitern am Audio-Stecker unterstützen:
  • 70 Ohm oder weniger: KEYCODE_HEADSETHOOK
  • 210–290 Ohm: KEYCODE_VOLUME_UP
  • 360–680 Ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] MUSS beim Einstecken eines Steckers ACTION_HEADSET_PLUG auslösen, jedoch erst, nachdem alle Kontakte des Steckers die entsprechenden Segmente der Buchse berühren.
• [C-1-5] MUSS bei einer Lautsprecherimpedanz von 32 Ohm mindestens 150 mV ± 10% der Ausgangsspannung liefern können.
• [C-1-6] MUSS eine Mikrofonvorspannung zwischen 1,8 V und 2,9 V haben.
• [C-1-7] MÜSSEN den Tastencode für den folgenden Bereich der äquivalenten Impedanz zwischen dem Mikrofon und den Masseleitern am Audiostecker erkennen und zuordnen:
  • 110–180 Ohm:KEYCODE_VOICE_ASSIST
• [C-SR-2] Es wird DRINGEND EMPFOHLEN, Audio-Stecker mit der OMTP-Pinbelegung zu unterstützen.
• [C-SR-3] Es wird DRINGEND EMPFOHLEN, die Audioaufnahme über Stereo-Headsets mit Mikrofon zu unterstützen.

Wenn Geräteimplementierungen eine 3, 5‑mm-Audiobuchse mit 4 Leitern haben und ein Mikrofon unterstützen und android.intent.action.HEADSET_PLUG mit dem zusätzlichen Wert „Mikrofon“ als „1“ übertragen wird, gilt Folgendes:

• [C-2-1] MUSS die Erkennung des Mikrofons am angeschlossenen Audiozubehör unterstützen.

7.8.2.2. Digitale Audioanschlüsse

Gerätespezifische Anforderungen finden Sie im Abschnitt 2.2.1.

7.8.3. Nahe am Ultraschallbereich

Audio im Grenzbereich zum Ultraschall liegt im Bereich von 18,5 kHz bis 20 kHz.

Geräteimplementierungen:

• MUSS die Unterstützung der Near-Ultrasound-Audiofunktion über die AudioManager.getProperty API korrekt melden:

Wenn PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND auf „true“ gesetzt ist, MÜSSEN die Audioquellen VOICE_RECOGNITION und UNPROCESSED die folgenden Anforderungen erfüllen:

• [C-1-1] Die mittlere Leistungsreaktion des Mikrofons im Bereich von 18,5 kHz bis 20 kHz DARF nicht mehr als 15 dB unter der Reaktion bei 2 kHz liegen.
• [C-1-2] Das ungewichtete Signal-Rausch-Verhältnis des Mikrofons über 18,5 kHz bis 20 kHz für einen 19‑kHz-Ton bei -26 dBFS DARF nicht niedriger als 50 dB sein.

Wenn PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND „true“ ist:

• [C-2-1] Die mittlere Reaktion des Lautsprechers im Bereich von 18,5 kHz bis 20 kHz DARF nicht niedriger als 40 dB unter der Reaktion bei 2 kHz sein.

7.8.4. Signalintegrität

Geräteimplementierungen:

• Sollte einen störungsfreien Audiosignalpfad für Ein- und Ausgabestreams auf Mobilgeräten bieten, wie durch null Störungen definiert, die während eines einminütigen Tests pro Pfad gemessen werden. Testen Sie mit OboeTester den „Automated Glitch Test“.

Für den Test ist ein Audio-Loopback-Dongle erforderlich, der direkt in einem 3,5-mm-Anschluss und/oder in Kombination mit einem USB‑C-auf-3,5‑mm-Adapter verwendet wird. Alle Audioausgänge SOLLTEN getestet werden.

OboeTester unterstützt derzeit AAudio-Pfade. Daher SOLLTEN die folgenden Kombinationen mit AAudio auf Glitches getestet werden:

Leistungsmodus	Teilen	Out Sample Rate	In Chans	Out-Chans
LOW_LATENCY	EXKLUSIVE	UNSPECIFIED	1	2
LOW_LATENCY	EXKLUSIVE	UNSPECIFIED	2	1
LOW_LATENCY	Weiterempfohlen	UNSPECIFIED	1	2
LOW_LATENCY	Weiterempfohlen	UNSPECIFIED	2	1
KEINE	Weiterempfohlen	48000	1	2
KEINE	Weiterempfohlen	48000	2	1
KEINE	Weiterempfohlen	44100	1	2
KEINE	Weiterempfohlen	44100	2	1
KEINE	Weiterempfohlen	16.000	1	2
KEINE	Weiterempfohlen	16.000	2	1

Ein zuverlässiger Stream SOLLTE die folgenden Kriterien für das Signal-Rausch-Verhältnis (SNR) und die gesamte harmonische Verzerrung (THD) für einen 2.000 Hz-Sinuston erfüllen.

Wandler	THD	SNR
primärer integrierter Lautsprecher, gemessen mit einem externen Referenzmikrofon	< 3,0%	>= 50 dB
primäres integriertes Mikrofon, gemessen mit einem externen Referenzlautsprecher	< 3,0%	>= 50 dB
Integrierte analoge 3,5‑mm-Anschlüsse, getestet mit Loopback-Adapter	< 1 %	>= 60 dB
Mit dem Smartphone gelieferte USB-Adapter, getestet mit Loopback-Adapter	< 1,0%	>= 60 dB

7.9. Virtual Reality

Android bietet APIs und Funktionen zum Erstellen von Virtual Reality-Anwendungen (VR), einschließlich hochwertiger mobiler VR-Erlebnisse. Geräteimplementierungen MÜSSEN diese APIs und Verhaltensweisen wie in diesem Abschnitt beschrieben korrekt implementieren.

7.9.1. Virtual Reality-Modus

Android unterstützt den VR-Modus. Diese Funktion sorgt für die stereoskopische Darstellung von Benachrichtigungen und deaktiviert monokulare System-UI-Komponenten, wenn eine VR-Anwendung den Fokus des Nutzers hat.

7.9.2. Virtual Reality-Modus – Hohe Leistung

Wenn Geräteimplementierungen den VR-Modus unterstützen, gilt Folgendes:

• [C-1-1] MUSS mindestens 2 physische Kerne haben.
• [C-1-2] MÜSSEN die android.hardware.vr.high_performance-Funktion deklarieren.
• [C-1-3] MUSS den Modus für nachhaltige Leistung unterstützen.
• [C-1-4] MUSS OpenGL ES 3.2 unterstützen.
• [C-1-5] MÜSSEN android.hardware.vulkan.level 0 unterstützen.
• Sollte android.hardware.vulkan.level 1 oder höher unterstützen.
• [C-1-6] MUSS EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace implementieren und die Erweiterungen in der Liste der verfügbaren EGL-Erweiterungen verfügbar machen.
• [C-1-8] MUSS GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen verfügbar machen.
• [C-SR-1] Es wird DRINGEND EMPFOHLEN, GL_EXT_external_buffer, GL_EXT_EGL_image_array und GL_OVR_multiview_multisampled_render_to_texture zu implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen verfügbar zu machen.
• [C-SR-2] Es wird DRINGEND EMPFOHLEN, Vulkan 1.1 zu unterstützen.
• [C-SR-3] Es wird DRINGEND EMPFOHLEN, VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing und VK_KHR_shared_presentable_image zu implementieren und in der Liste der verfügbaren Vulkan-Erweiterungen verfügbar zu machen.
• [C-SR-4] Es wird DRINGEND EMPFOHLEN, mindestens eine Vulkan-Warteschlangenfamilie verfügbar zu machen, in der flags sowohl VK_QUEUE_GRAPHICS_BIT als auch VK_QUEUE_COMPUTE_BIT enthält und queueCount mindestens 2 ist.
• [C-1-7] Die GPU und das Display MÜSSEN den Zugriff auf den gemeinsam genutzten Frontbuffer so synchronisieren können, dass die abwechselnde Darstellung von VR-Inhalten für das linke und rechte Auge mit 60 fps mit zwei Rendering-Kontexten ohne sichtbare Tearing-Artefakte erfolgt.
• [C-1-9] MUSS die Unterstützung für AHardwareBuffer-Flags AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA und AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT implementieren, wie im NDK beschrieben.
• [C-1-10] MUSS die Unterstützung für AHardwareBuffers mit einer beliebigen Kombination der Nutzungsflags AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT für mindestens die folgenden Formate implementieren: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] Es wird DRINGEND EMPFOHLEN, die Zuweisung von AHardwareBuffers mit mehr als einer Ebene sowie Flags und Formaten zu unterstützen, die in C-1-10 angegeben sind.
• [C-1-11] MUSS die H.264-Decodierung mit mindestens 3.840 × 2.160 bei 30 fps unterstützen, komprimiert auf durchschnittlich 40 Mbit/s (entspricht 4 Instanzen von 1.920 × 1.080 bei 30 fps – 10 Mbit/s oder 2 Instanzen von 1.920 × 1.080 bei 60 fps – 20 Mbit/s).
• [C-1-12] MUSS HEVC und VP9 unterstützen und mindestens 1.920 × 1.080 bei 30 fps mit einer durchschnittlichen Komprimierung von 10 Mbit/s decodieren können. Es SOLLTE 3.840 × 2.160 bei 30 fps mit einer durchschnittlichen Komprimierung von 20 Mbit/s decodieren können (entspricht 4 Instanzen von 1.920 × 1.080 bei 30 fps mit einer durchschnittlichen Komprimierung von 5 Mbit/s).
• [C-1-13] MUSS die HardwarePropertiesManager.getDeviceTemperatures API unterstützen und genaue Werte für die Hauttemperatur zurückgeben.
• [C-1-14] MUSS einen eingebetteten Bildschirm haben und seine Auflösung MUSS mindestens 1920 × 1080 betragen.
• [C-SR-6] Es wird DRINGEND EMPFOHLEN, eine Bildschirmauflösung von mindestens 2560 × 1440 zu verwenden.
• [C-1-15] Das Display MUSS im VR-Modus mit mindestens 60 Hz aktualisiert werden.
• [C-1-17] Das Display MUSS einen Modus mit geringer Persistenz mit einer Persistenz von ≤ 5 Millisekunden unterstützen. Die Persistenz wird als die Zeitspanne definiert, in der ein Pixel Licht emittiert.
• [C-1-18] MÜSSEN Bluetooth 4.2 und die Bluetooth LE Data Length Extension Abschnitt 7.4.3 unterstützen.
• [C-1-19] MÜSSEN den Direct Channel Type für alle folgenden Standardsensortypen unterstützen und korrekt melden:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] Es wird DRINGEND EMPFOHLEN, den direkten Channeltyp TYPE_HARDWARE_BUFFER für alle oben aufgeführten direkten Channeltypen zu unterstützen.
• [C-1-21] MÜSSEN die Anforderungen an Gyroskop, Beschleunigungsmesser und Magnetometer für android.hardware.hifi_sensors erfüllen, wie in Abschnitt 7.3.9 beschrieben.
• [C-SR-8] Es wird DRINGEND EMPFOHLEN, die android.hardware.sensor.hifi_sensors-Funktion zu unterstützen.
• [C-1-22] Die End-to-End-Latenz von Bewegung zu Photon DARF nicht höher als 28 Millisekunden sein.
• [C-SR-9] Es wird DRINGEND EMPFOHLEN, dass die End-to-End-Latenz zwischen Bewegung und Photon nicht höher als 20 Millisekunden ist.
• [C-1-23] MUSS ein First-Frame-Verhältnis von mindestens 85 % aufweisen. Das First-Frame-Verhältnis ist das Verhältnis zwischen der Helligkeit der Pixel im ersten Frame nach einem Übergang von Schwarz zu Weiß und der Helligkeit der weißen Pixel im stabilen Zustand.
• [C-SR-10] Es wird DRINGEND EMPFOHLEN, ein First-Frame-Verhältnis von mindestens 90 % zu haben.
• MAY kann einen exklusiven Core für die Vordergrundanwendung bereitstellen und MAY kann die Process.getExclusiveCores API unterstützen, um die Anzahl der CPU-Cores zurückzugeben, die exklusiv für die oberste Vordergrundanwendung reserviert sind.

Wenn der exklusive Kern unterstützt wird, gilt Folgendes:

• [C-2-1] Es DÜRFEN keine anderen Userspace-Prozesse darauf ausgeführt werden (mit Ausnahme von Gerätetreibern, die von der Anwendung verwendet werden), aber es DÜRFEN einige Kernelprozesse nach Bedarf ausgeführt werden.

7.10. Haptik

Geräte, die in der Hand gehalten oder getragen werden sollen, können einen haptischen Aktuator für allgemeine Zwecke enthalten, der für Anwendungen verfügbar ist, um unter anderem durch Klingeltöne, Wecker, Benachrichtigungen sowie allgemeines Touch-Feedback Aufmerksamkeit zu erregen.

Wenn Geräteimplementierungen KEINEN solchen universellen Haptik-Aktuator enthalten, gilt Folgendes:

• [7.10/C] MUSS für Vibrator.hasVibrator() „false“ zurückgeben.

Wenn Geräteimplementierungen mindestens einen solchen universellen Haptik-Aktuator enthalten, gilt Folgendes:

• [C-1-1] MUSS für Vibrator.hasVibrator() „true“ zurückgeben.
• Es SOLLTE KEIN Haptik-Aktuator (Vibrator) mit exzentrischer rotierender Masse (ERM) verwendet werden.
• ALLE öffentlichen Konstanten für deutliches haptisches Feedback in android.view.HapticFeedbackConstants SOLLTEN implementiert werden, nämlich (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START und GESTURE_END).
• ALLE öffentlichen Konstanten für deutliche Haptik in android.os.VibrationEffect (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK und EFFECT_DOUBLE_CLICK) und alle möglichen öffentlichen PRIMITIVE_*-Konstanten für umfangreiche Haptik> in android.os.VibrationEffect.Composition (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD) SOLLTEN implementiert werden. Einige dieser Primitiven, z. B. LOW_TICK und SPIN, sind möglicherweise nur möglich, wenn der Vibrator relativ niedrige Frequenzen unterstützt.
• Sollte der Anleitung zum Zuordnen öffentlicher Konstanten in android.view.HapticFeedbackConstants zu den empfohlenen android.os.VibrationEffect-Konstanten mit den entsprechenden Amplitudenbeziehungen folgen.
• Sollten diese verknüpften haptischen Konstanten verwenden.
• Sollte der Qualitätsbewertung für die APIs createOneShot() und createWaveform() folgen.
• Sollte überprüfen, ob das Ergebnis der öffentlichen android.os.Vibrator.hasAmplitudeControl()-API die Funktionen des Vibrators korrekt widerspiegelt.
• SHOULD verify the capabilities for amplitude scalability by running android.os.Vibrator.hasAmplitudeControl().

Wenn Geräteimplementierungen der Zuordnung von Haptikkonstanten folgen,

• Der Implementierungsstatus SOLLTE durch Ausführen der APIs android.os.Vibrator.areAllEffectsSupported() und android.os.Vibrator.arePrimitivesSupported() überprüft werden.
• Es SOLLTE eine Qualitätsbewertung für haptische Konstanten durchgeführt werden.
• Sollte die Fallback-Konfiguration für nicht unterstützte Primitiven prüfen und bei Bedarf aktualisieren, wie in der Implementierungsanleitung für Konstanten beschrieben.
• Sollte Fallback-Unterstützung bieten, um das Risiko von Fehlern zu minimieren, wie hier beschrieben.

7.11. Media Performance Class

Die Media-Leistungsklasse der Geräteimplementierung kann über die android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API abgerufen werden. Die Anforderungen für die Media-Leistungsklasse sind für jede Android-Version ab R (Version 30) definiert. Der Sonderwert 0 gibt an, dass das Gerät keiner Media-Leistungsklasse angehört.

Wenn Geräteimplementierungen einen Wert ungleich null für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

• [C-1-1] MUSS mindestens den Wert android.os.Build.VERSION_CODES.R zurückgeben.

• [C-1-2] MUSS ein Mobilgerät sein.

• [C-1-3] MUSS alle Anforderungen für die „Media Performance Class“ erfüllen, die in Abschnitt 2.2.7 beschrieben sind.

Die Media Performance Class in Android T ist also nur für Handheld-Geräte mit Version T, S oder R definiert.

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.2.7.

8. Leistung und Energie

Bestimmte Mindestkriterien für Leistung und Energieverbrauch sind für die Nutzerfreundlichkeit entscheidend und wirken sich auf die grundlegenden Annahmen aus, die Entwickler bei der Entwicklung einer App treffen.

8.1. Konsistenz der Nutzerfreundlichkeit

Eine flüssige Benutzeroberfläche kann für den Endnutzer bereitgestellt werden, wenn bestimmte Mindestanforderungen erfüllt sind, um eine konsistente Framerate und Reaktionszeiten für Anwendungen und Spiele zu gewährleisten. Je nach Gerätetyp KÖNNEN Geräteimplementierungen messbare Anforderungen an die Latenz der Benutzeroberfläche und den Aufgabenwechsel haben, wie in Abschnitt 2 beschrieben.

8.2. Leistung beim Zugriff auf Datei-E/A

Eine gemeinsame Baseline für eine konsistente Dateizugriffsleistung im privaten Datenspeicher der Anwendung (/data-Partition) ermöglicht es App-Entwicklern, eine angemessene Erwartung festzulegen, die bei der Softwareentwicklung hilfreich ist. Geräteimplementierungen können je nach Gerätetyp bestimmte Anforderungen haben, die in Abschnitt 2 für die folgenden Lese- und Schreibvorgänge beschrieben sind:

• Sequenzielle Schreibleistung: Gemessen durch Schreiben einer 256-MB-Datei mit einem 10-MB-Schreibpuffer.
• Leistung beim zufälligen Schreiben: Gemessen durch Schreiben einer 256-MB-Datei mit einem 4-KB-Schreibpuffer.
• Sequenzielle Leseleistung: Gemessen durch das Lesen einer 256 MB großen Datei mit einem 10 MB großen Schreibpuffer.
• Leistung beim zufälligen Lesen: Gemessen durch Lesen einer 256 MB großen Datei mit einem 4 KB großen Schreibpuffer.

8.3. Energiesparmodi

Wenn Geräteimplementierungen Funktionen zur Verbesserung der Energieverwaltung des Geräts enthalten, die in AOSP enthalten sind (z.B. App Standby Bucket, Doze), oder die Funktionen so erweitert werden, dass strengere Einschränkungen als der RESTRICTED App Standby Bucket angewendet werden, gilt Folgendes:

• [C-1-1] Die Auslöse-, Wartungs- und Weckalgorithmen sowie die Verwendung globaler Systemeinstellungen oder der DeviceConfig der Energiesparmodi „App-Standby“ und „Doze“ DÜRFEN NICHT von der AOSP-Implementierung abweichen.
• [C-1-2] Die Verwendung globaler Einstellungen oder von DeviceConfig zum Verwalten der Drosselung von Jobs, Alarmen und Netzwerken für Apps in den einzelnen Buckets für den App-Standby darf NICHT von der AOSP-Implementierung abweichen.
• [C-1-3] Die Anzahl der App Standby Buckets, die für App Standby verwendet werden, DARF NICHT von der AOSP-Implementierung abweichen.
• [C-1-4] MÜSSEN App Standby Buckets und Doze wie unter Energieverwaltung beschrieben implementieren.
• [C-1-5] true MUSS für PowerManager.isPowerSaveMode() zurückgegeben werden, wenn sich das Gerät im Energiesparmodus befindet.
• [C-1-6] MUSS eine Möglichkeit für den Nutzer bieten, alle Apps anzuzeigen, die von den Energiesparmodi „App-Standby“ und „Doze“ oder anderen Akkuoptimierungen ausgenommen sind, und MUSS den Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS implementieren, um den Nutzer zu bitten, einer App zu erlauben, Akkuoptimierungen zu ignorieren.
• [C-SR-1] Es wird DRINGEND EMPFOHLEN, dem Nutzer die Möglichkeit zu geben, den Energiesparmodus zu aktivieren und zu deaktivieren.
• [C-SR-2] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, alle Apps anzuzeigen, die von den Energiesparmodi „App-Standby“ und „Stromsparmodus“ ausgenommen sind.

Wenn Geräteimplementierungen die in AOSP enthaltenen Funktionen zur Energieverwaltung erweitern und diese Erweiterung strengere Einschränkungen als der App-Standby-Bucket „Selten verwendet“ vorsieht, lesen Sie Abschnitt 3.5.1.

Zusätzlich zu den Energiesparmodi KÖNNEN Android-Geräteimplementierungen alle oder einige der vier Ruhezustände implementieren, die vom Advanced Configuration and Power Interface (ACPI) definiert werden.

Wenn Geräteimplementierungen S4-Energiezustände gemäß ACPI implementieren, gilt Folgendes:

• [C-1-1] Dieser Status DARF erst erreicht werden, nachdem der Nutzer eine explizite Aktion ausgeführt hat, um das Gerät in einen inaktiven Status zu versetzen (z.B. durch Schließen eines Deckels, der physisch Teil des Geräts ist, oder durch Ausschalten eines Fahrzeugs oder Fernsehers), und bevor der Nutzer das Gerät reaktiviert (z.B. durch Öffnen des Deckels oder durch erneutes Einschalten des Fahrzeugs oder Fernsehers).

Wenn Geräteimplementierungen S3-Energiezustände gemäß ACPI implementieren, gilt Folgendes:

• [C-2-1] MUSS C-1-1 oben entsprechen ODER den S3-Status nur dann aufrufen, wenn Drittanbieteranwendungen die Systemressourcen (z.B. Bildschirm, CPU) nicht benötigen.

  Umgekehrt MUSS der S3-Status beendet werden, wenn Drittanbieteranwendungen die Systemressourcen benötigen, wie in diesem SDK beschrieben.

  Wenn Drittanbieteranwendungen beispielsweise anfordern, dass der Bildschirm über FLAG_KEEP_SCREEN_ON eingeschaltet bleibt oder die CPU über PARTIAL_WAKE_LOCK weiterläuft, DARF das Gerät NICHT in den S3-Zustand wechseln, es sei denn, der Nutzer hat, wie in C-1-1 beschrieben, explizit Maßnahmen ergriffen, um das Gerät in einen inaktiven Zustand zu versetzen. Wenn eine Aufgabe, die von Drittanbieter-Apps über JobScheduler implementiert wird, ausgelöst wird oder Firebase Cloud Messaging an Drittanbieter-Apps gesendet wird, MUSS das Gerät den S3-Status verlassen, es sei denn, der Nutzer hat das Gerät in einen inaktiven Zustand versetzt. Dies sind keine umfassenden Beispiele. AOSP implementiert umfangreiche Wecksignale, die ein Aufwachen aus diesem Zustand auslösen.

8.4. Abrechnung des Stromverbrauchs

Eine genauere Erfassung und Berichterstellung des Stromverbrauchs bietet dem App-Entwickler sowohl Anreize als auch Tools zur Optimierung des Stromverbrauchs der Anwendung.

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, ein Energieprofil für jede Komponente bereitzustellen, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch durch die Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.
• [C-SR-2] Es wird DRINGEND EMPFOHLEN, alle Werte zum Stromverbrauch in Milliamperestunden (mAh) anzugeben.
• [C-SR-3] Es wird DRINGEND EMPFOHLEN, den CPU-Stromverbrauch für die UID jedes Prozesses zu melden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• [C-SR-4] Es wird DRINGEND EMPFOHLEN, diese Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung zu stellen.
• Sollte der Hardwarekomponente selbst zugeschrieben werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.

8.5. Symbol: Konstante Leistung

Die Leistung kann bei leistungsstarken, lang laufenden Apps aufgrund anderer Apps, die im Hintergrund ausgeführt werden, oder aufgrund von CPU-Drosselung aufgrund von Temperaturgrenzen stark schwanken. Android umfasst programmatische Schnittstellen, sodass die oberste Vordergrundanwendung, wenn das Gerät dazu in der Lage ist, anfordern kann, dass das System die Zuweisung der Ressourcen optimiert, um solchen Schwankungen entgegenzuwirken.

Geräteimplementierungen:

• [C-0-1] MUSS die Unterstützung des Modus für nachhaltige Leistung über die API-Methode PowerManager.isSustainedPerformanceModeSupported() genau melden.

• Sollte den Modus für nachhaltige Leistung unterstützen.

Wenn Geräteimplementierungen den Modus für nachhaltige Leistung unterstützen, gilt Folgendes:

• [C-1-1] Die oberste Vordergrundanwendung MUSS mindestens 30 Minuten lang ein gleichbleibendes Leistungsniveau bieten, wenn die App dies anfordert.
• [C-1-2] MUSS die Window.setSustainedPerformanceMode() API und andere zugehörige APIs unterstützen.

Wenn Geräteimplementierungen zwei oder mehr CPU-Kerne enthalten, gilt Folgendes:

• Es SOLLTE mindestens ein exklusiver Kern bereitgestellt werden, der von der wichtigsten Vordergrundanwendung reserviert werden kann.

Wenn Geräteimplementierungen das Reservieren eines exklusiven Kerns für die oberste Vordergrundanwendung unterstützen, gilt Folgendes:

• [C-2-1] Die ID-Nummern der exklusiven Kerne, die von der wichtigsten Vordergrundanwendung reserviert werden können, MÜSSEN über die API-Methode Process.getExclusiveCores() gemeldet werden.
• [C-2-2] Es DÜRFEN keine Userspace-Prozesse außer den von der Anwendung verwendeten Gerätetreibern auf den exklusiven Kernen ausgeführt werden. Es DÜRFEN jedoch einige Kernelprozesse nach Bedarf ausgeführt werden.

Wenn Geräteimplementierungen keinen exklusiven Kern unterstützen, gilt Folgendes:

• [C-3-1] MUSS über die API-Methode Process.getExclusiveCores() eine leere Liste zurückgeben.

8.6. App-Arbeitsspeicherlimits

9. Kompatibilität des Sicherheitsmodells

Geräteimplementierungen:

• [C-0-1] MUSS ein Sicherheitsmodell implementieren, das mit dem Sicherheitsmodell der Android-Plattform übereinstimmt, wie im Referenzdokument zu Sicherheit und Berechtigungen in der Android-Entwicklerdokumentation zu APIs definiert.

• [C-0-2] Die Installation selbstsignierter Anwendungen MUSS unterstützt werden, ohne dass zusätzliche Berechtigungen/Zertifikate von Dritten/Behörden erforderlich sind.

Wenn Geräteimplementierungen das android.hardware.security.model.compatible-Feature deklarieren, gilt Folgendes:

• [C-1-1] MUSS die in den folgenden Unterabschnitten aufgeführten Anforderungen unterstützen.

9.1 Berechtigungen

Geräteimplementierungen:

• [C-0-1] MÜSSEN das Android-Berechtigungsmodell und das Android-Rollenmodell unterstützen, wie in der Android-Entwicklerdokumentation definiert. Insbesondere MÜSSEN sie jede Berechtigung und Rolle wie in der SDK-Dokumentation beschrieben erzwingen. Es dürfen keine Berechtigungen und Rollen ausgelassen, geändert oder ignoriert werden.

• Es KÖNNEN zusätzliche Berechtigungen hinzugefügt werden, sofern die neuen Berechtigungs-ID-Strings nicht im Namespace android.\* enthalten sind.

• [C-0-2] Berechtigungen mit einem protectionLevel von PROTECTION_FLAG_PRIVILEGED DÜRFEN nur Apps erteilt werden, die im privilegierten Pfad des System-Images vorinstalliert sind (sowie APEX-Dateien) und sich innerhalb der Teilmenge der explizit zugelassenen Berechtigungen für jede App befinden. Die AOSP-Implementierung erfüllt diese Anforderung, indem sie die zugelassenen Berechtigungen für jede App aus den Dateien im Pfad etc/permissions/ liest und berücksichtigt und den Pfad system/priv-app als privilegierten Pfad verwendet.

• [C-SR-1] Berechtigungen mit einem protectionLevel von PROTECTION_SIGNATURE sollten DRINGEND nur für Folgendes erteilt werden:

  • Apps, die im Systemimage vorinstalliert sind (sowie APEX-Dateien).

  • Apps, die auf der Zulassungsliste stehen, mit zulässigen Berechtigungen, wenn sie nicht im System-Image enthalten sind.

Berechtigungen mit dem Schutzlevel „gefährlich“ sind Laufzeitberechtigungen. Bei Anwendungen mit targetSdkVersion > 22 werden sie zur Laufzeit angefordert.

Geräteimplementierungen:

• [C-0-3] MUSS eine spezielle Benutzeroberfläche für den Nutzer anzeigen, über die er entscheiden kann, ob er die angeforderten Laufzeitberechtigungen erteilen möchte. Außerdem MUSS eine Benutzeroberfläche für den Nutzer bereitgestellt werden, über die er Laufzeitberechtigungen verwalten kann.

• [C-0-5] Es DÜRFEN keine Laufzeitberechtigungen für Apps erteilt werden, es sei denn:

  • Sie werden bei der Auslieferung des Geräts installiert UND
  • Die Einwilligung des Nutzers kann eingeholt werden, bevor die App die Berechtigung verwendet.

  ODER

  • Die Laufzeitberechtigungen werden durch die Standardrichtlinie für die Berechtigungserteilung oder durch die Zuweisung einer Plattformrolle erteilt.

• [C-0-6] MUSS die Berechtigung android.permission.RECOVER_KEYSTORE nur System-Apps gewähren, die einen ordnungsgemäß gesicherten Wiederherstellungs-Agent registrieren. Ein ordnungsgemäß gesicherter Wiederherstellungs-Agent ist ein On-Device-Software-Agent, der mit einem Off-Device-Remotespeicher synchronisiert wird, der mit sicherer Hardware mit einem Schutz ausgestattet ist, der dem in Google Cloud Key Vault Service beschriebenen Schutz entspricht oder stärker ist, um Brute-Force-Angriffe auf den Sperrbildschirm-Wissensfaktor zu verhindern.

Geräteimplementierungen:

• [C-0-7] MUSS die Eigenschaften der Android-Berechtigung zur Standortermittlung einhalten, wenn eine App den Standort oder Aktivitätsdaten über die Standard-Android-API oder einen proprietären Mechanismus anfordert. Zu diesen Daten gehören unter anderem:

  • Standort des Geräts (z.B. Breitengrad und Längengrad), wie in Abschnitt 9.8.8 beschrieben.

  • Informationen, die verwendet werden können, um den Standort des Geräts zu bestimmen oder zu schätzen, z.B. SSID, BSSID, Cell ID oder Standort des Netzwerks, mit dem das Gerät verbunden ist.

  • Körperliche Aktivität des Nutzers oder Klassifizierung der körperlichen Aktivität.

Geräteimplementierungen:

• [C-0-8] Die Nutzereinwilligung MUSS eingeholt werden, damit eine App auf Standort- oder Aktivitätsdaten zugreifen kann.

• [C-0-9] MUSS eine Laufzeitberechtigung NUR der App erteilen, die über die im SDK beschriebene ausreichende Berechtigung verfügt. Beispiel: TelephonyManager#getServiceState erfordert android.permission.ACCESS_FINE_LOCATION.

Die einzigen Ausnahmen von den oben genannten Eigenschaften der Android-Berechtigung zur Standortermittlung gelten für Apps, die nicht auf den Standort zugreifen, um den Standort des Nutzers abzuleiten oder zu identifizieren. Das betrifft insbesondere:

• Wenn Apps die Berechtigung RADIO_SCAN_WITHOUT_LOCATION haben.

• Für die Gerätekonfiguration und Einrichtung, wenn System-Apps die Berechtigung NETWORK_SETTINGS oder NETWORK_SETUP_WIZARD haben.

Berechtigungen können als eingeschränkt gekennzeichnet werden, wodurch sich ihr Verhalten ändert.

• [C-0-10] Berechtigungen, die mit dem Flag hardRestricted gekennzeichnet sind, DÜRFEN einer App nur unter folgenden Bedingungen gewährt werden:

  • Die APK-Datei einer App befindet sich in der Systempartition.

  • Der Nutzer weist einer App eine Rolle zu, die mit den Berechtigungen hardRestricted verknüpft ist.

  • Das Installationsprogramm gewährt einer App die hardRestricted.

  • Einer App wird die Berechtigung hardRestricted in einer früheren Android-Version gewährt.

• [C-0-11] Apps mit der Berechtigung softRestricted DÜRFEN nur eingeschränkten Zugriff erhalten und NICHT den vollständigen Zugriff, bis sie wie im SDK beschrieben auf die Zulassungsliste gesetzt werden. Dort ist für jede softRestricted-Berechtigung (z. B. READ_EXTERNAL_STORAGE) der vollständige und der eingeschränkte Zugriff definiert.

• [C-0-12] Es DÜRFEN keine benutzerdefinierten Funktionen oder APIs bereitgestellt werden, um die in den APIs setPermissionPolicy und setPermissionGrantState definierten Berechtigungseinschränkungen zu umgehen.

• [C-0-13] MÜSSEN die AppOpsManager-APIs verwenden, um jeden programmatischen Zugriff auf Daten, die durch riskante Berechtigungen geschützt sind, von Android-Aktivitäten und ‑Diensten aufzuzeichnen und zu verfolgen.

• [C-0-14] MÜSSEN Rollen nur Anwendungen mit Funktionen zugewiesen werden, die den Rollenanforderungen entsprechen.

• [C-0-15] Es DÜRFEN KEINE Rollen definiert werden, die Duplikate oder eine Obermenge der Funktionalität von Rollen sind, die von der Plattform definiert werden.

Wenn Geräte Datensensoren enthalten, die gesundheitsbezogene biometrische Daten wie Herzfrequenz oder Hauttemperatur erfassen, müssen diese biometrischen Daten:

• [C-0-16] MUSS durch Plattformberechtigungen von android.permission-group.HEALTH geschützt werden, wenn es eine entsprechende Berechtigung in HealthPermissions gibt.

• [C-0-17] MUSS, wenn keine Plattformberechtigung dem gewünschten Datentyp entspricht, durch eine benutzerdefinierte Systemberechtigung geschützt werden. (Zum Beispiel: ELECTROCARDIOGRAM).

Wenn Geräte android.software.managed_users melden, gilt Folgendes:

• [C-1-1] Die folgenden Berechtigungen dürfen nicht stillschweigend vom Administrator gewährt werden:

  • Standort (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Kamera (CAMERA)
  • Mikrofon (RECORD_AUDIO)
  • Körpersensor (BODY_SENSORS)
  • Gesundheit (HealthPermissions)
  • Körperliche Aktivität (ACTIVITY_RECOGNITION)

Wenn Geräte android.software.managed_users melden, gilt Folgendes:

• [C-1-1] Die folgenden Berechtigungen dürfen nicht stillschweigend vom Administrator gewährt werden:

  • Standort (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Kamera (CAMERA)
  • Mikrofon (RECORD_AUDIO)
  • Körpersensor (BODY_SENSORS)
  • Körperliche Aktivität (ACTIVITY_RECOGNITION)

Wenn Geräteimplementierungen eine Möglichkeit für Nutzer bieten, auszuwählen, welche Apps über anderen Apps mit einer Activity, die den Intent ACTION_MANAGE_OVERLAY_PERMISSION verarbeitet, angezeigt werden können, gilt Folgendes:

• [C-2-1] ALLE Aktivitäten mit Intent-Filtern für den ACTION_MANAGE_OVERLAY_PERMISSION-Intent MÜSSEN denselben UI-Bildschirm haben, unabhängig von der initiierenden App oder den von ihr bereitgestellten Informationen.

Wenn Geräteimplementierungen android.software.device_admin melden, gilt Folgendes:

• [C-3-1] Während der Einrichtung eines vollständig verwalteten Geräts (Einrichtung durch den Geräteinhaber) MUSS ein Haftungsausschluss angezeigt werden, in dem darauf hingewiesen wird, dass der IT-Administrator Apps die Möglichkeit geben kann, Einstellungen auf dem Smartphone zu steuern, einschließlich Mikrofon, Kamera und Standort. Der Nutzer hat die Möglichkeit, die Einrichtung fortzusetzen oder zu beenden, ES SEI DENN, der Administrator hat die Steuerung von Berechtigungen auf dem Gerät deaktiviert.

Wenn auf Geräteimplementierungen Pakete vorinstalliert sind, die eine der Rollen System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence oder System Visual Intelligence enthalten, müssen die Pakete:

• [C-4-1] MUSS alle Anforderungen erfüllen, die für Geräteimplementierungen in den Abschnitten 9.8.6. Betriebssystemebene und Umgebungsdaten und 9.8.15. Sandboxed API-Implementierungen.

9.2 UID und Prozessisolation

Geräteimplementierungen:

• [C-0-1] MUSS das Android-App-Sandboxmodell unterstützen, in dem jede Anwendung als eindeutige UID im Unix-Stil und in einem separaten Prozess ausgeführt wird.
• [C-0-2] Es MUSS möglich sein, mehrere Anwendungen mit derselben Linux-Nutzer-ID auszuführen, sofern die Anwendungen ordnungsgemäß signiert und erstellt wurden, wie in der Referenz zu Sicherheit und Berechtigungen definiert.

9.3 Dateisystemberechtigungen

Geräteimplementierungen:

• [C-0-1] MÜSSEN das Android-Berechtigungsmodell für den Dateizugriff unterstützen, wie in der Referenz zu Sicherheit und Berechtigungen definiert.

9.4. Alternative Ausführungsumgebungen

Geräteimplementierungen MÜSSEN die Konsistenz des Android-Sicherheits- und Berechtigungsmodells beibehalten, auch wenn sie Laufzeitumgebungen enthalten, in denen Anwendungen mit anderer Software oder Technologie als dem Dalvik Executable-Format oder nativem Code ausgeführt werden. Dies bedeutet:

• [C-0-1] Alternative Runtimes MÜSSEN selbst Android-Anwendungen sein und dem standardmäßigen Android-Sicherheitsmodell entsprechen, wie an anderer Stelle in Abschnitt 9 beschrieben.

• [C-0-2] Alternativen Laufzeitumgebungen DÜRFEN über den <uses-permission>-Mechanismus NICHT auf Ressourcen zugreifen, die durch Berechtigungen geschützt sind, die in der AndroidManifest.xml-Datei der Laufzeitumgebung nicht angefordert werden.

• [C-0-3] Alternative Laufzeitumgebungen DÜRFEN Anwendungen NICHT erlauben, Funktionen zu nutzen, die durch Android-Berechtigungen geschützt sind, die auf Systemanwendungen beschränkt sind.

• [C-0-4] Alternative Laufzeiten MÜSSEN dem Android-Sandbox-Modell entsprechen und mit einer alternativen Laufzeit installierte Anwendungen DÜRFEN die Sandbox einer anderen auf dem Gerät installierten App NICHT wiederverwenden, es sei denn, dies erfolgt über die standardmäßigen Android-Mechanismen für die gemeinsame Nutzer-ID und das Signaturzertifikat.

• [C-0-5] Alternative Runtimes DÜRFEN NICHT mit den Sandboxes anderer Android-Anwendungen gestartet werden, Zugriff auf diese gewähren oder Zugriff auf diese erhalten.

• [C-0-6] Alternative Runtimes DÜRFEN NICHT mit den Berechtigungen des Superusers (Root) oder einer anderen Nutzer-ID gestartet werden, solche Berechtigungen erhalten oder anderen Anwendungen gewähren.

• [C-0-7] Wenn die .apk-Dateien alternativer Runtimes im Systemimage von Geräteimplementierungen enthalten sind, MÜSSEN sie mit einem Schlüssel signiert werden, der sich von dem Schlüssel unterscheidet, der zum Signieren anderer Anwendungen verwendet wird, die in den Geräteimplementierungen enthalten sind.

• [C-0-8] Bei der Installation von Anwendungen MÜSSEN alternative Laufzeiten die Nutzereinwilligung für die von der Anwendung verwendeten Android-Berechtigungen einholen.

• [C-0-9] Wenn eine Anwendung eine Geräteressource verwenden muss, für die eine entsprechende Android-Berechtigung vorhanden ist (z. B. Kamera, GPS usw.), MUSS die alternative Laufzeit den Nutzer darüber informieren, dass die Anwendung auf diese Ressource zugreifen kann.

• [C-0-10] Wenn die Laufzeitumgebung die Anwendungsfunktionen nicht auf diese Weise aufzeichnet, MUSS sie bei der Installation einer Anwendung mit dieser Laufzeit alle von der Laufzeit selbst gehaltenen Berechtigungen auflisten.

• Alternative Runtimes SOLLTEN Apps über die PackageManager in separaten Android-Sandboxes (Linux-Nutzer-IDs usw.) installieren.

• Alternative Laufzeiten KÖNNEN eine einzelne Android-Sandbox bereitstellen, die von allen Anwendungen verwendet wird, die die alternative Laufzeit verwenden.

9.5. Unterstützung mehrerer Nutzer

Android bietet Unterstützung für mehrere Nutzer und vollständige Nutzerisolation sowie das Klonen von Nutzerprofilen mit teilweiser Isolation (d.h. ein einzelnes zusätzliches Nutzerprofil vom Typ android.os.usertype.profile.CLONE).

• Bei Geräteimplementierungen KANN, SOLLTE aber NICHT die Unterstützung mehrerer Nutzer aktiviert werden, wenn Wechselmedien als primärer externer Speicher verwendet werden.

Wenn Geräteimplementierungen Unterstützung für mehrere Nutzer enthalten, gilt Folgendes:

• [C-1-2] MUSS für jeden Nutzer ein Sicherheitsmodell implementieren, das mit dem Sicherheitsmodell der Android-Plattform übereinstimmt, wie im Referenzdokument zu Sicherheit und Berechtigungen in den APIs definiert.

• [C-1-3] MUSS für jede Nutzerinstanz separate und isolierte Verzeichnisse für den gemeinsamen Anwendungs-Storage (auch /sdcard genannt) haben.

• [C-1-4] MUSS dafür sorgen, dass Anwendungen, die einem bestimmten Nutzer gehören und in seinem Namen ausgeführt werden, die Dateien eines anderen Nutzers nicht auflisten, lesen oder in sie schreiben können, auch wenn die Daten beider Nutzer auf demselben Volume oder Dateisystem gespeichert sind.

• [C-1-5] Der Inhalt der SD-Karte MUSS verschlüsselt werden, wenn die Mehrbenutzerfunktion aktiviert ist. Dazu muss ein Schlüssel verwendet werden, der nur auf nicht herausnehmbaren Medien gespeichert ist, auf die nur das System zugreifen kann, wenn in Geräteimplementierungen herausnehmbare Medien für die APIs für externen Speicher verwendet werden. Da die Medien dadurch für einen Host-PC nicht mehr lesbar sind, müssen Geräteimplementierungen auf MTP oder ein ähnliches System umgestellt werden, um Host-PCs Zugriff auf die Daten des aktuellen Nutzers zu ermöglichen.

Wenn Geräteimplementierungen Unterstützung für mehrere Nutzer enthalten, gilt für alle Nutzer mit Ausnahme von Nutzern, die speziell für die Ausführung von zwei Instanzen derselben App erstellt wurden:

• [C-2-1] Es MUSS separate und isolierte Verzeichnisse für den gemeinsamen Anwendungs-Speicher (auch bekannt als /sdcard) für jede Nutzerinstanz geben.

• [C-2-2] MUSS dafür sorgen, dass Anwendungen, die einem bestimmten Nutzer gehören und in seinem Namen ausgeführt werden, die Dateien anderer Nutzer nicht auflisten, lesen oder in sie schreiben können, auch wenn die Daten beider Nutzer auf demselben Volume oder Dateisystem gespeichert sind.

Geräteimplementierungen DÜRFEN ein einzelnes zusätzliches Nutzerprofil vom Typ android.os.usertype.profile.CLONE für den Hauptnutzer (und nur für den Hauptnutzer) erstellen, um zwei Instanzen derselben App auszuführen. Diese beiden Instanzen verwenden teilweise isolierten Speicher, werden dem Endnutzer gleichzeitig im Launcher angezeigt und erscheinen in derselben Ansicht „Letzte Apps“. So könnte beispielsweise unterstützt werden, dass der Nutzer zwei separate Instanzen einer einzelnen App auf einem Dual-SIM-Gerät installiert.

Wenn Geräteimplementierungen das oben beschriebene zusätzliche Nutzerprofil erstellen, gilt Folgendes:

• [C-3-1] MUSS nur Zugriff auf Speicher oder Daten gewähren, auf die das übergeordnete Nutzerprofil bereits zugreifen kann oder die direkt diesem zusätzlichen Nutzerprofil gehören.

• [C-3-2] Das Gerät darf kein Arbeitsprofil haben.

• [C-3-3] Private App-Datenverzeichnisse MÜSSEN vom übergeordneten Nutzerkonto isoliert sein.

• [C-3-4] Das Erstellen des zusätzlichen Nutzerprofils DARF NICHT zugelassen werden, wenn ein Geräteinhaber bereitgestellt wurde (siehe Abschnitt 3.9.1), und es DARF NICHT zugelassen werden, dass ein Geräteinhaber bereitgestellt wird, ohne das zusätzliche Nutzerprofil zuerst zu entfernen.

Wenn Geräteimplementierungen das oben beschriebene zusätzliche Nutzerprofil erstellen, gilt Folgendes:

• [C-4-1] MUSS es ermöglichen, dass die unten aufgeführten Intents, die vom zusätzlichen Profil stammen, von Anwendungen des Hauptnutzers auf dem Gerät verarbeitet werden:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] Alle Nutzerbeschränkungen für Geräte und ausgewählte restrictions(list below), die auf den Hauptnutzer des Geräts angewendet werden, MÜSSEN auf dieses zusätzliche Nutzerprofil übertragen werden.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] Das Schreiben von Kontakten aus diesem zusätzlichen Profil MUSS nur über die folgenden Intents möglich sein:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] Für Anwendungen, die in diesem zusätzlichen Nutzerprofil ausgeführt werden, dürfen KEINE Kontaktsynchronisierungen erfolgen.

• [C-4-5] Apps im zusätzlichen Profil, die eine Launcher-Aktivität haben, DÜRFEN NUR auf Kontakte zugreifen, auf die das übergeordnete Nutzerprofil bereits Zugriff hat.

Wenn Geräteimplementierungen das oben beschriebene zusätzliche Nutzerprofil erstellen, mindestens eine Kamera enthalten und die vorinstallierte Kameraanwendung die Intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE oder MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE verarbeitet, gilt Folgendes:

• [C-5-1] Anwendungen des Hauptnutzers MÜSSEN diese Intents verarbeiten können, die von diesem zusätzlichen Nutzerprofil stammen.

9.6. Warnung zu Premium-SMS

Android unterstützt die Warnung von Nutzern vor ausgehenden Premium-SMS-Nachrichten. Premium-SMS sind SMS, die an einen bei einem Mobilfunkanbieter registrierten Dienst gesendet werden und für die dem Nutzer möglicherweise Kosten in Rechnung gestellt werden.

Wenn Geräteimplementierungen Unterstützung für android.hardware.telephony deklarieren, gilt Folgendes:

• [C-1-1] Nutzer MÜSSEN gewarnt werden, bevor eine SMS an Nummern gesendet wird, die durch reguläre Ausdrücke identifiziert werden, die in der Datei /data/misc/sms/codes.xml auf dem Gerät definiert sind. Das Upstream-Open-Source-Projekt für Android bietet eine Implementierung, die diese Anforderung erfüllt.

9.7. Sicherheitsfunktionen

Geräteimplementierungen MÜSSEN die unten beschriebenen Sicherheitsfunktionen im Kernel und auf der Plattform einhalten.

Die Android-Sandbox umfasst Funktionen, die das obligatorische Zugriffssteuerungssystem (Mandatory Access Control, MAC) von Security-Enhanced Linux (SELinux), Seccomp-Sandboxing und andere Sicherheitsfunktionen im Linux-Kernel verwenden. Geräteimplementierungen:

• [C-0-1] MUSS die Kompatibilität mit bestehenden Anwendungen aufrechterhalten, auch wenn SELinux oder andere Sicherheitsfunktionen unterhalb des Android-Frameworks implementiert werden.

• [C-0-2] DARF KEINE sichtbare Benutzeroberfläche haben, wenn ein Sicherheitsverstoß erkannt und von der Sicherheitsfunktion, die unter dem Android-Framework implementiert ist, erfolgreich blockiert wird. Eine sichtbare Benutzeroberfläche ist jedoch ZULÄSSIG, wenn ein nicht blockierter Sicherheitsverstoß auftritt, der zu einem erfolgreichen Exploit führt.

• [C-0-3] SELinux oder andere Sicherheitsfunktionen, die unterhalb des Android-Frameworks implementiert sind, DÜRFEN NICHT für den Nutzer oder App-Entwickler konfigurierbar sein.

• [C-0-4] Eine Anwendung, die über eine API (z. B. eine Geräteadministrator-API) eine andere Anwendung beeinflussen kann, DARF NICHT die Konfiguration einer Richtlinie ermöglichen, die die Kompatibilität beeinträchtigt.

• [C-0-5] Das Media-Framework MUSS in mehrere Prozesse aufgeteilt werden, damit der Zugriff für jeden Prozess eingeschränkter gewährt werden kann, wie auf der Website des Open-Source-Projekts für Android beschrieben.

• [C-0-6] MUSS einen Kernel-Anwendungssandbox-Mechanismus implementieren, der das Filtern von Systemaufrufen mithilfe einer konfigurierbaren Richtlinie aus Multithread-Programmen ermöglicht. Das Upstream-Open-Source-Projekt für Android erfüllt diese Anforderung, indem es seccomp-BPF mit Threadgroup-Synchronisierung (TSYNC) aktiviert, wie im Abschnitt „Kernel Configuration“ (Kernelkonfiguration) auf source.android.com beschrieben.

Die Kernelintegrität und die Selbstschutzfunktionen sind ein wichtiger Bestandteil der Android-Sicherheit. Geräteimplementierungen:

• [C-0-7] MÜSSEN Schutzmechanismen gegen Pufferüberläufe im Kernel-Stack implementieren. Beispiele für solche Mechanismen sind CC_STACKPROTECTOR_REGULAR und CONFIG_CC_STACKPROTECTOR_STRONG.

• [C-0-8] Es MUSS ein strenger Schutz des Kernel-Speichers implementiert werden, bei dem ausführbarer Code schreibgeschützt ist, schreibgeschützte Daten nicht ausführbar und nicht beschreibbar sind und beschreibbare Daten nicht ausführbar sind (z. B. sind sowohl rodata als auch CONFIG_STRICT_KERNEL_RWX aktiviert).

• [C-0-9] Auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden, MUSS eine statische und dynamische Größenprüfung von Kopien zwischen Nutzer- und Kernelbereich (z.B. CONFIG_HARDENED_USERCOPY) implementiert werden.

• [C-0-10] DÜRFEN bei der Ausführung im Kernelmodus (z.B. Hardware-PXN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden, KEINEN Arbeitsspeicher im Nutzerbereich ausführen.

• [C-0-11] Der Kernel DÜRFEN NICHT auf den Arbeitsspeicher im Nutzerbereich zugreifen oder in den Arbeitsspeicher im Nutzerbereich schreiben, außer über normale Usercopy-Zugriffs-APIs (z.B. Hardware-PAN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden.

• [C-0-12] Die Kernel-Seitentabelle muss isoliert werden, wenn die Hardware auf allen Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden (z.B. CONFIG_PAGE_TABLE_ISOLATION oder CONFIG_UNMAP_KERNEL_AT_EL0), anfällig für CVE-2017-5754 ist.

• [C-0-13] MUSS die Härtung der Zweigvorhersage implementieren, wenn die Hardware auf allen Geräten, die ursprünglich mit API-Level 28 oder höher (z.B. CONFIG_HARDEN_BRANCH_PREDICTOR) ausgeliefert wurden, anfällig für CVE-2017-5715 ist.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, Kernel-Daten, die nur während der Initialisierung geschrieben werden, nach der Initialisierung als schreibgeschützt zu kennzeichnen (z.B. __ro_after_init).

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, das Layout des Kernel-Codes und des Arbeitsspeichers zu randomisieren und Offenlegungen zu vermeiden, die die Randomisierung beeinträchtigen könnten (z.B. CONFIG_RANDOMIZE_BASE mit Bootloader-Entropie über /chosen/kaslr-seed Device Tree node oder EFI_RNG_PROTOCOL).

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, Control Flow Integrity (CFI) im Kernel zu aktivieren, um zusätzlichen Schutz vor Angriffen durch Wiederverwendung von Code (z.B. CONFIG_CFI_CLANG und CONFIG_SHADOW_CALL_STACK) zu bieten.

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, Control-Flow Integrity (CFI), Shadow Call Stack (SCS) oder Integer Overflow Sanitization (IntSan) nicht für Komponenten zu deaktivieren, für die sie aktiviert sind.

• [C-SR-5] Es wird DRINGEND EMPFOHLEN, CFI, SCS und IntSan für alle zusätzlichen sicherheitssensiblen Nutzerbereichskomponenten zu aktivieren, wie in CFI und IntSan beschrieben.

• [C-SR-6] Es wird DRINGEND EMPFOHLEN, die Stapelinitialisierung im Kernel zu aktivieren, um die Verwendung nicht initialisierter lokaler Variablen (CONFIG_INIT_STACK_ALL oder CONFIG_INIT_STACK_ALL_ZERO) zu verhindern. Außerdem SOLLTEN Geräteimplementierungen nicht davon ausgehen, dass der Compiler die lokalen Variablen mit einem bestimmten Wert initialisiert.

• [C-SR-7] Es wird DRINGEND EMPFOHLEN, die Heap-Initialisierung im Kernel zu aktivieren, um die Verwendung nicht initialisierter Heap-Zuweisungen (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) zu verhindern. Es SOLLTE NICHT davon ausgegangen werden, dass der vom Kernel verwendete Wert zur Initialisierung dieser Zuweisungen verwendet wird.

Wenn Geräteimplementierungen einen Linux-Kernel verwenden, der SELinux unterstützt, gilt Folgendes:

• [C-1-1] MUSS SELinux implementieren.

• [C-1-2] SELinux MUSS auf den globalen Erzwingungsmodus eingestellt werden.

• [C-1-3] ALLE Domains MÜSSEN im Erzwingungsmodus konfiguriert werden. Es sind keine Domains im permissiven Modus zulässig, auch nicht Domains, die für ein bestimmtes Gerät oder einen bestimmten Anbieter gelten.

• [C-1-5] Drittanbieteranwendungen, die auf API-Level 28 oder höher ausgerichtet sind, MÜSSEN in SELinux-Sandboxes pro Anwendung mit SELinux-Einschränkungen pro App für das private Datenverzeichnis jeder Anwendung ausgeführt werden.

• Sollten die standardmäßige SELinux-Richtlinie beibehalten, die im Ordner „system/sepolicy“ des Open-Source-Projekts für Android bereitgestellt wird, und diese Richtlinie nur für ihre eigene gerätespezifische Konfiguration erweitern.

Wenn in Geräteimplementierungen ein anderer Kernel als Linux oder Linux ohne SELinux verwendet wird, gilt Folgendes:

• [C-2-1] MUSS ein obligatorisches Zugriffssteuerungssystem verwenden, das SELinux entspricht.

Wenn in Geräteimplementierungen I/O-Geräte verwendet werden, die DMA unterstützen, gilt Folgendes:

• [C-SR-9] Es wird DRINGEND EMPFOHLEN, jedes I/O-Gerät, das DMA unterstützt, mit einem IOMMU (z.B. dem ARM SMMU) zu isolieren.

Android enthält mehrere Funktionen für gestaffelte Sicherheitsebenen, die für die Gerätesicherheit unerlässlich sind. Außerdem konzentriert sich Android darauf, wichtige Klassen häufiger Fehler zu reduzieren, die zu schlechter Qualität und Sicherheit beitragen.

Um Speicherfehler zu reduzieren, sollten Geräteimplementierungen:

• [C-SR-10] Es wird DRINGEND EMPFOHLEN, diese mit Tools zur Erkennung von Speicherfehlern im Userspace wie MTE für ARMv9-Geräte, HWASan für ARMv8+-Geräte oder ASan für andere Gerätetypen zu testen.

• [C-SR-11] Es wird DRINGEND EMPFOHLEN, diese mit Tools zur Erkennung von Kernel-Speicherfehlern wie KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS für ARMv9-Geräte, CONFIG_KASAN_SW_TAGS für ARMv8-Geräte oder CONFIG_KASAN_GENERIC für andere Gerätetypen) zu testen.

• [C-SR-12] Es wird DRINGEND EMPFOHLEN, in der Produktion Tools zur Erkennung von Speicherfehlern wie MTE, GWP-ASan und KFENCE zu verwenden.

Wenn Geräteimplementierungen eine auf Arm TrustZone basierende TEE verwenden, gilt Folgendes:

• [C-SR-13] Es wird DRINGEND EMPFOHLEN, ein Standardprotokoll für die Speicherfreigabe zwischen Android und der TEE zu verwenden, z. B. das Arm Firmware Framework for Armv8-A (FF-A).

• [C-SR-14] Es WIRD DRINGEND EMPFOHLEN, den Zugriff vertrauenswürdiger Anwendungen auf Speicher zu beschränken, der explizit über das oben genannte Protokoll für sie freigegeben wurde. Wenn das Gerät die ARM‑Ausnahmestufe S‑EL2 unterstützt, sollte dies durch die sichere Partitionsverwaltung erzwungen werden. Andernfalls sollte dies vom TEE‑Betriebssystem erzwungen werden.

Eine Memory Safety-Technologie ist eine Technologie, die mindestens die folgenden Fehlerklassen mit hoher Wahrscheinlichkeit (> 90%) in Anwendungen, die die Manifestoption android:memtagMode verwenden, behebt:

• Heap-Pufferüberlauf
• Use After Free
• double free
• wild free (Freigabe eines Nicht-Malloc-Zeigers)

Geräteimplementierungen:

• [C-SR-15] Es wird DRINGEND EMPFOHLEN, ro.arm64.memtag.bootctl_supported festzulegen.

Wenn Geräteimplementierungen die Systemeigenschaft ro.arm64.memtag.bootctl_supported auf „true“ setzen, gilt Folgendes:

• [C-3-1] Die System-Property arm64.memtag.bootctl MUSS eine durch Kommas getrennte Liste der folgenden Werte akzeptieren, wobei der gewünschte Effekt beim nächsten Neustart angewendet wird:

  • memtag: Eine Memory Safety-Technologie wie oben definiert ist aktiviert.

  • memtag-once: Eine Memory Safety-Technologie wie oben beschrieben wird vorübergehend aktiviert und beim nächsten Neustart automatisch deaktiviert.

  • memtag-off: Eine oben definierte Memory Safety-Technologie ist deaktiviert.

• [C-3-2] Der Shell-Nutzer MUSS arm64.memtag.bootctl festlegen können.

• [C-3-3] Jeder Prozess MUSS arm64.memtag.bootctl lesen dürfen.

• [C-3-4] MUSS arm64.memtag.bootctl beim Booten auf den aktuell angeforderten Status setzen und die Property auch aktualisieren, wenn die Geräteimplementierung die Änderung des Status ohne Änderung der Systemeigenschaft zulässt.

• [C-SR-16] Es wird DRINGEND EMPFOHLEN, eine Entwicklereinstellung anzuzeigen, mit der „memtag-once“ festgelegt und das Gerät neu gestartet wird. Mit einem kompatiblen Bootloader erfüllt das Open-Source-Projekt für Android die oben genannten Anforderungen über das MTE-Bootloader-Protokoll.

Wenn ein Gerät android.hardware.telephony deklariert, die Funkfunktion CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK unterstützt und ein Mobilfunkmodem enthält, das 2G-Verbindungen unterstützt, muss die Geräteimplementierung:

• [C-SR-17] Es wird DRINGEND EMPFOHLEN, dem Nutzer die Möglichkeit zu geben, 2G zu deaktivieren und zu aktivieren.

• [C-SR-18] Es wird DRINGEND EMPFOHLEN, die Möglichkeit für Nutzer, 2G über ein anderes Geräte-Entität als einen Geräteadministrator mit UserManager.DISALLOW_CELLULAR_2G zu deaktivieren und zu aktivieren, NICHT zu überschreiben.

• [C-SR-19] Es wird DRINGEND EMPFOHLEN, TelephonyManager.setAllowedNetworkTypesForReason mit dem Grund ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G aufzurufen, um diese Anforderung zu erfüllen.

• [C-SR-20] Es wird DRINGEND EMPFOHLEN, die Unterstützung des Mobilfunkmodems für 2G durch Aufrufen von TelephonyManager.getSupportedRadioAccessFamily zu ermitteln. Weitere Informationen finden Sie unter 2G deaktivieren.

9.8. Datenschutz

9.8.1. Nutzungsverlauf

Android speichert den Verlauf der Nutzerauswahl und verwaltet ihn mit UsageStatsManager.

Geräteimplementierungen:

• [C-0-1] MUSS einen angemessenen Aufbewahrungszeitraum für diesen Nutzerverlauf einhalten.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die standardmäßig in der AOSP-Implementierung konfigurierte Aufbewahrungsdauer von 14 Tagen beizubehalten.

Android speichert die Systemereignisse mit den StatsLog-Kennungen und verwaltet den Verlauf über die System-APIs StatsManager und IncidentManager.

Geräteimplementierungen:

• [C-0-2] MUSS nur die Felder enthalten, die im von der System API-Klasse IncidentManager erstellten Vorfallbericht mit DEST_AUTOMATIC gekennzeichnet sind.

• [C-0-3] Die Systemereignis-IDs DÜRFEN NICHT verwendet werden, um andere Ereignisse als die in der StatsLog-SDK-Dokumentation beschriebenen zu protokollieren. Wenn zusätzliche Systemereignisse protokolliert werden, wird möglicherweise eine andere Atom-ID im Bereich zwischen 100.000 und 200.000 verwendet.

9.8.2. Aufnahme läuft

Geräteimplementierungen:

• [C-0-1] Softwarekomponenten dürfen nicht sofort nach dem Auspacken vorinstalliert oder verteilt werden, die private Informationen des Nutzers (z.B. Tasteneingaben, auf dem Bildschirm angezeigter Text, Fehlerbericht) ohne die Einwilligung des Nutzers oder klare, fortlaufende Benachrichtigungen vom Gerät senden.

• [C-0-2] MUSS eine Nutzerwarnung anzeigen und die ausdrückliche Nutzereinwilligung einholen, damit alle vertraulichen Informationen, die auf dem Bildschirm des Nutzers angezeigt werden, jedes Mal erfasst werden können, wenn eine Sitzung zur Erfassung des Screen-Castings oder der Bildschirmaufzeichnung über MediaProjection.createVirtualDisplay() oder proprietäre APIs aktiviert wird.

• [C-0-3] Während der Bildschirmübertragung oder Bildschirmaufzeichnung MUSS eine Benachrichtigung über laufende Aktivitäten für den Nutzer angezeigt werden. AOSP erfüllt diese Anforderung, indem ein Symbol für Benachrichtigungen über laufende Aktivitäten in der Statusleiste angezeigt wird.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, eine Nutzerwarnung anzuzeigen, die genau der in AOSP implementierten Meldung entspricht. Sie KANN jedoch geändert werden, solange die Meldung den Nutzer deutlich darauf hinweist, dass alle vertraulichen Informationen auf dem Bildschirm des Nutzers erfasst werden.

• [C-0-4] Anforderung in Android 16 entfernt.

Geräteimplementierungen:

• [C-0-7] Es DÜRFEN KEINE vertraulichen Informationen wie die folgenden aufgezeichnet, projiziert oder übertragen werden:

  • Vertrauliche Benachrichtigungsinhalte, die in Abschnitt 3.8.3.4 Schutz vertraulicher Benachrichtigungen aufgeführt sind
  • App-Aktivitätsfenster mit Einmalpasswörtern
  • Sensible Inhalte wie Nutzername, Passwort und Kreditkarteninformationen

Wenn Geräteimplementierungen Funktionen im System enthalten, die entweder die auf dem Bildschirm angezeigten Inhalte erfassen und/oder den auf dem Gerät wiedergegebenen Audiostream aufzeichnen, außer über die System-API ContentCaptureService oder andere proprietäre Mittel, die in Abschnitt 9.8.6 Betriebssystemebene und Umgebungsdaten beschrieben sind, gilt Folgendes:

• [C-1-1] MUSS eine Benachrichtigung über laufende Aktivitäten für den Nutzer anzeigen, wenn diese Funktion aktiviert ist und aktiv Daten erfasst/aufzeichnet.

Wenn Geräteimplementierungen eine Komponente enthalten, die standardmäßig aktiviert ist und Umgebungsgeräusche und/oder auf dem Gerät wiedergegebenes Audio aufzeichnen kann, um nützliche Informationen über den Kontext des Nutzers abzuleiten, gilt Folgendes:

• [C-2-1] Aufgezeichnete Rohaudiodaten oder ein Format, das in die Originalaudiodaten oder ein ähnliches Format zurückkonvertiert werden kann, DÜRFEN NICHT im persistenten On-Device-Speicher gespeichert oder vom Gerät übertragen werden, es sei denn, der Nutzer hat ausdrücklich zugestimmt.

Ein „Mikrofonindikator“ ist eine Ansicht auf dem Bildschirm, die für den Nutzer ständig sichtbar ist und nicht verdeckt werden kann. Nutzer verstehen sie als Hinweis darauf, dass ein Mikrofon verwendet wird(durch eindeutigen Text, eine eindeutige Farbe, ein eindeutiges Symbol oder eine Kombination davon).

Ein „Kamerazugriff-Hinweis“ ist eine Ansicht auf dem Bildschirm, die für den Nutzer ständig sichtbar ist und nicht verdeckt werden kann. Nutzer verstehen sie als Hinweis darauf, dass eine Kamera verwendet wird (durch eindeutigen Text, eine eindeutige Farbe, ein eindeutiges Symbol oder eine Kombination davon).

Nach der ersten Sekunde kann sich ein Indikator visuell verändern, z. B. kleiner werden. Er muss nicht so angezeigt werden, wie er ursprünglich präsentiert und verstanden wurde.

Die Mikrofonanzeige kann mit einer aktiv angezeigten Kameraanzeige zusammengeführt werden, sofern Text, Symbole oder Farben dem Nutzer anzeigen, dass die Mikrofonnutzung begonnen hat.

Der Kamerazugriff-Hinweis kann mit einer aktiv angezeigten Mikrofonanzeige zusammengeführt werden, sofern Text, Symbole oder Farben dem Nutzer anzeigen, dass die Kamera verwendet wird.

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, gilt Folgendes:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die Mikrofonanzeige zu präsentieren, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 Berechtigungen mit CDD-Kennung [C-3-X] genannten Rollen auf das Mikrofon zugreifen.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, die Liste der zuletzt verwendeten und aktiven Apps, die das Mikrofon verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen anzuzeigen.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Nutzerinteraktion NICHT auszublenden.

Wenn Geräteimplementierungen android.hardware.camera.any deklarieren, gilt Folgendes:

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, den Kamerazugriff-Hinweis zu präsentieren, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn auf die Kamera nur von Apps mit den in Abschnitt 9.1 „Berechtigungen mit CDD-Kennung [C-3-X]“ genannten Rollen zugegriffen wird.

• [C-SR-5] Es wird DRINGEND EMPFOHLEN, die letzten und aktiven Apps, die die Kamera verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen anzuzeigen.

• [C-SR-6] Es wird DRINGEND EMPFOHLEN, den Kamerazugriff-Hinweis für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Nutzerinteraktion NICHT auszublenden.

9.8.3. Konnektivität

Wenn Geräteimplementierungen einen USB-Anschluss mit Unterstützung für den USB-Peripheriemodus haben, gilt Folgendes:

• [C-1-1] MUSS eine Benutzeroberfläche präsentieren, in der der Nutzer um seine Einwilligung gebeten wird, bevor über den USB-Anschluss auf die Inhalte des freigegebenen Speichers zugegriffen werden darf.

9.8.4. Netzwerktraffic

Geräteimplementierungen:

• [C-0-1] Es MUSS dieselben Root-Zertifikate für den vom System vertrauenswürdigen Zertifizierungsstellenspeicher vorinstallieren, die im Upstream-Open-Source-Projekt für Android bereitgestellt werden.

• [C-0-2] MÜSSEN mit einem leeren Nutzerstammzertifikatspeicher ausgeliefert werden.

• [C-0-3] MUSS dem Nutzer eine Warnung anzeigen, dass der Netzwerkverkehr überwacht werden kann, wenn eine Nutzer-Root-Zertifizierungsstelle hinzugefügt wird.

Wenn der Geräteverkehr über ein VPN geleitet wird, müssen Geräteimplementierungen:

• [C-1-1] Dem Nutzer MUSS eine Warnung angezeigt werden, die Folgendes angibt:
  • Dieser Netzwerkverkehr wird möglicherweise überwacht.
  • Dieser Netzwerkverkehr wird über die jeweilige VPN-Anwendung weitergeleitet, die das VPN bereitstellt.

Wenn Geräteimplementierungen einen Mechanismus haben, der standardmäßig aktiviert ist und mit dem Netzwerkdatenverkehr über einen Proxyserver oder ein VPN-Gateway geleitet wird (z. B. durch Vorabinstallation eines VPN-Dienstes mit android.permission.CONTROL_VPN), gilt Folgendes:

• [C-2-1] Der Nutzer MUSS um Einwilligung gebeten werden, bevor dieser Mechanismus aktiviert wird, es sei denn, das VPN wird vom Device Policy Controller über DevicePolicyManager.setAlwaysOnVpnPackage() aktiviert. In diesem Fall muss der Nutzer keine separate Einwilligung erteilen, sondern NUR benachrichtigt werden.

Wenn Geräteimplementierungen eine Nutzeraufforderung zum Aktivieren der Funktion „Durchgehend aktives VPN“ einer VPN-App eines Drittanbieters implementieren, gilt Folgendes:

• [C-3-1] Diese Nutzerfreundlichkeit MUSS für Apps deaktiviert werden, die den Always-on-VPN-Dienst in der Datei AndroidManifest.xml nicht unterstützen. Dazu muss das Attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON auf false gesetzt werden.

9.8.5. Geräte-IDs

Geräteimplementierungen:

• [C-0-1] MUSS den Zugriff auf die Geräte-Seriennummer und, falls zutreffend, auf IMEI/MEID, SIM-Seriennummer und International Mobile Subscriber Identity (IMSI) über eine App verhindern, sofern die App nicht eine der folgenden Anforderungen erfüllt:
  • ist eine signierte Carrier-App, die von Geräteherstellern bestätigt wird.
  • Die Berechtigung READ_PRIVILEGED_PHONE_STATE wurde gewährt.
  • hat Mobilfunkanbieterberechtigungen gemäß UICC Carrier Privileges.
  • ist ein Geräteinhaber oder Profilinhaber, dem die Berechtigung READ_PHONE_STATE gewährt wurde.
  • (Nur für SIM-Seriennummer/ICCID) – Die lokalen Vorschriften erfordern, dass die App Änderungen an der Identität des Abonnenten erkennt.

9.8.6. Betriebssystemebene und Umgebungsdaten-Schutz

Android unterstützt über die System-APIs einen Mechanismus für Geräteimplementierungen, mit dem die folgenden sensiblen Daten erfasst werden können:

• Mediendaten wie Audio oder Video, die vom Gerät aufgezeichnet oder wiedergegeben werden.

• Eingabeereignisse (z. B. Tastatur, Maus, Geste, Sprache, Video und Barrierefreiheit)

• Alle Bildschirme oder anderen Daten, die über die AugmentedAutofillService an das System gesendet werden.

• Alle Bildschirme oder anderen Daten, auf die über Content Capture-APIs zugegriffen werden kann.

• Alle Anwendungsdaten, die über die AppSearchManager API an das System übergeben werden und über AppSearchGlobalManager.query zugänglich sind.

• Alle Texte oder anderen Daten, die über die TextClassifier API an den System-TextClassifier gesendet werden, d.h. an den Systemdienst, um die Bedeutung von Text zu verstehen und auf Grundlage des Textes vorhergesagte nächste Aktionen zu generieren.

• Von der AppSearch-Implementierung der Plattform indexierte Daten, einschließlich, aber nicht beschränkt auf Text, Grafiken, Mediendaten oder andere ähnliche Daten.

• Audiodaten, die durch die Verwendung von SpeechRecognizer#onDeviceSpeechRecognizer() durch die Speech Recognizer-Implementierung erfasst werden.

• Audio-Daten, die im Hintergrund (kontinuierlich) über AudioRecord, SoundTrigger oder andere Audio-APIs erhoben werden und nicht zu einer für den Nutzer sichtbaren Anzeige führen

• Kameradaten, die im Hintergrund (kontinuierlich) über CameraManager oder andere Kamera-APIs abgerufen werden und nicht zu einer für den Nutzer sichtbaren Anzeige führen

• [C-1-7] Der Nutzer MUSS die Möglichkeit haben, die über AppSearch oder proprietäre Methoden erhobenen Daten aus der Android-Plattform (z.B. Launcher) zu entfernen.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, die INTERNET-Berechtigung NICHT anzufordern.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, nur über strukturierte APIs auf das Internet zuzugreifen, die von öffentlich verfügbaren Open-Source-Implementierungen unterstützt werden.

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, sie mit der Android SDK API oder einem ähnlichen Open-Source-Repository des OEM zu implementieren und / oder in einer Sandbox-Implementierung auszuführen (siehe 9.8.15 Sandbox-API-Implementierungen).

9.8.7. Zugriff auf die Zwischenablage

Geräteimplementierungen:

• [C-0-1] Es DÜRFEN KEINE gekürzten Daten aus der Zwischenablage zurückgegeben werden (z.B. über die ClipboardManager-API), es sei denn, die Drittanbieter-App ist die Standard-IME oder die App, die gerade den Fokus hat.

• [C-0-2] MUSS Daten in der Zwischenablage spätestens 60 Minuten nach dem letzten Einfügen oder Lesen aus der Zwischenablage löschen.

9.8.8. Standort

Der Standort umfasst Informationen in der Android-Standortklasse( z. B. Breitengrad, Längengrad, Höhe) sowie Kennungen, die in einen Standort umgewandelt werden können. Der Standort kann so genau wie DGPS (Differential Global Positioning System) oder so grob wie Standorte auf Länderebene (z. B. der Ländercode – MCC – Mobile Country Code) sein.

Im Folgenden finden Sie eine Liste der Standorte, die entweder direkt den Standort eines Nutzers angeben oder in den Standort eines Nutzers umgewandelt werden können. Diese Liste ist nicht vollständig, soll aber als Beispiel dafür dienen, woraus der Standort direkt oder indirekt abgeleitet werden kann:

• GPS/GNSS/DGPS/PPP

  • Global Positioning Solution oder Global Navigation Satellite System oder Differential Global Positioning Solution
  • Dazu gehören auch GNSS-Rohmessungen und der GNSS-Status.
    • Genaue Standorte können aus den GNSS-Rohmessungen abgeleitet werden.

• Drahtlose Technologien mit eindeutigen Kennzeichnungen wie:

  • WLAN-Zugangspunkte (MAC, BSSID, Name oder SSID)
  • Bluetooth/BLE (MAC, BSSID, Name oder SSID)
  • UWB (MAC, BSSID, Name oder SSID)
  • Mobilfunkmast-ID (3G, 4G, 5G usw., einschließlich aller zukünftigen Mobilfunkmodem-Technologien mit eindeutigen Kennungen)

Die Android-APIs, für die die Berechtigungen ACCESS_FINE_Location oder ACCESS_COARSE_Location erforderlich sind, sind die primäre Referenz.

Geräteimplementierungen:

• [C-0-1] Die Einstellungen für den Gerätestandort und die Einstellungen für das Scannen von WLAN/Bluetooth dürfen NICHT ohne ausdrückliche Nutzereinwilligung oder ohne Nutzerinitiative aktiviert/deaktiviert werden.

• [C-0-2] Der Nutzer muss die Möglichkeit haben, auf standortbezogene Informationen zuzugreifen, einschließlich der letzten Standortanfragen, Berechtigungen auf App-Ebene und der Verwendung von WLAN-/Bluetooth-Scans zur Ermittlung des Standorts.

• [C-0-3] MUSS dafür sorgen, dass die Anwendung, die die Emergency Location Bypass API LocationRequest.setLocationSettingsIgnored() verwendet, eine vom Nutzer initiierte Notsitzung ist (z.B. durch Wählen von 911 oder Senden einer SMS an 911). Bei Automotive kann ein Fahrzeug jedoch eine Notsitzung ohne aktive Nutzerinteraktion starten, wenn ein Unfall erkannt wird (z. B. um eCall-Anforderungen zu erfüllen).

• [C-0-4] MUSS die Möglichkeit der Emergency Location Bypass APIs beibehalten, die Gerätestandorteinstellungen zu umgehen, ohne die Einstellungen zu ändern.

• [C-0-5] MUSS eine Benachrichtigung planen, die den Nutzer daran erinnert, nachdem eine App im Hintergrund mit der Berechtigung ACCESS_BACKGROUND_LOCATION auf seinen Standort zugegriffen hat.

9.8.9. Installierte Apps

Android-Apps, die auf API-Level 30 oder höher ausgerichtet sind, können standardmäßig keine Details zu anderen installierten Apps sehen (siehe Paketsichtbarkeit in der Android-SDK-Dokumentation).

Geräteimplementierungen:

• [C-0-1] Es DÜRFEN KEINE Details zu anderen installierten Apps für Apps mit API-Level 30 oder höher offengelegt werden, es sei denn, die App kann bereits über die verwalteten APIs Details zu der anderen installierten App sehen. Dazu gehören unter anderem Details, die von benutzerdefinierten APIs offengelegt werden, die vom Geräteimplementierer hinzugefügt wurden oder über das Dateisystem zugänglich sind.

• [C-0-2] Apps DÜRFEN KEINEN Lese- oder Schreibzugriff auf Dateien im app-spezifischen Verzeichnis einer anderen App auf dem externen Speicher erhalten. Die einzigen Ausnahmen sind:

  • Die Autorität des externen Speicheranbieters (z.B. Apps wie DocumentsUI).

  • Download-Provider, der die Provider-Autorität „downloads“ zum Herunterladen von Dateien in den App-Speicher verwendet.

  • Plattformsignierte MTP-Apps (Media Transfer Protocol), die die privilegierte Berechtigung ACCESS_MTP verwenden, um die Übertragung von Dateien auf ein anderes Gerät zu ermöglichen.

  • Apps, die andere Apps installieren und die Berechtigung INSTALL_PACKAGES haben, können nur auf „obb“-Verzeichnisse zugreifen, um APK-Erweiterungsdateien zu verwalten.

9.8.10. Fehlerbericht zur Verbindung

Wenn Geräteimplementierungen das Funktions-Flag android.hardware.telephony deklarieren, gilt Folgendes:

• [C-1-1] Das Gerät MUSS die Generierung von Verbindungsfehlerberichten über BUGREPORT_MODE_TELEPHONY mit BugreportManager unterstützen.

• [C-1-2] Die Nutzereinwilligung MUSS jedes Mal eingeholt werden, wenn BUGREPORT_MODE_TELEPHONY verwendet wird, um einen Bericht zu erstellen. Der Nutzer DARF NICHT aufgefordert werden, allen zukünftigen Anfragen der Anwendung zuzustimmen.

• [C-1-3] Der generierte Bericht DARF NICHT ohne ausdrückliche Nutzereinwilligung an die anfragende App zurückgegeben werden.

• [C-1-4] Berichte, die mit BUGREPORT_MODE_TELEPHONY erstellt werden, MÜSSEN mindestens die folgenden Informationen enthalten:

  • TelephonyDebugService verschieben
  • TelephonyRegistry verschieben
  • WifiService verschieben
  • ConnectivityService verschieben
  • Ein Dump der CarrierService-Instanz des aufrufenden Pakets (falls gebunden)
  • Funkschnittstellen-Logpuffer
  • SubscriptionManagerService verschieben

• [C-1-5] Die generierten Berichte DÜRFEN Folgendes NICHT enthalten:

  • Alle Informationen, die nicht direkt mit der Fehlerbehebung bei der Verbindung zusammenhängen.

  • Jegliche Art von Traffic-Logs oder detaillierten Profilen von vom Nutzer installierten Anwendungen/Paketen (UIDs sind in Ordnung, Paketnamen nicht).

• KANN zusätzliche Informationen enthalten, die keiner Nutzeridentität zugeordnet sind. (z.B. Anbieter-Logs).

Wenn Geräteimplementierungen zusätzliche Informationen (z.B. Vendor-Logs) in Fehlerberichte aufnehmen und diese Informationen Auswirkungen auf Datenschutz, Sicherheit, Akku, Speicher oder Arbeitsspeicher haben, gilt Folgendes:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, dass eine Entwicklereinstellung standardmäßig deaktiviert ist. Die AOSP-Referenzimplementierung erfüllt diese Anforderung, indem sie die Option Enable verbose vendor logging in den Entwicklereinstellungen bietet, um zusätzliche gerätespezifische Anbieterprotokolle in die Fehlerberichte aufzunehmen.

9.8.11. Weitergabe von Daten-Blobs

Unter Android können Apps über BlobStoreManager Daten-Blobs für das System bereitstellen, die für eine ausgewählte Gruppe von Apps freigegeben werden.

Wenn Geräteimplementierungen freigegebene Daten-Blobs unterstützen, wie in der SDK-Dokumentation beschrieben, gilt Folgendes:

• [C-1-1] Daten-Blobs von Apps dürfen nicht über das hinaus weitergegeben werden, was die App zulassen soll (d.h. der Umfang des Standardzugriffs und der anderen Zugriffsmodi, die mit BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() oder BlobStoreManager.session#allowPublicAccess() angegeben werden können, dürfen nicht geändert werden). Die AOSP-Referenzimplementierung erfüllt diese Anforderungen.

• [C-1-2] Die sicheren Hashes von Daten-Blobs (die zur Zugriffssteuerung verwendet werden) DÜRFEN NICHT an andere Apps gesendet oder mit ihnen geteilt werden.

9.8.12. Musikerkennung

Android unterstützt über die System-API MusicRecognitionManager einen Mechanismus, mit dem Geräteimplementierungen die Musikerkennung für eine Audioaufnahme anfordern und die Musikerkennung an eine privilegierte App delegieren können, die die MusicRecognitionService-API implementiert.

Wenn Geräteimplementierungen einen Dienst enthalten, der die System API MusicRecognitionManager oder einen proprietären Dienst implementiert, der Audiodaten wie oben beschrieben streamt, gilt Folgendes:

• [C-1-1] MUSS erzwingen, dass der Aufrufer von MusicRecognitionManager die Berechtigung MANAGE_MUSIC_RECOGNITION hat.

• [C-1-2] MUSS dafür sorgen, dass eine einzelne, vorinstallierte Musikerkennungsanwendung MusicRecognitionService implementiert.

• [C-1-3] Nutzer DÜRFEN den MusicRecognitionManagerService oder MusicRecognitionService NICHT durch eine vom Nutzer installierbare Anwendung oder einen vom Nutzer installierbaren Dienst ersetzen.

• [C-1-4] MUSS dafür sorgen, dass der Audiozugriff über Aufrufe von AppOpsManager.noteOp / startOp erfasst wird, wenn der MusicRecognitionManagerService auf die Audioaufzeichnung zugreift und sie an die Anwendung weiterleitet, die MusicRecognitionService implementiert.

Wenn in Geräteimplementierungen von MusicRecognitionManagerService oder MusicRecognitionService aufgenommene Audiodaten gespeichert werden, gilt Folgendes:

• [C-2-1] Es dürfen keine Rohaudiodaten oder Audio-Fingerabdrücke auf der Festplatte oder im Arbeitsspeicher länger als 14 Tage gespeichert werden.

• [C-2-2] Solche Daten DÜRFEN NICHT über die MusicRecognitionService hinaus weitergegeben werden, es sei denn, der Nutzer hat jedes Mal eine explizite Nutzereinwilligung erteilt.

9.8.13. SensorPrivacyManager

Wenn Geräteimplementierungen dem Nutzer eine Softwarefunktion zum Deaktivieren der Kamera- und/oder Mikrofoneingabe für die Geräteimplementierung bieten, gilt Folgendes:

• [C-1-1] MUSS für die entsprechende supportsSensorToggle()-API-Methode korrekt „true“ zurückgeben.

• [C-1-2] MUSS, wenn eine App versucht, auf ein blockiertes Mikrofon oder eine blockierte Kamera zuzugreifen, dem Nutzer eine nicht schließbare Benachrichtigung präsentieren, die deutlich darauf hinweist, dass der Sensor blockiert ist und eine Auswahl erforderlich ist, um die Blockierung fortzusetzen oder aufzuheben, wie in der AOSP-Implementierung, die diese Anforderung erfüllt.

• [C-1-3] MUSS nur leere (oder gefälschte) Kamera- und Audiodaten an Apps übergeben und darf keinen Fehlercode melden, weil der Nutzer die Kamera oder das Mikrofon nicht über die gemäß [C-1-2] oben angezeigte Benutzeroberfläche aktiviert hat.

9.8.14. –

9.8.15. Implementierungen von Private Compute Core und Gateway-Anwendungen

9.8.16. Kontinuierliche Audio- und Kameradaten

Wenn in Geräteimplementierungen Daten gemäß Abschnitt 9.8.2 oder Abschnitt 9.8.6 erfasst werden und in solchen Implementierungen Audiodaten verwendet werden, die im Hintergrund (kontinuierlich) über AudioRecord, SoundTrigger oder andere Audio-APIs abgerufen werden, ODER Kameradaten verwendet werden, die im Hintergrund (kontinuierlich) über CameraManager oder andere Kamera-APIs abgerufen werden, gilt Folgendes:

• [C-0-1] MUSS eine entsprechende Anzeige (Kamera und/oder Mikrofon gemäß Abschnitt 9.8.2 „Aufzeichnung“) erzwingen, es sei denn:

  • Dieser Zugriff erfolgt in einer Sandbox-Implementierung (siehe 9.8.15 Sandbox-API-Implementierung) über ein Paket mit einer oder mehreren der folgenden Rollen: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, oder System Visual Intelligence.

  • Der Zugriff erfolgt über eine Sandbox, die über Mechanismen in AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector) implementiert und erzwungen wird.

  • Der Audiozugriff erfolgt zu unterstützenden Zwecken durch die App für den digitalen Assistenten, die SOURCE_HOTWORD als Audioquelle verwendet.

  • Der Zugriff erfolgt durch das System und wird mit Open-Source-Code implementiert.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, für jede Funktion, die solche Daten verwendet, die Nutzereinwilligung einzuholen und die Funktion standardmäßig zu deaktivieren.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, die gleichen Maßnahmen (d.h. die in 9.8.2 Aufzeichnung, 9.8.6 Betriebssystem- und Umgebungsdaten, 9.8.15 Sandboxed API-Implementierungen und 9.8.16 Kontinuierliche Audio- und Kameradaten beschriebenen Einschränkungen) auf Kameradaten anzuwenden, die von einem Remote-Wearable stammen.

Wenn Geräteimplementierungen Kamera- oder Mikrofondaten von einem Remote-Wearable-Gerät empfangen und auf die Daten außerhalb von Android-Betriebssystem, einer Sandbox-Implementierung oder einer von WearableSensingManager entwickelten Sandbox-Funktion in unverschlüsselter Form zugegriffen wird, gilt Folgendes:

• [C-1-1] MUSS dem Remote-Wearable-Gerät signalisieren, dort einen zusätzlichen Indikator anzuzeigen.

Wenn Geräte die Möglichkeit bieten, mit einer Anwendung für digitale Assistenten ohne das zugewiesene Keyword zu interagieren (entweder durch die Verarbeitung allgemeiner Nutzeranfragen oder die Analyse der Nutzerpräsenz über die Kamera), gilt Folgendes:

• [C-2-1] MUSS dafür sorgen, dass eine solche Implementierung von einem Paket mit der Rolle android.app.role.ASSISTANT bereitgestellt wird.

• [C-2-2] MUSS sicherstellen, dass bei der Implementierung die Android-APIs HotwordDetectionService und/oder VisualQueryDetectionService verwendet werden.

9.8.17. Telemetrie

Android speichert System- und App-Logs mithilfe von StatsLog-APIs. Diese Logs werden über StatsManager-APIs verwaltet, die von privilegierten Systemanwendungen verwendet werden können.

Mit StatsManager können auch Daten, die als datenschutzrelevant eingestuft werden, von Geräten mit einem datenschutzfreundlichen Mechanismus erhoben werden. Insbesondere bietet die StatsManager::query API die Möglichkeit, eingeschränkte Messwertkategorien abzufragen, die in StatsLog definiert sind.

Jede Implementierung, die eingeschränkte Messwerte von StatsManager abfragt und erhebt:

• [C-0-1] MUSS die einzige Anwendung/Implementierung auf dem Gerät sein und die Berechtigung READ_RESTRICTED_STATS haben.

• [C-0-2] MUSS Telemetriedaten und das Protokoll des Geräts nur über einen datenschutzfreundlichen Mechanismus senden. Der datenschutzfreundliche Mechanismus ist definiert als „Mechanismen, die nur eine aggregierte Analyse ermöglichen und verhindern, dass protokollierte Ereignisse oder abgeleitete Ergebnisse einzelnen Nutzern zugeordnet werden“. So wird verhindert, dass Daten auf Nutzerebene eingesehen werden können (z. B. durch die Implementierung einer Differential-Privacy-Technologie wie RAPPOR).

• [C-0-3] DARF solche Daten NICHT mit einer Nutzeridentität (z. B. Konto) auf dem Gerät verknüpfen.

• [C-0-4] DÜRFEN solche Daten NICHT an andere Betriebssystemkomponenten weitergeben, die die in diesem Abschnitt beschriebenen Anforderungen nicht erfüllen (9.8.17. Telemetrie).

• [C-0-5] MÜSSEN eine Möglichkeit für Nutzer bieten, die datenschutzfreundliche Erhebung, Verwendung und Weitergabe von Telemetriedaten zu aktivieren bzw. zu deaktivieren.

• [C-0-6] Die Implementierung MUSS dem Nutzer die Möglichkeit bieten, solche Daten zu löschen, die von der Implementierung erhoben werden, wenn die Daten in irgendeiner Form auf dem Gerät gespeichert werden. Wenn der Nutzer sich für das Löschen der Daten entschieden hat, MUSS er alle Daten entfernen, die derzeit auf dem Gerät gespeichert sind.

• [C-0-7] Die zugrunde liegende Implementierung des datenschutzfreundlichen Protokolls MUSS in einem Open-Source-Repository offengelegt werden.

• [C-0-8] In diesem Abschnitt MUSS die Richtlinie für den Daten-Egress durchgesetzt werden, um die Erfassung von Daten in eingeschränkten Messwertkategorien zu verhindern, die in StatsLog definiert sind.

9.8.18. Datenschutz bei agentischen Funktionen

9.9. Verschlüsselung der Datenspeicherung

Alle Geräte MÜSSEN die Anforderungen von Abschnitt 9.9.1 erfüllen. Geräte, die mit einem API-Level auf den Markt gekommen sind, das niedriger ist als das in diesem Dokument, sind von den Anforderungen der Abschnitte 9.9.2 und 9.9.3 ausgenommen. Stattdessen MÜSSEN sie die Anforderungen in Abschnitt 9.9 des Android-Dokuments zur Kompatibilitätsdefinition erfüllen, das dem API-Level entspricht, mit dem das Gerät auf den Markt gekommen ist.

9.9.1. Direct Boot

Geräteimplementierungen:

• [C-0-1] MUSS die APIs für den Direct Boot-Modus implementieren, auch wenn sie keine Speicherverschlüsselung unterstützen.

• [C-0-2] Die Intents ACTION_LOCKED_BOOT_COMPLETED und ACTION_USER_UNLOCKED MÜSSEN weiterhin übertragen werden, um Direct Boot-kompatiblen Apps zu signalisieren, dass die Speicherorte „Device Encrypted“ (DE) und „Credential Encrypted“ (CE) für den Nutzer verfügbar sind.

9.9.2. Verschlüsselungsanforderungen

Geräteimplementierungen:

• [C-0-1] MUSS die privaten App-Daten (/data-Partition) sowie die Partition für den freigegebenen App-Speicher (/sdcard-Partition) verschlüsseln, wenn es sich um einen permanenten, nicht entfernbaren Teil des Geräts handelt.
• [C-0-2] Die Verschlüsselung der Datenspeicherung MUSS standardmäßig aktiviert werden, wenn der Nutzer die Einrichtung abgeschlossen hat.

• [C-0-3] MUSS die oben genannte Anforderung zur Verschlüsselung der Datenspeicherung erfüllen, indem eine der folgenden beiden Verschlüsselungsmethoden implementiert wird:

  • Dateibasierte Verschlüsselung (File Based Encryption, FBE) und Metadatenverschlüsselung, wie in Abschnitt 9.9.3.1 beschrieben.
  • Verschlüsselung auf Blockebene pro Nutzer gemäß Abschnitt 9.9.3.2.

9.9.3. Verschlüsselungsmethoden

Wenn Geräteimplementierungen verschlüsselt sind, gilt Folgendes:

• [C-1-1] Das Gerät MUSS ohne Aufforderung zur Eingabe von Anmeldedaten hochfahren und Apps, die Direct Boot unterstützen, den Zugriff auf den verschlüsselten Gerätespeicher (Device Encrypted, DE) ermöglichen, nachdem die ACTION_LOCKED_BOOT_COMPLETED-Nachricht gesendet wurde.

• [C-1-2] Der Zugriff auf den verschlüsselten Speicher für Anmeldedaten (Credential Encrypted, CE) DARF erst dann gewährt werden, wenn:

  • Der Nutzer entsperrt das Gerät mit einer primären Authentifizierungsmethode (z. B. Passwort, Muster oder PIN).
  • Die ACTION_USER_UNLOCKED-Nachricht wird gesendet.

• [C-1-13] Es DÜRFEN keine Methoden zum Entsperren des CE-geschützten Speichers angeboten werden, die nicht auf den vom Nutzer angegebenen Anmeldedaten, einem registrierten Escrow-Schlüssel oder einer Implementierung zum Fortsetzen nach dem Neustart basieren, die den Anforderungen in Abschnitt 9.9.4 entspricht.

• [C-1-4] MUSS den Bootmodus mit Verifikation verwenden.

9.9.3.1. Dateibasierte Verschlüsselung mit Metadatenverschlüsselung

Wenn Geräteimplementierungen die dateibasierte Verschlüsselung mit Metadatenverschlüsselung verwenden, gilt Folgendes:

• [C-1-5] MUSS Dateiinhalte und Dateisystemmetadaten mit AES-256-XTS oder Adiantum verschlüsseln. AES-256-XTS bezieht sich auf den Advanced Encryption Standard mit einer Schlüssellänge von 256 Bit, der im XTS-Modus ausgeführt wird. Die vollständige Länge des Schlüssels beträgt 512 Bit. Adiantum bezieht sich auf Adiantum-XChaCha12-AES, wie unter https://github.com/google/adiantum beschrieben. Dateisystemmetadaten sind Daten wie Dateigrößen, Eigentümer, Modi und erweiterte Attribute (xattrs).
• [C-1-6] MUSS Dateinamen mit AES-256-CBC-CTS, AES-256-HCTR2 oder Adiantum verschlüsseln.
• [C-1-12] Wenn das Gerät AES-Befehle (Advanced Encryption Standard) hat, z. B. ARMv8-Kryptoerweiterungen auf ARM-basierten Geräten oder AES-NI auf x86-basierten Geräten, MÜSSEN die oben genannten AES-basierten Optionen für die Verschlüsselung von Dateinamen, Dateiinhalten und Dateisystemmetadaten verwendet werden, nicht Adiantum.
• [C-1-13] Es MUSS eine kryptografisch starke und nicht reversible Schlüsselableitungsfunktion (z.B. HKDF-SHA512) verwendet werden, um alle erforderlichen Unterschlüssel (z.B. Schlüssel pro Datei) aus den CE- und DE-Schlüsseln abzuleiten. „Kryptografisch stark und nicht umkehrbar“ bedeutet, dass die Funktion zur Ableitung von Schlüsseln eine Sicherheitsstärke von mindestens 256 Bit hat und sich als Pseudozufallsfunktionsfamilie über ihre Eingaben verhält.
• [C-1-14] Es DÜRFEN NICHT dieselben Schlüssel oder Unterschlüssel für die dateibasierte Verschlüsselung (File-Based Encryption, FBE) für verschiedene kryptografische Zwecke verwendet werden, z.B. sowohl für die Verschlüsselung als auch für die Schlüsselableitung oder für zwei verschiedene Verschlüsselungsalgorithmen.
• [C-1-15] MUSS dafür sorgen, dass alle nicht gelöschten Blöcke verschlüsselter Dateiinhalte im nichtflüchtigen Speicher mit Kombinationen aus Verschlüsselungsschlüssel und Initialisierungsvektor (IV) verschlüsselt wurden, die sowohl von der Datei als auch vom Offset innerhalb der Datei abhängen. Außerdem MÜSSEN alle diese Kombinationen eindeutig sein, es sei denn, die Verschlüsselung erfolgt mit Inline-Verschlüsselungshardware, die nur eine IV-Länge von 32 Bit unterstützt.
• [C-1-16] MUSS dafür sorgen, dass alle nicht gelöschten verschlüsselten Dateinamen auf dem permanenten Speicher in verschiedenen Verzeichnissen mit unterschiedlichen Kombinationen aus Verschlüsselungsschlüssel und Initialisierungsvektor (IV) verschlüsselt wurden.

• [C-1-17] MUSS dafür sorgen, dass alle verschlüsselten Dateisystem-Metadatenblöcke im nichtflüchtigen Speicher mit unterschiedlichen Kombinationen aus Verschlüsselungsschlüssel und Initialisierungsvektor (IV) verschlüsselt wurden.

• Schlüssel zum Schutz von CE- und DE-Speicherbereichen und Dateisystemmetadaten:

  • [C-1-7] MUSS kryptografisch an einen hardwaregestützten Keystore gebunden sein. Dieser Schlüsselspeicher MUSS an den Bootmodus mit Verifikation und den Hardware-Root-of-Trust des Geräts gebunden sein.
  • [C-1-8] CE-Schlüssel MÜSSEN an die Anmeldedaten für den Sperrbildschirm eines Nutzers gebunden sein.
  • [C-1-9] CE-Schlüssel MÜSSEN an ein Standardkennwort gebunden sein, wenn der Nutzer keine Anmeldedaten für den Sperrbildschirm angegeben hat.
  • [C-1-10] MUSS eindeutig sein. Das bedeutet, dass der CE- oder DE-Schlüssel eines Nutzers nicht mit dem CE- oder DE-Schlüssel eines anderen Nutzers übereinstimmen darf.
  • [C-1-11] MUSS die obligatorisch unterstützten Chiffren, Schlüssellängen und Modi verwenden.
  • [C-1-12] MUSS beim Entsperren und Sperren des Bootloaders gemäß dieser Beschreibung sicher gelöscht werden.

• Vorinstallierte wichtige Apps (z.B. Wecker, Telefon, Messenger) SOLLTEN Direct Boot unterstützen.

Das Upstream-Android Open Source-Projekt bietet eine bevorzugte Implementierung der dateibasierten Verschlüsselung basierend auf der Linux-Kernel-Verschlüsselungsfunktion „fscrypt“ und der Metadatenverschlüsselung basierend auf der Linux-Kernel-Funktion „dm-default-key“.

9.9.3.2. Blockverschlüsselung pro Nutzer

Wenn Geräteimplementierungen die Blockverschlüsselung pro Nutzer verwenden, gilt Folgendes:

• [C-1-1] MUSS die Unterstützung mehrerer Nutzer gemäß Abschnitt 9.5 ermöglichen.
• [C-1-2] Es MUSS Partitionen pro Nutzer geben, entweder mit Rohpartitionen oder logischen Volumes.
• [C-1-3] MUSS für die Verschlüsselung der zugrunde liegenden Blockgeräte eindeutige und unterschiedliche Verschlüsselungsschlüssel pro Nutzer verwenden.

• [C-1-4] MUSS AES-256-XTS für die Blockverschlüsselung der Nutzerpartitionen verwenden.

• Die Schlüssel zum Schutz der pro Nutzer auf Blockebene verschlüsselten Geräte:

  • [C-1-5] MUSS kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. Dieser Schlüsselspeicher MUSS an den Bootmodus mit Verifikation und den Hardware-Root-of-Trust des Geräts gebunden sein.
  • [C-1-6] MUSS an die Anmeldedaten für den Sperrbildschirm des entsprechenden Nutzers gebunden sein.

Die Blockverschlüsselung pro Nutzer kann mit der Funktion „dm-crypt“ des Linux-Kernels über Partitionen pro Nutzer implementiert werden.

9.9.4. Wiedergabe nach Neustart fortsetzen

Mit „Resume on Reboot“ kann der CE-Speicher aller Apps, einschließlich derer, die Direct Boot noch nicht unterstützen, nach einem durch ein OTA initiierten Neustart entsperrt werden. Mit dieser Funktion können Nutzer nach dem Neustart Benachrichtigungen von installierten Apps erhalten.

Bei der Implementierung von „Resume-on-Reboot“ muss weiterhin dafür gesorgt werden, dass es für einen Angreifer äußerst schwierig ist, die CE-verschlüsselten Daten des Nutzers wiederherzustellen, selbst wenn das Gerät eingeschaltet ist, der CE-Speicher entsperrt ist und der Nutzer das Gerät nach Erhalt eines OTA entsperrt hat. Um Insiderangriffen zu widerstehen, gehen wir auch davon aus, dass der Angreifer Zugriff auf die kryptografischen Signaturschlüssel für Broadcasts erhält.

Im Detail:

• [C-0-1] Der CE-Speicher DARF nicht einmal für den Angreifer lesbar sein, der das Gerät physisch besitzt und die folgenden Fähigkeiten und Einschränkungen hat:

  • Kann den Signaturschlüssel eines beliebigen Anbieters oder Unternehmens verwenden, um beliebige Nachrichten zu signieren.
  • Kann dazu führen, dass das Gerät ein OTA-Update empfängt.
  • Kann den Betrieb von Hardware (AP, Flash usw.) ändern, sofern unten nicht anders angegeben. Eine solche Änderung führt jedoch zu einer Verzögerung von mindestens einer Stunde und einem Neustart, bei dem der RAM-Inhalt gelöscht wird.
  • Die Funktionsweise von manipulationssicherer Hardware (z. B. Titan M) kann nicht geändert werden.
  • Der RAM des Live-Geräts kann nicht gelesen werden.
  • Die Anmeldedaten des Nutzers (PIN, Muster, Passwort) dürfen nicht abgerufen oder auf andere Weise eingegeben werden.

Eine Geräteimplementierung, die alle hier beschriebenen Anforderungen erfüllt, entspricht [C-0-1].

9.10. Geräteintegrität

Die folgenden Anforderungen sorgen für Transparenz in Bezug auf den Status der Geräteintegrität. Geräteimplementierungen:

• [C-0-1] MUSS über die System API-Methode PersistentDataBlockManager.getFlashLockState() korrekt melden, ob der Bootloader-Status das Flashen des System-Images zulässt.

• [C-0-2] MUSS den Bootmodus mit Verifikation zur Gewährleistung der Geräteintegrität unterstützen.

Wenn Geräteimplementierungen bereits ohne Unterstützung des Bootmodus mit Verifikation in einer früheren Android-Version eingeführt wurden und die Unterstützung für diese Funktion nicht durch ein Systemsoftware-Update hinzugefügt werden kann, KÖNNEN sie von der Anforderung ausgenommen werden.

Der Bootmodus mit Verifikation ist eine Funktion, die die Integrität der Gerätesoftware garantiert. Wenn Geräteimplementierungen die Funktion unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Plattform-Funktions-Flag android.software.verified_boot deklarieren.
• [C-1-2] Die Überprüfung MUSS bei jeder Boot-Sequenz durchgeführt werden.
• [C-1-3] Die Überprüfung MUSS mit einem unveränderlichen Hardwareschlüssel als Root of Trust beginnen und bis zur Systempartition reichen.
• [C-1-4] Jede Phase der Überprüfung MUSS implementiert werden, um die Integrität und Authentizität aller Bytes in der nächsten Phase zu prüfen, bevor der Code in der nächsten Phase ausgeführt wird.
• [C-1-5] MUSS Validierungsalgorithmen verwenden, die so stark sind wie die aktuellen Empfehlungen des NIST für Hash-Algorithmen (SHA-256) und Größen öffentlicher Schlüssel (RSA-2048).
• [C-1-6] Das Booten DARF NICHT abgeschlossen werden, wenn die Systemüberprüfung fehlschlägt, es sei denn, der Nutzer stimmt zu, das Booten trotzdem zu versuchen. In diesem Fall DÜRFEN die Daten aus nicht überprüften Speicherblöcken NICHT verwendet werden.
• [C-1-7] VERIFIZIERTE Partitionen auf dem Gerät DÜRFEN NICHT geändert werden, es sei denn, der Nutzer hat den Bootloader explizit entsperrt.
• [C-1-8] MUSS einen manipulationssicheren Speicher verwenden, um zu speichern, ob der Bootloader entsperrt ist. Manipulationssicherer Speicher bedeutet, dass der Bootloader erkennen kann, ob der Speicher von Android aus manipuliert wurde.
• [C-1-9] Der Nutzer MUSS während der Verwendung des Geräts aufgefordert werden, die physische Bestätigung zu geben, bevor ein Übergang vom gesperrten Bootloader-Modus zum entsperrten Bootloader-Modus zugelassen wird.
• [C-1-10] Es MUSS ein Rollback-Schutz für Partitionen implementiert werden, die von Android verwendet werden (z. B. Boot- und Systempartitionen). Außerdem MUSS ein manipulationssicherer Speicher zum Speichern der Metadaten verwendet werden, die zur Bestimmung der zulässigen Mindestversion des Betriebssystems erforderlich sind.

• [C-1-11] ALLE Nutzerdaten MÜSSEN beim Entsperren und Sperren des Bootloaders gemäß Abschnitt 9.12 sicher gelöscht werden. „Daten löschen“ (einschließlich der Partition „userdata“ und aller NVRAM-Bereiche).

• [C-1-14] Die Signatur MUSS mindestens einmal pro Bootvorgang für zugelassene Pakete überprüft werden, die in der Systemkonfiguration als require-strict-signature aufgeführt sind.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, alle APK-Dateien privilegierter Apps mit einer Vertrauenskette zu überprüfen, die auf Partitionen basiert, die durch Bootmodus mit Verifikation geschützt sind.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, alle ausführbaren Artefakte, die von einer privilegierten App von außerhalb ihrer APK-Datei geladen werden (z. B. dynamisch geladener Code oder kompilierter Code), vor der Ausführung zu überprüfen oder DRINGEND EMPFOHLEN, sie überhaupt nicht auszuführen.

• Es SOLLTE ein Rollback-Schutz für alle Komponenten mit persistenter Firmware (z.B. Modem, Kamera) implementiert werden und es SOLLTE ein manipulationssicherer Speicher zum Speichern der Metadaten verwendet werden, die zur Bestimmung der zulässigen Mindestversion verwendet werden.

Das Upstream-Open-Source-Projekt für Android bietet eine bevorzugte Implementierung dieser Funktion im Repository external/avb/, das in den Bootloader integriert werden kann, der zum Laden von Android verwendet wird.

Wenn Geräteimplementierungen die Möglichkeit haben, Dateiinhalte seitenweise zu prüfen, dann:

• [C-2-1] Unterstützung der kryptografischen Überprüfung von Dateiinhalten, ohne die gesamte Datei lesen zu müssen.

• [C-2-2] Leseanfragen für eine geschützte Datei DÜRFEN NICHT erfolgreich sein, wenn der gelesene Inhalt nicht gemäß [C-2-1] oben überprüft wurde.

• [C-2-4] MUSS für aktivierte Dateien die Dateiprüfsumme in O(1) zurückgeben.

Wenn Geräteimplementierungen bereits ohne die Möglichkeit gestartet wurden, Dateiinhalte anhand eines vertrauenswürdigen Schlüssels in einer früheren Android-Version zu überprüfen, und die Unterstützung für diese Funktion nicht mit einem Systemsoftwareupdate hinzugefügt werden kann, KÖNNEN sie von der Anforderung ausgenommen werden. Das Upstream-Open-Source-Projekt für Android bietet eine bevorzugte Implementierung dieser Funktion, die auf dem Linux-Kernel-Feature fs-verity basiert.

9.11. Schlüssel und Anmeldedaten

Mit dem Android Keystore System können App-Entwickler kryptografische Schlüssel in einem Container speichern und sie über die KeyChain API oder die Keystore API für kryptografische Vorgänge verwenden. Geräteimplementierungen:

• [C-0-1] Es MUSS möglich sein,mindestens 8.192 Schlüssel zu importieren oder zu generieren.

• [C-0-2] Die Authentifizierung auf dem Sperrbildschirm MUSS ein Zeitintervall zwischen fehlgeschlagenen Versuchen implementieren. Wenn „n“ die Anzahl der fehlgeschlagenen Versuche ist, MUSS das Zeitintervall für 9 < n < 30 mindestens 30 Sekunden betragen. Für n > 29 MUSS der Wert des Zeitintervalls mindestens 30*2^floor((n-30)/10) Sekunden oder mindestens 24 Stunden betragen, je nachdem, welcher Wert kleiner ist.

• Die Anzahl der Schlüssel, die generiert werden können, SOLLTE nicht begrenzt werden.

Wenn die Geräteimplementierung einen sicheren Sperrbildschirm unterstützt, gilt Folgendes:

• [C-1-1] Die Keystore-Implementierung MUSS durch eine isolierte Ausführungsumgebung gesichert werden.

• [C-1-3] Die Sperrbildschirm-Authentifizierung MUSS in der isolierten Ausführungsumgebung erfolgen und die Verwendung der an die Authentifizierung gebundenen Schlüssel DARF nur bei erfolgreicher Authentifizierung zugelassen werden. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Authentifizierung für den Sperrbildschirm durchführen kann. Das Upstream-Open-Source-Projekt für Android bietet die Gatekeeper Hardwareabstraktionsschicht (HAL) und Trusty, die verwendet werden können, um diese Anforderung zu erfüllen.

• [C-1-4] MUSS die Schlüsselattestierung unterstützen, bei der der Attestierungssignierschlüssel durch sichere Hardware geschützt ist und die Signierung in sicherer Hardware erfolgt. Die Attestierungssignaturschlüssel DÜRFEN NICHT als dauerhafte Geräte-IDs verwendet werden.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version eingeführt wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen durch eine isolierte Ausführungsumgebung gesicherten Schlüsselspeicher zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert das android.hardware.fingerprint-Feature, das einen durch eine isolierte Ausführungsumgebung gesicherten Schlüsselspeicher erfordert.

• [C-1-5] Der Nutzer MUSS das Zeitlimit für den Übergang vom entsperrten in den gesperrten Zustand auswählen können. Das zulässige Mindestzeitlimit beträgt 15 Sekunden. Automotive-Geräte, die den Bildschirm sperren, wenn das Infotainmentsystem ausgeschaltet oder der Nutzer gewechselt wird, DÜRFEN NICHT über die Konfiguration für das Zeitlimit für den Ruhemodus verfügen.

• [C-1-6] MUSS IKeymasterDevice 3.0 oder höher oder IKeyMintDevice Version 1 oder höher unterstützen.

9.11.1. Sicherer Sperrbildschirm, Authentifizierung und virtuelle Geräte

Die AOSP-Implementierung folgt einem mehrstufigen Authentifizierungsmodell, bei dem eine primäre Authentifizierung auf Grundlage eines Wissensfaktors entweder durch eine sekundäre starke biometrische Authentifizierung oder durch schwächere tertiäre Modalitäten unterstützt werden kann.

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, nur eine der folgenden Optionen als primäre Authentifizierungsmethode festzulegen:

  • Eine numerische PIN
  • Ein alphanumerisches Passwort
  • Ein Wischmuster auf einem Raster mit genau 3 × 3 Punkten

  Die oben genannten Authentifizierungsmethoden werden in diesem Dokument als empfohlene primäre Authentifizierungsmethoden bezeichnet.

• [C-0-1] Die Anzahl der fehlgeschlagenen primären Authentifizierungsversuche MUSS begrenzt werden.

• [C-SR-5] Es wird DRINGEND EMPFOHLEN, eine Obergrenze von 20 fehlgeschlagenen primären Authentifizierungsversuchen zu implementieren und, wenn Nutzer zustimmen und die Funktion aktivieren, nach Überschreiten der Obergrenze für fehlgeschlagene primäre Authentifizierungsversuche einen „Factory Data Reset“ (Zurücksetzen auf die Werkseinstellungen) durchzuführen.

Wenn in Geräteimplementierungen eine numerische PIN als empfohlene primäre Authentifizierungsmethode festgelegt ist, gilt Folgendes:

• [C-SR-6] Es wird DRINGEND EMPFOHLEN, dass eine PIN mindestens 6 Ziffern oder eine Entropie von 20 Bit hat.

• [C-SR-7] Es wird DRINGEND EMPFOHLEN, für eine PIN mit weniger als 6 Ziffern KEINE automatische Eingabe ohne Nutzerinteraktion zuzulassen, um die PIN-Länge nicht preiszugeben.

Wenn in Geräteimplementierungen die empfohlenen primären Authentifizierungsmethoden hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode als sichere Methode zum Sperren des Displays verwendet wird, muss die neue Authentifizierungsmethode:

• [C-2-1] MUSS die Nutzerauthentifizierungsmethode sein, die unter Nutzerauthentifizierung für die Schlüsselverwendung erforderlich beschrieben wird.

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms auf Grundlage eines bekannten Geheimnisses hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode als sichere Methode zum Sperren des Bildschirms verwendet wird:

• [C-3-1] Die Entropie der kürzesten zulässigen Länge von Eingaben MUSS größer als 10 Bit sein.

• [C-3-2] Die maximale Entropie aller möglichen Eingaben MUSS größer als 18 Bit sein.

• [C-3-3] Die neue Authentifizierungsmethode DARF KEINE der empfohlenen primären Authentifizierungsmethoden (d.h. PIN, Muster, Passwort) ersetzen, die in AOSP implementiert und bereitgestellt werden.

• [C-3-4] Die neue Authentifizierungsmethode MUSS deaktiviert werden, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie für die Passwortanforderungen über DevicePolicyManager.setRequiredPasswordComplexity() mit einer restriktiveren Komplexitätskonstante als PASSWORD_COMPLEXITY_NONE oder über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Konstante als PASSWORD_QUALITY_BIOMETRIC_WEAK festgelegt hat.

• [C-3-5] Neue Authentifizierungsmethoden MÜSSEN entweder alle 72 Stunden oder weniger auf die empfohlenen primären Authentifizierungsmethoden (d.h. PIN, Muster, Passwort) zurückgreifen ODER dem Nutzer klar mitteilen, dass einige Daten nicht gesichert werden, um den Schutz seiner Daten zu gewährleisten.

Wenn Geräteimplementierungen die empfohlenen primären Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzufügen oder ändern und eine neue Authentifizierungsmethode verwenden, die auf Biometrie basiert und als sichere Methode zum Sperren des Bildschirms gilt, muss die neue Methode:

• [C-4-1] MUSS alle in Abschnitt 7.3.10 für Klasse 1 (früher Komfort) beschriebenen Anforderungen erfüllen.

• [C-4-2] MUSS einen Fallback-Mechanismus haben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Secret basiert.

• [C-4-3] MUSS deaktiviert sein und darf nur die empfohlene primäre Authentifizierung zum Entsperren des Displays zulassen, wenn die DPC-Anwendung (Device Policy Controller) die Keyguard-Funktionsrichtlinie durch Aufrufen der Methode DevicePolicyManager.setKeyguardDisabledFeatures() mit einem der zugehörigen biometrischen Flags (z.B. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE oder KEYGUARD_DISABLE_IRIS) festgelegt hat.

Wenn die biometrischen Authentifizierungsmethoden nicht den Anforderungen für Klasse 3 (früher Stark) gemäß Abschnitt 7.3.10 entsprechen:

• [C-5-1] Die Methoden MÜSSEN deaktiviert werden, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie für die Passwortanforderungen über DevicePolicyManager.setRequiredPasswordComplexity() mit einem restriktiveren Komplexitätsbereich als PASSWORD_COMPLEXITY_LOW oder über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_BIOMETRIC_WEAK festgelegt hat.

• [C-5-2] Der Nutzer MUSS zur Eingabe der empfohlenen primären Authentifizierung (z. B. PIN, Muster oder Passwort) aufgefordert werden, wie in [C-1-7] und [C-1-8] in Abschnitt 7.3.10 beschrieben.

• [C-5-3] Die Methoden DÜRFEN NICHT als sicherer Sperrbildschirm behandelt werden und MÜSSEN die Anforderungen erfüllen, die in diesem Abschnitt unten mit C-8 beginnen.

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode auf einem physischen Token oder dem Standort basiert:

• [C-6-1] Sie MÜSSEN einen Fallback-Mechanismus haben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Secret basiert und die Anforderungen für einen sicheren Sperrbildschirm erfüllt.

• [C-6-2] Die neue Methode MUSS deaktiviert sein und nur eine der empfohlenen primären Authentifizierungsmethoden darf das Entsperren des Displays ermöglichen, wenn die DPC-App (Device Policy Controller) die Richtlinie mit einer der folgenden Optionen festgelegt hat:

  • Die Methode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS).

  • Die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_NONE.

  • Die Methode DevicePolicyManager.setRequiredPasswordComplexity() mit einem restriktiveren Komplexitäts-Bucket als PASSWORD_COMPLEXITY_NONE.

• [C-6-3] Der Nutzer MUSS mindestens alle 4 Stunden oder weniger zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster oder Passwort) aufgefordert werden. Wenn ein physisches Token die Anforderungen für TrustAgent-Implementierungen in C-X erfüllt, gelten stattdessen die in [C-9-5] definierten Zeitüberschreitungsbeschränkungen.

• [C-6-4] Die neue Methode DARF NICHT als sicherer Sperrbildschirm behandelt werden und MUSS den unten in C-8 aufgeführten Einschränkungen entsprechen.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agents enthalten, die die TrustAgentService System API implementieren, gilt Folgendes:

• [C-7-1] Es MUSS im Einstellungsmenü und auf dem Sperrbildschirm deutlich darauf hingewiesen werden, wenn die Gerätesperre verzögert wird oder das Gerät von Trust Agents entsperrt werden kann. AOSP erfüllt diese Anforderung beispielsweise, indem im Einstellungsmenü eine Textbeschreibung für die Einstellung „Automatisch sperren“ und „Ein/Aus-Taste sperrt sofort“ sowie ein eindeutiges Symbol auf dem Sperrbildschirm angezeigt werden.

• [C-7-2] MUSS alle Trust-Agent-APIs in der Klasse DevicePolicyManager respektieren und vollständig implementieren, z. B. die Konstante KEYGUARD_DISABLE_TRUST_AGENTS.

• [C-7-3] Die TrustAgentService.addEscrowToken()-Funktion DÜRFEN NICHT vollständig auf einem Gerät implementiert werden, das als primäres privates Gerät verwendet wird (z.B. ein Mobilgerät), DÜRFEN aber vollständig auf Geräteimplementierungen implementiert werden, die in der Regel gemeinsam verwendet werden (z.B. Android-Fernseher oder Automotive-Gerät).

• [C-7-4] ALLE von TrustAgentService.addEscrowToken() hinzugefügten gespeicherten Tokens MÜSSEN verschlüsselt werden.

• [C-7-5] Der Verschlüsselungsschlüssel oder das Escrow-Token dürfen NICHT auf demselben Gerät gespeichert werden, auf dem der Schlüssel verwendet wird. Beispiel: Ein auf einem Smartphone gespeicherter Schlüssel darf ein Nutzerkonto auf einem Fernseher entsperren. Bei Automotive-Geräten darf das Escrow-Token nicht auf einem Teil des Fahrzeugs gespeichert werden.

• [C-7-6] Der Nutzer MUSS über die Sicherheitsrisiken informiert werden, bevor das Escrow-Token zum Entschlüsseln des Datenspeichers aktiviert wird.

• [C-7-7] MUSS einen Fallback-Mechanismus haben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden.

• [C-7-9] Der Nutzer MUSS zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster oder Passwort) aufgefordert werden, wie in Abschnitt 7.3.10 in [C-1-7] und [C-1-8] beschrieben, es sei denn, die Sicherheit des Nutzers (z. B. Ablenkung des Fahrers) ist gefährdet.

• [C-7-10] DARF NICHT als sicherer Sperrbildschirm behandelt werden und MUSS die in C-8 unten aufgeführten Einschränkungen einhalten.

• [C-7-11] Trust Agents DÜRFEN auf primären persönlichen Geräten (z. B. Smartphones) NICHT zum Entsperren des Geräts verwendet werden. Sie können nur verwendet werden, um ein bereits entsperrtes Gerät für maximal 4 Stunden im entsperrten Zustand zu halten. Die Standardimplementierung von TrustManagerService in AOSP erfüllt diese Anforderung.

• [C-7-12] MUSS einen kryptografisch sicheren (z. B. UKEY2) Kommunikationskanal verwenden, um das Escrow-Token vom Speichergerät an das Zielgerät zu übergeben.

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms, der kein sicherer Sperrbildschirm wie oben beschrieben ist, hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode zum Entsperren des Keyguards verwendet wird:

• [C-8-1] Die neue Methode MUSS deaktiviert werden, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie zur Passwortqualität über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_NONE oder über die Methode DevicePolicyManager.setRequiredPasswordComplexity() mit einer restriktiveren Komplexitätskonstante als PASSWORD_COMPLEXITY_NONE festgelegt hat.

• [C-8-2] Sie DÜRFEN die von DevicePolicyManager.setPasswordExpirationTimeout() festgelegten Timer für den Ablauf des Passworts NICHT zurücksetzen.

• [C-8-3] Sie DÜRFEN KEINE API für die Verwendung durch Drittanbieter-Apps zum Ändern des Sperrzustands bereitstellen.

Wenn Geräteimplementierungen es Anwendungen ermöglichen, sekundäre virtuelle Displays zu erstellen, und keine zugehörigen Eingabeereignisse unterstützen, z. B. über VirtualDeviceManager, gilt Folgendes:

• [C-9-1] Diese sekundären virtuellen Displays MÜSSEN gesperrt werden, wenn das Standarddisplay des Geräts gesperrt ist, und entsperrt werden, wenn das Standarddisplay des Geräts entsperrt ist.

Wenn Geräteimplementierungen es Anwendungen ermöglichen, sekundäre virtuelle Displays zu erstellen und zugehörige Eingabeereignisse zu unterstützen, z. B. über VirtualDeviceManager, gilt Folgendes:

• [C-10-1] MUSS separate Sperrzustände pro virtuellem Gerät unterstützen

• [C-10-2] Anforderung in Android 16 entfernt.

• [C-10-3] Anforderung in Android 16 entfernt.

• [C-10-4] MÜSSEN alle Displays gesperrt werden, wenn der Nutzer eine Sperrung initiiert, auch über die für Handheld-Geräte erforderliche Benutzeroberfläche für die Sperrung (siehe Abschnitt 2.2.5[9.11/H-1-2]).

• [C-10-5] MUSS separate virtuelle Geräteinstanzen pro Nutzer haben

• [C-10-6] Das App-Streaming MUSS deaktiviert werden, wie in DevicePolicyManager.setNearbyAppStreamingPolicy angegeben.

• [C-10-7] Anforderung in Android 16 entfernt.

• [C-10-11] MUSS die Authentifizierungs-UI auf virtuellen Geräten deaktivieren, einschließlich der Eingabe des Wissensfaktors und der biometrischen Aufforderung.

• [C-10-12] Anforderung in Android 16 entfernt.

• [C-10-13] Der virtuelle Gerätesperrstatus darf NICHT als Nutzerauthentifizierungsautorisierung mit dem Android Keystore System verwendet werden. Siehe KeyGenParameterSpec.Builder.setUserAuthentication*.

• [C-10-14] MUSS eine Möglichkeit für Nutzer bieten, die gemeinsame Nutzung der Zwischenablage zwischen Geräten zu aktivieren, bevor Zwischenablagedaten zwischen physischen und virtuellen Geräten geteilt werden, wenn auf dem Gerät eine gemeinsame Zwischenablage implementiert ist.

• [C-10-15] MUSS Benachrichtigungen anzeigen, wenn auf Zwischenablagedaten zugegriffen wird, sowohl auf dem Gerät, von dem aus der Zugriff erfolgt ist, als auch auf dem Gerät, von dem die Zwischenablage stammt.

Wenn Geräteimplementierungen es dem Nutzer ermöglichen, den primären Authentifizierungs-Wissensfaktor von einem Quellgerät auf ein Zielgerät zu übertragen, z. B. für die Ersteinrichtung des Zielgeräts, gilt Folgendes:

• [C-11-1] MUSS den Wissensfaktor mit Schutzgarantien verschlüsseln, die denen ähneln, die im Whitepaper zum Thema Sicherheit zum Google Cloud Key Vault Service beschrieben sind, wenn der Wissensfaktor vom Quellgerät auf das Zielgerät übertragen wird, sodass der Wissensfaktor nicht per Remotezugriff entschlüsselt oder zum Entsperren eines der beiden Geräte per Remotezugriff verwendet werden kann.

• [C-11-2] MUSS den Nutzer auf dem Quellgerät auffordern, den Wissensfaktor des Quellgeräts zu bestätigen , bevor der Wissensfaktor auf das Zielgerät übertragen wird.

• [C-11-3] MUSS den Nutzer auf einem Zielgerät, auf dem kein primärer Wissensfaktor für die Authentifizierung festgelegt ist, auffordern, einen übertragenen Wissensfaktor auf dem Zielgerät zu bestätigen, bevor dieser Wissensfaktor als primärer Wissensfaktor für die Authentifizierung für das Zielgerät festgelegt wird und bevor Daten, die von einem Quellgerät übertragen wurden, verfügbar gemacht werden.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agents enthalten, die die TrustAgentService.grantTrust()-System-API mit dem Flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE aufrufen, gilt Folgendes:

• [C-12-1] grantTrust() MUSS nur mit dem Flag aufgerufen werden, wenn eine Verbindung zu einem physischen Gerät in der Nähe mit einem eigenen Sperrbildschirm besteht und der Nutzer seine Identität auf diesem Sperrbildschirm authentifiziert hat. Geräte in der Nähe können nach dem einmaligen Entsperren durch den Nutzer Mechanismen zur Erkennung am Handgelenk oder zur Trageerkennung verwenden, um die Nutzerauthentifizierung zu erfüllen.

• [C-12-2] Die Geräteimplementierung MUSS in den Status TrustState.TRUSTABLE versetzt werden, wenn der Bildschirm ausgeschaltet wird (z. B. durch Drücken einer Taste oder durch Zeitüberschreitung des Displays) und der TrustAgent das Vertrauen nicht widerrufen hat. AOSP erfüllt diese Anforderung.

• [C-12-3] Das Gerät DARF NUR dann vom Status TrustState.TRUSTABLE in den Status TrustState.TRUSTED wechseln, wenn der TrustAgent weiterhin Vertrauen auf Grundlage der Anforderungen in [C-12-1] gewährt.

.

• [C-12-5] Implementierungen, die auf sicherer und genauer Entfernungsmessung basieren, um die Anforderungen von [C-12-4] zu erfüllen, MÜSSEN eine der folgenden Lösungen verwenden:

  • Implementierungen mit UWB:

    • MUSS die Konformitäts-, Zertifizierungs-, Genauigkeits- und Kalibrierungsanforderungen für UWB erfüllen, die in 7.4.9 beschrieben sind.

    • Es MUSS einer der in 7.4.9 aufgeführten P-STS-Sicherheitsmodi verwendet werden.

  • Implementierungen mit WLAN NAN (Neighbor Awareness Networking):

    • MUSS die Genauigkeitsanforderungen in 2.2.1 [7.4.2.5/H-SR-1] erfüllen, die Bandbreite von 160 MHz (oder höher) verwenden und die in Präsenzkalibrierung angegebenen Schritte zur Einrichtung der Messung ausführen.

    • Es MUSS Secure LTF gemäß IEEE 802.11az verwendet werden.

Wenn Geräteimplementierungen es Anwendungen ermöglichen, sekundäre virtuelle Displays zu erstellen und zugehörige Eingabeereignisse wie über VirtualDeviceManager zu unterstützen, und die Displays nicht mit VIRTUAL_DISPLAY_FLAG_SECURE gekennzeichnet sind, gilt Folgendes:

• [C-13-8] MUSS das Starten von Aktivitäten mit dem Attribut android:canDisplayOnRemoteDevices oder den Metadaten android.activity.can_display_on_remote_devices, die auf „false“ gesetzt sind, auf dem virtuellen Gerät blockieren.

• [C-13-9] Aktivitäten, bei denen das Streaming nicht explizit aktiviert ist und die darauf hinweisen, dass sensible Inhalte angezeigt werden, einschließlich über SurfaceView#setSecure und FLAG_SECURE, DÜRFEN NICHT auf dem virtuellen Gerät gestartet werden.

Wenn Geräteimplementierungen separate Display-Energiezustände über DeviceStateManager und separate Display-Sperrzustände über KeyguardDisplayManager unterstützen, gilt Folgendes:

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, Anmeldedaten zu verwenden, die den Anforderungen in Abschnitt 9.11.1 entsprechen, oder biometrische Daten, die mindestens den in Abschnitt 7.3.10 definierten Spezifikationen der Klasse 1 entsprechen, um ein unabhängiges Entsperren über das Standarddisplay des Geräts zu ermöglichen.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, das separate Entsperren des Displays über ein definiertes Display-Zeitlimit einzuschränken.

• [C-SR-4] Es wird DRINGEND EMPFOHLEN, dem Nutzer zu erlauben, alle Displays über die Sperrfunktion des primären Mobilgeräts global zu sperren.

9.11.2. StrongBox

Mit dem Android Keystore System können App-Entwickler kryptografische Schlüssel in einem dedizierten sicheren Prozessor sowie in der oben beschriebenen isolierten Ausführungsumgebung speichern. Ein solcher dedizierter sicherer Prozessor wird als „StrongBox“ bezeichnet. Die Anforderungen C-1-3 bis C-1-11 unten definieren die Anforderungen, die ein Gerät erfüllen muss, um als StrongBox zu gelten.

Geräteimplementierungen mit einem dedizierten sicheren Prozessor:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, StrongBox zu unterstützen. StrongBox wird wahrscheinlich in einer zukünftigen Version zur Pflicht.

Wenn Geräteimplementierungen StrongBox unterstützen, gilt Folgendes:

• [C-1-1] MUSS FEATURE_STRONGBOX_KEYSTORE deklarieren.

• [C-1-2] Es MUSS eine dedizierte sichere Hardware bereitgestellt werden, die zur Unterstützung des Schlüsselspeichers und der sicheren Nutzerauthentifizierung verwendet wird. Die dedizierte sichere Hardware kann auch für andere Zwecke verwendet werden.

• [C-1-3] MUSS eine separate CPU haben, die keinen Cache, DRAM, Coprozessoren oder andere Kernressourcen mit dem Anwendungsprozessor (AP) teilt.

• [C-1-4] MUSS dafür sorgen, dass Peripheriegeräte, die mit dem AP geteilt werden, die StrongBox-Verarbeitung in keiner Weise verändern oder Informationen aus der StrongBox abrufen können. Die AP kann den Zugriff auf StrongBox deaktivieren oder blockieren.

• [C-1-5] MUSS eine interne Uhr mit angemessener Genauigkeit (+/- 10%) haben, die nicht vom AP manipuliert werden kann.

• [C-1-6] MUSS einen echten Zufallszahlengenerator haben, der gleichmäßig verteilte und unvorhersehbare Ausgaben erzeugt.

• [C-1-7] MUSS manipulationssicher sein, einschließlich Schutz vor physischem Eindringen und Glitching.

• [C-1-8] MUSS gegen Seitenkanalangriffe geschützt sein, einschließlich des Schutzes gegen das Auslesen von Informationen über Seitenkanäle wie Strom, Timing, elektromagnetische Strahlung und Wärmestrahlung.

• [C-1-9] MUSS eine sichere Speicherung haben, die für Vertraulichkeit, Integrität, Authentizität, Konsistenz und Aktualität der Inhalte sorgt. Der Speicher darf nicht gelesen oder geändert werden, es sei denn, dies ist durch die StrongBox-APIs zulässig.

So prüfen Sie die Einhaltung von [C-1-3] bis [C-1-9] in Geräteimplementierungen:

• [C-1-10] MUSS die Hardware enthalten, die gemäß dem Schutzprofil für sichere integrierte Schaltkreise BSI-CC-PP-0084-2014 oder BSI-CC-PP-0117-2022 zertifiziert ist oder von einem national akkreditierten Prüflabor bewertet wird, das eine Schwachstellenbewertung mit hohem Angriffspotenzial gemäß den Common Criteria Application of Attack Potential to Smartcards (Anwendung des Angriffspotenzials auf Smartcards gemäß den Common Criteria) durchführt.

• [C-1-11] MUSS die Firmware enthalten, die von einem national akkreditierten Prüflabor bewertet wird, das eine Sicherheitsrisikobewertung mit hohem Angriffspotenzial gemäß den Common Criteria Application of Attack Potential to Smartcards durchführt.

• [C-SR-2] Es wird DRINGEND EMPFOHLEN, die Hardware einzubeziehen, die mit einem Security Target, Evaluation Assurance Level (EAL) 5, bewertet wird, ergänzt durch AVA_VAN.5. Die EAL 5-Zertifizierung wird wahrscheinlich in einem zukünftigen Release erforderlich sein.

• [C-SR-3] Es wird DRINGEND EMPFOHLEN, einen Schutz vor Insider-Angriffen (Insider Attack Resistance, IAR) zu bieten. Das bedeutet, dass ein Insider mit Zugriff auf Firmware-Signaturschlüssel keine Firmware erstellen kann, die dazu führt, dass die StrongBox Geheimnisse preisgibt, funktionale Sicherheitsanforderungen umgeht oder auf andere Weise den Zugriff auf vertrauliche Nutzerdaten ermöglicht. Die empfohlene Methode zum Implementieren von IAR besteht darin, Firmware-Updates nur zuzulassen, wenn das Passwort des Hauptnutzers über das IAuthSecret HAL angegeben wird.

9.11.3. Identitätsnachweis

Das System für Identitätsanmeldedaten wird durch die Implementierung aller APIs im Paket android.security.identity.* definiert und erreicht. Mit diesen APIs können App-Entwickler Dokumente zur Nutzeridentität speichern und abrufen. Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, das Identity Credential System zu implementieren.

Wenn Geräteimplementierungen das Identity Credential System implementieren, gilt Folgendes:

• [C-1-1] MUSS für die Methode IdentityCredentialStore#getInstance() einen Wert zurückgeben, der nicht null ist.

• [C-1-2] Das Identity Credential System (z.B. die android.security.identity.*-APIs) MUSS mit Code implementiert werden, der mit einer vertrauenswürdigen Anwendung in einem Bereich kommuniziert, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird. Die sichere Isolation MUSS alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA.

• [C-1-3] Die für die Implementierung des Identity Credential System erforderlichen kryptografischen Vorgänge (z.B. die android.security.identity.*-APIs) MÜSSEN vollständig in der vertrauenswürdigen Anwendung ausgeführt werden und privates Schlüsselmaterial DARF die isolierte Ausführungsumgebung niemals verlassen, es sei denn, dies ist durch APIs auf höherer Ebene (z.B. die Methode createEphemeralKeyPair()) ausdrücklich erforderlich.

• [C-1-4] Die vertrauenswürdige Anwendung MUSS so implementiert werden, dass ihre Sicherheitseigenschaften nicht beeinträchtigt werden (z.B. werden Anmeldedaten nur freigegeben, wenn die Zugriffssteuerungsbedingungen erfüllt sind, MACs können nicht für beliebige Daten erstellt werden), auch wenn Android sich nicht ordnungsgemäß verhält oder kompromittiert wurde.

Das Open-Source-Projekt für Android bietet eine Referenzimplementierung einer vertrauenswürdigen Anwendung (libeic), die zur Implementierung des Identity Credential-Systems verwendet werden kann.

9.12. Löschen von Daten

Alle Geräteimplementierungen:

• [C-0-1] Nutzer MÜSSEN die Möglichkeit haben, das Gerät auf die Werkseinstellungen zurückzusetzen.
• [C-0-2] MUSS alle Daten im userdata-Dateisystem löschen, wenn ein „Zurücksetzen auf die Werkseinstellungen“ durchgeführt wird.
• [C-0-3] Die Daten MÜSSEN so gelöscht werden, dass die relevanten Branchenstandards wie NIST SP800-88 erfüllt werden, wenn ein „Zurücksetzen auf Werkseinstellungen“ durchgeführt wird.
• [C-0-4] MUSS den oben beschriebenen Vorgang zum Zurücksetzen auf die Werkseinstellungen auslösen, wenn die DevicePolicyManager.wipeData() API von der Device Policy Controller App des primären Nutzers aufgerufen wird.
• MAY bietet möglicherweise eine Option zum schnellen Löschen von Daten an, bei der nur ein logisches Löschen von Daten durchgeführt wird.

9.13. Abgesicherter Startmodus

Android bietet den abgesicherten Modus, in dem nur vorinstallierte System-Apps ausgeführt werden dürfen und alle Drittanbieter-Apps deaktiviert sind. In diesem Modus, dem sogenannten „abgesicherten Startmodus“, kann der Nutzer potenziell schädliche Drittanbieter-Apps deinstallieren.

Geräteimplementierungen:

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, den abgesicherten Boot-Modus zu implementieren.

Wenn Geräteimplementierungen den abgesicherten Bootmodus implementieren, gilt Folgendes:

• [C-1-1] Der Nutzer MUSS die Möglichkeit haben, den abgesicherten Modus so zu starten, dass er nicht durch Drittanbieter-Apps unterbrochen wird, die auf dem Gerät installiert sind. Dies gilt nicht, wenn die Drittanbieter-App ein Device Policy Controller ist und das Flag UserManager.DISALLOW_SAFE_BOOT auf „true“ gesetzt hat.

• [C-1-2] Der Nutzer MUSS die Möglichkeit haben, alle Drittanbieter-Apps im abgesicherten Modus zu deinstallieren.

• Der Nutzer SOLLTE die Möglichkeit haben, über das Bootmenü in den abgesicherten Modus zu wechseln. Der Workflow dafür sollte sich von dem eines normalen Starts unterscheiden.

9.14. Isolierung von Fahrzeugsystemen

Android Automotive-Geräte müssen Daten mit wichtigen Fahrzeugsubsystemen austauschen. Dazu wird der Fahrzeug-HAL verwendet, um Nachrichten über Fahrzeugnetzwerke wie den CAN-Bus zu senden und zu empfangen.

Der Datenaustausch kann durch die Implementierung von Sicherheitsfunktionen unter den Android-Framework-Ebenen gesichert werden, um böswillige oder unbeabsichtigte Interaktionen mit diesen Subsystemen zu verhindern.

9.15. Abopläne

„Abo-Tarife“ bezieht sich auf die Abrechnungsbeziehungsplandetails, die von einem Mobilfunkanbieter über SubscriptionManager.setSubscriptionPlans() bereitgestellt werden.

Alle Geräteimplementierungen:

• [C-0-1] MÜSSEN Abos nur an die Mobilfunkanbieter-App zurückgeben, die sie ursprünglich bereitgestellt hat.
• [C-0-2] ABOS DÜRFEN NICHT per Fernzugriff gesichert oder hochgeladen werden.
• [C-0-3] MÜSSEN Überschreibungen wie SubscriptionManager.setSubscriptionOverrideCongested() nur über die App des Mobilfunkanbieters zulassen, die derzeit gültige Abos anbietet.

9.16. Migration von Anwendungsdaten

Wenn Geräteimplementierungen die Möglichkeit bieten, Daten von einem Gerät auf ein anderes zu übertragen, und die kopierten Anwendungsdaten nicht auf die Daten beschränken, die vom Anwendungsentwickler im Manifest über das Attribut android:fullBackupContent konfiguriert wurden, gilt Folgendes:

• [C-1-1] Es DÜRFEN KEINE Übertragungen von Anwendungsdaten von Geräten initiiert werden, auf denen der Nutzer keine primäre Authentifizierung wie in 9.11.1 Sicherer Sperrbildschirm und Authentifizierung beschrieben festgelegt hat.
• [C-1-2] Die primäre Authentifizierung auf dem Quellgerät MUSS sicher bestätigt werden und die Nutzerabsicht, die Daten auf dem Quellgerät zu kopieren, MUSS bestätigt werden, bevor Daten übertragen werden.
• [C-1-3] MUSS die Sicherheitsschlüsselattestierung verwenden, um sicherzustellen, dass sowohl das Quellgerät als auch das Zielgerät bei der Migration von Gerät zu Gerät legitime Android-Geräte sind und einen gesperrten Bootloader haben.
• [C-1-4] Anwendungsdaten DÜRFEN NUR auf dasselbe Zielgerät mit demselben Paketnamen UND Signaturzertifikat migriert werden.

• [C-1-5] Es MUSS im Einstellungsmenü angezeigt werden, dass Daten vom Quellgerät durch eine Datenmigration von Gerät zu Gerät migriert wurden. Ein Nutzer SOLLTE diese Kennzeichnung NICHT entfernen können.

9.17. Android Virtualization-Framework

Mit den APIs des Android Virtualization Framework (AVF) (android.system.virtualmachine.*) können Anwendungen virtuelle Maschinen (VMs), geschützte VMs (pVMs) und nicht geschützte VMs (non-pVMs) auf dem Gerät erstellen, die native Binärdateien als Nutzlasten laden und ausführen.

Wenn in Geräteimplementierungen FEATURE_VIRTUALIZATION_FRAMEWORK auf true festgelegt ist, gilt Folgendes:

• [C-1-1] MUSS dafür sorgen, dass android.system.virtualmachine.VirtualMachineManager.getCapabilities() einen der folgenden Werte zurückgibt:

  • CAPABILITY_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. Entwicklerbestätigung

Geräteimplementierungen, die API-Level 36.1 oder höher deklarieren:

• KANN die Unterstützung eines Entwicklerprüfdienstes umfassen, um zu bestätigen, dass Anwendungen von einem bekannten Entwickler stammen.

Geräteimplementierungen, die API-Level 36.1 oder höher deklarieren und einen Entwickler-Verifier konfigurieren, indem sie config_developerVerificationServiceProviderPackageName in config.xml definieren:

• [9.18/C-1-1] MUSS die konfigurierte android.content.pm.verify.developer.DeveloperVerifierService für jede Installation eines Anwendungspakets aufrufen, einschließlich Neuinstallationen und Updates für bestehende Anwendungen.

Geräteimplementierungen, die API-Level 36.1 oder höher deklarieren:

• MAY kann auch einen Delegaten zum Festlegen der aktiven Richtlinie konfigurieren, indem er config_developerVerificationPolicyDelegatePackageName in config.xml definiert.

Wenn ein Entwicklerprüfer konfiguriert ist, müssen Geräteimplementierungen:

• [9.18/C-2-1] Der Entwickler-Verifier oder sein konfigurierter Delegierter DÜRFEN die Installationsrichtlinie NUR wie in android.content.pm.PackageInstaller definiert festlegen.

Wenn ein Prüfer im Rahmen einer Paketinstallationssitzung aufgerufen wird, müssen Geräteimplementierungen:

• [9.18/C-3-1] Die Installation eines Anwendungspakets MUSS verhindert werden, wenn:

  • Die Installation schlägt bei der Überprüfung der Entwickleridentität fehl.

  • Die Richtlinie zur Entwicklerbestätigung für die Installationssitzung ist auf einen anderen Wert als DEVELOPER_VERIFICATION_POLICY_NONE festgelegt.

  • Es sei denn, entweder 9.18/C-3-2 oder 9.18/C-3-3 gelten.

• [9.18/C-3-3] Die Installation eines Anwendungspakets DARF NICHT verhindert werden, wenn alle folgenden Bedingungen erfüllt sind:

  • Die Richtlinie ist auf DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN oder DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN festgelegt.

  • Die Überprüfung wird als unvollständig gemeldet.

  • Der Installer gibt an, dass der Nutzer die Fortsetzung der Installation explizit angefordert hat, indem er DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY gemeldet hat.

10. Softwarekompatibilitätstests

Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen. Beachten Sie jedoch, dass kein Softwaretestpaket vollständig ist. Aus diesem Grund wird Geräteimplementierern DRINGEND EMPFOHLEN, so wenige Änderungen wie möglich an der Referenz- und bevorzugten Implementierung von Android vorzunehmen, die im Open-Source-Projekt für Android verfügbar ist. So wird das Risiko minimiert, dass Fehler eingeführt werden, die Inkompatibilitäten verursachen, die eine Überarbeitung und potenzielle Geräteupdates erfordern.

10.1. Compatibility Test Suite

Geräteimplementierungen:

• [C-0-1] MUSS die Android Compatibility Test Suite (CTS) bestehen, die im Android Open Source Project verfügbar ist. Dabei muss die endgültige Software auf dem Gerät verwendet werden, die ausgeliefert wird.

• [C-0-2] MUSS für Kompatibilität sorgen, wenn es Unklarheiten im CTS gibt und bei allen Reimplementierungen von Teilen des Referenzquellcodes.

Der CTS ist für die Ausführung auf einem echten Gerät konzipiert. Wie jede Software kann auch das CTS Fehler enthalten. Das CTS wird unabhängig von dieser Kompatibilitätsdefinition versioniert und es können mehrere Revisionen des CTS für Android 17 veröffentlicht werden.

Geräteimplementierungen:

• [C-0-3] MUSS die neueste CTS-Version bestehen, die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbar ist.

• Sollte die Referenzimplementierung im Android Open Source-Baum so weit wie möglich verwenden.

10.2. CTS‑Prüfung

Der CTS-Verifier ist in der Compatibility Test Suite enthalten und soll von einem menschlichen Bediener ausgeführt werden, um Funktionen zu testen, die nicht von einem automatisierten System getestet werden können, z. B. die korrekte Funktion einer Kamera und von Sensoren.

Geräteimplementierungen:

• [C-0-1] ALLE relevanten Fälle im CTS-Verifier MÜSSEN korrekt ausgeführt werden.

Der CTS-Verifier enthält Tests für viele Arten von Hardware, einschließlich einiger optionaler Hardware.

Geräteimplementierungen:

• [C-0-2] MÜSSEN alle Tests für die Hardware bestehen, die sie enthalten. Wenn ein Gerät beispielsweise einen Beschleunigungsmesser hat, MUSS es den Beschleunigungsmesser-Testfall im CTS Verifier korrekt ausführen.

Testläufe für Funktionen, die in diesem Kompatibilitätsdefinitionsdokument als optional gekennzeichnet sind, KÖNNEN übersprungen oder ausgelassen werden.

• [C-0-2] Auf jedem Gerät und in jedem Build MUSS der CTS‑Verifier wie oben beschrieben korrekt ausgeführt werden. Da viele Builds jedoch sehr ähnlich sind, wird von Geräteimplementierern nicht erwartet, dass sie den CTS-Verifier explizit für Builds ausführen, die sich nur in unwesentlichen Punkten unterscheiden. Insbesondere Geräteimplementierungen, die sich von einer Implementierung, die den CTS-Verifier bestanden hat, nur durch die enthaltenen Sprachen, das Branding usw. unterscheiden, DÜRFEN den CTS-Verifier-Test auslassen.

11. Aktualisierbare Software

• [C-0-1] Geräteimplementierungen MÜSSEN einen Mechanismus zum Ersetzen der gesamten Systemsoftware enthalten. Der Mechanismus muss keine „Live“-Upgrades durchführen. Das heißt, ein Neustart des Geräts KANN erforderlich sein. Es kann jede Methode verwendet werden, sofern damit die gesamte auf dem Gerät vorinstallierte Software ersetzt werden kann. Diese Anforderung kann beispielsweise auf folgende Weise erfüllt werden:

  • „Over-the-Air“-Downloads (OTA) mit Offline-Update über Neustart.
  • „Tethered“-Updates über USB von einem Host-PC.
  • „Offline“-Updates über einen Neustart und ein Update über eine Datei auf einem Wechselspeicher.

• [C-0-2] Der verwendete Aktualisierungsmechanismus MUSS Aktualisierungen ohne Löschen von Nutzerdaten unterstützen. Das heißt, der Aktualisierungsmechanismus MUSS private Anwendungsdaten und weitergegebene Anwendungsdaten beibehalten. Die Upstream-Android-Software enthält einen Aktualisierungsmechanismus, der diese Anforderung erfüllt.

• [C-0-3] Das gesamte Update MUSS signiert sein und der Update-Mechanismus auf dem Gerät MUSS das Update und die Signatur anhand eines auf dem Gerät gespeicherten öffentlichen Schlüssels überprüfen.

• [C-SR-1] Es wird DRINGEND EMPFOHLEN, den Hash des Updates mit SHA-256 zu erstellen und den Hash mit dem öffentlichen Schlüssel mit ECDSA NIST P-256 zu validieren.

Wenn die Geräteimplementierung die Unterstützung einer Datenverbindung ohne Volumenbegrenzung wie 802.11 oder Bluetooth PAN (Personal Area Network) umfasst, gilt Folgendes:

• [C-1-1] MUSS OTA-Downloads mit Offline-Update über Neustart unterstützen.

Geräteimplementierungen SOLLTEN prüfen, ob das System-Image nach einem OTA binär mit dem erwarteten Ergebnis identisch ist. Die blockbasierte OTA-Implementierung im Upstream-Open-Source-Projekt für Android, die seit Android 5.1 hinzugefügt wurde, erfüllt diese Anforderung.

Außerdem SOLLTEN Geräteimplementierungen A/B-Systemupdates unterstützen. In AOSP wird diese Funktion mit dem Boot Control HAL implementiert.

Wenn nach der Veröffentlichung einer Geräteimplementierung, aber innerhalb ihrer angemessenen Produktlebensdauer, die in Absprache mit dem Android-Kompatibilitätsteam festgelegt wird, ein Fehler gefunden wird, der die Kompatibilität von Drittanbieteranwendungen beeinträchtigt, gilt Folgendes:

• [C-2-1] Der Geräteimplementierer MUSS den Fehler über ein Softwareupdate beheben, das gemäß dem gerade beschriebenen Mechanismus angewendet werden kann.

Android enthält Funktionen, mit denen die Geräteinhaber-App (falls vorhanden) die Installation von Systemupdates steuern kann. Wenn das Systemupdate-Subsystem für Geräte „android.software.device_admin“ meldet, gilt Folgendes:

• [C-3-1] MUSS das in der Klasse SystemUpdatePolicy beschriebene Verhalten implementieren.

12. Änderungsprotokoll des Dokuments

Ab Android 16 gibt es kein separat gepflegtes Changelog mehr. Alle Änderungen gegenüber der vorherigen Version sind in diesem Dokument hervorgehoben.

13. Kontakt

Sie können dem android-compatibility-Forum beitreten und um Klarstellungen bitten oder Probleme ansprechen, die Ihrer Meinung nach nicht im Dokument behandelt werden.