Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Kompatibilitätsdefinition für Android 11

1. Einführung

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

Die Verwendung von „MUSS“, „MÜSSEN“, „DARF NICHT“, „DÜRFEN NICHT“, „DARF“, „DÜRFEN“, „SOLLTE“, „SOLLTEN“, „SOLLTE NICHT“, „SOLLTEN NICHT“, „EMPFOHLEN“ sowie „KANN“ und „KÖNNEN“ folgt dem IETF-Standard RFC2119.

In diesem Dokument bezeichnet ein „Geräteimplementierer“ oder „Implementierer“ eine Person oder Organisation, die eine Hardware-/Softwarelösung mit Android 11 entwickelt. Eine „Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte Hardware-/Softwarelösung.

Damit Geräteimplementierungen als mit Android 11 kompatibel gelten, MÜSSEN sie die in dieser Kompatibilitätsdefinition enthaltenen Anforderungen erfüllen, einschließlich aller Dokumente, die per Verweis aufgenommen wurden.

Wenn diese Definition oder die in Abschnitt 10 beschriebenen Softwaretests nicht eindeutig, mehrdeutig oder unvollständig sind, liegt es in der Verantwortung des Geräteherstellers, 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 im Android Open Source Project 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 ausgetauscht 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 enthalten 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.
Anforderungen, die DRINGEND EMPFOHLEN werden, 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 Watch-Implementierung
- Tab: Android-Tablet-Implementierung
Bedingungs-ID
- Wenn die Anforderung bedingungslos ist, wird diese ID auf 0 gesetzt.
- Wenn die Anforderung bedingt ist, wird für die erste Bedingung „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-ID in Abschnitt 2 beginnt mit der entsprechenden 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 Android Open Source Project bietet zwar einen Software-Stack, der für eine Vielzahl von Gerätetypen und Formfaktoren verwendet werden kann, aber 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 jeden Gerätetyp 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 an Handheld-Geräte

Ein Android-Handheldgerät ist ein Android-Gerät, das 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 Bildschirmgröße muss zwischen 3,3 Zoll (oder 2,5 Zoll für Geräte, die mit einem API‑Level vor Android 11 eingeführt wurden) und 8 Zoll liegen.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Implementierungen von Android-Handheld-Geräten.

Hinweis:Anforderungen, die nicht für Android-Tablets gelten, sind mit einem Sternchen (*) gekennzeichnet.

2.2.1. Hardware

Implementierungen für Handheld-Geräte:

[7.1.1.1/H-0-1] MUSS mindestens ein Android-kompatibles Display haben, das alle in diesem Dokument beschriebenen Anforderungen erfüllt.
[7.1.1.3/H-SR] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, die Anzeigegröße (Bildschirmdichte) zu ändern.

Wenn Handheld-Geräteimplementierungen die Software-Bildschirmdrehung unterstützen, gilt Folgendes:

[7.1.1.1/H-1-1]* Der logische Bildschirm, der für Drittanbieteranwendungen zur Verfügung gestellt wird, MUSS an der kurzen Kante(n) mindestens 2 Zoll und an der langen Kante(n) mindestens 2,7 Zoll groß sein. Geräte, die mit einem API-Level auf den Markt gekommen sind, das niedriger ist als das in diesem Dokument, sind von dieser Anforderung ausgenommen.

Wenn Handheld-Geräteimplementierungen die Software-Bildschirmdrehung nicht unterstützen, gilt Folgendes:

[7.1.1.1/H-2-1]* Der logische Bildschirm, der für Drittanbieteranwendungen zur Verfügung gestellt wird, MUSS an der kurzen Kante mindestens 2,7 Zoll groß sein. Geräte, die mit einem API-Level auf den Markt gekommen sind, das niedriger ist als das in diesem Dokument, sind von dieser Anforderung ausgenommen.

Wenn Handheld-Geräteimplementierungen ü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 Handheld-Geräte:

[7.1.4.6/H-0-1] MUSS über die 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-Renderstages 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 packet proto melden.
[7.1.4.6/H-1-3] MUSS konforme Werte für die GPU-RenderStages des Geräts gemäß dem render stage trace packet proto melden.
[7.1.4.6/H-1-4] MUSS einen GPU-Frequenz-Tracepoint gemäß dem Format power/gpu_frequency melden.

Implementierungen für Handheld-Geräte:

[7.1.5/H-0-1] MUSS die Unterstützung für den Legacy-Anwendungskompatibilitätsmodus enthalten, wie er vom Upstream-Android-Quellcode implementiert wird. Das heißt, Geräteimplementierungen DÜRFEN die Trigger oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert wird, NICHT ändern und das Verhalten des Kompatibilitätsmodus selbst NICHT ändern.
[7.2.1/H-0-1] MUSS Unterstützung für IME-Apps (Input Method Editor) von Drittanbietern enthalten.
[7.2.3/H-0-3] MUSS die Startseitenfunktion auf allen Android-kompatiblen Displays bereitstellen, die den Startbildschirm anzeigen.
[7.2.3/H-0-4] MUSS die Zurück-Funktion auf allen Android-kompatiblen Displays und die Funktion „Letzte“ auf mindestens einem der Android-kompatiblen Displays bereitstellen.
[7.2.3/H-0-2] MUSS sowohl das normale als auch das lange Drücken der Zurück-Funktion (KEYCODE_BACK) an die im Vordergrund ausgeführte Anwendung 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.4/H-0-1] MÜSSEN Touchscreen-Eingabe unterstützen.
[7.2.4/H-SR] Es wird DRINGEND EMPFOHLEN, die vom Nutzer ausgewählte Assistenz-App, also die App, die VoiceInteractionService implementiert, oder eine Aktivität zu starten, 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] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser einzubauen.

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

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

Wenn Implementierungen von Handheld-Gerä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 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.

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

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

Für Handheld-Geräteimplementierungen, mit denen Sprachanrufe getätigt werden können und die in getPhoneType einen anderen Wert als PHONE_TYPE_NONE angeben, gilt Folgendes:

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

Implementierungen für Handheld-Geräte:

[7.3.11/H-SR] Es wird EMPFOHLEN, den Lagesensor mit 6 Freiheitsgraden zu unterstützen.
[7.4.3/H] SOLLTE Unterstützung für Bluetooth und Bluetooth LE enthalten.

Wenn Handheld-Geräteimplementierungen eine Verbindung mit beschränktem Datenvolumen umfassen, gilt Folgendes:

[7.4.7/H-1-1] MUSS den Datensparmodus bereitstellen.

Wenn Implementierungen von Handheld-Geräten 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, das zwischen 50 und 90 Grad liegen MUSS.

Implementierungen für Handheld-Geräte:

[7.6.1/H-0-1] MUSS mindestens 4 GB nicht flüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) bieten.
[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 Handheld-Geräten nur ein 32‑Bit-ABI deklariert wird:

[7.6.1/H-1-1] Der für den Kernel und den Nutzerbereich 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 Nutzerbereich 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 Nutzerbereich 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 Handheld-Geräteimplementierungen die Unterstützung einer 64‑Bit-ABI (mit oder ohne 32‑Bit-ABI) deklarieren:

[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 Nutzerbereich 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 Kernel und Userspace verfügbarer Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicher, der zusätzlich zu dem Arbeitsspeicher bereitgestellt wird, der bereits Hardwarekomponenten wie Funk und Video zugewiesen ist, die in Geräteimplementierungen nicht der Kontrolle des Kernels unterliegen.

Wenn Handheld-Geräteimplementierungen weniger als oder gleich 1 GB Arbeitsspeicher für den Kernel und den Nutzerbereich 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 nicht flüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) haben.

Wenn Handheld-Geräteimplementierungen mehr als 1 GB Arbeitsspeicher für den Kernel und den Userspace umfassen, 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.

Implementierungen für Handheld-Geräte:

[7.6.2/H-0-1] MUSS einen gemeinsamen Speicher für Anwendungen mit einer Größe von mindestens 1 GiB bereitstellen.
[7.7.1/H] SOLLTE einen USB-Port enthalten, der den Peripheriemodus unterstützt.

Wenn Handheld-Geräteimplementierungen einen USB-Anschluss enthalten, der den Peripheriemodus unterstützt, gilt Folgendes:

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

Wenn Handheld-Geräteimplementierungen einen USB-Anschluss enthalten, der den Hostmodus unterstützt, gilt Folgendes:

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

Implementierungen für Handheld-Gerä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 android.hardware.vr.high_performance-Funktions-Flag 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 Handheld-Geräteimplementierungen einen oder mehrere USB‑C-Ports 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
		Medienwiedergabe	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
		Eingehender Anruf	Eingabe: Lange drücken Ausgabe: Anruf ablehnen
		Aktiver Anruf	Eingabe: Kurz drücken Ausgabe: Anruf beenden
		Aktiver Anruf	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 Lautstärke des Systems oder Headsets
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 den Intent ACTION_HEADSET_PLUG mit dem Extra „microphone“ auf 0 senden.

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“ auf 1 senden.

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

[7.8.2.2/H-4-1] MUSS ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_HEADSET und mit der Rolle isSink() auflisten, wenn das Feld für den USB-Audio-Terminaltyp 0x0302 ist.
[7.8.2.2/H-4-2] MUSS ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_HEADSET und mit 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 die Rolle isSource() auflisten, wenn das Feld „USB-Audio-Terminaltyp“ 0x0402 ist.
[7.8.2.2/H-4-4] MUSS ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE und mit 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] Es MUSS ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE und mit der Rolle isSink() aufgeführt werden, wenn das Feld für den 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-Audio-Terminaltyp“ 0x400 ist.
[7.8.2.2/H-SR] Es wird DRINGEND EMPFOHLEN, beim Anschließen eines USB‑C-Audio-Peripheriegeräts die Enumeration von USB-Deskriptoren durchzuführen, Terminaltypen zu identifizieren und den Intent ACTION_HEADSET_PLUG innerhalb von 1.000 Millisekunden zu übertragen.

Wenn Implementierungen für Handheld-Geräte mindestens einen haptischen Aktuator enthalten, gilt Folgendes:

[7.10/H-SR]* Es wird DRINGEND EMPFOHLEN, keinen haptischen Aktuator (Vibrator) mit exzentrischer rotierender Masse(ERM) zu verwenden.
[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-SR]* Es wird DRINGEND EMPFOHLEN, alle öffentlichen Konstanten für clear haptics in android.view.HapticFeedbackConstants zu implementieren, 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).
[7.10/H-SR]* Es wird DRINGEND EMPFOHLEN, alle öffentlichen Konstanten für clear haptics in android.os.VibrationEffect zu implementieren, nämlich (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK und EFFECT_DOUBLE_CLICK), und alle öffentlichen Konstanten für rich haptics in android.os.VibrationEffect.Composition, nämlich (PRIMITIVE_CLICK und PRIMITIVE_TICK).
[7.10/H-SR]* Es wird DRINGEND EMPFOHLEN, diese verknüpften Haptikkonstanten zu verwenden.
[7.10/H-SR]* Es wird DRINGEND EMPFOHLEN, die Qualitätsbewertung für die APIs createOneShot() und createWaveform() zu befolgen.
[7.10/H-SR]* Es wird DRINGEND EMPFOHLEN, die Funktionen für die Amplitudenskalierbarkeit zu prüfen, indem Sie android.os.Vibrator.hasAmplitudeControl() ausführen.

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

Wenn Implementierungen für Handheld-Geräte mindestens einen linearen Resonanzaktor enthalten, gilt Folgendes:

[7.10/H]* SOLLTE den haptischen Aktuator auf der X-Achse im Hochformat bewegen.

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

[7.10/H-SR]* Es wird DRINGEND EMPFOHLEN, dass die Resonanzfrequenz des LRA der X-Achse unter 200 Hz liegt.

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

[7.10/H-SR]* Es wird DRINGEND EMPFOHLEN, eine Qualitätsbewertung für haptische Konstanten durchzuführen.

2.2.2. Multimedia

Implementierungen für tragbare Geräte 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)

Implementierungen für Mobilgeräte MÜSSEN die folgenden Video-Codierungsformate unterstützen und Drittanbieteranwendungen zur Verfügung stellen:

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

Implementierungen für Mobilgeräte MÜSSEN die folgenden Videodecodierungsformate unterstützen und Drittanbieteranwendungen zur Verfügung stellen:

[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

2.2.3. Software

Implementierungen für Handheld-Gerä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 verarbeitet, wie in der SDK-Dokumentation beschrieben. Außerdem MUSS die Anwendung dem Nutzer die Möglichkeit bieten, über die DocumentsProvider API auf die Daten des Dokumentanbieters zuzugreifen.
[3.2.3.1/H-0-2]* MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorinstallieren, die durch die folgenden hier aufgeführten Anwendungs-Intents definiert sind.
[3.2.3.1/H-SR] Es wird DRINGEND EMPFOHLEN, eine E‑Mail-Anwendung vorzuladen, die die Intents ACTION_SENDTO, ACTION_SEND oder ACTION_SEND_MULTIPLE verarbeiten kann, um eine E‑Mail zu senden.
[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] 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] 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] Es wird DRINGEND EMPFOHLEN, eine Standard-Launcher-App einzubinden, die Badges für die App-Symbole anzeigt.
[3.8.2/H-SR] Es wird DRINGEND EMPFOHLEN, App-Widgets von Drittanbietern zu unterstützen.
[3.8.3/H-0-1] MÜSSEN Drittanbieter-Apps Nutzern die Benachrichtigung über wichtige Ereignisse über die API-Klassen Notification und NotificationManager ermöglichen.
[3.8.3/H-0-2] MÜSSEN Rich Notifications unterstützen.
[3.8.3/H-0-3] MÜSSEN wichtige Benachrichtigungen unterstützen.
[3.8.3/H-0-4] MUSS eine Benachrichtigungsleiste enthalten, über die der Nutzer Benachrichtigungen direkt steuern kann (z. B. antworten, Schlummern, schließen, blockieren). Dazu müssen Nutzeraktionen wie Aktionsschaltflächen oder die in AOSP implementierte Steuerleiste möglich sein.
[3.8.3/H-0-5] MUSS die über RemoteInput.Builder setChoices() bereitgestellten Optionen in der Benachrichtigungsleiste anzeigen.
[3.8.3/H-SR] Es wird DRINGEND EMPFOHLEN, die erste über RemoteInput.Builder setChoices() bereitgestellte Auswahlmöglichkeit ohne zusätzliche Nutzerinteraktion im Benachrichtigungsfeld anzuzeigen.
[3.8.3/H-SR] 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] 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] Es wird DRINGEND EMPFOHLEN, einen Assistenten auf dem Gerät zu implementieren, der die Assist-Aktion verarbeitet.

Wenn Implementierungen von Handheld-Geräten die Assist-Aktion unterstützen, gilt Folgendes:

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

Wenn Implementierungen auf Mobilgeräten conversation notifications unterstützen und sie in einem separaten Bereich von Benachrichtigungen für Benachrichtigungen und stummen Benachrichtigungen ohne Unterhaltung gruppieren, gilt Folgendes:

[3.8.4/H-1-1]* Unterhaltungsbenachrichtigungen MÜSSEN vor anderen Benachrichtigungen angezeigt werden, mit Ausnahme von Benachrichtigungen für laufende Vordergrunddienste und Benachrichtigungen mit importance:high.

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

[3.8.10/H-1-1] MÜSSEN die Sperrbildschirmbenachrichtigungen einschließlich der Medienbenachrichtigungsvorlage angezeigt werden.

Wenn Handheld-Geräte einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:

[3.9/H-1-1] MUSS die gesamte Bandbreite der in der Android SDK-Dokumentation definierten Richtlinien zur Geräteverwaltung implementieren.
[3.9/H-1-2] Die Unterstützung von verwalteten Profilen MUSS über das Feature-Flag android.software.managed_users deklariert werden, es sei denn, das Gerät ist so konfiguriert, dass es sich selbst als Gerät mit wenig RAM meldet oder dass es internen (nicht entfernbaren) Speicher als gemeinsam genutzten Speicher zuweist.

Wenn Implementierungen für tragbare Geräte Unterstützung für die APIs ControlsProviderService und Control enthalten und Drittanbieter-Apps 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 Möglichkeit für Nutzer bieten, die von Drittanbieteranwendungen über die APIs ControlsProviderService und Control registrierten Gerätesteuerungen hinzuzufügen, zu bearbeiten, auszuwählen und zu bedienen.
[3.8.16/H-1-3] MUSS innerhalb von drei Interaktionen über einen Standard-Launcher zugänglich sein.
[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.

Wenn Handheld-Geräte solche Steuerelemente nicht implementieren, gilt Folgendes:

[3.8.16/H-2-1] null MUSS 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 setzen.

Implementierungen für Handheld-Geräte:

[3.10/H-0-1] MUSS Barrierefreiheitsdienste von Drittanbietern unterstützen.
[3.10/H-SR] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorab zu laden, 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 Drittanbieter-Sprachausgabe-Engines unterstützen.
[3.11/H-SR] Es wird DRINGEND EMPFOHLEN, eine TTS-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
[3.13/H-SR] Es wird DRINGEND EMPFOHLEN, eine UI-Komponente 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 Kopplung von Begleitgeräten 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 Handheld-Geräten eine Navigationsfunktion als Geste von einer beliebigen Stelle am linken und rechten Displayrand bereitgestellt wird:

[7.2.3/H-0-1] Der Gestenbereich der Navigationsfunktion MUSS auf jeder Seite weniger als 40 dp breit sein. Der Bereich für die Geste SOLLTE standardmäßig 24 dp breit sein.

2.2.4. Leistung und Energie

[8.1/H-0-1] Gleichbleibende 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 unter 1 Frame pro Sekunde liegen.
[8.1/H-0-2] Latenz der Benutzeroberfläche. Geräteimplementierungen MÜSSEN für eine geringe 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 (Aufgabenwechsel). Wenn mehrere Anwendungen gestartet wurden, muss das erneute Starten einer bereits laufenden Anwendung weniger als 1 Sekunde dauern.

Implementierungen für Handheld-Geräte:

[8.2/H-0-1] MUSS eine sequenzielle Schreibleistung von mindestens 5 MB/s gewährleisten.
[8.2/H-0-2] MUSS 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 bieten.
[8.2/H-0-4] MUSS eine zufällige Leseleistung von mindestens 3,5 MB/s gewährleisten.

Wenn Handheld-Geräteimplementierungen 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 geben, den Energiesparmodus zu aktivieren und zu deaktivieren.
[8.3/H-1-2] MUSS eine Möglichkeit für Nutzer bieten, alle Apps anzuzeigen, die von den Stromsparmodi „App-Standby“ und „Stromsparmodus“ ausgenommen sind.

Implementierungen für Handheld-Geräte:

[8.4/H-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/H-0-2] MÜSSEN alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angegeben werden.
[8.4/H-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/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 die Leistungsaufnahme 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 Intention android.intent.action.POWER_USAGE_SUMMARY berücksichtigen und ein Einstellungsmenü anzeigen, in dem dieser Stromverbrauch zu sehen ist.

2.2.5. Sicherheitsmodell

Implementierungen für Handheld-Geräte:

[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 bereitgestellt werden, mit dem der Zugriff auf solche Apps als Reaktion auf die Absicht android.settings.ACTION_USAGE_ACCESS_SETTINGS gewährt oder widerrufen werden kann.

Implementierungen für Handheld-Geräte (* Nicht anwendbar für Tablets):

[9.11/H-0-2]* MUSS die Keystore-Implementierung mit einer isolierten Ausführungsumgebung sichern.
[9.11/H-0-3]* MÜSSEN Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie der Hash-Funktionen der MD5-, SHA1- und SHA-2-Familie enthalten, um die unterstützten Algorithmen des Android-Schlüsselspeichers in einem Bereich, der sicher vom Code isoliert ist, der auf dem Kernel und darüber ausgeführt wird, richtig zu unterstützen. Die sichere Isolierung 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 auf ARM TrustZone basierende Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer geeigneten hypervisorbasierten Isolation sind alternative Optionen.
[9.11/H-0-4]* Die Authentifizierung über die Displaysperre 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-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (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 Attestierungssignierschlüssel durch sichere Hardware geschützt ist und die Signierung in sicherer Hardware erfolgt. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten geteilt werden, damit sie nicht als Geräte-IDs verwendet werden können. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer bestimmten Artikelnummer produziert werden. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, KANN für jeweils 100.000 Einheiten ein anderer Schlüssel 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 Keystore zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert das android.hardware.fingerprint-Feature, für das ein durch eine isolierte Ausführungsumgebung gesicherter Keystore erforderlich ist.

Wenn Handheld-Geräteimplementierungen einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:

[9.11/H-1-1] Der Nutzer MUSS das kürzeste Zeitlimit für den Ruhemodus, d. h. die Übergangszeit vom entsperrten zum gesperrten Zustand, auf 15 Sekunden oder weniger festlegen können.
[9.11/H-1-2] MUSS dem Nutzer die Möglichkeit bieten, Benachrichtigungen auszublenden und alle Formen der Authentifizierung mit Ausnahme der primären Authentifizierung gemäß 9.11.1 Sicherer Sperrbildschirm zu deaktivieren. AOSP erfüllt die Anforderung als Sperrmodus.

Wenn Handheld-Geräteimplementierungen mehrere Nutzer umfassen und das Feature-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 Berechtigungen 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 Feature-Flag android.hardware.telephony deklarieren, gilt Folgendes:

[9.5/H-3-1] MUSS keine eingeschränkten Profile unterstützen, MUSS aber mit der AOSP-Implementierung von Steuerelementen übereinstimmen, mit denen andere Nutzer den Zugriff auf Sprachanrufe und SMS aktivieren /deaktivieren können.

2.2.6. Kompatibilität von Entwicklertools und ‑optionen

Implementierungen für Handheld-Geräte (* Nicht anwendbar für Tablets):

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

Implementierungen für Handheld-Geräte (* Nicht anwendbar für Tablets):

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ärdatei für Perfetto MUSS eine Protobuf-Konfiguration als Eingabe akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/H-0-4]* Die Binärdatei „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 traced“-Daemon MUSS standardmäßig aktiviert sein (Systemeigenschaft persist.traced.enable).

2.2.7 Handheld Media Performance Class

Die Definition der Media-Leistungsklasse finden Sie in Abschnitt 7.11.

2.2.7.1. Medien

Wenn Implementierungen für tragbare Geräte android.os.Build.VERSION_CODES.R für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

[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() beworben werden.
[5.1/H-1-2] MUSS 6 Instanzen von Hardware-Videodecoder-Sitzungen (AVC oder HEVC) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 720p bei 30 fps ausgeführt werden.
[5.1/H-1-3] Der Gerätehersteller MUSS über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() die maximale Anzahl von Hardware-Video-Encoder-Sitzungen angeben, die gleichzeitig in einer beliebigen Codec-Kombination ausgeführt werden können.
[5.1/H-1-4] MUSS 6 Instanzen von Hardware-Video-Encoder-Sitzungen (AVC oder HEVC) in beliebiger Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 720p bei 30 fps ausgeführt werden.
[5.1/H-1-5] MUSS die maximale Anzahl von Hardware-Video-Encoder- und ‑Decoder-Sitzungen, die gleichzeitig in einer beliebigen Codec-Kombination ausgeführt werden können, über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() angeben.
[5.1/H-1-6] MUSS 6 Instanzen von Hardware-Videodecoder- und Hardware-Videoencoder-Sitzungen (AVC oder HEVC) in beliebiger Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 720p bei 30 fps ausgeführt werden.
[5.1/H-1-7] MUSS eine Codec-Initialisierungslatenz von höchstens 65 ms für eine Videocodierungssitzung mit 1080p oder weniger für alle Hardware-Videocodecs (außer Dolby Vision-Codec) unter Last aufweisen. Die Last wird hier als gleichzeitige Transcodierungssitzung von 1080p zu 720p nur für Video mit Hardware-Video-Codecs zusammen mit der Initialisierung der 1080p-Audio-Video-Aufnahme definiert.
[5.1/H-1-8] MUSS eine Codec-Initialisierungslatenz von höchstens 50 ms für eine Audio-Codierungssitzung mit einer Bitrate von 128 kbit/s oder weniger für alle Audio-Encoder unter Last aufweisen.Die Last wird hier als gleichzeitige Transcodierungssitzung von 1080p zu 720p nur für Video mit Hardware-Video-Codecs zusammen mit der Initialisierung der Audio-Video-Aufzeichnung in 1080p definiert.
[5.3/H-1-1] Darf bei einer 1080p-Videositzung mit 30 fps unter Last nicht mehr als 1 Frame in 10 Sekunden verlieren (d.h.weniger als 0,333 % Frame-Verlust). Die Last wird als gleichzeitige Transcodierungssitzung von 1080p zu 720p nur für Video mit Hardware-Video-Codecs sowie als AAC-Audiowiedergabe mit 128 kbit/s definiert.
[5.3/H-1-2] Während einer Änderung der Videoauflösung in einer 30‑fps-Videositzung unter Last DÜRFEN NICHT mehr als 1 Frame in 10 Sekunden verloren gehen. Die Last wird als gleichzeitige Transcodierungssitzung von 1080p- zu 720p-Video mit Hardware-Videocodecs sowie als AAC-Audiowiedergabe mit 128 kBit/s definiert.
[5.6/H-1-1] Die Latenz zwischen Tippen und Ton muss bei Verwendung des OboeTester-Tests oder des CTS Verifier-Tests für die Latenz zwischen Tippen und Ton weniger als 100 Millisekunden betragen.

2.2.7.2. Kamera

Wenn Implementierungen für tragbare Geräte android.os.Build.VERSION_CODES.R für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

[7.5/H-1-1] MUSS eine primäre rückseitige Kamera mit einer Auflösung von mindestens 12 Megapixeln haben, die Videoaufnahmen mit 4K bei 30 fps unterstützt. Die primäre Rückkamera ist die Rückkamera mit der niedrigsten Kamera-ID.
[7.5/H-1-2] MUSS eine primäre nach vorn gerichtete Kamera mit einer Auflösung von mindestens 4 Megapixeln haben, die Videoaufnahmen mit 1080p bei 30 fps unterstützt. Die primäre Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
[7.5/H-1-3] MUSS die Eigenschaft „android.info.supportedHardwareLevel“ als „FULL“ oder höher für die primäre Rückkamera und als „LIMITED“ oder höher für die primäre Frontkamera unterstützen.
[7.5/H-1-4] MUSS CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME für beide primären Kameras unterstützen.
[7.5/H-1-5] Die Latenz beim JPEG-Aufnehmen mit camera2 MUSS bei einer Auflösung von 1080p weniger als 1.000 ms betragen. Dies wird mit dem CTS-Kameraleistungstest unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Primärkameras gemessen.
[7.5/H-1-6] Die Startlatenz von Camera2 (Öffnen der Kamera bis zum ersten Vorschaubild) MUSS gemäß dem CTS-Kamera-PerformanceTest unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Primärkameras unter 600 ms liegen.

2.2.7.3. Hardware

Wenn Implementierungen für Handheld-Geräte android.os.Build.VERSION_CODES.R für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

[7.1.1.1/H-1-1] MUSS eine Bildschirmauflösung von mindestens 1080p haben.
[7.1.1.3/H-1-1] MUSS eine Bildschirmdichte von mindestens 400 dpi haben.
[7.6.1/H-1-1] MUSS mindestens 6 GB physischen Arbeitsspeicher haben.

2.2.7.4. Leistung

Wenn Implementierungen für Handheld-Geräte android.os.Build.VERSION_CODES.R für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, gilt Folgendes:

[8.2/H-1-1] MUSS eine sequenzielle Schreibleistung von mindestens 100 MB/s bieten.
[8.2/H-1-2] MUSS eine zufällige Schreibleistung von mindestens 10 MB/s gewährleisten.
[8.2/H-1-3] MUSS eine sequenzielle Leseleistung von mindestens 200 MB/s gewährleisten.
[8.2/H-1-4] MUSS eine zufällige Leseleistung von mindestens 25 MB/s gewährleisten.

2.3. Anforderungen an das Fernsehgerät

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

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

Es wurde ein 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 oder einen Videoausgang wie VGA, HDMI, DisplayPort oder einen drahtlosen Anschluss für die Anzeige haben.

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

2.3.1. Hardware

Implementierungen von Fernsehgeräten:

[7.2.2/T-0-1] MUSS das Steuerkreuz unterstützen.
[7.2.3/T-0-1] MÜSSEN die Funktionen „Home“ und „Zurück“ bereitstellen.
[7.2.3/T-0-2] MUSS sowohl das normale als auch das Ereignis für langes 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-Feature-Flag deklarieren.
[7.2.7/T] SOLLTE eine Fernbedienung enthalten, ü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 von Fernsehgeräten:

[7.4.3/T-0-1] MÜSSEN Bluetooth und Bluetooth LE unterstützen.
[7.6.1/T-0-1] MUSS mindestens 4 GB nicht flüchtigen Speicher für private Anwendungsdaten (auch bekannt als „/data“-Partition) bieten.

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

[7.5.3/T-1-1] MUSS Unterstützung für eine externe Kamera enthalten, die über diesen USB-Anschluss verbunden wird, aber nicht unbedingt immer verbunden ist.

Wenn TV-Geräteimplementierungen 32 Bit haben:

[7.6.1/T-1-1] Der für den Kernel und den Nutzerbereich 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-Implementierungen sind:

[7.6.1/T-2-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.280 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

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

Implementierungen für Fernsehgeräte:

[5.2.2/T-SR] Es wird DRINGEND EMPFOHLEN, die H.264-Codierung von Videos mit einer Auflösung von 720p und 1080p bei 30 Bildern pro Sekunde zu unterstützen.

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

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

[5.3.1/T-1-1] HD 1080p mit 29,97 Bildern pro Sekunde und 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 verschachteltes MPEG‑2-Video deinterlacen und Drittanbieteranwendungen zur Verfügung stellen.

Implementierungen von Fernsehgeräten MÜSSEN die H.264-Decodierung unterstützen, wie in Abschnitt 5.3.4 beschrieben, bei Standard-Videobildraten und Auflösungen bis 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 mit 60 Bildern pro Sekunde mit dem Main10 Level 5 Main Tier-Profil unterstützen.

Implementierungen von Fernsehgeräten MÜSSEN die VP8-Decodierung gemäß Abschnitt 5.3.6 bei Standard-Videobildraten und ‑auflösungen bis 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-2-1] Es wird DRINGEND EMPFOHLEN, das UHD-Decodierungsprofil mit 60 Bildern pro Sekunde mit Profil 2 (10-Bit-Farbtiefe) zu unterstützen.

Implementierungen von Fernsehgeräten:

[5.5/T-0-1] MUSS Unterstützung für die System-Master-Lautstärke und die Lautstärkeabsenkung 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 ein externes Display unterstützen, das über HDMI angeschlossen wird, gilt Folgendes:

[5.8/T-0-1] Der HDMI-Ausgabemodus MUSS so eingestellt werden, dass die maximale Auflösung ausgewählt wird, die entweder mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz unterstützt werden kann.
[5.8/T-SR] Es wird DRINGEND EMPFOHLEN, eine vom Nutzer konfigurierbare Auswahl für die HDMI-Aktualisierungsrate bereitzustellen.
[5.8] SOLLTE die Aktualisierungsrate des HDMI-Ausgabemodus 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 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 einen über HDMI angeschlossenen externen Bildschirm, gilt Folgendes:

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

2.3.3. Software

Implementierungen von Fernsehgeräten:

[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 vorinstallieren, die durch die folgenden hier aufgeführten Anwendungs-Intents definiert sind.
[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 die Benachrichtigungen auf dem Sperrbildschirm einschließlich der Medienbenachrichtigungsvorlage angezeigt werden.

Implementierungen von Fernsehgeräten:

[3.8.14/T-SR] Es wird DRINGEND EMPFOHLEN, den Bild-im-Bild-Modus (BiB) im Multi-Window-Modus zu unterstützen.
[3.10/T-0-1] MÜSSEN Barrierefreiheitsdienste von Drittanbietern unterstützen.
[3.10/T-SR] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorab zu laden, 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.

Wenn Fernsehgeräte die Funktion android.hardware.audio.output melden, gilt Folgendes:

[3.11/T-SR] 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 Drittanbieter-Sprachausgabe-Engines unterstützen.

Implementierungen von Fernsehgeräten:

[3.12/T-0-1] MÜSSEN das TV Input Framework unterstützen.

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 unter 1 Frame pro Sekunde liegen.
[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 gewährleisten.
[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 gewährleisten.

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 geben, 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,

[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 von Fernsehgeräten:

[8.4/T-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/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 dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.

2.3.5. Sicherheitsmodell

Implementierungen für Fernsehgeräte:

[9.11/T-0-1] Die Keystore-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 MD5, SHA1 und SHA-2 haben, um die vom Android Keystore-System unterstützten Algorithmen in einem Bereich, der sicher vom Code isoliert ist, der auf dem Kernel und darüber ausgeführt wird, ordnungsgemäß zu unterstützen. Die sichere Isolierung 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 auf ARM TrustZone basierende Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer geeigneten hypervisorbasierten Isolation sind alternative Optionen.
[9.11/T-0-3] Die Sperrbildschirmauthentifizierung MUSS in der isolierten Ausführungsumgebung erfolgen und nur bei Erfolg dürfen die an die Authentifizierung gebundenen Schlüssel verwendet 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-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, die verwendet werden können, um diese Anforderung zu erfüllen.
[9.11/T-0-4] MUSS die Schlüsselattestation unterstützen, bei der der Attestierungssignierschlüssel durch sichere Hardware geschützt ist und die Signierung in sicherer Hardware erfolgt. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten geteilt werden, damit sie nicht als Geräte-IDs verwendet werden können. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer bestimmten Artikelnummer produziert werden. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, KANN für jeweils 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Wenn Fernsehgeräteimplementierungen eine sichere Displaysperre 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 zulässige Mindestzeitlimit beträgt 15 Sekunden oder weniger.

Wenn Fernsehgeräteimplementierungen mehrere Nutzer umfassen und das android.hardware.telephony-Funktionsflag nicht deklariert wird, 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 Implementierungen von Fernsehgeräten mehrere Nutzer umfassen und das Feature-Flag android.hardware.telephony deklarieren, gilt Folgendes:

[9.5/T-3-1] MUSS keine eingeschränkten 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.

2.3.6. Kompatibilität von Entwicklertools und ‑optionen

Implementierungen von Fernsehgeräten:

Perfetto
- [6.1/T-0-1] MUSS ein /system/bin/perfetto-Binärprogramm für den Shell-Nutzer bereitstellen, dessen Befehlszeile der Perfetto-Dokumentation entspricht.
- [6.1/T-0-2] Die binäre Datei von Perfetto MUSS eine Protobuf-Konfiguration als Eingabe akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/T-0-3] Die Binärdatei „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.

2.4. Smartwatch-Anforderungen

Ein Android-Smartwatch-Gerät ist eine Android-Geräteimplementierung, die am Körper getragen werden soll, z. B. am Handgelenk.

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] MÜSSEN ein Display mit einer physischen Diagonalen von 1,1 bis 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] 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] 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 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.

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 nicht flüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) bieten.
[7.6.1/W-0-2] MÜSSEN mindestens 416 MB Arbeitsspeicher für den Kernel und den Nutzerbereich zur Verfügung haben.
[7.8.1/W-0-1] MÜSSEN ein Mikrofon enthalten.
[7.8.2/W] MAY have audio output.

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] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorinstallieren, die durch die folgenden hier aufgeführten Anwendungs-Intents definiert sind.

Smartwatch-Geräteimplementierungen:

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

Für Smartwatch-Geräteimplementierungen, die das Feature-Flag android.hardware.audio.output deklarieren, gilt Folgendes:

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

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

[3.11/W-SR] 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 Drittanbieter-Sprachausgabe-Engines 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] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, alle Apps anzuzeigen, die von den Energiesparmodi „App-Standby“ und „Doze“ ausgenommen sind.
[8.3/W-SR] 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] Es MUSS ein Energieprofil pro Komponente bereitgestellt werden, 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/W-0-2] MÜSSEN alle Werte zum Stromverbrauch in Milliamperestunden (mAh) angegeben werden.
[8.4/W-0-3] Der CPU-Stromverbrauch muss für die UID jedes Prozesses angegeben werden. 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 zugeschrieben werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.

2.4.5. Sicherheitsmodell

Wenn Watch-Geräteimplementierungen mehrere Nutzer umfassen und das Feature-Flag android.hardware.telephony nicht deklarieren, 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 Feature-Flag android.hardware.telephony deklarieren, gilt Folgendes:

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

2.5. Anforderungen für die Automobilbranche

Eine 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-Geräte 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.2.3/A-0-1] MUSS die Home-Funktion bereitstellen und DARF die Zurück- und die Letzte-Funktion bereitstellen.
[7.2.3/A-0-2] MÜSSEN sowohl das normale als auch das Ereignis für langes Drücken der Zurück-Funktion (KEYCODE_BACK) an die Vordergrundanwendung 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 beim Photometer 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-0-1] KANN die Position nach dem Koppelnavigationsverfahren bestimmen, 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-2] Der über LocationManager#requestLocationUpdates() angeforderte Standort DARF NICHT auf die Karte abgestimmt werden.

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

