Diese Seite wurde von der Cloud Translation API übersetzt.

Android 11-Kompatibilitätsdefinition

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 „MUST“, „MUST NOT“, „REQUIRED“, „SHALL“, „SHALL NOT“, „SHOULD“, „SHOULD NOT“, „RECOMMENDED“, „MAY“ und „OPTIONAL“ erfolgt gemäß dem IETF-Standard, der in RFC2119 definiert ist.

In diesem Dokument bezeichnet der Begriff „Geräteimplementierer“ 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äte als mit Android 11 kompatibel eingestuft werden, MÜSSEN sie die in dieser Kompatibilitätsdefinition aufgeführten Anforderungen erfüllen, einschließlich aller Dokumente, die als Referenz eingefügt wurden.

Wenn diese Definition oder die in Abschnitt 10 beschriebenen Softwaretests nicht eindeutig oder unvollständig sind, liegt es in der Verantwortung des Geräteimplementators, für die Kompatibilität mit vorhandenen Implementierungen zu sorgen.

Aus diesem Grund ist das Android Open Source Project sowohl die Referenz- als auch die bevorzugte Implementierung von Android. Geräteimplementierern wird DRINGEND empfohlen, ihre Implementierungen nach Möglichkeit auf dem „Upstream“-Quellcode zu basieren, der im Android Open Source Project verfügbar ist. Einige Komponenten können zwar theoretisch durch alternative Implementierungen ersetzt werden, dies wird jedoch DRINGEND abgeraten, da das Bestehen der Softwaretests dadurch erheblich erschwert wird. Es liegt in der Verantwortung des Implementators, für eine vollständige Verhaltenskompatibilität mit der Standard-Android-Implementierung zu sorgen, einschließlich und über die Compatibility Test Suite hinaus. Bestimmte Komponentenersetzungen und ‑änderungen sind gemäß diesem Dokument ausdrücklich untersagt.

Viele der in diesem Dokument verlinkten Ressourcen stammen direkt oder indirekt aus dem Android SDK und sind funktional mit den Informationen in der Dokumentation dieses SDK identisch. In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstestsuite nicht mit der SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als verbindlich. Alle technischen Details in den verlinkten Ressourcen in diesem Dokument gelten 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 allgemein für alle Android-Geräte gelten, sind in den Abschnitten nach Abschnitt 2 aufgeführt. Diese Anforderungen werden in diesem Dokument als „Grundlegende Anforderungen“ bezeichnet.

1.1.2. Anforderungs-ID

Die Anforderungs-ID wird für MUST-Anforderungen zugewiesen.

Die ID wird nur für MUSS-Anforderungen zugewiesen.
DRINGEND EMPFOHLENE Anforderungen sind als [SR] gekennzeichnet, aber es ist keine ID zugewiesen.
Die ID besteht aus : Gerätetyp-ID – Bedingungs-ID – Anforderungs-ID (z.B. C-0-1).

Jede ID wird so definiert:

Gerätetyp-ID (weitere Informationen finden Sie unter 2. Gerätetypen)
- C: Kern (Anforderungen, die für alle Android-Geräte gelten)
- H: Android-Mobilgerät
- T: Android TV-Gerät
- A: Android Automotive-Implementierung
- W: Implementierung für Android-Smartwatches
- Tab: Implementierung für Android-Tablets
Bedingungs-ID
- Wenn die Anforderung nicht bedingt ist, wird diese ID auf „0“ gesetzt.
- Wenn die Anforderung bedingt ist, wird der 1. Bedingung 1 zugewiesen. Die Zahl wird innerhalb desselben Abschnitts und desselben Gerätetyps um 1 erhöht.
Anforderungs-ID
- Diese ID beginnt bei 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ätetyp-ID – Bedingungs-ID – Anforderungs-ID (z.B. 7.4.3/A-0-1).

2. Gerätetypen

Das Android Open Source Project bietet einen Softwarestack, der für eine Vielzahl von Gerätetypen und Formfaktoren verwendet werden kann. Es gibt jedoch einige Gerätetypen, für die ein relativ besser etabliertes System für die Anwendungsbereitstellung existiert.

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

Alle Android-Geräteimplementierungen, die keinem der beschriebenen Gerätetypen zugeordnet werden können, MÜSSEN dennoch alle Anforderungen in den anderen Abschnitten dieser Kompatibilitätsdefinition erfüllen.

2.1 Gerätekonfigurationen

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

2.2. Anforderungen an Handhelds

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

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

Sie haben eine Stromquelle, die Mobilität bietet, z. B. einen Akku.
Die physische Bildschirmdiagonale muss zwischen 8,4 cm (2,5 Zoll für Geräte, die mit einer API-Ebene vor Android 11 auf den Markt gebracht wurden) und 20,3 cm (8 Zoll) liegen.

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

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

2.2.1. Hardware

Implementierungen für E-Reader und Handheld-Computer:

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

Wenn Implementierungen von Handheld-Geräten die Bildschirmdrehung durch Software unterstützen, gilt Folgendes:

[7.1.1.1/H-1-1]* Der logische Bildschirm, der für Drittanbieteranwendungen verfügbar gemacht wird, muss an den kurzen Seiten mindestens 5,1 cm und an den langen Seiten mindestens 6,9 cm groß sein. Geräte, die mit einem früheren API-Level als dem in diesem Dokument beschriebenen eingeführt wurden, sind von dieser Anforderung ausgenommen.

Wenn die Implementierung von Handheld-Geräten die Bildschirmdrehung durch Software nicht unterstützt, gilt Folgendes:

[7.1.1.1/H-2-1]* Der logische Bildschirm, der für Drittanbieter-Apps verfügbar gemacht wird, muss an den kürzeren Seiten mindestens 69,9 mm haben. Geräte, die mit einem früheren API-Level als dem in diesem Dokument beschriebenen eingeführt wurden, sind von dieser Anforderung ausgenommen.

Wenn für die Implementierung von Mobilgeräten die Unterstützung von HDR-Displays über Configuration.isScreenHdr() angegeben wird , gilt Folgendes:

[7.1.4.5/H-1-1] Es MUSS 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 angeboten werden.

Implementierungen für E-Reader und Handheld-Computer:

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

Wenn Implementierungen von Handheld-Geräten 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 enthalten, der dem Schema für GPU-Zähler und GPU-Renderstufen entspricht, das in der Perfetto-Dokumentation definiert ist.
[7.1.4.6/H-1-2] MÜSSEN 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] MÜSSEN konforme Werte für die GPU-Renderphasen des Geräts gemäß dem Render-Phase-Trace-Paket-Proto melden.
[7.1.4.6/H-1-4] Es MUSS ein GPU-Taktfrequenz-Tracepoint gemäß dem Format power/gpu_frequency erfasst werden.

Implementierungen für E-Reader und Handheld-Computer:

[7.1.5/H-0-1] MÜSSEN den Modus für die Kompatibilität mit älteren Anwendungen unterstützen, wie er im Upstream-Android-Open-Source-Code implementiert ist. Das heißt, die Auslöser oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert wird, und das Verhalten des Kompatibilitätsmodus selbst DÜRFEN NICHT geändert werden.
[7.2.1/H-0-1] MUSS die Unterstützung von IME-Anwendungen (Eingabemethoden-Editor) von Drittanbietern umfassen.
[7.2.3/H-0-3] Die Startbildschirmfunktion MUSS auf allen Android-kompatiblen Displays verfügbar sein, die den Startbildschirm anzeigen.
[7.2.3/H-0-4] Auf allen Android-kompatiblen Displays MUSS die Schaltfläche „Zurück“ und auf mindestens einem der Android-kompatiblen Displays die Schaltfläche „Letzte Apps“ vorhanden sein.
[7.2.3/H-0-2] Es MUSS sowohl das normale als auch das Ereignis „Langes Drücken“ der Zurück-Funktion (KEYCODE_BACK) an die Anwendung im Vordergrund gesendet werden. Diese Ereignisse DÜRFEN NICHT vom System verwendet 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] MUSS die Eingabe per Touchscreen unterstützen.
[7.2.4/H-SR] Es wird DRINGEND empfohlen, die vom Nutzer ausgewählte Assistenz-App zu starten, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die ACTION_ASSIST beim langen Drücken von KEYCODE_MEDIA_PLAY_PAUSE oder KEYCODE_HEADSETHOOK verarbeitet, wenn die Aktivität im Vordergrund diese Ereignisse nicht verarbeitet.
[7.3.1/H-SR] Es wird DRINGEND empfohlen, einen 3-Achsen-Beschleunigungsmesser zu verwenden.

Wenn Handheld-Implementierungen einen 3-Achsen-Beschleunigungsmesser enthalten, gilt Folgendes:

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

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

[7.3.3/H-2-1] GNSS-Messungen MÜSSEN gemeldet werden, sobald sie gefunden werden, auch wenn ein aus GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
[7.3.3/H-2-2] MÜSSEN GNSS-Pseudostrecken und Pseudostreckenraten melden, die bei freiem Blick nach der Standortbestimmung, bei Stillstand oder bei einer Beschleunigung von weniger als 0,2 Metern pro Sekunde zum Quadrat ausreichen, um mindestens 95% der Zeit die Position innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0,2 Metern pro Sekunde zu berechnen.

Wenn die Implementierung von Handheld-Geräten ein 3-Achsen-Gyroskop umfasst, gilt Folgendes:

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

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

[7.3.8/H] Es sollte einen Näherungssensor enthalten.

Implementierungen für E-Reader und Handheld-Computer:

[7.3.11/H-SR] Es wird EMPFOHLEN, einen Pose-Sensor mit 6 Freiheitsgraden zu unterstützen.
[7.4.3/H] Es sollte Bluetooth und Bluetooth LE unterstützen.

Wenn bei der Implementierung von Handheld-Geräten eine getaktete Verbindung verwendet wird, gilt Folgendes:

[7.4.7/H-1-1] Der Datensparmodus MUSS verfügbar sein.

Wenn Implementierungen von Handheld-Geräten ein logisches Kameragerät enthalten, das Funktionen mit CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA auflistet, gilt Folgendes:

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

Implementierungen für E-Reader und Handheld-Computer:

[7.6.1/H-0-1] Es muss mindestens 4 GB nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) verfügbar sein.
[7.6.1/H-0-2] MUSS für ActivityManager.isLowRamDevice() „wahr“ zurückgeben, wenn für den Kernel und den Userspace weniger als 1 GB Arbeitsspeicher verfügbar ist.

Wenn bei Implementierungen von Handheld-Geräten nur eine 32-Bit-ABI unterstützt wird:

[7.6.1/H-1-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 416 MB betragen, wenn das Standarddisplay Framebufferauflösungen bis zu qHD (z.B. FWVGA) verwendet.
[7.6.1/H-2-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 592 MB betragen, wenn das Standarddisplay Framebufferauflösungen bis zu HD+ (z.B. HD, WSVGA) verwendet.
[7.6.1/H-3-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 896 MB betragen, wenn das Standarddisplay Framebufferauflösungen bis zu FHD (z.B. WSXGA+) verwendet.
[7.6.1/H-4-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 1.344 MB betragen, wenn das Standarddisplay Framebufferauflösungen bis QHD (z. B. QWXGA) verwendet.

Wenn für die Implementierung von Handheld-Geräten die Unterstützung eines 64‑Bit-ABI (mit oder ohne 32‑Bit-ABI) deklariert wird:

[7.6.1/H-5-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 816 MB betragen, wenn das Standarddisplay Framebufferauflösungen bis zu qHD (z.B. FWVGA) verwendet.
[7.6.1/H-6-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 944 MB betragen, wenn das Standarddisplay Framebufferauflö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 1.280 MB betragen, wenn das Standarddisplay Framebufferauflösungen bis zu FHD (z. B. WSXGA+) verwendet.
[7.6.1/H-8-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 1.824 MB betragen, wenn das Standarddisplay Framebufferauflösungen bis QHD (z. B. QWXGA) verwendet.

Hinweis: Der oben genannte „für den Kernel und Userspace verfügbare Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicherplatz, der zusätzlich zu dem Arbeitsspeicher zur Verfügung gestellt wird, der bereits für Hardwarekomponenten wie Radio, Video usw. reserviert ist, die bei Geräteimplementierungen nicht vom Kernel verwaltet werden.

Wenn für den Kernel und den Userspace weniger als 1 GB Arbeitsspeicher zur Verfügung steht, gelten für die Implementierung von Handheld-Geräten folgende Einschränkungen:

[7.6.1/H-9-1] DAS Funktions-Flag android.hardware.ram.low MUSS deklariert werden.
[7.6.1/H-9-2] Es muss mindestens 1,1 GB nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) vorhanden sein.

Wenn für Implementierungen von Handheld-Geräten mehr als 1 GB Arbeitsspeicher für den Kernel und den Userspace verfügbar ist, gilt Folgendes:

[7.6.1/H-10-1] Es muss mindestens 4 GB nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) verfügbar sein.
MÜSSEN das Funktions-Flag android.hardware.ram.normal deklarieren.

Implementierungen für E-Reader und Handheld-Computer:

[7.6.2/H-0-1] Der gemeinsam genutzte Speicherplatz für Anwendungen darf NICHT kleiner als 1 GiB sein.
[7.7.1/H] MUSS einen USB-Anschluss haben, der den Peripheriegerätemodus unterstützt.

Wenn die Implementierung von Handheld-Geräten einen USB-Anschluss mit Peripheriemodus umfasst, gilt Folgendes:

[7.7.1/H-1-1] Die Android Open Accessory API (AOA) MUSS implementiert werden.

Wenn die Implementierung von Handheld-Geräten einen USB-Anschluss mit Hostmodus umfasst, gilt Folgendes:

[7.7.2/H-1-1] Die USB Audio Class muss gemäß der Dokumentation des Android SDK implementiert sein.

Implementierungen für E-Reader und Handheld-Computer:

[7.8.1/H-0-1] MUSS ein Mikrofon enthalten.
[7.8.2/H-0-1] MUSS eine Audioausgabe haben und android.hardware.audio.output angeben.

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

[7.9.1/H-1-1] DAS android.hardware.vr.high_performance-Funktions-Flag MUSS deklariert werden.
[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 Implementierungen von Handheld-Geräten einen oder mehrere USB-C-Anschlüsse im Hostmodus haben und die USB Audio Class 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-Nutzungsseite: 0x0C HID-Nutzung: 0x0CD Kernel-Schlüssel: `KEY_PLAYPAUSE` Android-Schlüssel: `KEYCODE_MEDIA_PLAY_PAUSE`	Medienwiedergabe	Eingabe: Kurzes Drücken Ausgabe: Wiedergabe oder Pause
		Medienwiedergabe	Eingabe: Lang drücken Ausgabe: Sprachbefehl starten 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: Kurzes Drücken Ausgabe: Anruf annehmen
		Eingehender Anruf	Eingabe: Lang drücken Ausgabe: Anruf ablehnen
		Aktiver Anruf	Eingabe: Kurzes Drücken Ausgabe: Anruf beenden
		Aktiver Anruf	Eingabe: Lang drücken Ausgabe: Mikrofon stummschalten oder Stummschaltung aufheben
B	HID-Nutzungsseite: 0x0C HID-Nutzung: 0x0E9 Kernel-Schlüssel: `KEY_VOLUMEUP` Android-Schlüssel: `VOLUME_UP`	Medienwiedergabe, aktiver Anruf	Eingabe: Kurz oder lang drücken Ausgabe: Erhöht die System- oder Headsetlautstärke
C	HID-Nutzungsseite: 0x0C HID-Nutzung: 0x0EA Kernelschlüssel: `KEY_VOLUMEDOWN` Android-Schlüssel: `VOLUME_DOWN`	Medienwiedergabe, aktiver Anruf	Eingabe: Kurz oder lang drücken Ausgabe: Verringert die System- oder Headsetlautstärke
D	HID-Nutzungsseite: 0x0C HID-Nutzung: 0x0CF Kernelschlüssel: `KEY_VOICECOMMAND` Android-Schlüssel: `KEYCODE_VOICE_ASSIST`	Alle. Kann in jeder Instanz ausgelöst werden.	Eingabe: Kurzes oder langes Drücken Ausgabe: Sprachbefehl starten

[7.8.2.2/H-1-2] MUSS ACTION_HEADSET_PLUG beim Einstecken eines Steckers auslösen, aber erst, nachdem die USB-Audioschnittstellen und ‑Endpunkte korrekt nummeriert wurden, um den Typ des angeschlossenen Anschlusses zu identifizieren.

Wenn der USB-Audioendpunkttyp 0x0302 erkannt wird, geschieht Folgendes:

[7.8.2.2/H-2-1] MUSS Intent ACTION_HEADSET_PLUG mit dem zusätzlichen Parameter „microphone“ auf 0 ausstrahlen.

Wenn der USB-Audioendpunkttyp 0x0402 erkannt wird, geschieht Folgendes:

[7.8.2.2/H-3-1] MUSS die Intent ACTION_HEADSET_PLUG mit „Mikrofon“ zusätzlich auf „1“ ausstrahlen.

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

[7.8.2.2/H-4-1] Es MUSS ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_HEADSET und mit der Rolle „isSink()“ aufgeführt werden, wenn das Feld „USB audio terminal type“ den Wert 0x0302 hat.
[7.8.2.2/H-4-2] Es MUSS ein Gerät vom Typ „AudioDeviceInfo.TYPE_USB_HEADSET“ mit der Rolle „isSink()“ aufgeführt werden, wenn das Feld „USB audio terminal type“ den Wert „0x0402“ hat.
[7.8.2.2/H-4-3] Es MUSS ein Gerät vom Typ „AudioDeviceInfo.TYPE_USB_HEADSET“ mit der Rolle „isSource()“ aufgeführt sein, wenn das Feld „USB audio terminal type“ den Wert „0x0402“ hat.
[7.8.2.2/H-4-4] MUSS ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE und die Rolle „isSink()“ auflisten, wenn das Feld „USB audio terminal type“ den Wert 0x603 hat.
[7.8.2.2/H-4-5] Es MUSS ein Gerät vom Typ „AudioDeviceInfo.TYPE_USB_DEVICE“ und mit der Rolle „isSource()“ aufgeführt werden, wenn das Feld „USB audio terminal type“ den Wert „0x604“ hat.
[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 „USB audio terminal type“ den Wert „0x400“ hat.
[7.8.2.2/H-4-7] Es MUSS ein Gerät vom Typ „AudioDeviceInfo.TYPE_USB_DEVICE“ und mit der Rolle „isSource()“ aufgeführt werden, wenn das Feld „USB audio terminal type“ den Wert „0x400“ hat.
[7.8.2.2/H-SR] Es wird DRINGEND empfohlen, nach dem Anschluss eines USB-C-Audio-Peripheriegeräts die USB-Beschreibungen aufzuzählen, die Anschlusstypen zu identifizieren und die Absicht ACTION_HEADSET_PLUG in weniger als 1.000 Millisekunden zu senden.

Wenn die Implementierung von Handheld-Geräten mindestens einen haptischen Aktor enthält, gilt Folgendes:

[7.10/H-SR]* Es wird DRINGEND davon abgeraten, einen ERM-Haptik-Aktor (Vibrator) zu verwenden.
[7.10/H]* Der Aktuator sollte sich in der Nähe des Bereichs befinden, an dem das Gerät normalerweise gehalten oder berührt wird.
[7.10/H-SR]* Es wird DRINGEND empfohlen, alle öffentlichen Konstanten für deutliche Haptik 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 klare Haptik in android.os.VibrationEffect zu implementieren, nämlich EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK und EFFECT_DOUBLE_CLICK, sowie alle öffentlichen Konstanten für ausgeprägte Haptik in android.os.VibrationEffect.Composition, nämlich PRIMITIVE_CLICK und PRIMITIVE_TICK.
[7.10/H-SR]* Es wird dringend empfohlen, diese verknüpften Zuordnungen für haptische Konstanten zu verwenden.
[7.10/H-SR]* Es wird DRINGEND empfohlen, die Qualitätsbewertung für die APIs createOneShot() und createWaveform() zu beachten.
[7.10/H-SR]* Es wird DRINGEND empfohlen, die Funktionen zur Amplitudenskalierung zu prüfen, indem android.os.Vibrator.hasAmplitudeControl() ausgeführt wird.

Ein linearer ResonanzAktor (LRA) ist ein System mit einer einzelnen Massefeder, das eine dominante Resonanzfrequenz hat, bei der sich die Masse in Richtung der gewünschten Bewegung bewegt.

Wenn Implementierungen von Handheld-Geräten mindestens einen linearen ResonanzAktor enthalten, gilt Folgendes:

[7.10/H]* Der haptische Aktor sollte sich im Hochformat entlang der X-Achse bewegen.

Wenn die Implementierung eines Handheld-Geräts einen haptischen Aktor hat, der ein linearer Resonanz-Aktor (LRA) in X-Achse ist, gilt Folgendes:

[7.10/H-SR]* Es wird DRINGEND empfohlen, dass die Resonanzfrequenz der X‑Achsen-LRA unter 200 Hz liegt.

Wenn bei der Implementierung von Touchbedienungsgeräten die Zuordnung haptischer Konstanten verwendet wird, gilt Folgendes:

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

2.2.2. Multimedia

Implementierungen von Mobilgeräten MÜSSEN die folgenden Audiocodierungs- und -dekodierungsformate unterstützen und für Anwendungen von Drittanbietern 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 Profile (AAC+)
[5.1/H-0-5] AAC ELD (Enhanced Low Delay AAC)

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

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

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

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

2.2.3. Software

Implementierungen für E-Reader und Handheld-Computer:

[3.2.3.1/H-0-1] Es MUSS eine Anwendung geben, die die Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE und ACTION_CREATE_DOCUMENT wie in den SDK-Dokumenten beschrieben verarbeitet und Nutzern die Möglichkeit bietet, ü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 vorladen, die durch die hier aufgeführten Anwendungsabsichten definiert sind.
[3.2.3.1/H-SR] Es wird DRINGEND empfohlen, eine E-Mail-Anwendung vorab zu laden, die die Intents ACTION_SENDTO, ACTION_SEND oder ACTION_SEND_MULTIPLE zum Senden einer E-Mail verarbeiten kann.
[3.4.1/H-0-1] Es MUSS eine vollständige Implementierung der android.webkit.Webview API bereitgestellt werden.
[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 von Drittanbieter-Apps bietet.
[3.8.1/H-SR] Es wird EMPFOHLEN, eine Standard-Launcher-App anzugeben, die Logos mit Logos für die App-Symbole anzeigt.
[3.8.2/H-SR] Es wird DRINGEND empfohlen, Widgets von Drittanbieter-Apps zu unterstützen.
[3.8.3/H-0-1] Drittanbieter-Apps MÜSSEN Nutzern über die API-Klassen Notification und NotificationManager Benachrichtigungen zu wichtigen Ereignissen senden dürfen.
[3.8.3/H-0-2] MUSS Rich Notifications unterstützen.
[3.8.3/H-0-3] MÜSSEN Push-Benachrichtigungen unterstützen.
[3.8.3/H-0-4] Es MUSS einen Benachrichtigungs-Schirm enthalten, über den Nutzer die Benachrichtigungen direkt steuern können (z. B. antworten, pausieren, schließen, blockieren) – z. B. über Aktionsschaltflächen oder das Steuerfeld, wie im AOSP implementiert.
[3.8.3/H-0-5] Die über RemoteInput.Builder setChoices() verfügbaren Optionen MÜSSEN in der Benachrichtigungsleiste angezeigt werden.
[3.8.3/H-SR] Es wird DRINGEND empfohlen, die erste Option, die über RemoteInput.Builder setChoices() bereitgestellt wird, im Benachrichtigungs-Shade ohne zusätzliche Nutzerinteraktion anzuzeigen.
[3.8.3/H-SR] Es wird EMPFOHLEN, alle Optionen, die über RemoteInput.Builder setChoices() verfügbar sind, in der Benachrichtigungsleiste anzuzeigen, wenn der Nutzer alle Benachrichtigungen in der Benachrichtigungsleiste maximiert.
[3.8.3.1/H-SR] Es wird EMPFOHLEN, Aktionen, für die Notification.Action.Builder.setContextual als true festgelegt ist, inline mit den Antworten anzuzeigen, die über Notification.Remoteinput.Builder.setChoices angezeigt werden.
[3.8.4/H-SR] Es wird DRINGEND empfohlen, auf dem Gerät einen Assistenten zu implementieren, der die Hilfeaktion 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 Taste HOME als Interaktion zu verwenden, um die Assistenz-App zu starten, wie in Abschnitt 7.2.3 beschrieben. MUSS die vom Nutzer ausgewählte Assistenz-App starten, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die den ACTION_ASSIST-Intent verarbeitet.

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

[3.8.4/H-1-1]* Unterhaltungsbenachrichtigungen MÜSSEN vor nicht zu Unterhaltungen gehörenden Benachrichtigungen angezeigt werden, mit Ausnahme von Benachrichtigungen zu laufenden Diensten im Vordergrund und Benachrichtigungen mit importance:high.

Wenn Android-Handheld-Implementierungen einen Sperrbildschirm unterstützen, müssen sie:

[3.8.10/H-1-1] Die Sperrbildschirmbenachrichtigungen, einschließlich der Vorlage für Medienbenachrichtigungen, MÜSSEN angezeigt werden.

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

[3.9/H-1-1] MÜSSEN die gesamte Palette der in der Android SDK-Dokumentation definierten Richtlinien zur Geräteverwaltung implementieren.
[3.9/H-1-2] Die Unterstützung verwalteter Profile muss über das android.software.managed_users-Funktionsflag deklariert werden, es sei denn, das Gerät ist so konfiguriert, dass es sich als Gerät mit wenig RAM meldet oder internen (nicht entfernbaren) Speicher als freigegebenen Speicher zuweist.

Wenn Implementierungen von Handheld-Geräten die Unterstützung der APIs ControlsProviderService und Control umfassen und Drittanbieter-Anwendungen die Veröffentlichung von Gerätesteuerelementen zulassen, müssen sie:

[3.8.16/H-1-1] DAS Feature-Flag android.software.controls MUSS deklariert und auf true festgelegt werden.
[3.8.16/H-1-2] Es MUSS eine Nutzerfunktion geben, mit der Nutzer die bevorzugten Gerätesteuerungen aus den Steuerelementen hinzufügen, bearbeiten, auswählen und bedienen können, die von den Drittanbieter-Apps über die ControlsProviderService und die Control APIs registriert wurden.
[3.8.16/H-1-3] Der Zugriff auf diese Nutzerfunktion muss innerhalb von drei Interaktionen über einen Standard-Launcher möglich sein.
[3.8.16/H-1-4] In dieser Nutzerfunktion MÜSSEN der Name und das Symbol jeder Drittanbieter-App, die Steuerelemente über die ControlsProviderService API bereitstellt, sowie alle angegebenen Felder der Control APIs korrekt dargestellt werden.

Wenn solche Steuerelemente bei der Implementierung von Mobilgeräten nicht vorhanden sind, gilt Folgendes:

[3.8.16/H-2-1] null für die ControlsProviderService- und die Control-APIs MÜSSEN gemeldet werden.
[3.8.16/H-2-2] DAS Feature-Flag android.software.controls MUSS deklariert und auf false gesetzt werden.

Implementierungen für E-Reader und Handheld-Computer:

[3.10/H-0-1] MUSS Dienste zur Barrierefreiheit von Drittanbietern unterstützen.
[3.10/H-SR] Es wird DRINGEND empfohlen, Bedienungshilfen auf dem Gerät vorinstalliert zu haben, die mit den Bedienungshilfen „Schalterzugriff“ und „TalkBack“ (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden) vergleichbar sind oder diese übertreffen. Diese Bedienungshilfen müssen im Rahmen des TalkBack Open Source Project zur Verfügung gestellt werden.
[3.11/H-0-1] MUSS die Installation von TTS-Engines von Drittanbietern unterstützen.
[3.11/H-SR] Es wird DRINGEND empfohlen, eine TTS-Engine zu verwenden, 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 bei der Implementierung von Android-Handheld-Geräten FEATURE_BLUETOOTH oder FEATURE_WIFI unterstützt wird, gilt Folgendes:

[3.16/H-1-1] MUSS die Kopplungsfunktion für Companion-Geräte unterstützen.

Wenn die Navigationsfunktion als eine auf dem Bildschirm angezeigte, gestenbasierte Aktion bereitgestellt wird:

[7.2.3/H] Die Zone für die Gestenerkennung für die Startbildschirmfunktion sollte vom unteren Displayrand aus nicht höher als 32 dp sein.

Wenn auf Mobilgeräten eine Navigationsfunktion als Geste an beliebiger Stelle am linken und rechten Displayrand verfügbar ist:

[7.2.3/H-0-1] Der Bereich für die Navigationsfunktion darf auf jeder Seite nicht breiter als 40 dp sein. Der Bereich für Touch-Gesten sollte standardmäßig 24 dp breit sein.

2.2.4. Leistung und Akkulaufzeit

[8.1/H-0-1] Gleichbleibende Frame-Latenz. Eine schwankende Frame-Latenz oder eine Verzögerung beim Rendern von Frames darf NICHT häufiger als 5 Frames pro Sekunde auftreten und sollte unter 1 Frame pro Sekunde liegen.
[8.1/H-0-2] Latenz der Benutzeroberfläche. Geräteimplementierungen MÜSSEN eine geringe Latenz gewährleisten, indem eine Liste mit 10.000 Listeneinträgen gemäß der Android Compatibility Test Suite (CTS) in weniger als 36 Sekunden gescrollt wird.
[8.1/H-0-3] Aufgabenwechsel. Wenn mehrere Anwendungen gestartet wurden, darf das erneute Starten einer bereits laufenden Anwendung nach dem Start weniger als eine Sekunde dauern.

Implementierungen für E-Reader und Handheld-Computer:

[8.2/H-0-1] Die sequenzielle Schreibleistung muss mindestens 5 MB/s betragen.
[8.2/H-0-2] Die zufällige Schreibleistung muss mindestens 0,5 MB/s betragen.
[8.2/H-0-3] MÜSSEN eine sequenzielle Leseleistung von mindestens 15 MB/s gewährleisten.
[8.2/H-0-4] Die Leistung bei zufälligen Lesevorgängen muss mindestens 3,5 MB/s betragen.

Wenn Implementierungen von Mobilgeräten Funktionen zur Verbesserung der Geräteenergieverwaltung enthalten, die in AOSP enthalten sind, oder die in AOSP enthaltenen Funktionen erweitern, gelten folgende Anforderungen:

[8.3/H-1-1] Es MUSS eine Nutzerinteraktion zum Aktivieren und Deaktivieren des Energiesparmodus geben.
[8.3/H-1-2] Es MUSS eine Nutzerfunktion geben, mit der alle Apps angezeigt werden können, die vom App-Standby- und Doze-Energiesparmodus ausgenommen sind.

Implementierungen für E-Reader und Handheld-Computer:

[8.4/H-0-1] Es MUSS ein Energieprofil pro Komponente angegeben werden, das den Wert für den aktuellen Verbrauch für jede Hardwarekomponente und den ungefähren Akkuverbrauch definiert, der durch die Komponenten im Laufe der Zeit verursacht wird, wie auf der Website des Android Open Source Project dokumentiert.
[8.4/H-0-2] Alle Werte für den Energieverbrauch MÜSSEN in Milliamperestunden (mAh) angegeben werden.
[8.4/H-0-3] MÜSSEN den CPU-Stromverbrauch pro UID des Prozesses angeben. Das Android Open Source Project erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
[8.4/H-0-4] MÜSSEN diese Stromaufnahme über den Shell-Befehl adb shell dumpsys batterystats für den App-Entwickler verfügbar machen.
[8.4/H] MÜSSEN der Hardwarekomponente selbst zugeordnet werden, wenn die Stromaufnahme der Hardwarekomponente keiner Anwendung zugeordnet werden kann.

Wenn Implementierungen von Handheld-Geräten einen Bildschirm oder eine Videoausgabe umfassen, müssen sie:

[8.4/H-1-1] MUSS die android.intent.action.POWER_USAGE_SUMMARY-Intent berücksichtigen und ein Einstellungsmenü anzeigen, in dem diese Stromnutzung angezeigt wird.

2.2.5. Sicherheitsmodell

Implementierungen für E-Reader und Handheld-Computer:

[9.1/H-0-1] Drittanbieter-Apps MÜSSEN über die Berechtigung android.permission.PACKAGE_USAGE_STATS auf die Nutzungsstatistiken zugreifen können und einen nutzerzugänglichen Mechanismus bereitstellen, um den Zugriff auf solche Apps als Reaktion auf die Absicht android.settings.ACTION_USAGE_ACCESS_SETTINGS zu gewähren oder zu widerrufen.

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

[9.11/H-0-2]* Die Implementierung des Schlüsselspeichers MUSS mit einer isolierten Ausführungsumgebung gesichert werden.
[9.11/H-0-3]* MUSS Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie Hash-Funktionen der MD5-, SHA1- und SHA-2-Familie haben, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich zu unterstützen, der sicher vom Code isoliert ist, der im 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. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternative Optionen sind jedoch eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation.
[9.11/H-0-4]* Die Authentifizierung für den Sperrbildschirm MUSS in der isolierten Ausführungsumgebung erfolgen und nur bei Erfolg dürfen die authentifizierten Schlüssel verwendet werden. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Sperrbildschirmauthentifizierung ausführen kann. Das Upstream-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
[9.11/H-0-5]* MUSS die Schlüsselattestierung unterstützen, bei der der Attestierungssignaturschlüssel durch sichere Hardware geschützt und die Signatur in sicherer Hardware ausgeführt wird. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten freigegeben werden, um zu verhindern, dass sie als Geräte-IDs verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, es sei denn, es werden mindestens 100.000 Einheiten einer bestimmten SKU produziert. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, kann für jede 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version gestartet wurde, ist dieses Gerät von der Anforderung ausgenommen, einen von einer abgeschotteten Ausführungsumgebung unterstützten Schlüsselspeicher zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, die android.hardware.fingerprint-Funktion wird deklariert, für die ein von einer abgeschotteten Ausführungsumgebung unterstützter Schlüsselspeicher erforderlich ist.

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

[9.11/H-1-1] Der Nutzer MUSS die kürzeste Zeitüberschreitung für den Ruhemodus auswählen können, d. h. die Übergangszeit vom entsperrten zum gesperrten Zustand, und diese darf maximal 15 Sekunden betragen.
[9.11/H-1-2] Es MUSS eine Nutzerfunktion geben, mit der Benachrichtigungen ausgeblendet und alle Authentifizierungsformen deaktiviert werden können, mit Ausnahme der primären Authentifizierung, die in 9.11.1 Sicherer Sperrbildschirm beschrieben ist. Das AOSP erfüllt die Anforderung als Sperrmodus.

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

[9.5/H-2-1] MUSS eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteinhaber zusätzliche Nutzer und deren Funktionen auf dem Gerät verwalten können. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen in den Apps verwalten, die in diesen Umgebungen verfügbar sind.

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

[9.5/H-3-1] Es dürfen KEINE eingeschränkten Profile unterstützt werden. Die Steuerelemente müssen jedoch der AOSP-Implementierung entsprechen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen oder zu deaktivieren.

2.2.6. Kompatibilität von Entwicklertools und ‑optionen

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

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

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

Perfetto
- [6.1/H-0-2]* Dem Shell-Nutzer muss eine /system/bin/perfetto-Binärdatei mit einer Befehlszeile zur Verfügung gestellt werden, die der Dokumentation zu perfetto entspricht.
- [6.1/H-0-3]* Die perfetto-Binärdatei MUSS als Eingabe eine Protobuf-Konfiguration akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/H-0-4]* Die perfetto-Binärdatei 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 perfetto-Binärdatei 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 Leistungsklasse für tragbare Medien

Die Definition der Leistungsklasse für Medien finden Sie in Abschnitt 7.11.

2.2.7.1. Medien

Wenn bei Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.R für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgegeben wird, gilt Folgendes:

[5.1/H-1-1] MÜSSEN die maximale Anzahl von Hardware-Videodecodersitzungen angeben, die in beliebiger Codec-Kombination gleichzeitig ausgeführt werden können, und zwar über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-2] MÜSSEN 6 Instanzen von Hardware-Videodecodersitzungen (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-3] MÜSSEN die maximale Anzahl von Hardware-Videoencoder-Sitzungen angeben, die gleichzeitig in einer beliebigen Kombination von Codecs über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() ausgeführt werden können.
[5.1/H-1-4] MÜSSEN 6 Instanzen von 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-5] MÜSSEN die maximale Anzahl von Hardware-Videoencoder- und ‑decodersitzungen angeben, die in beliebiger Codec-Kombination gleichzeitig ausgeführt werden können, und zwar über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-6] MÜSSEN 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] Für alle Hardware-Videoencoder (außer Dolby Vision-Codec) muss die Codec-Initialisierungslatenz bei einer Videocodierungssitzung mit 1080p oder weniger unter Last 65 ms oder weniger betragen. „Auslastung“ wird hier als eine gleichzeitige Transcodierungssitzung von 1080p auf 720p definiert, bei der Hardware-Videocodecs zusammen mit der Initialisierung der 1080p-Audio-Videoaufnahme verwendet werden.
[5.1/H-1-8] Die Codec-Initialisierungslatenz für eine Audiocodierungssitzung mit einer Bitrate von 128 kbit/s oder weniger für alle Audioencoder muss bei Belastung 50 ms oder weniger betragen.Als Belastung wird hier eine gleichzeitige Transcodierungssitzung mit nur Video von 1080p auf 720p mit Hardware-Video-Codecs zusammen mit der Initialisierung der 1080p-Audio-/Videoaufzeichnung definiert.
[5.3/H-1-1] Bei einer Video-Sitzung mit 1080p und 30 fps darf bei Belastung KEIN Frame in 10 Sekunden (d.h.weniger als 0,333 % Frame-Drop) verloren gehen. Die Auslastung wird als gleichzeitige Transcodierungssitzung für 1080p-zu-720p-Videos mit Hardware-Video-Codecs sowie eine AAC-Audiowiedergabe mit 128 kbit/s definiert.
[5.3/H-1-2] Bei einer Änderung der Videoauflösung in einer Video-Sitzung mit 30 fps darf bei Belastung KEIN Frame pro 10 Sekunden verloren gehen. Die Auslastung wird als gleichzeitige Transcodierungssitzung für 1080p-zu-720p-Videos mit Hardware-Videocodecs sowie eine AAC-Audiowiedergabe mit 128 kbit/s definiert.
[5.6/H-1-1] Die Latenz beim Tippen-zum-Tönen muss unter 100 Millisekunden liegen, wenn der OboeTester-Tipp-zum-Tönen-Test oder der CTS-Verifier-Tipp-zum-Tönen-Test verwendet wird.

2.2.7.2. Kamera

Wenn bei Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.R für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgegeben wird, gilt Folgendes:

[7.5/H-1-1] Es MUSS eine primäre Rückkamera mit einer Auflösung von mindestens 12 Megapixeln haben, die die Videoaufzeichnung 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] Es MUSS eine primäre Frontkamera mit einer Auflösung von mindestens 4 Megapixeln haben, die die Videoaufzeichnung mit 1080p bei 30 fps unterstützt. Die primäre Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
[7.5/H-1-3] Die Eigenschaft „android.info.supportedHardwareLevel“ MUSS für die primäre Rückkamera den Wert „FULL“ oder höher und für die primäre Frontkamera den Wert „LIMITED“ oder höher unterstützen.
[7.5/H-1-4] MUSS CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME für beide Hauptkameras unterstützen.
[7.5/H-1-5] Die Latenz der JPEG-Aufnahme mit camera2 für 1080p-Auflösung muss unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Hauptkameras unter 1.000 ms liegen, wie im CTS-Kamera-Leistungstest gemessen.
[7.5/H-1-6] Die Kamera 2-Startlatenz (Öffnen der Kamera bis zum ersten Vorschauframe) muss unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Hauptkameras unter 600 ms liegen, wie im CTS-Kamera-Leistungstest gemessen.

2.2.7.3. Hardware

Wenn Implementierungen für Mobilgerä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] Die Bildschirmauflösung muss mindestens 1080p betragen.
[7.1.1.3/H-1-1] Die Bildschirmdichte muss mindestens 400 dpi betragen.
[7.6.1/H-1-1] Es muss mindestens 6 GB Arbeitsspeicher haben.

2.2.7.4. Leistung

Wenn Implementierungen für Mobilgerä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] MÜSSEN eine sequenzielle Schreibleistung von mindestens 100 MB/s gewährleisten.
[8.2/H-1-2] Die zufällige Schreibleistung muss mindestens 10 MB/s betragen.
[8.2/H-1-3] MÜSSEN eine sequenzielle Leseleistung von mindestens 200 MB/s gewährleisten.
[8.2/H-1-4] Die Leistung bei zufälligen Lesevorgängen muss mindestens 25 MB/s betragen.

2.3. Anforderungen an Fernseher

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

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

Sie haben einen Mechanismus zur Fernsteuerung der gerenderten Benutzeroberfläche auf dem Display bereitgestellt, das sich möglicherweise drei Meter vom Nutzer entfernt befindet.
Sie müssen ein integriertes Display mit einer Diagonale von mehr als 61 cm haben ODER einen Videoausgang wie VGA, HDMI, DisplayPort oder einen kabellosen Anschluss für das Display 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 ein D-Pad unterstützen.
[7.2.3/T-0-1] MÜSSEN die Funktionen „Startseite“ und „Zurück“ bereitstellen.
[7.2.3/T-0-2] Es MUSS sowohl das normale als auch das Ereignis „Lang gedrückt halten“ der Zurück-Funktion (KEYCODE_BACK) an die App im Vordergrund gesendet werden.
[7.2.6.1/T-0-1] MUSS die Unterstützung für Gamecontroller umfassen und die android.hardware.gamepad-Funktionsflag deklarieren.
[7.2.7/T] Es sollte eine Fernbedienung vorhanden sein, über die Nutzer auf die Touchbedienung und die wichtigsten Navigationstasten zugreifen können.

Wenn Fernsehgeräte ein 3-Achsen-Gyroskop haben, gilt Folgendes:

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

Implementierungen von Fernsehgeräten:

[7.4.3/T-0-1] MUSS Bluetooth und Bluetooth LE unterstützen.
[7.6.1/T-0-1] Es muss mindestens 4 GB nichtflüchtiger Speicher für private Daten der Anwendung (auch als „/data“-Partition bezeichnet) verfügbar sein.

Wenn Fernseher einen USB-Anschluss haben, der den Hostmodus unterstützt, gilt Folgendes:

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

Wenn die Implementierungen von Fernsehgeräten 32-Bit sind:

[7.6.1/T-1-1] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 896 MB betragen, wenn eine der folgenden Dichten verwendet wird:
- 400 dpi oder höher auf kleinen/normalen Bildschirmen
- xhdpi oder höher auf großen Bildschirmen
- tvdpi oder höher auf sehr großen Bildschirmen

Wenn die Implementierungen von Fernsehgeräten 64-Bit sind:

[7.6.1/T-2-1] Der für den Kernel und den Userspace 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
- tvdpi oder höher auf sehr großen Bildschirmen

Hinweis: Der oben genannte „für den Kernel und Userspace verfügbare Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicher, der zusätzlich zu dem Arbeitsspeicher bereitgestellt wird, der bereits für Hardwarekomponenten wie Radio, Video usw. reserviert ist, die bei Geräteimplementierungen nicht vom Kernel gesteuert werden.

Implementierungen von Fernsehgeräten:

[7.8.1/T] Es sollte ein Mikrofon enthalten.
[7.8.2/T-0-1] MUSS eine Audioausgabe haben und android.hardware.audio.output angeben.

2.3.2. Multimedia

Fernsehgeräte müssen die folgenden Audiocodierungs- und -decodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

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

Fernsehgeräte müssen die folgenden Videocodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

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

Implementierungen von Fernsehgeräten:

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

Fernsehgeräte müssen die folgenden Videodekodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

[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

Fernsehgeräte müssen die MPEG-2-Dekodierung gemäß Abschnitt 5.3.1 bei Standard-Videoframeraten und -auflösungen bis zu und einschließlich der folgenden unterstützen:

[5.3.1/T-1-1] HD 1080p mit 29,97 Frames 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 interlaced MPEG-2-Video deinterlaced und für Drittanbieter-Anwendungen verfügbar machen.

Fernsehgeräte müssen die H.264-Dekodierung gemäß Abschnitt 5.3.4 bei Standard-Videoframeraten und -auflösungen bis zu und einschließlich der folgenden unterstützen:

[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 Hauptprofil
[5.3.4/T-1-3] HD 1080p bei 60 Bildern pro Sekunde mit High Profile Level 4.2

Fernsehgeräte mit H.265-Hardwaredekodern MÜSSEN die H.265-Decodierung gemäß Abschnitt 5.3.5 bei Standard-Videoframeraten und -auflösungen bis zu und einschließlich Folgendem unterstützen:

[5.3.5/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit dem Hauptprofil der Stufe 4.1

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

[5.3.5/T-2-1] MUSS das UHD-Dekodierungsprofil mit 60 Frames pro Sekunde mit dem Main10 Level 5 Main Tier-Profil unterstützen

Fernsehgeräte müssen die VP8-Decodierung gemäß Abschnitt 5.3.6 bei Standard-Videoframeraten und -auflösungen bis zu und einschließlich der folgenden unterstützen:

[5.3.6/T-1-1] Dekodierungsprofil für HD 1080p bei 60 Bildern pro Sekunde

Fernsehgeräte mit VP9-Hardwaredekodern MÜSSEN die VP9-Decodierung gemäß Abschnitt 5.3.7 bei Standard-Videoframeraten und -auflösungen bis zu und 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äte mit VP9-Hardwaredekodern die VP9-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:

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

Implementierungen von Fernsehgeräten:

[5.5/T-0-1] MUSS die Unterstützung für die Master-Lautstärke des Systems und die Lautstärkedämpfung der digitalen Audioausgabe an unterstützten Ausgängen umfassen, mit Ausnahme der komprimierten Audio-Passthrough-Ausgabe (bei der keine Audiodekodierung auf dem Gerät erfolgt).

Wenn Fernseher keine integrierten Displays haben, aber stattdessen ein externes Display unterstützen, das über HDMI angeschlossen ist, gilt Folgendes:

[5.8/T-0-1] Der HDMI-Ausgabemodus muss so eingestellt werden, dass die maximale Auflösung ausgewählt wird, die 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 HDMI-Bildwiederholratenauswahl bereitzustellen.
[5.8] Die Aktualisierungsrate des HDMI-Ausgabemodus sollte entweder auf 50 Hz oder 60 Hz festgelegt werden, je nach Videoaktualisierungsrate für die Region, in der das Gerät verkauft wird.

Wenn Fernseher keine integrierten Displays haben, aber stattdessen ein externes Display unterstützen, das über HDMI angeschlossen ist, gilt Folgendes:

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

Wenn Fernseher keine UHD-Dekodierung unterstützen, aber ein externes Display über HDMI, 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 deklariert werden.
[3.2.3.1/T-0-1] Es MUSS mindestens eine Anwendung oder Dienstkomponente mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorgeladen werden, die durch die hier aufgeführten Anwendungsabsichten definiert sind.
[3.4.1/T-0-1] Es MUSS eine vollständige Implementierung der android.webkit.Webview API bereitgestellt werden.

Wenn Android TV-Geräte einen Sperrbildschirm unterstützen,müssen sie folgende Anforderungen erfüllen:

[3.8.10/T-1-1] Die Sperrbildschirmbenachrichtigungen, einschließlich der Vorlage für Medienbenachrichtigungen, MÜSSEN angezeigt werden.

Implementierungen von Fernsehgeräten:

[3.8.14/T-SR] Es wird DRINGEND empfohlen, den Modus „Bild im Bild“ (Picture-in-Picture, PiP) für mehrere Fenster zu unterstützen.
[3.10/T-0-1] MÜSSEN Dienste zur Barrierefreiheit von Drittanbietern unterstützen.
[3.10/T-SR] Es wird DRINGEND empfohlen, Bedienungshilfen auf dem Gerät vorinstalliert zu haben, die mit den Funktionen von Switch Access und TalkBack (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden) vergleichbar sind oder diese übertreffen. Diese Bedienungshilfen müssen im Rahmen des TalkBack Open Source-Projekts bereitgestellt werden.

Wenn bei der Implementierung von Fernsehgeräten die Funktion android.hardware.audio.output gemeldet wird, gilt Folgendes:

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

Implementierungen von Fernsehgeräten:

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

2.3.4. Leistung und Akkulaufzeit

[8.1/T-0-1] Gleichbleibende Frame-Latenz. Eine unterschiedliche Frame-Latenz oder eine Verzögerung beim Rendern von Frames darf NICHT häufiger als 5 Frames pro Sekunde auftreten und sollte unter 1 Frame pro Sekunde liegen.
[8.2/T-0-1] Die sequenzielle Schreibleistung muss mindestens 5 MB/s betragen.
[8.2/T-0-2] Die Zufallsschreibleistung muss mindestens 0,5 MB/s betragen.
[8.2/T-0-3] MÜSSEN eine sequenzielle Leseleistung von mindestens 15 MB/s gewährleisten.
[8.2/T-0-4] Die Leistung bei zufälligen Lesevorgängen muss mindestens 3,5 MB/s betragen.

Wenn Fernseher Funktionen zur Verbesserung der Geräteenergieverwaltung enthalten, die in AOSP enthalten sind, oder die in AOSP enthaltenen Funktionen erweitern, gelten folgende Anforderungen:

[8.3/T-1-1] Es MUSS eine Nutzerinteraktion zum Aktivieren und Deaktivieren der Energiesparfunktion geben.

Wenn Fernsehgeräte keine Akkus haben, gilt Folgendes:

[8.3/T-1-2] Das Gerät muss wie unter Unterstützung für akkulose Geräte beschrieben als akkuloses Gerät registriert werden.

Wenn Fernsehgeräte einen Akku haben, gilt Folgendes:

[8.3/T-1-3] Es MUSS eine Nutzerfunktion geben, mit der alle Apps angezeigt werden können, die vom App-Standby und vom Doze-Energiesparmodus ausgenommen sind.

Implementierungen von Fernsehgeräten:

[8.4/T-0-1] Es MUSS ein Energieprofil pro Komponente angegeben werden, das den Wert für den aktuellen Verbrauch für jede Hardwarekomponente und den ungefähren Akkuverbrauch definiert, der durch die Komponenten im Laufe der Zeit verursacht wird, wie auf der Website des Android Open Source Project dokumentiert.
[8.4/T-0-2] Alle Werte für den Energieverbrauch MÜSSEN in Milliamperestunden (mAh) angegeben werden.
[8.4/T-0-3] Der CPU-Stromverbrauch muss pro UID des Prozesses angegeben werden. Das Android Open Source Project erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
[8.4/T] MÜSSEN der Hardwarekomponente selbst zugeordnet werden, wenn die Stromaufnahme der Hardwarekomponente keiner Anwendung zugeordnet werden kann.
[8.4/T-0-4] MÜSSEN diese Stromaufnahme über den Shell-Befehl adb shell dumpsys batterystats für den App-Entwickler verfügbar machen.

2.3.5. Sicherheitsmodell

Implementierungen von Fernsehgeräten:

[9.11/T-0-1] Die Implementierung des Schlüsselspeichers MUSS mit einer isolierten Ausführungsumgebung gesichert werden.
[9.11/T-0-2] MUSS Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie Hash-Funktionen der MD5-, SHA1- und SHA-2-Familie haben, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich ordnungsgemäß zu unterstützen, der sicher vom Code isoliert ist, der im 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. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternative Optionen sind jedoch eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation.
[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 Sperrbildschirmauthentifizierung ausführen kann. Das Upstream-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
[9.11/T-0-4] MUSS die Schlüsselattestierung unterstützen, bei der der Attestierungssignaturschlüssel durch sichere Hardware geschützt und die Signatur auf sicherer Hardware ausgeführt wird. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten freigegeben werden, um zu verhindern, dass die Schlüssel als Geräte-IDs verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, es sei denn, es werden mindestens 100.000 Einheiten einer bestimmten SKU produziert. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, kann für jede 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version gestartet wurde, ist dieses Gerät von der Anforderung ausgenommen, einen Schlüsselspeicher zu haben, der von einer isolierten Ausführungsumgebung unterstützt wird, und die Schlüsselattestierung zu unterstützen, es sei denn, die android.hardware.fingerprint-Funktion wird deklariert, für die ein Schlüsselspeicher erforderlich ist, der von einer isolierten Ausführungsumgebung unterstützt wird.

Wenn Fernseher einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:

[9.11/T-1-1] Der Nutzer MUSS die Zeitüberschreitung für den Ruhemodus für den Übergang vom entsperrten zum gesperrten Zustand auswählen können. Die zulässige Mindestzeitüberschreitung darf 15 Sekunden nicht überschreiten.

Wenn Fernseherimplementierungen 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, eine Funktion, mit der Geräteinhaber zusätzliche Nutzer und deren Funktionen auf dem Gerät verwalten können. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen in den Apps verwalten, die in diesen Umgebungen verfügbar sind.

Wenn Implementierungen von Fernsehgeräten mehrere Nutzer umfassen und das android.hardware.telephony-Funktionsflag deklarieren, gilt Folgendes:

[9.5/T-3-1] Darf KEINE eingeschränkten Profile unterstützen, muss aber der AOSP-Implementierung der Steuerelemente entsprechen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen oder zu deaktivieren.

2.3.6. Kompatibilität von Entwicklertools und ‑optionen

Implementierungen von Fernsehgeräten:

Perfetto
- [6.1/T-0-1] Dem Shell-Nutzer MUSS eine /system/bin/perfetto-Binärdatei mit einer Befehlszeile zur Verfügung gestellt werden, die der Perfetto-Dokumentation entspricht.
- [6.1/T-0-2] Die perfetto-Binärdatei MUSS als Eingabe eine Protobuf-Konfiguration akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/T-0-3] Die perfetto-Binärdatei 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 perfetto-Binärdatei mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitstellen.

2.4. Smartwatch-Anforderungen

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

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

Sie haben ein Display mit einer physischen Diagonale von 28 bis 64 mm.
Sie müssen einen Mechanismus zum Tragen am Körper haben.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für die Implementierung von Android-Smartwatches.

2.4.1. Hardware

Geräteimplementierungen ansehen:

[7.1.1.1/W-0-1] MUSS ein Display mit einer physischen Diagonale von 2,8 bis 6,4 cm haben.
[7.2.3/W-0-1] Der Nutzer muss die Startbildschirmfunktion und die Zurück-Funktion nutzen können, es sei denn, er befindet sich in UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] MUSS die Eingabe über einen Touchscreen unterstützen.
[7.3.1/W-SR] Es wird DRINGEND empfohlen, einen 3-Achsen-Beschleunigungsmesser zu verwenden.

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

[7.3.3/W-1-1] GNSS-Messungen MÜSSEN gemeldet werden, sobald sie gefunden werden, auch wenn ein aus GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
[7.3.3/W-1-2] MÜSSEN GNSS-Pseudostrecken und Pseudostreckenraten melden, die bei freiem Blick nach der Standortbestimmung, bei Stillstand oder bei einer Beschleunigung von weniger als 0,2 Metern pro Sekunde zum Quadrat ausreichen, um mindestens 95% der Zeit die Position innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0,2 Metern pro Sekunde zu berechnen.

Wenn Smartwatch-Implementierungen ein 3-Achsen-Gyroskop enthalten, gilt Folgendes:

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

Geräteimplementierungen ansehen:

[7.4.3/W-0-1] MUSS Bluetooth unterstützen.
[7.6.1/W-0-1] Es muss mindestens 1 GB nichtflüchtiger Speicher für private Anwendungsdaten (auch „/data“-Partition genannt) verfügbar sein.
[7.6.1/W-0-2] Für den Kernel und den Userspace müssen mindestens 416 MB Arbeitsspeicher verfügbar sein.
[7.8.1/W-0-1] MUSS ein Mikrofon enthalten.
[7.8.2/W] KANN eine Audioausgabe haben.

2.4.2. Multimedia

Es gelten keine zusätzlichen Anforderungen.

2.4.3. Software

Geräteimplementierungen ansehen:

[3/W-0-1] Die Funktion android.hardware.type.watch MUSS deklariert werden.
[3/W-0-2] MUSS uiMode = UI_MODE_TYPE_WATCH unterstützen.
[3.2.3.1/W-0-1] Es MUSS mindestens eine Anwendung oder Dienstkomponente mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorgeladen werden, die durch die hier aufgeführten Anwendungsabsichten definiert sind.

Geräteimplementierungen ansehen:

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

Sehen Sie sich Geräteimplementierungen an, in denen das android.hardware.audio.output-Funktionsflag deklariert wird:

[3.10/W-1-1] MÜSSEN Dienste zur Barrierefreiheit von Drittanbietern unterstützen.
[3.10/W-SR] Es wird DRINGEND empfohlen, Bedienungshilfen auf dem Gerät vorinstalliert zu haben, die mit den Funktionen von Switch Access und TalkBack (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden) vergleichbar sind oder diese übertreffen. Diese Bedienungshilfen müssen dem Open-Source-Projekt TalkBack entsprechen.

Wenn bei Smartwatch-Implementierungen die Funktion „android.hardware.audio.output“ gemeldet wird, gilt Folgendes:

[3.11/W-SR] Es wird DRINGEND empfohlen, eine TTS-Engine zu verwenden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
[3.11/W-0-1] MUSS die Installation von TTS-Engines von Drittanbietern unterstützen.

2.4.4. Leistung und Akkulaufzeit

Wenn Smartwatch-Implementierungen Funktionen zur Verbesserung der Geräteenergieverwaltung enthalten, die in AOSP enthalten sind, oder die in AOSP enthaltenen Funktionen erweitern, gelten folgende Anforderungen:

[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 EMPFOHLEN, Nutzern die Möglichkeit zu geben, den Energiesparmodus zu aktivieren und zu deaktivieren.

Geräteimplementierungen ansehen:

[8.4/W-0-1] Es MUSS ein Energieprofil pro Komponente bereitgestellt werden, das den Wert für den aktuellen Verbrauch für jede Hardwarekomponente und den ungefähren Akkuverbrauch definiert, der durch die Komponenten im Laufe der Zeit verursacht wird, wie auf der Website des Android Open Source Project dokumentiert.
[8.4/W-0-2] Alle Werte für den Energieverbrauch MÜSSEN in Milliamperestunden (mAh) angegeben werden.
[8.4/W-0-3] Der CPU-Stromverbrauch muss pro UID des Prozesses angegeben werden. Das Android Open Source Project erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
[8.4/W-0-4] MÜSSEN diese Stromaufnahme über den Shell-Befehl adb shell dumpsys batterystats für den App-Entwickler verfügbar machen.
[8,4 W] MÜSSEN der Hardwarekomponente selbst zugeordnet werden, wenn die Stromaufnahme der Hardwarekomponente keiner Anwendung zugeordnet werden kann.

2.4.5. Sicherheitsmodell

Wenn die Implementierung von Smartwatch-Geräten mehrere Nutzer umfasst und das android.hardware.telephony-Funktionsflag nicht deklariert wird, gilt Folgendes:

[9.5/W-1-1] MUSS eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteeigentümer zusätzliche Nutzer und deren Funktionen auf dem Gerät verwalten können. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen in den Apps verwalten, die in diesen Umgebungen verfügbar sind.

Wenn Implementierungen von Smartwatch-Geräten mehrere Nutzer umfassen und das android.hardware.telephony-Funktionsflag deklarieren, gilt Folgendes:

[9.5/W-2-1] Es dürfen KEINE eingeschränkten Profile unterstützt werden. Die Steuerelemente müssen jedoch der AOSP-Implementierung entsprechen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen oder zu deaktivieren.

2.5. Anforderungen für die Automobilbranche

Eine Android Automotive-Implementierung bezieht sich auf eine Auto-Haupteinheit, auf der Android als Betriebssystem für einen Teil oder alle System- und/oder Infotainmentfunktionen ausgeführt wird.

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

Sie sind in ein Fahrzeug eingebettet oder können an ein Fahrzeug angeschlossen werden.
Sie verwenden ein Display in der Fahrerreihe als primäres Display.

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

2.5.1. Hardware

Implementierungen von Fahrzeuggeräten:

[7.1.1.1/A-0-1] Das Display muss eine Diagonale von mindestens 6 Zoll haben.
[7.1.1.1/A-0-2] Das Layout muss eine Bildschirmgröße von mindestens 750 dp × 480 dp haben.
[7.2.3/A-0-1] MUSS die Startbildschirmfunktion und DARF die Funktionen „Zurück“ und „Letzte Apps“ bereitstellen.
[7.2.3/A-0-2] Es MUSS sowohl das normale als auch das Ereignis „Langes Drücken“ der Zurück-Funktion (KEYCODE_BACK) an die App im Vordergrund gesendet werden.
[7.3/A-0-1] GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED und PARKING_BRAKE_ON MÜSSEN implementiert und gemeldet werden.
[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 mit dem Photometer identisch sein.
[7.3/A-0-3] Für jeden angegebenen Sensor MUSS das Feld „Zusätzliche Sensorinformationen“ TYPE_SENSOR_PLACEMENT als Teil von „SensorAdditionalInfo“ angegeben werden.
[7.3/A-0-1] KANN den Standort durch Fusion von GPS/GNSS mit zusätzlichen Sensoren per Positionsbestimmung bestimmen. Wenn Standort per Positionsbestimmung ermittelt wird, wird DRINGEND empfohlen, die entsprechenden Sensor-Typen und/oder Fahrzeugeigenschafts-IDs zu implementieren und anzugeben.
[7.3/A-0-2] Der über LocationManager#requestLocationUpdates() angeforderte Standort DARF NICHT mit einer Karte abgeglichen werden.

Wenn die Implementierung von Automotive-Geräten einen 3-Achsen-Beschleunigungsmesser enthält, 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 des Android-Autosensors entsprechen.

Wenn die Implementierung von Geräten für die Automobilbranche ein 3-Achsen-Gyroskop umfasst, gilt Folgendes:

[7.3.4/A-2-1] MUSS Ereignisse mit einer Frequenz von mindestens 100 Hz erfassen können.
[7.3.4/A-2-2] MUSS auch den TYPE_GYROSCOPE_UNCALIBRATED-Sensor implementieren.
[7.3.4/A-2-3] MÜSSEN in der Lage sein, Ausrichtungsänderungen 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 Auflösung zu maximieren.

Wenn die Implementierung von Fahrzeuggeräten einen GPS-/GNSS-Empfänger, aber keine Mobilfunknetz-basierte Datenverbindung umfasst, gilt Folgendes:

[7.3.3/A-3-1] Der Standort muss beim ersten Einschalten des GPS-/GNSS-Empfängers oder nach mehr als 4 Tagen innerhalb von 60 Sekunden bestimmt werden.
[7.3.3/A-3-2] MÜSSEN die Kriterien für die Zeit bis zur ersten Fixierung gemäß 7.3.3/C-1-2 und 7.3.3/C-1-6 für alle anderen Standortanfragen erfüllen (d. h. Anfragen, die nicht zum ersten Mal oder nach mehr als 4 Tagen gestellt werden). Die Anforderung 7.3.3/C-1-2 wird in Fahrzeugen ohne zellulare Datenverbindung in der Regel durch die Verwendung von GNSS-Orbitvorhersagen erfüllt, die auf dem Empfänger berechnet werden, oder durch die Verwendung der letzten bekannten Fahrzeugposition und der Möglichkeit, mindestens 60 Sekunden lang mit einer Positionsabweichung, die 7.3.3/C-1-3 erfüllt, per Positionsbestimmung ohne Satelliten zu navigieren, oder durch eine Kombination aus beiden.

Implementierungen von Fahrzeuggeräten:

[7.4.3/A-0-1] MUSS Bluetooth und SOLLTE Bluetooth LE unterstützen.
[7.4.3/A-0-2] Android Automotive-Implementierungen MÜSSEN die folgenden Bluetooth-Profile unterstützen:
- Telefonanrufe über das Hands-Free Profile (HFP)
- Medienwiedergabe über Audio Distribution Profile (A2DP)
- Steuerung der Medienwiedergabe über das Remote Control Profile (AVRCP).
- Kontaktfreigabe über das 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] Es sollte Unterstützung für die mobilfunkbasierte Datenverbindung enthalten.
[7.4.5/A] Die System API-Konstante NetworkCapabilities#NET_CAPABILITY_OEM_PAID darf für Netzwerke verwendet werden, die für System-Apps verfügbar sein sollten.

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

Implementierungen von Fahrzeuggeräten:

MÜSSEN eine oder mehrere Kameras für die Außenansicht enthalten.

Wenn die Implementierung von Automotive-Geräten eine Kamera für die Außenansicht umfasst, gelten für diese Kamera folgende Anforderungen:

[7.5/A-1-1] Es dürfen KEINE Kameras für die Außenansicht vorhanden sein, auf die über die Android Camera APIs zugegriffen werden kann, es sei denn, sie erfüllen die grundlegenden Anforderungen 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 EMPFOHLEN, die Kamera so auszurichten, dass die lange Seite der Kamera parallel zum Horizont verläuft.
[7.5/A-SR] Es wird DRINGEND empfohlen, eine Auflösung von mindestens 1,3 Megapixeln zu verwenden.
MÜSSEN entweder eine Hardware mit fester Brennweite oder eine Hardware mit erweiterter Schärfentiefe haben.
MÜSSEN das Android-Synchronisierungs-Framework unterstützen.
KANN entweder einen Hardware- oder Software-Autofokus im Kameratreiber haben.

Implementierungen von Fahrzeuggeräten:

[7.6.1/A-0-1] Es muss mindestens 4 GB nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) verfügbar sein.
[7.6.1/A] Die Datenpartition sollte formatiert werden, um eine bessere Leistung und Langlebigkeit des Flash-Speichers zu ermöglichen, z. B. mit dem Dateisystem f2fs.

Wenn Implementierungen von Automotive-Geräten über einen Teil des internen nicht entfernbaren Speichers freigegebenen externen Speicher bereitstellen, gilt Folgendes:

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

Wenn die Implementierungen von Automotive-Geräten 32-Bit sind:

[7.6.1/A-1-1] Der für den Kernel und den Userspace 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 sehr großen Bildschirmen
- mdpi oder niedriger auf großen Bildschirmen
[7.6.1/A-1-2] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 608 MB betragen, wenn eine der folgenden Speicherdichten verwendet wird:
- xhdpi oder höher auf kleinen/normalen Displays
- hdpi oder höher auf großen Bildschirmen
- mdpi oder höher auf sehr großen Bildschirmen
[7.6.1/A-1-3] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 896 MB betragen, wenn eine der folgenden Speicherdichten verwendet wird:
- 400 dpi oder höher auf kleinen/normalen Bildschirmen
- xhdpi oder höher auf großen Bildschirmen
- tvdpi oder höher auf sehr großen Bildschirmen
[7.6.1/A-1-4] Der für den Kernel und den Userspace 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 extra großen Bildschirmen

Wenn die Implementierungen von Automotive-Geräten 64-Bit sind:

[7.6.1/A-2-1] Der für den Kernel und den Userspace 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 sehr großen Bildschirmen
- mdpi oder niedriger auf großen Bildschirmen
[7.6.1/A-2-2] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 944 MB betragen, wenn eine der folgenden Dichten verwendet wird:
- xhdpi oder höher auf kleinen/normalen Displays
- hdpi oder höher auf großen Bildschirmen
- mdpi oder höher auf sehr großen Bildschirmen
[7.6.1/A-2-3] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 1.280 MB betragen, wenn eine der folgenden Speicherdichten verwendet wird:
- 400 dpi oder höher auf kleinen/normalen Bildschirmen
- xhdpi oder höher auf großen Bildschirmen
- tvdpi oder höher auf sehr großen Bildschirmen
[7.6.1/A-2-4] Der für den Kernel und den Userspace 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 extra großen Bildschirmen

Implementierungen von Fahrzeuggeräten:

[7.7.1/A] Es sollte einen USB-Anschluss mit Unterstützung für den Peripheriemodus haben.

Implementierungen von Fahrzeuggeräten:

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

Implementierungen von Fahrzeuggeräten:

[7.8.2/A-0-1] MUSS eine Audioausgabe haben und android.hardware.audio.output angeben.

2.5.2. Multimedia

Implementierungen von Automotive-Geräten MÜSSEN die folgenden Audiocodierungs- und -decodierungsformate unterstützen und für Drittanbieter-Apps verfügbar machen:

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

Implementierungen von Automotive-Geräten MÜSSEN die folgenden Videocodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

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

Implementierungen von Automotive-Geräten MÜSSEN die folgenden Videodekodierungsformate unterstützen und für Drittanbieter-Apps 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

Bei der Implementierung von Geräten für die Automobilbranche wird dringend empfohlen, die folgende Videodekodierung zu unterstützen:

[5.3/A-SR] H.265 HEVC

2.5.3. Software

Implementierungen von Fahrzeuggeräten:

[3/A-0-1] Die Funktion android.hardware.type.automotive MUSS deklariert werden.
[3/A-0-2] MUSS uiMode = UI_MODE_TYPE_CAR unterstützen.
[3/A-0-3] MUSS alle öffentlichen APIs im Namespace android.car.* unterstützen.

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

[3/A-1-1] Es dürfen KEINE speziellen Berechtigungen für die Verwendung dieser Properties durch Systemanwendungen festgelegt oder die Verwendung dieser Properties durch Drittanbieteranwendungen verhindert werden.
[3/A-1-2] Eine Fahrzeugeigenschaft, die bereits im SDK vorhanden ist, darf NICHT repliziert werden.

Implementierungen von Fahrzeuggeräten:

[3.2.1/A-0-1] MÜSSEN alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der Referenzseite für Berechtigungen für die Automobilbranche dokumentiert.
[3.2.3.1/A-0-1] Es MUSS mindestens eine Anwendung oder Dienstkomponente mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorgeladen werden, die durch die hier aufgeführten Anwendungsabsichten definiert sind.
[3.4.1/A-0-1] Es MUSS eine vollständige Implementierung der android.webkit.Webview API bereitgestellt werden.
[3.8.3/A-0-1] MÜSSEN Benachrichtigungen anzeigen, die die Notification.CarExtender API verwenden, wenn sie von Drittanbieteranwendungen angefordert werden.
[3.8.4/A-SR] Es wird dringend empfohlen, auf dem Gerät einen Assistenten zu implementieren, der die Hilfeaktion verarbeitet.

Wenn die Implementierung von Automotive-Geräten eine Push-to-Talk-Schaltfläche enthält, gilt Folgendes:

[3.8.4/A-1-1] MUSS ein kurzes Drücken der Push-to-Talk-Taste als Interaktion zum Starten der vom Nutzer ausgewählten Assistenz-App verwenden, d. h. der App, die VoiceInteractionService implementiert.

Implementierungen von Fahrzeuggeräten:

[3.8.3.1/A-0-1] Ressourcen MÜSSEN wie in der Notifications on Automotive OS SDK-Dokumentation beschrieben korrekt gerendert werden.
[3.8.3.1/A-0-2] MÜSSEN „WIEDERGAUEN“ und „STILL“ für Benachrichtigungsaktionen anstelle der über Notification.Builder.addAction() bereitgestellten Optionen anzeigen
[3.8.3.1/A] Die Verwendung umfangreicher Verwaltungsaufgaben wie Steuerelemente für Benachrichtigungskanäle sollte EINGESCHRENKt werden. Es KANN pro Anwendung UI-Affordance verwendet werden, um die Anzahl der Steuerelemente zu reduzieren.

Implementierungen von Fahrzeuggeräten:

[3.14/A-0-1] MUSS ein UI-Framework enthalten, um Drittanbieter-Apps zu unterstützen, die die Medien-APIs wie in Abschnitt 3.14 beschrieben verwenden.
[3.14/A-0-2] MUSS es dem Nutzer ermöglichen, während der Fahrt sicher mit Medienanwendungen zu interagieren.
[3.14/A-0-3] Die implizite Intent-Aktion CAR_INTENT_ACTION_MEDIA_TEMPLATE muss mit dem Extra CAR_EXTRA_MEDIA_PACKAGE unterstützt werden.
[3.14/A-0-4] Es MUSS eine Option geben, um die Einstellungen einer Medienanwendung aufzurufen. Diese Option darf jedoch nur aktiviert sein, wenn keine Einschränkungen für die Nutzererfahrung im Auto gelten.
[3.14/A-0-5] MÜSSEN Fehlermeldungen von Medienanwendungen anzeigen und MÜSSEN 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-Suche unterstützen.
[3.14/A-0-7] Die Definitionen für CONTENT_STYLE_BROWSABLE_HINT und CONTENT_STYLE_PLAYABLE_HINT MÜSSEN bei der Darstellung der MediaBrowser-Hierarchie eingehalten werden.

Wenn die Implementierung von Automotive-Geräten eine Standard-Launcher-App enthält, gilt Folgendes:

[3.14/A-1-1] MUSS Mediendienste enthalten und diese mit der Intent-Aktion CAR_INTENT_ACTION_MEDIA_TEMPLATE öffnen.

Implementierungen von Fahrzeuggeräten:

[3.8/A] Es ist MÖGLICH, die Anwendungsanfragen so einzuschränken, dass sie den Vollbildmodus wie unter immersive documentation beschrieben betreten.
[3.8/A] Die Statusleiste und die Navigationsleiste können jederzeit sichtbar sein.
[3.8/A] Die Anwendungsanfragen können eingeschränkt werden, um die Farben hinter den System-UI-Elementen zu ändern, damit diese Elemente jederzeit gut sichtbar sind.

2.5.4. Leistung und Akkulaufzeit

Implementierungen von Fahrzeuggeräten:

[8.2/A-0-1] MÜSSEN die Anzahl der Byte angeben, die pro UID des Prozesses aus nichtflüchtigem Speicher gelesen und geschrieben wurden, damit die Statistiken für Entwickler über die System API android.car.storagemonitoring.CarStorageMonitoringManager verfügbar sind. Das Android Open Source Project erfüllt die Anforderung über das uid_sys_stats-Kernelmodul.
[8.3/A-1-3] MUSS den Garage Mode unterstützen.
[8.3/A] Sollte nach jeder Fahrt mindestens 15 Minuten im Garagenmodus bleiben, es sei denn:
- Der Akku ist leer.
- Es sind keine inaktiven Jobs geplant.
- Der Fahrer beendet den Garagenmodus.
[8.4/A-0-1] Es MUSS ein Energieprofil pro Komponente angegeben werden, das den Wert für den aktuellen Verbrauch für jede Hardwarekomponente und den ungefähren Akkuverbrauch definiert, der durch die Komponenten im Laufe der Zeit verursacht wird, wie auf der Website des Android Open Source Project dokumentiert.
[8.4/A-0-2] Alle Werte für den Energieverbrauch MÜSSEN in Milliamperestunden (mAh) angegeben werden.
[8.4/A-0-3] Der CPU-Stromverbrauch muss pro UID des Prozesses angegeben werden. Das Android Open Source Project erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
[8.4/A] SOLLTE der Hardwarekomponente selbst zugeordnet werden, wenn die Stromaufnahme der Hardwarekomponente keiner Anwendung zugeordnet werden kann.
[8.4/A-0-4] MÜSSEN diese Stromaufnahme über den Shell-Befehl adb shell dumpsys batterystats für den App-Entwickler verfügbar machen.

2.5.5. Sicherheitsmodell

Wenn Implementierungen von Automotive-Geräten mehrere Nutzer unterstützen, müssen sie:

[9.5/A-1-1] Nutzer dürfen NICHT mit dem Nutzer des headless-Systems interagieren oder zu diesem wechseln, ausgenommen bei der Gerätebereitstellung.
[9.5/A-1-2] MÜSSEN 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.

Implementierungen von Fahrzeuggeräten:

[9.11/A-0-1] Die Implementierung des Schlüsselspeichers MUSS mit einer isolierten Ausführungsumgebung gesichert werden.
[9.11/A-0-2] MUSS Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie Hash-Funktionen der MD5-, SHA1- und SHA-2-Familie haben, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich ordnungsgemäß zu unterstützen, der sicher vom Code isoliert ist, der im 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. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternativ sind auch eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation möglich.
[9.11/A-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 Sperrbildschirmauthentifizierung ausführen kann. Das Upstream-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
[9.11/A-0-4] MUSS die Schlüsselattestierung unterstützen, bei der der Attestierungssignaturschlüssel durch sichere Hardware geschützt und die Signatur in sicherer Hardware ausgeführt wird. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten freigegeben werden, um zu verhindern, dass sie als Geräte-IDs verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, es sei denn, es werden mindestens 100.000 Einheiten einer bestimmten SKU produziert. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, kann für jede 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Implementierungen von Fahrzeuggeräten:

[9.14/A-0-1] MÜSSEN Nachrichten von Fahrzeug-Subsystemen des Android-Frameworks verwalten, z.B. durch Hinzufügen zulässiger Nachrichtentypen und Nachrichtenquellen zu einer Zulassungsliste.
[9.14/A-0-2] Es MUSS einen Watchdog gegen Denial-of-Service-Angriffe vom Android-Framework oder von Drittanbieter-Apps geben. So wird verhindert, dass Malware das Fahrzeugnetzwerk mit Traffic überlastet, was zu Fehlfunktionen von Fahrzeuguntersystemen führen kann.

2.5.6. Kompatibilität von Entwicklertools und ‑optionen

Implementierungen von Fahrzeuggeräten:

Perfetto
- [6.1/A-0-1] Dem Shell-Nutzer MUSS eine /system/bin/perfetto-Binärdatei mit einer Befehlszeile zur Verfügung gestellt werden, die der Perfetto-Dokumentation entspricht.
- [6.1/A-0-2] Die perfetto-Binärdatei MUSS als Eingabe eine Protobuf-Konfiguration akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/A-0-3] Die perfetto-Binärdatei 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 perfetto-Binärdatei mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitstellen.

2.6. Tabletanforderungen

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

Wird in beiden Händen gehalten.
Es hat keine Clamshell- oder Convertible-Konfiguration.
Physische Tastaturen, die mit dem Gerät verwendet werden, werden über eine Standardverbindung (z.B. USB, Bluetooth) verbunden.
Sie haben eine Stromquelle, die Mobilität bietet, z. B. einen Akku.
Die Bildschirmdiagonale liegt zwischen 7 und 18 Zoll.

Die Implementierung von Tablets hat ähnliche Anforderungen wie die von Mobilgeräten. Die Ausnahmen sind in diesem Abschnitt mit einem * gekennzeichnet.

2.6.1. Hardware

Displaygröße

[7.1.1.1/Tab-0-1] MUSS ein Display mit einer Größe von 18 bis 46 cm haben.

Gyroskop

Wenn Tablet-Implementierungen ein 3-Achsen-Gyroskop enthalten, gilt Folgendes:

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

Mindestarbeitsspeicher und Mindestspeicherplatz (Abschnitt 7.6.1)

Die Bildschirmdichten, die in den Anforderungen für Smartphones für kleine/normale Bildschirme aufgeführt sind, gelten nicht für Tablets.

USB-Peripheriegerätemodus (Abschnitt 7.7.1)

Wenn Tablet-Implementierungen einen USB-Anschluss haben, der den Peripheriemodus unterstützt, gilt Folgendes:

[7.7.1/Tab] Die Android Open Accessory API (AOA) KANN implementiert werden.

Virtueller Realitätsmodus (Abschnitt 7.9.1)

Hochleistung für virtuelle Realität (Abschnitt 7.9.2)

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

2.6.2. Sicherheitsmodell

Schlüssel und Anmeldedaten (Abschnitt 9.11)

Weitere Informationen finden Sie unter [9.11].

Wenn Implementierungen von Tablet-Geräten mehrere Nutzer umfassen und das android.hardware.telephony-Funktionsflag nicht deklariert wird, gilt Folgendes:

[9.5/T-1-1] MUSS eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteeigentümer zusätzliche Nutzer und deren Funktionen auf dem Gerät verwalten können. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen in den Apps verwalten, die in diesen Umgebungen verfügbar sind.

Wenn Implementierungen von Tablet-Geräten mehrere Nutzer umfassen und das android.hardware.telephony-Funktionsflag deklarieren, gilt Folgendes:

[9.5/T-2-1] Es dürfen KEINE eingeschränkten Profile unterstützt werden. Die Steuerelemente müssen jedoch der AOSP-Implementierung entsprechen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen oder zu deaktivieren.

2.6.2. Software

[3.2.3.1/Tab-0-1] Es MUSS eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler vorab geladen werden, für alle öffentlichen Intent-Filtermuster, die durch die hier aufgeführten Anwendungsabsichten definiert sind.

3. Software

3.1. Kompatibilität mit verwalteten APIs

Die verwaltete Dalvik-Bytecode-Ausführungsumgebung ist das primäre Mittel für Android-Anwendungen. Die Android 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] Es MÜSSEN vollständige Implementierungen aller dokumentierten APIs bereitgestellt werden, die vom Android SDK oder von APIs mit dem Markierungs-Tag „@SystemApi“ im Upstream-Android-Quellcode bereitgestellt werden, einschließlich aller dokumentierten Verhaltensweisen.
[C-0-2] Alle Klassen, Methoden und zugehörigen Elemente, die mit der TestApi-Anmerkung (@TestApi) gekennzeichnet sind, MÜSSEN unterstützt/erhalten werden.
[C-0-3] Es dürfen KEINE verwalteten APIs ausgelassen, API-Schnittstellen oder ‑Signaturen geändert, vom dokumentierten Verhalten abgewichen oder No-Ops verwendet werden, es sei denn, dies ist ausdrücklich in dieser Kompatibilitätsdefinition erlaubt.
[C-0-4] Die APIs MÜSSEN vorhanden sein und sich angemessen verhalten, auch wenn einige Hardwarefunktionen, für die Android APIs enthält, weggelassen werden. In Abschnitt 7 finden Sie spezifische Anforderungen für dieses Szenario.
[C-0-5] Drittanbieter-Apps dürfen KEINE Nicht-SDK-Schnittstellen verwenden, die als Methoden und Felder in den Java-Sprachpaketen definiert sind, die sich im Boot-Classpath in AOSP befinden und nicht Teil des öffentlichen SDKs sind. Dazu gehören APIs, die mit der Anmerkung @hide, aber nicht mit einer @SystemAPI versehen sind, wie in den SDK-Dokumenten beschrieben, sowie private und paketprivate Klassenmitglieder.
[C-0-6] MÜSSEN mit jeder nicht SDK-Schnittstelle auf denselben eingeschränkten Listen enthalten sein, die über die vorläufigen und Deaktivierungslisten im Pfad prebuilts/runtime/appcompat/hiddenapi-flags.csv für den entsprechenden API-Level-Zweig im AOSP angegeben sind.
[C-0-7] MUSS den dynamischen Aktualisierungsmechanismus für die signierte Konfiguration unterstützen, um Nicht-SDK-Schnittstellen aus einer eingeschränkten Liste zu entfernen, indem eine signierte Konfiguration in ein APK eingebettet wird, wobei die vorhandenen öffentlichen Schlüssel in AOSP verwendet werden.

Allerdings gilt:
- MÖGLICH: Wenn eine ausgeblendete API in der Geräteimplementierung nicht vorhanden oder anders implementiert ist, können Sie die ausgeblendete API in die Sperrliste verschieben oder sie aus allen eingeschränkten Listen (d.h. hellgrau, dunkelgrau, schwarz) ausschließen.
- MÖGLICH: Wenn eine versteckte API noch nicht im AOSP vorhanden ist, fügen Sie sie einer der eingeschränkten Listen hinzu (d.h. hellgrau, dunkelgrau oder schwarz).

3.1.1. Android-Erweiterungen

Android unterstützt die Erweiterung der verwalteten API-Oberfläche eines bestimmten API-Levels durch Aktualisieren der Erweiterungsversion für dieses API-Level. Die android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API gibt die Erweiterungsversion der angegebenen apiLevel zurück, sofern es Erweiterungen für diese API-Ebene gibt.

Implementierungen von Android-Geräten:

[C-0-1] Die AOSP-Implementierung der freigegebenen Bibliothek ExtShared und der Dienste ExtServices MUSS mit Versionen vorgeladen werden, die mindestens den für jede API-Ebene zulässigen Mindestversionen entsprechen. Beispielsweise müssen Geräteimplementierungen von Android 7.0 mit API-Level 24 mindestens Version 1 enthalten.
[C-0-2] Es MUSS nur eine gültige Erweiterungsversionsnummer zurückgegeben werden, die vom AOSP definiert wurde.
[C-0-3] MÜSSEN alle APIs unterstützen, die von den von android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) zurückgegebenen Erweiterungsversionen definiert sind, genau 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 in der Boot-Class-Path platziert werden.
[C-0-2] Die org.apache.http.legacy-Bibliothek darf dem Classpath der Anwendung nur dann hinzugefügt werden, wenn die App eine der folgenden Bedingungen erfüllt:
- Sie sind auf API-Level 28 oder niedriger ausgerichtet.
- Sie geben in Ihrem Manifest an, dass die Bibliothek erforderlich ist, indem Sie das android:name-Attribut von <uses-library> auf org.apache.http.legacy festlegen.

Die AOSP-Implementierung erfüllt diese Anforderungen.

3.2 Soft API Compatibility

Neben den verwalteten APIs aus Abschnitt 3.1 enthält Android auch eine wichtige „weiche“ API, die nur zur Laufzeit verwendet wird. Dazu gehören beispielsweise Intents, Berechtigungen und ähnliche Aspekte von Android-Apps, die nicht zur Kompilierungszeit der App erzwungen werden können.

3.2.1. Berechtigungen

[C-0-1] Geräteimplementierer MÜSSEN alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der Referenzseite für Berechtigungen beschrieben. In Abschnitt 9 sind zusätzliche Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell aufgeführt.

3.2.2. Parameter erstellen

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

[C-0-1] Um für alle Geräteimplementierungen einheitliche, aussagekräftige Werte bereitzustellen, enthält die folgende Tabelle zusätzliche Einschränkungen für die Formate dieser Werte, die von Geräteimplementierungen einzuhalten SIND.

Parameter	Details
VERSION.RELEASE	Die Version des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format. Dieses Feld MUSS einen der in 11 definierten Stringwerte haben.
VERSION.SDK	Die Version des derzeit ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 11 MUSS dieses Feld den Ganzzahlwert 11_INT haben.
VERSION.SDK_INT	Die Version des derzeit ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 11 MUSS dieses Feld den Ganzzahlwert 11_INT haben.
VERSION.INCREMENTAL	Ein vom Geräteimplementierer ausgewählter Wert, der den Build des derzeit ausgeführten Android-Systems in einem visuell 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 Änderungs-ID der Quellkontrolldatei zum Generieren des Builds verwendet wurde. Der Wert dieses Felds MUSS als druckbarer 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[^ :\/~]+$“ entsprechen.
BRETTSPIEL	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Hardware des Geräts in einem visuell lesbaren Format angibt. Dieses Feld kann beispielsweise verwendet werden, um die spezifische Version des Boards anzugeben, das das Gerät mit Strom versorgt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
MARKE	Ein Wert, der den Markennamen des Geräts widerspiegelt, der den Endnutzern bekannt ist. MÜSSEN in einem für Menschen lesbaren Format vorliegen und SOLLEN den Hersteller des Geräts oder die Marke des Unternehmens repräsentieren, unter der das Gerät vertrieben wird. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
SUPPORTED_ABIS	Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
SUPPORTED_32_BIT_ABIS	Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
SUPPORTED_64_BIT_ABIS	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
CPU_ABI	Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
CPU_ABI2	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter 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 das Industriedesign des Geräts identifiziert. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein 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. Er sollte für Menschen gut 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 codierbar sein.
Hardware	Der Name der Hardware (aus der Kernel-Befehlszeile oder /proc). Er sollte für Menschen gut lesbar sein. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
HOST	Ein String, der den Host, auf dem der Build erstellt wurde, eindeutig in einem für Menschen lesbaren Format identifiziert. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
ID	Eine vom Geräteimplementierer ausgewählte Kennung für eine bestimmte Version in einem für Menschen lesbaren Format. Dieses Feld kann mit „android.os.Build.VERSION.INCREMENTAL“ identisch sein, sollte aber einen ausreichend aussagekräftigen Wert haben, damit Endnutzer zwischen Software-Builds unterscheiden können. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen.
HERSTELLER	Der Handelsname des Erstausrüsters (Original Equipment Manufacturer, OEM) des Produkts. Es gibt keine Anforderungen an das spezifische Format dieses Felds, es darf jedoch NICHT null oder der leere 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. Dies sollte derselbe Name sein, unter dem das Gerät vermarktet und an Endnutzer verkauft wird. Es gibt keine Anforderungen an das spezifische Format dieses Felds, es darf jedoch NICHT null oder der leere 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 und innerhalb derselben Marke eindeutig sein MUSS. MÜSSEN für Menschen lesbar sein, sind aber nicht unbedingt für Endnutzer gedacht. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein 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 werden und die den Build weiter unterscheiden. Die Tags MÜSSEN als 7-Bit-ASCII codierbar sein, dem regulären Ausdruck „^[a-zA-Z0-9._-]+“ entsprechen und einen der Werte haben, die den drei gängigen Signaturkonfigurationen der Android-Plattform entsprechen: Release-Schlüssel, Entwicklerschlüssel und Testschlüssel.
UHRZEIT	Ein Wert, der den Zeitstempel des Builds angibt.
SCHREIBMASCHINE	Ein vom Geräteimplementierer ausgewählter Wert, der die Laufzeitkonfiguration des Builds angibt. Dieses Feld MUSS einen der Werte haben, die den drei gängigen 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 Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
VERSION.SECURITY_PATCH	Ein Wert, der den Stand der Sicherheits-Patches eines Builds angibt. Sie MUSS angeben, dass der Build in keiner Weise anfällig für die in dem angegebenen öffentlichen Sicherheitsbulletin für Android beschriebenen Probleme ist. Es MUSS im Format [JJJJ-MM-TT] vorliegen und mit einem definierten String übereinstimmen, der im öffentlichen Sicherheitsbulletin für Android oder in der Sicherheitswarnung für Android dokumentiert ist, z. B. „2015-11-01“.
VERSION.BASE_OS	Ein Wert, der dem FINGERPRINT-Parameter des Builds entspricht, der mit Ausnahme der im Android Public Security Bulletin bereitgestellten Patches mit diesem Build identisch ist. Es MUSS der richtige Wert angegeben werden. Wenn ein solcher Build nicht vorhanden ist, muss ein leerer String („"") angegeben werden.
BOOTLOADER	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Bootloader-Version des Geräts in einem visuell lesbaren Format angibt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen.
getRadioVersion()	MÜSSTE (sein oder zurückgeben) ein vom Geräteimplementierer ausgewählter Wert sein, der die spezifische interne Funk-/Modemversion des Geräts in einem für Menschen lesbaren Format angibt. Wenn ein Gerät kein internes Funk-/Modem hat, MUSS NULL zurückgegeben werden. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9._-,]+$“ entsprechen.
getSerial()	Es MUSS eine Hardware-Seriennummer angegeben werden, die für alle Geräte mit demselben MODELL und HERSTELLER verfügbar und eindeutig sein MUSS. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9._-,]+$“ entsprechen.

3.2.3. Intent-Kompatibilität

3.2.3.1. Gängige Anwendungsabsichten

Mit Android-Intents können Anwendungskomponenten Funktionen von anderen Android-Komponenten anfordern. Das Android-Upstream-Projekt enthält eine Liste von Anwendungen, die mehrere Intent-Muster für die Ausführung gängiger 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 hier aufgeführten Anwendungsabsichten definiert sind, und die Erfüllung zu ermöglichen, d. h. die Erwartungen der Entwickler an diese gängigen Anwendungsabsichten wie im SDK beschrieben zu erfüllen.

Informationen zu den für jeden Gerätetyp erforderlichen Anwendungsabsichten finden Sie in Abschnitt 2.

3.2.3.2. Intent-Auflösung

[C-0-1] Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen zulassen, dass jedes Intent-Muster, auf das in Abschnitt 3.2.3.1 verwiesen wird, mit Ausnahme der Einstellungen, von Drittanbieter-Apps überschrieben werden kann. Die Open-Source-Implementierung von Android ermöglicht dies standardmäßig.
[C-0-2] Geräteimplementierer DÜRFEN der Verwendung dieser Intent-Muster durch Systemanwendungen KEINE speziellen Berechtigungen zuweisen oder verhindern, dass Drittanbieteranwendungen eine Bindung an diese Muster herstellen und die Kontrolle übernehmen. Dieses Verbot umfasst insbesondere, aber nicht ausschließlich, die Deaktivierung 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 bereitstellen, ü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 die Daten-URI enthält. Ein Intent-Filtermuster, das den Daten-URI „http://www.android.com“ angibt, ist beispielsweise spezifischer als das Haupt-Intent-Muster des Browsers für „http://“.

Android bietet außerdem einen Mechanismus, mit dem Drittanbieter-Apps ein vertrauenswürdiges Standard-App-Verknüpfungsverhalten für bestimmte Arten von Web-URI-Intents angeben können. Wenn solche autorisierten Erklärungen in den Intent-Filtermustern einer App definiert sind, gilt für Geräteimplementierungen Folgendes:

[C-0-4] MUSS versuchen, alle Intent-Filter zu validieren, indem die in der Digital Asset Links-Spezifikation definierten Validierungsschritte ausgeführt werden, die vom Paketmanager im Upstream-Android Open Source Project implementiert wurden.
[C-0-5] MÜSSEN die Intent-Filter während der Installation der Anwendung validieren und alle erfolgreich validierten URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen.
KÖNNEN bestimmte URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen, wenn sie erfolgreich überprüft wurden, andere infrage kommende URI-Filter jedoch nicht. Wenn eine Geräteimplementierung dies tut, MUSS sie dem Nutzer im Einstellungsmenü entsprechende URI-Musterüberschreibungen zur Verfügung stellen.
MÜSSEN Nutzern in den Einstellungen App-Link-Einstellungen pro App zur Verfügung stellen:
- [C-0-6] Der Nutzer MUSS in der Lage sein, das Standardverhalten von App-Links für eine App ganzheitlich zu überschreiben: „Immer öffnen“, „Immer fragen“ oder „Nie öffnen“. Dies muss für alle infrage kommenden URI-Intent-Filter gleichermaßen gelten.
- [C-0-7] Der Nutzer MUSS eine Liste der Kandidaten für URI-Intent-Filter sehen können.
- Die Geräteimplementierung KANN dem Nutzer die Möglichkeit bieten, bestimmte URI-Intent-Filter, die erfolgreich bestätigt wurden, pro Intent-Filter zu überschreiben.
- [C-0-8] Die Geräteimplementierung MUSS Nutzern die Möglichkeit bieten, bestimmte Filter für URI-Intents anzusehen und zu überschreiben, wenn bei der Geräteimplementierung einige Filter für URI-Intents die Überprüfung bestehen, andere aber nicht.

3.2.3.3. Intent-Namespaces

[C-0-1] Geräteimplementierungen DÜRFEN KEINE Android-Komponenten enthalten, die neue Intent- oder Broadcast-Intent-Muster mit einer ACTION, CATEGORY oder einem anderen Schlüsselstring im Namespace „android“ oder „com.android“ berücksichtigen.
[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 KEINE der in Abschnitt 3.2.3.1 aufgeführten Intent-Muster ändern oder erweitern.
Geräteimplementierungen KÖNNEN Intent-Muster mit Namespaces enthalten, die eindeutig und offensichtlich mit der eigenen Organisation verknüpft sind. Dieses Verbot entspricht dem für Java-Sprachklassen in Abschnitt 3.6.

3.2.3.4. Broadcast-Intents

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

Geräteimplementierungen:

[C-0-1] MUSS die hier aufgeführten öffentlichen Broadcast-Intents als Reaktion auf entsprechende Systemereignisse senden, 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 ist. Bestimmte Broadcast-Intents sind außerdem an die Hardwareunterstützung gebunden. Wenn das Gerät die erforderliche Hardware unterstützt, MÜSSEN die Intents gesendet und das Verhalten gemäß der SDK-Dokumentation bereitgestellt werden.

3.2.3.5. Bedingte Anwendungsabsichten

Android bietet Einstellungen, mit denen Nutzer ihre Standard-Apps ganz einfach auswählen können, z. B. für den Startbildschirm oder SMS.

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

Wenn für Geräteimplementierungen android.software.home_screen gemeldet wird, gilt Folgendes:

[C-1-1] Es MUSS der android.settings.HOME_SETTINGS-Intentiviteit gefolgt werden, um ein Menü mit Standardeinstellungen für Apps auf dem Startbildschirm anzuzeigen.

Wenn für Geräteimplementierungen android.hardware.telephony gemeldet wird, gilt Folgendes:

[C-2-1] Es MUSS ein Einstellungsmenü geben, das die Intent android.provider.Telephony.ACTION_CHANGE_DEFAULT aufruft, um ein Dialogfeld zum Ändern der Standard-SMS-Anwendung anzuzeigen.
[C-2-2] Es MUSS die Absicht android.telecom.action.CHANGE_DEFAULT_DIALER berücksichtigen, einen Dialogfeld anzuzeigen, über den der Nutzer die Standardtelefonanwendung ä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] Die Absicht android.telecom.action.CHANGE_PHONE_ACCOUNTS MUSS berücksichtigt werden, um Nutzern die Möglichkeit zu geben, die ConnectionServices zu konfigurieren, die mit der PhoneAccounts verknüpft ist, sowie eine Standard-PhoneAccount, die der Telekommunikationsanbieter für ausgehende Anrufe verwendet. Die AOSP-Implementierung erfüllt diese Anforderung, indem im Menü „Anrufe“ die Option „Anrufkonten“ enthalten ist.
[C-2-4] android.telecom.CallRedirectionService MUSS für eine App zugelassen sein, die die Rolle android.app.role.CALL_REDIRECTION hat.
[C-2-5] MUSS dem Nutzer die Möglichkeit bieten, eine App auszuwählen, die die Rolle android.app.role.CALL_REDIRECTION hat.
[C-2-6] MUSS die Intents android.intent.action.SENDTO und android.intent.action.VIEW einhalten und eine Aktivität zum Senden/Zeigen 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 Telefonanwendung zu verarbeiten, die diese Intents verarbeiten und wie im SDK beschrieben erfüllen kann.

Wenn für Geräteimplementierungen android.hardware.nfc.hce gemeldet wird, gilt Folgendes:

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

Wenn für Geräteimplementierungen android.hardware.nfc gemeldet wird, gilt Folgendes:

[C-4-1] Es MÜSSEN die Intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED und android.nfc.action.TECH_DISCOVERED berücksichtigt werden, um eine Aktivität anzuzeigen, die die im SDK beschriebenen Entwicklererwartungen für diese Intents erfüllt.

Wenn Geräteimplementierungen die VoiceInteractionService unterstützen und mehr als eine Anwendung installiert ist, die diese API verwendet, gilt Folgendes:

[C-4-1] Es MUSS der Absicht von android.settings.ACTION_VOICE_INPUT_SETTINGS nachgekommen werden, ein Menü mit Standardeinstellungen für die Spracheingabe und den Sprachassistenten anzuzeigen.

Wenn für Geräteimplementierungen android.hardware.bluetooth gemeldet wird, gilt Folgendes:

[C-5-1] Die Intent „android.bluetooth.adapter.action.REQUEST_ENABLE“ MUSS berücksichtigt werden und es muss eine Systemaktivität angezeigt werden, damit der Nutzer Bluetooth aktivieren kann.
[C-5-2] Die Intent ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ MUSS berücksichtigt werden und es muss eine Systemaktivität angezeigt werden, die den Sichtbarkeitsmodus anfordert.

Wenn die 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 dabei um eine Aktivität handeln, bei der der Nutzer der App Zugriff auf die Konfigurationen der DND-Richtlinie gewähren oder verweigern kann.

Wenn Geräteimplementierungen es Nutzern erlauben, Eingabemethoden von Drittanbietern auf dem Gerät zu verwenden, gilt Folgendes:

[C-7-1] Es MUSS ein nutzerzugänglicher Mechanismus zum Hinzufügen und Konfigurieren von Eingabemethoden von Drittanbietern als Reaktion auf den Intent android.settings.INPUT_METHOD_SETTINGS vorhanden sein.

Wenn Geräteimplementierungen Bedienungshilfen von Drittanbietern unterstützen, gilt Folgendes:

[C-8-1] MUSS der Absicht von android.settings.ACCESSIBILITY_SETTINGS entsprechen, einen nutzerzugänglichen Mechanismus bereitzustellen, mit dem die Bedienungshilfen von Drittanbietern neben den vorinstallierten Bedienungshilfen aktiviert und deaktiviert werden können.

Wenn Geräteimplementierungen die Unterstützung von Wi‑Fi Easy Connect umfassen und die Funktion für Drittanbieter-Apps freigeben, müssen sie:

[C-9-1] Die Intent APIs Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI MÜSSEN wie in der SDK-Dokumentation beschrieben implementiert werden.

Wenn Geräteimplementierungen den Datensparmodus bieten, müssen sie: * [C-10-1] MÜSSEN in den Einstellungen eine Benutzeroberfläche bereitstellen, die die Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS-Intent verarbeitet und es Nutzern ermöglicht, der Zulassungsliste Apps hinzuzufügen oder daraus zu entfernen.

Wenn Geräteimplementierungen keinen Datensparmodus bieten, gilt Folgendes:

[C-11-1] Es MUSS eine Aktivität geben, die die Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS-Intention verarbeitet. Sie kann aber als No-Op implementiert werden.

Wenn die Geräteimplementierung die Unterstützung der Kamera über android.hardware.camera.any angibt, gilt Folgendes:

[C-12-1] Die android.media.action.STILL_IMAGE_CAMERA- und android.media.action.STILL_IMAGE_CAMERA_SECURE-Intents MÜSSEN berücksichtigt werden und die Kamera muss wie im SDK beschrieben im Standbildmodus gestartet werden.
[C-12-2] Die android.media.action.VIDEO_CAMERA-Intent muss die Kamera wie im SDK beschrieben im Videomodus starten.
[C-12-3] Es MUSS nur vorinstallierten Android-Apps erlaubt sein, die folgenden Intents zu verarbeiten: MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE und MediaStore.ACTION_VIDEO_CAPTURE, wie im SDK-Dokument beschrieben.

Wenn für Geräteimplementierungen android.software.device_admin gemeldet wird, gilt Folgendes:

[C-13-1] Es MUSS die Absicht android.app.action.ADD_DEVICE_ADMIN respektiert werden, eine Benutzeroberfläche aufzurufen, über die der Nutzer den Geräteadministrator dem System hinzufügen oder ablehnen kann.
[C-13-2] 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 MÜSSEN unterstützt werden. Außerdem muss eine Aktivität vorhanden sein, die die Ausführung dieser Intents ermöglicht, wie im SDK hier beschrieben.

Wenn in Geräteimplementierungen das Funktionsflag android.software.autofill deklariert wird, gilt Folgendes:

[C-14-1] Die APIs AutofillService und AutofillManager MÜSSEN vollständig implementiert werden und die Absicht android.settings.REQUEST_SET_AUTOFILL_SERVICE einhalten, um ein Menü mit Standard-App-Einstellungen zum Aktivieren und Deaktivieren des automatischen Ausfüllens und zum Ändern des Standard-Autofill-Dienstes für den Nutzer anzuzeigen.

Wenn bei der Geräteimplementierung eine vorinstallierte App verwendet wird oder Drittanbieter-Apps auf die Nutzungsstatistiken zugreifen sollen, müssen Sie Folgendes tun:

[C-SR] Es wird DRINGEND empfohlen, einen nutzerzugänglichen Mechanismus bereitzustellen, um den Zugriff auf die Nutzungsstatistiken als Reaktion auf die Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS für Apps zu gewähren oder zu widerrufen, die die Berechtigung android.permission.PACKAGE_USAGE_STATS angeben.

Wenn bei der Geräteimplementierung der Zugriff auf die Nutzungsstatistiken für alle Apps, einschließlich vorinstallierter Apps, verhindert werden soll, müssen folgende Anforderungen erfüllt sein:

[C-15-1] Es MUSS weiterhin eine Aktivität geben, die das Intent-Muster android.settings.ACTION_USAGE_ACCESS_SETTINGS verarbeitet, aber es MUSS als No-Op implementiert werden, d. h. es muss dasselbe Verhalten haben wie bei der Ablehnung des Zugriffs für den Nutzer.

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

[C-SR] Es wird dringend empfohlen, für die Intents „android.intent.action.TTS_SERVICE“, „android.speech.tts.engine.INSTALL_TTS_DATA“ und „android.speech.tts.engine.GET_SAMPLE_TEXT“ eine Aktivität zu haben, um diese Intents wie im SDK hier beschrieben zu erfüllen.

Android unterstützt interaktive Bildschirmschoner, die zuvor als „Dreams“ bezeichnet wurden. Mit Bildschirmschonern können Nutzer mit Anwendungen interagieren, wenn ein an eine Stromquelle angeschlossenes Gerät inaktiv ist oder an einem Dock angedockt ist. Geräteimplementierungen:

MÜSSEN Unterstützung für Bildschirmschoner bieten und eine Einstellungsoption für Nutzer bereitstellen, mit der sie Bildschirmschoner als Reaktion auf die android.settings.DREAM_SETTINGS-Intent konfigurieren können.

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

Wenn die Geräteimplementierung das Starten normaler Android-Aktivitäten auf mehreren Displays zulässt, gilt Folgendes:

[C-1-1] Das Feature-Flag android.software.activities_on_secondary_displays MUSS festgelegt werden.
[C-1-2] Die API-Kompatibilität muss der einer Aktivität auf dem Hauptdisplay entsprechen.
[C-1-3] Die neue Aktivität MUSS auf demselben Display wie die Aktivität gestartet werden, die sie gestartet hat, wenn die neue Aktivität gestartet wird, ohne über die ActivityOptions.setLaunchDisplayId() API ein Zieldisplay anzugeben.
[C-1-4] ALLE Aktivitäten MÜSSEN gelöscht werden, wenn ein Display mit dem Flag Display.FLAG_PRIVATE entfernt wird.
[C-1-5] Inhalte MÜSSEN auf allen Bildschirmen sicher ausgeblendet werden, wenn das Gerät mit einem sicheren Sperrbildschirm gesperrt ist, es sei denn, die App aktiviert die Anzeige auf dem Sperrbildschirm über die Activity#setShowWhenLocked() API.
MÜSSEN android.content.res.Configuration haben, die diesem Display entspricht, damit sie angezeigt werden, ordnungsgemäß funktionieren und die Kompatibilität bei der Ausführung einer Aktivität auf dem sekundären Display erhalten bleibt.

Wenn die 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 Eigentümer des Displays, des Systems und der Aktivitäten, die sich bereits auf dem Display befinden, MUSS es starten können. Jeder kann auf einem Display starten, das das Flag android.view.Display.FLAG_PUBLIC hat.

3.3 Kompatibilität mit nativen APIs

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

[SR] Wir empfehlen DRINGEND, die Implementierungen der unten aufgeführten Bibliotheken aus dem Upstream-Android Open Source Project zu verwenden.

3.3.1. Application Binary Interfaces

Verwalteter Dalvik-Bytecode kann auf den nativen Code zugreifen, der in der Anwendungsdatei .apk als ELF-Datei .so bereitgestellt und 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 mindestens einer der 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 mithilfe der Standard-Java Native Interface (JNI)-Semantik aufzurufen.
[C-0-3] MUSS mit jeder erforderlichen Bibliothek in der folgenden Liste Quell- (d.h. Header-) und Binärkompatibel (für das ABI) sein.
[C-0-5] Die vom Gerät unterstützte native Application Binary Interface (ABI) MUSS über die Parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS und android.os.Build.SUPPORTED_64_BIT_ABIS korrekt angegeben werden. Dabei muss es sich jeweils um eine durch Kommas getrennte Liste von ABIs handeln, die von der am häufigsten bis zur am wenigsten bevorzugten sortiert ist.
[C-0-6] Es MUSS über die oben genannten Parameter eine Teilmenge der folgenden Liste von ABIs gemeldet werden. Es DÜRFEN KEINE ABIs gemeldet werden, die nicht auf der Liste stehen.
- armeabi (wird vom NDK nicht mehr als Ziel unterstützt)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] Alle folgenden Bibliotheken, die native APIs bereitstellen, MÜSSEN für Apps mit nativem Code verfügbar sein:
- libaaudio.so (native Audiounterstützung von AAudio)
- libamidi.so (native MIDI-Unterstützung, wenn die Funktion android.software.midi wie in Abschnitt 5.9 beschrieben beansprucht wird)
- libandroid.so (Unterstützung für native 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 nativer Medien-APIs)
- libm (Mathematische Bibliothek)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (Unterstützung von OpenMAX AL 1.0.1)
- libOpenSLES.so (OpenSL ES 1.0.1-Audiounterstützung)
- libRS.so
- libstdc++ (minimale Unterstützung für C++)
- libvulkan.so (Vulkan)
- libz (Zlib-Komprimierung)
- JNI-Schnittstelle
[C-0-8] Die öffentlichen Funktionen für die oben aufgeführten nativen Bibliotheken DÜRFEN NICHT hinzugefügt oder entfernt werden.
[C-0-9] In /vendor/etc/public.libraries.txt MÜSSEN zusätzliche Bibliotheken aufgeführt werden, die nicht zu AOSP gehören und direkt für Drittanbieter-Apps freigegeben sind.
[C-0-10] Andere native Bibliotheken, die in AOSP als Systembibliotheken implementiert und bereitgestellt werden, dürfen Drittanbieter-Apps, die auf API-Level 24 oder höher ausgerichtet sind, NICHT zugänglich gemacht werden, da sie reserviert sind.
[C-0-11] Alle OpenGL ES 3.1- und Android Extension Pack-Funktionssymbole, wie im NDK definiert, MÜSSEN über die libGLESv3.so-Bibliothek exportiert werden. Alle Symbole MÜSSEN vorhanden sein. In Abschnitt 7.1.4.1 werden die Anforderungen beschrieben, wann die vollständige Implementierung der einzelnen Funktionen erwartet wird.
[C-0-12] Es MÜSSEN Funktionssymbole für die Vulkan 1.0-Kernfunktionssymbole 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 exportiert werden. Alle Symbole MÜSSEN vorhanden sein. In Abschnitt 7.1.4.2 werden die Anforderungen beschrieben, wann die vollständige Implementierung der einzelnen Funktionen erwartet wird.
MÜSSEN mit dem Quellcode und den Headerdateien erstellt werden, die im Upstream-Android-Open-Source-Projekt verfügbar sind

In zukünftigen Android-Releases werden möglicherweise weitere ABIs unterstützt.

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

Wenn die Geräteimplementierungen die Unterstützung des armeabi ABI melden, gilt Folgendes:

[C-3-1] MUSS auch armeabi-v7a unterstützen und dies angeben, da armeabi nur für die Abwärtskompatibilität mit älteren Apps gedacht ist.

Wenn die Geräteimplementierungen die Unterstützung des armeabi-v7a ABI melden, gilt für Apps, die dieses ABI verwenden, Folgendes:

[C-2-1] Die folgenden Zeilen MÜSSEN in /proc/cpuinfo enthalten sein und die Werte auf demselben Gerät DÜRFEN NICHT geändert werden, 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 Softwareemulation:
- SWP- und SWPB-Anweisungen
- SETEND-Anweisung
- Barriere-Vorgänge CP15ISB, CP15DSB und CP15DMB
[C-2-3] MUSS die Unterstützung für die Advanced SIMD-Erweiterung (auch NEON genannt) umfassen.

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] Für die Implementierung der android.webkit.WebView API MUSS der Chromium-Build aus dem Upstream-Android-Open-Source-Projekt im Android 11-Branch verwendet werden.
[C-1-3] Der von WebView gemeldete User-Agent-String MUSS dieses Format haben:

Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, wie 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) DARF leer sein. Wenn er nicht leer ist, MUSS er mit dem Wert von „android.os.Build.MODEL“ übereinstimmen.
- „Build/$(BUILD)“ kann weggelassen werden. Wenn der String jedoch vorhanden ist, MUSS er mit dem Wert für „android.os.Build.ID“ übereinstimmen.
- Der Wert des Strings $(CHROMIUM_VER) MUSS der Version von Chromium im Upstream-Android-Open-Source-Projekt entsprechen.
- 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, sofern sie die Funktion unterstützt, der HTML5-Spezifikation entsprechen.
[C-1-3] Die bereitgestellten Inhalte oder die Inhalte der Remote-URL MÜSSEN in einem Prozess gerendert werden, der sich von der Anwendung unterscheidet, die die WebView instanziiert. Insbesondere muss der separate Renderer-Prozess geringere Berechtigungen haben, als separate Nutzer-ID ausgeführt werden, keinen Zugriff auf das Datenverzeichnis der App haben, 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 sind 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, gilt Folgendes:

[C-1-1] MÜSSEN alle folgenden APIs unterstützen, die mit HTML5 verknüpft sind:
[C-1-2] MUSS die HTML5/W3C-Webstorage API unterstützen und SOLLTE die HTML5/W3C-IndexedDB API unterstützen. Da die Standardsteuergruppen für die Webentwicklung IndexedDB gegenüber Webstorage bevorzugen, wird IndexedDB voraussichtlich in einer zukünftigen Version von Android zu einer erforderlichen Komponente.
Es darf ein benutzerdefinierter User-Agent-String in der eigenständigen Browseranwendung enthalten sein.
Es sollte in der eigenständigen Browseranwendung möglichst viel HTML5 unterstützt werden, unabhängig davon, ob sie auf der Upstream-WebKit-Browseranwendung oder einem Ersatz von Drittanbietern basiert.

Wenn Geräteimplementierungen jedoch keine eigenständige Browseranwendung enthalten, gilt Folgendes:

[C-2-1] MÜSSEN weiterhin die Muster für öffentliche Absichten unterstützen, wie in Abschnitt 3.2.3.1 beschrieben.

3.5. API-Verhaltenskompatibilität

Geräteimplementierungen:

[C-0-9] Die API-Verhaltenskompatibilität MUSS für alle installierten Apps angewendet werden, es sei denn, sie sind wie in Abschnitt 3.5.1 beschrieben eingeschränkt.
[C-0-10] Es DARF KEIN Zulassungslisten-Ansatz implementiert werden, der die API-Verhaltenskompatibilität nur für Apps gewährleistet, die von Geräteimplementierern ausgewählt werden.

Das Verhalten der einzelnen API-Typen (verwaltet, soft, nativ und Web) muss mit der bevorzugten Implementierung des Upstream-Android Open Source Project übereinstimmen. Beispiele für Bereiche, in denen die Kompatibilität geprüft wird:

[C-0-1] Geräte dürfen das Verhalten oder die Semantik einer Standardabsicht NICHT ändern.
[C-0-2] Geräte dürfen den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, Content-Provider usw.) NICHT ändern.
[C-0-3] Die Semantik einer Standardberechtigung darf von Geräten NICHT geändert werden.
Geräte dürfen die Einschränkungen für Hintergrund-Apps NICHT ändern. Für Apps im Hintergrund gilt Folgendes:
- [C-0-4] Sie MÜSSEN die Ausführung von Callbacks beenden, die von der App registriert wurden, um Ausgaben von GnssMeasurement und GnssNavigationMessage zu erhalten.
- [C-0-5] Die Häufigkeit der Updates, die der App über die LocationManager API-Klasse oder die WifiManager.startScan()-Methode zur Verfügung gestellt werden, MUSS begrenzt werden.
- [C-0-6] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, dürfen im Manifest der App keine Broadcastempfänger für die impliziten Broadcasts von Standard-Android-Intents registriert werden, es sei denn, die Broadcast-Intents erfordern eine "signature"- oder "signatureOrSystem"-Berechtigung protectionLevel oder die App steht auf der Befreiungsliste.
- [C-0-7] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN die Hintergrunddienste der App beendet werden, 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 Aufgabe zu erledigen, die für den Nutzer sichtbar ist.
- [C-0-8] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN die Wakelocks freigegeben werden, die die App hält.
[C-0-9] Geräte MÜSSEN die folgenden Sicherheitsanbieter als die ersten sieben Arraywerte aus der Methode Security.getProviders() in der angegebenen Reihenfolge und mit den angegebenen Namen (wie von Provider.getName() zurückgegeben) und Klassen zurückgeben, es sei denn, die App hat die Liste über insertProviderAt() oder removeProvider() geändert. Geräte KÖNNEN nach der unten aufgeführten Liste von Anbietern zusätzliche 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 oben genannte Liste ist nicht vollständig. Die Compatibility Test Suite (CTS) testet einen Großteil der Plattform auf Verhaltenskompatibilität, aber nicht alle Bereiche. Der Implementierer ist dafür verantwortlich, die Verhaltenskompatibilität mit dem Android Open Source Project sicherzustellen. 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. Anwendungsbeschränkung

Wenn bei Geräteimplementierungen ein proprietärer Mechanismus zum Einschränken von Apps implementiert ist und dieser Mechanismus strenger ist als der Bucket „Seltene App im Ruhemodus“, gilt Folgendes:

[C-1-1] Es MUSS eine Nutzerfunktion geben, über die Nutzer die Liste der eingeschränkten Apps aufrufen können.
[C-1-2] Es MUSS eine Nutzerfunktion geben, mit der die Einschränkungen für jede App aktiviert oder deaktiviert werden können.
[C-1-3] Einschränkungen dürfen nicht automatisch angewendet werden, ohne dass ein Hinweis auf eine schlechte Systemgesundheit vorliegt. Sie können jedoch bei Erkennen einer schlechten Systemgesundheit wie beispielsweise bei steckengebliebenen Wakelocks, lang laufenden Diensten und anderen Kriterien auf Apps angewendet werden. Die Kriterien KÖNNEN von Geräteimplementierern festgelegt werden, MÜSSEN aber mit der Auswirkung der App auf den Systemzustand in Verbindung stehen. Andere Kriterien, die nicht ausschließlich mit der Systemintegrität zusammenhängen, wie die geringe 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 sie manuell deaktiviert hat. Es kann dem Nutzer aber vorgeschlagen werden, App-Einschränkungen anzuwenden.
[C-1-5] Nutzer MÜSSEN darüber informiert werden, wenn App-Einschränkungen automatisch auf eine App angewendet werden. Diese Informationen MÜSSEN innerhalb von 24 Stunden nach der Anwendung der Einschränkungen bereitgestellt werden.
[C-1-6] Muss true für ActivityManager.isBackgroundRestricted() zurückgeben, wenn die eingeschränkte App diese API aufruft.
[C-1-7] Die oberste App im Vordergrund, die vom Nutzer ausdrücklich verwendet wird, DARF NICHT eingeschränkt werden.
[C-1-8] Es MÜSSEN Einschränkungen für eine App aufgehoben werden, die die oberste App im Vordergrund wird, wenn der Nutzer die zuvor eingeschränkte App explizit verwendet.

3.6. API-Namespaces

Android folgt den Paket- und Klassen-Namespace-Konventionen, die von der Java-Programmiersprache definiert wurden. Um die Kompatibilität mit Anwendungen von Drittanbietern zu gewährleisten, dürfen Geräteimplementierer an diesen Paketnamenräumen KEINE verbotenen Änderungen vornehmen (siehe unten):

java.*
javax.*
sun.*
android.*
androidx.*
com.android.*

Das bedeutet:

[C-0-1] Die öffentlich zugänglichen APIs auf der Android-Plattform dürfen NICHT durch Ändern von Methoden- oder Klassensignaturen oder durch Entfernen von Klassen oder Klassenfeldern geändert werden.
[C-0-2] Den APIs in den oben genannten Namespaces dürfen KEINE öffentlich zugänglichen Elemente (z. B. Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) oder Test- oder System-APIs hinzugefügt werden. Ein „öffentlich zugängliches Element“ ist jedes Konstrukt, das nicht mit der Markierung „@hide“ versehen ist, wie sie im Upstream-Android-Quellcode verwendet wird.

Geräteimplementierer KÖNNEN die zugrunde liegende Implementierung der APIs ändern. Solche Änderungen:

[C-0-3] Darf sich NICHT auf das angegebene Verhalten und die Java-Signatur öffentlich zugänglicher APIs auswirken.
[C-0-4] Darf NICHT beworben oder Entwicklern anderweitig zugänglich gemacht werden.

Geräteimplementierer KÖNNEN jedoch benutzerdefinierte APIs außerhalb des Standard-Android-Namespace hinzufügen. Diese benutzerdefinierten APIs müssen folgende Anforderungen erfüllen:

[C-0-5] DARF NICHT in einem Namespace enthalten sein, der einer anderen Organisation gehört oder sich auf eine andere Organisation bezieht. Geräteimplementierer dürfen dem Namespace com.google.* oder einem ähnlichen Namespace KEINE APIs hinzufügen. Das darf nur Google tun. Ebenso darf Google KEINE APIs zu Namespaces anderer Unternehmen hinzufügen.
[C-0-6] MÜSSEN in einer freigegebenen Android-Bibliothek verpackt sein, damit nur Apps, die sie explizit verwenden (über den Mechanismus <uses-library>), von der erhöhten Speichernutzung solcher APIs betroffen sind.

Wenn ein Geräteimplementierer vorschlägt, einen der oben genannten Paketnamensräume 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 Einreichen von Änderungen und Code beginnen.

Die oben genannten Einschränkungen entsprechen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java. Dieser Abschnitt soll diese Konventionen lediglich verstärken und durch Aufnahme in diese Kompatibilitätsdefinition verbindlich machen.

3.7. Laufzeitkompatibilität

Geräteimplementierungen:

[C-0-1] MUSS das vollständige Dalvik-Ausführformat (DEX) und die Dalvik-Bytecodespezifikation und -Semantik unterstützen.
[C-0-2] Dalvik-Laufzeitumgebungen MÜSSEN so konfiguriert werden, dass sie Speicher gemäß der Upstream-Android-Plattform und wie in der folgenden Tabelle angegeben zuweisen. (Definitionen für Bildschirmgröße und Bildschirmdichte finden Sie unter Abschnitt 7.1.1.)
Es sollte Android Runtime (ART), die Referenz-Upstream-Implementierung des Dalvik-Ausführbaren-Formats und das Paketverwaltungssystem der Referenzimplementierung verwenden.
MÜSSEN Fuzz-Tests unter verschiedenen Ausführungsmodi und Zielarchitekturen ausführen, 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 Speicherwerte gelten als Mindestwerte. Geräteimplementierungen KÖNNEN mehr Arbeitsspeicher pro Anwendung zuweisen.

Bildschirmlayout	Bildschirmdichte	Mindestarbeitsspeicher der Anwendung
Android-Uhr	120 dpi (ldpi)	32 MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)	36 MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	48 MB
	360 dpi (360dpi)	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 Drittanbieter-Anwendungen, die den Geräte-Launcher (Startbildschirm) ersetzen.

Wenn bei Geräteimplementierungen Drittanbieter-Apps den Startbildschirm des Geräts ersetzen können, gilt Folgendes:

[C-1-1] Die Plattformfunktion android.software.home_screen MUSS deklariert werden.
[C-1-2] MUSS das AdaptiveIconDrawable-Objekt zurückgeben, wenn die Drittanbieteranwendung das <adaptive-icon>-Tag zum Angeben ihres Symbols verwendet und die Methoden PackageManager 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] true für ShortcutManager.isRequestPinShortcutSupported() MÜSSEN gemeldet werden.
[C-2-2] Es MUSS eine Nutzerinteraktion geben, bevor ein über die ShortcutManager.requestPinShortcut() API-Methode von Apps angeforderter Verknüpfung hinzugefügt wird.
[C-2-3] MUSS angepinnte Verknüpfungen sowie dynamische und statische Verknüpfungen unterstützen, wie auf der Seite zu App-Verknüpfungen beschrieben.

Wenn die Geräteimplementierungen das Anpinnen von Verknüpfungen in Apps nicht unterstützen, gilt Folgendes:

[C-3-1] Es MUSS false für ShortcutManager.isRequestPinShortcutSupported() gemeldet werden.

Wenn bei Geräteimplementierungen ein Standard-Launcher implementiert ist, der über die ShortcutManager API schnellen Zugriff auf die zusätzlichen Verknüpfungen von Drittanbieter-Apps bietet, gilt Folgendes:

[C-4-1] MÜSSEN alle dokumentierten Tastenkürzelfunktionen (z.B. statische und dynamische Tastenkürzel, angepinnte Tastenkürzel) unterstützen und die APIs der ShortcutManager API-Klasse vollständig implementieren.

Wenn die Geräteimplementierungen eine Standard-Launcher-App enthalten, die Logos für die App-Symbole anzeigt, gelten folgende Anforderungen:

[C-5-1] MUSS die API-Methode NotificationChannel.setShowBadge() einhalten. Mit anderen Worten: Zeigen Sie ein visuelles Symbol für das App-Symbol an, wenn der Wert auf true festgelegt ist, und kein App-Symbol-Badge-Schema, wenn der Wert für alle Benachrichtigungskanäle der App auf false festgelegt ist.
Sie KÖNNEN die App-Symbol-Kennzeichen mit ihrem eigenen Kennzeichensystem überschreiben, wenn Anwendungen von Drittanbietern die Unterstützung des eigenen Kennzeichensystems durch die Verwendung proprietärer APIs angeben. Sie SOLLTEN jedoch die Ressourcen und Werte verwenden, die über die im SDK beschriebenen APIs für Benachrichtigungskennzeichen 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 Lebenszyklus definiert werden, mit denen Anwendungen Endnutzern ein App-Widget zur Verfügung stellen können.

Wenn Geräteimplementierungen Widgets von Drittanbieter-Apps unterstützen, gilt Folgendes:

[C-1-1] MÜSSEN die Unterstützung für die Plattformfunktion android.software.app_widgets angeben.
[C-1-2] MUSS eine integrierte Unterstützung für App-Widgets bieten und Nutzeroberflächenelemente zum Hinzufügen, Konfigurieren, Ansehen und Entfernen von App-Widgets direkt im Launcher enthalten.
[C-1-3] MUSS Widgets in der Standardrastergröße von 4 × 4 rendern können. Weitere Informationen finden Sie in der Android SDK-Dokumentation unter Designrichtlinien für App-Widgets.
Es KANN Anwendungs-Widgets auf dem Sperrbildschirm unterstützen.

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

[C-2-1] true für AppWidgetManager.html.isRequestPinAppWidgetSupported() MÜSSEN gemeldet werden.
[C-2-2] Es MUSS eine Nutzerinteraktion geben, bevor ein über die AppWidgetManager.requestPinAppWidget() API-Methode von Apps angeforderter Verknüpfung hinzugefügt wird.

3.8.3. Benachrichtigungen

Android bietet die APIs Notification und NotificationManager, mit denen App-Entwickler von Drittanbietern Nutzer über wichtige Ereignisse informieren und ihre Aufmerksamkeit mithilfe der Hardwarekomponenten (z.B. Ton, Vibration und Licht) und Softwarefunktionen (z.B. Benachrichtigungsleiste, Systemleiste) des Geräts auf sich ziehen können.

3.8.3.1. Darstellung von Benachrichtigungen

Wenn Geräteimplementierungen es Drittanbieter-Apps erlauben, Nutzer über wichtige Ereignisse zu benachrichtigen, gilt Folgendes:

[C-1-1] MÜSSEN Benachrichtigungen unterstützen, die Hardwarefunktionen verwenden, wie in der SDK-Dokumentation beschrieben, und nach Möglichkeit mit der Hardware der Geräteimplementierung. Wenn eine Geräteimplementierung beispielsweise einen Vibrator enthält, MÜSSEN die Vibrations-APIs korrekt implementiert sein. Wenn bei einer Geräteimplementierung die entsprechende Hardware fehlt, MÜSSEN die entsprechenden APIs als No-Ops implementiert werden. Dieses Verhalten wird in Abschnitt 7 näher erläutert.
[C-1-2] Alle Ressourcen (Symbole, Animationsdateien usw.), die in den APIs oder im Symbolstilhandbuch für die Status-/Systemleiste bereitgestellt werden, MÜSSEN korrekt gerendert werden. Die Benachrichtigungen können jedoch eine andere Nutzererfahrung bieten als die der Referenzimplementierung der Android Open Source-Plattform.
[C-1-3] Sie MÜSSEN die für die APIs beschriebenen Verhaltensweisen zum Aktualisieren, Entfernen und Gruppieren von Benachrichtigungen einhalten und ordnungsgemäß implementieren.
[C-1-4] MUSS das vollständige Verhalten der im SDK dokumentierten NotificationChannel API angeben.
[C-1-5] Es MUSS eine Nutzerfunktion geben, mit der Benachrichtigungen einer bestimmten Drittanbieter-App auf Ebene jedes Kanals und App-Pakets blockiert und geändert werden können.
[C-1-6] MUSS Nutzern auch die Möglichkeit bieten, gelöschte Benachrichtigungskanäle anzuzeigen.
[C-1-7] Alle über Notification.MessagingStyle bereitgestellten Ressourcen (Bilder, Sticker, Symbole usw.) MÜSSEN zusammen mit dem Benachrichtigungstext korrekt gerendert werden, ohne dass der Nutzer etwas tun muss. Beispielsweise MÜSSEN alle Ressourcen einschließlich Symbole, die über android.app.Person bereitgestellt werden, in einer Gruppenunterhaltung angezeigt werden, die über setGroupConversation festgelegt wird.
[C-SR] Es wird DRINGEND empfohlen, Nutzern auf jeder Kanal- und App-Paketebene automatisch die Möglichkeit zu geben, die Benachrichtigungen einer bestimmten Drittanbieter-App zu blockieren, nachdem der Nutzer diese Benachrichtigung mehrmals geschlossen hat.
MÜSSEN umfassende Benachrichtigungen unterstützen.
MÜSSEN einige Benachrichtigungen mit höherer Priorität als Vorabbenachrichtigungen angezeigt werden.
Es sollte eine Nutzerfunktion geben, mit der Benachrichtigungen pausiert werden können.
Sie dürfen nur die Sichtbarkeit und das Timing verwalten, zu dem Drittanbieter-Apps Nutzer über wichtige Ereignisse benachrichtigen können, um Sicherheitsrisiken wie Ablenkungen des Fahrers zu minimieren.

Android 11 unterstützt Benachrichtigungen zu Unterhaltungen. Dabei handelt es sich um Benachrichtigungen, die MessagingStyle verwenden und eine veröffentlichte Personen-Verknüpfungs-ID enthalten.

Geräteimplementierungen:

[C-SR] Es wird EMPFOHLEN, conversation notifications vor Benachrichtigungen zu gruppieren und anzuzeigen, die nicht zu einer Unterhaltung gehören, mit Ausnahme von Benachrichtigungen zu laufenden Diensten im Vordergrund und importance:high-Benachrichtigungen.

Wenn die 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 Sprechblase anzuzeigen. Die AOSP-Implementierung erfüllt diese Anforderungen mit der Standard-Benutzeroberfläche, den Standardeinstellungen und dem Standard-Launcher.

Wenn Geräteimplementierungen erweiterte Benachrichtigungen unterstützen, gilt Folgendes:

[C-2-1] Für die dargestellten Ressourcenelemente MÜSSEN genau die Ressourcen verwendet werden, die über die Notification.Style API-Klasse und ihre Unterklassen bereitgestellt werden.
MÜSSEN alle Ressourcenelemente (z.B. Symbol, Titel und Zusammenfassungstext) enthalten, die in der Notification.Style API-Klasse und ihren Unterklassen definiert sind.

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

[C-3-1] Bei der Darstellung von Pop-up-Benachrichtigungen MÜSSEN die Ansicht und die Ressourcen für Pop-up-Benachrichtigungen wie in der Notification.Builder API-Klasse beschrieben verwendet werden.
[C-3-2] Die über Notification.Builder.addAction() bereitgestellten Aktionen MÜSSEN zusammen mit dem Inhalt der Benachrichtigung ohne zusätzliche Nutzerinteraktion angezeigt werden, wie im SDK beschrieben.

3.8.3.2. Notification Listener Service

Android enthält die NotificationListenerService APIs, mit denen Apps (nachdem sie vom Nutzer explizit aktiviert wurden) eine Kopie aller Benachrichtigungen erhalten, sobald sie gepostet oder aktualisiert werden.

Geräteimplementierungen:

[C-0-1] Benachrichtigungen müssen korrekt und zeitnah in ihrer Gesamtheit an alle installierten und vom Nutzer aktivierten Listener-Dienste gesendet werden, einschließlich aller Metadaten, die dem Benachrichtigungsobjekt zugeordnet sind.
[C-0-2] MUSS den snoozeNotification()-API-Aufruf einhalten und die Benachrichtigung schließen und einen Callback ausführen, nachdem die im API-Aufruf festgelegte Schlummerdauer abgelaufen ist.

Wenn Geräteimplementierungen eine Nutzerfunktion zum Pausieren von Benachrichtigungen haben, gilt Folgendes:

[C-1-1] Der Status der Schlummerfunktion für Benachrichtigungen muss über die Standard-APIs wie NotificationListenerService.getSnoozedNotifications() korrekt widergespiegelt werden.
[C-1-2] Es MUSS eine Nutzerfunktion geben, mit der Benachrichtigungen von jeder installierten Drittanbieter-App pausiert werden können, es sei denn, sie stammen von Diensten im Hintergrund oder im Vordergrund.

3.8.3.3. „Bitte nicht stören“

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

[C-1-1] MUST: Wenn die Geräteimplementierung dem Nutzer die Möglichkeit bietet, Drittanbieter-Apps Zugriff auf die DND-Richtlinienkonfiguration zu gewähren oder zu verweigern, müssen neben den vom Nutzer erstellten und vordefinierten Regeln auch automatische DND-Regeln angezeigt werden, die von Apps erstellt wurden.
[C-1-3] MÜSSEN die Werte suppressedVisualEffects berücksichtigen, die über NotificationManager.Policy übergeben werden. Wenn eine App eines der Flags SUPPRESSED_EFFECT_SCREEN_OFF oder SUPPRESSED_EFFECT_SCREEN_ON festgelegt hat, SOLLTE dem Nutzer im Menü der Einstellungen für die Funktion „Bitte nicht stören“ angezeigt werden, dass die visuellen Effekte unterdrückt werden.

3.8.4. Suchen

Android bietet APIs, mit denen Entwickler die Suche in ihre Anwendungen einbinden und die Daten ihrer Anwendung in die globale Systemsuche einbinden können. Im Allgemeinen besteht diese Funktion aus einer einzigen systemweiten Benutzeroberfläche, über die Nutzer Suchanfragen eingeben können, während Vorschläge angezeigt werden und Ergebnisse angezeigt werden. Mit den Android APIs können Entwickler diese Benutzeroberfläche wiederverwenden, um die Suche in ihren eigenen Apps bereitzustellen, und Ergebnisse für die gemeinsame Benutzeroberfläche der globalen Suche bereitstellen.

Android-Geräteimplementierungen MÜSSEN eine globale Suche enthalten, eine einzelne, gemeinsame systemweite Suchoberfläche, die Echtzeitvorschläge als Reaktion auf Nutzereingaben liefern kann.

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

[C-1-1] MÜSSEN die APIs implementieren, die es Drittanbieter-Anwendungen ermöglichen, dem Suchfeld Vorschläge hinzuzufügen, wenn es im Modus für die globale Suche 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 enthält außerdem 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 die Geräteimplementierungen die Aktion „Hilfe“ unterstützen, gilt Folgendes:

[C-2-1] Dem Endnutzer muss klar und deutlich angezeigt werden, wann der Kontext weitergegeben wird. Dies kann auf folgende Weise geschehen:
- Jedes Mal, wenn die Assistent-App auf den Kontext zugreift, wird ein weißes Licht um die Ränder des Displays herum angezeigt, das die Dauer und Helligkeit der Android Open Source Project-Implementierung erfüllt oder übertrifft.
- Für die vorinstallierte Assistenz-App muss der Nutzer weniger als zwei Navigationsschritte vom Standardmenü für die Spracheingabe und die Einstellungen der Assistenz-App entfernt sein. Außerdem darf der Kontext nur geteilt werden, wenn die Assistenz-App vom Nutzer explizit über ein Hotword oder eine Navigationstaste für die Assistenz aufgerufen wird.
[C-2-2] Die in Abschnitt 7.2.3 beschriebene Interaktion zum Starten der Assistenz-App MUSS die vom Nutzer ausgewählte Assistenz-App starten, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die den ACTION_ASSIST-Intent verarbeitet.

3.8.5. Benachrichtigungen und Toasts

Mit der Toast API können Anwendungen Endnutzern kurze nicht modale Strings anzeigen, die nach kurzer Zeit verschwinden. Mit der Window Type API TYPE_APPLICATION_OVERLAY können Benachrichtigungsfenster als Overlay über anderen Apps angezeigt werden.

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

[C-1-1] Es MUSS eine Nutzerfunktion geben, mit der verhindert werden kann, dass eine App Benachrichtigungsfenster mit dem TYPE_APPLICATION_OVERLAY anzeigt . Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente im Benachrichtigungs-Schieberegler.
[C-1-2] MÜSSEN die Toast API einhalten und Toasts von Anwendungen für Endnutzer gut sichtbar anzeigen.

3.8.6. Designs

Android bietet „Designs“ als Mechanismus für Anwendungen, um Stile auf eine gesamte Aktivität oder Anwendung anzuwenden.

Android umfasst die Themenfamilien „Holo“ und „Material“ als Reihe von definierten Stilen, die App-Entwickler verwenden können, wenn sie das Holo-Design des Android SDK nachahmen möchten.

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

[C-1-1] KEINE der Holo-Designattribute dürfen geändert werden, die für Anwendungen freigegeben sind.
[C-1-2] Die Designfamilie „Material“ MUSS unterstützt werden und es dürfen keine der Material Design-Attribute oder deren Assets geändert werden, die für Anwendungen freigegeben sind.
[C-1-3] Die Schriftfamilie „sans-serif“ MUSS für die von Roboto unterstützten Sprachen entweder auf Roboto Version 2.x festgelegt sein oder es muss eine Nutzerinteraktion geben, mit der die für die Schriftfamilie „sans-serif“ verwendete Schriftart in Roboto Version 2.x geändert werden kann.

Android enthält auch die Designfamilie „Gerätestandard“ mit einer Reihe von definierten Stilen, die App-Entwickler verwenden können, wenn sie das Erscheinungsbild des vom Geräteimplementierer definierten Gerätedesigns anpassen möchten.

Geräteimplementierungen KÖNNEN die Standarddesignattribute des Geräts ändern, die für Anwendungen freigegeben sind.

Android unterstützt ein Variante-Design mit durchsichtigen Systemleisten, mit dem App-Entwickler den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten füllen können. Damit Entwickler in dieser Konfiguration einheitlich arbeiten können, ist es wichtig, dass der Stil der Statusleiste für verschiedene 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 vom System ausgegebene Benachrichtigungen 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äten MUSS die Farbe der Systemstatussymbole zu Schwarz geändert werden, wenn eine App eine helle Statusleiste anfordert (weitere Informationen finden Sie unter R.style).

3.8.7. Live-Hintergründe

Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, mit denen Anwendungen Nutzern einen oder mehrere Live-Hintergründe zur Verfügung stellen können. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabemöglichkeiten, die als Hintergrund hinter anderen Apps angezeigt werden.

Hardware gilt als zuverlässig für die Ausführung von Live-Hintergründen, wenn sie alle Live-Hintergründe ohne Funktionseinschränkungen mit einer angemessenen Framerate und ohne negative Auswirkungen auf andere Anwendungen ausführen kann. Wenn aufgrund von Hardwareeinschränkungen Hintergründe und/oder Anwendungen abstürzen, nicht richtig funktionieren, zu viel CPU- oder Akkuleistung verbrauchen oder mit unzumutbar niedrigen Frameraten laufen, ist die Hardware nicht in der Lage, Live-Hintergründe auszuführen. Einige Live-Hintergründe verwenden beispielsweise einen OpenGL 2.0- oder 3.x-Kontext, um ihre Inhalte zu rendern. Live-Hintergründe funktionieren auf Hardware, die keine mehreren OpenGL-Kontexte unterstützt, nicht zuverlässig, da die Verwendung eines OpenGL-Kontexts für den Live-Hintergrund mit anderen Anwendungen in Konflikt stehen kann, die ebenfalls einen OpenGL-Kontext verwenden.

Geräteimplementierungen, die wie oben beschrieben zuverlässig Live-Hintergründe ausführen können, MÜSSEN Live-Hintergründe implementieren.

Wenn bei Geräteimplementierungen Live-Hintergründe implementiert werden, gilt Folgendes:

[C-1-1] MUSS 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 zum Wechseln von Aufgaben und zum Anzeigen kürzlich aufgerufener Aktivitäten und Aufgaben mit einem Thumbnail-Bild des grafischen Zustands der Anwendung, als der Nutzer die Anwendung zuletzt verlassen hat.

Geräteimplementierungen, die die Navigationstaste für die letzten Elemente enthalten, wie in Abschnitt 7.2.3 beschrieben, KÖNNEN die Benutzeroberfläche verändern.

Wenn Geräteimplementierungen, die die Navigationstaste für die letzten Funktionen enthalten, wie in Abschnitt 7.2.3 beschrieben, die Benutzeroberfläche ändern, müssen sie:

[C-1-1] Es müssen mindestens sieben angezeigte Aktivitäten unterstützt werden.
Es sollte mindestens der Titel von vier Aktivitäten gleichzeitig angezeigt werden.
[C-1-2] MÜSSEN das Verhalten der Bildschirmsperre implementieren und dem Nutzer ein Einstellungsmenü zur Verfügung stellen, mit dem er die Funktion aktivieren oder deaktivieren kann.
MÜSSEN die Markierungsfarbe, das Symbol und den Bildschirmtitel in den letzten Elementen anzeigen.
Es sollte eine Schließfunktion („x“) geben, die aber verzögert werden kann, bis der Nutzer mit den Bildschirmen interagiert.
Es sollte einen Hotkey geben, mit dem man einfach zur vorherigen Aktivität zurückkehren kann.
Es sollte die Schnellwechselaktion zwischen den beiden zuletzt verwendeten Apps auslösen, wenn zweimal auf die Funktionstaste für die zuletzt verwendeten Apps getippt wird.
Sollte den Splitscreen-Multifenstermodus auslösen, sofern unterstützt, wenn die Taste für die letzten Apps lange gedrückt wird.
Es kann sein, dass ähnliche aktuelle Inhalte als Gruppe angezeigt werden, die sich gemeinsam bewegt.
[SR] Es wird DRINGEND empfohlen, die Android-Benutzeroberfläche (oder eine ähnliche, auf Miniaturansichten basierende Benutzeroberfläche) für den Übersichtsbildschirm zu verwenden.

3.8.9. Eingabeverwaltung

Android unterstützt die Eingabeverwaltung und Editoren für Eingabemethoden von Drittanbietern.

Wenn Geräteimplementierungen es Nutzern erlauben, Eingabemethoden von Drittanbietern auf dem Gerät zu verwenden, gilt Folgendes:

[C-1-1] Die Plattformfunktion „android.software.input_methods“ MUSS deklariert werden und IME APIs müssen gemäß der Definition in der Android SDK-Dokumentation unterstützt werden.

3.8.10. Mediensteuerung auf dem Sperrbildschirm

Die Remote Control Client API wird ab Android 5.0 zugunsten der Media Notification Template eingestellt. Mit dieser Vorlage können Medienanwendungen in Wiedergabesteuerungen eingebunden werden, die auf dem Sperrbildschirm angezeigt werden.

3.8.11. Bildschirmschoner (früher „Träume“)

Informationen zu den Einstellungen für Bildschirmschoner finden Sie unter Abschnitt 3.2.3.5.

3.8.12. Standort

Wenn Geräteimplementierungen einen Hardwaresensor (z.B. GPS) enthalten, der die Standortkoordinaten bereitstellen kann,

[C-1-2] Im Menü „Standort“ in den Einstellungen MUSS der aktuelle Status der Standortermittlung angezeigt werden.
[C-1-3] Im Menü „Standort“ in den Einstellungen DÜRFEN KEINE Standortmodi angezeigt werden.

3.8.13. Unicode und Schriftart

Android unterstützt die Emoji-Zeichen, die in Unicode 10.0 definiert sind.

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

[C-1-1] MUSS diese Emoji-Zeichen als farbiges Glyph rendern können.
[C-1-2] MUSS Folgendes unterstützen:
- Roboto 2-Schriftart mit verschiedenen Stärken: „sans-serif-thin“, „sans-serif-light“, „sans-serif-medium“, „sans-serif-black“, „sans-serif-condensed“ und „sans-serif-condensed-light“ für die auf dem Gerät verfügbaren Sprachen.
- Vollständige Abdeckung von lateinischen, griechischen und kyrillischen Schriftzeichen gemäß Unicode 7.0, einschließlich der Bereiche „Latin Extended A“, „Latin Extended B“, „Latin Extended C“ und „Latin Extended D“ sowie aller Schriftzeichen im Block „Währungssymbole“ von Unicode 7.0.
MÜSSEN die Emojis für Hauttöne und verschiedene Familien unterstützen, wie im Unicode Technical Report #51 angegeben.

Wenn Geräteimplementierungen eine IME enthalten, gilt Folgendes:

Es MUSS eine Eingabemethode für diese Emoji-Zeichen geben.

Android unterstützt das Rendern von Myanmar-Schriftarten. In Myanmar gibt es mehrere nicht Unicode-kompatible Schriftarten, die allgemein als „Zawgyi“ bezeichnet werden und für die Darstellung der myanmarischen Sprache verwendet werden.

Wenn die Geräteimplementierung die Unterstützung von Birmanisch umfasst, 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] MÜSSEN solche Mehrfenstermodi gemäß den Anwendungsverhalten und APIs implementieren, die in der Dokumentation zur Unterstützung des Mehrfenstermodus des Android SDK beschrieben sind, und die folgenden Anforderungen erfüllen:
[C-1-2] MUSS android:resizeableActivity berücksichtigen, das von einer App in der Datei AndroidManifest.xml festgelegt wird, wie in diesem SDK beschrieben.
[C-1-3] Der Splitscreen- oder Freiformmodus darf NICHT angeboten werden, wenn die Bildschirmhöhe weniger als 440 dp und die Bildschirmbreite weniger als 440 dp beträgt.
[C-1-4] Die Größe einer Aktivität darf in anderen Multifenstermodi als Bild-im-Bild NICHT auf unter 220 dp (Pixel) verkleinert werden.
Geräteimplementierungen mit einer Bildschirmgröße von xlarge MÜSSEN den Freeform-Modus unterstützen.

Wenn die Geräteimplementierungen den Mehrfenstermodus und den Splitscreen-Modus unterstützen, gilt Folgendes:

[C-2-1] Es MUSS ein veränderbares Launcher-Symbol als Standardsymbol vorgeladen werden.
[C-2-2] Die angedockte Aktivität eines Splitscreen-Multifensters MUSS zugeschnitten werden, aber einige Inhalte DARF es zeigen, wenn die Launcher-App das fokussierte Fenster ist.
[C-2-3] MÜSSEN die angegebenen Werte AndroidManifestLayout_minWidth und AndroidManifestLayout_minHeight der Launcher-Anwendung des Drittanbieters einhalten und diese Werte nicht überschreiben, wenn Inhalte der angedockten Aktivität angezeigt werden.

Wenn Geräteimplementierungen den Mehrfenstermodus und den Bild-im-Bild-Mehrfenstermodus unterstützen, gilt Folgendes:

[C-3-1] Aktivitäten MÜSSEN im Bild-im-Bild-Multifenstermodus gestartet werden, wenn die App: * auf API-Level 26 oder höher ausgerichtet ist und android:supportsPictureInPicture deklariert * auf API-Level 25 oder niedriger ausgerichtet ist und sowohl android:resizeableActivity als auch android:supportsPictureInPicture deklariert.
[C-3-2] MÜSSEN die Aktionen in ihrer SystemUI gemäß der aktuellen PIP-Aktivität über die setActions() API bereitstellen.
[C-3-3] MUSS Seitenverhältnisse unterstützen, die mindestens 1:2,39 und maximal 2,39:1 sind, wie in der PIP-Aktivität über die setAspectRatio() API angegeben.
[C-3-4] Zum Steuern des PIP-Fensters MUSS KeyEvent.KEYCODE_WINDOW verwendet werden. Wenn der PIP-Modus nicht implementiert ist, MUSS die Taste für die Aktivität im Vordergrund verfügbar sein.
[C-3-5] Es MUSS eine Nutzerfunktion geben, mit der eine App daran gehindert werden kann, im PIP-Modus angezeigt zu werden. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente im Benachrichtigungs-Schieberegler.
[C-3-6] Für das PIP-Fenster MÜSSEN die folgende Mindestbreite und Mindesthöhe zugewiesen werden, wenn eine Anwendung keinen Wert für AndroidManifestLayout_minWidth und AndroidManifestLayout_minHeight angibt:
- Geräten mit einem anderen Wert für „Configuration.uiMode“ als UI_MODE_TYPE_TELEVISION MÜSSEN eine Mindestbreite und -höhe von 108 dp zugewiesen werden.
- Geräte mit dem Wert UI_MODE_TYPE_TELEVISION für „Configuration.uiMode“ MÜSSEN eine Mindestbreite von 240 dp und eine Mindesthöhe von 135 dp haben.

3.8.15. Display-Aussparung

Android unterstützt einen Displayausschnitt wie im SDK-Dokument beschrieben. Die DisplayCutout API definiert einen Bereich am Displayrand, der aufgrund eines Displayausschnitts oder eines gebogenen Displays an den Rändern möglicherweise nicht für eine App funktioniert.

Wenn Geräteimplementierungen Displayausschnitte enthalten, gelten folgende Anforderungen:

[C-1-5] Es dürfen KEINE Ausschnitte vorhanden sein, wenn das Seitenverhältnis des Geräts 1,0 (1:1) beträgt.
[C-1-2] Es darf nicht mehr als einen Ausschnitt pro Kante geben.
[C-1-3] Die von der App über die WindowManager.LayoutParams API festgelegten Flags für den Displayausschnitt MÜSSEN wie im SDK beschrieben berücksichtigt werden.
[C-1-4] MÜSSEN korrekte Werte für alle in der DisplayCutout API definierten Messwerte für Ausschnitte melden.

3.8.16. Gerätesteuerung

Android enthält die APIs ControlsProviderService und Control, mit denen Drittanbieter-Apps Gerätesteuerelemente für einen schnellen Status und eine schnelle Aktion für Nutzer veröffentlichen können.

Gerätespezifische Anforderungen finden Sie unter 2_2_3.

3.9. Geräteverwaltung

Android bietet Funktionen, mit denen sicherheitsbewusste Anwendungen über die Android Device Administration API Geräteverwaltungsfunktionen auf Systemebene ausführen können, z. B. die Erzwingung von Passwortrichtlinien oder das Löschen von Daten aus der Ferne.

Wenn bei der Geräteimplementierung die gesamte Palette der in der Android SDK-Dokumentation definierten Richtlinien für die Geräteverwaltung implementiert wird, gilt Folgendes:

[C-1-1] android.software.device_admin MUSS deklariert werden.
[C-1-2] MUSS die Bereitstellung für Geräteeigentümer gemäß Abschnitt 3.9.1 und Abschnitt 3.9.1.1 unterstützen.

3.9.1 Gerätebereitstellung

3.9.1.1 Geräteeigentümer-Bereitstellung

Wenn Geräteimplementierungen android.software.device_admin angeben, gilt Folgendes:

[C-1-1] MUSS die Registrierung eines Device Policy Clients (DPC) als App des Geräteeigentümers unterstützen, wie unten beschrieben:
- Wenn die Geräteimplementierung noch keine Nutzerdaten enthält, geschieht Folgendes:
  - [C-1-3] Es MUSS true für DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) gemeldet werden.
  - [C-1-4] Die DPC-Anwendung MUSS als App des Geräteeigentümers in Reaktion auf die Intent-Aktion android.app.action.PROVISION_MANAGED_DEVICE registriert werden.
  - [C-1-5] Die DPC-Anwendung MUSS als App des Geräteeigentümers registriert werden, wenn das Gerät die Nahfeldkommunikation (Near Field Communication, NFC) über das Feature-Flag android.hardware.nfc angibt und eine NFC-Nachricht mit einem Eintrag vom MIME-Typ MIME_TYPE_PROVISIONING_NFC empfängt.
- Wenn die Geräteimplementierung Nutzerdaten enthält, gilt Folgendes:
  - [C-1-6] Es MUSS false für die DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) gemeldet werden.
  - [C-1-7] Es darf KEINE DPC-Anwendung mehr als App des Geräteinhabers registriert werden.
[C-1-2] Es MUSS vor oder während des Bereitstellungsvorgangs eine aktive Aktion des Nutzers erforderlich sein, um der Einrichtung der App als Geräteeigentümer zuzustimmen. Die Einwilligung kann über eine Nutzeraktion oder auf programmatische Weise erfolgen. Vor Beginn der Bereitstellung für Geräteeigentümer muss jedoch eine entsprechende Offenlegungsmitteilung (wie im AOSP erwähnt) angezeigt werden. Außerdem darf der programmatische Einwilligungsmechanismus für Geräteeigentümer, der von Unternehmen für die Bereitstellung von Geräteeigentümern verwendet wird, die Out-of-the-Box-Nutzung für die nicht geschäftliche Nutzung nicht beeinträchtigen.
[C-1-3] Die Einwilligung darf NICHT hartcodiert sein und die Nutzung anderer Apps des Geräteeigentümers darf nicht verhindert werden.

Wenn Geräteimplementierungen android.software.device_admin angeben, aber auch eine proprietäre Lösung zur Verwaltung des Geräteeigentümers enthalten und einen Mechanismus bereitstellen, um eine in ihrer Lösung konfigurierte App als „Geräteeigentümer-Äquivalent“ für den Standard-Geräteeigentümer zu kennzeichnen, der von den standardmäßigen Android-DevicePolicyManager APIs erkannt wird, gilt Folgendes:

[C-2-1] Es MUSS ein Verfahren geben, mit dem überprüft wird, ob die beworbene App zu einer legitimen Lösung zur Geräteverwaltung für Unternehmen gehört und bereits in der proprietären Lösung so konfiguriert wurde, dass sie die Rechte eines „Geräteeigentümers“ hat.
[C-2-2] Es MUSS dieselbe AOSP-Offenlegung zur Einwilligung des Geräteeigentümers wie beim von android.app.action.PROVISION_MANAGED_DEVICE initiierten Ablauf angezeigt werden, bevor die DPC-Anwendung als „Geräteeigentümer“ registriert wird.
Es KÖNNEN Nutzerdaten auf dem Gerät vorhanden sein, bevor die DPC-Anwendung als „Geräteeigentümer“ registriert wird.

3.9.1.2 Bereitstellung verwalteter Profile

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

[C-1-1] MÜSSEN die APIs implementieren, die es einer Device Policy Controller-Anwendung (DPC) ermöglichen, Inhaber eines neuen verwalteten Profils zu werden.
[C-1-2] Der Bereitstellungsprozess für verwaltete Profile (der Ablauf, der durch android.app.action.PROVISION_MANAGED_PROFILE initiiert wird) muss der AOSP-Implementierung entsprechen.
[C-1-3] MÜSSEN in den Einstellungen die folgenden Nutzerfunktionen zur Verfügung stellen, um dem Nutzer anzuzeigen, wenn eine bestimmte Systemfunktion vom Device Policy Controller (DPC) deaktiviert wurde:
- Ein einheitliches Symbol oder eine andere Nutzerfunktion (z. B. das Infosymbol von AOSP) für den Fall, dass eine bestimmte Einstellung durch einen Geräteadministrator eingeschränkt ist.
- Eine kurze Erklärung, die der Geräteadministrator über die setShortSupportMessage angegeben hat.
- Das Symbol der DPC-Anwendung.

3.9.2 Unterstützung für verwaltete Profile

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

[C-1-1] Es MÜSSEN verwaltete Profile über die android.app.admin.DevicePolicyManager APIs unterstützt werden.
[C-1-2] Es darf nur ein einziges verwaltetes Profil erstellt werden.
[C-1-3] Es muss ein Symbolsymbol (ähnlich dem AOSP-Upstream-Arbeitssymbol) verwendet werden, um die verwalteten Anwendungen und Widgets sowie andere UI-Elemente mit Symbolen wie „Letzte“ und „Benachrichtigungen“ darzustellen.
[C-1-4] Es MUSS ein Benachrichtigungssymbol (ähnlich dem AOSP-Arbeitssymbol) angezeigt werden, um anzuzeigen, dass sich der Nutzer in einer Anwendung mit verwaltetem Profil befindet.
[C-1-5] Es MUSS ein Toast angezeigt werden, das darauf hinweist, dass sich der Nutzer im verwalteten Profil befindet, wenn das Gerät aktiviert wird (ACTION_USER_PRESENT) und die App im Vordergrund sich im verwalteten Profil befindet.
[C-1-6] Wenn ein verwaltetes Profil vorhanden ist, MUSS in der Intent-Auswahl eine visuelle Aufforderung angezeigt werden, damit der Nutzer den Intent vom verwalteten Profil an den Hauptnutzer oder umgekehrt weiterleiten kann, sofern dies vom Device Policy Controller aktiviert ist.
[C-1-7] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN die folgenden Nutzerfunktionen sowohl für den Hauptnutzer als auch für das verwaltete Profil verfügbar sein:
- Separate Erfassung der Akku-, Standort-, mobilen Daten- und Speichernutzung für den Hauptnutzer und das verwaltete Profil.
- Unabhängige Verwaltung von VPN-Anwendungen, die im primären Nutzer- oder verwalteten Profil installiert sind.
- Unabhängige Verwaltung von Anwendungen, die im primären Nutzer oder im verwalteten Profil installiert sind.
- Unabhängige Verwaltung von Konten im primären Nutzer- oder verwalteten Profil
[C-1-8] Die vorinstallierten Telefon-, Kontakt- und Messaging-Apps MÜSSEN die Möglichkeit haben, Anruferinformationen aus dem verwalteten Profil (falls vorhanden) zusammen mit denen aus dem primären Profil zu suchen und abzurufen, sofern dies vom Geräterichtliniencontroller zulässig ist.
[C-1-9] Es MUSS dafür sorgen, dass alle Sicherheitsanforderungen für ein Gerät mit aktivierter Mehrfachnutzung erfüllt werden (siehe Abschnitt 9.5), auch wenn das verwaltete Profil nicht zusätzlich zum primären Nutzer gezählt wird.

Wenn in Geräteimplementierungen android.software.managed_users und android.software.secure_lock_screen deklariert werden, gilt Folgendes:

[C-2-1] Es MUSS möglich sein, einen separaten Sperrbildschirm anzugeben, der die folgenden Anforderungen erfüllt, um Zugriff nur auf Apps zu gewähren, die in einem verwalteten Profil ausgeführt werden.
- Geräteimplementierungen MÜSSEN die DevicePolicyManager.ACTION_SET_NEW_PASSWORD-Intent einhalten und eine Benutzeroberfläche anzeigen, über die separate Anmeldedaten für den Sperrbildschirm für das verwaltete Profil konfiguriert werden können.
- Für die Anmeldedaten des Sperrbildschirms des verwalteten Profils MÜSSEN dieselben Speicher- und Verwaltungsmechanismen für Anmeldedaten wie für das übergeordnete Profil verwendet werden, wie auf der Android Open Source Project-Website beschrieben.
- Die Passwortrichtlinien des DPC MÜSSEN nur auf die Anmeldedaten für den Sperrbildschirm des verwalteten Profils angewendet werden, es sei denn, die DevicePolicyManager-Instanz wird von getParentProfileInstance zurückgegeben.
Wenn Kontakte aus dem verwalteten Profil im vorinstallierten Anrufprotokoll, in der Anrufoberfläche, in Benachrichtigungen zu laufenden und verpassten Anrufen, in Kontakt- und Messaging-Apps angezeigt werden, MÜSSEN sie mit demselben Symbol gekennzeichnet sein, das für Anwendungen im verwalteten Profil verwendet wird.

3.9.3 Support für verwaltete Nutzer

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

[C-1-1] Es MUSS eine Nutzerfunktion geben, mit der er sich von dem aktuellen Nutzer abmelden und in einer Sitzung mit mehreren Nutzern zum Hauptnutzer zurückkehren kann, wenn isLogoutEnabled true zurückgibt. Auf die Nutzerfunktion MUSS vom Sperrbildschirm aus zugegriffen werden können, ohne das Gerät entsperren zu müssen.

3.10. Bedienungshilfen

Android bietet eine Bedienungshilfenebene, die es Nutzern mit Beeinträchtigungen erleichtert, ihre Geräte zu bedienen. Darüber hinaus bietet Android Plattform-APIs, mit denen Implementierungen von Bedienungshilfen Rückrufe für Nutzer- und Systemereignisse erhalten und alternative Feedbackmechanismen wie Text-zu-Sprache-Funktion, haptisches Feedback und Navigation per Trackball/D-Pad generieren können.

Wenn Geräteimplementierungen Bedienungshilfen von Drittanbietern unterstützen, gilt Folgendes:

[C-1-1] Es MUSS eine Implementierung des Android-Bedienungshilfen-Frameworks wie in der SDK-Dokumentation der Accessibility APIs beschrieben bereitgestellt werden.
[C-1-2] MÜSSEN Ereignisse zur Barrierefreiheit generieren und die entsprechenden AccessibilityEvent an alle registrierten AccessibilityService-Implementierungen senden, wie im SDK dokumentiert.
[C-1-4] Es MUSS eine Schaltfläche in der Navigationsleiste des Systems hinzugefügt werden, mit der der Nutzer den Bedienungshilfendienst steuern kann, wenn die aktivierten Bedienungshilfen den AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON angeben . Für Geräteimplementierungen ohne Systemnavigationsleiste gilt diese Anforderung nicht. Geräteimplementierungen sollten jedoch eine Nutzeroberfläche zur Steuerung dieser Bedienungshilfen bieten.

Wenn Geräteimplementierungen vorinstallierte Dienste zur Barrierefreiheit enthalten, gilt Folgendes:

[C-2-1] Diese vorinstallierten Bedienungshilfen MÜSSEN als Direct Boot Aware-Apps implementiert werden, wenn der Datenspeicher mit der dateibasierten Verschlüsselung (File Based Encryption, FBE) verschlüsselt ist.
Es sollte in der Einrichtung einen Mechanismus geben, mit dem Nutzer relevante Bedienungshilfen aktivieren können, sowie Optionen zum Anpassen der Schrift- und Displaygröße und der Gesten für die Vergrößerung.

3.11. Sprachausgabe

Android enthält APIs, mit denen Anwendungen TTS-Dienste (Text-to-Speech) nutzen und Dienstanbieter TTS-Dienste implementieren können.

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

[C-1-1] MUSS die APIs des Android TTS Framework unterstützen.

Wenn die Geräteimplementierungen die Installation von TTS-Engines von Drittanbietern unterstützen, gilt Folgendes:

[C-2-1] Es MUSS eine Nutzerinteraktion geben, mit der der Nutzer eine TTS-Engine für die Verwendung auf Systemebene auswählen kann.

3.12. TV Input Framework

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

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

[C-1-1] Die Plattformfunktion android.software.live_tv MUSS deklariert werden.
[C-1-2] MÜSSEN alle TIF-APIs unterstützen, damit eine Anwendung, die diese APIs und den Dienst für TIF-basierte Eingaben von Drittanbietern verwendet, auf dem Gerät installiert und verwendet werden kann.

3.13. Schnelleinstellungen

Android bietet eine Benutzeroberfläche für die Schnelleinstellungen, über die häufig verwendete oder dringend benötigte Aktionen schnell aufgerufen werden können.

Wenn Geräteimplementierungen eine UI-Komponente für die Schnelleinstellungen enthalten und die Schnelleinstellungen von Drittanbietern unterstützen, gilt Folgendes:

[C-1-1] Der Nutzer MUSS die Möglichkeit haben, die über die quicksettings APIs bereitgestellten Kacheln aus einer Drittanbieter-App hinzuzufügen oder zu entfernen.
[C-1-2] Es darf KEINE Kacheln von Drittanbieter-Apps automatisch in die Schnelleinstellungen aufgenommen werden.
[C-1-3] Alle vom Nutzer hinzugefügten Kacheln von Drittanbieter-Apps MÜSSEN neben den vom System bereitgestellten Kacheln für die Schnelleinstellungen angezeigt werden.

3.14. Medien-UI

Wenn Geräteimplementierungen nicht sprachaktivierte Apps (die Apps) enthalten, die über MediaBrowser oder MediaSession mit Drittanbieter-Apps interagieren, gelten für die Apps die folgenden Anforderungen:

[C-1-2] Es MÜSSEN Symbole, die über „getIconBitmap()“ oder „getIconUri()“ und Titel, die über „getTitle()“ abgerufen wurden, wie unter MediaDescription beschrieben, deutlich angezeigt werden. Titel können gekürzt werden, um Sicherheitsvorschriften einzuhalten (z.B. Ablenkung des Fahrers).
[C-1-3] Das Symbol der Drittanbieter-App MUSS immer angezeigt werden, wenn Inhalte dieser Drittanbieter-App 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 Sicherheitsvorschriften einzuhalten (z. B. Ablenkung des Fahrers). Es darf jedoch KEINE Bevorzugung aufgrund von Inhalten oder Inhaltsanbietern geben.
[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 erteilt werden, 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 freigegeben und hat CATEGORY_BROWSABLE
- Die Aktion ist eine der folgenden: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- Das Ziel wird explizit mit android:visibleToInstantApps freigegeben.
[C-0-3] Instant Apps dürfen NICHT explizit mit installierten Apps interagieren, es sei denn, die Komponente wird über „android:visibleToInstantApps“ freigegeben.
[C-0-4] Installierte Apps DÜRFEN KEINE Details zu Instant Apps auf dem Gerät sehen, es sei denn, die Instant App stellt ausdrücklich eine Verbindung zur installierten Anwendung her.

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

[C-1-1] MÜSSEN die folgenden Nutzerfreundlichkeiten für die Interaktion mit Instant Apps bereitstellen. Das AOSP erfüllt die Anforderungen mit der Standard-Benutzeroberfläche, den Standardeinstellungen und dem Standard-Launcher.
[C-1-2] Es MUSS eine Nutzerfunktion geben, mit der Nutzer lokal im Cache gespeicherte Instant Apps für jedes einzelne App-Paket ansehen und löschen können.
[C-1-3] Es MUSS eine dauerhafte Nutzerbenachrichtigung geben, die minimiert werden kann, während eine Instant-App im Vordergrund ausgeführt wird. Diese Nutzerbenachrichtigung MUSS darauf hinweisen, dass Instant Apps nicht installiert werden müssen, und eine Nutzerinteraktion enthalten, die den Nutzer zum Bildschirm mit den App-Informationen in den Einstellungen weiterleitet. Bei Instant Apps, die über Webintents gestartet werden, wie definiert durch die Verwendung eines Intents mit der Aktion „Intent.ACTION_VIEW“ und dem Schema „http“ oder „https“, sollte dem Nutzer über eine zusätzliche Nutzeroberfläche die Möglichkeit gegeben werden, die Instant App nicht zu starten, sondern den zugehörigen Link mit dem konfigurierten Webbrowser zu öffnen, sofern auf dem Gerät ein Browser verfügbar ist.
[C-1-4] Es MUSS möglich sein, über die Funktion „Letzte Apps“ auf laufende Instant Apps zuzugreifen, wenn die Funktion „Letzte Apps“ auf dem Gerät verfügbar ist.
[C-1-5] Es MUSS eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für die 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 das Koppeln von Zusatzgeräten, um die Verknüpfung mit Zusatzgeräten effizienter zu verwalten. Außerdem bietet die CompanionDeviceManager API Apps die Möglichkeit, auf diese Funktion zuzugreifen.

Wenn die Geräteimplementierungen die Kopplungsfunktion für Companion-Geräte unterstützen, gilt Folgendes:

[C-1-1] Das Funktions-Flag FEATURE_COMPANION_DEVICE_SETUP MUSS deklariert werden .
[C-1-2] Die APIs im Paket android.companion MÜSSEN vollständig implementiert sein.
[C-1-3] Es MÜSSEN Nutzeroptionen vorhanden sein, mit denen Nutzer ein verbundenes Gerät auswählen und bestätigen können, dass es vorhanden und funktionsfähig ist.

3:17. Ressourcenintensive Apps

Wenn die Funktion FEATURE_CANT_SAVE_STATE in Geräteimplementierungen deklariert wird, gilt Folgendes:

[C-1-1] Es darf nur eine installierte App geben, die angibt, dass cantSaveState im System ausgeführt wird. Wenn der Nutzer eine solche App verlässt, ohne sie explizit zu beenden (z. B. durch Drücken der Startbildschirmtaste, während eine aktive Aktivität im System aktiv ist, anstatt die Rücktaste zu drücken, wenn keine aktiven Aktivitäten mehr im System vorhanden sind), muss diese App in der Geräteimplementierung im RAM priorisiert werden, genau wie andere Elemente, die voraussichtlich weiter ausgeführt werden, z. B. Dienste im Vordergrund. Auch wenn eine solche App im Hintergrund ausgeführt wird, kann das System weiterhin Energiesparfunktionen darauf anwenden, z. B. den CPU- und Netzwerkzugriff einschränken.
[C-1-2] Es MUSS eine UI-Affordance zur Auswahl der App geben, die nicht am normalen Speicher-/Wiederherstellungsmechanismus für den Status teilnimmt, wenn der Nutzer eine zweite App startet, die mit dem Attribut cantSaveState deklariert wurde.
[C-1-3] Es dürfen KEINE anderen Richtlinienänderungen auf Apps angewendet werden, für die cantSaveState angegeben ist, z. B. Änderungen an der CPU-Leistung oder an der Planungspriorisierung.

Wenn die Funktion FEATURE_CANT_SAVE_STATE in Geräteimplementierungen nicht deklariert wird, gilt Folgendes:

[C-1-1] Das von Apps festgelegte Attribut cantSaveState MUSS ignoriert werden und das App-Verhalten darf NICHT basierend auf diesem Attribut geändert werden.

3.18. Kontakte

Android enthält Contacts Provider APIs, mit denen Anwendungen die auf dem Gerät gespeicherten Kontaktdaten 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 sein. Kontakte, die nur auf dem Gerät gespeichert sind, werden als lokale Kontakte bezeichnet.

RawContacts sind mit einem Konto „verknüpft“ oder „in einem Konto gespeichert“, wenn die Spalten ACCOUNT_NAME und ACCOUNT_TYPE für die RawContacts mit den entsprechenden Feldern Account.name und Account.type des Kontos übereinstimmen.

Standardlokales 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 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 nicht nullwertigen Wert 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 für die Geräteimplementierung ein benutzerdefiniertes lokales Konto verwendet wird:

[C-1-1] Die ACCOUNT_NAME des benutzerdefinierten lokalen Kontos MUSS bis ContactsContract.RawContacts.getLocalAccountName zurückgegeben werden.
[C-1-2] Die ACCOUNT_TYPE des benutzerdefinierten lokalen Kontos MUSS bis ContactsContract.RawContacts.getLocalAccountType zurückgegeben werden.
[C-1-3] Raw-Kontakte, die von Drittanbieter-Apps mit dem Standardlokalkonto 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, die im benutzerdefinierten lokalen Konto ausgeführt werden, MÜSSEN dazu führen, dass Rohkontakte sofort gelöscht werden (als wäre der Parameter CALLER_IS_SYNCADAPTER auf „wahr“ gesetzt), auch wenn der Parameter CALLER\_IS\_SYNCADAPTER auf „falsch“ 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 mit dem im offiziellen Android SDK enthaltenen Tool „aapt“ generiert wurden.
Da die oben genannte Anforderung eine Herausforderung darstellen kann, wird für Geräteimplementierungen das Paketverwaltungssystem der AOSP-Referenzimplementierung EMPFOHLEN.

Geräteimplementierungen:

[C-0-2] MUSS die Überprüfung von „.apk“-Dateien mit dem APK-Signaturschema v3 , dem APK-Signaturschema v2 und der JAR-Signatur unterstützen.
[C-0-3] Die Dateiformate .apk, Android-Manifest, Dalvik-Bytecode oder RenderScript-Bytecode dürfen NICHT so erweitert werden, dass die Installation und Ausführung dieser Dateien auf anderen kompatiblen Geräten verhindert wird.
[C-0-4] Es darf KEINEN Apps außer dem aktuellen „installer of record“ für das Paket erlaubt sein, die App ohne Nutzerbestätigung im Hintergrund zu deinstallieren, wie im SDK für die Berechtigung DELETE_PACKAGE dokumentiert. Die einzigen Ausnahmen sind die App zur Überprüfung von Systempaketen, die den Intent PACKAGE_NEEDS_VERIFICATION verarbeitet, und die App zum Speichermanager, die den Intent ACTION_MANAGE_STORAGE verarbeitet.
[C-0-5] Es MUSS eine Aktivität geben, die den Intent android.settings.MANAGE_UNKNOWN_APP_SOURCES verarbeitet.
[C-0-6] Es dürfen KEINE App-Pakete aus unbekannten Quellen installiert werden, es sei denn, die App, die die Installation anfordert, erfüllt alle folgenden Anforderungen:
- Es MUSS die Berechtigung REQUEST_INSTALL_PACKAGES angeben oder der Wert für android:targetSdkVersion muss 24 oder niedriger sein.
- Der Nutzer MUSS die Berechtigung erteilt haben, Apps aus unbekannten Quellen zu installieren.
Es sollte Nutzern ermöglicht werden, die Berechtigung zum Installieren von Apps aus unbekannten Quellen pro Anwendung zu gewähren oder zu widerrufen. Es ist jedoch zulässig, dies als No-Op zu implementieren und RESULT_CANCELED für startActivityForResult() zurückzugeben, wenn Nutzern diese Auswahlmöglichkeit nicht über die Geräteimplementierung zur Verfügung gestellt werden soll. Auch in solchen Fällen sollte der Nutzer jedoch darüber informiert werden, warum keine solche Auswahl angezeigt wird.
[C-0-7] Es MUSS ein Warndialogfeld mit dem Warnstring angezeigt werden, der dem Nutzer über die System-API PackageManager.setHarmfulAppWarning zur Verfügung gestellt wird, bevor eine Aktivität in einer Anwendung gestartet wird, die von derselben System-API PackageManager.setHarmfulAppWarning als potenziell schädlich gekennzeichnet wurde.
Es sollte Nutzern im Warndialogfeld die Möglichkeit gegeben werden, eine Anwendung zu deinstallieren oder zu starten.
[C-0-8] Es MUSS Unterstützung für das inkrementelle Dateisystem implementiert werden, wie hier beschrieben.
[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 Systemsoftwareupdate erfüllt werden können, können sie von diesen Anforderungen AUSGESCHLOSSEN werden.

5. Multimedia-Kompatibilität

Geräteimplementierungen:

[C-0-1] MUSS die in Abschnitt 5.1 definierten Medienformate, 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 angeben und melden, die Drittanbieter-Apps über MediaCodecList zur Verfügung stehen.
[C-0-3] MUSS alle Formate, die es codieren kann, korrekt decodieren und für Drittanbieter-Apps verfügbar machen. Dazu gehören alle Bitstreams, die von den Encodern generiert werden, und die Profile, die in der CamcorderProfile gemeldet werden.

Geräteimplementierungen:

SOLLTEN eine minimale Codec-Latenz anstreben, d. h. sie sollten:
- Darf keine Eingabebuffer verbrauchen und speichern und darf Eingabebuffer nur nach der Verarbeitung zurückgeben.
- Dekodierte Puffer DÜRFEN nicht länger als im Standard angegeben (z.B. SPS) aufbewahrt werden.
- Die codierten Puffer dürfen NICHT länger als von der GOP-Struktur erforderlich gehalten werden.

Alle im folgenden Abschnitt aufgeführten Codecs werden als Softwareimplementierungen in der bevorzugten Android-Implementierung des Android Open Source Project bereitgestellt.

Weder Google noch die Open Handset Alliance geben eine Zusicherung dafür, dass diese Codecs frei von Patenten Dritter sind. Nutzer, die diesen Quellcode in Hardware- oder Softwareprodukten verwenden möchten, werden darauf hingewiesen, dass für die Implementierung dieses Codes, einschließlich in Open-Source-Software oder Shareware, Patentlizenzen der entsprechenden Patentinhaber erforderlich sein können.

5.1. Medien-Codecs

5.1.1. Audiocodierung

Weitere Informationen finden Sie unter 5.1.3. Details zu Audio-Codecs

Wenn in Geräteimplementierungen android.hardware.microphone deklariert wird, 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 Audioencoder MÜSSEN Folgendes unterstützen:

[C-3-1] PCM-16-Bit-Audioframes mit nativer Byte-Reihenfolge über die android.media.MediaCodec API

5.1.2. Audiodekodierung

Weitere Informationen finden Sie unter 5.1.3. Details zu Audio-Codecs

Wenn die Geräteimplementierungen die Unterstützung der android.hardware.audio.output-Funktion angeben, müssen sie die Dekodierung der folgenden Audioformate unterstützen:

[C-1-1] MPEG-4 AAC-Profil (AAC LC)
[C-1-2] MPEG-4 HE AAC Profile (AAC+)
[C-1-3] MPEG-4 HE AACv2-Profil (erweitertes AAC+)
[C-1-4] AAC ELD (Enhanced Low Delay AAC)
[C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, einschließlich USAC Baseline Profile und ISO/IEC 23003-4 Dynamic Range Control Profile)
[C-1-5] FLAC
[C-1-6] MP3
[C-1-7] MIDI
[C-1-8] Vorbis
[C-1-9] PCM/WAVE, einschließlich Audioformate mit hoher Auflösung bis zu 24 Bit, 192 kHz Abtastrate und 8 Kanälen. Diese Anforderung gilt nur für die Dekodierung. Ein Gerät darf während der Wiedergabephase ein Downsampling und Downmix durchführen.
[C-1-10] Opus

Wenn Geräteimplementierungen die Dekodierung von AAC-Eingabepuffern von Mehrkanalstreams (d.h. mehr als zwei Kanäle) in PCM über den Standard-AAC-Audiodecoder in der android.media.MediaCodec API unterstützen, MÜSSEN Folgendes unterstützt werden:

[C-2-1] Die Dekodierung MUSS ohne Downmix 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] Die Metadaten für den dynamischen Bereich MÜSSEN gemäß der Definition in „Dynamic Range Control (DRC)“ in ISO/IEC 14496-3 und den android.media.MediaFormat DRC-Schlüsseln für die Konfiguration des dynamisch bereichsbezogenen Verhaltens des Audiodecoders sein. 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-Audiodekoder die Anforderungen C-2-1 und C-2-2 oben erfüllen.

Bei der Dekodierung von USAC-Audio: MPEG-D (ISO/IEC 23003-4):

[C-3-1] Lautstärke- und DRC-Metadaten MÜSSEN gemäß dem 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-Profil-Decoder:

KANN die Lautstärke- und den Dynamikbereich mit dem Dynamic Range Control Profile (ISO/IEC 23003-4) steuern.

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 nach ISO/IEC 23003-4 MÜSSEN Vorrang haben.

Alle Audiodekoder MÜSSEN die Ausgabe folgender Formate unterstützen:

[C-6-1] PCM-16-Bit-Audioframes mit nativer Byte-Reihenfolge über die android.media.MediaCodec API

5.1.3. Audio-Codecs – Details

Format/Codec	Details	Zu unterstützende Dateitypen/Containerformate
MPEG-4 AAC-Profil (AAC LC)	Unterstützung für Mono-/Stereo-/5.0-/5.1-Inhalte mit Standardabtastraten von 8 bis 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS-Raw-AAC (.aac, ADIF nicht unterstützt) MPEG-TS (.ts, nicht suchbar, nur decodieren) Matroska (.mkv, nur Dekodierung)
MPEG-4 HE AAC Profile (AAC+)	Unterstützung für Mono-/Stereo-/5.0-/5.1-Inhalte mit Standardabtastraten von 16 bis 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profil (erweitertes AAC+)	Unterstützung für Mono-/Stereo-/5.0-/5.1-Inhalte mit Standardabtastraten von 16 bis 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (Enhanced Low Delay AAC)	Unterstützung für Mono-/Stereoinhalte mit Standardabtastraten von 16 bis 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Unterstützung für Mono-/Stereoinhalte mit Standardabtastraten von 7,35 bis 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 bis 12,2 kbit/s bei 8 kHz abgetastet	3GPP (.3gp)
AMR-WB	9 Raten von 6,60 kbit/s bis 23,85 kbit/s 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 MÜSSEN mindestens die Modi „Mono“ und „Stereo“ unterstützt werden. Abtastraten bis zu 192 kHz MÜSSEN unterstützt werden. 16-Bit- und 24-Bit-Auflösung MÜSSEN unterstützt werden. Die Verarbeitung von FLAC-24-Bit-Audiodaten MUSS mit einer Gleitkomma-Audiokonfiguration verfügbar sein.	FLAC (.flac) MPEG-4 (.mp4, .m4a, nur decodieren) Matroska (.mkv, nur Dekodierung)
MP3	Mono/Stereo 8–320 kbit/s konstant (CBR) oder variable Bitrate (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, nur decodieren) Matroska (.mkv, nur Dekodierung)
MIDI	MIDI-Typ 0 und 1 DLS-Version 1 und 2 XMF und Mobile XMF. Unterstützung für 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 decodieren) 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-, 32-Bit-lineares PCM und 32-Bit-Gleitkomma (Raten bis zum Limit der Hardware) unterstützen. Abtastraten MÜSSEN zwischen 8 kHz und 192 kHz liegen.	WAVE (.wav)
Opus	Dekodierung: 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. Encoding: Unterstützung für Mono- und Stereoinhalte mit Abtastraten von 8.000, 12.000, 16.000, 24.000 und 48.000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, nur decodieren) Matroska (.mkv) WebM (.webm)

5.1.4. Bildcodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Bildcodecs

Geräteimplementierungen MÜSSEN die folgenden Bildcodierungen 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] Es MUSS ein hardwaregestützter HEVC-Encoder-Codec bereitgestellt werden, der den BITRATE_MODE_CQ-Bitrate-Kontrollmodus, das HEVCProfileMainStill-Profil und eine Framegröße von 512 × 512 Pixeln unterstützt.

5.1.5. Bild-Decodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Bildcodecs

Geräteimplementierungen MÜSSEN die Dekodierung der folgenden Bildcodierungen 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 die Geräteimplementierungen die HEVC-Videodekodierung unterstützen, MÜSSEN sie: * [C-1-1] die HEIF-Bilddekodierung (HEIC) unterstützen.

Bilddekoder, die ein Format mit hoher Bittiefe unterstützen (mehr als 9 Bit pro Kanal):

[C-2-1] MUSS die Ausgabe eines 8‑Bit-äquivalenten Formats 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 Bildcodecs

Format/Codec	Details	Unterstützte Dateitypen/Containerformate
JPEG	Basispreis + progressiver Preis	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)

Bildencoder und ‑decoder, die über die MediaCodec API bereitgestellt werden

[C-1-1] MUSS das flexible Farbformat YUV420 8:8:8 (COLOR_FormatYUV420Flexible) bis CodecCapabilities unterstützen.
[SR] Es wird dringend empfohlen, das RGB888-Farbformat für den Eingabemodus „Surface“ zu unterstützen.
[C-1-3] Es muss mindestens eines der planaren oder semiplanaren YUV420 8:8:8-Farbformate unterstützt werden: COLOR_FormatYUV420PackedPlanar (entspricht COLOR_FormatYUV420Planar) oder COLOR_FormatYUV420PackedSemiPlanar (entspricht COLOR_FormatYUV420SemiPlanar). Es wird DRINGEND empfohlen, beide zu unterstützen.

5.1.7. Video-Codecs

Für eine akzeptable Qualität von Webvideostreaming und Videokonferenzdiensten SOLLTE bei Geräteimplementierungen ein Hardware-VP8-Codec verwendet werden, der die Anforderungen erfüllt.

Wenn die Geräteimplementierungen einen Video-Decoder oder -Encoder enthalten:

[C-1-1] Videocodecs MÜSSEN Ausgabe- und Eingabe-Bytebuffergrößen unterstützen, die den größten möglichen komprimierten und unkomprimierten Frame gemäß Standard und Konfiguration aufnehmen, aber auch nicht überbelegen.
[C-1-2] Videoencoder und ‑decoder MÜSSEN flexible Farbformate von YUV420 8:8:8 (COLOR_FormatYUV420Flexible) bis CodecCapabilities unterstützen.
[C-1-3] Videoencoder und ‑decoder MÜSSEN mindestens ein planares oder semiplanares YUV420 8:8:8-Farbformat unterstützen: COLOR_FormatYUV420PackedPlanar (entspricht COLOR_FormatYUV420Planar) oder COLOR_FormatYUV420PackedSemiPlanar (entspricht COLOR_FormatYUV420SemiPlanar). Es wird DRINGEND empfohlen, beide zu unterstützen.
[SR] Videoencoder und ‑decoder sollten mindestens eines der hardwareoptimierten planaren oder semiplanaren YUV420 8:8:8-Farbformate (YV12, NV12, NV21 oder ein entsprechendes vom Anbieter optimiertes Format) unterstützen.
[C-1-5] Videodekoder, die ein Format mit hoher Bittiefe (mehr als 9 Bit pro Kanal) unterstützen, MÜSSEN die Ausgabe eines 8‑Bit-äquivalenten Formats unterstützen, wenn dies von der Anwendung angefordert wird. Dies muss durch die Unterstützung eines YUV420 8:8:8-Farbformats ü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 für Zwischenaktualisierungen über FEATURE_IntraRefresh in der Klasse MediaCodecInfo.CodecCapabilities angeben, gilt Folgendes:

[C-3-1] MUSS die Aktualisierungszeiten im Bereich von 10 bis 60 Frames unterstützen und innerhalb von 20% der konfigurierten Aktualisierungszeit genau funktionieren.

Sofern die Anwendung nicht über den Formatschlüssel KEY_COLOR_FORMAT etwas anderes angibt, gilt für Videodecoder-Implementierungen Folgendes:

[C-4-1] MUSS standardmäßig das für die Hardwareanzeige optimierte Farbformat verwenden, wenn es mit der Surface-Ausgabe konfiguriert ist.
[C-4-2] Es MUSS standardmäßig ein YUV420 8:8:8-Farbformat verwendet werden, das für die CPU-Lese optimiert ist, wenn die Surface-Ausgabe nicht verwendet wird.

5.1.8. Liste der Video-Codecs

Format/Codec	Details	Zu unterstützende Dateitypen/Containerformate
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, nur Dekodierung)
H.264 AVC	Weitere Informationen finden Sie in den Abschnitten 5.2 und 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, nicht suchbar) Matroska (.mkv, nur Dekodierung)
H.265 HEVC	Weitere Informationen finden Sie unter Abschnitt 5.3.	MPEG-4 (.mp4) Matroska (.mkv, nur Dekodierung)
MPEG-2	Profil "Main"	MPEG2-TS (.ts, nicht suchbar) MPEG-4 (.mp4, nur decodieren) Matroska (.mkv, nur Dekodierung)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, nur Dekodierung)
VP8	Weitere Informationen finden Sie in den Abschnitten 5.2 und 5.3.	WebM (.webm) Matroska (.mkv)
VP9	Weitere Informationen finden Sie unter Abschnitt 5.3.	WebM (.webm) Matroska (.mkv)

5.1.9. Medien-Codec-Sicherheit

Bei der Geräteimplementierung MÜSSEN die unten beschriebenen Sicherheitsfunktionen für Mediencodecs eingehalten werden.

Android unterstützt OMX, eine plattformübergreifende Multimedia-Beschleunigungs-API, sowie Codec 2.0, eine Multimedia-Beschleunigungs-API mit geringem Overhead.

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

[C-1-1] MUSS Unterstützung für Medien-Codecs entweder über OMX- oder Codec 2.0-APIs (oder beide) wie im Android Open Source Project bieten und die Sicherheitsmaßnahmen nicht deaktivieren oder umgehen. Das bedeutet nicht, dass jeder Codec entweder die OMX- oder die Codec 2.0 API verwenden MUSS. Es muss lediglich mindestens eine dieser APIs unterstützt werden. Die Unterstützung der verfügbaren APIs muss außerdem die vorhandenen Sicherheitsmaßnahmen umfassen.
[C-SR] Es wird DRINGEND empfohlen, die Unterstützung für die Codec 2.0 API hinzuzufügen.

Wenn Geräteimplementierungen die Codec 2.0 API nicht unterstützen, gilt Folgendes:

[C-2-1] Für jedes vom Gerät unterstützte Medienformat und jeden vom Gerät unterstützten Typ (Encoder oder Decoder) MUSS der entsprechende OMX-Software-Codec aus dem Android Open Source Project (sofern verfügbar) enthalten sein.
[C-2-2] Codecs, deren Namen mit „OMX.google.“ beginnen MÜSSEN auf dem Quellcode des Android Open Source Project 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 Speicherzuordnungsprogramme hat.

Wenn Geräteimplementierungen die Codec 2.0 API unterstützen, gilt Folgendes:

[C-3-1] Für jedes vom Gerät unterstützte Medienformat und jeden vom Gerät unterstützten Typ (Encoder oder Decoder) MUSS der entsprechende Codec 2.0-Software-Codec aus dem Android Open Source Project (sofern verfügbar) enthalten sein.
[C-3-2] Die Codec 2.0-Software-Codecs MÜSSEN im Software-Codec-Prozess gemäß dem Android Open Source Project gespeichert werden, damit der Zugriff auf Software-Codecs eingeschränkt werden kann.
[C-3-3] Codecs, deren Namen mit „c2.android.“ beginnen MÜSSEN auf dem Quellcode des Android Open Source Project basieren.

5.1.10. Medien-Codec-Charakterisierung

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

[C-1-1] MÜSSEN über die MediaCodecInfo API korrekte Werte für die Medien-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-Richtlinien für die Benennung entsprechen.
[C-1-3] Codecs mit Namen, die mit „c2.“ beginnen Sie MÜSSEN die Codec 2.0 API verwenden und Namen haben, die den Codec 2.0-Richtlinien für Android entsprechen.
[C-1-4] Codecs mit Namen, die mit „OMX.google.“ oder „c2.android.“ beginnen Darf NICHT als anbieter- oder hardwaregestützt gekennzeichnet werden.
[C-1-5] Codecs, die in einem Codec-Prozess (Anbieter- oder System) ausgeführt werden und Zugriff auf andere Hardwaretreiber als Speicherallokatoren und ‑mapper haben, DÜRFEN NICHT als reine Software bezeichnet werden.
[C-1-6] Codecs, die nicht im Android Open Source Project enthalten sind oder nicht auf dem Quellcode dieses Projekts basieren, MÜSSEN als Anbieter gekennzeichnet werden.
[C-1-7] Codecs, die die Hardwarebeschleunigung nutzen, MÜSSEN als hardwarebeschleunigt gekennzeichnet sein.
[C-1-8] Codec-Namen DÜRFEN NICHT irreführend sein. Codecs mit dem Namen „decoders“ MÜSSEN beispielsweise die Dekodierung 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 die 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 vom Codec 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 Pixel (VP8, VP8) 320 × 240 Pixel (andere)	704 x 576 Pixel (H263) 640 × 360 px (VP8, VP9) 640 x 480 Pixel (MPEG4-Encoder) 720 x 480 Pixel (Sonstiges)	1408 × 1152 Pixel (H263) 1280 × 720 Pixel (Sonstiges)	1920 x 1080 Pixel (nicht MPEG4)	3840 × 2160 Pixel (HEVC, VP9)

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

5.2. Videocodierung

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

Die Bitrate darf über zwei gleitende Fenster hinweg nicht um mehr als 15% über der Bitrate zwischen den Intraframe-Intervallen (I-Frames) liegen.
Die Bandbreitenüberschreitung darf in einem gleitenden Fenster von 1 Sekunde nicht mehr als 100% betragen.

Wenn Geräteimplementierungen ein integriertes Display mit einer Diagonale von mindestens 6,4 cm haben oder einen Videoausgang enthalten oder die Unterstützung einer Kamera über das android.hardware.camera.any-Funktionsflag deklarieren, gelten folgende Anforderungen:

[C-1-1] MUSS mindestens einen der Videoencoder VP8 oder H.264 unterstützen und für Drittanbieteranwendungen verfügbar machen.
MÜSSEN sowohl VP8- als auch H.264-Videoencoder unterstützen und diese für Anwendungen von Drittanbietern verfügbar machen.

Wenn Geräteimplementierungen einen der Videoencoder H.264, VP8, VP9 oder HEVC unterstützen und für Drittanbieteranwendungen verfügbar machen, gelten folgende Anforderungen:

[C-2-1] MUSS dynamisch konfigurierbare Bitraten unterstützen.
MÜSSEN variable Frameraten unterstützen, wobei der Videoencoder die momentane Framedauer anhand der Zeitstempel der Eingabebuffer bestimmen und den Bitbucket basierend auf dieser Framedauer zuweisen SOLLTE.

Wenn Geräteimplementierungen den MPEG-4 SP-Videoencoder unterstützen und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

MÜSSEN dynamisch konfigurierbare Bitraten für den unterstützten Encoder unterstützen.

Wenn Geräteimplementierungen hardwaregestützte Video- oder Bildencoder bereitstellen und eine oder mehrere angeschlossene oder anschließbare Hardwarekameras unterstützen, die über die android.camera APIs verfügbar sind:

[C-4-1] Alle hardwarebeschleunigten Video- und Bildencoder MÜSSEN Frames von den Hardwarekameras codieren können.
MÜSSEN Frames von den Hardwarekameras über alle Video- oder Bildencoder codieren.

5.2.1. H.263

Wenn Geräteimplementierungen H.263-Encoder unterstützen und diese für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

[C-1-1] MUSS das Baseline-Profil der Stufe 45 unterstützen.
MÜSSEN dynamisch konfigurierbare Bitraten für den unterstützten Encoder unterstützen.

5.2.2. H.264

Wenn die Geräteimplementierungen den H.264-Codec unterstützen, gilt Folgendes:

[C-1-1] MUSS das Referenzprofil der Stufe 3 unterstützen. Die Unterstützung von ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist jedoch OPTIONAL. Außerdem wird empfohlen, ASO, FMO und RS nicht für das Baseline-Profil zu verwenden, um die Kompatibilität mit anderen Android-Geräten zu gewährleisten.
[C-1-2] MÜSSEN die Videocodierungsprofile für SD (Standard Definition) in der folgenden Tabelle unterstützen.
Sollte Main Profile Level 4 unterstützen.
MÜSSEN die HD-Videocodierungsprofile (High Definition) wie in der folgenden Tabelle angegeben unterstützen.

Wenn Geräteimplementierungen über die Medien-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] MÜSSEN 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 x 480 px	1.280 × 720 Pixel	1920 × 1080 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.
MÜSSEN die folgenden HD-Videocodierungsprofile (High Definition) unterstützen.
[C-1-2] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
MÜSSEN einen Hardware-VP8-Codec bereitstellen, der den Anforderungen an die RTC-Hardwarecodierung des WebM-Projekts entspricht, um eine akzeptable Qualität von Webvideostreaming 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] MÜSSEN 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	1.280 × 720 Pixel	1920 × 1080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	800 kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.4. VP9

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

[C-1-2] MUSS Profil 0 Level 3 unterstützen.
[C-1-1] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
[C-1-3] MÜSSEN CodecPrivate-Daten generieren.
MÜSSEN die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
[SR] Es wird DRINGEND empfohlen, die in der folgenden Tabelle aufgeführten HD-Decodierungsprofile zu unterstützen, wenn ein Hardware-Encoder vorhanden ist.

	SD	HD 720p	HD 1080p	UHD
Videoauflösung	720 x 480 px	1.280 × 720 Pixel	1920 × 1080 Pixel	3840 x 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 in der Geräteimplementierung angegeben ist, dass Profil 2 oder Profil 3 über die Media APIs unterstützt wird:

Die Unterstützung des 12-Bit-Formats ist OPTIONAL.

5.2.5. H.265

Wenn die Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:

[C-1-1] MUSS das Hauptprofil der Stufe 3 unterstützen.
MÜSSEN 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 x 480 px	1.280 × 720 Pixel	1920 × 1080 Pixel	3840 x 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. Videodekodierung

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

[C-1-1] MUSS dynamische Videoauflösung 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 Hauptprofil auf hoher Ebene unterstützen.

5.3.2. H.263

Wenn Geräteimplementierungen H.263-Decoder unterstützen, gilt Folgendes:

[C-1-1] MUSS das Baseline-Profil der Stufe 30 und der Stufe 45 unterstützen.

5.3.3. MPEG-4

Bei Geräteimplementierungen mit MPEG-4-Decodern gilt Folgendes:

[C-1-1] MUSS Simple Profile Level 3 unterstützen.

5.3.4. H.264

Wenn die Geräteimplementierungen H.264-Decoder unterstützen, gilt Folgendes:

[C-1-1] MUSS Main Profile Level 3.1 und Baseline Profile unterstützen. Die Unterstützung von ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist OPTIONAL.
[C-1-2] MUSS Videos mit den in der folgenden Tabelle aufgeführten SD-Profilen (Standarddefinition) decodieren können, die mit dem Baseline-Profil und dem Hauptprofil der Stufe 3.1 codiert sind (einschließlich 720p30).
MÜSSEN in der Lage sein, Videos mit den HD-Profilen (High Definition) zu decodieren, wie in der folgenden Tabelle angegeben.

Wenn die von der Display.getSupportedModes()-Methode gemeldete Höhe der Videoauflösung entspricht oder diese übersteigt, gilt für Geräteimplementierungen Folgendes:

[C-2-1] MÜSSEN die Video-Decodierungsprofile für HD 720p in der folgenden Tabelle unterstützen.
[C-2-2] MÜSSEN die in der folgenden Tabelle aufgeführten Videodekodierungsprofile für HD 1080p unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 240 px	720 x 480 px	1.280 × 720 Pixel	1920 × 1080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	60 fps	30 fps (60 fps^Fernseher)
Video-Bitrate	800 kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.3.5. H.265 (HEVC)

Wenn die Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:

[C-1-1] MUSS das Main Profile Level 3 Main Tier und die SD-Videodekodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
MÜSSEN die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
[C-1-2] MUSS die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen, wenn ein Hardware-Decoder vorhanden ist.

Wenn die mit der Methode Display.getSupportedModes() gemeldete Höhe der Videoauflösung entspricht oder größer ist, gilt Folgendes:

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

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	352 × 288 px	720 x 480 px	1.280 × 720 Pixel	1920 × 1080 Pixel	3840 x 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-Hardwaredekodierung})	60 fps
Video-Bitrate	600 Kbit/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Wenn Geräteimplementierungen angeben, dass sie ein HDR-Profil über die Media APIs unterstützen:

[C-3-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR-Metadaten von der Anwendung akzeptieren 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 korrekt auf dem Gerätebildschirm oder über einen 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-Dekodierungsprofile in der folgenden Tabelle unterstützen.
Es sollte ein Hardware-VP8-Codec verwendet werden, der die Anforderungen erfüllt.
MÜSSEN die HD-Dekodierungsprofile in der folgenden Tabelle unterstützen.

Wenn die Höhe, die mit der Methode Display.getSupportedModes() ermittelt wurde, der Videoauflösung entspricht oder größer 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 1080p-Profile in der folgenden Tabelle unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 180 px	640 × 360 px	1.280 × 720 Pixel	1920 × 1080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30 fps (60 fps^Fernseher)	30 (60 fps^Fernseher)
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 SD-Video-Dekodierungsprofile unterstützen, die in der folgenden Tabelle aufgeführt sind.
MÜSSEN die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.

Wenn die Geräteimplementierungen den VP9-Codec und einen Hardware-Decoder unterstützen:

[C-2-1] MUSS die HD-Dekodierungsprofile unterstützen, die in der folgenden Tabelle aufgeführt sind.

Wenn die mit der Methode Display.getSupportedModes() gemeldete Höhe der Videoauflösung entspricht oder größer ist, gilt Folgendes:

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

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	320 × 180 px	640 × 360 px	1.280 × 720 Pixel	1920 × 1080 Pixel	3840 x 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 VP9Profile2 oder VP9Profile3 über die Medien-APIs 'CodecProfileLevel' unterstützen:

Die Unterstützung des 12-Bit-Formats ist OPTIONAL.

Wenn Geräteimplementierungen angeben, dass sie über die Media APIs ein HDR-Profil (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) unterstützen:

[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) aus der Anwendung akzeptieren. Außerdem MÜSSEN sie das Extrahieren und Ausgeben der erforderlichen HDR-Metadaten aus dem Bitstream und/oder Container unterstützen.
[C-4-2] Geräteimplementierungen MÜSSEN HDR-Inhalte korrekt auf dem Gerätebildschirm oder über einen Standard-Videoausgang (z.B. HDMI).

5.3.8. Dolby Vision

Wenn die Geräteimplementierung die Unterstützung des Dolby Vision-Decoders über HDR_TYPE_DOLBY_VISION deklariert , gilt Folgendes:

[C-1-1] Es MUSS ein Dolby Vision-fähiger Extractor bereitgestellt werden.
[C-1-2] Dolby Vision-Inhalte MÜSSEN korrekt auf dem Display des Geräts oder über einen Standard-Videoausgang (z.B. HDMI).
[C-1-3] Der Titelindex der rückwärtskompatiblen Basisebenen (falls vorhanden) MUSS mit dem Titelindex der kombinierten Dolby Vision-Ebene übereinstimmen.

5.3.9. AV1

Wenn die 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 „SOLLTE“ aufgeführt. In der Kompatibilitätsdefinition für zukünftige Versionen werden diese jedoch voraussichtlich in „MUSS“ geändert. Für bestehende und neue Android-Geräte wird DRINGEND empfohlen, diese Anforderungen zu erfüllen, die als „SOLLTE“ aufgeführt sind. Andernfalls sind sie nach dem Upgrade auf die zukünftige Version nicht mit Android kompatibel.

5.4.1. Rohe Audioaufnahme und Mikrofoninformationen

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

[C-1-1] MÜSSEN die Erfassung von Roh-Audioinhalten mit den folgenden Eigenschaften zulassen:
- Format: Lineare PCM, 16 Bit
- Abtastraten: 8.000, 11.025, 16.000, 44.100, 48.000 Hz
- Kanäle: Mono
MÜSSEN die Erfassung von Roh-Audioinhalten mit den folgenden Eigenschaften ermöglichen:
- Format: Lineare PCM, 16‑Bit und 24‑Bit
- Abtastraten: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 Hz
- Kanäle: So viele Kanäle wie die Anzahl der Mikrofone auf dem Gerät
[C-1-2] Die Aufnahme muss mit den oben genannten Abtastraten erfolgen, ohne Upsampling.
[C-1-3] Es MUSS ein geeigneter Anti-Aliasing-Filter verwendet werden, wenn die oben genannten Abtastfrequenzen mit Downsampling erfasst werden.
MÜSSEN die Aufnahme von Roh-Audioinhalten in AM-Radio- und DVD-Qualität ermöglichen. Das bedeutet, dass die folgenden Eigenschaften erfüllt sein müssen:
- Format: Lineare PCM, 16 Bit
- Abtastraten: 22.050, 48.000 Hz
- Kanäle: Stereo
- [C-1-4] MUSS die MicrophoneInfo API einhalten und Informationen zu den verfügbaren Mikrofonen auf dem Gerät korrekt ausfüllen, auf die die Drittanbieter-Apps über die AudioManager.getMicrophones() API zugreifen können, sowie zu den derzeit aktiven Mikrofonen, auf die die Drittanbieter-Apps über die APIs AudioRecord.getActiveMicrophones() und MediaRecorder.getActiveMicrophones() zugreifen können. Wenn die Geräteimplementierungen die Aufnahme von Roh-Audioinhalten in AM-Radio- und DVD-Qualität ermöglichen, gilt Folgendes:
[C-2-1] Die Aufnahme muss ohne Upsampling bei einem Verhältnis von mehr als 16.000:22.050 oder 44.100:48.000 erfolgen.
[C-2-2] Es MUSS ein geeigneter Anti-Aliasing-Filter für jede Art von Up- oder Downsampling verwendet werden.

5.4.2. Für Spracherkennung aufnehmen

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

[C-1-1] Die android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION-Audioquelle muss mit einer der Abtastraten 44.100 oder 48.000 aufgenommen werden.
[C-1-2] MUSS standardmäßig alle Audioverarbeitungsmethoden zur Rauschunterdrückung deaktivieren, wenn ein Audiostream von der AudioSource.VOICE_RECOGNITION-Audioquelle aufgezeichnet wird.
[C-1-3] Bei der Aufzeichnung eines Audiostreams von der AudioSource.VOICE_RECOGNITION-Audioquelle MUSS standardmäßig die automatische Verstärkungsregelung deaktiviert sein.
Der Audiostream für die Spracherkennung sollte mit einer nahezu flachen Amplituden-/Frequenzcharakteristik aufgezeichnet werden, genauer gesagt mit ± 3 dB von 100 Hz bis 4.000 Hz.
Der Audiostream für die Spracherkennung sollte mit einer Empfindlichkeit für die Eingabe eingestellt werden, die bei einer Quelle mit einer Schallleistung von 90 dB bei 1.000 Hz eine RMS von 2.500 für 16-Bit-Samples ergibt.
Der Audiostream für die Spracherkennung sollte so aufgezeichnet werden, dass die PCM-Amplitudenstufen die Änderungen des Eingangs-SPL über einen Bereich von mindestens 30 dB von −18 dB bis +12 dB bezogen auf 90 dB SPL am Mikrofon linear verfolgen.
Der Audiostream für die Spracherkennung sollte mit einer Gesamtharmonischen Verzerrung (Total Harmonic Distortion, THD) von weniger als 1% für 1 kHz bei einem Eingangspegel von 90 dB SPL am Mikrofon aufgezeichnet werden.

Wenn bei der Geräteimplementierung android.hardware.microphone und Geräuschunterdrückungstechnologien für die Spracherkennung angegeben werden, gilt Folgendes:

[C-2-1] Dieser Audioeffekt MUSS mit der android.media.audiofx.NoiseSuppressor API steuerbar sein.
[C-2-2] Jede Implementierung von Geräuschunterdrückungstechnologien MUSS über das Feld AudioEffect.Descriptor.uuid eindeutig identifiziert werden.

5.4.3. Daten für die Weiterleitung der Wiedergabe erfassen

Die android.media.MediaRecorder.AudioSource-Klasse 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] Die REMOTE_SUBMIX-Audioquelle MUSS richtig implementiert sein, damit eine Anwendung, die die android.media.AudioRecord API zum Aufzeichnen von dieser Audioquelle verwendet, einen Mix aller Audiostreams aufnimmt, mit folgenden Ausnahmen:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. Akustische Echounterdrückung

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

MÜSSEN eine Technologie zur akustischen Echounterdrückung (AEC) implementieren, die auf die Sprachkommunikation abgestimmt ist und beim Aufnehmen mit AudioSource.VOICE_COMMUNICATION auf den Aufnahmepfad angewendet wird.

Wenn die Geräteimplementierung eine akustische Echounterdrückung bietet, die in den Audiopfad der Aufnahme eingefügt wird, wenn AudioSource.VOICE_COMMUNICATION ausgewählt ist, gilt Folgendes:

[C-SR] Es wird dringend empfohlen, dies über die API-Methode AcousticEchoCanceler AcousticEchoCanceler.isAvailable() zu deklarieren.
[C-SR] Es wird dringend empfohlen, diesen Audioeffekt mit der AcousticEchoCanceler API steuerbar zu machen.
[C-SR] Es wird dringend empfohlen, jede AEC-Technologie-Implementierung über das Feld AudioEffect.Descriptor.uuid eindeutig zu identifizieren.

5.4.5. Gleichzeitige Aufnahme

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

[C-1-1] Es MUSS ein gleichzeitiger Zugriff auf das Mikrofon durch einen Dienst zur Barrierefreiheit, der mit AudioSource.VOICE_RECOGNITION erfasst, und mindestens eine Anwendung, die mit einer beliebigen AudioSource erfasst, möglich sein.
[C-1-2] MUSS den gleichzeitigen Zugriff auf das Mikrofon durch eine vorinstallierte App mit einer Assistant-Rolle und mindestens eine App-Aufzeichnung mit einer beliebigen AudioSource zulassen, mit Ausnahme von AudioSource.VOICE_COMMUNICATION oder AudioSource.CAMCORDER.
[C-1-3] Die Audioaufnahme für alle anderen Apps muss stummgeschaltet werden, mit Ausnahme von Bedienungshilfen, während eine App mit AudioSource.VOICE_COMMUNICATION oder AudioSource.CAMCORDER aufnimmt. Wenn eine App jedoch über AudioSource.VOICE_COMMUNICATION aufnimmt, kann eine andere App den Sprachanruf aufzeichnen, wenn es sich um eine privilegierte (vorinstallierte) App mit der Berechtigung CAPTURE_AUDIO_OUTPUT handelt.
[C-1-4] Wenn zwei oder mehr Anwendungen gleichzeitig aufzeichnen und keine der Apps eine Benutzeroberfläche hat, wird der Audiostream an die App gesendet, die die Aufzeichnung am spätesten gestartet hat.

5.4.6. Mikrofonverstärkungsstufen

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

MÜSSEN im mittleren Frequenzbereich eine nahezu flache Amplitude-zu-Frequenz-Charakteristik 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 Audioeingabeempfindlichkeit MUSS so eingestellt sein, dass eine Sinustonquelle mit 1.000 Hz, die bei einem Schalldruckpegel (SPL) von 90 dB wiedergegeben wird, für jedes Mikrofon, das zum Aufzeichnen der Audioquelle für die Spracherkennung verwendet wird, eine Antwort mit einer RMS von 2.500 für 16‑Bit-Samples (oder −22,35 dB Vollskala für Gleitkomma-/Doppelpräzision-Samples) liefert.
[C-SR] Es wird DRINGEND empfohlen, dass die Amplituden im niedrigen Frequenzbereich für jedes Mikrofon, das zur Aufnahme der Audioquelle für die Spracherkennung verwendet wird, ± 20 dB von 5 Hz bis 100 Hz im Vergleich zum Mittelfrequenzbereich betragen.
[C-SR] Es wird DRINGEND empfohlen, dass die Amplituden im Hochfrequenzbereich für jedes Mikrofon, das zur Aufnahme der Audioquelle für die Spracherkennung verwendet wird, ± 30 dB von 4.000 Hz bis 22.000 Hz im Vergleich zum Mittelfrequenzbereich betragen.

5.5. Audiowiedergabe

Android unterstützt die Audiowiedergabe über das Audioausgabegerät, wie in Abschnitt 7.8.2 definiert.

5.5.1. Rohe Audiowiedergabe

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

[C-1-1] MÜSSEN die Wiedergabe von Roh-Audioinhalten mit den folgenden Eigenschaften zulassen:
- Quellformate: Lineare PCM, 16-Bit, 8-Bit, Float
- Kanäle: Mono, Stereo, gültige Mehrkanalkonfigurationen mit bis zu 8 Kanälen
- Abtastfrequenzen (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
MÜSSEN die Wiedergabe von Roh-Audioinhalten mit den folgenden Eigenschaften zulassen:
- Abtastraten: 24.000, 48.000

5.5.2. Audioeffekte

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

Wenn die Funktion android.hardware.audio.output in Geräteimplementierungen deklariert wird, gilt Folgendes:

[C-1-1] MUSS die EFFECT_TYPE_EQUALIZER- und EFFECT_TYPE_LOUDNESS_ENHANCER-Implementierungen unterstützen, die über die AudioEffect-Unterklassen Equalizer und LoudnessEnhancer gesteuert werden.
[C-1-2] MUSS die Visualizer API-Implementierung unterstützen, die über die Klasse Visualizer gesteuert wird.
[C-1-3] Die EFFECT_TYPE_DYNAMICS_PROCESSING-Implementierung MUSS über die AudioEffect-Unterklasse DynamicsProcessing steuerbar sein.
MÜSSEN die EFFECT_TYPE_BASS_BOOST-, EFFECT_TYPE_ENV_REVERB-, EFFECT_TYPE_PRESET_REVERB- und EFFECT_TYPE_VIRTUALIZER-Implementierungen unterstützen, die über die AudioEffect-Unterklassen BassBoost, EnvironmentalReverb, PresetReverb und Virtualizer gesteuert werden.
[C-SR] Es wird DRINGEND empfohlen, Effekte in Gleitkomma- und Mehrkanalformaten zu unterstützen.

5.5.3. Audioausgabelautstärke

Implementierungen von Fahrzeuggeräten:

Die Audiolautstärke sollte für jeden Audiostream separat angepasst werden können. Dabei sollte der Inhaltstyp oder die Verwendung gemäß AudioAttributes und die Verwendung von Audioinhalten in Autos gemäß der öffentlichen Definition in android.car.CarAudioManager berücksichtigt werden.

5.6. Audiolatenz

Die Audiolatenz ist die Zeitverzögerung, die ein Audiosignal beim Durchlaufen eines Systems hat. Viele Anwendungsklassen erfordern kurze Latenzen, um Echtzeit-Toneffekte zu erzielen.

Im Sinne dieses Abschnitts gelten für die folgenden Begriffe die unten aufgeführten Definitionen:

Ausgabelatenz. Das Intervall zwischen dem Schreiben eines Frames mit PCM-codierten Daten durch eine Anwendung und der Ausgabe des entsprechenden Tons über einen On-Device-Wandler oder dem Verlassen des Signals über einen Port, das extern beobachtet werden kann.
Cold-Output-Latenz. Die Ausgabelatenz für den ersten Frame, wenn das Audioausgabesystem vor der Anfrage inaktiv und ausgeschaltet war.
Kontinuierliche Ausgabelatenz 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 an einen On-Device-Transducer oder ein Signal über einen Port an das Gerät gesendet wird, und dem Zeitpunkt, zu dem eine Anwendung den entsprechenden Frame mit PCM-codierten Daten liest.
Eingabe verloren Der erste Teil eines Eingabesignals, der nicht verwendet werden kann oder nicht verfügbar ist.
Cold-Input-Latenz. 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.
Jitter bei kaltem Start. Die Variabilität zwischen verschiedenen Messungen der Latenzwerte der kalten Ausgabe.
Jitter bei kaltem Eingang. Die Variabilität zwischen den einzelnen Messungen der Latenzwerte bei kalter Eingabe.
kontinuierliche Umlauflatenz. Die Summe aus kontinuierlicher Eingabelatenz, kontinuierlicher Ausgabelatenz und einer Pufferzeit. Die Pufferzeit gibt der App Zeit, das Signal zu verarbeiten und die Phasendifferenz zwischen Eingabe- und Ausgabestreams zu verringern.
OpenSL ES PCM-Puffer-Queue-API Die PCM-bezogenen OpenSL ES APIs im Android NDK.
AAudio Native Audio API Die AAudio APIs im Android NDK.
Zeitstempel. Ein Paar, das aus einer relativen Frameposition innerhalb eines Streams und der geschätzten Zeit besteht, zu der dieser Frame die Audioverarbeitungspipeline am zugehörigen Endpunkt betritt oder verlässt. Siehe auch AudioTimestamp.
glitch. Eine vorübergehende Unterbrechung oder ein falscher Samplewert im Audiosignal, der in der Regel durch einen Buffer-Unterlauf bei der Ausgabe, einen Buffer-Überlauf bei der Eingabe oder eine andere Quelle digitaler oder analoger Störungen verursacht wird.

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

[C-1-1] Der Ausgabezeitstempel, der von AudioTrack.getTimestamp und AAudioStream_getTimestamp zurückgegeben wird, ist auf +/- 2 ms genau.
[C-1-2] Die Latenz der Kaltstartausgabe beträgt maximal 500 Millisekunden.

Wenn für Geräteimplementierungen android.hardware.audio.output deklariert wird, wird dringend empfohlen, die folgenden Anforderungen zu erfüllen oder zu übertreffen:

[C-SR] Die Latenz der Kaltstartausgabe darf 100 Millisekunden nicht überschreiten. Wir empfehlen Ihnen dringend, diese Anforderungen auf allen Geräten mit dieser Android-Version jetzt zu erfüllen. Bei einer zukünftigen Plattformversion im Jahr 2021 ist eine Latenz der Kaltausgabe von maximal 200 ms erforderlich.
[C-SR] Kontinuierliche Ausgabelatenz von maximal 45 Millisekunden.
[C-SR] Jitter bei Kaltstart minimieren.
[C-SR] Der Ausgabezeitstempel, der von AudioTrack.getTimestamp und AAudioStream_getTimestamp zurückgegeben wird, ist auf +/- 1 ms genau.

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

[C-SR] Es wird dringend empfohlen, Audio mit niedriger Latenz zu melden, indem die android.hardware.audio.low_latency-Funktionsflag deklariert wird.
[C-SR] Es wird dringend empfohlen, die Anforderungen für Audio mit niedriger Latenz über die AAudio API zu erfüllen.
[C-SR] Es wird dringend empfohlen, 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) für den Property-Schlüssel AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER zurückgegebenen Wert ist.

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

[C-2-1] Die Unterstützung für Audio mit niedriger Latenz darf NICHT gemeldet werden.

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

[C-3-1] Begrenzen Sie den Fehler bei den Eingabezeitstempeln, die von AudioRecord.getTimestamp oder AAudioStream_getTimestamp zurückgegeben werden, auf +/- 2 ms. „Fehler“ bedeutet hier die Abweichung vom korrekten Wert.
[C-3-2] Die Eingabelatenz nach dem Kaltstart darf 500 Millisekunden nicht überschreiten.

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

[C-SR] Die Eingabelatenz nach dem Kaltstart darf maximal 100 Millisekunden betragen. Wir empfehlen Ihnen dringend, diese Anforderungen auf allen Geräten mit dieser Android-Version jetzt zu erfüllen. Bei einer zukünftigen Plattformversion im Jahr 2021 ist eine Eingabelatenz von maximal 200 ms erforderlich.
[C-SR] Kontinuierliche Eingabelatenz von maximal 30 Millisekunden.
[C-SR] Eine kontinuierliche Round-Trip-Latenz von 50 Millisekunden oder weniger.
[C-SR] Jitter bei der Kaltstarteingabe minimieren.
[C-SR] Begrenzen Sie den Fehler bei den Eingabezeitstempeln, die von AudioRecord.getTimestamp oder AAudioStream_getTimestamp zurückgegeben werden, auf +/- 1 ms.

5.7. Netzwerkprotokolle

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

Wenn Geräteimplementierungen einen Audio- oder Videodecoder enthalten, gelten folgende Anforderungen:

[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 „Mediensegmentformate“ unten aufgeführten Mediensegmentformate über das HTTP Live Streaming-Entwurfsprotokoll, Version 7 unterstützen.
[C-1-3] MUSS das folgende RTP-Audio-Videoprofil und die zugehörigen Codecs in der folgenden RTSP-Tabelle unterstützen. Ausnahmen finden Sie in den Fußnoten der Tabelle in Abschnitt 5.1.

Mediensegmentformate

Segmentformate	Referenzen	Erforderliche Codec-Unterstützung
MPEG-2-Transportstream	ISO 13818	Video-Codecs: H264 AVC MPEG-4 SP MPEG-2 Abschnitt 5.1.3 enthält Details zu H264 AVC, MPEG2-4 SP und MPEG-2. Audio-Codecs: AAC Details zu AAC und seinen Varianten findest du unter Abschnitt 5.1.1.
AAC mit ADTS-Framing und ID3-Tags	ISO 13818-7	Weitere Informationen zu AAC und seinen Varianten findest du in Abschnitt 5.1.1.
WebVTT	WebVTT

Segmentformate

Referenzen

Erforderliche Codec-Unterstützung

MPEG-2-Transportstream

ISO 13818

Video-Codecs:

H264 AVC
MPEG-4 SP
MPEG-2

Abschnitt 5.1.3 enthält Details zu H264 AVC, MPEG2-4 SP und MPEG-2.

Audio-Codecs:

Details zu AAC und seinen Varianten findest du unter Abschnitt 5.1.1.

AAC mit ADTS-Framing und ID3-Tags

ISO 13818-7

Weitere Informationen zu AAC und seinen Varianten findest du in Abschnitt 5.1.1.

WebVTT

RTSP (RTP, SDP)

Profilname	Referenzen	Erforderliche Codec-Unterstützung
H264 AVC	RFC 6184	Weitere Informationen zu H264 AVC findest du in Abschnitt 5.1.3.
MP4A-LATM	RFC 6416	Weitere Informationen zu AAC und seinen Varianten findest du in Abschnitt 5.1.1.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Weitere Informationen zu H263 findest du in Abschnitt 5.1.3.
H263-2000	RFC 4629	Weitere Informationen zu H263 findest du in Abschnitt 5.1.3.
AMR	RFC 4867	Weitere Informationen zu AMR-NB findest du unter Abschnitt 5.1.1.
AMR-WB	RFC 4867	Weitere Informationen zu AMR-WB findest du im Abschnitt 5.1.1.
MP4V-ES	RFC 6416	Weitere Informationen zu MPEG-4 SP findest du in Abschnitt 5.1.3.
mpeg4-generic	RFC 3640	Weitere Informationen zu AAC und seinen Varianten findest du in Abschnitt 5.1.1.
MP2T	RFC 2250	Weitere Informationen finden Sie unter „HTTP Live Streaming“ im Abschnitt MPEG-2-Transportstream.

5.8. Secure Media

Wenn Geräteimplementierungen eine sichere Videoausgabe und sichere Oberflächen unterstützen, gilt Folgendes:

[C-1-1] MÜSSEN Unterstützung für Display.FLAG_SECURE angeben.

Wenn Geräteimplementierungen Display.FLAG_SECURE und das Wireless Display Protocol unterstützen, gilt Folgendes:

[C-2-1] Die Verbindung muss mit einem kryptografisch starken Mechanismus wie HDCP 2.x oder höher für die Displays gesichert werden, die über drahtlose Protokolle wie Miracast verbunden sind.

Wenn Geräteimplementierungen Display.FLAG_SECURE und ein kabelgebundenes externes Display unterstützen, gilt Folgendes:

[C-3-1] MUSS HDCP 1.2 oder höher für alle externen Bildschirme 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 der Funktion android.software.midi über die Klasse android.content.pm.PackageManager melden, gilt Folgendes:

[C-1-1] MUSS MIDI über alle MIDI-fähigen Hardware-Transporte unterstützen, für die eine generische nicht-MIDI-Verbindung bereitgestellt wird. Diese Transporte sind:
- USB-Hostmodus, Abschnitt 7.7
- MIDI over Bluetooth LE in zentraler Rolle, Abschnitt 7.4.3
[C-1-2] MUSS den Inter-App-MIDI-Software-Transport (virtuelle MIDI-Geräte) unterstützen
[C-1-3] MUSS libamidi.so (native MIDI-Unterstützung) enthalten
SOLLTE MIDI über USB-Peripheriegerätemodus unterstützen, Abschnitt 7.7

5.10. Professionelles Audio

Wenn Geräteimplementierungen die Unterstützung für die Funktion android.hardware.audio.pro über die Klasse android.content.pm.PackageManager melden, gilt Folgendes:

[C-1-1] MÜSSEN Unterstützung für die Funktion android.hardware.audio.low_latency angeben.
[C-1-2] Die kontinuierliche Audio-Rücklauflatenz, wie in Abschnitt 5.6 Audiolatenz definiert, darf maximal 20 Millisekunden betragen und sollte über mindestens einen unterstützten Pfad 10 Millisekunden oder weniger betragen.
[C-1-3] MUSS USB-Ports haben, die den USB-Host-Modus und den USB-Peripheriegerätemodus unterstützen.
[C-1-4] MUSS die Unterstützung für die Funktion android.software.midi angeben.
[C-1-5] MÜSSEN die Latenz- und USB-Audioanforderungen sowohl mit der OpenSL ES PCM-Pufferwarteschlangen-API als auch mit mindestens einem Pfad der AAudio Native Audio API erfüllen.
[SR] Es wird DRINGEND empfohlen, die Latenz- und USB-Audioanforderungen mit der AAudio Native Audio API über den MMAP-Pfad zu erfüllen.
[C-1-6] Die Latenz der Kaltstartausgabe muss 200 Millisekunden oder weniger betragen.
[C-1-7] Die Eingabelatenz bei kaltem Start muss 200 Millisekunden oder weniger betragen.
[SR] Es wird DRINGEND empfohlen, eine gleichbleibende CPU-Leistung zu bieten, während Audio aktiv ist und die CPU-Auslastung 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 „Automatischer 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.

MÜSSEN Abweichungen und Abweichungen der Audiouhr relativ zur Standardzeit minimieren.
MÜSSEN die Audiotaktdrift im Verhältnis zur CPU-CLOCK_MONOTONIC minimieren, wenn beide aktiv sind.
MÜSSEN die Audiolatenz über die Transducer auf dem Gerät minimieren.
MÜSSEN die Audiolatenz über digitale USB-Audioschnittstellen minimieren.
MÜSSEN Audiolatenzmessungen über alle Pfade dokumentieren.
Der Jitter bei den Callback-Eingabezeiten für den Abschluss des Audiopuffers sollte minimiert werden, da dies sich auf den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback auswirkt.
Bei normalem Gebrauch und der angegebenen Latenz sollte es KEINE Audiostörungen geben.
Die Latenz zwischen den Kanälen sollte gleich sein.
Die durchschnittliche MIDI-Latenz über alle Transports sollte MINIMIERT werden.
MÜSSEN die MIDI-Latenzvariabilität bei Belastung (Jitter) über alle Übertragungen minimieren.
MÜSSEN genaue MIDI-Zeitstempel über alle Übertragungen hinweg bereitstellen.
MÜSSEN Audiosignalrauschen über On-Device-Wandler minimieren, einschließlich der Zeit unmittelbar nach dem Kaltstart.
Die Audiotaktdifferenz zwischen der Eingabe- und Ausgabeseite der entsprechenden Endpunkte sollte null sein, wenn beide aktiv sind. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher auf dem Gerät oder der Audioeingang und -ausgang.
MÜSSEN Callbacks für den Abschluss des Audiopuffers für die Eingabe- und Ausgabeseite der entsprechenden Endpunkte im selben Thread verarbeiten, wenn beide aktiv sind, und den Ausgabe-Callback sofort nach der Rückkehr aus dem Eingabe-Callback aufrufen. Wenn es nicht möglich ist, die Rückrufe im selben Thread zu verarbeiten, geben Sie den Ausgaberückruf kurz nach dem Eingaberückruf ein, damit die Anwendung eine einheitliche Zeitabfolge für die Eingabe- und Ausgabeseite hat.
MÜSSEN die Phasendifferenz zwischen der HAL-Audiopufferung für die Eingabe- und Ausgabeseite der entsprechenden Endpunkte minimieren.
Die Touch-Latenz sollte MINIMIERT werden.
Die Touch-Latenz sollte unter Last möglichst gering sein (Jitter).
Die Latenz von der Touch-Eingabe bis zur Audioausgabe sollte maximal 40 ms betragen.

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

[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 die Geräteimplementierungen eine 4-polige 3,5-mm-Audiobuchse enthalten, müssen sie:

[C-2-1] Die kontinuierliche Audio-Rundlauflatenz über den Audio-Anschluss darf maximal 20 Millisekunden betragen.
[SR] Es wird dringend empfohlen, den Abschnitt Spezifikationen für Mobilgeräte (Stecker) der Spezifikation für kabelgebundene Audio-Headsets (Version 1.1) einzuhalten.
Die kontinuierliche Audio-Rundlauflatenz über den Audio-Anschluss sollte 10 Millisekunden oder weniger betragen.

Wenn bei Geräten keine 4-polige 3,5-mm-Audiobuchse vorhanden ist, aber USB-Ports, die den USB-Host-Modus unterstützen, müssen folgende Anforderungen erfüllt sein:

[C-3-1] Die USB-Audioklasse MUSS implementiert werden.
[C-3-2] Die Audio-Umlauflatenz über den USB-Host-Modus-Port mit USB Audio Class darf maximal 20 Millisekunden betragen.
Die kontinuierliche Audio-Rundlauflatenz über den USB-Hostmodus-Port mit USB-Audioklasse sollte 10 Millisekunden oder weniger betragen.
[C-SR] Es wird DRINGEND empfohlen, gleichzeitige E/A-Vorgänge mit bis zu 8 Kanälen in jede Richtung, eine Abtastrate von 96 kHz und eine Auflösung von 24 Bit oder 32 Bit zu unterstützen, wenn sie mit USB-Audioperipheriegeräten verwendet werden, die diese Anforderungen ebenfalls erfüllen.

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

MÜSSEN in mindestens einer Konfiguration die Ausgabe in Stereo und acht Kanälen mit 20-Bit- oder 24-Bit-Tiefe und 192 kHz ohne Bittiefeverlust oder Resampling unterstützen.

5.11. Aufnahme für „Unverarbeitet“

Android unterstützt die Aufzeichnung von unverarbeitetem Audio über die Audioquelle android.media.MediaRecorder.AudioSource.UNPROCESSED. In OpenSL ES kann mit der Aufnahmevoreinstellung SL_ANDROID_RECORDING_PRESET_UNPROCESSED darauf zugegriffen werden.

Wenn Geräteimplementierungen die Unterstützung der unverarbeiteten Audioquelle beabsichtigen und sie für Drittanbieter-Apps verfügbar machen möchten, müssen sie:

[C-1-1] Die Unterstützung muss über die android.media.AudioManager-Property PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED gemeldet werden.
[C-1-2] MÜSSEN im mittleren Frequenzbereich eine nahezu flache Amplitude-zu-Frequenz-Charakteristik aufweisen: insbesondere ± 10 dB von 100 Hz bis 7.000 Hz für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird.
[C-1-3] Die Amplitudenwerte im Niederfrequenzbereich MÜSSEN für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird, ± 20 dB von 5 Hz bis 100 Hz im Vergleich zum Mittelfrequenzbereich betragen.
[C-1-4] Müssen Amplitudenwerte im Hochfrequenzbereich aufweisen: insbesondere von ± 30 dB von 7.000 Hz bis 22.000 Hz im Vergleich zum Mittelfrequenzbereich für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird.
[C-1-5] Die Audioeingabeempfindlichkeit MUSS so eingestellt sein, dass eine Sinustonquelle mit 1.000 Hz, die bei einem Schalldruckpegel (SPL) von 94 dB wiedergegeben wird, für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird, eine Antwort mit einem RMS von 520 für 16‑Bit-Samples (oder −36 dB Vollskala für Gleitkomma-/Doppelpräzision-Samples) liefert.
[C-1-6] Für jedes Mikrofon, das zur Aufzeichnung der unbehandelten Audioquelle verwendet wird, MUSS ein Signal-Rausch-Verhältnis (SNR) von mindestens 60 dB vorhanden sein. Der SNR wird als Differenz zwischen 94 dB SPL und dem äquivalenten SPL des Eigenrauschens (A-bewertet) gemessen.
[C-1-7] Die Gesamtharmonische Verzerrung (Total Harmonic Distortion, THD) muss für jedes Mikrofon, das zur Aufzeichnung der unbehandelten Audioquelle verwendet wird, bei 1 kHz und einem Eingangspegel von 90 dB SPL unter 1% liegen.
Der Pfad darf keine andere Signalverarbeitung (z.B. automatische Verstärkungsregelung, Hochpassfilter oder Echounterdrückung) enthalten, außer einem Pegelmultiplikator, um den Pegel in den gewünschten Bereich zu bringen. Mit anderen Worten:
[C-1-8] Wenn die Architektur aus irgendeinem Grund eine Signalverarbeitung enthält, MUSS diese deaktiviert werden und darf keine zusätzliche Latenz oder Verzögerung im Signalpfad verursachen.
[C-1-9] Der Pegelmultiplikator darf sich zwar im Pfad befinden, darf aber KEINE Verzögerung oder Latenz im Signalpfad verursachen.

Alle SPL-Messungen werden direkt neben dem zu testenden Mikrofon durchgeführt. Bei mehreren Mikrofonkonfigurationen gelten diese Anforderungen für jedes Mikrofon.

Wenn Geräteimplementierungen android.hardware.microphone angeben, aber keine unverarbeitete Audioquelle unterstützen, gilt Folgendes:

[C-2-1] Für die AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API-Methode MUSS null zurückgegeben werden, um die fehlende Unterstützung korrekt anzugeben.
[SR] Es wird nach wie vor DRINGEND empfohlen, so viele Anforderungen wie möglich für den Signalpfad für die unbearbeitete Aufnahmequelle zu erfüllen.

6. Kompatibilität von Entwicklertools und ‑optionen

6.1. Entwicklertools

Geräteimplementierungen:

[C-0-1] MUSS die im Android SDK bereitgestellten Android-Entwicklertools unterstützen.
Android Debug Bridge (adb)
- [C-0-2] MUSS adb gemäß der Dokumentation im Android SDK und die im AOSP bereitgestellten Shell-Befehle 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. Upgrades von Geräteimplementierungen von einer früheren Android-Version ohne nichtflüchtigen Datenblock KÖNNEN von C-0-11 ausgenommen werden.
- [C-0-3] Das Format oder den 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] Die folgenden Ereignisse MÜSSEN ohne Auslassung aufgezeichnet und für den cmd stats-Shell-Befehl und die StatsManager-System-API-Klasse zugänglich gemacht werden.
  - 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 geräteseitige adb-Daemon MUSS standardmäßig inaktiv sein und es MUSS einen nutzerzugänglichen Mechanismus zum Aktivieren der Android Debug Bridge geben.
- [C-0-5] MUSS sicheres ADB unterstützen. Android unterstützt sichere adb-Verbindungen. Mit Secure adb wird adb auf bekannten authentifizierten Hosts aktiviert.
- [C-0-6] Es MUSS ein Mechanismus vorhanden sein, mit dem adb von einem Hostcomputer aus verbunden werden kann. Im Detail:
Wenn Geräteimplementierungen ohne USB-Anschluss den Peripheriemodus unterstützen, gilt Folgendes:
- [C-3-1] adb MUSS über ein lokales Netzwerk (z. B. Ethernet oder WLAN) implementiert werden.
- [C-3-2] Es MÜSSEN Treiber für Windows 7, 8 und 10 bereitgestellt werden, mit denen 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 AdbManager#isAdbWifiSupported()-Methode MUSS true zurückgeben.
Wenn Geräteimplementierungen adb-Verbindungen zu einem Hostcomputer über WLAN unterstützen und mindestens eine Kamera enthalten, gilt Folgendes:
- [C-5-1] Die AdbManager#isAdbWifiQrSupported()-Methode MUSS true zurückgeben.
Dalvik Debug Monitor Service (ddms)
- [C-0-7] MUSS 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. Sie MUSS jedoch unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben beschrieben aktiviert hat.
Affe
- [C-0-8] Das Monkey-Framework MUSS enthalten sein und für Anwendungen verfügbar gemacht werden.
SysTrace
- [C-0-9] MUSS das systrace-Tool unterstützen, wie im Android SDK beschrieben. Systrace muss standardmäßig inaktiv sein und es MUSS einen nutzerzugänglichen Mechanismus geben, um Systrace zu aktivieren.
Perfetto
- [C-SR] Es wird DRINGEND empfohlen, dem Shell-Nutzer eine /system/bin/perfetto-Binärdatei bereitzustellen, deren Befehlszeile der Perfetto-Dokumentation entspricht.
- [C-SR] Es wird DRINGEND empfohlen, dass die perfetto-Binärdatei als Eingabe eine Protobuf-Konfiguration akzeptiert, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [C-SR] Es wird dringend empfohlen, mit der perfetto-Binärdatei einen Protobuf-Trace als Ausgabe zu schreiben, 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 anzugeben.
Low Memory Killer
- [C-0-10] Es MUSS ein LMK_KILL_OCCURRED_FIELD_NUMBER-Atom in das statsd-Log geschrieben werden, wenn eine App vom Low Memory Killer beendet wird.
Test-Harness-Modus 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] Der Test-Harnischmodus MUSS wie in der Dokumentation zum Test-Harnischmodus beschrieben implementiert werden.

Wenn die Geräteimplementierungen die Unterstützung von Vulkan 1.0 oder höher über die android.hardware.vulkan.version-Funktionsflags melden, gilt Folgendes:

[C-1-1] Es MUSS eine Funktion geben, mit der der App-Entwickler GPU-Debug-Ebenen aktivieren oder deaktivieren kann.
[C-1-2] Wenn die GPU-Debugebenen aktiviert sind, MÜSSEN im Basisverzeichnis der debugbaren Anwendungen Ebenen in Bibliotheken aufgezählt werden, die von externen Tools bereitgestellt werden (d.h. nicht Teil des Plattform- oder Anwendungspakets), um die API-Methoden vkEnumerateInstanceLayerProperties() und vkCreateInstance() zu unterstützen.

6.2. Entwickleroptionen

Android bietet Entwicklern Unterstützung bei der Konfiguration von Einstellungen für die Anwendungsentwicklung.

Geräteimplementierungen MÜSSEN eine einheitliche Nutzung der Entwickleroptionen ermöglichen. Dabei gelten folgende Anforderungen:

[C-0-1] Der Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS MUSS berücksichtigt werden, um Einstellungen für die Anwendungsentwicklung anzuzeigen. In der Upstream-Android-Implementierung ist das Menü „Entwickleroptionen“ standardmäßig ausgeblendet. Nutzer können die Entwickleroptionen aufrufen, indem sie siebenmal auf das Menü Einstellungen > Informationen zum Gerät > Build-Nummer tippen.
[C-0-2] Die Entwickleroptionen MÜSSEN standardmäßig ausgeblendet sein.
[C-0-3] Es MUSS ein klarer Mechanismus vorhanden sein, der keine Bevorzugung einer Drittanbieter-App gegenüber einer anderen bei der Aktivierung der Entwickleroptionen vorsieht. Sie MÜSSEN ein öffentlich sichtbares Dokument oder eine öffentlich sichtbare Website zur Verfügung stellen, in dem bzw. auf dem beschrieben wird, wie die Entwickleroptionen aktiviert werden. Dieses Dokument oder diese Website MUSS über die Android SDK-Dokumente verlinkbar sein.
Es sollte eine fortlaufende visuelle Benachrichtigung für den Nutzer geben, wenn die Entwickleroptionen aktiviert sind und die Sicherheit des Nutzers gefährdet ist.
Es ist zulässig, den Zugriff auf das Menü „Entwickleroptionen“ vorübergehend einzuschränken, indem es ausgeblendet oder deaktiviert wird, um Ablenkungen in Situationen zu vermeiden, in denen die Sicherheit des Nutzers ein Anliegen ist.

7. Hardwarekompatibilität

Wenn ein Gerät eine bestimmte Hardwarekomponente mit einer entsprechenden API für Drittanbieterentwickler hat:

[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 hat:

[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, bei denen Nullwerte gemäß der SDK-Dokumentation nicht zulässig sind.
[C-0-6] API-Methoden DÜRFEN KEINE Ausnahmen auslösen, die nicht in der SDK-Dokumentation beschrieben sind.
[C-0-7] Geräteimplementierungen MÜSSEN für dieselbe Build-Fingerabdruck-Kennung über die Methoden getSystemAvailableFeatures() und hasSystemFeature(String) der Klasse android.content.pm.PackageManager korrekte Informationen zur Hardwarekonfiguration melden.

Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telephony API: Auch auf Geräten, die keine Smartphones sind, müssen diese APIs als sinnvolle No-Ops implementiert werden.

7.1. Display und Grafik

Android bietet Funktionen, mit denen Anwendungs-Assets und UI-Layouts automatisch an das Gerät angepasst werden, damit Drittanbieter-Apps auf verschiedenen Hardwarekonfigurationen ordnungsgemäß funktionieren. Auf den Android-kompatiblen Displays, auf denen alle Android-kompatiblen Drittanbieter-Apps ausgeführt werden können, MÜSSEN diese APIs und Verhaltensweisen wie in diesem Abschnitt beschrieben implementiert sein.

Die Einheiten, auf die in den Anforderungen in diesem Abschnitt verwiesen wird, sind so definiert:

die physische Diagonale. Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Bereichs des Displays.
Punkte pro Zoll (dpi). Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spannweite von 1" abgedeckt werden. Wenn dpi-Werte aufgeführt sind, müssen sowohl die horizontalen als auch die vertikalen dpi in den Bereich fallen.
Seitenverhältnis. Das Verhältnis der Pixel der längeren zur kürzeren Seite des Bildschirms. Ein Display mit 480 × 854 Pixeln hat beispielsweise ein Seitenverhältnis von 854 ÷ 480 = 1, 779, also ungefähr „16:9“.
Dichteunabhängiges Pixel (dp). Die virtuelle Pixeleinheit, normalisiert auf ein Display mit 160 dpi, berechnet als: Pixel = dpi * (Dichte/160).

7.1.1. Bildschirmkonfiguration

7.1.1.1. Bildschirmgröße und -form

Das Android-UI-Framework unterstützt eine Vielzahl verschiedener logischer Bildschirmlayoutgrößen und ermöglicht es Anwendungen, die Größe des Bildschirmlayouts 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 die Configuration.screenLayout gemäß der Definition in der Android SDK-Dokumentation angeben. Insbesondere müssen Geräteimplementierungen die korrekten logischen Bildschirmabmessungen in Dichte-unabhängigen Pixeln (dp) wie unten angegeben angeben:
- Geräte, für die Configuration.uiMode auf einen anderen Wert als „UI_MODE_TYPE_WATCH“ festgelegt ist und die eine small-Größe für die Configuration.screenLayout melden, MÜSSEN mindestens 426 dp × 320 dp haben.
- Geräte, die eine normal-Größe für die Configuration.screenLayout angeben, MÜSSEN mindestens 480 dp × 320 dp haben.
- Geräte, die eine large-Größe für die Configuration.screenLayout melden, MÜSSEN mindestens 640 dp × 480 dp haben.
- Geräte, die eine xlarge-Größe für die Configuration.screenLayout melden, MÜSSEN mindestens 960 dp × 720 dp haben.
[C-0-2] Die angegebene Unterstützung von Bildschirmgrößen durch Anwendungen MUSS über das <supports-screens>-Attribut in der AndroidManifest.xml korrekt berücksichtigt werden, wie in der Android SDK-Dokumentation beschrieben.
KANN Android-kompatible Displays mit abgerundeten Ecken haben.

Wenn Geräteimplementierungen UI_MODE_TYPE_NORMAL unterstützen und Android-kompatible Displays mit abgerundeten Ecken haben, gilt Folgendes:

[C-1-1] Es MUSS sichergestellt sein, dass mindestens eine der folgenden Anforderungen erfüllt ist:
Der Radius der abgerundeten Ecken darf maximal 38 dp betragen.
Wenn an jeder Ecke des logischen Displays ein Feld mit einer Größe von 15 × 15 dp verankert ist, ist auf dem Bildschirm mindestens ein Pixel jedes Felds sichtbar.
Es sollte eine Nutzerinteraktion zum Wechseln in den Displaymodus mit den rechteckigen Ecken geben.

Wenn Geräteimplementierungen ein Android-kompatibles Display haben, das sich zusammenfalten lässt, oder ein Scharnier zwischen mehreren Displayfeldern und diese Displays für das Rendern von Drittanbieter-Apps verfügbar machen, gelten folgende Anforderungen:

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

Wenn Geräteimplementierungen ein Android-kompatibles Display haben, das sich zusammenfalten lässt, oder ein Scharnier zwischen mehreren Displaybereichen und das Scharnier oder die Falte ein Vollbildfenster der Anwendung kreuzt, gelten folgende Anforderungen:

[C-3-1] Die Position, die Grenzen und den Zustand des Scharniers oder des Klappmechanismus müssen der Anwendung über Erweiterungen oder Sidecar-APIs gemeldet werden.

Weitere Informationen zur korrekten Implementierung der Sidecar- oder Erweiterungs-APIs finden Sie in der öffentlichen Dokumentation von Window Manager Jetpack.

7.1.1.2. Seitenverhältnis des Bildschirms

Für das Seitenverhältnis des physischen Displays der Android-kompatiblen Displays gibt es keine Einschränkungen. Das Seitenverhältnis des logischen Displays, auf dem Drittanbieter-Apps gerendert werden, das sich aus den über die view.Display APIs und Konfigurations-APIs gemeldeten Werten für Höhe und Breite ableiten lässt, MUSS jedoch 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:
- Die App hat angegeben, dass sie ein größeres Seitenverhältnis unterstützt. Dies ist über den Metadatenwert android.max_aspect angegeben.
- Die App gibt über das Attribut android:resizeableActivity an, dass sie in der Größe veränderbar ist.
- Die App ist auf API-Level 24 oder höher ausgerichtet und deklariert keine android:maxAspectRatio, die 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 breiter gezogen werden, indem eine der folgenden Bedingungen erfüllt ist:
- Die App gibt über das Attribut android:resizeableActivity an, dass sie in der Größe veränderbar ist.
- Die App deklariert eine android:minAspectRatio, die 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 das Seitenverhältnis auf 1,0 (1:1) festgelegt sein.

7.1.1.3. Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe von standardmäßigen logischen Dichten, die Entwicklern helfen, ihre Anwendungsressourcen zu optimieren.

[C-0-1] Standardmäßig MÜSSEN Geräteimplementierungen nur eine der Android-Framework-Dichten melden, die auf DisplayMetrics über die DENSITY_DEVICE_STABLE API aufgeführt sind. Dieser Wert DARF sich zu keinem Zeitpunkt ändern. Das Gerät KANN jedoch eine andere beliebige Dichte melden, je nach den Änderungen an der Displaykonfiguration, die der Nutzer nach dem ersten Start vorgenommen hat (z. B. Displaygröße).
Bei Geräteimplementierungen sollte die Standarddichte des Android-Frameworks definiert werden, die der physischen Dichte des Bildschirms numerisch am nächsten kommt, es sei denn, diese logische Dichte drückt die gemeldete Bildschirmgröße unter die unterstützte Mindestgröße. 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, MÜSSEN Geräteimplementierungen die nächstniedrigere Standarddichte des Android-Frameworks angeben.

Wenn es eine Option gibt, die Displaygröße des Geräts zu ändern:

[C-1-1] Die Displaygröße darf nicht größer als das 1,5-Fache der nativen Dichte sein oder eine effektive Mindestbildschirmgröße von weniger als 320 dp (entspricht dem Ressourcenqualifizierer „sw320dp“) haben, je nachdem, was zuerst eintritt.
[C-1-2] Die Displaygröße darf NICHT auf weniger als 0,85-fache der nativen Dichte skaliert werden.
Für eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen wird die folgende Skalierung der Optionen für native Anzeigen EMPFOHLEN (unter Einhaltung der oben genannten Limits):
Klein: 0,85x
Standard: 1x (native Displayskala)
Groß: 1,15-fach
Größer: 1,3-fach
Größter Wert: 1,45-fach

7.1.2. Displaymesswerte

Wenn die Geräteimplementierungen Android-kompatible Displays oder eine Videoausgabe an die Android-kompatiblen Bildschirme enthalten, müssen sie:

[C-1-1] MÜSSEN korrekte Werte für alle Android-kompatiblen Displaymesswerte melden, die in der android.util.DisplayMetrics API definiert sind.

Wenn die Geräteimplementierungen kein eingebettetes Display oder eine Videoausgabe enthalten, müssen sie:

[C-2-1] MÜSSEN korrekte Werte des Android-kompatiblen Displays gemäß der android.util.DisplayMetrics API für das emulierte Standard-view.Display melden.

7.1.3. Displayausrichtung

Geräteimplementierungen:

[C-0-1] MÜSSEN angeben, welche Bildschirmausrichtungen unterstützt werden (android.hardware.screen.portrait und/oder android.hardware.screen.landscape) und MÜSSEN mindestens eine unterstützte Ausrichtung angeben. Bei einem Gerät mit einem fixierten Querformat-Display, z. B. einem Fernseher oder Laptop, sollte nur android.hardware.screen.landscape gemeldet werden.
[C-0-2] MUSS den korrekten Wert für die aktuelle Ausrichtung des Geräts angeben, wenn es über die android.content.res.Configuration.orientation, android.view.Display.getOrientation() oder andere APIs abgefragt wird.

Wenn die Geräteimplementierungen beide Bildschirmausrichtungen unterstützen, gilt Folgendes:

[C-1-1] Apps MÜSSEN eine dynamische Ausrichtung im Hoch- oder Querformat unterstützen. Das Gerät muss also die Anfrage der Anwendung für eine bestimmte Bildschirmausrichtung respektieren.
[C-1-2] Die gemeldete Bildschirmgröße oder -dichte darf sich beim Ändern der Ausrichtung NICHT ändern.
Sie können als Standardeinstellung entweder das Hoch- oder das Querformat auswählen.

7.1.4. 2D- und 3D-Grafikbeschleunigung

7.1.4.1 OpenGL ES

Geräteimplementierungen:

[C-0-1] Die unterstützten OpenGL ES-Versionen (1.1, 2.0, 3.0, 3.1, 3.2) MÜSSEN über die verwalteten APIs (z. B. über die GLES10.getString()-Methode) und die nativen APIs korrekt angegeben werden.
[C-0-2] MUSS die Unterstützung für alle entsprechenden verwalteten APIs und nativen APIs für jede OpenGL ES-Version umfassen, die als unterstützt angegeben wurde.

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

[C-1-1] MUSS 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.
MÜSSEN OpenGL ES 3.2 unterstützen.

Wenn Geräteimplementierungen eine der OpenGL ES-Versionen unterstützen, gilt Folgendes:

[C-2-1] Alle anderen von ihnen implementierten OpenGL ES-Erweiterungen MÜSSEN über die von OpenGL ES verwalteten APIs und nativen APIs gemeldet werden. Erweiterungsstrings, die nicht unterstützt werden, DÜRFEN NICHT gemeldet 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 Erweiterungen EGL_KHR_partial_update und OES_EGL_image_external zu unterstützen.
MÜSSEN alle unterstützten Texturkomprimierungsformate, die in der Regel anbieterspezifisch sind, korrekt über die getString()-Methode melden.

Wenn die Geräteimplementierungen die Unterstützung von OpenGL ES 3.0, 3.1 oder 3.2 angeben, gilt Folgendes:

[C-3-1] MÜSSEN zusätzlich zu den OpenGL ES 2.0-Funktionssymbolen in der libGLESv2.so-Bibliothek die entsprechenden Funktionssymbole für diese Version exportieren.
[SR] Es wird DRINGEND empfohlen, die OES_EGL_image_external_essl3-Erweiterung zu unterstützen.

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

[C-4-1] Das OpenGL ES Android Extension Pack muss vollständig unterstützt werden.

Wenn die Geräteimplementierungen das Android Extension Pack von OpenGL ES vollständig unterstützen, gilt Folgendes:

[C-5-1] Die Unterstützung muss über das android.hardware.opengles.aep-Funktionsflag angegeben werden.

Wenn Geräteimplementierungen die Unterstützung der EGL_KHR_mutable_render_buffer-Erweiterung anbieten, gilt Folgendes:

[C-6-1] MUSS auch die Erweiterung EGL_ANDROID_front_buffer_auto_refresh unterstützen.

7.1.4.2 Vulkan

Android unterstützt Vulkan, eine plattformübergreifende API mit geringem Overhead für leistungsstarke 3D-Grafiken.

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

[SR] Es wird DRINGEND empfohlen, Unterstützung für Vulkan 1.1 hinzuzufügen.

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

MÜSSEN Unterstützung für Vulkan 1.1 umfassen.

Die Vulkan-dEQP-Tests sind in mehrere Testlisten unterteilt, die jeweils mit einem Datum/einer Version verknüpft sind. 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 Stufe unterstützt, gibt an, dass es die dEQP-Tests in allen Testlisten ab dieser Stufe bestehen kann.

Wenn Geräteimplementierungen Vulkan 1.0 oder höher unterstützen, gilt Folgendes:

[C-1-1] Der korrekte Ganzzahlwert für die Feature-Flags android.hardware.vulkan.level und android.hardware.vulkan.version MUSS angegeben werden.
[C-1-2] Es MUSS mindestens eine VkPhysicalDevice für die native Vulkan-API vkEnumeratePhysicalDevices() aufgelistet werden .
[C-1-3] Die Vulkan 1.0 APIs MÜSSEN für jede aufgezählte VkPhysicalDevice vollständig implementiert sein.
[C-1-4] MUST enumerate layers, contained in native libraries named as libVkLayer*.so in the native library directory of the application package, through the Vulkan native APIs vkEnumerateInstanceLayerProperties() and vkEnumerateDeviceLayerProperties() .
[C-1-5] Es DÜRFEN KEINE Ebenen aufgelistet werden, die von Bibliotheken außerhalb des Anwendungspakets bereitgestellt werden, und es DÜRFEN KEINE anderen Möglichkeiten zum Überwachen oder Abfangen der Vulkan API bereitgestellt werden, es sei denn, das Attribut android:debuggable der Anwendung ist auf true festgelegt.
[C-1-6] MÜSSEN alle Erweiterungsstrings melden, die sie über die nativen Vulkan-APIs unterstützen, und umgekehrt MÜSSEN sie keine Erweiterungsstrings melden, die sie nicht korrekt unterstützen.
[C-1-7] MUSS die Erweiterungen VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain und VK_KHR_incremental_present unterstützen.
[C-1-8] MUSS die maximale Version der Vulkan-dEQP-Tests angeben, die über das android.software.vulkan.deqp.level-Funktionsflag unterstützt wird.
[C-1-9] MUSS mindestens Version 132317953 (ab dem 1. März 2019) unterstützen, wie im Feature-Flag android.software.vulkan.deqp.level angegeben.
[C-1-10] Alle Vulkan-dEQP-Tests in den Testlisten zwischen Version 132317953 und der im android.software.vulkan.deqp.level-Funktionsflag 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 bieten, gilt Folgendes:

[C-2-1] KEINE Vulkan-Funktions-Flags angeben (z.B. android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] Es dürfen KEINE VkPhysicalDevice für die native Vulkan-API vkEnumeratePhysicalDevices() aufgelistet werden.

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

[C-3-1] MUSS Unterstützung für die externen Semaphoren- 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 über das Manifest-Tag android:hardwareAccelerated oder direkte API-Aufrufe angeben können, dass sie die Hardwarebeschleunigung für 2D-Grafiken auf Anwendungs-, Aktivitäts-, Fenster- oder Ansichtsebene aktivieren möchten.

Geräteimplementierungen:

[C-0-1] Die Hardwarebeschleunigung MUSS standardmäßig aktiviert und MUSS deaktiviert werden, wenn der Entwickler dies anfordert, indem er „android:hardwareAccelerated=“false““ festlegt oder die Hardwarebeschleunigung direkt über die Android View APIs deaktiviert.
[C-0-2] MUSS sich gemäß der Android SDK-Dokumentation zur Hardwarebeschleunigung verhalten.

Android enthält ein TextureView-Objekt, mit dem Entwickler hardwarebeschleunigte OpenGL ES-Texturen direkt als Rendering-Ziele in eine UI-Hierarchie einbinden können.

Geräteimplementierungen:

[C-0-3] MUSS die TextureView API unterstützen und MUSS ein einheitliches Verhalten mit der Upstream-Android-Implementierung aufweisen.

7.1.4.5 Bildschirme mit breitem Farbraum

Wenn bei Geräteimplementierungen die Unterstützung von Wide-Gamut-Displays über Configuration.isScreenWideColorGamut() angegeben ist , müssen folgende Anforderungen erfüllt sein:

[C-1-1] MUSS ein farbkalibriertes Display haben.
[C-1-2] MUSS ein Display haben, dessen Farbraum den sRGB-Farbraum vollständig im CIE 1931 xyY-Farbraum abdeckt.
[C-1-3] Es MUSS ein Display haben, dessen Farbraum im CIE 1931 xyY-Farbraum eine Fläche von mindestens 90% des DCI-P3-Farbraums hat.
[C-1-4] MUSS OpenGL ES 3.1 oder 3.2 unterstützen und dies korrekt melden.
[C-1-5] Es MUSS 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 angeboten werden.
[C-SR] Es wird DRINGEND empfohlen, GL_EXT_sRGB zu unterstützen.

Wenn Geräteimplementierungen keine Wide-Gamut-Displays unterstützen, gilt Folgendes:

[C-2-1] MÜSSEN mindestens 100% des sRGB-Farbraums im CIE 1931 xyY-Farbraum abdecken, auch wenn der Farbraum des Bildschirms nicht definiert ist.

7.1.5. Modus für die Kompatibilität mit älteren Anwendungen

Android bietet einen „Kompatibilitätsmodus“, in dem das Framework mit einer „normalen“ Bildschirmgröße (320 dp Breite) arbeitet. Dieser Modus ist für ältere Anwendungen gedacht, die nicht für alte Android-Versionen entwickelt wurden, die noch keine Unabhängigkeit von der Bildschirmgröße hatten.

7.1.6. Displaytechnologie

Die Android-Plattform enthält APIs, mit denen Anwendungen hochwertige Grafiken auf einem Android-kompatiblen Display rendern können. Geräte MÜSSEN alle diese APIs gemäß der Definition im Android SDK unterstützen, sofern dies nicht ausdrücklich in diesem Dokument erlaubt ist.

Alle Android-kompatiblen Displays einer Geräteimplementierung:

[C-0-1] MUSS 16-Bit-Farbgrafiken rendern können.
SOLLTE Displays mit 24-Bit-Farbgrafik unterstützen.
[C-0-2] MUSS Animationen rendern können.
[C-0-3] Das Pixelseitenverhältnis (Pixel Aspect Ratio, PAR) muss zwischen 0,9 und 1,15 liegen. Das Pixelseitenverhä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.

Wenn Geräteimplementierungen ein externes Display entweder über eine kabelgebundene, drahtlose oder eine eingebettete zusätzliche Displayverbindung unterstützen, gilt Folgendes:

[C-1-1] Der Systemdienst und die API DisplayManager MÜSSEN wie in der Android SDK-Dokumentation beschrieben implementiert sein.

7.2. Eingabegeräte

Geräteimplementierungen:

[C-0-1] Es MUSS einen Eingabemechanismus wie einen Touchscreen oder eine Touchbedienungsfreie Navigation geben, um zwischen den UI-Elementen zu wechseln.

7.2.1. Tastatur

Wenn Geräteimplementierungen die Unterstützung von IME-Anwendungen (Eingabemethoden-Editor) von Drittanbietern umfassen, müssen sie:

[C-1-1] Das Funktions-Flag android.software.input_methods MUSS deklariert werden.
[C-1-2] MÜSSEN vollständig Input Management Framework implementiert sein
[C-1-3] Es MUSS eine vorinstallierte Softwaretastatur haben.

Geräteimplementierungen: * [C-0-1] Darf KEINE Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard angegebenen Formate entspricht (QWERTY oder 12-Tasten). * MÜSSEN zusätzliche Softkeyboard-Implementierungen enthalten. * KANN eine Hardwaretastatur enthalten.

7.2.2. Bedienung ohne Touchscreen

Android unterstützt D-Pads, Trackballs und Rollen als Mechanismen für die Bedienung ohne Touchbedienung.

Geräteimplementierungen:

[C-0-1] Es MUSS der richtige Wert für android.content.res.Configuration.navigation angegeben werden.

Wenn bei Geräteimplementierungen keine Touchbedienung verfügbar ist, sind folgende Probleme zu erwarten:

[C-1-1] Es MUSS ein angemessener alternativer Mechanismus für die Benutzeroberfläche zur Auswahl und Bearbeitung von Text vorhanden sein, der mit Eingabeverwaltungs-Engines kompatibel ist. Die Upstream-Open-Source-Implementierung von Android enthält einen Auswahlmechanismus, der für Geräte geeignet ist, die keine Eingaben für die Navigation ohne Touchbedienung haben.

7.2.3. Navigationstasten

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

[C-0-1] Es MUSS eine Nutzerfunktion zum Starten installierter Anwendungen geben, die eine Aktivität mit der <intent-filter> haben, die mit ACTION=MAIN und CATEGORY=LAUNCHER oder CATEGORY=LEANBACK_LAUNCHER für Fernsehgeräte implementiert ist. Die Startbildschirmfunktion SOLLTE der Mechanismus für diese Nutzeraffordance sein.
Es MÜSSEN Schaltflächen für die Funktionen „Letzte Apps“ und „Zurück“ vorhanden sein.

Wenn die Funktionen „Startseite“, „Letzte“ oder „Zurück“ verfügbar sind, gelten folgende Regeln:

[C-1-1] Sie MÜSSEN mit einer einzelnen Aktion (z.B. Tippen, Doppelklicken oder Wischen) zugänglich sein, wenn eine davon zugänglich ist.
[C-1-2] Es MUSS klar angegeben werden, welche einzelne Aktion jede Funktion auslösen würde. Beispiele für solche Hinweise sind ein gut sichtbares Symbol auf der Schaltfläche, ein Softwaresymbol in der Navigationsleiste auf dem Bildschirm oder eine Schritt-für-Schritt-Demo während der Ersteinrichtung.

Geräteimplementierungen:

[SR] Es wird DRINGEND empfohlen, keinen Eingabemechanismus für die Menüfunktion bereitzustellen, da diese 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 den Aktionsüberlauf MUSS angezeigt werden, wenn das Pop-up-Menü für den Aktionsüberlauf nicht leer ist und die Aktionsleiste sichtbar ist.
[C-2-2] Die Position des Pop-ups für die Aktionsleiste darf NICHT geändert werden, wenn die Schaltfläche „Overflow“ in der Aktionsleiste ausgewählt wird. Das Pop-up für die Aktionsleiste darf aber an einer anderen Position auf dem Bildschirm gerendert werden, wenn es durch Auswahl der Menüfunktion angezeigt wird.

Wenn die Geräteimplementierungen die Menüfunktion nicht bieten, müssen sie aus Gründen der Abwärtskompatibilität Folgendes tun:

[C-3-1] Die Menüfunktion muss für Anwendungen verfügbar sein, wenn targetSdkVersion < 10 ist, entweder über eine physische Taste, einen Softwareschlüssel oder Touch-Gesten. Diese Menüfunktion sollte zugänglich sein, es sei denn, sie ist zusammen mit anderen Navigationsfunktionen ausgeblendet.

Wenn Geräteimplementierungen die Hilfefunktion bieten, gilt Folgendes:

[C-4-1] Die Assistenzfunktion muss mit einer einzelnen Aktion (z.B. Tippen, Doppeltippen oder Geste) zugänglich sein, wenn andere Navigationstasten zugänglich sind.
[SR] Es wird dringend empfohlen, die Funktion „Zuhause“ durch langes Drücken auszulösen.

Wenn bei Geräteimplementierungen die Navigationstasten in einem separaten Bereich des Displays angezeigt werden, gilt Folgendes:

[C-5-1] Die Navigationstasten MÜSSEN einen eigenen Bereich des Displays belegen, der für Apps nicht verfügbar ist. Sie DÜRFEN den für Apps verfügbaren Bereich des Displays NICHT verdecken oder anderweitig beeinträchtigen.
[C-5-2] MUSS einen Teil des Displays für Anwendungen verfügbar machen, die die in Abschnitt 7.1.1 definierten Anforderungen erfüllen.
[C-5-3] Die von der App über die API-Methode View.setSystemUiVisibility() festgelegten Flags MÜSSEN berücksichtigt werden, damit dieser bestimmte Bereich des Bildschirms (auch Navigationsleiste genannt) wie im SDK dokumentiert ausgeblendet wird.

Wenn die Navigationsfunktion als eine auf dem Bildschirm angezeigte, gestenbasierte Aktion bereitgestellt wird:

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() darf NUR verwendet werden, um den Bereich für die Erkennung von Home-Gesten anzugeben.
[C-6-2] Gesten, die innerhalb eines Ausschlussbereichs beginnen, der von der App im Vordergrund über View#setSystemGestureExclusionRects() angegeben wurde, aber außerhalb von WindowInsets#getMandatorySystemGestureInsets() liegen, DÜRFEN NICHT für die Navigationsfunktion abgefangen werden, solange der Ausschlussbereich innerhalb des maximal zulässigen Ausschlussbereichs liegt, wie in der Dokumentation für View#setSystemGestureExclusionRects() angegeben.
[C-6-3] Es MUSS der App im Vordergrund ein MotionEvent.ACTION_CANCEL-Ereignis gesendet werden, sobald Touch-Gesten für eine Systemgeste abgefangen werden, wenn der App im Vordergrund zuvor ein MotionEvent.ACTION_DOWN-Ereignis gesendet wurde.
[C-6-4] Es MUSS eine Nutzerinteraktion geben, um zu einer Schaltflächennavigation auf dem Bildschirm zu wechseln (z. B. in den Einstellungen).
Die Startbildschirmfunktion sollte durch Wischen vom unteren Displayrand nach oben in der aktuellen Displayausrichtung aufgerufen werden.
Die Funktion „Letzte“ sollte durch Wischen nach oben und Halten vor dem Loslassen in derselben Region wie die Geste „Zuhause“ verfügbar sein.
Gesten, die innerhalb von WindowInsets#getMandatorySystemGestureInsets() beginnen, DÜRFEN NICHT von Ausschluss-Rechtecken beeinflusst werden, die von der App im Vordergrund über View#setSystemGestureExclusionRects() bereitgestellt werden.

Wenn eine Navigationsfunktion von überall am linken und rechten Rand des Displays in der aktuellen Ausrichtung verfügbar ist:

[C-7-1] Die Navigationsfunktion MUSS „Zurück“ sein und als Wischen vom linken und rechten Rand der aktuellen Displayausrichtung angeboten werden.
[C-7-2] Wenn benutzerdefinierte wischbare Systembereiche am linken oder rechten Rand vorhanden sind, MÜSSEN sie sich im oberen Drittel des Bildschirms befinden und eine klare, dauerhafte visuelle Kennzeichnung haben, dass durch Wischen die oben genannten Bereiche und nicht „Zurück“ aufgerufen werden. Ein Steuerfeld kann vom Nutzer so konfiguriert werden, dass es sich unterhalb des oberen Drittels des Bildschirmrands befindet. Es darf jedoch nicht länger als ein Drittel des Randes sein.
[C-7-3] Wenn für die App im Vordergrund entweder die Flags View.SYSTEM_UI_FLAG_IMMERSIVE oder View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY festgelegt sind, muss das Wischen von den Rändern so funktionieren, wie es in AOSP implementiert ist. Das ist im SDK dokumentiert.
[C-7-4] Wenn für die App im Vordergrund entweder die Flags View.SYSTEM_UI_FLAG_IMMERSIVE oder View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY festgelegt sind, MÜSSEN benutzerdefinierte wischbare Systemfelder ausgeblendet werden, bis der Nutzer die Systemleisten (Navigations- und Statusleiste) einblendet, wie in AOSP implementiert.

7.2.4. Touchscreen-Eingabe

Android unterstützt eine Vielzahl von Eingabesystemen für Zeiger, z. B. Touchscreens, Touchpads und Eingabegeräte mit Touch-Emulation. Touchscreen-basierte Geräteimplementierungen sind mit einem Display verbunden, sodass der Nutzer den Eindruck hat, Elemente direkt auf dem Bildschirm zu bearbeiten. Da der Nutzer den Bildschirm direkt berührt, sind keine zusätzlichen visuellen Hinweise erforderlich, um die manipulierten Objekte anzuzeigen.

Geräteimplementierungen:

SOLLTE eine Art Eingabesystem für den Cursor haben (entweder Maus- oder Touchbedienung).
MÜSSEN vollständig unabhängige Mauszeiger unterstützen.

Wenn Geräteimplementierungen einen Touchscreen (Einzelpunkt-Touchscreen oder besser) auf einem primären Android-kompatiblen Display haben, müssen sie:

[C-1-1] Für das API-Feld Configuration.touchscreen MUSS TOUCHSCREEN_FINGER angegeben werden.
[C-1-2] MÜSSEN die Feature-Flags android.hardware.touchscreen und android.hardware.faketouch melden.

Wenn Geräteimplementierungen einen Touchscreen haben, der mehr als eine Berührung auf einem primären Android-kompatiblen Display erfassen kann, gelten folgende Anforderungen:

[C-2-1] MÜSSEN die entsprechenden Feature-Flags android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand für den Typ des Touchscreens auf dem Gerät melden.

Wenn bei Geräteimplementierungen für die Eingabe auf einem primären Android-kompatiblen Display ein externes Eingabegerät wie eine Maus oder ein Trackball verwendet wird (d.h. das Display wird nicht direkt berührt) und die Anforderungen an gefälschte Touch-Ereignisse in Abschnitt 7.2.5 erfüllt werden, gilt Folgendes:

[C-3-1] Es dürfen KEINE Funktions-Flags gemeldet werden, die mit android.hardware.touchscreen beginnen.
[C-3-2] Es darf nur android.hardware.faketouch gemeldet werden.
[C-3-3] Für das API-Feld Configuration.touchscreen MUSS TOUCHSCREEN_NOTOUCH angegeben werden.

7.2.5. Gefälschte Eingabe per Berührung

Eine gefälschte Touch-Oberfläche bietet ein Nutzereingabesystem, das eine Teilmenge der Touchscreen-Funktionen annähernd nachahmt. Eine Maus oder Fernbedienung, die einen Cursor auf dem Bildschirm steuert, ähnelt beispielsweise dem Tippen, erfordert aber, dass der Nutzer zuerst den Cursor bewegt oder den Fokus darauf legt und dann klickt. Zahlreiche Eingabegeräte wie Maus, Touchpad, gyrobasierte Air Mouse, Gyro-Cursor, Joystick und Multi-Touch-Touchpad können gefälschte Touch-Interaktionen unterstützen. Android enthält die Funktionskonstante „android.hardware.faketouch“, die einem High-Fidelity-Eingabegerät ohne Touchbedienung (Maus oder Touchpad) entspricht, das die Touchbedienung (einschließlich grundlegender Gestenunterstützung) angemessen emulieren kann. Sie gibt an, dass das Gerät eine emulierte Teilmenge der Touchscreen-Funktionen unterstützt.

Wenn Geräteimplementierungen keinen Touchscreen, aber ein anderes Eingabesystem mit einem Zeiger enthalten, das verfügbar gemacht werden soll, müssen sie Folgendes tun:

MÜSSEN die Unterstützung für das android.hardware.faketouch-Funktions-Flag angeben.

Wenn Geräteimplementierungen die Unterstützung von android.hardware.faketouch angeben, gilt Folgendes:

[C-1-1] MÜSSEN die absoluten X- und Y-Bildschirmpositionen des Cursors melden und einen visuellen Cursor auf dem Bildschirm anzeigen.
[C-1-2] Es MUSS ein Touch-Ereignis mit dem Aktionscode gemeldet werden, der die Statusänderung angibt, die auftritt, wenn der Cursor auf dem Bildschirm nach unten oder oben bewegt wird.
[C-1-3] Es MUSS möglich sein, den Mauszeiger auf ein Objekt auf dem Bildschirm zu bewegen und dann die Maustaste nach unten oder oben zu drücken, damit Nutzer das Tippen auf ein Objekt auf dem Bildschirm emulieren können.
[C-1-4] Es MUSS möglich sein, innerhalb eines bestimmten Zeitlimits an derselben Stelle auf einem Objekt auf dem Display den Cursor nach unten, nach oben, nach unten und dann nach oben zu bewegen, damit Nutzer ein Doppeltippen auf ein Objekt auf dem Display emulieren können.
[C-1-5] MUSS das Bewegen des Mauszeigers auf einen beliebigen Punkt auf dem Bildschirm, das Bewegen des Mauszeigers zu einem beliebigen anderen Punkt auf dem Bildschirm und anschließend das Bewegen des Mauszeigers nach oben unterstützen, damit Nutzer ein Ziehen per Touch emulieren können.
[C-1-6] MUSS die Maustaste gedrückt halten unterstützen, damit Nutzer das Objekt schnell an eine andere Position auf dem Bildschirm verschieben können, und dann die Maustaste loslassen, damit Nutzer das Objekt auf dem Bildschirm wegschleudern können.

Wenn Geräteimplementierungen die Unterstützung von android.hardware.faketouch.multitouch.distinct angeben, gilt Folgendes:

[C-2-1] MUSS Unterstützung für android.hardware.faketouch angeben.
[C-2-2] MUSS das eindeutige Tracking von zwei oder mehr unabhängigen Eingaben des Touchpads unterstützen.

Wenn Geräteimplementierungen die Unterstützung von android.hardware.faketouch.multitouch.jazzhand angeben, gilt Folgendes:

[C-3-1] MÜSSEN Unterstützung für android.hardware.faketouch angeben.
[C-3-2] MUSS das unabhängige Tracking von mindestens fünf (Tracking einer Hand mit Fingern) Eingaben von Eingabegeräten unterstützen.

7.2.6. Unterstützung für Gamecontroller

7.2.6.1. Tastenbelegung

Geräteimplementierungen:

[C-1-1] MUSS HID-Ereignisse den entsprechenden InputEvent-Konstanten zuordnen können, die in den folgenden Tabellen aufgeführt sind. Die Upstream-Android-Implementierung erfüllt diese Anforderung.

Wenn in Geräteimplementierungen ein Controller eingebettet ist oder ein separater Controller im Lieferumfang enthalten ist, mit dem alle in den folgenden Tabellen aufgeführten Ereignisse eingegeben werden können, gilt Folgendes:

[C-2-1] DAS Funktions-Flag android.hardware.gamepad MUSS deklariert werden.

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)
D-Pad nach oben¹ D-Pad 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)
Linker Stick klicken¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Rechter Stick klicken¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Start¹	0x0c 0x0223	KEYCODE_HOME (3)
Zurück¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Die oben genannten HID-Nutzungen müssen in einer Gamepad-CA (0x01 0x0005) deklariert werden.

3 Dieser Messwert muss ein logisches Minimum von 0, ein logisches Maximum von 7, ein physikalisches Minimum von 0, ein physikalisches Maximum von 315, Einheiten in Grad und eine Berichtsgröße von 4 haben. Der Logikwert ist als Drehung im Uhrzeigersinn weg von der vertikalen Achse definiert. Ein Logikwert von 0 steht beispielsweise für keine Drehung und die gedrückte Aufwärtstaste, während ein Logikwert von 1 für eine Drehung von 45 Grad und die gedrückten Auf- und Linkstasten steht.

4 MotionEvent

Analoge Steuerelemente¹	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 unter Abschnitt 2.3.1.

7.3. Sensoren

Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittanbieter enthalten, MUSS die Geräteimplementierung diese API wie in der Android SDK-Dokumentation und in der Android Open Source-Dokumentation zu Sensoren beschrieben implementieren.

Geräteimplementierungen:

[C-0-1] Das Vorhandensein oder Fehlen von Sensoren muss gemäß der Klasse android.content.pm.PackageManager korrekt gemeldet werden.
[C-0-2] Es MUSS eine genaue Liste der unterstützten Sensoren über die SensorManager.getSensorList() und ähnliche Methoden zurückgegeben werden.
[C-0-3] MÜSSEN sich für alle anderen Sensor-APIs angemessen verhalten (z. B. true oder false zurückgeben, wenn Anwendungen versuchen, Listener zu registrieren, Sensor-Listener nicht aufrufen, wenn die entsprechenden Sensoren nicht vorhanden sind usw.).

Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittanbieter enthalten, gilt Folgendes:

[C-1-1] Alle Sensormessungen müssen mit den entsprechenden metrischen Werten des Internationalen Einheitensystems (SI) für jeden Sensortyp gemäß der Android SDK-Dokumentation erfasst werden.
[C-1-2] Bei einem Sensorstream mit einer maximalen angeforderten Latenz von 0 ms müssen Sensordaten mit einer maximalen Latenz von 100 Millisekunden + 2 * sample_time gemeldet werden, wenn der Anwendungsprozessor aktiv ist. Diese Verzögerung schließt keine Filterverzögerungen ein.
[C-1-3] Die erste Sensormessung MUSS innerhalb von 400 Millisekunden + 2 * „sample_time“ nach der Aktivierung des Sensors gemeldet werden. Für dieses Beispiel ist eine Genauigkeit von 0 zulässig.
[C-1-4] Bei jeder API, die in der Android SDK-Dokumentation als kontinuierlicher Sensor angegeben ist, MÜSSEN Geräteimplementierungen kontinuierliche Datenproben bereitstellen, deren Jitter UNTER 3 % liegen SOLLTE. Jitter wird als Standardabweichung der Differenz der gemeldeten Zeitstempelwerte zwischen aufeinanderfolgenden Ereignissen definiert.
[C-1-5] Der Sensorereignisstream darf die CPU des Geräts nicht daran hindern, in den Ruhemodus zu wechseln oder aus dem Ruhemodus aufzuwachen.
[C-1-6] Die Ereigniszeit muss in Nanosekunden angegeben werden, wie in der Android SDK-Dokumentation definiert. Sie entspricht dem Zeitpunkt, zu dem das Ereignis stattgefunden hat, und ist mit der SystemClock.elapsedRealtimeNano()-Uhr synchronisiert.
[C-SR] Es wird DRINGEND empfohlen, dass der Zeitstempelsynchronisierungsfehler unter 100 Millisekunden liegt. Er sollte unter 1 Millisekunde liegen.
Wenn mehrere Sensoren aktiviert sind, darf der Energieverbrauch NICHT die Summe des gemeldeten Energieverbrauchs der einzelnen Sensoren überschreiten.

Die Liste oben ist nicht vollständig. Als verbindlich gilt das dokumentierte Verhalten des Android SDK und die Android Open Source-Dokumentation zu Sensoren.

Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittanbieter enthalten, gilt Folgendes:

[C-1-6] Es MUSS eine nicht nullwertige Auflösung für alle Sensoren festgelegt werden und der Wert muss über die API-Methode Sensor.getResolution() gemeldet werden.

Einige Sensortypen sind zusammengesetzt, d. h., sie können aus Daten abgeleitet werden, die von einem oder mehreren anderen Sensoren bereitgestellt werden. Beispiele sind der Ausrichtungssensor und der lineare Beschleunigungssensor.

Geräteimplementierungen:

Diese Sensortypen sollten 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] Der Sensor muss wie in der Android Open Source-Dokumentation zu Composite-Sensoren beschrieben implementiert sein.

Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittanbieter enthalten und der Sensor nur einen Wert meldet, gelten für Geräteimplementierungen folgende Anforderungen:

[C-3-1] Die Auflösung muss für den Sensor auf „1“ gesetzt und der Wert über die API-Methode Sensor.getResolution() gemeldet werden.

Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, der SensorAdditionalInfo#TYPE_VEC3_CALIBRATION unterstützt, und der Sensor für Drittanbieter verfügbar ist, gilt Folgendes:

[C-4-1] Die bereitgestellten Daten DÜRFEN KEINE festen, werkseitig festgelegten Kalibrierungsparameter enthalten.

Wenn die Geräteimplementierungen eine Kombination aus einem 3-Achsen-Beschleunigungsmesser, einem 3-Achsen-Gyroskopsensor oder einem Magnetometersensor enthalten, sind sie:

[C-SR] Es wird dringend empfohlen, dafür zu sorgen, dass der Beschleunigungsmesser, das Gyroskop und das Magnetometer eine feste relative Position haben. Wenn das Gerät verformbar ist (z. B. faltbar), bleiben die Sensorachsen in allen möglichen Gerätetransformationszuständen ausgerichtet und mit dem Sensorkoordinatensystem übereinstimmend.

7.3.1. Beschleunigungsmesser

Geräteimplementierungen:

[C-SR] Es wird dringend empfohlen, einen 3-Achsen-Beschleunigungsmesser zu verwenden.

Wenn Geräteimplementierungen einen dreiachsigen Beschleunigungsmesser enthalten, gilt Folgendes:

[C-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 50 Hz melden können.
[C-1-2] Der Sensor TYPE_ACCELEROMETER MUSS implementiert und erfasst werden.
[C-1-3] MUSS dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben.
[C-1-4] MUSS in der Lage sein, in jeder Achse von freiem Fall bis zu viermal die Erdbeschleunigung(4 g) oder mehr zu messen.
[C-1-5] MÜSSEN eine Auflösung von mindestens 12 Bit haben.
[C-1-6] Die Standardabweichung darf maximal 0,05 m/s² betragen.Die Standardabweichung sollte pro Achse anhand von Stichproben berechnet werden, die über einen Zeitraum von mindestens 3 Sekunden mit der höchsten Abtastrate erfasst wurden.
[SR] Es wird DRINGEND empfohlen, den TYPE_SIGNIFICANT_MOTION-Kompositsensor zu implementieren.
[SR] Es wird DRINGEND empfohlen, den Sensor TYPE_ACCELEROMETER_UNCALIBRATED zu implementieren und zu erfassen. Für Android-Geräte wird dringend empfohlen, diese Anforderung zu erfüllen, damit sie auf die zukünftige Plattformversion umgestellt werden können, bei der dies möglicherweise erforderlich ist.
MÜSSEN die Kompositsensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR und TYPE_STEP_COUNTER gemäß der Beschreibung im Android SDK-Dokument implementieren.
MÜSSEN Ereignisse mit mindestens 200 Hz erfassen.
MÜSSEN eine Auflösung von mindestens 16 Bit haben.
MÜSSEN während der Nutzung kalibriert werden, wenn sich die Eigenschaften im Laufe des Lebenszyklus ändern und kompensiert werden, und die Kompensationsparameter zwischen den Neustarts des Geräts beibehalten.
SOLLTE temperaturkompensiert sein.

Wenn die 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 ihres Energieverbrauchs DARF immer unter 4 mW liegen.
MÜSSEN jeweils unter 2 mW und 0,5 mW liegen, wenn sich das Gerät in einem dynamischen oder statischen Zustand befindet.

Wenn die Geräteimplementierungen einen 3-Achsen-Beschleunigungsmesser und einen 3-Achsen-Gyroskopsensor enthalten, gilt Folgendes:

[C-3-1] Die zusammengesetzten Sensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION MÜSSEN implementiert werden.
[C-SR] Es wird DRINGEND empfohlen, den TYPE_GAME_ROTATION_VECTOR-Kompositsensor zu implementieren.

Wenn die Geräteimplementierungen einen 3-Achsen-Beschleunigungsmesser, einen 3-Achsen-Gyroskopsensor und einen Magnetometersensor enthalten, gilt Folgendes:

[C-4-1] Es MUSS ein TYPE_ROTATION_VECTOR-Kompositsensor implementiert werden.

7.3.2. Magnetometer

Geräteimplementierungen:

[C-SR] Es wird dringend empfohlen, ein 3-Achsen-Magnetometer (Kompass) einzubauen.

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

[C-1-1] Der TYPE_MAGNETIC_FIELD-Sensor MUSS implementiert sein.
[C-1-2] MÜSSEN Ereignisse mit einer Häufigkeit von mindestens 10 Hz und SOLLTEN Ereignisse mit einer Häufigkeit von mindestens 50 Hz erfassen können.
[C-1-3] MUSS dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben.
[C-1-4] MUSS in der Lage sein, zwischen -900 µT und +900 µT auf jeder Achse zu messen, bevor es zu einer Sättigung kommt.
[C-1-5] Der Wert für den harten Eisenabstand MUSS unter 700 µT liegen und SOLLTE unter 200 µT liegen, wenn der Magnetometer weit von dynamischen (strominduzierten) und statischen (magnetinduzierten) Magnetfeldern entfernt platziert wird.
[C-1-6] Die Auflösung MUSS mindestens 0,6 µT betragen.
[C-1-7] MUSS die Onlinekalibrierung und ‑kompensation der Magnetfeldabweichung unterstützen und die Kompensationsparameter zwischen den Geräteneustarts beibehalten.
[C-1-8] Die Weicheisenkompensation MUSS angewendet werden. Die Kalibrierung kann entweder während der Verwendung oder während der Herstellung des Geräts erfolgen.
[C-1-9] Die Standardabweichung, die auf der Grundlage von Stichproben berechnet wird, die über einen Zeitraum von mindestens 3 Sekunden mit der höchsten Abtastfrequenz erfasst wurden, darf pro Achse nicht größer als 1,5 µT sein. Die Standardabweichung sollte nicht größer als 0,5 µT sein.
[C-SR] Es wird DRINGEND empfohlen, den TYPE_MAGNETIC_FIELD_UNCALIBRATED-Sensor zu implementieren.

Wenn die Geräteimplementierungen einen 3-Achsen-Magnetometer, einen Beschleunigungsmesser und ein 3-Achsen-Gyroskop enthalten, haben sie folgende Vorteile:

[C-2-1] Es MUSS ein TYPE_ROTATION_VECTOR-Kompositsensor implementiert werden.

Wenn Geräteimplementierungen ein dreiachsiges Magnetometer und einen Beschleunigungsmesser enthalten, gilt Folgendes:

Der TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor kann implementiert werden.

Wenn die Geräteimplementierungen einen 3-Achsen-Magnetometer, einen Beschleunigungsmesser und einen TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor enthalten, haben sie folgende Vorteile:

[C-3-1] Der Energieverbrauch DARF nicht über 10 mW liegen.
Der Energieverbrauch sollte unter 3 mW liegen, 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 anzugeben.

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

[C-1-1] MÜSSEN Standortausgaben mit einer Rate von mindestens 1 Hz unterstützen, wenn sie über LocationManager#requestLocationUpdate angefordert werden.
[C-1-2] MÜSSEN in einer offenen Umgebung (starke Signale, vernachlässigbare Mehrwegeausbreitung, HDOP < 2) innerhalb von 10 Sekunden (schnelle Zeit bis zur ersten Fixierung) den Standort bestimmen können, wenn sie mit einer Internetverbindung mit einer Datenübertragungsrate von mindestens 0,5 Mbit/s verbunden sind. Diese Anforderung wird in der Regel durch die Verwendung einer Form von unterstütztem oder prognostiziertem GPS/GNSS-Verfahren erfüllt, um die GPS/GNSS-Anlaufzeit zu minimieren. Zu den Hilfsdaten gehören Referenzzeit, Referenzstandort und Satellitenephemeris/-uhr.
- [C-1-6] Nach einer solchen Standortberechnung MÜSSEN Geräteimplementierungen ihren Standort unter freiem Himmel innerhalb von 5 Sekunden bestimmen, wenn Standortanfragen neu gestartet werden, bis zu einer Stunde nach der ersten Standortberechnung, auch wenn die nachfolgende Anfrage ohne Datenverbindung und/oder nach einem Neustart erfolgt.
Bei freiem Himmel nach der Standortbestimmung, wenn Sie stehen oder sich mit weniger als 1 Meter pro Sekunde² bewegen:
- [C-1-3] MUSS in mindestens 95% der Fälle den Standort innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0,5 Metern pro Sekunde bestimmen können.
- [C-1-4] MUSS mindestens acht Satelliten aus einer Konstellation gleichzeitig über GnssStatus.Callback verfolgen und melden.
- MÜSSEN mindestens 24 Satelliten aus mehreren Konstellationen gleichzeitig verfolgen können (z.B. GPS + mindestens eine von Glonass, Beidou, Galileo).
- [C-SR] Es wird DRINGEND empfohlen, während eines Notanrufs weiterhin normale GPS-/GNSS-Standortausgaben über die GNSS Location Provider API zu senden.
- [C-SR] Es wird DRINGEND empfohlen, GNSS-Messungen von allen erfassten Konstellationen (wie in GnssStatus-Nachrichten angegeben) zu melden, mit Ausnahme von SBAS.
- [C-SR] Es wird DRINGEND empfohlen, AGC und die Häufigkeit der GNSS-Messung zu erfassen.
- [C-SR] Es wird DRINGEND empfohlen, alle Genauigkeitsschätzungen (einschließlich Richtung, Geschwindigkeit und Vertikale) als Teil jedes GPS-/GNSS-Standorts anzugeben.
- [C-SR] Es wird DRINGEND empfohlen, GNSS-Messungen zu melden, sobald sie gefunden werden, auch wenn ein aus GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
- [C-SR] Es wird DRINGEND empfohlen, GNSS-Pseudostrecken und Pseudostreckenraten zu melden, die bei freiem Blick nach der Standortbestimmung, bei Stillstand oder bei einer Beschleunigung von weniger als 0, 2 Metern pro Sekunde zum Quadrat ausreichen, um mindestens 95% der Zeit 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 hinzuzufügen.

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] Sie MÜSSEN den TYPE_GYROSCOPE-Sensor implementieren und es wird DRINGEND empfohlen, auch den TYPE_GYROSCOPE_UNCALIBRATED-Sensor zu implementieren.
[C-1-4] Die Auflösung MUSS mindestens 12 Bit betragen und SOLLTE mindestens 16 Bit betragen.
[C-1-5] MUSS temperaturkompensiert sein.
[C-1-6] MÜSSEN während der Verwendung kalibriert und kompensiert werden und die Kompensationsparameter zwischen den Neustarts des Geräts beibehalten.
[C-1-7] Die Abweichung darf maximal 1 · 10−7 rad² / s² pro Hz betragen (Abweichung pro Hz oder rad² / s). Die Abweichung darf mit der Abtastrate variieren, muss aber auf diesen Wert beschränkt sein. Mit anderen Worten: Wenn Sie die Varianz des Gyroskops bei einer Abtastrate von 1 Hz messen, sollte sie nicht größer als 1 E-7 rad²/s² sein.
[SR] Der Kalibrierungsfehler sollte bei einem ruhenden Gerät bei Raumtemperatur UNTER 0,01 rad/s liegen.
MÜSSEN Ereignisse mit mindestens 200 Hz erfassen.

Wenn die Geräteimplementierungen ein 3-Achsen-Gyroskop, einen Beschleunigungsmesser und einen Magnetometersensor enthalten, gilt Folgendes:

[C-2-1] Es MUSS ein TYPE_ROTATION_VECTOR-Kompositsensor implementiert werden.

Wenn die Geräteimplementierungen einen 3-Achsen-Beschleunigungsmesser und einen 3-Achsen-Gyroskopsensor enthalten, gilt Folgendes:

[C-3-1] Die zusammengesetzten Sensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION MÜSSEN implementiert werden.
[C-SR] Es wird DRINGEND empfohlen, den TYPE_GAME_ROTATION_VECTOR-Kompositsensor zu implementieren.

7.3.5. Barometer

Geräteimplementierungen:

[C-SR] Es wird dringend empfohlen, ein Barometer (Umgebungsluftdrucksensor) einzubauen.

Wenn Geräteimplementierungen ein Barometer enthalten, gilt Folgendes:

[C-1-1] Der TYPE_PRESSURE-Sensor MUSS implementiert und erfasst werden.
[C-1-2] MUSS Ereignisse mit mindestens 5 Hz senden können.
[C-1-3] MUSS temperaturkompensiert sein.
[SR] Es wird dringend empfohlen, Druckmessungen im Bereich von 300 hPa bis 1.100 hPa erfassen zu können.
MÜSSEN 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 bei einer Änderung von etwa 200 m über dem Meeresspiegel).

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-/Fahrzeuginnenraumtemperatur) an dem Ort messen, an dem der Nutzer mit dem Gerät interagiert, in Grad Celsius.

Wenn Geräteimplementierungen einen Thermometersensor enthalten, der eine andere Temperatur als die Umgebungstemperatur misst, z. B. die CPU-Temperatur, gilt Folgendes:

[C-2-1] SENSOR_TYPE_AMBIENT_TEMPERATURE darf NICHT für den Temperatursensor definiert werden.

7.3.7. Fotometer

Geräteimplementierungen KÖNNEN einen Photometer (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] Die Nähe eines Objekts MUSS in derselben Richtung wie das Display gemessen werden. Der Näherungssensor MUSS so ausgerichtet sein, dass er Objekte in der Nähe des Displays erkennt, da dieser Sensortyp in erster Linie dazu dient, ein vom Nutzer verwendetes Smartphone zu erkennen. Wenn Geräteimplementierungen einen Näherungssensor mit einer anderen Ausrichtung enthalten, darf dieser NICHT über diese API zugänglich sein.
[C-1-2] MÜSSEN eine Genauigkeit von mindestens 1 Bit haben.

7.3.9. Hochpräzise Sensoren

Wenn Geräteimplementierungen eine Reihe von Sensoren mit höherer Qualität wie in diesem Abschnitt definiert enthalten und diese für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

[C-1-1] Die Funktion MUSS über das Feature-Flag android.hardware.sensor.hifi_sensors angegeben werden.

Wenn Geräteimplementierungen android.hardware.sensor.hifi_sensors angeben, gilt Folgendes:

[C-2-1] MUSS einen TYPE_ACCELEROMETER-Sensor haben, der:
- Der Messbereich muss mindestens -8 g bis +8 g betragen. Wir empfehlen einen Messbereich von mindestens -16 g bis +16 g.
- Die Messauflösung muss mindestens 2.048 LSB/g betragen.
- Die Mindestmessungsfrequenz muss 12,5 Hz oder niedriger sein.
- MÜSSEN eine maximale Messfrequenz von mindestens 400 Hz haben; SOLLTEN den SensorDirectChannel RATE_VERY_FAST unterstützen.
- Der Messrauschen darf maximal 400 μg/√Hz betragen.
- Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 3.000 Sensorereignissen implementiert werden.
- Der Batch-Stromverbrauch darf maximal 3 mW betragen.
- [C-SR] Es wird DRINGEND empfohlen, eine 3-dB-Messbandbreite von mindestens 80% der Nyquist-Frequenz und ein Weißrauschenspektrum innerhalb dieser Bandbreite zu verwenden.
- MÜSSEN einen Zufallspfad der Beschleunigung von weniger als 30 μg √Hz bei Raumtemperatur haben.
- Die Vorabweichung sollte bei Temperaturänderungen ≤ ± 1 mg/°C betragen.
- Die Nichtlinearität der Bestfit-Linie sollte ≤ 0,5 % und die Empfindlichkeitsänderung bei Temperaturschwankungen ≤ 0,03%/°C betragen.
- MÜSSEN eine Sensitivität über die Achsen von weniger als 2,5 % und eine Abweichung der Sensitivität über die Achsen von weniger als 0,2% im Betriebstemperaturbereich des Geräts haben.
[C-2-2] Es MUSS ein TYPE_ACCELEROMETER_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_ACCELEROMETER geben.
[C-2-3] MUSS einen TYPE_GYROSCOPE-Sensor haben, der:
- Der Messbereich muss mindestens -1.000 und +1.000 dps betragen.
- MÜSSEN eine Messauflösung von mindestens 16 LSB/dps haben.
- Die Mindestmessungsfrequenz muss 12,5 Hz oder niedriger sein.
- MÜSSEN eine maximale Messfrequenz von 400 Hz oder höher haben; SOLLTEN den SensorDirectChannel RATE_VERY_FAST unterstützen.
- Der Messrauschen darf maximal 0,014 °/s/√Hz betragen.
- [C-SR] Es wird DRINGEND empfohlen, eine 3-dB-Messbandbreite von mindestens 80% der Nyquist-Frequenz und ein Weißrauschenspektrum innerhalb dieser Bandbreite zu verwenden.
- Die Rate des zufälligen Ausschlags sollte bei Raumtemperatur unter 0,001 °/s √Hz liegen.
- Die Vorabweichung sollte bei Temperaturänderungen ≤ ± 0,05 °/ s / °C betragen.
- Die Empfindlichkeit sollte sich bei Temperaturänderungen um maximal 0,02 % pro °C ändern.
- Die Nichtlinearität der Ausgleichsgerade sollte ≤ 0,2 % betragen.
- MÜSSEN eine Rauschdichte von ≤ 0,007 °/s/√Hz haben.
- Der Kalibrierungsfehler sollte bei einer Temperatur von 10 bis 40 °C unter 0,002 rad/s liegen, wenn sich das Gerät nicht bewegt.
- Die G-Empfindlichkeit sollte unter 0,1 °/s/g liegen.
- MÜSSEN eine Achsenkreuzempfindlichkeit von weniger als 4,0 % und eine Achsenkreuzempfindlichkeitsabweichung von weniger als 0,3% im Betriebstemperaturbereich des Geräts haben.
[C-2-4] TYPE_GYROSCOPE_UNCALIBRATED MUSS dieselben Qualitätsanforderungen wie TYPE_GYROSCOPE erfüllen.
[C-2-5] MUSS einen TYPE_GEOMAGNETIC_FIELD-Sensor haben, der:
- Der Messbereich muss mindestens -900 und +900 μT betragen.
- Die Messauflösung muss mindestens 5 LSB/uT betragen.
- Die Mindestmessungsfrequenz muss 5 Hz oder weniger betragen.
- Die maximale Messfrequenz muss mindestens 50 Hz betragen.
- Der Messrauschen darf maximal 0,5 µT betragen.
[C-2-6] Es MUSS eine TYPE_MAGNETIC_FIELD_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_GEOMAGNETIC_FIELD geben. Außerdem gilt Folgendes:
- Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 600 Sensorereignissen implementiert werden.
- [C-SR] Es wird DRINGEND empfohlen, ein Weißrauschenspektrum von 1 Hz bis mindestens 10 Hz zu verwenden, wenn die Berichtsrate 50 Hz oder höher ist.
[C-2-7] MUSS einen TYPE_PRESSURE-Sensor haben, der:
- Der Messbereich muss mindestens 300 bis 1.100 hPa betragen.
- MÜSSEN eine Messauflösung von mindestens 80 LSB/hPa haben.
- Die Mindestmessungsfrequenz muss 1 Hz oder weniger betragen.
- Die maximale Messfrequenz muss mindestens 10 Hz betragen.
- Der Messrauschen darf maximal 2 Pa/√Hz betragen.
- Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 300 Sensorereignissen implementiert werden.
- Der Batch-Stromverbrauch darf maximal 2 mW betragen.
[C-2-8] MUSS einen TYPE_GAME_ROTATION_VECTOR-Sensor haben.
[C-2-9] MUSS einen TYPE_SIGNIFICANT_MOTION-Sensor haben, der:
- Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
[C-2-10] MUSS einen TYPE_STEP_DETECTOR-Sensor haben, der:
- Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 100 Sensorereignissen implementiert werden.
- Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
- Der Batch-Stromverbrauch darf maximal 4 mW betragen.
[C-2-11] MUSS einen TYPE_STEP_COUNTER-Sensor haben, der:
- Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
[C-2-12] MUSS einen TILT_DETECTOR-Sensor haben, der:
- Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
[C-2-13] Der Zeitstempel desselben physischen Ereignisses, der vom Beschleunigungsmesser, Gyroskop und Magnetometer erfasst wird, DARF maximal 2,5 Millisekunden voneinander abweichen. Der Zeitstempel des Ereignisses für dasselbe physische Ereignis, das vom Beschleunigungsmesser und Gyroskop erfasst wird, sollte innerhalb von 0,25 Millisekunden voneinander abweichen.
[C-2-14] Die Zeitstempel der Gyroskopsensore MÜSSEN auf derselben Zeitbasis wie das Kamera-Subsystem liegen und dürfen maximal 1 Millisekunde vom Wert des Kamera-Subsystems abweichen.
[C-2-15] Die Samples MÜSSEN innerhalb von 5 Millisekunden an die Anwendungen gesendet werden, nachdem die Daten auf einem der oben genannten physischen Sensoren für die Anwendung verfügbar sind.
[C-2-16] Die Leistungsaufnahme darf bei inaktivem Gerät nicht mehr als 0,5 mW und bei in Bewegung befindlichem Gerät nicht mehr als 2,0 mW betragen, 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] KANN einen TYPE_PROXIMITY-Sensor haben, muss aber einen Mindestpuffer von 100 Sensorereignissen haben.

Hinweis: Alle in diesem Abschnitt aufgeführten Anforderungen an den Stromverbrauch umfassen nicht den Stromverbrauch des Anwendungsprozessors. Sie umfasst den Stromverbrauch der gesamten Sensorkette – des Sensors, aller unterstützenden Schaltkreise und aller speziellen Sensorverarbeitungssysteme usw.

Wenn Geräteimplementierungen die direkte Sensorunterstützung umfassen, gilt Folgendes:

[C-3-1] Die Unterstützung von direkten Kanaltypen und Berichtsraten für direkte Channels muss über die isDirectChannelTypeSupported- und getHighestDirectReportRateLevel-API korrekt deklariert werden.
[C-3-2] Es MUSS mindestens einer der beiden Kanaltypen für den direkten Sensor unterstützt werden, für alle Sensoren, die die Unterstützung für den direkten Sensorkanal angeben.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
MÜSSEN Ereignisberichte über den direkten Sensorkanal für den primären Sensor (ohne Weckvariante) 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 biometrischer Entsperrung finden Sie in der Dokumentation zum Messen der biometrischen Sicherheit.

Wenn die Geräteimplementierungen einen sicheren Sperrbildschirm enthalten, gilt Folgendes:

SOLLTE einen biometrischen Sensor enthalten

Biometrische Sensoren können je nach Akzeptanzrate von Spoofing und Identitätsdiebstahl sowie je nach Sicherheit der biometrischen Pipeline als Klasse 3 (früher Hoch), Klasse 2 (früher Niedrig) oder Klasse 1 (früher Nutzerfreundlichkeit) eingestuft werden. Diese Klassifizierung bestimmt die Funktionen, die der biometrische Sensor für die Kommunikation mit der Plattform und Drittanbieteranwendungen haben muss. Sensoren werden standardmäßig als Klasse 1 eingestuft. Sie müssen die unten aufgeführten zusätzlichen Anforderungen erfüllen, um als Klasse 2 oder Klasse 3 eingestuft zu werden. Sowohl Klasse 2 als auch Klasse 3 erhalten zusätzliche Funktionen, die unten beschrieben werden.

Wenn Geräteimplementierungen einen biometrischen Sensor über android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt und android.provider.Settings.ACTION_BIOMETRIC_ENROLL für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

[C-4-1] MUSS die Anforderungen für biometrische Verfahren der Klasse 3 oder Klasse 2 erfüllen, wie in diesem Dokument definiert.
[C-4-2] MUSS jeden Parameternamen erkennen und berücksichtigen, der in der Klasse Authenticators als Konstante definiert ist, sowie alle Kombinationen davon. Andererseits dürfen an die Methoden canAuthenticate(int) und setAllowedAuthenticators(int) nur Ganzzahlkonstanten übergeben werden, die als öffentliche Konstanten in Authenticators dokumentiert sind, und keine Kombinationen davon.
[C-4-3] Die Aktion ACTION_BIOMETRIC_ENROLL MUSS auf Geräten mit biometrischen Funktionen der Klasse 3 oder Klasse 2 implementiert werden. Bei dieser Aktion MÜSSEN nur die Anmeldepunkte für biometrische Verfahren der Klasse 3 oder Klasse 2 angezeigt werden.

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

[C-5-1] Es MUSS standardmäßig ein zusätzlicher Bestätigungsschritt erforderlich sein (z.B. das Drücken einer Schaltfläche).
[C-SR] Es wird DRINGEND empfohlen, eine Einstellung zu haben, mit der Nutzer die Anwendungseinstellungen überschreiben können und immer einen Bestätigungsschritt erfordern.
[C-SR] Es wird DRINGEND empfohlen, die Bestätigungsaktion so zu sichern, dass sie nicht durch eine Manipulation des Betriebssystems oder des Kernels gefälscht werden kann. Das bedeutet beispielsweise, dass die Bestätigungsaktion, die auf einer physischen Taste basiert, über einen GPIO-Pin (General Purpose Input/Output) eines Secure Elements (SE) mit nur Eingabefunktion geleitet wird, der nur durch Drücken einer physischen Taste betätigt werden kann.
[C-5-2] Es MUSS zusätzlich ein impliziter Authentifizierungsablauf (ohne Bestätigungsschritt) implementiert werden, der setConfirmationRequired(boolean) entspricht und von Anwendungen für Anmeldeabläufe verwendet werden kann.

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

[C-SR] Es wird DRINGEND empfohlen, pro Authentifizierung nur eine biometrische Bestätigung zu verlangen. Wenn z. B. sowohl ein Fingerabdruck- als auch ein Gesichtssensor auf dem Gerät verfügbar sind, sollte onAuthenticationSucceeded gesendet werden, nachdem einer von beiden bestätigt wurde.

Damit Geräteimplementierungen Drittanbieter-Apps den Zugriff auf Schlüsselspeicherschlüssel gewähren können, müssen sie:

[C-6-1] MÜSSEN die Anforderungen für Klasse 3 erfüllen, wie in diesem Abschnitt unten definiert.
[C-6-2] Es DÜRFEN nur biometrische Daten der Klasse 3 verwendet werden, wenn für die Authentifizierung BIOMETRIC_STRONG erforderlich ist oder die Authentifizierung mit einem CryptoObject aufgerufen wird.

Wenn bei der Geräteimplementierung ein biometrischer Sensor als Klasse 1 (früher Nutzerfreundlichkeit) behandelt werden soll, müssen folgende Anforderungen erfüllt sein:

[C-1-1] Die Falsch-Akzeptanzrate DARF nicht über 0,002 % liegen.
[C-1-2] Es MUSS offengelegt werden, dass dieser Modus möglicherweise weniger sicher ist als eine starke PIN, ein starkes Muster oder ein starkes Passwort. Außerdem müssen die Risiken der Aktivierung klar aufgelistet werden, wenn die Akzeptanzraten für Spoofing und Identitätsdiebstahl gemäß den Android-Biometrie-Testprotokollen über 7% liegen.
[C-1-3] Nach fünf fehlgeschlagenen Versuchen der biometrischen Bestätigung MUSS die Rate der Versuche für mindestens 30 Sekunden begrenzt werden. Ein fehlgeschlagener Versuch ist ein Versuch mit einer ausreichenden Aufnahmequalitä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 zuerst eine Vertrauenskette zu erstellen, indem der Nutzer vorhandene Anmeldedaten (PIN/Muster/Passwort) bestätigt oder neue Anmeldedaten für das Gerät hinzufügt, die durch die TEE gesichert sind. Die Implementierung des Android Open Source Project bietet den Mechanismus im Framework dafür.
[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] Es MUSS das individuelle Flag für dieses biometrische Verfahren berücksichtigt werden (d.h. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE oder DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] Auf neuen Geräten mit Android 10 muss der Nutzer mindestens alle 24 Stunden zur empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden. Auf Geräten, die von einer älteren Android-Version umgestellt werden, muss der Nutzer mindestens alle 72 Stunden zur empfohlenen primären Authentifizierung aufgefordert werden.
[C-1-8] Der Nutzer MUSS nach einem der folgenden Ereignisse zur empfohlenen primären Authentifizierung aufgefordert werden (z. B. PIN, Muster, Passwort):
- ein Zeitlimit von 4 Stunden für die Inaktivität ODER
- 3 fehlgeschlagene biometrische Authentifizierungsversuche.
- Die Zeitüberschreitung bei Inaktivität und die Anzahl der fehlgeschlagenen Authentifizierungen werden nach jeder erfolgreichen Bestätigung der Geräteanmeldedaten zurückgesetzt.
Upgrades von Geräten von einer früheren Android-Version können 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 durchzusetzen. * [C-SR] Es wird DRINGEND empfohlen, dass die Falsch-Ablehnungsrate auf dem Gerät unter 10 % liegt. * [C-SR] Es wird dringend empfohlen, für jede registrierte biometrische Entsperrung eine Latenz von weniger als einer Sekunde zu haben, gemessen vom Zeitpunkt der Erkennung der biometrischen Daten bis zur Entsperrung des Displays.

Wenn bei Geräteimplementierungen ein biometrischer Sensor als Klasse 2 (früher Schwach) behandelt werden soll, müssen folgende Anforderungen erfüllt sein:

[C-2-1] MÜSSEN alle Anforderungen für Klasse 1 oben erfüllen.
[C-2-2] Die Akzeptanzrate von Spoofing und Identitätsdiebstahl darf gemäß den Android-Biometrie-Testprotokollen nicht über 20% liegen.
[C-2-3] Der biometrische Abgleich MUSS in einer isolierten Ausführungsumgebung außerhalb des Android-Nutzer- oder Kernel-Bereichs 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 sein, sodass sie nicht außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal zur isolierten Ausführungsumgebung abgerufen, gelesen oder geändert werden können, wie in den Implementierungsrichtlinien auf der Website des Android Open Source Project beschrieben.
[C-2-5] Bei kamerabasierter Biometrie während der biometrischen Authentifizierung oder Registrierung:
- Die Kamera MUSS in einem Modus betrieben werden, der verhindert, dass Kameraframes außerhalb der abgeschotteten Ausführungsumgebung gelesen oder geändert werden. Alternativ kann ein Chip mit einem sicheren Kanal zur abgeschotteten Ausführungsumgebung verwendet werden.
- Bei RGB-Einzelkameralösungen können die Kameraframes außerhalb der isolierten Ausführungsumgebung gelesen werden, um Vorgänge wie die Vorschau für die Registrierung zu unterstützen. Sie dürfen jedoch NICHT verändert werden.
[C-2-6] Drittanbieter-Apps DÜRFEN NICHT zwischen einzelnen biometrischen Registrierungen unterscheiden.
[C-2-7] Der Anwendungsprozessor darf außerhalb des Kontexts der TEE KEIN unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder abgeleitete Daten (z. B. Einbettungen) erhalten.
[C-2-8] Es MUSS eine sichere Verarbeitungspipeline geben, damit bei einer Manipulation des Betriebssystems oder Kernels keine Daten direkt eingefügt werden können, um sich 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 Systemsoftwareupdate erfüllt werden kann, können sie von der Anforderung AUSGESCHLOSSEN WERDEN.
[C-SR] Es wird DRINGEND empfohlen, die Echtheitsprüfung für alle biometrischen Modalitäten und die Aufmerksamkeitserkennung für die Gesichtserkennung einzubinden.

Wenn bei Geräteimplementierungen ein biometrischer Sensor als Klasse 3 (früher Hoch) behandelt werden soll, müssen folgende Anforderungen erfüllt sein:

[C-3-1] MUSS alle Anforderungen von Klasse 2 oben erfüllen, mit Ausnahme von [C-1-7] und [C-1-8]. Upgrades von Geräten von einer früheren Android-Version sind von C-2-7 nicht ausgenommen.
[C-3-2] Es MUSS eine hardwaregestützte Schlüsselspeicherimplementierung geben.
[C-3-3] Die Akzeptanzrate von Spoofing und Identitätsdiebstahl darf gemäß den Android-Biometrie-Testprotokollen nicht über 7% liegen.
[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. Positionssensor

Geräteimplementierungen:

Es wird unter Umständen ein Positionssensor mit 6 Freiheitsgraden unterstützt.

Wenn Geräteimplementierungen einen 6-Achsen-Pose-Sensor unterstützen, gilt Folgendes:

[C-1-1] Der Sensor TYPE_POSE_6DOF MUSS implementiert und erfasst werden.
[C-1-2] MÜSSEN genauer sein als der Drehvektor allein.

7.3.13. Scharnierwinkelsensor

Wenn die Geräteimplementierung einen Scharnierwinkelsensor unterstützt, gilt Folgendes:

[C-1-1] TYPE_HINGLE_ANGLE MUSS implementiert und gemeldet werden.
[C-1-2] MUSS mindestens zwei Messwerte zwischen 0 und 360 Grad unterstützen (einschließlich 0 und 360 Grad).
[C-1-3] Es MUSS ein Weck-Sensor für getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) zurückgegeben werden.

7.4. Datenverbindung

7.4.1. Telefonie

„Telefonie“ bezieht sich in den Android APIs und in diesem Dokument speziell auf Hardware, die für das Tätigen von Sprachanrufen und das Senden von SMS über ein GSM- oder CDMA-Netzwerk verwendet wird. Diese Sprachanrufe können paketvermittelt sein oder nicht, werden aber für Android unabhängig von jeglicher Datenverbindung betrachtet, die über dasselbe Netzwerk implementiert werden kann. Mit anderen Worten: Die Android-Funktionen und APIs für die „Telefonie“ beziehen sich speziell auf Sprachanrufe und SMS. Geräteimplementierungen, mit denen keine Anrufe getätigt oder SMS gesendet und 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 Telefoniehardware enthalten. Android ist also mit Geräten kompatibel, die keine Smartphones sind.

Wenn die Geräteimplementierungen GSM- oder CDMA-Telefonie umfassen, gilt Folgendes:

[C-1-1] Das android.hardware.telephony-Funktionsflag und andere Unterfunktionsflags MÜSSEN gemäß der Technologie deklariert werden.
[C-1-2] Es MUSS eine vollständige Unterstützung der API für diese Technologie implementiert werden.

Wenn Geräteimplementierungen keine Telefoniehardware enthalten, gelten folgende Anforderungen:

[C-2-1] Die APIs MÜSSEN vollständig als No-Ops implementiert werden.

Wenn Geräteimplementierungen eUICCs oder eSIMs/eingebettete SIMs unterstützen und einen proprietären Mechanismus enthalten, um die eSIM-Funktion für Drittanbieter zu ermöglichen, müssen sie:

[C-3-1] Es MUSS eine vollständige Implementierung der EuiccManager API enthalten.

7.4.1.1. Kompatibilität mit der Nummernblockierung

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

[C-1-1] MUSS die Blockierung von Nummern unterstützen
[C-1-2] BlockedNumberContract und die entsprechende API MÜSSEN vollständig gemäß der SDK-Dokumentation implementiert werden.
[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 Blockierung von Nummern wie in der SDK-Dokumentation beschrieben vorübergehend aufgehoben wird.
[C-1-4] Darf bei einem blockierten Anruf NICHT an den Anruflistenanbieter der Plattform schreiben.
[C-1-5] Darf nicht an den Telefonieanbieter wegen einer blockierten Nachricht schreiben.
[C-1-6] Es MUSS eine Benutzeroberfläche zum Verwalten blockierter Nummern implementiert werden, die mit dem Intent geöffnet wird, der von der Methode TelecomManager.createManageBlockedNumbersIntent() zurückgegeben wird.
[C-1-7] Sekundäre Nutzer dürfen die blockierten Nummern auf dem Gerät NICHT ansehen oder bearbeiten, da die Android-Plattform davon ausgeht, dass der Hauptnutzer die vollständige Kontrolle über die Telefondienste (eine einzelne Instanz) auf dem Gerät hat. Alle blockierungsbezogenen Benutzeroberflächen MÜSSEN für sekundäre Nutzer ausgeblendet sein und die Blockierungsliste MÜSSEN weiterhin berücksichtigt werden.
Die blockierten Nummern MÜSSEN zum Anbieter migriert werden, wenn ein Gerät auf Android 7.0 aktualisiert wird.

7.4.1.2. Telecom API

Wenn für Geräteimplementierungen android.hardware.telephony gemeldet wird, gilt Folgendes:

[C-1-1] MÜSSEN die im SDK beschriebenen ConnectionService APIs unterstützen.
[C-1-2] Es MUSS ein neuer eingehender Anruf angezeigt werden und der Nutzer muss die Möglichkeit haben, den Anruf anzunehmen oder abzulehnen, wenn er sich in einem laufenden Anruf befindet, der über eine Drittanbieter-App gestartet wurde, die die über CAPABILITY_SUPPORT_HOLD angegebene Funktion „Anruf pausieren“ nicht unterstützt.
[C-1-3] Es MUSS eine Anwendung geben, die InCallService implementiert.
[C-SR] Es wird 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 Benachrichtigung, die den Nutzer darüber informiert, dass der andere Anruf beendet wird, wenn er einen eingehenden Anruf annimmt.
[C-SR] Es wird DRINGEND empfohlen, die Standard-Anruf-App vorab zu laden, die einen Anrufprotokolleintrag und den Namen einer Drittanbieter-App im Anrufprotokoll anzeigt, wenn die Drittanbieter-App den Extraschlüssel EXTRA_LOG_SELF_MANAGED_CALLS in ihrer PhoneAccount auf true festlegt.
[C-SR] Es wird DRINGEND empfohlen, die Ereignisse KEYCODE_MEDIA_PLAY_PAUSE und KEYCODE_HEADSETHOOK des Audio-Headsets für die android.telecom APIs wie unten beschrieben zu verarbeiten:
- Ruft Connection.onDisconnect() auf, wenn während eines laufenden Anrufs eine kurze Betätigung des Schlüsselereignisses erkannt wird.
- Ruft Connection.onAnswer() auf, wenn während eines eingehenden Anrufs eine kurze Betätigung des Schlüsselereignisses erkannt wird.
- Ruft Connection.onReject() auf, wenn während eines eingehenden Anrufs das Schlüsselereignis lange gedrückt wird.
- Aktivieren oder deaktivieren Sie die Stummschaltung der CallAudioState.

7.4.2. IEEE 802.11 (Wi‑Fi)

Geräteimplementierungen:

MÜSSEN eine oder mehrere Formen von 802.11 unterstützen.

Wenn Geräteimplementierungen 802.11 unterstützen und die Funktion für eine Drittanbieteranwendung freigeben, gelten folgende Anforderungen:

[C-1-1] Die entsprechende Android API MUSS implementiert werden.
[C-1-2] Das Hardware-Funktions-Flag android.hardware.wifi MUSS gemeldet werden.
[C-1-3] Die Multicast API muss wie in der SDK-Dokumentation beschrieben implementiert sein.
[C-1-4] MUSS Multicast-DNS (mDNS) unterstützen und darf mDNS-Pakete (224.0.0.251) zu keinem Zeitpunkt filtern, einschließlich:
- Auch wenn der Bildschirm nicht aktiv ist.
- Bei Android TV-Geräten auch im Standby-Modus.
[C-1-5] Der API-Methodenaufruf WifiManager.enableNetwork() darf NICHT als ausreichender Hinweis zum Wechseln des aktuell aktiven Network behandelt werden, der standardmäßig für den Anwendungstraffic verwendet und von ConnectivityManager API-Methoden wie getActiveNetwork und registerDefaultNetworkCallback zurückgegeben wird. Mit anderen Worten: Sie KÖNNEN den Internetzugriff eines anderen Netzwerkanbieters (z.B. Mobilfunkdaten) nur dann deaktivieren, wenn sie bestätigt haben, dass das WLAN-Netzwerk Internetzugriff bietet.
[C-1-6] Es wird DRINGEND empfohlen, den Internetzugriff auf dem Network noch einmal zu prüfen, wenn die ConnectivityManager.reportNetworkConnectivity() API-Methode aufgerufen wird. Sobald die Prüfung ergeben hat, dass der aktuelle Network keinen Internetzugriff mehr bietet, wechseln Sie zu einem anderen verfügbaren Netzwerk (z. B. mobile Daten), das Internetzugriff bietet.
[C-SR] Es wird DRINGEND empfohlen, die MAC-Quelladresse und die Sequenznummer der Prüfanfrageframes einmal zu Beginn jedes Scans zufällig zu generieren, während die STA getrennt ist.
- Jede Gruppe von Probe-Anfrageframes, die einen Scan umfasst, sollte eine einheitliche MAC-Adresse verwenden. Die MAC-Adresse darf nicht in der Mitte eines Scans zufällig generiert werden.
- Die Sequenznummer der Probeanfrage sollte wie gewohnt (sequentiell) zwischen den Probeanfragen in einem Scan iterieren.
- Die Sequenznummer der Prüfanfrage sollte zwischen der letzten Prüfanfrage eines Scans und der ersten Prüfanfrage des nächsten Scans zufällig generiert werden.
[C-SR] Es wird DRINGEND empfohlen, während die STA getrennt ist, nur die folgenden Elemente in Probe-Anfrageframes zuzulassen:
- SSID-Parametersatz (0)
- DS-Parametersatz (3)

Wenn die Geräteimplementierungen den im IEEE 802.11-Standard definierten Energiesparmodus für WLAN unterstützen, gilt Folgendes:

[C-3-1] Der Energiesparmodus für WLAN MUSS deaktiviert werden, wenn eine App über die APIs WifiManager.createWifiLock() und WifiManager.WifiLock.acquire() die Sperre WIFI_MODE_FULL_HIGH_PERF oder WIFI_MODE_FULL_LOW_LATENCY erwirkt und die Sperre aktiv ist.
[C-3-2] Die durchschnittliche Paketumlaufzeit zwischen dem Gerät und einem Zugangspunkt, während sich das Gerät im Modus „Wi-Fi Low Latency Lock“ (WIFI_MODE_FULL_LOW_LATENCY) befindet, MUSS kleiner sein als die Latenz im Modus „Wi-Fi High Perf Lock“ (WIFI_MODE_FULL_HIGH_PERF).
[C-SR] Es wird DRINGEND empfohlen, die WLAN-Rücklauflatenz zu minimieren, wenn eine Sperre für niedrige Latenz (WIFI_MODE_FULL_LOW_LATENCY) erworben und wirksam wird.

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

[C-2-1] Es MUSS eine Nutzerfunktion geben, mit der der über die API-Methode WifiManager.isScanAlwaysAvailable gelesene Wert aktiviert oder deaktiviert werden kann.

7.4.2.1. Wi-Fi Direct

Geräteimplementierungen:

MÜSSEN Wi‑Fi Direct (Wi‑Fi-Peer-to-Peer) unterstützen.

Wenn die Geräteimplementierung Wi‑Fi Direct unterstützt, gilt Folgendes:

[C-1-1] Die entsprechende Android API muss wie in der SDK-Dokumentation beschrieben implementiert werden.
[C-1-2] Die Hardwarefunktion android.hardware.wifi.direct MUSS erfasst werden.
[C-1-3] MUSS den regulären WLAN-Betrieb unterstützen.
[C-1-4] MUSS WLAN und Wi‑Fi Direct gleichzeitig unterstützen.

7.4.2.2. Einrichtung eines Wi‑Fi-Tunneled Direct Link

Geräteimplementierungen:

MÜSSEN Unterstützung für Wi‑Fi Tunneled Direct Link Setup (TDLS) bieten, wie in der Android SDK-Dokumentation beschrieben.

Wenn Geräteimplementierungen TDLS unterstützen und TDLS über die WiFiManager API aktiviert ist, gilt Folgendes:

[C-1-1] MUSS die Unterstützung für TDLS über WifiManager.isTdlsSupported deklarieren.
TDLS sollte nur verwendet werden, wenn es möglich UND vorteilhaft ist.
SOLLTE eine Heuristik haben und TDLS NICHT verwenden, wenn die Leistung schlechter als über den WLAN-Zugangspunkt ist.

7.4.2.3. Wi‑Fi Aware

Geräteimplementierungen:

MÜSSEN Unterstützung für Wi‑Fi Aware bieten.

Wenn Geräteimplementierungen die Unterstützung von Wi‑Fi Aware umfassen und die Funktion für Drittanbieter-Apps freigeben, gelten folgende Anforderungen:

[C-1-1] Die WifiAwareManager APIs MÜSSEN wie in der SDK-Dokumentation beschrieben implementiert werden.
[C-1-2] Das android.hardware.wifi.aware-Funktions-Flag MUSS deklariert werden.
[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 maximal 30 Minuten und immer dann zufällig generiert werden, wenn Wi‑Fi Aware aktiviert ist, es sei denn, ein Aware-Messvorgang ist in Bearbeitung oder ein Aware-Datenpfad ist aktiv. Die Zufallsgenerierung ist nicht erforderlich, solange der Datenpfad aktiv ist.

Wenn die Geräteimplementierungen die Unterstützung für WLAN-Aware und WLAN-Standortermittlung wie in Abschnitt 7.4.2.5 beschrieben umfassen und diese Funktionen für Drittanbieter-Apps verfügbar machen, gelten folgende Anforderungen:

[C-2-1] MÜSSEN die APIs zur standortbasierten Suche implementieren: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm und onServiceDiscoveredWithinRange.

7.4.2.4. Wi‑Fi Passpoint

Wenn Geräteimplementierungen 802.11 (Wi‑Fi) unterstützen, gilt Folgendes:

MÜSSEN Wi‑Fi Passpoint unterstützen.

Wenn die Geräteimplementierung Wi‑Fi Passpoint unterstützt, gilt Folgendes:

[C-1-2] Die Passpoint-bezogenen WifiManager APIs MÜSSEN wie in der SDK-Dokumentation beschrieben implementiert werden.
[C-1-3] MUSS den IEEE 802.11u-Standard unterstützen, insbesondere im Zusammenhang mit der Netzwerksuche und ‑auswahl, z. B. den Generic Advertisement Service (GAS) und das Access Network Query Protocol (ANQP).

Wenn die Geräteimplementierungen keine Unterstützung für Wi‑Fi Passpoint bieten, gilt Folgendes:

[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:

MÜSSEN die WLAN-Standortermittlung unterstützen.

Wenn Geräteimplementierungen die Unterstützung für die WLAN-Standortermittlung umfassen und die Funktion für Drittanbieter-Apps freigeben, gilt Folgendes:

[C-1-1] Die WifiRttManager APIs MÜSSEN wie in der SDK-Dokumentation beschrieben implementiert werden.
[C-1-2] Das android.hardware.wifi.rtt-Funktions-Flag MUSS deklariert werden.
[C-1-3] Die MAC-Quelladresse für jeden RTT-Burst muss zufällig generiert werden, der ausgeführt wird, während die WLAN-Schnittstelle, auf der der RTT ausgeführt wird, keinem Zugangspunkt zugeordnet ist.

7.4.2.6. WLAN-Keepalive-Offload

Geräteimplementierungen:

MÜSSEN die Unterstützung für das Offload von keepalive-Nachrichten für WLANs umfassen.

Wenn Geräteimplementierungen die Unterstützung für das Offload von WLAN-Keepalives umfassen und die Funktion für Drittanbieter-Apps freigeben, gilt Folgendes:

[C-1-1] MUSS die SocketKeepAlive API unterstützen.
[C-1-2] MUSS mindestens drei gleichzeitige keepalive-Slots über WLAN und mindestens einen keepalive-Slot über Mobilfunk unterstützen.

Wenn die Geräteimplementierungen keine Unterstützung für das Offload von WLAN-Keepalives bieten, gilt Folgendes:

[C-2-1] MUSS ERROR_UNSUPPORTED zurückgeben.

7.4.2.7. Wi‑Fi Easy Connect (Device Provisioning Protocol)

Geräteimplementierungen:

MÜSSEN Unterstützung für Wi‑Fi Easy Connect (DPP) bieten.

Wenn Geräteimplementierungen die Unterstützung von Wi‑Fi Easy Connect umfassen und die Funktion für Drittanbieter-Apps freigeben, müssen sie:

[C-1-1] Die Methode WifiManager#isEasyConnectSupported() MUSS true zurückgeben.

7.4.3. Bluetooth

Wenn die Geräteimplementierungen das Bluetooth Audio-Profil unterstützen, gilt Folgendes:

MÜSSEN erweiterte Audiocodecs und Bluetooth-Audiocodecs (z.B. LDAC) unterstützen.

Wenn Geräteimplementierungen HFP, A2DP und AVRCP unterstützen, gilt Folgendes:

MÜSSEN mindestens 5 verbundene Geräte unterstützen.

Wenn Geräteimplementierungen die Funktion android.hardware.vr.high_performance angeben, gilt Folgendes:

[C-1-1] MUSS Bluetooth 4.2 und Bluetooth LE Data Length Extension unterstützen.

Android unterstützt Bluetooth und Bluetooth Low Energy.

Wenn die Geräteimplementierungen Bluetooth und Bluetooth Low Energy unterstützen, gilt Folgendes:

[C-2-1] MÜSSEN die relevanten Plattformfunktionen (android.hardware.bluetooth bzw. android.hardware.bluetooth_le) deklarieren und die Plattform-APIs implementieren.
MÜSSEN relevante Bluetooth-Profile wie A2DP, AVRCP, OBEX, HFP usw. implementieren, je nach Gerät.

Wenn die Geräteimplementierungen Bluetooth Low Energy (BLE) unterstützen, gelten folgende Anforderungen:

[C-3-1] Die Hardwarefunktion android.hardware.bluetooth_le MUSS deklariert werden.
[C-3-2] Die GATT-basierten (Generic Attribute Profile) Bluetooth APIs MÜSSEN wie in der SDK-Dokumentation und in android.bluetooth beschrieben aktiviert sein.
[C-3-3] Es MUSS der richtige Wert für BluetoothAdapter.isOffloadedFilteringSupported() angegeben werden, um anzugeben, ob die Filterlogik für die API-Klassen ScanFilter implementiert ist.
[C-3-4] Es MUSS der richtige Wert für BluetoothAdapter.isMultipleAdvertisementSupported() angegeben werden, um anzugeben, ob Anzeigen mit niedrigem Energieverbrauch unterstützt werden.
[C-3-5] Es MUSS ein Timeout für eine lösbare private Adresse (Resolvable Private Address, RPA) von maximal 15 Minuten implementiert werden. Die Adresse muss nach Ablauf des Timeouts gewechselt 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 Zeitüberschreitungsintervalle außerdem zwischen 5 und 15 Minuten zufällig sein.
MÜSSEN die Auslagerung der Filterlogik an den Bluetooth-Chipsatz bei der Implementierung der ScanFilter API unterstützen.
Sollte das Auslagern des Batch-Scans an den Bluetooth-Chip unterstützen.
MÜSSEN mehrere Anzeigen mit mindestens 4 Slots unterstützen.

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

[C-4-1] Es MUSS eine Nutzerfunktion zum Aktivieren/Deaktivieren des über die System-API BluetoothAdapter.isBleScanAlwaysAvailable() gelesenen Werts geben.

Wenn die Geräteimplementierungen Bluetooth LE und das Hörgeräteprofil unterstützen, wie unter Unterstützung von Hörgeräten über Bluetooth LE beschrieben, gilt Folgendes:

[C-5-1] Für BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) MUSS true zurückgegeben werden.

7.4.4. Nahfeldkommunikation

Geräteimplementierungen:

MÜSSEN einen Transceiver und zugehörige Hardware für die Nahfeldkommunikation (Near Field Communication, NFC) enthalten.
[C-0-1] Die android.nfc.NdefMessage- und android.nfc.NdefRecord-APIs MÜSSEN implementiert werden, auch wenn sie keine Unterstützung für NFC bieten oder die android.hardware.nfc-Funktion deklarieren, da die Klassen ein protokollunabhängiges Datendarstellungsformat darstellen.

Wenn Geräteimplementierungen NFC-Hardware enthalten und diese für Drittanbieter-Apps verfügbar gemacht werden sollen, müssen sie:

[C-1-1] Die android.hardware.nfc-Funktion MUSS über die android.content.pm.PackageManager.hasSystemFeature()-Methode erfasst werden.
MÜSSEN NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können:
[C-1-2] MUSS über die folgenden NFC-Standards als NFC-Forum-Lese-/Schreibgerät (wie in der technischen NFC-Forum-Spezifikation NFCForum-TS-DigitalProtocol-1.0 definiert) fungieren können:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- NFC-Forum-Tag-Typen 1, 2, 3, 4 und 5 (vom NFC-Forum definiert)
[SR] Es wird dringend empfohlen, NDEF-Nachrichten sowie Rohdaten über die folgenden NFC-Standards lesen und schreiben zu können. Die NFC-Standards sind zwar als „EMPFOHLENE VORAUSSETZUNG“ angegeben, in der Kompatibilitätsdefinition für eine zukünftige Version sollen sie jedoch in „ERFORDERLICH“ geändert werden. Diese Standards sind in dieser Version optional, werden aber in zukünftigen Versionen erforderlich sein. Wir empfehlen dringend, diese Anforderungen jetzt auf allen Geräten zu erfüllen, auf denen diese Version von Android ausgeführt wird, damit sie auf die zukünftigen Plattformversionen umgestellt werden können.
[C-1-13] MUSS im NFC-Suchmodus nach allen unterstützten Technologien abfragen.
SOLLTE sich im NFC-Erkennungsmodus befinden, während das Gerät aktiv ist, das Display eingeschaltet und der Sperrbildschirm entsperrt ist.
MÜSSEN den Barcode und die URL (falls codiert) von Thinfilm-NFC-Barcodes lesen können.

Für die oben genannten JIS-, ISO- und NFC Forum-Spezifikationen sind keine öffentlich zugänglichen Links 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 der Anwendungs-ID (AID) unterstützen, gilt Folgendes:

[C-2-1] Die Funktion android.hardware.nfc.hce MUSS als Konstante angegeben werden.
[C-2-2] MUSS NFC HCE APIs gemäß der Definition im Android SDK unterstützen.

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz für NfcF enthalten und die Funktion für Drittanbieter-Apps implementieren, gilt Folgendes:

[C-3-1] Die Funktion android.hardware.nfc.hcef MUSS als Konstante angegeben werden.
[C-3-2] MÜSSEN die NfcF Card Emulation APIs gemäß der Definition im Android SDK implementieren.

Wenn die Geräteimplementierungen die allgemeine NFC-Unterstützung wie in diesem Abschnitt beschrieben und MIFARE-Technologien (MIFARE Classic, MIFARE Ultralight, NDEF auf MIFARE Classic) in der Leser-/Schreiberrolle unterstützen, müssen sie:

[C-4-1] Die entsprechenden Android APIs MÜSSEN gemäß der Dokumentation des Android SDK implementiert werden.
[C-4-2] Die Funktion com.nxp.mifare aus der Methode android.content.pm.PackageManager.hasSystemFeature() MUSS erfasst werden. Hinweis: Dies ist keine standardmäßige Android-Funktion und wird daher nicht als Konstante in der Klasse android.content.pm.PackageManager angezeigt.

7.4.5. Netzwerkprotokolle und APIs

7.4.5.1. Mindestnetzwerkanforderungen

Geräteimplementierungen:

[C-0-1] MUSS eine Unterstützung für eine oder mehrere Formen von Datennetzwerken umfassen. Insbesondere müssen Geräteimplementierungen mindestens einen Datenstandard unterstützen, der eine Geschwindigkeit von mindestens 200 Kbit/s bietet. Beispiele für Technologien, die diese Anforderung erfüllen, sind EDGE, HSPA, EV-DO, 802.11g, Ethernet und Bluetooth PAN.
MÜSSEN auch mindestens einen gängigen WLAN-Standard wie 802.11 (Wi‑Fi) unterstützen, wenn ein physischer Netzwerkstandard wie Ethernet die primäre Datenverbindung ist.
Es kann mehr als eine Form der Datenverbindung implementiert werden.

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] IPv6 MUSS standardmäßig aktiviert sein.
Die IPv6-Kommunikation muss so zuverlässig wie IPv4 sein, z. B.:
- [C-0-4] Die IPv6-Verbindung muss im Ruhemodus aufrechterhalten werden.
- [C-0-5] Die Ratenbegrenzung darf NICHT dazu führen, dass das Gerät die IPv6-Verbindung in einem IPv6-kompatiblen Netzwerk verliert, das RA-Lebensdauern von mindestens 180 Sekunden verwendet.
[C-0-6] MUSS Drittanbieteranwendungen eine direkte IPv6-Verbindung zum Netzwerk bereitstellen, wenn eine Verbindung zu einem IPv6-Netzwerk besteht, ohne dass lokal auf dem Gerät eine Adress- oder Portübersetzung 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 bzw. der tatsächlich zum Senden und Empfangen von Paketen im Netzwerk verwendet wird und als Quell-IP-Adresse und Port für Internet- (Web-)Server sichtbar ist.

Die erforderliche IPv6-Unterstützung hängt vom Netzwerktyp ab, wie in den folgenden Anforderungen dargestellt.

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

[C-1-1] MUSS Dual-Stack und reinen IPv6-Betrieb über WLAN unterstützen.

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

[C-2-1] MUSS Dual-Stack und reinen IPv6-Betrieb über Ethernet unterstützen.

Wenn die Geräteimplementierungen Mobilfunkdaten unterstützen, gilt Folgendes:

[C-3-1] MUSS den IPv6-Betrieb (nur IPv6 und eventuell Dual-Stack) über Mobilfunk unterstützen.

Wenn Geräteimplementierungen mehrere Netzwerktypen unterstützen (z.B. WLAN und mobile Daten) haben folgende Vorteile:

[C-4-1] Die oben genannten Anforderungen MÜSSEN gleichzeitig für jedes Netzwerk erfüllt werden, wenn das Gerät gleichzeitig mit mehreren Netzwerktypen verbunden ist.

7.4.5.3. Captive Portals

Ein Captive Portal ist ein Netzwerk, für das eine Anmeldung erforderlich ist, um Internetzugriff zu erhalten.

Wenn Geräteimplementierungen eine vollständige Implementierung der android.webkit.Webview API bieten, gilt Folgendes:

[C-1-1] Es MUSS eine Captive-Portal-Anwendung zur Verfügung gestellt werden, um den Intent ACTION_CAPTIVE_PORTAL_SIGN_IN zu verarbeiten und die Anmeldeseite des Captive-Portals anzuzeigen. Dazu muss der Intent bei einem Aufruf an die System-API ConnectivityManager#startCaptivePortalApp(Network, Bundle) gesendet werden.
[C-1-2] MUSS Captive Portals erkennen und die Anmeldung über die Captive Portal-Anwendung unterstützen, wenn das Gerät mit einem beliebigen Netzwerktyp verbunden ist, einschließlich Mobilfunknetz, WLAN, Ethernet oder Bluetooth.
[C-1-3] MUSS die Anmeldung in Captive Portals mit Nur-Text-DNS unterstützen, wenn das Gerät für den strikten Modus des privaten DNS konfiguriert ist.
[C-1-4] Es MUSS verschlüsseltes DNS gemäß der SDK-Dokumentation für android.net.LinkProperties.getPrivateDnsServerName und android.net.LinkProperties.isPrivateDnsActive für den gesamten Netzwerkverkehr verwendet werden, der nicht explizit mit dem Captive Portal kommuniziert.
[C-1-5] Es MUSS sichergestellt sein, dass während der Nutzer sich in einem Captive Portal anmeldet, das von Anwendungen verwendete Standardnetzwerk (wie von ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback zurückgegeben und standardmäßig von Java-Netzwerk-APIs wie java.net.Socket und nativen APIs wie connect() verwendet) ein anderes verfügbares Netzwerk ist, das Internetzugang bietet, sofern verfügbar.

7.4.6. Synchronisierungseinstellungen

Geräteimplementierungen:

[C-0-1] Die automatische Synchronisierung für den Master muss standardmäßig aktiviert sein, damit die Methode getMasterSyncAutomatically() „wahr“ zurückgibt.

7.4.7. Datensparmodus

Wenn Geräteimplementierungen eine getaktete Verbindung umfassen, gilt Folgendes:

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

Wenn Geräteimplementierungen den Datensparmodus bieten, gilt Folgendes:

[C-1-1] MÜSSEN alle APIs in der Klasse ConnectivityManager unterstützen, wie in der SDK-Dokumentation beschrieben.

Wenn Geräteimplementierungen keinen Datensparmodus bieten, gilt Folgendes:

[C-2-1] MUSS den Wert RESTRICT_BACKGROUND_STATUS_DISABLED für ConnectivityManager.getRestrictBackgroundStatus() zurückgeben
[C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED DARF NICHT gesendet werden.

7.4.8. Secure Elements

Wenn Geräteimplementierungen sichere Elemente unterstützen, die die Open Mobile API unterstützen, und diese für Drittanbieter-Apps verfügbar machen, bieten sie folgende Vorteile:

[C-1-1] MÜSSEN die verfügbaren Secure Elements-Lesegeräte über die android.se.omapi.SEService.getReaders() API auflisten.
[C-1-2] MÜSSEN die richtigen Feature-Flags über android.hardware.se.omapi.uicc für das Gerät mit UICC-basierten sicheren Elementen, android.hardware.se.omapi.ese für das Gerät mit eSE-basierten sicheren Elementen und android.hardware.se.omapi.sd für das Gerät mit SD-basierten sicheren Elementen angeben.

7.5. Kameras

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

[C-1-1] Das android.hardware.camera.any-Funktions-Flag MUSS deklariert werden.
[C-1-2] Es MUSS möglich sein, dass eine Anwendung gleichzeitig drei RGBA_8888-Bitmaps zuweist, die der Größe der Bilder entsprechen, die vom Kamerasensor mit der höchsten Auflösung auf dem Gerät aufgenommen werden, während die Kamera für eine einfache Vorschau und Standbildaufnahme geöffnet ist.
[C-1-3] Die vorinstallierte Standardkamera-App, die die Intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE oder MediaStore.ACTION_VIDEO_CAPTURE verarbeitet, MUSS dafür verantwortlich sein, den Nutzerstandort aus den Bildmetadaten zu entfernen, bevor sie an die Empfänger-App gesendet werden, wenn die Empfänger-App nicht ACCESS_FINE_LOCATION hat.

7.5.1. Rückkamera

Eine Rückkamera befindet sich auf der Seite des Geräts, die dem Display gegenüberliegt. Sie nimmt also Bilder auf der Rückseite des Geräts auf, ähnlich wie eine herkömmliche Kamera.

Geräteimplementierungen:

MÜSSEN eine Rückkamera haben.

Wenn Geräteimplementierungen mindestens eine Rückkamera enthalten, gilt Folgendes:

[C-1-1] MÜSSEN die Funktions-Flags android.hardware.camera und android.hardware.camera.any melden.
[C-1-2] MÜSSEN eine Auflösung von mindestens 2 Megapixeln haben.
Es sollte entweder ein Hardware- oder Software-Autofokus im Kameratreiber implementiert sein (für die Anwendungssoftware transparent).
KANN Hardware mit fester Brennweite oder erweiterter Schärfentiefe haben.
KANN einen Blitz enthalten.

Wenn die Kamera einen Blitz hat:

[C-2-1] Der Blitz darf NICHT leuchten, während eine android.hardware.Camera.PreviewCallback-Instanz auf einer Kameravorschauoberfläche registriert ist, es sei denn, die Anwendung hat den Blitz explizit aktiviert, indem sie die Attribute FLASH_MODE_AUTO oder FLASH_MODE_ON eines Camera.Parameters-Objekts aktiviert hat. 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 zum Aufnehmen von Bildern des Nutzers verwendet, z. B. für Videokonferenzen und ähnliche Anwendungen.

Geräteimplementierungen:

KANN eine Frontkamera enthalten.

Wenn Geräteimplementierungen mindestens eine nach vorne 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] MÜSSEN eine Auflösung von mindestens VGA (640 × 480 Pixel) haben.
[C-1-3] Die Frontkamera darf NICHT als Standard für die Camera API verwendet werden und die API darf NICHT so konfiguriert werden, dass eine Frontkamera als Standardrückkamera behandelt wird, auch wenn sie die einzige Kamera auf dem Gerät ist.
[C-1-4] Die Kameravorschau MUSS horizontal gespiegelt werden, bezogen auf die von der Anwendung angegebene Ausrichtung, wenn die aktuelle Anwendung ausdrücklich die Drehung des Kameradisplays über einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() angefordert hat. Umgekehrt MUSS die Vorschau entlang der Standardhorizontalachse des Geräts gespiegelt werden, wenn die aktuelle Anwendung nicht explizit über einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() anfordert, dass das Kameradisplay gedreht wird.
[C-1-5] Die finalen aufgenommenen Standbilder oder Videostreams, die an Anwendungs-Callbacks zurückgegeben oder im Medienspeicher gespeichert werden, DÜRFEN NICHT gespiegelt werden.
[C-1-6] Das Bild, das in der Postview angezeigt wird, MUSS auf dieselbe Weise gespiegelt werden wie der Bildstream der Kameravorschau.
KANN Funktionen wie Autofokus und Blitz enthalten, die für Rückkameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.

Wenn Geräteimplementierungen vom Nutzer gedreht werden können (z. B. automatisch über einen Beschleunigungsmesser oder manuell über die Nutzereingabe):

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

7.5.3. Externe Kamera

Geräteimplementierungen:

MÖGLICHERWEISE Unterstützung für eine externe Kamera, die nicht unbedingt immer verbunden ist.

Wenn die Geräteimplementierungen die Unterstützung einer externen Kamera umfassen, gilt Folgendes:

[C-1-1] Die Plattform-Funktions-Flags android.hardware.camera.external und android.hardware camera.any MÜSSEN deklariert werden.
[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 ist.
[C-1-3] Die Kamera muss die CTS-Tests mit einem angeschlossenen externen Kameragerät bestehen. Details zu den CTS-Tests für Kameras finden Sie unter source.android.com.
MÜSSEN Videokomprimierungen wie MJPEG unterstützen, um die Übertragung von hochwertigen, nicht codierten Streams (d.h. Roh- oder unabhängig komprimierte Bildstreams) zu ermöglichen.
Unter Umständen wird die Nutzung mehrerer Kameras unterstützt.
Unter Umständen wird die kamerabasierte Videocodierung unterstützt.

Wenn die kamerabasierte Videocodierung unterstützt wird:

[C-2-1] Auf einen gleichzeitigen uncodierten / MJPEG-Stream (QVGA oder höhere Auflösung) MUSS von der Geräteimplementierung aus zugegriffen werden können.

7.5.4. Verhalten der Camera API

Android bietet zwei API-Pakete für den Zugriff auf die Kamera. Die neuere android.hardware.camera2 API stellt der App eine Kamerasteuerung auf niedriger Ebene zur Verfügung, einschließlich effizienter Zero-Copy-Burst-/Streaming-Abläufe und Frames-spezifischer Einstellungen für Belichtung, Verstärkung, Weißabgleich, Farbkonvertierung, Rauschunterdrückung, Schärfung und mehr.

Das ältere API-Paket android.hardware.Camera ist in Android 5.0 als eingestellt gekennzeichnet, sollte aber weiterhin für Apps verfügbar sein. Bei der Implementierung von Android-Geräten MUSS die API wie in diesem Abschnitt und im Android SDK beschrieben weiter unterstützt werden.

Alle Funktionen, die der eingestellten Klasse „android.hardware.Camera“ und dem neueren Paket „android.hardware.camera2“ gemeinsam sind, MÜSSEN in beiden APIs dieselbe Leistung und Qualität haben. Bei vergleichbaren Einstellungen müssen beispielsweise die Geschwindigkeit und Genauigkeit des Autofokus 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 dieselbe Geschwindigkeit oder Qualität haben, sollten aber so nah wie möglich übereinstimmen.

Bei Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs für alle verfügbaren Kameras implementiert werden. Geräteimplementierungen:

[C-0-1] android.hardware.PixelFormat.YCbCr_420_SP MUSS für Vorschaudaten verwendet werden, die an Anwendungs-Callbacks übergeben werden, wenn eine Anwendung noch nie android.hardware.Camera.Parameters.setPreviewFormat(int) aufgerufen hat.
[C-0-2] MÜSSEN außerdem im NV21-Codierungsformat vorliegen, wenn eine Anwendung eine android.hardware.Camera.PreviewCallback-Instanz registriert und das System die onPreviewFrame()-Methode aufruft und das Vorschauformat YCbCr_420_SP ist, werden die Daten in der byte[] an onPreviewFrame() übergeben. Das heißt, NV21 MUSS der Standard sein.
[C-0-3] Für android.hardware.Camera MUSS das YV12-Format (wie durch die Konstante android.graphics.ImageFormat.YV12 angegeben) für Kameravorschauen sowohl für die Front- als auch für die Rückkamera unterstützt werden. Der Hardware-Videoencoder und die Kamera können beliebige native Pixelformate verwenden, aber die Geräteimplementierung MUSS die Umwandlung in YV12 unterstützen.
[C-0-4] Die android.hardware.ImageFormat.YUV_420_888- und android.hardware.ImageFormat.JPEG-Formate MÜSSEN als Ausgaben über die android.media.ImageReader API für android.hardware.camera2-Geräte unterstützt werden, die die REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE-Funktion in android.request.availableCapabilities angeben.
[C-0-5] Die vollständige Camera API in der Android SDK-Dokumentation MUSS implementiert werden, unabhängig davon, ob das Gerät einen Hardware-Autofokus oder andere Funktionen hat. Kameras ohne Autofokus MÜSSEN beispielsweise alle registrierten android.hardware.Camera.AutoFocusCallback-Instanzen aufrufen, auch wenn dies für eine Kamera ohne Autofokus keine Relevanz hat. Dies gilt auch für Frontkameras. Auch wenn die meisten Frontkameras keinen Autofokus unterstützen, müssen die API-Callbacks wie beschrieben „gefaket“ werden.
[C-0-6] MUSS jeden Parameternamen erkennen und berücksichtigen, der in der Klasse android.hardware.Camera.Parameters und der Klasse android.hardware.camera2.CaptureRequest als Konstante definiert ist. Umgekehrt dürfen Geräteimplementierungen nur Stringkonstanten berücksichtigen oder erkennen, die an die android.hardware.Camera.setParameters()-Methode übergeben werden und als Konstanten in der android.hardware.Camera.Parameters dokumentiert sind. Das bedeutet, dass Geräteimplementierungen alle Standardkameraparameter unterstützen MÜSSEN, sofern die Hardware dies zulässt, und KEINE benutzerdefinierten Kameraparametertypen unterstützen DÜRFEN. Geräteimplementierungen, die die Bildaufnahme mit HDR-Bildgebungstechniken (High Dynamic Range) unterstützen, MÜSSEN beispielsweise den Kameraparameter Camera.SCENE_MODE_HDR unterstützen.
[C-0-7] Die richtige Supportstufe muss mit der Property android.info.supportedHardwareLevel gemäß der Beschreibung im Android SDK angegeben werden. Außerdem müssen die entsprechenden Framework-Funktions-Flags angegeben werden.
[C-0-8] MÜSSEN auch die einzelnen Kamerafunktionen von android.hardware.camera2 über die Property android.request.availableCapabilities angeben und die entsprechenden Funktions-Flags deklarieren; MÜSSEN das Funktions-Flag definieren, wenn eines der angeschlossenen Kamerageräte die Funktion unterstützt.
[C-0-9] Die Camera.ACTION_NEW_PICTURE-Intention MUSS gesendet werden, wenn mit der Kamera ein neues Bild aufgenommen und der Eintrag des Bildes dem Medienspeicher hinzugefügt wurde.
[C-0-10] Die Camera.ACTION_NEW_VIDEO-Intention MUSS gesendet werden, wenn von der Kamera ein neues Video aufgenommen und der Eintrag des Bildes dem Medienspeicher hinzugefügt wurde.
[C-0-11] Alle Kameras MÜSSEN über die eingestellte android.hardware.Camera API und die android.hardware.camera2 API zugänglich sein.
[C-0-12] Es DARF NICHT möglich sein, das Aussehen des Gesichts zu ändern, einschließlich, aber nicht beschränkt auf die Gesichtsgeometrie, den Hautton oder die Hautglättung für jede android.hardware.camera2- oder android.hardware.Camera-API.
[C-SR] Für Geräte mit mehreren RGB-Kameras, die in dieselbe Richtung zeigen, wird DRINGEND empfohlen, ein logisches Kameragerät zu unterstützen, das die Funktion CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA auflistet und aus allen RGB-Kameras besteht, die in diese Richtung zeigen, 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 Anbieter-Tags und/oder ‑Erweiterungen für die android.hardware.camera2 API bereitstellen.

7.5.5. Kameraausrichtung

Wenn Geräte eine Front- oder Rückkamera haben, gelten für diese Kamera(s) die folgenden Anforderungen:

[C-1-1] MUSS so ausgerichtet sein, dass die lange Dimension der Kamera mit der langen Dimension des Bildschirms übereinstimmt. Wenn das Gerät also im Querformat gehalten wird, MÜSSEN die Kameras Bilder im Querformat aufnehmen. Das gilt unabhängig von der natürlichen Ausrichtung des Geräts, also sowohl für Geräte, die im Querformat als auch im Hochformat verwendet werden.

7.6. Arbeitsspeicher und Datenspeicher

7.6.1. Mindestarbeitsspeicher und Mindestspeicherplatz

Geräteimplementierungen:

[C-0-1] MUSS einen Download-Manager enthalten, den Anwendungen zum Herunterladen von Datendateien VERWENDEN DÜRFEN. Außerdem MUSS es möglich sein, einzelne Dateien mit einer Größe von mindestens 100 MB an den standardmäßigen Cache-Speicherort herunterzuladen.

7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen

Geräteimplementierungen:

[C-0-1] MUSS Speicherplatz für die gemeinsame Nutzung durch Anwendungen bieten, der auch oft als „freigegebener externer Speicher“, „freigegebener Speicher für Anwendungen“ oder durch den Linux-Pfad „/sdcard“, auf dem er bereitgestellt wird, bezeichnet wird.
[C-0-2] MUSS mit freigegebenem Speicher konfiguriert sein, der standardmäßig bereitgestellt wird, also „out of the box“, unabhängig davon, ob der Speicher auf einer internen Speicherkomponente oder einem Wechseldatenträger (z.B. SD-Kartenslot) implementiert ist.
[C-0-3] Der freigegebene Speicher der Anwendung muss direkt über den Linux-Pfad sdcard bereitgestellt oder einen Linux-Symbollink von sdcard zum tatsächlichen Bereitstellungspunkt enthalten.
[C-0-4] Der befristete Speicher muss standardmäßig für alle Apps aktiviert sein, die auf API-Level 29 oder höher ausgerichtet sind, mit folgenden Ausnahmen:
- Wenn die App android:requestLegacyExternalStorage="true" in ihrem Manifest angefordert hat.
[C-0-5] Standortmetadaten wie GPS-EXIF-Tags, die in Mediendateien gespeichert sind, MÜSSEN entfernt werden, wenn ü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:

Ein für Nutzer zugänglicher Wechseldatenträger, z. B. ein SD-Kartenslot (Secure Digital).
Ein Teil des internen (nicht entfernbaren) Speichers, wie im Android Open Source Project (AOSP) implementiert.

Wenn bei Geräteimplementierungen Wechselspeicher verwendet wird, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

[C-1-1] Es MUSS eine Toast- oder Pop-up-Benutzeroberfläche implementiert werden, die den Nutzer warnt, wenn sich kein Speichermedium im Steckplatz befindet.
[C-1-2] MUSS ein FAT-formatiertes Speichermedium (z.B. eine SD-Karte) enthalten oder auf der Verpackung und anderen zum Zeitpunkt des Kaufs verfügbaren Materialien muss angegeben sein, dass das Speichermedium separat erworben werden muss.

Wenn bei Geräteimplementierungen ein Teil des nicht entfernbaren Speichers verwendet wird, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

SOLLTE die AOSP-Implementierung des internen freigegebenen Speichers der Anwendung verwenden.
KANN den Speicherplatz mit den privaten Daten der Anwendung teilen.

Wenn Geräteimplementierungen einen USB-Anschluss mit Unterstützung des USB-Peripheriemodus haben, gilt Folgendes:

[C-3-1] Es MUSS ein Mechanismus zum Zugriff auf die Daten im freigegebenen Speicher der Anwendung von einem Hostcomputer aus bereitgestellt werden.
MÜSSEN Inhalte aus beiden Speicherpfaden transparent über den Medienscannerdienst von Android und android.provider.MediaStore bereitstellen.
Es kann USB-Massenspeicher verwenden, sollte aber das Media-Übertragungsprotokoll verwenden, um diese Anforderung zu erfüllen.

Wenn Geräteimplementierungen einen USB-Anschluss mit USB-Peripheriemodus haben und das Media-Transfer-Protokoll unterstützen, gilt Folgendes:

MÜSSEN mit dem Referenz-Android-MTP-Host Android File Transfer kompatibel sein.
MÜSSEN eine USB-Geräteklasse von 0x00 melden.
MÜSSEN den Namen „MTP“ für die USB-Schnittstelle angeben.

7.6.3. Adoptable Storage

Wenn das Gerät im Gegensatz zu einem Fernseher mobil sein soll, sind Geräteimplementierungen:

[SR] Es wird dringend empfohlen, den anpassbaren Speicher an einem langfristig stabilen Ort zu implementieren, da ein versehentliches Trennen zu Datenverlusten oder Beschädigungen führen kann.

Wenn sich der Anschluss für das Wechselspeichergerät an einer dauerhaft stabilen Stelle befindet, z. B. im Batteriefach oder in einer anderen Schutzabdeckung, sind die Geräteimplementierungen:

[SR] Es wird dringend empfohlen, Adaptive Storage zu implementieren.

7.7. USB

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

MÜSSEN den USB-Peripheriegerätemodus und den USB-Hostmodus unterstützen.

7.7.1. USB-Peripheriegerätemodus

Wenn die Geräteimplementierungen einen USB-Anschluss mit Peripheriemodus enthalten:

[C-1-1] Der Anschluss MUSS mit einem USB-Host mit einem Standard-USB-Typ-A- oder -Typ-C-Anschluss verbunden werden können.
[C-1-2] Der korrekte Wert von iSerialNumber muss im USB-Standardgeräte-Descriptor über android.os.Build.SERIAL gemeldet werden.
[C-1-3] MÜSSEN Ladegeräte mit 1,5 A und 3,0 A gemäß dem Widerstandsstandard für USB-Typ-C erkennen und MÜSSEN Änderungen in der Werbung erkennen, wenn sie USB-Typ-C unterstützen.
[SR] Der Anschluss sollte den USB-Formfaktor Micro-B, Micro-AB oder Typ-C haben. Für bestehende und neue Android-Geräte wird dringend empfohlen, diese Anforderungen zu erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt werden können.
[SR] Der Anschluss sollte sich an der Unterseite des Geräts befinden (entsprechend der natürlichen Ausrichtung) oder die Bildschirmdrehung für alle Apps (einschließlich Startbildschirm) aktivieren, damit das Display korrekt dargestellt wird, wenn sich das Gerät mit dem Anschluss nach unten befindet. Für bestehende und neue Android-Geräte wird dringend empfohlen, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen umgestellt werden können.
[SR] Es sollte Unterstützung für einen Stromverbrauch von 1,5 A während des HS-Chirps und des Traffics implementiert werden, wie in der USB Battery Charging specification, Revision 1.2 angegeben. Für bestehende und neue Android-Geräte wird dringend empfohlen, diese Anforderungen zu erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt 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 Rolle des Sinks/der Quelle ändern, da dies zu Inkompatibilitätsproblemen mit Ladegeräten oder Geräten führen kann, die die standardmäßigen USB-Lademethoden unterstützen. Diese Funktion wird zwar als „EMPFOHLENE OPTION“ gekennzeichnet, in zukünftigen Android-Versionen wird es jedoch möglicherweise erforderlich sein, dass alle Geräte mit USB-Typ-C-Anschluss die vollständige Interoperabilität mit Standard-USB-Typ-C-Ladegeräten unterstützen.
[SR] Es wird dringend empfohlen, die Stromversorgung für den Daten- und Stromversorgungsrollentausch zu unterstützen, wenn USB-Typ-C und der USB-Hostmodus unterstützt werden.
MÜSSEN Power Delivery für das Laden mit hoher Spannung und Unterstützung für alternative Modi wie Displayausgang unterstützen.
MÜSSEN die Android Open Accessory (AOA) API und ‑Spezifikation wie in der Android SDK-Dokumentation beschrieben implementieren.

Wenn Geräteimplementierungen einen USB-Anschluss und die AOA-Spezifikation implementieren, gilt Folgendes:

[C-2-1] MUSS die Unterstützung der Hardwarefunktion android.hardware.usb.accessory angeben.
[C-2-2] Die USB-Massenspeicherklasse MUSS am Ende des Interface-Beschreibungsstrings iInterface des USB-Massenspeichers den String „android“ enthalten.

7.7.2. USB-Host-Modus

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

[C-1-1] Die Android USB Host API MUSS gemäß der Dokumentation im Android SDK implementiert werden und es MUSS Unterstützung für die Hardwarefunktion android.hardware.usb.host deklariert werden.
[C-1-2] MÜSSEN die Verbindung von Standard-USB-Peripheriegeräten unterstützen. Das bedeutet, dass sie entweder:
- Sie haben einen USB-C-Anschluss oder werden mit Kabeln geliefert, die einen proprietären Anschluss des Geräts an einen standardmäßigen USB-C-Anschluss anpassen (USB-C-Gerät).
- Sie haben einen USB-A-Anschluss oder werden mit Kabeln geliefert, die einen proprietären Anschluss des Geräts an einen Standard-USB-A-Anschluss anpassen.
- einen Micro-AB-Anschluss auf dem Gerät haben, der MIT einem Kabel geliefert werden sollte, das an einen Standard-Typ-A-Anschluss passt.
[C-1-3] Der Lieferumfang darf KEIN Adapter enthalten, der von USB-Typ-A- oder Micro-AB-Ports zu einem Typ-C-Port (Anschluss) konvertiert.
[C-SR] Es wird DRINGEND empfohlen, die USB-Audioklasse gemäß der Dokumentation des Android SDK zu implementieren.
MÜSSEN das Aufladen des angeschlossenen USB-Peripheriegeräts im Hostmodus unterstützen und einen Quellstrom von mindestens 1,5 A angeben, wie im Abschnitt „Termination Parameters“ (Begrenzungsparameter) der USB Type-C Cable and Connector Specification Revision 1.2 (USB-Typ-C-Kabel- und Anschlussspezifikation Version 1.2) für USB-Typ-C-Anschlüsse oder mit dem Ausgabestrombereich des Charging Downstream Ports (CDP) gemäß den USB Battery Charging specifications, revision 1.2 (USB-Spezifikationen für das Aufladen von Akkus, Version 1.2) für Micro-AB-Anschlüsse.
MÜSSEN USB-Typ-C-Standards implementieren und unterstützen.

Wenn Geräteimplementierungen einen USB-Anschluss haben, der den Hostmodus und die USB-Audioklasse unterstützt, gilt Folgendes:

[C-2-1] MUSS die USB HID-Klasse unterstützen.
[C-2-2] MUSS die Erkennung und Zuordnung der folgenden HID-Datenfelder unterstützen, die in den USB HID-Nutzungstabellen und der Nutzungsanfrage für Sprachbefehle an die KeyEvent-Konstanten unten angegeben sind:
- Nutzungsseite (0xC) – Nutzungs-ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Nutzungsseite (0xC) – Nutzungs-ID (0x0E9): KEYCODE_VOLUME_UP
- Seite für die Nutzung (0xC) – Nutzungs-ID (0x0EA): KEYCODE_VOLUME_DOWN
- Nutzungsseite (0xC) – Nutzungs-ID (0x0CF): KEYCODE_VOICE_ASSIST

Wenn Geräteimplementierungen einen USB-Anschluss haben, der den Host-Modus und das Storage Access Framework (SAF) unterstützt, gilt Folgendes:

[C-3-1] MUSS alle per Fernzugriff verbundenen MTP-Geräte (Media Transfer Protocol) erkennen und deren Inhalte über die Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT und ACTION_CREATE_DOCUMENT zugänglich machen. .

Wenn Geräteimplementierungen einen USB-Port haben, der den Hostmodus und USB Typ-C unterstützt, gilt Folgendes:

[C-4-1] MÜSSEN die Funktion „Dual Role Port“ gemäß der USB-Typ-C-Spezifikation (Abschnitt 4.5.1.3.3) implementieren.
[SR] DisplayPort wird DRINGEND empfohlen, USB SuperSpeed-Datenraten sollten unterstützt werden und die Unterstützung von Power Delivery für den Austausch von Daten- und Stromversorgungsrollen wird DRINGEND empfohlen.
[SR] Es wird DRINGEND empfohlen, den Zubehörmodus für Audioadapter NICHT zu unterstützen, wie in Anhang A der USB Type-C Cable and Connector Specification Revision 1.2 beschrieben.
MÜSSEN das Try.*-Modell implementieren, das für den Geräteformfaktor am besten geeignet ist. Beispielsweise sollte ein Handheld das Try.SNK-Modell implementieren.

7.8. Audio

7.8.1. Mikrofon

Wenn Geräteimplementierungen ein Mikrofon enthalten, gilt Folgendes:

[C-1-1] Die Funktion android.hardware.microphone MUSS als Konstante angegeben werden.
[C-1-2] MÜSSEN die Anforderungen an Audioaufnahmen in Abschnitt 5.4 erfüllen.
[C-1-3] MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
[SR] Es wird EMPFINDLICH EMPFOHLEN, die Aufzeichnung von Nah-Ultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen.

Wenn bei Geräteimplementierungen kein Mikrofon vorhanden ist, gilt Folgendes:

[C-2-1] Die Funktion android.hardware.microphone darf NICHT gemeldet werden.
[C-2-2] Gemäß Abschnitt 7 MUSS die Audioaufzeichnungs-API mindestens als No-Op implementiert werden.

7.8.2. Audioausgabe

Wenn Geräteimplementierungen einen Lautsprecher oder einen Audio-/Multimedia-Ausgabeanschluss für ein Audioausgabegerät wie eine 4-polige 3,5-mm-Audiobuchse oder einen USB-Host-Modus-Anschluss mit USB Audio Class enthalten, müssen sie:

[C-1-1] Die Funktion android.hardware.audio.output MUSS als Konstante angegeben werden.
[C-1-2] MUSS die Anforderungen an die Audiowiedergabe in Abschnitt 5.5 erfüllen.
[C-1-3] MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
[SR] Es wird dringend empfohlen, die Wiedergabe von Near-Ultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen.

Wenn Geräteimplementierungen keinen Lautsprecher oder Audioausgang haben, gilt Folgendes:

[C-2-1] Die Funktion android.hardware.audio.output DARF NICHT gemeldet werden.
[C-2-2] Die APIs für den Audioausgang MÜSSEN mindestens als No-Ops implementiert werden.

In diesem Abschnitt bezeichnet ein „Ausgabeanschluss“ eine physische Schnittstelle wie einen 3,5-mm-Audioanschluss, einen HDMI-Anschluss oder einen USB-Hostmodus-Anschluss mit USB-Audioklasse. Die Unterstützung der Audioausgabe über radiobasierte Protokolle wie Bluetooth, WLAN oder Mobilfunknetz gilt nicht als „Ausgabeport“.

7.8.2.1. Analoge Audioports

Damit Geräte mit einem oder mehreren analogen Audioanschlüssen mit Headsets und anderem Audiozubehör kompatibel sind, die den 3,5-mm-Audiostecker verwenden, müssen sie folgende Anforderungen erfüllen:

[C-SR] Es wird DRINGEND empfohlen, dass mindestens einer der Audioanschlüsse eine 4-polige 3,5-mm-Audiobuchse ist.

Wenn die Geräteimplementierungen eine 3,5-mm-Audiobuchse mit vier Adern haben, gilt Folgendes:

[C-1-1] Die Audiowiedergabe über Stereokopfhörer und Stereoheadsets mit Mikrofon MUSS unterstützt werden.
[C-1-2] MÜSSEN TRRS-Audiostecker mit der CTIA-Belegung unterstützen.
[C-1-3] MUSS die Erkennung und Zuordnung zu den Tastencodes für die folgenden drei Bereiche der äquivalenten Impedanz zwischen dem Mikrofon und den Erdleitern am Audiostecker unterstützen:
- 70 Ohm oder weniger: KEYCODE_HEADSETHOOK
- 210–290 Ohm: KEYCODE_VOLUME_UP
- 360–680 Ohm: KEYCODE_VOLUME_DOWN
[C-1-4] MUSS ACTION_HEADSET_PLUG beim Einstecken des Steckers auslösen, aber erst, nachdem alle Kontakte am Stecker ihre entsprechenden Segmente an der Buchse berühren.
[C-1-5] MUSS mindestens 150 mV ± 10% der Ausgangsspannung bei einer Lautsprecherimpedanz von 32 Ohm liefern können.
[C-1-6] Die Mikrofonvorspannung muss zwischen 1,8 V und 2,9 V liegen.
[C-1-7] MUSS den folgenden Bereich der äquivalenten Impedanz zwischen dem Mikrofon und den Erdleitern am Audiostecker erkennen und dem Schlüsselcode zuordnen:
- 110–180 Ohm:KEYCODE_VOICE_ASSIST
[C-SR] Es wird DRINGEND empfohlen, Audiostecker mit der OMTP-Belegung zu unterstützen.
[C-SR] Es wird dringend empfohlen, die Audioaufnahme über Stereo-Headsets mit Mikrofon zu unterstützen.

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

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

7.8.2.2. Digitale Audioports

Damit Headsets und anderes Audiozubehör mit USB-C-Anschlüssen kompatibel sind und die USB Audio Class im gesamten Android-System implementiert wird, wie in der Android USB Headset Specification definiert.

Gerätespezifische Anforderungen finden Sie unter 2.2.1.

7.8.3. Nah-Ultraschall

Nah-Ultraschall-Audio ist das Band von 18,5 kHz bis 20 kHz.

Geräteimplementierungen:

MÜSSEN die Unterstützung der Near-Ultrasound-Audiofunktion über die AudioManager.getProperty API wie unten beschrieben korrekt melden:

Wenn PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND „wahr“ ist, MÜSSEN die folgenden Anforderungen von den Audioquellen VOICE_RECOGNITION und UNPROCESSED erfüllt werden:

[C-1-1] Die durchschnittliche Leistungsantwort des Mikrofons im Bereich von 18,5 kHz bis 20 kHz DARF maximal 15 dB unter der Antwort bei 2 kHz liegen.
[C-1-2] Das ungewichtete Signal-Rausch-Verhältnis des Mikrofons bei 18,5 kHz bis 20 kHz für einen 19 kHz-Ton bei −26 dBFS darf nicht unter 50 dB liegen.

Wenn PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND „wahr“ ist:

[C-2-1] Die mittlere Antwort des Lautsprechers bei 18,5 kHz bis 20 kHz DARF nicht mehr als 40 dB unter der Antwort bei 2 kHz liegen.

7.8.4. Signalintegrität

Geräteimplementierungen: * MÜSSEN einen störungsfreien Audiosignalpfad sowohl für Eingabe- als auch für Ausgabestreams auf Mobilgeräten bereitstellen, was durch Null-Störungen während eines Tests von einer Minute pro Pfad definiert wird. Führe einen Test mit dem „Automated Glitch Test“ von [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) durch.

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

OboeTester unterstützt derzeit AAudio-Pfade. Daher sollten die folgenden Kombinationen mit AAudio auf Störungen geprüft werden:

Perf-Modus	Inhalte teilen	Ausgabeabtastrate	In Channels	Out-Channels
LOW_LATENCY	EXKLUSIV	KEINE ANGABE	1	2
LOW_LATENCY	EXKLUSIV	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 MUSS die folgenden Kriterien für das Signal-Rausch-Verhältnis (SNR) und die Gesamtharmonische Verzerrung (Total Harmonic Distortion, THD) für eine Sinuswelle mit 2.000 Hz 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 implementieren.

7.9.1. Virtual Reality-Modus

Android unterstützt den VR-Modus. Diese Funktion verarbeitet das stereoskopische Rendern von Benachrichtigungen und deaktiviert monokulare System-UI-Komponenten, während der Fokus des Nutzers auf einer VR-Anwendung liegt.

7.9.2. Virtual Reality-Modus – Hohe Leistung

Wenn Geräteimplementierungen den VR-Modus unterstützen, gilt Folgendes:

[C-1-1] Es müssen mindestens zwei physische Kerne vorhanden sein.
[C-1-2] Die Funktion android.hardware.vr.high_performance MUSS deklariert werden.
[C-1-3] MUSS den Modus für eine konstante Leistung unterstützen.
[C-1-4] Es wird DRINGEND empfohlen, OpenGL ES 3.2 zu unterstützen.
[C-1-5] MUSS android.hardware.vulkan.level 0 unterstützen.
Sollte android.hardware.vulkan.level 1 oder höher unterstützen.
[C-1-6] Es 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 und EGL_EXT_image_gl_colorspace implementiert werden. Die Erweiterungen müssen in der Liste der verfügbaren EGL-Erweiterungen aufgeführt sein.
[C-1-8] GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2 und GL_EXT_protected_textures MÜSSEN implementiert werden und die Erweiterungen MÜSSEN in der Liste der verfügbaren GL-Erweiterungen aufgeführt werden.
[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 anzugeben.
[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 anzugeben.
[C-SR] Es wird DRINGEND empfohlen, mindestens eine Vulkan-Warteschlangenfamilie bereitzustellen, bei 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 freigegebenen Front-Buffer so synchronisieren können, dass das abwechselnde Rendern von VR-Inhalten mit zwei Rendering-Kontexten bei 60 fps ohne sichtbare Tearing-Artefakte erfolgt.
[C-1-9] Es MUSS Unterstützung für die AHardwareBuffer-Flags AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA und AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT wie im NDK beschrieben implementiert werden.
[C-1-10] Es MUSS Unterstützung für AHardwareBuffers mit beliebigen Kombinationen der Nutzungsflags AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT für mindestens die folgenden Formate implementiert werden: 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 und Flags und Formaten zu unterstützen, die in C-1-10 angegeben sind.
[C-1-11] MUSS die H.264-Dekodierung mit mindestens 3.840 × 2.160 bei 30 fps unterstützen, komprimiert auf durchschnittlich 40 Mbit/s (entspricht 4 Instanzen von 1.920 × 1.080 bei 30 fps – 10 Mbit/s oder 2 Instanzen von 1.920 × 1.080 bei 60 fps – 20 Mbit/s).
[C-1-12] MUSS HEVC und VP9 unterstützen, MUSS mindestens 1920 × 1080 bei 30 fps decodieren können, komprimiert auf durchschnittlich 10 Mbit/s, und SOLLTE 3840 × 2160 bei 30 fps bis 20 Mbit/s decodieren können (entspricht 4 Instanzen von 1920 × 1080 bei 30 fps bis 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] Es MUSS ein eingebetteter Bildschirm vorhanden sein und die 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 mindestens mit 60 Hz aktualisiert werden.
[C-1-17] Das Display MUSS einen Modus mit geringer Nachleuchtzeit mit einer Nachleuchtzeit von maximal 5 Millisekunden unterstützen. Die Nachleuchtzeit wird definiert als die Zeitspanne, in der ein Pixel Licht ausstrahlt.
[C-1-18] MUSS Bluetooth 4.2 und die Bluetooth LE Data Length Extension (Bluetooth LE-Datenlängenerweiterung) unterstützen Abschnitt 7.4.3.
[C-1-19] Der Direktkanaltyp muss für alle folgenden Standardsensortypen unterstützt und korrekt erfasst werden:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR] Es wird DRINGEND empfohlen, den Direktkanaltyp TYPE_HARDWARE_BUFFER für alle oben aufgeführten Direktkanaltypen zu unterstützen.
[C-1-21] MUSS die Anforderungen an Gyroskop, Beschleunigungsmesser und Magnetometer für android.hardware.hifi_sensors erfüllen, wie in Abschnitt 7.3.9 angegeben.
[C-SR] Es wird DRINGEND empfohlen, die Funktion android.hardware.sensor.hifi_sensors zu unterstützen.
[C-1-22] Die End-to-End-Bewegungs-zu-Photon-Latenz darf maximal 28 Millisekunden betragen.
[C-SR] Es wird DRINGEND empfohlen, dass die End-to-End-Latenz von Bewegung zu Photon nicht mehr als 20 Millisekunden beträgt.
[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 stabilen Zustand, MUSS mindestens 85 % betragen.
[C-SR] Es wird DRINGEND empfohlen, dass das Verhältnis des ersten Frames mindestens 90 % beträgt.
KANN einen exklusiven Kern für die Anwendung im Vordergrund bereitstellen und KANN die Process.getExclusiveCores API unterstützen, um die Anzahl der CPU-Kerne zurückzugeben, die exklusiv für die oberste Anwendung im Vordergrund sind.

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

[C-2-1] Es dürfen keine anderen Prozesse im Userspace darauf ausgeführt werden (außer Gerätetreibern, die von der Anwendung verwendet werden). Es dürfen jedoch bei Bedarf einige Kernelprozesse ausgeführt werden.

7.10. Haptik

Gerätespezifische Anforderungen finden Sie unter 2.2.1.

7.11. Leistungsklasse für Medien

Die Medienleistungsklasse der Geräteimplementierung kann über die android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API abgerufen werden. Die Anforderungen für die Medienleistung werden für jede Android-Version ab R (Version 30) definiert. Der spezielle Wert „0“ gibt an, dass das Gerät keiner Leistungsklasse für Medien zugewiesen ist.

Wenn Geräteimplementierungen für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS einen Wert ungleich Null zurückgeben, gilt Folgendes:

[C-1-1] MUSS mindestens den Wert android.os.Build.VERSION_CODES.R zurückgeben.
[C-1-2] MUSS eine Implementierung für ein Mobilgerät sein.
[C-1-3] MÜSSEN alle Anforderungen für die „Media Performance Class“ erfüllen, die in Abschnitt 2.2.7 beschrieben sind.

Gerätespezifische Anforderungen finden Sie unter Abschnitt 2.2.7.

8. Leistung und Akkulaufzeit

Einige Mindestanforderungen an Leistung und Stromverbrauch sind entscheidend für die Nutzerfreundlichkeit und wirken sich auf die Grundannahmen aus, die Entwickler bei der Entwicklung einer App haben.

8.1. Einheitliche Nutzererfahrung

Eine flüssige Benutzeroberfläche kann für den Endnutzer bereitgestellt werden, wenn bestimmte Mindestanforderungen für eine gleichbleibende Framerate und Reaktionszeiten für Anwendungen und Spiele erfüllt werden. Geräteimplementierungen können je nach Gerätetyp messbare Anforderungen an die Latenz der Benutzeroberfläche und die Aufgabenübergabe haben, wie in Abschnitt 2 beschrieben.

8.2. Leistung des Datei-E/A-Zugriffs

Wenn eine gemeinsame Baseline für eine konsistente Dateizugriffsleistung im privaten Datenspeicher der Anwendung (/data-Partition) bereitgestellt wird, können App-Entwickler angemessene Erwartungen stellen, die ihrem Softwaredesign helfen. Je nach Gerätetyp können für die folgenden Lese- und Schreibvorgänge bestimmte Anforderungen gelten, die in Abschnitt 2 beschrieben sind:

Sequenzielle Schreibleistung Gemessen beim Schreiben einer 256 MB großen Datei mit einem 10 MB großen Schreibpuffer.
Zufallsschreibleistung Gemessen beim Schreiben einer 256 MB großen Datei mit einem Schreibpuffer von 4 KB.
Sequenzielle Leseleistung Gemessen beim Lesen einer 256 MB großen Datei mit einem 10 MB großen Schreibpuffer.
Leistung bei zufälligen Lesezugriffen Gemessen beim Lesen einer 256 MB großen Datei mit einem Schreibpuffer von 4 KB.

8.3. Energiesparmodi

Wenn Geräteimplementierungen Funktionen zur Verbesserung der Geräteenergieverwaltung enthalten, die in AOSP enthalten sind (z.B. App-Standby-Bucket, Doze), oder die Funktionen erweitern, die keine strengeren Einschränkungen als der seltene App-Standby-Bucket anwenden, gelten folgende Anforderungen:

[C-1-1] Die Trigger-, Wartungs- und Weckalgorithmen sowie die Verwendung der globalen Systemeinstellungen der Energiesparmodi „App Standby“ und „Doze“ DÜRFEN NICHT von der AOSP-Implementierung abweichen.
[C-1-2] Die Verwendung globaler Einstellungen zur Verwaltung der Drosselung von Jobs, Weckern und Netzwerken für Apps in jedem Bucket für den App-Standby 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] Es MÜSSEN App-Standby-Buckets und Doze wie unter Energieverwaltung beschrieben implementiert werden.
[C-1-5] true muss für PowerManager.isPowerSaveMode() zurückgegeben werden, wenn sich das Gerät im Energiesparmodus befindet.
[C-SR] Es wird EMPFOHLEN, Nutzern 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 die Geräteimplementierungen die in AOSP enthaltenen Energieverwaltungsfunktionen erweitern und diese Erweiterung strengere Einschränkungen als der Bucket „Seltene App im Ruhemodus“ vorsieht, lesen Sie den Abschnitt 3.5.1.

Zusätzlich zu den Energiesparmodi können Android-Geräteimplementierungen einen oder alle vier Ruhemodi implementieren, die von der Advanced Configuration and Power Interface (ACPI) definiert sind.

Wenn Geräteimplementierungen die von ACPI definierten S4-Energiesparzustände implementieren, gilt Folgendes:

[C-1-1] Dieser Status darf nur dann erreicht werden, wenn der Nutzer eine explizite Aktion ausgeführt hat, um das Gerät in den Inaktivitätsstatus zu versetzen (z.B. durch Schließen eines Deckels, der physisch zum Gerät gehört, oder durch Ausschalten eines Fahrzeugs oder Fernsehers) und bevor der Nutzer das Gerät wieder aktiviert (z.B. durch Öffnen des Deckels oder Einschalten des Fahrzeugs oder Fernsehers).

Wenn Geräteimplementierungen die von ACPI definierten S3-Energiesparzustände implementieren, gilt Folgendes:

[C-2-1] MUSS C-1-1 oben erfüllen oder MUSS den S3-Zustand nur dann eintreten, wenn Anwendungen von Drittanbietern die Systemressourcen (z.B. den Bildschirm, die CPU) nicht benötigen.

Umgekehrt muss der S3-Status beendet werden, wenn Anwendungen von Drittanbietern die Systemressourcen benötigen, wie in diesem SDK beschrieben.

Wenn die Drittanbieteranwendungen beispielsweise anfordern, dass der Bildschirm über FLAG_KEEP_SCREEN_ON eingeschaltet oder die CPU über PARTIAL_WAKE_LOCK laufen soll, darf das Gerät NICHT in den S3-Zustand wechseln, es sei denn, der Nutzer hat wie in C-1-1 beschrieben ausdrücklich eine Aktion ausgeführt, um das Gerät in den Inaktivitätsstatus zu versetzen. Umgekehrt muss das Gerät den S3-Status verlassen, wenn eine Aufgabe ausgelöst wird, die von Drittanbieter-Apps über JobScheduler implementiert wird, oder wenn Firebase Cloud Messaging an Drittanbieter-Apps gesendet wird, es sei denn, der Nutzer hat das Gerät in den Inaktivitätsstatus versetzt. Dies sind keine umfassenden Beispiele. AOSP implementiert umfangreiche Wecksignale, die einen Aufweckvorgang aus diesem Zustand auslösen.

8.4. Stromverbrauchserfassung

Eine genauere Erfassung und Berichterstellung des Energieverbrauchs bietet App-Entwicklern sowohl Anreize als auch Tools, um den Energieverbrauch der App zu optimieren.

Geräteimplementierungen:

[SR] Es wird dringend empfohlen, ein Energieprofil pro Komponente anzugeben, das den aktuellen Verbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch definiert, der durch die Komponenten im Laufe der Zeit verursacht wird, wie auf der Website des Android Open Source Project dokumentiert.
[SR] Es wird DRINGEND empfohlen, alle Werte für den Energieverbrauch in Milliamperestunden (mAh) anzugeben.
[SR] Es wird dringend empfohlen, die CPU-Stromaufnahme pro UID des Prozesses zu erfassen. Das Android Open Source Project erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
[SR] Es wird dringend empfohlen, diese Stromnutzung über den Shell-Befehl adb shell dumpsys batterystats für den App-Entwickler verfügbar zu machen.
SOLLTE der Hardwarekomponente selbst zugeordnet werden, wenn die Stromaufnahme der Hardwarekomponente keiner Anwendung zugeordnet werden kann.

8.5. Konstante Leistung

Bei leistungsstarken, lang laufenden Apps kann die Leistung stark schwanken, entweder aufgrund anderer Apps, die im Hintergrund ausgeführt werden, oder aufgrund der CPU-Drosselung aufgrund von Temperaturlimits. Android bietet programmatische Schnittstellen, mit denen die führende Anwendung im Vordergrund das System bitten kann, die Ressourcenzuweisung zu optimieren, um solche Schwankungen zu beheben.

Geräteimplementierungen:

[C-0-1] Die Unterstützung des Modus für nachhaltige Leistung MUSS korrekt über die API-Methode PowerManager.isSustainedPerformanceModeSupported() gemeldet werden.
MÜSSEN den Modus für dauerhafte Leistung unterstützen.

Wenn Geräteimplementierungen den Modus für nachhaltige Leistung unterstützen, gilt Folgendes:

[C-1-1] Die führende App im Vordergrund MUSS mindestens 30 Minuten lang eine gleichbleibende Leistung bieten, wenn die App dies anfordert.
[C-1-2] MUSS die Window.setSustainedPerformanceMode() API und andere zugehörige APIs einhalten.

Wenn Geräteimplementierungen zwei oder mehr CPU-Kerne umfassen, haben sie folgende Vorteile:

Es sollte mindestens einen exklusiven Kern geben, der von der führenden Anwendung im Vordergrund reserviert werden kann.

Wenn die Geräteimplementierungen das Reservieren eines exklusiven Kerns für die führende Anwendung im Vordergrund unterstützen, gilt Folgendes:

[C-2-1] MÜSSEN über die Process.getExclusiveCores() API-Methode die ID-Nummern der exklusiven Kerne melden, die von der App im Vordergrund reserviert werden können.
[C-2-2] Es dürfen KEINE Prozesse im Nutzerbereich außer den von der Anwendung verwendeten Gerätetreibern auf den exklusiven Kernen ausgeführt werden. Es KÖNNEN jedoch einige Kernelprozesse nach Bedarf ausgeführt werden.

Wenn Geräteimplementierungen keinen exklusiven Kern unterstützen, gilt Folgendes:

[C-3-1] MÜSSEN über die API-Methode Process.getExclusiveCores() eine leere Liste zurückgeben.

9. Kompatibilität des Sicherheitsmodells

Geräteimplementierungen:

[C-0-1] Es MUSS ein Sicherheitsmodell implementiert werden, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument zu Sicherheit und Berechtigungen in den APIs in der Android-Entwicklerdokumentation definiert.
[C-0-2] Die Installation selbst signierter Anwendungen MUSS unterstützt werden, ohne dass zusätzliche Berechtigungen/Zertifikate von Dritten/Behörden erforderlich sind. Insbesondere müssen kompatible Geräte die in den folgenden Unterabschnitten beschriebenen Sicherheitsmechanismen unterstützen.

9.1. Berechtigungen

Geräteimplementierungen:

[C-0-1] MUSS das Android-Berechtigungsmodell unterstützen, wie in der Android-Entwicklerdokumentation definiert. Insbesondere MÜSSEN alle Berechtigungen erzwungen werden, die in der SDK-Dokumentation beschrieben sind. Keine Berechtigungen dürfen ausgelassen, geändert oder ignoriert werden.
Es dürfen zusätzliche Berechtigungen hinzugefügt werden, sofern die neuen Berechtigungs-ID-Strings nicht zum Namespace android.\* gehören.
[C-0-2] Berechtigungen mit einer protectionLevel von PROTECTION_FLAG_PRIVILEGED DÜRFEN nur Apps gewährt werden, die im privilegierten Pfad bzw. den privilegierten Pfaden des System-Images vorinstalliert sind, und nur innerhalb der Teilmenge der Berechtigungen, die für jede App ausdrücklich auf die Zulassungsliste gesetzt wurden. Die AOSP-Implementierung erfüllt diese Anforderung, indem sie die Berechtigungen auf der Zulassungsliste für jede App aus den Dateien im Pfad etc/permissions/ liest und den Pfad system/priv-app als privilegierten Pfad verwendet.

Berechtigungen mit dem Schutzniveau „Schädlich“ sind Laufzeitberechtigungen. Anwendungen mit targetSdkVersion > 22 fordern sie zur Laufzeit an.

Geräteimplementierungen:

[C-0-3] Es MUSS eine spezielle Benutzeroberfläche geben, über die der Nutzer entscheiden kann, ob er die angeforderten Laufzeitberechtigungen gewähren möchte. Außerdem muss es eine Benutzeroberfläche geben, über die der Nutzer die Laufzeitberechtigungen verwalten kann.
[C-0-4] Es MUSS eine und nur eine Implementierung der beiden Benutzeroberflächen geben.
[C-0-5] Vorinstallierten Apps DÜRFEN KEINE Laufzeitberechtigungen gewährt werden, es sei denn:
- Die Einwilligung des Nutzers kann eingeholt werden, bevor die Anwendung sie verwendet.
- Die Laufzeitberechtigungen sind mit einem Intent-Muster verknüpft, für das die vorinstallierte Anwendung als Standard-Handler festgelegt ist.
[C-0-6] Die Berechtigung android.permission.RECOVER_KEYSTORE darf nur System-Apps gewährt werden, die einen ordnungsgemäß gesicherten Wiederherstellungs-Agenten registrieren. Ein ordnungsgemäß gesicherter Wiederherstellungsagent wird als On-Device-Softwareagent definiert, der mit einem Remote-Speicher außerhalb des Geräts synchronisiert wird. Dieser Remote-Speicher muss mit sicherer Hardware ausgestattet sein, die einen Schutz bietet, der dem im Google Cloud Key Vault-Dienst beschriebenen Schutz entspricht oder darüber hinausgeht, um Brute-Force-Angriffe auf den Wissensfaktor des Sperrbildschirms zu verhindern.

Geräteimplementierungen:

[C-0-7] Die Eigenschaften der Android-Standortberechtigung MÜSSEN eingehalten werden, wenn eine App Standort- oder Daten zu körperlichen Aktivitäten über die standardmäßige Android API oder einen proprietären Mechanismus anfordert. Dazu gehören unter anderem:
- Standort des Geräts (z. B. Breiten- und Längengrad)
- Informationen, mit denen der Standort des Geräts bestimmt oder geschätzt werden kann (z.B. SSID, BSSID, Zellen-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 bieten folgende Vorteile:

[C-0-8] Es MUSS die Einwilligung der Nutzer eingeholt werden, damit eine App auf die Standort- oder Aktivitätsdaten zugreifen kann.
[C-0-9] Eine Laufzeitberechtigung darf NUR der App gewährt werden, die die im SDK beschriebene ausreichende Berechtigung hat. Beispiel: Für TelephonyManager#getServiceState ist android.permission.ACCESS_FINE_LOCATION erforderlich.

Berechtigungen können als eingeschränkt gekennzeichnet werden, um ihr Verhalten zu ändern.

[C-0-10] Berechtigungen, die mit dem Flag hardRestricted gekennzeichnet sind, DÜRFEN einer App NICHT gewährt werden, es sei denn:
- Eine APK-Datei der App befindet sich in der Systempartition.
- Der Nutzer weist einer App eine Rolle zu, die mit den hardRestricted-Berechtigungen verknüpft ist.
- Das Installationsprogramm gewährt der App die hardRestricted.
- Eine App erhält die hardRestricted in einer früheren Android-Version.
[C-0-11] Apps mit einer softRestricted-Berechtigung DÜRFEN nur eingeschränkten Zugriff erhalten und KÖNNEN keinen vollen Zugriff erhalten, bis sie wie im SDK beschrieben auf die Zulassungsliste gesetzt wurden. Dort werden für jede softRestricted-Berechtigung (z. B. READ_EXTERNAL_STORAGE) „Vollständiger Zugriff“ und „Eingeschränkter Zugriff“ definiert.

Wenn Geräteimplementierungen Nutzern die Möglichkeit bieten, auszuwählen, welche Apps mit einer Aktivität, die die ACTION_MANAGE_OVERLAY_PERMISSION-Intention verarbeitet, über anderen Apps zeichnen können, gilt Folgendes:

[C-2-1] Alle Aktivitäten mit Intent-Filtern für den Intent ACTION_MANAGE_OVERLAY_PERMISSION MÜSSEN denselben UI-Bildschirm haben, unabhängig von der auslösenden App oder den von ihr bereitgestellten Informationen.

9.2. UID und Prozessisolierung

Geräteimplementierungen:

[C-0-1] MUSS das Android-Sandbox-Modell für Anwendungen unterstützen, bei dem jede Anwendung als eindeutige UID im Unix-Stil und in einem separaten Prozess ausgeführt wird.
[C-0-2] MUSS das Ausführen mehrerer Anwendungen mit derselben Linux-Nutzer-ID unterstützen, sofern die Anwendungen wie in der Referenz zu Sicherheit und Berechtigungen definiert korrekt signiert und erstellt sind.

9.3. Dateisystemberechtigungen

Geräteimplementierungen:

[C-0-1] MUSS das Android-Modell für Dateizugriffsberechtigungen 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 einhalten, auch wenn sie Laufzeitumgebungen enthalten, in denen Anwendungen mit einer anderen Software oder Technologie als dem Dalvik-Ausführformat oder nativem Code ausgeführt werden. Mit anderen Worten:

[C-0-1] Alternative Laufzeiten MÜSSEN selbst Android-Anwendungen sein und dem standardmäßigen Android-Sicherheitsmodell entsprechen, wie in Abschnitt 9 beschrieben.
[C-0-2] Alternanten dürfen KEIN Zugriff auf Ressourcen gewährt werden, die durch Berechtigungen geschützt sind, die nicht über den Mechanismus <uses-permission> in der AndroidManifest.xml-Datei der Runtime angefordert wurden.
[C-0-3] Alternative Laufzeiten DÜRFEN Anwendungen nicht die Nutzung von Funktionen erlauben, die durch Android-Berechtigungen geschützt sind, die auf Systemanwendungen beschränkt sind.
[C-0-4] Alternative Laufzeiten MÜSSEN dem Android-Sandbox-Modell entsprechen. Installierte Anwendungen, die eine alternative Laufzeit verwenden, DÜRFEN die Sandbox einer anderen auf dem Gerät installierten App NICHT wiederverwenden, es sei denn, dies geschieht über die standardmäßigen Android-Mechanismen für freigegebene Nutzer-IDs und Signaturzertifikate.
[C-0-5] Alternative Laufzeiten dürfen NICHT mit den Sandboxes anderer Android-Anwendungen gestartet werden, ihnen NICHT Zugriff auf diese Sandboxes gewähren oder Zugriff auf diese Sandboxes erhalten.
[C-0-6] Alternative Laufzeiten dürfen NICHT mit Berechtigungen des Superusers (Root) oder einer anderen Nutzer-ID gestartet werden, ihnen dürfen NICHT Berechtigungen des Superusers (Root) oder einer anderen Nutzer-ID gewährt werden und sie dürfen anderen Anwendungen KEINE Berechtigungen des Superusers (Root) oder einer anderen Nutzer-ID gewähren.
[C-0-7] Wenn die .apk-Dateien der alternativen Laufzeiten im System-Image der Geräteimplementierungen enthalten sind, MÜSSEN sie mit einem anderen Schlüssel signiert werden als der Schlüssel, mit dem andere Anwendungen signiert wurden, die in den Geräteimplementierungen enthalten sind.
[C-0-8] Bei der Installation von Anwendungen MÜSSEN alternative Laufzeiten die Nutzereinwilligung für die von der Anwendung verwendeten Android-Berechtigungen einholen.
[C-0-9] Wenn eine Anwendung eine Geräteressource verwenden muss, für die es eine entsprechende Android-Berechtigung gibt (z. B. Kamera, GPS usw.), MUSS die alternative Laufzeit den Nutzer darüber informieren, dass die Anwendung auf diese Ressource zugreifen kann.
[C-0-10] Wenn die Laufzeitumgebung die Anwendungsfunktionen nicht auf diese Weise aufzeichnet, MUSS die Laufzeitumgebung bei der Installation einer Anwendung, die diese Laufzeit verwendet, alle Berechtigungen auflisten, die der Laufzeit selbst zugewiesen sind.
Alternative Laufzeiten MÜSSEN Apps über die PackageManager in separaten Android-Sandboxes (z. B. Linux-Nutzer-IDs) installieren.
Alternative Laufzeiten KÖNNEN eine einzelne Android-Sandbox bereitstellen, die von allen Anwendungen gemeinsam genutzt wird, die die alternative Laufzeit verwenden.

9.5. Unterstützung mehrerer Nutzer

Android unterstützt mehrere Nutzer und bietet eine vollständige Nutzerisolierung.

Bei Geräteimplementierungen kann, aber sollte die Mehrfachnutzung NICHT aktiviert werden, wenn Wechseldatenträger als primärer externer Speicher verwendet werden.

Wenn Geräteimplementierungen mehrere Nutzer umfassen, gilt Folgendes:

[C-1-1] MUSS die folgenden Anforderungen im Zusammenhang mit der Unterstützung mehrerer Nutzer erfüllen.
[C-1-2] Es MUSS für jeden Nutzer ein Sicherheitsmodell implementiert werden, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument zu Sicherheit und Berechtigungen in den APIs definiert.
[C-1-3] Es MUSS für jede Nutzerinstanz separate und isolierte Verzeichnisse für den freigegebenen Anwendungsspeicher (auch /sdcard genannt) geben.
[C-1-4] Es MUSS sichergestellt sein, dass Anwendungen, die einem bestimmten Nutzer gehören und im Namen dieses Nutzers ausgeführt werden, die Dateien anderer Nutzer nicht auflisten, lesen oder darauf 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 Mehrfachnutzung aktiviert ist, und zwar mit einem Schlüssel, der nur auf nicht entfernbaren Medien gespeichert ist, auf die nur das System zugreifen kann, wenn die Geräteimplementierungen für die externen Speicher-APIs entfernbare Medien verwenden. Da die Medien dadurch für einen Host-PC unlesbar werden, müssen Geräteimplementierungen zu MTP oder einem ähnlichen System wechseln, um Host-PCs Zugriff auf die Daten des aktuellen Nutzers zu gewähren.

9.6. Warnung zu Premium-SMS

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

Wenn Geräteimplementierungen die Unterstützung von android.hardware.telephony angeben, gilt Folgendes:

[C-1-1] Nutzer MÜSSEN vor dem Senden einer SMS an Nummern gewarnt werden, die durch reguläre Ausdrücke identifiziert werden, die in der Datei /data/misc/sms/codes.xml auf dem Gerät definiert sind. Das Upstream-Android-Open-Source-Projekt 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 Mandatory Access Control-System (MAC) von Security-Enhanced Linux (SELinux), Seccomp-Sandboxing und andere Sicherheitsfunktionen im Linux-Kernel nutzen. Geräteimplementierungen:

[C-0-1] Die Kompatibilität mit vorhandenen Anwendungen MUSS erhalten bleiben, auch wenn SELinux oder andere Sicherheitsfunktionen unter dem Android-Framework implementiert sind.
[C-0-2] Es darf KEINE sichtbare Benutzeroberfläche geben, wenn ein Sicherheitsverstoß erkannt und durch die Sicherheitsfunktion, die unter dem Android-Framework implementiert ist, erfolgreich blockiert wird. Es kann jedoch eine sichtbare Benutzeroberfläche geben, wenn ein nicht blockierter Sicherheitsverstoß auftritt, der zu einer erfolgreichen Ausnutzung führt.
[C-0-3] SELinux oder andere Sicherheitsfunktionen, die unter dem Android-Framework implementiert sind, dürfen NICHT für Nutzer oder App-Entwickler konfigurierbar sein.
[C-0-4] Es DARF nicht möglich sein, dass eine Anwendung, die sich über eine API (z. B. eine Device Administration API) auf eine andere Anwendung auswirken kann, eine Richtlinie konfiguriert, 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 eingegrenzt werden kann, wie auf der Website des Android Open Source Project beschrieben.
[C-0-6] Es MUSS ein Kernel-Sandboxing-Mechanismus für Anwendungen implementiert werden, der das Filtern von Systemaufrufen mithilfe einer konfigurierbaren Richtlinie aus mehrstufigen Programmen ermöglicht. Das Upstream-Android Open Source Project erfüllt diese Anforderung durch die Aktivierung von seccomp-BPF mit Threadgruppensynchronisierung (TSYNC), wie im Abschnitt „Kernel Configuration“ (Kernelkonfiguration) von source.android.com beschrieben.

Kernelintegrität und Selbstschutzfunktionen sind ein wesentlicher Bestandteil der Android-Sicherheit. Geräteimplementierungen:

[C-0-7] Es MÜSSEN Schutzmechanismen für Kernel-Stack-Buffer-Overflows implementiert werden. Beispiele für solche Mechanismen sind CC_STACKPROTECTOR_REGULAR und CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] Es MÜSSEN strenge Kernel-Speicherschutzmaßnahmen implementiert werden, bei denen ausführbarer Code nur lesbar, schreibgeschützte Daten nicht ausführbar und nicht beschreibbar 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 Prüfung der Grenzwerte für die statische und dynamische Objektgröße bei Kopien zwischen Userspace und Kernelspace (z.B. CONFIG_HARDENED_USERCOPY) implementiert sein.
[C-0-10] Der User-Space-Speicher darf NICHT ausgeführt werden, wenn die Ausführung im Kernel-Modus erfolgt (z.B. Hardware-PXN oder über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN emuliert) auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden.
[C-0-11] Auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden, darf außerhalb der normalen APIs für den Usercopy-Zugriff (z.B. Hardware-PAN oder über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN emuliert) KEIN Nutzerspeicher im Kernel gelesen oder geschrieben werden.
[C-0-12] 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), MUSS die Kernel-Seitentabellenisolation implementiert werden, wenn die Hardware anfällig für CVE-2017-5754 ist.
[C-0-13] Auf allen Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden (z.B. CONFIG_HARDEN_BRANCH_PREDICTOR), MUSS eine Branch-Prediction-Härtung implementiert werden, wenn die Hardware 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 Kernelcodes und des Arbeitsspeichers zufällig zu generieren und Sicherheitslücken zu vermeiden, die die Zufallsgenerierung beeinträchtigen würden (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 Control Flow Integrity (CFI) im Kernel zu aktivieren, um zusätzlichen Schutz vor Code-Reuse-Angriffen (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, bei denen diese Funktionen aktiviert sind.
[C-SR] Es wird DRINGEND empfohlen, CFI, SCS und IntSan für alle zusätzlichen sicherheitssensiblen Nutzerbereichskomponenten zu aktivieren, wie unter CFI und IntSan erläutert.
[C-SR] Es wird DRINGEND empfohlen, die Stack-Initialisierung im Kernel zu aktivieren, um die Verwendung nicht initialisierter Lokalvariablen (CONFIG_INIT_STACK_ALL oder CONFIG_INIT_STACK_ALL_ZERO) zu verhindern. Außerdem DÜRFEN Geräteimplementierungen NICHT den Wert annehmen, der vom Compiler zum Initialisieren der Lokalvariablen 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. Der Wert, der vom Kernel zum Initialisieren dieser Zuweisungen verwendet wird, sollte NICHT angenommen werden.

Wenn bei Geräteimplementierungen ein Linux-Kernel verwendet wird, gilt Folgendes:

[C-1-1] SELinux MUSS implementiert sein.
[C-1-2] SELinux MUSS auf den globalen Erzwingungsmodus gesetzt werden.
[C-1-3] Alle Domains MÜSSEN im Erzwingungsmodus konfiguriert werden. Domains im permissiven Modus sind nicht zulässig, einschließlich geräte-/anbieterspezifischer Domains.
[C-1-4] Die im Ordner „system/sepolicy“ des Upstream-Android Open Source Project (AOSP) enthaltenen Neverallow-Regeln DÜRFEN NICHT geändert, weggelassen oder ersetzt werden. 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] Drittanbieteranwendungen, die auf API-Ebene 28 oder höher ausgeführt werden, MÜSSEN in SELinux-Sandboxes pro Anwendung mit SELinux-Einschränkungen pro Anwendung im privaten Datenverzeichnis der jeweiligen Anwendung ausgeführt werden.
MÜSSEN die Standard-SELinux-Richtlinie im Ordner „system/sepolicy“ des Upstream-Android-Open-Source-Projekts beibehalten und diese Richtlinie nur für die eigene gerätespezifische Konfiguration ergänzen.

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 Systemsoftwareupdate erfüllt werden können, KÖNNEN sie von diesen Anforderungen ausgenommen werden.

Wenn für Geräteimplementierungen ein anderer Kernel als Linux verwendet wird, gilt Folgendes:

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

Android bietet mehrere Funktionen für die abgestufte Sicherheit, die für die Gerätesicherheit unerlässlich sind.

9.8. Datenschutz

9.8.1. Nutzungsverlauf

Android speichert die bisherigen Auswahlen des Nutzers und verwaltet diese über UsageStatsManager.

Geräteimplementierungen:

[C-0-1] Der Nutzerverlauf muss für einen angemessenen Zeitraum aufbewahrt werden.
[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-IDs und verwaltet diesen Verlauf über die StatsManager- und die IncidentManager-System-API.

Geräteimplementierungen:

[C-0-2] Der von der System API-Klasse IncidentManager erstellte Vorfallbericht DARF nur die mit DEST_AUTOMATIC gekennzeichneten Felder enthalten.
[C-0-3] Die Systemereignis-IDs dürfen NICHT zum Logging anderer Ereignisse als der in den SDK-Dokumenten von StatsLog beschriebenen verwendet werden. Wenn zusätzliche Systemereignisse protokolliert werden, kann eine andere Atom-ID im Bereich zwischen 100.000 und 200.000 verwendet werden.

9.8.2. Aufnahme läuft

Geräteimplementierungen:

[C-0-1] Softwarekomponenten dürfen NICHT vorinstalliert oder ohne vorherige Benachrichtigung und ohne Zustimmung des Nutzers verteilt werden, die personenbezogene Daten des Nutzers (z.B. Tastenanschläge, auf dem Bildschirm angezeigter Text, Fehlerberichte) vom Gerät senden.
[C-0-2] Es MUSS eine explizite Nutzereinwilligung eingeholt werden, die es erlaubt, alle vertraulichen Informationen zu erfassen, die auf dem Bildschirm des Nutzers angezeigt werden, wenn die Bildschirmübertragung oder -aufzeichnung über MediaProjection oder proprietäre APIs aktiviert ist. Es DARF Nutzern NICHT möglich sein, die zukünftige Anzeige der Nutzereinwilligung zu deaktivieren.
[C-0-3] Während der Bildschirmübertragung oder Bildschirmaufzeichnung MUSS dem Nutzer eine laufende Benachrichtigung angezeigt werden. AOSP erfüllt diese Anforderung, indem in der Statusleiste ein Symbol für eine laufende Benachrichtigung angezeigt wird.

Wenn Geräteimplementierungen Funktionen im System enthalten, die entweder den auf dem Bildschirm angezeigten Inhalt erfassen und/oder den auf dem Gerät wiedergegebenen Audiostream aufzeichnen, und dies nicht über die System API ContentCaptureService oder andere proprietäre Mittel erfolgt, die in Abschnitt 9.8.6 Inhaltserfassung beschrieben sind, gelten folgende Einschränkungen:

[C-1-1] Der Nutzer muss ständig benachrichtigt werden, wenn diese Funktion aktiviert ist und aktiv Daten erfasst oder aufzeichnet.

Wenn Geräteimplementierungen eine standardmäßig aktivierte Komponente enthalten, die Umgebungsaudio und/oder die auf dem Gerät wiedergegebene Audioaufnahmen aufzeichnen kann, um nützliche Informationen über den Kontext des Nutzers zu gewinnen, gilt Folgendes:

[C-2-1] Die aufgezeichneten Roh-Audiodaten oder ein Format, das in das ursprüngliche Audioformat oder ein ähnliches Format umgewandelt werden kann, DÜRFEN NICHT im dauerhaften Gerätespeicher 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 des USB-Peripheriemodus haben, gilt Folgendes:

[C-1-1] Es MUSS eine Benutzeroberfläche angezeigt werden, auf der die Einwilligung des Nutzers eingeholt wird, bevor der Zugriff auf den Inhalt des freigegebenen Speichers über den USB-Anschluss gewährt wird.

9.8.4. Netzwerkverkehr

Geräteimplementierungen:

[C-0-1] MÜSSEN dieselben Stammzertifikate für den vom System als vertrauenswürdig eingestuften CA-Speicher (Zertifizierungsstelle) vorinstalliert werden, wie sie im Upstream-Android Open Source Project zur Verfügung gestellt werden.
[C-0-2] MUSS mit einem leeren Nutzer-Stamm-CA-Speicher geliefert werden.
[C-0-3] Dem Nutzer muss eine Warnung angezeigt werden, dass der Netzwerkverkehr überwacht werden kann, wenn eine Nutzer-Root-Zertifizierungsstelle hinzugefügt wird.

Wenn der Geräteverkehr über ein VPN geleitet wird, gilt für Geräteimplementierungen Folgendes:

[C-1-1] Es MUSS dem Nutzer eine Warnung angezeigt werden, die entweder Folgendes angibt:
- Dieser Netzwerkverkehr kann überwacht werden.
- Dieser Netzwerkverkehr wird über die VPN-Anwendung geleitet, die das VPN bereitstellt.

Wenn Geräteimplementierungen einen Mechanismus haben, der standardmäßig aktiviert ist und Netzwerkdatenverkehr über einen Proxyserver oder ein VPN-Gateway leitet (z. B. das Vorladen eines VPN-Dienstes mit android.permission.CONTROL_VPN), gilt Folgendes:

[C-2-1] Es MUSS die Einwilligung des Nutzers eingeholt werden, bevor dieser Mechanismus aktiviert wird, es sei denn, das VPN wird vom Device Policy Controller über die DevicePolicyManager.setAlwaysOnVpnPackage() aktiviert. In diesem Fall muss der Nutzer keine separate Einwilligung erteilen, sondern MUSS nur benachrichtigt werden.

Wenn bei Geräteimplementierungen eine Nutzerfunktion zum Aktivieren der Funktion „Durchgehend aktives VPN“ einer VPN-App von Drittanbietern implementiert ist, müssen folgende Anforderungen erfüllt sein:

[C-3-1] Diese Nutzerfunktion für Apps, die keinen durchgehend aktiven VPN-Dienst unterstützen, MUSS in der Datei AndroidManifest.xml deaktiviert werden. Dazu muss das Attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON auf false festgelegt werden.

9.8.5. Geräte-IDs

Geräteimplementierungen:

[C-0-1] Der Zugriff auf die Geräteseriennummer und gegebenenfalls die IMEI/MEID, die SIM-Seriennummer und die International Mobile Subscriber Identity (IMSI) muss von einer App verhindert werden, es sei denn, sie erfüllt eine der folgenden Anforderungen:
- ist eine signierte Mobilfunkanbieter-App, die von Geräteherstellern geprüft wird.
- wurde die Berechtigung READ_PRIVILEGED_PHONE_STATE gewährt.
- Mobilfunkanbieterberechtigungen gemäß UICC-Mobilfunkanbieterberechtigungen hat.
- ist ein Geräteinhaber oder Profilinhaber, dem die Berechtigung READ_PHONE_STATE gewährt wurde.
- (Nur für SIM-Seriennummer/ICCID) Gemäß den lokalen Bestimmungen muss die App Änderungen an der Identität des Abonnenten erkennen.

9.8.6. Inhalte erfassen

Android unterstützt über die System API ContentCaptureService oder andere proprietäre Mittel einen Mechanismus für Geräteimplementierungen, mit dem die folgenden Interaktionen zwischen den Anwendungen und dem Nutzer erfasst werden können.

Auf dem Bildschirm gerenderter Text und Grafiken, einschließlich, aber nicht beschränkt auf Benachrichtigungen und Assistenzdaten über die AssistStructure API.
Mediendaten wie Audio- oder Videoinhalte, die vom Gerät aufgezeichnet oder wiedergegeben werden.
Eingabeereignisse (z. B. Tastatur, Maus, Geste, Sprache, Video und Barrierefreiheit)
Alle anderen Ereignisse, die eine Anwendung über die Content Capture API oder eine ähnliche proprietäre API an das System sendet.
Text oder andere Daten, die über TextClassifier API an den System TextClassifier gesendet werden, d. h. an den Systemdienst, um die Bedeutung von Text zu verstehen und anhand des Texts die nächsten Aktionen vorherzusagen.

Wenn Geräteimplementierungen die oben genannten Daten erfassen, gilt Folgendes:

[C-1-1] Alle derartigen Daten MÜSSEN verschlüsselt werden, wenn sie auf dem Gerät gespeichert werden. Diese Verschlüsselung kann mit der Android-Dateibasierten Verschlüsselung oder einer der im Cipher SDK für API-Version 26 und höher aufgeführten Chiffren durchgeführt werden.
[C-1-2] Es dürfen weder Rohdaten noch verschlüsselte Daten mit Android-Sicherungsmethoden oder anderen Sicherungsmethoden gesichert werden.
[C-1-3] Alle diese Daten und das Protokoll des Geräts MÜSSEN nur mit einem datenschutzfreundlichen Mechanismus gesendet werden. Der datenschutzfreundliche Mechanismus wird definiert als „eine Methode, die nur eine zusammengefasste Analyse zulässt und das Abgleichen von protokollierten Ereignissen oder abgeleiteten Ergebnissen mit einzelnen Nutzern verhindert“, um zu verhindern, dass Daten pro Nutzer eingesehen werden können (z.B. mithilfe einer Technologie zur Differential Privacy wie RAPPOR).
[C-1-4] Solche Daten dürfen KEINE Nutzeridentität (z. B. Account) auf dem Gerät zugeordnet werden, es sei denn, die Nutzer haben bei jeder Verknüpfung der Daten ihre ausdrückliche Einwilligung erteilt.
[C-1-5] Solche Daten dürfen NICHT mit anderen Apps geteilt werden, es sei denn, es liegt jedes Mal eine ausdrückliche Nutzereinwilligung vor.
[C-1-6] Es MUSS Nutzern möglich sein, 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 sind.

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

[C-2-1] Nutzer dürfen den Dienst zur Erfassung von Inhalten NICHT durch eine vom Nutzer installierbare Anwendung oder einen vom Nutzer installierbaren Dienst ersetzen. Die Erfassung solcher Daten ist nur durch den vorinstallierten Dienst zulässig.
[C-2-2] Es DÜRFEN KEINE anderen Apps als der vorinstallierte Dienst zur Erfassung von Inhalten solche Daten erfassen.
[C-2-3] Es MUSS eine Nutzerfunktion zur Deaktivierung des Dienstes zur Erfassung von Inhalten geben.
[C-2-4] Es darf KEINE Option für Nutzer geben, die Android-Berechtigungen zu verwalten, die vom Dienst zur Erfassung von Inhalten gehalten werden, und es muss dem Android-Berechtigungsmodell gemäß Abschnitt 9.1 gefolgt werden. Berechtigung
[C-SR] Es wird DRINGEND empfohlen, die Dienstkomponenten zur Erfassung von Inhalten getrennt zu halten, z. B. den Dienst nicht zu binden oder Prozess-IDs nicht mit anderen Systemkomponenten zu teilen, mit folgenden Ausnahmen:
- Telefonie, Kontakte, System-UI und Medien

9.8.7. Zugriff auf die Zwischenablage

Geräteimplementierungen:

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

9.8.8. Standort

Geräteimplementierungen:

[C-0-1] Die Standorteinstellungen des Geräts und die WLAN-/Bluetooth-Sucheinstellungen dürfen NICHT ohne ausdrückliche Zustimmung des Nutzers oder Nutzereinleitung aktiviert oder deaktiviert werden.
[C-0-2] Nutzer MÜSSEN die Möglichkeit haben, auf standortbezogene Informationen zuzugreifen, einschließlich der letzten Standortanfragen, Berechtigungen auf App-Ebene und der Verwendung von WLAN-/Bluetooth-Scans zur Standortbestimmung.
[C-0-3] Es MUSS sichergestellt sein, dass die Anwendung, die die API „Emergency Location Bypass API“ [LocationRequest.setLocationSettingsIgnored()] verwendet, eine vom Nutzer initiierte Notfallsitzung ist (z.B. Anruf oder SMS an 911). Bei der Automobilbranche kann ein Fahrzeug jedoch eine Notfallsitzung ohne aktive Nutzerinteraktion starten, wenn ein Unfall erkannt wird (z.B. um die eCall-Anforderungen zu erfüllen).
[C-0-4] Die Funktion der Emergency Location Bypass API, die Standorteinstellungen des Geräts zu umgehen, ohne die Einstellungen zu ändern, MUSS erhalten bleiben.
[C-0-5] Es MUSS eine Benachrichtigung geplant werden, die den Nutzer daran erinnert, dass 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] Apps, die auf API-Level 30 oder höher ausgerichtet sind, DÜRFEN KEINE Details zu anderen installierten Apps offenlegen, es sei denn, die App kann bereits über die verwalteten APIs Details zu der anderen installierten App sehen. Dazu gehören unter anderem Details, die von benutzerdefinierten APIs offengelegt werden, die vom Geräteimplementierer hinzugefügt wurden, oder auf die über das Dateisystem zugegriffen werden kann.

9.8.10. Fehlerbericht zur Verbindung

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

[C-1-1] Es MUSS jedes Mal die Einwilligung des Nutzers eingeholt werden, wenn die System API BUGREPORT_MODE_TELEPHONY aufgerufen wird, um einen Bericht zu generieren. Der Nutzer darf NICHT aufgefordert werden, allen zukünftigen Anfragen der Anwendung zuzustimmen.
[C-1-2] Es MUSS eine explizite Nutzereinwilligung angezeigt und eingeholt werden, wenn die Berichte erstellt werden. Der generierte Bericht darf NICHT ohne explizite Nutzereinwilligung an die anfragende App zurückgegeben werden.
[C-1-3] Es MÜSSEN angeforderte Berichte erstellt werden, die mindestens die folgenden Informationen enthalten:
- TelephonyDebugService-Dump
- TelephonyRegistry-Dump
- WifiService-Dump
- ConnectivityService-Dump
- Ein Dump der CarrierService-Instanz des anrufenden Pakets (falls gebunden)
- Funkschnittstellen-Protokollpuffer
[C-1-4] Die generierten Berichte DÜRFEN NICHT Folgendes enthalten:
- Informationen, die nicht mit der Fehlerbehebung bei der Internetverbindung zusammenhängen.
- Alle Arten von Nutzerprotokollen zu Anwendungszugriffen oder detaillierte Profile von vom Nutzer installierten Anwendungen/Paketen (UIDs sind zulässig, Paketnamen nicht).
KANN zusätzliche Informationen enthalten, die nicht mit einer Nutzeridentität verknüpft sind. (z.B. Anbieterprotokolle).

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, müssen sie Folgendes tun:

[C-SR] Es wird DRINGEND empfohlen, die Standardeinstellung für eine Entwicklereinstellung auf „Deaktiviert“ festzulegen. Das AOSP erfüllt diese Anforderung, indem in den Entwicklereinstellungen die Option Enable verbose vendor logging zur Verfügung gestellt wird, um zusätzliche gerätespezifische Anbieterprotokolle in die Fehlerberichte aufzunehmen.

9.8.11. Freigabe von Daten-Blobs

Android ermöglicht es Apps über BlobStoreManager, Daten-Blobs zum System beizutragen, die für eine ausgewählte Gruppe von Apps freigegeben werden.

Wenn Geräteimplementierungen freigegebene Daten-Blobs wie in der SDK-Dokumentation beschrieben unterstützen, gilt Folgendes:

[C-1-1] Es dürfen KEINE Daten-Blobs von Apps freigegeben werden, die nicht erlaubt sind. Das bedeutet, dass der Umfang des Standardzugriffs und der anderen Zugriffsmodi, die mit BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() oder BlobStoreManager.session#allowPublicAccess() angegeben werden können, NICHT geändert werden darf. Die AOSP-Referenzimplementierung erfüllt diese Anforderungen.
[C-1-2] Die sicheren Hash-Werte von Data Chunks (die zur Zugriffssteuerung verwendet werden) DÜRFEN NICHT vom Gerät gesendet oder mit anderen Apps geteilt werden.

9.9. Datenspeicherverschlüsselung

Alle Geräte MÜSSEN die Anforderungen von Abschnitt 9.9.1 erfüllen. Geräte, die mit einem früheren API-Level als dem in diesem Dokument aufgeführten eingeführt wurden, sind von den Anforderungen in den Abschnitten 9.9.2 und 9.9.3 ausgenommen. Stattdessen MÜSSEN sie die Anforderungen in Abschnitt 9.9 der Android Compatibility Definition (Definition der Android-Kompatibilität) erfüllen, die dem API-Level entsprechen, mit dem das Gerät eingeführt wurde.

9.9.1. Direct Boot

Geräteimplementierungen:

[C-0-1] Die APIs für den Direktstartmodus MÜSSEN implementiert werden, auch wenn sie die Speicherverschlüsselung nicht unterstützen.
[C-0-2] Die Intents ACTION_LOCKED_BOOT_COMPLETED und ACTION_USER_UNLOCKED MÜSSEN weiterhin gesendet werden, um Direct Boot-kompatiblen Anwendungen zu signalisieren, dass Speicherorte mit Geräteverschlüsselung (Device Encrypted, DE) und mit Anmeldedaten verschlüsselt (Credential Encrypted, CE) für den Nutzer verfügbar sind.

9.9.2. Verschlüsselungsanforderungen

Geräteimplementierungen:

[C-0-1] Die privaten Daten der Anwendung (/data-Partition) sowie die gemeinsam genutzte Speicherpartition der Anwendung (/sdcard-Partition) MÜSSEN verschlüsselt werden, wenn sie ein permanenter, nicht entfernbarer Teil des Geräts ist.
[C-0-2] Die Datenspeicherverschlüsselung MUSS standardmäßig aktiviert sein, wenn der Nutzer die Ersteinrichtung abgeschlossen hat.
[C-0-3] MÜSSEN die oben genannte Anforderung zur Verschlüsselung von Datenspeichern erfüllen, indem eine der folgenden beiden Verschlüsselungsmethoden implementiert wird:
- Dateibasierte Verschlüsselung (File Based Encryption, FBE) und Metadatenverschlüsselung wie in Abschnitt 9.9.3.1 beschrieben.
- Nutzerspezifische Blockebenenverschlüsselung, wie in Abschnitt 9.9.3.2 beschrieben.

9.9.3. Verschlüsselungsmethoden

Wenn Geräteimplementierungen verschlüsselt sind, haben sie folgende Vorteile:

[C-1-1] MUSS ohne Aufforderung des Nutzers zur Eingabe von Anmeldedaten starten und Direct Boot-kompatiblen Apps den Zugriff auf den verschlüsselten Gerätespeicher (Device Encrypted, DE) erlauben, nachdem die ACTION_LOCKED_BOOT_COMPLETED-Nachricht gesendet wurde.
[C-1-2] Der Zugriff auf den verschlüsselten Anmeldedatenspeicher (Credential Encrypted, CE) DARF nur gewährt werden, nachdem der Nutzer das Gerät durch Eingabe seiner Anmeldedaten (z. B. Sicherheitscode, PIN, Muster oder Fingerabdruck) entsperrt und die ACTION_USER_UNLOCKED-Nachricht gesendet wurde.
[C-1-13] Es darf KEINE Methode zum Entsperren des durch die clientseitige Verschlüsselung geschützten Speichers ohne die vom Nutzer bereitgestellten Anmeldedaten, einen registrierten Treuhänderschlüssel oder eine Wiederaufnahme nach Neustart geben, die den Anforderungen in Abschnitt 9.9.4 entspricht.
[C-1-4] Der verifizierte Bootmodus MUSS verwendet werden.

9.9.3.1. Dateibasierte Verschlüsselung mit Metadatenverschlüsselung

Wenn bei Geräteimplementierungen die dateibasierte Verschlüsselung mit Metadatenverschlüsselung verwendet wird, gilt Folgendes:

[C-1-5] Dateiinhalte und Dateisystemmetadaten MÜSSEN mit AES-256-XTS oder Adiantum verschlüsselt werden. AES-256-XTS bezieht sich auf den Advanced Encryption Standard mit einer Chiffreschlüssellänge von 256 Bit, der im XTS-Modus verwendet 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 angegeben. Dateisystemmetadaten sind Daten wie Dateigrößen, Inhaberschaft, Modi und erweiterte Attribute (xattrs).
[C-1-6] Dateinamen MÜSSEN mit AES-256-CBC-CTS oder Adiantum verschlüsselt werden.
[C-1-12] Wenn das Gerät AES-Anweisungen (Advanced Encryption Standard) hat (z. B. ARMv8-Kryptografieerweiterungen auf ARM-basierten Geräten oder AES-NI auf x86-basierten Geräten), MÜSSEN die oben genannten AES-basierten Optionen für die Verschlüsselung von Dateinamen, Dateiinhalten und Dateisystemmetadaten verwendet werden, nicht Adiantum.
[C-1-13] Es MUSS eine kryptografisch starke und nicht reversible Schlüsselableitungsfunktion (z.B. HKDF-SHA512) verwendet werden, um alle erforderlichen Unterschlüssel (z.B. pro Datei) aus den CE- und DE-Schlüsseln abzuleiten. „Kryptografisch stark und nicht reversibel“ bedeutet, dass die Schlüsselableitungsfunktion eine Sicherheitsstärke von mindestens 256 Bit hat und sich bei ihren Eingaben wie eine Pseudozufallsfunktionsfamilie verhält.
[C-1-14] Es dürfen NICHT dieselben FBE-Schlüssel (File Based Encryption, dateibasierte Verschlüsselung) oder ‑Unterschlüssel 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 der Speicherbereiche für die Client- und Datenträgerebene und der Dateisystemmetadaten:
[C-1-7] MÜSSEN kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. Dieser Schlüsselspeicher MUSS an den bestätigten Boot und den Hardware-Root-of-Trust des Geräts gebunden sein.
[C-1-8] CE-Schlüssel MÜSSEN an die Anmeldedaten des Sperrbildschirms eines Nutzers gebunden sein.
[C-1-9] CE-Schlüssel MÜSSEN an einen Standard-Sicherheitscode gebunden sein, wenn der Nutzer keine Anmeldedaten für den Sperrbildschirm angegeben hat.
[C-1-10] MÜSSEN eindeutig und unterschiedlich sein. Das bedeutet, dass der CE- oder DE-Schlüssel eines Nutzers nicht mit dem CE- oder DE-Schlüssel eines anderen Nutzers übereinstimmen darf.
[C-1-11] Es MÜSSEN die obligatorisch unterstützten Chiffren, Schlüssellängen und Modi verwendet werden.
Vorinstallierte wichtige Apps (z.B. Wecker, Telefon, Messenger) MÜSSEN Direct Boot unterstützen.

Das Upstream-Android-Open-Source-Projekt bietet eine bevorzugte Implementierung der dateibasierten Verschlüsselung basierend auf der Verschlüsselungsfunktion „fscrypt“ des Linux-Kernels und der Metadatenverschlüsselung basierend auf der Funktion „dm-default-key“ des Linux-Kernels.

9.9.3.2. Nutzerspezifische Verschlüsselung auf Blockebene

Wenn bei Geräteimplementierungen die Verschlüsselung auf Blockebene pro Nutzer verwendet wird, haben sie folgende Vorteile:

[C-1-1] Die Unterstützung mehrerer Nutzer muss wie in Abschnitt 9.5 beschrieben aktiviert sein.
[C-1-2] Es MÜSSEN Partitionen pro Nutzer bereitgestellt werden, entweder mithilfe von Raw-Partitionen oder logischen Volumes.
[C-1-3] Es MÜSSEN eindeutige Verschlüsselungsschlüssel pro Nutzer für die Verschlüsselung der zugrunde liegenden Blockgeräte verwendet werden.
[C-1-4] Für die Blockebenenverschlüsselung der Nutzerpartitionen MUSS AES-256-XTS verwendet werden.
Die Schlüssel, die die pro Nutzer verschlüsselten Geräte auf Blockebene schützen:
[C-1-5] MÜSSEN kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. Dieser Schlüsselspeicher MUSS an den bestätigten Boot und den Hardware-Root-of-Trust des Geräts gebunden sein.
[C-1-6] MÜSSEN an die Anmeldedaten für den Sperrbildschirm des entsprechenden Nutzers gebunden sein.

Die blockbasierte Verschlüsselung pro Nutzer kann mit der Funktion „dm-crypt“ des Linux-Kernels über benutzerspezifische Partitionen implementiert werden.

9.9.4. Nach Neustart fortsetzen

Mit „Weiter nach Neustart“ können Sie den CE-Speicher aller Apps entsperren, auch von solchen, die Direct Boot noch nicht unterstützen, nach einem Neustart, der durch ein Over-the-air-Update (OTA) initiiert wurde. Mit dieser Funktion können Nutzer nach dem Neustart Benachrichtigungen von installierten Apps erhalten.

Bei der Implementierung von „Wiederherstellen nach Neustart“ muss weiterhin sichergestellt werden, dass es für Angreifer extrem schwierig ist, die clientseitig verschlüsselten Daten des Nutzers wiederherzustellen, wenn ein Gerät in ihre Hände fällt, auch wenn das Gerät eingeschaltet ist, der clientseitige Speicher entsperrt ist und der Nutzer das Gerät nach Erhalt einer OTA entsperrt hat. Für die Widerstandsfähigkeit gegen Insiderangriffe gehen wir davon aus, dass der Angreifer Zugriff auf kryptografische Signaturschlüssel für die Übertragung erhält.

Im Detail:

[C-0-1] Der CE-Speicher darf nicht lesbar sein, auch nicht für den Angreifer, der das Gerät physisch in seinem Besitz hat und dann folgende Funktionen und Einschränkungen hat:
- Kann den Signaturschlüssel eines beliebigen Anbieters oder Unternehmens verwenden, um beliebige Nachrichten zu signieren.
- Kann dazu führen, dass ein OTA-Update vom Gerät empfangen wird.
- Der Betrieb von Hardware (z. B. ZP, Flash) kann geändert werden, sofern dies unten beschrieben ist. Eine solche Änderung führt jedoch zu einer Verzögerung von mindestens einer Stunde und einem Neustart, der den RAM-Inhalt zerstört.
- Die Funktionsweise 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) können nicht abgerufen oder anderweitig zur Eingabe veranlasst werden.

Beispielsweise entspricht eine Geräteimplementierung, die alle hier aufgeführten Beschreibungen implementiert und einhält, [C-0-1].

9.10. Geräteintegrität

Die folgenden Anforderungen sorgen für Transparenz beim 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 umgestellt werden, in der diese neue System-API-Methode nicht vorhanden war.
[C-0-2] Der bestätigte Boot muss für die Geräteintegrität unterstützt werden.

Wenn Geräteimplementierungen bereits ohne Unterstützung von Verified Boot auf einer früheren Android-Version eingeführt wurden und diese Funktion nicht durch ein Systemsoftwareupdate 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 die Funktion von Geräteimplementierungen unterstützt wird, gilt Folgendes:

[C-1-1] Das Plattform-Funktions-Flag android.software.verified_boot MUSS deklariert werden.
[C-1-2] Die Überprüfung muss bei jeder Bootreihenfolge erfolgen.
[C-1-3] Die Überprüfung MUSS mit einem unveränderlichen Hardwareschlüssel beginnen, der der Root of Trust ist, und bis zur Systempartition reichen.
[C-1-4] MÜSSEN alle Phasen der Überprüfung implementieren, 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] Es MÜSSEN Überprüfungsalgorithmen verwendet werden, die so stark sind wie die aktuellen Empfehlungen des NIST für Hash-Algorithmen (SHA-256) und öffentliche Schlüsselgrößen (RSA-2048).
[C-1-6] Der Start darf NICHT abgeschlossen werden, wenn die Systemüberprüfung fehlschlägt, es sei denn, der Nutzer stimmt dem Startversuch zu. In diesem Fall dürfen die Daten aus nicht überprüften Speicherblöcken NICHT verwendet werden.
[C-1-7] Es darf NICHT möglich sein, geprüfte Partitionen auf dem Gerät zu ändern, es sei denn, der Nutzer hat den Bootloader ausdrücklich entsperrt.
[C-SR] Wenn sich im Gerät mehrere diskrete Chips befinden (z.B. Funkschnittstelle, spezieller Bildprozessor), wird dringend empfohlen, beim Starten jede Phase des Bootvorgangs für jeden dieser Chips zu überprüfen.
[C-1-8] Es MUSS ein manipulationssicherer Speicher verwendet werden, um zu speichern, ob der Bootloader entsperrt ist. Ein manipulationssicherer Speicher bedeutet, dass der Bootloader erkennen kann, ob der Speicher von Android aus manipuliert wurde.
[C-1-9] Der Nutzer muss während der Nutzung des Geräts aufgefordert und eine physische Bestätigung geben, bevor ein Wechsel vom gesperrten zum entsperrten Bootloader-Modus zulässig ist.
[C-1-10] Es MUSS ein Rollback-Schutz für Partitionen implementiert werden, die von Android verwendet werden (z.B. Boot- und Systempartitionen), und es muss ein manipulationssicherer Speicher für die Speicherung der Metadaten verwendet werden, die zur Bestimmung der zulässigen Mindestbetriebssystemversion verwendet werden.
[C-SR] Es wird DRINGEND empfohlen, alle APK-Dateien von privilegierten Apps mit einer Vertrauenskette zu überprüfen, die auf Partitionen basiert, die durch den verifizierten Bootmodus 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, sie gar nicht auszuführen.
Es sollte ein Rollback-Schutz für alle Komponenten mit nichtflüchtiger Firmware (z. B. Modem, Kamera) implementiert werden. Außerdem 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 auf einer früheren Android-Version eingeführt wurden und diese Anforderungen nicht durch ein Systemsoftwareupdate unterstützt werden können, KÖNNEN sie von den Anforderungen ausgenommen werden.

Das Upstream-Android Open Source Project bietet eine bevorzugte Implementierung dieser Funktion im external/avb/-Repository, die in den Bootloader für das Laden von Android eingebunden werden kann.

Geräteimplementierungen:

[C-0-3] MUSS die kryptografische Überprüfung von Dateiinhalten anhand eines vertrauenswürdigen Schlüssels unterstützen, ohne die gesamte Datei zu lesen.
[C-0-4] Es DARF NICHT zulässig sein, dass Leseanfragen für eine geschützte Datei erfolgreich sind, wenn die gelesenen Inhalte nicht mit einem vertrauenswürdigen Schlüssel verifiziert werden.

Wenn Geräteimplementierungen bereits auf einer früheren Android-Version eingeführt wurden, ohne dass Dateiinhalte mit einem vertrauenswürdigen Schlüssel abgeglichen werden können, und die Unterstützung für diese Funktion nicht durch ein Systemsoftwareupdate hinzugefügt werden kann, KÖNNEN sie von der Anforderung ausgenommen werden. Das Upstream-Android-Open-Source-Projekt bietet eine bevorzugte Implementierung dieser Funktion, die auf der fs-verity-Funktion des Linux-Kernels 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] true MUSS für die ConfirmationPrompt.isSupported() API gemeldet werden.
[C-3-2] Es MUSS sichergestellt werden, dass Code, der im Android-Betriebssystem ausgeführt wird, einschließlich des Kernels, schädlich oder anderweitig, ohne Nutzerinteraktion keine positive Antwort generieren kann.
[C-3-3] Es MUSS sichergestellt sein, dass der Nutzer die angezeigte Nachricht auch dann prüfen und genehmigen kann, wenn das Android-Betriebssystem, einschließlich des Kernels, manipuliert wurde.

9.11. Schlüssel und Anmeldedaten

Mit dem Android-Schlüsselspeichersystem können App-Entwickler kryptografische Schlüssel in einem Container speichern und sie über die KeyChain API oder die Keystore API in kryptografischen Vorgängen verwenden. Geräteimplementierungen:

[C-0-1] Es MÜSSEN mindestens 8.192 Schlüssel importiert oder generiert werden können.
[C-0-2] Die Authentifizierung über den Sperrbildschirm MUSS die Anzahl der Versuche begrenzen und einen exponentiellen Backoff-Algorithmus haben. Nach 150 fehlgeschlagenen Versuchen muss die Verzögerung mindestens 24 Stunden pro Versuch betragen.
Die Anzahl der generierbaren Schlüssel sollte NICHT begrenzt sein.

Wenn die Geräteimplementierung einen sicheren Sperrbildschirm unterstützt, gilt Folgendes:

[C-1-1] Die Implementierung des Schlüsselspeichers MUSS mit einer isolierten Ausführungsumgebung gesichert werden.
[C-1-2] MUSS Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie Hash-Funktionen der MD5-, SHA1- und SHA-2-Familie haben, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich ordnungsgemäß zu unterstützen, der sicher vom Code isoliert ist, der im 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. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternative Optionen sind jedoch eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation.
[C-1-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 Sperrbildschirmauthentifizierung ausführen kann. Das Upstream-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
[C-1-4] MUSS die Schlüsselattestierung unterstützen, bei der der Attestierungssignaturschlüssel durch sichere Hardware geschützt und die Signatur in sicherer Hardware ausgeführt wird. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten freigegeben werden, um zu verhindern, dass sie als Geräte-IDs verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, es sei denn, es werden mindestens 100.000 Einheiten einer bestimmten SKU produziert. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, kann für jede 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version gestartet wurde, ist dieses Gerät von der Anforderung ausgenommen, einen von einer abgeschirmten Ausführungsumgebung unterstützten Schlüsselspeicher zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, die android.hardware.fingerprint-Funktion wird deklariert, für die ein von einer abgeschirmten Ausführungsumgebung unterstützter Schlüsselspeicher erforderlich ist.

[C-1-5] Der Nutzer MUSS die Zeitüberschreitung für den Ruhemodus für den Übergang vom entsperrten zum gesperrten Zustand auswählen können, wobei die zulässige Mindestzeitüberschreitung 15 Sekunden beträgt. Bei Geräten für die Automobilbranche, die das Display sperren, wenn die Headunit ausgeschaltet wird oder der Nutzer wechselt, darf die Zeitüberschreitung für den Ruhemodus NICHT konfiguriert sein.

9.11.1. Sichere Sperrbildschirme und Authentifizierung

Die AOSP-Implementierung folgt einem mehrstufigen Authentifizierungsmodell, bei dem eine Knowledge-Factory-basierte primäre Authentifizierung 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 Methoden als primäre Authentifizierungsmethode festzulegen:
- Eine numerische PIN
- Ein alphanumerisches Passwort
- Wischmuster in einem Raster mit genau 3 × 3 Punkten

Die oben genannten Authentifizierungsmethoden werden in diesem Dokument als empfohlene primäre Authentifizierungsmethoden bezeichnet.

Wenn bei Geräteimplementierungen die empfohlenen primären Authentifizierungsmethoden hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode als sichere Möglichkeit zum Sperren des Bildschirms verwendet wird, muss die neue Authentifizierungsmethode:

[C-2-1] MUSS die Nutzerauthentifizierungsmethode sein, die unter Nutzerauthentifizierung für die Schlüsselnutzung erforderlich machen beschrieben wird.

Wenn bei Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden, wenn sie auf einem bekannten Geheimnis basieren, und eine neue Authentifizierungsmethode verwendet wird, die als sichere Methode zum Sperren des Displays behandelt 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 (z.B. PIN, Muster, Passwort) ersetzen, die in AOSP implementiert und bereitgestellt werden.
[C-3-4] Die neue Authentifizierungsmethode MUSS deaktiviert werden, wenn die Anwendung „Device Policy Controller“ (DPC) die Passwortqualitätsrichtlinie über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_SOMETHING festgelegt hat.
[C-3-5] Neue Authentifizierungsmethoden MÜSSEN alle 72 Stunden oder kürzer auf die empfohlenen primären Authentifizierungsmethoden (z.B. PIN, Muster, Passwort) zurückgreifen ODER den Nutzern klar und deutlich mitteilen, dass einige Daten nicht gesichert werden, um den Datenschutz ihrer Daten zu wahren.

Wenn bei 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 Entsperren des Bildschirms behandelt wird, gilt für die neue Methode Folgendes:

[C-4-1] MÜSSEN alle in Abschnitt 7.3.10 für Klasse 1 (früher Convenience) beschriebenen Anforderungen erfüllen.
[C-4-2] Es MUSS einen Fallback-Mechanismus geben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Geheimnis basiert.
[C-4-3] MUSS deaktiviert sein und nur die empfohlene primäre Authentifizierung zum Entsperren des Displays zulassen , wenn die Anwendung „Device Policy Controller“ (DPC) die Richtlinie für die Keyguard-Funktion festgelegt hat, indem sie die Methode DevicePolicyManager.setKeyguardDisabledFeatures() mit einem der zugehörigen biometrischen Flags (KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE oder KEYGUARD_DISABLE_IRIS) aufgerufen hat.

Wenn die biometrischen Authentifizierungsmethoden die Anforderungen für Klasse 3 (früher Hoch) gemäß Abschnitt 7.3.10 nicht erfüllen:

[C-5-1] Die Methoden MÜSSEN deaktiviert werden, wenn die DPC-Anwendung (Device Policy Controller) die Passwortqualitätsrichtlinie über die Methode DevicePolicyManager.setPasswordQuality() mit einer strengeren Qualitätskonstante als PASSWORD_QUALITY_BIOMETRIC_WEAK festgelegt hat.
[C-5-2] Der Nutzer MUSS zur empfohlenen primären Authentifizierung aufgefordert werden (z. B. PIN, Muster, Passwort), 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 mit C-8 beginnen.

Wenn bei 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] Es MUSS ein Fallback-Mechanismus vorhanden sein, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Geheimnis basiert und die Anforderungen erfüllt, um als sicherer Sperrbildschirm behandelt zu werden.
[C-6-2] Die neue Methode MUSS deaktiviert sein und nur eine der empfohlenen primären Authentifizierungsmethoden zum Entsperren des Bildschirms zulassen, wenn die Device Policy Controller-Anwendung (DPC) 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 4 Stunden oder kürzer mit einer der empfohlenen primären Authentifizierungsmethoden (z.B.PIN, Muster, Passwort) herausgefordert werden.
[C-6-4] Die neue Methode DARF NICHT als sicherer Sperrbildschirm behandelt werden und MUSS den in C-8 unten aufgeführten Einschränkungen entsprechen.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm und einen oder mehrere Vertrauensagenten enthalten, die die TrustAgentService System API implementieren, gilt Folgendes:

[C-7-1] Es MUSS im Einstellungsmenü und auf dem Sperrbildschirm klar angezeigt werden, ob die Gerätesperre verzögert wird oder von Vertrauenspersonen entsperrt werden kann. AOSP erfüllt diese Anforderung beispielsweise, indem im Einstellungsmenü eine Textbeschreibung für die Einstellungen „Automatische Sperre“ und „Ein/Aus-Taste sperrt sofort“ sowie ein gut sichtbares Symbol auf dem Sperrbildschirm angezeigt werden.
[C-7-2] Alle Trust-Agent-APIs in der Klasse DevicePolicyManager MÜSSEN berücksichtigt und vollständig implementiert werden, z. B. die Konstante KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] Die Funktion TrustAgentService.addEscrowToken() MUSS auf einem Gerät, das als primäres privates Gerät verwendet wird (z. B. ein Mobilgerät), NICHT vollständig implementiert werden. Sie DARF jedoch vollständig auf Geräten implementiert werden, die in der Regel gemeinsam genutzt werden (z. B. Android-Fernseher oder -Automobilgerä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 Treuhändertoken dürfen NICHT auf demselben Gerät gespeichert werden, auf dem der Schlüssel verwendet wird. So ist es beispielsweise zulässig, dass ein auf einem Smartphone gespeicherter Schlüssel ein Nutzerkonto auf einem Fernseher entsperren kann. Bei Automotive-Geräten darf das Treuhandtoken nicht an einem beliebigen Teil des Fahrzeugs gespeichert werden.
[C-7-6] Der Nutzer MUSS über die Sicherheitsrisiken informiert werden, bevor das Treuhandtoken zum Entschlüsseln des Datenspeichers aktiviert wird.
[C-7-7] Es MUSS einen Fallback-Mechanismus geben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden.
[C-7-8] Der Nutzer muss mindestens alle 72 Stunden aufgefordert werden, eine der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) zu verwenden, es sei denn, die Sicherheit des Nutzers (z. B. Ablenkung des Fahrers) ist gefährdet.
[C-7-9] Der Nutzer MUSS aufgefordert werden, eine der empfohlenen Methoden der primären Authentifizierung (z. B. PIN, Muster, Passwort) auszuführen, 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 den in C-8 unten aufgeführten Einschränkungen entsprechen.
[C-7-11] TrustAgents dürfen auf primären privaten Geräten (z. B. Smartphones) NICHT das Entsperren des Geräts zulassen. Sie dürfen sie nur verwenden, um ein bereits entsperrtes Gerät maximal 4 Stunden lang entsperrt zu halten. Die Standardimplementierung von TrustManagerService in AOSP erfüllt diese Anforderung.
[C-7-12] Es MUSS ein kryptografisch sicherer Kommunikationskanal (z. B. UKEY2) verwendet werden, um das Treuhändertoken vom Speichergerät an das Zielgerät weiterzuleiten.

Wenn bei Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden, der nicht wie oben beschrieben sicher ist, 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] Die von DevicePolicyManager.setPasswordExpirationTimeout() festgelegten Timer für das Ablaufen von Passwörtern DÜRFEN NICHT zurückgesetzt werden.
[C-8-3] Es darf KEINE API für die Verwendung durch Drittanbieter-Apps zur Änderung des Schlossstatus geben.

9.11.2. StrongBox

Mit dem Android Keystore System können App-Entwickler kryptografische Schlüssel in einem speziellen sicheren Prozessor sowie in der oben beschriebenen isolierten Ausführungsumgebung speichern. Ein solcher spezieller sicherer Prozessor wird als „StrongBox“ bezeichnet. In den Anforderungen C-1-3 bis C-1-11 unten werden die Anforderungen definiert, die ein Gerät erfüllen muss, um als StrongBox zu gelten.

Geräteimplementierungen mit einem speziellen sicheren Prozessor:

[C-SR] Wir empfehlen dringend, StrongBox zu unterstützen. StrongBox wird in einer zukünftigen Version wahrscheinlich eine Anforderung sein.

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

[C-1-1] FEATURE_STRONGBOX_KEYSTORE MUSS deklariert werden.
[C-1-2] Es MUSS spezielle sichere Hardware bereitgestellt werden, die zum Sichern des Schlüsselspeichers und zur sicheren Nutzerauthentifizierung verwendet wird. Die spezielle sichere Hardware kann auch für andere Zwecke verwendet werden.
[C-1-3] MUSS eine diskrete CPU haben, die keinen Cache, DRAM, Coprozessor oder andere Kernressourcen mit dem Anwendungsprozessor (AP) teilt.
[C-1-4] Es MUSS sichergestellt sein, dass alle Peripheriegeräte, die mit dem AP geteilt werden, die StrongBox-Verarbeitung in keiner Weise verändern oder Informationen aus dem StrongBox abrufen können. Der AP KANN den Zugriff auf StrongBox deaktivieren oder blockieren.
[C-1-5] MUSS eine interne Uhr mit angemessener Genauigkeit (+ − 10%) haben, die nicht manipuliert werden kann.
[C-1-6] Es MUSS einen echten Zufallszahlengenerator geben, der eine gleichmäßig verteilte und unvorhersehbare Ausgabe liefert.
[C-1-7] MUSS manipulationssicher sein, einschließlich Widerstandsfähigkeit gegen physisches Eindringen und Glitching.
[C-1-8] MUSS Nebenkanalresistenz haben, einschließlich Widerstand gegen das Austreten von Informationen über Stromversorgung, Timing, elektromagnetische Strahlung und thermische Strahlung.
[C-1-9] Es MUSS ein sicherer Speicher vorhanden sein, der für Vertraulichkeit, Integrität, Authentizität, Konsistenz und Aktualität der Inhalte sorgt. Der Speicher darf nur dann gelesen oder geändert werden, wenn dies von den StrongBox APIs zulässig ist.
Zur Validierung der Einhaltung von [C-1-3] bis [C-1-9] müssen Geräteimplementierungen:
- [C-1-10] Die Hardware MUSS gemäß dem Secure IC Protection Profile BSI-CC-PP-0084-2014 zertifiziert oder von einem national akkreditierten Testlabor bewertet worden sein, das die Bewertung der Sicherheitslücken mit hohem Angriffspotenzial gemäß den Common Criteria Application of Attack Potential to Smartcards berücksichtigt.
- [C-1-11] MUSS die Firmware enthalten, die von einem national akkreditierten Testlabor gemäß der Common Criteria Application of Attack Potential to Smartcards (Anwendung von Common Criteria auf das Angriffspotenzial von Smartcards) auf Sicherheitslücken mit hohem Angriffspotenzial geprüft wurde.
- [C-SR] Es wird DRINGEND empfohlen, die Hardware anzugeben, die mit einem Sicherheitsziel der Bewertungssicherheitsstufe 5 (Evaluation Assurance Level, EAL) bewertet wird, ergänzt durch AVA_VAN.5. Die EAL 5-Zertifizierung wird wahrscheinlich in einer zukünftigen Version erforderlich.
[C-SR] Es wird DRINGEND empfohlen, einen Schutz vor Insiderangriffen (Insider Attack Resistance, IAR) bereitzustellen. Das bedeutet, dass ein Insider mit Zugriff auf Firmware-Signaturschlüssel keine Firmware erstellen kann, die dazu führt, dass der StrongBox Geheimnisse preisgibt, funktionale Sicherheitsanforderungen umgeht oder anderweitig den Zugriff auf vertrauliche Nutzerdaten ermöglicht. Wir empfehlen, Firmwareupdates nur zuzulassen, wenn das primäre Nutzerpasswort über die HAL „IAuthSecret“ angegeben wird.

9.11.3. Identity Credential

Das Identitäts-Anmeldedatensystem wird durch Implementieren aller APIs im Paket android.security.identity.* definiert und erreicht. Mit diesen APIs können App-Entwickler Dokumente zur Nutzeridentität speichern und abrufen. Geräteimplementierungen:

[C-SR] Es wird DRINGEND empfohlen, das Identitätsnachweissystem zu implementieren.

Wenn das Identitätsnachweissystem in Geräteimplementierungen implementiert ist, gilt Folgendes:

[C-0-1] Die Methode IdentityCredentialStore#getInstance() MUSS einen nicht nullwertigen Wert zurückgeben.
[C-0-2] Das Identitäts-Anmeldedatensystem (z.B. die android.security.identity.* APIs) MUSS mit Code implementiert werden, der mit einer vertrauenswürdigen Anwendung in einem Bereich kommuniziert, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird. Die sichere 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 kryptografischen Vorgänge, die zur Implementierung des Identitätsnachweissystems erforderlich sind (z. B. die android.security.identity.* APIs), MÜSSEN vollständig in der vertrauenswürdigen Anwendung ausgeführt werden. Das Material für den privaten Schlüssel darf die isolierte Ausführungsumgebung niemals verlassen, es sei denn, dies wird von APIs höherer Ebene ausdrücklich verlangt (z. B. die Methode createEphemeralKeyPair()).
[C-0-4] Die vertrauenswürdige Anwendung MUSS so implementiert sein, dass ihre Sicherheitseigenschaften nicht beeinträchtigt werden (z.B. werden Anmeldedaten nicht freigegeben, es sei denn, die Zugriffssteuerungsbedingungen sind erfüllt, MACs können nicht für beliebige Daten erstellt werden), auch wenn Android sich nicht richtig verhält oder manipuliert wurde.

9.12. Löschen von Daten

Alle Geräteimplementierungen:

[C-0-1] Es MUSS Nutzern möglich sein, das Gerät auf die Werkseinstellungen zurückzusetzen.
[C-0-2] MÜSSEN alle Daten im userdata-Dateisystem löschen.
[C-0-3] Die Daten MÜSSEN so gelöscht werden, dass relevante Branchenstandards wie NIST SP800-88 eingehalten werden.
[C-0-4] MUSS den oben genannten Vorgang „Zurücksetzen auf die Werkseinstellungen“ auslösen, wenn die DevicePolicyManager.wipeData() API von der Device Policy Controller App des Hauptnutzers aufgerufen wird.
KANN eine Option zum schnellen Löschen von Daten bieten, bei der nur die logischen Daten gelöscht werden.

9.13. Abgesicherter Modus

Android bietet den abgesicherten Modus, in dem Nutzer ein Gerät in einem Modus starten können, in dem nur vorinstallierte System-Apps ausgeführt werden dürfen und alle Drittanbieter-Apps deaktiviert sind. In diesem Modus, dem sogenannten „Abgesicherten Boot-Modus“, können Nutzer potenziell schädliche Drittanbieter-Apps deinstallieren.

Geräteimplementierungen sind:

[SR] Wir empfehlen dringend, den abgesicherten Modus zu implementieren.

Wenn der abgesicherte Modus in Geräteimplementierungen implementiert ist, gilt Folgendes:

[C-1-1] Dem Nutzer MUSS eine Option zum Starten des abgesicherten Modus zur Verfügung gestellt werden, die nicht von auf dem Gerät installierten Drittanbieter-Apps unterbrochen werden kann, es sei denn, die Drittanbieter-App ist ein Device Policy Controller und hat das Flag UserManager.DISALLOW_SAFE_BOOT auf „wahr“ gesetzt.
[C-1-2] MUSS dem Nutzer die Möglichkeit bieten, Drittanbieter-Apps im abgesicherten Modus zu deinstallieren.
SOLLTE dem Nutzer die Möglichkeit bieten, über das Boot-Menü in den abgesicherten Modus zu wechseln, wobei der Ablauf vom normalen Start abweichen sollte.

9.14. Isolation des Fahrzeugsystems

Android Automotive-Geräte sollen Daten mit kritischen Fahrzeug-Subsystemen austauschen. Dazu wird die Vehicle HAL verwendet, um Nachrichten über Fahrzeugnetzwerke wie CAN-Bus zu senden und zu empfangen.

Der Datenaustausch kann durch Implementierung von Sicherheitsfunktionen unterhalb der Android-Framework-Ebenen gesichert werden, um böswillige oder unbeabsichtigte Interaktionen mit diesen Subsystemen zu verhindern.

9.15. Abos

„Abos“ bezieht sich auf die Details zum Abrechnungsverhältnis, die von einem Mobilfunkanbieter über SubscriptionManager.setSubscriptionPlans() bereitgestellt werden.

Alle Geräteimplementierungen:

[C-0-1] Abos MÜSSEN nur an die App des Mobilfunkanbieters zurückgegeben werden, über den sie ursprünglich bereitgestellt wurden.
[C-0-2] Abos dürfen NICHT aus der Ferne gesichert oder hochgeladen werden.
[C-0-3] Es dürfen nur Überschreibungen wie SubscriptionManager.setSubscriptionOverrideCongested() von der App des Mobilfunkanbieters zugelassen werden, der derzeit gültige Abotarife anbietet.

9.16. Migration von Anwendungsdaten

Wenn Geräteimplementierungen die Möglichkeit zur Migration von Daten von einem Gerät zu einem anderen bieten und die kopierten App-Daten nicht auf das beschränken, was vom App-Entwickler im Manifest über das Attribut android:fullBackupContent konfiguriert wurde, gilt Folgendes:

[C-1-1] Es DÜRFEN KEINE Übertragungen von Anwendungsdaten von Geräten gestartet werden, auf denen der Nutzer keine primäre Authentifizierung gemäß 9.11.1 Sicherer Sperrbildschirm und Authentifizierung eingerichtet hat.
[C-1-2] Die primäre Authentifizierung auf dem Quellgerät und die Absicht des Nutzers, die Daten auf dem Quellgerät zu kopieren, MÜSSEN sicher bestätigt werden, bevor Daten übertragen werden.
[C-1-3] Es MUSS die Attestierung mit Sicherheitsschlüssel verwendet werden, um sicherzustellen, dass sowohl das Quell- als auch das Zielgerät bei der Gerätemigration legitime Android-Geräte sind und einen gesperrten Bootloader haben.
[C-1-4] Anwendungsdaten dürfen nur in dieselbe Anwendung auf dem Zielgerät mit demselben Paketnamen UND Signaturzertifikat migriert werden.
[C-1-5] Im Einstellungsmenü MUSS angegeben werden, dass auf dem Quellgerät Daten durch eine Migration von Gerät zu Gerät migriert wurden. Nutzer sollten diese Kennzeichnung NICHT entfernen können.

10. Softwarekompatibilitätstests

Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen. Beachten Sie jedoch, dass kein Softwaretestpaket vollständig ist. Aus diesem Grund wird Geräteimplementierern DRINGEND empfohlen, nur so wenige Änderungen wie möglich an der Referenz- und bevorzugten Implementierung von Android vorzunehmen, die im Android Open Source Project verfügbar ist. So wird das Risiko minimiert, dass Fehler auftreten, die Inkompatibilitäten verursachen, die Neuarbeit 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, und dabei die finale Versandsoftware auf dem Gerät verwenden.
[C-0-2] MÜSSEN für Kompatibilität bei Unklarheiten im CTS und bei jeder Neuimplementierung von Teilen des Referenz-Quellcodes sorgen.

Der CTS ist für die Ausführung auf einem echten Gerät konzipiert. Wie jede Software kann auch die CTS Fehler enthalten. Die CTS wird unabhängig von dieser Kompatibilitätsdefinition versioniert. Es können mehrere Versionen der 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.
Die Referenzimplementierung im Android Open Source-Baum sollte nach Möglichkeit verwendet werden.

10.2. CTS-Verifier

Der CTS Verifier ist in der Compatibility Test Suite enthalten und soll von einem menschlichen Operator ausgeführt werden, um Funktionen zu testen, die nicht von einem automatisierten System getestet werden können, z. B. die ordnungsgemäße Funktion von Kameras und Sensoren.

Geräteimplementierungen:

[C-0-1] MÜSSEN alle anwendbaren Fälle im CTS-Verifier korrekt ausgeführt werden.

Der CTS-Verifier bietet Tests für viele Arten von Hardware, einschließlich optionaler Hardware.

Geräteimplementierungen:

[C-0-2] MUSS alle Tests für die vorhandene Hardware bestehen. Wenn ein Gerät beispielsweise einen Beschleunigungsmesser hat, MUSS der Testfall für den Beschleunigungsmesser im CTS-Verifier korrekt ausgeführt werden.

Testfälle für Funktionen, die in diesem Dokument zur Kompatibilitätsdefinition als optional gekennzeichnet sind, KÖNNEN übersprungen oder weggelassen werden.

[C-0-2] Auf jedem Gerät und für jede Build-Version MUSS der CTS-Verifier wie oben beschrieben ausgeführt werden. Da viele Builds jedoch sehr ähnlich sind, wird von Geräteimplementierern nicht erwartet, dass sie den CTS-Verifier explizit auf Builds ausführen, die sich nur unwesentlich unterscheiden. Insbesondere bei Geräteimplementierungen, die sich von einer Implementierung, die den CTS-Verifier bestanden hat, nur durch die enthaltenen Sprachen, das Branding usw. unterscheiden, kann der CTS-Verifier-Test weggelassen werden.

11. Aktualisierbare Software

[C-0-1] Geräteimplementierungen MÜSSEN einen Mechanismus zum Ersetzen der gesamten Systemsoftware enthalten. Der Mechanismus muss keine „Live-Upgrades“ ausführen. Das bedeutet, dass ein Neustart des Geräts möglicherweise erforderlich ist. Es kann jede Methode verwendet werden, sofern damit die gesamte auf dem Gerät vorinstallierte Software ersetzt werden kann. Beispielsweise erfüllen alle der folgenden Ansätze diese Anforderung:
- „Over-the-air“-Downloads (OTA) mit Offlineupdate über Neustart
- Tethering-Updates über USB von einem Host-PC
- „Offline“-Updates über einen Neustart und ein Update über eine Datei auf einem Wechseldatenträger
[C-0-2] Der verwendete Updatemechanismus MUSS Updates ohne Löschen von Nutzerdaten unterstützen. Das bedeutet, dass der Aktualisierungsmechanismus private Daten der Anwendung und freigegebene Daten der Anwendung MUSS beibehalten. Die Android-Software enthält einen Aktualisierungsmechanismus, der diese Anforderung erfüllt.
[C-0-3] Das gesamte Update MUSS signiert sein und der Aktualisierungsmechanismus auf dem Gerät MUSS das Update und die Signatur anhand eines auf dem Gerät gespeicherten öffentlichen Schlüssels überprüfen.
[C-SR] Der Signaturmechanismus sollte das Update mit SHA-256 hashen und den Hash mit ECDSA NIST P-256 anhand des öffentlichen Schlüssels validieren.

Wenn die Geräteimplementierungen die Unterstützung einer unbegrenzten Datenverbindung wie 802.11 oder Bluetooth PAN (Personal Area Network) umfassen, müssen sie:

[C-1-1] MUSS OTA-Downloads mit Offline-Update über Neustart unterstützen.

Bei Geräteimplementierungen, die mit Android 6.0 und höher eingeführt werden, sollte der Updatemechanismus die Überprüfung unterstützen, ob das System-Image nach einem Over-the-air-Update 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 MÜSSEN Geräteimplementierungen A/B-Systemupdates unterstützen. Das AOSP implementiert diese Funktion mit der Boot Control HAL.

Wenn nach der Markteinführung, aber innerhalb der angemessenen Lebensdauer eines Produkts, in der Geräteimplementierung ein Fehler gefunden wird, der sich in Absprache mit dem Android-Kompatibilitätsteam auf die Kompatibilität von Drittanbieter-Apps auswirkt, gilt Folgendes:

[C-2-1] Der Geräteimplementierer MUSS den Fehler über ein verfügbares Softwareupdate korrigieren, das gemäß dem gerade beschriebenen Mechanismus angewendet werden kann.

Android bietet Funktionen, mit denen die App „Geräteinhaber“ (falls vorhanden) die Installation von Systemupdates steuern kann. Wenn das Systemupdate-Subsystem für Geräte android.software.device_admin meldet, geschieht Folgendes:

[C-3-1] MUSS das in der Klasse SystemUpdatePolicy beschriebene Verhalten implementieren.

12. Änderungsprotokoll für Dokumente

Hier eine Zusammenfassung der Änderungen an der Kompatibilitätsdefinition in dieser Version:

Änderungslog dokumentieren

Hier eine Zusammenfassung der Änderungen an den Abschnitten für Einzelpersonen:

12.1. Tipps zum Ansehen des Änderungslogs

Änderungen werden so gekennzeichnet:

CDD
Wesentliche Änderungen an den Kompatibilitätsanforderungen.
Docs
Änderungen am Erscheinungsbild oder am Build.

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

13. Kontakt

Sie können dem Android-Kompatibilitätsforum beitreten und um Klarstellungen bitten oder Probleme ansprechen, die Ihrer Meinung nach im Dokument nicht behandelt werden.