[7.3.1/A-1-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz melden können.
[7.3.1/A-1-2] MUSS dem Koordinatensystem für Autosensoren von Android entsprechen.

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

[7.3.4/A-2-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz melden können.
[7.3.4/A-2-2] MÜSSEN auch den TYPE_GYROSCOPE_UNCALIBRATED-Sensor implementieren.
[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] 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 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 in 7.3.3/C-1-2 und 7.3.3/C-1-6 beschriebenen Kriterien für die Zeit bis zur ersten Positionsbestimmung für alle anderen Standortanfragen erfüllen (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 Mobilfunkverbindung in der Regel erfüllt, indem GNSS-Orbitvorhersagen 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.

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] Es wird DRINGEND EMPFOHLEN, das Message Access Profile (MAP) zu unterstützen.
[7.4.5/A] SOLLTE die Unterstützung für datenbasierte Mobilfunknetzverbindungen enthalten.
[7.4.5/A] MAY use the System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID constant for networks that should be available to system apps.

Eine Außenkamera ist eine Kamera, die Szenen außerhalb des Geräts aufnimmt, z. B. eine Dashcam.

Automotive-Geräteimplementierungen:

Sollte mindestens eine Kamera mit Außenansicht enthalten.

Wenn Automotive-Geräteimplementierungen eine Kamera für die Außenansicht enthalten, gilt für diese Kamera Folgendes:

[7.5/A-1-1] Kameras mit Außenansicht DÜRFEN NICHT über die Android Camera APIs zugänglich sein, es sei denn, sie entsprechen den Kernanforderungen an Kameras.
[7.5/A-SR] Es wird DRINGEND EMPFOHLEN, die Kameravorschau nicht zu drehen oder horizontal zu spiegeln.
[7.5.5/A-SR] Es wird DRINGEND EMPFOHLEN, die Kamera so auszurichten, dass die lange Seite der Kamera mit dem Horizont übereinstimmt.
[7.5/A-SR] Es wird DRINGEND EMPFOHLEN, dass sie eine Auflösung von mindestens 1,3 Megapixeln haben.
Sollte entweder Hardware mit festem Fokus oder EDOF (Extended Depth of Field) haben.
SOLLTE das Android-Synchronisierungs-Framework unterstützen.
MAY have either hardware auto-focus or software auto-focus implemented in the camera driver.

Automotive-Geräteimplementierungen:

[7.6.1/A-0-1] MUSS mindestens 4 GB nicht flüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) bieten.
[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 freigegebenen externen Speicher über einen Teil des internen, nicht entfernbaren Speichers bereitstellen, gilt Folgendes:

[7.6.1/A-SR] 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 32-Bit-Implementierungen sind:

[7.6.1/A-1-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 512 MB 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-1-2] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 608 MB betragen, wenn eine der folgenden Dichten verwendet wird:
- xhdpi oder höher auf kleinen/normalen Bildschirmen
- hdpi oder höher auf großen Bildschirmen
- mdpi oder höher auf besonders großen Bildschirmen
[7.6.1/A-1-3] Der für den Kernel und den Nutzerbereich 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
[7.6.1/A-1-4] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.344 MB 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 extragroßen Bildschirmen

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 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 Arbeitsspeicher MUSS mindestens 944 MB betragen, wenn eine der folgenden Dichten verwendet wird:
- xhdpi oder höher auf kleinen/normalen Bildschirmen
- 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 Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.280 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
[7.6.1/A-2-4] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.824 MB 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 extragroßen Bildschirmen

Automotive-Geräteimplementierungen:

[7.7.1/A] SOLLTE einen USB-Port enthalten, der den Peripheriemodus unterstützt.

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.

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 folgende Videodecodierung zu unterstützen:

[5.3/A-SR] H.265 HEVC

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] Es DARF KEINE Fahrzeugeigenschaft repliziert werden, die bereits im SDK vorhanden ist.

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] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorinstallieren, die durch die folgenden hier aufgeführten Anwendungs-Intents definiert sind.
[3.4.1/A-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API bereitstellen.
[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] 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] MUSS ein kurzes Drücken der Push-to-Talk-Taste als die vorgesehene Interaktion zum Starten der vom Nutzer ausgewählten Assistenz-App verwenden, d. h. der App, die VoiceInteractionService implementiert.

Automotive-Geräteimplementierungen:

[3.8.3.1/A-0-1] Ressourcen MÜSSEN korrekt gerendert werden, wie in der Notifications on Automotive OS SDK-Dokumentation beschrieben.
[3.8.3.1/A-0-2] MUSS für Benachrichtigungsaktionen anstelle der über Notification.Builder.addAction() bereitgestellten Optionen die Optionen „PLAY“ (Wiedergabe) und „MUTE“ (Stummschalten) anzeigen.
[3.8.3.1/A] Sollte die Verwendung von erweiterten Verwaltungsaufgaben wie Steuerelementen pro Benachrichtigungskanal einschränken. MAY use UI affordance per application to reduce controls.

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. Diese Möglichkeit DARF jedoch nur aktiviert werden, wenn keine Einschränkungen der Car UX gelten.
[3.14/A-0-5] MÜSSEN von Media-Apps festgelegte Fehlermeldungen angezeigt werden 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 In-App-Suchfunktion anbieten.
[3.14/A-0-7] Bei der Anzeige der MediaBrowser-Hierarchie MUSS die Definition von CONTENT_STYLE_BROWSABLE_HINT und CONTENT_STYLE_PLAYABLE_HINT eingehalten werden.

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

Automotive-Geräteimplementierungen:

[8.2/A-0-1] MUSS die Anzahl der Byte, die pro UID jedes Prozesses in den nichtflüchtigen Speicher gelesen und geschrieben wurden, melden, damit die Statistiken Entwicklern über die System-API android.car.storagemonitoring.CarStorageMonitoringManager zur Verfügung stehen. Das Open-Source-Projekt für Android erfüllt die Anforderung durch das uid_sys_stats-Kernelmodul.
[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 die Leistungsaufnahme 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 zu einem 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.

Automotive-Geräteimplementierungen:

[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-, SHA1- und SHA-2-Familie enthalten, um die unterstützten Algorithmen des Android-Schlüsselspeichers in einem Bereich, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird, ordnungsgemäß zu unterstützen. Die sichere Isolierung 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 auf ARM TrustZone basierende Lösung oder eine von einem Drittanbieter 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 für den Sperrbildschirm durchführen kann. Das Upstream-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, die verwendet werden können, um diese Anforderung zu erfüllen.
[9.11/A-0-4] MUSS die Schlüsselattestation unterstützen, bei der der Attestierungssignierschlüssel durch sichere Hardware geschützt ist und die Signierung auf sicherer Hardware erfolgt. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten geteilt werden, damit sie nicht als Geräte-IDs verwendet werden können. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer bestimmten Artikelnummer produziert werden. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, KANN für jeweils 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Automotive-Geräteimplementierungen:

[9.14/A-0-1] MÜSSEN Nachrichten von Android-Framework-Fahrzeugsubsystemen filtern, z.B. indem zulässige Nachrichtentypen und Nachrichtenquellen auf eine Zulassungsliste gesetzt werden.
[9.14/A-0-2] MUSS vor Denial-of-Service-Angriffen durch das Android-Framework oder Drittanbieter-Apps schützen. 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 für 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 von 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.

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) verbunden.
Das Gerät hat eine Stromquelle, die Mobilität ermöglicht, z. B. einen Akku.
Die physische Bildschirmdiagonale liegt zwischen 7 und 18 Zoll.

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

2.6.1. Hardware

Displaygröße

[7.1.1.1/Tab-0-1] MUSS ein Display mit einer Größe zwischen 7 und 18 Zoll haben.

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 Bildschirme in den Anforderungen für Handheld-Geräte aufgeführten Bildschirmdichten gelten nicht für Tablets.

USB-Peripheriemodus (Abschnitt 7.7.1)

Wenn Tablet-Geräteimplementierungen einen USB-Anschluss enthalten, der den Peripheriemodus unterstützt, gilt Folgendes:

[7.7.1/Tab] MAY implement the Android Open Accessory (AOA) API.

Virtual Reality Mode (Abschnitt 7.9.1)

Hohe Leistung bei Virtual Reality (Abschnitt 7.9.2)

Virtual-Reality-Anforderungen 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-Feature-Flag nicht deklariert wird, gilt Folgendes:

[9.5/T-1-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 Tablet-Geräteimplementierungen mehrere Nutzer umfassen und das android.hardware.telephony-Feature-Flag deklarieren, gilt Folgendes:

[9.5/T-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.

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 geladen werden, die durch die folgenden hier aufgeführten Anwendungs-Intents definiert 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-Anwendungsprogrammierschnittstelle (API) ist die Gruppe von Android-Plattformschnittstellen, 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 bereitstellen, einschließlich aller dokumentierten Verhaltensweisen, aller dokumentierten APIs, die vom Android SDK oder einer API, die im Upstream-Android-Quellcode mit dem Marker „@SystemApi“ versehen ist, bereitgestellt werden.
[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 No-Ops eingeschlossen werden, sofern dies nicht ausdrücklich in dieser Kompatibilitätsdefinition zulässig ist.
[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 prebuilts/runtime/appcompat/hiddenapi-flags.csv-Pfad 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. Dabei sind die vorhandenen öffentlichen Schlüssel in AOSP zu verwenden.

Allerdings:
- MAY: Wenn eine ausgeblendete API in der Geräteimplementierung fehlt oder anders implementiert ist, verschieben Sie sie in die Denylist oder lassen Sie sie aus allen eingeschränkten Listen (d.h. hellgrau, dunkelgrau, schwarz) weg.
- MAI: Wenn eine verborgene API noch nicht im AOSP vorhanden ist, fügen Sie sie einer der eingeschränkten Listen (hellgrau, dunkelgrau, schwarz) 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 es Erweiterungen für diese API-Ebene gibt.

Android-Geräteimplementierungen:

[C-0-1] Die AOSP-Implementierung der gemeinsam genutzten Bibliothek ExtShared und der Dienste ExtServices MUSS mit Versionen vorab geladen werden, die mindestens den für jedes API-Level zulässigen Mindestversionen entsprechen. 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 Erweiterungsversionsnummern zurückgeben, die vom AOSP definiert wurden.
[C-0-3] MUSS alle APIs unterstützen, die von den von android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) zurückgegebenen Erweiterungsversionen definiert 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 Classpath 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, indem das Attribut android:name von <uses-library> auf org.apache.http.legacy gesetzt wird.

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 nicht zur Kompilierzeit der Anwendung 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. Parameter erstellen

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

[C-0-1] Damit geräteübergreifend einheitliche, aussagekräftige Werte bereitgestellt werden, enthält die Tabelle unten zusätzliche Einschränkungen für die Formate dieser Werte, die von Geräteimplementierungen eingehalten werden MÜSSEN.

Parameter	Details
VERSION.RELEASE	Die Version des aktuell ausgeführten Android-Systems in einem für Menschen lesbaren Format. Dieses Feld MUSS einen der in 11 definierten Stringwerte enthalten.
VERSION.SDK	Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Drittanbieter-Anwendungscode zugreifen kann. Bei Android 11 MUSS dieses Feld den Ganzzahlwert 11_INT haben.
VERSION.SDK_INT	Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Drittanbieter-Anwendungscode zugreifen kann. Bei Android 11 MUSS dieses Feld den Ganzzahlwert 11_INT haben.
VERSION.INCREMENTAL	Ein vom Geräteimplementierer ausgewählter Wert, der den spezifischen Build des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format angibt. Dieser Wert DARF NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. Dieses Feld wird in der Regel verwendet, um anzugeben, welche Build-Nummer oder Quellcode-Änderungs-ID zum Generieren des Builds verwendet wurde. Der Wert dieses Felds MUSS als druckbares 7‑Bit-ASCII codiert werden können und dem regulären Ausdruck „^[^ :\/~]+$“ entsprechen.
BRETTSPIEL	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Hardware des Geräts in einem für Menschen lesbaren Format angibt. Ein möglicher Anwendungsfall für dieses Feld ist die Angabe der spezifischen Revision der Platine, die das Gerät mit Strom versorgt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
MARKE	Ein Wert, der den Markennamen des Geräts widerspiegelt, wie er den Endnutzern bekannt ist. MUSS in einem für Menschen lesbaren Format vorliegen und SOLLTE den Hersteller des Geräts oder die Unternehmensmarke angeben, unter der das Gerät vermarktet wird. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
SUPPORTED_ABIS	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität:
SUPPORTED_32_BIT_ABIS	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität:
SUPPORTED_64_BIT_ABIS	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität:
CPU_ABI	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität:
CPU_ABI2	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität:
GERÄT	Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen enthält, der die Konfiguration der Hardwarefunktionen und des Industriedesigns des Geräts identifiziert. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen. Dieser Gerätename DARF sich während der Lebensdauer des Produkts NICHT ändern.
FINGERPRINT	Ein String, der diesen Build eindeutig identifiziert. Sie SOLLTE einigermaßen für Menschen lesbar sein. Es MUSS dieser Vorlage entsprechen: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Beispiel: acme/myproduct/ mydevice:11/LMYXX/3359:userdebug/test-keys Der Fingerabdruck darf keine Leerzeichen enthalten. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können.
HARDWARE	Der Name der Hardware (aus der Kernel-Befehlszeile oder /proc). Sie SOLLTE einigermaßen für Menschen lesbar sein. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
VORTRAGENDER	Ein String, der den Host, auf dem der Build erstellt wurde, in einem für Menschen lesbaren Format eindeutig identifiziert. Es gibt keine Anforderungen an das spezifische Format dieses Felds, außer dass es NICHT „null“ oder ein leerer String („“) sein darf.
ID	Eine vom Geräteimplementierer gewählte Kennung, die sich auf eine bestimmte Version bezieht, in einem für Menschen lesbaren Format. Dieses Feld kann mit android.os.Build.VERSION.INCREMENTAL identisch sein, SOLLTE aber einen Wert enthalten, der für Endnutzer aussagekräftig genug ist, um zwischen Software-Builds zu unterscheiden. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen.
HERSTELLER	Der Markenname des Erstausrüsters (OEM) des Produkts. Für das Format dieses Felds gibt es keine Anforderungen, es darf jedoch nicht „null“ oder ein leerer String („“) sein. Dieses Feld darf sich während der Lebensdauer des Produkts nicht ändern.
MODELL	Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endnutzer bekannt ist. Das SOLLTE derselbe Name sein, unter dem das Gerät an Endnutzer vermarktet und verkauft wird. Für das Format dieses Felds gelten keine besonderen Anforderungen, es darf jedoch nicht „null“ oder ein leerer String („“) sein. Dieses Feld darf sich während der Lebensdauer des Produkts nicht ändern.
PRODUKT/FUNKTION	Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des jeweiligen Produkts (SKU) enthält. Dieser MUSS innerhalb derselben Marke eindeutig sein. MUSS für Menschen lesbar sein, ist aber nicht unbedingt für Endnutzer gedacht. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen. Dieser Produktname DARF sich während der Lebensdauer des Produkts NICHT ändern.
SERIAL	MUSS „UNKNOWN“ zurückgeben.
TAGS	Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt wurden und den Build weiter unterscheiden. Die Tags MÜSSEN als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9._-]+“ entsprechen. Außerdem MÜSSEN sie einen der Werte haben, die den drei typischen Android-Plattform-Signierungskonfigurationen entsprechen: release-keys, dev-keys und test-keys.
UHRZEIT	Ein Wert, der den Zeitstempel des Builds darstellt.
SCHREIBMASCHINE	Ein vom Geräteimplementierer ausgewählter Wert, der die Laufzeitkonfiguration des Builds angibt. Dieses Feld MUSS einen der Werte haben, die den drei typischen Android-Laufzeitkonfigurationen entsprechen: user, userdebug oder eng.
NUTZER	Ein Name oder eine Nutzer-ID des Nutzers (oder automatisierten Nutzers), der den Build generiert hat. Es gibt keine Anforderungen an das spezifische Format dieses Felds, außer dass es NICHT „null“ oder ein leerer String („“) sein darf.
VERSION.SECURITY_PATCH	Ein Wert, der das Sicherheitspatch-Level eines Builds angibt. Es MUSS darauf hinweisen, dass der Build in keiner Weise anfällig für die Probleme ist, die bis zum angegebenen öffentlichen Sicherheitsbulletin für Android beschrieben werden. Es MUSS im Format [JJJJ-MM-TT] vorliegen und einem definierten String entsprechen, der im öffentlichen Sicherheitsbulletin für Android oder im Android Security Advisory dokumentiert ist, z. B. „2015-11-01“.
VERSION.BASE_OS	Ein Wert, der den FINGERPRINT-Parameter des Builds darstellt, der ansonsten mit diesem Build identisch ist, mit Ausnahme der im Android Public Security Bulletin bereitgestellten Patches. Es MUSS den richtigen Wert zurückgeben. Wenn ein solcher Build nicht vorhanden ist, MUSS ein leerer String ("") zurückgegeben werden.
BOOTLOADER	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Bootloader-Version des Geräts in einem für Menschen lesbaren Format angibt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen.
getRadioVersion()	MUSS ein vom Gerätehersteller ausgewählter Wert sein oder zurückgeben, der die spezifische interne Funk-/Modemversion identifiziert, die im Gerät verwendet wird, in einem für Menschen lesbaren Format. Wenn ein Gerät kein internes Funkgerät/Modem hat, MUSS NULL zurückgegeben werden. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-,]+$“ entsprechen.
getSerial()	MUSS eine Hardware-Seriennummer sein oder zurückgeben, die für Geräte mit demselben MODELL und HERSTELLER verfügbar und eindeutig sein MUSS. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-,]+$“ entsprechen.

3.2.3. Intent-Kompatibilität

3.2.3.1. Häufig verwendete Anwendungs-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] 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 werden, und die Erfüllung bereitzustellen, d. h. die Erwartungen der Entwickler für diese gängigen Anwendungs-Intents zu erfüllen, wie im SDK beschrieben.

In Abschnitt 2 finden Sie 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-Implementierung von Android Open Source 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 und NICHT verhindern, dass Drittanbieteranwendungen diese Muster binden und die Kontrolle über sie übernehmen. Dieses Verbot umfasst insbesondere, aber nicht ausschließlich, das Deaktivieren der Benutzeroberfläche „Chooser“, über die Nutzer zwischen mehreren Anwendungen auswählen können, die alle dasselbe Intent-Muster verarbeiten.
[C-0-3] Geräteimplementierungen MÜSSEN eine Benutzeroberfläche bieten, über die Nutzer die Standardaktivität für Intents ändern können.
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. Ein Intent-Filtermuster, das den Daten-URI „http://www.android.com“ angibt, ist beispielsweise 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 Validierungsschritte ausgeführt werden, die in der Digital Asset Links-Spezifikation definiert sind, wie sie vom Paketmanager im Upstream-Android Open Source Project implementiert werden.
[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.
Nutzer MÜSSEN in den Einstellungen die Möglichkeit haben, App-Links für jede App einzeln zu verwalten. Das muss so aussehen:
- [C-0-6] Der Nutzer MUSS das Standardverhalten von 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 geben, bestimmte Kandidaten-URI-Intent-Filter, die erfolgreich überprüft wurden, pro Intent-Filter 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 DÜRFEN 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 übertragen, wie in der SDK-Dokumentation beschrieben. 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 Nutzern die Möglichkeit, ihre Standardanwendungen auszuwählen, z. B. für den Startbildschirm oder SMS.

Sofern sinnvoll, MUSS in Geräteimplementierungen ein ähnliches Einstellungsmenü vorhanden sein und die Geräte 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] Der android.settings.HOME_SETTINGS-Intent muss berücksichtigt werden, um ein Standardmenü für die App-Einstellungen für den Startbildschirm anzuzeigen.

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

[C-2-1] Es MUSS ein Einstellungsmenü vorhanden sein, in dem der Intent android.provider.Telephony.ACTION_CHANGE_DEFAULT aufgerufen wird, um ein Dialogfeld zum Ändern der Standard-SMS-App anzuzeigen.
[C-2-2] MUSS die Intention android.telecom.action.CHANGE_DEFAULT_DIALER berücksichtigen, um ein Dialogfeld anzuzeigen, in dem der Nutzer die Standard-Telefonie-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] 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-Anwendung 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 Standard-App-Einstellungsmenü 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 VoiceInteractionService unterstützen und mehr als eine Anwendung, die diese API verwendet, gleichzeitig installiert ist, gilt Folgendes:

[C-4-1] Der android.settings.ACTION_VOICE_INPUT_SETTINGS-Intent MUSS berücksichtigt werden, um ein Standardmenü für App-Einstellungen für die Spracheingabe und den Assistenten anzuzeigen.

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 Absicht 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 den Zugriff auf die Konfigurationen der Funktion „Bitte nicht stören“ gewähren oder verweigern kann.

Wenn Geräteimplementierungen Nutzern die Verwendung von Eingabemethoden von Drittanbietern auf dem Gerät ermöglichen, gilt Folgendes:

[C-7-1] Es MUSS einen für Nutzer zugänglichen Mechanismus geben, um als Reaktion auf den Intent android.settings.INPUT_METHOD_SETTINGS Eingabemethoden von Drittanbietern hinzuzufügen und zu konfigurieren.

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 zusammen mit den 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 unterstützen, gilt Folgendes: * [C-10-1] Sie MÜSSEN eine Benutzeroberfläche in den Einstellungen bereitstellen, 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-1] Das Gerät MUSS die Intents android.media.action.STILL_IMAGE_CAMERA und android.media.action.STILL_IMAGE_CAMERA_SECURE berücksichtigen und die Kamera im Standbildmodus starten, wie im SDK beschrieben.
[C-12-2] Das Intent android.media.action.VIDEO_CAMERA zum Starten der Kamera im Videomodus MUSS wie im SDK beschrieben berücksichtigt werden.
[C-12-3] MÜSSEN nur vorinstallierte Android-Apps die folgenden Intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE und MediaStore.ACTION_VIDEO_CAPTURE verarbeiten dürfen, 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, ihn abzulehnen), MUSS berücksichtigt werden.
[C-13-2] MUSS die Intents android.app.action.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_SUCCESSFUL, android.app.action.PROVISION_MANAGED_DEVICE, 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 unterstützen und eine Aktivität haben, die diese Intents wie im SDK hier beschrieben ausführt.

Wenn Geräteimplementierungen das Feature-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 das automatische Ausfüllen aktivieren und deaktivieren und den Standarddienst für das automatische Ausfüllen ä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] Es wird DRINGEND EMPFOHLEN, einen für Nutzer zugänglichen Mechanismus zum Gewähren oder Widerrufen des Zugriffs auf die Nutzungsstatistiken als Reaktion auf den Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS für Apps bereitzustellen, die die Berechtigung android.permission.PACKAGE_USAGE_STATS deklarieren.

Wenn Geräteimplementierungen den Zugriff auf die Nutzungsstatistiken für Apps, einschließlich vorinstallierter Apps, nicht zulassen sollen, müssen sie:

[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 Geräteimplementierungen das Feature android.hardware.audio.output melden, gilt Folgendes:

[C-SR] Es wird DRINGEND EMPFOHLEN, dass Sie 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 verarbeiten, die die Erfüllung dieser Intents wie im SDK hier beschrieben ermöglicht.

Android unterstützt interaktive Bildschirmschoner, die früher als „Dreams“ bezeichnet wurden. Mit Bildschirmschonern können Nutzer mit Anwendungen interagieren, wenn ein an eine Stromquelle angeschlossenes Gerät inaktiv ist oder in einer Dockingstation steht. Geräteimplementierungen:

Sollte Unterstützung für Bildschirmschoner enthalten und eine Einstellungsoption für Nutzer bieten, um Bildschirmschoner als Reaktion auf die Intention android.settings.DREAM_SETTINGS zu konfigurieren.

3.2.4. Aktivitäten auf sekundären/mehreren Displays

Wenn Geräteimplementierungen das Starten normaler Android-Aktivitäten auf mehreren Displays 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, die sie gestartet hat, angezeigt werden, 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 entscheidet sich dafür, Inhalte mithilfe der Activity#setShowWhenLocked() API über dem Sperrbildschirm anzuzeigen.
MUSS android.content.res.Configuration haben, das dem Display entspricht, damit es angezeigt wird, korrekt 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 bereits auf dem Display angezeigt werden, darf die Inhalte auf dem Display starten. Jeder kann eine Anzeige auf einem Display mit dem Flag android.view.Display.FLAG_PUBLIC starten.

3.3 Kompatibilität mit nativen APIs

Die Kompatibilität mit nativem Code ist eine Herausforderung. Aus diesem Grund sind Gerätehersteller:

[SR] Es wird DRINGEND EMPFOHLEN, die Implementierungen der unten aufgeführten Bibliotheken aus dem Upstream-Android Open Source Project 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 bereitgestellt wird, die für die entsprechende Gerätehardwarearchitektur kompiliert wurde. 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 Application Binary Interface (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 von der bevorzugtesten bis zur 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
[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 direkt für Drittanbieter-Apps verfügbar sind, 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] MÜSSEN Funktionssymbole für die wichtigsten Vulkan 1.0-Funktionssymbole 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-Android-Open-Source-Projekt verfügbar sind

In zukünftigen Android-Versionen werden möglicherweise zusätzliche ABIs unterstützt.

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 das ABI auf einer ARMv8-Architektur implementiert ist, entweder durch native CPU-Unterstützung oder durch Software-Emulation:
- Anleitungen für SWP und SWPB
- SETEND-Anweisung.
- CP15ISB-, CP15DSB- und CP15DMB-Barriereoperationen.
[C-2-3] MUSS die Advanced SIMD-Erweiterung (auch NEON) 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 für die Implementierung der android.webkit.WebView API den Chromium-Projekt-Build aus dem Upstream-Android-Open-Source-Projekt im Android 11-Branch verwenden.
[C-1-3] Der vom WebView gemeldete User-Agent-String MUSS folgendes 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 Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE übereinstimmen.
- Der String $(MODEL) KANN leer sein. Wenn er nicht leer ist, MUSS er denselben Wert wie android.os.Build.MODEL haben.
- „Build/$(BUILD)“ KANN ausgelassen werden. Wenn es jedoch vorhanden ist, MUSS der String „$(BUILD)“ mit dem Wert für „android.os.Build.ID“ übereinstimmen.
- Der Wert des Strings $(CHROMIUM_VER) MUSS die Version von Chromium im Upstream-Android Open Source Project 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-3] Der bereitgestellte Inhalt oder der Inhalt der Remote-URL MUSS in einem Prozess gerendert werden, der sich von der Anwendung unterscheidet, die die WebView instanziiert. Insbesondere muss der separate Renderer-Prozess über geringere Berechtigungen verfügen, als separate Nutzer-ID ausgeführt werden, 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.

Wenn Geräteimplementierungen 32 Bit haben oder das Feature-Flag android.hardware.ram.low deklarieren, sind sie von C-1-3 ausgenommen.

3.4.2. Browserkompatibilität

Wenn Geräteimplementierungen eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten, müssen sie folgende Anforderungen erfüllen:

[C-1-1] MUSS jede dieser APIs unterstützen, die mit HTML5 verknüpft sind:
[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 erwartet, dass IndexedDB in einer zukünftigen Version von Android eine erforderliche Komponente wird.
MAY ship a custom user agent string in the standalone Browser application.
Sollte in der eigenständigen Browseranwendung (unabhängig davon, ob sie auf der Upstream-WebKit-Browseranwendung oder einem Ersatz von Drittanbietern basiert) 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] Das Zulassungslistenverfahren, das die API-Verhaltenskompatibilität nur für Apps gewährleistet, die von Geräteimplementierern ausgewählt werden, DARF NICHT implementiert werden.

Das Verhalten der einzelnen API-Typen (verwaltet, Soft, nativ und Web) muss mit der bevorzugten Implementierung des Upstream-Android Open Source Project übereinstimmen. Hier einige konkrete Beispiele für die Kompatibilität:

[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. Insbesondere für Hintergrund-Apps gilt Folgendes:
- [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 der Aktualisierungen, die der App über die API-Klasse LocationManager oder die Methode WifiManager.startScan() bereitgestellt werden, ratenbegrenzen.
- [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 App-Manifest registriert werden, es sei denn, für den Broadcast-Intent ist eine "signature"- oder "signatureOrSystem"-Berechtigung protectionLevel 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-9] Geräte MÜSSEN die folgenden Sicherheitsanbieter als die ersten sieben Arraywerte der Methode Security.getProviders() in der angegebenen Reihenfolge und mit den angegebenen Namen (wie von Provider.getName() zurückgegeben) und Klassen zurückgeben, sofern die Liste nicht von der App über insertProviderAt() oder removeProvider() geändert wurde. Geräte KÖNNEN 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. Es liegt in der Verantwortung des Implementierers, für die Verhaltenskompatibilität mit dem Open-Source-Projekt für Android zu sorgen. Aus diesem Grund SOLLTEN Geräteimplementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt wichtige Teile des Systems neu zu implementieren.

3.5.1. Anwendungseinschränkung

Wenn Geräteimplementierungen einen proprietären Mechanismus zum Einschränken von Apps implementieren und dieser Mechanismus restriktiver ist als der Standby-Bucket „Selten verwendet“, gilt Folgendes:

[C-1-1] Der Nutzer MUSS die Liste der eingeschränkten Apps aufrufen können.
[C-1-2] MUSS dem Nutzer die Möglichkeit bieten, die Einschränkungen für jede App zu aktivieren bzw. zu deaktivieren.
[C-1-3] Es DÜRFEN keine Einschränkungen automatisch angewendet werden, ohne dass es Hinweise auf ein schlechtes Systemverhalten gibt. Die Einschränkungen DÜRFEN jedoch auf Apps angewendet werden, wenn ein schlechtes Systemverhalten wie blockierte Wakelocks, Dienste mit langer Laufzeit und andere Kriterien erkannt werden. Die Kriterien KÖNNEN von Geräteherstellern festgelegt werden, MÜSSEN sich aber auf die Auswirkungen der App auf den Systemzustand 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] App-Einschränkungen dürfen nicht automatisch für Apps angewendet werden, wenn ein Nutzer App-Einschränkungen manuell deaktiviert hat. Der Nutzer kann jedoch aufgefordert werden, App-Einschränkungen anzuwenden.
[C-1-5] MUSS Nutzer informieren, wenn App-Einschränkungen automatisch auf eine App angewendet werden. Diese Informationen MÜSSEN innerhalb von 24 Stunden nach Anwendung der Einschränkungen bereitgestellt werden.
[C-1-6] MUSS für ActivityManager.isBackgroundRestricted() true zurückgeben, wenn die eingeschränkte App diese API aufruft.
[C-1-7] Die oberste Vordergrund-App, die vom Nutzer explizit verwendet wird, DARF NICHT eingeschränkt werden.
[C-1-8] Einschränkungen für eine App, die zur wichtigsten Vordergrund-App wird, MÜSSEN aufgehoben werden, wenn der Nutzer explizit beginnt, die App zu verwenden, die zuvor eingeschränkt war.

3.6. API-Namespaces

Android folgt den von der Programmiersprache Java definierten Paket- und Klassen-Namespace-Konventionen. 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, dass sie:

[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 den APIs in den oben genannten Namespaces KEINE öffentlich zugänglichen Elemente (z. B. Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) oder Test- oder System-APIs hinzugefügt werden. Ein „öffentlich bereitgestelltes 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] DÜRFEN 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:

[C-0-5] DARF NICHT in einem Namespace 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 <uses-library>-Mechanismus), von der erhöhten Speichernutzung solcher APIs betroffen sind.

Wenn ein Gerätehersteller 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 er source.android.com aufrufen und gemäß den Informationen auf dieser Website mit dem Prozess zum Beitragen von Änderungen und Code beginnen.

Die oben genannten Einschränkungen entsprechen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java. In diesem Abschnitt werden diese Konventionen lediglich verstärkt und durch die Aufnahme in diese Kompatibilitätsdefinition verbindlich gemacht.

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] MUSS Dalvik-Laufzeitumgebungen so konfigurieren, dass Speicher gemäß der Upstream-Android-Plattform und wie in der folgenden Tabelle angegeben zugewiesen wird. Abschnitt 7.1.1 enthält Definitionen für Bildschirmgröße und ‑dichte.
Sollte Android RunTime (ART), die Referenz-Upstream-Implementierung des Dalvik Executable-Formats, und das Paketverwaltungssystem der Referenzimplementierung verwenden.
Fuzz-Tests SOLLTEN in verschiedenen Ausführungsmodi und auf verschiedenen Zielarchitekturen ausgeführt werden, um die Stabilität der Laufzeit zu gewährleisten. Weitere Informationen finden Sie auf der Website des Open-Source-Projekts von 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 (220 dpi)	36 MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	48 MB
	360 dpi (360dpi)	48 MB
	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)	80 MB
	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)	48 MB
	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)	80 MB
	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 Apps unterstützt, gilt Folgendes:

[C-2-1] MÜSSEN true für ShortcutManager.isRequestPinShortcutSupported() melden.
[C-2-2] Es MUSS eine Nutzeraufforderung geben, in der der Nutzer gefragt wird, bevor eine von Apps über die API-Methode ShortcutManager.requestPinShortcut() angeforderte Verknüpfung hinzugefügt wird.
[C-2-3] MUSS angepinnte Verknüpfungen sowie dynamische und statische Verknüpfungen unterstützen, wie auf der Seite „App-Verknüpfungen“ beschrieben.

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 Funktionen für Verknüpfungen unterstützen (z.B. statische und dynamische Verknüpfungen, Anpinnen von Verknüpfungen) 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() berücksichtigen. Das bedeutet, dass eine visuelle Aufforderung im Zusammenhang mit dem App-Symbol angezeigt wird, wenn der Wert auf true festgelegt ist. Wenn für alle Benachrichtigungschannels der App der Wert false festgelegt ist, wird kein App-Symbol-Badging-Schema angezeigt.
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 aber die Ressourcen und Werte verwenden, die über die in dem SDK beschriebenen Benachrichtigungs-Badges-APIs bereitgestellt werden, z. B. die Notification.Builder.setNumber()- und die Notification.Builder.setBadgeIconType()-API.

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 dem Endnutzer ein AppWidget zur Verfügung stellen können.

Wenn Geräteimplementierungen App-Widgets von Drittanbietern unterstützen, gilt Folgendes:

[C-1-1] MUSS die Unterstützung für die Plattformfunktion android.software.app_widgets deklarieren.
[C-1-2] MUSS eine integrierte Unterstützung für App-Widgets enthalten und Benutzeroberflächen-Funktionen zum Hinzufügen, Konfigurieren, Anzeigen und Entfernen von App-Widgets direkt im Launcher bereitstellen.
[C-1-3] MUSS Widgets in der Standardrastergröße 4 × 4 rendern können. Weitere Informationen finden Sie in der Android SDK-Dokumentation unter App Widget DesignGuidelines.
MAY unterstützt App-Widgets auf dem Sperrbildschirm.

Wenn Geräteimplementierungen App-Widgets von Drittanbietern und das Anpinnen von Verknüpfungen in der App unterstützen, gilt Folgendes:

[C-2-1] MÜSSEN true für AppWidgetManager.html.isRequestPinAppWidgetSupported() melden.
[C-2-2] Es MUSS eine Nutzeraufforderung geben, in der der Nutzer gefragt wird, bevor eine von Apps über die API-Methode AppWidgetManager.requestPinAppWidget() angeforderte Verknüpfung hinzugefügt wird.

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. Benachrichtigungsfeld, 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 der Geräteimplementierung 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] Die für die APIs beschriebenen Verhaltensweisen zum Aktualisieren, Entfernen und Gruppieren von Benachrichtigungen MÜSSEN eingehalten und ordnungsgemäß implementiert werden.
[C-1-4] Das vollständige Verhalten der NotificationChannel API, das im SDK dokumentiert ist, MUSS angegeben werden.
[C-1-5] Es MUSS eine Möglichkeit für Nutzer geben, Benachrichtigungen einer bestimmten Drittanbieter-App pro 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] Es wird DRINGEND EMPFOHLEN, Nutzern automatisch die Möglichkeit zu geben, Benachrichtigungen einer bestimmten Drittanbieter-App pro Kanal und App-Paketebene zu blockieren, nachdem sie diese Benachrichtigung mehrmals geschlossen haben.
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 bereitstellen.

Geräteimplementierungen:

[C-SR] Es wird DRINGEND EMPFOHLEN, conversation notifications vor Benachrichtigungen, die keine Konversationen betreffen, 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] Es wird DRINGEND EMPFOHLEN, diese Unterhaltung als Blase anzuzeigen. Die AOSP-Implementierung erfüllt diese Anforderungen mit der Standard-System-UI, den Einstellungen und dem Launcher.

Wenn Geräteimplementierungen Rich Notifications unterstützen, gilt Folgendes:

[C-2-1] MUSS die genauen Ressourcen verwenden, die über die API-Klasse Notification.Style und ihre Unterklassen für die präsentierten Ressourcenelemente bereitgestellt werden.
Jedes in der API-Klasse Notification.Style und ihren Unterklassen definierte Ressourcenelement (z.B. Symbol, Titel und Zusammenfassungstext) SOLLTE dargestellt werden.

Wenn Geräteimplementierungen Pop-up-Benachrichtigungen unterstützen, gilt Folgendes:

[C-3-1] Bei der Darstellung von Pop-up-Benachrichtigungen MUSS die Ansicht und die Ressourcen für Pop-up-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 sie vom Nutzer explizit aktiviert wurden) eine Kopie aller Benachrichtigungen erhalten können, sobald diese gesendet oder aktualisiert werden.

Geräteimplementierungen:

[C-0-1] MUSS Benachrichtigungen vollständig und zeitnah an alle installierten und vom Nutzer aktivierten Listener-Dienste senden, 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 der im API-Aufruf festgelegten Schlummerdauer einen Callback ausführen.

Wenn Geräteimplementierungen eine Möglichkeit zum Zurückstellen von Benachrichtigungen bieten, gilt Folgendes:

[C-1-1] Der Status der pausierten Benachrichtigung MUSS über die Standard-APIs wie NotificationListenerService.getSnoozedNotifications() korrekt wiedergegeben werden.
[C-1-2] MUSS diese Möglichkeit zum Schlummern von Benachrichtigungen für jede installierte Drittanbieter-App bereitstellen, sofern die Benachrichtigungen nicht von persistenten/Vordergrunddiensten stammen.

3.8.3.3. Bitte nicht stören

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

[C-1-1] WENN die Geräteimplementierung dem Nutzer die Möglichkeit bietet, Drittanbieter-Apps den Zugriff auf die Konfiguration der Bitte-nicht-stören-Richtlinie zu gewähren oder zu verweigern, MUSS sie die von Anwendungen erstellten Automatischen Regeln für „Bitte nicht stören“ neben den vom Nutzer erstellten und vordefinierten Regeln anzeigen.
[C-1-3] Die Werte von suppressedVisualEffects, die über NotificationManager.Policy übergeben werden, MÜSSEN berücksichtigt werden. Wenn in einer App die Flags SUPPRESSED_EFFECT_SCREEN_OFF oder SUPPRESSED_EFFECT_SCREEN_ON festgelegt sind, SOLLTE dem Nutzer im Menü „Bitte nicht stören“-Einstellungen angezeigt werden, dass die visuellen Effekte unterdrückt werden.

3.8.4. Suchen

Android umfasst APIs, mit denen Entwickler Suchfunktionen in ihre Anwendungen einbinden und die Daten ihrer Anwendungen in der globalen Systemsuchfunktion verfügbar machen können. Im Allgemeinen besteht diese Funktion aus einer einzigen systemweiten Benutzeroberfläche, über die Nutzer Anfragen eingeben können. Während der Eingabe werden Vorschläge angezeigt und die Ergebnisse werden präsentiert. Mit den Android-APIs können Entwickler diese Oberfläche wiederverwenden, um die Suche in ihren eigenen Apps zu ermöglichen. Außerdem können sie Ergebnisse für die gemeinsame globale Suchoberfläche bereitstellen.

Android-Geräteimplementierungen SOLLTEN eine globale Suche enthalten, eine einzelne, gemeinsame, systemweite Suchbenutzeroberfläche, die in der Lage ist, in Echtzeit Vorschläge als Reaktion auf Nutzereingaben zu machen.

Wenn Geräteimplementierungen die globale Suchoberfläche implementieren, gilt Folgendes:

[C-1-1] MUSS die APIs implementieren, die es Drittanbieteranwendungen ermöglichen, dem Suchfeld Vorschläge hinzuzufügen, wenn es im globalen Suchmodus ausgeführt wird.

Wenn keine Drittanbieter-Apps installiert sind, die die globale Suche nutzen:

Standardmäßig SOLLTEN Ergebnisse und Vorschläge der Websuchmaschine angezeigt werden.

Android umfasst auch die Assist APIs, mit denen Anwendungen festlegen können, wie viele Informationen des aktuellen Kontexts mit dem Assistant auf dem Gerät geteilt werden.

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

[C-2-1] MUSS dem Endnutzer klar anzeigen, wann der Kontext geteilt wird, entweder:
- Jedes Mal, wenn die Assistent-App auf den Kontext zugreift, wird ein weißes Licht um die Ränder des Displays angezeigt, das die Dauer und Helligkeit der Android Open Source Project-Implementierung erreicht oder überschreitet.
- Bei der vorinstallierten Assistenten-App muss eine Nutzeraufforderung weniger als zwei Navigationsschritte vom Menü mit den Standardeinstellungen für die Spracheingabe und die Assistenten-App entfernt sein. Außerdem darf der Kontext nur dann geteilt werden, wenn die Assistenten-App explizit vom Nutzer über ein Hotword oder eine Eingabe über die Navigationstaste für den Assistenten aufgerufen wird.
[C-2-2] Die in Abschnitt 7.2.3 beschriebene Interaktion zum Starten der Assist-App MUSS die vom Nutzer ausgewählte Assist-App starten, 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 sie Benachrichtigungsfenster als Overlay über anderen Apps anzeigen.

Wenn Geräteimplementierungen einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

[C-1-1] MUSS eine Möglichkeit für Nutzer bieten, zu verhindern, dass eine App Benachrichtigungsfenster mit TYPE_APPLICATION_OVERLAY anzeigt . Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente im Benachrichtigungsfeld.
[C-1-2] MUSS die Toast API unterstützen und Toasts von Anwendungen für Endnutzer auf gut sichtbare Weise anzeigen.

3.8.6. Designs

Android bietet „Themes“ als Mechanismus, um Stile auf eine gesamte Aktivität oder Anwendung anzuwenden.

Android enthält die Themenfamilien „Holo“ und „Material“ als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Holo-Thema, wie im Android SDK definiert, verwenden möchten.

Wenn Geräteimplementierungen einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

[C-1-1] DÜRFEN KEINE der für Anwendungen verfügbaren Holo-Designattribute ändern.
[C-1-2] MUSS die „Material“-Themenfamilie unterstützen und DARF KEINE der Attribute des Material-Designs 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.

Android enthält auch eine 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 Variantendesign 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 Erfahrung 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 Symbole für den Systemstatus (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 mit dem Flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR eine helle Statusleiste an.
[C-2-2] Bei Android-Geräteimplementierungen MUSS die Farbe der Systemstatussymbole in Schwarz geändert werden (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 Bildrate 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 inakzeptabel niedrigen Frameraten 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 auf Hardware, die mehrere OpenGL-Kontexte nicht unterstützt, nicht zuverlässig, 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, die Live-Hintergründe wie oben beschrieben zuverlässig ausführen 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. Dazu wird ein Miniaturbild des grafischen Zustands der Anwendung zu dem Zeitpunkt verwendet, als der Nutzer die Anwendung zuletzt verlassen hat.

Bei Geräteimplementierungen, die die Navigationsschaltfläche 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 den Navigationsschlüssel für die Funktion „Zuletzt verwendet“ 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.
[C-1-2] MUSS das Verhalten beim Anpinnen von Bildschirmen implementieren und dem Nutzer ein Einstellungsmenü zum Aktivieren und Deaktivieren der Funktion zur Verfügung stellen.
Die Markierungsfarbe, das Symbol und der Bildschirmtitel sollten in den letzten verwendeten Apps 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 Funktionstaste für „Zuletzt verwendet“ getippt wird.
SOLLTE bei langem Drücken der Taste für die Übersicht den Splitscreen-Multifenstermodus auslösen, sofern dieser unterstützt wird.
Möglicherweise werden zugehörige kürzlich angesehene Inhalte als Gruppe angezeigt, die sich gemeinsam bewegt.
[SR] 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-Editoren (Input Method Editors) von Drittanbietern.

Wenn Geräteimplementierungen Nutzern die Verwendung von Eingabemethoden von Drittanbietern auf dem Gerät ermöglichen, 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 (Vorlagen für Medienbenachrichtigungen) veraltet. Diese ermöglicht es Medienanwendungen, Wiedergabesteuerelemente zu integrieren, die auf dem Sperrbildschirm angezeigt werden.

3.8.11. Bildschirmschoner (früher „Dreams“)

Informationen zum Konfigurieren von Bildschirmschonern mit dem Settings-Intent 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,

[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] MÜSSEN Unterstützung für Folgendes enthalten:
- 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“, „Latin Extended B“, „Latin Extended C“ und „Latin Extended D“ sowie aller Glyphen im Block „Currency Symbols“ von Unicode 7.0.
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:

Sollte dem Nutzer eine Eingabemethode für diese Emojis zur Verfügung stellen.

Android unterstützt die Darstellung 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] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

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 Anwendungsfunktionen und APIs implementieren und die folgenden Anforderungen erfüllen:
[C-1-2] MUSS die von einer App in der Datei AndroidManifest.xml festgelegte android:resizeableActivity gemäß diesem SDK berücksichtigen.
[C-1-3] Der Split-Screen- 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 Multi-Window-Modi, die nicht der Bild-im-Bild-Modus sind, 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-1] Es MUSS ein anpassbarer Launcher als Standard vorab geladen werden.
[C-2-2] Die angedockte Aktivität eines Split-Screen-Multi-Window MUSS zugeschnitten werden, 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] MUSS Aktivitäten im Bild-im-Bild-Multifenstermodus starten, wenn die App * auf API‑Level 26 oder höher ausgerichtet ist und android:supportsPictureInPicture deklariert oder * auf API‑Level 25 oder niedriger ausgerichtet ist und sowohl android:resizeableActivity als auch android:supportsPictureInPicture deklariert.
[C-3-2] MUSS die Aktionen in der SystemUI gemäß der aktuellen PIP-Aktivität über die setActions() API verfügbar machen.
[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 im Benachrichtigungsfeld.
[C-3-6] Für das BiB-Fenster MUSS die folgende Mindestbreite und ‑höhe zugewiesen werden, wenn eine Anwendung keinen Wert für AndroidManifestLayout_minWidth und AndroidManifestLayout_minHeight deklariert:
- Geräte, bei denen Configuration.uiMode auf einen anderen Wert als UI_MODE_TYPE_TELEVISION festgelegt ist, MÜSSEN eine Mindestbreite und ‑höhe von 108 dp zuweisen.
- Geräte, bei denen Configuration.uiMode auf UI_MODE_TYPE_TELEVISION festgelegt ist, MÜSSEN eine Mindestbreite von 240 dp und eine Mindesthöhe von 135 dp zuweisen.

3.8.15. Display-Aussparung

Android unterstützt Display-Ausschnitte, wie im SDK-Dokument beschrieben. Die DisplayCutout API definiert einen Bereich am Rand des Displays, der aufgrund eines Displayausschnitts oder eines gebogenen Displays am Rand für eine Anwendung möglicherweise nicht funktional ist.

Wenn Geräteimplementierungen Displayausschnitte 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 nur ein Ausschnitt pro Kante vorhanden sein.
[C-1-3] MUSS die von der App über die WindowManager.LayoutParams API festgelegten Flags für das Display-Cutout 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 Drittanbieteranwendungen 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.9. Geräteverwaltung

Android bietet Funktionen, mit denen sicherheitsbewusste Anwendungen Geräteverwaltungsfunktionen auf Systemebene ausführen können, z. B. das Erzwingen von Passwortrichtlinien oder das Ausführen von Remote-Löschungen über die Android Device Administration API.

Wenn Geräteimplementierungen die gesamte Bandbreite der in der Android SDK-Dokumentation definierten Richtlinien zur Geräteverwaltung implementieren, gilt Folgendes:

[C-1-1] MÜSSEN android.software.device_admin deklarieren.
[C-1-2] MUSS die Bereitstellung des Geräteinhabers gemäß Abschnitt 3.9.1 und Abschnitt 3.9.1.1 unterstützen.

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 Gerätepolicy-Clients (Device Policy Client, DPC) als App für Geräteinhaber wie unten beschrieben unterstützen:
- Wenn die Geräteimplementierung noch keine Nutzerdaten hat, gilt Folgendes:
  - [C-1-3] MÜSSEN true für DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) melden.
  - [C-1-4] Die DPC-Anwendung MUSS als Geräteinhaber-App als Reaktion auf die Intent-Aktion android.app.action.PROVISION_MANAGED_DEVICE registriert werden.
  - [C-1-5] Die DPC-Anwendung MUSS als Geräteinhaber-App registriert werden, wenn das Gerät die Unterstützung von Near-Field Communication (NFC) über das Feature-Flag android.hardware.nfc deklariert und eine NFC-Nachricht mit einem Datensatz mit dem MIME-Typ MIME_TYPE_PROVISIONING_NFC empfängt.
- Wenn die Geräteimplementierung Nutzerdaten enthält, gilt Folgendes:
  - [C-1-6] MÜSSEN false für DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) melden.
  - [C-1-7] DPC-Anwendungen dürfen nicht mehr als Geräteinhaber-App registriert werden.
[C-1-2] Es MUSS vor oder während der Bereitstellung eine aktive Nutzeraktion erforderlich sein, um der Festlegung der App als Geräteinhaber zuzustimmen. Die Einwilligung kann durch eine Nutzeraktion oder auf programmatischem Wege erfolgen. Vor der Bereitstellung des Geräteeigentümers MUSS jedoch ein entsprechender Offenlegungshinweis (wie im AOSP beschrieben) angezeigt werden. Außerdem darf der programmatische Einwilligungsmechanismus für Geräteinhaber, der (von Unternehmen) für die Bereitstellung von Geräteinhabern verwendet wird, die Out-of-Box-Experience für die nicht unternehmensbezogene Nutzung NICHT beeinträchtigen.
[C-1-3] Die Einwilligung darf NICHT fest codiert sein und die Verwendung anderer Apps des Geräteinhabers darf NICHT verhindert werden.

Wenn Geräteimplementierungen android.software.device_admin deklarieren, aber auch eine proprietäre Lösung zur Verwaltung von Geräteeigentümern enthalten und einen Mechanismus bieten, um eine in ihrer Lösung konfigurierte Anwendung als „Geräteeigentümer-Äquivalent“ zum Standard-„Geräteeigentümer“ zu bewerben, der von den Standard-Android-DevicePolicyManager-APIs erkannt wird, gilt Folgendes:

[C-2-1] Es MUSS ein Verfahren vorhanden sein, um zu überprüfen, ob die beworbene App zu einer legitimen Lösung für die Geräteverwaltung gehört und in der proprietären Lösung bereits so konfiguriert wurde, dass sie die Rechte eines Geräteinhabers hat.
[C-2-2] Es MUSS dieselbe Offenlegung der Einwilligung des AOSP-Geräteinhabers angezeigt werden wie bei dem von android.app.action.PROVISION_MANAGED_DEVICE initiierten Ablauf, bevor die DPC-Anwendung als „Geräteinhaber“ registriert wird.
Möglicherweise sind Nutzerdaten auf dem Gerät vorhanden, bevor die DPC-Anwendung als „Geräteinhaber“ registriert wird.

3.9.1.2 Bereitstellung verwalteter Profile

Wenn Geräteimplementierungen android.software.managed_users deklarieren, gilt Folgendes:

[C-1-1] MUSS die APIs implementieren, die es einer DPC-Anwendung (Device Policy Controller) ermöglichen, Inhaber eines neuen verwalteten Profils zu werden.
[C-1-2] Der Bereitstellungsprozess für verwaltete Profile (der durch android.app.action.PROVISION_MANAGED_PROFILE initiierte Ablauf) muss mit der AOSP-Implementierung übereinstimmen.
[C-1-3] MUSS in den Einstellungen die folgenden Informationen für den Nutzer bereitstellen, um anzugeben, wann eine bestimmte Systemfunktion vom Device Policy Controller (DPC) deaktiviert wurde:
- Ein einheitliches Symbol oder eine andere Nutzerhilfe (z. B. das AOSP-Infosymbol) zur Darstellung, 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.

3.9.2 Unterstützung verwalteter 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 „Zuletzt verwendet“ 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-Arbeitssymbol) angezeigt werden, um anzugeben, wann sich der Nutzer in einer Anwendung mit verwaltetem Profil befindet.
[C-1-5] Es MUSS ein Toast angezeigt werden, der darauf hinweist, 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 primären Nutzer oder umgekehrt weiterleiten kann, sofern dies vom Device Policy Controller aktiviert wurde.
[C-1-7] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN sowohl für den primären Nutzer als auch für das verwaltete Profil die folgenden Nutzerfunktionen verfügbar sein:
- Separate Abrechnung für Akku, Standort, mobile Daten und Speichernutzung für den primären Nutzer und das verwaltete Profil.
- Unabhängige Verwaltung von VPN-Anwendungen, 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 Hauptnutzer- oder verwalteten Profil
[C-1-8] MUSS dafür sorgen, dass in den vorinstallierten Dialer-, Kontakt- 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 für ein Gerät mit mehreren aktivierten Nutzern erfüllen (siehe Abschnitt 9.5), auch wenn das verwaltete Profil nicht als zusätzlicher Nutzer neben dem primären Nutzer gezählt wird.

Wenn Geräteimplementierungen android.software.managed_users und android.software.secure_lock_screen deklarieren, gilt Folgendes:

[C-2-1] Es MUSS möglich sein, einen separaten Sperrbildschirm anzugeben, der die folgenden Anforderungen erfüllt, um nur Zugriff auf Apps zu gewähren, die in einem verwalteten Profil ausgeführt werden.
- Geräteimplementierungen MÜSSEN den Intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD berücksichtigen und eine Benutzeroberfläche zum Konfigurieren eines separaten Sperrbildschirm-Anmeldedaten für das verwaltete Profil anzeigen.
- Die Anmeldedaten für den Sperrbildschirm des verwalteten Profils MÜSSEN dieselben Mechanismen für die Speicherung und Verwaltung von Anmeldedaten wie das übergeordnete Profil verwenden, wie auf der Android Open Source Project-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] MUSS eine Möglichkeit für Nutzer bieten, sich vom aktuellen Nutzer abzumelden und in einer Sitzung mit mehreren Nutzern zum primären Nutzer zurückzukehren, wenn isLogoutEnabled true zurückgibt. Die Nutzeraufforderung MUSS vom Sperrbildschirm aus zugänglich sein, ohne dass das Gerät entsperrt werden muss.

3.10. Bedienungshilfen

Android bietet eine Barrierefreiheitsebene, die Nutzern mit Beeinträchtigungen die Bedienung ihrer Geräte erleichtert. Außerdem bietet Android Plattform-APIs, mit denen Implementierungen von Barrierefreiheitsdiensten Callbacks für Nutzer- und Systemereignisse empfangen und alternative Feedbackmechanismen wie Text-to-Speech, haptisches Feedback und Trackball-/D-Pad-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 Accessibility APIs bereitstellen.
[C-1-2] MUSS Barrierefreiheitsereignisse generieren und die entsprechende AccessibilityEvent an alle registrierten AccessibilityService-Implementierungen senden, wie im SDK dokumentiert.
[C-1-4] Es MUSS in der Navigationsleiste des Systems eine Schaltfläche hinzugefügt werden, über die der Nutzer den Bedienungshilfendienst steuern kann, wenn die aktivierten Bedienungshilfendienste AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON deklarieren . Bei Geräteimplementierungen ohne Systemnavigationsleiste gilt diese Anforderung nicht. Geräteimplementierungen SOLLTEN jedoch eine Möglichkeit für Nutzer bieten, diese Bedienungshilfen 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 im Einrichtungsablauf ein Mechanismus bereitgestellt werden, mit dem Nutzer relevante Bedienungshilfen aktivieren sowie die Schriftgröße, die Anzeigegröße und die Vergrößerungsbewegungen anpassen können.

3.11. Sprachausgabe

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 Drittanbieter-TTS-Engines 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. TV Input Framework

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

Wenn Geräteimplementierungen TIF unterstützen, gilt Folgendes:

[C-1-1] MUSS die Plattformfunktion android.software.live_tv deklarieren.
[C-1-2] MUSS alle TIF-APIs unterstützen, sodass eine Anwendung, die diese APIs und den Dienst TIF-basierte Eingaben von Drittanbietern verwendet, auf dem Gerät installiert und verwendet werden kann.

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 Schnelleinstellungen von Drittanbietern unterstützen, gilt Folgendes:

[C-1-1] Der Nutzer MUSS die Möglichkeit haben, die über die quicksettings-APIs bereitgestellten Kacheln über eine Drittanbieter-App hinzuzufügen oder zu entfernen.
[C-1-2] Eine Kachel aus einer Drittanbieter-App DARF NICHT automatisch 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 Schnelleinstellungen angezeigt werden.

3.14. Media-UI

Wenn Geräteimplementierungen nicht sprachaktivierte Anwendungen (die Apps) enthalten, die über MediaBrowser oder MediaSession mit Drittanbieteranwendungen interagieren, gilt Folgendes:

[C-1-2] MUSS Symbole, die über getIconBitmap() oder getIconUri() abgerufen wurden, und Titel, die über getTitle() abgerufen wurden, wie in MediaDescription beschrieben, deutlich anzeigen. 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. Der Zugriff auf einen Teil der Hierarchie KANN eingeschränkt werden, um Sicherheitsbestimmungen einzuhalten (z.B. Ablenkung des Fahrers), es DÜRFEN aber keine bevorzugten Behandlungen basierend auf Inhalten oder Inhaltsanbietern erfolgen.
[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. Android Instant Apps

Geräteimplementierungen MÜSSEN die folgenden Anforderungen erfüllen:

[C-0-1] Instant-Apps DÜRFEN nur Berechtigungen erhalten, für die android:protectionLevel auf "instant" festgelegt ist.
[C-0-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 hat 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-0-3] Instant-Apps DÜRFEN NICHT explizit mit installierten Apps interagieren, es sei denn, die Komponente wird über „android:visibleToInstantApps“ verfügbar gemacht.
[C-0-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 Anwendung her.

Wenn Geräteimplementierungen Instant-Apps unterstützen, gilt Folgendes:

[C-1-1] MÜSSEN die folgenden Möglichkeiten zur Interaktion mit Instant-Apps bieten. Das AOSP erfüllt die Anforderungen mit der Standard-System-UI, den Einstellungen und dem Launcher.
[C-1-2] Es MUSS eine Möglichkeit für Nutzer geben, lokal zwischengespeicherte Instant-Apps für jedes einzelne App-Paket anzusehen und zu löschen.
[C-1-3] MUSS eine dauerhafte Nutzerbenachrichtigung bereitstellen, die minimiert werden kann, während eine Instant-App im Vordergrund ausgeführt wird. Diese Nutzerbenachrichtigung MUSS enthalten, dass Instant Apps keine Installation erfordern, und eine Möglichkeit für den Nutzer bieten, die App-Infoseite in den Einstellungen aufzurufen. Bei Instant Apps, die über Web-Intents gestartet werden (definiert durch einen Intent mit der auf „Intent.ACTION_VIEW“ festgelegten Aktion und dem Schema „http“ oder „https“), SOLLTE eine zusätzliche Nutzerfunktion 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-4] MUSS den Zugriff auf Instant Apps über die Funktion „Letzte Apps“ ermöglichen, wenn diese Funktion auf dem Gerät verfügbar ist.
[C-1-5] Es MUSS mindestens eine Anwendung oder Dienstkomponente mit einem Intent-Handler für die hier im SDK aufgeführten Intents vorab geladen werden und die Intents MÜSSEN für Instant Apps sichtbar sein.

3.16. Kopplung von Begleitgeräten

Android unterstützt die Kopplung 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 zum Koppeln 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 geben, ein Companion-Gerät auszuwählen/zu bestätigen, das vorhanden und betriebsbereit ist.

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 im System mehr vorhanden sind), MUSS die Geräteimplementierung diese App im RAM priorisieren, wie sie es auch bei anderen Dingen tut, die voraussichtlich weiter ausgeführt werden, z. B. bei Vordergrunddiensten. Auch wenn sich eine solche App im Hintergrund befindet, 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, in denen cantSaveState angegeben ist, z. B. Änderungen an der CPU-Leistung oder an der Priorisierung der Planung.

Wenn Geräteimplementierungen das Feature FEATURE_CANT_SAVE_STATE nicht deklarieren, 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_TYPE erstellt.

Benutzerdefiniertes lokales Konto: 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 mindestens einem Wert ungleich null für die Spalten ACCOUNT_NAME und ACCOUNT_TYPE erstellt.

Geräteimplementierungen:

[C-SR] 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] Rohkontakte, die von Drittanbieteranwendungen mit dem lokalen Standardkonto eingefügt werden (d.h. durch Festlegen von Nullwerten für ACCOUNT_NAME und ACCOUNT_TYPE), MÜSSEN in das benutzerdefinierte lokale Konto eingefügt werden.
[C-1-4] Rohkontakte, die in das benutzerdefinierte lokale Konto eingefügt wurden, 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.

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 werden, 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.

Geräteimplementierungen:

[C-0-2] MUSS die Überprüfung von „.apk“-Dateien mit dem APK-Signaturschema v3 , dem APK-Signaturschema v2 und der JAR-Signierung unterstützen.
[C-0-3] Die Formate .apk, Android-Manifest, Dalvik-Bytecode oder RenderScript-Bytecode dürfen NICHT so erweitert werden, dass die Dateien nicht auf anderen kompatiblen Geräten installiert und ausgeführt werden können.
[C-0-4] Apps, die nicht die aktuelle „Installer of Record“-App für das Paket sind, DÜRFEN die App nicht ohne Bestätigung durch den Nutzer 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] MUSS eine Aktivität haben, die den Intent android.settings.MANAGE_UNKNOWN_APP_SOURCES verarbeitet.
[C-0-6] App-Pakete dürfen NICHT 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 Auswahl nicht ermöglichen soll. Auch in solchen Fällen SOLLTEN sie dem Nutzer jedoch mitteilen, warum keine solche Auswahl 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 über die System-API PackageManager.setHarmfulAppWarning bereitgestellten Warnstring angezeigt werden.
Es SOLLTE eine Möglichkeit für den Nutzer geben, eine Anwendung im Warnungsdialog 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 unterstützen.
Wenn Geräteimplementierungen bereits mit einer früheren Android-Version eingeführt wurden und die Anforderungen [C-0-8] und [C-0-9] nicht durch ein Systemsoftware-Update erfüllen können, KÖNNEN sie von diesen Anforderungen ausgenommen werden.

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 deklarieren und melden, die Drittanbieteranwendungen über MediaCodecList zur Verfügung stehen.
[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 in der CamcorderProfile gemeldeten Profile.

Geräteimplementierungen:

SHOULD aim for minimum codec latency, in others words, they
- Eingabepuffer sollten NICHT verarbeitet und gespeichert werden. Sie 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 durch die GOP-Struktur erforderlich aufbewahren.

Alle 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 darüber zu informieren, ob für die Implementierung dieses Codes, auch in Open-Source-Software oder Shareware, Patentlizenzen von den entsprechenden Patentinhabern erforderlich sind.

5.1. Media-Codecs

5.1.1. Audiocodierung

Weitere Informationen finden Sie unter 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 unter 5.1.3. Details zu Audio-Codecs.

Wenn Geräteimplementierungen die Unterstützung für die Funktion android.hardware.audio.output deklarieren, müssen sie die folgenden Audioformate decodieren können:

[C-1-1] MPEG-4 AAC-Profil (AAC LC)
[C-1-2] MPEG-4 HE AAC-Profil (AAC+)
[C-1-3] MPEG-4 HE AACv2-Profil (Enhanced AAC+)
[C-1-4] AAC ELD (Enhanced Low Delay AAC)
[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)
[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, einer Abtastrate von 192 kHz 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

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 decodiert werden, ein 5.1-AAC-Stream in sechs PCM-Kanäle).
[C-2-2] Metadaten für den dynamischen Bereich MÜSSEN wie in „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.
[SR] Es wird DRINGEND EMPFOHLEN, dass alle AAC-Audio-Decodierer die oben genannten Anforderungen C-2-1 und C-2-2 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 die Steuerung von Lautstärke und Dynamikbereich mit dem ISO/IEC 23003-4-Profil für die Steuerung des Dynamikbereichs.

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 Audiodecoder 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.

5.1.3. Details zu Audio-Codecs

Format/Codec	Details	Unterstützte Dateitypen/Containerformate
MPEG-4 AAC-Profil (AAC LC)	Unterstützung für Mono-/Stereo-/5.0-/5.1-Inhalte mit Standard-Abtastraten von 8 bis 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS-Roh-AAC (.aac, ADIF wird nicht unterstützt) MPEG-TS (.ts, nicht suchbar, nur decodierbar) Matroska (.mkv, nur Decodierung)
MPEG-4 HE AAC-Profil (AAC+)	Unterstützung für Mono-/Stereo-/5.0-/5.1-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profile (enhanced AAC+)	Unterstützung für Mono-/Stereo-/5.0-/5.1-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (Enhanced Low Delay AAC)	Unterstützung für Mono-/Stereo-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Unterstützung für Mono-/Stereo-Inhalte mit Standard-Abtastraten von 7,35 bis 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 bis 12,2 kbit/s bei einer Abtastrate von 8 kHz	3GPP (.3gp)
AMR-WB	9 Raten von 6,60 kbit/s bis 23,85 kbit/s, gesampelt bei 16 kHz, wie in AMR-WB, Adaptive Multi-Rate – Wideband Speech Codec definiert	3GPP (.3gp)
FLAC	Sowohl für Encoder als auch für Decoder: Mindestens Mono- und Stereomodi MÜSSEN unterstützt werden. Abtastraten von bis zu 192 kHz MÜSSEN unterstützt werden. 16‑Bit- und 24‑Bit-Auflösung MÜSSEN unterstützt werden. Die Verarbeitung von 24‑Bit-FLAC-Audiodaten MUSS mit einer Gleitkomma-Audiokonfiguration verfügbar sein.	FLAC (.flac) MPEG-4 (.mp4, .m4a, nur Dekodierung) Matroska (.mkv, nur Decodierung)
MP3	Mono/Stereo, 8–320 kbit/s, konstante (CBR) oder variable Bitrate (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, nur Dekodierung) Matroska (.mkv, nur Decodierung)
MIDI	MIDI-Typ 0 und 1 DLS-Version 1 und 2 XMF und Mobile XMF Unterstützung für die Klingeltonformate RTTTL/RTX, OTA und iMelody	Typ 0 und 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis		Ogg (.ogg) MPEG-4 (.mp4, .m4a, nur Dekodierung) Matroska (.mkv) WebM (.webm)
PCM/WAVE	Der PCM-Codec MUSS lineare 16-Bit-PCM und 16-Bit-Float unterstützen. Der WAVE-Extractor muss 16‑Bit-, 24‑Bit- und 32‑Bit-Linear-PCM sowie 32‑Bit-Float (Raten bis zur Hardwaregrenze) unterstützen. Abtastraten von 8 kHz bis 192 kHz MÜSSEN unterstützt werden.	WAVE (.wav)
Opus	Decodierung: Unterstützung für Mono-, Stereo-, 5.0- und 5.1-Inhalte mit Abtastraten von 8.000, 12.000, 16.000, 24.000 und 48.000 Hz. Codierung: Unterstützung für Mono- und Stereo-Inhalte mit Abtastraten von 8.000, 12.000, 16.000, 24.000 und 48.000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, nur Dekodierung) Matroska (.mkv) WebM (.webm)

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

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] MUSS 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. Bild-Decodierung

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

Wenn Geräteimplementierungen die HEVC-Videodecodierung unterstützen, gilt Folgendes: * [C-1-1] Sie MÜSSEN 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)

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.
[SR] Es wird DRINGEND EMPFOHLEN, das RGB888-Farbformat für den Eingabeoberflächenmodus zu unterstützen.
[C-1-3] MUSS mindestens eines der planaren oder semiplanaren YUV420-8:8:8-Farbformate 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 Web-Videostreaming- 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, aber auch nicht überdimensioniert sind.
[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-Farbenformate 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.
[SR] Video-Encoder und ‑Decoder sollten DRINGEND mindestens eines der hardwareoptimierten planaren oder semiplanaren YUV420-Farbformate (8:8:8) unterstützen (YV12, NV12, NV21 oder ein entsprechendes anbieteroptimiertes Format).
[C-1-5] Video-Decoder, 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 (8:8:8) über android.media.MediaCodecInfo widergespiegelt werden.

Wenn Geräteimplementierungen die Unterstützung von HDR-Profilen über Display.HdrCapabilities angeben, 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 funktionieren.

Sofern die Anwendung nicht anders angibt (mit dem Formatschlüssel KEY_COLOR_FORMAT), gilt für Implementierungen von Videodecodern Folgendes:

[C-4-1] MUSS standardmäßig das für das Hardware-Display optimierte Farbformat verwenden, wenn es über die Oberflächenausgabe konfiguriert wird.
[C-4-2] MUSS standardmäßig ein für das Lesen durch die CPU optimiertes YUV420-Farbformat mit 8:8:8 verwenden, wenn die Ausgabe über die Oberfläche nicht konfiguriert ist.

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)

5.1.9. Sicherheit von Media-Codecs

Geräteimplementierungen MÜSSEN die unten beschriebenen Sicherheitsfunktionen für Media-Codecs unterstützen.

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] MUSS Unterstützung für Media-Codecs entweder über OMX- oder Codec 2.0-APIs (oder beides) wie im Android Open Source Project bieten und darf 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] 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 enthalten (sofern verfügbar).
[C-2-2] Codecs, deren Namen mit „OMX.google.“ beginnen MUSS auf dem Quellcode des Open-Source-Projekts für Android basieren.
[C-SR] Es wird DRINGEND EMPFOHLEN, dass die OMX-Software-Codecs in einem Codec-Prozess ausgeführt werden, der keinen Zugriff auf andere Hardwaretreiber als Memory Mapper 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 Mediatyp (Encoder oder Decoder) den entsprechenden Codec 2.0-Software-Codec aus dem Android Open Source Project enthalten (sofern verfügbar).
[C-3-2] MÜSSEN die Codec 2.0-Software-Codecs im Software-Codec-Prozess untergebracht werden, wie im Android Open Source Project 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 Android Open Source Project basieren.

5.1.10. Media-Codec-Charakterisierung

Wenn Geräteimplementierungen Media-Codecs unterstützen, gilt Folgendes:

[C-1-1] MUSS über die MediaCodecInfo API 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 mit Namen, die 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 als 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 von 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] Alle Videocodecs MÜSSEN Daten zur erreichbaren Framerate für die folgenden Größen veröffentlichen, 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 px (H263) 640 × 360 px (VP8, VP9) 640 × 480 Pixel (MPEG4-Encoder) 720 × 480 Pixel (andere)	1408 × 1152 Pixel (H263) 1280 × 720 Pixel (sonstige)	1920 × 1080 Pixel (nicht MPEG4)	3.840 × 2.160 Pixel (HEVC, VP9)

[C-2-2] Für Videocodecs, die als hardwarebeschleunigt gekennzeichnet sind, MUSS es Informationen zu Leistungspunkten geben. Sie MÜSSEN alle unterstützten Standard-Leistungspunkte (aufgeführt in der PerformancePoint API) auflisten, sofern sie nicht von einem anderen unterstützten Standard-Leistungspunkt abgedeckt werden.
Außerdem SOLLTEN sie erweiterte Leistungspunkte veröffentlichen, wenn sie eine andere als die aufgeführten Standardleistungen für nachhaltige Videoleistung unterstützen.

5.2. Videocodierung

Wenn Geräteimplementierungen einen Video-Encoder unterstützen und ihn für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

Sollte über zwei gleitende 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 ein eingebettetes Display mit einer Diagonale von mindestens 2,5 Zoll oder einen Videoausgangsanschluss enthalten oder die Unterstützung einer Kamera über das android.hardware.camera.any-Funktionsflag deklarieren, müssen sie:

[C-1-1] MUSS mindestens einen der Video-Encoder VP8 oder H.264 unterstützen und für Drittanbieteranwendungen verfügbar machen.
SOLLTE 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.

5.2.1. H.263

Wenn Geräteimplementierungen H.263-Encoder unterstützen und sie Drittanbieter-Apps zur Verfügung stellen, gilt Folgendes:

[C-1-1] MUSS das Baseline-Profil Level 45 unterstützen.
Sollte dynamisch konfigurierbare Bitraten für den unterstützten Encoder unterstützen.

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 von ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist jedoch OPTIONAL. Um die Kompatibilität mit anderen Android-Geräten aufrechtzuerhalten, wird außerdem EMPFOHLEN, dass ASO, FMO und RS nicht für das Baseline-Profil von Encodern verwendet werden.
[C-1-2] MUSS die SD-Videocodierungsprofile (Standard Definition) in der folgenden Tabelle unterstützen.
SOLLTE Main Profile Level 4 unterstützen.
Sollte die in der folgenden Tabelle angegebenen HD-Videocodierungsprofile (High Definition) 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 den Hardware-Codierungsanforderungen des WebM-Projekts für RTC entspricht, 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] Das Schreiben von Matroska WebM-Dateien MUSS unterstützt werden.
[C-1-3] MUSS CodecPrivate-Daten generieren.
Sollte die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
[SR] 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 unterstützen.
Sollte die HD-Codierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
[SR] Es wird DRINGEND EMPFOHLEN, die in der folgenden Tabelle aufgeführten HD-Codierungsprofile 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

5.3. Videodecodierung

Wenn Geräteimplementierungen die Codecs VP8, VP9, H.264 oder H.265 unterstützen, gilt Folgendes:

[C-1-1] MUSS dynamische Videoauflösungs- und Framerate-Wechsel über die standardmäßigen Android-APIs innerhalb desselben Streams für alle VP8-, VP9-, H.264- und H.265-Codecs in Echtzeit und bis zur maximalen Auflösung unterstützen, die von jedem Codec auf dem Gerät unterstützt wird.

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 und Level 45 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-Profil unterstützen. Die Unterstützung von ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist OPTIONAL.
[C-1-2] MUSS Videos mit den in der folgenden Tabelle aufgeführten SD-Profilen (Standard Definition) decodieren können, die mit dem Baseline-Profil und dem Main-Profil Level 3.1 (einschließlich 720p30) codiert sind.
Sollte Videos mit den in der folgenden Tabelle angegebenen HD-Profilen (High Definition) decodieren können.

Wenn die Höhe, die von der Display.getSupportedModes()-Methode gemeldet wird, gleich oder größer als die Videoauflösung ist, gilt für Geräteimplementierungen Folgendes:

[C-2-1] MUSS die HD‑Videodecodierungsprofile mit 720p in der folgenden Tabelle unterstützen.
[C-2-2] MUSS die in der folgenden Tabelle aufgeführten HD‑1080p‑Videodecodierungsprofile 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 fps^Fernsehen)
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] MUSS die in der folgenden Tabelle angegebenen HD-Decodierungsprofile unterstützen, wenn ein Hardware-Decoder vorhanden ist.

Wenn die Höhe, die von der Methode Display.getSupportedModes() gemeldet wird, gleich oder größer als die Videoauflösung ist, gilt Folgendes:

[C-2-1] Geräteimplementierungen MÜSSEN mindestens eine der folgenden Decodierungen unterstützen: H.265 oder VP9 für 720-, 1080- und UHD-Profile.

	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 fps^{Fernseher 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 über die Media APIs angeben, dass sie ein HDR-Profil unterstützen:

[C-3-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR‑Metadaten von der Anwendung akzeptieren und 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).

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.
Sollte einen Hardware-VP8-Codec verwenden, der die Anforderungen erfüllt.
Sollte die HD-Decodierungsprofile in 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-2-1] Geräteimplementierungen MÜSSEN die 720p-Profile in der folgenden Tabelle unterstützen.
[C-2-2] Geräteimplementierungen MÜSSEN die in der folgenden Tabelle aufgeführten 1080p-Profile 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 fps^Fernsehen)	30 (60 fps^Fernsehen)
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:

[C-2-1] MUSS die HD-Decodierungsprofile gemäß der folgenden Tabelle unterstützen.

Wenn die Höhe, die von der Methode Display.getSupportedModes() gemeldet wird, gleich oder größer als die Videoauflösung ist, gilt Folgendes:

[C-3-1] Geräteimplementierungen MÜSSEN mindestens die Decodierung von VP9- oder H.265-Profilen mit 720p, 1080p und UHD unterstützen.

	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 fps^{Fernseher 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 die erforderlichen HDR‑Metadaten aus dem Bitstream und/oder Container extrahieren und ausgeben können.
[C-4-2] Geräteimplementierungen MÜSSEN HDR-Inhalte auf dem Gerätebildschirm oder an einem Standard-Videoausgang (z.B. HDMI).

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 bereitstellen, der Dolby Vision unterstützt.
[C-1-2] Dolby Vision-Inhalte MÜSSEN auf dem Gerätebildschirm oder über einen Standard-Videoausgang (z.B. HDMI).
[C-1-3] Der Track-Index der abwärtskompatiblen Basisebene(n) (falls vorhanden) MUSS mit dem Track-Index der kombinierten Dolby Vision-Ebene übereinstimmen.

5.3.9. AV1

Wenn Geräteimplementierungen den AV1-Codec unterstützen, gilt Folgendes:

[C-1-1] MUSS Profil 0 einschließlich 10‑Bit-Inhalten unterstützen.

5.4. Audioaufnahmen

Einige der in diesem Abschnitt beschriebenen Anforderungen sind seit Android 4.3 als SHOULD aufgeführt. In der Kompatibilitätsdefinition für zukünftige Versionen ist jedoch geplant, diese in MUST zu ändern. Es wird DRINGEND EMPFOHLEN, dass vorhandene und neue Android-Geräte diese Anforderungen erfüllen, die als „SHOULD“ aufgeführt sind. Andernfalls können sie bei einem Upgrade auf die zukünftige Version nicht die Android-Kompatibilität erreichen.

5.4.1. Rohdaten der Audioaufnahme und Mikrofoninformationen

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, gilt Folgendes:

[C-1-1] MUSS die Aufnahme von Audio-Rohinhalten mit den folgenden Eigenschaften ermöglichen:
- Format: Lineare PCM, 16 Bit
- Abtastraten: 8.000, 11.025, 16.000, 44.100, 48.000 Hz
- Channels (Kanäle): Mono
Die Aufnahme von Audio-Rohinhalten mit den folgenden Eigenschaften SOLLTE möglich sein:
- Format: Lineares 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 die Anzahl der Mikrofone auf dem Gerät
[C-1-2] MUSS mit den oben genannten Abtastraten ohne Upsampling erfasst werden.
[C-1-3] Bei der Erfassung der oben genannten Sampleraten mit Downsampling MUSS ein geeigneter Anti-Aliasing-Filter verwendet werden.
Sollte die Aufnahme von Audio-Rohinhalten 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, sowie zu den derzeit aktiven Mikrofonen, auf die Drittanbieteranwendungen über die AudioRecord.getActiveMicrophones() und MediaRecorder.getActiveMicrophones() APIs zugreifen können, korrekt ausfüllen. Wenn Geräteimplementierungen AM-Radio und die Aufnahme von rohen Audioinhalten in DVD-Qualität ermöglichen, gilt Folgendes:
[C-2-1] MUSS ohne Upsampling bei einem Verhältnis über 16.000:22.050 oder 44.100:48.000 erfasst werden.
[C-2-2] Bei jedem Upsampling oder Downsampling MUSS ein geeigneter Anti-Aliasing-Filter verwendet werden.

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 alle Audioverarbeitungen 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.
Der Audio-Stream für die Spracherkennung SOLLTE mit einer ungefähr flachen Amplitude im Verhältnis zur Frequenz aufgezeichnet werden, genauer gesagt mit ±3 dB von 100 Hz bis 4.000 Hz.
Der Audio-Stream für die Spracherkennung SOLLTE mit einer Eingangsempfindlichkeit aufgezeichnet werden, die so eingestellt ist, dass eine Schallleistungspegelquelle (SPL) von 90 dB bei 1.000 Hz einen RMS von 2.500 für 16-Bit-Samples ergibt.
Der Audio-Stream für die Spracherkennung SOLLTE so aufgezeichnet werden, dass die PCM-Amplitudenpegel Ä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 Technologien zur Rauschunterdrückung (Reduzierung) deklarieren, die für die Spracherkennung optimiert sind, gilt Folgendes:

[C-2-1] Der Audioeffekt MUSS über die android.media.audiofx.NoiseSuppressor API steuerbar sein.
[C-2-2] Jede Implementierung der Technologie zur Rauschunterdrückung MUSS über das Feld AudioEffect.Descriptor.uuid eindeutig identifiziert werden.

5.4.3. Erfassung für die Umleitung der Wiedergabe

Die Klasse android.media.MediaRecorder.AudioSource enthält die Audioquelle REMOTE_SUBMIX.

Wenn in Geräteimplementierungen sowohl android.hardware.audio.output als auch android.hardware.microphone deklariert werden, gilt Folgendes:

[C-1-1] MUSS die Audioquelle REMOTE_SUBMIX korrekt implementieren, sodass bei der Aufnahme über die android.media.AudioRecord API aus dieser Audioquelle ein Mix aller Audio-Streams 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.

Wenn Geräteimplementierungen einen Acoustic Echo Canceler (AEC) bereitstellen, der in den Audioaufnahmepfad eingefügt wird, wenn AudioSource.VOICE_COMMUNICATION ausgewählt ist, gilt Folgendes:

[C-SR] Es wird DRINGEND EMPFOHLEN, dies über die AcousticEchoCanceler API-Methode AcousticEchoCanceler.isAvailable() zu deklarieren.
[C-SR] Es wird DRINGEND EMPFOHLEN, diesen Audioeffekt über die AcousticEchoCanceler API steuern zu lassen.
[C-SR] Es wird DRINGEND EMPFOHLEN, jede AEC-Technologieimplementierung über das Feld AudioEffect.Descriptor.uuid eindeutig zu identifizieren.

5.4.5. Gleichzeitige Aufnahme

Wenn Geräteimplementierungen android.hardware.microphone deklarieren,MUSS die gleichzeitige Aufnahme wie in diesem Dokument beschrieben implementiert werden. Im Detail:

[C-1-1] Der gleichzeitige Zugriff auf das Mikrofon durch einen Bedienungshilfendienst, der mit AudioSource.VOICE_RECOGNITION aufnimmt, und mindestens eine Anwendung, die mit einem beliebigen AudioSource aufnimmt, MUSS möglich sein.
[C-1-2] Es MUSS der gleichzeitige 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, erlaubt sein.
[C-1-3] Die Audioaufnahme MUSS für alle anderen Anwendungen außer für einen Barrierefreiheitsdienst 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, sofern es sich um eine privilegierte (vorinstallierte) App mit der Berechtigung CAPTURE_AUDIO_OUTPUT handelt.
[C-1-4] Wenn zwei oder mehr Anwendungen gleichzeitig Audio aufnehmen und keine der Apps eine Benutzeroberfläche im Vordergrund hat, erhält die App, die die Aufnahme zuletzt gestartet hat, Audio.

5.4.6. Mikrofonverstärkung

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, gilt Folgendes:

SOLLTE im mittleren Frequenzbereich ungefähr flache Amplituden-Frequenz-Eigenschaften 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.
Die Empfindlichkeit des Audioeingangs SOLLTE so eingestellt werden, dass eine bei 90 dB Schalldruckpegel (SPL) wiedergegebene 1000‑Hz-Sinustonquelle eine Reaktion mit einem RMS von 2500 für 16‑Bit-Samples (oder -22,35 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.
[C-SR] Es wird DRINGEND EMPFOHLEN, dass die Amplitudenpegel im niedrigen Frequenzbereich (insbesondere ±20 dB von 5 Hz bis 100 Hz) im Vergleich zum mittleren Frequenzbereich für jedes Mikrofon, das zum Aufzeichnen der Audioquelle für die Spracherkennung verwendet wird, eingehalten werden.
[C-SR] Es wird DRINGEND EMPFOHLEN, dass die Amplitudenpegel im Hochfrequenzbereich ±30 dB von 4.000 Hz bis 22.000 Hz im Vergleich zum Mittelfrequenzbereich für jedes Mikrofon betragen, das zum Aufzeichnen der Audioquelle für die Spracherkennung verwendet wird.

5.5. Audiowiedergabe

Android unterstützt die Audiowiedergabe von Apps über das in Abschnitt 7.8.2 definierte Audioausgabe-Peripheriegerät.

5.5.1. Wiedergabe von Rohaudio

Wenn Geräteimplementierungen android.hardware.audio.output deklarieren, gilt Folgendes:

[C-1-1] MUSS die Wiedergabe von rohen Audioinhalten mit den folgenden Merkmalen ermöglichen:
- 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, 32.000, 44.100, 48.000 bei den oben aufgeführten Channelkonfigurationen
  - 96.000 Hz in Mono und Stereo
Die Wiedergabe von rohen Audioinhalten mit den folgenden Merkmalen SOLLTE möglich sein:
- Abtastraten: 24.000, 48.000

5.5.2. Audioeffekte

Android bietet eine API für Audioeffekte für Geräteimplementierungen.

Wenn Geräteimplementierungen die Funktion android.hardware.audio.output deklarieren, gilt Folgendes:

[C-1-1] MUSS die Implementierungen 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.
Sollte die Implementierungen von 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] Es wird DRINGEND EMPFOHLEN, Effekte in Gleitkomma- und Mehrkanalformaten zu unterstützen.

5.5.3. Audioausgabelautstärke

Automotive-Geräteimplementierungen:

Die Audiolautstä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.6. Audiolatenz

Die Audiolatenz ist die Zeitverzögerung, die auftritt, wenn ein Audiosignal ein System durchläuft. Viele Arten von Anwendungen sind auf kurze Latenzen angewiesen, um Echtzeit-Soundeffekte zu erzielen.

Für die Zwecke dieses Abschnitts 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 On-Device-Wandler an die Umgebung ausgegeben wird oder das Signal das Gerät über einen Port verlässt und extern beobachtet werden kann.
Kaltstartlatenz. Die Ausgabelatenz für den ersten Frame, 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 Ton von der Umgebung über einen On-Device-Wandler an das Gerät übertragen 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 Summe aus der verlorenen Eingabezeit und der Eingabelatenz für den ersten Frame, wenn das Audioeingabesystem vor der Anfrage inaktiv und ausgeschaltet war.
Kontinuierliche Eingabelatenz: Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufnimmt.
Kalter Ausgabeflatter. Die Variabilität zwischen einzelnen Messungen von Kaltstart-Latenzwerten.
Kalter Eingabe-Jitter: Die Variabilität zwischen einzelnen Messungen von Kaltstart-Eingabelatenzwerten.
kontinuierliche Roundtrip-Latenz. Die Summe aus der Latenz für die kontinuierliche Eingabe, der Latenz für die kontinuierliche Ausgabe und einem Pufferzeitraum. Der Pufferzeitraum gibt der App Zeit, das Signal zu verarbeiten und die Phasendifferenz zwischen Ein- und Ausgabestreams zu minimieren.
OpenSL ES PCM buffer queue API Die Gruppe der PCM-bezogenen OpenSL ES-APIs im Android NDK.
AAudio Native Audio API Die Gruppe der AAudio-APIs im Android NDK.
Zeitstempel. Ein Paar aus einer relativen Frame-Position in einem Stream und der geschätzten Zeit, zu der dieser Frame in die Audioverarbeitungspipeline 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.

Wenn Geräteimplementierungen android.hardware.audio.output deklarieren, MÜSSEN sie die folgenden Anforderungen erfüllen oder übertreffen:

[C-1-1] Der von AudioTrack.getTimestamp und AAudioStream_getTimestamp zurückgegebene Ausgabetimestamp hat eine Genauigkeit von +/-2 ms.
[C-1-2] Die Kaltstartlatenz beträgt maximal 500 Millisekunden.

Wenn Geräteimplementierungen android.hardware.audio.output deklarieren, wird DRINGEND EMPFOHLEN, die folgenden Anforderungen zu erfüllen oder zu übertreffen:

[C-SR] Kaltstart-Ausgabelatenz von maximal 100 Millisekunden. Es wird DRINGEND EMPFOHLEN, dass vorhandene und neue Geräte, auf denen diese Android-Version ausgeführt wird, diese Anforderungen jetzt erfüllen. In einer zukünftigen Plattformversion im Jahr 2021 wird eine Kaltstart-Ausgabelatenz von maximal 200 ms als MUST-Anforderung gelten.
[C-SR] Kontinuierliche Ausgabelatenz von höchstens 45 Millisekunden.
[C-SR] Minimiere den Jitter bei der Ausgabe von Kaltstarts.
[C-SR] Der von AudioTrack.getTimestamp und AAudioStream_getTimestamp zurückgegebene Zeitstempel ist auf +/-1 ms genau.

Wenn Geräteimplementierungen die oben genannten Anforderungen erfüllen, sind die kontinuierliche Ausgabelatenz und die Kaltstart-Ausgabelatenz bei Verwendung sowohl der OpenSL ES-PCM-Pufferwarteschlange als auch der nativen AAudio-Audio-APIs für mindestens ein unterstütztes Audioausgabegerät nach der ersten Kalibrierung:

[C-SR] Es wird DRINGEND EMPFOHLEN, Audio mit geringer Latenz zu melden, indem das android.hardware.audio.low_latency-Funktions-Flag deklariert wird.
[C-SR] Es wird DRINGEND EMPFOHLEN, die Anforderungen für Audio mit geringer Latenz über die AAudio API zu erfüllen.
[C-SR] DRINGEND EMPFOHLEN, um sicherzustellen, dass für Streams, die AAUDIO_PERFORMANCE_MODE_LOW_LATENCY von AAudioStream_getPerformanceMode() zurückgeben, der von AAudioStream_getFramesPerBurst() zurückgegebene Wert kleiner oder gleich dem von android.media.AudioManager.getProperty(String) zurückgegebenen Wert für den Attributschlüssel AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER ist.

Wenn Geräteimplementierungen die Anforderungen für Audio mit geringer Latenz über die OpenSL ES-PCM-Pufferwarteschlange und die nativen AAudio-Audio-APIs nicht erfüllen, gilt Folgendes:

[C-2-1] DÜRFEN NICHT die Unterstützung von Audio mit geringer Latenz melden.

Wenn Geräteimplementierungen android.hardware.microphone enthalten, MÜSSEN sie die folgenden Anforderungen an die Audioeingabe erfüllen:

[C-3-1] Beschränke den Fehler bei Eingabe-Zeitstempeln, die von AudioRecord.getTimestamp oder AAudioStream_getTimestamp zurückgegeben werden, auf +/-2 ms. „Fehler“ steht hier für die Abweichung vom korrekten Wert.
[C-3-2] Kaltstart-Eingabelatenz von höchstens 500 Millisekunden.

Wenn Geräteimplementierungen android.hardware.microphone enthalten, wird DRINGEND EMPFOHLEN, die folgenden Anforderungen an die Audioeingabe zu erfüllen:

[C-SR] Kaltstart-Eingabelatenz von höchstens 100 Millisekunden. Es wird DRINGEND EMPFOHLEN, dass vorhandene und neue Geräte, auf denen diese Android-Version ausgeführt wird, diese Anforderungen jetzt erfüllen. In einer zukünftigen Plattformversion im Jahr 2021 wird eine Kaltstart-Eingabelatenz von maximal 200 ms als MUST-Anforderung gelten.
[C-SR] Kontinuierliche Eingabelatenz von maximal 30 Millisekunden.
[C-SR] Kontinuierliche Umlauflatenz von höchstens 50 Millisekunden.
[C-SR] Minimiere den Kaltstart-Jitter.
[C-SR] Beschränke den Fehler bei Eingabe-Zeitstempeln, die von AudioRecord.getTimestamp oder AAudioStream_getTimestamp zurückgegeben werden, auf +/-1 ms.

5.7. Netzwerkprotokolle

Geräteimplementierungen MÜSSEN die Media Network Protocols für die Audio- und Videowiedergabe unterstützen, wie in der Android SDK-Dokumentation angegeben.

Wenn Geräteimplementierungen einen Audio- oder Videodecoder enthalten, gilt Folgendes:

[C-1-1] MUSS alle erforderlichen Codecs und Containerformate in Abschnitt 5.1 über HTTP(S) unterstützen.
[C-1-2] MUSS die in der Tabelle „Media Segment Formats“ unten gezeigten Media-Segmentformate über das HTTP Live Streaming-Protokollentwurf, Version 7, unterstützen.
[C-1-3] MUSS das folgende RTP-Audio-/Videoprofil und die zugehörigen Codecs in der RTSP-Tabelle unten unterstützen. 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.3. Audio-Codecs: AAC Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1.
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

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.3.

Audio-Codecs:

Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1.

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

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.3.
MP4A-LATM	RFC 6416	Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Details zu H263 finden Sie im Abschnitt 5.1.3.
H263-2000	RFC 4629	Details zu H263 finden Sie im Abschnitt 5.1.3.
AMR	RFC 4867	Weitere Informationen zu AMR-NB finden Sie in Abschnitt 5.1.1.
AMR-WB	RFC 4867	Weitere Informationen zu AMR-WB finden Sie in Abschnitt 5.1.1.
MP4V-ES	RFC 6416	Weitere Informationen zu MPEG-4 SP finden Sie im Abschnitt 5.1.3.
mpeg4-generic	RFC 3640	Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1.
MP2T	RFC 2250	Weitere Informationen finden Sie unter MPEG-2-Transportstrom unter HTTP-Livestreaming.

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 Unterstützung für Display.FLAG_SECURE und das Wireless Display-Protokoll 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 verbunden 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, gilt Folgendes:

[C-1-1] MÜSSEN MIDI über alle MIDI-fähigen Hardware-Transports unterstützen, für die sie eine generische Nicht-MIDI-Verbindung bereitstellen, wobei solche Transports Folgendes sind:
- USB-Hostmodus, Abschnitt 7.7
- MIDI über Bluetooth LE in zentraler Rolle, Abschnitt 7.4.3
[C-1-2] MUSS den Inter-App-MIDI-Softwaretransport (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] Die kontinuierliche Audio-Umlauflatenz, wie in Abschnitt 5.6 Audio-Latenz definiert, MUSS mindestens auf einem unterstützten Pfad 20 Millisekunden oder weniger betragen und SOLLTE 10 Millisekunden oder weniger betragen.
[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] MUSS die Anforderungen an Latenz und USB-Audio sowohl mit der OpenSL ES-PCM-Pufferwarteschlangen-API als auch mit mindestens einem Pfad der nativen AAudio-Audio-API erfüllen.
[SR] Es wird DRINGEND EMPFOHLEN, die Latenz- und USB-Audioanforderungen über die AAudio Native Audio API anstelle des MMAP-Pfads zu erfüllen.
[C-1-6] Die Kaltstartlatenz der Ausgabe MUSS maximal 200 Millisekunden betragen.
[C-1-7] MUSS eine Kaltstart-Eingabelatenz von maximal 200 Millisekunden haben.
[SR] Es wird DRINGEND EMPFOHLEN, ein gleichbleibendes Maß an CPU-Leistung bereitzustellen, während Audio aktiv ist und die CPU-Last variiert. Dies sollte mit der Android-App-Version von SynthMark mit der Commit-ID 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 getestet werden. SynthMark verwendet einen Softwaresynthesizer, der in einem simulierten Audio-Framework ausgeführt wird, um die Systemleistung zu messen. Die SynthMark App muss mit der Option „Automatisierter Test“ ausgeführt werden und die folgenden Ergebnisse erzielen:
- voicemark.90 >= 32 Stimmen
- latencymark.fixed.little <= 15 ms
- latencymark.dynamic.little <= 50 ms

Eine Erläuterung der Benchmarks finden Sie in der SynthMark-Dokumentation.

Sollte die Ungenauigkeit und Abweichung des Audio-Taktgebers im Vergleich zur Standardzeit minimieren.
Sollte die Audio-Clock-Drift relativ zur CPU CLOCK_MONOTONIC minimieren, wenn beide aktiv sind.
Sollte die Audiolatenz über geräteinterne Wandler minimieren.
Sollte die Audiolatenz über digitalen USB-Audio minimieren.
Die Audiolatenzmessungen sollten für alle Pfade dokumentiert werden.
Sollte Jitter bei den Eintragszeiten für den Audio-Puffer-Vervollständigungs-Callback minimieren, da dies den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback beeinflusst.
SOLLTE bei normalem Gebrauch bei der angegebenen Latenz keine Audiofehler aufweisen.
Sollte keinen Latenzunterschied zwischen den Kanälen aufweisen.
Die durchschnittliche MIDI-Latenz sollte über alle Transportarten hinweg minimiert werden.
Die Variabilität der MIDI-Latenz unter Last (Jitter) sollte über alle Transportarten hinweg minimiert werden.
Sollte über alle Transportarten hinweg genaue MIDI-Zeitstempel liefern.
Sollte das Rauschen des Audiosignals über On-Device-Wandler minimieren, einschließlich des Zeitraums unmittelbar nach dem Kaltstart.
Sollte bei aktiven Endpunkten keinen Unterschied zwischen der Audio-Clock auf der Eingabe- und der Ausgabeseite der entsprechenden Endpunkte aufweisen. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher auf dem Gerät oder der Ein- und Ausgang der Audiobuchse.
Sollte Audio-Puffer-Abschluss-Callbacks für die Ein- und Ausgabeseiten der entsprechenden Endpunkte auf demselben Thread verarbeiten, wenn beide aktiv sind, und den Ausgabecallback unmittelbar nach der Rückgabe vom Eingabecallback aufrufen. Wenn es nicht möglich ist, die Rückrufe im selben Thread zu verarbeiten, rufen Sie den Ausgaberückruf kurz nach dem Eingaberückruf auf, damit die Anwendung ein einheitliches Timing auf der Eingabe- und Ausgabeseite hat.
Die Phasendifferenz zwischen der HAL-Audio-Pufferung für die Ein- und Ausgabeseiten der entsprechenden Endpunkte SOLLTE minimiert werden.
Die Berührungslatenz SOLLTE minimiert werden.
Die Variabilität der Berührungslatenz unter Last (Jitter) SOLLTE minimiert werden.
Die Latenz vom Touch-Eingang bis zur Audioausgabe SOLLTE maximal 40 ms betragen.

Wenn Geräteimplementierungen alle oben genannten Anforderungen erfüllen,

[SR] Es wird DRINGEND EMPFOHLEN, die Unterstützung für die Funktion android.hardware.audio.pro über die Klasse android.content.pm.PackageManager zu melden.

Wenn Geräteimplementierungen einen 3,5‑mm-Audioanschluss mit 4 Leitern enthalten, gilt Folgendes:

[C-2-1] Die kontinuierliche Audio-Roundtrip-Latenz muss über den Kopfhöreranschluss 20 Millisekunden oder weniger betragen.
[SR] Es wird DRINGEND EMPFOHLEN, den Abschnitt Mobile device (jack) specifications der Wired Audio Headset Specification (v1.1) einzuhalten.
Die kontinuierliche Audio-Umlauflatenz SOLLTE über den Kopfhöreranschluss 10 Millisekunden oder weniger betragen.

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.
[C-3-2] MUSS im USB-Hostmodus über den USB-Audio-Class-Port eine kontinuierliche Audio-Umlauflatenz von höchstens 20 Millisekunden aufweisen.
Die kontinuierliche Audio-Umlauflatenz SOLLTE im USB-Hostmodus-Port mit USB-Audioklasse 10 Millisekunden oder weniger betragen.
[C-SR] Es wird DRINGEND EMPFOHLEN, die gleichzeitige Ein-/Ausgabe von bis zu 8 Kanälen in jeder Richtung, eine Abtastrate von 96 kHz und eine Bittiefe von 24 Bit oder 32 Bit zu unterstützen, wenn USB-Audio-Peripheriegeräte verwendet werden, die diese Anforderungen ebenfalls unterstützen.

Wenn Geräteimplementierungen einen HDMI-Anschluss enthalten, müssen sie:

Sollte in mindestens einer Konfiguration die Ausgabe in Stereo und acht Kanälen mit einer Bit-Tiefe von 20 Bit oder 24 Bit und 192 kHz ohne Verlust der Bit-Tiefe oder Resampling unterstützen.

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 einen annähernd flachen Amplituden-Frequenz-Verlauf aufweisen, d. h. für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird, ±10 dB von 100 Hz bis 7.000 Hz.
[C-1-3] MUSS Amplitudenpegel im niedrigen Frequenzbereich aufweisen, insbesondere ±20 dB von 5 Hz bis 100 Hz im Vergleich zum mittleren Frequenzbereich 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 werden, dass eine bei 94 dB Schalldruckpegel (SPL) abgespielte 1.000 Hz-Sinustonquelle für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird, eine Reaktion mit einem RMS-Wert von 520 für 16-Bit-Samples (oder -36 dB Full Scale für Gleitkomma-/Double-Precision-Samples) ergibt.
[C-1-6] Das Signal-Rausch-Verhältnis (SNR) muss für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird, mindestens 60 dB betragen. 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, einen THD‑Wert (Total Harmonic Distortion) von weniger als 1% aufweisen.
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. Mit anderen Worten:
[C-1-8] 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-9] 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] MUSS für die AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)-API-Methode null zurückgeben, um das Fehlen der Unterstützung richtig anzugeben.
[SR] werden DRINGEND EMPFOHLEN, um so viele Anforderungen wie möglich an den Signalpfad für die unverarbeitete Aufnahmequelle zu erfüllen.

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 und in den Shell-Befehlen im AOSP dokumentiert unterstützen, die von App-Entwicklern verwendet werden können, einschließlich dumpsys cmd stats.
- [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 vollständig aufzeichnen und über den cmd stats-Shell-Befehl und die StatsManager-System-API-Klasse zugänglich und verfügbar machen.
  - ActivityForegroundStateChanged
  - AnomalyDetected
  - AppBreadcrumbReported
  - AppCrashOccurred
  - AppStartOccurred
  - BatteryLevelChanged
  - BatterySaverModeStateChanged
  - BleScanResultReceived
  - BleScanStateChanged
  - ChargingStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - PluggedStateChanged
  - ScheduledJobStateChanged
  - ScreenStateChanged
  - SyncStateChanged
  - SystemElapsedRealtime
  - UidProcessStateChanged
  - WakelockStateChanged
  - WakeupAlarmOccurred
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - WifiScanStateChanged
- [C-0-4] Der ADB-Daemon auf dem Gerät MUSS 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 einen Mechanismus geben, der es ermöglicht, adb von einem Hostcomputer aus zu verbinden. 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] MÜSSEN Treiber für Windows 7, 8 und 10 bereitgestellt werden, damit Entwickler über das ADB-Protokoll eine Verbindung zum Gerät herstellen können.
Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN 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 unterstützen und mindestens eine Kamera enthalten, müssen sie die folgenden Anforderungen erfüllen:
- [C-5-1] Die Methode AdbManager#isAdbWifiQrSupported() MUSS 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 jedoch unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben beschrieben aktiviert hat.
Affe
- [C-0-8] MUSS das Monkey-Framework enthalten und für Anwendungen verfügbar machen.
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] 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] 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] 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] Es wird DRINGEND EMPFOHLEN, über die Perfetto-Binärdatei mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitzustellen.
Low Memory Killer
- [C-0-10] MUSS ein LMK_KILL_OCCURRED_FIELD_NUMBER-Atom in das statsd-Log schreiben, wenn eine App vom Low Memory Killer beendet wird.
Test Harness Mode: 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.

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] Der App-Entwickler MUSS die Möglichkeit haben, GPU-Debug-Ebenen zu aktivieren/deaktivieren.
[C-1-2] MUSS, wenn die GPU-Debug-Ebenen aktiviert sind, Ebenen in Bibliotheken aufzählen, die von externen Tools bereitgestellt werden (d.h. nicht Teil des Plattform- oder Anwendungspakets sind) und sich im Basisverzeichnis von debugfähigen Anwendungen befinden, 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 Nutzung der Entwickleroptionen ermöglichen. Sie:

[C-0-1] MUSS den Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS berücksichtigen, um Einstellungen für die Anwendungsentwicklung anzuzeigen. In der Upstream-Android-Implementierung ist das Menü „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.
MAY kann den Zugriff auf das Menü „Entwickleroptionen“ vorübergehend einschränken, indem es das Menü visuell ausblendet oder deaktiviert, 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 Drittentwickler 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 auf angemessene 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) in 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 Telefonie-API: Auch auf Geräten, die keine Smartphones sind, müssen diese APIs als sinnvolle No-Ops implementiert werden.

7.1. Display und Grafik

Android bietet Funktionen, mit denen App-Assets und UI-Layouts automatisch an das Gerät angepasst werden, damit Drittanbieter-Apps auf einer Vielzahl von Hardwarekonfigurationen gut ausgeführt werden. Auf den Android-kompatiblen Displays, auf denen alle Android-kompatiblen Drittanbieteranwendungen ausgeführt werden können, MÜSSEN Geräteimplementierungen diese APIs und Verhaltensweisen wie in diesem Abschnitt beschrieben korrekt implementieren.

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.
Punkte pro Zoll (DPI). Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1 Zoll abgedeckt werden. Wenn DPI-Werte angegeben sind, müssen sowohl die horizontalen als auch die vertikalen DPI-Werte in den Bereich fallen.
Seitenverhältnis. Das Verhältnis der Pixel der längeren Seite zur kürzeren Seite des Bildschirms. 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). Die virtuelle Pixeleinheit, die auf einen Bildschirm mit 160 dpi normalisiert wird, berechnet sich so: Pixel = dp * (Dichte/160).

7.1.1. Bildschirmkonfiguration

7.1.1.1. Displaygröße und ‑form

Das Android-UI-Framework unterstützt eine Vielzahl verschiedener logischer Bildschirm-Layoutgrößen und ermöglicht es Anwendungen, die Bildschirm-Layoutgröß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 die eine small-Größe für Configuration.screenLayout melden, MÜSSEN mindestens 426 dp × 320 dp haben.
- 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 die Configuration.screenLayout eine Größe von large melden, MÜSSEN mindestens 640 dp × 480 dp haben.
- Geräte, die eine Größe von xlarge für die 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 Datei „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 UI_MODE_TYPE_NORMAL unterstützen und Android-kompatible Displays mit abgerundeten Ecken enthalten, gilt Folgendes:

[C-1-1] MUSS dafür sorgen, dass 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 15 × 15 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 ein oder mehrere Android-kompatible Displays enthalten, die faltbar sind, oder ein Faltgelenk zwischen mehreren Display-Panels enthalten und solche Displays zum Rendern von Drittanbieter-Apps zur Verfügung stellen, gilt Folgendes:

[C-2-1] MUSS die neueste verfügbare stabile Version der Extensions API oder die stabile Version der Sidecar API implementieren, die von der Window Manager Jetpack-Bibliothek verwendet wird.

Wenn Geräteimplementierungen ein Android-kompatibles Display oder mehrere Android-kompatible Displays enthalten, die faltbar sind, oder ein Faltgelenk zwischen mehreren Displaybereichen, und wenn das Gelenk oder die Faltstelle ein Vollbildanwendungsfenster kreuzt, gilt Folgendes:

[C-3-1] Die Position, die Grenzen und den Status des Scharniers oder der Faltung MUSS über Erweiterungen oder Sidecar-APIs an die Anwendung gemeldet werden.

Details zur korrekten Implementierung der Sidecar- oder Erweiterungs-APIs finden Sie in der öffentlichen Dokumentation zu Window Manager Jetpack.

7.1.1.2. Seitenverhältnis des Bildschirms

Das Seitenverhältnis des physischen Displays für die Android-kompatiblen Displays ist nicht eingeschränkt. Das Seitenverhältnis des logischen Displays, auf dem Drittanbieter-Apps gerendert werden, das aus den über die view.Display-APIs und Configuration-APIs gemeldeten Höhe- und Breitenwerten abgeleitet werden kann, MUSS die folgenden Anforderungen erfüllen:

[C-0-1] Bei Geräteimplementierungen, bei denen Configuration.uiMode auf UI_MODE_TYPE_NORMAL festgelegt ist, MUSS das Seitenverhältnis kleiner oder gleich 1,86 (ungefähr 16:9) sein, es sei denn, die App erfüllt eine der folgenden Bedingungen:
- In der App wurde mit dem Metadatenwert android.max_aspect angegeben, dass sie ein größeres Seitenverhältnis unterstützt.
- Die App deklariert über das Attribut android:resizeableActivity, dass sie in der Größe verändert werden kann.
- Die App ist auf API-Level 24 oder höher ausgerichtet und deklariert kein android:maxAspectRatio, das das zulässige Seitenverhältnis einschränken würde.
[C-0-2] Bei Geräteimplementierungen, bei denen Configuration.uiMode auf UI_MODE_TYPE_NORMAL festgelegt ist, MUSS das Seitenverhältnis mindestens 1,3333 (4:3) betragen, es sei denn, die App kann durch Erfüllen einer der folgenden Bedingungen breiter dargestellt werden:
- Die App deklariert über das Attribut android:resizeableActivity, dass sie in der Größe verändert werden kann.
- In der App wird ein android:minAspectRatio deklariert, das das zulässige Seitenverhältnis einschränkt.
[C-0-3] Bei Geräteimplementierungen, bei denen Configuration.uiMode auf UI_MODE_TYPE_WATCH festgelegt ist, MUSS der Wert für das Seitenverhältnis auf 1,0 (1:1) festgelegt sein.

7.1.1.3. Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe von logischen Standarddichten, um App-Entwicklern bei der Ausrichtung von App-Ressourcen zu helfen.

[C-0-1] Standardmäßig MUSS für Geräteimplementierungen über die DENSITY_DEVICE_STABLE-API nur eine der Android-Framework-Dichten gemeldet werden, die unter DisplayMetrics aufgeführt sind. Dieser Wert DARF sich zu keinem Zeitpunkt ändern. Das Gerät KANN jedoch eine andere beliebige Dichte melden, die sich aus den vom Nutzer vorgenommenen Änderungen der Displaykonfiguration (z. B. Displaygröße) ergibt, die nach dem ersten Start festgelegt wurden.
Geräteimplementierungen SOLLTEN die Standarddichte des Android-Frameworks definieren, die der physischen Dichte des Bildschirms numerisch am nächsten kommt, es sei denn, diese logische Dichte führt dazu, dass die gemeldete Bildschirmgröße unter die unterstützte Mindestgröße fällt. Wenn die Standarddichte des Android-Frameworks, die der physischen Dichte numerisch am nächsten kommt, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 dp Breite) ist, SOLLTEN Geräteimplementierungen die nächstniedrigere Standarddichte des Android-Frameworks melden.

Wenn es eine Möglichkeit gibt, die Anzeigegröße des Geräts zu ändern:

[C-1-1] Die Displaygröße darf nicht auf mehr als das 1,5-Fache der nativen Dichte skaliert werden und darf keine effektive Mindestbildschirmdimension von weniger als 320 dp (entspricht dem Ressourcenqualifizierer „sw320dp“) ergeben, je nachdem, was zuerst eintritt.
[C-1-2] Die Displaygröße DARF NICHT auf weniger als 0,85 Mal die native Dichte skaliert werden.
Um eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen zu gewährleisten, wird EMPFOHLEN, die folgenden Skalierungen der Optionen für die native Anzeige 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 des Android-kompatiblen Displays 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] MÜSSEN angeben, welche Bildschirmausrichtungen sie unterstützen (android.hardware.screen.portrait und/oder android.hardware.screen.landscape), und MÜSSEN 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 die 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] MUSS die dynamische Ausrichtung von Anwendungen im Hoch- oder Querformat unterstützen. Das Gerät muss also die Anfrage der Anwendung nach einer bestimmten Bildschirmausrichtung berücksichtigen.
[C-1-2] Die gemeldete Bildschirmgröße oder ‑dichte darf sich beim Ändern der Ausrichtung NICHT ändern.
MAY select either portrait or landscape orientation as the default.

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 Methode GLES10.getString()) 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 sowohl OpenGL ES 1.1 als auch 2.0 unterstützen, wie in der Android SDK-Dokumentation beschrieben.
[C-SR] Es wird DRINGEND EMPFOHLEN, OpenGL ES 3.1 zu unterstützen.
SOLLTEN OpenGL ES 3.2 unterstützen.

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-SR] 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.

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 Version zusätzlich zu den OpenGL ES 2.0-Funktionssymbolen in der Bibliothek „libGLESv2.so“ exportieren.
[SR] 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 Overhead für leistungsstarke 3D-Grafiken.

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

[SR] Es wird DRINGEND EMPFOHLEN, Unterstützung für Vulkan 1.1 einzuschließen.

Wenn Geräteimplementierungen einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

SOLLTE Unterstützung für Vulkan 1.1 enthalten.

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 ab dieser Ebene und früher bestehen.

Wenn Geräteimplementierungen Unterstützung für Vulkan 1.0 oder höher enthalten, gilt Folgendes:

[C-1-1] MUSS den richtigen Ganzzahlwert mit den Funktions-Flags android.hardware.vulkan.level und android.hardware.vulkan.version melden.
[C-1-2] MUSS mindestens eine VkPhysicalDevice für die native Vulkan-API vkEnumeratePhysicalDevices() aufzählen .
[C-1-3] MÜSSEN die Vulkan 1.0-APIs für jede aufgeführte VkPhysicalDevice vollständig implementieren.
[C-1-4] MUSS die Ebenen, die in nativen Bibliotheken mit dem Namen libVkLayer*.so im nativen Bibliotheksverzeichnis des Anwendungspakets enthalten sind, über die nativen Vulkan-APIs vkEnumerateInstanceLayerProperties() und vkEnumerateDeviceLayerProperties() auflisten .
[C-1-5] Es ist NICHT zulässig, Ebenen aufzulisten, die von Bibliotheken außerhalb des Anwendungspakets bereitgestellt werden, oder andere Möglichkeiten zum Tracing oder Abfangen der Vulkan API bereitzustellen, es sei denn, für die Anwendung ist das Attribut android:debuggable auf true festgelegt.
[C-1-6] MUSS alle Erweiterungs-Strings, die unterstützt werden, über die nativen Vulkan-APIs melden und DÜRFEN umgekehrt KEINE Erweiterungs-Strings melden, die nicht korrekt unterstützt werden.
[C-1-7] MÜSSEN die Erweiterungen VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain und VK_KHR_incremental_present unterstützen.
[C-1-8] MÜSSEN die maximale Version der über das android.software.vulkan.deqp.level-Funktions-Flag unterstützten Vulkan-dEQP-Tests melden.
[C-1-9] MUSS mindestens die Version 132317953 (ab 1. März 2019) unterstützen, wie im android.software.vulkan.deqp.level-Feature-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-SR] Es wird DRINGEND EMPFOHLEN, die Erweiterungen VK_KHR_driver_properties und VK_GOOGLE_display_timing zu unterstützen.

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.

Wenn Geräteimplementierungen Unterstützung für Vulkan 1.1 enthalten und eines der Vulkan-Feature-Flags deklarieren, gilt Folgendes:

[C-3-1] MUSS Unterstützung für die externen Semaphor- und Handle-Typen SYNC_FD und die Erweiterung VK_ANDROID_external_memory_android_hardware_buffer bieten.

7.1.4.3 RenderScript

[C-0-1] Geräteimplementierungen 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 aktivieren möchten. Dazu wird ein Manifest-Tag android:hardwareAccelerated oder direkte API-Aufrufe verwendet.

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 Deaktivieren der Hardwarebeschleunigung direkt über die Android View APIs anfordert.
[C-0-2] MUSS ein Verhalten zeigen, das mit der Android SDK-Dokumentation zur Hardwarebeschleunigung übereinstimmt.

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 breitem Farbraum

Wenn Geräteimplementierungen über Configuration.isScreenWideColorGamut() Unterstützung für Displays mit großem Farbraum beanspruchen , gilt Folgendes:

[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 hat.
[C-1-4] MÜSSEN 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] 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 ältere 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 veröffentlicht wurden.

7.1.6. Displaytechnologie

Die Android-Plattform umfasst 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 Entwickler-APIs für den Zugriff auf externe Displays bereitzustellen.

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 IME-Apps (Input Method Editor) 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] DÜRFEN keine Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard angegebenen Formate (QWERTY oder 12-Tasten) entspricht. * SOLLTE zusätzliche Implementierungen für die Bildschirmtastatur enthalten. * KANN eine Hardwaretastatur enthalten.

7.2.2. Bedienung ohne Berührung

Android unterstützt das Steuerkreuz, den Trackball und das Rad als Mechanismen für die Navigation ohne Touch.

Geräteimplementierungen:

[C-0-1] MUSS den richtigen Wert für android.content.res.Configuration.navigation melden.

Wenn Geräteimplementierungen keine Navigation ohne Touch-Eingabe unterstützen, 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 die Verwendung mit Geräten geeignet ist, die keine Touch-Navigationseingaben haben.

7.2.3. Navigationstasten

Die Funktionen Startbildschirm, Letzte Apps und Zurück, die in der Regel durch eine Interaktion mit einer speziellen physischen Taste oder einem bestimmten Bereich des Touchscreens bereitgestellt werden, sind für das Android-Navigationsparadigma und daher für Geräteimplementierungen unerlässlich:

[C-0-1] MUSS eine Möglichkeit für Nutzer bieten, installierte Anwendungen zu starten, die eine Aktivität 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 „Home“ SOLLTE der Mechanismus für diese Nutzerfreundlichkeit sein.
Es SOLLTE Schaltflächen für die Funktionen „Letzte Apps“ und „Zurück“ geben.

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 Funktionen zugänglich ist.
[C-1-2] Es MUSS klar angegeben werden, welche einzelne Aktion die einzelnen Funktionen auslöst. Ein sichtbares Symbol auf der Schaltfläche, ein Softwaresymbol im Navigationsleistenbereich des Displays oder eine Schritt-für-Schritt-Demo während der Einrichtung sind Beispiele für solche Hinweise.

Geräteimplementierungen:

[SR] Es wird DRINGEND EMPFOHLEN, den Eingabemechanismus für die Menüfunktion nicht bereitzustellen, da sie seit Android 4.0 zugunsten der Aktionsleiste eingestellt wurde.

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 ist und die Aktionsleiste sichtbar ist.
[C-2-2] Das Kontextmenü für Aktionen, das durch Auswahl der Überlaufschaltfläche in der Aktionsleiste angezeigt wird, DARF NICHT in seiner Position geändert werden. Es DARF jedoch an einer anderen Position auf dem Bildschirm gerendert werden, wenn es durch Auswahl der Menüfunktion angezeigt wird.

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 unter 10 liegt. 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.
[SR] Es wird DRINGEND EMPFOHLEN, langes Drücken der HOME-Funktion als diese vorgesehene Interaktion zu verwenden.

Wenn in Geräteimplementierungen ein bestimmter Teil des Bildschirms zum Anzeigen der Navigationstasten verwendet wird, 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] Die durch die App über die API-Methode View.setSystemUiVisibility() festgelegten Flags MÜSSEN berücksichtigt werden, 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() DARF NUR verwendet werden, um den Bereich für die Erkennung der Home-Geste anzugeben.
[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 Vordergrund-App MUSS ein MotionEvent.ACTION_CANCEL-Ereignis senden, sobald Berührungen für eine Systemgeste abgefangen werden, wenn der Vordergrund-App zuvor ein MotionEvent.ACTION_DOWN-Ereignis gesendet wurde.
[C-6-4] MÜSSEN eine Möglichkeit für Nutzer bieten, zu einer buttonbasierten On-Screen-Navigation 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 Aufwischen und Halten vor dem Loslassen aus demselben Bereich wie die Home-Geste bereitgestellt werden.
Gesten, die innerhalb von WindowInsets#getMandatorySystemGestureInsets() beginnen, SOLLTEN 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 als Wischbewegung vom linken und rechten Rand der aktuellen Ausrichtung des Displays bereitgestellt werden.
[C-7-2] Wenn benutzerdefinierte wischbare Systembereiche an den linken oder rechten Rändern bereitgestellt werden, MÜSSEN sie im oberen Drittel des Bildschirms platziert werden. Außerdem muss es eine klare, dauerhafte visuelle Anzeige geben, die darauf hinweist, dass durch Ziehen in diese Bereiche die oben genannten Bereiche und nicht „Zurück“ aufgerufen werden. Ein Systemfeld kann von einem Nutzer so konfiguriert werden, dass es unter dem oberen Drittel des Bildschirmrands platziert wird. Es darf jedoch nicht länger als ein Drittel des Rands sein.
[C-7-3] Wenn für die im Vordergrund ausgeführte App entweder die Flags View.SYSTEM_UI_FLAG_IMMERSIVE oder View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY festgelegt sind, MUSS das Wischen von den Rändern aus wie in AOSP implementiert funktionieren. Dies ist im SDK dokumentiert.
[C-7-4] Wenn für die Vordergrund-App entweder die Flags View.SYSTEM_UI_FLAG_IMMERSIVE oder View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY festgelegt sind, MÜSSEN benutzerdefinierte wischbare Systemleisten ausgeblendet werden, bis der Nutzer die Systemleisten (auch als Navigations- und Statusleiste bezeichnet) wie in AOSP implementiert einblendet.

7.2.4. Touchscreen-Eingabe

Android unterstützt eine Vielzahl von Zeigereingabesystemen wie Touchscreens, Touchpads und Geräte für die Fälschung von Berührungseingaben. 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 den Bildschirm direkt berührt, sind keine zusätzlichen Hinweise 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] MUSS die entsprechenden Feature-Flags android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct und android.hardware.touchscreen.multitouch.jazzhand entsprechend dem Typ des jeweiligen Touchscreens auf dem Gerät melden.

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. der Bildschirm wird nicht direkt berührt) und die Anforderungen für Fake-Touch 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] MÜSSEN nur android.hardware.faketouch melden.
[C-3-3] MUSS TOUCHSCREEN_NOTOUCH für das API-Feld Configuration.touchscreen melden.

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, Trackpad, gyroskopbasierte Air Mouse, Gyro-Pointer, Joystick und Multi-Touch-Trackpad können Fake-Touch-Interaktionen unterstützen. Android enthält die 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 ein Touch-Ereignis mit dem Aktionscode melden, der die Zustandsänderung angibt, die auftritt, wenn der Zeiger auf dem Bildschirm nach unten oder oben bewegt wird.
[C-1-3] MUSS das Drücken und Loslassen 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] Das Gerät MUSS das Drücken und Loslassen des Zeigers sowie das Drücken und Loslassen des Zeigers an derselben Stelle auf einem Objekt auf dem Bildschirm innerhalb eines Zeitlimits unterstützen, damit Nutzer Doppeltippen auf einem Objekt auf dem Bildschirm simulieren können.
[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, wodurch das Objekt auf dem Bildschirm geschleudert wird.

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 unabhängige Erfassung von mindestens fünf Zeigereingaben (Erfassung einer Hand mit Fingern) unterstützen.

7.2.6. Unterstützung für Gamecontroller

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 Geräteimplementierungen einen Controller enthalten oder mit einem separaten Controller im Lieferumfang ausgeliefert werden, der die Eingabe aller in den folgenden Tabellen aufgeführten Ereignisse ermöglicht, gilt Folgendes:

[C-2-1] MUSS das Funktions-Flag android.hardware.gamepad deklarieren.

Schaltfläche	HID-Nutzung²	Android-Schaltfläche
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Steuerkreuz nach oben¹ Steuerkreuz nach unten¹	0x01 0x0039³	AXIS_HAT_Y⁴
Steuerkreuz links1 Steuerkreuz rechts¹	0x01 0x0039³	AXIS_HAT_X⁴
Linke Schultertaste¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Rechte Schultertaste¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Klick auf den linken Stick¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Klicken auf den rechten Stick¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Startseite¹	0x0c 0x0223	KEYCODE_HOME (3)
Zurück¹	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 steht beispielsweise für keine Drehung und das Drücken der Aufwärtstaste, während ein logischer Wert von 1 für eine Drehung um 45 Grad und das Drücken der Aufwärts- und der linken Taste steht.

4 MotionEvent

Analoge Steuerung¹	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 es eine entsprechende API für Drittanbieterentwickler gibt, 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 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, keine Sensor-Listener aufrufen, wenn die entsprechenden Sensoren nicht vorhanden sind usw.).

Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, für den es eine entsprechende API für Drittanbieterentwickler gibt, gilt Folgendes:

[C-1-1] MÜSSEN alle Sensormessungen mit den relevanten Werten des Internationalen Einheitensystems (metrisch) für jeden Sensortyp gemäß der Android SDK-Dokumentation gemeldet werden.
[C-1-2] MUSS Sensordaten mit einer maximalen Latenz von 100 Millisekunden + 2 * sample_time für den Fall eines Sensorstreams mit einer maximal angeforderten Latenz von 0 ms melden, 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 der 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 regelmäßige Datenproben bereitstellen, die ein Jitter von 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 nicht verhindert, dass die Geräte-CPU in den Ruhezustand wechselt oder aus dem Ruhezustand aufwacht.
[C-1-6] MUSS die Ereigniszeit in Nanosekunden gemäß der Android SDK-Dokumentation melden. Diese gibt die Zeit an, zu der das Ereignis stattgefunden hat und mit der SystemClock.elapsedRealtimeNano()-Uhr synchronisiert wurde.
[C-SR] Es wird DRINGEND EMPFOHLEN, dass der Zeitstempel-Synchronisationsfehler unter 100 Millisekunden liegt, und er SOLLTE unter 1 Millisekunde liegen.
Wenn mehrere Sensoren aktiviert sind, SOLLTE der Stromverbrauch die Summe des angegebenen Stromverbrauchs der einzelnen Sensoren NICHT ü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] MUSS für alle Sensoren eine Auflösung ungleich null festlegen und den Wert über die API-Methode Sensor.getResolution() melden.

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 unter 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 für den Sensor 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] 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 mit dem Sensorkoordinatensystem ausgerichtet und konsistent sein.

7.3.1. Beschleunigungsmesser

Geräteimplementierungen:

[C-SR] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser einzubauen.

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

[C-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 50 Hz melden können.
[C-1-2] MÜSSEN den TYPE_ACCELEROMETER-Sensor implementieren und melden.
[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 Messungen vom freien Fall bis zum Vierfachen der Erdbeschleunigung(4g) oder mehr 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 anhand von Stichproben berechnet werden, die über einen Zeitraum von mindestens 3 Sekunden bei der schnellsten Samplingrate erfasst wurden.
[SR] Es wird DRINGEND EMPFOHLEN, den TYPE_SIGNIFICANT_MOTION-Verbundsensor zu implementieren.
[SR] Das Implementieren und Melden des TYPE_ACCELEROMETER_UNCALIBRATED-Sensors wird DRINGEND EMPFOHLEN. Android-Geräte werden DRINGEND EMPFOHLEN, um diese Anforderung zu erfüllen, damit sie auf die zukünftige Plattformversion aktualisiert werden können, in der dies 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.
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 und einen der zusammengesetzten Sensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR oder TYPE_STEP_COUNTER enthalten:

[C-2-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-3-1] MÜSSEN die Verbundsensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren.
[C-SR] 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-4-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Verbundsensor implementieren.

7.3.2. Magnetometer

Geräteimplementierungen:

[C-SR] 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 die Sättigung eintritt.
[C-1-5] MUSS einen Offsetwert für das harte Eisen 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] Das Gerät MUSS die Online-Kalibrierung und ‑Kompensation des Hard-Iron-Bias unterstützen und die Kompensationsparameter zwischen Geräte-Neustarts 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, die nicht größer als 1,5 µT ist; SOLLTE eine Standardabweichung haben, die nicht größer als 0,5 µT ist.
[C-SR] Es wird DRINGEND EMPFOHLEN, den TYPE_MAGNETIC_FIELD_UNCALIBRATED-Sensor zu implementieren.

Wenn Geräteimplementierungen ein 3‑Achsen-Magnetometer, einen Beschleunigungsmesser und einen 3‑Achsen-Gyroskop-Sensor 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] 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 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 MUSS die Geräteimplementierung 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] Es wird DRINGEND EMPFOHLEN, während eines Notrufs weiterhin normale GPS-/GNSS-Standortausgaben über die GNSS Location Provider API zu liefern.
- [C-SR] SOLLTEN GNSS-Messungen von allen verfolgten Konstellationen (wie in GnssStatus-Nachrichten angegeben) mit Ausnahme von SBAS melden.
- [C-SR] Es wird DRINGEND EMPFOHLEN, AGC und die Frequenz von GNSS-Messungen zu melden.
- [C-SR] Es wird DRINGEND EMPFOHLEN, alle Genauigkeitsschätzungen (einschließlich Toleranz, Geschwindigkeit und Höhe) als Teil jeder GPS-/GNSS-Positionsangabe zu melden.
- [C-SR] 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] Es WIRD DRINGEND EMPFOHLEN, GNSS-Pseudobereiche und Pseudobereichsraten zu 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 ausreichen, um in mindestens 95% der Fälle die Position innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0,2 Metern pro Sekunde zu berechnen.

7.3.4. Gyroskop

Geräteimplementierungen:

[C-SR] Es wird DRINGEND EMPFOHLEN, einen Gyroskopsensor einzubauen.

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

[C-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 50 Hz melden können.
[C-1-2] MÜSSEN den TYPE_GYROSCOPE-Sensor implementieren und es wird DRINGEND EMPFOHLEN, auch den TYPE_GYROSCOPE_UNCALIBRATED-Sensor zu implementieren.
[C-1-4] MUSS eine Auflösung von mindestens 12 Bit haben und SOLLTE eine Auflösung von mindestens 16 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] MUSS eine Varianz von höchstens 1e-7 rad^2 / s^2 pro Hz (Varianz pro Hz oder rad^2 / s) aufweisen. Die Varianz darf mit der Samplingrate variieren, MUSS aber durch diesen Wert begrenzt werden. Mit anderen Worten: Wenn Sie die Varianz des Gyroskops bei einer Abtastrate von 1 Hz messen, DÜRFTE sie nicht größer als 1e-7 rad²/s² sein.
[SR] Es wird DRINGEND EMPFOHLEN, dass der Kalibrierungsfehler weniger als 0,01 rad/s beträgt, wenn sich das Gerät bei Raumtemperatur in Ruhe befindet.
Sollte Ereignisse mit einer Frequenz von mindestens 200 Hz melden.

Wenn Geräteimplementierungen ein 3‑Achsen-Gyroskop, einen Beschleunigungsmesser und einen Magnetometer-Sensor enthalten, gilt Folgendes:

[C-2-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-3-1] MÜSSEN die Verbundsensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren.
[C-SR] Es wird DRINGEND EMPFOHLEN, den TYPE_GAME_ROTATION_VECTOR-Verbundsensor zu implementieren.

7.3.5. Barometer

Geräteimplementierungen:

[C-SR] Es wird DRINGEND EMPFOHLEN, ein Barometer (Sensor für den Umgebungsdruck) einzubauen.

Wenn Geräteimplementierungen ein Barometer enthalten,

[C-1-1] MÜSSEN den TYPE_PRESSURE-Sensor implementieren und melden.
[C-1-2] MUSS Ereignisse mit einer Frequenz von mindestens 5 Hz liefern können.
[C-1-3] MUSS temperaturkompensiert sein.
[SR] 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).

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, an der 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.

7.3.7. Fotometer

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, gilt Folgendes:

[C-1-1] MUSS die Nähe eines Objekts in derselben Richtung wie das Display messen. 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, zu erkennen, ob ein Nutzer ein Smartphone verwendet. 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.

7.3.9. Zuverlässige Sensoren

Wenn Geräteimplementierungen eine Reihe von Sensoren mit 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 SOLLTE einen Messbereich zwischen mindestens -16 g und +16 g haben.
- MUSS eine Messauflösung von mindestens 2048 LSB/g haben.
- MUSS eine Mindestmesshäufigkeit von 12,5 Hz oder weniger haben.
- MUSS eine maximale Messfrequenz von 400 Hz oder höher haben; SOLLTE den SensorDirectChannel RATE_VERY_FAST unterstützen.
- Das Messrauschen darf nicht über 400 μg/√Hz liegen.
- MUSS eine Nicht-Wake-up-Version dieses Sensors mit einer Pufferkapazität von mindestens 3.000 Sensorereignissen implementieren.
- MUSS einen Stromverbrauch für Batching von höchstens 3 mW haben.
- [C-SR] Es wird DRINGEND EMPFOHLEN, dass die 3-dB-Messbandbreite mindestens 80% der Nyquist-Frequenz und das Rauschen in diesem Frequenzbereich ein weißes Rauschen ist.
- SOLLTE bei Raumtemperatur einen Beschleunigungs-Random Walk von weniger als 30 μg √Hz haben.
- SOLLTE eine Bias-Änderung im Vergleich zur Temperatur von ≤ +/- 1 mg/°C haben.
- Die Nichtlinearität der Best-Fit-Linie SOLLTE ≤ 0,5 % und die Änderung der Empfindlichkeit 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 zwischen mindestens -1.000 und +1.000 dps haben.
- MUSS eine Messauflösung von mindestens 16 LSB/dps haben.
- MUSS eine Mindestmesshäufigkeit von 12,5 Hz oder weniger haben.
- MUSS eine maximale Messfrequenz von 400 Hz oder höher haben; SOLLTE den SensorDirectChannel RATE_VERY_FAST unterstützen.
- Das Messrauschen DARF nicht über 0,014°/s/√Hz liegen.
- [C-SR] Es wird DRINGEND EMPFOHLEN, dass die 3-dB-Messbandbreite mindestens 80% der Nyquist-Frequenz und das Rauschen in diesem Frequenzbereich ein weißes Rauschen ist.
- SOLLTE bei Raumtemperatur einen Rate Random Walk von weniger als 0,001 °/s √Hz 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.
- Die Querachsensensitivität SOLLTE im Betriebstemperaturbereich des Geräts < 4,0 % und die Querachsensensitivitätsabweichung < 0,3% betragen.
[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-Wake-up-Version dieses Sensors mit einer Pufferkapazität von mindestens 600 Sensorereignissen implementieren.
- [C-SR] Es wird DRINGEND EMPFOHLEN, ein Rauschen mit einem Spektrum von 1 Hz bis mindestens 10 Hz zu haben, 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] MÜSSEN 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] MÜSSEN einen TYPE_STEP_DETECTOR-Sensor haben, der:
- Es MUSS eine Nicht-Wake-up-Version dieses Sensors mit einer Pufferkapazität von mindestens 100 Sensorereignissen implementiert werden.
- 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 für das Batching MUSS mindestens 4 mW betragen.
[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 liegen. Der Ereigniszeitstempel desselben physischen Ereignisses, das vom Beschleunigungsmesser und vom Gyroskop gemeldet wird, SOLLTE sich innerhalb von 0,25 Millisekunden voneinander befinden.
[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 Proben 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, an Anwendungen liefern.
[C-2-16] DARF im statischen Zustand nicht mehr als 0,5 mW und im bewegten Zustand 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.

Beachten Sie, dass alle Anforderungen an den Stromverbrauch in diesem Abschnitt nicht den Stromverbrauch des Anwendungsprozessors umfassen. Dazu gehört auch der Stromverbrauch der gesamten Sensorkette, also des Sensors, der unterstützenden Schaltungen, des dedizierten Sensorverarbeitungssystems usw.

Wenn Geräteimplementierungen eine direkte Sensorunterstützung enthalten, gilt Folgendes:

[C-3-1] MUSS die Unterstützung von direkten Kanaltypen und direkten Berichtsraten korrekt über die API isDirectChannelTypeSupported und getHighestDirectReportRateLevel deklarieren.
[C-3-2] MUSS mindestens einen der beiden direkten Sensor-Kanaltypen für alle Sensoren unterstützen, die Unterstützung für den direkten Sensor-Kanal deklarieren.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
MUSS 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 der biometrischen Entsperrung 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 basierend auf ihren Akzeptanzraten für Spoofing und Betrüger sowie auf der Sicherheit der biometrischen Pipeline als Klasse 3 (früher Stark), Klasse 2 (früher Schwach) oder Klasse 1 (früher Nutzerfreundlichkeit) klassifiziert werden. Diese Klassifizierung bestimmt die Möglichkeiten, die der biometrische Sensor für die Interaktion mit der Plattform und mit Drittanbieteranwendungen hat. Sensoren werden standardmäßig als Klasse 1 eingestuft und müssen zusätzliche Anforderungen erfüllen, die unten aufgeführt sind, wenn sie als 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] MUSS die Anforderungen für biometrische Daten der Klasse 3 oder Klasse 2 gemäß Definition in diesem Dokument 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 anderen als die in Authenticators als öffentliche Konstanten dokumentierten Ganzzahlkonstanten und Kombinationen davon berücksichtigt oder erkannt werden, die an die Methoden canAuthenticate(int) und setAllowedAuthenticators(int) übergeben werden.
[C-4-3] Auf Geräten mit biometrischen Verfahren der Klasse 3 oder Klasse 2 MUSS die Aktion ACTION_BIOMETRIC_ENROLL implementiert werden. Bei dieser Aktion DÜRFEN NUR die Registrierungspunkte für biometrische Verfahren der Klasse 3 oder Klasse 2 angezeigt werden.

Wenn Geräteimplementierungen passive Biometrie unterstützen, gilt Folgendes:

[C-5-1] MUSS standardmäßig einen zusätzlichen Bestätigungsschritt (z.B. einen Tastendruck) erfordern.
[C-SR] Es wird DRINGEND EMPFOHLEN, eine Einstellung zu haben, mit der Nutzer die Anwendungseinstellung überschreiben und immer einen begleitenden Bestätigungsschritt anfordern können.
[C-SR] 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 Schaltfläche basiert, über einen reinen Eingabe-GPIO-Pin (General-Purpose Input/Output) eines sicheren Elements (SE) geleitet wird, der nur durch Drücken einer physischen Schaltfläche 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 festgelegt werden kann.

Wenn Geräteimplementierungen mehrere biometrische Sensoren haben, gilt Folgendes:

[C-SR] Es wird DRINGEND EMPFOHLEN, dass pro 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 Drittanbieteranwendungen den Zugriff auf Keystore-Schlüssel 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 tun:

[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. Außerdem MÜSSEN die Risiken der Aktivierung 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-3] Es MUSS eine Ratenbegrenzung für Versuche von mindestens 30 Sekunden nach fünf fehlgeschlagenen Versuchen zur biometrischen Überprüfung geben. Ein fehlgeschlagener Versuch ist ein Versuch mit einer angemessenen Erfassungsqualität (BIOMETRIC_ACQUIRED_GOOD), der nicht mit einem registrierten biometrischen Merkmal übereinstimmt.
[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 TEE gesichert 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).
[C-1-6] MUSS das individuelle Flag für das 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 auf neuen Geräten, die mit Android 10 eingeführt werden, mindestens alle 24 Stunden und auf Geräten, die von einer früheren Android-Version aktualisiert werden, mindestens alle 72 Stunden zur empfohlenen primären Authentifizierung (z.B. PIN, Muster, Passwort) aufgefordert werden.
[C-1-8] Der Nutzer MUSS nach einem der folgenden Ereignisse zur empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden:
- ein Zeitlimit von 4 Stunden für Inaktivität ODER
- 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.
Das Upgraden von Geräten von einer früheren Android-Version kann von C-1-8 ausgenommen werden. * [C-SR] Es wird DRINGEND EMPFOHLEN, die Logik im Framework des Android Open Source Project zu verwenden, um die in [C-1-7] und [C-1-8] für neue Geräte angegebenen Einschränkungen zu erzwingen. * [C-SR] Es wird DRINGEND EMPFOHLEN, dass die Falsch-Zurückweisungsrate auf dem Gerät gemessen weniger als 10 % beträgt. * [C-SR] Es wird DRINGEND EMPFOHLEN, dass die Latenz für jede registrierte biometrische Methode unter 1 Sekunde liegt. Die Latenz wird ab dem Zeitpunkt gemessen, an dem die biometrische Methode erkannt wird, bis das Display entsperrt wird.

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] Die Akzeptanzrate für Spoofing und Identitätsdiebstahl darf gemäß den Android Biometrics Test Protocols nicht höher als 20% sein.
[C-2-3] Die biometrische Abgleichung MUSS in einer isolierten Ausführungsumgebung außerhalb des Android-Nutzer- oder Kernelbereichs erfolgen, z. B. in der Trusted Execution Environment (TEE) oder auf einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung.
[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, wie in den Implementierungsrichtlinien auf der Android Open Source Project-Website dokumentiert.
[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 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 veränderbar sein.
[C-2-6] Drittanbieteranwendungen DÜRFEN NICHT zwischen einzelnen biometrischen Registrierungen unterscheiden können.
[C-2-7] Es DARF KEINEN unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder daraus abgeleitete Daten (z. B. Einbettungen) auf dem Anwendungsprozessor außerhalb des TEE geben.
[C-2-8] MUSS eine sichere Verarbeitungspipeline haben, 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.

Wenn Geräteimplementierungen bereits mit einer früheren Android-Version eingeführt wurden und die Anforderung C-2-8 nicht durch ein Systemsoftware-Update erfüllen können, KÖNNEN sie von der Anforderung ausgenommen werden.
[C-SR] Es wird DRINGEND EMPFOHLEN, die Lebenderkennung für alle biometrischen Modalitäten und die Aufmerksamkeitserkennung für die Gesichtserkennung zu verwenden.

Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 3 (früher Stark) behandeln möchten, müssen sie Folgendes erfüllen:

[C-3-1] MUSS alle Anforderungen von Klasse 2 oben erfüllen, mit Ausnahme von [C-1-7] und [C-1-8]. Geräte, die von einer früheren Android-Version aktualisiert werden, sind nicht von C-2-7 ausgenommen.
[C-3-2] MUSS eine hardwaregestützte Keystore-Implementierung haben.
[C-3-3] Die Akzeptanzrate für Spoofing und Identitätsdiebstahl darf gemäß den Android Biometrics Test Protocols nicht höher als 7% sein.
[C-3-4] Der Nutzer MUSS mindestens alle 72 Stunden zur empfohlenen primären Authentifizierung (z.B. PIN, Muster, Passwort) aufgefordert werden.

7.3.12. Pose Sensor

Geräteimplementierungen:

Unterstützt möglicherweise den Positionssensor 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.13. Sensor für Scharnierwinkel

Wenn Geräteimplementierungen einen Scharnierwinkelsensor unterstützen, gilt Folgendes:

[C-1-1] MÜSSEN TYPE_HINGLE_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 wakeup-Sensor zurückgeben.

7.4. Datenverbindung

7.4.1. Telefonie

„Telefonie“ bezieht sich in den Android-APIs und in diesem Dokument speziell auf Hardware, die zum Tätigen von Sprachanrufen und zum Senden von SMS-Nachrichten über ein GSM- oder CDMA-Netzwerk verwendet wird. Diese Sprachanrufe können paketvermittelt sein oder nicht, werden aber für Android unabhängig von einer Datenverbindung betrachtet, die möglicherweise über dasselbe Netzwerk implementiert wird. Die Android-Funktionen und APIs für Telefonie beziehen sich also speziell auf Sprachanrufe und SMS. Geräteimplementierungen, mit denen keine Anrufe getätigt oder SMS gesendet/empfangen werden können, gelten beispielsweise nicht als Telefoniegeräte, unabhängig davon, ob sie ein Mobilfunknetz für die Datenverbindung verwenden.

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, gilt Folgendes:

[C-1-1] MÜSSEN das android.hardware.telephony-Funktions-Flag und andere Unterfunktions-Flags entsprechend der Technologie deklarieren.
[C-1-2] MUSS die API für diese Technologie vollständig unterstützen.

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 eine vollständige Implementierung von EuiccManager API bereitstellen.

7.4.1.1. Kompatibilität der Nummernblockierung

Wenn Geräteimplementierungen android.hardware.telephony 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] ALLE Anrufe und Nachrichten von einer Telefonnummer in „BlockedNumberProvider“ MÜSSEN ohne Interaktion mit Apps blockiert werden. Die einzige Ausnahme ist, wenn die Nummernbereiche vorübergehend aufgehoben werden, wie in der SDK-Dokumentation beschrieben.
[C-1-4] Die App DARF NICHT in den Anruflistenanbieter der Plattform für einen blockierten Anruf schreiben.
[C-1-5] Der Telefonieanbieter darf bei einer blockierten Nachricht NICHT kontaktiert werden.
[C-1-6] Es MUSS eine Benutzeroberfläche zur Verwaltung blockierter Nummern implementiert werden, die mit dem von der Methode TelecomManager.createManageBlockedNumbersIntent() zurückgegebenen Intent geöffnet wird.
[C-1-7] Sekundäre Nutzer DÜRFEN die blockierten Nummern auf dem Gerät NICHT ansehen oder bearbeiten können, da die Android-Plattform davon ausgeht, dass der primäre Nutzer die vollständige Kontrolle über die Telefoniedienste auf dem Gerät hat. Die gesamte Benutzeroberfläche für das Blockieren MUSS für sekundäre 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.

7.4.1.2. Telecom API

Wenn Geräteimplementierungen android.hardware.telephony 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] 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 Pop-up-Benachrichtigung, die den Nutzer darüber informiert, dass durch das Annehmen eines eingehenden Anrufs der andere Anruf beendet wird.
[C-SR] Es wird DRINGEND EMPFOHLEN, die Standard-Dialer-App vorzuladen, in deren Anrufliste ein Anruflisteneintrag 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 setzt.
[C-SR] 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 Tastendruckereignisses erkannt wird.
- Rufen Sie Connection.onAnswer() auf, wenn während eines eingehenden Anrufs ein kurzes Drücken des Tastaturereignisses erkannt wird.
- Rufen Sie Connection.onReject() auf, wenn während eines eingehenden Anrufs ein langes Drücken des Tastaturereignisses erkannt wird.
- Stummschaltung des CallAudioState aktivieren oder deaktivieren.

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 Funktion 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] MUSS Multicast-DNS (mDNS) unterstützen und mDNS-Pakete (224.0.0.251) zu keinem Zeitpunkt filtern, einschließlich:
- Auch wenn der Bildschirm nicht aktiv ist.
- Bei Android TV-Geräteimplementierungen, auch im Standby-Modus.
[C-1-5] Der Aufruf der WifiManager.enableNetwork() API-Methode darf NICHT als ausreichender Hinweis darauf gewertet werden, dass die aktuell aktive Network, die standardmäßig für den 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 bestätigen, dass das WLAN einen Internetzugang bietet.
[C-1-6] Es wird DRINGEND EMPFOHLEN, bei Aufruf der ConnectivityManager.reportNetworkConnectivity() API-Methode 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. mobile Daten) zu wechseln, das Internetzugriff bietet.
[C-SR] Es wird DRINGEND EMPFOHLEN, die MAC‑Quelladresse und Sequenznummer von Frames zur Prüfungsanfrage einmal zu Beginn jedes Scans zu randomisieren, während die STA getrennt ist.
- Jede Gruppe mit Frames zur Prüfungsanfrage mit einen Scan SOLLTE eine gleichbleibende MAC‑Adresse verwenden (SOLLTE die MAC‑Adresse nicht nach der Hälfte des Scans randomisieren).
- Die Sequenznummer der Prüfungsanfrage sollte zwischen den Prüfungsanfragen in einem Scan als normal (sequenziell) iteriert werden.
- Die Sequenznummer der Prüfungsanfrage sollte zwischen der letzten Prüfungsanfrage eines Scans und der ersten Prüfungsanfrage des nächsten Scans randomisiert werden.
[C-SR] Es wird DRINGEND EMPFOHLEN, dass nur die folgenden Elemente in Probe Request-Frames zulässig sind, während die STA getrennt ist:
- SSID-Parametersatz (0)
- DS-Parametersatz (3)

Wenn Geräteimplementierungen die Unterstützung des WLAN-Energiesparmodus gemäß IEEE 802.11-Standard umfassen, gilt Folgendes:

[C-3-1] Der WLAN-Energiesparmodus MUSS deaktiviert werden, wenn eine App über die APIs WifiManager.createWifiLock() und WifiManager.WifiLock.acquire() den WIFI_MODE_FULL_HIGH_PERF- oder WIFI_MODE_FULL_LOW_LATENCY-Lock erhält und der Lock aktiv ist.
[C-3-2] Die durchschnittliche Paketumlaufzeit zwischen dem Gerät und einem Zugangspunkt muss im WLAN-Modus mit niedriger Latenz (WIFI_MODE_FULL_LOW_LATENCY) geringer sein als im WLAN-Modus mit hoher Leistung (WIFI_MODE_FULL_HIGH_PERF).
[C-SR] WIRD DRINGEND EMPFOHLEN, um die WLAN-Roundtrip-Latenz zu minimieren, wenn ein Low-Latency-Lock (WIFI_MODE_FULL_LOW_LATENCY) erfasst wird und wirksam wird.

Wenn Geräteimplementierungen WLAN unterstützen und WLAN für die Standortermittlung verwenden, gilt Folgendes:

[C-2-1] MUSS eine Möglichkeit für Nutzer bieten, das Lesen des Werts ü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] MUSS WLAN- und Wi‑Fi Direct-Vorgänge gleichzeitig unterstützen.

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 wird, 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 randomisiert werden, wenn Wi-Fi Aware aktiviert ist, es sei denn, es läuft gerade ein Aware-Entfernungsvorgang oder ein Aware-Datenpfad ist aktiv (die Randomisierung wird nicht erwartet, solange der Datenpfad aktiv ist).

Wenn Geräteimplementierungen Unterstützung für Wi-Fi Aware und Wi-Fi Location enthalten, wie in Abschnitt 7.4.2.5 beschrieben, und diese Funktionen für Drittanbieter-Apps verfügbar machen, dann:

[C-2-1] MUSS die standortbezogenen Erkennungs-APIs setRangingEnabled, setMinDistanceMm, setMaxDistanceMm und onServiceDiscoveredWithinRange implementieren.

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).

Wenn Geräteimplementierungen keine Unterstützung für Wi‑Fi Passpoint enthalten:

[C-2-1] Die Implementierung der Passpoint-bezogenen WifiManager-APIs MUSS eine UnsupportedOperationException auslösen.

7.4.2.5. WLAN-Standort (WLAN-Umlaufzeit – RTT)

Geräteimplementierungen:

SOLLTE Unterstützung für WLAN-Standort enthalten.

Wenn Geräteimplementierungen die Unterstützung für WLAN-Standort 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.

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-Keep-Alive-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] MUSS mindestens drei gleichzeitige Keep-Alive-Slots über WLAN und mindestens einen Keep-Alive-Slot über Mobilfunk unterstützen.

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 die 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.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] MUSS die Hardwarefunktion android.hardware.bluetooth_le deklarieren.
[C-3-2] MÜSSEN die GATT-basierten (Generic Attribute Profile) Bluetooth-APIs wie in der SDK-Dokumentation und unter android.bluetooth beschrieben aktiviert werden.
[C-3-3] MUSS den richtigen Wert für BluetoothAdapter.isOffloadedFilteringSupported() melden, um anzugeben, ob die Filterlogik für die ScanFilter-API-Klassen implementiert ist.
[C-3-4] Der korrekte Wert für BluetoothAdapter.isMultipleAdvertisementSupported() MUSS angegeben werden, 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 und die Adresse nach Ablauf des Zeitlimits 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 randomisiert werden.
Die Auslagerung der Filterlogik auf den Bluetooth-Chipsatz SOLLTE unterstützt werden, wenn die ScanFilter API implementiert wird.
Sollte das Auslagern des Batch-Scans 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] Es MUSS eine Möglichkeit für Nutzer geben, 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.

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 deklariert wird, 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 über die folgenden NFC-Standards als NFC-Forum-Lesegerät/Schreibgerät fungieren können (gemäß der technischen Spezifikation NFCForum-TS-DigitalProtocol-1.0 des NFC-Forums):
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- NFC Forum Tag Types 1, 2, 3, 4, 5 (definiert vom NFC-Forum)
[SR] 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 vorhandene und neue Geräte, auf denen diese Android-Version ausgeführt wird, diese Anforderungen jetzt erfüllen, damit sie auf zukünftige Plattformversionen aktualisiert werden können.
[C-1-13] Im NFC-Erkennungsmodus MUSS nach allen unterstützten Technologien gesucht werden.
Das Gerät SOLLTE sich im NFC-Erkennungsmodus befinden, wenn es aktiv ist, das Display eingeschaltet und der Sperrbildschirm entsperrt ist.
Sollte den Barcode und die URL (falls codiert) von Thinfilm NFC Barcode-Produkten lesen können.

Öffentlich verfügbare Links sind für die oben genannten Spezifikationen von JIS, ISO und NFC Forum nicht verfügbar.

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 ID, AID) 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 gemäß diesem Abschnitt und die MIFARE-Technologien (MIFARE Classic, MIFARE Ultralight, NDEF on 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 eine oder mehrere Formen der Datenvernetzung enthalten. Geräteimplementierungen MÜSSEN mindestens einen Datenstandard mit einer Geschwindigkeit von mindestens 200 Kbit/s unterstützen. 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 sicherstellen, 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 eine Verbindung zu einem IPv6-Netzwerk besteht, 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 mobile Daten)

[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 bieten, gilt Folgendes:

[C-1-1] MUSS eine Captive Portal-Anwendung bereitstellen, um den Intent ACTION_CAPTIVE_PORTAL_SIGN_IN zu verarbeiten und die Captive Portal-Anmeldeseite anzuzeigen, indem dieser Intent beim Aufruf der System-API ConnectivityManager#startCaptivePortalApp(Network, Bundle) gesendet wird.
[C-1-2] Das Gerät MUSS Captive Portals erkennen und die Anmeldung über die Captive Portal-App unterstützen, wenn es 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 Nur-Text-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 den gesamten Netzwerkverkehr 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 und 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 Einstellung für die automatische Hauptsynchronisierung 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:

[SR] Es wird DRINGEND EMPFOHLEN, den Datensparmodus bereitzustellen.

Wenn Geräteimplementierungen den Datensparmodus bereitstellen, 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] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED darf nicht übertragen werden.

7.4.8. Secure Elements

Wenn Geräteimplementierungen sichere Elemente unterstützen, die mit der Open Mobile API kompatibel sind, und sie Drittanbieter-Apps zur Verfügung stellen, gilt Folgendes:

[C-1-1] Die verfügbaren Secure Element-Lesegeräte MÜSSEN über die android.se.omapi.SEService.getReaders() API aufgelistet werden.
[C-1-2] MUSS die richtigen Feature-Flags ü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 deklarieren.

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 drei 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 Fotos 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 Metadaten an die empfangende Anwendung sendet, wenn die empfangende Anwendung nicht über ACCESS_FINE_LOCATION verfügt.

7.5.1. Rückkamera

Eine nach hinten gerichtete Kamera befindet sich auf der Seite des Geräts, die dem Display gegenüberliegt. Sie nimmt Bilder von Szenen auf der gegenüberliegenden Seite des Geräts auf, wie eine herkömmliche Kamera.

Geräteimplementierungen:

Eine nach hinten gerichtete Kamera SOLLTE vorhanden sein.

Wenn Geräteimplementierungen mindestens eine nach hinten gerichtete Kamera enthalten, gilt Folgendes:

[C-1-1] MÜSSEN die Funktions-Flags android.hardware.camera und android.hardware.camera.any melden.
[C-1-2] MUSS eine Auflösung von mindestens 2 Megapixeln haben.
Sollte entweder Hardware-Autofokus oder Software-Autofokus im Kameratreiber implementiert sein (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 Frontkamera befindet sich auf derselben Seite des Geräts wie das Display. Sie wird in der Regel verwendet, um den Nutzer zu filmen, z. B. für Videokonferenzen und ähnliche Anwendungen.

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 die Funktions-Flags 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] Eine 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 relativ zur von der Anwendung angegebenen Ausrichtung gedreht wird. Umgekehrt MUSS die Vorschau entlang 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 an Anwendungs-Callbacks zurückgegebenen oder im Medienspeicher gespeicherten Videostreams 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 Eingabe des Nutzers):

[C-2-1] Die Kameravorschau MUSS horizontal gespiegelt werden, bezogen auf die aktuelle Ausrichtung des Geräts.

7.5.3. Externe Kamera

Geräteimplementierungen:

MÖGLICHERWEISE wird eine externe Kamera unterstützt, die nicht unbedingt immer verbunden ist.

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] MUSS USB Video Class (UVC 1.0 oder höher) unterstützen, wenn die externe Kamera über den USB-Host-Port verbunden wird.
[C-1-3] MUSS die CTS-Tests für Kameras bestehen, wenn ein physisches externes Kameragerät angeschlossen ist. Details zum CTS-Test der Kamera 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. Roh- 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äteimplementierungen MÜSSEN die fortlaufende Unterstützung der API gewährleisten, wie in diesem Abschnitt und im Android SDK beschrieben.

Alle Funktionen, die in der eingestellten Klasse „android.hardware.Camera“ und im neueren Paket „android.hardware.camera2“ vorhanden sind, MÜSSEN in beiden APIs eine gleichwertige Leistung und Qualität bieten. Bei gleichwertigen Einstellungen müssen beispielsweise die 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 noch nie android.hardware.Camera.Parameters.setPreviewFormat(int) 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 Methode onPreviewFrame() 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 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 keine Relevanz hat. Das gilt auch für Frontkameras. Auch wenn die meisten Frontkameras keinen Autofokus unterstützen, müssen die API-Rückrufe 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. Geräteimplementierungen, die die Aufnahme von Bildern mit HDR-Bildgebungstechniken (High Dynamic Range) unterstützen, MÜSSEN beispielsweise 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] MUSS auch die einzelnen Kamerafunktionen von android.hardware.camera2 über die android.request.availableCapabilities-Property 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 senden, wenn ein neues Bild mit 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 Media Store 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 oder der Glättung der Gesichtshaut für eine android.hardware.camera2- oder android.hardware.Camera-API.
[C-SR] Für Geräte mit mehreren RGB-Kameras, die 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, als physische Untergeräte.

Wenn Geräteimplementierungen Drittanbieter-Apps eine proprietäre Kamera-API zur Verfügung stellen, gilt Folgendes:

[C-1-1] Eine solche Kamera-API MUSS mit der android.hardware.camera2 API implementiert werden.
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. Wenn das Gerät im Querformat gehalten wird, MÜSSEN die 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.

7.6. Arbeitsspeicher und Datenspeicher

7.6.1. Mindestspeicher und ‑arbeitsspeicher

Geräteimplementierungen:

[C-0-1] MUSS einen Download-Manager enthalten, den Anwendungen zum Herunterladen von Datendateien verwenden KÖNNEN. Außerdem MÜSSEN einzelne Dateien mit einer Größe von mindestens 100 MB an den Standard-Cache-Speicherort heruntergeladen werden können.

7.6.2. Shared Storage für Anwendungen

Geräteimplementierungen:

[C-0-1] MUSS einen von Anwendungen gemeinsam genutzten Speicher anbieten, der auch als „freigegebener externer Speicher“, „von Anwendungen gemeinsam genutzter Speicher“ oder als der Linux-Pfad „/sdcard“ bezeichnet wird, auf dem er bereitgestellt wird.
[C-0-2] MUSS standardmäßig mit eingebundenem gemeinsam genutzten 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. SD-Kartensteckplatz) implementiert ist.
[C-0-3] MUSS den freigegebenen Speicher der Anwendung direkt im Linux-Pfad sdcard einbinden oder einen symbolischen Linux-Link von sdcard zum tatsächlichen Mount-Punkt einfügen.
[C-0-4] MÜSSEN scoped storage 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 unkenntlich gemacht werden, wenn über MediaStore auf diese Dateien 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 herausnehmbaren) 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 angegeben sein, 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 freigegebenen internen 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] MUSS ein Verfahren zum Zugriff auf die Daten im freigegebenen Speicher der Anwendung von einem Hostcomputer aus bereitstellen.
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 Referenz-Android-MTP-Host Android File Transfer kompatibel sein.
Sollte die USB-Geräteklasse 0x00 melden.
Sollte den USB-Schnittstellennamen „MTP“ melden.

7.6.3. Verwendbarer Speicher

Wenn das Gerät voraussichtlich mobil ist, im Gegensatz zu einem Fernseher, sind die Geräteimplementierungen:

[SR] Es wird DRINGEND EMPFOHLEN, den adoptable storage 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, sind die Geräteimplementierungen:

[SR] Es wird DRINGEND EMPFOHLEN, adoptable storage zu implementieren.

7.7. USB

Wenn Geräteimplementierungen einen USB-Anschluss haben, gilt Folgendes:

SOLLTE den USB-Peripheriemodus und den USB-Hostmodus unterstützen.

7.7.1. USB-Peripheriemodus

Wenn Geräteimplementierungen einen USB-Anschluss enthalten, der den Peripheriemodus unterstützt:

[C-1-1] Der Port MUSS mit einem USB-Host verbunden werden können, der einen Standard-USB-Port vom Typ A oder Typ C hat.
[C-1-2] MUSS den korrekten Wert von iSerialNumber im USB-Standardgerätedeskriptor über android.os.Build.SERIAL melden.
[C-1-3] MUSS Ladegeräte mit 1,5 A und 3,0 A gemäß dem Typ‑C-Widerstandsstandard erkennen und MUSS Änderungen in der Ankündigung erkennen, wenn sie Typ‑C-USB unterstützen.
[SR] Der Port SOLLTE den USB-Formfaktor Micro-B, Micro-AB oder Typ C verwenden. Für bestehende und neue Android-Geräte WIRD DRINGEND EMPFOHLEN, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen aktualisiert werden können.
[SR] Der Anschluss SOLLTE sich unten am Gerät befinden (entsprechend der natürlichen Ausrichtung) oder die Software-Bildschirmdrehung für alle Apps (einschließlich des Startbildschirms) ermöglichen, damit das Display korrekt dargestellt wird, wenn das Gerät mit dem Anschluss unten ausgerichtet ist. Für bestehende und neue Android-Geräte WIRD DRINGEND EMPFOHLEN, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen aktualisiert werden können.
[SR] Das Gerät SOLLTE die Möglichkeit bieten, während des HS-Chirps und des Traffics einen Strom von 1,5 A zu ziehen, wie in der USB Battery Charging Specification, Revision 1.2 beschrieben. Für bestehende und neue Android-Geräte WIRD DRINGEND EMPFOHLEN, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen aktualisiert werden können.
[SR] Es wird DRINGEND EMPFOHLEN, keine proprietären Lademethoden zu unterstützen, die die Vbus-Spannung über die Standardwerte hinaus ändern oder die Sink-/Source-Rollen ändern, da dies zu Interoperabilitätsproblemen mit Ladegeräten oder Geräten führen kann, die die standardmäßigen USB Power Delivery-Methoden unterstützen. Auch wenn dies als „DRINGEND EMPFOHLEN“ gekennzeichnet ist, kann es sein, dass wir in zukünftigen Android-Versionen vorschreiben, dass alle Typ‑C-Geräte die vollständige Interoperabilität mit Standard-Typ‑C-Ladegeräten unterstützen müssen.
[SR] Es wird DRINGEND EMPFOHLEN, Power Delivery für den Rollentausch von Daten und Strom zu unterstützen, wenn das Gerät USB Typ-C und den USB-Hostmodus unterstützt.
Sollte Power Delivery für das Laden mit hoher Spannung und alternative Modi wie die Bildschirmausgabe unterstützen.
Sollte die Android Open Accessory (AOA) API und Spezifikation wie in der Android SDK-Dokumentation beschrieben implementieren.

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 Strings iInterface 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 Unterstützung für den Anschluss von Standard-USB-Peripheriegeräten implementieren, d. h., es MUSS entweder:
- Ein Typ-C-Anschluss am Gerät oder ein Kabel, das einen proprietären Anschluss am Gerät in einen Standard-USB-Typ-C-Anschluss umwandelt (USB-Typ-C-Gerät).
- Sie haben einen Typ A-Anschluss oder werden mit Kabeln geliefert, die einen proprietären Anschluss des Geräts an einen Standard-USB-Typ A-Anschluss anpassen.
- Das Gerät muss einen Micro-AB-Port haben, der mit einem Kabel geliefert wird, das an einen Standard-Typ-A-Port 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 Typ‑C-Port (Buchse) umwandelt.
[C-SR] Die Implementierung der USB-Audioklasse gemäß der Android SDK-Dokumentation wird DRINGEND EMPFOHLEN.
Das angeschlossene USB-Peripheriegerät sollte im Hostmodus aufgeladen 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 beworben 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, die in den USB HID Usage Tables und der Voice Command Usage Request angegeben sind, zu den KeyEvent-Konstanten wie unten unterstützen:
- 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
- Usage Page (0xC) Usage 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 Typ‑C unterstützt, gilt Folgendes:

[C-4-1] MUSS die Dual Role Port-Funktionalität gemäß der USB Typ‑C-Spezifikation (Abschnitt 4.5.1.3.3) implementiert werden.
[SR] Es wird DRINGEND EMPFOHLEN, DisplayPort zu unterstützen. Es SOLLTEN USB-SuperSpeed-Datenraten unterstützt werden und es wird DRINGEND EMPFOHLEN, Power Delivery für das Tauschen von Daten- und Stromversorgungsrollen zu unterstützen.
[SR] Es wird DRINGEND EMPFOHLEN, den Audioadapter-Zubehörmodus NICHT zu unterstützen, wie in Anhang A der USB Type-C Cable and Connector Specification Revision 1.2 beschrieben.
Es SOLLTE das Try.*-Modell implementiert werden, das am besten für den Geräteformfaktor geeignet ist. Ein tragbares Gerät SOLLTE beispielsweise das Try.SNK-Modell implementieren.

7.8. Audio

7.8.1. Mikrofon

Wenn Geräteimplementierungen ein Mikrofon enthalten, müssen sie folgende Anforderungen erfüllen:

[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.
[SR] Es wird DRINGEND EMPFOHLEN, die Aufnahme 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.
[SR] 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 Audioausgangsanschluss 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-Op 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äteimplementierungen mit Headsets und anderem Audiozubehör kompatibel sind, die den 3,5‑mm-Audiostecker im gesamten Android-Ökosystem verwenden, gilt Folgendes, wenn sie einen oder mehrere analoge Audioanschlüsse enthalten:

[C-SR] 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 Stereo-Kopfhö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 äquivalenten Impedanz zwischen den Mikrofon- und 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 bei 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 Audio-Stecker erkennen und zuordnen:
- 110–180 Ohm:KEYCODE_VOICE_ASSIST
[C-SR] Es wird DRINGEND EMPFOHLEN, Audio-Stecker mit der OMTP-Pinbelegung zu unterstützen.
[C-SR] Es wird DRINGEND EMPFOHLEN, die Audioaufnahme über Stereo-Headsets mit Mikrofon zu unterstützen.

Wenn Geräteimplementierungen einen 3, 5‑mm-Audioanschluss mit 4 Leitern haben und ein Mikrofon unterstützen und android.intent.action.HEADSET_PLUG mit dem zusätzlichen Wert „Mikrofon“ auf 1 gesetzt wird, gilt Folgendes:

[C-2-1] MUSS die Erkennung des Mikrofons am angeschlossenen Audiozubehör unterstützen.

7.8.2.2. Digitale Audioanschlüsse

Um mit Headsets und anderem Audiozubehör mit USB‑C-Anschlüssen kompatibel zu sein, die (USB-Audioklasse) im gesamten Android-Ökosystem gemäß der Android USB headset specification implementieren.

Gerätespezifische Anforderungen finden Sie im Abschnitt 2.2.1.

7.8.3. Nahe am Ultraschall

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 „true“ 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 MUSS mindestens 50 dB betragen.

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 MUSS mindestens 40 dB unter der Reaktion bei 2 kHz liegen.

7.8.4. Signalintegrität

Geräteimplementierungen: * Sollten sowohl für Ein- als auch für Ausgabestreams auf Mobilgeräten einen störungsfreien Audiosignalpfad bieten, wie durch null Störungen definiert, die während eines einminütigen Tests pro Pfad gemessen werden. Testen Sie mit [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) „Automated Glitch Test“.

Für den Test ist ein Audio-Loopback-Dongle erforderlich, der direkt in einer 3,5‑mm-Buchse und/oder in Kombination mit einem USB‑C-auf-3,5‑mm-Adapter verwendet wird. Alle Audioausgabeports SOLLTEN getestet werden.

OboeTester unterstützt derzeit AAudio-Pfade. Daher SOLLTEN die folgenden Kombinationen mit AAudio auf Glitches getestet werden:

Perf-Modus	Teilen	Out Sample Rate	In Chans	Out-Chans
LOW_LATENCY	EXKLUSIVE	KEINE ANGABE	1	2
LOW_LATENCY	EXKLUSIVE	KEINE ANGABE	2	1
LOW_LATENCY	Weiterempfohlen	KEINE ANGABE	1	2
LOW_LATENCY	Weiterempfohlen	KEINE ANGABE	2	1
KEINE	Weiterempfohlen	48000	1	2
KEINE	Weiterempfohlen	48000	2	1
KEINE	Weiterempfohlen	44100	1	2
KEINE	Weiterempfohlen	44100	2	1
KEINE	Weiterempfohlen	16000	1	2
KEINE	Weiterempfohlen	16000	2	1

Ein zuverlässiger Stream SOLLTE die folgenden Kriterien für das Signal-Rausch-Verhältnis (SNR) und die Gesamtharmonische 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 ordnungsgemäß implementieren.

7.9.1. Virtual Reality-Modus

Android unterstützt den VR-Modus. Diese Funktion übernimmt das stereoskopische Rendern von Benachrichtigungen und deaktiviert monokulare System-UI-Komponenten, während 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] Es wird DRINGEND EMPFOHLEN, OpenGL ES 3.2 zu 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] 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] Es wird DRINGEND EMPFOHLEN, Vulkan 1.1 zu unterstützen.
[C-SR] 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] 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 gemeinsamen Front-Buffer so synchronisieren können, dass die abwechselnde Darstellung von VR-Inhalten für das linke und rechte Auge mit 60 fps mit zwei Renderkontexten ohne sichtbare Tearing-Artefakte erfolgt.
[C-1-9] MÜSSEN die Unterstützung für die 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 AHardwareBuffer mit einer beliebigen Kombination der Nutzungs-Flags 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] 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 3840 × 2160 bei 30 fps unterstützen, komprimiert auf durchschnittlich 40 Mbit/s (entspricht 4 Instanzen von 1920 × 1080 bei 30 fps und 10 Mbit/s oder 2 Instanzen von 1920 × 1080 bei 60 fps und 20 Mbit/s).
[C-1-12] MUSS HEVC und VP9 unterstützen und mindestens 1920 × 1080 bei 30 fps mit einer durchschnittlichen Komprimierung von 10 Mbit/s decodieren können. Das Gerät SOLLTE 3840 × 2160 bei 30 fps mit einer durchschnittlichen Komprimierung von 20 Mbit/s decodieren können (entspricht 4 Instanzen von 1920 × 1080 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 1.920 × 1.080 betragen.
[C-SR] 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 Zeit 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] 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 gemäß Abschnitt 7.3.9 erfüllen.
[C-SR] 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] Es wird DRINGEND EMPFOHLEN, dass die End-to-End-Latenz zwischen Bewegung und Photon nicht höher als 20 Millisekunden ist.
[C-1-23] Das Verhältnis des ersten Frames, also 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 Steady State, MUSS mindestens 85 % betragen.
[C-SR] Es wird DRINGEND EMPFOHLEN, ein First-Frame-Verhältnis von mindestens 90 % zu haben.
MAY kann einen exklusiven Kern für die Vordergrundanwendung bereitstellen und MAY kann die Process.getExclusiveCores API unterstützen, um die Anzahl der CPU-Kerne zurückzugeben, die exklusiv für die oberste Vordergrundanwendung reserviert sind.

Wenn der exklusive Kern unterstützt wird, gilt Folgendes:

[C-2-1] Auf dem Prozessor dürfen keine anderen Userspace-Prozesse ausgeführt werden (mit Ausnahme von Gerätetreibern, die von der Anwendung verwendet werden). Es dürfen jedoch einige Kernelprozesse ausgeführt werden, sofern dies erforderlich ist.

7.10. Haptik

Gerätespezifische Anforderungen finden Sie im Abschnitt 2.2.1.

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 Performance Class werden 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 tragbares Gerät sein.
[C-1-3] MUSS alle Anforderungen für die „Media Performance Class“ erfüllen, die in Abschnitt 2.2.7 beschrieben sind.

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.2.7.

8. Leistung und Energie

Einige Mindestkriterien für Leistung und Stromverbrauch 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 Nutzererfahrung

Eine reibungslose 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 einheitliche Dateizugriffsleistung im privaten Datenspeicher der Anwendung (/data-Partition) ermöglicht es App-Entwicklern, eine angemessene Erwartung festzulegen, die ihnen bei der Softwareentwicklung hilft. Je nach Gerätetyp KÖNNEN Geräteimplementierungen 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 großen Datei mit einem 10 MB großen Schreibpuffer.
Leistung beim zufälligen Schreiben. Gemessen durch Schreiben einer 256 MB großen Datei mit einem 4 KB großen 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-Datei mit einem 4-KB-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 Funktionen erweitern, die keine strengeren Einschränkungen als der seltene App-Standby-Bucket auferlegen, gilt Folgendes:

[C-1-1] Die Trigger-, Wartungs- und Weckalgorithmen sowie die Verwendung globaler Systemeinstellungen der App-Standby- und Doze-Energiesparmodi DÜRFEN NICHT von der AOSP-Implementierung abweichen.
[C-1-2] Die Verwendung globaler Einstellungen zum Verwalten der Drosselung von Jobs, Alarmen und Netzwerken für Apps in den einzelnen App-Standby-Buckets darf NICHT von der AOSP-Implementierung abweichen.
[C-1-3] Die Anzahl der für den App-Standby verwendeten App-Standby-Buckets 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-SR] Es wird DRINGEND EMPFOHLEN, dem Nutzer die Möglichkeit zu geben, den Energiesparmodus zu aktivieren und zu deaktivieren.
[C-SR] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, alle Apps anzuzeigen, die von den Energiesparmodi „App-Standby“ und „Doze“ ausgenommen sind.

Wenn Geräteimplementierungen die in AOSP enthaltenen Funktionen zur Energieverwaltung erweitern und diese Erweiterung strengere Einschränkungen als der Standby-Bucket „Selten verwendet“ mit sich bringt, 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] MUSS nur in diesen Status wechseln, 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 über FLAG_KEEP_SCREEN_ON anfordern, dass der Bildschirm eingeschaltet bleibt, oder über PARTIAL_WAKE_LOCK, dass die CPU weiter ausgeführt wird, DARF das Gerät NICHT in den S3-Status wechseln, es sei denn, der Nutzer hat, wie in C-1-1 beschrieben, explizit Maßnahmen ergriffen, um das Gerät in einen inaktiven Status zu versetzen. Wenn hingegen 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 Status versetzt. Dies sind keine umfassenden Beispiele. AOSP implementiert umfangreiche Wecksignale, die ein Aufwachen aus diesem Zustand auslösen.

8.4. Stromverbrauchsabrechnung

Eine genauere Abrechnung und Berichterstellung des Stromverbrauchs bietet dem App-Entwickler sowohl Anreize als auch Tools zur Optimierung des Stromverbrauchs der Anwendung.

Geräteimplementierungen:

[SR] Es wird DRINGEND EMPFOHLEN, ein Energieprofil pro 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.
[SR] Es wird DRINGEND EMPFOHLEN, alle Werte zum Stromverbrauch in Milliamperestunden (mAh) anzugeben.
[SR] 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.
[SR] ES WIRD DRINGEND EMPFOHLEN, diese Informationen zur 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 der 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 die Unterstützung des Modus für nachhaltige Leistung melden, 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:

Sollte mindestens einen exklusiven Kern bereitstellen, 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.

9. Kompatibilität des Sicherheitsmodells

Geräteimplementierungen:

[C-0-1] MÜSSEN ein Sicherheitsmodell implementieren, das mit dem Sicherheitsmodell der Android-Plattform übereinstimmt, wie im Referenzdokument zu Sicherheit und Berechtigungen in der Android-Entwicklerdokumentation für die 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. Kompatible Geräte MÜSSEN die in den folgenden Unterabschnitten beschriebenen Sicherheitsmechanismen unterstützen.

9.1. Berechtigungen

Geräteimplementierungen:

[C-0-1] MÜSSEN das Android-Berechtigungsmodell unterstützen, wie in der Android-Entwicklerdokumentation definiert. Insbesondere MÜSSEN sie jede Berechtigung wie in der SDK-Dokumentation beschrieben erzwingen. Berechtigungen dürfen nicht 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 gewährt werden, die im privilegierten Pfad des System-Images vorinstalliert sind, und nur innerhalb der Teilmenge der explizit auf die Zulassungsliste gesetzten Berechtigungen für jede App. Die AOSP-Implementierung erfüllt diese Anforderung, indem sie die auf die Zulassungsliste gesetzten 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.

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 anzeigen, über die der Nutzer entscheiden kann, ob er die angeforderten Laufzeitberechtigungen erteilen möchte. Außerdem MUSS eine Benutzeroberfläche zur Verwaltung von Laufzeitberechtigungen bereitgestellt werden.
[C-0-4] MUSS genau eine Implementierung beider Benutzeroberflächen haben.
[C-0-5] Vorinstallierte Apps DÜRFEN keine Laufzeitberechtigungen erhalten, es sei denn:
- Die Einwilligung des Nutzers kann eingeholt werden, bevor die Anwendung die Daten verwendet.
- Die Laufzeitberechtigungen sind einem Intent-Muster zugeordnet, für das die vorinstallierte Anwendung als Standard-Handler festgelegt ist.
[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-Standortberechtigung einhalten, wenn eine App Standort- oder Daten zu körperlichen Aktivitäten über die Standard-Android-API oder einen proprietären Mechanismus anfordert. Dazu gehören unter anderem:
- Standort des Geräts (z.B. Breiten- und Längengrad).
- Informationen, die verwendet werden können, um den Standort des Geräts zu ermitteln 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 Einwilligung des Nutzers MUSS eingeholt werden, damit eine App auf Standort- oder Daten zu körperlichen Aktivitäten 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.

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 gewährt werden, wenn:
- 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 haben und DÜRFEN erst dann vollen Zugriff erhalten, wenn sie wie im SDK beschrieben auf die Zulassungsliste gesetzt werden. Dort wird für jede softRestricted-Berechtigung (z. B. READ_EXTERNAL_STORAGE) voller und eingeschränkter Zugriff definiert.

Wenn Geräteimplementierungen eine Möglichkeit für Nutzer bieten, auszuwählen, welche Apps über anderen Apps mit einer Aktivität, die den ACTION_MANAGE_OVERLAY_PERMISSION-Intent verarbeitet, angezeigt werden können, gilt Folgendes:

[C-2-1] MUSS dafür sorgen, dass alle Aktivitäten mit Intent-Filtern für den ACTION_MANAGE_OVERLAY_PERMISSION-Intent denselben UI-Bildschirm haben, unabhängig von der initiierenden App oder den von ihr bereitgestellten Informationen.

9.2. UID und Prozessisolation

Geräteimplementierungen:

[C-0-1] MUSS das Android-App-Sandbox-Modell unterstützen, in dem jede App 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 das Android-Sicherheits- und Berechtigungsmodell 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. Mit anderen Worten:

[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 KEINEN Zugriff auf Ressourcen erhalten, die durch Berechtigungen geschützt sind, die nicht in der AndroidManifest.xml-Datei der Laufzeitumgebung angefordert werden.
[C-0-3] Alternative Runtimes 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 Runtimes MÜSSEN das Android-Sandbox-Modell einhalten und installierte Anwendungen, die eine alternative Runtime verwenden, DÜRFEN die Sandbox keiner anderen auf dem Gerät installierten App 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 Superuser-Berechtigungen (Root) oder Berechtigungen einer anderen Nutzer-ID gestartet werden, solche Berechtigungen erhalten oder anderen Anwendungen erteilen.
[C-0-7] Wenn die .apk-Dateien alternativer Runtimes im System-Image 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 Einwilligung des Nutzers 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 Anwendungsfunktionen nicht auf diese Weise aufzeichnet, MUSS sie bei der Installation einer Anwendung mit dieser Laufzeit alle Berechtigungen auflisten, die die Laufzeit selbst hat.
Alternative Runtimes SOLLTEN Apps über 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.

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 mehrere Nutzer umfassen, gilt Folgendes:

[C-1-1] MUSS die folgenden Anforderungen in Bezug auf die Unterstützung mehrerer Nutzer erfüllen.
[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 Anwendungsspeicher (auch als /sdcard bezeichnet) 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 entfernbaren Medien gespeichert ist, auf die nur das System zugreifen kann, wenn Geräteimplementierungen entfernbare Medien für die APIs für externen Speicher verwenden. Da die Medien dadurch für einen Host-PC unlesbar werden, 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.

9.6. Warnung zu Premium-SMS

Android unterstützt die Warnung von Nutzern vor ausgehenden Premium-SMS-Nachrichten. Premium-SMS sind Textnachrichten, die an einen bei einem Mobilfunkanbieter registrierten Dienst gesendet werden und für den dem Nutzer möglicherweise Kosten entstehen.

Wenn Geräteimplementierungen Unterstützung für android.hardware.telephony deklarieren, gilt Folgendes:

[C-1-1] MUSS Nutzer warnen, bevor eine SMS an Nummern gesendet wird, die durch reguläre Ausdrücke identifiziert werden, die in der /data/misc/sms/codes.xml-Datei 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 Einhaltung der Sicherheitsfunktionen sowohl im Kernel als auch auf der Plattform wie unten beschrieben sicherstellen.

Die Android-Sandbox umfasst Funktionen, die das obligatorische Zugriffssteuerungssystem (MAC) von Security-Enhanced Linux (SELinux), Seccomp-Sandboxing und andere Sicherheitsfunktionen im Linux-Kernel verwenden. Geräteimplementierungen:

[C-0-1] Die Kompatibilität mit vorhandenen Anwendungen MUSS aufrechterhalten werden, auch wenn SELinux oder andere Sicherheitsfunktionen unter dem Android-Framework implementiert sind.
[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. Sie DARF jedoch eine sichtbare Benutzeroberfläche haben, 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 eine andere Anwendung über eine API (z. B. eine Geräteadministrator-API) beeinflussen kann, DARF NICHT zulassen, dass eine Richtlinie konfiguriert wird, 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 wie auf der Android Open Source Project-Website beschrieben genauer gewährt werden kann.
[C-0-6] MUSS einen Kernel-Anwendungssandboxing-Mechanismus implementieren, der das Filtern von Systemaufrufen mithilfe einer konfigurierbaren Richtlinie aus Multithread-Programmen ermöglicht. Das Upstream-Android Open Source Project erfüllt diese Anforderung, indem seccomp-BPF mit Threadgroup Synchronization (TSYNC) aktiviert wird, wie im Abschnitt „Kernel Configuration“ 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. CONFIG_DEBUG_RODATA oder CONFIG_STRICT_KERNEL_RWX).
[C-0-9] Auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden, MUSS eine statische und dynamische Prüfung der Objektgrößenbegrenzungen von Kopien zwischen Nutzer- und Kernelbereich (z.B. CONFIG_HARDENED_USERCOPY) implementiert werden.
[C-0-10] Auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden, DARF bei der Ausführung im Kernelmodus (z.B. Hardware-PXN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) KEIN Nutzerspeicher ausgeführt werden.
[C-0-11] Auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden, DARF der Kernel den Arbeitsspeicher des Nutzerbereichs nicht außerhalb der normalen Usercopy-Zugriffs-APIs (z.B. Hardware-PAN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) lesen oder schreiben.
[C-0-12] Die Kernel-Seitentabellenisolation MUSS implementiert 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] Die Hardware MUSS Branch-Prediction-Hardening implementieren, wenn sie auf allen Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden (z.B. CONFIG_HARDEN_BRANCH_PREDICTOR), anfällig für CVE-2017-5715 ist.
[SR] Es wird DRINGEND EMPFOHLEN, Kerneldaten, die nur während der Initialisierung geschrieben werden, nach der Initialisierung als schreibgeschützt zu markieren (z.B. __ro_after_init).
[C-SR] 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] Es wird DRINGEND EMPFOHLEN, die Kontrollflussintegrität (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] Es wird DRINGEND EMPFOHLEN, die Control-Flow Integrity (CFI), den Shadow Call Stack (SCS) oder die Integer Overflow Sanitization (IntSan) nicht für Komponenten zu deaktivieren, für die sie aktiviert sind.
[C-SR] 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] 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 vom Compiler verwendete Wert zum Initialisieren der lokalen Variablen verwendet wird.
[C-SR] 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. Sie SOLLTEN NICHT davon ausgehen, dass der vom Kernel verwendete Wert zur Initialisierung dieser Zuweisungen verwendet wird.

Wenn Geräteimplementierungen einen Linux-Kernel verwenden, 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, einschließlich Domains, die für ein Gerät oder einen Anbieter spezifisch sind.
[C-1-4] DÜRFEN NICHT die „neverallow“-Regeln ändern, weglassen oder ersetzen, die im System-/sepolicy-Ordner des Upstream-Android Open Source Project (AOSP) enthalten sind. Die Richtlinie MUSS mit allen vorhandenen „neverallow“-Regeln kompiliert werden, sowohl für AOSP-SELinux-Domains als auch für geräte-/anbieterspezifische Domains.
[C-1-5] MÜSSEN Drittanbieteranwendungen, die auf API-Ebene 28 oder höher ausgerichtet sind, 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 Upstream-Android Open Source Project bereitgestellt wird, und diese Richtlinie nur für ihre eigene gerätespezifische Konfiguration erweitern.

Wenn Geräteimplementierungen bereits mit einer früheren Android-Version eingeführt wurden und die Anforderungen [C-1-1] und [C-1-5] nicht durch ein Systemsoftware-Update erfüllen können, KÖNNEN sie von diesen Anforderungen ausgenommen werden.

Wenn Geräteimplementierungen einen anderen Kernel als Linux verwenden, gilt Folgendes:

[C-2-1] MUSS ein System zur obligatorischen Zugriffssteuerung verwenden, das SELinux entspricht.

Android enthält mehrere Funktionen für gestaffelte Sicherheitsebenen, die für die Gerätesicherheit unerlässlich sind.

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.
[SR] 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 Vorfallbericht, der von der System-API-Klasse IncidentManager erstellt wurde, 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, kann dafür eine andere Atom-ID im Bereich zwischen 100.000 und 200.000 verwendet werden.

9.8.2. Aufnahme

Geräteimplementierungen:

[C-0-1] Softwarekomponenten, die private Informationen des Nutzers (z.B. Tasteneingaben, auf dem Bildschirm angezeigter Text, Fehlerbericht) ohne Zustimmung des Nutzers oder ohne klare, fortlaufende Benachrichtigungen vom Gerät senden, DÜRFEN NICHT vorinstalliert oder standardmäßig verteilt werden.
[C-0-2] MUSS eine explizite Nutzereinwilligung eingeholt werden, die es erlaubt, alle vertraulichen Informationen, die auf dem Bildschirm des Nutzers angezeigt werden, zu erfassen, wenn die Bildschirmübertragung oder Bildschirmaufzeichnung über MediaProjection oder proprietäre APIs aktiviert ist. Nutzer dürfen keine Möglichkeit haben, die zukünftige Anzeige der Einwilligung des Nutzers zu deaktivieren.
[C-0-3] MUSS eine laufende Benachrichtigung für den Nutzer anzeigen, wenn die Bildschirmübertragung oder Bildschirmaufzeichnung aktiviert ist. AOSP erfüllt diese Anforderung, indem ein Symbol für laufende Benachrichtigungen in der Statusleiste angezeigt wird.

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, und zwar nicht über die System-API ContentCaptureService oder andere proprietäre Mittel, die in Abschnitt 9.8.6 – Inhaltserfassung beschrieben sind, gilt Folgendes:

[C-1-1] MUSS eine laufende Benachrichtigung 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.

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. Netzwerkverkehr

Geräteimplementierungen:

[C-0-1] Es MUSS dieselben Root-Zertifikate für den vom System vertrauenswürdigen Zertifizierungsstellenspeicher vorinstallieren, die im Upstream-Android Open Source Project bereitgestellt werden.
[C-0-2] MÜSSEN mit einem leeren Nutzer-Stammzertifizierungsstellenspeicher ausgeliefert werden.
[C-0-3] MUSS dem Nutzer eine Warnung anzeigen, dass der Netzwerkverkehr überwacht werden kann, wenn eine Root-Zertifizierungsstelle eines Nutzers 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 der Berechtigung 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 Geräteinhaber ü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 durchgehend aktives VPN nicht unterstützen. Dazu muss das Attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON in der Datei AndroidManifest.xml auf false gesetzt werden.

9.8.5. Geräte-IDs

Geräteimplementierungen:

[C-0-1] Der Zugriff auf die Geräte-Seriennummer und, falls zutreffend, auf die IMEI/MEID, die SIM-Seriennummer und die International Mobile Subscriber Identity (IMSI) muss durch eine App verhindert werden, sofern sie nicht eine der folgenden Anforderungen erfüllt:
- ist eine signierte Carrier-App, die von Geräteherstellern überprüft wird.
- die Berechtigung READ_PRIVILEGED_PHONE_STATE erhalten hat.
- hat Betreiberberechtigungen 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. Inhalte erfassen

Android unterstützt über die System-API ContentCaptureService oder auf andere proprietäre Weise einen Mechanismus, mit dem Geräteimplementierungen die folgenden Interaktionen zwischen den Anwendungen und dem Nutzer erfassen können.

Auf dem Bildschirm gerenderter Text und Grafiken, einschließlich, aber nicht beschränkt auf Benachrichtigungen und Assist-Daten über die AssistStructure API.
Mediendaten wie Audio oder Video, die vom Gerät aufgezeichnet oder wiedergegeben werden.
Eingabeereignisse (z. B. Tastatur, Maus, Geste, Sprache, Video und Bedienungshilfen)
Alle anderen Ereignisse, die eine Anwendung dem System über die Content Capture API oder eine ähnlich leistungsfähige proprietäre API bereitstellt.
Alle Texte oder anderen Daten, die über 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.

Wenn Geräteimplementierungen die oben genannten Daten erfassen, müssen sie:

[C-1-1] MUSS alle diese Daten verschlüsseln, wenn sie auf dem Gerät gespeichert werden. Diese Verschlüsselung KANN mit der dateibasierten Android-Verschlüsselung oder einem der in Cipher SDK für API-Version 26 und höher aufgeführten Chiffren erfolgen.
[C-1-2] ROH- oder verschlüsselte Daten DÜRFEN NICHT mit Android-Sicherungsmethoden oder anderen Sicherungsmethoden gesichert werden.
[C-1-3] MUSS alle diese Daten und das Protokoll des Geräts nur über einen datenschutzfreundlichen Mechanismus senden. Der datenschutzfreundliche Mechanismus ist definiert als „Mechanismen, die nur Analysen auf aggregierter Ebene zulassen 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-1-4] Solche Daten DÜRFEN NICHT mit einer Nutzeridentität (z. B. Account) auf dem Gerät verknüpft werden, es sei denn, der Nutzer stimmt jedes Mal ausdrücklich zu, wenn die Daten verknüpft werden.
[C-1-5] Solche Daten DÜRFEN NICHT an andere Apps weitergegeben werden, es sei denn, der Nutzer hat jedes Mal ausdrücklich zugestimmt.
[C-1-6] MUSS dem Nutzer die Möglichkeit bieten, solche Daten zu löschen, die von der ContentCaptureService oder den proprietären Mitteln erhoben werden, wenn die Daten in irgendeiner Form auf dem Gerät gespeichert werden.

Wenn Geräteimplementierungen einen Dienst enthalten, der die System-API ContentCaptureService oder einen proprietären Dienst implementiert, der die oben beschriebenen Daten erfasst, gilt Folgendes:

[C-2-1] Nutzer DÜRFEN den Dienst zum Erfassen von Inhalten NICHT durch eine vom Nutzer installierbare Anwendung oder einen vom Nutzer installierbaren Dienst ersetzen können. Nur der vorinstallierte Dienst DARF solche Daten erfassen.
[C-2-2] Es DARF KEINEN Apps außer dem vorinstallierten Dienst zum Erfassen von Inhalten erlaubt sein, solche Daten zu erfassen.
[C-2-3] Der Nutzer MUSS die Möglichkeit haben, den Dienst zum Erfassen von Inhalten zu deaktivieren.
[C-2-4] MUSS dem Nutzer die Möglichkeit geben, die vom Dienst zum Erfassen von Inhalten gehaltenen Android-Berechtigungen zu verwalten, und dem Android-Berechtigungsmodell gemäß Abschnitt 9.1 folgen. Berechtigung.
[C-SR] Es wird DRINGEND EMPFOHLEN, die Komponenten des Dienstes zur Erfassung von Inhalten getrennt zu halten, z. B. den Dienst nicht zu binden oder Prozess-IDs mit anderen Systemkomponenten zu teilen, mit Ausnahme der folgenden:
- Telefonie, Kontakte, System-UI und Medien

9.8.7. Zugriff auf die Zwischenablage

Geräteimplementierungen:

[C-0-1] Es DÜRFEN KEINE abgeschnittenen Daten in die Zwischenablage zurückgegeben werden (z.B. über die ClipboardManager API), es sei denn, die App ist die Standard-IME oder die App, die gerade den Fokus hat.

9.8.8. Standort

Geräteimplementierungen:

[C-0-1] Die Einstellungen für den Gerätestandort und die WLAN-/Bluetooth-Suche DÜRFEN NICHT ohne ausdrückliche Einwilligung oder Initiative des Nutzers aktiviert oder deaktiviert werden.
[C-0-2] MUSS dem Nutzer die Möglichkeit bieten, 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 der 911 oder Senden einer SMS an die 911). Bei Automotive kann ein Fahrzeug jedoch eine Notfallsitzung 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 API beibehalten, die Standorteinstellungen des Geräts zu umgehen, ohne die Einstellungen zu ändern.
[C-0-5] MUSS eine Benachrichtigung planen, die den Nutzer daran erinnert, wenn 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] DÜRFEN keine Details zu anderen installierten Apps für Apps mit Ziel-API-Level 30 oder höher bereitgestellt 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, die vom Geräteimplementierer hinzugefügt wurden, oder über das Dateisystem verfügbar gemacht werden.

9.8.10. Fehlerbericht zur Konnektivität

Wenn Geräteimplementierungen Fehlerberichte mit der System-API BUGREPORT_MODE_TELEPHONY und BugreportManager generieren, gilt Folgendes:

[C-1-1] Die Einwilligung des Nutzers MUSS jedes Mal eingeholt werden, wenn die System-API BUGREPORT_MODE_TELEPHONY aufgerufen wird, um einen Bericht zu erstellen. Der Nutzer DARF NICHT aufgefordert werden, allen zukünftigen Anfragen der Anwendung zuzustimmen.
[C-1-2] Die ausdrückliche Einwilligung des Nutzers muss angezeigt und eingeholt werden, wenn die Berichte generiert werden. Der generierte Bericht darf nicht ohne ausdrückliche Einwilligung des Nutzers an die anfragende App zurückgegeben werden.
[C-1-3] MUSS die angeforderten Berichte mit mindestens den folgenden Informationen generieren:
- TelephonyDebugService-Dump
- TelephonyRegistry-Dump
- WifiService-Dump
- ConnectivityService-Dump
- Ein Dump der CarrierService-Instanz des Anrufpakets (falls gebunden)
- Funkschnittstellen-Logpuffer
[C-1-4] Die generierten Berichte DÜRFEN Folgendes NICHT enthalten:
- Alle Arten von Informationen, die nicht mit der Fehlerbehebung bei der Verbindung zusammenhängen.
- Jegliche Art von Traffic-Logs für vom Nutzer installierte Apps oder detaillierte Profile von vom Nutzer installierten Apps/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. Anbieterprotokolle) in den Fehlerbericht aufnehmen und diese Informationen Auswirkungen auf Datenschutz, Sicherheit, Akku, Speicher oder Arbeitsspeicher haben, gilt Folgendes:

[C-SR] Es wird DRINGEND EMPFOHLEN, dass eine Entwicklereinstellung standardmäßig deaktiviert ist. AOSP erfüllt diese Anforderung, indem in den Entwicklereinstellungen die Option Enable verbose vendor logging bereitgestellt wird, um zusätzliche gerätespezifische Vendor-Logs 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] Es ist NICHT zulässig, Daten-Blobs von Apps über das hinaus weiterzugeben, was sie zulassen wollten. Das heißt, 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] Sichere Hashes von Daten-Blobs (die zur Zugriffssteuerung verwendet werden) DÜRFEN NICHT vom Gerät gesendet oder mit anderen Apps geteilt werden.

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 Compatibility Definition Document 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 die Speicherverschlüsselung nicht unterstützt wird.
[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 Daten der Anwendung (/data-Partition) sowie die Partition des gemeinsam genutzten Speichers der Anwendung (/sdcard-Partition) verschlüsseln, wenn sie ein permanenter, nicht entfernbarer Teil des Geräts ist.
[C-0-2] Die Verschlüsselung der Datenspeicherung MUSS standardmäßig aktiviert werden, sobald 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 gemäß Abschnitt 9.9.3.1.
- 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 hochfahren, ohne den Nutzer nach Anmeldedaten zu fragen, und Apps, die Direct Boot unterstützen, den Zugriff auf den geräteverschlüsselten (Device Encrypted, DE) Speicher nach dem Broadcast der ACTION_LOCKED_BOOT_COMPLETED-Nachricht ermöglichen.
[C-1-2] Der Zugriff auf den Credential Encrypted (CE)-Speicher MUSS erst dann möglich sein, wenn der Nutzer das Gerät durch Angabe seiner Anmeldedaten (z. B. Sicherheitscode, PIN, Muster oder Fingerabdruck) entsperrt hat und die ACTION_USER_UNLOCKED-Nachricht gesendet wurde.
[C-1-13] Es darf keine Methode 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 basiert, die den Anforderungen in Abschnitt 9.9.4 entspricht.
[C-1-4] MUSS den verifizierten Bootmodus 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 256‑Bit-Verschlüsselungsschlüssellänge, 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 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 Metadaten des Dateisystems verwendet werden, nicht Adiantum.
[C-1-13] Es MUSS eine kryptografisch starke und nicht umkehrbare 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 über ihre Eingaben als pseudozufällige Funktionsfamilie 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).
Die Schlüssel zum Schutz von CE- und DE-Speicherbereichen und Dateisystemmetadaten:
[C-1-7] MUSS kryptografisch an einen hardwaregestützten Keystore gebunden sein. Dieser Keystore MUSS an Verified Boot und den Hardware-Root-of-Trust des Geräts gebunden sein.
[C-1-8] CE-Schlüssel MÜSSEN an die Sperrbildschirm-Anmeldedaten eines Nutzers gebunden sein.
[C-1-9] CE-Schlüssel MÜSSEN an einen Standardsicherheitscode gebunden sein, wenn der Nutzer keine Anmeldedaten für den Sperrbildschirm angegeben hat.
[C-1-10] MUSS eindeutig sein. Das heißt, der Schlüssel für die vertrauliche Umgebung oder das Geräte-Attest eines Nutzers darf nicht mit dem Schlüssel für die vertrauliche Umgebung oder das Geräte-Attest eines anderen Nutzers übereinstimmen.
[C-1-11] MUSS die obligatorisch unterstützten Chiffren, Schlüssellängen und Modi verwenden.
WICHTIG: Vorinstallierte wichtige Apps (z.B. Wecker, Telefon, Messenger) SOLLTEN für den Direktstart optimiert werden.

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 blockweise verschlüsselten Geräte pro Nutzer:
[C-1-5] MUSS kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. Dieser Keystore MUSS an Verified Boot und den Hardware-Root-of-Trust des Geräts gebunden sein.
[C-1-6] MUSS an die Anmeldedaten des entsprechenden Nutzers für den Sperrbildschirm gebunden sein.

Die Block-Level-Verschlüsselung pro Nutzer kann mit der Linux-Kernelfunktion „dm-crypt“ über Partitionen pro Nutzer implementiert werden.

9.9.4. Bei Neustart fortsetzen

Mit „Resume on Reboot“ kann der CE-Speicher aller Apps, einschließlich derer, die Direct Boot noch nicht unterstützen, nach einem Neustart, der durch ein OTA-Update ausgelöst wurde, 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 extrem 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 dem Empfang 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 physischen Zugriff auf das Gerät hat. Für ihn gelten dann die folgenden Funktionen und Einschränkungen:
- 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. Der Status FLASH_LOCK_UNKNOWN ist für Geräteimplementierungen reserviert, die von einer früheren Android-Version aktualisiert werden, in der diese neue System-API-Methode noch nicht vorhanden war.
[C-0-2] MUSS den Bootmodus mit Verifikation zur Überprüfung 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 verifizierte Bootmodus 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 Bestätigung 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 Verifizierungsalgorithmen 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-SR] Wenn das Gerät mehrere separate Chips hat (z.B. Funkchip, spezieller Bildprozessor), wird DRINGEND EMPFOHLEN, dass der Bootvorgang jedes dieser Chips bei jedem Booten jede Phase überprüft.
[C-1-8] MUSS manipulationssicheren Speicher verwenden, um zu speichern, ob der Bootloader entsperrt ist. Manipulationssicherer Speicher bedeutet, dass der Bootloader erkennen kann, ob der Speicher innerhalb von Android manipuliert wurde.
[C-1-9] Der Nutzer MUSS während der Verwendung des Geräts aufgefordert werden, die Änderung des Bootloader-Status von „Bootloader locked“ zu „Bootloader unlocked“ physisch zu bestätigen, bevor sie zugelassen wird.
[C-1-10] Es MUSS ein Rollback-Schutz für von Android verwendete Partitionen (z.B. Boot- und Systempartitionen) implementiert werden und es MUSS ein manipulationssicherer Speicher zum Speichern der Metadaten verwendet werden, die zur Bestimmung der zulässigen Mindestversion des Betriebssystems verwendet werden.
[C-SR] Es wird DRINGEND EMPFOHLEN, alle APK-Dateien privilegierter Apps mit einer Vertrauenskette zu überprüfen, die auf Partitionen basiert, die durch Verified Boot geschützt sind.
[C-SR] Es wird DRINGEND EMPFOHLEN, alle ausführbaren Artefakte, die von einer privilegierten App 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.

Wenn Geräteimplementierungen bereits ohne Unterstützung von C-1-8 bis C-1-10 in einer früheren Android-Version eingeführt wurden und die Unterstützung dieser Anforderungen nicht durch ein Systemsoftware-Update hinzugefügt werden kann, KÖNNEN sie von den Anforderungen ausgenommen werden.

Das Upstream-Android Open Source Project bietet eine bevorzugte Implementierung dieser Funktion im Repository external/avb/, die in den Bootloader integriert werden kann, der zum Laden von Android verwendet wird.

Geräteimplementierungen:

[C-0-3] MUSS die kryptografische Überprüfung von Dateiinhalten anhand eines vertrauenswürdigen Schlüssels unterstützen, ohne die gesamte Datei lesen zu müssen.
[C-0-4] Leseanfragen für eine geschützte Datei DÜRFEN NICHT erfolgreich sein, wenn der gelesene Inhalt nicht mit einem vertrauenswürdigen Schlüssel überprüft werden kann.

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 durch ein Systemsoftware-Update 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.

Geräteimplementierungen:

[C-R] Es wird EMPFOHLEN, die Android Protected Confirmation API zu unterstützen.

Wenn Geräteimplementierungen die Android Protected Confirmation API unterstützen, gilt Folgendes:

[C-3-1] MUSS true für die ConfirmationPrompt.isSupported() API melden.
[C-3-2] MUSS dafür sorgen, dass Code, der im Android-Betriebssystem einschließlich des Kernels ausgeführt wird, unabhängig davon, ob er schädlich ist oder nicht, ohne Nutzerinteraktion keine positive Antwort generieren kann.
[C-3-3] MUSS dafür sorgen, dass der Nutzer die angezeigte Meldung auch dann überprüfen und genehmigen kann, wenn das Android-Betriebssystem, einschließlich des Kernels, manipuliert wurde.

9.11. Schlüssel und Anmeldedaten

Mit dem Android Keystore System können App-Entwickler kryptografische Schlüssel in einem Container speichern und in kryptografischen Vorgängen über die KeyChain API oder die Keystore API 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 Versuche ratenbegrenzen und einen exponentiellen Backoff-Algorithmus haben. Nach 150 fehlgeschlagenen Versuchen MUSS die Verzögerung mindestens 24 Stunden pro Versuch betragen.
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-2] MUSS Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie der Hashfunktionen MD5, SHA1 und SHA-2 enthalten, um die vom Android-Keystore-System unterstützten Algorithmen in einem Bereich, der sicher vom Code isoliert ist, der auf dem Kernel und darüber ausgeführt wird, ordnungsgemäß zu unterstützen. Die sichere Isolierung 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 auf ARM TrustZone basierende Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer geeigneten hypervisorbasierten Isolation sind alternative Optionen.
[C-1-3] Die Sperrbildschirmauthentifizierung MUSS in der isolierten Ausführungsumgebung erfolgen und die Verwendung der authentifizierungsgebundenen 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-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, die verwendet werden können, um diese Anforderung zu erfüllen.
[C-1-4] MUSS die Schlüsselattestierung unterstützen, wobei der Attestierungssignierschlüssel durch sichere Hardware geschützt ist und die Signierung in sicherer Hardware erfolgt. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten geteilt werden, damit sie nicht als Geräte-IDs verwendet werden können. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer bestimmten Artikelnummer produziert werden. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, KANN für jeweils 100.000 Einheiten ein anderer Schlüssel verwendet werden.

[C-1-5] MUSS dem Nutzer ermöglichen, das Zeitlimit für den Übergang vom entsperrten in den gesperrten Zustand festzulegen. Das Mindestzeitlimit beträgt 15 Sekunden. Bei Geräten für das Auto, die den Bildschirm sperren, wenn das Infotainmentsystem ausgeschaltet oder der Nutzer gewechselt wird, ist die Konfiguration für das Zeitlimit für den Ruhemodus möglicherweise NICHT verfügbar.

9.11.1. Sicherer Sperrbildschirm und Authentifizierung

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] 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.

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 Passwortrichtlinie über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_SOMETHING 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 deutlich mitteilen, dass einige Daten nicht gesichert werden, um die Privatsphäre seiner Daten zu schützen.

Wenn in Geräteimplementierungen die empfohlenen primären Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode verwendet wird, die auf Biometrie basiert und als sichere Methode zum Sperren des Bildschirms gilt, muss die neue Methode:

[C-4-1] MUSS alle Anforderungen erfüllen, die in Abschnitt 7.3.10 für Klasse 1 (früher Komfort) beschrieben sind.
[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 (d.h. 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 Passwortqualität über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_BIOMETRIC_WEAK festgelegt hat.
[C-5-2] Der Nutzer MUSS zur empfohlenen primären Authentifizierung (z. B. PIN, Muster, 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 zum Entsperren des Bildschirms zulassen, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie entweder mit der Methode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) oder der Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_UNSPECIFIED festgelegt hat.
[C-6-3] Der Nutzer MUSS mindestens alle vier Stunden oder weniger zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z.B.PIN, Muster, Passwort) aufgefordert werden.
[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 mindestens einen Trust-Agent enthalten, der die TrustAgentService-System-API implementiert, 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 durch 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 persönliches Gerät verwendet wird (z.B. ein Mobilgerät), DÜRFEN aber vollständig auf Geräteimplementierungen implementiert werden, die in der Regel gemeinsam genutzt werden (z.B. Android-Fernseher oder Automotive-Geräte).
[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-8] Der Nutzer MUSS mindestens alle 72 Stunden oder weniger zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) aufgefordert werden, es sei denn, die Sicherheit des Nutzers (z. B. Ablenkung des Fahrers) ist gefährdet.
[C-7-9] Der Nutzer MUSS zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) aufgefordert werden, wie in [C-1-7] und [C-1-8] in Abschnitt 7.3.10 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 unten in C-8 aufgeführten Einschränkungen einhalten.
[C-7-11] TrustAgents dürfen auf primären persönlichen Geräten (z. B. Handhelds) NICHT zum Entsperren des Geräts verwendet werden. Sie dürfen 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 Treuhand-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 Passwortqualitätsrichtlinie über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_UNSPECIFIED 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 zur Änderung des Schlossstatus bereitstellen.

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. In den Anforderungen C-1-3 bis C-1-11 unten wird definiert, welche Anforderungen ein Gerät erfüllen muss, um als StrongBox zu gelten.

Geräteimplementierungen mit einem dedizierten sicheren Prozessor:

[C-SR] 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] MUSS eine dedizierte sichere Hardware bereitstellen, die zur Unterstützung des Keystores 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 gemeinsam genutzt werden, die StrongBox-Verarbeitung in keiner Weise verändern oder Informationen aus der StrongBox abrufen können. Die App kann den Zugriff auf StrongBox deaktivieren oder blockieren.
[C-1-5] MUSS eine interne Uhr mit angemessener Genauigkeit (±10%) haben, die nicht durch den 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, Zeit, elektromagnetische Strahlung und Wärmestrahlung.
[C-1-9] MUSS über einen sicheren Speicher verfügen, der die Vertraulichkeit, Integrität, Authentizität, Konsistenz und Aktualität der Inhalte gewährleistet. Der Speicher darf nur über die StrongBox-APIs gelesen oder geändert werden.
Zur Validierung der Einhaltung von [C-1-3] bis [C-1-9] müssen Geräteimplementierungen:
- [C-1-10] MUSS die Hardware enthalten, die gemäß dem Schutzprofil für sichere ICs BSI-CC-PP-0084-2014 zertifiziert oder von einem national akkreditierten Prüflabor bewertet wurde, das eine Schwachstellenbewertung mit hohem Angriffspotenzial gemäß den Common Criteria Application of Attack Potential to Smartcards (Anwendung des Angriffspotenzials auf Smartcards gemäß Common Criteria) durchführt.
- [C-1-11] MUSS die Firmware enthalten, die von einem national akkreditierten Prüflabor bewertet wird, das eine Schwachstellenbewertung mit hohem Angriffspotenzial gemäß den Common Criteria Application of Attack Potential to Smartcards durchführt.
- [C-SR] Es wird DRINGEND EMPFOHLEN, die Hardware einzubeziehen, die mit einem Security Target, Evaluation Assurance Level (EAL) 5, ergänzt durch AVA_VAN.5, bewertet wird. Die EAL5-Zertifizierung wird wahrscheinlich in einem zukünftigen Release erforderlich sein.
[C-SR] wird DRINGEND EMPFOHLEN, um Insider-Angriffen (Insider Attack Resistance, IAR) zu widerstehen. 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 zur Implementierung von IAR besteht darin, Firmware-Updates nur zuzulassen, wenn das Passwort des primären Nutzers über das IAuthSecret HAL angegeben wird.

9.11.3. Identity Credential

Das Identity Credential System wird durch die Implementierung aller APIs im Paket android.security.identity.* definiert und erreicht. Mit diesen APIs können App-Entwickler Nutzeridentifikationsdokumente speichern und abrufen. Geräteimplementierungen:

[C-SR] Es wird DRINGEND EMPFOHLEN, das Anmeldesystem für Identität zu implementieren.

Wenn Geräteimplementierungen das Identity Credential System implementieren, gilt Folgendes:

[C-0-1] MUSS für die Methode IdentityCredentialStore#getInstance() einen Wert zurückgeben, der nicht null ist.
[C-0-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 auf dem Kernel und darüber ausgeführt wird. Die sichere Isolierung MUSS alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA.
[C-0-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. Das Material für private Schlüssel 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-0-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.

9.12. Löschen von Daten

Für alle Geräteimplementierungen gilt:

[C-0-1] Nutzer MÜSSEN die Möglichkeit haben, das Gerät auf die Werkseinstellungen zurückzusetzen.
[C-0-2] ALLE Daten im userdata-Dateisystem MÜSSEN gelöscht werden.
[C-0-3] Die Daten MÜSSEN so gelöscht werden, dass die relevanten Branchenstandards wie NIST SP800-88 erfüllt werden.
[C-0-4] MUSS den oben genannten 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“, können Nutzer potenziell schädliche Drittanbieter-Apps deinstallieren.

Geräteimplementierungen:

[SR] Es wird DRINGEND EMPFOHLEN, den abgesicherten 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 auf dem Gerät installierte Drittanbieter-Apps unterbrochen wird, es sei denn, die Drittanbieter-App ist ein Gerätepolicy-Controller und hat das Flag UserManager.DISALLOW_SAFE_BOOT auf „true“ gesetzt.
[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 die 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. Abos

„Abos“ bezieht sich auf die Abrechnungsbeziehungsplandetails, die von einem Mobilfunkanbieter über SubscriptionManager.setSubscriptionPlans() bereitgestellt werden.

Für alle Geräteimplementierungen gilt:

[C-0-1] MÜSSEN Abos nur an die Mobilfunkanbieter-App zurückgeben, die sie ursprünglich bereitgestellt hat.
[C-0-2] DÜRFEN Abos NICHT per Fernzugriff sichern oder hochladen.
[C-0-3] MÜSSEN nur Überschreibungen wie SubscriptionManager.setSubscriptionOverrideCongested() aus der Mobilfunkanbieter-App 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 der Nutzer MUSS bestätigen, dass er die Daten auf dem Quellgerät kopieren möchte, bevor Daten übertragen werden.
[C-1-3] MUSS die Attestierung des Sicherheitsschlüssels 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 zur selben Anwendung auf dem Zielgerät mit demselben Paketnamen UND Signaturzertifikat migriert werden.
[C-1-5] Im Einstellungsmenü MUSS angezeigt werden, dass Daten vom Quellgerät durch eine Datenmigration von Gerät zu Gerät migriert wurden. Nutzer SOLLTEN diese Angabe NICHT entfernen können.

10. Softwarekompatibilitätstests

Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen. Kein Softwaretestpaket ist jedoch vollständig. Aus diesem Grund wird Geräteherstellern DRINGEND EMPFOHLEN, die Mindestanzahl an Änderungen an der Referenz- und bevorzugten Implementierung von Android vorzunehmen, die im Android Open Source Project verfügbar ist. Dadurch 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.
[C-0-2] MUSS die Kompatibilität bei Unklarheiten im CTS und bei allen Reimplementierungen von Teilen des Referenzquellcodes sicherstellen.

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 Überarbeitungen des CTS für Android 11 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 verwendet werden.

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, müssen Geräteimplementierer den CTS-Verifier nicht explizit für Builds ausführen, die sich nur in unwichtigen Details unterscheiden. Insbesondere Geräteimplementierungen, die sich von einer Implementierung, die den CTS-Verifier bestanden hat, nur durch die Menge der enthaltenen Gebietsschemas, 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 durch einen der folgenden Ansätze 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 freigegebene 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] 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] OTA-Downloads mit Offline-Update über Neustart MUSS unterstützt werden.

Bei Geräteimplementierungen, die mit Android 6.0 und höher eingeführt werden, SOLLTE der Aktualisierungsmechanismus unterstützen, dass das System-Image nach einer OTA-Aktualisierung binär mit dem erwarteten Ergebnis identisch ist. Die blockbasierte OTA-Implementierung im Upstream-Android Open Source Project, 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ätehersteller MUSS den Fehler über ein Softwareupdate beheben, das über den 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 Subsystem für Systemupdates 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

Eine Zusammenfassung der Änderungen an der Kompatibilitätsdefinition in dieser Version finden Sie hier:

Änderungslog für Dokumente

Zusammenfassung der Änderungen an den einzelnen Abschnitten:

12.1. Tipps zum Ansehen des Änderungsprotokolls

Änderungen werden so gekennzeichnet:

CDD
Substantielle Änderungen an den Kompatibilitätsanforderungen.
Docs
Kosmetische oder buildbezogene Änderungen.

Für eine optimale Darstellung sollten Sie die URL-Parameter pretty=full und no-merges an die URLs Ihres Änderungslogs anhängen.

13. Kontakt

Sie können dem android-compatibility-Forum beitreten und um Klarstellungen bitten oder Probleme ansprechen, die Ihrer Meinung nach im Dokument nicht behandelt werden.

Kompatibilitätsdefinition für Android 11 Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

1. Einführung

1.1 Dokumentstruktur

1.1.1. Anforderungen nach Gerätetyp

1.1.2. Anforderungs-ID

1.1.3. Anforderungs-ID in Abschnitt 2

2. Gerätetypen

2.1 Gerätekonfigurationen

2.2. Anforderungen an Handheld-Geräte

2.2.1. Hardware

2.2.2. Multimedia

2.2.3. Software

2.2.4. Leistung und Energie

2.2.5. Sicherheitsmodell

2.2.6. Kompatibilität von Entwicklertools und ‑optionen

2.2.7 Handheld Media Performance Class

2.2.7.1. Medien

2.2.7.2. Kamera

2.2.7.3. Hardware

2.2.7.4. Leistung

2.3. Anforderungen an das Fernsehgerät

2.3.1. Hardware

2.3.2. Multimedia

2.3.3. Software

2.3.4. Leistung und Energie

2.3.5. Sicherheitsmodell

2.3.6. Kompatibilität von Entwicklertools und ‑optionen

2.4. Smartwatch-Anforderungen

2.4.1. Hardware

2.4.2. Multimedia

2.4.3. Software

2.4.4. Leistung und Energie

2.4.5. Sicherheitsmodell

2.5. Anforderungen für die Automobilbranche

2.5.1. Hardware

2.5.2. Multimedia

2.5.3. Software

2.5.4. Leistung und Energie

2.5.5. Sicherheitsmodell

2.5.6. Kompatibilität von Entwicklertools und ‑optionen

2.6. Tablet-Anforderungen

2.6.1. Hardware

2.6.2. Sicherheitsmodell

2.6.2. Software

3. Software

3.1. Verwaltete API-Kompatibilität

3.1.1. Android-Erweiterungen

3.1.2. Android-Bibliothek

3.2 Soft API Compatibility

3.2.1. Berechtigungen

3.2.2. Parameter erstellen

3.2.3. Intent-Kompatibilität

3.2.3.1. Häufig verwendete Anwendungs-Intents

3.2.3.2. Intent-Auflösung

3.2.3.3. Intent-Namespaces

3.2.3.4. Broadcast-Intents

3.2.3.5. Bedingte Anwendungs-Intents

3.2.4. Aktivitäten auf sekundären/mehreren Displays

3.3 Kompatibilität mit nativen APIs

3.3.1. Binärschnittstellen

3.3.2. Kompatibilität mit nativem 32-Bit-ARM-Code

3.4. Webkompatibilität

3.4.1. WebView-Kompatibilität

3.4.2. Browserkompatibilität

3.5. Verhaltenskompatibilität der API

3.5.1. Anwendungseinschränkung

3.6. API-Namespaces

3.7. Laufzeitkompatibilität

3.8. Kompatibilität der Benutzeroberfläche

3.8.1. Launcher (Startbildschirm)

3.8.2. Widgets

3.8.3. Benachrichtigungen

3.8.3.1. Darstellung von Benachrichtigungen

3.8.3.2. Mitteilungs-Listener-Dienst

3.8.3.3. Bitte nicht stören

3.8.4. Suchen

3.8.5. Benachrichtigungen und Pop-up-Meldungen

3.8.6. Designs

3.8.7. Live-Hintergründe

3.8.8. Aktivitätswechsel

Kompatibilitätsdefinition für Android 11