1. Einführung
In diesem Dokument sind die Anforderungen aufgeführt, die erfüllt sein müssen, damit Geräte mit Android 14 kompatibel sind.
Die Verwendung von "MUSS", "MUSS NICHT", "ERFORDERLICH", "WIRD", "WIRD NICHT", "SOLLTE", "SOLLTE NICHT", "EMPFOHLEN", "KÖNNEN" und "OPTIONAL" verwendet werden, entspricht dem in RFC 2119 definierten IETF-Standard.
In diesem Dokument ist ein „Geräteimplementierung“ oder „Implementierer“ eine Person oder Organisation, die eine Hardware-/Softwarelösung unter Android 14 entwickelt. Eine "Geräteimplementierung" oder "Implementierung" ist die so entwickelte Hardware-/Softwarelösung.
Um als mit Android 14 kompatibel zu gelten, MÜSSEN Geräteimplementierungen den Anforderungen dieser Kompatibilitätsdefinition entsprechen, einschließlich aller Dokumente, die per Verweis aufgenommen werden.
Wenn diese Definition oder die in Abschnitt 10 beschriebenen Softwaretests nicht verständlich, mehrdeutig oder unvollständig ist, liegt es in der Verantwortung des Geräteimplementierung, die Kompatibilität mit vorhandenen Implementierungen sicherzustellen.
Aus diesem Grund ist das Android Open Source Project sowohl die Referenz als auch die bevorzugte Implementierung von Android. Geräte-Implementierer wird dringend empfohlen, ihre Implementierungen so weit wie möglich auf dem vorgelagerten Quellcode des Android-Open-Source-Projekts zu basieren. Zwar können einige Komponenten hypothetisch durch alternative Implementierungen ersetzt werden, es wird jedoch UNBEDINGT EMPFOHLEN, diese Vorgehensweise nicht zu befolgen, da das Bestehen der Softwaretests erheblich schwieriger wird. Der Implementierer ist dafür verantwortlich, die vollständige Verhaltenskompatibilität mit der standardmäßigen Android-Implementierung einschließlich und darüber hinaus sicherzustellen. Beachten Sie schließlich, dass bestimmte Ersatzkomponenten und Änderungen ausdrücklich verboten sind.
Viele der in diesem Dokument verlinkten Ressourcen werden direkt oder indirekt vom Android SDK abgeleitet und sind funktional mit den Informationen in der Dokumentation des entsprechenden SDKs identisch. In Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstest-Suite nicht mit der SDK-Dokumentation übereinstimmt, wird die SDK-Dokumentation als maßgeblich betrachtet. Alle technischen Details, die in den verlinkten Ressourcen in diesem Dokument bereitgestellt werden, werden als Teil dieser Kompatibilitätsdefinition betrachtet.
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 in Abschnitt 2 ist einem bestimmten Gerätetyp zugeordnet.
Alle anderen Anforderungen, die allgemein für alle Android-Geräteimplementierungen gelten, sind in den Abschnitten nach Abschnitt 2 aufgeführt. Diese Anforderungen werden in diesem Dokument als „zentrale Anforderungen“ bezeichnet.
1.1.2 Anforderungs-ID
Für MUSS-Anforderungen wird eine Anforderungs-ID zugewiesen.
- Die ID wird nur für MUSS-Anforderungen zugewiesen.
- Anforderungen sind mit "[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 ist wie folgt definiert:
- Gerätetyp-ID (weitere Informationen unter 2. Gerätetypen)
- C: Kern (Anforderungen, die für alle Implementierungen von Android-Geräten gelten)
- H: Android-Handheld-Gerät
- T: Android TV-Gerät
- A: Android Automotive-Implementierung
- W: Android Watch-Implementierung
- Tab: Android-Tablet-Implementierung
- Bedingungs-ID
- Wenn die Anforderung unbedingt erforderlich ist, wird diese ID auf 0 gesetzt.
- Wenn die Anforderung bedingt ist, wird für die erste Bedingung „1“ zugewiesen und die Zahl wird im selben Abschnitt und für denselben Gerätetyp um 1 erhöht.
- Anforderungs-ID
- Diese ID beginnt bei 1 und wird im selben Abschnitt und derselben Bedingung um 1 erhöht.
1.1.3 Anforderungs-ID in Abschnitt 2
Die Anforderungs-IDs in Abschnitt 2 bestehen aus zwei Teilen. Die erste entspricht einer Abschnitts-ID wie oben beschrieben. Im zweiten Teil werden der Formfaktor und die formfaktorspezifische Anforderung definiert.
Abschnitts-ID gefolgt von der oben beschriebenen Anforderungs-ID.
- Die ID in Abschnitt 2 besteht aus folgenden Komponenten: 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 Software-Stack, der für eine Vielzahl von Gerätetypen und Formfaktoren verwendet werden kann. Zur Gewährleistung der Gerätesicherheit wird erwartet, dass der Softwarestack, einschließlich eines Ersatzbetriebssystems oder einer alternativen Kernel-Implementierung, in einer sicheren Umgebung ausgeführt wird, wie in Abschnitt 9 und an anderer Stelle in diesem CDD beschrieben. Es gibt einige Gerätetypen, die sich über ein relativ besser etabliertes Ökosystem für die Anwendungsverteilung verfügen.
In diesem Abschnitt werden diese Gerätetypen sowie zusätzliche Anforderungen und Empfehlungen beschrieben, die für jeden Gerätetyp gelten.
Alle Android-Geräteimplementierungen, die zu keinem der beschriebenen Gerätetypen passen, MÜSSEN trotzdem alle Anforderungen in den anderen Abschnitten dieser Kompatibilitätsdefinition erfüllen.
2.1 Gerätekonfigurationen
Die wichtigsten Unterschiede bei der Hardwarekonfiguration je nach Gerätetyp finden Sie in den gerätespezifischen Anforderungen in diesem Abschnitt.
2.2. Anforderungen an Handhelds
Ein Android-Handheld-Gerät bezieht sich auf eine Android-Geräteimplementierung, die normalerweise verwendet wird, indem das Gerät in der Hand gehalten wird, z. B. ein MP3-Player, ein Smartphone oder ein Tablet.
Implementierungen von Android-Geräten werden als Handhelds klassifiziert, wenn sie die folgenden Kriterien erfüllen:
- eine Stromquelle nutzen, die Mobilität ermöglicht, z. B. einen Akku.
- Bildschirmgröße der physischen Diagonale zwischen 4 Zoll
3,3 Zoll (oder 2,5 Zoll für Geräteimplementierungen, die mit API-Level 29 oder früher ausgeliefert wurden)bis 8 Zoll. - Sie müssen über eine Touchscreen-Eingabeoberfläche verfügen.
Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Implementierungen von Android-Handheld-Geräten.
2.2.1. Hardware
Implementierungen von Handheld-Geräten:
- [7.1.1.1/H-0-1] MUSS mindestens ein Android-kompatibles
Display haben, das alle in diesem Dokument beschriebenen Anforderungen erfüllt.Display mit einer Länge von mindestens 2,2 Zoll an der kurzen und 3,4 Zoll an der langen Seite [7.1.1.3/H-SR-1] werden dringend empfohlen, um Nutzern die Möglichkeit zu bieten, die Displaygröße (Bildschirmdichte) zu ändern.
[7.1.1.1/H-0-2] MUSS die GPU-Zusammensetzung grafischer Zwischenspeicher unterstützen, die mindestens so groß ist wie die höchste Auflösung aller integrierten Bildschirme.
Neue Anforderungen erstellen
[7.1.1.1/H-0-3]* MÜSSEN jedes
UI_MODE_NORMAL
-Display, das für Anwendungen von Drittanbietern zur Verfügung gestellt wird, auf einem freien Bildschirmbereich platzieren, der an der kurzen Seite mindestens 2,2" und an der langen Seite 3,4" Zoll groß ist.[7.1.1.3/H-0-1]* MÜSSEN den Wert von
DENSITY_DEVICE_STABLE
auf 92% oder größer als die tatsächliche Dichte des entsprechenden Bildschirms setzen.
Neue Anforderungen beenden
Wenn Implementierungen von Handheld-Geräten die Bildschirmdrehung durch Software unterstützen, gilt Folgendes:
- [7.1.1.1/H-1-1]* MÜSSEN der logische Bildschirm, der für Anwendungen von Drittanbietern zur Verfügung gestellt wird, an den kurzen Seiten mindestens 2 Zoll und an den langen Kanten mindestens 2,7 Zoll lang sein. Geräte, die mit Android API-Level 29 oder niedriger ausgeliefert wurden, KÖNNEN von dieser Anforderung ausgenommen.
Wenn Implementierungen von Handheld-Geräten die Bildschirmdrehung durch Software nicht unterstützen, geschieht Folgendes:
- [7.1.1.1/H-2-1]* MÜSSEN die kurzen Seiten des logischen Bildschirms, der für Anwendungen von Drittanbietern zur Verfügung gestellt wird, mindestens 2,7 Zoll haben. Geräte, die mit Android API-Level 29 oder niedriger ausgeliefert wurden, KÖNNEN von dieser Anforderung ausgenommen.
Wenn Implementierungen von Handheld-Geräten Unterstützung für Displays mit hohem Dynamikumfang über Configuration.isScreenHdr()
versprechen, gilt Folgendes:
- [7.1.4.5/H-1-1] MUSS mit der 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
undVK_EXT_hdr_metadata
werben.
Implementierungen von Handheld-Geräten:
- [7.1.4.6/H-0-1] MÜSSEN über die Systemeigenschaft
graphics.gpu.profiler.support
angeben, ob das Gerät die GPU-Profilerstellung unterstützt.
Wenn Implementierungen von Handheld-Geräten die Unterstützung über eine Systemeigenschaft graphics.gpu.profiler.support
deklarieren, geschieht Folgendes:
- [7.1.4.6/H-1-1] MÜSSEN einen protobuf-Trace als Ausgabe melden, der dem in der Perfetto-Dokumentation definierten Schema für GPU-Zähler und GPU-Renderingphasen entspricht.
- [7.1.4.6/H-1-2] MÜSSEN konforme Werte für die GPU-Zähler des Geräts nach dem Protokoll für das GPU-Zähler-Trace-Paket melden.
- [7.1.4.6/H-1-3] MÜSSEN konforme Werte für die GPU-RenderStages des Geräts nach dem Trace-Paket der Rendering-Phase melden.
- [7.1.4.6/H-1-4] MÜSSEN einen GPU-Frequenz-Tracepoint gemäß dem Format power/gpu_frequency melden.
Implementierungen von Handheld-Geräten:
- [7.1.5/H-0-1] MUSS Unterstützung für den Kompatibilitätsmodus von älteren Anwendungen enthalten, wie er durch den vorgelagerten Open-Source-Code von Android implementiert wird. Das heißt, Geräteimplementierungen DÜRFEN NICHT die Trigger oder Grenzwerte ändern, bei denen der Kompatibilitätsmodus aktiviert wird, und DÜRFEN NICHT das Verhalten des Kompatibilitätsmodus selbst ändern.
- [7.2.1/H-0-1] MUSS Unterstützung für IME-Anwendungen (Input Method Editor) von Drittanbietern enthalten.
- [7.2.3/H-0-2] MÜSSEN sowohl das normale als auch das lange Drücken der Funktion „Zurück“ (
KEYCODE_BACK
) an die Anwendung im Vordergrund senden. Diese Ereignisse DÜRFEN NICHT vom System verarbeitet werden und können außerhalb des Android-Geräts ausgelöst werden, z.B. über eine mit dem Android-Gerät verbundene externe Hardwaretastatur. - [7.2.3/H-0-3] MUSS die Home-Funktion auf allen mit Android kompatiblen Displays bereitstellen, auf denen der Startbildschirm angezeigt wird.
- [7.2.3/H-0-4] MÜSSEN die Funktion „Zurück“ auf allen mit Android kompatiblen Displays und die Funktion „Zuletzt verwendet“ auf mindestens einem der mit Android kompatiblen Displays bereitstellen.
- [7.2.4/H-0-1] MUSS die Touchscreen-Eingabe unterstützen.
- [7.2.4/H-SR-1] wird dringend empfohlen, die vom Nutzer ausgewählte Assistent-App zu starten, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die
ACTION_ASSIST
durch langes Drücken vonKEYCODE_MEDIA_PLAY_PAUSE
oderKEYCODE_HEADSETHOOK
verarbeitet, wenn diese langes Drücken nicht durch die Aktivität im Vordergrund ausgeführt wird. - [7.3.1/H-SR-1] wird dringend empfohlen, einen 3-Achsen-Beschleunigungsmesser zu verwenden.
Wenn Handheld-Geräte einen dreiachsigen Beschleunigungsmesser enthalten, gilt Folgendes:
- [7.3.1/H-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 100 Hz melden können.
Wenn Implementierungen von Handheld-Geräten einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps
an Anwendungen melden, geschieht Folgendes:
- [7.3.3/H-2-1] MÜSSEN GNSS-Messungen melden, sobald sie gefunden werden, auch wenn ein über GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
- [7.3.3/H-2-2] MÜSSEN GNSS-Pseudobereiche und Pseudorangeraten melden, die bei freiem Himmel nach der Bestimmung des Standorts bei einer Bewegung von weniger als 0,2 Metern pro Quadratsekunde ausreichen, um eine Position innerhalb von 20 Metern und eine Geschwindigkeit von mindestens 0,9% pro Sekunde zu berechnen.
Wenn Handheld-Geräte ein 3-Achsen-Gyroskop enthalten, gilt Folgendes:
- [7.3.4/H-3-1] MÜSSEN Ereignisse bis zu 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 Handheld-Geräten, die einen Sprachanruf tätigen und einen anderen Wert als PHONE_TYPE_NONE
in getPhoneType
anzeigen können:
- [7.3.8/H] SOLLTE einen Näherungssensor enthalten.
Implementierungen von Handheld-Geräten:
- [7.3.11/H-SR-1] wird dringend empfohlen, einen Positionssensor mit 6 Freiheitsgraden zu unterstützen.
- [7.4.3/H] SOLLTEN Bluetooth und Bluetooth LE unterstützen.
Wenn Geräte das NAN-Protokoll (Wi-Fi Neighbor Awareness Networking) unterstützen, indem sie PackageManager.FEATURE_WIFI_AWARE
und den WLAN-Standort (Wi-Fi Round Trip Time – RTT) durch Angabe von PackageManager.FEATURE_WIFI_RTT
deklarieren, dann gilt Folgendes:
[7.4.2.5/H-1-1] MÜSSEN den Bereich genau innerhalb von +/-1 Meter bei 160 MHz Bandbreite beim 68. Perzentil (berechnet mit der kumulativen Verteilungsfunktion), +/- 2 Meter bei 80 MHz Bandbreite beim 68. Perzentil, +/-4 Meter bei 40 MHz-Bandbreite bei 68 MHz/WLAN-Bandbreite bei 40 MHz-Bandbreite melden.
[7.4.2.5/H-SR-1] WIRD UNBEDINGT EMPFOHLEN, den Bereich bei der Bandbreite von +/-1 Meter bei 160 MHz Bandbreite beim 90. Perzentil genau anzugeben (berechnet mit der Funktion für kumulative Verteilung), +/-2 Meter bei 80 MHz Bandbreite beim 90. Perzentil, +/-2 Meter bei der Bandbreite von 80 MHz des 90. Perzentils, +/-4 MHz-Bandbreite bei 90 MHz/9 MHz/9 MHz Bandbreite 9 MHz/-4 Hz Bandbreite bei 4 MHz
Es wird dringend empfohlen, die unter Anwesenheitskalibrierung angegebenen Schritte zur Einrichtung der Messung zu befolgen.
Neue Anforderungen erstellen
Wenn in Implementierungen von Handheld-Geräten FEATURE_BLUETOOTH_LE
deklariert ist, gilt Folgendes:
- [7.4.3/H-1-3] MÜSSEN und kompensieren den Rx-Offset, um sicherzustellen, dass der Medianwert für BLE RSSI bei -50 dBm +/-15 dB in 1 m Entfernung von einem Referenzgerät liegt, das bei
ADVERTISE_TX_POWER_HIGH
sendet. - [7.4.3/H-1-4] MÜSSEN den Tx-Offset messen und kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -50 dBm +/-15 dB liegt, wenn beim Scannen von einem Referenzgerät, das in einer Entfernung von 1 m positioniert ist, und bei der Übertragung bei
ADVERTISE_TX_POWER_HIGH
der Wert liegt.
Neue Anforderungen beenden
Wenn Implementierungen von Handheld-Geräten ein logisches Kameragerät enthalten, das Funktionen mithilfe von CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
auflistet, geschieht Folgendes:
- [7.5.4/H-1-1] MUSS standardmäßig ein normales Sichtfeld haben und muss zwischen 50 und 50 Grad liegen.
Implementierungen von Handheld-Geräten:
- [7.6.1/H-0-1] MUSS mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als "/data"-Partition) verfügbar haben.
- [7.6.1/H-0-2] MUSS "true" für
ActivityManager.isLowRamDevice()
zurückgeben, wenn weniger als 1 GB Arbeitsspeicher für den Kernel und den Nutzerbereich verfügbar ist.
Wenn Implementierungen von Handheld-Geräten nur eine 32-Bit-ABI unterstützen:
[7.6.1/H-1-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 416 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis qHD (z.B. FWVGA) verwendet.
[7.6.1/H-2-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 592 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis HD+ (z.B. HD, WSVGA) verwendet.
[7.6.1/H-3-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 896 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis FHD (z.B. WSXGA+) verwendet.
[7.6.1/H-4-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1344 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis zu QHD (z.B. QWXGA) verwendet.
Wenn Implementierungen von Handheld-Geräten die Unterstützung von 64-Bit-ABIs (mit oder ohne 32-Bit-ABI) deklarieren:
[7.6.1/H-5-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 816 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis qHD (z.B. FWVGA) verwendet.
[7.6.1/H-6-1] Der für Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 944 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis HD+ (z.B. HD, WSVGA) verwendet.
[7.6.1/H-7-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.280 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis zu FHD (z. B. WSXGA+) verwendet.
[7.6.1/H-8-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.824 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis zu QHD (z. B. QWXGA) verwendet.
Der oben angegebene „für den Kernel und Userspace verfügbaren Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicher, der zusätzlich zu jedem Arbeitsspeicher zur Verfügung steht, der bereits für Hardwarekomponenten wie Radio, Video usw. vorgesehen ist und nicht unter der Kontrolle des Kernels bei Geräteimplementierungen steht.
Wenn Implementierungen von Handheld-Geräten weniger als oder gleich 1 GB Arbeitsspeicher für den Kernel und Nutzerbereich umfassen, geschieht Folgendes:
- [7.6.1/H-9-1] MUSS das Funktions-Flag
android.hardware.ram.low
deklarieren. - [7.6.1/H-9-2] MUSS mindestens 1,1 GB nichtflüchtigen Speicher für private Anwendungsdaten haben (auch als "/data"-Partition bezeichnet).
Wenn Implementierungen von Handheld-Geräten mehr als 1 GB Arbeitsspeicher für den Kernel und Userspace umfassen, geschieht Folgendes:
- [7.6.1/H-10-1] MUSS mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als "/data"-Partition) verfügbar haben.
- SOLLTEN das Funktions-Flag
android.hardware.ram.normal
deklarieren.
Wenn Implementierungen von Handheld-Geräten größer oder gleich 2 GB und weniger als 4 GB Arbeitsspeicher für Kernel und Nutzerbereich umfassen, gilt Folgendes:
- [7.6.1/H-SR-1] WIRD DRINGEND empfohlen, nur den 32-Bit-Nutzerbereich zu unterstützen (sowohl Apps als auch Systemcode)
Wenn Implementierungen von Handheld-Geräten weniger als 2 GB Arbeitsspeicher für den Kernel und den Nutzerbereich umfassen, geschieht Folgendes:
- [7.6.1/H-1-1] MUSS nur 32-Bit-ABIs unterstützen.
Implementierungen von Handheld-Geräten:
- [7.6.2/H-0-1] DARF KEINEN gemeinsam genutzten Anwendungsspeicher mit weniger als 1 GiB bereitstellen.
- [7.7.1/H] SOLLTEN einen USB-Anschluss haben, der den Peripheriemodus unterstützt.
Wenn Implementierungen von Handheld-Geräten einen USB-Port enthalten, der den Peripheriemodus unterstützt, geschieht Folgendes:
- [7.7.1/H-1-1] MÜSSEN die Android Open Accessory (AOA) API implementieren.
Wenn Implementierungen von Handheld-Geräten einen USB-Port enthalten, der den Hostmodus unterstützt, gilt Folgendes:
- [7.7.2/H-1-1] MÜSSEN die USB-Audioklasse wie in der Android SDK-Dokumentation beschrieben implementieren.
Implementierungen von Handheld-Geräten:
- [7.8.1/H-0-1] MUSS ein Mikrofon enthalten.
- [7.8.2/H-0-1] MUSS einen Audioausgang haben und
android.hardware.audio.output
deklarieren.
Wenn Handheld-Implementierungen alle Leistungsanforderungen für die Unterstützung des VR-Modus erfüllen und diesen unterstützen, gilt Folgendes:
- [7.9.1/H-1-1] MUSS das Funktions-Flag
android.hardware.vr.high_performance
deklarieren. - [7.9.1/H-1-2] MUSS eine App enthalten, die
android.service.vr.VrListenerService
implementiert, die von VR-Anwendungen überandroid.app.Activity#setVrModeEnabled
aktiviert werden kann.
Wenn Implementierungen für Handheld-Geräte einen oder mehrere USB-C-Ports im Hostmodus enthalten und implementieren (USB-Audioklasse), gilt zusätzlich zu den Anforderungen in Abschnitt 7.7.2 Folgendes:
- [7.8.2.2/H-1-1] MUSS die folgende Softwarezuordnung von HID-Codes angeben:
Funktion | Zuordnungen | Kontext | Verhalten |
---|---|---|---|
A | HID-Nutzungsseite: 0x0C HID-Nutzung: 0x0CD Kernelschlüssel: KEY_PLAYPAUSE Android-Schlüssel: KEYCODE_MEDIA_PLAY_PAUSE |
Medienwiedergabe | Eingang: Kurz drücken Ausgabe: Wiedergabe oder Pause |
Eingabe: Lange drücken Ausgabe: Sprachbefehl starten Senden: android.speech.action.VOICE_SEARCH_HANDS_FREE , wenn das Gerät gesperrt oder das Display ausgeschaltet ist. Andernfalls wird android.speech.RecognizerIntent.ACTION_WEB_SEARCH gesendet. |
|||
Eingehender Anruf | Eingabe: Kurz drücken Ausgabe: Anruf annehmen |
||
Eingabe: Lange drücken Ausgabe: Anruf ablehnen |
|||
Aktiver Anruf | Eingabe: Kurz drücken Ausgabe: Anruf beenden |
||
Eingang: Lange drücken Ausgabe: Mikrofon stummschalten oder Stummschaltung aufheben |
|||
Mrd. | HID-Nutzungsseite: 0x0C HID-Nutzung: 0x0E9 Kernelschlüssel: KEY_VOLUMEUP Android-Schlüssel: VOLUME_UP |
Medienwiedergabe, Aktiver Anruf | Eingang: Kurz oder lange 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 | Eingang: Kurz oder lange 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: Kurz oder lange drücken Ausgabe: Sprachbefehl starten |
- [7.8.2.2/H-1-2] MÜSSEN ACTION_HEADSET_PLUG bei einem Steckereinsatz auslösen, aber erst, nachdem die USB-Audioschnittstellen und -Endpunkte ordnungsgemäß aufgelistet wurden, um den angeschlossenen Terminaltyp zu identifizieren.
Wenn der USB-Audioterminal-Typ 0x0302 erkannt wird, geschieht Folgendes:
- [7.8.2.2/H-2-1] MÜSSEN den Intent ACTION_HEADSET_PLUG übertragen und das zusätzliche "microphone" (Mikrofon) auf 0 setzen.
Wenn der USB-Audioterminal-Typ 0x0402 erkannt wird, geschieht Folgendes:
- [7.8.2.2/H-3-1] MÜSSEN den Intent ACTION_HEADSET_PLUG übertragen und das zusätzliche "microphone" (Mikrofon) auf 1 setzen.
Wenn die API AudioManager.getDevices() aufgerufen wird, während das USB-Peripheriegerät angeschlossen ist, gilt Folgendes:
[7.8.2.2/H-4-1] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_HEADSET und die Rolle „isSink()“ auflisten, wenn das Feld für den USB-Audioterminaltyp „0x0302“ lautet.
[7.8.2.2/H-4-2] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_HEADSET und die Rolle isSink() auflisten, wenn das Feld für den USB-Audioterminaltyp 0x0402 lautet.
[7.8.2.2/H-4-3] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_HEADSET und die Rolle isSource() auflisten, wenn das Feld für den USB-Audioterminaltyp 0x0402 lautet.
[7.8.2.2/H-4-4] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE und die Rolle „isSink()“ auflisten, wenn das Feld für den USB-Audioterminaltyp „0x603“ lautet.
[7.8.2.2/H-4-5] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE und Rolle isSource() auflisten, wenn das Feld für den USB-Audioterminaltyp 0x604 lautet.
[7.8.2.2/H-4-6] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE und die Rolle isSink() auflisten, wenn das Feld für den USB-Audioterminaltyp 0x400 lautet.
[7.8.2.2/H-4-7] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE und Rolle isSource() auflisten, wenn das Feld für den USB-Audioterminaltyp 0x400 lautet.
[7.8.2.2/H-SR-1] werden beim Anschluss eines USB-C-Audio-Peripheriegeräts dringend empfohlen, um eine Aufzählung von USB-Deskriptoren durchzuführen, Terminaltypen zu identifizieren und den Intent ACTION_HEADSET_PLUG in weniger als 1.000 Millisekunden zu senden.
Wenn in Implementierungen von Handheld-Geräten android.hardware.audio.output
und android.hardware.microphone
deklariert sind, gilt Folgendes:
[5.6/H-1-1] MUSS eine durchschnittliche Latenz für kontinuierliche Umlaufzeit von 300 Millisekunden oder weniger über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 30 ms über die folgenden Datenpfade haben: „Lautsprecher zu Mikrofon“, 3,5 mm Loopback-Adapter (falls unterstützt), USB-Loopback-Adapter (falls unterstützt).
[5.6/H-1-2] MUSS eine durchschnittliche Tap-to-Tone-Latenz von 300 Millisekunden oder weniger in mindestens 5 Messungen über dem Lautsprecher-zu-Mikrofon-Datenpfad haben.
Implementierungen von Handheld-Geräten, die mindestens einen haptischen Bedienungselement enthalten:
- [7.10/H]* DÜRFEN KEINE haptischen Bedienungselement mit exzentrischer rotierender Masse (ERM) verwenden.
- [7.10/H]* SOLLTEN alle öffentlichen Konstanten für eine klare Haptik in android.view.HapticFeedbackConstants implementieren, nämlich (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAPVI, LONG_PRESSAND_KEYEKE_START, LONG_PRESS.
- [7.10/H]* SOLLTEN alle öffentlichen Konstanten für eindeutige Haptik in android.os.VibrationEffect implementieren, nämlich (EFFEKT_TICK, EFFEKT_KLICK, EFFEKT_HEAVY_CLICK und EFFEKT_DOUBLE_CLICK) und alle zulässigen öffentlichen
PRIMITIVE_*
-Konstanten für Rich_PIN0-Haptik{/0, SPI_THICK1, QUANTIL_THICK1 und hoher haptischer Effekt. Einige dieser Primitive, z. B. LOW_TICK und SPIN, sind möglicherweise nur dann ausführbar, wenn die Vibration relativ niedrige Frequenzen unterstützt. - [7.10/H]* SOLLTEN Sie nach der Anleitung zur Zuordnung öffentlicher Konstanten in android.view.HapticFeedbackConstants den empfohlenen android.os.VibrationEffect-Konstanten mit den entsprechenden Amplitudenbeziehungen folgen.
- [7.10/H]* SOLLTEN der Qualitätsprüfung für die APIs createOneShot() und createWaveform() folgen.
- [7.10/H]* SOLLTEN prüfen, ob das Ergebnis der öffentlichen android.os.Vibrator.hasAmplitudeControl() API die Vibrationsfunktionen korrekt wiedergibt.
- [7.10/H]* SOLLTE die Position des Bedienungselements in der Nähe der Stelle positionieren, an der das Gerät normalerweise von Händen gehalten oder berührt wird.
Ein linearer Resonantaktuator (LRA) ist ein Federsystem mit einer einzigen Masse, das eine dominante Resonanzfrequenz hat, bei der sich die Masse in die gewünschte Bewegung verschiebt.
Wenn Implementierungen von Handheld-Geräten mindestens einen linearen Resonant-Aktuator 7.10 für allgemeine Zwecke enthalten, gilt Folgendes:
Neue Anforderungen erstellen
- [7.10/H] SOLLTE die Position des Bedienungselements in der Nähe der Stelle positionieren, an der das Gerät normalerweise mit Händen gehalten oder berührt wird.
Neue Anforderungen beenden
- [7.10/H]
SOLLTE den haptischen Auslöser in der X-Achse (links-rechts) des natürlichen
Hochformatsdes Geräts verschieben.
Wenn Implementierungen von Handheld-Geräten einen haptischen Bedienelement für allgemeine Zwecke haben, bei dem es sich um einen linearen Resonanzaktuator (X-Achsen-LRA) handelt, gilt Folgendes:
- [7.10/H] SOLLTEN die Resonanzfrequenz der X-Achsen-LRA unter 200 Hz liegen.
Wenn Implementierungen von Handheld-Geräten der Zuordnung haptischer Konstanten folgen, gilt Folgendes:
- [7.10/H]* SOLLTEN den Implementierungsstatus mithilfe der APIs android.os.Vibrator.areAllEffectsSupported() und android.os.Vibrator.arePrimitivesSupported() überprüfen.
[7.10/H]* SOLLTEN eine Qualitätsprüfung für haptische Konstanten durchführen.
[7.10/H]* SOLLTEN bei Bedarf die Fallback-Konfiguration für nicht unterstützte Primitive überprüfen und bei Bedarf aktualisieren, wie in der Implementierungsanleitung für Konstanten beschrieben.
2.2.2. Multimedia
Implementierungen von Handheld-Geräten MÜSSEN die folgenden Audiocodierungs- und -decodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] MPEG-4 AAC Profile (AAC LC)
- [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
- [5.1/H-0-5] AAC ELD (Optimierte AAC mit niedriger Verzögerung)
Implementierungen von Handheld-Geräten MÜSSEN die folgenden Videocodierungsformate unterstützen und für Anwendungen von Drittanbietern verfügbar machen:
Implementierungen von Handheld-Geräten MÜSSEN die folgenden Videodecodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:
2.2.3. Software
Implementierungen von Handheld-Geräten:
- [3.2.3.1/H-0-1] MUSS eine Anwendung haben, die die Intents
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
undACTION_CREATE_DOCUMENT
verarbeitet, wie in den SDK-Dokumenten beschrieben, und die Nutzerberechtigung für den Zugriff auf die Daten des Dokumentanbieters über dieDocumentsProvider
API bereitstellen. - [3.2.3.1/H-0-2]* MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler vorab für alle öffentlichen Intent-Filtermuster laden, die von den folgenden hier aufgeführten Anwendungs-Intents definiert werden.
- [3.2.3.1/H-SR-1] wird dringend empfohlen, vorab eine E-Mail-Anwendung zu laden, die ACTION_SENDTO-, ACTION_SEND- oder ACTION_SEND_MULTIPLE-Intents zum Senden einer E-Mail verarbeiten kann.
- [3.4.1/H-0-1] MUSS eine vollständige Implementierung der
android.webkit.Webview
API bereitstellen. - [3.4.2/H-0-1] MUSS eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten.
- [3.8.1/H-SR-1] wird dringend empfohlen, einen Standard-Launcher zu implementieren, der das Anpinnen von Verknüpfungen, Widgets und widgetFeatures in der App unterstützt.
- [3.8.1/H-SR-2] wird dringend empfohlen, einen Standard-Launcher zu implementieren, der schnellen Zugriff auf die zusätzlichen Verknüpfungen von Drittanbieter-Apps über die ShortcutManager API bietet.
- [3.8.1/H-SR-3] wird dringend empfohlen, eine Standard-Launcher-App einzubinden, die Kennzeichen für die App-Symbole anzeigt.
- [3.8.2/H-SR-1] wird dringend empfohlen, App-Widgets von Drittanbietern zu unterstützen.
- [3.8.3/H-0-1] MÜSSEN Drittanbieter-Apps erlauben, Nutzer über die API-Klassen
Notification
undNotificationManager
über wichtige Ereignisse zu benachrichtigen. - [3.8.3/H-0-2] MUSS die umfangreichen Benachrichtigungen unterstützen.
- [3.8.3/H-0-3] MUSS Vorabbenachrichtigungen unterstützen.
- [3.8.3/H-0-4] MÜSSEN eine Benachrichtigungsleiste enthalten, mit der der Nutzer die Benachrichtigungen direkt steuern (z.B. beantworten, zurückstellen, schließen oder blockieren kann) über Aktionsschaltflächen oder das Steuerfeld, wie in der AOSP implementiert.
- [3.8.3/H-0-5] MÜSSEN die über
RemoteInput.Builder setChoices()
bereitgestellten Auswahlmöglichkeiten in der Benachrichtigungsleiste anzeigen. - [3.8.3/H-SR-1] wird dringend empfohlen, die über
RemoteInput.Builder setChoices()
angegebene erste Auswahlmöglichkeit ohne zusätzliche Nutzerinteraktion in der Benachrichtigungsleiste anzuzeigen. - [3.8.3/H-SR-2] wird dringend empfohlen, alle über
RemoteInput.Builder setChoices()
bereitgestellten Optionen in der Benachrichtigungsleiste anzuzeigen, wenn der Nutzer alle Benachrichtigungen in der Benachrichtigungsleiste maximiert. - [3.8.3.1/H-SR-1] wird dringend empfohlen, Aktionen anzuzeigen, für die
Notification.Action.Builder.setContextual
alstrue
neben den vonNotification.Remoteinput.Builder.setChoices
angezeigten Antworten festgelegt wird. - [3.8.4/H-SR-1] wird dringend empfohlen, auf dem Gerät einen Assistenten für die Unterstützungsaktion zu implementieren.
Wenn Implementierungen von Handheld-Geräten MediaStyle-Benachrichtigungen unterstützen, geschieht Folgendes:
- [3.8.3.1/H-SR-2] werden UNBEDINGT empfohlen, Nutzern Angebote (z. B. Ausgabeauswahl) zu bieten, auf die über die System-UI zugegriffen wird, die es Nutzern ermöglicht, zwischen geeigneten verfügbaren Medienrouten (z. B. Bluetooth-Geräten und Routen, die für
MediaRouter2Manager
bereitgestellt werden) zu wechseln, wenn eine App eineMediaStyle
-Benachrichtigung mit einemMediaSession
-Token veröffentlicht.
Neue Anforderungen erstellen
Wenn Geräteimplementierungen, einschließlich der Navigationstaste für die Funktion „Recents“, wie in Abschnitt 7.2.3 beschrieben, die Schnittstelle ändern, passiert Folgendes:
- [3.8.3/H-1-1] MÜSSEN das Verhalten der Bildschirmfixierung implementieren und dem Nutzer ein Einstellungsmenü zum Ein-/Ausschalten der Funktion zur Verfügung stellen.
Neue Anforderungen beenden
Wenn Implementierungen von Handheld-Geräten die Assist-Aktion unterstützen, gilt Folgendes:
- [3.8.4/H-SR-2] WIRD DRINGEND empfohlen, langes Drücken der
HOME
-Taste als vorgesehene Interaktion zum Starten der Assistant-App zu verwenden, wie in Abschnitt 7.2.3 beschrieben. MÜSSEN die vom Nutzer ausgewählte Assistent-App, also die App, in derVoiceInteractionService
implementiert ist, oder eine Aktivität, die den IntentACTION_ASSIST
verarbeitet, gestartet werden.
Wenn Implementierungen von Handheld-Geräten conversation notifications
unterstützen und sie in einem separaten Abschnitt für Benachrichtigungen und lautlose Benachrichtigungen ohne Unterhaltungen gruppieren, geschieht Folgendes:
- [3.8.4/H-1-1]* MÜSSEN Unterhaltungsbenachrichtigungen vor anderen Benachrichtigungen eingeblendet werden, mit Ausnahme laufender Benachrichtigungen zu Diensten im Vordergrund und Benachrichtigungen vom Typ importance:high.
Wenn Implementierungen von Android-Handheld-Geräten einen Sperrbildschirm unterstützen, gilt Folgendes:
- [3.8.10/H-1-1] MÜSSEN die Sperrbildschirmbenachrichtigungen einschließlich der Media Notification Template anzeigen.
Wenn Handheld-Geräte einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:
- [3.9/H-1-1] MÜSSEN alle Richtlinien zur Geräteverwaltung implementieren, die in der Android SDK-Dokumentation definiert sind.
Wenn Implementierungen von Handheld-Geräten die APIs ControlsProviderService
und Control
unterstützen und Drittanbieter-Apps erlauben, Gerätesteuerung zu veröffentlichen, gilt Folgendes:
- [3.8.16/H-1-1] MÜSSEN das Funktions-Flag
android.software.controls
deklarieren und auftrue
festlegen. - [3.8.16/H-1-2] MUSS einem Nutzer die Möglichkeit geben, bevorzugte Gerätesteuerelemente über die Steuerelemente hinzuzufügen, zu bearbeiten, auszuwählen und zu verwenden, die von den Drittanbieteranwendungen über die
ControlsProviderService
und dieControl
APIs registriert wurden. - [3.8.16/H-1-3] MUSS innerhalb von drei Interaktionen von einem Standard-Launcher aus Zugriff auf dieses Nutzerangebot gewähren.
[3.8.16/H-1-4] MÜSSEN in dieser Nutzerdarstellung den Namen und das Symbol jeder Drittanbieter-App, die Steuerelemente über die
ControlsProviderService
API bereitstellt, sowie alle über dieControl
APIs bereitgestellten Felder korrekt rendern.[3.8.16/H-1-5] MÜSSEN Nutzer dazu berechtigt sein, die von der Drittanbieter-App über die
ControlsProviderService
und dieControl
Control.isAuthRequired
API registrierten Steuerelementen für Authentifizierungsgeräte zu deaktivieren.
Neue Anforderungen erstellen
- [3.8.16/H-1-6] Geräteimplementierungen MÜSSEN die Leistung für Nutzer wie folgt korrekt wiedergeben:
- Wenn auf dem Gerät
config_supportsMultiWindow=true
festgelegt ist und die App die MetadatenMETA_DATA_PANEL_ACTIVITY
in derControlsProviderService
-Deklaration deklariert, einschließlich des ComponentName einer gültigen Aktivität (wie von der API definiert), MUSS die App diese Aktivität in dieses Nutzerangebot einbetten. - Wenn die App die Metadaten
META_DATA_PANEL_ACTIVITY
nicht deklariert, MÜSSEN die von derControlsProviderService
API bereitgestellten Felder sowie alle von den Control APIs bereitgestellten Felder gerendert werden.
- Wenn auf dem Gerät
- [3.8.16/H-1-7] Wenn die App die Metadaten
META_DATA_PANEL_ACTIVITY
deklariert, MUSS sie beim Starten der eingebetteten Aktivität mithilfe vonEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
den Wert der in [3.8.16/H-1-5] definierten Einstellung übergeben.
Neue Anforderungen beenden
Umgekehrt gilt: Wenn solche Kontrollen nicht in Implementierungen von Handheld-Geräten implementiert sind, gilt Folgendes:
- [3.8.16/H-2-1] MÜSSEN
null
für dieControlsProviderService
und dieControl
APIs melden. - [3.8.16/H-2-2] MÜSSEN das Funktions-Flag
android.software.controls
deklarieren und auffalse
festlegen.
Wenn Implementierungen von Handheld-Geräten nicht im Sperrmodus ausgeführt werden und Inhalte in die Zwischenablage kopiert werden, geschieht Folgendes:
- [3.8.17/H-1-1] MÜSSEN dem Nutzer eine Bestätigung vorlegen, dass die Daten in die Zwischenablage kopiert wurden (z. B. eine Miniaturansicht oder eine Warnung, dass Inhalt kopiert wurde). Außerdem muss hier angegeben werden, ob die Daten in der Zwischenablage geräteübergreifend synchronisiert werden.
Implementierungen von Handheld-Geräten:
- [3.10/H-0-1] MUSS Bedienungshilfen von Drittanbietern unterstützen.
- [3.10/H-SR-1] wird dringend empfohlen, Bedienungshilfen vorab auf dem Gerät zu laden, die mit den Bedienungshilfen des Schalterzugriffs und TalkBack (für Sprachen, die von der vorinstallierten Text-in-Sprache-Engine unterstützt werden) vergleichbar oder sogar übertreffen, wie im Open-Source-Projekt Talkback bereitgestellt.
- [3.11/H-0-1] MUSS die Installation von Drittanbieter-TTS-Engines unterstützen.
- [3.11/H-SR-1] wird dringend empfohlen, eine Text-in-Sprache-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
- [3.13/H-SR-1] wird dringend empfohlen, eine UI-Komponente für Schnelleinstellungen hinzuzufügen.
Wenn bei Implementierungen von Android-Handheld-Geräten die Unterstützung von FEATURE_BLUETOOTH
oder FEATURE_WIFI
deklariert wird, geschieht Folgendes:
- [3.16/H-1-1] MUSS die Funktion zum Koppeln von Begleitgeräten unterstützen.
Wenn die Navigationsfunktion als bewegungsbasierte Aktion auf dem Bildschirm bereitgestellt wird:
- [7.2.3/H] Der Bereich für die Bewegungserkennung der Funktion „Zuhause“ SOLLTE am unteren Bildschirmrand nicht höher als 32 dp sein.
Wenn Implementierungen von Handheld-Geräten eine Navigationsfunktion als Geste von einer beliebigen Stelle am linken und rechten Bildschirmrand aus enthalten:
- [7.2.3/H-0-1] Der Touch-Gestenbereich der Navigationsfunktion muss auf jeder Seite kleiner als 40 dp sein. Der Gestenbereich sollte standardmäßig 24 dp breit sein.
Wenn Implementierungen für Handheld-Geräte einen sicheren Sperrbildschirm unterstützen und mehr als oder gleich 2 GB Arbeitsspeicher für den Kernel und den Nutzerbereich zur Verfügung stehen, gilt Folgendes:
- [3.9/H-1-2] MÜSSEN die Unterstützung verwalteter Profile mit dem Funktions-Flag
android.software.managed_users
deklarieren.
Wenn Implementierungen von Android-Handheld-Geräten die Unterstützung für die Kamera über android.hardware.camera.any
deklarieren, geschieht Folgendes:
- [7.5.4/H-1-1] MÜSSEN die Intents
android.media.action.STILL_IMAGE_CAMERA
undandroid.media.action.STILL_IMAGE_CAMERA_SECURE
berücksichtigen und die Kamera wie im SDK beschrieben im Standbildmodus starten. - [7.5.4/H-1-2] MUSS dem
android.media.action.VIDEO_CAMERA
-Intent entsprechen, um die Kamera wie im SDK beschrieben im Videomodus zu starten.
Wenn in der Einstellungsanwendung der Geräteimplementierung eine Aufteilungsfunktion mithilfe von Aktivitätseinbettungen implementiert wird, gilt Folgendes:
- [3.2.3.1/ H-1-1] MUSS eine Aktivität haben, die den Intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY verarbeitet, wenn die Aufteilungsfunktion aktiviert ist. Die Aktivität MUSS durch
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
geschützt sein und die Aktivität des Intents starten, der über Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI geparst wurde.
Neue Anforderungen erstellen
Wenn Geräte, die es Nutzern ermöglichen, beliebige Anrufe zu tätigen,
- [7.4.1.2/H-0-1] MUSS das Funktions-Flag
android.software.telecom
deklarieren. - [7.4.1.2/H-0-2] MÜSSEN das Telekommunikations-Framework implementieren.
Neue Anforderungen beenden
2.2.4 Leistung und Leistung
- [8.1/H-0-1] Konsistente Framelatenz. Inkonsistente Frame-Latenz oder eine Verzögerung beim Rendern von Frames DÜRFEN NICHT häufiger als 5 Frames pro Sekunde auftreten und SOLLTEN in einer Sekunde unter 1 Frames liegen.
- [8.1/H-0-2] Latenz der Benutzeroberfläche. Geräteimplementierungen MÜSSEN für eine geringe Latenz sorgen, indem eine von der Android Compatibility Test Suite (CTS) definierte Liste mit 10.000 Listeneinträgen in weniger als 36 Sekunden durchgescrollt wird.
- [8.1/H-0-3] Aufgabenwechsel. Wenn mehrere Anwendungen gestartet wurden, MUSS der Neustart einer bereits laufenden Anwendung weniger als 1 Sekunde dauern.
Implementierungen von Handheld-Geräten:
- [8.2/H-0-1] MUSS eine sequenzielle Schreibleistung von mindestens 5 MB/s gewährleisten.
- [8.2/H-0-2] MUSS eine zufällige Schreibleistung von mindestens 0,5 MB/s gewährleisten.
- [8.2/H-0-3] MUSS eine sequentielle Leseleistung von mindestens 15 MB/s gewährleisten.
- [8.2/H-0-4] MUSS eine zufällige Leseleistung von mindestens 3,5 MB/s gewährleisten.
Wenn Implementierungen von Handheld-Geräten Funktionen zur Verbesserung des Energiesparmodus für das Gerät enthalten, die in AOSP enthalten sind, oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:
- [8.3/H-1-1] MUSS Nutzern die Möglichkeit bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.
- [8.3/H-1-2] MÜSSEN Nutzern die Möglichkeit bieten, alle Apps anzuzeigen, die vom App-Standby- und dem Stromsparmodus ausgenommen sind.
Implementierungen von Handheld-Geräten:
- [8.4/H-0-1] MÜSSEN ein Leistungsprofil pro Komponente angeben, in dem der Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkuleistung, die durch die Komponenten im Laufe der Zeit verursacht wird, definiert wird, wie auf der Website des Android Open Source-Projekts dokumentiert.
- [8.4/H-0-2] MÜSSEN alle Werte zum Energieverbrauch in Milliamperestunden (mAh) angeben.
- [8.4/H-0-3] MÜSSEN die CPU-Energieverbrauchsaufnahme gemäß der UID jedes Prozesses melden. Das Android Open Source-Projekt erfüllt die Anforderung durch die Implementierung des Kernelmoduls
uid_cputime
. - [8.4/H-0-4] MUSS dem App-Entwickler diesen Stromverbrauch über den Shell-Befehl
adb shell dumpsys batterystats
zur Verfügung stellen. - [8.4/H] SOLLTEN der Hardwarekomponente selbst zugeordnet werden, wenn sie einer Anwendung den Stromverbrauch der Hardwarekomponente nicht zuordnen können.
Implementierungen von Handheld-Geräten, die eine Bildschirm- oder Videoausgabe beinhalten:
- [8.4/H-1-1] MÜSSEN den Intent
android.intent.action.POWER_USAGE_SUMMARY
berücksichtigen und ein Einstellungsmenü mit Informationen zu diesem Stromverbrauch anzeigen.
Implementierungen von Handheld-Geräten:
- [8.5/H-0-1] MÜSSEN ein Nutzerangebot
im Einstellungsmenüzur Verfügung stellen, um alle Apps mit aktiven Diensten oder vom Nutzer initiierten Jobs zu sehen, einschließlich der Dauer der einzelnen Dienste, da sie wie im SDK-Dokument beschrieben gestartet wurden.und die Möglichkeit, eine App zu beenden, in der ein Dienst im Vordergrund ausgeführt wird und die Funktion eines vom Nutzer initiierten Jobs, der im Vordergrund ausgeführt wird, sowie die Möglichkeit, eine App zu beenden, in der ein Dienst im Vordergrund ausgeführt wird, oder ein vom Nutzer initiierter Job zu stoppen.- Einige Apps KÖNNEN, wie im SDK-Dokument beschrieben, von der Beendigung oder Auflistung dieser Apps ausgenommen sein.
Neue Anforderungen erstellen
- [8.5/H-0-2]MÜSSEN ein Nutzerangebot zum Stoppen einer App bereitstellen, die einen Dienst im Vordergrund ausführt, oder einen vom Nutzer initiierten Job.
Neue Anforderungen beenden
2.2.5 Sicherheitsmodell
Implementierungen von Handheld-Geräten:
- [9/H-0-1] MUSS die Funktion
android.hardware.security.model.compatible
deklarieren. - [9.1/H-0-1] MÜSSEN Drittanbieter-Apps den Zugriff auf die Nutzungsstatistiken über die Berechtigung
android.permission.PACKAGE_USAGE_STATS
erlauben und einen für Nutzer zugänglichen Mechanismus bereitstellen, mit dem der Zugriff auf diese Apps als Reaktion auf denandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
-Intent gewährt oder widerrufen werden kann.
Neue Anforderungen erstellen
Wenn in Geräteimplementierungen die Unterstützung von android.hardware.telephony
deklariert wird, gilt Folgendes:
- [9.5/H-1-1] DARF
UserManager.isHeadlessSystemUserMode
NICHT auftrue
setzen.
Neue Anforderungen beenden
Implementierungen von Handheld-Geräten:
- [9.11/H-0-2] MÜSSEN die Schlüsselspeicherimplementierung in einer isolierten Ausführungsumgebung sichern.
- [9.11/H-0-3] MÜSSEN Implementierungen von RSA, AES, ECDSA und HMAC kryptografischen Algorithmen sowie die Hash-Funktionen MD5, SHA1 und SHA-2 der Familie haben, um die unterstützten Algorithmen des Android-Schlüsselspeichersystems in einem Bereich ordnungsgemäß zu unterstützen, der sicher von dem Code isoliert ist, der im Kernel und darüber ausgeführt wird. Sichere Isolation MÜSSEN alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das vorgelagerte Open-Source-Projekt von Android (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternativ können auch eine andere ARM TrustZone-basierte Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer ordnungsgemäßen Hypervisor-basierten Isolierung verwendet werden.
- [9.11/H-0-4] MÜSSEN die Sperrbildschirm-Authentifizierung in der isolierten Ausführungsumgebung durchführen und nur bei erfolgreicher Ausführung die Verwendung der authentifizierungsgebundenen Schlüssel zulassen. Sperrbildschirm-Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Sperrbildschirm-Authentifizierung durchführen kann. Das vorgelagerte Android-Open-Source-Projekt bietet den Gatekeeper Hardware Abstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
- [9.11/H-0-5] MUSS die Schlüsselattestierung unterstützen, wenn der Attestierungssignaturschlüssel durch sichere Hardware geschützt ist und die Signatur auf sicherer Hardware erfolgt. Die Signaturschlüssel für die Attestierung MÜSSEN für eine ausreichend große Anzahl von Geräten freigegeben werden, um zu verhindern, dass die Schlüssel als Gerätekennungen verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer bestimmten SKU produziert werden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, kann für 100.000 Einheiten ein anderer Schlüssel verwendet werden.
Wenn eine Geräteimplementierung bereits unter einer früheren Android-Version gestartet wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen Schlüsselspeicher in einer isolierten Ausführungsumgebung zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert die Funktion android.hardware.fingerprint
, die einen Schlüsselspeicher erfordert, der von einer isolierten Ausführungsumgebung unterstützt wird.
Wenn Handheld-Geräte einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:
- [9.11/H-1-1] MÜSSEN dem Nutzer die kürzeste Zeitüberschreitung für den Ruhemodus ermöglichen. Das ist eine Übergangszeit von maximal 15 Sekunden vom entsperrten in den gesperrten Zustand.
- [9.11/H-1-2] MUSS dem Nutzer die Möglichkeit bieten, Benachrichtigungen auszublenden und alle Formen der Authentifizierung zu deaktivieren, mit Ausnahme der unter 9.11.1 Sicherer Sperrbildschirm beschriebenen primären Authentifizierung. Der AOSP erfüllt die Anforderung als Sperrmodus.
Neue Anforderungen erstellen
Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agenten enthalten, die die TrustAgentService
System API implementieren, geschieht Folgendes:
- [9.11.1/H-1-1] MÜSSEN den Nutzer häufiger als alle 72 Stunden zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) auffordern.
Neue Anforderungen beenden
Wenn Implementierungen von Handheld-Geräten mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony
nicht deklariert wird, geschieht Folgendes:
- [9.5/H-2-1] MÜSSEN 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äteinhaber schnell separate Umgebungen einrichten, in denen zusätzliche Nutzer arbeiten können. Außerdem haben sie die Möglichkeit, detailliertere Einschränkungen in den Anwendungen zu verwalten, die in diesen Umgebungen verfügbar sind.
Wenn Implementierungen von Handheld-Geräten mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony
deklarieren, geschieht Folgendes:
- [9.5/H-3-1] DARF KEINE eingeschränkten Profile unterstützen, MÜSSEN jedoch der AOSP-Implementierung der Steuerelemente entsprechen, mit denen andere Nutzer am Zugriff auf Sprachanrufe und SMS teilnehmen können.
Neue Anforderungen erstellen
Wenn in Implementierungen von Handheld-Geräten UserManager.isHeadlessSystemUserMode
auf true
gesetzt wird,
- [9.5/H-4-1] DARF KEINE Unterstützung für eUICCs oder eSIMs mit Anruffunktion enthalten.
- [9.5/H-4-2] DARF KEINE Unterstützung für
android.hardware.telephony
deklarieren.
Neue Anforderungen beenden
Android unterstützt über die System API einen Mechanismus für eine sichere Hotword-Erkennung, die immer aktiv ist, ohne dass der Mikrofonzugriff angezeigt wird, und die Erkennung von Always-on-Abfragen ohne Angabe des Mikrofon- oder Kamerazugriffs.
Wenn Implementierungen von Handheld-Geräten die System API HotwordDetectionService
oder einen anderen Mechanismus für die Hotword-Erkennung ohne Anzeige des Mikrofonzugriffs unterstützen, gilt Folgendes:
- [9.8/H-1-1] MÜSSEN sicherstellen, dass der Hotword-Erkennungsdienst nur Daten an das System,
ContentCaptureService
oder den vonSpeechRecognizer#createOnDeviceSpeechRecognizer()
erstellten On-Device-Spracherkennungsdienst auf dem Gerät übertragen kann. - [9.8/H-1-2] MÜSSEN sicherstellen, dass der Hotword-Erkennungsdienst nur Mikrofon-Audiodaten oder daraus abgeleitete Daten über die
HotwordDetectionService
API an den Systemserver oder über dieContentCaptureManager
API anContentCaptureService
übertragen kann. - [9.8/H-1-3] DÜRFEN KEIN Mikrofon-Audio bereitstellen, der länger als 30 Sekunden für eine einzelne hardware ausgelöste Anfrage an den Hotword-Erkennungsdienst ist.
- [9.8/H-1-4] DARF KEINE gepufferten Mikrofone bereitstellen, die älter als 8 Sekunden sind, für eine einzelne Anfrage an den Hotword-Erkennungsdienst.
- [9.8/H-1-5] DÜRFEN KEINE gepufferten Mikrofone, die älter als 30 Sekunden sind, an den Sprachinteraktionsdienst oder eine ähnliche Entität weitergeben.
- [9.8/H-1-6] DARF NICHT zulassen, dass bei jedem erfolgreichen Hotword-Ergebnis mehr als 100 Byte Daten aus dem Hotword-Erkennungsdienst übertragen werden, mit Ausnahme von Audiodaten, die über HotwordAudioStream weitergeleitet werden.
- [9.8/H-1-7] DÜRFEN NICHT zulassen, dass bei jedem negativen Hotword-Ergebnis mehr als 5 Bit an Daten aus dem Hotword-Erkennungsdienst übertragen werden.
- [9.8/H-1-8] MUSS die Übertragung von Daten aus dem Hotword-Erkennungsdienst nur bei einer Anfrage zur Hotword-Validierung vom Systemserver zulassen.
- [9.8/H-1-9] DARF NICHT zulassen, dass eine vom Nutzer installierbare Anwendung den Dienst zur Hotword-Erkennung bereitstellt.
- [9.8/H-1-10] DÜRFEN KEINE quantitativen Daten zur Mikrofonnutzung vom Hotword-Erkennungsdienst in der Benutzeroberfläche anzeigen.
- [9.8/H-1-11] MÜSSEN die Anzahl der Byte, die in jeder Übertragung vom Hotword-Erkennungsdienst enthalten sind, protokollieren, damit Sicherheitsforscher sie überprüfen können.
- [9.8/H-1-12] MÜSSEN einen Debug-Modus unterstützen, der den Rohinhalt jeder Übertragung vom Hotword-Erkennungsdienst protokolliert, um die Überprüfung für Sicherheitsexperten zu ermöglichen.
- [9.8/H-1-14] MÜSSEN die Mikrofonanzeige wie in Abschnitt 9.8.2 beschrieben einblenden, wenn ein erfolgreiches Hotword-Ergebnis an den Sprachinteraktionsdienst oder eine ähnliche Entität übertragen wird.
Neue Anforderungen erstellen
- [9.8/H-1-15] MÜSSEN sicherstellen, dass Audiostreams, die bei erfolgreichen Hotword-Ergebnissen bereitgestellt werden, in eine Richtung vom Hotword-Erkennungsdienst an den Sprachinteraktionsdienst übertragen werden.
Neue Anforderungen beenden
- [9.8/H-SR-1] Es wird dringend empfohlen, Nutzer zu benachrichtigen, bevor sie eine Anwendung als Anbieter des Hotword-Erkennungsdienstes festlegen.
- [9.8/H-SR-2] wird dringend empfohlen, die Übertragung unstrukturierter Daten aus dem Hotword-Erkennungsdienst zu unterbinden.
- [9.8/H-SR-3] Es wird dringend empfohlen, den Prozess, der den Dienst zur Hotword-Erkennung hostet, mindestens einmal pro Stunde oder alle 30 Hardware-Trigger-Ereignisse neu zu starten, je nachdem, was zuerst eintritt.
Wenn in der Geräteimplementierung eine Anwendung enthalten ist, die die System API HotwordDetectionService
oder einen ähnlichen Mechanismus zur Hotword-Erkennung ohne Hinweis auf die Mikrofonnutzung verwendet, gilt für die Anwendung Folgendes:
- [9.8/H-2-1] MÜSSEN Nutzer explizit auf jede unterstützte Hotword-Wortgruppe hinweisen.
- [9.8/H-2-2] DÜRFEN KEINE Audio-Rohdaten oder daraus abgeleitete Daten über den Dienst zur Hotword-Erkennung beibehalten.
- [9.8/H-2-3] DÜRFEN KEINE Audiodaten, Audiodaten, die zur vollständigen oder teilweisen Rekonstruktion der Audiodaten verwendet werden können, oder Audioinhalte, die in keinem Zusammenhang mit dem Hotword selbst stehen, übertragen, mit Ausnahme von
ContentCaptureService
oder dem Spracherkennungsdienst auf dem Gerät.
Neue Anforderungen erstellen
Wenn Implementierungen von Handheld-Geräten die System API VisualQueryDetectionService
oder einen anderen Mechanismus zur Abfrageerkennung ohne Angabe des Mikrofon- und/oder Kamerazugriffs unterstützen, gilt Folgendes:
- [9.8/H-3-1] MÜSSEN sicherstellen, dass der Abfrageerkennungsdienst nur Daten an den System-,
ContentCaptureService
- oder On-Device-Spracherkennungsdienst (erstellt vonSpeechRecognizer#createOnDeviceSpeechRecognizer()
) übertragen kann. - [9.8/H-3-2] DÜRFEN NICHT zulassen, dass Audio- oder Videoinformationen aus
VisualQueryDetectionService
übertragen werden, mit Ausnahme vonContentCaptureService
oder dem Spracherkennungsdienst auf dem Gerät. - [9.8/H-3-3] MÜSSEN in der System-UI ein Nutzerhinweis angezeigt werden, wenn das Gerät erkennt, dass ein Nutzer mit der App für digitalen Assistenten interagieren möchte (z. B. durch die Erkennung der Anwesenheit eines Nutzers über die Kamera).
- [9.8/H-3-4] MÜSSEN eine Mikrofonanzeige und die erkannte Nutzeranfrage direkt nach der Erkennung in der Benutzeroberfläche anzeigen.
- [9.8/H-3-5] DARF NICHT zulassen, dass eine vom Nutzer installierbare Anwendung den visuellen Abfrageerkennungsdienst bereitstellt.
Neue Anforderungen beenden
Wenn in Implementierungen von Handheld-Geräten android.hardware.microphone
deklariert ist, gilt Folgendes:
- [9.8.2/H-4-1] MÜSSEN die Mikrofonanzeige einblenden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
oder Apps mit den in Abschnitt 9.1 genannten Rollen mit der CDD-Kennung [C-4-X] auf das Mikrofon zugreifen. - [9.8.2/H-4-2] MÜSSEN die Liste der zuletzt verwendeten und aktiven Apps, die das Mikrofon verwenden, wie von
PermissionManager.getIndicatorAppOpUsageData()
zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen angezeigt werden.
Wenn in Implementierungen von Handheld-Geräten android.hardware.camera.any
deklariert ist, gilt Folgendes:
- [9.8.2/H-5-1] MÜSSEN die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn auf die Kamera nur Apps mit den in Abschnitt 9.1 beschriebenen Rollen mit der CDD-Kennung [C-4-X] zugreifen.
- [9.8.2/H-5-2] MÜSSEN aktuelle und aktive Apps, die die Kamera wie von
PermissionManager.getIndicatorAppOpUsageData()
zurückgegeben haben, zusammen mit allen damit verbundenen Quellenangaben angezeigt werden.
2.2.6 Kompatibilität von Entwicklertools und -optionen
Implementierungen von Handheld-Geräten (* Nicht zutreffend für Tablets):
- [6.1/H-0-1]* MUSS den Shell-Befehl
cmd testharness
unterstützen.
Implementierungen von Handheld-Geräten (* Nicht zutreffend für Tablets):
- Perfetto
- [6.1/H-0-2]* MÜSSEN dem Shell-Nutzer eine
/system/bin/perfetto
-Binärdatei zur Verfügung gestellt werden, wobei die cmdline der Perfetto-Dokumentation entspricht. - [6.1/H-0-3]* Das Perfetto-Binärprogramm MUSS als Eingabe eine protobuf-Konfiguration akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/H-0-4]* Das Perfetto-Binärprogramm MÜSSEN als Ausgabe einen protobuf-Trace schreiben, der dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/H-0-5]* MÜSSEN über das Perfetto-Binärprogramm mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen angeben.
- [6.1/H-0-6]* Der perfetto verfolgte Daemon MUSS standardmäßig aktiviert sein (Systemeigenschaft
persist.traced.enable
).
- [6.1/H-0-2]* MÜSSEN dem Shell-Nutzer eine
2.2.7 Handheld Media Performance-Kurs
Die Definition der Medienleistungsklasse findest du in Abschnitt 7.11.
2.2.7.1 Medien
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.T
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, gilt Folgendes:
- MÜSSEN die in Android 13 CDD, Abschnitt 2.2.7.1 aufgeführten Anforderungen an Medien erfüllen.
Neue Anforderungen erstellen
Wenn Implementierungen von Handheld-Gerätenandroid.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, gilt Folgendes:
- [5.1/H-1-1] MÜSSEN die maximale Anzahl von Hardware-Videodecodersitzungen bekannt geben, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
ausgeführt werden können. - [5.1/H-1-2] MUSS 6 Instanzen von 8-Bit-Hardware-Videodecodersitzungen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen bei einer Auflösung von 1080p bei 30 fps und 3 Sitzungen bei 4K-Auflösung bei AV30 fps läuft, außer AVC, AV1-Codecs sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen. Sie sind aber auch für sechs Instanzen mit 1080p30 fps erforderlich.
- [5.1/H-1-3] MÜSSEN die maximale Anzahl von Hardware-Video-Encoder-Sitzungen bekannt machen, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
ausgeführt werden können. - [5.1/H-1-4] MUSS 6 Instanzen von 8-Bit-Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit 4 Sitzungen bei einer Auflösung von 1080p bei 30 fps und 2 Sitzungen bei 4K-Auflösung bei AV30 fps läuft, außer AVC, AV1-Codecs sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen. Sie sind aber auch für sechs Instanzen mit 1080p30 fps erforderlich.
- [5.1/H-1-5] MÜSSEN die maximale Anzahl von Hardware-Video-Encoder- und -Decoder-Sitzungen bekannt machen, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
ausgeführt werden können. - [5.1/H-1-6] MÜSSEN 6 Instanzen von 8-Bit-Hardware-Videodecoder- und Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen mit einer Auflösung von 4K bei 30 fps (außer AV1) und maximal 30 Encoder-Sitzungen mit Auflösung erforderlich ist. AV1-Codecs sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen. Sie sind aber auch für sechs Instanzen mit 1080p30 fps erforderlich.
- [5.1/H-1-19] MÜSSEN 3 Instanzen von 10-Bit-Hardware-Videodecoder (HDR) und Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 4K bei 30 fps läuft (es sei denn, AV1 kann ein Surface_GL0-Format sein, das in einer Encoder-Sitzung konfiguriert ist). Bei einer Codierung über die GL-Oberfläche ist keine HDR-Metadatengenerierung durch den Encoder erforderlich. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, auch wenn 4K für diese Anforderung erforderlich ist.
- [5.1/H-1-7] MÜSSEN bei einer Videocodierungssitzung mit 1080p oder weniger bei allen Hardware-Video-Encodern unter Last eine Codec-Initialisierungslatenz von 40 ms oder weniger haben. Der Ladevorgang ist hier als eine gleichzeitige reine Videotranscodierungssitzung von 1080p bis 720p definiert, die Hardware-Video-Codecs und die Initialisierung von 1080p-Audio-Video-Aufzeichnungen verwendet. Bei Dolby Vision-Codec MUSS die Codec-Initialisierungslatenz 50 ms oder weniger betragen.
- [5.1/H-1-8] MÜSSEN bei einer Audiocodierungssitzung mit 128 kbit/s oder einer niedrigeren Bitrate bei allen Audio-Encodern unter Last eine Codec-Initialisierungslatenz von 30 ms oder weniger auftreten. Der Ladevorgang ist hier als eine gleichzeitige reine Videotranscodierungssitzung von 1080p bis 720p definiert, die Hardware-Video-Codecs und die Initialisierung von 1080p-Audio-Video-Aufzeichnungen verwendet.
- [5.1/H-1-9] MUSS 2 Instanzen sicherer Hardware-Videodecodersitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 4K bei 30 fps (außer AV1) für 8-Bit- (SDR) und 10-Bit-HDR-Inhalte läuft. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, auch wenn 4K für diese Anforderung erforderlich ist.
- [5.1/H-1-10] MÜSSEN 3 Instanzen nicht sicherer Hardware-Videodecoder-Sitzungen zusammen mit einer Instanz einer sicheren Hardware-Videodecoder-Sitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen bei 4K-Auflösung bei 30 fps und einer sicheren AV1-Sitzung mit einer Auflösung von 30 fps und einer sicheren AV1-Sitzung mit 4K-Auflösung bei 30 fps ausgeführt wird. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, auch wenn 4K für diese Anforderung erforderlich ist.
- [5.1/H-1-11] MÜSSEN für jeden Hardware-AVC-, HEVC-, VP9- oder AV1-Decoder auf dem Gerät einen sicheren Decoder unterstützen.
- [5.1/H-1-12] MÜSSEN unter Last bei einer Videodecodierungssitzung mit 1080p oder kleiner für alle Hardware-Videodecoder eine Codec-Initialisierungslatenz von maximal 40 ms haben. Das Laden ist definiert als eine gleichzeitige reine Videotranscodierung mit 1080p bis 720p, die Hardware-Video-Codecs und die Initialisierung der Audio-Video-Wiedergabe von 1080p verwendet. Bei Dolby Vision-Codec MUSS die Codec-Initialisierungslatenz 50 ms oder weniger betragen.
- [5.1/H-1-13] MÜSSEN bei einer Audiodecodierungssitzung mit 128 kbit/s oder einer niedrigeren Bitrate für alle Audiodecoder unter Last eine Codec-Initialisierungslatenz von 30 ms oder weniger haben. Der Ladevorgang ist hier als eine gleichzeitige reine Videotranscodierungssitzung von 1080p bis 720p definiert, die Hardware-Video-Codecs zusammen mit der Initialisierung der Audio-Video-Wiedergabe von 1080p verwendet.
- [5.1/H-1-14] MÜSSEN den AV1-Hardwaredecoder Main 10, Level 4.1 und Filmkörnung unterstützen.
- [5.1/H-1-15] MUSS mindestens einen Hardware-Videodecoder haben, der 4K60 unterstützt.
- [5.1/H-1-16] MUSS mindestens einen Hardware-Video-Encoder haben, der 4K60 unterstützt.
- [5.3/H-1-1] DARF BEI einer Videositzung mit 4K und 60 fps unter Last NICHT mehr als einen Frame in 10 Sekunden (d.h.weniger als 0,167 % Frame-Abfall) fallen.
- [5.3/H-1-2] DÜRFEN NICHT mehr als 1 Frame in 10 Sekunden während einer Änderung der Videoauflösung in einer Videositzung mit 60 fps unter Last bei einer 4K-Sitzung fallen.
- [5.6/H-1-1] MÜSSEN bei Verwendung des Tap-to-Tone-Tests von CTS Verifier eine Antippen-Ton-Latenz von maximal 80 Millisekunden haben.
- [5.6/H-1-2] MÜSSEN über mindestens einen unterstützten Datenpfad eine Umlauf-Audiolatenz von 80 Millisekunden oder weniger haben.
- [5.6/H-1-3] MUSS MEHR ALS 24-Bit-Audio für die Stereoausgabe über 3,5-mm-Audiobuchsen unterstützen, sofern vorhanden, und über USB, wenn dies über den gesamten Datenpfad für Konfigurationen mit niedriger Latenz und Streaming-Konfigurationen unterstützt wird. Für die Konfiguration mit niedriger Latenz sollte AAudio von der Anwendung im Callback-Modus mit niedriger Latenz verwendet werden. Für die Streamingkonfiguration sollte von der Anwendung ein Java AudioTrack verwendet werden. Sowohl in den Konfigurationen mit niedriger Latenz als auch bei Streamingkonfigurationen sollte die HAL-Ausgabesenke entweder
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
oderAUDIO_FORMAT_PCM_FLOAT
als Zielausgabeformat akzeptieren. - [5.6/H-1-4] MÜSSEN USB-Audiogeräte mit mindestens 4 Kanälen unterstützen (wird von DJ-Controllern für die Vorschau von Songs verwendet.)
- [5.6/H-1-5] MÜSSEN klassenkonforme MIDI-Geräte unterstützen und das MIDI-Funktions-Flag deklarieren.
- [5.6/H-1-9] MUSS mindestens 12 Kanäle unterstützen. Dies impliziert die Möglichkeit, einen AudioTrack mit 7.1.4-Kanal-Maske zu öffnen und alle Kanäle ordnungsgemäß auf Stereo zu übertragen oder zu verkleinern.
- [5.6/H-SR] Es wird dringend empfohlen, 24-Kanal-Mischungen mit mindestens den Kanalmasken 9.1.6 und 22.2 zu unterstützen.
- [5.7/H-1-2] MUSS
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
mit den unten aufgeführten Funktionen zur Inhaltsentschlüsselung unterstützen.
Mindeststichprobengröße | 4 MiB |
Mindestanzahl von Unterstichproben – H264 oder HEVC | 32 |
Mindestanzahl von Teilstichproben – VP9 | 9 |
Mindestanzahl von Teilstichproben – AV1 | 288 |
Minimale Zwischenspeichergröße für Teilstichproben | 1 MiB |
Mindestgröße des generischen Krypto-Zwischenspeichers | 500 KiB |
Mindestanzahl gleichzeitiger Sitzungen | 30 |
Mindestanzahl von Schlüsseln pro Sitzung | 20 |
Mindestanzahl von Schlüsseln (alle Sitzungen) | 80 |
Mindestanzahl der DRM-Schlüssel (alle Sitzungen) | 6 |
Nachrichtengröße | 16 KiB |
Entschlüsselte Frames pro Sekunde | 60 fps |
- [5.1/H-1-17] MUSS mindestens einen Hardware-Bilddecoder haben, der das AVIF-Baseline-Profil unterstützt.
- [5.1/H-1-18] MUSS AV1-Encoder unterstützen, der eine Auflösung von bis zu 480p bei 30 fps und 1 Mbit/s codieren kann.
[5.12/H-1-1] MÜSSEN[5.12/H-SR] dringend empfohlen werden, um dieFeature_HdrEditing
-Funktion für alle Hardware-AV1- und HEVC-Encoder auf dem Gerät zu unterstützen.- [5.12/H-1-2] MÜSSEN das RGBA_1010102-Farbformat für alle Hardware-AV1- und HEVC-Encoder auf dem Gerät unterstützen.
- [5.12/H-1-3] MÜSSEN die Unterstützung der Erweiterung EXT_YUV_target für Stichproben aus YUV-Texturen sowohl in 8 als auch in 10 Bit anbieten.
- [7.1.4/H-1-1] MUSS mindestens 6 Hardware-Overlays in der Display-Verarbeitungseinheit (DPU) enthalten, wobei mindestens zwei davon 10-Bit-Videoinhalte darstellen können.
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben und einen AVC- oder HEVC-Encoder Hardware unterstützen, gilt Folgendes:
- [5.2/H-2-1] MÜSSEN das durch die Videoencoder-Raten-Verzerrungskurven für Hardware-AVC- und HEVC-Codecs definierte Mindestqualitätsziel erfüllen, wie in Tests der Leistungsklasse 14 (PC14) – VEQ-Tests (Video-Codierungsqualität) definiert.
Neue Anforderungen beenden
2.2.7.2 Kamera
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.T
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, gilt Folgendes:
- MÜSSEN die in Android 13 CDD, Abschnitt 2.2.7.2 aufgeführten Anforderungen an Medien erfüllen.
Neue Anforderungen erstellen
Wenn Implementierungen von Handheld-Gerätenandroid.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, gilt Folgendes:
- [7.5/H-1-1] MUSS eine primäre Rückkamera mit einer Auflösung von mindestens 12 Megapixeln haben, die eine Videoaufnahme mit 4K bei 30 fps unterstützt. Die primäre Kamera auf der Rückseite ist die Kamera auf der Rückseite mit der niedrigsten Kamera-ID.
- [7.5/H-1-2] MÜSSEN eine primäre Frontkamera mit einer Auflösung von mindestens 6 Megapixeln haben und Videoaufnahmen mit 1080p bei 30 fps unterstützen. Die primäre Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
- [7.5/H-1-3] MUSS die Eigenschaft
android.info.supportedHardwareLevel
alsFULL
oder besser für die rückwärtige primäre Kamera undLIMITED
oder besser für die primäre Frontkamera unterstützen. - [7.5/H-1-4] MUSS
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
für beide primären Kameras unterstützen. - [7.5/H-1-5] MÜSSEN eine JPEG-Aufnahmelatenz der Kamera2 von unter 1.000
900ms für eine 1080p-Auflösung haben. Der Leistungstest der CTS-Kamera wurde unter ITS-Beleuchtungsbedingungen (3.000 K) für beide primären Kameras gemessen. - [7.5/H-1-6] MUSS die Startlatenz von Kamera 2 (Kamera öffnen, um den ersten Vorschauframe öffnen) unter 500 ms liegen, wie von der CTS-Kameraleistungstest unter ITS-Beleuchtungsbedingungen (3.000 K) für beide primären Kameras gemessen.
- [7.5/H-1-8] MUSS
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
undandroid.graphics.ImageFormat.RAW_SENSOR
für die primäre Rückkamera unterstützen. - [7.5/H-1-9] MUSS auf der Rückseite eine primäre Kamera haben, die 720p oder 1080p bei 240 fps unterstützt.
- [7.5/H-1-10] MÜSSEN mindestens ZOOM_RATIO < 1,0 für die primären Kameras haben, wenn eine Ultraweitwinkel-RGB-Kamera in die gleiche Richtung gerichtet ist.
- [7.5/H-1-11] MUSS gleichzeitiges Front-Back-Streaming auf primären Kameras implementieren.
- [7.5/H-1-12] MUSS
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
sowohl für die primäre Front- als auch die primäre Rückkamera unterstützen. - [7.5/H-1-13] MUSS die
LOGICAL_MULTI_CAMERA
-Funktion für die primäre rückseitige Kamera unterstützen, wenn mehr als eine RGB-Rückkamera vorhanden ist. - [7.5/H-1-14] MUSS die Funktion
STREAM_USE_CASE
sowohl für die primäre Frontkamera als auch für die primäre Rückkamera unterstützen. - [7.5/H-1-15] MÜSSEN
Bokeh- undNachtmoduserweiterungen für primäre Kameras über die Erweiterungen CameraX und Camera2 unterstützen. - [7.5/H-1-16] MUSS die Funktion DYNAMIC_RANGE_TEN_BIT für die primären Kameras unterstützen.
- [7.5/H-1-17] MUSS CONTROL_SCENE_MODE_FACE_PRIORITY und Gesichtserkennung (STATISTICS_FACE_DETECT_MODE_SIMPLE oder STATISTICS_FACE_DETECT_MODE_FULL) für die primären Kameras unterstützen.
Neue Anforderungen beenden
2.2.7.3 Hardware
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.T
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, gilt Folgendes:
- MÜSSEN die in Android 13 CDD, Abschnitt 2.2.7.3 aufgeführten Anforderungen an Medien erfüllen.
Neue Anforderungen erstellen
Wenn Implementierungen von Handheld-Gerätenandroid.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, gilt Folgendes:
- [7.1.1.1/H-2-1] MUSS eine Bildschirmauflösung von mindestens 1080p haben.
- [7.1.1.3/H-2-1] MUSS eine Bildschirmdichte von mindestens 400 dpi haben.
- [7.1.1.3/H-3-1] MUSS ein HDR-Display mit mindestens 1.000 cd/m2 im Durchschnitt haben.
- [7.6.1/H-2-1] MUSS mindestens 8 GB physischen Arbeitsspeicher haben.
Neue Anforderungen beenden
2.2.7.4 Leistung
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.T
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, gilt Folgendes:
- MÜSSEN die in Android 13 CDD, Abschnitt 2.2.7.4 aufgeführten Leistungsanforderungen erfüllen.
Neue Anforderungen erstellen
Wenn Implementierungen von Handheld-Gerätenandroid.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, gilt Folgendes:
- [8.2/H-1-1] MÜSSEN eine sequentielle Schreibleistung von mindestens 150 MB/s gewährleisten.
- [8.2/H-1-2] MÜSSEN eine zufällige Schreibleistung von mindestens 10 MB/s gewährleisten.
- [8.2/H-1-3] MÜSSEN eine sequentielle Leseleistung von mindestens 250 MB/s gewährleisten.
- [8.2/H-1-4] MÜSSEN eine zufällige Leseleistung von mindestens 100 MB/s gewährleisten.
- [8.2/H-1-5] MÜSSEN eine parallele sequenzielle Lese- und Schreibleistung mit einer 2-fachen Lese- und einer 1-fachen Schreibleistung von mindestens 50 MB/s gewährleisten.
Neue Anforderungen beenden
2.3. Fernsehanforderungen
Ein Android-Fernsehgerät bezieht sich auf eine Android-Geräteimplementierung, die eine Unterhaltungsoberfläche für die Wiedergabe digitaler Medien, Filme, Spiele, Apps und/oder Live-TV für Nutzer, die etwa drei Meter entfernt sitzen, darstellt (eine 3 Meter große Benutzeroberfläche).
Implementierungen von Android-Geräten werden als Fernseher eingestuft, wenn sie die folgenden Kriterien erfüllen:
- Bereitstellung eines Mechanismus zur Fernsteuerung der gerenderten Benutzeroberfläche auf dem Bildschirm, die etwa drei Meter vom Nutzer entfernt sein kann
- Sie haben einen eingebetteten Bildschirm mit einer diagonalen Länge von mehr als 24 Zoll ODER einen Videoausgangsanschluss (z. B. VGA, HDMI, DisplayPort) oder einen kabellosen Port für die Anzeige.
Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für die Implementierung von Android TV-Geräten.
2.3.1 Hardware
Implementierungen von Fernsehgeräten:
- [7.2.2/T-0-1] MUSS das Steuerkreuz unterstützen.
- [7.2.3/T-0-1] MÜSSEN die Funktionen „Startseite“ und „Zurück“ bereitstellen.
- [7.2.3/T-0-2] MÜSSEN sowohl das normale als auch das lange Drücken der Funktion „Zurück“ (
KEYCODE_BACK
) an die Anwendung im Vordergrund senden. - [7.2.6.1/T-0-1] MUSS Unterstützung für Gamecontroller enthalten und das Funktions-Flag
android.hardware.gamepad
deklarieren. - [7.2.7/T] SOLLTE eine Fernbedienung bereitstellen, mit der Nutzer auf die Bedienung ohne Touchscreen und die Hauptnavigationstasten zugreifen können.
Wenn Fernsehgeräte ein 3-Achsen-Gyroskop enthalten, ist Folgendes zu beachten:
- [7.3.4/T-1-1] MÜSSEN in der Lage sein, Ereignisse bis zu einer Frequenz von mindestens 100 Hz zu melden.
- [7.3.4/T-1-2] MÜSSEN 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] MUSS mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als "/data"-Partition) verfügbar haben.
Wenn Implementierungen von Fernsehgeräten einen USB-Port enthalten, der den Hostmodus unterstützt, gilt Folgendes:
- [7.5.3/T-1-1] MUSS Unterstützung für eine externe Kamera beinhalten, die über diesen USB-Port angeschlossen wird, aber nicht unbedingt immer angeschlossen ist.
Bei 32-Bit-Implementierungen von TV-Geräten:
[7.6.1/T-1-1] Der für Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 896 MB groß sein, wenn eine der folgenden Dichten verwendet wird:
- Mindestens 400 dpi auf kleinen/normalen Bildschirmen
- xhdpi oder höher auf großen Bildschirmen
- tvdpi oder höher auf sehr großen Bildschirmen
Bei 64-Bit-Implementierungen von TV-Geräten:
[7.6.1/T-2-1] Der für Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 1.280 MB groß sein, wenn eine der folgenden Dichten verwendet wird:
- Mindestens 400 dpi auf kleinen/normalen Bildschirmen
- xhdpi oder höher auf großen Bildschirmen
- tvdpi oder höher auf sehr großen Bildschirmen
Beachten Sie, dass sich der oben angegebene "für den Kernel und Userspace verfügbaren Arbeitsspeicher" auf den Arbeitsspeicher bezieht, der zusätzlich zu jeglichen Arbeitsspeichern bereitgestellt wird, die bereits für Hardwarekomponenten wie Radio, Video usw. vorgesehen sind und nicht der Kontrolle des Kernels auf Geräteimplementierungen unterliegen.
Implementierungen von Fernsehgeräten:
- [7.8.1/T] SOLLTEN ein Mikrofon enthalten.
- [7.8.2/T-0-1] MUSS einen Audioausgang haben und
android.hardware.audio.output
deklarieren.
2.3.2 Multimedia
Implementierungen von Fernsehgeräten MÜSSEN die folgenden Audiocodierungs- und -decodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:
- [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC-Profil (AAC+)
- [5.1/T-0-3] AAC ELD (Optimierte AAC mit niedriger Verzögerung)
Implementierungen von Fernsehgeräten MÜSSEN die folgenden Videocodierungsformate unterstützen und für Anwendungen von Drittanbietern verfügbar machen:
Implementierungen von Fernsehgeräten:
- [5.2.2/T-SR-1] wird dringend empfohlen, die H.264-Codierung von Videos mit einer Auflösung von 720p und 1080p bei 30 Bildern pro Sekunde zu unterstützen.
Implementierungen von Fernsehgeräten MÜSSEN die folgenden Videodecodierungsformate unterstützen und 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
Implementierungen von Fernsehgeräten MÜSSEN die MPEG-2-Decodierung, wie in Abschnitt 5.3.1 beschrieben, bei Standard-Frameraten und -auflösungen für Videos unterstützen, einschließlich:
- [5.3.1/T-1-1] HD 1080p bei 29,97 Bildern pro Sekunde mit High-Level-Hauptprofil.
- [5.3.1/T-1-2] HD 1080i bei 59,94 Bildern pro Sekunde mit High-Level-Hauptprofil. Sie MÜSSEN MPEG-2-Videos mit Zeilenentflechtung per Deinterlacing konvertiert und in Anwendungen von Drittanbietern zur Verfügung gestellt werden.
Implementierungen von Fernsehgeräten MÜSSEN, wie in Abschnitt 5.3.4 beschrieben, die H.264-Decodierung bei Standard-Video-Framerates und -Auflösungen bis einschließlich:
- [5.3.4/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Basisprofil
- [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
Implementierungen von Fernsehgeräten mit H.265-Hardwaredecoder müssen die H.265-Decodierung, wie in Abschnitt 5.3.5 beschrieben, bei Standard-Frameraten und -auflösungen von bis zu einschließlich der Folgenden unterstützen:
- [5.3.5/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Hauptprofilebene 4.1
Wenn Implementierungen von Fernsehgeräten mit H.265-Hardwaredecodierern die H.265-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:
- [5.3.5/T-2-1] MÜSSEN das UHD-Decodierungsprofil bei 60 Bildern pro Sekunde mit dem Main10-Profil der Stufe 5 der Hauptstufe unterstützen.
Implementierungen von Fernsehgeräten MÜSSEN wie in Abschnitt 5.3.6 beschrieben die VP8-Decodierung bei Standard-Framerates und Auflösungen für Videos unterstützen, einschließlich:
- [5.3.6/T-1-1] Decodierungsprofil in HD 1080p bei 60 Bildern pro Sekunde
Implementierungen von Fernsehgeräten mit VP9-Hardwaredecoder müssen die VP9-Decodierung wie in Abschnitt 5.3.7 beschrieben unterstützen, und zwar mit Standard-Framerates und Auflösungen für Video-Frames bis einschließlich:
- [5.3.7/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Profil 0 (8-Bit-Farbtiefe)
Wenn Implementierungen von Fernsehgeräten mit VP9-Hardwaredecodierern die VP9-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:
- [5.3.7/T-2-1] MÜSSEN das UHD-Decodierungsprofil bei 60 Bildern pro Sekunde mit Profil 0 (8-Bit-Farbtiefe) unterstützen.
- [5.3.7/T-SR1] WIRD DRINGEND empfohlen, das UHD-Decodierungsprofil bei 60 Bildern pro Sekunde mit Profil 2 (10-Bit-Farbtiefe) zu unterstützen.
Implementierungen von Fernsehgeräten:
- [5.5/T-0-1] MÜSSEN auf unterstützten Ausgängen Unterstützung für die System-Master-Volume-Dämpfung und die Lautstärkedämpfung der digitalen Audioausgabe enthalten. Hiervon ausgenommen ist die komprimierte Audio-Passthrough-Ausgabe, bei der keine Audiodecodierung auf dem Gerät durchgeführt wird.
Wenn Fernsehgeräte nicht über einen integrierten Bildschirm verfügen, sondern stattdessen einen über HDMI angeschlossenen externen Bildschirm unterstützen, gilt Folgendes:
- [5.8/T-0-1] MÜSSEN für den HDMI-Ausgabemodus die höchste Auflösung für das ausgewählte Pixelformat eingestellt werden, die mit einer Aktualisierungsrate von 50 Hz oder 60 Hz für den externen Bildschirm funktioniert. Dies hängt von der Videoaktualisierungsrate in der Region ab, in der das Gerät verkauft wird.
MÜSSEN im HDMI-Ausgabemodus die maximale Auflösung ausgewählt werden, die mit einer Aktualisierungsrate von 50 Hz oder 60 Hz unterstützt wird. - [5.8/T-SR-1] wird dringend empfohlen, eine vom Nutzer konfigurierbare Auswahl der HDMI-Aktualisierungsrate bereitzustellen.
- [5.8] SOLLTEN die Aktualisierungsrate des HDMI-Ausgabemodus auf entweder 50 Hz oder 60 Hz festlegen. Das ist abhängig von der Videoaktualisierungsrate in der Region, in der das Gerät verkauft wird.
Wenn Fernsehgeräte nicht über einen integrierten Bildschirm verfügen, sondern stattdessen einen über HDMI angeschlossenen externen Bildschirm unterstützen, gilt Folgendes:
- [5.8/T-1-1] MUSS HDCP 2.2 unterstützen.
Wenn Implementierungen von Fernsehgeräten die UHD-Decodierung nicht, sondern einen über HDMI angeschlossenen externen Bildschirm unterstützen, 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
undandroid.hardware.type.television
deklarieren. - [3.2.3.1/T-0-1] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler vorab für alle öffentlichen Intent-Filtermuster laden, die von den folgenden hier aufgeführten Anwendungs-Intents definiert werden.
- [3.4.1/T-0-1] MUSS eine vollständige Implementierung der
android.webkit.Webview
API bereitstellen.
Wenn Android TV-Geräteimplementierungen einen Sperrbildschirm unterstützen,gilt Folgendes:
- [3.8.10/T-1-1] MÜSSEN die Sperrbildschirmbenachrichtigungen einschließlich der Media Notification Template anzeigen.
Implementierungen von Fernsehgeräten:
- [3.8.14/T-SR-1] WIRD UNBEDINGT EMPFOHLEN, um den Bild-im-Bild-Modus (BiB) den Mehrfenstermodus zu unterstützen.
- [3.10/T-0-1] MÜSSEN Bedienungshilfen von Drittanbietern unterstützen.
- [3.10/T-SR-1] WIRD DRINGEND empfohlen, Bedienungshilfen vorab auf dem Gerät zu laden, die mit den Bedienungshilfen des Schalterzugriffs und TalkBack (für Sprachen, die von der vorinstallierten Text-in-Sprache-Engine unterstützt werden) vergleichbar oder sogar übertreffen, wie im Open-Source-Projekt TalkBack bereitgestellt.
Wenn Implementierungen von Fernsehgeräten die Funktion android.hardware.audio.output
melden, geschieht Folgendes:
- [3.11/T-SR-1] wird dringend empfohlen, eine Text-in-Sprache-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
- [3.11/T-1-1] MUSS die Installation von Drittanbieter-TTS-Engines unterstützen.
Implementierungen von Fernsehgeräten:
- [3.12/T-0-1] MUSS das TV Input Framework unterstützen.
2.3.4 Leistung und Leistung
- [8.1/T-0-1] Konsistente Framelatenz. Inkonsistente Frame-Latenz oder eine Verzögerung beim Rendern von Frames DÜRFEN NICHT häufiger als 5 Frames pro Sekunde auftreten und SOLLTEN in einer Sekunde unter 1 Frames liegen.
- [8.2/T-0-1] MÜSSEN für eine sequenzielle Schreibleistung von mindestens 5 MB/s sorgen.
- [8.2/T-0-2] MUSS eine zufällige Schreibleistung von mindestens 0,5 MB/s gewährleisten.
- [8.2/T-0-3] MUSS eine sequenzielle Leseleistung von mindestens 15 MB/s gewährleisten.
- [8.2/T-0-4] MÜSSEN für eine zufällige Leseleistung von mindestens 3,5 MB/s sorgen.
Wenn Implementierungen für Fernsehgeräte Funktionen zur Verbesserung des Energiesparmodus für Geräte enthalten, die in AOSP enthalten sind, oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:
- [8.3/T-1-1] MUSS Nutzern die Möglichkeit bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.
Fernsehgeräte ohne Akku:
- [8.3/T-1-2] MÜSSEN das Gerät als akkuloses Gerät registrieren, wie unter Batterielose Geräte unterstützen beschrieben.
Wenn Fernsehgeräte einen Akku haben, gilt Folgendes:
- [8.3/T-1-3] MÜSSEN Nutzern die Möglichkeit bieten, alle Apps anzuzeigen, die vom App-Standby- und dem Stromsparmodus ausgenommen sind.
Implementierungen von Fernsehgeräten:
- [8.4/T-0-1] MÜSSEN ein Leistungsprofil pro Komponente angeben, das den Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkukapazität durch die Komponenten im Laufe der Zeit definiert, wie auf der Website des Android Open Source-Projekts dokumentiert.
- [8.4/T-0-2] MÜSSEN alle Werte zum Energieverbrauch in Milliamperestunden (mAh) angeben.
- [8.4/T-0-3] MÜSSEN die CPU-Energieverbrauchsaufnahme gemäß der UID jedes Prozesses melden. Das Android Open Source-Projekt erfüllt die Anforderung durch die Implementierung des Kernelmoduls
uid_cputime
. - [8.4/T] SOLLTEN der Hardwarekomponente selbst zugeordnet werden, wenn sie einer Anwendung den Stromverbrauch der Hardwarekomponente nicht zuordnen können.
- [8.4/T-0-4] MUSS dem App-Entwickler diesen Stromverbrauch über den Shell-Befehl
adb shell dumpsys batterystats
zur Verfügung stellen.
2.3.5 Sicherheitsmodell
Implementierungen von Fernsehgeräten:
- [9/T-0-1] MÜSSEN die Funktion
android.hardware.security.model.compatible
deklarieren. - [9.11/T-0-1] MÜSSEN die Schlüsselspeicherimplementierung in einer isolierten Ausführungsumgebung sichern.
- [9.11/T-0-2] MÜSSEN Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie die Hash-Funktionen MD5, SHA1 und SHA-2 der Familie haben, um die unterstützten Algorithmen des Android-Schlüsselspeichersystems in einem Bereich ordnungsgemäß zu unterstützen, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird. Sichere Isolation MÜSSEN alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das vorgelagerte Open-Source-Projekt von Android (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternativ können auch eine andere ARM TrustZone-basierte Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer ordnungsgemäßen Hypervisor-basierten Isolierung verwendet werden.
- [9.11/T-0-3] MÜSSEN die Sperrbildschirm-Authentifizierung in der isolierten Ausführungsumgebung durchführen und nur bei erfolgreicher Ausführung die Verwendung der authentifizierungsgebundenen Schlüssel zulassen. Sperrbildschirm-Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Sperrbildschirm-Authentifizierung durchführen kann. Das vorgelagerte Android-Open-Source-Projekt bietet den Gatekeeper Hardware Abstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
- [9.11/T-0-4] MUSS die Schlüsselattestierung unterstützen, wenn der Attestierungssignaturschlüssel durch sichere Hardware geschützt ist und die Signatur auf sicherer Hardware erfolgt. Die Signaturschlüssel für die Attestierung MÜSSEN für eine ausreichend große Anzahl von Geräten freigegeben werden, um zu verhindern, dass die Schlüssel als Gerätekennungen verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer bestimmten SKU produziert werden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, kann für 100.000 Einheiten ein anderer Schlüssel verwendet werden.
Wenn eine Geräteimplementierung bereits unter einer früheren Android-Version gestartet wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen Schlüsselspeicher in einer isolierten Ausführungsumgebung zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert die Funktion android.hardware.fingerprint
, die einen Schlüsselspeicher erfordert, der von einer isolierten Ausführungsumgebung unterstützt wird.
Wenn Implementierungen von Fernsehgeräten einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:
- [9.11/T-1-1] MÜSSEN dem Nutzer das Zeitlimit für den Ruhemodus für den Wechsel vom entsperrten in den gesperrten Zustand mit einem zulässigen Mindestzeitlimit von maximal 15 Sekunden ermöglichen.
Wenn Implementierungen von Fernsehgeräten mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony
nicht deklariert wird, geschieht Folgendes:
- [9.5/T-2-1] MÜSSEN 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äteinhaber schnell separate Umgebungen einrichten, in denen zusätzliche Nutzer arbeiten können. Außerdem haben sie die Möglichkeit, detailliertere Einschränkungen in den Anwendungen zu verwalten, die in diesen Umgebungen verfügbar sind.
Wenn Implementierungen von Fernsehgeräten mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony
deklarieren, geschieht Folgendes:
- [9.5/T-3-1] DARF KEINE eingeschränkten Profile unterstützen, MÜSSEN jedoch der AOSP-Implementierung der Steuerelemente entsprechen, mit denen andere Nutzer am Zugriff auf Sprachanrufe und SMS teilnehmen können.
Wenn in Implementierungen von Fernsehgeräten android.hardware.microphone
deklariert ist, gilt Folgendes:
- [9.8.2/T-4-1] MÜSSEN die Mikrofonanzeige einblenden, wenn eine App auf Audiodaten vom Mikrofon zugreift, jedoch nicht, wenn nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 „Berechtigungen mit CDD-Kennung C-3-X“ angegebenen Rollen auf das Mikrofon zugreifen.]
- [9.8.2/T-4-2] DARF die Mikrofonanzeige für System-Apps, die sichtbare Benutzeroberflächen oder direkte Nutzerinteraktionen haben, nicht ausblenden.
Wenn in Implementierungen von Fernsehgeräten android.hardware.camera.any
deklariert ist, gilt Folgendes:
- [9.8.2/T-5-1] MÜSSEN die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn nur Apps mit den in Abschnitt 9.1 „Berechtigungen mit CDD-Kennung [C-3-X]“ genannten Rollen auf die Kamera zugreifen.
- [9.8.2/T-5-2] DARF die Kameraanzeige bei System-Apps, die sichtbare Benutzeroberflächen oder direkte Nutzerinteraktionen haben, nicht ausblenden.
2.3.6. Kompatibilität von Entwicklertools und -optionen
Implementierungen von Fernsehgeräten:
- Perfetto
- [6.1/T-0-1] MÜSSEN dem Shell-Nutzer eine
/system/bin/perfetto
-Binärdatei zur Verfügung stellen, wobei die cmdline der Perfetto-Dokumentation entspricht. - [6.1/T-0-2] Das Perfetto-Binärprogramm MUSS als Eingabe eine protobuf-Konfiguration akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/T-0-3] Das Perfetto-Binärprogramm MÜSSEN als Ausgabe einen protobuf-Trace schreiben, der dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/T-0-4] MÜSSEN über das Perfetto-Binärprogramm mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen angeben.
- [6.1/T-0-1] MÜSSEN dem Shell-Nutzer eine
2.4. Smartwatch-Anforderungen
Eine Android Watch bezieht sich auf eine Android-Geräteimplementierung, die am Körper getragen werden soll, z. B. am Handgelenk.
Implementierungen von Android-Geräten werden als Smartwatch eingestuft, wenn sie die folgenden Kriterien erfüllen:
- Die Bildschirmdiagonale muss zwischen 2,8 und 2,5 Zoll liegen.
- Ein Mechanismus zum Tragen am Körper muss vorhanden sein.
Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für die Implementierung von Android Watch-Geräten.
2.4.1 Hardware
Implementierungen von Smartwatch-Geräten:
[7.1.1.1/W-0-1] MUSS ein Display mit einer physischen Diagonale zwischen 1,1 und 2,5 Zoll haben.
[7.2.3/W-0-1] MÜSSEN die Home-Funktion und die Zurück-Funktion für den Nutzer verfügbar sein, es sei denn, sie befindet sich in
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] MUSS die Touchscreen-Eingabe unterstützen.
[7.3.1/W-SR-1] wird dringend empfohlen, einen 3-Achsen-Beschleunigungsmesser zu verwenden.
Wenn Implementierungen der Smartwatch einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps
an Anwendungen melden, geschieht Folgendes:
- [7.3.3/W-1-1] MÜSSEN GNSS-Messungen melden, sobald sie gefunden werden, auch wenn ein über GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
- [7.3.3/W-1-2] MÜSSEN GNSS-Pseudobereiche und Pseudorangeraten melden, die bei freiem Himmel nach der Bestimmung des Standorts bei einer unbeweglichen Bewegung oder bei Bewegungen mit weniger als 0, 2 Metern pro Quadratsekunde ausreichen, um die Position innerhalb von 20 Metern und eine Geschwindigkeit innerhalb von 0, 9 Metern pro Sekunde zu berechnen, und zwar bei mindestens 0, 2 %.
Wenn Smartwatch-Implementierungen ein 3-Achsen-Gyroskop enthalten, gilt Folgendes:
- [7.3.4/W-2-1] MÜSSEN in der Lage sein, Ausrichtungsänderungen von bis zu 1.000 Grad pro Sekunde zu messen.
Implementierungen von Smartwatch-Geräten:
[7.4.3/W-0-1] MUSS Bluetooth unterstützen.
[7.6.1/W-0-1] MUSS mindestens 1 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als "/data"-Partition) verfügbar haben.
[7.6.1/W-0-2] MUSS mindestens 416 MB Arbeitsspeicher für den Kernel und den Userspace zur Verfügung haben.
[7.8.1/W-0-1] MUSS ein Mikrofon enthalten.
[7.8.2/W] KÖNNEN Audioausgang haben.
2.4.2 Multimedia
Keine zusätzlichen Anforderungen.
2.4.3 Software
Implementierungen von Smartwatch-Geräten:
- [3/W-0-1] MUSS das Element
android.hardware.type.watch
deklarieren. - [3/W-0-2] MUSS uiMode = UI_MODE_TYPE_WATCH unterstützen.
- [3.2.3.1/W-0-1] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler vorab für alle öffentlichen Intent-Filtermuster laden, die von den folgenden hier aufgeführten Anwendungs-Intents definiert werden.
Implementierungen von Smartwatch-Geräten:
- [3.8.4/W-SR-1] wird dringend empfohlen, auf dem Gerät einen Assistenten für die Unterstützungsaktion zu implementieren.
Beobachten Sie Geräteimplementierungen, die das Funktions-Flag android.hardware.audio.output
deklarieren:
- [3.10/W-1-1] MUSS Bedienungshilfen von Drittanbietern unterstützen.
- [3.10/W-SR-1] wird dringend empfohlen, Bedienungshilfen vorab auf dem Gerät zu laden, die mit den Bedienungshilfen des Schalterzugriffs und TalkBack (für Sprachen, die von der vorinstallierten Text-in-Sprache-Engine unterstützt werden) vergleichbar oder sogar übertreffen, wie im Open-Source-Projekt TalkBack bereitgestellt.
Wenn Smartwatch-Implementierungen die Funktion „android.hardware.audio.output“ melden, geschieht Folgendes:
[3.11/W-SR-1] wird dringend empfohlen, eine Text-in-Sprache-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
[3.11/W-0-1] MUSS die Installation von Drittanbieter-TTS-Engines unterstützen.
2.4.4 Leistung und Leistung
Wenn Implementierungen von Smartwatch-Geräten Funktionen zur Verbesserung des Energieverbrauchs des Geräts in AOSP oder Erweiterung der in AOSP enthaltenen Features enthalten, gilt Folgendes:
- [8.3/W-SR-1] WIRD UNBEDINGT EMPFOHLEN, Nutzern die Möglichkeit zu bieten, alle Apps anzuzeigen, die vom App-Standby- und Stromsparmodus ausgenommen sind.
- [8.3/W-SR-2] werden DRINGEND empfohlen, Nutzern die Möglichkeit zu bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.
Implementierungen von Smartwatch-Geräten:
- [8.4/W-0-1] MUSS ein Leistungsprofil pro Komponente angeben, in dem der Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkus durch die Komponenten im Zeitverlauf definiert wird, wie auf der Website des Android Open Source-Projekts dokumentiert.
- [8.4/W-0-2] MÜSSEN alle Werte zum Energieverbrauch in Milliamperestunden (mAh) angeben.
- [8.4/W-0-3] MÜSSEN die CPU-Energieverbrauchsaufnahme gemäß der UID jedes Prozesses melden. Das Android Open Source-Projekt erfüllt die Anforderung durch die Implementierung des Kernelmoduls
uid_cputime
. - [8.4/W-0-4] MUSS dem App-Entwickler diesen Stromverbrauch über den Shell-Befehl
adb shell dumpsys batterystats
zur Verfügung stellen. - [8.4/W] SOLLTE der Hardwarekomponente selbst zugeschrieben werden, wenn der Stromverbrauch der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.
2.4.5 Sicherheitsmodell
Implementierungen von Smartwatch-Geräten:
- [9/W-0-1] MUSS die Funktion
android.hardware.security.model.compatible
deklarieren.
Wenn Implementierungen für Smartwatches mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony
nicht deklariert wird, geschieht 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äteinhaber schnell separate Umgebungen einrichten, in denen zusätzliche Nutzer arbeiten können. Außerdem haben sie die Möglichkeit, detailliertere Einschränkungen in den Anwendungen zu verwalten, die in diesen Umgebungen verfügbar sind.
Wenn Implementierungen für Smartwatches mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony
deklarieren, geschieht Folgendes:
- [9.5/W-2-1] DARF KEINE eingeschränkten Profile unterstützen, MÜSSEN jedoch der AOSP-Implementierung der Steuerelemente entsprechen, mit denen andere Nutzer am Zugriff auf Sprachanrufe und SMS teilnehmen können.
Neue Anforderungen erstellen
Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agenten enthalten, die die TrustAgentService
System API implementieren, geschieht Folgendes:
- [9.11.1/W-1-1] MÜSSEN den Nutzer häufiger als alle 72 Stunden zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) auffordern.
Neue Anforderungen beenden
2.5. Fahrzeuganforderungen
Die Android Automotive-Implementierung bezieht sich auf die Haupteinheit eines Fahrzeugs, auf der Android als Betriebssystem für einen Teil oder die gesamte System- und/oder Infotainmentfunktionen ausgeführt wird.
Implementierungen von Android-Geräten werden als „Automobil“ eingestuft, wenn sie die Funktion android.hardware.type.automotive
deklarieren oder alle folgenden Kriterien erfüllen.
- Sie sind als Teil eines Fahrzeugs eingebettet oder können an das angeschlossene Fahrzeug angeschlossen werden.
- ein Display in der Fahrersitzreihe als primäres Display verwenden.
Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Android Automotive-Geräteimplementierungen.
2.5.1 Hardware
Implementierungen von Automobilgeräten:
- [7.1.1.1/A-0-1] MUSS einen Bildschirm mit einer Bildschirmdiagonale von mindestens 6 Zoll haben.
- [7.1.1.1/A-0-2] MÜSSEN ein Layout mit einer Bildschirmgröße von mindestens 750 dp x 480 dp haben.
- [7.2.3/A-0-1] MÜSSEN die Home-Funktion sowie die Funktionen „Zurück“ und „Letzte“ angeben.
- [7.2.3/A-0-2] MÜSSEN sowohl das normale als auch das lange Drücken der Funktion „Zurück“ (
KEYCODE_BACK
) an die Anwendung im Vordergrund senden. - [7.3/A-0-1] MÜSSEN
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
undPARKING_BRAKE_ON
implementieren und melden. - [7.3/A-0-2] Der Wert des Flags
NIGHT_MODE
MÜSSEN mit dem Tag-/Nachtmodus im Dashboard übereinstimmen und auf der Eingabe des Umgebungslichtsensors basieren. Der zugrunde liegende Umgebungslicht-Sensor KANN dem Fotometer entsprechen. - [7.3/A-0-3] MUSS für jeden Sensor ein zusätzliches Infofeld für den Sensor
TYPE_SENSOR_PLACEMENT
als Teil von „SensorAdditionalInfo“ angeben. - [7.3/A-SR1] KANN die Standortermittlung übersehen, wenn GPS/GNSS mit zusätzlichen Sensoren kombiniert wird. Wenn der Standort ungewollt ist, wird UNBEDINGT EMPFOHLEN, die entsprechenden Sensortypen und/oder Fahrzeug-Property-IDs zu implementieren und zu melden.
[7.3/A-0-4] Der über LocationManager#requestLocationUpdates() angeforderte Location DARF NICHT mit einer Karte abgeglichen werden.
[7.3.1/A-0-4] MUSS dem Koordinatensystem für Autosensoren von Android entsprechen.
[7.3/A-SR-1] Sind STRONGLY_RECOMMENDED, um einen 3-Achsen-Beschleunigungsmesser und ein 3-Achsen-Gyroskop einzubeziehen.
[7.3/A-SR-2] sind STRONGLY_RECOMMENDED zur Implementierung und Meldung des
TYPE_HEADING
-Sensors.
Wenn Automotive-Geräteimplementierungen OpenGL ES 3.1 unterstützen, gilt Folgendes:
- [7.1.4.1/A-0-1] MÜSSEN OpenGL ES 3.1 oder höher deklarieren.
- [7.1.4.1/A-0-2] MUSS Vulkan 1.1 unterstützen.
- [7.1.4.1/A-0-3] MUSS das Vulkan-Ladeprogramm enthalten und alle Symbole exportieren.
Wenn Automobil-Geräte einen Beschleunigungsmesser enthalten, gilt Folgendes:
- [7.3.1/A-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 100 Hz melden können.
Wenn Geräte einen dreiachsigen Beschleunigungsmesser enthalten, gilt Folgendes:
- [7.3.1/A-SR-1] wird dringend empfohlen, den Verbundsensor für einen begrenzten Achsen-Beschleunigungsmesser zu implementieren.
Wenn Implementierungen von Automobil-Geräten einen Beschleunigungsmesser mit weniger als drei Achsen enthalten, gilt Folgendes:
- [7.3.1/A-1-3] MÜSSEN den
TYPE_ACCELEROMETER_LIMITED_AXES
-Sensor implementieren und melden. - [7.3.1/A-1-4] MÜSSEN den
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
-Sensor implementieren und melden.
Wenn Automobil-Geräteimplementierungen ein Gyroskop enthalten, ist Folgendes zu beachten:
- [7.3.4/A-2-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 100 Hz melden können.
- [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-1] wird dringend empfohlen, den Messbereich des Gyroskops auf +/-250 dps zu konfigurieren, um die bestmögliche Auflösung zu erzielen.
Wenn Automobil-Geräteimplementierungen ein 3-Achsen-Gyroskop umfassen, ist Folgendes zu beachten:
- [7.3.4/A-SR-2] wird dringend empfohlen, den Verbundsensor für ein eingeschränktes Achsen-Gyroskop zu implementieren.
Wenn Geräte in der Automobilbranche ein Gyroskop mit weniger als 3 Achsen enthalten, gilt Folgendes:
- [7.3.4/A-4-1] MÜSSEN den
TYPE_GYROSCOPE_LIMITED_AXES
-Sensor implementieren und melden. - [7.3.4/A-4-2] MUSS den
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
-Sensor implementieren und melden.
Wenn Automotive-Geräteimplementierungen einen GPS-/GNSS-Empfänger enthalten, aber keine mobilfunkbasierte Datenverbindung, geschieht Folgendes:
- [7.3.3/A-3-1] MÜSSEN den Standort bestimmen, wenn der GPS-/GNSS-Empfänger zum ersten Mal eingeschaltet wird, oder nach mehr als 4 Tagen innerhalb von 60 Sekunden.
- [7.3.3/A-3-2] MÜSSEN die in 7.3.3/C-1-2 und 7.3.3/C-1-6 beschriebenen Kriterien für die Zeit bis zur ersten Problembehebung bei allen anderen Standortanfragen erfüllen (d. h. Anfragen, die nicht das erste Mal überhaupt sind oder nach mehr als 4 Tagen). Die Anforderung 7.3.3/C-1-2 wird in der Regel in Fahrzeugen ohne Mobilfunknetzwerk-basierte Datenverbindung erfüllt. Dazu werden GNSS-Orbit-Vorhersagen verwendet, die auf dem Empfänger berechnet wurden, oder der letzte bekannte Fahrzeugstandort und die Fähigkeit, mindestens 60 Sekunden lang gefahren zu sein, mit einer Positionsgenauigkeit, die 7.3.3/C-1-3 erfüllt, oder einer Kombination aus beidem.
Wenn Fahrzeugimplementierungen einen TYPE_HEADING
-Sensor enthalten, gilt Folgendes:
- [7.3.4/A-4-3] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 1 Hz melden können.
- [7.3.4/A-SR-3] STRONGLY_RECOMMENDED zur Meldung von Ereignissen bis zu einer Frequenz von mindestens 10 Hz.
- SOLLTE sich auf den geografischen Norden beziehen.
- SOLLTEN auch verfügbar sein, wenn das Fahrzeug still steht.
- SOLLTE eine Auflösung von mindestens 1 Grad haben.
Implementierungen von Automobilgeräten:
- [7.4.3/A-0-1] MUSS Bluetooth und Bluetooth LE unterstützen.
- [7.4.3/A-0-2] Android Automotive-Implementierungen MÜSSEN die folgenden Bluetooth-Profile unterstützen:
- Telefonanrufe über Hands-Free Profile (HFP).
- Medienwiedergabe über das 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-1] wird dringend empfohlen, das Message Access Profile (MAP) zu unterstützen.
[7.4.5/A] SOLLTE Unterstützung für mobilnetzbasierte Datenverbindungen enthalten.
[7.4.5/A] KANN die
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
-Konstante der System API für Netzwerke verwenden, die für Systemanwendungen verfügbar sein sollen.
Neue Anforderungen erstellen
Wenn Geräteimplementierungen AM/FM-Radio unterstützen und die Funktion für eine beliebige Anwendung verfügbar machen, gilt Folgendes:
- [7.4
.10/A-0-1] MUSS die Unterstützung fürFEATURE_BROADCAST_RADIO
deklarieren.
Neue Anforderungen beenden
Eine Außenkamera ist eine Kamera, die Szenen außerhalb der Geräteimplementierung aufnimmt, z. B. die Rückkamera.
Implementierungen von Automobilgeräten:
- SOLLTEN eine oder mehrere Außenkameras enthalten.
Wenn Implementierungen von Automobil-Geräten eine Außenkamera umfassen, gilt Folgendes:
- [7.5/A-1-1] DÜRFEN KEINE Außenansichtskameras über die Android Camera APIs zugänglich haben, es sei denn, sie erfüllen die Hauptanforderungen für Kamera.
[7.5/A-SR-1] wird dringend empfohlen, die Kameravorschau nicht zu drehen oder horizontal zu spiegeln.
[7.5/A-SR-2] wird dringend empfohlen, eine Auflösung von mindestens 1,3 Megapixeln zu haben.
SOLLTEN entweder über Fixfokus- oder EDOF-Hardware verfügen.
KANN im Kameratreiber entweder Hardware-Autofokus oder Software-Autofokus implementiert sein.
Wenn Implementierungen für Automobilgeräte eine oder mehrere Außenkameras umfassen und den EVS-Dienst (Exterior View System) laden, gilt für eine solche Kamera Folgendes:
- [7.5/A-2-1] DARF die Kameravorschau NICHT drehen oder horizontal spiegeln.
Implementierungen von Automobilgeräten:
- KÖNNEN eine oder mehrere Kameras enthalten, die für Anwendungen von Drittanbietern verfügbar sind.
Wenn Implementierungen von Automobilgeräten mindestens eine Kamera enthalten und für Anwendungen von Drittanbietern verfügbar gemacht werden, geschieht Folgendes:
- [7.5/A-3-1] MÜSSEN das Funktions-Flag
android.hardware.camera.any
melden. - [7.5/A-3-2] DARF die Kamera nicht als Systemkamera deklarieren.
- KANN externe Kameras unterstützen, wie in Abschnitt 7.5.3 beschrieben.
- KÖNNEN Funktionen wie Autofokus enthalten, die für Kameras auf der Rückseite verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.
Neue Anforderungen erstellen
Eine nach hinten gerichtete Kamera ist eine nach außen gerichtete Kamera, die sich an jedem beliebigen Ort im Fahrzeug anbringen kann und auf die Außenseite des Fahrzeugs zeigt. Das heißt, sie nimmt Szenen von der hinteren Seite der Fahrzeugkarosserie auf, z. B. von der Rückkamera.
Eine Frontkamera ist eine Kamera, die sich an jedem beliebigen Ort im Fahrzeug befindet und in den Innenraum des Fahrzeugs zeigt. Das heißt, sie erfasst den Nutzer, z. B. bei Videokonferenzen und ähnlichen Anwendungen.
Implementierungen von Automobilgeräten:
- [7.5/A-SR-1] wird dringend empfohlen, eine oder mehrere nach außen gerichtete Kameras zu verwenden.
- KANN eine oder mehrere Kameras für den Nutzer enthalten.
- [7.5/A-SR-2] WIRD UNBEDINGT EMPFOHLEN, das gleichzeitige Streaming mehrerer Kameras zu unterstützen.
Wenn Automotive-Geräteimplementierungen mindestens eine Kamera enthalten, die nach der Welt gerichtet ist, gilt für eine solche Kamera Folgendes:
- [7.5/A-1-1] MUSS so ausgerichtet sein, dass die lange Achse der Kamera mit der x-y-Ebene der Android-Automotive-Sensorachsen übereinstimmt.
- [7.5/A-SR-3] Wir empfehlen dringend, entweder Fixfokus- oder EDOF-Hardware (Extended Depth of Field) zu verwenden.
- [7.5/A-1-2] MÜSSEN die primäre nach außen gerichtete Kamera als die nach außen gerichtete Kamera mit der niedrigsten Kamera-ID haben.
Wenn Implementierungen für Automotive-Geräte mindestens eine Kamera enthalten, die dann für den Nutzer sichtbar ist, gilt für eine solche Kamera Folgendes:
- [7.5/A-2-1] Die primäre Kamera für den Nutzer MÜSSEN die Kamera mit der niedrigsten Kamera-ID sein.
- KANN so ausgerichtet werden, dass die lange Dimension der Kamera mit der x-y-Ebene der Android-Automotive-Sensorachsen übereinstimmt.
Wenn Implementierungen für Automotive-Geräte eine Kamera enthalten, auf die entweder über die android.hardware.Camera
API oder die android.hardware.camera2
API zugegriffen werden kann, gilt Folgendes:
- [7.5/A-3-1] MUSS den grundlegenden Kameraanforderungen in Abschnitt 7.5 entsprechen.
Wenn Implementierungen für Automotive-Geräte eine Kamera enthalten, auf die weder über die android.hardware.Camera
noch über die android.hardware.camera2
API zugegriffen werden kann, geschieht Folgendes:
- [7.5/A-4-1] MÜSSEN über den Extended View System-Dienst zugänglich sein.
Wenn Automotive-Geräteimplementierungen eine oder mehrere Kameras umfassen, die über den Extended View System Service zugänglich sind, gilt für eine solche Kamera Folgendes:
- [7.5/A-5-1] Dürfen die Kameravorschau NICHT drehen oder horizontal spiegeln.
- [7.5/A-SR-4] Eine Auflösung von mindestens 1,3 Megapixel wird dringend empfohlen.
Wenn die Implementierungen für Automobilgeräte eine oder mehrere Kameras umfassen, die sowohl über den Extended View System Service als auch über die android.hardware.Camera
oder die android.hardware.Camera2
API zugänglich sind, gilt für eine solche Kamera Folgendes:
- [7.5/A-6-1] MÜSSEN dieselbe Kamera-ID melden.
Wenn Automotive-Geräteimplementierungen eine proprietäre Kamera-API bieten, gilt Folgendes:
- [7.5/A-7-1] MÜSSEN eine solche Kamera-API mit der
android.hardware.camera2
API oder der Extended View System API implementieren.
Neue Anforderungen beenden
Implementierungen von Automobilgeräten:
[7.6.1/A-0-1] MUSS mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als "/data"-Partition) verfügbar haben.
[7.6.1/A] SOLLTEN die Datenpartition formatieren, um die Leistung und Langlebigkeit des Flash-Speichers zu verbessern, z. B. mit dem Dateisystem
f2fs
.
Wenn Automotive-Geräteimplementierungen über einen Teil des internen nicht entfernbaren Speichers gemeinsam genutzten externen Speicher bereitstellen, gilt Folgendes:
- [7.6.1/A-SR-1] wird dringend empfohlen, den E/A-Overhead für Vorgänge zu reduzieren, die auf dem externen Speicher ausgeführt werden, z. B. mit
SDCardFS
.
Bei Automotive-Geräten mit 64-Bit-Implementierungen:
[7.6.1/A-2-1] Der für Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 816 MB groß sein, wenn eine der folgenden Dichten verwendet wird:
- 280 dpi oder niedriger 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 Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 944 MB betragen, wenn eine der folgenden Dichten verwendet wird:
- xhdpi oder höher auf kleinen/normalen Bildschirmen
- HDPI oder mehr auf großen Bildschirmen
- mdpi oder höher auf extragroßen Bildschirmen
[7.6.1/A-2-3] Der für Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 1.280 MB groß sein, wenn eine der folgenden Dichten verwendet wird:
- Mindestens 400 dpi 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 Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 1.824 MB groß sein, wenn eine der folgenden Dichten verwendet wird:
- 560 dpi oder höher auf kleinen/normalen Bildschirmen
- Mindestens 400 dpi auf großen Bildschirmen
- xhdpi oder höher auf extragroßen Bildschirmen
Der oben angegebene „für den Kernel und Userspace verfügbaren Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicher, der zusätzlich zu jedem Arbeitsspeicher zur Verfügung steht, der bereits für Hardwarekomponenten wie Radio, Video usw. vorgesehen ist und nicht unter der Kontrolle des Kernels bei Geräteimplementierungen steht.
Implementierungen von Automobilgeräten:
- [7.7.1/A] SOLLTEN einen USB-Port haben, der den Peripheriemodus unterstützt.
Implementierungen von Automobilgeräten:
- [7.8.1/A-0-1] MUSS ein Mikrofon enthalten.
Implementierungen von Automobilgeräten:
- [7.8.2/A-0-1] MUSS einen Audioausgang haben und
android.hardware.audio.output
deklarieren.
2.5.2 Multimedia
Implementierungen für Automobilgeräte MÜSSEN die folgenden Audiocodierungs- und -decodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:
- [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/A-0-2] MPEG-4 HE AAC-Profil (AAC+)
- [5.1/A-0-3] AAC ELD (Optimierte AAC mit niedriger Verzögerung)
Implementierungen für Automobilgeräte MÜSSEN die folgenden Videocodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:
Implementierungen für Automobilgeräte MÜSSEN die folgenden Videodecodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:
Implementierungen für Automobilgeräte werden dringend empfohlen, die folgende Videodecodierung zu unterstützen:
- [5.3/A-SR-1] H.265 HEVC
2.5.3 Software
Implementierungen von Automobilgeräten:
[3/A-0-1] MUSS das Element
android.hardware.type.automotive
deklarieren.[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 Automotive-Geräteimplementierungen eine proprietäre API bereitstellen, die android.car.CarPropertyManager
mit android.car.VehiclePropertyIds
verwendet, werden sie:
- [3/A-1-1] DÜRFEN KEINE besonderen Berechtigungen für die Verwendung dieser Attribute durch Systemanwendungen gewähren oder Anwendungen von Drittanbietern daran hindern, diese Attribute zu verwenden.
- [3/A-1-2] DARF KEINE Fahrzeugeigenschaft replizieren, die bereits im SDK vorhanden ist.
Implementierungen von Automobilgeräten:
[3.2.1/A-0-1] MÜSSEN alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der Referenzseite für Automotive-Berechtigungen dokumentiert.
[3.2.3.1/A-0-1] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler vorab für alle öffentlichen Intent-Filtermuster laden, die von den folgenden hier aufgeführten Anwendungs-Intents definiert werden.
[3.4.1/A-0-1] MUSS eine vollständige Implementierung der
android.webkit.Webview
API bereitstellen.
Neue Anforderungen erstellen
- [3.8/A-0-1] DÜRFEN NICHT erlauben, dass sekundäre Nutzer, die nicht der aktuelle Nutzer im Vordergrund sind, Aktivitäten starten und auf allen Bildschirmen Zugriff auf die Benutzeroberfläche haben.
Neue Anforderungen beenden
[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-1] wird dringend empfohlen, auf dem Gerät einen Assistenten für die Unterstützungsaktion zu implementieren.
Wenn Implementierungen von Automobil-Geräten eine Push-to-Talk-Taste enthalten, gilt Folgendes:
- [3.8.4/A-1-1] MÜSSEN ein kurzes Drücken der Push-to-Talk-Taste als vorgesehene Interaktion zum Starten der vom Nutzer ausgewählten Assist-App verwendet werden, also der App, in der
VoiceInteractionService
implementiert ist.
Implementierungen von Automobilgeräten:
- [3.8.3.1/A-0-1] MÜSSEN Ressourcen wie in der SDK-Dokumentation für
Notifications on Automotive OS
beschrieben korrekt rendern. - [3.8.3.1/A-0-2] MÜSSEN für Benachrichtigungsaktionen anstelle der über
Notification.Builder.addAction()
bereitgestellten Aktionen WIEDERGABE und STUMMSCHALTEN angezeigt werden. - [3.8.3.1/A] SOLLTEN die Nutzung umfangreicher Verwaltungsaufgaben wie Steuerelemente für einzelne Benachrichtigungskanäle einschränken. KANN die UI-Angebote pro Anwendung verwenden, um die Steuerungsmöglichkeiten zu reduzieren.
Wenn Automotive-Geräteimplementierungen Nutzer-HAL-Eigenschaften unterstützen, gilt Folgendes:
- [3.9.3/A-1-1] MÜSSEN alle Eigenschaften für den Nutzerlebenszyklus implementieren.
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
.
Implementierungen von Automobilgeräten:
- [3.14/A-0-1] MÜSSEN ein UI-Framework zur Unterstützung von Drittanbieter-Apps enthalten, die die in Abschnitt 3.14 beschriebenen Medien-APIs verwenden.
- [3.14/A-0-2] MÜSSEN dem Nutzer die sichere Interaktion mit Medienanwendungen während der Fahrt ermöglichen.
- [3.14/A-0-3] MUSS die implizite Intent-Aktion
CAR_INTENT_ACTION_MEDIA_TEMPLATE
mit dem ZusatzCAR_EXTRA_MEDIA_PACKAGE
unterstützen. - [3.14/A-0-4] MÜSSEN eine Option zum Aufrufen der Einstellungsaktivitäten einer Medienanwendung bereitstellen, MUSS sie aber nur aktivieren, wenn die UX-Einschränkungen für Autos nicht gelten.
- [3.14/A-0-5] MÜSSEN von Medienanwendungen festgelegte Fehlermeldungen anzeigen und die optionalen Extras
ERROR_RESOLUTION_ACTION_LABEL
undERROR_RESOLUTION_ACTION_INTENT
unterstützen. - [3.14/A-0-6] MUSS eine In-App-Suchoption für Apps unterstützen, die die Suche unterstützen.
- [3.14/A-0-7] MÜSSEN bei der Anzeige der MediaBrowser-Hierarchie die Definitionen
CONTENT_STYLE_BROWSABLE_HINT
undCONTENT_STYLE_PLAYABLE_HINT
berücksichtigen.
Wenn Implementierungen für Automotive-Geräte eine Standard-Launcher-App enthalten, gilt Folgendes:
- [3.14/A-1-1] MÜSSEN Mediendienste angeben und mit dem Intent
CAR_INTENT_ACTION_MEDIA_TEMPLATE
öffnen.
Implementierungen von Automobilgeräten:
- [3.8/A] KANN die Anwendungsanfragen einschränken, um in den Vollbildmodus zu wechseln, wie unter
immersive documentation
beschrieben. - [3.8/A] KANN die Statusleiste und die Navigationsleiste jederzeit sichtbar bleiben.
- [3.8/A] KANN die Anwendungsanfragen einschränken, um die Farben hinter den UI-Elementen des Systems zu ändern, damit diese Elemente immer deutlich sichtbar sind.
2.5.4 Leistung und Leistung
Implementierungen von Automobilgeräten:
- [8.2/A-0-1] MÜSSEN die Anzahl der gelesenen und geschriebenen Byte pro UID jedes Prozesses in den nichtflüchtigen Speicher melden, damit die Statistiken für Entwickler über die System API
android.car.storagemonitoring.CarStorageMonitoringManager
verfügbar sind. Das Android-Open-Source-Projekt erfüllt die Anforderung über das Kernelmoduluid_sys_stats
. - [8.3/A-1-3] MUSS den Garagemodus unterstützen.
- [8.3/A] SOLLTEN sich nach jeder Fahrt mindestens 15 Minuten lang im Garagenmodus befinden, es sei denn:
- Der Akku ist leer.
- Es sind keine inaktiven Jobs geplant.
- Der Fahrer beendet den Garagenmodus.
- [8.4/A-0-1] MÜSSEN ein Leistungsprofil pro Komponente angeben, in dem der Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkuleistung, die durch die Komponenten im Laufe der Zeit verursacht wird, definiert wird, wie auf der Website des Android Open Source-Projekts dokumentiert.
- [8.4/A-0-2] MÜSSEN alle Werte zum Energieverbrauch in Milliamperestunden (mAh) angeben.
- [8.4/A-0-3] MÜSSEN die CPU-Energieverbrauchsaufnahme gemäß der UID jedes Prozesses melden. Das Android Open Source-Projekt erfüllt die Anforderung durch die Implementierung des Kernelmoduls
uid_cputime
. - [8.4/A] SOLLTEN der Hardwarekomponente selbst zugeordnet werden, wenn sie einer Anwendung den Stromverbrauch der Hardwarekomponente nicht zuordnen können.
- [8.4/A-0-4] MUSS dem App-Entwickler diesen Stromverbrauch über den Shell-Befehl
adb shell dumpsys batterystats
zur Verfügung stellen.
2.5.5 Sicherheitsmodell
Wenn Automotive-Geräteimplementierungen mehrere Nutzer unterstützen, gilt Folgendes:
- [9.5/A-1-1] DÜRFEN Nutzern die Interaktion oder den Wechsel zum monitorlosen Systemnutzer NICHT erlauben, mit Ausnahme der Gerätebereitstellung.
- [9.5/A-1-2] MÜSSEN vor
BOOT_COMPLETED
zu einem sekundären Nutzer wechseln. - [9.5/A-1-3] MUSS die Möglichkeit zum Erstellen eines Gastnutzers unterstützen, auch wenn die maximale Anzahl von Nutzern auf einem Gerät erreicht ist.
Neue Anforderungen erstellen
Wenn in Implementierungen von Automobil-Geräten android.hardware.microphone
deklariert ist, gilt Folgendes:
- [9.8.2/A-1-1] MÜSSEN die Mikrofonanzeige einblenden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
oder Apps mit den in Abschnitt 9.1 genannten Rollen mit der CDD-Kennung [C-4-X] auf das Mikrofon zugreifen. - [9.8.2/A-1-2] DARF die Mikrofonanzeige für System-Apps, die sichtbare Benutzeroberflächen oder direkte Nutzerinteraktionen haben, nicht ausblenden.
- [9.8.2/A-1-3] MUSS dem Nutzer die Möglichkeit bieten, das Mikrofon in der App „Einstellungen“ ein- oder auszuschalten.
Neue Anforderungen beenden
Wenn in Implementierungen von Automobil-Geräten android.hardware.camera.any
deklariert ist, gilt Folgendes:
- [9.8.2/A-2-1] MÜSSEN die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn nur Apps mit den in
Abschnitt 9.1angegebenen Rollen mit der CDD-Kennung [C-4-X][C-3-X]auf die Kamera zugreifen. - [9.8.2/A-2-2] DARF die Kameraanzeige bei System-Apps, die sichtbare Benutzeroberflächen oder direkte Nutzerinteraktionen haben, nicht ausblenden.
Neue Anforderungen erstellen
- [9.8.2/A-2-3] MÜSSEN Nutzern die Möglichkeit bieten, die Kamera in den Einstellungen ein- und auszuschalten.
- [9.8.2/A-2-4] MÜSSEN aktuelle und aktive Apps, die die Kamera verwenden, wie von
PermissionManager.getIndicatorAppOpUsageData()
zurückgegeben, zusammen mit allen damit verbundenen Quellenangaben angezeigt werden.
Neue Anforderungen beenden
Implementierungen von Automobilgeräten:
- [9/A-0-1] MUSS die Funktion
android.hardware.security.model.compatible
deklarieren. - [9.11/A-0-1] MÜSSEN die Schlüsselspeicherimplementierung in einer isolierten Ausführungsumgebung sichern.
- [9.11/A-0-2] MÜSSEN Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie die Hash-Funktionen MD5, SHA1 und SHA-2 der Familie haben, um die unterstützten Algorithmen des Android-Schlüsselspeichersystems in einem Bereich ordnungsgemäß zu unterstützen, der sicher von dem Code isoliert ist, der auf dem Kernel und darüber ausgeführt wird. Sichere Isolation MÜSSEN alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das vorgelagerte Open-Source-Projekt von Android (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternativ können auch eine andere ARM TrustZone-basierte Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer ordnungsgemäßen Hypervisor-basierten Isolierung verwendet werden.
- [9.11/A-0-3] MUSS die Sperrbildschirm-Authentifizierung in der isolierten Ausführungsumgebung durchführen und nur bei erfolgreicher Ausführung die Verwendung der authentifizierungsgebundenen Schlüssel zulassen. Sperrbildschirm-Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Sperrbildschirm-Authentifizierung durchführen kann. Das vorgelagerte Android-Open-Source-Projekt bietet den Gatekeeper Hardware Abstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
- [9.11/A-0-4] MUSS die Schlüsselattestierung unterstützen, wenn der Attestierungssignaturschlüssel durch sichere Hardware geschützt ist und die Signatur auf sicherer Hardware erfolgt. Die Signaturschlüssel für die Attestierung MÜSSEN für eine ausreichend große Anzahl von Geräten freigegeben werden, um zu verhindern, dass die Schlüssel als Gerätekennungen verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer bestimmten SKU produziert werden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, kann für 100.000 Einheiten ein anderer Schlüssel verwendet werden.
Wenn eine Geräteimplementierung bereits unter einer früheren Android-Version gestartet wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen Schlüsselspeicher in einer isolierten Ausführungsumgebung zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert die Funktion android.hardware.fingerprint
, die einen Schlüsselspeicher erfordert, der von einer isolierten Ausführungsumgebung unterstützt wird.
Implementierungen von Automobilgeräten:
- [9.14/A-0-1] MÜSSEN Gatekeep-Nachrichten von Fahrzeug-Subsystemen von Android-Frameworks verarbeiten, z.B. zulässige Nachrichtentypen und Nachrichtenquellen auf die Zulassungsliste setzen.
- [9.14/A-0-2] MÜSSEN Sie gegen Denial-of-Service-Angriffe vom Android-Framework oder von Drittanbieter-Apps überwachen. So wird verhindert, dass schädliche Software das Fahrzeugnetzwerk mit Traffic überflutet, was zu defekten Fahrzeug-Subsystemen führen kann.
2.5.6 Kompatibilität von Entwicklertools und -optionen
Implementierungen von Automobilgeräten:
- Perfetto
- [6.1/A-0-1] MÜSSEN dem Shell-Nutzer eine
/system/bin/perfetto
-Binärdatei zur Verfügung stellen, wobei die cmdline der Perfetto-Dokumentation entspricht. - [6.1/A-0-2] Das Perfetto-Binärprogramm MUSS als Eingabe eine protobuf-Konfiguration akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/A-0-3] Das Perfetto-Binärprogramm MÜSSEN als Ausgabe einen protobuf-Trace schreiben, der dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [6.1/A-0-4] MÜSSEN über das Perfetto-Binärprogramm mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen angeben.
- [6.1/A-0-1] MÜSSEN dem Shell-Nutzer eine
2.6. Tablet-Anforderungen
Als Android-Tablet wird eine Android-Geräteimplementierung bezeichnet, die normalerweise die folgenden Kriterien erfüllt:
- Wird durch Halten in beiden Händen verwendet.
- Hat keine Clamshell- oder Convertible-Konfiguration.
- Implementierungen einer physischen Tastatur, die mit dem Gerät verwendet werden, werden über eine Standardverbindung (z.B. USB oder Bluetooth) verbunden.
Das Gerät hat eine Stromquelle, die Mobilität ermöglicht, z. B. einen Akku.
Das Display des Displays ist größer als 7 Zoll und kleiner als 18 Zoll, gemessen an diagonaler Messung.
Implementierungen für Tablets haben ähnliche Anforderungen wie Implementierungen auf Mobilgeräten. Die Ausnahmen sind in diesem Abschnitt mit einem * gekennzeichnet und werden in diesem Abschnitt zur Referenz vermerkt.
2.6.1 Hardware
Gyroskop
Wenn Tablet-Geräte ein 3-Achsen-Gyroskop enthalten, ist Folgendes erforderlich:
- [7.3.4/Tab-1-1] MÜSSEN in der Lage sein, Ausrichtungsänderungen bis zu 1.000 Grad pro Sekunde zu messen.
Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)
Die in den Anforderungen für Handhelds für kleine/normale Bildschirme aufgeführte Bildschirmdichten gelten nicht für Tablets.
USB-Peripheriemodus (Abschnitt 7.7.1)
Wenn Tablet-Implementierungen einen USB-Port enthalten, der den Peripheriemodus unterstützt, geschieht Folgendes:
- [7.7.1/Tab] KANN die Android Open Accessory (AOA) API implementieren.
Virtual-Reality-Modus (Abschnitt 7.9.1)
Virtual Reality: High Performance (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)
Siehe Abschnitt [9.11].
Wenn Tablet-Geräteimplementierungen mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony
nicht deklariert wird, geschieht Folgendes:
- [9.5/T-1-1] MÜSSEN 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äteinhaber schnell separate Umgebungen einrichten, in denen zusätzliche Nutzer arbeiten können. Außerdem haben sie die Möglichkeit, detailliertere Einschränkungen in den Anwendungen zu verwalten, die in diesen Umgebungen verfügbar sind.
Wenn Tablet-Geräteimplementierungen mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony
deklarieren, geschieht Folgendes:
- [9.5/T-2-1] DARF KEINE eingeschränkten Profile unterstützen, MÜSSEN jedoch der AOSP-Implementierung der Steuerelemente entsprechen, mit denen andere Nutzer am Zugriff auf Sprachanrufe und SMS teilnehmen können.
2.6.2 Software
- [3.2.3.1/Tab-0-1] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler vorab für alle öffentlichen Intent-Filtermuster laden, die von den folgenden hier aufgeführten Anwendungs-Intents definiert werden.
3. Software
3.1. Kompatibilität mit verwalteten APIs
Die verwaltete Dalvik-Bytecode-Ausführungsumgebung ist das wichtigste Instrument für Android-Anwendungen. Die Android-API (Application Programming Interface) umfasst die Schnittstellen der Android-Plattform, die für Anwendungen sichtbar sind, die in der verwalteten Laufzeitumgebung ausgeführt werden.
Geräteimplementierungen:
[C-0-1] MÜSSEN vollständige Implementierungen, einschließlich aller dokumentierten Verhaltensweisen, aller dokumentierten APIs bereitstellen, die vom Android SDK oder einer API, die im vorgelagerten Android-Quellcode mit der Markierung „@SystemApi“ versehen ist, bereitgestellt werden.
[C-0-2] MÜSSEN alle Klassen, Methoden und zugehörigen Elemente unterstützen bzw. beibehalten, die von der TestApi-Annotation (@TestApi) gekennzeichnet sind.
[C-0-3] DÜRFEN KEINE verwalteten APIs auslassen, API-Schnittstellen oder Signaturen ändern, vom dokumentierten Verhalten abweichen oder No-Ops-Funktionen einschließen, sofern dies nicht ausdrücklich durch diese Kompatibilitätsdefinition gestattet ist.
[C-0-4] MÜSSEN die APIs weiterhin vorhanden sein und sich einwandfrei verhalten, selbst wenn einige Hardwarefunktionen, für die Android APIs enthält, weggelassen werden. Informationen zu spezifischen Anforderungen für dieses Szenario finden Sie in Abschnitt 7.
[C-0-5] DÜRFEN NICHT zulassen, dass Drittanbieter-Apps Nicht-SDK-Schnittstellen verwenden. Diese sind als Methoden und Felder in den Java-Sprachpaketen definiert, die sich im Boot-Klassenpfad in AOSP befinden und nicht Teil des öffentlichen SDK sind. Dazu gehören APIs, die mit der Annotation
@hide
, aber nicht mit einer@SystemAPI
dekoriert sind, wie in den SDK-Dokumenten beschrieben, sowie private und paketprivate Klassenmitglieder.[C-0-6] MÜSSEN mit allen Nicht-SDK-Schnittstellen auf denselben eingeschränkten Listen ausgeliefert werden, die über die Vorläufig- und Sperrlisten-Flags im Pfad
prebuilts/runtime/appcompat/hiddenapi-flags.csv
für den entsprechenden API-Level-Zweig im AOSP bereitgestellt werden.[C-0-7] MÜSSEN den dynamischen Updatemechanismus Signed config (signierte Konfiguration) unterstützen, um Nicht-SDK-Schnittstellen aus einer eingeschränkten Liste zu entfernen. Dazu müssen die signierte Konfiguration in ein beliebiges APK eingebettet werden und die vorhandenen öffentlichen Schlüssel in AOSP verwendet werden.
Allerdings gilt:
- Wenn eine versteckte API fehlt oder in der Geräteimplementierung anders implementiert wurde, verschieben Sie die verborgene API in die Sperrliste oder lassen Sie sie aus allen eingeschränkten Listen weg.
- MAG, wenn noch keine ausgeblendete API in der AOSP vorhanden ist, füge die ausgeblendete API einer der eingeschränkten Listen hinzu.
Neue Anforderungen erstellen
- [C-0-8] DARF NICHT die Installation von Anwendungen unterstützen, die auf ein API-Level unter 23 ausgerichtet sind.
Neue Anforderungen beenden
3.1.1. Android-Erweiterungen
Android unterstützt das Erweitern der verwalteten API-Oberfläche einer bestimmten API-Ebene, indem die Erweiterungsversion für das jeweilige API-Level aktualisiert wird. Die android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API gibt die Erweiterungsversion der angegebenen apiLevel
zurück, wenn Erweiterungen für diese API-Ebene vorhanden sind.
Implementierungen auf Android-Geräten:
[C-0-1] MÜSSEN die AOSP-Implementierung der gemeinsam genutzten Bibliothek
ExtShared
und der DiensteExtServices
vorab mit Versionen laden, die mindestens der für jedes API-Level zulässigen Mindestversion entsprechen. Beispielsweise MUSS bei Android 7.0-Geräteimplementierungen mit API-Level 24 mindestens Version 1 enthalten sein.[C-0-2] MUSS nur eine gültige Versionsnummer der Erweiterung zurückgeben, die von der AOSP definiert wurde.
[C-0-3] MUSS alle APIs, die von den von
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
zurückgegebenen Erweiterungsversionen definiert werden, auf dieselbe Weise unterstützen wie andere verwaltete APIs. Dabei gelten die 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] DARF die Bibliothek
org.apache.http.legacy
NICHT im Bootclasspath platzieren. - [C-0-2] MUSS die
org.apache.http.legacy
-Bibliothek nur dann zum Klassenpfad der Anwendung hinzufügen, wenn die Anwendung eine der folgenden Bedingungen erfüllt:- Ausrichtung auf API-Level 28 oder niedriger.
- Deklariert im Manifest, dass die Bibliothek benötigt wird, indem das Attribut
android:name
von<uses-library>
auforg.apache.http.legacy
gesetzt wird.
Die AOSP-Implementierung erfüllt diese Anforderungen.
3.2. Soft API-Kompatibilität
Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 enthält Android auch eine erhebliche nur zur Laufzeit verfügbare „weiche“ API in Form von Intents, Berechtigungen und ähnlichen Aspekten von Android-Anwendungen, die nicht zum Kompilieren der Anwendung erzwungen werden können.
3.2.1. Berechtigungen
- [C-0-1] Geräteimplementierungen MÜSSEN alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der Referenzseite für Berechtigungen dokumentiert. In Abschnitt 9 sind zusätzliche Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell aufgeführt.
3.2.2. Build-Parameter
Die Android APIs enthalten eine Reihe von Konstanten für die android.os.Build-Klasse, die das aktuelle Gerät beschreiben sollen.
- [C-0-1] Um einheitliche, aussagekräftige Werte für alle Geräteimplementierungen bereitzustellen, enthält die folgende Tabelle zusätzliche Beschränkungen für die Formate dieser Werte, denen die Geräteimplementierungen entsprechen MÜSSEN.
Parameter | Details |
---|---|
VERSION.VERÖFFENTLICHUNG | Die Version des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format. Dieses Feld MUSS einen der Stringwerte enthalten, der unter Zulässige Versionsstrings für Android 14 definiert ist. |
SDK VERSION | Die Version des derzeit ausgeführten Android-Systems in einem Format, auf das Drittanbieter-App-Code zugreifen kann. Bei Android 14 MUSS dieses Feld den Ganzzahlwert 14_INT haben. |
VERSION.SDK_INT | Die Version des derzeit ausgeführten Android-Systems in einem Format, auf das Drittanbieter-App-Code zugreifen kann. Bei Android 14 MUSS dieses Feld den Ganzzahlwert 14_INT haben. |
VERSION.INCREMENTAL | Ein vom Geräte-Implementierer ausgewählter Wert, der den spezifischen Build des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format angibt. Dieser Wert DARF NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. Mit diesem Feld wird typischerweise angegeben, welche Build-Nummer oder Versionsverwaltungs-ID zum Generieren des Builds verwendet wurde. Der Wert dieses Felds MUSS als druckbarer 7-Bit-ASCII codiert werden und dem regulären Ausdruck „^[^ :\/~]+$“ entsprechen. |
BRETTSPIEL | Ein von der Geräteimplementierung ausgewählter Wert, der die vom Gerät verwendete spezifische interne Hardware in einem für Menschen lesbaren Format identifiziert. Dieses Feld kann verwendet werden, um die spezifische Überarbeitung der Leiterplatte anzugeben, über die das Gerät betrieben wird. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen. |
MARKE | Ein Wert, der den mit dem Gerät verbundenen Markennamen angibt, der den Endnutzern bekannt ist. MÜSSEN in einem für Menschen lesbaren Format vorliegen und den Hersteller des Geräts oder die Unternehmensmarke repräsentieren, unter der das Gerät vertrieben wird. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck "^[a-zA-Z0-9_-]+$" entsprechen. |
UNTERSTÜTZTE ABIS | Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität. |
UNTERSTÜTZT_32_BIT_ABIS | Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität. |
UNTERSTÜTZT_64_BIT_ABIS | Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität. |
CPU_ABI | Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität. |
CPU_ABI2 | Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität. |
GERÄT | Wert, der vom Geräte-Implementierer ausgewählt wird und den Entwicklungsnamen oder Codenamen enthält, der die Konfiguration der Hardwarefunktionen und das Industriedesign des Geräts identifiziert. Der Wert dieses Feldes MUSS als 7-Bit-ASCII codiert werden und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen. Dieser Gerätename DARF NICHT während der Lebensdauer des Produkts geändert werden. |
Fingerabdruck | Ein String, der diesen Build eindeutig identifiziert. Sie SOLLTEN menschenlesbar sein. Sie MUSS dieser Vorlage folgen:
$(BRAND)/$(PRODUCT)/ Beispiel: acme/meinprodukt/ Der Fingerabdruck DARF KEINE Leerzeichen enthalten. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können. |
Hardware | Der Name der Hardware (aus der Kernel-Befehlszeile oder aus „/proc“). Sie SOLLTE angemessen für Menschen lesbar sein. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck "^[a-zA-Z0-9_-]+$" entsprechen. |
Moderator | Ein String, der den Host, auf dem der Build erstellt wurde, in menschenlesbarem Format eindeutig identifiziert. Es gibt keine Anforderungen an das spezifische Format dieses Felds, außer dass es NICHT null sein oder der leere String („“) sein darf. |
ID | Eine vom Geräte-Implementierer ausgewählte Kennung in einem visuell lesbaren Format, um auf eine bestimmte Version zu verweisen. Dieses Feld kann mit „android.os.Build.VERSION.INCREMENTAL“ identisch sein, SOLLTE aber ein Wert sein, der für Endnutzer aussagekräftig genug ist, um zwischen Software-Builds zu unterscheiden. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen. |
HERSTELLER | Der Handelsname des Erstausrüsters (Original Equipment Manufacturer, OEM) des Produkts. Es gibt keine Anforderungen an das spezifische Format dieses Felds, mit der Ausnahme, dass es NICHT null sein oder der leere String („“) sein darf. Dieses Feld DARF NICHT während der Lebensdauer des Produkts geändert werden. |
SOC-Hersteller | Der Handelsname des Herstellers des im Produkt verwendeten primären System-on-Chips (SOC). Geräte mit demselben SOC-Hersteller sollten denselben konstanten Wert verwenden. Erkundigen Sie sich beim SOC-Hersteller nach der richtigen Konstante. Der Wert dieses Felds MÜSSEN als 7-Bit-ASCII codiert werden, MUSS mit dem regulären Ausdruck „^([0-9A-Za-z ]+)“ übereinstimmen, DARF NICHT mit einem Leerzeichen beginnen oder enden und DARF NICHT gleich „unbekannt“ sein. Dieses Feld DARF NICHT während der Lebensdauer des Produkts geändert werden. |
SOC-Modell | Der Modellname des primären Systems-on-Chips (SOC), das im Produkt verwendet wird. Geräte mit demselben SOC-Modell sollten denselben konstanten Wert verwenden. Fragen Sie den SOC-Hersteller nach der richtigen Konstante. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden und dem regulären Ausdruck „^([0-9A-Za-z ._/+-]+)$“ entsprechen, DARF NICHT mit einem Leerzeichen beginnen oder enden und NICHT gleich „unknown“ sein. Dieses Feld DARF NICHT während der Lebensdauer des Produkts geändert werden. |
MODELL | Ein Wert, der vom Geräte-Implementierer ausgewählt wird, der den Namen des Geräts enthält, der dem Endnutzer bekannt ist. Dies SOLLTE der Name sein, unter dem das Gerät vermarktet und an Endnutzer verkauft wird. Es gibt keine Anforderungen an das spezifische Format dieses Felds, mit der Ausnahme, dass es NICHT null sein oder der leere String („“) sein darf. Dieses Feld DARF NICHT während der Lebensdauer des Produkts geändert werden. |
PRODUKT/FUNKTION | Ein vom Geräte-Implementierer ausgewählter Wert, der den Entwicklungs- oder Codenamen des jeweiligen Produkts (SKU) enthält und innerhalb derselben Marke eindeutig sein MUSS. MUSS für Menschen lesbar sein, sind aber nicht unbedingt zur Ansicht für Endnutzer gedacht. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck "^[a-zA-Z0-9_-]+$" entsprechen. Dieser Produktname DARF NICHT während der Lebensdauer des Produkts geändert werden. |
ODM_SKU | Ein optionaler Wert, der vom Geräte-Implementierer ausgewählt wird und die Artikelnummer (Stock Keeping Unit) enthält. Damit werden bestimmte Konfigurationen des Geräts erfasst, z. B. Peripheriegeräte, die beim Verkauf im Gerät enthalten sind. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck "[0-9A-Za-z.,_-])" entsprechen. |
Seriennummer | MÜSSEN "UNKNOWN" zurückgeben. |
TAGS | Eine durch Kommas getrennte Liste von Tags, die vom Geräte-Implementierer ausgewählt wurden und den Build weiter unterscheiden. Die Tags MÜSSEN als 7-Bit-ASCII kodierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9._-]+“ entsprechen. Außerdem MÜSSEN sie einen der Werte haben, die den drei typischen Signaturkonfigurationen der Android-Plattform entsprechen: Release-Schlüssel, Entwicklungsschlüssel und Testschlüssel. |
UHRZEIT | Ein Wert, der den Zeitstempel für den Build darstellt. |
SCHREIBMASCHINE | Wert, der vom Geräte-Implementierer ausgewählt wird, der die Laufzeitkonfiguration des Builds angibt. Dieses Feld MUSS einen der Werte enthalten, die den drei typischen Android-Laufzeitkonfigurationen entsprechen: user, userdebug oder eng. |
NUTZER | Ein Name oder eine Nutzer-ID des Nutzers (oder automatisierten Nutzers), der den Build generiert hat. Es gibt keine Anforderungen für das spezifische Format dieses Felds, außer dass es NICHT null sein oder der leere String („“) sein darf. |
SICHERHEITSPATCH | Ein Wert, der die Sicherheitspatch-Ebene eines Builds angibt. Er MUSS angeben, dass der Build in keiner Weise anfällig für eines der Probleme ist, die im vorgesehenen öffentlichen Sicherheitsbulletin für Android beschrieben sind. Sie MUSS das Format [JJJJ-MM-TT] haben und mit einem definierten String übereinstimmen, der im öffentlichen Sicherheitsbulletin von Android oder in den Sicherheitshinweisen von Android dokumentiert ist, z. B. „2015-11-01“. |
BASIS_OS | Ein Wert, der den FINGERPrint-Parameter des Builds darstellt und ansonsten mit diesem Build identisch ist, mit Ausnahme der Patches, die im Android Public Security Bulletin bereitgestellt werden. Sie MÜSSEN den richtigen Wert melden. Wenn ein solcher Build nicht vorhanden ist, wird ein leerer String („“) gemeldet. |
BOOTLOADER | Ein vom Geräte-Implementierer ausgewählter Wert, der die spezifische interne Bootloader-Version identifiziert, die auf dem Gerät verwendet wird, in einem für Menschen lesbaren Format. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen. |
getRadioVersion() | MÜSSEN (oder zurückgegeben) ein vom Geräte-Implementierer ausgewählter Wert sein, der die spezifische interne Funk-/Modemversion in einem visuell lesbaren Format identifiziert. Wenn ein Gerät kein internes Funk- oder Modem hat, MUSS NULL zurückgegeben werden. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck "^[a-zA-Z0-9._-,]+$" entsprechen. |
getSerial() | MÜSSEN (oder zurückgeben) eine Hardware-Seriennummer, die für alle Geräte mit demselben MODELL und MANUFACTURER verfügbar und eindeutig sein MUSS. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9]+$“ entsprechen. |
3.2.3 Intent-Kompatibilität
3.2.3.1 Allgemeine Anwendungs-Intents
Mit Android-Intents können Anwendungskomponenten Funktionen von anderen Android-Komponenten anfordern. Das Android-Upstream-Projekt enthält eine Liste von Anwendungen, die mehrere Intent-Muster zum Ausführen allgemeiner Aktionen implementieren.
Geräteimplementierungen:
- [C-SR-1] Es wird dringend empfohlen, eine oder mehrere Anwendungen oder Dienstkomponenten vorab mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster zu laden, die von den folgenden hier aufgeführten Anwendungs-Intents definiert werden, und die Auftragsausführung zu ermöglichen, d.h. die Erwartungen des Entwicklers für diese gängigen Anwendungs-Intents zu erfüllen, wie im SDK beschrieben.
Informationen zu obligatorischen Anwendungs-Intents für jeden Gerätetyp finden Sie in Abschnitt 2.
3.2.3.2 Intent-Auflösung
[C-0-1] Da Android eine erweiterbare Plattform ist, MÜSSEN bei Geräteimplementierungen alle Intent-Muster, auf die in Abschnitt 3.2.3.1 verwiesen wird, von Drittanbieter-Apps überschrieben werden, mit Ausnahme der Einstellungen. Die Open-Source-Implementierung von Android ermöglicht dies standardmäßig.
[C-0-2] Geräte-Implementierer DÜRFEN KEINE besonderen Berechtigungen für die Nutzung dieser Intent-Muster durch Systemanwendungen zuweisen oder verhindern, dass Anwendungen von Drittanbietern eine Bindung an diese Muster herstellen und die Kontrolle über diese Muster übernehmen. Dieses Verbot umfasst insbesondere die Deaktivierung der Benutzeroberfläche „Auswahl“, ü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 den Daten-URI enthält. Beispielsweise ist ein Intent-Filtermuster, das den Daten-URI „http://www.android.com“ angibt, spezifischer als das grundlegende Intent-Muster des Browsers für „http://“.
Android umfasst auch einen Mechanismus, mit dem Drittanbieter-Apps ein maßgebliches standardmäßiges App-Verknüpfungsverhalten für bestimmte Arten von Web-URI-Intents deklarieren können. Wenn solche autoritativen Deklarationen in den Intent-Filtermustern einer App definiert sind, gilt für Geräteimplementierungen Folgendes:
- [C-0-4] MÜSSEN versuchen, Intent-Filter zu validieren. Dazu führen Sie die in der Spezifikation für Digital Asset Links definierten Validierungsschritte aus, die vom Paketmanager im vorgelagerten Android-Open-Source-Projekt implementiert wurden.
- [C-0-5] MÜSSEN während der Installation der Anwendung die Intent-Filter validieren und alle erfolgreich validierten URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen.
- Sie können bestimmte URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen, wenn sie erfolgreich überprüft wurden, aber andere mögliche URI-Filter die Prüfung nicht bestehen. Wenn dies bei einer Geräteimplementierung geschieht, MUSS sie dem Nutzer im Einstellungsmenü die entsprechenden Pro-URI-Musterüberschreibungen bereitstellen.
- MÜSSEN dem Nutzer in den Einstellungen Steuerelemente für App-Links zur Verfügung stehen:
- [C-0-6] Der Nutzer MÜSSEN in der Lage sein, das Standardverhalten von App-Links für eine App ganzheitlich zu überschreiben: immer geöffnet, immer fragen oder nie öffnen. Dies muss für alle möglichen URI-Intent-Filter gleichermaßen gelten.
- [C-0-7] Der Nutzer MÜSSEN eine Liste möglicher URI-Intent-Filter sehen können.
- Die Geräteimplementierung MÖGLICHERWEISE dem Nutzer die Möglichkeit geben, bestimmte URI-Intent-Filter, die erfolgreich bestätigt wurden, auf Basis eines einzelnen Intent-Filters zu überschreiben.
- [C-0-8] Die Geräteimplementierung MÜSSEN Nutzern die Möglichkeit bieten, bestimmte mögliche URI-Intent-Filter aufzurufen und zu überschreiben, wenn bei der Geräteimplementierung einige der möglichen URI-Intent-Filter erfolgreich überprüft werden können, während andere fehlschlagen können.
3.2.3.3 Intent-Namespaces
- [C-0-1] Geräteimplementierungen DÜRFEN KEINE Android-Komponente enthalten, die neue Intent- oder Broadcast-Intent-Muster mit einer ACTION-, CATEGORY- oder anderen Schlüsselzeichenfolge im Namespace android.* oder com.android.* würdigt.
- [C-0-2] Geräte-Implementierer DÜRFEN KEINE Android-Komponenten enthalten, die neue Intent- oder Broadcast-Intent-Muster mit einer ACTION-, CATEGORY- oder anderen Schlüsselzeichenfolge in einem Paketbereich, der zu einer anderen Organisation gehört, würdigen.
- [C-0-3] Geräteimplementierungen 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 klar und deutlich der eigenen Organisation zugeordnet sind. Dieses Verbot entspricht dem Verbot, das in Abschnitt 3.6 für Java-Sprachklassen angegeben wurde.
3.2.3.4 Übertragungs-Intents
Drittanbieteranwendungen nutzen die Plattform, um bestimmte Intents zu senden und sie über Änderungen in der Hardware- oder Softwareumgebung zu informieren.
Geräteimplementierungen:
- [C-0-1] MÜSSEN die hier aufgeführten öffentlichen Übertragungs-Intents als Reaktion auf entsprechende Systemereignisse gemäß der SDK-Dokumentation übertragen. Diese Anforderung steht nicht im Widerspruch zu Abschnitt 3.5, da die Beschränkung für Hintergrundanwendungen auch in der SDK-Dokumentation beschrieben wird. Bestimmte Übertragungs-Intents sind von der Hardwareunterstützung abhängig. Wenn das Gerät die erforderliche Hardware unterstützt, MÜSSEN die Intents übertragen und das Verhalten gemäß der SDK-Dokumentation bereitgestellt werden.
3.2.3.5 Bedingte Anwendungs-Intents
Android bietet Einstellungen, mit denen Nutzer ihre Standardanwendungen einfach auswählen können, z. B. für den Startbildschirm oder für SMS.
Wo es sinnvoll ist, 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 Geräteimplementierungen android.software.home_screen
melden, geschieht Folgendes:
- [C-1-1] MÜSSEN den Intent
android.settings.HOME_SETTINGS
berücksichtigen, damit für den Startbildschirm ein Standardmenü mit App-Einstellungen angezeigt wird.
Wenn Geräteimplementierungen android.hardware.telephony.calling
melden, geschieht Folgendes:
[C-2-1] MÜSSEN ein Einstellungsmenü bereitstellen, das den Intent
android.provider.Telephony.ACTION_CHANGE_DEFAULT
aufruft, um ein Dialogfeld zum Ändern der Standard-SMS-Anwendung anzuzeigen.[C-2-2] MÜSSEN den Intent
android.telecom.action.CHANGE_DEFAULT_DIALER
berücksichtigen, um ein Dialogfeld anzuzeigen, über das der Nutzer die Standard-Telefonanwendung ändern kann.- MÜSSEN die vom Nutzer ausgewählte UI der Standard-Telefon-App für ein- und ausgehende Anrufe verwendet werden, außer für Notrufe, für die die vorinstallierte Telefon-App verwendet wird.
[C-2-3] MÜSSEN die Absicht von android.telecom.action.CHANGE_PHONE_ACCOUNTS berücksichtigen, dem Nutzer die Möglichkeit zu bieten, das mit
PhoneAccounts
verknüpfteConnectionServices
sowie ein standardmäßiges PhoneAccount zu konfigurieren, das der Telekommunikationsanbieter für ausgehende Anrufe verwendet. Die AOSP-Implementierung erfüllt diese Anforderung, indem im Einstellungsmenü „Anrufe“ ein Menü „Anrufkonten“ hinzugefügt wird.[C-2-4] MUSS
android.telecom.CallRedirectionService
für eine Anwendung zulassen, die die Rolleandroid.app.role.CALL_REDIRECTION
hat.[C-2-5] MÜSSEN dem Nutzer die Möglichkeit bieten, eine App mit der Rolle
android.app.role.CALL_REDIRECTION
auszuwählen.[C-2-6] MÜSSEN die Intents android.intent.action.SENDTO und android.intent.action.VIEW berücksichtigen und eine Aktivität zum Senden/Anzeigen von SMS-Nachrichten angeben.
[C-SR-1] EMPFOHLEN: android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_button, android.intent.action.VIEW und android.intent.action.DIAL mit einer vorab geladenen Dialer-App berücksichtigen, die diese Intents verarbeiten und die Auftragsausführung wie in der SDK-Beschreibung beschrieben bereitstellen kann.
Wenn Geräteimplementierungen android.hardware.nfc.hce
melden, geschieht Folgendes:
- [C-3-1] MÜSSEN den Intent android.settings.NFC_PAYMENT_SETTINGS berücksichtigen, um ein Standardmenü mit App-Einstellungen für kontaktloses Bezahlen anzuzeigen.
- [C-3-2] MÜSSEN den Intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT berücksichtigen, um eine Aktivität anzuzeigen, mit der ein Dialogfeld geöffnet wird, in dem der Nutzer aufgefordert wird, den Standarddienst zur Kartenemulation für eine bestimmte Kategorie zu ändern, wie im SDK beschrieben.
Wenn Geräteimplementierungen android.hardware.nfc
melden, geschieht Folgendes:
- [C-4-1] MÜSSEN die Intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED und android.nfc.action.TECH_DISCOVERED berücksichtigen, um eine Aktivität darzustellen, die den Entwicklererwartungen an diese Intents entspricht, wie im SDK beschrieben.
Wenn Geräteimplementierungen android.hardware.bluetooth
melden, geschieht Folgendes:
- [C-5-1] MUSS den Intent android.bluetooth.adapter.action.REQUEST_ENABLE berücksichtigen und eine Systemaktivität anzeigen, damit der Nutzer Bluetooth aktivieren kann.
- [C-5-2] MUSS den Intent android.bluetooth.adapter.action.REQUEST_DISCOVERABLE berücksichtigen und eine Systemaktivität anzeigen, die den Erkennungsmodus anfordert.
Wenn Geräteimplementierungen die Funktion „Nicht stören“ unterstützen, gilt Folgendes:
- [C-6-1] MÜSSEN eine Aktivität implementieren, die auf den Intent
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
reagieren würde. Bei Implementierungen mit UI_MODE_TYPE_NORMAL MUSS es sich dabei um eine Aktivität handeln, bei der der Nutzer der App Zugriff auf nicht störende Richtlinienkonfigurationen gewähren oder verweigern kann.
Wenn Nutzer bei der Geräteimplementierung Eingabemethoden von Drittanbietern auf dem Gerät verwenden können, gilt Folgendes:
- [C-7-1] MÜSSEN einen für Nutzer zugänglichen Mechanismus bereitstellen, um Eingabemethoden von Drittanbietern als Reaktion auf den Intent
android.settings.INPUT_METHOD_SETTINGS
hinzuzufügen und zu konfigurieren.
Wenn Geräteimplementierungen Bedienungshilfen von Drittanbietern unterstützen, gilt Folgendes:
- [C-8-1] MÜSSEN die
android.settings.ACCESSIBILITY_SETTINGS
-Intents berücksichtigen, um einen für Nutzer zugänglichen Mechanismus bereitzustellen, mit dem die Bedienungshilfen von Drittanbietern neben den vorinstallierten Bedienungshilfen aktiviert und deaktiviert werden können.
Wenn Geräteimplementierungen Wi-Fi Easy Connect unterstützen und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:
- [C-9-1] MÜSSEN die Intent APIs Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI wie in der SDK-Dokumentation beschrieben implementieren.
Wenn Geräteimplementierungen den Datensparmodus unterstützen, ist Folgendes möglich:
- [C-10-1] MÜSSEN in den Einstellungen eine Benutzeroberfläche zur Verfügung stellen, die den
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
-Intent verarbeitet und es Nutzern ermöglicht, Anwendungen auf die Zulassungsliste zu setzen oder daraus zu entfernen.
Wenn Geräteimplementierungen den Datensparmodus nicht unterstützen, kann das folgende Gründe haben:
- [C-11-1] MUSS eine Aktivität haben, die den
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
-Intent verarbeitet, KANN ihn aber als No-Op implementieren.
Wenn Geräteimplementierungen die Unterstützung der Kamera über android.hardware.camera.any
deklarieren, geschieht Folgendes:
- [C-12-3] MÜSSEN und MÜSSEN nur vorinstallierte Android-Apps die Verarbeitung der folgenden Intents
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
undMediaStore.ACTION_VIDEO_CAPTURE
verarbeiten, wie im SDK-Dokument beschrieben.
Wenn Geräteimplementierungen android.software.device_admin
melden, geschieht Folgendes:
[C-13-1] MÜSSEN den Intent
android.app.action.ADD_DEVICE_ADMIN
berücksichtigen, um eine UI aufzurufen, um den Nutzer durch Hinzufügen des Geräteadministrators zum System oder Ablehnen des Zugriffs zuzulassen.[C-13-2] MÜSSEN die Intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD und android.app.action.START_ENCRYPTION berücksichtigen und eine Aktivität zur Bereitstellung der Auftragsausführung für diese Intents wie hier beschrieben haben.
Wenn Geräteimplementierungen das Funktions-Flag android.software.autofill
deklarieren, geschieht Folgendes:
- [C-14-1] MÜSSEN die APIs
AutofillService
undAutofillManager
vollständig implementieren und den Intent android.settings.REQUEST_SET_AUTOFILL_SERVICE berücksichtigen, um ein Standardmenü mit App-Einstellungen zum Aktivieren und Deaktivieren von Autofill anzuzeigen und den standardmäßigen Autofill-Dienst für den Nutzer zu ändern.
Wenn Geräteimplementierungen eine vorinstallierte App enthalten oder Drittanbieter-Apps den Zugriff auf die Nutzungsstatistiken erlauben möchten, gilt Folgendes:
- [C-SR-2] wird dringend empfohlen, Apps, die die Berechtigung
android.permission.PACKAGE_USAGE_STATS
deklarieren, einen zugänglichen Mechanismus bereitzustellen, mit dem der Zugriff auf die Nutzungsstatistiken als Reaktion auf den Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS gewährt oder widerrufen kann.
Wenn in Geräteimplementierungen verhindert wird, dass Apps, einschließlich vorinstallierter Apps, auf die Nutzungsstatistiken zugreifen, geschieht Folgendes:
- [C-15-1] MÜSSEN weiterhin eine Aktivität haben, die das Intent-Muster android.settings.ACTION_USAGE_ACCESS_SETTINGS verarbeitet, aber MÜSSEN sie als No-Op implementieren, das sich genauso verhält wie bei einer Zugriffsverweigerung des Nutzers.
Wenn bei Geräteimplementierungen Links zu den Aktivitäten angezeigt werden, die in den Einstellungen unter AutofillService_passwordsActivity angegeben sind, oder über einen ähnlichen Mechanismus auf Nutzerpasswörter verweist, geschieht Folgendes:
- [C-16-1] Solche Links MÜSSEN für alle installierten Autofill-Dienste angezeigt werden.
Wenn Geräteimplementierungen das VoiceInteractionService
unterstützen und mehr als eine Anwendung, die diese API verwendet, gleichzeitig installiert ist, geschieht Folgendes:
- [C-18-1] MÜSSEN den Intent
android.settings.ACTION_VOICE_INPUT_SETTINGS
berücksichtigen, um ein Standardmenü mit App-Einstellungen für Spracheingabe und Unterstützung anzuzeigen.
Wenn Geräteimplementierungen die Funktion android.hardware.audio.output
melden, geschieht Folgendes:
- [C-SR-3] Es wird dringend empfohlen, die Intents „android.intent.action.TTS_SERVICE“, „android.speech.tts.engine.INSTALL_TTS_DATA“ und „android.speech.tts.engine.GET_SAMPLE_TEXT“ zu berücksichtigen, um die Ausführung für diese Intents bereitzustellen, wie hier im SDK beschrieben.
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 in einem Desktop-Dock angedockt ist. Geräteimplementierungen:
- SOLLTEN Bildschirmschoner unterstützen und Nutzern eine Einstellungsoption zur Konfiguration von Bildschirmschonern als Reaktion auf den Intent
android.settings.DREAM_SETTINGS
bieten.
Neue Anforderungen erstellen
Wenn Geräteimplementierungen android.hardware.nfc.uicc
oder android.hardware.nfc.ese
melden, geschieht Folgendes:
- [C-19-1] MÜSSEN die NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API implementieren (als „EVT_TRANSACTION“ gemäß der technischen Spezifikation der GSM Association TS.26 – Anforderungen an NFC-Mobilgeräte).
Neue Anforderungen beenden
3.2.4 Aktivitäten auf sekundären/mehreren Displays
Wenn Geräteimplementierungen das Starten normaler Android-Aktivitäten auf mehr als einem Bildschirm zulassen, geschieht Folgendes:
- [C-1-1] MUSS das Feature-Flag
android.software.activities_on_secondary_displays
festlegen. - [C-1-2] MUSS eine API-Kompatibilität ähnlich einer Aktivität, die auf dem primären Bildschirm ausgeführt wird, garantiert werden.
- [C-1-3] MÜSSEN die neue Aktivität auf dem gleichen Display wie die Aktivität anzeigen, die sie gestartet hat, wenn die neue Aktivität gestartet wird, ohne eine Zielanzeige über die
ActivityOptions.setLaunchDisplayId()
API anzugeben. - [C-1-4] MUSS alle Aktivitäten löschen, wenn eine Anzeige mit dem Flag
Display.FLAG_PRIVATE
entfernt wird. - [C-1-5] MÜSSEN Inhalte auf allen Bildschirmen sicher verstecken, wenn das Gerät mit einem sicheren Sperrbildschirm gesperrt ist, es sei denn, die App lässt die Anzeige über dem Sperrbildschirm mithilfe der
Activity#setShowWhenLocked()
API zu. - SOLLTEN SIE
android.content.res.Configuration
haben, das dieser Anzeige entspricht, damit sie angezeigt wird, korrekt funktioniert und die Kompatibilität aufrechterhalten wird, wenn eine Aktivität auf einem sekundären Display gestartet wird.
Wenn Geräteimplementierungen das Starten normaler Android-Aktivitäten auf sekundären Displays zulassen und ein sekundärer Bildschirm das Flag android.view.Display.FLAG_PRIVATE hat, gilt Folgendes:
- [C-3-1] Nur der Eigentümer dieses Displays, Systems und Aktivitäten, die sich bereits auf diesem Bildschirm befinden, MUSS in der Lage sein, das Gerät zu starten. Jeder kann einen Bildschirm mit dem Flag android.view.Display.FLAG_PUBLIC aufrufen.
3.3. Native API-Kompatibilität
Die Kompatibilität mit nativem Code ist schwierig. Daher sind Geräteimplementierungen:
- [C-SR-1] EMPFOHLEN, die Implementierungen der unten aufgeführten Bibliotheken aus dem vorgelagerten Android-Open-Source-Projekt zu verwenden.
3.3.1 Binäre Anwendungsschnittstellen
Der verwaltete Dalvik-Bytecode kann den nativen Code aufrufen, der in der .apk
-Anwendungsdatei als ELF-.so
-Datei bereitgestellt wird, die für die entsprechende Gerätehardwarearchitektur kompiliert wurde. Da nativer Code stark von der zugrunde liegenden Prozessortechnologie abhängt, definiert Android eine Reihe von Binärschnittstellen (Application Binary Interfaces, ABIs) im Android-NDK.
Geräteimplementierungen:
- [C-0-1] MÜSSEN mit einem oder mehreren definierten Android-NDK-ABIs kompatibel sein.
- [C-0-2] MÜSSEN Unterstützung für Code bieten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code mit der standardmäßigen JNI-Semantik (Java Native Interface) aufzurufen.
- [C-0-3] MÜSSEN mit jeder erforderlichen Bibliothek in der Liste unten quellkompatibel (d.h. header-kompatibel) und binär kompatibel (für das ABI) sein.
- [C-0-5] MÜSSEN die native Binärschnittstelle (Application Binary Interface, ABI), die vom Gerät unterstützt wird, korrekt über die Parameter
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
undandroid.os.Build.SUPPORTED_64_BIT_ABIS
melden, wobei die Parameter jeweils eine durch Kommas getrennte Liste von ABIs sind, sortiert von der am häufigsten bis zur am wenigsten bevorzugten. [C-0-6] MÜSSEN über die oben genannten Parameter eine Teilmenge der folgenden Liste von ABIs melden und DARF KEINE ABIs melden, 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] MÜSSEN alle folgenden Bibliotheken, die native APIs bereitstellen, für Anwendungen mit nativem Code zur Verfügung stellen:
- libaaudio.so (Unterstützung für natives AAudio-Audio)
- libamidi.so (native MIDI-Unterstützung, wenn die Funktion
android.software.midi
wie in Abschnitt 5.9 beschrieben beansprucht wird) - libandroid.so (native Unterstützung für Android-Aktivitäten)
- libc (C-Bibliothek)
- libcamera2ndk.so
- libdl (dynamische Verknüpfung)
- libEGL.so (natives OpenGL-Oberflächenmanagement)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- Liblog (Android-Protokollierung)
- libmediandk.so (Unterstützung für native Media APIs)
- libm (Mathematikbibliothek)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (Unterstützung von OpenMAX AL 1.0.1)
- libOpenSLES.so (Audiounterstützung von OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (Minimale Unterstützung für C++)
- libvulkan.so (Vulkan)
- libz (Zlib-Komprimierung)
- JNI-Schnittstelle
[C-0-8] DÜRFEN die öffentlichen Funktionen für die oben aufgeführten nativen Bibliotheken NICHT hinzufügen oder entfernen.
[C-0-9] MÜSSEN zusätzliche Bibliotheken ohne AOSP auflisten, die direkt in
/vendor/etc/public.libraries.txt
von Drittanbieteranwendungen bereitgestellt werden.[C-0-10] DÜRFEN KEINE anderen nativen Bibliotheken, die in AOSP implementiert und als Systembibliotheken bereitgestellt werden, für Drittanbieter-Apps mit API-Level 24 oder höher verfügbar gemacht werden, da diese reserviert sind.
[C-0-11] MÜSSEN alle Funktionssymbole für OpenGL ES 3.1 und Android Extension Pack, wie im NDK definiert, über die Bibliothek
libGLESv3.so
exportieren. Alle Symbole MÜSSEN zwar vorhanden sein, in Abschnitt 7.1.4.1 wird jedoch genauer beschrieben, wann die vollständige Implementierung der einzelnen Funktionen erwartet wird.[C-0-12] MÜSSEN Funktionssymbole für die Kernfunktionssymbole
Vulkan 1.0des Typs Vulkan 1.1 sowie die ErweiterungenVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
undVK_KHR_get_physical_device_properties2
über die Bibliotheklibvulkan.so
exportieren. Alle Symbole MÜSSEN zwar vorhanden sein, Abschnitt 7.1.4.2 beschreibt jedoch genauer, wann die vollständige Implementierung der einzelnen Funktionen erwartet wird.SOLLTEN mit dem Quellcode und den Header-Dateien erstellt werden, die im vorgelagerten Android Open Source-Projekt verfügbar sind.
In zukünftigen Android-Versionen werden möglicherweise weitere AIs unterstützt.
3.3.2 Kompatibilität mit nativem 32-Bit-ARM-Code
Wenn Geräteimplementierungen die Unterstützung des ABI für armeabi
melden, geschieht Folgendes:
- [C-3-1] MÜSSEN auch
armeabi-v7a
unterstützen und deren Unterstützung melden, daarmeabi
nur der Abwärtskompatibilität mit älteren Apps dient.
Wenn Geräteimplementierungen die Unterstützung des ABI armeabi-v7a
melden, wird für Apps, die dieses ABI verwenden, Folgendes angegeben:
[C-2-1] MÜSSEN die folgenden Zeilen in
/proc/cpuinfo
einfügen und die Werte auf demselben Gerät NICHT ändern, selbst 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] MÜSSEN die folgenden Vorgänge immer verfügbar halten, auch wenn das ABI in einer ARMv8-Architektur implementiert ist, entweder durch native CPU-Unterstützung oder durch Softwareemulation:
- Anweisungen zu SWP und SWPB
- CP15ISB-, CP15DSB- und CP15DMB-Hürdenoperationen
[C-2-3] MÜSSEN Support für die Erweiterung Advanced SIMD (NEON) bereitstellen.
3.4 Webkompatibilität
3.4.1 WebView-Kompatibilität
Wenn Geräteimplementierungen eine vollständige Implementierung der android.webkit.Webview
API ermöglichen, gilt Folgendes:
- [C-1-1] MÜSSEN
android.software.webview
melden. - [C-1-2] MUSS zur Implementierung der
android.webkit.WebView
API den Chromium-Projekt-Build aus dem übergeordneten Open-Source-Projekt von Android im Android 14-Zweig verwenden. [C-1-3] Der von WebView gemeldete User-Agent-String MUSS folgendes Format haben:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Der Wert des Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE übereinstimmen.
- Der String $(MODEL) KANN leer sein, aber wenn er nicht leer ist, MUSS er denselben Wert wie android.os.Build.MODEL haben.
- „Build/$(BUILD)“ KANN weggelassen werden, aber wenn vorhanden, MUSS der String $(BUILD) mit dem Wert für android.os.Build.ID identisch sein.
- Der Wert des Strings $(CHROMIUM_VER) MUSS der Version von Chromium im vorgelagerten Android-Open-Source-Projekt sein.
- Bei Geräteimplementierungen KANN „Mobile“ im User-Agent-String weggelassen werden.
Die WebView-Komponente sollte so viele HTML5-Funktionen wie möglich unterstützen. Sofern sie dies unterstützt, SOLLTE die WebView-Komponente der HTML5-Spezifikation entsprechen.
[C-1-4] MÜSSEN den bereitgestellten Inhalt oder den Remote-URL-Inhalt in einem Prozess rendern, der sich von der Anwendung unterscheidet, die das WebView instanziiert. Insbesondere MUSS der separate Renderer-Prozess weniger Berechtigungen haben, als separate Nutzer-ID ausgeführt werden, keinen Zugriff auf das Datenverzeichnis der Anwendung haben, keinen direkten Netzwerkzugriff haben und nur auf die mindestens erforderlichen Systemdienste über Binder zugreifen können. Die AOSP-Implementierung von WebView erfüllt diese Anforderung.
Wenn Geräteimplementierungen 32-Bit sind oder das Funktions-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] MUSS alle der folgenden mit HTML5 verknüpften APIs unterstützen:
- [C-1-2] MUSS die HTML5/W3C Webstorage API und die HTML5/W3C IndexedDB API unterstützen. Im Zuge der Umstellung der Normen zur Webentwicklung auf IndexedDB gegenüber Webspeichern wird erwartet, dass IndexedDB in einer zukünftigen Android-Version eine erforderliche Komponente sein wird.
- KANN einen benutzerdefinierten User-Agent-String in der eigenständigen Browseranwendung versenden.
- SOLLTE Unterstützung für möglichst viele HTML5-Inhalte in der eigenständigen Browseranwendung implementieren (sei es auf der Grundlage der vorgelagerten WebKit-Browseranwendung oder einer Ersatzanwendung durch einen Drittanbieter).
Wenn Geräteimplementierungen jedoch keine eigenständige Browseranwendung enthalten, gilt Folgendes:
- [C-2-1] MÜSSEN weiterhin die in Abschnitt 3.2.3.1 beschriebenen Muster für die öffentliche Absicht unterstützen.
3.5 API-Verhaltenskompatibilität
Geräteimplementierungen:
- [C-0-9] MÜSSEN sicherstellen, dass die API-Verhaltenskompatibilität auf alle installierten Apps angewendet wird, es sei denn, sie sind wie in Abschnitt 3.5.1 beschrieben eingeschränkt.
- [C-0-10] DARF NICHT den Ansatz auf die Zulassungsliste setzen, der die Verhaltenskompatibilität der API nur für Apps gewährleistet, die von Geräte-Implementierern ausgewählt werden.
Das Verhalten der einzelnen API-Typen (verwaltet, weich, nativ und Web) muss der bevorzugten Implementierung des vorgelagerten Android-Open-Source-Projekts entsprechen. Einige spezifische Kompatibilitätsbereiche sind:
- [C-0-1] Geräte DÜRFEN das Verhalten oder die Semantik eines Standard-Intents NICHT ändern.
- [C-0-2] Geräte DÜRFEN die Lebenszyklus- oder Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, ContentProvider usw.) NICHT ändern.
- [C-0-3] Geräte DÜRFEN die Semantik einer Standardberechtigung NICHT ändern.
- Auf den Geräten DÜRFEN die Beschränkungen für Hintergrund-Apps NICHT geändert werden.
Genauer gesagt für Hintergrund-Apps:
- [C-0-4] Sie MÜSSEN die Ausführung von Callbacks beenden, die von der App registriert sind, um Ausgaben von
GnssMeasurement
undGnssNavigationMessage
zu erhalten. - [C-0-5] MÜSSEN sie die Häufigkeit von Updates begrenzen, die für die App über die API-Klasse
LocationManager
oder die MethodeWifiManager.startScan()
bereitgestellt werden. - [C-0-6] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, DÜRFEN SIE NICHT erlauben, Broadcast-Empfänger für die impliziten Broadcasts von standardmäßigen Android-Intents im Manifest der App zu registrieren, es sei denn, der Broadcast-Intent erfordert eine
"signature"
- oder"signatureOrSystem"
-protectionLevel
-Berechtigung oder ist in der Ausnahmeliste enthalten. - [C-0-7] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN sie die Hintergrunddienste der App beenden, so als ob die App die Methode
stopSelf()
des Dienstes aufgerufen hätte, es sei denn, die App wird auf eine temporäre Zulassungsliste gesetzt, um eine Aufgabe auszuführen, 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 der App freigegeben werden.
- [C-0-4] Sie MÜSSEN die Ausführung von Callbacks beenden, die von der App registriert sind, um Ausgaben von
- [C-0-11] 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 vonProvider.getName()
zurückgegeben) und Klassen zurückgeben, es sei denn, die App hat die Liste überinsertProviderAt()
oderremoveProvider()
geändert. Geräte geben KÖNNEN nach der unten angegebenen Liste von Anbietern weitere Anbieter zurück.- AndroidNSSP –
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL –
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider –
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround –
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC –
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE –
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore –
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP –
Die obige Liste ist nicht vollständig. Die Compatibility Test Suite (CTS) testet große Teile der Plattform auf Verhaltenskompatibilität, aber nicht alle. Der Implementierer ist dafür verantwortlich, die Verhaltenskompatibilität mit dem Android Open Source Project zu gewährleisten. Daher sollten Geräte-Implementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt große Teile des Systems noch einmal zu implementieren.
3.5.1 Anwendungseinschränkung
Wenn Geräteimplementierungen einen proprietären Mechanismus zur Beschränkung von Apps implementieren (z.B. zum Ändern oder Einschränken des API-Verhaltens, das im SDK beschrieben ist) und dieser Mechanismus restriktiver als der eingeschränkte Standby-Bucket für Apps ist, gilt Folgendes:
- [C-1-1] MÜSSEN dem Nutzer erlauben, die Liste der eingeschränkten Apps aufzurufen.
- [C-1-2] MÜSSEN Nutzern die Möglichkeit bieten, diese proprietären Einschränkungen für jede App zu aktivieren / deaktivieren.
[C-1-3] MUSS diese proprietären Einschränkungen nicht automatisch anwenden, wenn der Systemzustand nicht nachgewiesen wird. MÖGLICHERWEISE sollten jedoch die Einschränkungen für Apps angewendet werden, wenn ein schlechtes Systemzustandsverhalten wie hängende Wakelocks, Dienste mit langer Laufzeit und andere Kriterien erkannt werden. Die Kriterien MÖGLICHERWEISE von Geräteimplementierungen festgelegt werden, MÜSSEN jedoch im Zusammenhang mit den Auswirkungen der App auf den Systemzustand stehen. Andere Kriterien, die sich nicht nur auf den Systemzustand beziehen, z. B. die geringe Beliebtheit der App auf dem Markt, DÜRFEN NICHT als Kriterien verwendet werden.
[C-1-4] MUSS diese proprietären Einschränkungen nicht automatisch für Apps anwenden, wenn ein Nutzer App-Einschränkungen manuell deaktiviert hat, und KANN dem Nutzer vorschlagen, diese proprietären Einschränkungen anzuwenden.
[C-1-5] MÜSSEN Nutzer informieren, wenn diese proprietären Einschränkungen automatisch auf eine App angewendet werden. Solche Informationen MÜSSEN innerhalb von 24 Stunden vor der Anwendung dieser proprietären Einschränkungen bereitgestellt werden.
[C-1-6] MUSS für alle API-Aufrufe einer App für die Methode ActivityManager.isBackgroundRestricted() "true" zurückgeben.
[C-1-7] DARF NICHT die App im Vordergrund einschränken, die vom Nutzer explizit verwendet wird.
[C-1-8] MÜSSEN diese proprietären Einschränkungen für eine App aussetzen, wenn ein Nutzer beginnt, die App explizit zu verwenden, sodass sie zur obersten Anwendung im Vordergrund wird.
[C-1-10] MÜSSEN ein öffentlich zugängliches und übersichtliches Dokument oder eine eindeutige Website zur Verfügung gestellt werden, in dem bzw. der beschrieben wird, wie proprietäre Einschränkungen angewendet werden. Dieses Dokument oder diese Website MÜSSEN über die Android SDK-Dokumente verknüpfbar sein und MÜSSEN Folgendes enthalten:
- Bedingungen für proprietäre Einschränkungen auslösen
- Welche Einschränkungen für Apps gelten und wie sie eingeschränkt werden können
- Wie eine App von solchen Einschränkungen ausgenommen werden kann
- Wie eine App eine Ausnahme von proprietären Einschränkungen anfordern kann, wenn sie eine solche Ausnahme für Apps unterstützt, die der Nutzer installieren kann.
Wenn eine App auf dem Gerät vorinstalliert ist und von einem Nutzer länger als 30 Tage nie explizit verwendet wurde, sind [C-1-3] [C-1-5] ausgenommen.
Wenn Geräteimplementierungen die in AOSP implementierten App-Einschränkungen erweitern, geschieht Folgendes:
- [C-2-1]MÜSSEN der in diesem Dokument beschriebenen Implementierung folgen.
3.5.2 Ruhezustand von Anwendungen
Wenn Geräteimplementierungen den in AOSP enthaltenen App-Hibernation beinhalten oder die in AOSP enthaltene Funktion erweitern, dann gilt Folgendes:
- [C-1-1] MUSS alle Anforderungen in Abschnitt 3.5.1 mit Ausnahme von [C-1-6] und [C-1-3] erfüllen.
- [C-1-2] MUSS die Einschränkung für die App nur dann für einen Nutzer anwenden, wenn es nachweislich gibt, dass der Nutzer die App über einen bestimmten Zeitraum nicht verwendet hat. Diese Dauer wird dringend auf einen Monat oder länger empfohlen. Die Nutzung MUSS entweder durch explizite Nutzerinteraktion über die API UsageStats#getLastTimeVisible() oder durch alles definiert werden, was dazu führt, dass eine App den Status mit erzwungener Beendeung verlässt, einschließlich Dienstbindungen, Inhaltsanbieterbindungen, expliziten Broadcasts usw., die von einer neuen API-Nutzungsstatistik#getLastTimeAnyComponentUsed() nachverfolgt werden.
- [C-1-3] MUSS nur Einschränkungen anwenden, die alle Gerätenutzer betreffen, wenn es Anzeichen dafür gibt, dass das Paket über einen bestimmten Zeitraum nicht von keinem Nutzer verwendet wurde. Diese Dauer wird UNBEDINGT zu einem Monat oder länger empfohlen.
- [C-1-4] DARF die App NICHT so einstellen, dass sie nicht auf Aktivitäts-Intents, Dienstbindungen, Anfragen von Contentanbietern oder explizite Broadcasts reagiert.
Der App-Ruhezustand in AOSP erfüllt die oben genannten Anforderungen.
3.6. API-Namespaces
Android folgt den Konventionen für Paket- und Klassen-Namespaces, die von der Programmiersprache Java definiert werden. Um die Kompatibilität mit Anwendungen von Drittanbietern sicherzustellen, dürfen Geräte-Implementierer an diesen Paket-Namespaces KEINE unzulässigen Änderungen (siehe unten) vornehmen:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
Das heißt:
- [C-0-1] DÜRFEN die öffentlich zugänglichen APIs auf der Android-Plattform NICHT ändern, indem Sie Methoden oder Klassensignaturen ändern oder Klassen oder Klassenfelder entfernen.
- [C-0-2] DÜRFEN den APIs in den oben genannten Namespaces keine öffentlich zugänglichen Elemente (wie Klassen oder Schnittstellen bzw. Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) oder Test- oder System-APIs hinzufügen. Ein „öffentlich zugängliches Element“ ist ein Konstrukt, das nicht mit der Markierung „@hide“ dekoriert ist, wie es im vorgelagerten Android-Quellcode verwendet wird.
Geräte-Implementierer KÖNNEN die zugrunde liegende Implementierung der APIs ändern. Durch solche Änderungen gilt jedoch Folgendes:
- [C-0-3] DÜRFEN das angegebene Verhalten und die Java-Sprachsignatur von öffentlich zugänglichen APIs NICHT beeinflussen.
- [C-0-4] DÜRFEN NICHT beworben und nicht auf andere Weise Entwicklern zugänglich gemacht werden.
Geräte-Implementierer KÖNNEN jedoch benutzerdefinierte APIs außerhalb des Android-Standard-Namespace hinzufügen. Die benutzerdefinierten APIs jedoch:
- [C-0-5] DÜRFEN sich NICHT in einem Namespace befinden, der einer anderen Organisation gehört oder auf diese verweist. Beispielsweise dürfen Geräte-Implementierer KEINE APIs dem
com.google.*
oder einem ähnlichen Namespace hinzufügen. Nur Google kann das tun. Ebenso DARF Google KEINE APIs zu Namespaces anderer Unternehmen hinzufügen. - [C-0-6] MÜSSEN in einer gemeinsam genutzten Bibliothek von Android gepackt sein, damit nur Apps, die diese explizit (über den Mechanismus <uses-library>) verwenden, von der erhöhten Arbeitsspeichernutzung solcher APIs betroffen sind.
Geräte-Implementierer KÖNNEN benutzerdefinierte APIs in Muttersprachen außerhalb der NDK APIs hinzufügen. Die benutzerdefinierten APIs können jedoch:
- [C-1-1] DARF NICHT in einer NDK-Bibliothek oder einer Bibliothek einer anderen Organisation enthalten sein, wie hier beschrieben.
Wenn ein Geräte-Implementierer vorschlägt, einen der oben genannten Paket-Namespaces zu verbessern (z. B. durch Hinzufügen nützlicher neuer Funktionen zu einer vorhandenen API oder Hinzufügen einer neuen API), sollte der Implementierer source.android.com aufrufen und mit dem Prozess beginnen, Änderungen und Code gemäß den Informationen auf dieser Website beizusteuern.
Beachten Sie, dass die oben genannten Einschränkungen Standardkonventionen für die Benennung von APIs in der Programmiersprache Java entsprechen. In diesem Abschnitt soll lediglich versucht werden, diese Konventionen zu verstärken und durch Einbeziehung in diese Kompatibilitätsdefinition bindend zu machen.
3.7 Laufzeitkompatibilität
Geräteimplementierungen:
[C-0-1] MUSS das vollständige Dalvik Executable-Format (DEX) und die Dalvik-Bytecode-Spezifikation und -Semantik unterstützen.
[C-0-2] MÜSSEN Dalvik-Laufzeiten so konfigurieren, dass Arbeitsspeicher in Übereinstimmung mit der vorgelagerten Android-Plattform und wie in der folgenden Tabelle angegeben zugeordnet werden. Informationen zu Bildschirmgrößen und Bildschirmdichten findest du in Abschnitt 7.1.1.
SOLLTEN Android RunTime (ART), die Upstream-Referenzimplementierung des Dalvik Executable Format und das Paketverwaltungssystem der Referenzimplementierung verwenden.
SOLLTEN Fuzz-Tests in verschiedenen Ausführungsmodi und Zielarchitekturen ausführen, um die Stabilität der Laufzeit sicherzustellen. Weitere Informationen finden Sie auf der Website des Android Open Source Project unter JFuzz und DexFuzz.
Die unten angegebenen Speicherwerte werden als Mindestwerte betrachtet. Bei Geräteimplementierungen MÖGLICHERWEISE kann mehr Speicher pro Anwendung zugewiesen werden.
Bildschirmlayout | Bildschirmdichte | Mindestanforderungen an den Anwendungsarbeitsspeicher |
---|---|---|
Android-Uhr | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
klein/normal | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
groß | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512MB | |
xlarge | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3.8 Kompatibilität der Benutzeroberfläche
3.8.1 Launcher (Startbildschirm)
Android umfasst eine Launcher-App (Startbildschirm) und Unterstützung für Drittanbieter-Apps als Ersatz für den Geräte-Launcher (Startbildschirm).
Wenn auf Geräten Drittanbieter-Apps den Startbildschirm des Geräts ersetzen können, geschieht Folgendes:
- [C-1-1] MÜSSEN die Plattformfunktion
android.software.home_screen
deklarieren. - [C-1-2] MÜSSEN das
AdaptiveIconDrawable
-Objekt zurückgeben, wenn die Drittanbieter-App das<adaptive-icon>
-Tag zur Bereitstellung ihres Symbols verwendet und diePackageManager
-Methoden zum Abrufen von Symbolen aufgerufen werden.
Wenn Geräteimplementierungen einen Standard-Launcher enthalten, der das Anpinnen von Verknüpfungen in der App unterstützt, gilt Folgendes:
- [C-2-1] MÜSSEN
true
fürShortcutManager.isRequestPinShortcutSupported()
melden. - [C-2-2] MÜSSEN den Nutzer fragen, ob er eine Verknüpfung hinzufügen kann, die von Apps über die API-Methode
ShortcutManager.requestPinShortcut()
angefordert wird. - [C-2-3] MÜSSEN angepinnte Verknüpfungen sowie dynamische und statische Verknüpfungen unterstützen, wie auf der Seite „App-Verknüpfungen“ beschrieben.
Umgekehrt gilt: Wenn Geräteimplementierungen das In-App-Pinning von Verknüpfungen nicht unterstützen, geschieht Folgendes:
- [C-3-1] MÜSSEN
false
fürShortcutManager.isRequestPinShortcutSupported()
melden.
Wenn in Geräteimplementierungen ein Standard-Launcher implementiert wird, der schnellen Zugriff auf zusätzliche Verknüpfungen von Drittanbieter-Apps über die ShortcutManager API bietet, gilt Folgendes:
- [C-4-1] MUSS alle dokumentierten Verknüpfungsfunktionen (z.B. statische und dynamische Verknüpfungen, angepinnte Verknüpfungen) unterstützen und die APIs der API-Klasse
ShortcutManager
vollständig implementieren.
Wenn Geräteimplementierungen eine Standard-Launcher-App enthalten, die Logos für die App-Symbole anzeigt, geschieht Folgendes:
- [C-5-1] MUSS die API-Methode
NotificationChannel.setShowBadge()
berücksichtigen. Mit anderen Worten: Zeigen Sie eine visuelle Darstellung im Zusammenhang mit dem App-Symbol, wenn der Wert auftrue
festgelegt ist, und zeigen Sie kein Kennzeichenschema für das App-Symbol an, wenn alle Benachrichtigungskanäle der App den Wert auffalse
gesetzt haben. - KÖNNEN die App-Symbol-Badges durch ihr proprietäres Badge-Schema überschreiben, wenn Drittanbieter-Apps die Unterstützung des proprietären Kennzeichenschemas durch die Nutzung proprietärer APIs angeben. MÜSSEN jedoch die Ressourcen und Werte verwenden, die über die im SDK beschriebenen APIs für Benachrichtigungen zur Verfügung gestellt werden, z. B.
Notification.Builder.setNumber()
und dieNotification.Builder.setBadgeIconType()
API.
Wenn Geräteimplementierungen monochrome Symbole unterstützen, sind dies folgende:
- [C-6-1] MUSS nur verwendet werden, wenn der Nutzer sie ausdrücklich aktiviert (z.B. über die Einstellungen oder das Auswahlmenü für den Hintergrund).
3.8.2 Widgets
Android unterstützt Widgets von Drittanbieter-Apps, indem ein Komponententyp sowie eine entsprechende API und ein Lebenszyklus definiert werden, sodass Anwendungen ein AppWidget für den Endnutzer verfügbar machen können.
Wenn Geräteimplementierungen App-Widgets von Drittanbietern unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die Unterstützung für die Plattformfunktion
android.software.app_widgets
erklären. [C-1-2] MÜSSEN integrierte Unterstützung für AppWidgets zur Verfügung stehen und Funktionen der Benutzeroberfläche zum Hinzufügen, Konfigurieren, Anzeigen und Entfernen von AppWidgets aufzeigen.
[C-1-3] MUSS Widgets mit einer Größe von 4 x 4 in der Standardrastergröße rendern können. Weitere Informationen findest du in den Designrichtlinien für App Widgets in der Android SDK-Dokumentation.
KANN App-Widgets auf dem Sperrbildschirm unterstützen.
Wenn Geräteimplementierungen App-Widgets von Drittanbietern und das Anpinnen von Verknüpfungen in der App unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN
true
fürAppWidgetManager.html.isRequestPinAppWidgetSupported()
melden. - [C-2-2] MÜSSEN den Nutzer fragen, ob er eine Verknüpfung hinzufügen kann, die von Apps über die API-Methode
AppWidgetManager.requestPinAppWidget()
angefordert wird.
3.8.3 Benachrichtigungen
Android enthält Notification
und NotificationManager
APIs, mit denen Entwickler von Drittanbieter-Apps Nutzer über wichtige Ereignisse informieren und die Aufmerksamkeit der Nutzer mithilfe der Hardwarekomponenten (z.B. Ton, Vibration und Licht) und Softwarefunktionen (z.B. Benachrichtigungsleiste, Systemleiste) des Geräts gewinnen können.
3.8.3.1 Darstellung von Benachrichtigungen
Wenn Drittanbieter-Apps Nutzer über wichtige Ereignisse benachrichtigen dürfen, gilt Folgendes:
- [C-1-1] MÜSSEN Benachrichtigungen unterstützen, die Hardwarefunktionen verwenden, wie in der SDK-Dokumentation beschrieben, und soweit dies mit der Hardware für die Geräteimplementierung möglich ist. Wenn beispielsweise eine Geräteimplementierung einen Vibrationsalarm enthält, MÜSSEN die Vibrations-APIs korrekt implementiert werden. Wenn bei einer Geräteimplementierung keine Hardware vorhanden ist, MÜSSEN die entsprechenden APIs als managementfrei implementiert werden. Dieses Verhalten wird in Abschnitt 7 ausführlicher beschrieben.
- [C-1-2] MÜSSEN alle Ressourcen (Symbole, Animationsdateien usw.), die in den APIs oder im Symbolstil für Status/Systemleiste angegeben sind, korrekt rendern. Sie MÖGLICHERWEISE jedoch eine alternative Nutzererfahrung für Benachrichtigungen bieten als die, die von der Android-Open-Source-Referenzimplementierung bereitgestellt wird.
- [C-1-3] MÜSSEN die für die APIs beschriebenen Verhaltensweisen einhalten und korrekt implementieren, um Benachrichtigungen zu aktualisieren, zu entfernen und zu gruppieren.
- [C-1-4] MUSS das vollständige Verhalten der NotificationChannel API bereitstellen, die im SDK dokumentiert ist.
- [C-1-5] MÜSSEN auf jeder Kanal- und App-Paketebene eine Nutzeroption zum Blockieren und Ändern der Benachrichtigung einer bestimmten Drittanbieter-App bereitstellen.
- [C-1-6] MÜSSEN auch eine Nutzeroption zum Anzeigen gelöschter Benachrichtigungskanäle bereitstellen.
[C-1-7] MÜSSEN alle über Notification.MessagingStyle bereitgestellten Ressourcen (Bilder, Sticker, Symbole usw.) zusammen mit dem Benachrichtigungstext ohne zusätzliche Nutzerinteraktion korrekt rendern. Beispielsweise MÜSSEN alle Ressourcen einschließlich Symbolen von android.app.Person in einer Gruppenunterhaltung angezeigt werden, die über setGroupConversation festgelegt wird.
[C-SR-1] Es wird dringend empfohlen, dem Nutzer die Möglichkeit zu bieten, die Benachrichtigungen von Apps zu steuern, denen die Berechtigung „Benachrichtigungs-Listener“ gewährt wurde. Der Detaillierungsgrad MUSS so sein, dass der Nutzer für jeden solchen Benachrichtigungs-Listener steuern kann, welche Benachrichtigungstypen an diesen Listener überbrückt werden. Die Typen MÜSSEN die Benachrichtigungen „Unterhaltungen“, „Benachrichtigungen“, „Lautlos“ und „Wichtige laufende Benachrichtigungen“ enthalten.
[C-SR-2] EMPFOHLEN, bieten Nutzern die Möglichkeit, Apps festzulegen, die keinen bestimmten Benachrichtigungs-Listener senden dürfen.
[C-SR-3] Es wird dringend empfohlen, automatisch ein Nutzerangebot anzuzeigen, mit dem die Benachrichtigung einer bestimmten Drittanbieter-App für jeden Kanal und jede App-Paketebene blockiert wird, nachdem der Nutzer die Benachrichtigung mehrmals geschlossen hat.
SOLLTEN erweiterte Benachrichtigungen unterstützen.
SOLLTEN Benachrichtigungen mit höherer Priorität als Vorabbenachrichtigungen präsentiert werden.
SOLLTEN die Nutzer die Möglichkeit haben, Benachrichtigungen zurückzustellen.
KANN nur die Sichtbarkeit und das Timing festlegen, wann Drittanbieter-Apps Nutzer über wichtige Ereignisse informieren dürfen, um Sicherheitsprobleme wie die Ablenkung des Fahrers zu verringern.
Mit Android 11 werden Unterhaltungsbenachrichtigungen unterstützt. Dabei handelt es sich um Benachrichtigungen, die MessagingStyle verwenden und eine veröffentlichte Kurzbefehl-ID für Personen bereitstellen.
Geräteimplementierungen:
- [C-SR-4] wird dringend empfohlen,
conversation notifications
vor Benachrichtigungen ohne Unterhaltung zu gruppieren und anzuzeigen, mit Ausnahme laufender Benachrichtigungen zu Diensten im Vordergrund undimportance:high
-Benachrichtigungen.
Wenn Geräteimplementierungen conversation notifications
unterstützen und die App die erforderlichen Daten für bubbles
bereitstellt, geschieht Folgendes:
- [C-SR-5] Wir empfehlen dringend, diese Unterhaltung als Bubble anzuzeigen. Die AOSP-Implementierung erfüllt diese Anforderungen mit der standardmäßigen System-UI, den Einstellungen und dem Launcher.
Wenn Geräteimplementierungen umfassende Benachrichtigungen unterstützen, gilt Folgendes:
- [C-2-1] MUSS exakt die Ressourcen verwenden, die über die API-Klasse
Notification.Style
und deren abgeleitete Klassen für die dargestellten Ressourcenelemente bereitgestellt werden. - SOLLTEN alle Ressourcenelemente (z.B. Symbol, Titel und Zusammenfassungstext) enthalten, die in der API-Klasse
Notification.Style
und ihren Unterklassen definiert sind.
Vorwarnungen sind Benachrichtigungen, die dem Nutzer angezeigt werden, sobald sie eintreffen, unabhängig von der Oberfläche, auf der er sich befindet. Wenn Geräteimplementierungen Vorabbenachrichtigungen unterstützen, gilt Folgendes:
- [C-3-1] MÜSSEN die Ansicht und die Ressourcen für Vorabbenachrichtigungen verwenden, wie in der API-Klasse
Notification.Builder
beschrieben, wenn Vorabbenachrichtigungen angezeigt werden. - [C-3-2] MÜSSEN die über
Notification.Builder.addAction()
bereitgestellten Aktionen zusammen mit dem Benachrichtigungsinhalt ohne zusätzliche Nutzerinteraktion, wie im SDK beschrieben, angezeigt werden.
3.8.3.2 Mitteilungs-Listener-Dienst
Android enthält die NotificationListenerService
APIs, über die Apps (sobald sie explizit vom Nutzer aktiviert wurden) eine Kopie aller Benachrichtigungen erhalten, wenn diese gepostet oder aktualisiert werden.
Geräteimplementierungen:
- [C-0-1] MÜSSEN Benachrichtigungen in ihrer Gesamtheit korrekt und unverzüglich vollständig für alle installierten und nutzeraktivierten Listener-Dienste verwenden, einschließlich aller an das Benachrichtigungsobjekt angehängten Metadaten.
- [C-0-2] MÜSSEN den
snoozeNotification()
-API-Aufruf respektieren, die Benachrichtigung schließen und nach der im API-Aufruf festgelegten Schlummerdauer einen Rückruf starten.
Wenn Geräteimplementierungen Nutzern die Möglichkeit bieten, Benachrichtigungen zurückzustellen, geschieht Folgendes:
- [C-1-1] MÜSSEN den Status der zurückgestellten Benachrichtigungen über die Standard-APIs wie
NotificationListenerService.getSnoozedNotifications()
korrekt wiedergeben. - [C-1-2] MÜSSEN diesem Nutzer die Möglichkeit zum Pausieren von Benachrichtigungen von jeder installierten Drittanbieter-App zur Verfügung stellen, es sei denn, sie stammen aus dauerhaften Diensten im Vordergrund.
3.8.3.3 Nicht stören/Prioritätsmodus
Wenn Geräteimplementierungen die Funktion „Nicht stören“ (auch Prioritätsmodus genannt) unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN, wenn der Nutzer durch die Geräteimplementierung den Zugriff von Drittanbieter-Apps auf die Konfiguration der Richtlinie „Nicht stören“ erlauben oder verweigern kann, die von Anwendungen erstellten automatischen Regeln für die Funktion „Nicht stören“ zusammen mit den vom Nutzer erstellten und vordefinierten Regeln angezeigt werden.
- [C-1-3] MÜSSEN die über
NotificationManager.Policy
übergebenen WertesuppressedVisualEffects
berücksichtigen. Wenn für eine App eines der Flags SUPPRESSED_EFFEKT_SCREEN_OFF oder SUPPRESSED_EFFECT_SCREEN_ON festgelegt ist, SOLLTEN die Nutzer darauf hingewiesen werden, dass die visuellen Effekte im Einstellungsmenü „Nicht stören“ unterdrückt werden.
3.8.4. Assist APIs
Android umfasst die Assist APIs, damit Anwendungen auswählen können, wie viele Informationen des aktuellen Kontextes mit dem Assistenten auf dem Gerät geteilt werden.
Wenn Geräteimplementierungen die Aktion „Assist“ unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN den Endnutzer deutlich darüber informieren, wenn der Kontext freigegeben wird. Dazu haben Sie folgende Möglichkeiten:
- Jedes Mal, wenn die Assistent-App auf den Kontext zugreift, wird ein weißes Licht am Bildschirmrand angezeigt, das die Dauer und Helligkeit der Android Open Source Project-Implementierung erreicht oder überschreitet.
- Die vorinstallierte Assistent-App bietet dem Nutzer weniger als zwei Navigationsoptionen vom Standardmenü für Spracheingabe und Einstellungen der Assistant-App entfernt. Der Kontext wird nur geteilt, wenn der Nutzer die Assistent-App explizit über ein Hotword oder die Eingabe der Navigationstaste für die Unterstützung aufrufen kann.
- [C-2-2] Die vorgesehene Interaktion zum Starten der Assist-App, wie in Abschnitt 7.2.3 beschrieben, MÜSSEN die vom Nutzer ausgewählte Unterstützungs-App starten, also die App, die
VoiceInteractionService
implementiert, oder eine Aktivität, die den IntentACTION_ASSIST
verarbeitet.
3.8.5 Benachrichtigungen und Toasts
Anwendungen können die Toast
API verwenden, um dem Endnutzer kurze nicht modale Strings anzuzeigen, die nach kurzer Zeit verschwinden. Mit der TYPE_APPLICATION_OVERLAY
API für den Fenstertyp können Benachrichtigungsfenster als Overlay über anderen Anwendungen angezeigt werden.
Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:
[C-1-1] MÜSSEN eine App anbieten, mit der verhindert werden kann, dass Benachrichtigungsfenster angezeigt werden, die
TYPE_APPLICATION_OVERLAY
verwenden. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente in der Benachrichtigungsleiste.[C-1-2] MÜSSEN die Toast API berücksichtigen und Endnutzern in gut sichtbarer Weise Toasts von Anwendungen anzeigen.
3.8.6. Designs
In Android können Apps mithilfe von „Designs“ Stile auf eine gesamte Aktivität oder App anwenden.
Android umfasst die Designfamilie „Holo“ und „Material“ als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie dem Holo-Design-Design gemäß der Definition im Android SDK entsprechen möchten.
Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:
- [C-1-1] DÜRFEN KEINE der Holo-Designattribute verändern, die Anwendungen zur Verfügung gestellt werden.
- [C-1-2] MUSS die Designfamilie "Material" unterstützen und DARF KEINE Attribute des Materials oder deren Assets ändern, die in Anwendungen sichtbar sind.
[C-1-3] MÜSSEN entweder die Schriftfamilie „sans-serif“ für die von Roboto unterstützten Sprachen auf Roboto Version 2.x festlegen oder Nutzern die Möglichkeit bieten, die Schriftart für die Schriftfamilie „sans-serif“ in Roboto Version 2.x für die von Roboto unterstützten Sprachen zu ändern.
[C-1-4] MÜSSEN dynamische Farbtonpaletten gemäß der AOSP-Dokumentation von
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
generieren (sieheandroid.theme.customization.system_palette
undandroid.theme.customization.theme_style
).[C-1-5] MÜSSEN dynamische Farbtonpaletten mithilfe von Farbdesignstilen generieren, die in der Dokumentation zu
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(sieheandroid.theme.customization.theme_styles
) aufgeführt sind, nämlichTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
und undMONOCHROMATIC
."Quellfarbe", die zum Generieren dynamischer Farbtonpaletten verwendet wird, wenn sie mit
android.theme.customization.system_palette
gesendet werden (wie inSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
dokumentiert).[C-1-6] MUSS einen
CAM16
-Chromawert von 5 oder höher haben.SOLLTEN aus dem Hintergrund über
com.android.systemui.monet.ColorScheme#getSeedColors
abgeleitet werden, wobei mehrere gültige Quellfarben zur Auswahl stehen.SOLLTEN Sie den Wert
0xFF1B6EF3
verwenden, wenn keine der angegebenen Farben die oben genannten Anforderungen an die Quellfarbe erfüllt.
Android umfasst auch eine „Gerätestandard“-Designfamilie als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Erscheinungsbild des Gerätedesigns anpassen möchten, das vom Geräte-Implementierer definiert wurde.
- Durch Geräteimplementierungen KÖNNEN die Gerätestandard-Designattribute, die Anwendungen zur Verfügung gestellt werden, geändert werden.
Android unterstützt ein Variantendesign mit durchscheinenden Systemleisten, mit denen App-Entwickler den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten ausfüllen können. Damit Entwickler in dieser Konfiguration einheitlich arbeiten können, ist es wichtig, dass der Symbolstil der Statusleiste bei verschiedenen Geräteimplementierungen beibehalten wird.
Wenn Geräteimplementierungen eine Systemstatusleiste enthalten, gilt Folgendes:
- [C-2-1] MUSS Weiß für Systemstatussymbole (z. B. Signalstärke und Akkustand) und vom System ausgegebene Benachrichtigungen verwenden, es sei denn, das Symbol zeigt einen problematischen Status an oder eine App fordert mit dem Flag WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS eine helle Statusleiste an.
- [C-2-2] Bei Implementierungen von Android-Geräten MÜSSEN die Farbe der Systemstatussymbole zu Schwarz ändern (weitere Informationen dazu unter R.style), wenn eine App eine helle Statusleiste anfordert.
3.8.7 Live-Hintergründe
Android definiert einen Komponententyp sowie eine entsprechende API und einen entsprechenden Lebenszyklus, damit Anwendungen ein oder mehrere Live-Hintergründe für den Endnutzer verfügbar machen können. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabemöglichkeiten, die als Hintergrund hinter anderen Anwendungen angezeigt werden.
Hardware gilt als in der Lage, Live-Hintergründe zuverlässig auszuführen, wenn sie alle Live-Hintergründe ohne Einschränkung der Funktionalität mit einer angemessenen Framerate und ohne negative Auswirkungen auf andere Anwendungen ausführen kann. Wenn Einschränkungen in der Hardware dazu führen, dass Hintergründe und/oder Anwendungen abstürzen, nicht richtig funktionieren, übermäßige CPU- oder Akkuleistung verbraucht wird oder mit einer inakzeptablen niedrigen Framerate ausgeführt wird, kann die Hardware keinen Live-Hintergrund ausführen. Beispielsweise können einige Live-Hintergründe zum Rendern ihrer Inhalte einen OpenGL 2.0- oder 3.x-Kontext verwenden. Live-Hintergrund funktioniert nicht zuverlässig auf Hardware, die nicht mehrere OpenGL-Kontexte unterstützt, da die Verwendung eines OpenGL-Kontexts mit anderen Anwendungen in Konflikt stehen kann, die ebenfalls einen OpenGL-Kontext verwenden.
- In Geräteimplementierungen, die Live-Hintergründe wie oben beschrieben zuverlässig ausführen, SOLLTEN Live-Hintergründe implementiert werden.
Wenn Live-Hintergründe auf Geräten implementiert sind, gilt Folgendes:
- [C-1-1] MÜSSEN das Funktions-Flag „android.software.live_wallpaper“ der Plattform melden.
3.8.8. Wechseln zwischen Aktivitäten
Der vorgelagerte Android-Quellcode umfasst den Übersichtsbildschirm, eine Benutzeroberfläche auf Systemebene zum Wechseln zwischen Aufgaben und zur Anzeige kürzlich aufgerufener Aktivitäten und Aufgaben. Dabei wird eine Miniaturansicht des grafischen Zustands zu dem Zeitpunkt angezeigt, an dem der Nutzer die App das letzte Mal verlassen hat.
Bei Geräteimplementierungen, einschließlich der Navigationstaste für die Funktion „Recents“, wie in Abschnitt 7.2.3 beschrieben, KANN die Benutzeroberfläche geändert werden.
Wenn Geräteimplementierungen, die die Navigationstaste der Funktion „Zuletzt verwendet“ wie in Abschnitt 7.2.3 beschrieben, geändert haben, gilt Folgendes:
- [C-1-1] MUSS mindestens bis zu sieben angezeigte Aktivitäten unterstützen.
- SOLLTE mindestens den Titel von vier Aktivitäten gleichzeitig anzeigen.
- [C-1-2] MÜSSEN die Funktionsweise der Bildschirmfixierung implementieren und dem Nutzer ein Einstellungsmenü zur Ein/Aus-Schaltfläche für die Funktion zur Verfügung stellen.
- SOLLTEN unter „Letzte“ die Farbe, das Symbol und den Bildschirmtitel hervorheben.
- SOLLTE ein abschließendes Angebot („x“) angezeigt werden, aber KANN die Anzeige verzögern, bis der Nutzer mit den Bildschirmen interagiert.
- SOLLTEN Sie eine Verknüpfung implementieren, um einfach zur vorherigen Aktivität zu wechseln.
- SOLLTEN Sie den schnellen Wechsel zwischen den beiden zuletzt verwendeten Apps auslösen, wenn zweimal auf die Funktionstaste „Zuletzt verwendet“ getippt wird.
- SOLLTE den Splitscreen-Mehrfenstermodus (falls unterstützt) auslösen, wenn die letzte Funktionstaste lange gedrückt wird.
- KANN verbundene zuletzt verwendete Elemente als Gruppe angezeigt werden, die zusammen verschoben wird.
- [C-SR-1] wird dringend empfohlen, für den Übersichtsbildschirm die vorgelagerte Android-Benutzeroberfläche (oder eine ähnliche, Miniaturbildbasierte Oberfläche) zu verwenden.
3.8.9. Eingabeverwaltung
Android unterstützt Input Management und Eingabemethodeneditoren von Drittanbietern.
Wenn Nutzer bei der Geräteimplementierung Eingabemethoden von Drittanbietern auf dem Gerät verwenden können, gilt Folgendes:
- [C-1-1] MÜSSEN die Plattformfunktion „android.software.input_methods“ deklarieren und IME-APIs unterstützen, wie in der Android SDK-Dokumentation definiert.
3.8.10 Mediensteuerung auf dem Sperrbildschirm
Die Remote Control Client API wird in Android 5.0 durch die Media Notification Template ersetzt, mit der Medienanwendungen in die Wiedergabesteuerung auf dem Sperrbildschirm integriert werden können.
3.8.11 Bildschirmschoner (früher „Dreams“)
Informationen zum Konfigurieren von Bildschirmschonern finden Sie in Abschnitt 3.2.3.5.
3.8.12. Standort
Wenn Geräteimplementierungen einen Hardwaresensor (z.B. GPS) enthalten, der die Standortkoordinaten liefern kann, müssen sie
- [C-1-2] MÜSSEN den aktuellen Status des Standorts im Menü „Standort“ in den Einstellungen anzeigen.
- [C-1-3] DÜRFEN KEINE Standortmodi im Menü „Standort“ in den Einstellungen angezeigt werden.
3.8.13. Unicode und Schriftart
Android unterstützt die in Unicode 10.0 definierten Emoji-Zeichen.
Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:
- [C-1-1] MUSS diese Emoji-Zeichen in Farbglyphen rendern können.
- [C-1-2] MUSS Folgendes unterstützen:
- Roboto 2-Schriftart mit unterschiedlichen Schriftstärken: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed,sans-serif-condensed-light.
- Vollständige Unicode 7.0-Abdeckung für lateinische, griechische und kyrillische Sprachen, einschließlich der erweiterten lateinamerikanischen Bereiche A, B, C und D sowie aller Glyphen im Währungssymbolblock von Unicode 7.0.
- [C-1-3] DARF KEINE NotoColorEmoji.tff aus dem System-Image entfernen oder verändern. (Es ist zulässig, eine neue Emoji-Schriftart hinzuzufügen, um Emojis in NotoColorEmoji.tff zu überschreiben.)
- SOLLTEN den Hautton und verschiedene Familien-Emojis gemäß Unicode Technical Report Nr. 51 unterstützen.
Wenn Geräteimplementierungen einen IME enthalten, gilt Folgendes:
- SOLLTE dem Nutzer eine Eingabemethode für diese Emoji-Zeichen zur Verfügung stellen.
Android unterstützt das Rendern von myanmarischen Schriftarten. In Myanmar gibt es für das Rendern der Sprachen Myanmars mehrere nicht Unicode-konforme Schriftarten, die allgemein als „Zawgyi“ bezeichnet werden.
Wenn Geräteimplementierungen Burmesisch unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN Text in einer Unicode-konformen Schriftart standardmäßig wiedergeben. Eine nicht Unicode-konforme Schriftart DARF NICHT als Standardschriftart festgelegt werden, es sei denn, der Nutzer wählt diese Schriftart in der Sprachauswahl aus.
- [C-2-2] MÜSSEN eine Unicode- und eine nicht-Unicode-konforme Schriftart unterstützen, wenn auf dem Gerät eine nicht Unicode-konforme Schriftart unterstützt wird. Nicht Unicode-konforme Schriftart DARF die Unicode-Schriftart NICHT entfernen oder überschreiben.
- [C-2-3] MÜSSEN Text nur dann in nicht Unicode-konformer Schriftart rendern, wenn ein Sprachcode mit dem Skriptcode Qaag angegeben ist (z.B. my-Qaag). Es dürfen keine anderen ISO-Sprach- oder Regionscodes (zugewiesen, nicht zugewiesen oder reserviert) verwendet werden, um auf eine nicht Unicode-konforme Schriftart für Myanmar zu verweisen. App-Entwickler und Webseitenautoren können my-Qaag wie für jede andere Sprache als ausgewiesenen Sprachcode angeben.
3.8.14. Mehrere Fenster
Wenn Geräteimplementierungen die Möglichkeit haben, mehrere Aktivitäten gleichzeitig anzuzeigen, geschieht Folgendes:
- [C-1-1] MÜSSEN diese Mehrfenstermodi gemäß dem Anwendungsverhalten und den APIs implementieren, die in der Dokumentation zur Unterstützung des Mehrfenstermodus des Android SDK beschrieben sind. Außerdem müssen die folgenden Anforderungen erfüllt werden:
- [C-1-2] MÜSSEN
android:resizeableActivity
berücksichtigen, das von einer App in der DateiAndroidManifest.xml
festgelegt wird, wie in diesem SDK beschrieben. - [C-1-3] DÜRFEN KEINEN Splitscreen- oder Freeform-Modus anbieten, 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 NICHT auf eine Größe unter 220 dp im Mehrfenstermodus (außer „Bild im Bild“) geändert werden.
- Geräteimplementierungen mit einer Bildschirmgröße von
xlarge
SOLLTEN den Freiformmodus unterstützen.
Wenn Geräteimplementierungen den Mehrfenstermodus und den Splitscreen-Modus unterstützen, geschieht Folgendes:
- [C-2-2] MÜSSEN die angedockte Aktivität eines Mehrfenstermodus mit geteiltem Bildschirm zuschneiden, SOLLTE aber einige Inhalte des Bildschirms anzeigen, wenn die Launcher-App das fokussierte Fenster ist.
- [C-2-3] MÜSSEN die deklarierten Werte
AndroidManifestLayout_minWidth
undAndroidManifestLayout_minHeight
der Drittanbieter-Launcher-App berücksichtigen und dürfen 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] MÜSSEN Aktivitäten im Mehrfenstermodus „Bild im Bild“ starten,
wenn die App
* auf API-Level 26 oder höher ausgerichtet ist und
android:supportsPictureInPicture
* auf API-Level 25 oder niedriger ausgerichtet ist und sowohlandroid:resizeableActivity
als auchandroid:supportsPictureInPicture
angibt. - [C-3-2] MÜSSEN die Aktionen in der System-UI gemäß der aktuellen PIP-Aktivität über die
setActions()
API anzeigen. - [C-3-3] MUSS Seitenverhältnisse größer oder gleich 1:2,39 und kleiner oder gleich 2,39:1 unterstützen, wie in der PIP-Aktivität über die
setAspectRatio()
API angegeben. - [C-3-4] MUSS
KeyEvent.KEYCODE_WINDOW
zur Steuerung des PIP-Fensters verwenden. Wenn der PIP-Modus nicht implementiert ist, MUSS der Schlüssel für die Vordergrundaktivität verfügbar sein. - [C-3-5] MÜSSEN eine App anbieten, die verhindert, dass eine App im BiB-Modus angezeigt wird. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente in der Benachrichtigungsleiste.
[C-3-6] MUSS dem BiB-Fenster die folgende Mindestbreite und -höhe zuweisen, wenn in einer App für
AndroidManifestLayout_minWidth
undAndroidManifestLayout_minHeight
kein Wert deklariert wird:- Geräten, deren Configuration.uiMode einen anderen Wert als
UI_MODE_TYPE_TELEVISION
hat, MÜSSEN eine Mindestbreite und -höhe von 108 dp zuweisen. - Geräte, deren Configuration.uiMode auf
UI_MODE_TYPE_TELEVISION
gesetzt ist, MÜSSEN eine Mindestbreite von 240 dp und eine Mindesthöhe von 135 dp zuweisen.
- Geräten, deren Configuration.uiMode einen anderen Wert als
3.8.15. Display-Aussparung
Android unterstützt einen Display Cutout, wie im SDK-Dokument beschrieben. Die DisplayCutout
API definiert einen Bereich am Rand des Displays, der aufgrund einer Display-Aussparung oder eines gebogenen Displays an den Rändern möglicherweise nicht für Apps geeignet ist.
Wenn Geräteimplementierungen Display-Aussparungen enthalten, gilt Folgendes:
- [C-1-5] DÜRFEN KEINE Aussparungen haben, wenn das Seitenverhältnis des Geräts 1,0 (1:1) beträgt.
- [C-1-2] DÜRFEN NICHT mehr als eine Aussparung pro Rand haben.
- [C-1-3] MÜSSEN die Flags für die Display-Aussparung berücksichtigen, die von der App über die
WindowManager.LayoutParams
API festgelegt wurden, wie im SDK beschrieben. - [C-1-4] MÜSSEN korrekte Werte für alle Messwerte für Aussparungen melden, die in der
DisplayCutout
API definiert sind.
3.8.16. Gerätesteuerung
Android enthält die ControlsProviderService
und Control
APIs, damit Drittanbieter-Apps Gerätesteuerungen veröffentlichen können, mit denen Nutzer schnell Statusinformationen abrufen und Aktionen ausführen können.
Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2_2_3.
3.8.17. Zwischenablage
Geräteimplementierungen:
- [C-0-1] DÜRFEN KEINE Daten aus der Zwischenablage ohne ausdrückliche Nutzeraktion (z. B. Drücken einer Schaltfläche auf dem Overlay) an Komponenten, Aktivitäten, Dienste oder über Netzwerkverbindungen hinweg senden. Ausgenommen hiervon sind Dienste, die unter 9.8.6 Inhaltserfassung und App-Suche erwähnt werden.
Wenn Geräteimplementierungen eine für Nutzer sichtbare Vorschau generieren, wenn Inhalte für ein ClipData
-Element, bei dem ClipData.getDescription().getExtras()
android.content.extra.IS_SENSITIVE
enthält, in die Zwischenablage kopiert werden, geschieht Folgendes:
- [C-1-1] MUSS die sichtbare Vorschau des Nutzers entfernen.
Die AOSP-Referenzimplementierung erfüllt diese Anforderungen für die Zwischenablage.
3.9. Geräteverwaltung
Android umfasst Funktionen, mit denen sicherheitsbewusste Anwendungen Geräteverwaltungsfunktionen auf Systemebene über die Android Device Administration API ausführen können, z. B. Passwortrichtlinien erzwingen oder Daten aus der Ferne löschen.
Wenn Geräteimplementierungen alle in der Android SDK-Dokumentation definierten Richtlinien zur Geräteverwaltung implementieren, gilt Folgendes:
- [C-1-1] MUSS
android.software.device_admin
deklarieren. - [C-1-2] MUSS die Nutzerverwaltung für Geräte unterstützen, wie in Abschnitt 3.9.1 und Abschnitt 3.9.1.1 beschrieben.
3.9.1 Gerätebereitstellung
3.9.1.1 Nutzerverwaltung für Geräteinhaber
Wenn in Geräteimplementierungen android.software.device_admin
deklariert wird, gilt Folgendes:
- [C-1-1] MUSS die Registrierung eines Device Policy-Clients (DPC) als Device Owner-App unterstützen, wie unten beschrieben:
- Wenn in der Geräteimplementierung weder Nutzerdaten noch Nutzerdaten konfiguriert sind, geschieht Folgendes:
- [C-1-5] MÜSSEN die DPC-Anwendung als Geräteinhaber-App registrieren oder die DPC-App aktivieren, um auszuwählen, ob sie ein Geräteinhaber oder ein Profilinhaber werden soll, wenn das Gerät NFC-Unterstützung (Near Field Communications) über das Funktions-Flag
android.hardware.nfc
deklariert und eine NFC-Nachricht mit einem Eintrag vom MIME-TypMIME_TYPE_PROVISIONING_NFC
empfängt. - [C-1-8] MÜSSEN den Intent ACTION_GET_PROVISIONING_MODE senden, nachdem die Bereitstellung des Geräteinhabers ausgelöst wurde, damit die DPC-App abhängig von den Werten von
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
auswählen kann, ob sie Geräteinhaber oder Profilinhaber werden soll, es sei denn, aus dem Kontext lässt sich erkennen, dass es nur eine gültige Option gibt. - [C-1-9] MÜSSEN den Intent ACTION_ADMIN_POLICY_COMPLIANCE an die Geräteinhaber-App senden, wenn während der Bereitstellung ein Geräteinhaber festgelegt wird, unabhängig von der verwendeten Bereitstellungsmethode. Der Nutzer darf den Einrichtungsassistenten erst fortsetzen, wenn die App „Geräteinhaber“ abgeschlossen ist.
- [C-1-5] MÜSSEN die DPC-Anwendung als Geräteinhaber-App registrieren oder die DPC-App aktivieren, um auszuwählen, ob sie ein Geräteinhaber oder ein Profilinhaber werden soll, wenn das Gerät NFC-Unterstützung (Near Field Communications) über das Funktions-Flag
- Wenn die Geräteimplementierung Nutzer- oder Nutzerdaten enthält, geschieht Folgendes:
- [C-1-7] DARF keine DPC-Anwendung mehr als Geräteinhaber-App registrieren.
- Wenn in der Geräteimplementierung weder Nutzerdaten noch Nutzerdaten konfiguriert sind, geschieht Folgendes:
[C-1-2] MÜSSEN einen entsprechenden Offenlegungshinweis wie in AOSP angegeben einblenden und die Einwilligung des Endnutzers einholen, bevor eine App als Geräteinhaber festgelegt wird, es sei denn, das Gerät wurde vor der Endnutzerinteraktion auf dem Bildschirm programmatisch für den Demomodus für den Einzelhandel konfiguriert. Wenn in Geräteimplementierungen
android.software.device_admin
deklariert wird, aber auch eine proprietäre Geräteverwaltungslösung eingebunden und ein Mechanismus bereitgestellt wird, um eine in der Lösung konfigurierte App als Geräteinhaber entsprechend dem standardmäßigen Geräteinhaber hochzustufen, der von den standardmäßigen Android DevicePolicyManager APIs erkannt wird, geschieht Folgendes:[C-2-1] MÜSSEN über ein Verfahren verfügen, mit dem geprüft wird, ob die beworbene App zu einer legitimen Lösung für die Geräteverwaltung eines Unternehmens gehört und in der proprietären Lösung so konfiguriert wurde, dass die entsprechenden Rechte als „Geräteinhaber“ gelten.
[C-2-2] MÜSSEN dieselbe Offenlegung zur Einwilligung des AOSP-Geräteinhabers anzeigen wie in dem von
android.app.action.PROVISION_MANAGED_DEVICE
initiierten Ablauf, bevor die DPC-Anwendung als „Geräteinhaber“ registriert wird.[C-2-3] DÜRFEN die Einwilligung nicht hartcodieren oder die Verwendung anderer Apps von Geräteeigentümern verhindern.
3.9.1.2 Verwaltete Bereitstellung von Profilen
Wenn in Geräteimplementierungen android.software.managed_users
deklariert wird, gilt Folgendes:
[C-1-1] MÜSSEN die APIs implementieren, die es einer DPC-Anwendung (Device Policy Controller) ermöglichen, Inhaber eines neuen verwalteten Profils zu werden.
[C-1-2] Der Bereitstellungsprozess für verwaltete Profile (der vom DPC mit android.app.action.PROVISION_MANAGED_PROFILE initiierte Ablauf), der Zustimmungsbildschirm und die Nutzererfahrung MÜSSEN mit der AOSP-Implementierung übereinstimmen.
[C-1-3] MÜSSEN in den Einstellungen die folgenden Nutzerangebote zur Verfügung stellen, um dem Nutzer anzuzeigen, wenn eine bestimmte Systemfunktion vom Device Policy Controller (DPC) deaktiviert wurde:
- Ein konsistentes Symbol oder ein anderes Nutzerangebot (z. B. das vorgelagerte AOSP-Infosymbol), das angibt, wenn eine bestimmte Einstellung von einem Device Admin eingeschränkt wird.
- Eine kurze Erklärung, die der Device Admin über die
setShortSupportMessage
bereitstellt. - Das Symbol der DPC-Anwendung.
[C-1-4] MÜSSEN den Handler für den Intent ACTION_PROVISIONING_SUCCESSFUL im Arbeitsprofil starten, wenn ein Profilinhaber eingerichtet wird, während die Bereitstellung vom Intent android.app.action.PROVISION_MANAGED_PROFILE initiiert wird und der DPC den Handler implementiert hat.
[C-1-5] MÜSSEN die Übertragung ACTION_PROFILE_PROVISIONING_COMPLETE an den DPC des Arbeitsprofils senden, wenn die Bereitstellung über den Intent android.app.action.PROVISION_MANAGED_PROFILE initiiert wird.
[C-1-6] MÜSSEN den Intent ACTION_GET_PROVISIONING_MODE senden, nachdem die Nutzerverwaltung des Profilinhabers ausgelöst wurde, damit die DPC-App auswählen kann, ob sie Geräteinhaber oder Profilinhaber werden soll, es sei denn, die Bereitstellung wird durch den Intent android.app.action.PROVISION_MANAGED_PROFILE ausgelöst.
[C-1-7] MÜSSEN den Intent ACTION_ADMIN_POLICY_COMPLIANCE an das Arbeitsprofil senden, wenn während der Bereitstellung ein Profilinhaber festgelegt wird, unabhängig davon, welche Bereitstellungsmethode verwendet wird. Ausgenommen hiervon ist der Intent android.app.action.PROVISION_MANAGED_PROFILE. Der Nutzer darf den Einrichtungsassistenten erst fortsetzen, wenn die Anwendung des Profilinhabers abgeschlossen ist.
[C-1-8] MÜSSEN unabhängig von der verwendeten Bereitstellungsmethode die Broadcast ACTION_MANAGED_PROFILE_PROVISIONED an den DPC für das persönliche Profil senden, wenn ein Profilinhaber eingerichtet wird.
3.9.2 Unterstützung für verwaltete Profile
Wenn in Geräteimplementierungen android.software.managed_users
deklariert wird, gilt Folgendes:
- [C-1-1] MUSS verwaltete Profile über die
android.app.admin.DevicePolicyManager
APIs unterstützen. - [C-1-2] MUSS die Erstellung nur eines einzigen verwalteten Profils zulassen.
- [C-1-3] MÜSSEN ein Symbol verwenden (ähnlich dem AOSP-Upstream-Logo), das verwaltete Anwendungen und Widgets sowie andere Badge-UI-Elemente wie „Letzte und Benachrichtigungen“ repräsentiert.
- [C-1-4] MÜSSEN ein Benachrichtigungssymbol (ähnlich dem AOSP-Upstream-Arbeitsbadge) anzeigen, das anzeigt, wenn sich der Nutzer in einer Anwendung mit einem verwalteten Profil befindet.
- [C-1-5] MÜSSEN Sie darauf hinweisen, dass sich der Nutzer im verwalteten Profil befindet, wenn das Gerät aktiviert wird (ACTION_USER_PRESENT) und sich die Anwendung im Vordergrund innerhalb des verwalteten Profils befindet.
- [C-1-6] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN Sie im Intent „Auswahl“ eine visuelle Darstellung anzeigen, damit der Nutzer den Intent vom verwalteten Profil an den primären Nutzer weiterleiten kann oder umgekehrt, sofern der Device Policy Controller dies aktiviert hat.
- [C-1-7] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN die folgenden Nutzerangebote sowohl für den primären Nutzer als auch für das verwaltete Profil angezeigt werden:
- Separate Abrechnung von Akku, Standort, mobiler 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 verwalteten Profil installiert sind
- Unabhängige Verwaltung von Konten innerhalb des Hauptnutzers oder des verwalteten Profils.
- [C-1-8] MÜSSEN darauf achten, dass die vorinstallierten Dialer-, Kontakt- und Messaging-Anwendungen Anruferinformationen im verwalteten Profil (falls vorhanden) neben denen aus dem primären Profil suchen und nachschlagen können, wenn der Device Policy Controller dies zulässt.
- [C-1-9] MUSS alle Sicherheitsanforderungen erfüllen, die für ein Gerät mit mehreren aktivierten Nutzern gelten (siehe Abschnitt 9.5), auch wenn das verwaltete Profil nicht zusätzlich zum primären Nutzer als weiterer Nutzer gezählt wird.
Neue Anforderungen erstellen
- [C-1-10] MÜSSEN darauf achten, dass die Screenshotdaten im Arbeitsprofilspeicher gespeichert werden, wenn ein Screenshot mit einem
topActivity
-Fenster mit Fokus erstellt wird (das, mit dem der Nutzer zuletzt unter allen Aktivitäten interagiert hat) und zu einer Arbeitsprofil-App gehört. - [C-1-11] DÜRFEN KEINE anderen Bildschirminhalte (Systemleiste, Benachrichtigungen oder Inhalte aus privaten Profilen) mit Ausnahme der Fenster/Fenster des Arbeitsprofils erfassen, wenn ein Screenshot im Arbeitsprofil gespeichert wird. So wird sichergestellt, dass keine persönlichen Profildaten im Arbeitsprofil gespeichert werden.
Neue Anforderungen beenden
Wenn in Geräteimplementierungen android.software.managed_users
und android.software.secure_lock_screen
deklariert sind, gilt Folgendes:
- [C-2-1] MUSS die Möglichkeit unterstützen, einen separaten Sperrbildschirm anzugeben, der die folgenden Anforderungen erfüllt, um nur Apps, die in einem verwalteten Profil ausgeführt werden, Zugriff zu gewähren.
- Geräteimplementierungen MÜSSEN den Intent
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
berücksichtigen und eine Schnittstelle zum Konfigurieren separater Anmeldedaten für den Sperrbildschirm für das verwaltete Profil anzeigen. - Die Anmeldedaten für den Sperrbildschirm des verwalteten Profils MÜSSEN die gleichen Mechanismen zum Speichern und Verwalten von Anmeldedaten wie das übergeordnete Profil verwenden. Eine Dokumentation hierzu finden Sie auf der Website des Android-Open-Source-Projekts.
- Die DPC-Passwortrichtlinien MÜSSEN nur für die Sperrbildschirm-Anmeldedaten des verwalteten Profils gelten, sofern sie nicht über die
DevicePolicyManager
-Instanz aufgerufen werden, die von getParentProfileInstance zurückgegeben wird.
- Geräteimplementierungen MÜSSEN den Intent
- Wenn Kontakte aus dem verwalteten Profil in der vorinstallierten Anrufliste, auf der Benutzeroberfläche für laufende Anrufe, in Benachrichtigungen über laufende und verpasste Anrufe, Kontakte und Messaging-Apps angezeigt werden, SOLLTEN sie mit demselben Kennzeichen versehen sein, das für die Anwendungen des verwalteten Profils verwendet wird.
3.9.3 Support für verwaltete Nutzer
Wenn in Geräteimplementierungen android.software.managed_users
deklariert wird, gilt Folgendes:
- [C-1-1] MÜSSEN Nutzern die Möglichkeit bieten, sich vom aktuellen Nutzer abzumelden und in einer Sitzung mit mehreren Nutzern zum primären Nutzer zurückzuwechseln, wenn
isLogoutEnabled
true
zurückgibt. Auf die Nutzerangebote MUSS über den Sperrbildschirm zugegriffen werden können, ohne das Gerät zu entsperren.
Wenn in Geräteimplementierungen android.software.device_admin
deklariert und die Möglichkeit für Nutzer auf dem Gerät angeboten wird, zusätzliche sekundäre Nutzer hinzuzufügen, geschieht Folgendes:
- [C-SR-1] werden DRINGEND empfohlen, dieselben Offenlegungen der AOSP-Geräteinhaber-Einwilligung zu zeigen, die im von android.app.action.PROVISION_MANAGED_DEVICE initiierten Ablauf angezeigt wurden, bevor Konten im neuen sekundären Nutzer hinzugefügt werden können, damit Nutzer erkennen, dass das Gerät verwaltet wird.
3.9.4 Anforderungen an Rollen zur Verwaltung von Geräterichtlinien
Wenn Geräteimplementierungen android.software.device_admin
oder android.software.managed_users
melden, gilt Folgendes:
- [C-1-1] MUSS die in Abschnitt 9.1 definierte Rolle zur Verwaltung von Geräterichtlinien unterstützen. Sie können die Anwendung mit der Rolle zur Verwaltung von Geräterichtlinien definieren, indem Sie
config_devicePolicyManagement
auf den Paketnamen setzen. Auf den Paketnamen MÜSSEN:
und das Signaturzertifikat folgen, es sei denn, die Anwendung ist vorab geladen.
Wenn ein Paketname für config_devicePolicyManagement
nicht wie oben beschrieben definiert ist:
- [C-2-1] Geräteimplementierungen MÜSSEN die Bereitstellung ohne eine Rolleninhaberanwendung für die Geräterichtlinienverwaltung unterstützen (AOSP bietet eine Referenzimplementierung).
Wenn ein Paketname für config_devicePolicyManagement
wie oben beschrieben definiert ist:
- [C-3-1] Die Anwendung MUSS in allen Profilen eines Nutzers installiert werden.
- [C-3-2] Bei Geräteimplementierungen KANN eine Anwendung definiert werden, die den Rolleninhaber für die Geräterichtlinienverwaltung vor der Bereitstellung durch Festlegen von
config_devicePolicyManagementUpdater
aktualisiert.
Wenn ein Paketname für config_devicePolicyManagementUpdater
wie oben beschrieben definiert ist:
- [C-4-1] Die App MUSS auf dem Gerät vorinstalliert sein.
- [C-4-2] Die Anwendung MÜSSEN einen Intent-Filter implementieren, der
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
auflöst.
Neue Anforderungen erstellen
3.9.5 Framework zur Klärung von Geräterichtlinien
Wenn Geräteimplementierungen android.software.device_admin
oder android.software.managed_users
melden, gilt Folgendes:
- [C-1-1] MÜSSEN Konflikte mit Geräterichtlinien wie im Device Policy Resolution Framework beschrieben lösen.
Neue Anforderungen beenden
3:10. Bedienungshilfen
Android bietet eine Ebene der Bedienungshilfen, über die Nutzer mit Behinderungen ihre Geräte einfacher bedienen können. Darüber hinaus bietet Android Plattform-APIs, die Implementierungen von Bedienungshilfen ermöglichen, Callbacks für Nutzer- und Systemereignisse zu empfangen und alternative Feedbackmechanismen wie Sprachausgabe, haptisches Feedback und Trackball-/Steuerkreuz-Navigation zu generieren.
Wenn Geräteimplementierungen Bedienungshilfen von Drittanbietern unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN eine Implementierung des Android-Frameworks für Barrierefreiheit bereitstellen, wie in der SDK-Dokumentation zu Accessibility APIs beschrieben.
- [C-1-2] MÜSSEN Ereignisse für Bedienungshilfen generieren und die entsprechende
AccessibilityEvent
für alle registriertenAccessibilityService
-Implementierungen wie im SDK dokumentiert bereitstellen. - [C-1-4] MÜSSEN die Bedienungshilfen steuern, die AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_button deklarieren. Bei Geräteimplementierungen mit einer Systemnavigationsleiste sollten Nutzer die Option für eine Schaltfläche in der Navigationsleiste des Systems zur Steuerung dieser Dienste haben.
Wenn Geräteimplementierungen vorinstallierte Bedienungshilfen enthalten, gilt Folgendes:
- [C-2-1] MÜSSEN diese vorinstallierten Bedienungshilfen als Direct Boot Aware-Apps implementieren, wenn der Datenspeicher mit File-Based Encryption (FBE) verschlüsselt ist.
- SOLLTEN in der vorkonfigurierten Einrichtung einen Mechanismus enthalten, mit dem Nutzer relevante Bedienungshilfen aktivieren können, sowie Optionen zum Anpassen der Schriftgröße, der Anzeigegröße und der Vergrößerungsbewegungen.
3:11. Sprachausgabe
Android umfasst APIs, mit denen Anwendungen die Sprachausgabedienste nutzen können. Außerdem können Dienstanbieter Implementierungen von Text-in-Sprache-Diensten anbieten.
Wenn Geräteimplementierungen die Funktion „android.hardware.audio.output“ melden, geschieht Folgendes:
- [C-1-1] MUSS die APIs für das Android TTS Framework unterstützen.
Wenn Geräteimplementierungen die Installation von Sprachausgabe-Engines von Drittanbietern unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN Nutzern die Möglichkeit bieten, eine Sprachausgabe-Engine für die Verwendung auf Systemebene auszuwählen.
3:12. TV-Eingabe-Framework
Das Android Television Input Framework (TIF) vereinfacht die Bereitstellung von Live-Inhalten auf Android Television-Geräten. TIF bietet eine Standard-API zum Erstellen von Eingabemodulen, die Android TV-Geräte steuern.
Wenn Geräteimplementierungen TIF unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die Plattformfunktion
android.software.live_tv
deklarieren. - [C-1-2] MÜSSEN alle TIF APIs unterstützen, damit eine Anwendung, die diese APIs und den TIF-basierten Eingabedienst eines Drittanbieters verwendet, auf dem Gerät installiert und verwendet werden kann.
3:13. Schnelleinstellungen
Android bietet eine UI-Komponente für die Schnelleinstellungen, die einen schnellen Zugriff auf häufig verwendete oder dringend benötigte Aktionen ermöglicht.
Wenn Geräteimplementierungen eine UI-Komponente für Schnelleinstellungen enthalten und die Schnelleinstellungen von Drittanbietern unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN dem Nutzer die Möglichkeit geben, die über die
quicksettings
APIs bereitgestellten Kacheln zu einer Drittanbieter-App hinzuzufügen oder zu entfernen. - [C-1-2] DARF NICHT automatisch eine Kachel aus einer Drittanbieter-App direkt zu den Schnelleinstellungen hinzufügen.
- [C-1-3] MÜSSEN alle vom Nutzer hinzugefügten Kacheln aus Drittanbieter-Apps zusammen mit den vom System bereitgestellten Kacheln für die Schnelleinstellungen angezeigt werden.
3:14. Medien-UI
Wenn Geräteimplementierungen Apps ohne Sprachsteuerung umfassen (die Apps), die über MediaBrowser
oder MediaSession
mit Drittanbieteranwendungen interagieren, gilt für die Apps Folgendes:
[C-1-2] MÜSSEN Symbole, die über getIconBitmap() oder getIconUri() abgerufen wurden, und Titel, die über getTitle() abgerufen wurden, klar und deutlich anzeigen, wie unter
MediaDescription
beschrieben. Titel können zur Einhaltung von Sicherheitsvorschriften gekürzt werden (z.B. Ablenkung des Autofahrers).[C-1-3] MÜSSEN das Symbol der Drittanbieter-App angezeigt werden, wenn von dieser Drittanbieter-App bereitgestellte Inhalte angezeigt werden.
[C-1-4] MÜSSEN dem Nutzer die Interaktion mit der gesamten
MediaBrowser
-Hierarchie ermöglichen. KÖNNEN den Zugriff auf einen Teil der Hierarchie einschränken, um Sicherheitsvorschriften einzuhalten (z. B. Ablenkung der Autofahrer). Sie DARF aber NICHT basierend auf Inhalten oder Contentanbietern bevorzugt behandelt werden.[C-1-5] MUSS doppelt auf
KEYCODE_HEADSETHOOK
oderKEYCODE_MEDIA_PLAY_PAUSE
alsKEYCODE_MEDIA_NEXT
fürMediaSession.Callback#onMediaButtonEvent
doppeltippen.
3:15. Android Instant Apps
Wenn Geräteimplementierungen Instant Apps unterstützen, MÜSSEN sie die folgenden Anforderungen erfüllen:
- [C-1-1] Instant Apps MÜSSEN nur Berechtigungen gewährt werden, bei denen
android:protectionLevel
auf"instant"
festgelegt ist. - [C-1-2] Instant-Apps DÜRFEN NICHT über implizite Intents mit installierten Apps interagieren, es sei denn, eine der folgenden Bedingungen ist erfüllt:
- Der Intent-Musterfilter der Komponente ist verfügbar und enthält CATEGORY_BROWSABLE
- Es handelt sich um eine der folgenden Aktionen: ACTION_SEND, ACTION_SENDTO oder ACTION_SEND_MULTIPLE
- Das Ziel wird explizit mit android:visibleToInstantApps bereitgestellt.
- [C-1-3] Instant Apps DÜRFEN NICHT explizit mit installierten Apps interagieren, es sei denn, die Komponente wird über android:visibleToInstantApps bereitgestellt.
- [C-1-4] Installierte Apps DÜRFEN KEINE Details zu Instant Apps auf dem Gerät sehen, es sei denn, die Instant App stellt explizit eine Verbindung zur installierten App her.
Geräteimplementierungen MÜSSEN die folgenden Nutzerangebote für die Interaktion mit Instant Apps bieten. Der AOSP erfüllt die Anforderungen mit der standardmäßigen System-UI, den Einstellungen und dem Launcher. Geräteimplementierungen:
- [C-1-5] MÜSSEN Nutzern die Möglichkeit bieten, Instant-Apps im lokalen Cache für jedes einzelne Anwendungspaket anzusehen und zu löschen.
- [C-1-6] MÜSSEN eine dauerhafte Nutzerbenachrichtigung bereitstellen, die minimiert werden kann, während eine Instant App im Vordergrund ausgeführt wird. Diese Nutzerbenachrichtigung MÜSSEN angeben, dass Instant Apps keine Installation erfordern, und ein Nutzerangebot bieten, das den Nutzer zum Informationsbildschirm für die Anwendung in den Einstellungen weiterleitet. Bei Instant Apps, die über Web Intents gestartet werden, definiert durch die Verwendung eines Intents mit einer Aktion, die auf
Intent.ACTION_VIEW
und dem Schema „http“ oder „https“ festgelegt ist, sollte ein zusätzliches Nutzerangebot es dem Nutzer ermöglichen, die Instant App nicht zu starten, sondern den zugehörigen Link mit dem konfigurierten Webbrowser zu starten, sofern auf dem Gerät ein Browser verfügbar ist. - [C-1-7] MÜSSEN den Zugriff auf ausgeführte Instant Apps über die Funktion „Letzte Apps“ erlauben, wenn die Funktion „Zuletzt verwendet“ auf dem Gerät verfügbar ist.
[C-1-8] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten vorab mit einem Intent-Handler für die im SDK hier aufgeführten Intents laden und die Intents für Instant Apps sichtbar machen.
3:16. Begleitgerät koppeln
Android unterstützt die Kopplung von Begleitgeräten, um die Verknüpfung mit Begleitgeräten effektiver zu verwalten, und bietet die CompanionDeviceManager
API für Apps, die auf diese Funktion zugreifen können.
Wenn Geräteimplementierungen die Kopplungsfunktion von Begleitgeräten unterstützen, gilt Folgendes:
- [C-1-1] MUSS das Funktions-Flag
FEATURE_COMPANION_DEVICE_SETUP
deklarieren. - [C-1-2] MÜSSEN darauf achten, dass die APIs im Paket
android.companion
vollständig implementiert sind. - [C-1-3] MÜSSEN Nutzern Angebote zur Verfügung stellen, damit sie auswählen/bestätigen können, dass ein Companion-Gerät vorhanden und betriebsbereit ist.
3:17. Komplexe Apps
Wenn in Geräteimplementierungen die Funktion FEATURE_CANT_SAVE_STATE
deklariert ist, gilt Folgendes:
- [C-1-1] MUSS immer nur eine installierte Anwendung im System haben, die
cantSaveState
angibt. Wenn der Nutzer eine solche App verlässt, ohne sie explizit zu beenden (z. B. durch Drücken der Startbildschirmtaste beim Verlassen einer aktiven Aktivität und nicht durch Drücken der Schaltfläche „Zurück“, wenn keine aktiven Aktivitäten im System mehr vorhanden sind), MÜSSEN Geräteimplementierungen diese App im RAM priorisieren, so wie für andere Dinge, die weiterhin ausgeführt werden sollen, z. B. Dienste im Vordergrund. Solange sich eine solche Anwendung im Hintergrund befindet, kann das System trotzdem Energieverwaltungsfunktionen darauf anwenden, z. B. die Begrenzung des CPU- und Netzwerkzugriffs. - [C-1-2] MÜSSEN eine UI-Option zur Auswahl der App bereitstellen, die nicht am Mechanismus zum Speichern/Wiederherstellen des normalen Status teilnimmt, sobald der Nutzer eine zweite mit dem Attribut
cantSaveState
deklarierte App startet. - [C-1-3] DÜRFEN KEINE anderen Richtlinienänderungen auf Apps anwenden, die
cantSaveState
angeben, z. B. eine Änderung der CPU-Leistung oder der Planungspriorität.
Wenn die Funktion FEATURE_CANT_SAVE_STATE
in Geräteimplementierungen nicht deklariert wird, geschieht Folgendes:
- [C-1-1] MUSS das von Apps festgelegte Attribut
cantSaveState
ignorieren und DARF DAS App-Verhalten NICHT auf Grundlage dieses Attributs ändern.
3:18. Kontakte
Android umfasst Contacts Provider
APIs, mit denen Apps auf dem Gerät gespeicherte Kontaktdaten verwalten können.
Kontaktdaten, die direkt in das Gerät eingegeben werden, werden normalerweise mit einem Webdienst synchronisiert, aber die Daten KÖNNEN auch nur lokal auf dem Gerät gespeichert werden.
Kontakte, die nur auf dem Gerät gespeichert sind, werden als lokale Kontakte bezeichnet.
Rohkontakte werden einem Account zugeordnet oder darin gespeichert, wenn die Spalten ACCOUNT_NAME
und ACCOUNT_TYPE
für die unformatierten Kontakte mit den entsprechenden Feldern Account.name und Account.type des Kontos übereinstimmen.
Lokales Standardkonto: Ein Konto für unformatierte Kontakte, die nur auf dem Gerät gespeichert und mit keinem Konto im AccountManager verknüpft sind. Diese werden mit Null-Werten für die Spalten ACCOUNT_NAME
und ACCOUNT_TYPE
erstellt.
Benutzerdefiniertes lokales Konto: Ein Konto für unformatierte Kontakte, die nur auf dem Gerät gespeichert und nicht mit einem Konto im AccountManager verknüpft sind und mit mindestens einem Nicht-Null-Wert für die Spalten ACCOUNT_NAME
und ACCOUNT_TYPE
erstellt werden.
Geräteimplementierungen:
- [C-SR-1] Es wird dringend empfohlen, keine benutzerdefinierten lokalen Konten zu erstellen.
Wenn für Geräteimplementierungen ein benutzerdefiniertes lokales Konto verwendet wird:
- [C-1-1] Die
ACCOUNT_NAME
des benutzerdefinierten lokalen Kontos MUSS vonContactsContract.RawContacts.getLocalAccountName
zurückgegeben werden. - [C-1-2] Die
ACCOUNT_TYPE
des benutzerdefinierten lokalen Kontos MUSS vonContactsContract.RawContacts.getLocalAccountType
zurückgegeben werden. - [C-1-3] Rohkontakte, die von Anwendungen von Drittanbietern mit dem lokalen Standardkonto eingefügt werden (d.h. durch Festlegen von Nullwerten für
ACCOUNT_NAME
undACCOUNT_TYPE
), MÜSSEN in das benutzerdefinierte lokale Konto eingefügt werden. - [C-1-4] In das benutzerdefinierte lokale Konto eingefügte Rohkontakte DÜRFEN nicht entfernt werden, wenn Konten hinzugefügt oder entfernt werden.
- [C-1-5] Löschvorgänge für das benutzerdefinierte lokale Konto MÜSSEN dazu führen, dass unformatierte Kontakte sofort dauerhaft gelöscht werden (als wäre der Parameter
CALLER_IS_SYNCADAPTER
auf „true“ gesetzt), auch wenn der ParameterCALLER\_IS\_SYNCADAPTER
auf „false“ gesetzt oder nicht angegeben wurde.
4. Kompatibilität der App-Paketerstellung
Implementierungen auf Geräten:
[C-0-1] MUSS in der Lage sein, Android-".apk"-Dateien zu installieren und auszuführen, wie sie von dem "aapt"-Tool im offiziellen Android SDK generiert wurden.
- Da die oben genannte Anforderung eine Herausforderung sein kann, wird bei Geräteimplementierungen EMPFOHLEN, das Paketverwaltungssystem der AOSP-Referenzimplementierung zu verwenden.
[C-0-2] MUSS die Überprüfung von APK-Dateien mit dem APK-Signaturschema v3.1, dem APK-Signaturschema v3, dem APK-Signaturschema v2 und der JAR-Signatur unterstützen.
[C-0-3] DÜRFEN die Apk-Dateien, das Android-Manifest, den Dalvik-Bytecode oder den RenderScript-Bytecode nicht so erweitern, dass die Installation dieser Dateien auf anderen kompatiblen Geräten verhindert und korrekt ausgeführt wird.
[C-0-4] DÜRFEN NICHT zulassen, dass mit Ausnahme des aktuellen „installierten Installationsprogramms“ für das Paket die App im Hintergrund und ohne Bestätigung durch den Nutzer deinstalliert wird, wie im SDK für die Berechtigung
DELETE_PACKAGE
dokumentiert. Die einzigen Ausnahmen sind die App zur Systempaketprüfung, die den Intent PACKAGE_NEEDS_VERIFICATION verarbeitet, und die Speichermanager-App, die den Intent ACTION_MANAGE_STORAGE verarbeitet.[C-0-5] MÜSSEN eine Aktivität haben, die den
android.settings.MANAGE_UNKNOWN_APP_SOURCES
-Intent verarbeitet.[C-0-6] DARF KEINE Anwendungspakete aus unbekannten Quellen installieren, es sei denn, die Anwendung, die die Installation anfordert, erfüllt die folgenden Anforderungen:
- Es MÜSSEN die Berechtigung
REQUEST_INSTALL_PACKAGES
deklariert oderandroid:targetSdkVersion
auf 24 oder niedriger festgelegt sein. - Der Nutzer MUSS die Berechtigung erhalten haben, Apps aus unbekannten Quellen zu installieren.
- Es MÜSSEN die Berechtigung
SOLLTE Nutzern die Möglichkeit bieten, die Berechtigung zum Installieren von Apps aus unbekannten Quellen pro Anwendung zu gewähren/zu widerrufen, aber KANN dies als No-Op implementieren und
RESULT_CANCELED
fürstartActivityForResult()
zurückgeben, wenn die Geräteimplementierung den Nutzern diese Auswahl nicht ermöglichen soll. Aber selbst in solchen Fällen SOLLTEN sie dem Nutzer auch erklären, warum eine solche Auswahl nicht möglich ist.[C-0-7] MÜSSEN einen Warnhinweis mit dem Warnstring anzeigen, 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-APIPackageManager.setHarmfulAppWarning
als potenziell schädlich gekennzeichnet wurde.SOLLTEN im Warndialogfeld dem Nutzer die Möglichkeit bieten, eine App zu deinstallieren oder zu starten.
[C-0-8] MÜSSEN die Unterstützung für inkrementelles Dateisystem implementieren, wie hier beschrieben.
[C-0-9] MUSS die Überprüfung von APK-Dateien mit dem APK Signature Scheme v4 und dem APK Signature Scheme v4.1 unterstützen.
5. Multimedia-Kompatibilität
Geräteimplementierungen:
- [C-0-1] MUSS für jeden von
MediaCodecList
deklarierten Codec die in Abschnitt 5.1 definierten Medienformate, Encoder, Decodierer, Dateitypen und Containerformate unterstützen. - [C-0-2] MÜSSEN über
MediaCodecList
die Unterstützung von Encodern, Decodern, die für Drittanbieteranwendungen verfügbar sind, deklarieren und melden. - [C-0-3] MÜSSEN alle Formate, die codiert werden können, ordnungsgemäß decodieren und für Drittanbieter-Apps zur Verfügung stellen können. Dazu gehören alle Bitstreams, die von seinen Encodern generiert werden, und die Profile, die in der
CamcorderProfile
gemeldet werden.
Geräteimplementierungen:
- SOLLTE eine minimale Codec-Latenz anstreben. Mit anderen Worten:
- Eingabepuffer sollten NICHT verbraucht und gespeichert und nur nach der Verarbeitung zurückgegeben werden.
- Decodierte Zwischenspeicher sollten NICHT länger aufbewahrt werden, als vom Standard festgelegt (z.B. SPS).
- Sie sollten codierte Zwischenspeicher NICHT länger aufbewahren, als von der GOP-Struktur erforderlich ist.
Alle im folgenden Abschnitt aufgeführten Codecs sind Software-Implementierungen in der bevorzugten Android-Implementierung aus dem Android Open Source Project.
Weder Google noch die Open Handset Alliance machen eine Zusicherung, 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 Implementierungen dieses Codes, einschließlich in Open-Source-Software oder Shareware, möglicherweise Patentlizenzen von den entsprechenden Patentinhabern erforderlich sind.
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 für Drittanbieter-Apps verfügbar machen:
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
Alle Audioencoder MÜSSEN unterstützen:
- [C-3-1] Native 16-Bit-PCM-Audioframes für die native Bytereihenfolge von PCM über die
android.media.MediaCodec
API.
5.1.2 Audiodecodierung
Weitere Informationen finden Sie unter 5.1.3. Details zu Audio-Codecs.
Wenn Geräteimplementierungen eine Unterstützung für die Funktion android.hardware.audio.output
deklarieren, müssen sie die Decodierung der folgenden Audioformate unterstützen:
- [C-1-1] MPEG-4 AAC Profile (AAC LC)
- [C-1-2] MPEG-4 HE AAC-Profil (AAC+)
- [C-1-3] MPEG-4 HE AACv2 Profile (erweitertes AAC+)
- [C-1-4] AAC ELD (Optimierte AAC mit niedriger Verzögerung)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, einschließlich des USAC Baseline Profile und ISO/IEC 23003-4 Dynamic Range Control Profile)
- [C-1-5] FLAC
- [C-1-6] MP3-Datei
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE, einschließlich hochauflösender Audioformate mit bis zu 24 Bit, Abtastrate von 192 kHz und 8 Kanälen. Beachten Sie, dass diese Anforderung nur für die Decodierung gilt und dass ein Gerät während der Wiedergabe ein Downsampling und ein Downmix ausführen darf.
- [C-1-10] Opus
Wenn Geräteimplementierungen die Decodierung von AAC-Eingabepuffern von Mehrkanalstreams (d.h. mehr als zwei Kanälen) 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 Decodierung MUSS ohne Downmix durchgeführt werden (z.B. muss ein 5.0-AAC-Stream in fünf PCM-Kanäle decodiert werden, ein 5.1-AAC-Stream muss in sechs PCM-Kanäle decodiert werden).
- [C-2-2] Die Metadaten für den dynamischen Bereich MÜSSEN der Definition in "Dynamic Range Control (DRC)" in ISO/IEC 14496-3 entsprechen. Außerdem müssen die DRC-Schlüssel
android.media.MediaFormat
verwendet werden, um das Verhalten des Audiodecoders in Bezug auf den dynamischen Bereich zu konfigurieren. Die AAC-DRC-Schlüssel wurden mit 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
undKEY_AAC_ENCODED_TARGET_LEVEL
. - [C-SR-1] Es wird dringend empfohlen, dass alle AAC-Audiodecoder die oben genannten Anforderungen C-2-1 und C-2-2 erfüllen.
Bei der Decodierung von USAC-Audio mit MPEG-D (ISO/IEC 23003-4):
- [C-3-1] Lautstärke und DRC-Metadaten MÜSSEN gemäß MPEG-D DRC Dynamic Range Control Profile Level 1 interpretiert und angewendet werden.
- [C-3-2] Der Decoder MÜSSEN sich gemäß der Konfiguration mit den folgenden
android.media.MediaFormat
-Schlüsseln verhalten:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
undKEY_AAC_DRC_EFFECT_TYPE
.
MPEG-4 AAC-, HE AAC- und HE AACv2-Profildecoder:
- KANN die Steuerung der Lautstärke und des dynamischen Bereichs mit dem Profil für die dynamische Bereichskontrolle gemäß ISO/IEC 23003-4 unterstützen.
Wenn ISO/IEC 23003-4 unterstützt wird und sowohl die ISO/IEC 23003-4- als auch die ISO/IEC 14496-3-Metadaten in einem decodierten Bitstream vorhanden sind, gilt Folgendes:
- ISO/IEC 23003-4-Metadaten WERDEN Vorrang haben.
Alle Audiodecoder müssen die Ausgabe unterstützen:
- [C-6-1] Native 16-Bit-PCM-Audioframes für die native Bytereihenfolge von PCM über die
android.media.MediaCodec
API.
Wenn Geräteimplementierungen die Decodierung von AAC-Eingabepuffern von Mehrkanalstreams (d.h. mehr als zwei Kanälen) über den Standard-AAC-Audiodecoder in der android.media.MediaCodec
API in PCM unterstützen, MUSS Folgendes unterstützt werden:
- [C-7-1] MUSS von der Anwendung mit der Decodierung mit dem Schlüssel
KEY_MAX_OUTPUT_CHANNEL_COUNT
konfiguriert werden können, um zu steuern, ob der Inhalt auf Stereo heruntergemixt wird (bei Verwendung eines Werts von 2) oder mit der nativen Anzahl von Kanälen ausgegeben wird (wenn ein Wert gleich oder größer dieser Zahl ist). Mit einem Wert von 6 oder höher würde ein Decoder beispielsweise so konfiguriert werden, dass er 6 Kanäle ausgibt, wenn 5.1-Inhalte eingespeist werden. - [C-7-2] Bei der Decodierung muss der Decoder die im Ausgabeformat verwendete Kanalmaske mit dem Schlüssel
KEY_CHANNEL_MASK
unter Verwendung derandroid.media.AudioFormat
-Konstanten bewerben (Beispiel:CHANNEL_OUT_5POINT1
).
Wenn Geräteimplementierungen andere Audiodecoder als der standardmäßige AAC-Audiodecoder unterstützen und in der Lage sind, Mehrkanal-Audio (d.h. mehr als zwei Kanäle) auszugeben, wenn komprimierter Mehrkanalinhalt eingespeist wird, dann gilt:
- [C-SR-2] Der Decodierer wird dringend empfohlen, von der Anwendung so konfiguriert werden zu können, dass er mit dem Schlüssel
KEY_MAX_OUTPUT_CHANNEL_COUNT
decodiert wird. Damit wird gesteuert, ob der Inhalt auf Stereo heruntergemixt wird (bei Verwendung eines Werts von 2) oder über die native Anzahl von Kanälen ausgegeben wird (bei Verwendung eines Werts gleich oder größer dieser Zahl). Mit einem Wert von 6 oder höher würde ein Decoder beispielsweise so konfiguriert werden, dass er 6 Kanäle ausgibt, wenn 5.1-Inhalte eingespeist werden. - [C-SR-3] Bei der Decodierung wird der Decoder dringend empfohlen, die im Ausgabeformat verwendete Kanalmaske mit dem Schlüssel
KEY_CHANNEL_MASK
unter Verwendung der Konstanten „android.media.AudioFormat“ zu bewerben (Beispiel:CHANNEL_OUT_5POINT1
).
5.1.3 Details zu Audio-Codecs
Format/Codec | Details | Zu unterstützende Dateitypen/Containerformate |
---|---|---|
MPEG-4 AAC Profile (AAC LC) |
Unterstützung für Mono-/Stereo-/5.0/5.1-Inhalte mit Standardabtastraten von 8 bis 48 kHz. |
|
MPEG-4 HE AAC Profile (AAC+) | Unterstützung für Mono-/Stereo-/5.0/5.1-Inhalte mit Standardabtastraten von 16 bis 48 kHz. |
|
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. |
|
AAC ELD (Optimierte AAC mit geringer Verzögerung) | Unterstützung für Mono-/Stereoinhalte mit Standardabtastraten von 16 bis 48 kHz. |
|
Logo: 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, Stichproben bei 8 kHz | 3GPP (3GP) |
AMR-WB | 9 Raten von 6,60 kbit/s bis 23,85 kbit/s, abgetastet bei 16 kHz, definiert unter AMR-WB, Adaptive Multi-Rate – Wideband Speech Codec | 3GPP (3GP) |
FLAC | Sowohl für Encoder als auch Decoder: MÜSSEN mindestens die Mono- und Stereomodi unterstützt werden. Abtastraten von bis zu 192 kHz MÜSSEN unterstützt werden, 16-Bit- und 24-Bit-Auflösung MÜSSEN unterstützt werden. Die 24-Bit-FLAC-Audiodatenverarbeitung MÜSSEN in der Gleitkomma-Audiokonfiguration verfügbar sein. |
|
MP3 | Mono/Stereo, 8–320 Kbit/s konstant (CBR) oder variable Bitrate (VBR) |
|
MIDI | MIDI-Typ 0 und 1. DLS Version 1 und 2. XMF und XMF für Mobilgeräte Unterstützung der Klingeltonformate RTTTL/RTX, OTA und iMelody |
|
Vorbis |
|
|
PCM/WAVE | Der PCM-Codec muss lineare 16-Bit-PCM und 16-Bit-Gleitkommazahl unterstützen. Der WAVE-Extraktor muss lineare 16-Bit-, 24-Bit-, 32-Bit-PCM und 32-Bit-Gleitkommazahl (Raten bis zur Grenze der Hardware) unterstützen. Abtastraten von 8 kHz bis 192 kHz MÜSSEN unterstützt werden. | WAVE (WAV) |
Opus | Decodierung: Unterstützung für Mono-, Stereo-, 5.0- und 5.1-Inhalte mit Abtastraten von 8.000, 12.000, 16.000, 24.000 und 48.000 Hz. Codierung: Unterstützung für Mono- und Stereoinhalte mit Abtastraten von 8000, 140, 0,0, 0,0 und 0,0 Hz |
|
5.1.4. Bildcodierung
Weitere Informationen finden Sie unter 5.1.6. Details zu Image-Codecs.
Geräteimplementierungen MÜSSEN die Codierung der folgenden Bildcodierung unterstützen:
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
Neue Anforderungen erstellen
- [C-0-4] AVIF
- Geräte müssen
BITRATE_MODE_CQ
und Baseline-Profil unterstützen.
- Geräte müssen
Neue Anforderungen beenden
Wenn Geräteimplementierungen die HEIC-Codierung über android.media.MediaCodec
für den Medientyp MIMETYPE_IMAGE_ANDROID_HEIC
unterstützen, gilt Folgendes:
- [C-1-1] MUSS einen hardwarebeschleunigten HEVC-Encoder-Codec bereitstellen, der den Bitratenkontrollmodus
BITRATE_MODE_CQ
, das ProfilHEVCProfileMainStill
und eine Frame-Größe von 512 × 512 Pixeln unterstützt.
5.1.5 Bilddecodierung
Weitere Informationen finden Sie unter 5.1.6. Details zu Image-Codecs.
Geräteimplementierungen MÜSSEN die Decodierung der folgenden Bildcodierung unterstützen:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Roh
- [C-0-7] AVIF (Baseline-Profil)
Wenn Geräteimplementierungen die HEVC-Videodecodierung unterstützen, gilt Folgendes: * [C-1-1] MÜSSEN die HEIF-Bilddecodierung (HEIC) unterstützen.
Bilddecoder, die ein Format mit hoher Bittiefe unterstützen (mehr als 9 Bit pro Kanal):
- [C-2-1] MUSS die Ausgabe eines entsprechenden 8-Bit-Formats unterstützen, wenn dies von der Anwendung angefordert wird, z. B. über die Konfiguration
ARGB_8888
vonandroid.graphics.Bitmap
.
5.1.6. Details zu Image-Codecs
Format/Codec | Details | Unterstützte Dateitypen/Containerformate |
---|---|---|
JPEG | Base+progressiv | JPEG (JPG) |
GIF | GIF (.gif) | |
PNG | PNG (PNG) | |
BMP | BMP (BMP) | |
WebP | WebP (WebP) | |
Raw | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIF | Bild, Bildersammlung, Bildsequenz | HEIF (.heif), HEIC (.heic) |
AVIF (Baseline-Profil) | Bild, Bilderfassung, Bildsequenz-Baseline-Profil | HEIF-Container (.avif) |
Bild-Encoder und -Decodierer, die über die MediaCodec API verfügbar gemacht werden
[C-1-1] MUSS das flexible Farbformat YUV420 im Format 8:8:8 (
COLOR_FormatYUV420Flexible
) bisCodecCapabilities
unterstützen.[C-SR-1] WIRD DRINGEND zur Unterstützung des RGB888-Farbformats für den Eingabeoberflächenmodus empfohlen.
[C-1-3] MÜSSEN mindestens eines der planaren oder semiplanaren YUV420-Farbformate 8:8:8 unterstützen:
COLOR_FormatYUV420PackedPlanar
(entsprichtCOLOR_FormatYUV420Planar
) oderCOLOR_FormatYUV420PackedSemiPlanar
(entsprichtCOLOR_FormatYUV420SemiPlanar
). Es wird dringend empfohlen, beide zu unterstützen.
5.1.7. Video-Codecs
- Für eine akzeptable Qualität von Webvideostreaming- und Videokonferenzdiensten SOLLTEN bei Geräteimplementierungen ein VP8-Hardware-Codec verwendet werden, der die Anforderungen erfüllt.
Wenn Geräteimplementierungen einen Videodecoder oder Encoder umfassen:
[C-1-1] Video-Codecs MÜSSEN Ausgabe- und Eingabe-Bytebuffer-Größen unterstützen, die den größten zulässigen komprimierten und unkomprimierten Frame gemäß dem Standard und der Konfiguration unterstützen, aber auch nicht zu viel zuweisen.
[C-1-2] Videoencoder und -decoder müssen das flexible YUV420-Farbformat 8:8:8 (
COLOR_FormatYUV420Flexible
) überCodecCapabilities
unterstützen.[C-1-3] Videoencoder und -decoder MÜSSEN mindestens eines der planaren oder halbplanaren YUV420-Farbformate 8:8:8 unterstützen:
COLOR_FormatYUV420PackedPlanar
(entsprichtCOLOR_FormatYUV420Planar
) oderCOLOR_FormatYUV420PackedSemiPlanar
(entsprichtCOLOR_FormatYUV420SemiPlanar
). Es wird dringend empfohlen, beide Formate zu unterstützen.[C-SR-1] Videoencoder und -decoder werden dringend empfohlen, mindestens eines der hardwareoptimierten planaren oder semiplanaren YUV420-Farbformate 8:8:8 (YV12, NV12, NV21 oder ein gleichwertiges herstelleroptimiertes Format) zu unterstützen.
[C-1-5] Videodecoder, die ein Format mit hoher Bittiefe (mehr als 9 Bits pro Kanal) unterstützen, MÜSSEN die Ausgabe eines äquivalenten 8-Bit-Formats unterstützen, wenn sie von der Anwendung angefordert werden. Dies MUSS sich durch die Unterstützung eines YUV420-Farbformats im Format 8:8:8 über
android.media.MediaCodecInfo
widerspiegeln.
Wenn Geräteimplementierungen den Support für HDR-Profile über Display.HdrCapabilities
bewerben, geschieht Folgendes:
- [C-2-1] MUSS das Parsen und die Verarbeitung statischer HDR-Metadaten unterstützen.
Wenn Geräteimplementierungen den Support für Intra-Aktualisierungen über FEATURE_IntraRefresh
in der Klasse MediaCodecInfo.CodecCapabilities
bewerben, gilt Folgendes:
- [C-3-1] MUSS die Aktualisierungszeiträume im Bereich von 10 bis 60 Frames unterstützen und innerhalb von 20% des konfigurierten Aktualisierungszeitraums korrekt funktionieren.
Sofern in der Anwendung nicht anders mit dem Formatschlüssel KEY_COLOR_FORMAT
angegeben, gilt für Videodecoderimplementierungen:
- [C-4-1] MUSS standardmäßig das für die Hardware-Anzeige optimierte Farbformat verwenden, wenn die Konfiguration mit der Oberflächenausgabe erfolgt.
- [C-4-2] MÜSSEN standardmäßig ein YUV420-Farbformat 8:8:8 verwenden, das für CPU-Lesevorgänge 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 |
|
|
H.264-AVC | Weitere Informationen finden Sie in Abschnitt 5.2 und 5.3. |
|
H.265 HEVC | Weitere Informationen finden Sie in Abschnitt 5.3. |
|
MPEG-2 | Profil "Main" |
|
MPEG-4 SP |
|
|
VP8 | Einzelheiten finden Sie in Abschnitt 5.2 und 5.3. |
|
VP9 | Weitere Informationen finden Sie in Abschnitt 5.3. |
|
AV1 | Weitere Informationen finden Sie in Abschnitt 5.2 und Abschnitt 5.3. |
|
5.1.9. Medien-Codec-Sicherheit
Geräteimplementierungen MÜSSEN die Einhaltung der unten beschriebenen Sicherheitsfunktionen für Medien-Codec sicherstellen.
Android unterstützt OMX, eine plattformübergreifende Multimedia Aceleration API, sowie Codec 2.0, eine Low-Overhead Multimedia Aceleration API.
Wenn Geräteimplementierungen Multimedia unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN Support für Mediencodecs entweder über OMX oder Codec 2.0 APIs (oder beides) bereitstellen, wie im Android Open Source-Projekt, und die Sicherheitsfunktionen nicht deaktivieren oder umgehen. Das bedeutet nicht, dass jeder Codec entweder die OMX- oder die Codec 2.0 API verwenden MÜSSEN. Nur die Unterstützung für mindestens eine dieser APIs MUSS verfügbar sein und die Unterstützung für die verfügbaren APIs MÜSSEN die vorhandenen Sicherheitsvorkehrungen umfassen.
- [C-SR-1] wird dringend empfohlen, Support für die Codec 2.0 API aufzunehmen.
Wenn Geräteimplementierungen die Codec 2.0 API nicht unterstützen, geschieht Folgendes:
- [C-2-1] MÜSSEN den entsprechenden OMX-Software-Codec aus dem Android Open Source Project (falls verfügbar) für jedes vom Gerät unterstützte Medienformat und jeden -typ (Encoder oder Decoder) hinzufügen.
- [C-2-2] Codecs, deren Namen mit „OMX.google“ beginnen. MÜSSEN auf dem Quellcode des Open-Source-Projekts von Android basieren.
- [C-SR-2] Es wird dringend empfohlen, dass die OMX-Software-Codecs in einem Codec-Prozess ausgeführt werden, der keinen Zugriff auf andere Hardwaretreiber als Speicher-Mapper hat.
Wenn Geräteimplementierungen die Codec 2.0 API unterstützen, gilt Folgendes:
- [C-3-1] MÜSSEN den entsprechenden Codec 2.0-Software-Codec aus dem Android Open Source Project (falls verfügbar) für jedes Medienformat und jeden Typ (Encoder oder Decoder), die vom Gerät unterstützt werden, enthalten.
- [C-3-2] MÜSSEN die Codec 2.0-Software-Codecs im Software-Codec-Prozess enthalten, der im Android Open Source Project bereitgestellt wird, damit der Zugriff auf Software-Codecs eingeschränkt möglich ist.
- [C-3-3] Codecs, deren Namen mit „c2.android“ beginnen. MÜSSEN auf dem Quellcode des Open-Source-Projekts von Android basieren.
5.1.10. Charakterisierung von Medien-Codec
Wenn Geräteimplementierungen Medien-Codecs unterstützen, gilt Folgendes:
- [C-1-1] MUSS die richtigen Werte für die Media-Codec-Charakterisierung über die
MediaCodecInfo
API zurückgeben.
Insbesondere
- [C-1-2] Codecs, deren Namen mit „OMX“ beginnen. MÜSSEN die OMX-APIs verwendet werden und deren Namen den OMX-Benennungsrichtlinien entsprechen.
- [C-1-3] Codecs mit Namen, die mit „c2“ beginnen. MÜSSEN die Codec 2.0 API verwenden und deren Namen den Codec 2.0-Benennungsrichtlinien für Android entsprechen.
- [C-1-4] Codecs, deren Namen mit „OMX.google.“ oder „c2.android“ beginnen. DÜRFEN NICHT als Anbieter oder hardwarebeschleunigt bezeichnet werden.
- [C-1-5] Codecs, die in einem Codec-Prozess (Anbieter oder System) ausgeführt werden, der Zugriff auf andere Hardwaretreiber als Arbeitsspeicherzuweisungen und Mapper hat, DÜRFEN NICHT als reine Software gekennzeichnet werden.
- [C-1-6] Codecs, die nicht im Android Open Source-Projekt vorhanden sind oder nicht auf dem Quellcode in diesem Projekt basieren, MÜSSEN als Anbieter gekennzeichnet werden.
- [C-1-7] Codecs, die die Hardwarebeschleunigung nutzen, MÜSSEN als hardwarebeschleunigt bezeichnet werden.
- [C-1-8] Codec-Namen DÜRFEN NICHT irreführend sein. Beispielsweise müssen Codecs namens „decoders“ die Decodierung unterstützen und Codecs namens „encoders“ müssen die Codierung unterstützen. Codecs mit Namen, die Medienformate enthalten, MÜSSEN diese Formate unterstützen.
Wenn Geräteimplementierungen Video-Codecs unterstützen:
- [C-2-1] Alle Video-Codecs MÜSSEN erreichbare Framerate-Daten für die folgenden Größen veröffentlichen, wenn sie vom Codec unterstützt werden:
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Videoauflösung |
|
|
|
1920 x 1080 Pixel (außer MPEG4, AV1) | 3840 x 2160 Pixel (HEVC, VP9, AV1) |
- [C-2-2] Video-Codecs, die als hardwarebeschleunigt gekennzeichnet sind, MÜSSEN Informationen zu Leistungspunkten veröffentlichen. Sie MÜSSEN jeweils alle unterstützten Standardleistungspunkte auflisten, die in der
PerformancePoint
API aufgeführt sind, sofern sie nicht von einem anderen unterstützten Leistungspunkt abgedeckt sind. - Außerdem SOLLTEN sie erweiterte Leistungspunkte veröffentlichen, wenn sie eine andere kontinuierliche Videoleistung als eine der oben aufgeführten unterstützen.
5.2. Videocodierung
- Über zwei gleitende Fenster NICHT mehr als 15% über der Bitrate zwischen Intraframe-Intervallen (I-Frame) liegen
- NICHT mehr als 100% über der Bitrate auf einem gleitenden Fenster von einer Sekunde liegen.
Neue Anforderungen erstellen
Wenn Geräteimplementierungen einen Videoencoder unterstützen und für Drittanbieter-Apps zur Verfügung stellen undMediaFormat.KEY_BITRATE_MODE
auf BITRATE_MODE_VBR
setzen, damit der Encoder im Modus mit variabler Bitrate arbeitet, gilt für die codierte Bitrate Folgendes, sofern die Mindestqualität nicht beeinträchtigt wird :
[C-5-1] MUSSSOLLTE NICHT über einem gleitenden Fenster mehr als 15% über der Bitrate zwischen Intraframe-Intervallen (I-Frame) liegen.[C-5-2] MUSSSOLL NICHT mehr als 100% über der Bitrate auf einem gleitenden Fenster von 1 Sekunde liegen.
Wenn Geräteimplementierungen einen Videoencoder unterstützen und für Drittanbieter-Apps verfügbar machen und MediaFormat.KEY_BITRATE_MODE
auf BITRATE_MODE_CBR
setzen, damit der Encoder im Modus mit konstanter Bitrate arbeitet, gilt für die codierte Bitrate:
[C-6-1] MUSS[C-SR-2] wird dringend empfohlen, bei einem gleitenden Fenster von 1 Sekunde NICHT mehr als 15% über der Zielbitrate zu liegen.
Neue Anforderungen beenden
Wenn Geräteimplementierungen ein eingebettetes Display mit einer diagonalen Länge von mindestens 2,5 Zoll, einen Videoausgabeanschluss oder die Unterstützung einer Kamera mit dem Funktions-Flag android.hardware.camera.any
enthalten, gilt Folgendes:
- [C-1-1] MÜSSEN mindestens einen VP8- oder H.264-Videoencoder unterstützen und für Drittanbieteranwendungen zur Verfügung stellen.
- SOLLTEN sowohl VP8- als auch H.264-Videoencoder unterstützen und für Drittanbieteranwendungen verfügbar machen.
Wenn Geräteimplementierungen H.264-, VP8-, VP9- oder HEVC-Videoencoder unterstützen und für Drittanbieteranwendungen verfügbar machen, gilt Folgendes:
- [C-2-1] MUSS dynamisch konfigurierbare Bitraten unterstützen.
- SOLLTE variable Frame-Rates unterstützen, wobei der Video-Encoder die sofortige Frame-Dauer anhand der Zeitstempel der Eingabepuffer bestimmen und seinen Bit-Bucket anhand dieser Frame-Dauer zuweisen sollte.
Wenn Geräteimplementierungen den Videoencoder MPEG-4 SP unterstützen und für Drittanbieter-Apps verfügbar machen, geschieht Folgendes:
- SOLLTEN für den unterstützten Encoder dynamisch konfigurierbare Bitraten unterstützen.
Wenn Geräteimplementierungen hardwarebeschleunigte Video- oder Bild-Encoder bereitstellen und eine oder mehrere angeschlossene oder steckbare Hardwarekameras unterstützen, die über die android.camera
APIs sichtbar sind, gilt Folgendes:
- [C-4-1] Alle hardwarebeschleunigten Video- und Bildencoder MÜSSEN die Codierung von Frames der Hardwarekamera(s) unterstützen.
- SOLLTEN die Codierung von Frames der Hardwarekameras über alle Video- oder Bild-Encoder unterstützen.
Wenn Geräteimplementierungen eine HDR-Codierung ermöglichen, geschieht Folgendes:
- [C-SR-1] wird dringend empfohlen, ein Plug-in für die nahtlose Transcodierungs-API bereitzustellen, um vom HDR-Format in das SDR-Format zu konvertieren.
5.2.1 H.263
Wenn Geräteimplementierungen H.263-Encoder unterstützen und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:
- [C-1-1] MUSS die QCIF-Auflösung (176 x 144) mit Referenzprofilebene 45 unterstützen. Die SQCIF-Auflösung ist optional.
Dynamisch konfigurierbare Bitraten für den unterstützten Encoder unterstützen
5.2.2 H.264
Wenn Geräteimplementierungen den H.264-Codec unterstützen, gilt Folgendes:
- [C-1-1] MUSS Baseline-Profilebene 3 unterstützen. Die Unterstützung für ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (redundante Slices) ist jedoch OPTIONAL. Aus Gründen der Kompatibilität mit anderen Android-Geräten wird empfohlen, ASO, FMO und RS von Encodern nicht für das Baseline-Profil zu verwenden.
- [C-1-2] MUSS die SD-Videocodierungsprofile (Standard Definition) in der folgenden Tabelle unterstützen.
- SOLLTEN die Hauptprofilebene 4 unterstützen.
- SOLLTEN die Videocodierungsprofile in HD (High Definition) unterstützen, wie in der folgenden Tabelle angegeben.
Wenn Geräteimplementierungen die Unterstützung der H.264-Codierung für Videos mit der Auflösung 720p oder 1080p über die Media APIs melden, gilt Folgendes:
- [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | |
---|---|---|---|---|
Videoauflösung | 320 x 240 px | 720 x 480 Pixel | 1280 x 720 px | 1920 x 1080 px |
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-Video-Codierungsprofile unterstützen.
- SOLLTEN die folgenden HD-Videocodierungsprofile (High Definition) unterstützen.
- [C-1-2] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
- SOLLTEN SIE einen VP8-Hardware-Codec bereitstellen, der die Anforderungen zur RTC-Hardwarecodierung des WebM-Projekts erfüllt, um eine akzeptable Qualität von Webvideostreaming- und Videokonferenzen sicherzustellen.
Wenn Geräteimplementierungen die Unterstützung der VP8-Codierung für Videos mit einer Auflösung von 720p oder 1080p über die Media APIs melden, gilt Folgendes:
- [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | |
---|---|---|---|---|
Videoauflösung | 320 x 180 Pixel | 640 x 360 Pixel | 1280 x 720 px | 1920 x 1080 px |
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.
- SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
- [C-SR-1] wird dringend empfohlen, die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben zu unterstützen, wenn es einen Hardware-Encoder gibt.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Videoauflösung | 720 x 480 Pixel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
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 Geräteimplementierungen Profil 2 oder Profil 3 über die Media APIs unterstützt werden, gilt Folgendes:
- Unterstützung für das 12-Bit-Format ist optional.
5.2.5 H.265
Wenn Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:
- [C-1-1] MUSS Hauptprofilebene 3 bis zu einer Auflösung von 512 x 512 unterstützen.
SOLLTEN die HD-Codierungsprofile wie in der folgenden Tabelle angegeben unterstützen.- [C-SR-1] wird dringend empfohlen, die SD-Profile (720 x 480) und die HD-Codierungsprofile zu unterstützen, wie in der folgenden Tabelle angegeben, wenn ein Hardware-Encoder vorhanden ist.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Videoauflösung | 720 x 480 Pixel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
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 |
Neue Anforderungen erstellen
5.2.6. AV1
Wenn Geräteimplementierungen den AV1-Codec unterstützen, geschieht Folgendes:
- [C-1-1] MUSS das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalte unterstützen.
[C-1-2] MÜSSEN Leistungsdaten, d.h. Berichte zur Leistung, über die APIs
getSupportedFrameRatesFor()
odergetSupportedPerformancePoints()
veröffentlichen, wenn die Lösungen in der Tabelle unten unterstützt werden.[C-1-3] MUSS HDR-Metadaten akzeptieren und im Bitstream ausgeben
Wenn der AV1-Encoder hardwarebeschleunigt ist, geschieht Folgendes:
- [C-2-1] MUSS bis einschließlich HD1080p-Codierungsprofil aus der folgenden Tabelle unterstützen:
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Videoauflösung | 720 x 480 Pixel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps |
Video-Bitrate | 5 Mbit/s | 8 Mbit/s | 16 Mbit/s | 50 Mbit/s |
Neue Anforderungen beenden
5.3. Videodecodierung
Wenn Geräteimplementierungen die Codecs VP8, VP9, H.264 oder H.265 unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN den dynamischen Videoauflösungs- und Framerate-Wechsel über die standardmäßigen Android-APIs innerhalb desselben Streams für alle VP8-, VP9-, H.264- und H.265-Codecs in Echtzeit und bis zur maximalen Auflösung unterstützen, die von jedem Codec auf dem Gerät unterstützt wird.
5.3.1 MPEG-2
Wenn Geräteimplementierungen MPEG-2-Decodierer unterstützen, gilt Folgendes:
- [C-1-1] MUSS die allgemeine Ebene "Hauptprofil" unterstützen.
5.3.2 H.263
Wenn Geräteimplementierungen H.263-Decoder unterstützen, gilt Folgendes:
- [C-1-1] MUSS Baseline-Profilstufe 30 (CIF-, QCIF- und SQCIF-Auflösungen bei 30 fps, 384 kbit/s) und Stufe 45 (QCIF- und SQCIF-Auflösungen bei 30 fps und 128 kbit/s) unterstützen.
5.3.3 MPEG-4
Bei Geräteimplementierungen mit MPEG-4-Decodierern gilt Folgendes:
- [C-1-1] MÜSSEN die einfache Profilebene 3 unterstützen.
5.3.4. H.264
Wenn Geräteimplementierungen H.264-Decoder unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die Hauptprofilebene 3.1 und das Basisprofil unterstützen. Die Unterstützung für ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (redundante Slices) ist OPTIONAL.
- [C-1-2] MUSS Videos mit den in der folgenden Tabelle aufgeführten SD-Profilen (Standard Definition) decodieren können und mit dem Basisprofil und dem Hauptprofil der Ebene 3.1 (einschließlich 720p30) codiert sein.
- SOLLTEN in der Lage sein, Videos mit HD-Profilen (High Definition) zu decodieren, wie in der folgenden Tabelle angegeben.
Wenn die von der Methode Display.getSupportedModes()
gemeldete Höhe der Videoauflösung entspricht oder größer ist, wird auf dem Gerät Folgendes implementiert:
- [C-2-1] MUSS die HD-720p-Videodecodierungsprofile in der folgenden Tabelle unterstützen.
- [C-2-2] MUSS die HD-1080p-Videodecodierungsprofile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | |
---|---|---|---|---|
Videoauflösung | 320 x 240 px | 720 x 480 Pixel | 1280 x 720 px | 1920 x 1080 px |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | 60 fps | 30 fps (60 fpsFernsehen) |
Video-Bitrate | 800 kbit/s | 2 Mbit/s | 8 Mbit/s | 20 Mbit/s |
5.3.5. H.265 (HEVC)
Wenn Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die Hauptprofilebene 3 der Hauptstufe und die SD-Videodecodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
- SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
- [C-1-2] MUSS die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen, wenn es einen Hardwaredecoder gibt.
Wenn die von der Methode Display.getSupportedModes()
gemeldete Höhe gleich oder größer als die Videoauflösung ist, dann gilt:
- [C-2-1] Geräteimplementierungen MÜSSEN mindestens eine H.265- oder VP9-Decodierung von 720-, 1080- und UHD-Profilen unterstützen.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Videoauflösung | 352 x 288 px | 720 x 480 Pixel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | 30/60 fps (60 fpsFernsehen mit H.265-Hardware-Decodierung) | 60 fps |
Video-Bitrate | 600 Kbit/s | 1,6 Mbit/s | 4 Mbit/s | 5 Mbit/s | 20 Mbit/s |
Wenn in Geräteimplementierungen über die Medien-APIs ein HDR-Profil unterstützt wird, gehe so vor:
- [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 an einem standardmäßigen Videoausgabeport (z.B. HDMI).
5.3.6. VP8
Wenn Geräteimplementierungen den VP8-Codec unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die SD-Decodierungsprofile in der folgenden Tabelle unterstützen.
- SOLLTEN SIE einen Hardware-VP8-Codec verwenden, der die Anforderungen erfüllt.
- SOLLTEN die HD-Decodierungsprofile in der folgenden Tabelle unterstützen.
Wenn die von der Methode Display.getSupportedModes()
gemeldete Höhe der Videoauflösung entspricht oder größer ist, dann gilt:
- [C-2-1] Geräteimplementierungen MÜSSEN 720p-Profile in der folgenden Tabelle unterstützen.
- [C-2-2] Geräteimplementierungen MÜSSEN 1080p-Profile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | |
---|---|---|---|---|
Videoauflösung | 320 x 180 Pixel | 640 x 360 Pixel | 1280 x 720 px | 1920 x 1080 px |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | 30 fps (60 fpsFernsehen) | 30 (60 fpsFernsehen) |
Video-Bitrate | 800 kbit/s | 2 Mbit/s | 8 Mbit/s | 20 Mbit/s |
5.3.7. VP9
Wenn Geräteimplementierungen den VP9-Codec unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die SD-Videodecodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
- SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
Wenn Geräteimplementierungen den VP9-Codec und einen Hardwaredecoder unterstützen:
- [C-2-1] MUSS die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
Wenn die von der Methode Display.getSupportedModes()
gemeldete Höhe gleich oder größer als die Videoauflösung ist, dann gilt:
- [C-3-1] Geräteimplementierungen MÜSSEN mindestens eine VP9- oder H.265-Decodierung der 720-, 1080- und UHD-Profile unterstützen.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Videoauflösung | 320 x 180 Pixel | 640 x 360 Pixel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | 30 fps (60 fpsFernsehen 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 in Geräteimplementierungen VP9Profile2
oder VP9Profile3
über die Medien-APIs 'CodecProfileLevel unterstützt werden:
- Unterstützung für das 12-Bit-Format ist optional.
Wenn in Geräteimplementierungen ein HDR-Profil (VP9Profile2HDR
, VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) über die Medien-APIs unterstützt wird:
- [C-4-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR-Metadaten (
KEY_HDR_STATIC_INFO
für alle HDR-Profile sowie 'KEY_HDR10_PLUS_INFO' für HDR10Plus-Profile) von der Anwendung akzeptieren. Sie MÜSSEN auch 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 an einem Standard-Videoausgabeport (z.B. HDMI).
5.3.8. Dolby Vision
Wenn Geräteimplementierungen die Unterstützung des Dolby Vision-Decoders über HDR_TYPE_DOLBY_VISION
deklarieren, geschieht Folgendes:
- [C-1-1] MÜSSEN einen Dolby Vision-fähigen Extraktor bereitstellen.
- [C-1-2] MÜSSEN Dolby Vision-Inhalte korrekt auf dem Gerätebildschirm oder an einem Standard-Videoausgangsport (z.B. HDMI).
- [C-1-3] MÜSSEN die Track-ID der abwärtskompatiblen Basisschichten (falls vorhanden) auf dieselbe Track-ID wie die kombinierte Dolby Vision-Ebene festlegen.
5.3.9. AV1
- [C-1-1] MUSS Profil 0 einschließlich 10-Bit-Inhalten unterstützen.
Neue Anforderungen erstellen
Wenn Geräteimplementierungen den AV1-Codec unterstützen und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:- [C-1-1] MUSS das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalte unterstützen.
Wenn Geräteimplementierungen den AV1-Codec mit einem hardwarebeschleunigten Decoder unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN mindestens HD-Videodecodierungsprofile mit 720p aus der folgenden Tabelle decodieren können, wenn die von der Methode
Display.getSupportedModes()
gemeldete Höhe mindestens 720p beträgt. - [C-2-2] MÜSSEN mindestens HD-Videodecodierungsprofile mit 1080p aus der folgenden Tabelle decodieren können, wenn die von der Methode
Display.getSupportedModes()
gemeldete Höhe mindestens 1080p beträgt.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Videoauflösung | 720 x 480 Pixel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps |
Video-Bitrate | 5 Mbit/s | 8 Mbit/s | 16 Mbit/s | 50 Mbit/s |
Wenn Geräteimplementierungen HDR-Profile über die Media APIs unterstützen, gilt Folgendes:
- [C-3-1] MUSS das Extrahieren und Ausgeben von HDR-Metadaten aus dem Bitstream und/oder dem Container unterstützen.
- [C-3-2] MÜSSEN HDR-Inhalte richtig auf dem Gerätebildschirm oder an einem Standard-Videoausgangsanschluss (z. B. HDMI) anzeigen.
Neue Anforderungen beenden
5.4. Audioaufnahmen
Während einige der in diesem Abschnitt beschriebenen Anforderungen seit Android 4.3 als SOLLTEN aufgelistet werden, werden diese in der Kompatibilitätsdefinition für zukünftige Versionen in MÜSSEN geändert. Für bestehende und neue Android-Geräte EMPFOHLEN, diese Anforderungen zu erfüllen, die aufgelistet sind, aber sie können nach dem Upgrade auf die zukünftige Version nicht mehr mit Android kompatibel sein.
5.4.1 Aufzeichnung von Rohdaten und Mikrofon
Wenn in Geräteimplementierungen android.hardware.microphone
deklariert wird, gilt Folgendes:
[C-1-1] MUSS die Erfassung von Audio-Rohinhalten für jeden
AudioRecord
- oderAAudio
-EINGABE-Stream, der erfolgreich geöffnet wird, zulassen. Es MÜSSEN mindestens die folgenden Eigenschaften unterstützt werden:- Format:Lineare PCM, 16 Bit
- Abtastraten:8.000, 11.025, 16.000, 44.100, 48.000 Hz
- Kanäle:Mono
- Audioquellen:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
oderVOICE_PERFORMANCE
. Dies gilt auch für die entsprechenden Eingabevoreinstellungen inAAudio
, z. B.AAUDIO_INPUT_PRESET_CAMCORDER
.
SOLLTEN die Erfassung von Rohaudioinhalten mit den folgenden Eigenschaften zulassen:
- 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] MÜSSEN bei den obigen Stichprobenraten ohne Up-Sampling erfassen.
[C-1-3] MÜSSEN einen geeigneten Anti-Aliasing-Filter verwenden, wenn die oben angegebenen Stichprobenraten mit Downsampling erfasst werden.
SOLLTEN die Aufnahme von Audio-Rohinhalten in AM-Radio- und DVD-Qualität zulassen. Das hat folgende Eigenschaften:
- Format: Lineare PCM, 16 Bit
- Abtastraten: 22.050, 48.000 Hz
- Kanäle: Stereo
[C-1-4] MÜSSEN die
MicrophoneInfo
API berücksichtigen und die Informationen für die verfügbaren Mikrofone auf dem Gerät, auf die Drittanbieteranwendungen über dieAudioManager.getMicrophones()
API zugreifen können, für aktive AudioRecords mitMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
oderVOICE_PERFORMANCE
korrekt ausfüllen. Wenn Geräteimplementierungen die Erfassung von Audio-Rohinhalten in AM-Radio- und DVD-Qualität ermöglichen, gilt Folgendes:[C-2-1] MÜSSEN ohne Upsampling bei einem Verhältnis von mehr als 16000:22050 oder 44100:48000 Aufnahmen erfassen.
[C-2-2] MÜSSEN für jedes Up- bzw. Downsampling einen geeigneten Anti-Aliasing-Filter verwenden.
5.4.2 Für Spracherkennung aufnehmen
Wenn in Geräteimplementierungen android.hardware.microphone
deklariert wird, gilt Folgendes:
- [C-1-1] MÜSSEN die Audioquelle
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
mit einer der Abtastraten 44100 und 48.000 erfassen. - [C-1-2] MÜSSEN standardmäßig die Audioverarbeitung zur Rauschunterdrückung deaktivieren, wenn ein Audiostream aus der Audioquelle
AudioSource.VOICE_RECOGNITION
aufgezeichnet wird. [C-1-3] MÜSSEN standardmäßig die automatische Verstärkungsregelung beim Aufzeichnen eines Audiostreams aus der Audioquelle
AudioSource.VOICE_RECOGNITION
deaktivieren.SOLLTEN im mittleren Frequenzbereich annähernd flache Amplitude-gegen-Frequenz-Eigenschaften haben, genauer gesagt ±3 dB von 100 Hz bis 4.000 Hz für jedes Mikrofon, das zur Aufnahme der Audioquelle für die Spracherkennung verwendet wird.
[C-SR-1] wird dringend empfohlen, Amplitudenpegel im niedrigen Frequenzbereich anzugeben, und zwar zwischen ±20 dB von 30 Hz und 100 Hz im Vergleich zum Mittelfrequenzbereich jedes einzelnen Mikrofons, das zur Aufzeichnung der Audioquelle für die Spracherkennung verwendet wird.
[C-SR-2] wird dringend empfohlen, Amplitudenpegel im hohen Frequenzbereich anzugeben, insbesondere von ±30 dB von 4.000 bis 22 kHz im Vergleich zum Mittelfrequenzbereich jedes einzelnen Mikrofons, das zur Aufzeichnung der Audioquelle für die Spracherkennung verwendet wird.
SOLLTE die Audioeingabeempfindlichkeit so einstellen, dass eine sinusoidale Tonquelle von 1.000 Hz bei 90 dB Schalldruckpegel (gemessen
in einem Abstand von 30 cm zum Mikrofon)neben dem Mikrofon eine ideale Antwort von RMS 2.500 und einer Gleitkommazahl von 1.770 mit 1.770 und 1.770 B3-Samples sowie 1.770 cd/m2 für eine Gleitkommazahl-Erkennung undSOLLTEN den Audiostream der Spracherkennung so aufzeichnen, dass die PCM-Amplitudenpegel linear Änderungen des Eingangs-SPL in einem Bereich von -18 dB bis +12 dB bzw. 90 dB SPL am Mikrofon erfassen.
SOLLTE den Audiostream der Spracherkennung mit einer insgesamten harmonischen Verzerrung (THD) von weniger als 1% für 1 kHz bei 90 dB SPL-Eingangslautstärke am Mikrofon aufzeichnen.
Wenn in Geräteimplementierungen android.hardware.microphone
und Technologien zur Rauschunterdrückung bzw. Rauschunterdrückung für die Spracherkennung deklariert sind, gilt Folgendes:
- [C-2-1] MÜSSEN erlauben, dass dieser Audioeffekt mit der
android.media.audiofx.NoiseSuppressor
API gesteuert werden kann. - [C-2-2] MÜSSEN jede Implementierung der Rauschunterdrückungstechnologie eindeutig über das Feld
AudioEffect.Descriptor.uuid
identifizieren.
5.4.3 Aufnahme für Umleitung der Wiedergabe
Die Klasse android.media.MediaRecorder.AudioSource
enthält die Audioquelle REMOTE_SUBMIX
.
Wenn in Geräteimplementierungen sowohl android.hardware.audio.output
als auch android.hardware.microphone
deklariert sind, gilt Folgendes:
[C-1-1] MÜSSEN die Audioquelle
REMOTE_SUBMIX
ordnungsgemäß implementieren, sodass eine Anwendung, die dieandroid.media.AudioRecord
API zum Aufzeichnen aus dieser Audioquelle verwendet, eine Mischung aus allen Audiostreams erfasst, mit Ausnahme der folgenden:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. Akustik-Echo-Canceler
Wenn in Geräteimplementierungen android.hardware.microphone
deklariert wird, gilt Folgendes:
- SOLLTEN SIE eine auf die Sprachkommunikation abgestimmte Technologie vom Typ Acoustic Echo Canceler (AEC) implementieren, die beim Erfassen mit
AudioSource.VOICE_COMMUNICATION
auf den Erfassungspfad angewendet wird.
Wenn Geräteimplementierungen einen akustischen Echo-Canceler bereitstellen, der in den Aufnahme-Audiopfad eingefügt wird, wenn AudioSource.VOICE_COMMUNICATION
ausgewählt ist, geschieht Folgendes:
- [C-SR-1] wird STRONGLY_RECOMMENDED über die API-Methode AcousticEchoCanceler.isAvailable() von AcousticEchoCanceler deklariert.
- [C-SR-2] sind STRONGLY_RECOMMENDED, damit dieser Audioeffekt mit der AcousticEchoCanceler API gesteuert werden kann.
- [C-SR-3] werden STRONGLY_RECOMMENDED verwendet, um jede AEC-Technologieimplementierung über das Feld AudioEffect.Descriptor.uuid eindeutig zu identifizieren.
5.4.5. Gleichzeitige Aufnahme
Wenn in Geräteimplementierungen android.hardware.microphone
deklariert wird, MÜSSEN sie die gleichzeitige Erfassung implementieren, wie in diesem Dokument beschrieben. Im Detail:
- [C-1-1] MÜSSEN den gleichzeitigen Zugriff auf das Mikrofon durch einen Bedienungshilfedienst, der Daten mit
AudioSource.VOICE_RECOGNITION
erfasst, und mindestens eine App, die mit einer beliebigenAudioSource
aufzeichnet, zulassen. - [C-1-2] MUSS den gleichzeitigen Zugriff auf das Mikrofon durch eine vorinstallierte App mit einer Assistant-Rolle und mindestens einer App erlauben, die mit einem beliebigen
AudioSource
mit Ausnahme vonAudioSource.VOICE_COMMUNICATION
oderAudioSource.CAMCORDER
Aufnahmen macht. - [C-1-3] MÜSSEN die Audioaufnahme für alle anderen Anwendungen mit Ausnahme von Bedienungshilfen stummschalten, während eine Anwendung Daten mit
AudioSource.VOICE_COMMUNICATION
oderAudioSource.CAMCORDER
aufzeichnet. Wenn eine App jedoch Daten überAudioSource.VOICE_COMMUNICATION
aufzeichnet, kann eine andere App den Sprachanruf aufzeichnen, sofern es sich um eine privilegierte (vorinstallierte) App mit der BerechtigungCAPTURE_AUDIO_OUTPUT
handelt. - [C-1-4] Wenn zwei oder mehr Anwendungen gleichzeitig Daten aufzeichnen und keine der Anwendungen über eine UI verfügt, empfängt die Anwendung, die mit der Aufzeichnung des zuletzt verwendeten Audios begonnen hat, auch.
5.5. Audiowiedergabe
Wie in Abschnitt 7.8.2 definiert, unterstützt Android es Apps, Audio über das Audioausgabe-Peripheriegerät wiederzugeben.
5.5.1 Raw-Audiowiedergabe
Wenn in Geräteimplementierungen android.hardware.audio.output
deklariert wird, gilt Folgendes:
[C-1-1] MÜSSEN die Wiedergabe von Rohaudioinhalten mit den folgenden Eigenschaften zulassen:
- Quellformate: Lineare PCM, 16-Bit, 8-Bit, Gleitkommazahl
- Kanäle: Mono, Stereo, gültige Multi-Channel-Konfigurationen mit bis zu 8 Kanälen
- Abtastraten (in Hz):
- 8000, 11025, 16.000, 22050, 24.000, 32.000, 44.100, 48.000 bei den oben aufgeführten Kanalkonfigurationen
- 96.000 in Mono und Stereo
5.5.2 Audioeffekte
Android bietet eine API für Audioeffekte für Geräteimplementierungen.
Wenn in Geräteimplementierungen die Funktion android.hardware.audio.output
deklariert wird, geschieht Folgendes:
- [C-1-1] MUSS die Implementierungen
EFFECT_TYPE_EQUALIZER
undEFFECT_TYPE_LOUDNESS_ENHANCER
unterstützen, die über die abgeleiteten AudioEffect-KlassenEqualizer
undLoudnessEnhancer
gesteuert werden können. - [C-1-2] MUSS die Visualizer API-Implementierung unterstützen, die über die Klasse
Visualizer
gesteuert werden kann. - [C-1-3] MUSS die Implementierung
EFFECT_TYPE_DYNAMICS_PROCESSING
unterstützen, die über die abgeleitete AudioEffect-KlasseDynamicsProcessing
gesteuert werden kann.
Neue Anforderungen erstellen
- [C-1-4] MUSS Audioeffekte mit Gleitkommaeingabe und -ausgabe unterstützen.
- [C-1-5] MÜSSEN sicherstellen, dass Audioeffekte mehrere Kanäle bis zur Mischkanalanzahl (auch als FCC_LIMIT bezeichnet) unterstützen.
Neue Anforderungen beenden
- SOLLTEN die Implementierungen
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
,EFFECT_TYPE_PRESET_REVERB
undEFFECT_TYPE_VIRTUALIZER
unterstützen, die über die abgeleitetenAudioEffect
-KlassenBassBoost
,EnvironmentalReverb
,PresetReverb
undVirtualizer
gesteuert werden können. - [C-SR-1] wird dringend empfohlen, Effekte in Gleitkomma- und Mehrkanalkanälen zu unterstützen.
5.5.3 Audioausgabelautstärke
Implementierungen von Automobilgeräten:
- SOLLTE die Audiolautstärke für jeden Audiostream separat anpassen. Dabei muss der Inhaltstyp oder die Nutzung gemäß der Definition unter AudioAttributes und die öffentlich in
android.car.CarAudioManager
definierte Nutzung der Audiofunktion des Autos verwendet werden.
5.5.4 Audio-Offload
Wenn Geräteimplementierungen die Wiedergabe von Audioauslagerungen unterstützen, geschieht Folgendes:
- [C-SR-1] Es wird dringend empfohlen, den wiedergegebenen, lückenlosen Audioinhalt zwischen zwei Clips mit demselben Format zu kürzen, wenn dies in der AudioTrack lückenlosen API und im Mediencontainer für MediaPlayer angegeben wird.
5.6. Audiolatenz
Die Audiolatenz ist die Zeitverzögerung, wenn ein Audiosignal ein System durchläuft. Viele Arten von Anwendungen nutzen kurze Latenzen, um Soundeffekte in Echtzeit zu erzielen.
Verwenden Sie für die Zwecke dieses Abschnitts die folgenden Definitionen:
- Ausgabelatenz. Das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung einen Frame mit PCM-codierten Daten schreibt, und dem Zeitpunkt, zu dem der entsprechende Ton der Umgebung über einen geräteinternen Transducer präsentiert wird oder das Signal das Gerät über einen Port verlässt und extern erfasst werden kann.
- Kalte Ausgabelatenz. Die Zeit zwischen dem Start eines Ausgabestreams und der Darstellung des ersten Frames basierend auf Zeitstempeln, wenn das Audioausgabesystem vor der Anfrage inaktiv und heruntergefahren wurde.
- Kontinuierliche Ausgabelatenz: Die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät Audio wiedergibt.
- Eingabelatenz Das Intervall zwischen dem Zeitpunkt, zu dem ein Schall dem Gerät von der Umgebung über einen geräteinternen Transducer oder ein Signal übertragen wird, der über einen Port in das Gerät eintritt, und wenn eine Anwendung den entsprechenden Frame von PCM-codierten Daten liest.
- keine Eingabe mehr. Der erste Teil eines Eingabesignals, der nicht verwendbar oder nicht verfügbar ist.
- Kalteingabelatenz Die Zeit zwischen dem Start des Streams und dem Empfang des ersten gültigen Frames, wenn das Audioeingabesystem vor der Anfrage inaktiv und heruntergefahren wurde.
Kontinuierliche Eingabelatenz. Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufzeichnet.
Kontinuierliche Umlauflatenz. Die Summe aus kontinuierlicher Eingabelatenz plus kontinuierlicher Ausgabelatenz plus einem Pufferzeitraum. Der Pufferzeitraum gibt der Anwendung Zeit, das Signal zu verarbeiten, und Zeit für die Anwendung, um die Phasendifferenz zwischen Eingabe- und Ausgabestreams abzuschwächen.
OpenSL ES PCM Buffer Queue API Alle PCM-bezogenen OpenSL ES APIs im Android NDK.
Native Audio API von Audio. Die AAudio APIs im Android-NDK.
Zeitstempel. Ein Paar, das aus einer relativen Frame-Position in einem Stream und der geschätzten Zeit besteht, zu der dieser Frame die Audioverarbeitungspipeline auf dem zugehörigen Endpunkt erreicht oder verlässt. Siehe auch AudioTimestamp.
Fehler. Eine vorübergehende Unterbrechung oder ein falscher Stichprobenwert im Audiosignal, die in der Regel durch eine Pufferunterlaufe für die Ausgabe, eine Pufferüberschreitung für die Eingabe oder eine andere Quelle von digitalem oder analogem Rauschen verursacht wird.
mittlere absolute Abweichung. Durchschnitt des absoluten Werts der Abweichungen vom Mittelwert für eine Gruppe von Werten.
Tap-to-Ton-Latenz. Die Zeit zwischen dem Antippen des Bildschirms und dem Ton, der als Ergebnis dieses Tippens auf dem Lautsprecher erzeugt wird.
Wenn in Geräteimplementierungen android.hardware.audio.output
deklariert wird, MÜSSEN die folgenden Anforderungen erfüllt oder übertroffen werden:
- [C-1-1] Der von AudioTrack.getTimestamp und
AAudioStream_getTimestamp
zurückgegebene Ausgabezeitstempel ist auf +/- 2 ms genau. [C-1-2] Kalte Ausgabelatenz von 500 Millisekunden oder weniger.
[C-1-3] Das Öffnen eines Ausgabestreams mit
AAudioStreamBuilder_openStream()
MUSS weniger als 1.000 Millisekunden dauern.
Wenn in Geräteimplementierungen android.hardware.audio.output
deklariert wird, wird dringend empfohlen, die folgenden Anforderungen zu erfüllen oder zu übertreffen:
- [C-SR-1] Kalte Ausgabelatenz von maximal 100 Millisekunden über den Sprecherdatenpfad.
- [C-SR-2] Die Tonwahl-Latenz beträgt maximal 80 Millisekunden.
- [C-SR-4] Der von AudioTrack.getTimestamp und
AAudioStream_getTimestamp
zurückgegebene Ausgabezeitstempel ist auf +/- 1 ms genau.
Neue Anforderungen erstellen
- [C-SR-4] Die berechneten Umlauflatenzen, die auf den von
AAudioStream_getTimestamp
zurückgegebenen Eingabe- und Ausgabezeitstempeln basieren, werden UNBEDINGT empfohlen, innerhalb von 30 ms der gemessenen Umlauflatenz fürAAUDIO_PERFORMANCE_MODE_NONE
undAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
für Lautsprecher sowie kabelgebundene und kabellose Headsets zu liegen.
Neue Anforderungen beenden
Wenn Geräteimplementierungen die oben genannten Anforderungen nach der Erstkalibrierung bei Verwendung der AAudio Native Audio API für kontinuierliche und kalte Ausgabelatenz für mindestens ein unterstütztes Audioausgabegerät erfüllen, gilt Folgendes:
- [C-SR-5] EMPFOHLEN, Audio mit niedriger Latenz zu melden, indem das Funktions-Flag
android.hardware.audio.low_latency
deklariert wird. - [C-SR-6] EMPFOHLEN, die Anforderungen an Audio mit niedriger Latenz über die AAudio API zu erfüllen.
- [C-SR-7] EMPFOHLEN, dass bei Streams, die
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
vonAAudioStream_getPerformanceMode()
zurückgeben, der vonAAudioStream_getFramesPerBurst()
zurückgegebene Wert kleiner oder gleich dem Wert ist, der vonandroid.media.AudioManager.getProperty(String)
für den AttributschlüsselAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
zurückgegeben wird.
Wenn Geräteimplementierungen die Anforderungen für Audio mit niedriger Latenz über die AAudio Native Audio API nicht erfüllen, geschieht Folgendes:
- [C-2-1] DÜRFEN KEINE Unterstützung für Audio mit niedriger Latenz melden.
Wenn Geräteimplementierungen android.hardware.microphone
enthalten, MÜSSEN die folgenden Anforderungen für die Audioeingabe erfüllt werden:
- [C-3-1] Begrenzen Sie den Fehler in Eingabezeitstempeln, wie von AudioRecord.getTimestamp oder
AAudioStream_getTimestamp
zurückgegeben, auf +/- 2 ms. "Fehler" bedeutet hier die Abweichung vom richtigen Wert. - [C-3-2] Kalte Eingabe-Latenz von 500 Millisekunden oder weniger.
- [C-3-3] Das Öffnen eines Eingabestreams mit
AAudioStreamBuilder_openStream()
MUSS weniger als 1.000 Millisekunden dauern.
Wenn Geräteimplementierungen android.hardware.microphone
enthalten, wird dringend empfohlen, die folgenden Anforderungen an die Audioeingabe zu erfüllen:
[C-SR-8] Kalteingabelatenz von maximal 100 Millisekunden über den Mikrofondatenpfad.
[C-SR-11] Begrenzen Sie den Fehler bei Eingabezeitstempeln, wie von AudioRecord.getTimestamp oder
AAudioStream_getTimestamp
zurückgegeben, auf +/- 1 ms.
Wenn in Geräteimplementierungen android.hardware.audio.output
und android.hardware.microphone
deklariert sind, gilt Folgendes:
- [C-SR-12] Es wird dringend empfohlen, für mindestens einen unterstützten Pfad eine durchschnittliche Continuous Round-Trip-Latenz von 50 Millisekunden oder weniger über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 10 ms zu verwenden.
5.7. Netzwerkprotokolle
Geräteimplementierungen MÜSSEN die Mediennetzwerkprotokolle für die Audio- und Videowiedergabe unterstützen, wie in der Android SDK-Dokumentation angegeben.
Für jeden Codec und jedes Containerformat, das von einer Geräteimplementierung unterstützt werden muss, gilt für die Geräteimplementierung Folgendes:
[C-1-1] MUSS diesen Codec oder Container über HTTP und HTTPS unterstützen.
[C-1-2] MÜSSEN die entsprechenden Mediensegmentformate unterstützen, wie in der Tabelle mit den Mediensegmentformaten unten im HTTP-Live-Streaming-Entwurfsprotokoll, Version 7 gezeigt.
[C-1-3] MUSS die entsprechenden RTSP-Nutzlastformate unterstützen, wie in der folgenden RTSP-Tabelle dargestellt. Ausnahmen finden Sie in den Fußnoten der Tabelle in Abschnitt 5.1.
Formate für Mediensegmente
Segmentformate | Referenz(en) | Codec-Unterstützung erforderlich |
---|---|---|
MPEG-2-Transportstrom | ISO 13818 |
Video-Codecs:
und MPEG-2. Audio-Codecs:
|
AAC mit ADTS-Framing und ID3-Tags | ISO 13818-7 | Weitere Informationen zu AAC und ihren Varianten finden Sie in Abschnitt 5.1.1 . |
WebVTT | WebVTT |
RTSP (RTP, SDP)
Profilname | Referenz(en) | Codec-Unterstützung erforderlich |
---|---|---|
H264-AVC | RFC 6184 | Weitere Informationen zu H264 AVC finden Sie in Abschnitt 5.1.8. |
MP4A-LATM | RFC 6416 | Weitere Informationen zu AAC und ihren Varianten finden Sie in Abschnitt 5.1.3. |
H263–1998 |
RFC 3551 RFC 4629 RFC 2190 |
Weitere Informationen zu H263 finden Sie in Abschnitt 5.1.8. |
H263–2000 | RFC 4629 | Weitere Informationen zu H263 finden Sie in Abschnitt 5.1.8. |
Logo: AMR | RFC 4867 | Weitere Informationen zu AMR-NB finden Sie in Abschnitt 5.1.3. |
AMR-WB | RFC 4867 | Weitere Informationen zu AMR-WB finden Sie in Abschnitt 5.1.3. |
MP4V-ES | RFC 6416 | Weitere Informationen zu MPEG-4 SP finden Sie in Abschnitt 5.1.8 |
MPEG4-generisch | RFC 3640 | Weitere Informationen zu AAC und ihren Varianten finden Sie in Abschnitt 5.1.3. |
MP2T | RFC 2250 | Weitere Informationen findest du im Abschnitt MPEG-2 Transport Stream unter "HTTP Live Streaming" |
5.8. Sichere Medien
Wenn Geräteimplementierungen eine sichere Videoausgabe und sichere Oberflächen unterstützen, geschieht Folgendes:
- [C-1-1] MÜSSEN die Unterstützung für
Display.FLAG_SECURE
erklären.
Wenn in Geräteimplementierungen die Unterstützung für Display.FLAG_SECURE
deklariert und das kabellose Anzeigeprotokoll unterstützt wird, gilt Folgendes:
- [C-2-1] MÜSSEN die Verbindung für die über WLAN-Protokolle wie Miracast verbundenen Bildschirme mit einem kryptografisch starken Mechanismus wie HDCP 2.x oder höher sichern.
Wenn in Geräteimplementierungen die Unterstützung von Display.FLAG_SECURE
deklariert wird und kabelgebundene externe Bildschirme unterstützt werden, gilt Folgendes:
- [C-3-1] MUSS HDCP 1.2 oder höher für alle externen Bildschirme unterstützen, die über einen vom Nutzer zugänglichen kabelgebundenen Port verbunden werden.
5.9. MIDI (Musical Instrument Digital Interface)
Wenn Geräteimplementierungen die Unterstützung des Features android.software.midi
über die Klasse android.content.pm.PackageManager
melden, geschieht Folgendes:
[C-1-1] MÜSSEN MIDI über alle MIDI-fähigen Hardwaretransporte unterstützen, für die sie generische Nicht-MIDI-Verbindungen bereitstellen. Dazu gehören:
- USB-Hostmodus, Abschnitt 7.7
- MIDI over Bluetooth LE in zentraler Rolle, Abschnitt 7.4.3
[C-1-2] MÜSSEN den App-übergreifenden MIDI-Softwaretransport (virtuelle MIDI-Geräte) unterstützen.
[C-1-3] MÜSSEN libamidi.so (native MIDI-Unterstützung) enthalten
SOLLTEN MIDI-over-USB-Peripheriemodus-Modus unterstützen, Abschnitt 7.7.
5.10. Professionelles Audio
Wenn Geräteimplementierungen die Unterstützung der Funktion android.hardware.audio.pro
über die Klasse android.content.pm.PackageManager melden, geschieht Folgendes:
- [C-1-1] MÜSSEN die Unterstützung für Funktion
android.hardware.audio.low_latency
melden. - [C-1-2] MÜSSEN über mindestens einen unterstützten Pfad eine kontinuierliche Umlauf-Audiolatenz haben, wie in Abschnitt 5.6 Audiolatenz von 25 Millisekunden oder weniger definiert.
- [C-1-3] MUSS einen oder mehrere USB-Ports haben, die den USB-Hostmodus und den USB-Peripheriemodus unterstützen.
- [C-1-4] MÜSSEN die Unterstützung für Funktion
android.software.midi
melden. - [C-1-5] MÜSSEN die Latenzen und USB-Audioanforderungen über die AAudio Native Audio API und
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
erfüllen. - [C-1-6] MUSS eine Latenz für die kalte Ausgabe von 200 Millisekunden oder weniger haben.
- [C-1-7] MÜSSEN eine Kalteingabelatenz von maximal 200 Millisekunden haben.
[C-1-8] MUSS eine durchschnittliche Tap-to-Tone-Latenz von 80 Millisekunden oder weniger bei mindestens 5 Messungen über dem Datenpfad zwischen Lautsprecher und Mikrofon haben.
[C-SR-1] Es wird dringend empfohlen, Latenzen wie in Abschnitt 5.6 Audiolatenz von 20 Millisekunden oder weniger bei 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden über den Weg vom Lautsprecher zum Mikrofon zu erreichen.
[C-SR-2] wird dringend empfohlen, die Pro Audio-Anforderungen für kontinuierliche Audiolatenz, Cold-Input-Latenz und Kaltausgabelatenz sowie USB-Audioanforderungen zu erfüllen, wenn die AAudio Native Audio API über den MMAP-Pfad verwendet wird.
[C-SR-3] wird dringend empfohlen, bei aktiver Audiowiedergabe und schwankender CPU-Auslastung eine konstante CPU-Leistung zu bieten. Dies sollte mit der Android-App SynthMark getestet werden. SynthMark verwendet einen Software-Synthesizer, der auf einem simulierten Audio-Framework ausgeführt wird und die Systemleistung misst. Eine Erläuterung der Benchmarks finden Sie in der SynthMark-Dokumentation. Die SynthMark-Anwendung muss mit der Option „Automatischer Test“ ausgeführt werden und folgende Ergebnisse erzielen:
- Stimmmarke.90 >= 32 Stimmen
- Latenzmark.Fixed.little <= 15 ms
- Latenzmark.dynamic.little <= 50 ms
SOLLTEN die Ungenauigkeit der Audiouhr und die Abweichung gegenüber der Standardzeit minimieren.
SOLLTEN Sie die Abweichung des Audiotakts relativ zur CPU-
CLOCK_MONOTONIC
minimieren, wenn beide aktiv sind.SOLLTEN die Audiolatenz über geräteinterne Transducer minimieren.
SOLLTEN die Audiolatenz im Vergleich zu digitalen USB-Audioquellen minimieren.
SOLLTEN die Messungen der Audiolatenz für alle Pfade dokumentieren.
SOLLTEN Jitter bei den Callback-Eingabezeiten für den Abschluss des Audiopuffers minimieren, da sich dies auf den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback auswirkt.
SOLLTEN bei normaler Nutzung mit der gemeldeten Latenz keine Audiostörungen auftreten.
SOLLTEN keinen Unterschied bei der kanalübergreifenden Latenz haben.
SOLLTEN die durchschnittliche MIDI-Latenz für alle Transporte minimieren.
SOLLTEN die MIDI-Latenzvariabilität unter Last (Jitter) bei allen Transporten minimieren.
SOLLTEN für alle Transporte genaue MIDI-Zeitstempel angeben.
SOLLTEN Rauschen des Audiosignals über Aufkleber auf dem Gerät minimieren, einschließlich des Zeitraums unmittelbar nach dem Kaltstart.
SOLLTEN keine Audiotaktdifferenz zwischen den Ein- und Ausgabeseiten der entsprechenden Endpunkte vorliegen, wenn beide aktiv sind. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher auf dem Gerät oder der Ein- und Ausgang des Audioanschlusses.
SOLLTEN Callbacks zum Abschluss des Audiopuffers für die Ein- und Ausgabeseiten der entsprechenden Endpunkte im selben Thread verarbeiten, wenn beide aktiv sind. Der Ausgabe-Callback sollte unmittelbar nach der Rückgabe des Eingabe-Callbacks eingegeben werden. Wenn es nicht möglich ist, die Callbacks im selben Thread zu verarbeiten, geben Sie den Ausgabe-Callback kurz nach der Eingabe des Eingabe-Callbacks ein, damit die Anwendung ein einheitliches Timing der Ein- und Ausgabeseiten hat.
SOLLTEN Sie den Phasenunterschied zwischen der HAL-Audiozwischenspeicherung für die Ein- und Ausgabeseiten der entsprechenden Endpunkte minimieren.
SOLLTEN die Berührungslatenz minimieren.
SOLLTEN Sie die Schwankungen der Berührungslatenz unter Last (Jitter) minimieren.
Wenn Geräteimplementierungen alle oben genannten Anforderungen erfüllen, gilt Folgendes:
- [C-SR-4] WIRD DRINGEND empfohlen, die Unterstützung des Features
android.hardware.audio.pro
über die Klasseandroid.content.pm.PackageManager
zu melden.
Wenn Geräte eine 3,5-mm-Audiobuchse mit 4 Kabeln enthalten, ist Folgendes zu beachten:
[C-2-1] MUSS bei 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden über den Audioanschlusspfad mit einem Audio-Loopback-Dongle eine durchschnittliche Continuous Round-Trip-Audiolatenz haben, wie in Abschnitt 5.6 Audiolatenz definiert. Sie darf maximal 20 Millisekunden betragen.
[C-SR-5] EMPFOHLEN, den Abschnitt Spezifikationen für Mobilgeräte (Anschlusse) in der Spezifikation für kabelgebundene Audioheadsets (Version 1.1) einzuhalten.
Wenn Geräteimplementierungen keinen 3,5-mm-Audioanschluss mit 4 Kabeln enthalten und einen oder mehrere USB-Ports enthalten, die den USB-Hostmodus unterstützen, gilt Folgendes:
- [C-3-1] MÜSSEN die USB-Audioklasse implementieren.
- [C-3-2] MUSS eine durchschnittliche kontinuierliche Umlauf-Audiolatenz von 25 Millisekunden oder weniger bei 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden über dem USB-Hostmodus-Port bei Verwendung der USB-Audioklasse haben. (Dies kann mit einem USB-3,5-mm-Adapter und einem Audio-Loopback-Dongle oder über eine USB-Audioschnittstelle mit Patchkabeln gemessen werden, über die die Ein- und Ausgänge verbunden werden.)
- [C-SR-6] wird dringend empfohlen, die gleichzeitige E/A-Unterstützung für bis zu 8 Kanäle pro Richtung, eine Abtastrate von 96 kHz und eine Tiefe von 24 Bit oder 32 Bit zu unterstützen, wenn sie mit USB-Audioperipheriegeräten verwendet werden, die diese Anforderungen ebenfalls erfüllen.
- [C-SR-7] wird dringend empfohlen, diese Gruppe von Anforderungen zu erfüllen und dafür die AAudio API für natives Audio über den MMAP-Pfad zu verwenden.
Wenn Geräteimplementierungen einen HDMI-Port enthalten, ist Folgendes erforderlich:
- SOLLTEN die Ausgabe in Stereo und acht Kanälen bei 20-Bit- oder 24-Bit-Tiefe und 192 kHz ohne Bittiefenverlust oder -resampling in mindestens einer Konfiguration unterstützen.
5:11. Für unverarbeitet erfassen
Android unterstützt die Aufzeichnung von nicht verarbeiteten Audiodaten über die Audioquelle android.media.MediaRecorder.AudioSource.UNPROCESSED
. In OpenSL ES kann über die Eintragsvoreinstellung SL_ANDROID_RECORDING_PRESET_UNPROCESSED
darauf zugegriffen werden.
Wenn Geräteimplementierungen nicht verarbeitete Audioquellen unterstützen und für Drittanbieter-Apps verfügbar machen möchten, gilt Folgendes:
[C-1-1] MÜSSEN die Unterstützung über die
android.media.AudioManager
-Property PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED melden.[C-1-2] MUSS im mittleren Frequenzbereich annähernd flache Amplitude-gegen-Frequenz-Eigenschaften aufweisen, insbesondere ±10 dB von 100 Hz bis 7.000 Hz für jedes Mikrofon, das zur Aufzeichnung der unverarbeiteten Audioquelle verwendet wird.
[C-1-3] MUSS Amplitudenpegel im niedrigen Frequenzbereich aufweisen, insbesondere von ±20 dB von 5 Hz bis 100 Hz im Vergleich zum Mittenfrequenzbereich jedes einzelnen Mikrofons, das zur Aufzeichnung der unverarbeiteten Audioquelle verwendet wird.
[C-1-4] MÜSSEN Amplitudenpegel im hohen Frequenzbereich aufweisen, insbesondere von ±30 dB von 7.000 bis 22 kHz im Vergleich zum Mittenfrequenzbereich für jedes einzelne Mikrofon, das zur Aufzeichnung der unverarbeiteten Audioquelle verwendet wird.
[C-1-5] MÜSSEN die Empfindlichkeit der Audioeingabe so einstellen, dass eine sinusoidale 1.000-Hz-Tonquelle, die bei 94 dB Schalldruckpegel (SPL) abgespielt wird, für 16 Bit-Samples (oder -36 dB Full Scale für Gleitkomma-/Audio-Samples mit doppelter Genauigkeit) für jedes Mikrofon und jedes nicht verarbeitete Mikrofon einen RMS von 520 RMS liefert.
[C-1-6] MUSS für jedes Mikrofon, das zur Aufnahme der unverarbeiteten Audioquelle verwendet wird, ein Signal-Rausch-Verhältnis (SNR) von 60 dB oder höher haben. Der SNR-Wert wird als Differenz zwischen 94 dB SPL und dem äquivalenten Schalldruckpegel des Eigenrauschens gemessen, A-gewichtet.
[C-1-7] MÜSSEN bei jedem Mikrofon, das zur Aufnahme der unverarbeiteten Audioquelle verwendet wird, eine Gesamtoberschwingung (THD) von weniger als 1% für 1 kHz bei 90 dB SPL haben.
[C-1-8] DARF im Pfad keine andere Signalverarbeitung (z.B. automatische Verstärkungsregelung, Hochpassfilter oder Echounterdrückung) haben, mit Ausnahme eines Stufenmultiplikators, um das Level in den gewünschten Bereich zu bringen. Mit anderen Worten:
- [C-1-9] Wenn in der Architektur aus irgendeinem Grund Signalverarbeitung vorhanden ist, MUSS sie deaktiviert werden und dem Signalpfad praktisch keine Verzögerung oder zusätzliche Latenz einbringen.
- [C-1-10] Der Levelmultiplikator darf zwar im Pfad vorhanden sein, DARF aber KEINE Verzögerung oder Latenz in den Signalpfad einbringen.
Alle Schallpegelmessungen erfolgen direkt neben dem zu testenden Mikrofon. Bei mehreren Mikrofonkonfigurationen gelten diese Anforderungen für jedes Mikrofon.
Wenn in Geräteimplementierungen android.hardware.microphone
deklariert ist, aber keine unverarbeitete Audioquelle unterstützt wird, geschieht Folgendes:
- [C-2-1] MÜSSEN
null
für die API-MethodeAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
zurückgeben, um richtig anzuzeigen, dass keine Unterstützung vorhanden ist. - [C-SR-1] wird weiterhin UNBEDINGT empfohlen, so viele Anforderungen für den Signalpfad für die unverarbeitete Aufnahmequelle zu erfüllen.
5:12. HDR-Video
Android 13 unterstützt die in einem der folgenden Dokumente beschriebenen HDR-Technologien.
Pixelformat
Wenn ein Videodecoder bewirbt, dass COLOR_FormatYUVP010 unterstützt wird, dann gilt:
[C-1-1] MUSS das P010-Format für CPU-Lesezugriff unterstützen (ImageReader, MediaImage, ByteBuffer). In Android 13 wird P010 gelockert, um beliebige Schritte für die Y- und UV-Ebene zu ermöglichen.
[C-1-2] Der P010-Ausgabepuffer muss von der GPU abgetastet werden können (bei Zuweisung mit GPU_SAMPLING-Nutzung). Dies ermöglicht die GPU-Zusammensetzung und die benutzerdefinierte Tonzuordnung durch Apps.
Wenn ein Videodecoder COLOR_Format32bitABGR2101010 unterstützt, geschieht Folgendes:
- [C-2-1] MUSS das RGBA_1010102-Format für die Ausgabeoberfläche und CPU-lesbare Ausgabe (ByteBuffer-Ausgabe) unterstützen.
Wenn ein Video-Encoder die Unterstützung für COLOR_FormatYUVP010 bewirbt, geschieht Folgendes:
- [C-3-1] MUSS das P010-Format für die Eingabeoberfläche und die CPU-beschreibbare Eingabe (ImageWriter, MediaImage, ByteBuffer) unterstützen.
Wenn ein Video-Encoder die Unterstützung für COLOR_Format32bitABGR2101010 bewirbt, geschieht Folgendes:
- [C-4-1] MÜSSEN das RGBA_1010102-Format für die Eingabeoberfläche und die CPU-beschreibbare Eingabe (ImageWriter, ByteBuffer) unterstützen. Hinweis: Bei Encodern ist KEINE Konvertierung zwischen verschiedenen Übertragungskurven erforderlich.
Anforderungen für HDR-Aufnahmen
Geräteimplementierungen für alle Video-Encoder, die HDR-Profile unterstützen:
[C-5-1] DARF NICHT davon ausgehen, dass die HDR-Metadaten präzise sind. Der codierte Frame könnte beispielsweise Pixel haben, die über der maximalen Leuchtdichte der Spitzenwerte liegen, oder das Histogramm ist nicht repräsentativ für den Frame.
MÜSSEN dynamische HDR-Metadaten aggregieren, um geeignete statische HDR-Metadaten für codierte Streams zu generieren, und sie sollten am Ende jeder Codierungssitzung ausgegeben werden.
Wenn Geräteimplementierungen HDR-Aufnahmen mit den CamcorderProfile APIs unterstützen, gilt Folgendes:
[C-6-1] MUSS HDR-Aufnahmen auch über die Camera2 APIs unterstützen.
[C-6-2] MUSS für jede unterstützte HDR-Technologie mindestens einen hardwarebeschleunigten Videoencoder unterstützen.
[C-6-3] MUSS mindestens die HLG-Aufnahme unterstützen.
[C-6-4] MUSS das Schreiben der HDR-Metadaten (falls für die HDR-Technologie) in die aufgezeichnete Videodatei unterstützen. Bei AV1, HEVC und DolbyVision bedeutet dies, die Metadaten in den codierten Bitstream aufzunehmen.
[C-6-5] MUSS P010 und COLOR_FormatYUVP010 unterstützen.
[C-6-6] MUSS HDR-zu-SDR Tone Mapping im standardmäßigen hardwarebeschleunigten Decoder für das aufgenommene Profil unterstützen. Mit anderen Worten: Wenn ein Gerät HDR10+ HEVC aufnehmen kann, MUSS der Standard-HEVC-Decoder in der Lage sein, den aufgezeichneten Stream in SDR zu decodieren.
Anforderungen für die HDR-Bearbeitung
Wenn auf Geräten Videoencoder verwendet werden, die die HDR-Bearbeitung unterstützen, gilt Folgendes:
- SOLLTE beim Generieren der HDR-Metadaten nur minimale Latenz verwenden, und MÜSSEN mit Situationen umgehen, in denen Metadaten für einige Frames vorhanden sind und für andere nicht. Diese Metadaten SOLLTEN präzise sein (z. B. die tatsächliche Leuchtdichte von Spitzenwerten und das Histogramm des Frames).
Wenn die Geräteimplementierung Codecs enthält, die FEATURE_HdrEditing unterstützen, dann sind diese Codecs:
[C-7-1] MUSS mindestens ein HDR-Profil unterstützen.
[C-7-2] MUSS FEATURE_HdrEditing für alle von diesem Codec beworbenen HDR-Profile unterstützen. Mit anderen Worten, sie MÜSSEN auch die Erstellung von HDR-Metadaten unterstützen, wenn diese nicht für alle HDR-Profile unterstützt werden, die HDR-Metadaten verwenden.
[C-7-3] MUSS die folgenden Video-Encoder-Eingabeformate unterstützen, die das decodierte HDR-Signal vollständig erhalten:
- RGBA_1010102 (bereits in der Zielübertragungskurve) sowohl für die Eingabeoberfläche als auch für ByteBuffer und MÜSSEN die Unterstützung für COLOR_Format32bitABGR2101010 anbieten.
Wenn die Geräteimplementierung Codecs enthält, die FEATURE_HdrEditing unterstützen, dann gilt für das Gerät Folgendes:
- [C-7-4] MÜSSEN die Unterstützung für die Erweiterung EXT_YUV_target OpenGL anbieten.
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.
-
- [C-0-2] MUSS ADB gemäß der Dokumentation im Android SDK und den im AOSP bereitgestellten Shell-Befehlen 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. Ein Upgrade von Geräteimplementierungen von einer früheren Android-Version ohne dauerhaften Datenblock KANN von C-0-11 ausgenommen werden. - [C-0-3] DÜRFEN NICHT das Format oder den Inhalt von Gerätesystemereignissen (batterystats, diskstats, Fingerabdruck,graphicsstats, netstats,notification, procstats) ändern, die über den Befehl dumpsys protokolliert wurden.
- [C-0-10] MÜSSEN die folgenden Ereignisse ohne Auslassung aufgezeichnet und für den Shell-Befehl
cmd stats
und die System-API-KlasseStatsManager
zugänglich und verfügbar gemacht werden.- AktivitätsforegroundState geändert
- Anomalie erkannt
- AppBreadcrumbReported
- App-Absturz aufgetreten
- AppStartAuftreten
- Akkustand geändert
- Energiesparmodus geändert
- BleScanResultReceived
- BleScanStateGeändert
- Ladestatus geändert
- DeviceIdleModeStateGeändert
- Dienststatus im Vordergrund geändert
- GpsScanStateGeändert
- JobStateChanged (Jobstatus geändert)
- PluggedStateChanged
- ScheduledJobStateGeändert
- Bildschirmstatus geändert
- Synchronisierungsstatus geändert
- SystemElapsedRealtime
- UidProcessStateGeändert
- WakelockStateGeändert
- Wakeup-Alarm aufgetreten
- WifiLockStateGeändert
- WifiMulticastLockStateGeändert
- WifiScanStateGeändert
- [C-0-4] MÜSSEN der geräteseitige ADB-Daemon standardmäßig inaktiv sein. Außerdem muss es einen vom Nutzer zugänglichen Mechanismus zum Aktivieren der Android Debug Bridge geben.
- [C-0-5] MUSS sicheres ADB unterstützen. Android unterstützt Secure ADB. „Secure adb“ aktiviert ADB auf bekannten authentifizierten Hosts.
- [C-0-6] MÜSSEN einen Mechanismus bereitstellen, der die Verbindung von ADB von einem Hostcomputer ermöglicht. Im Detail:
Wenn Geräteimplementierungen ohne USB-Port den Peripheriemodus unterstützen, gilt Folgendes:
- [C-3-1] MÜSSEN ADB über ein lokales Netzwerk (z. B. Ethernet oder WLAN) implementieren.
- [C-3-2] MÜSSEN Treiber für Windows 7, 8 und 10 bereitstellen, damit Entwickler eine Verbindung zum Gerät über das ADB-Protokoll herstellen können.
Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet unterstützen, gilt Folgendes:
- [C-4-1] MÜSSEN in der Methode
AdbManager#isAdbWifiSupported()
den Werttrue
zurückgeben.
Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet unterstützen und mindestens eine Kamera umfassen, gilt Folgendes:
- [C-5-1] MUSS in der Methode
AdbManager#isAdbWifiQrSupported()
den Werttrue
zurückgeben.
- [C-0-2] MUSS ADB gemäß der Dokumentation im Android SDK und den im AOSP bereitgestellten Shell-Befehlen unterstützen, die von App-Entwicklern verwendet werden können, einschließlich
Dalvik Debug Monitor-Dienst (ddms)
- [C-0-7] MUSS alle im Android SDK dokumentierten ddms-Funktionen unterstützen. Da ddms ADB verwendet, sollte die Unterstützung für ddms standardmäßig inaktiv sein, MÜSSEN jedoch unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben aktiviert hat.
-
- [C-0-9] MUSS das Systrace-Tool unterstützen, wie im Android SDK dokumentiert. Systrace muss standardmäßig inaktiv sein und es muss einen vom Nutzer zugänglichen Mechanismus zum Aktivieren von Systrace geben.
-
- [C-SR-1] Es wird dringend empfohlen, dem Shell-Nutzer eine
/system/bin/perfetto
-Binärdatei bereitzustellen, wobei die cmdline der Perfetto-Dokumentation entspricht. - [C-SR-2] Für das Perfetto-Binärprogramm wird DRINGEND empfohlen, als Eingabe eine protobuf-Konfiguration zu akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [C-SR-3] Für das Perfetto-Binärprogramm wird UNBEDINGT empfohlen, einen protobuf-Trace als Ausgabe zu schreiben, der dem in der Perfetto-Dokumentation definierten Schema entspricht.
- [C-SR-4] Es wird dringend empfohlen, über das Perfetto-Binärprogramm mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitzustellen.
- [C-SR-1] Es wird dringend empfohlen, dem Shell-Nutzer eine
-
- [C-0-12] MÜSSEN ein
LMK_KILL_OCCURRED_FIELD_NUMBER
-Atom in dasstatsd-Log schreiben, wenn eine Anwendung durch den Low Memory Killer beendet wird.
- [C-0-12] MÜSSEN ein
Harnessmodus testen Wenn Geräteimplementierungen den Shell-Befehl
cmd testharness
unterstützen undcmd testharness enable
ausführen, geschieht Folgendes:- [C-2-1] MUSS
true
fürActivityManager.isRunningInUserTestHarness()
zurückgeben - [C-2-2] MÜSSEN den Test-Harnischmodus wie in der Dokumentation zum Test-Harnischmodus beschrieben implementieren.
- [C-2-1] MUSS
Informationen zur Arbeit mit GPUs
Geräteimplementierungen:
- [C-0-13] MÜSSEN den Shell-Befehl
dumpsys gpu --gpuwork
implementieren, um die aggregierten GPU-Arbeitsdaten anzuzeigen, die vom Kernel-Tracepointpower/gpu_work_period
zurückgegeben werden. Wenn der Tracepoint nicht unterstützt wird, müssen auch keine Daten angezeigt werden. Die AOSP-Implementierung istframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] MÜSSEN den Shell-Befehl
Wenn Geräteimplementierungen die Unterstützung von Vulkan 1.0 oder höher über die Funktions-Flags android.hardware.vulkan.version
melden, geschieht Folgendes:
- [C-1-1] MÜSSEN dem App-Entwickler eine Option zum Aktivieren/Deaktivieren von GPU-Debug-Ebenen anbieten.
- [C-1-2] MÜSSEN, wenn die GPU-Debug-Ebenen aktiviert sind, Ebenen in Bibliotheken aufzählen, die von externen Tools (d.h. nicht Teil der Plattform oder des Anwendungspakets) im Basisverzeichnis der Debug-fähigen Anwendungen bereitgestellt werden, 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.
Die Geräteimplementierungen MÜSSEN für eine einheitliche Nutzererfahrung bei den Entwickleroptionen MÜSSEN:
- [C-0-1] MUSS den Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS berücksichtigen, um auf die App-Entwicklung bezogene Einstellungen anzuzeigen. Die Upstream-Android-Implementierung blendet das Menü mit den Entwickleroptionen standardmäßig aus und ermöglicht es Nutzern, die Entwickleroptionen zu starten, nachdem sie sieben (7) Mal auf den Menüpunkt Einstellungen > Über das Gerät > Build-Nummer geklickt haben.
- [C-0-2] MÜSSEN die Entwickleroptionen standardmäßig ausblenden.
- [C-0-3] MÜSSEN einen klaren Mechanismus bereitstellen, durch den eine Drittanbieter-App keiner anderen bevorzugt behandelt wird, um Entwickleroptionen zu aktivieren. MÜSSEN ein öffentlich sichtbares Dokument oder eine öffentlich sichtbare Website zur Verfügung gestellt werden, in dem bzw. der beschrieben wird, wie die Entwickleroptionen aktiviert werden. Dieses Dokument oder diese Website MUSS in den Android SDK-Dokumenten verknüpfbar sein.
- SOLLTE eine visuelle Benachrichtigung für den Nutzer eingeblendet werden, wenn die Entwickleroptionen aktiviert sind und die Sicherheit des Nutzers von Bedeutung ist.
- KANN den Zugriff auf das Menü „Entwickleroptionen“ vorübergehend einschränken, indem das Menü visuell ausgeblendet oder deaktiviert wird, um Ablenkungen in Situationen zu vermeiden, in denen die Sicherheit des Nutzers von Belang ist.
7. Hardwarekompatibilität
Wenn ein Gerät eine bestimmte Hardwarekomponente mit einer entsprechenden API für Drittentwickler hat:
- [C-0-1] Die Geräteimplementierung MÜSSEN diese API wie in der Android SDK-Dokumentation beschrieben implementieren.
Wenn eine API im SDK mit einer Hardwarekomponente interagiert, die als optional ausgewiesen wird, und die Geräteimplementierung diese Komponente nicht besitzt, gilt Folgendes:
- [C-0-2] Die vollständigen Klassendefinitionen (wie im SDK dokumentiert) für die Komponenten-APIs MÜSSEN weiterhin angezeigt werden.
- [C-0-3] Das Verhalten der API MÜSSEN in angemessener Weise als managementfrei implementiert werden.
- [C-0-4] API-Methoden MÜSSEN Nullwerte zurückgeben, sofern dies gemäß 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 dokumentiert sind.
- [C-0-7] Geräteimplementierungen MÜSSEN konsistent genaue Informationen zur Hardwarekonfiguration über die Methoden
getSystemAvailableFeatures()
undhasSystemFeature(String)
in der Klasse android.content.pm.PackageManager für denselben Build-Fingerabdruck melden.
Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telefonie-API: Auch auf anderen Geräten als Smartphones müssen diese APIs als angemessene managementfreie Umgebung implementiert werden.
7.1. Display und Grafik
Android bietet Funktionen, mit denen App-Assets und UI-Layouts automatisch an das Gerät angepasst werden, um sicherzustellen, dass Anwendungen von Drittanbietern auf verschiedenen Hardwarekonfigurationen
einwandfrei funktionieren. Ein mit Android kompatibler Bildschirm ist ein Bildschirm, auf dem alle unter Android-Entwickler – Übersicht über die Bildschirmkompatibilität, in diesem Abschnitt (7.1) und den zugehörigen Unterabschnitten beschriebenen Verhaltensweisen und APIs sowie alle weiteren gerätetypspezifischen Verhaltensweisen implementiert werden, die in Abschnitt 2 dieser CDD beschrieben sind.
Auf den mit Android kompatiblen Displays, auf denen alle Android-kompatiblen Anwendungen von Drittanbietern ausgeführt werden können, MÜSSEN diese APIs und Verhaltensweisen korrekt implementiert werden, wie in diesem Abschnitt beschrieben.
Neue Anforderungen erstellen
Geräteimplementierungen:
- [C-0-1] MÜSSEN Drittanbieter-Apps standardmäßig nur auf Android-kompatiblen Bildschirmen rendern.
Neue Anforderungen beenden
Die Einheiten, auf die in den Anforderungen in diesem Abschnitt verwiesen wird, sind wie folgt definiert:
- physische diagonale Größe. Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Teils des Displays.
Punkt pro Zoll (dpi): Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1 Zolleingeschlossen werden, ausgedrückt als Pixel pro Zoll (ppi oder dpi). Wenn die ppi- und dpi-Werte fürdpiangegeben sind, müssen sowohl die horizontale als auch die vertikale DPI-Werte in den aufgeführten Bereich fallen.- Seitenverhältnis. Das Verhältnis der Pixel der längeren Seite zur kürzeren Seite des Bildschirms. Eine Anzeige mit 480 × 854 Pixeln wäre beispielsweise 854/480 = 1, 779, also ungefähr „16:9“.
- dichteunabhängige Pixel (dp):
Dieeine virtuelle Pixeleinheit, normalisiert auf eineBildschirmdichte von 160 dpieine Bildschirmdichte von 160. Für eine bestimmte Dichte d und eine Anzahl von Pixeln p wird die Anzahl der dichteunabhängigen Pixel dp so berechnet:pixels = dps * (density/160)dp = (160 / d) * p .
7.1.1 Bildschirmkonfiguration
7.1.1.1 Displaygröße und -form
Das Android-UI-Framework unterstützt eine Vielzahl verschiedener logischer Bildschirmlayoutgrößen und ermöglicht es Anwendungen, die Bildschirmlayoutgröße der aktuellen Konfiguration über Configuration.screenLayout
mit SCREENLAYOUT_SIZE_MASK
und Configuration.smallestScreenWidthDp
abzufragen.
Geräteimplementierungen:
[C-0-1] MÜSSEN die korrekte Layoutgröße für
Configuration.screenLayout
angeben, wie in der Android SDK-Dokumentation definiert. Insbesondere MÜSSEN bei Geräteimplementierungen die korrekten dp-Bildschirmabmessungen (logisch dichteunabhängige Pixel) wie unten gezeigt gemeldet werden:- Geräte, bei denen
Configuration.uiMode
auf einen anderen Wert als UI_MODE_TYPE_WATCH festgelegt ist und einesmall
-Größe für dieConfiguration.screenLayout
gemeldet wird, MÜSSEN mindestens 426 dp × 320 dp haben. - Geräte, die eine
normal
-Größe fürConfiguration.screenLayout
melden, MÜSSEN mindestens 480 dp × 320 dp haben. - Geräte, die eine
large
-Größe fürConfiguration.screenLayout
melden, MÜSSEN mindestens 640 dp × 480 dp haben. - Geräte, die eine
xlarge
-Größe fürConfiguration.screenLayout
melden, MÜSSEN mindestens 960 dp × 720 dp haben.
- Geräte, bei denen
[C-0-2] MÜSSEN die in der App angegebenen Unterstützung für Bildschirmgrößen durch das Attribut <
supports-screens
> in der Datei „AndroidManifest.xml“ korrekt berücksichtigt werden, wie in der Android SDK-Dokumentation beschrieben.KÖNNEN die Android-kompatiblen Bildschirme mit abgerundeten Ecken angezeigt werden.
Wenn Geräteimplementierungen Bildschirme unterstützen, die die Größenkonfiguration UI_MODE_TYPE_NORMAL
unterstützen und Android-kompatible
Bildschirme mit abgerundeten Ecken verwenden, um diese Bildschirme zu rendern, geschieht Folgendes:
[C-1-1] MÜSSEN für jedes dieser Displays mindestens eine der folgenden Anforderungen erfüllen:
- Der Radius der abgerundeten Ecken ist kleiner oder gleich 38 dp.
- Wenn in jeder Ecke der logischen Anzeige ein Feld mit
1518 dp ×1518 dp verankert ist, ist mindestens ein Pixel jedes Felds auf dem Bildschirm sichtbar.
SOLLTEN die Nutzer die Möglichkeit haben, in den Anzeigemodus mit den rechteckigen Ecken zu wechseln.
Neue Anforderungen erstellen
Wenn in Geräteimplementierungen nur die Tastaturkonfiguration NO_KEYS
möglich ist und die Unterstützung für die Konfiguration des UI-Modus UI_MODE_TYPE_NORMAL
gemeldet werden soll, geschieht Folgendes:
- [C-4-1] MÜSSEN eine Layoutgröße von mindestens 596 dp x 384 dp ohne Display-Aussparungen haben.
Neue Anforderungen beenden
Wenn in Geräteimplementierungen Android-kompatible Displays enthalten sind, die faltbar sind, oder ein klappbares Scharnier zwischen mehreren Displays enthalten, das bzw. die zum Rendern von Drittanbieter-Apps zur Verfügung stehen, gilt Folgendes:
- [C-2-1] MÜSSEN die neueste verfügbare stabile Version der extensions API oder die stabile Version der Sidecar API implementieren, die von der Window Manager Jetpack-Bibliothek verwendet werden soll.
Wenn Geräteimplementierungen ein oder mehrere Android-kompatible Bildschirme umfassen, die faltbar sind, oder ein faltbares Scharnier zwischen mehreren Anzeigebereichen haben und sich das Scharnier oder die Faltung durch ein Anwendungsfenster im Vollbildmodus kreuzt, gilt Folgendes:
- [C-3-1] MÜSSEN die Position, Begrenzungen und den Zustand des Scharniers melden oder der Anwendung über Erweiterungen oder Sidecar-APIs zur Verfügung stellen.
Weitere Informationen zur korrekten Implementierung der Sidecar- oder Erweiterungs-APIs finden Sie in der öffentlichen Dokumentation zu Window Manager Jetpack.
Neue Anforderungen erstellen
Wenn Geräteimplementierungen einen oder mehrere mit Android kompatible Bereiche, die faltbar sind, oder ein faltbares Scharnier zwischen mehreren Android-kompatiblen Displaybereichen umfassen und diese Bereiche für Apps verfügbar machen, gilt Folgendes:
- [C-4-1] MÜSSEN die korrekte Version der Window Manager Extensions API-Ebene implementieren, wie unter WindowManager Extensions beschrieben.
Neue Anforderungen beenden
7.1.1.2 Bildschirmseitenverhältnis
Das Seitenverhältnis des physischen Bildschirms für Android-kompatible Bildschirme gibt es zwar nicht eingeschränkt. Das Seitenverhältnis der logischen Anzeige, auf der Drittanbieter-Apps gerendert werden, muss jedoch aus den Höhen- und Breitenwerten abgeleitet werden, die über die view.Display
APIs und Configuration APIs gemeldet werden. MÜSSEN jedoch die folgenden Anforderungen erfüllen:
[C-0-1] Geräteimplementierungen, bei denen
Configuration.uiMode
aufUI_MODE_TYPE_NORMAL
gesetzt ist, MÜSSEN ein Seitenverhältnis von weniger als 1,86 (etwa 16:9) haben, es sei denn, die App erfüllt eine der folgenden Bedingungen:- Die App hat angegeben, dass sie über den Metadatenwert
android.max_aspect
ein größeres Bildschirmseitenverhältnis unterstützt. - Die App deklariert über das Attribut android:resizeableActivity, dass die Größe angepasst werden kann.
- 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.
- Die App hat angegeben, dass sie über den Metadatenwert
[C-0-3] Bei Geräteimplementierungen, bei denen
Configuration.uiMode
aufUI_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 logischer Standarddichten, um Anwendungsentwicklern die Ausrichtung auf Anwendungsressourcen zu erleichtern.
Geräteimplementierungen:
- [C-0-1]
Standardmäßig müssen Geräteimplementierungennureine der Android-Framework-Dichten melden, die aufDisplayMetrics
über dieDENSITY_DEVICE_STABLE
API aufgeführt sind. Dieser Wert muss ein statischer Wert für jedes physische Display sein.Dürfen sich niemals ändern.Das Gerät KANN jedoch eine anderebeliebige DichteDisplayMetrics.density
melden. Dies richtet sich nach den vom Nutzer vorgenommenen Änderungen an der Anzeigekonfiguration (z. B. der Anzeigegröße), die nach dem ersten Start festgelegt wurden.
- Bei Geräteimplementierungen MÜSSEN die standardmäßige Android-Framework-Dichte definiert werden, die numerisch der physischen Dichte des Bildschirms am nächsten kommt, es sei denn, diese logische Dichte führt dazu, dass die gemeldete Bildschirmgröße unter die unterstützte Mindestgröße fällt. Wenn die Dichte des Android-Standard-Frameworks, die numerisch der physischen Dichte am nächsten kommt, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 dp) ist, SOLLTEN die Geräteimplementierungen die nächstniedrigere Standard-Android-Framework-Dichte melden.
Neue Anforderungen erstellen
- SOLLTE die standardmäßige Android-Framework-Dichte definieren, die numerisch der physischen Dichte des Bildschirms entspricht, oder einen Wert, der den gleichen äquivalenten Winkel-Sichtfeldmessungen eines Handheld-Geräts zuordnen würde.
Neue Anforderungen beenden
Wenn Geräteimplementierungen
die Möglichkeit bieten, die Anzeigegröße des Geräts zu ändern, werden sie:
- [C-1-1]
Die Displaygröße DARF NICHT skaliert werdenDÜRFEN NICHT die Anzeige auf ein 1,5-Faches derDENSITY_DEVICE_STABLE
nativen Dichteskalieren oder eine effektive Mindestgröße von unter 320 dp haben (entspricht dem Ressourcen-Qualifier sw320dp), je nachdem, was zuerst eintritt. - [C-1-2]
Die Anzeigegröße DARF NICHT skaliert werdenDürfen die Anzeige NICHT auf weniger als das 0,85-Fache derDENSITY_DEVICE_STABLE
nativen Dichteskaliert werden. - Um eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen zu gewährleisten, wird EMPFOHLEN, die folgende Skalierung der nativen Displayoptionen bereitzustellen (unter Einhaltung der oben angegebenen Limits):
- Klein: 0,85x
- Standardeinstellung: 1x (Skalierung für native Displayanzeige)
- Groß: 1,15x
- Größer: 1,3x
- Größte 1,45x
7.1.2 Messwerte anzeigen
Wenn Geräteimplementierungen die Android-kompatiblen Bildschirme oder die Videoausgabe auf die Android-kompatiblen Bildschirme umfassen, gilt Folgendes:
- [C-1-1] MÜSSEN korrekte Werte für alle Android-kompatiblen Displaymesswerte melden, die in der
android.util.DisplayMetrics
API definiert sind.
Wenn Geräteimplementierungen keinen eingebetteten Bildschirm oder keine Videoausgabe enthalten, geschieht Folgendes:
- [C-2-1] MÜSSEN korrekte Werte des Android-kompatiblen Bildschirms melden, wie in der
android.util.DisplayMetrics
API für den emulierten Standardwertview.Display
definiert.
7.1.3 Displayausrichtung
Geräteimplementierungen:
- [C-0-1] MÜSSEN angeben, welche Bildschirmausrichtungen sie unterstützen (
android.hardware.screen.portrait
und/oderandroid.hardware.screen.landscape
) und mindestens eine unterstützte Ausrichtung angeben. Beispielsweise sollte ein Gerät mit einer festen Ausrichtung im Querformat, wie ein Fernseher oder Laptop, nurandroid.hardware.screen.landscape
melden. - [C-0-2] MÜSSEN bei Abfragen über
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
oder andere APIs den richtigen Wert für die aktuelle Ausrichtung des Geräts angeben.
Wenn Geräteimplementierungen beide Bildschirmausrichtungen unterstützen, gilt Folgendes:
- [C-1-1] MUSS die dynamische Ausrichtung von Anwendungen im Hoch- oder Querformat unterstützen. Das heißt, das Gerät muss die Anfrage der Anwendung für eine bestimmte Bildschirmausrichtung berücksichtigen.
- [C-1-2] DÜRFEN die gemeldete Bildschirmgröße oder -dichte beim Ändern der Ausrichtung NICHT ändern.
- Sie können als Standardeinstellung das Hoch- oder Querformat auswählen.
7.1.4 2D- und 3D-Grafikbeschleunigung
7.1.4.1 OpenGL ES
Geräteimplementierungen:
- [C-0-1] MÜSSEN die unterstützten OpenGL ES-Versionen (1.1, 2.0, 3.0, 3.1, 3.2) über die verwalteten APIs (z. B. über die Methode
GLES10.getString()
) und die nativen APIs korrekt identifizieren. - [C-0-2] MÜSSEN die Unterstützung für alle entsprechenden verwalteten APIs und nativen APIs für alle OpenGL ES-Versionen angeben, die unterstützt werden sollen.
Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:
- [C-1-1] MUSS sowohl OpenGL ES 1.1 als auch OpenGL 2.0 unterstützen, wie in der Android SDK-Dokumentation beschrieben.
- [C-SR-1] Wir empfehlen dringend, OpenGL ES 3.1 zu unterstützen.
- SOLLTEN OpenGL ES 3.2 unterstützen.
Die OpenGL ES-dEQP-Tests sind in eine Reihe von Testlisten mit jeweils einem zugehörigen Datum und einer zugehörigen Versionsnummer unterteilt. Diese befinden sich in der Android-Quellstruktur unter external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
. Ein Gerät, das OpenGL ES auf einer selbst angegebenen Ebene unterstützt, bedeutet, dass es die dEQP-Tests in allen Testlisten von dieser und früheren Levels bestehen kann.
Wenn Geräteimplementierungen eine der OpenGL ES-Versionen unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN über die von OpenGL ES verwalteten APIs und nativen APIs alle anderen von ihnen implementierten OpenGL ES-Erweiterungen melden. Umgekehrt DARF NICHT Erweiterungsstrings gemeldet werden, die von ihnen nicht unterstützt werden.
- [C-2-2] MUSS die Erweiterungen
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
,EGL_ANDROID_recordable
undEGL_ANDROID_GLES_layers
unterstützen. - [C-2-3] MÜSSEN die höchste Version der OpenGL ES-dEQP-Tests über das Funktions-Flag
android.software.opengles.deqp.level
melden. - [C-2-4] MUSS mindestens Version 132383489 (ab 1. März 2020) unterstützen, wie im Funktions-Flag
android.software.opengles.deqp.level
angegeben. - [C-2-5] MÜSSEN alle OpenGL ES-dEQP-Tests in den Testlisten zwischen Version 132383489 und der im Funktions-Flag
android.software.opengles.deqp.level
angegebenen Version für jede unterstützte OpenGL ES-Version bestehen. - [C-SR-2] wird dringend empfohlen, die Erweiterungen
EGL_KHR_partial_update
undOES_EGL_image_external
zu unterstützen. SOLLTEN mithilfe der Methode
getString()
alle unterstützten Texturkomprimierungsformate, die in der Regel anbieterspezifisch sind, korrekt melden.SOLLTEN die Erweiterungen
EGL_IMG_context_priority
undEGL_EXT_protected_content
unterstützen.
Wenn in Geräteimplementierungen OpenGL ES 3.0, 3.1 oder 3.2 unterstützt werden, gilt Folgendes:
- [C-3-1] MÜSSEN die entsprechenden Funktionssymbole für diese Version zusätzlich zu den OpenGL ES 2.0-Funktionssymbolen in der libGLESv2.so-Bibliothek exportieren.
- [C-SR-3] wird dringend empfohlen, die Erweiterung
OES_EGL_image_external_essl3
zu unterstützen.
Wenn Geräteimplementierungen OpenGL ES 3.2 unterstützen, gilt Folgendes:
- [C-4-1] MUSS das gesamte OpenGL ES Android Extension Pack unterstützen.
Wenn Geräteimplementierungen das Android Extension Pack für OpenGL ES vollständig unterstützen, gilt Folgendes:
- [C-5-1] MUSS die Unterstützung mit dem Feature-Flag
android.hardware.opengles.aep
identifizieren.
Wenn Geräteimplementierungen die Erweiterung EGL_KHR_mutable_render_buffer
unterstützen, geschieht 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 Aufwand für leistungsstarke 3D-Grafiken.
Wenn Geräteimplementierungen OpenGL ES 3.1 unterstützen, gilt Folgendes:
- [C-SR-1] wird dringend empfohlen, Support für Vulkan 1.3 bereitzustellen.
- [C-4-1] DARF KEINE Vulkan-Variante unterstützen (d.h. der Variantenteil der Vulkan-Kernversion MUSS Null sein).
Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:
- [C-SR-2] wird dringend empfohlen, Support für Vulkan 1.3 bereitzustellen.
Die Vulkan-dEQP-Tests sind in eine Reihe von Testlisten mit jeweils einem zugehörigen Datum und einer zugehörigen Version partitioniert. Diese befinden sich in der Android-Quellstruktur unter external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
. Ein Gerät, das Vulkan auf einer selbst angegebenen Ebene unterstützt, bedeutet, dass es die dEQP-Tests in allen Testlisten von dieser und früheren Levels bestehen kann.
Wenn Geräteimplementierungen Vulkan 1.0 oder höher unterstützen, gilt Folgendes:
- [C-1-1] MUSS den richtigen Ganzzahlwert mit den Feature-Flags
android.hardware.vulkan.level
undandroid.hardware.vulkan.version
melden. - [C-1-2] MUSS mindestens einen
VkPhysicalDevice
für die Vulkan-APIvkEnumeratePhysicalDevices()
angeben. - [C-1-3] MÜSSEN die Vulkan 1.1 APIs von
Vulkan 1.0für jede aufgelisteteVkPhysicalDevice
vollständig implementieren. - [C-1-4] MÜSSEN Ebenen in nativen Bibliotheken mit dem Namen
libVkLayer*.so
im Bibliotheksverzeichnis des Anwendungspakets über die nativen Vulkan-APIsvkEnumerateInstanceLayerProperties()
undvkEnumerateDeviceLayerProperties()
aufzählen. - [C-1-5] DARF KEINE Layers aufzählen, die von Bibliotheken außerhalb des Anwendungspakets bereitgestellt werden, und keine anderen Möglichkeiten zum Tracing oder Abfangen der Vulkan API bieten, es sei denn, für die Anwendung ist das Attribut
android:debuggable
auftrue
oder die Metadatencom.android.graphics.injectLayers.enable
auftrue
gesetzt. - [C-1-6] MÜSSEN alle Erweiterungsstrings melden, die von ihnen über die nativen Vulkan-APIs unterstützt werden. Umgekehrt DÜRFEN KEINE Erweiterungsstrings melden, die von ihnen nicht korrekt unterstützt werden.
- [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 höchste Version der unterstützten Vulkan-dEQP-Tests über das Funktions-Flag
android.software.vulkan.deqp.level
melden. - [C-1-9] MUSS mindestens Version
132317953
(ab 1. März 2019) unterstützen, wie im Funktions-Flagandroid.software.vulkan.deqp.level
angegeben. - [C-1-10] MÜSSEN alle Vulkan-dEQP-Tests in den Testlisten zwischen Version
132317953
und der im Funktions-Flagandroid.software.vulkan.deqp.level
angegebenen Version bestehen. - [C-1-11] DARF NICHT die Unterstützung für die Erweiterungen VK_KHR_video_queue, VK_KHR_video_decode_queue oder VK_KHR_video_encode_queue aufzählen.
- [C-SR-3] wird dringend empfohlen, die Erweiterungen
VK_KHR_driver_properties
undVK_GOOGLE_display_timing
zu unterstützen.
- SOLLTEN
VkPhysicalDeviceProtectedMemoryFeatures
undVK_EXT_global_priority
unterstützen.
- [C-1-12] DARF NICHT die Unterstützung für die Erweiterung „VK_KHR_performance_query“ aufzählen.
Neue Anforderungen erstellen
- [C-1-13] MUSS die Anforderungen des Android Baseline-Profils 2021 erfüllen.
Neue Anforderungen beenden
- [C-SR-4] WIRD UNBEDINGT EMPFOHLEN, die Anforderungen des Android Baseline-Profils 2022 zu erfüllen.
Neue Anforderungen erstellen
[C-SR-5] wird dringend empfohlen,
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
undVK_EXT_global_priority
zu unterstützen.[C-SR-6] wird dringend empfohlen,
SkiaVk
mit HWUI zu verwenden.
Neue Anforderungen beenden
Wenn Geräteimplementierungen Vulkan 1.0 nicht unterstützen, passiert Folgendes:
- [C-2-1] DÜRFEN KEINE Vulkan-Feature-Flags (z.B.
android.hardware.vulkan.level
,android.hardware.vulkan.version
) deklarieren. - [C-2-2] DARF KEINE
VkPhysicalDevice
für die native Vulkan APIvkEnumeratePhysicalDevices()
aufzählen.
Wenn Geräteimplementierungen Vulkan 1.1 unterstützen und eines der hier beschriebenen Vulkan-Funktions-Flags deklarieren, geschieht Folgendes:
- [C-3-1] MÜSSEN die Unterstützung für die externe Semaphore und Handle-Typen
SYNC_FD
sowie die ErweiterungVK_ANDROID_external_memory_android_hardware_buffer
anbieten.
Neue Anforderungen erstellen
- [C-SR-7] Es wird dringend empfohlen, die Erweiterung
VK_KHR_external_fence_fd
für Drittanbieteranwendungen verfügbar zu machen und der Anwendung zu ermöglichen, Fence-Nutzlasten in POSIX-Dateideskriptoren zu exportieren und aus POSIX-Dateideskriptoren zu importieren, wie hier beschrieben.
Neue Anforderungen beenden
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 Beschleunigung der 2D-Grafik
Android enthält einen Mechanismus, mit dem Apps angeben können, dass sie die Hardwarebeschleunigung für 2D-Grafiken auf App-, Aktivitäts-, Fenster- oder Ansichtsebene aktivieren möchten. Dazu wird das Manifest-Tag android:hardwareAccelerated oder direkte API-Aufrufe verwendet.
Geräteimplementierungen:
- [C-0-1] MÜSSEN die Hardwarebeschleunigung standardmäßig aktivieren und MÜSSEN die Hardwarebeschleunigung deaktivieren, wenn der Entwickler dies anfordert. Dazu muss android:hardwareAccelerated="false" festgelegt oder die Hardwarebeschleunigung direkt über die Android View APIs deaktiviert werden.
- [C-0-2] MUSS ein Verhalten aufweisen, das der Android SDK-Dokumentation zur Hardwarebeschleunigung entspricht.
Android enthält ein TextureView-Objekt, mit dem Entwickler hardwarebeschleunigte OpenGL ES-Texturen direkt als Renderingziele in einer UI-Hierarchie integrieren können.
Geräteimplementierungen:
- [C-0-3] MUSS die TextureView API unterstützen und ein konsistentes Verhalten mit der vorgelagerten Android-Implementierung zeigen.
7.1.4.5 Breitwinkel-Displays
Wenn Geräteimplementierungen eine Unterstützung für Breitbild-Displays über Configuration.isScreenWideColorGamut()
versprechen, gilt Folgendes:
- [C-1-1] MUSS ein farbkalibriertes Display haben.
- [C-1-2] MÜSSEN über ein Display verfügen, dessen Farbgamut den sRGB-Farbraum im CIE 1931-xyY-Raum vollständig abdeckt.
- [C-1-3] MÜSSEN über ein Display verfügen, dessen Gamut eine Fläche von mindestens 90% des DCI-P3 im CIE 1931-xyY-Raum ausmacht.
- [C-1-4] MUSS OpenGL ES 3.1 oder 3.2 unterstützen und ordnungsgemäß melden.
- [C-1-5] MUSS Support 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
undEGL_EXT_gl_colorspace_display_p3_passthrough
bewerben. - [C-SR-1] WIRD UNBEDINGT EMPFOHLEN,
GL_EXT_sRGB
zu unterstützen.
Umgekehrt gilt: Wenn Geräteimplementierungen keine Wide-Gamut-Displays unterstützen, kann das folgende Gründe haben:
- [C-2-1] SOLLTEN mindestens 100% des sRGB-Bereichs im CIE 1931-xyY-Bereich abdecken, wobei die Bildschirmfarbgamut nicht definiert ist.
7.1.5 Legacy-App-Kompatibilitätsmodus
Android gibt einen „Kompatibilitätsmodus“ an, in dem das Framework in einem Modus mit normaler Bildschirmgröße (320 dp Breite) arbeitet. Das hat den Vorteil, dass ältere Anwendungen nicht für ältere Versionen von Android entwickelt wurden und noch vor der Bildschirmgröße unabhängig waren.
7.1.6 Bildschirmtechnologie
Die Android-Plattform umfasst APIs, mit denen Anwendungen komplexe Grafiken auf einem Android-kompatiblen Bildschirm rendern können. Geräte MÜSSEN gemäß der Definition des Android SDK alle diese APIs unterstützen, sofern dies in diesem Dokument nicht ausdrücklich zulässig ist.
Alle mit Android kompatiblen Displays einer Geräteimplementierung:
- [C-0-1] MUSS 16-Bit-Farbgrafiken unterstützen können.
- SOLLTEN Bildschirme unterstützt werden, die 24-Bit-Farbgrafiken unterstützen.
- [C-0-2] MUSS Animationen rendern können.
- [C-0-3] MUSS ein Pixelseitenverhältnis (PAR) zwischen 0,9 und 1,15 haben. Das heißt, das Pixel-Seitenverhältnis MUSS nahe dem Quadrat (1,0) mit einer Toleranz von 10–15% liegen.
7.1.7 Sekundäre Displays
Android unterstützt sekundäre Android-kompatible Bildschirme, um Funktionen zum Teilen von Medien und Entwickler-APIs für den Zugriff auf externe Bildschirme zu aktivieren.
Wenn Geräteimplementierungen einen externen Bildschirm über eine kabelgebundene, kabellose oder eingebettete zusätzliche Bildschirmverbindung unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN den Systemdienst und die API
DisplayManager
wie in der Android SDK-Dokumentation beschrieben implementieren.
7.2. Eingabegeräte
Geräteimplementierungen:
- [C-0-1] MÜSSEN einen Eingabemechanismus wie einen Touchscreen oder eine Navigation ohne Touchscreen enthalten, um zwischen den UI-Elementen zu navigieren.
7.2.1 Tastatur
Wenn Geräteimplementierungen IME-Anwendungen (Input Method Editor) von Drittanbietern unterstützen, gilt Folgendes:
- [C-1-1] MUSS das Feature-Flag
android.software.input_methods
deklarieren. - [C-1-2] MUSS
Input Management Framework
vollständig implementieren - [C-1-3] MUSS eine vorinstallierte Softwaretastatur haben.
Geräteimplementierungen:
- [C-0-1] DÜRFEN KEINE Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard angegebenen Formate entspricht (QWERTY oder 12-Taste).
- SOLLTEN zusätzliche Implementierungen von Softtastaturen beinhalten.
- KANN eine Hardware-Tastatur enthalten.
7.2.2 Berührungslose Navigation
Android unterstützt das Steuerkreuz, den Trackball und das Rad als Mechanismen für die berührungslose Navigation.
Geräteimplementierungen:
- [C-0-1] MUSS den richtigen Wert für android.content.res.Configuration.navigation melden.
Wenn Geräteimplementierungen keine berührungslose Navigation haben, kann das folgende Gründe haben:
- [C-1-1] MÜSSEN einen angemessenen alternativen Benutzeroberflächenmechanismus für die Auswahl und Bearbeitung von Text bereitstellen, der mit Input Management Engines kompatibel ist. Die vorgelagerte Open-Source-Implementierung von Android enthält einen Auswahlmechanismus, der für Geräte geeignet ist, auf denen keine berührungslosen Navigationseingaben vorhanden sind.
7.2.3 Navigationstasten
Die Funktionen Home, Recents und Back, die in der Regel über eine Interaktion mit einer dedizierten physischen Taste oder einem bestimmten Teil des Touchscreens bereitgestellt werden, sind für das Android-Navigationsmodell und daher für Geräteimplementierungen unerlässlich:
- [C-0-1] MÜSSEN ein Nutzerangebot zum Starten installierter Apps mit einer Aktivität bieten, bei der
<intent-filter>
aufACTION=MAIN
undCATEGORY=LAUNCHER
oderCATEGORY=LEANBACK_LAUNCHER
für Fernsehgeräteimplementierungen festgelegt ist. Die Home-Funktion SOLLTE der Mechanismus für dieses Nutzerangebot sein. - SOLLTEN Schaltflächen für die Funktionen Recents und Zurück bereitstellen.
Wenn die Funktionen „Startbildschirm“, „Letzte“ und „Zurück“ verfügbar sind, geschieht Folgendes:
- [C-1-1] MUSS mit einer einzigen Aktion (z.B. Tippen, Doppelklick oder Geste) aufgerufen werden können, wenn eine davon zugänglich ist.
- [C-1-2] MÜSSEN eindeutig angeben, welche einzelne Aktion die jeweilige Funktion auslösen würde. Beispiele für solche Hinweise sind ein sichtbares Symbol auf der Schaltfläche, ein Softwaresymbol in der Navigationsleiste des Bildschirms oder die geführte Demo durch eine Schritt-für-Schritt-Demo.
Geräteimplementierungen:
[C-SR-1] wird dringend empfohlen, den Eingabemechanismus für die Menüfunktion nicht bereitzustellen, da sie seit Android 4.0 zugunsten der Aktionsleiste eingestellt wurde.
[C-SR-2] Es wird dringend empfohlen, alle Navigationsfunktionen als stornierbar bereitzustellen. „Abbrechen“ ist definiert als die Fähigkeit des Nutzers, zu verhindern, dass die Navigationsfunktion ausgeführt wird (z. B. nach Hause oder zurück), wenn das Wischen nicht über einen bestimmten Grenzwert hinausgeht.
Wenn Geräteimplementierungen die Menüfunktion bieten, geschieht Folgendes:
- [C-2-1] MÜSSEN die Dreipunkt-Menüschaltfläche für die Aktion anzeigen, wenn das Pop-up-Fenster für das Aktionsmenü nicht leer und die Aktionsleiste sichtbar ist.
- [C-2-2] DÜRFEN die Position des Aktions-Überlauf-Pop-ups, das angezeigt wird, indem Sie die Überlaufschaltfläche in der Aktionsleiste auswählen, NICHT ändern. Es KANN jedoch an einer veränderten Position auf dem Bildschirm gerendert werden, wenn es angezeigt wird, indem Sie die Menüfunktion auswählen.
Geräteimplementierungen, die die Menüfunktion nicht bereitstellen, müssen aus Gründen der Abwärtskompatibilität:
* [C-3-1] MÜSSEN die Menüfunktion für Anwendungen verfügbar machen, wenn targetSdkVersion
kleiner als 10 ist, entweder durch eine physische Taste, eine Softwaretaste oder Touch-Gesten. Diese Menüfunktion sollte zugänglich sein, sofern sie nicht zusammen mit anderen Navigationsfunktionen ausgeblendet wird.
Wenn Geräteimplementierungen die Unterstützungsfunktion bieten, geschieht Folgendes:
- [C-4-1] MÜSSEN die Assistentenfunktion mit einer einzigen Aktion (z.B. Tippen, Doppelklick oder Geste) zugänglich machen, wenn andere Navigationstasten verfügbar sind.
- [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, als vorgesehene Interaktion lange auf die START-Funktion zu drücken.
Wenn Geräteimplementierungen einen bestimmten Teil des Bildschirms zur Anzeige der Navigationstasten verwenden, geschieht Folgendes:
- [C-5-1] Die Navigationstasten MÜSSEN einen deutlich erkennbaren Teil des Bildschirms verwenden, der für Apps nicht verfügbar ist, und dürfen den für Apps verfügbaren Teil des Bildschirms NICHT verdecken oder anderweitig beeinträchtigen.
- [C-5-2] MÜSSEN Anwendungen einen Teil des Bildschirms zur Verfügung stellen, die die in Abschnitt 7.1.1 definierten Anforderungen erfüllen.
- [C-5-3] MÜSSEN die von der App über die API-Methode
View.setSystemUiVisibility()
festgelegten Flags berücksichtigen, damit dieser bestimmte Teil des Bildschirms (die Navigationsleiste) ordnungsgemäß verborgen ist, wie im SDK dokumentiert.
Wenn die Navigationsfunktion als bewegungsbasierte Aktion auf dem Bildschirm bereitgestellt wird:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
DÜRFEN nur verwendet werden, um den Bereich zur Gestenerkennung für "Zuhause" zu melden. - [C-6-2] Gesten, die innerhalb eines Ausschlussrechtecks beginnen, das von der Anwendung im Vordergrund über
View#setSystemGestureExclusionRects()
bereitgestellt wird, aber außerhalb vonWindowInsets#getMandatorySystemGestureInsets()
, dürfen NICHT von der Navigationsfunktion abgefangen werden, solange das Ausschlussrechteck innerhalb des maximalen Ausschlussbereichs zulässig ist, wie in der Dokumentation fürView#setSystemGestureExclusionRects()
angegeben. - [C-6-3] MÜSSEN an die Vordergrund-App ein
MotionEvent.ACTION_CANCEL
-Ereignis senden, sobald Berührungen für eine Systemgeste abgefangen werden, wenn zuvor einMotionEvent.ACTION_DOWN
-Ereignis an die App im Vordergrund gesendet wurde. - [C-6-4] MÜSSEN Nutzern die Möglichkeit bieten, zu einer Bedienung über Schaltflächen auf dem Bildschirm zu wechseln (z. B. in den Einstellungen).
- MÜSSEN die Startbildschirmfunktion durch Wischen vom unteren Rand der aktuellen Bildschirmausrichtung nach oben bereitstellen.
- SOLLTE die Funktion „Letzte Apps“ durch Wischen nach oben und Halten vor dem Loslassen aus demselben Bereich wie die Touch-Geste für „Startbildschirm“ bereitstellen.
- Gesten, die in
WindowInsets#getMandatorySystemGestureInsets()
beginnen, SOLLTEN NICHT von Ausschlussabfragen beeinflusst werden, die von der Anwendung im Vordergrund überView#setSystemGestureExclusionRects()
bereitgestellt werden.
Wenn am linken und rechten Rand der aktuellen Bildschirmausrichtung eine Navigationsfunktion verfügbar ist, gehen Sie so vor:
- [C-7-1] Die Navigationsfunktion MUSS „Zurück“ sein und muss in der aktuellen Bildschirmausrichtung vom linken und vom rechten Rand aus wischen.
- [C-7-2] Wenn sich am linken oder rechten Rand benutzerdefinierte wischbare Steuerfelder befinden, MÜSSEN sie im oberen Drittel des Bildschirms mit einem klaren, dauerhaften optischen Hinweis platziert werden, dass durch Ziehen die oben genannten Steuerfelder aufgerufen werden, d. h. nicht „Zurück“. Ein Steuerfeld KANN von einem Nutzer so konfiguriert werden, dass es unterhalb der oberen ein Drittel der Bildschirmränder landet. Das Steuerfeld DARF jedoch NICHT länger als ein Drittel der Ränder verwenden.
- [C-7-3] Wenn die Vordergrund-App entweder das Flag „View.SYSTEM_UI_FLAG_IMMERSIVE“, „View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY“, „WindowInsetsController.BEHAVIOR_DEFAULT“ oder „WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE“ hat, das sich im SDK wie „AUSWISCHEN“ verhalten muss, wie beim Wischen von den Kanten aus
- [C-7-4] Wenn für die App im Vordergrund entweder View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT oder WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE-Flags implementiert sind, müsst benutzerdefinierte System-Steuerfelder- oder Navigationsfelder ausgeblendet werden.
Wenn die Zurück-Navigationsfunktion verfügbar ist und der Nutzer die Zurück-Touch-Geste abbricht, passiert Folgendes:
- [C-8-1]
OnBackInvokedCallback.onBackCancelled()
MUSS aufgerufen werden. - [C-8-2]
OnBackInvokedCallback.onBackInvoked()
DARF NICHT aufgerufen werden. - [C-8-3] Das KEYCODE_BACK-Ereignis DARF NICHT gesendet werden.
Wenn die Funktion „Zurück“ zur Verfügung steht, für die Anwendung im Vordergrund aber KEIN OnBackInvokedCallback
registriert ist, dann:
- Das System SOLLTE eine Animation für die Anwendung im Vordergrund bereitstellen, die vorgibt, dass der Nutzer wie in AOSP angegeben zurückgeht.
Wenn Geräteimplementierungen die System-API setNavBarMode
unterstützen, damit jede System-App mit der Berechtigung android.permission.STATUS_BAR
den Navigationsleistenmodus festlegen kann, dann gilt:
- [C-9-1] MÜSSEN wie im AOSP-Code angegeben Unterstützung für kinderfreundliche Symbole oder die schaltflächenbasierte Navigation bieten.
7.2.4 Touchscreeneingabe
Android unterstützt verschiedene Zeigereingabesysteme wie Touchscreens, Touchpads und gefälschte Touch-Eingabegeräte. Implementierungen von Touchscreen-Geräten sind mit einem Display so verknüpft, dass der Nutzer den Eindruck hat, Elemente auf dem Bildschirm direkt zu manipulieren. Da der Nutzer den Bildschirm direkt berührt, benötigt das System keine zusätzlichen Angebote, um die manipulierten Objekte anzuzeigen.
Geräteimplementierungen:
- SOLLTE ein Zeigereingabesystem (Maus- oder Touch-Eingabesystem) haben.
- SOLLTEN vollständig unabhängig nachverfolgte Zeiger unterstützen.
Wenn Geräteimplementierungen einen Touchscreen (Single-Touch oder besser) auf einem primären mit Android kompatiblen Bildschirm umfassen, gilt Folgendes:
- [C-1-1] MÜSSEN
TOUCHSCREEN_FINGER
für das API-FeldConfiguration.touchscreen
melden. - [C-1-2] MÜSSEN die Funktions-Flags
android.hardware.touchscreen
undandroid.hardware.faketouch
melden.
Wenn Geräteimplementierungen einen Touchscreen umfassen, der mehrere Berührungen auf einem mit Android kompatiblen primären Bildschirm erfassen kann, gilt Folgendes:
- [C-2-1] MÜSSEN die entsprechenden Funktions-Flags
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
melden, die dem Typ des Touchscreens des Geräts entsprechen.
Wenn für Geräteimplementierungen ein externes Eingabegerät wie eine Maus oder ein Trackball (d.h., das den Bildschirm nicht direkt berühren) auf einem primären mit Android kompatiblen Bildschirm verwendet wird und die in Abschnitt 7.2.5 genannten Anforderungen an falsche Berührungen erfüllt sind, gilt Folgendes:
- [C-3-1] DÜRFEN KEINE Funktions-Flags melden, die mit
android.hardware.touchscreen
beginnen. - [C-3-2] MÜSSEN nur
android.hardware.faketouch
melden. - [C-3-3] MÜSSEN
TOUCHSCREEN_NOTOUCH
für das API-FeldConfiguration.touchscreen
melden.
7.2.5 Eingabe von gefälschten Berührungen
Die Fake-Touch-Benutzeroberfläche bietet ein Nutzereingabesystem, das einen Teil der Touchscreen-Funktionen annähert. Beispiel: Eine Maus oder Fernbedienung, die einen Bildschirmcursor annähert, eine Berührung hervorruft, der Nutzer jedoch zuerst die Maus oder den Fokus fokussieren und dann klicken muss. Verschiedene Eingabegeräte wie Maus, Touchpad, Gyroskop, Gyroskop, Joystick und Multi-Touch-Trackpad können gefälschte Berührungen unterstützen. Android umfasst die Funktion android.hardware.faketouch, die einem High-Fidelity-Eingabegerät ohne Touchscreen entspricht, z. B. einer Maus oder einem Touchpad, das die berührungsbasierte Eingabe angemessen emulieren kann (einschließlich der grundlegenden Unterstützung von Touch-Gesten) und darauf hinweist, dass das Gerät eine emulierte Teilmenge von Touchscreen-Funktionen unterstützt.
Wenn Geräteimplementierungen keinen Touchscreen haben, sondern ein anderes Zeigereingabesystem, das verfügbar gemacht werden soll, geschieht Folgendes:
- SOLLTEN die Unterstützung für das Funktions-Flag
android.hardware.faketouch
deklarieren.
Wenn in Geräteimplementierungen die Unterstützung von android.hardware.faketouch
deklariert wird, gilt Folgendes:
- [C-1-1] MÜSSEN die absolute X- und Y-Bildschirmposition der Zeigerposition melden und einen visuellen Zeiger auf dem Bildschirm anzeigen.
- [C-1-2] MÜSSEN das Touch-Ereignis mit dem Aktionscode melden, der die Statusänderung angibt, die auf dem nach unten oder oben auf dem Bildschirm laufenden Zeiger auftritt.
- [C-1-3] MUSS den Zeiger auf einem Objekt auf dem Bildschirm nach unten und oben unterstützen, damit Nutzer auf ein Objekt auf dem Bildschirm tippen können.
- [C-1-4] MUSS den Zeiger nach unten, den Zeiger nach oben, den Zeiger nach unten und dann den Zeiger nach oben an derselben Stelle eines Objekts auf dem Bildschirm innerhalb eines Zeitgrenzwerts unterstützen. So können Nutzer doppeltippen auf ein Objekt auf dem Bildschirm emulieren.
- [C-1-5] MÜSSEN den Mauszeiger auf einen beliebigen Punkt auf dem Bildschirm nach unten bewegen, den Zeiger zu einem beliebigen anderen beliebigen Punkt auf dem Bildschirm gefolgt von einem nach oben zeigenden Zeiger unterstützen, damit Nutzer eine Ziehbewegung emulieren können.
- [C-1-6] MÜSSEN Nutzer nach unten zeigen und Nutzern ermöglichen, das Objekt schnell an eine andere Position auf dem Bildschirm und dann nach oben zu bewegen, damit Nutzer ein Objekt auf dem Bildschirm verschieben können.
Wenn Geräteimplementierungen die Unterstützung von android.hardware.faketouch.multitouch.distinct
deklarieren, geschieht Folgendes:
- [C-2-1] MÜSSEN die Unterstützung für
android.hardware.faketouch
erklären. - [C-2-2] MUSS das eindeutige Tracking von zwei oder mehr unabhängigen Zeigereingaben unterstützen.
Wenn Geräteimplementierungen die Unterstützung von android.hardware.faketouch.multitouch.jazzhand
deklarieren, geschieht Folgendes:
- [C-3-1] MÜSSEN die Unterstützung für
android.hardware.faketouch
erklären. - [C-3-2] MUSS das separate Tracking von 5 oder mehr Zeigereingaben vollständig unabhängig unterstützen, d. h. das Erfassen einer Hand mit Fingern.
7.2.6 Unterstützung für Gamecontroller
7.2.6.1 Schaltflächenzuordnungen
Geräteimplementierungen:
- [C-1-1] MUSS HID-Ereignisse den entsprechenden
InputEvent
-Konstanten zuordnen können, wie in den folgenden Tabellen aufgeführt. Die vorgelagerte Android-Implementierung erfüllt diese Anforderung.
Wenn bei der Geräteimplementierung ein Controller eingebettet ist oder ein separater Controller beigefügt wird, damit alle in den folgenden Tabellen aufgeführten Ereignisse eingegeben werden können, gilt Folgendes:
- [C-2-1] MÜSSEN das Funktions-Flag
android.hardware.gamepad
deklarieren.
Schaltfläche | HID-Nutzung2 | Android-Taste |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_SCHALTFLÄCHE (96) |
B1 | 0x09 0x0002 | KEYCODE_SCHALTFLÄCHE (97) |
X1 | 0x09 0x0004 | KEYCODE_button_X (99) |
J1 | 0x09 0x0005 | KEYCODE_SCHALTFLÄCHE (100) |
Steuerkreuz oben1 Steuerkreuz unten1 |
0x01 0x00393 | AXIS_HAT_Y4 |
Steuerkreuz links1 Steuerkreuz rechts1 |
0x01 0x00393 | AXIS_HAT_X4 |
Taste auf der linken Schulter1 | 0x09 0x0007 | KEYCODE_button_L1 (102) |
Rechte Schultertaste1 | 0x09 0x0008 | KEYCODE_button_R1 (103) |
Mit linker Maustaste klicken1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
Mit der rechten Maustaste klicken1 | 0x09 0x000F | KEYCODE_button_THUMBR (107) |
Zurück1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
2 Die oben genannten HID-Nutzungen müssen innerhalb einer Game Pad-CA (0x01 0x0005) deklariert werden.
3 Diese Nutzung muss ein logisches Minimum von 0, ein logisches Maximum von 7, ein physisches Minimum von 0, ein physisches Maximum von 315, ein Einheiten in Grad und eine Berichtsgröße von 4 sein. Der logische Wert ist als Rotation im Uhrzeigersinn weg von der vertikalen Achse definiert. Der logische Wert 0 steht beispielsweise für keine Drehung und das Drücken der Aufwärtstaste, während der logische Wert 1 eine Drehung um 45 Grad und das Drücken der Nach-oben- und der Nach-links-Taste darstellt.
Analoge Steuerelemente1 | HID-Nutzung | Android-Taste |
---|---|---|
Linker Trigger | 0x02 0x00C5 | WASSERGRÖSSE |
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 |
7.2.7 Fernbedienung
Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.3.1.
7.3. Sensoren
Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittentwickler enthalten, MÜSSEN die Geräteimplementierung diese API wie in der Android SDK-Dokumentation und der Android Open Source-Dokumentation zu Sensoren beschrieben implementieren.
Geräteimplementierungen:
- [C-0-1] MUSS das Vorhandensein oder Fehlen von Sensoren gemäß der
android.content.pm.PackageManager
-Klasse korrekt melden. - [C-0-2] MUSS über
SensorManager.getSensorList()
und ähnliche Methoden eine genaue Liste der unterstützten Sensoren zurückgeben. - [C-0-3] MÜSSEN sich für alle anderen Sensor-APIs angemessen verhalten, z. B. indem
true
oderfalse
zurückgegeben werden, wenn Anwendungen versuchen, Listener zu registrieren, und keine Sensor-Listener aufrufen, wenn die entsprechenden Sensoren nicht vorhanden sind.
Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittentwickler enthalten, geschieht Folgendes:
- [C-1-1] MÜSSEN alle Sensormessungen unter Verwendung der relevanten internationalen Maßeinheitenwerte für jeden Sensortyp melden, wie in der Android SDK-Dokumentation definiert.
- [C-1-2] MÜSSEN Sensordaten mit einer maximalen Latenz von 100 Millisekunden + 2 * sample_time für einen Sensorstream mit einer maximalen angeforderten Latenz von 0 ms melden, wenn der Anwendungsprozessor aktiv ist. Diese Verzögerung umfasst keine Filterverzögerungen.
- [C-1-3] MÜSSEN die erste Sensorprobe innerhalb von 400 Millisekunden + 2 * sample_time des Sensors melden, der aktiviert wird. Eine Genauigkeit von 0 ist für diese Stichprobe akzeptabel.
- [C-1-4] Damit eine API, die in der Android SDK-Dokumentation als kontinuierlicher Sensor angegeben ist, MÜSSEN Geräteimplementierungen kontinuierlich regelmäßige Datenstichproben bereitstellen, die einen Jitter unter 3 % haben sollten, wobei der Jitter als Standardabweichung der Differenz der gemeldeten Zeitstempelwerte zwischen aufeinanderfolgenden Ereignissen definiert ist.
- [C-1-5] MUSS sicherstellen, dass der Sensorereignisstream NICHT verhindern DA darf, dass die CPU des Geräts in den Anhalten- oder Ruhemodus versetzt wird.
- [C-1-6] MÜSSEN die Ereigniszeit in Nanosekunden angeben, wie in der Android SDK-Dokumentation definiert. Diese stellen den Zeitpunkt dar, zu dem das Ereignis stattgefunden hat und mit der SystemClock.elapsedRealtimeNano()-Uhr synchronisiert wurde.
- [C-SR-1] Es wird dringend empfohlen, einen Zeitstempel-Synchronisierungsfehler unter 100 Millisekunden und einen Zeitstempel-Synchronisierungsfehler unter einer Millisekunde zu haben.
- Wenn mehrere Sensoren aktiviert sind, SOLLTE die Stromaufnahme NICHT die Summe der vom einzelnen Sensor gemeldeten Stromverbrauch überschreiten.
Die Liste oben ist nicht vollständig. Das dokumentierte Verhalten des Android SDK und der Open-Source-Dokumentation von Android auf Sensoren ist verbindlich.
Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittentwickler enthalten, geschieht Folgendes:
- [C-1-6] MÜSSEN für alle Sensoren eine Auflösung ungleich null festlegen und den Wert über die API-Methode
Sensor.getResolution()
melden.
Einige Sensortypen sind zusammengesetzt, d. h., sie können aus Daten abgeleitet werden, die von einem oder mehreren anderen Sensoren bereitgestellt werden. (Beispiele hierfür sind der Ausrichtungssensor und der lineare Beschleunigungssensor.)
Geräteimplementierungen:
- SOLLTEN diese Sensortypen implementieren, wenn sie die erforderlichen physischen Sensoren enthalten, wie unter Sensortypen beschrieben.
Wenn Geräteimplementierungen einen zusammengesetzten Sensor enthalten, gilt Folgendes:
- [C-2-1] MÜSSEN den Sensor wie in der Android-Open-Source-Dokumentation zu zusammengesetzten Sensoren beschrieben implementieren.
Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittentwickler enthalten und der Sensor nur einen Wert meldet, dann gilt für Geräteimplementierungen:
- [C-3-1] MÜSSEN die Auflösung für den Sensor auf 1 festlegen und den Wert über die API-Methode
Sensor.getResolution()
melden.
Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, der SensorAdditionalInfo#TYPE_VEC3_CALIBRATION unterstützt, und der Sensor externen Entwicklern ausgesetzt ist, geschieht Folgendes:
- [C-4-1] DARF KEINE festen, werkseitig festgelegten Kalibrierungsparameter in die bereitgestellten Daten aufnehmen.
Wenn Geräteimplementierungen eine Kombination aus einem 3-Achsen-Beschleunigungsmesser, einem 3-Achsen-Gyroskopsensor oder einem Magnetometersensor umfassen, gilt Folgendes:
- [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, dass Beschleunigungsmesser, Gyroskop und Magnetometer eine feste relative Position haben. So bleiben die Sensorachsen bei allen möglichen Gerätezuständen ausgerichtet und konsistent mit dem Sensortransformationssystem.
7.3.1 Beschleunigungsmesser
Geräteimplementierungen:
- [C-SR-1] wird dringend empfohlen, einen dreiachsigen Beschleunigungsmesser zu verwenden.
Wenn Geräte einen Beschleunigungsmesser enthalten, gilt Folgendes:
- [C-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 50 Hz melden können.
- [C-1-3] MUSS dem Android-Sensorkoordinatensystem entsprechen, wie in den Android-APIs beschrieben.
- [C-1-4] MUSS vom freien Fall bis zur vierfachen Schwerkraft(4 g) oder mehr auf jeder Achse gemessen werden können.
- [C-1-5] MUSS eine Auflösung von mindestens 12 Bit haben.
- [C-1-6] MUSS eine Standardabweichung von maximal 0,05 m/s^ haben, wobei die Standardabweichung pro Achse für Stichproben berechnet werden sollte, die über einen Zeitraum von mindestens 3 Sekunden mit der schnellsten Stichprobenrate erfasst wurden.
- SOLLTE Ereignisse mit bis zu 200 Hz melden.
- SOLLTEN eine Auflösung von mindestens 16 Bit haben.
- SOLLTEN während der Verwendung kalibriert werden, wenn sich die Eigenschaften im Laufe des Lebenszyklus ändern und kompensiert werden. Die Kompensationsparameter sollten zwischen Geräteneustarts beibehalten werden.
- SOLLTE temperaturkompensiert werden.
Wenn Geräte einen dreiachsigen Beschleunigungsmesser enthalten, gilt Folgendes:
- [C-2-1] MÜSSEN den
TYPE_ACCELEROMETER
-Sensor implementieren und melden. - [C-SR-4] wird dringend empfohlen, den
TYPE_SIGNIFICANT_MOTION
-Verbundsensor zu implementieren. - [C-SR-5] wird dringend empfohlen, den
TYPE_ACCELEROMETER_UNCALIBRATED
-Sensor zu implementieren und zu melden. Android-Geräte werden UNBEDINGT empfohlen, diese Anforderung zu erfüllen, sodass ein Upgrade auf den zukünftigen Plattformrelease möglich ist, bei dem dies möglicherweise ERFORDERLICH ist. - SOLLTEN die zusammengesetzten Sensoren
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
undTYPE_STEP_COUNTER
wie im Android SDK-Dokument beschrieben implementieren.
Wenn Geräte einen Beschleunigungsmesser mit weniger als drei Achsen enthalten, ist Folgendes zu beachten:
- [C-3-1] MÜSSEN den
TYPE_ACCELEROMETER_LIMITED_AXES
-Sensor implementieren und melden. - [C-SR-6]
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
-Sensoren STRONGLY_RECOMMENDED zu implementieren und zu melden.
Wenn Geräteimplementierungen einen dreiachsigen Beschleunigungsmesser umfassen und einer der zusammengesetzten TYPE_SIGNIFICANT_MOTION
-, TYPE_TILT_DETECTOR
-, TYPE_STEP_DETECTOR
- oder TYPE_STEP_COUNTER
-Sensoren implementiert ist:
- [C-4-1] Die Summe ihres Energieverbrauchs MUSS immer kleiner als 4 mW sein.
- SOLLTE jeweils unter 2 mW bzw.0,5 mW liegen, wenn das Gerät in einem dynamischen oder statischen Zustand ist.
Wenn die Geräteimplementierung einen 3-Achsen-Beschleunigungsmesser und einen 3-Achsen-Gyroskopsensor umfasst, geschieht Folgendes:
- [C-5-1] MÜSSEN die zusammengesetzten Sensoren
TYPE_GRAVITY
undTYPE_LINEAR_ACCELERATION
implementieren. - [C-SR-7] wird dringend empfohlen, den zusammengesetzten
TYPE_GAME_ROTATION_VECTOR
-Sensor zu implementieren.
Wenn Geräteimplementierungen einen 3-Achsen-Beschleunigungsmesser, einen 3-Achsen-Gyroskopsensor und einen Magnetometer-Sensor umfassen, gilt Folgendes:
- [C-6-1] MÜSSEN einen
TYPE_ROTATION_VECTOR
-Sensoren implementieren.
7.3.2 Magnetometer
Geräteimplementierungen:
- [C-SR-1] Wir empfehlen dringend, einen dreiachsigen Magnetometer (Kompass) mitzunehmen.
Wenn Geräteimplementierungen ein 3-Achsen-Magnetometer umfassen, gilt Folgendes:
- [C-1-1] MÜSSEN den
TYPE_MAGNETIC_FIELD
-Sensor implementieren. - [C-1-2] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 10 Hz melden können und SOLLTEN Ereignisse mit einer Frequenz von mindestens 50 Hz melden.
- [C-1-3] MUSS dem Android-Sensorkoordinatensystem entsprechen, wie in den Android-APIs beschrieben.
- [C-1-4] MUSS vor der Sättigung zwischen -900 μT und +900 μT auf jeder Achse messen können.
- [C-1-5] MÜSSEN einen Offset-Wert des harten Eisens unter 700 μT und einen Wert unter 200 μT haben. Platzieren Sie das Magnetometer in größerer Entfernung von dynamischen (strominduzierten) und statischen (Magnetinduzierten) Magnetfeldern.
- [C-1-6] MUSS eine Auflösung von mindestens 0,6 μT haben.
- [C-1-7] MUSS die Onlinekalibrierung und die Korrektur der harten Eisenverzerrung unterstützen und die Kompensationsparameter zwischen Geräteneustarts beibehalten.
- Bei [C-1-8] MUSS die Kompensation für weiches Eisen angewendet werden. Die Kalibrierung kann entweder während der Verwendung oder während der Produktion des Geräts erfolgen.
- [C-1-9] MÜSSEN eine Standardabweichung haben, die achsenbasiert für Stichproben, die über einen Zeitraum von mindestens 3 Sekunden mit der schnellsten Abtastrate (nicht größer als 1,5 μT) erfasst wurden, berechnet; SOLLTE eine Standardabweichung von maximal 0,5 μT haben.
- [C-1-10] MÜSSEN den
TYPE_MAGNETIC_FIELD_UNCALIBRATED
-Sensor implementieren.
Wenn Geräteimplementierungen ein 3-Achsen-Magnetometer, einen Beschleunigungsmessersensor und einen 3-Achsen-Gyroskopsensor enthalten, gilt Folgendes:
- [C-2-1] MÜSSEN einen
TYPE_ROTATION_VECTOR
-Sensoren implementieren.
Wenn Geräteimplementierungen ein dreiachsiges Magnetometer oder einen Beschleunigungsmesser enthalten, ist Folgendes zu beachten:
- KANN den
TYPE_GEOMAGNETIC_ROTATION_VECTOR
-Sensor implementieren.
Wenn Geräteimplementierungen ein dreiachsiges Magnetometer, einen Beschleunigungsmesser und einen TYPE_GEOMAGNETIC_ROTATION_VECTOR
-Sensor umfassen, gilt Folgendes:
- [C-3-1] MUSS weniger als 10 mW verbrauchen.
- SOLLTEN weniger als 3 mW verbrauchen, wenn der Sensor für den Batchmodus bei 10 Hz registriert ist.
7.3.3 GPS
Geräteimplementierungen:
- [C-SR-1] wird dringend empfohlen, einen GPS-/GNSS-Empfänger mitzunehmen.
Wenn Geräteimplementierungen einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps
an Anwendungen melden, geschieht Folgendes:
- [C-1-1] MUSS die Standortausgaben mit einer Frequenz von mindestens 1 Hz unterstützen, wenn sie über
LocationManager#requestLocationUpdate
angefordert werden. - [C-1-2] MÜSSEN in der Lage sein, den Standort unter freiem Himmel (starke Signale, vernachlässigbarer Multipfad, HDOP < 2) innerhalb von 10 Sekunden (schnelle Zeit bis zur ersten Behebung) zu bestimmen, wenn eine Internetverbindung mit 0,5 Mbit/s oder einer schnelleren Datengeschwindigkeit hergestellt ist. Diese Anforderung wird in der Regel durch die Verwendung einer unterstützten oder vorhergesagten GPS-/GNSS-Technik erfüllt, um die GPS-/GNSS-Lock-On-Zeit zu minimieren (Unterstützungsdaten umfassen Referenzzeit, Referenzstandort und Satelliten-Ephemeris/Uhr).
- [C-1-6] Nach einer solchen Standortberechnung MÜSSEN Geräteimplementierungen ihren Standort unter freiem Himmel innerhalb von 5 Sekunden nach dem Neustart von Standortanfragen und bis zu einer Stunde nach der ursprünglichen Standortberechnung ermitteln, auch wenn die nachfolgende Anfrage ohne Datenverbindung und/oder nach dem Ein- und Ausschalten des Geräts erfolgt.
Bei freiem Himmel nach Bestimmung des Standorts im Stillstand oder bei Bewegungen mit weniger als 1 Meter pro Sekunde als Quadrat der Beschleunigung:
- [C-1-3] MÜSSEN in mindestens 95% der Fälle den Standort in einem Umkreis von 20 Metern und eine Geschwindigkeit von 0,5 Metern pro Sekunde bestimmen können.
- [C-1-4] MÜSSEN mindestens 8 Satelliten einer Konstellation gleichzeitig über
GnssStatus.Callback
verfolgen und melden. - SOLLTEN in der Lage sein, mindestens 24 Satelliten aus mehreren Konstellationen gleichzeitig zu verfolgen (z.B. GPS und mindestens eines von Glonass, Beidou oder Galileo).
[C-SR-2] Es wird dringend empfohlen, während eines Notrufs weiterhin normale GPS-/GNSS-Standortausgaben über GNSS Location Provider APIs bereitzustellen.
[C-SR-3] Es wird dringend empfohlen, GNSS-Messungen von allen erfassten Konstellationen (wie in GnssStatus-Nachrichten gemeldet) zu melden, mit Ausnahme von SBAS.
[C-SR-4] Es wird dringend empfohlen, AGC und die Häufigkeit der GNSS-Messung zu melden.
[C-SR-5] Es wird dringend empfohlen, alle Schätzungen zur Genauigkeit (einschließlich Peilung, Geschwindigkeit und Branche) für jeden GPS-/GNSS-Standort anzugeben.
[C-SR-6] Es wird dringend empfohlen, GNSS-Messungen zu melden, sobald sie gefunden wurden, auch wenn noch kein über GPS/GNSS berechneter Standort gemeldet wurde.
[C-SR-7] Es wird dringend empfohlen, GNSS-Pseudobereiche und Pseudorangeraten zu melden, die bei freiem Himmel nach der Bestimmung des Standorts ausreichen, wenn sie sich nicht bewegen oder mit einer Beschleunigung von weniger als 0,2 Metern pro Sekunde im Quadrat der Beschleunigung ausreichen, um eine Position innerhalb von 20 Metern und eine Geschwindigkeit innerhalb von 0,2% pro Sekunde, mindestens 9 Meter pro Sekunde, zu berechnen.
7.3.4 Gyroskop
Geräteimplementierungen:
- [C-SR-1] wird dringend empfohlen, einen Gyroskopsensor zu verwenden.
Wenn Geräteimplementierungen ein Gyroskop umfassen, gilt Folgendes:
- [C-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 50 Hz melden können.
- [C-1-4] MUSS eine Auflösung von mindestens 12 Bit haben.
- [C-1-5] MUSS temperaturkompensiert werden.
- [C-1-6] MÜSSEN während der Verwendung kalibriert und kompensiert werden und die Kompensationsparameter zwischen Geräteneustarts beibehalten.
- [C-1-7] MUSS eine Varianz von nicht größer als 1e–7 rad^2 / s^2 pro Hz (Abweichung pro Hz oder rad^2 / s) haben. Die Varianz darf mit der Stichprobenrate variieren, MUSS aber durch diesen Wert eingeschränkt werden. Mit anderen Worten: Wenn Sie die Varianz des Gyros mit einer Abtastrate von 1 Hz messen, SOLLTE sie nicht größer als 1e-7 rad^2/s^2 sein.
- [C-SR-2] Der Kalibrierungsfehler sollte unter 0,01 Rad/s liegen, wenn das Gerät bei Raumtemperatur steht.
- [C-SR-3] Eine Auflösung von mindestens 16 Bit wird dringend empfohlen.
- SOLLTE Ereignisse mit bis zu 200 Hz melden.
Wenn Geräteimplementierungen ein 3-Achsen-Gyroskop umfassen, ist Folgendes erforderlich:
- [C-2-1] MÜSSEN den
TYPE_GYROSCOPE
-Sensor implementieren. - [C-SR-4] wird dringend empfohlen, den
TYPE_GYROSCOPE_UNCALIBRATED
-Sensor zu implementieren.
Wenn Geräteimplementierungen ein Gyroskop mit weniger als 3 Achsen enthalten, ist Folgendes zu beachten:
- [C-3-1] MÜSSEN den
TYPE_GYROSCOPE_LIMITED_AXES
-Sensor implementieren und melden. - [C-SR-5]
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
-Sensoren STRONGLY_RECOMMENDED zu implementieren und zu melden.
Wenn Geräteimplementierungen ein 3-Achsen-Gyroskop, einen Beschleunigungsmessersensor und einen Magnetometersensor umfassen, gilt Folgendes:
- [C-4-1] MÜSSEN einen
TYPE_ROTATION_VECTOR
-Sensoren implementieren.
Wenn die Geräteimplementierung einen 3-Achsen-Beschleunigungsmesser und einen 3-Achsen-Gyroskopsensor umfasst, geschieht Folgendes:
- [C-5-1] MÜSSEN die zusammengesetzten Sensoren
TYPE_GRAVITY
undTYPE_LINEAR_ACCELERATION
implementieren. - [C-SR-6] wird dringend empfohlen, den zusammengesetzten
TYPE_GAME_ROTATION_VECTOR
-Sensor zu implementieren.
7.3.5 Barometer
Geräteimplementierungen:
- [C-SR-1] wird dringend empfohlen, einen Barometer (Umgebungsdrucksensor) mitzunehmen.
Wenn Geräteimplementierungen ein Barometer enthalten, gilt Folgendes:
- [C-1-1] MÜSSEN den
TYPE_PRESSURE
-Sensor implementieren und melden. - [C-1-2] MUSS Ereignisse bei 5 Hz oder mehr liefern können.
- [C-1-3] MUSS temperaturkompensiert werden.
- [C-SR-2] UNBEDINGT EMPFOHLEN, Druckmessungen in einem Bereich von 300 hPa bis 1.100 hPa melden zu können.
- SOLLTEN eine absolute Genauigkeit von 1 hPa haben.
- SOLLTE eine relative Genauigkeit von 0,12 hPa in einem Bereich von 20 hPa haben (entspricht einer Genauigkeit von ~1 m über ~200 m Änderung auf dem Meeresspiegel).
7.3.6 Thermometer
Wenn Geräteimplementierungen ein Umgebungsthermometer (Temperatursensor) enthalten, gilt Folgendes:
- [C-1-1] MUSS
SENSOR_TYPE_AMBIENT_TEMPERATURE
für den Umgebungstemperatursensor definieren und der Sensor MUSS die Umgebungstemperatur (Raum-/Fahrzeugraum) in Grad Celsius messen, bei der der Nutzer mit dem Gerät interagiert.
Wenn Geräteimplementierungen einen Thermometersensor enthalten, der eine andere Temperatur als die Umgebungstemperatur misst, z. B. die CPU-Temperatur, gilt Folgendes:
- [C-2-1] DARF KEINE
SENSOR_TYPE_AMBIENT_TEMPERATURE
für den Temperatursensor definieren.
Wenn Geräteimplementierungen einen Sensor zur Überwachung der Hauttemperatur enthalten, dann gilt:
- [C-SR-1] wird dringend empfohlen, die PowerManager.getThermalHeadroom API zu unterstützen.
7.3.7 Fotometer
- Sie können ein Fotometer (Umgebungslicht-Sensor) verwenden, in dem ein entsprechendes Gerät implementiert ist.
7.3.8 Näherungssensor
- Geräteimplementierungen KÖNNEN einen Näherungssensor enthalten.
Wenn Geräteimplementierungen einen Näherungssensor enthalten und nur eine binäre „nahe“ oder „weite“ Messung melden, geschieht Folgendes:
- [C-1-1] MÜSSEN die Nähe eines Objekts in derselben Richtung wie der Bildschirm messen. Das heißt, der Näherungssensor MUSS so ausgerichtet sein, dass er Objekte in der Nähe des Bildschirms erkennt, da die Hauptabsicht dieses Sensortyps darin besteht, ein vom Nutzer verwendetes Smartphone zu erkennen. Wenn Geräteimplementierungen einen Näherungssensor mit einer anderen Ausrichtung beinhalten, DARF NICHT über diese API darauf zugegriffen werden.
- [C-1-2] MUSS eine Genauigkeit von mindestens 1 Bit haben.
- [C-1-3] MÜSSEN 0 Zentimeter als Nahbereich und 5 Zentimeter als Fernmesswert verwenden.
- [C-1-4] MÜSSEN einen Höchstwert und eine Auflösung von 5 angeben.
7.3.9 Hochwertige Sensoren
Wenn Geräteimplementierungen eine Reihe hochwertiger Sensoren (wie in diesem Abschnitt definiert) enthalten und sie für Drittanbieter-Apps zur Verfügung stellen, geschieht Folgendes:
- [C-1-1] MUSS die Funktion mit dem Funktions-Flag
android.hardware.sensor.hifi_sensors
identifizieren.
Wenn in Geräteimplementierungen android.hardware.sensor.hifi_sensors
deklariert wird, geschieht Folgendes:
[C-2-1] MUSS einen
TYPE_ACCELEROMETER
-Sensor haben, der:- MÜSSEN einen Messbereich zwischen -8 g und +8 g haben. Es wird dringend empfohlen, einen Messbereich zwischen -16 g und +16 g zu haben.
- MÜSSEN eine Auflösung von mindestens 2.048 LSB/g haben.
- MUSS eine Mindest-Messfrequenz von 12,5 Hz oder weniger haben.
- MÜSSEN eine maximale Messfrequenz von 400 Hz oder höher haben; SOLLTE SensorDirectChannel
RATE_VERY_FAST
unterstützen. - MUSS ein Messrauschen nicht über 400 μg/√Hz haben.
- MÜSSEN eine Nicht-Aktivierungsform dieses Sensors mit einer Pufferfunktion für mindestens 3.000 Sensorereignisse implementieren.
- MUSS einen Batch-Stromverbrauch haben, der nicht unter 3 mW liegt.
- [C-SR-1] Es wird dringend empfohlen, eine 3-dB-Messbandbreite von mindestens 80% der Nyquist-Frequenz und ein Spektrum für weißes Rauschen innerhalb dieser Bandbreite zu haben.
- SOLLTEN Beschleunigungsvorgänge nach dem Zufallsprinzip unter 30 μg √Hz bei Raumtemperatur durchgeführt werden.
- SOLLTE eine Verzerrungsänderung gegenüber der Temperatur von ≤ +/- 1 mg/°C auftreten.
- SOLLTEN eine optimale Linien-Nichtlinearität von ≤ 0,5 % und Empfindlichkeitsänderung gegenüber Temperatur ≤ 0,03%/C° haben.
- SOLLTE eine Querachsenempfindlichkeit unter 2,5 % und eine Abweichung der Querachsenempfindlichkeit unter 0,2% im Betriebstemperaturbereich des Geräts haben.
[C-2-2] MUSS eine
TYPE_ACCELEROMETER_UNCALIBRATED
mit denselben Qualitätsanforderungen wieTYPE_ACCELEROMETER
haben.[C-2-3] MUSS einen
TYPE_GYROSCOPE
-Sensor haben, der:- MUSS einen Messbereich zwischen -1.000 und +1.000 dps haben.
- MÜSSEN eine Auflösung von mindestens 16 LSB/dps haben.
- MUSS eine Mindest-Messfrequenz von 12,5 Hz oder weniger haben.
- MÜSSEN eine maximale Messfrequenz von 400 Hz oder höher haben; SOLLTE SensorDirectChannel
RATE_VERY_FAST
unterstützen. - MUSS ein Messrauschen von maximal 0,014°/s/√Hz haben.
- [C-SR-2] Es wird dringend empfohlen, eine 3-dB-Messbandbreite von mindestens 80% der Nyquist-Frequenz und ein Spektrum für weißes Rauschen innerhalb dieser Bandbreite zu haben.
- SOLLTE eine Zufallsrate von unter 0,001°/s √Hz bei Raumtemperatur laufen lassen.
- SOLLTE eine Verzerrungsänderung gegenüber der Temperatur von ≤ +/- 0,05 °/ s / °C auftreten.
- SOLLTE eine Änderung der Empfindlichkeit gegenüber der Temperatur von ≤ 0,02% / °C betragen.
- SOLLTEN eine Nichtlinearität der bestmöglichen Linie von ≤ 0,2 % haben.
- SOLLTEN eine Rauschdichte von ≤ 0,007°/s/√Hz haben.
- SOLLTEN Kalibrierungsfehler unter 0,002 Rad/s im Temperaturbereich von 10–40 °C auftreten, wenn das Gerät steht.
- SOLLTE eine G-Empfindlichkeit unter 0,1°/s/g aufweisen.
- SOLLTE eine Querachsenempfindlichkeit unter 4,0 % und eine Schwankung der Querachsenempfindlichkeit unter 0,3% im Betriebstemperaturbereich des Geräts haben.
[C-2-4] MUSS eine
TYPE_GYROSCOPE_UNCALIBRATED
mit denselben Qualitätsanforderungen wieTYPE_GYROSCOPE
haben.[C-2-5] MUSS einen
TYPE_GEOMAGNETIC_FIELD
-Sensor haben, der:- MÜSSEN einen Messbereich zwischen -900 und +900 μT haben.
- MÜSSEN eine Auflösung von mindestens 5 LSB/uT haben.
- MUSS eine Mindest-Messfrequenz von 5 Hz oder niedriger haben.
- MUSS eine maximale Messfrequenz von 50 Hz oder höher haben.
- MUSS ein Messrauschen aufweisen, das nicht über 0,5 uT liegt.
[C-2-6] MUSS eine
TYPE_MAGNETIC_FIELD_UNCALIBRATED
mit denselben Qualitätsanforderungen wieTYPE_GEOMAGNETIC_FIELD
sowie zusätzlich Folgendes haben:- MÜSSEN eine Nicht-Aktivierungsform dieses Sensors mit einer Pufferfunktion für mindestens 600 Sensorereignisse implementieren.
- [C-SR-3] Es wird dringend empfohlen, ein weißes Rauschenspektrum von 1 Hz bis mindestens 10 Hz zu haben, wenn die Melderate mindestens 50 Hz beträgt.
[C-2-7] MUSS einen
TYPE_PRESSURE
-Sensor haben, der:- MÜSSEN einen Messbereich zwischen mindestens 300 und 1100 hPa aufweisen.
- MÜSSEN eine Auflösung von mindestens 80 LSB/hPa haben.
- MUSS eine Mindest-Messfrequenz von 1 Hz oder niedriger haben.
- MUSS eine maximale Messfrequenz von 10 Hz oder höher haben.
- MUSS ein Messrauschen von maximal 2 P/√Hz haben.
- MÜSSEN eine Nicht-Aktivierungsform dieses Sensors mit einer Pufferfunktion für mindestens 300 Sensorereignisse implementieren.
- Der Stromverbrauch für die Batchverarbeitung MUSS nicht unter 2 mW liegen.
[C-2-8] MUSS einen
TYPE_GAME_ROTATION_VECTOR
-Sensor haben.[C-2-9] MUSS einen
TYPE_SIGNIFICANT_MOTION
-Sensor haben, der:- MUSS einen Stromverbrauch von nicht weniger als 0,5 mW haben, wenn das Gerät statisch ist, und 1,5 mW, wenn das Gerät in Bewegung ist.
[C-2-10] MUSS einen
TYPE_STEP_DETECTOR
-Sensor haben, der:- MÜSSEN eine Nicht-Aktivierungsform dieses Sensors mit einer Pufferfunktion für mindestens 100 Sensorereignisse implementieren.
- MUSS einen Stromverbrauch von nicht weniger als 0,5 mW haben, wenn das Gerät statisch ist, und 1,5 mW, wenn das Gerät in Bewegung ist.
- MÜSSEN einen Batch-Stromverbrauch haben, der nicht unter 4 mW liegt.
[C-2-11] MUSS einen
TYPE_STEP_COUNTER
-Sensor haben, der:- MUSS einen Stromverbrauch von nicht weniger als 0,5 mW haben, wenn das Gerät statisch ist, und 1,5 mW, wenn das Gerät in Bewegung ist.
[C-2-12] MUSS einen
TILT_DETECTOR
-Sensor haben, der:- MUSS einen Stromverbrauch von nicht weniger als 0,5 mW haben, wenn das Gerät statisch ist, und 1,5 mW, wenn das Gerät in Bewegung ist.
[C-2-13] Der vom Beschleunigungsmesser, dem Gyroskop und dem Magnetometer gemeldete Ereigniszeitstempel desselben physischen Ereignisses MUSS nicht weiter als 2, 5 Millisekunden auseinander liegen. Der vom Beschleunigungsmesser und dem Gyroskop gemeldete Zeitstempel desselben physischen Ereignisses SOLLTE im Umkreis von 0,25 Millisekunden auseinander liegen.
[C-2-14] MÜSSEN Zeitstempel für Gyroskopsensor-Ereignisse auf der gleichen Zeitbasis wie das Kamerasubsystem und innerhalb von 1 Millisekunden nach Ablauf haben.
[C-2-15] MÜSSEN innerhalb von 5 Millisekunden ab dem Zeitpunkt, an dem die Daten auf einem der oben genannten physischen Sensoren für die Anwendung verfügbar sind, Stichproben an Anwendungen liefern.
[C-2-16] DÜRFEN keinen Stromverbrauch von mehr als 0,5 mW haben, wenn das Gerät statisch ist, und 2,0 mW, wenn das Gerät in Bewegung ist, wenn eine 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 eine Mindestpufferkapazität von 100 Sensorereignissen haben, wenn er vorhanden ist.
Beachten Sie, dass die Anforderungen an den Stromverbrauch in diesem Abschnitt nicht den Stromverbrauch des Anwendungsprozessors umfassen. Sie umfasst auch die Leistung, die von der gesamten Sensorkette verbraucht wird, also dem Sensor, allen unterstützenden Schaltkreisen, einem dedizierten Sensorverarbeitungssystem usw.
Wenn Geräte eine direkte Sensorunterstützung bieten, gilt Folgendes:
- [C-3-1] MÜSSEN die Unterstützung von Typen für direkte Kanäle und der Tarife für direkte Berichte über die
isDirectChannelTypeSupported
undgetHighestDirectReportRateLevel
API korrekt deklarieren. - [C-3-2] MÜSSEN für alle Sensoren, die den direkten Sensorkanal angeben, mindestens einen der beiden Typen des direkten Sensorkanals unterstützen.
- SOLLTEN Ereignisberichte über den direkten Sensorkanal für primäre Sensoren (Variante ohne Weckfunktion) 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 biometrischen Entsperrungssicherheit finden Sie in der Dokumentation zum Messen der biometrischen Sicherheit.
Wenn Geräteimplementierungen einen sicheren Sperrbildschirm beinhalten, gilt Folgendes:
- SOLLTE einen biometrischen Sensor enthalten
Biometrische Sensoren können basierend auf ihren Akzeptanzraten für gefälschte und betrügerische Elemente und auf der Sicherheit der biometrischen Pipeline in die Klasse 3 (früher Strong), Klasse 2 (früher Weak) oder Klasse 1 (früher Convenience) klassifiziert werden. Diese Klassifizierung bestimmt die Funktionen, über die der biometrische Sensor mit der Plattform und Drittanbieteranwendungen kommunizieren kann. Sensoren müssen den unten aufgeführten zusätzlichen Anforderungen entsprechen, wenn sie als Klasse 1, Klasse 2 oder Klasse 3 klassifiziert werden möchten. Sowohl für die Klasse 2 als auch für die Klasse 3 sind zusätzliche Funktionen verfügbar, die unten beschrieben werden.
Wenn in Geräteimplementierungen ein biometrischer Sensor über android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt und android.provider.Settings.ACTION_BIOMETRIC_ENROLL für Drittanbieteranwendungen verfügbar ist, gilt Folgendes:
- [C-4-1] MUSS die in diesem Dokument definierten Anforderungen für biometrische Daten der Klasse 3 oder Klasse 2 erfüllen.
- [C-4-2] MÜSSEN jeden Parameternamen erkennen und berücksichtigen, der in der Klasse Authenticators und allen Kombinationen daraus als Konstante definiert ist. Umgekehrt DÜRFEN KEINE Ganzzahlkonstanten, die an die Methoden canAuthenticate(int) und setAllowedAuthenticators(int) übergeben werden, berücksichtigt oder erkannt werden, sofern sie nicht in Authenticators und deren Kombinationen als öffentliche Konstanten dokumentiert sind.
- [C-4-3] MÜSSEN die Aktion ACTION_BIOMETRIC_ENROLL auf Geräten mit biometrischen Verfahren der Klasse 3 oder Klasse 2 implementieren. Bei dieser Aktion DARF nur die Einstiegspunkte zur Anmeldung für biometrische Daten der Klasse 3 oder Klasse 2 angezeigt werden.
Wenn Geräteimplementierungen passives biometrisches Verfahren unterstützen, gilt Folgendes:
- [C-5-1] MUSS standardmäßig einen zusätzlichen Bestätigungsschritt erfordern (z.B. das Drücken einer Schaltfläche).
- [C-SR-1] Es wird dringend empfohlen, eine Einstellung zu haben, mit der Nutzer Anwendungseinstellungen überschreiben können und immer einen zugehörigen Bestätigungsschritt erfordern.
- [C-SR-2] Es wird dringend empfohlen, die Bestätigungsaktion so abzusichern, dass sie von einem Betriebssystem- oder Kernel-Manipulation nicht spooft werden kann. Das bedeutet beispielsweise, dass die Bestätigungsaktion, die auf einer physischen Schaltfläche basiert, über einen GPIO-(Eingabe-/Ausgabe-Pin) eines Secure Elements (SE) weitergeleitet wird, das ausschließlich durch das Drücken einer physischen Taste angesteuert werden kann.
- [C-5-2] MÜSSEN außerdem einen impliziten Authentifizierungsvorgang (ohne Bestätigungsschritt) implementieren, der setConfirmationRequired(boolean) entspricht. Apps können diesen Ablauf für Anmeldevorgänge festlegen.
Geräteimplementierungen mit mehreren biometrischen Sensoren:
Neue Anforderungen erstellen
[C-7-1] MÜSSEN, wenn ein biometrisches Verfahren aufgrund zu vieler fehlgeschlagener Versuche vorübergehend gesperrt wird (das biometrische Verfahren wird deaktiviert, bis der Nutzer mit der primären Authentifizierung entsperrt) oder zeitgebunden ist (d. h., es wird vorübergehend deaktiviert, bis der Nutzer auf ein Zeitintervall wartet). Dies gilt auch für alle anderen biometrischen Daten einer niedrigeren biometrischen Klasse. Im Fall einer zeitgebundenen Sperrung MUSS die Backoff-Zeit für die biometrische Überprüfung die maximale Backoff-Zeit aller biometrischen Daten sein.
[C-SR-12] Werden dringend empfohlen, wenn ein biometrisches Verfahren aufgrund zu vieler fehlgeschlagener Versuche vorübergehend gesperrt wird (d. h. das biometrische Verfahren wird deaktiviert, bis der Nutzer mit der primären Authentifizierung entsperrt) oder biometrisches Verfahren (das biometrische Verfahren wird vorübergehend deaktiviert, bis der Nutzer ein bestimmtes Zeitintervall wartet). Im Fall einer zeitgebundenen Sperrung wird UNBEDINGT die maximale Backoff-Zeit aller biometrischen Daten in der biometrischen Überprüfung empfohlen.
[C-7-2] MÜSSEN den Nutzer zur empfohlenen primären Authentifizierung auffordern (z. B. mit PIN, Muster, Passwort), um den Sperrzähler zurückzusetzen, wenn ein biometrisches Verfahren gesperrt wird. Klasse 3 darf den Sperrzähler für ein gesperrtes biometrisches Verfahren derselben oder einer niedrigeren Klasse zurücksetzen. Biometrische Verfahren der Klasse 2 oder Klasse 1 DÜRFEN KEINEN Sperrvorgang zum Zurücksetzen für biometrische Daten durchführen.
Neue Anforderungen beenden
- [C-SR-3] Es wird dringend empfohlen, pro Authentifizierung nur ein biometrisches Verfahren zu bestätigen. Wenn auf dem Gerät beispielsweise sowohl der Fingerabdruck als auch der Gesichtserkennungssensor verfügbar sind, sollte onAuthenticationSucceeded gesendet werden, nachdem einer davon bestätigt wurde.
Damit Geräteimplementierungen den Zugriff auf Schlüsselspeicherschlüssel für Drittanbieteranwendungen ermöglichen können, müssen folgende Anforderungen erfüllt sein:
- [C-6-1] MÜSSEN die im folgenden Abschnitt definierten Anforderungen für Klasse 3 erfüllen.
- [C-6-2] MUSS nur biometrische Daten der Klasse 3 anzeigen, wenn die Authentifizierung BIOMETRIC_STRONG erfordert oder die Authentifizierung mit einem CryptoObject aufgerufen wird.
Wenn in Geräteimplementierungen ein biometrischer Sensor als Klasse 1 (früher Nutzerfreundlichkeit) behandelt werden soll, gilt Folgendes:
- [C-1-1] MUSS eine falsche Annahmequote unter 0,002 % haben.
- [C-1-2] MÜSSEN offenlegen, dass dieser Modus möglicherweise nicht so sicher ist als eine starke PIN, ein starkes Muster oder ein starkes Passwort, und die Risiken der Aktivierung des Modus klar angeben, wenn die Akzeptanzraten durch Spoofing und Betrüger gemäß den Android Biometrics Test Protocols über 7% liegen.
- [C-1-9] MÜSSEN den Nutzer nach maximal 20 falschen Tests und mindestens 90 Sekunden Backoff-Zeit für die biometrische Überprüfung zur empfohlenen primären Authentifizierung (z.B. PIN, Muster, Passwort) auffordern – wenn ein falscher Test eine solche ist, deren Erfassungsqualität (BIOMETRIC_ACQUIRED_GOOD) angemessen ist und nicht mit einem registrierten biometrischen Verfahren übereinstimmt.
- [C-SR-4] wird dringend empfohlen, die Gesamtzahl der in [C-1-9] angegebenen falschen Versuche für die biometrische Überprüfung zu senken, wenn die Annahmequoten für Spoofing und Hochstapler gemäß den Android Biometrics Test Protocols über 7% liegen.
- [C-1-3] MUSS die Anzahl der Versuche für die biometrische Überprüfung begrenzen, wenn ein falscher Versuch ein Test mit einer angemessenen Aufnahmequalität ist (
BIOMETRIC_ACQUIRED_GOOD
), die nicht mit einem registrierten biometrischen Verfahren übereinstimmt. - [C-SR-5] wird dringend empfohlen, die Ratenbegrenzung für mindestens 30 Sekunden nach fünf falschen biometrischen Tests für die maximale Anzahl falscher Versuche pro [C-1-9] zu begrenzen, wobei ein falscher Versuch einer mit einer angemessenen Erfassungsqualität (BIOMETRIC_ACQUIRED_GOOD) ist, die nicht mit einem registrierten biometrischen Verfahren übereinstimmt.
- [C-SR-6] Es wird dringend empfohlen, die gesamte Ratenbegrenzungslogik in TEE zu verwenden.
[C-1-10] MÜSSEN die biometrischen Daten deaktivieren, sobald der Backoff für die primäre Authentifizierung ausgelöst wurde, wie unter [C-0-2] in Abschnitt 9.11 beschrieben.
[C-1-11] MUSS eine Akzeptanzrate von Spoofing und Hochstapler-Spezies nicht über 30 % liegen, wobei (1) eine Akzeptanzrate von Spoofing und Hochstapler-Spezies für PAI-Arten der Stufe A nicht über 30 % liegt und (2) eine Parodien und Hochstapler-Akzeptanzraten von Level B-PAI-Spezies nicht über 40 % gemessen werden.
[C-1-4] MÜSSEN verhindern, dass neue biometrische Daten hinzugefügt werden, ohne zuvor eine Vertrauenskette aufzubauen. Dazu muss der Nutzer das Vorhandensein von Anmeldedaten bestätigen oder neue, von TEE gesicherte Geräteanmeldedaten (PIN/Muster/Passwort) hinzufügen. Die Implementierung des Android-Open-Source-Projekts stellt den entsprechenden Mechanismus im Framework bereit.
[C-1-5] MÜSSEN alle identifizierbaren biometrischen Daten eines Nutzers vollständig entfernen, wenn sein Konto entfernt wird (auch über das Zurücksetzen auf die Werkseinstellungen).
[C-1-6] MUSS das individuelle Flag für diese biometrische Methode (d.h.
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
oderDevicePolicymanager.KEYGUARD_DISABLE_IRIS
) berücksichtigen.[C-1-7] MÜSSEN den Nutzer höchstens alle 24 Stunden zur empfohlenen primären Authentifizierung (z.B. PIN, Muster, Passwort) auffordern. Hinweis: Bei einem Upgrade von Geräten, die mit Android 9 oder niedriger gestartet wurden, MUSS der Nutzer höchstens alle 72 Stunden die empfohlene primäre Authentifizierung (z.B. PIN, Muster oder Passwort) anfordern.
[C-1-8] MÜSSEN den Nutzer nach einer der folgenden Aktionen zur primären Authentifizierung (z. B. PIN, Muster, Passwort) oder biometrischen Verfahren der Klasse 3 (STRONG) auffordern:
- ein Zeitlimit von 4 Stunden bei Inaktivität ODER
- 3 fehlgeschlagene biometrische Authentifizierungsversuche.
- Das Zeitlimit bei Inaktivität und die Anzahl der fehlgeschlagenen Authentifizierungen werden zurückgesetzt, nachdem die Geräteanmeldedaten erfolgreich bestätigt wurden. Hinweis: Geräteupgrades, die unter Android 9 oder niedriger gestartet wurden, KÖNNEN von C-1-8 ausgenommen.
[C-SR-7] wird dringend empfohlen, die Logik im Framework des Android-Open-Source-Projekts zu verwenden, um die in [C-1-7] und [C-1-8] angegebenen Einschränkungen für neue Geräte durchzusetzen.
[C-SR-8] Wir empfehlen dringend, eine Rate falscher Ablehnungen von weniger als 10 % (gemessen am Gerät) zu haben.
[C-SR-9] Für jedes registrierte biometrische Verfahren wird dringend eine Latenz von unter einer Sekunde empfohlen, gemessen ab dem Zeitpunkt, an dem das biometrische Verfahren erkannt wird, bis zum Entsperren des Bildschirms.
Neue Anforderungen erstellen
[C-1-12] MUSS eine Spoofing- und Imposter-Akzeptanzrate von nicht mehr als 40 % pro Art des Präsentationsangriffs (PAI) haben, wie von den Android Biometrics Test Protocols gemessen.
[C-SR-13] Es wird dringend empfohlen, eine Spoofing- und Hochstufungsrate von maximal 30% pro Art des Präsentationsangriffs (PAI) gemäß den Android Biometrics Test Protocols zu verwenden.
[C-SR-14] wird dringend empfohlen, die biometrische Klasse des biometrischen Sensors und die entsprechenden Risiken der Aktivierung anzugeben.
[C-SR-17] wird dringend empfohlen, die neuen AIDL-Schnittstellen (z. B.
IFace.aidl
undIFingerprint.aidl
) zu implementieren.
Neue Anforderungen beenden
Wenn in Geräteimplementierungen ein biometrischer Sensor als Klasse 2 (früher Schwach) behandelt werden soll, gilt Folgendes:
[C-2-1] MÜSSEN alle Anforderungen für Klasse 1 oben erfüllen.
[C-2-2] MUSS eine Akzeptanzrate von Spoofing und Hochstapler-Spezies von maximal 20 % haben, wobei (1) eine Akzeptanzrate von Parodien und Hochstapler-Spezies für PAI-Arten (Level A Presentation Attack Instrument, PAI) nicht höher als 20 % und (2) eine Spoofing- und Hochstapler-Akzeptanzrate von Level B-PAI-Arten nicht höher als 30 % ist, gemessen nach den Testmesswerten.
Neue Anforderungen erstellen
- [C-SR-15] Es wird dringend empfohlen, die Akzeptanzrate von Spoofing und Hochstapler-Spoofen nicht über 20% pro Präsentationsangriffsart (PAI) zu setzen, wie von den Android Biometrics Test Protocols gemessen.
Neue Anforderungen beenden
- [C-2-3] MÜSSEN den biometrischen Abgleich in einer isolierten Ausführungsumgebung außerhalb des Android-Nutzer- oder Kernelbereichs wie der Trusted Execution Environment (TEE)
oderauf einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder auf einer geschützten virtuellen Maschine durchführen, die die Anforderungen in Abschnitt 9.17 erfüllt. - [C-2-4] MÜSSEN alle identifizierbaren Daten verschlüsselt und kryptografisch authentifiziert haben, sodass sie außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal nicht außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal für die isolierte Ausführungsumgebung erfasst, gelesen oder geändert werden können, wie in den Implementierungsrichtlinien auf der Website des Android Open Source Project oder einer geschützten virtuellen Maschine, die von Hypervisor gesteuert wird, die die Anforderungen in Abschnitt 9.17 erfüllt, dokumentiert ist.
- [C-2-5] Für kamerabasierte biometrische Verfahren und biometrische Authentifizierung oder Registrierung:
- Die Kamera MÜSSEN in einem Modus betrieben werden, der verhindert, dass Kameraframes außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal gelesen oder geändert werden, in die isolierte Ausführungsumgebung oder eine geschützte virtuelle Maschine, die vom Hypervisor gesteuert wird und die Anforderungen in Abschnitt 9.17 erfüllt.
- Bei RGB-Lösungen mit einer Kamera können die Kamerabilder außerhalb der isolierten Ausführungsumgebung lesbar sein, um Vorgänge wie die Vorschau für die Registrierung zu unterstützen, DÜRFEN aber dennoch NICHT geändert werden.
- [C-2-6] DÜRFEN Anwendungen von Drittanbietern NICHT ermöglichen, zwischen einzelnen biometrischen Registrierungen zu unterscheiden.
- [C-2-7] DÜRFEN NICHT den unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder daraus abgeleitete Daten (z. B. Einbettungen) auf den Anwendungsprozessor außerhalb des Kontexts des TEE oder der vom Hypervisor gesteuerten geschützten virtuellen Maschine, die die Anforderungen in Abschnitt 9.17 erfüllt, zulassen. Geräteupgrades, die unter Android 9 oder niedriger gestartet wurden, sind nicht von C-2-7 ausgenommen.
[C-2-8] MUSS eine sichere Verarbeitungspipeline haben, sodass aufgrund einer Manipulation des Betriebssystems oder Kernels keine direkte Einschleusung von Daten für eine falsche Nutzerauthentifizierung möglich ist. Hinweis: Geräteimplementierungen, die bereits unter Android 9 oder niedriger eingeführt sind und die Anforderung C-2-8 nicht durch ein Systemsoftwareupdate erfüllen, können von der Anforderung ausgenommen werden.
[C-SR-10] wird dringend empfohlen, die Aktivitätserkennung für alle biometrischen Modalitäten und die Aufmerksamkeitserkennung für das biometrische Verfahren für das Gesicht aufzunehmen.
[C-2-9] MUSS den biometrischen Sensor für Drittanbieteranwendungen verfügbar machen.
Wenn in Geräteimplementierungen ein biometrischer Sensor als Klasse 3 (früher Strong) behandelt werden soll, gilt Folgendes:
- [C-3-1] MUSS alle Anforderungen der obigen Klasse 2 mit Ausnahme von [C-1-7] und [C-1-8] erfüllen.
- [C-3-2] MÜSSEN eine hardwaregestützte Schlüsselspeicherimplementierung haben.
- [C-3-3] MUSS eine Akzeptanzrate von Spoofing und Hochstapler-Spezies von maximal 7 % haben, wobei (1) eine Akzeptanzrate von Parodien und Hochstapler-Spezies für PAI-Arten (Level A Presentation Attack Instrument, PAI) nicht höher als 7 % und (2) eine Parodien und Hochstapler-Biometrische Akzeptanzrate von Level B PAI-Testarten nicht höher als 20 % ist, wie von den Android-Testprotokollen gemessen. Android-Testprotokolle
- [C-3-4] MÜSSEN den Nutzer höchstens alle 72 Stunden zur empfohlenen primären Authentifizierung (z.B. PIN, Muster, Passwort) auffordern.
- [C-3-5] MÜSSEN die Authenticator-ID für alle biometrischen Verfahren der Klasse 3, die auf dem Gerät unterstützt werden, neu generieren, wenn eines davon neu registriert wird.
- [C-3-6] Sie müssen biometrische gesicherte Schlüsselspeicherschlüssel für Drittanbieteranwendungen aktivieren.
Neue Anforderungen erstellen
- [C-SR-16] Es wird dringend empfohlen, eine Spoofing- und Hochstufungsrate von maximal 7% pro Art des Präsentationsangriffs (PAI) gemäß den Android Biometrics Test Protocols zu verwenden.
Neue Anforderungen beenden
Wenn Geräteimplementierungen einen Fingerabdrucksensor unter dem Display enthalten, gilt Folgendes:
- [C-SR-11] Es wird dringend empfohlen, die Bedienung über 3 Schaltflächen durch den antippbaren Bereich des Fingerabdrucksensors zu verhindern, was einige Nutzer möglicherweise für die Barrierefreiheit benötigen.
7.3.11 Positionssensor
Geräteimplementierungen:
- KANN Positionssensor mit 6 Freiheitsgraden unterstützen.
Wenn Geräteimplementierungen einen Positionssensor mit 6 Freiheitsgraden unterstützen, ist Folgendes möglich:
- [C-1-1] MÜSSEN den
TYPE_POSE_6DOF
-Sensor implementieren und melden. - [C-1-2] MUSS genauer sein als der Rotationsvektor allein.
7.3.12 Scharnierwinkelsensor
Wenn Geräteimplementierungen einen Scharnierwinkelsensor unterstützen, ist Folgendes zu beachten:
- [C-1-1] MÜSSEN
TYPE_HINGLE_ANGLE
implementieren und melden. - [C-1-2] MUSS mindestens zwei Messwerte zwischen 0 und 360 Grad (einschließlich 0 und 360 Grad) unterstützen.
- [C-1-3] MUSS einen Wakeup-Sensor für
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
zurückgeben.
7.3.13 IEEE 802.1.15.4 (UWB)
Wenn Geräteimplementierungen 802.1.15.4 unterstützen und die Funktionalität einer Drittanbieteranwendung zugänglich machen, gilt Folgendes:
Neue Anforderungen erstellen
- [C-1-2] MÜSSEN das Hardwarefunktions-Flag
android.hardware.uwb
melden. - [C-1-3] MUSS alle folgenden Konfigurationssätze (vordefinierte Kombinationen von FIRA UCI-Parametern) unterstützen, die in der AOSP-Implementierung definiert sind.
CONFIG_ID_1
: FiRa-definierte Unicast-STATIC STS DS-TWR
-Bereichsbestimmung, verzögerter Modus, Bereichsintervall 240 ms.CONFIG_ID_2
: Von FiRa definierte 1:n-STATIC STS DS-TWR
-Bereichsbestimmung, verzögerter Modus, Abstandsintervall 200 ms. Typischer Anwendungsfall: Smartphones interagieren mit vielen Smart-Home-Geräten.CONFIG_ID_3
: EntsprichtCONFIG_ID_1
, mit dem Unterschied, dass keine Daten zum Anlaufwinkel (AoA) gemeldet werden.CONFIG_ID_4
: EntsprichtCONFIG_ID_1
, mit dem Unterschied, dass der P-STS-Sicherheitsmodus aktiviert ist.CONFIG_ID_5
: EntsprichtCONFIG_ID_2
, mit dem Unterschied, dass der P-STS-Sicherheitsmodus aktiviert ist.CONFIG_ID_6
: EntsprichtCONFIG_ID_3
, mit dem Unterschied, dass der P-STS-Sicherheitsmodus aktiviert ist.CONFIG_ID_7
: EntsprichtCONFIG_ID_2
, mit dem Unterschied, dass der P-STS-Schlüsselmodus für einzelne Steuerelemente aktiviert ist.
- [C-1-4] MÜSSEN eine Funktion anbieten, mit der der Nutzer das UWB-Radio ein- oder ausschalten kann.
- [C-1-5] MÜSSEN erzwingen, dass Apps, die UWB-Funkschnittstelle verwenden, die Berechtigung
UWB_RANGING
(unter der BerechtigungsgruppeNEARBY_DEVICES
) haben.
Das Bestehen der relevanten Konformitäts- und Zertifizierungstests, die von Standardorganisationen wie FIRA, CCC und CSA definiert wurden, trägt dazu bei, dass 802.1.15.4 ordnungsgemäß funktioniert.
Neue Anforderungen beenden
7.4 Datenverbindung
7.4.1 Telefonie
Der von den Android-APIs verwendete Begriff "Telefonie" bezieht sich in diesem Dokument speziell auf Hardware für das Tätigen von Sprachanrufen und das Senden von SMS-Nachrichten oder das Einrichten mobiler Daten über ein Mobilfunknetz (z.B. GSM-, CDMA-, LTE-, NR)GSM- oder CDMA-Netzwerk. Ein Gerät, das „Telefonie“ unterstützt, kann je nach Produkt einige oder alle Anruf-, Messaging- und Datendienste anbieten.
über ein GSM- oder CDMA-Netzwerk. Auch wenn diese Sprachanrufe paketversetzt werden können oder nicht, gelten sie für die Zwecke von Android als unabhängig von Datenverbindungen, die über dasselbe Netzwerk implementiert werden. Mit anderen Worten,die Android-Telefoniefunktionen und APIs beziehen sich speziell auf Sprachanrufe und SMS. Beispielsweise werden Geräteimplementierungen, die keine Anrufe tätigen oder keine SMS senden/empfangen können, als Telefoniegerät betrachtet, unabhängig davon, ob sie ein Mobilfunknetz für die Datenverbindung verwenden.
- Android KANN auf Geräten ohne Telefonie-Hardware verwendet werden. Das heißt, Android ist mit Geräten kompatibel, die keine Smartphones sind.
Wenn Geräteimplementierungen GSM- oder CDMA-Telefonie umfassen, gilt Folgendes:
- [C-1-1] MÜSSEN das Feature-Flag
android.hardware.telephony
und andere Flags für untergeordnete Elemente der Technologie entsprechend deklarieren. - [C-1-2] MÜSSEN für diese Technologie den vollen Support für die API implementieren.
- MÜSSEN während Notrufen alle verfügbaren Mobilfunktypen (2G, 3G, 4G, 5G usw.) zulassen (unabhängig von den mit
SetAllowedNetworkTypeBitmap()
festgelegten Netzwerktypen).
Wenn Geräteimplementierungen keine Telefoniehardware enthalten, gilt Folgendes:
- [C-2-1] MÜSSEN die vollständigen APIs als managementfrei implementieren.
Wenn Geräteimplementierungen eUICCs oder eSIMs/eingebettete SIMs unterstützen und einen proprietären Mechanismus enthalten, um Drittanbieter-Entwicklern eSIM-Funktionen zur Verfügung zu stellen, gilt Folgendes:
- [C-3-1] MUSS das Feature-Flag
android.hardware.telephony.euicc
deklarieren.
Wenn die Systemeigenschaft ro.telephony.iwlan\_operation\_mode
bei Geräteimplementierungen nicht auf „alt“ gesetzt wird, geschieht Folgendes:
- [C-4-1] DARF NICHT „NETWORK_TYPE_IWLAN“ über NetworkRegistrationInfo#getAccessNetworkTechnology() melden, wenn NetworkRegistrationInfo#getTransportType() für dieselbe NetworkRegistrationInfo-Instanz als TRANSPORT_TYPE_WWAN gemeldet wird.
Wenn Geräteimplementierungen eine einzelne IP Multimedia Subsystem-Registrierung (IMS) für die Funktionen des Multimedia-Telefoniediensts (Multimedia Telephony Service, MMTEL) und den Rich Communication Service (RCS) unterstützen und erwartet werden, dass sie die Anforderungen des Mobilfunkanbieters hinsichtlich der Verwendung einer einzigen IMS-Registrierung für den gesamten IMS-Signalisierungstraffic erfüllen, gilt Folgendes:
- [C-5-1] MÜSSEN das Funktions-Flag
android.hardware.telephony.ims
deklarieren und eine vollständige Implementierung der ImsService API sowohl für MMTEL als auch für die RCS User Capability Exchange API bereitstellen. - [C-5-2] MÜSSEN das Funktions-Flag
android.hardware.telephony.ims.singlereg
angeben und eine vollständige Implementierung der SipTransport API, der GbaService API, der Angabe dedizierter Inhaber über IRadio 1.6 HAL und der Bereitstellung über den Auto Configuration Server (ACS) oder andere proprietäre Bereitstellungsmechanismen mit der IMS Configuration API bereitstellen.
Wenn Geräteimplementierungen die Funktion android.hardware.telephony
melden, dann:
- [C-6-1]
SmsManager#sendTextMessage
undSmsManager#sendMultipartTextMessage
MÜSSEN zu entsprechenden Aufrufen vonCarrierMessagingService
führen, um SMS-Funktionen bereitzustellen.SmsManager#sendMultimediaMessage
undSmsManager#downloadMultimediaMessage
MÜSSEN zu entsprechenden Aufrufen anCarrierMessagingService
zur Bereitstellung von Multimedia-Messaging-Funktionen führen. - [C-6-2] Die von
android.provider.Telephony.Sms#getDefaultSmsPackage
angegebene Anwendung muss beim Senden und Empfangen von SMS und MMS SmsManager APIs verwenden. Die AOSP-Referenzimplementierung in Paketen, Anwendungen und Messaging erfüllt diese Anforderung. - [C-6-3] Die Anwendung, die auf
Intent#ACTION_DIAL
antwortet, muss die Eingabe beliebiger Dialer-Codes im Format*#*#CODE#*#*
unterstützen und eine entsprechendeTelephonyManager#ACTION_SECRET_CODE
-Übertragung auslösen. - [C-6-4] Die Anwendung, die auf
Intent#ACTION_DIAL
antwortet, mussVoicemailContract.Voicemails#TRANSCRIPTION
verwenden, um Nutzern die visuelle Sprache-zu-Text-Transkription von Mailboxnachrichten anzuzeigen, wenn sie visuelle Transkriptionen von Mailboxnachrichten unterstützt. - [C-6-5] MÜSSEN alle SubscriptionInfo mit entsprechenden Gruppen-UUIDs als einzelnes Abo in allen für Nutzer sichtbaren Angeboten, die SIM-Karteninformationen anzeigen und steuern, darstellen. Beispiele für solche Angebote sind Einstellungen, die mit
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
oderEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
übereinstimmen. - [C-6-6] DÜRFEN die Steuerung von SubscriptionInfo mit einer Gruppen-UUID und einem opportunistischen Bit ungleich null in für Nutzer sichtbaren Angeboten, die die Konfiguration oder Kontrolle von SIM-Karteneinstellungen ermöglichen, NICHT anzeigen oder erlauben.
Wenn die Geräteimplementierungen die Funktion android.hardware.telephony
melden und eine Systemstatusleiste bieten, gehe so vor:
- [C-7-1] MÜSSEN für eine bestimmte Gruppen-UUID ein repräsentatives aktives Abo auswählen, das dem Nutzer in allen Angeboten mit SIM-Statusinformationen angezeigt wird. Beispiele für solche Angebote sind das Symbol für das Mobilfunksignal in der Statusleiste oder die Kachel „Schnelleinstellungen“.
- [C-SR-1] Es wird dringend empfohlen, dass das repräsentative Abo als Abo mit aktiven Daten ausgewählt wird, es sei denn, mit dem Gerät wird ein Sprachanruf getätigt. Während dieses Zeitraums wird UNBEDINGT empfohlen, dass das repräsentative Abo das aktive Sprachabo ist.
Wenn Geräteimplementierungen die Funktion android.hardware.telephony
melden, dann:
- [C-6-7] MUSS für jeden UICC gemäß ETSI TS 102 221 die maximale Anzahl logischer Kanäle (insgesamt 20) öffnen und gleichzeitig verwenden können.
- [C-6-8] DÜRFEN KEINE der folgenden Verhaltensweisen auf aktive Mobilfunkanbieter-Apps (wie durch
TelephonyManager#getCarrierServicePackageName
festgelegt) automatisch oder ohne ausdrückliche Bestätigung durch den Nutzer angewendet werden:- Netzwerkzugriff widerrufen oder einschränken
- Berechtigungen widerrufen
- Die Ausführung von Apps im Hintergrund oder im Vordergrund über die vorhandenen Energieverwaltungsfunktionen von AOSP hinaus einschränken
- App deaktivieren oder deinstallieren
Wenn Geräteimplementierungen die Funktion android.hardware.telephony
melden und alle aktiven, nicht opportunistischen Abos, die eine Gruppen-UUID teilen, deaktiviert, physisch vom Gerät entfernt oder als opportunistisch gekennzeichnet werden, gilt für das Gerät Folgendes:
- [C-8-1] MÜSSEN automatisch alle verbleibenden aktiven opportunistischen Abos in derselben Gruppe deaktivieren.
Wenn Geräteimplementierungen GSM-Telefonie, aber keine CDMA-Telefonie umfassen, gilt Folgendes:
- [C-9-1] DARF NICHT
PackageManager#FEATURE_TELEPHONY_CDMA
deklarieren. - [C-9-2] MÜSSEN bei Versuchen, 3GPP2-Netzwerktypen in bevorzugten oder zulässigen Bitmasken des Netzwerktyps festzulegen, eine
IllegalArgumentException
ausgeben. - [C-9-3] MUSS einen leeren String aus
TelephonyManager#getMeid
zurückgeben.
Wenn die Geräteimplementierungen eUICCs mit mehreren Ports und Profilen unterstützen, gilt Folgendes:
- [C-10-1] MUSS das Feature-Flag
android.hardware.telephony.euicc.mep
deklarieren.
7.4.1.1 Kompatibilität mit Nummernblockierungen
Wenn Geräteimplementierungen die Funktion android.hardware.telephony.calling
melden, geschieht Folgendes:
- [C-1-1] MUSS die Unterstützung für das Blockieren von Nummern enthalten.
- [C-1-2] MÜSSEN
BlockedNumberContract
und die entsprechende API vollständig implementieren, wie in der SDK-Dokumentation beschrieben. [C-1-3] MÜSSEN alle Anrufe und Nachrichten von einer Telefonnummer in „BlockingNumberProvider“ ohne Interaktion mit Apps blockieren. Die einzige Ausnahme ist, wenn die Blockierung von Nummern vorübergehend aufgehoben wird, wie in der SDK-Dokumentation beschrieben.
[C-1-4] MÜSSEN für einen blockierten Anruf in den Plattformanbieter der Anrufliste schreiben und Anrufe mit
BLOCKED_TYPE
aus der Standardansicht der Anrufliste in der vorinstallierten Telefon-App herausfiltern.[C-1-5] DARF bei einer blockierten Nachricht NICHT an den Telefonieanbieter schreiben.
[C-1-6] MÜSSEN eine UI zur Verwaltung blockierter Nummern implementieren, die mit dem von der Methode
TelecomManager.createManageBlockedNumbersIntent()
zurückgegebenen Intent geöffnet wird.[C-1-7] DÜRFEN sekundäre Nutzer NICHT erlauben, die blockierten Nummern auf dem Gerät anzusehen oder zu bearbeiten, da die Android-Plattform davon ausgeht, dass der primäre Nutzer die vollständige Kontrolle über die Telefoniedienste auf dem Gerät hat (eine Instanz). Alle UI-Elemente in Zusammenhang mit Blockierungen MÜSSEN für sekundäre Nutzer ausgeblendet sein und die Sperrliste MÜSSEN weiterhin berücksichtigt werden.
SOLLTEN Sie die blockierten Nummern zum Anbieter migrieren, wenn ein Gerät auf Android 7.0 aktualisiert wird.
SOLLTE Nutzern die Möglichkeit bieten, blockierte Anrufe in der vorinstallierten Telefon-App anzuzeigen.
7.4.1.2 Telekommunikations-API
Wenn Geräteimplementierungen android.hardware.telephony.calling
melden, geschieht Folgendes:
- [C-1-1] MUSS die im SDK beschriebenen
ConnectionService
APIs unterstützen. - [C-1-2] MÜSSEN einen neuen eingehenden Anruf anzeigen und dem Nutzer die Möglichkeit bieten, den eingehenden Anruf anzunehmen oder abzulehnen, wenn der Nutzer gerade einen Anruf über eine Drittanbieter-App durchführt, die die über
CAPABILITY_SUPPORT_HOLD
angegebene Hold-Funktion nicht unterstützt. - [C-1-3] MUSS eine Anwendung haben, in der InCallService implementiert ist.
[C-SR-1] Es wird dringend empfohlen, den Nutzer darüber zu informieren, dass ein eingehender Anruf abgebrochen wird, wenn er einen eingehenden Anruf annimmt.
Die AOSP-Implementierung erfüllt diese Anforderungen durch eine Vorabbenachrichtigung, die dem Nutzer mitteilt, dass der Annehmen eines eingehenden Anrufs dazu führt, dass der andere Anruf abgebrochen wird.
[C-SR-2] Es wird dringend empfohlen, die Standard-Telefon-App vorab zu laden, die einen Anruflisteneintrag und den Namen einer Drittanbieter-App in der Anrufliste anzeigt, wenn die Drittanbieter-App den zusätzlichen Schlüssel
EXTRA_LOG_SELF_MANAGED_CALLS
auf derPhoneAccount
auftrue
festlegt.[C-SR-3] wird dringend empfohlen, die
KEYCODE_MEDIA_PLAY_PAUSE
- undKEYCODE_HEADSETHOOK
-Ereignisse des Headsets für dieandroid.telecom
APIs so zu verarbeiten:- Rufen Sie
Connection.onDisconnect()
auf, wenn während eines laufenden Anrufs ein kurzes Drücken des Schlüsselereignisses erkannt wird. - Rufen Sie
Connection.onAnswer()
auf, wenn bei einem eingehenden Anruf nur kurzes Drücken des Schlüsselereignisses erkannt wird. - Rufen Sie
Connection.onReject()
auf, wenn bei einem eingehenden Anruf langes Drücken des Schlüsselereignisses erkannt wird. - Stummschaltung des
CallAudioState
aktivieren oder deaktivieren.
- Rufen Sie
7.4.1.3 Mobilfunk-NAT-T-Keepalive-Abladung
Geräteimplementierungen:
- SOLLTEN die Unterstützung für die Keepalive-Auslagerung über Mobilfunk beinhalten.
Wenn Geräteimplementierungen die Unterstützung für die Cell-Keepalive-Auslagerung beinhalten und die Funktion für Drittanbieter-Apps verfügbar machen, geschieht Folgendes:
- [C-1-1] MUSS die SocketKeepAlive API unterstützen.
- [C-1-2] MUSS mindestens einen gleichzeitigen Keepalive-Slot über das Mobilfunknetz unterstützen.
- [C-1-3] MÜSSEN so viele gleichzeitige Mobilfunk-Keepalive-Slots unterstützen, wie vom Mobilfunk-HAL unterstützt.
- [C-SR-1] Es wird dringend empfohlen, mindestens drei Mobilfunk-Keepalive-Slots pro Funkinstanz zu unterstützen.
Wenn Geräteimplementierungen die Mobilfunk-Keepalive-Auslagerung nicht unterstützen, geschieht Folgendes:
- [C-2-1] MUSS ERROR_UNSUPPORTED zurückgeben.
7.4.2 IEEE 802.11 (Wi-Fi)
Geräteimplementierungen:
- SOLLTEN eine oder mehrere 802.11-Formulare unterstützen.
Wenn Geräteimplementierungen 802.11 unterstützen und die Funktionalität einer Drittanbieter-App zur Verfügung stellen, geschieht Folgendes:
- [C-1-1] MÜSSEN die entsprechende Android API implementieren.
- [C-1-2] MÜSSEN das Hardwarefunktions-Flag
android.hardware.wifi
melden. - [C-1-3] MÜSSEN die Multicast API wie in der SDK-Dokumentation beschrieben implementieren.
- [C-1-4] MUSS Multicast-DNS (mDNS) unterstützen und DARF KEINE mDNS-Pakete (224.0.0.251 oder ff02::fb) zu jedem Zeitpunkt, auch wenn sich der Bildschirm nicht in einem aktiven Zustand befindet, filtern, es sei denn, das Löschen oder Filtern dieser Pakete ist notwendig, um in den für den Zielmarkt erforderlichen Bereichen des Stromverbrauchs zu bleiben.
Für Android TV-Geräteimplementierungen, auch im Stand-by-Modus. - [C-1-5] DARF NICHT den API-Methodenaufruf
WifiManager.enableNetwork()
als ausreichenden Hinweis zum Wechseln des derzeit aktivenNetwork
-Objekts betrachten, das standardmäßig für den Anwendungstraffic verwendet und vonConnectivityManager
-API-Methoden wiegetActiveNetwork
undregisterDefaultNetworkCallback
zurückgegeben wird. Mit anderen Worten: Sie KÖNNEN den Internetzugriff von anderen Netzwerkanbietern (z.B. mobile Daten) nur deaktivieren, wenn sie erfolgreich nachweisen können, dass das WLAN den Internetzugriff bereitstellt. - [C-1-6] Es wird dringend empfohlen, beim Aufruf der API-Methode
ConnectivityManager.reportNetworkConnectivity()
den Internetzugriff aufNetwork
neu zu bewerten und zu einem anderen verfügbaren Netzwerk (z.B. mobilen Daten) zu wechseln, sobald die Bewertung ergibt, dass das aktuelleNetwork
keinen Internetzugriff mehr bietet. - [C-1-7] MÜSSEN die MAC-Quelladresse und die Sequenznummer der Prüfungsanfrageframes einmal zu Beginn jedes Scans zufällig anordnen, während STA getrennt wird.
- [C-1-8] MUSS eine konsistente MAC-Adresse verwenden (MAC-Adresse SOLLTE NICHT nach der Hälfte des Scans zufällig angeordnet werden).
- [C-1-9] MÜSSEN die Sequenznummer der Prüfanfragen in einem Scan wie gewohnt (sequentiell) zwischen den Prüfanfragen iterieren.
- [C-1-10] MÜSSEN die Sequenznummer der Prüfungsanfrage zwischen der letzten Prüfungsanfrage eines Scans und der ersten Prüfungsanfrage des nächsten Scans zufällig anordnen.
- [C-SR-1] Es wird dringend empfohlen, die MAC-Quelladresse, die für die gesamte STA-Kommunikation mit einem Zugangspunkt (Access Point, AP) verwendet wird, beim Zuweisen und Verknüpfen zufällig zu wählen.
- Das Gerät MÜSSEN für jede SSID (FQDN für Passpoint) eine andere zufällige MAC-Adresse verwenden, mit der es kommuniziert.
- Das Gerät MÜSSEN dem Nutzer eine Option zum Steuern der Randomisierung pro SSID (FQDN für Passpoint) mit nicht zufälligen und zufälligen Optionen bieten und MÜSSEN den Standardmodus für neue WLAN-Konfigurationen festlegen.
- [C-SR-2] Es wird dringend empfohlen, für jeden von ihm erstellten Zugangspunkt eine zufällige BSSID zu verwenden.
- Die MAC-Adresse MUSS für jede vom ZP verwendete SSID zufällig ausgewählt und beibehalten werden.
- Über das GERÄT können Nutzer diese Funktion deaktivieren. Wenn eine solche Option angegeben wird, MUSS die Zufallsauswahl standardmäßig aktiviert sein.
Wenn Geräteimplementierungen den WLAN-Energiesparmodus gemäß der Definition im IEEE 802.11-Standard unterstützen, gilt Folgendes:
- SOLLTEN SIE den WLAN-Energiesparmodus deaktivieren, wenn eine App eine
WIFI_MODE_FULL_HIGH_PERF
- oderWIFI_MODE_FULL_LOW_LATENCY
-Sperre über dieWifiManager.createWifiLock()
- undWifiManager.WifiLock.acquire()
-APIs erhält und die Sperre aktiv ist. - [C-3-2] Die durchschnittliche Umlauflatenz zwischen dem Gerät und einem Zugangspunkt, während sich das Gerät im Modus „WLAN-Sperre mit niedriger Latenz“ (
WIFI_MODE_FULL_LOW_LATENCY
) befindet, MUSS kleiner sein als die Latenz während eines Modus für Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] wird dringend empfohlen, die WLAN-Roundtrip-Latenz zu minimieren, wenn eine Sperre mit niedriger Latenz (
WIFI_MODE_FULL_LOW_LATENCY
) erkannt wird und wirksam wird.
Wenn Geräteimplementierungen WLAN unterstützen und zur Standortermittlung WLAN verwenden, gilt Folgendes:
- [C-2-1] MÜSSEN eine Nutzermöglichkeit zum Aktivieren/Deaktivieren des Werts bieten, der über die API-Methode
WifiManager.isScanAlwaysAvailable
gelesen wird.
7.4.2.1 Wi-Fi Direct
Geräteimplementierungen:
- SOLLTE Unterstützung für Wi-Fi Direct (Wi-Fi Peer-to-Peer) beinhalten.
Wenn Geräteimplementierungen Wi-Fi Direct unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die entsprechende Android API wie in der SDK-Dokumentation beschrieben implementieren.
- [C-1-2] MÜSSEN die Hardwarefunktion
android.hardware.wifi.direct
melden. - [C-1-3] MUSS den normalen WLAN-Betrieb unterstützen.
- [C-1-4] MUSS die gleichzeitige Verwendung von Wi-Fi und Wi-Fi Direct unterstützen.
- [C-SR-1] Es wird dringend empfohlen, die MAC-Quelladresse für alle neuen Wi-Fi Direct-Verbindungen zufällig zu bestimmen.
7.4.2.2 WLAN: Tunneled Direct Link-Einrichtung
Geräteimplementierungen:
- SOLLTE Unterstützung für Wi-Fi Tunneled Direct Link Setup (TDLS) beinhalten, wie in der Android SDK-Dokumentation beschrieben.
Wenn Geräteimplementierungen TDLS und TDLS durch die WiFiManager API unterstützen, geschieht Folgendes:
- [C-1-1] MÜSSEN die Unterstützung für TDLS über
WifiManager.isTdlsSupported
deklarieren. - SOLLTEN TDLS nur verwenden, wenn es möglich UND vorteilhaft ist.
- SOLLTEN heuristisch sein und KEIN TDLS verwenden, wenn die Leistung geringer sein könnte als über den WLAN-Zugangspunkt.
7.4.2.3 WLAN-fähig
Geräteimplementierungen:
- SOLLTE Support für Wi-Fi Aware beinhalten.
Wenn Geräteimplementierungen Wi-Fi Aware unterstützen und die Funktion über Drittanbieter-Apps verfügbar machen, gilt Folgendes:
- [C-1-1] MÜSSEN die
WifiAwareManager
APIs wie in der SDK-Dokumentation beschrieben implementieren. - [C-1-2] MÜSSEN das Funktions-Flag
android.hardware.wifi.aware
deklarieren. - [C-1-3] MUSS die gleichzeitige Verwendung von WLAN und Wi-Fi Aware unterstützen.
- [C-1-4] MÜSSEN die Adresse der Wi-Fi Aware-Verwaltungsoberfläche in Intervallen von maximal 30 Minuten zufällig und immer dann zufällig anordnen, wenn Wi-Fi Aware aktiviert ist, es sei denn, es wird ein Aware-Entfernungsvorgang ausgeführt oder ein Aware-Datenpfad ist aktiv. Eine Randomisierung wird nicht erwartet, solange der Datenpfad aktiv ist.
Wenn Geräteimplementierungen die in Abschnitt 7.4.2.5 beschriebenen Unterstützung von „Wi-Fi Aware“ und „WLAN-Standort“ unterstützen und diese Funktionen für Drittanbieter-Apps verfügbar machen, dann gilt:
- [C-2-1] MÜSSEN die APIs zur Standorterkennung implementieren: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm und onServiceDiscoveredWithinRange.
7.4.2.4 WLAN-Passpoint
Wenn Geräteimplementierungen 802.11 (WLAN) unterstützen, gilt Folgendes:
- [C-1-1] MUSS Unterstützung für Wi-Fi Passpoint beinhalten.
- [C-1-2] MÜSSEN die Passpoint-bezogenen
WifiManager
APIs wie in der SDK-Dokumentation beschrieben implementieren. - [C-1-3] MÜSSEN den IEEE 802.11u-Standard unterstützen, insbesondere in Bezug auf die Netzwerkerkennung und -auswahl, z. B. Generic Advertising Service (GAS) und Access Network Query Protocol (ANQP).
- [C-1-4] MÜSSEN das Funktions-Flag „
android.hardware.wifi.passpoint
“ deklarieren. - [C-1-5] MÜSSEN der AOSP-Implementierung folgen, um Passpoint-Netzwerke zu erkennen, abzugleichen und mit ihnen zu verknüpfen.
- [C-1-6] MUSS mindestens die folgenden Gerätebereitstellungsprotokolle gemäß Definition im Wi-Fi Alliance Passpoint R2 unterstützen: EAP-TTLS-Authentifizierung und SOAP-XML.
- [C-1-7] MÜSSEN das AAA-Serverzertifikat wie in der Spezifikation von Hotspot 2.0 R3 beschrieben verarbeiten.
- [C-1-8] MÜSSEN die Nutzersteuerung der Bereitstellung über die WLAN-Auswahl unterstützen.
- [C-1-9] MÜSSEN Passpoint-Konfigurationen auch nach einem Neustart beibehalten werden.
- [C-SR-1] wird dringend empfohlen, die Funktion zur Annahme von Nutzungsbedingungen zu unterstützen.
- [C-SR-2] wird dringend empfohlen, die Funktion „Informationen zu Veranstaltungsorten“ zu unterstützen.
Wenn ein globaler Nutzersteuerungsschalter mit Passpoint-Deaktivierung verfügbar ist, werden folgende Implementierungen angewendet:
- [C-3-1] MÜSSEN Passpoint standardmäßig aktivieren.
7.4.2.5 WLAN-Standort (WLAN-Umlaufzeit – RTT)
Geräteimplementierungen:
- SOLLTE Unterstützung für WLAN-Standort beinhalten.
Wenn Geräteimplementierungen die Funktion „WLAN-Standort“ unterstützen und die Funktion über Drittanbieter-Apps verfügbar machen, gilt Folgendes:
- [C-1-1] MÜSSEN die
WifiRttManager
APIs wie in der SDK-Dokumentation beschrieben implementieren. - [C-1-2] MÜSSEN das Funktions-Flag
android.hardware.wifi.rtt
deklarieren. - [C-1-3] MÜSSEN die MAC-Quelladresse für jeden RTT-Burst zufällig anordnen, während die WLAN-Schnittstelle, auf der die RTT ausgeführt wird, keinem Zugangspunkt zugeordnet ist.
- [C-1-4] MÜSSEN auf einen Bereich von 2 Metern bei einer Bandbreite von 80 MHz beim 68. Perzentil genau sein (wie mit der kumulativen Verteilungsfunktion berechnet).
- [C-SR-1] Es wird dringend empfohlen, Daten mit einer Genauigkeit von bis zu 1,5 Metern bei einer Bandbreite von 80 MHz beim 68.Perzentil (wie mit der kumulativen Verteilungsfunktion berechnet) zu melden.
7.4.2.6 Wi-Fi Keepalive Offload
Geräteimplementierungen:
- SOLLTEN die Unterstützung für Wi-Fi-Keepalive-Auslagerung umfassen.
Wenn Geräteimplementierungen die Unterstützung für die Wi-Fi-Keepalive-Auslagerung beinhalten und die Funktion für Drittanbieter-Apps verfügbar machen, geschieht Folgendes:
- [C-1-1] MUSS die SocketKeepAlive API unterstützen.
- [C-1-2] MUSS mindestens drei gleichzeitige Keepalive-Slots über WLAN unterstützen
Wenn Geräteimplementierungen die Wi-Fi-Keepalive-Auslagerung nicht unterstützen, geschieht Folgendes:
- [C-2-1] MUSS
ERROR_UNSUPPORTED
zurückgeben.
7.4.2.7 Wi-Fi Easy Connect (Protokoll für die Gerätebereitstellung)
Geräteimplementierungen:
- SOLLTEN Wi-Fi Easy Connect (DPP) unterstützen.
Wenn Geräteimplementierungen Wi-Fi Easy Connect unterstützen und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:
- [C-1-1] MÜSSEN die Methode WifiManager#isEasyConnectSupported()
true
zurückgeben.
7.4.2.8 Validierung des Unternehmens-WLAN-Serverzertifikats
Wenn das WLAN-Serverzertifikat nicht bestätigt oder der Domainname des WLAN-Servers nicht festgelegt ist, werden die Geräte so implementiert:
- [C-SR-1] Es wird dringend empfohlen, dem Nutzer in den Einstellungen nicht die Möglichkeit zu geben, ein Unternehmens-WLAN manuell hinzuzufügen.
7.4.2.9 Vertrauen bei der ersten Verwendung
Wenn Geräteimplementierungen Trust on First Usage (TOFU) unterstützen und dem Nutzer die Definition von WPA-/WPA2-/WPA3-Enterprise-Konfigurationen ermöglichen, gilt Folgendes:
- [C-4-1] MÜSSEN dem Nutzer die Möglichkeit geben, TOFU zu verwenden.
7.4.3 Bluetooth
Wenn Geräteimplementierungen das Bluetooth Audio-Profil unterstützen, gilt Folgendes:
- SOLLTEN erweiterte Audio-Codecs und Bluetooth-Audio-Codecs (z. B. LDAC) unterstützen.
Wenn Geräteimplementierungen HFP, A2DP und AVRCP unterstützen, gilt Folgendes:
- SOLLTEN mindestens 5 verbundene Geräte unterstützen.
Wenn in Geräteimplementierungen die Funktion android.hardware.vr.high_performance
deklariert wird, geschieht Folgendes:
- [C-1-1] MÜSSEN Bluetooth 4.2 und Bluetooth LE-Datenlängenerweiterung unterstützen.
Android unterstützt Bluetooth und Bluetooth Low Energy.
Wenn 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. - SOLLTEN für das Gerät relevante Bluetooth-Profile wie A2DP, AVRCP, OBEX, HFP usw. implementieren.
Wenn Geräteimplementierungen Bluetooth Low Energy (BLE) unterstützen, gilt Folgendes:
- [C-3-1] MÜSSEN die Hardwarefunktion
android.hardware.bluetooth_le
deklarieren. - [C-3-2] MÜSSEN die auf GATT (allgemeinen Attributprofil) basierenden Bluetooth-APIs aktivieren, wie in der SDK-Dokumentation und unter android.bluetooth beschrieben.
- [C-3-3] MÜSSEN den richtigen Wert für
BluetoothAdapter.isOffloadedFilteringSupported()
melden, um anzugeben, ob die Filterlogik für die API-Klassen ScanFilter implementiert ist. - [C-3-4] MÜSSEN den richtigen Wert für
BluetoothAdapter.isMultipleAdvertisementSupported()
melden, um anzugeben, ob energiesparende Werbung unterstützt wird. [C-3-5] MÜSSEN ein Zeitlimit von 15 Minuten (Resolvable Private Address) (RPA) implementieren und die Adresse bei einem Zeitlimit rotieren, um die Privatsphäre der Nutzer zu schützen, wenn das Gerät aktiv BLE zum Scannen oder Werben verwendet. Um Timing-Angriffe zu verhindern, MÜSSEN außerdem die Zeitüberschreitungsintervalle ebenfalls zufällig zwischen 5 und 15 Minuten liegen.
SOLLTEN bei der Implementierung der ScanFilter API die Übertragung der Filterlogik auf den Bluetooth-Chipsatz unterstützen.
SOLLTEN die Übertragung des Batch-Scans auf den Bluetooth-Chipsatz unterstützen.
SOLLTEN mehrere Anzeigen mit mindestens 4 Anzeigenflächen unterstützen.
Wenn Geräteimplementierungen Bluetooth LE unterstützen und Bluetooth LE für die Standortsuche verwenden, gilt Folgendes:
- [C-4-1] MÜSSEN eine Nutzeroption zum Aktivieren/Deaktivieren des Werts bereitstellen, der über die
BluetoothAdapter.isBleScanAlwaysAvailable()
der System-API gelesen wird.
Wenn Geräteimplementierungen Bluetooth LE und Hörgeräteprofile unterstützen, wie unter Unterstützung von Hörgeräten über Bluetooth LE beschrieben, gilt Folgendes:
- [C-5-1] MÜSSEN
true
für BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) zurückgeben.
Wenn Geräteimplementierungen Bluetooth oder Bluetooth Low Energy unterstützen, gilt Folgendes:
- [C-6-1] MÜSSEN den Zugriff auf Bluetooth-Metadaten (z. B. Scanergebnisse) einschränken, die zur Ableitung des Gerätestandorts verwendet werden könnten, es sei denn, die anfragende App hat die Berechtigungsprüfung
android.permission.ACCESS_FINE_LOCATION
basierend auf ihrem aktuellen Vorder-/Hintergrundstatus erfolgreich bestanden.
Wenn Geräteimplementierungen Bluetooth oder Bluetooth Low Energy unterstützen und das App-Manifest keine Erklärung des Entwicklers enthält, dass der Standort nicht von Bluetooth abgeleitet wird, gehe so vor:
- [C-6-2] MÜSSEN den Bluetooth-Zugriff hinter dem
android.permission.ACCESS_FINE_LOCATION
steuern.
Wenn Geräteimplementierungen true
für die BluetoothAdapter.isLeAudioSupported()
API zurückgeben, geschieht Folgendes:
- [C-7-1] MUSS den Unicast-Client unterstützen.
- [C-7-2] MUSS 2 Mio. PHY unterstützen.
- [C-7-3] MUSS LE Extended-Werbung unterstützen.
- [C-7-4] MUSS mindestens zwei CIS-Verbindungen in einem CIG unterstützen.
- [C-7-5] MÜSSEN BAP-Unicast-Client, CSIP-Set-Koordinator, MCP-Server, VCP-Controller und CCP-Server gleichzeitig aktiviert werden.
- [C-SR-1] Es wird dringend empfohlen, den HAP-Unicast-Client zu aktivieren.
Wenn Geräteimplementierungen true
für die BluetoothAdapter.isLeAudioBroadcastSourceSupported()
API zurückgeben, geschieht Folgendes:
- [C-8-1] MUSS mindestens zwei BIS-Links in einem BIG unterstützen.
- [C-8-2] MÜSSEN die BAP-Broadcast-Quelle und der BAP-Broadcast-Assistent gleichzeitig aktivieren.
- [C-8-3] MUSS Periodic Advertising von LE unterstützen.
Wenn Geräteimplementierungen true
für die BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API zurückgeben, geschieht Folgendes:
- [C-9-1] MUSS Past (Periodic Advertising Sync Transfer) unterstützen.
- [C-9-2] MUSS Periodic Advertising von LE unterstützen.
Wenn in Geräteimplementierungen FEATURE_BLUETOOTH_LE
deklariert wird, gilt Folgendes:
- [C-10-1] MÜSSEN RSSI-Messungen bei 95% der Messungen in 1 m Entfernung zu einem Referenzgerät, das
ADVERTISE_TX_POWER_HIGH
in direkter Sichtweite sendet, zwischen +/-9 dB liegen. [C-10-2] MÜSSEN Rx/Tx-Korrekturen aufnehmen, um Abweichungen pro Kanal zu reduzieren, sodass die Messungen auf jedem der drei Kanäle und auf jeder Antenne (falls mehrere verwendet) für 95% der Messungen im Bereich von +/-3 dB zueinander liegen.
[C-SR-2] Es wird dringend empfohlen, den Rx-Versatz zu messen und zu kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei 1 m Abstand zu einem Referenzgerät, das Daten sendet, bei
ADVERTISE_TX_POWER_HIGH
beträgt. Die Geräte sind dabei auf parallelen Ebenen mit Bildschirmen ausgerichtet, die in die gleiche Richtung zeigen.[C-SR-3] Es wird dringend empfohlen, den Tx-Versatz zu messen und zu kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -60 dBm +/-10 dB liegt, wenn das Scannen von einem Referenzgerät, das in 1 m Entfernung positioniert ist, und die Übertragung an
ADVERTISE_TX_POWER_HIGH
erfolgt. Dabei sind die Geräte so ausgerichtet, dass sie sich auf parallelen Ebenen befinden und Bildschirme in die gleiche Richtung zeigen.Die Anforderungen [C-10-3] und [C-10-4] wurden in 2.2.1. Hardware
- [C-10-3] MÜSSEN den Rx-Offset messen und kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -55 dBm +/-10 dB in 1 m Entfernung von einem Referenzgerät liegt, das bei
ADVERTISE_TX_POWER_HIGH
sendet. - [C-10-4] MÜSSEN den Tx-Offset messen und kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -55 dBm +/-10 dB liegt, wenn beim Scannen von einem Referenzgerät, das in einer Entfernung von 1 m positioniert ist, und bei der Übertragung bei
ADVERTISE_TX_POWER_HIGH
liegt.
Es wird dringend empfohlen, die unter Anforderungen für die Anwesenheitskalibrierung angegebenen Schritte zur Einrichtung der Messung zu befolgen.
Wenn Geräteimplementierungen die Bluetooth-Version 5.0 unterstützen, gilt Folgendes:
- [C-SR-4] wird dringend empfohlen, Support in folgenden Bereichen bereitzustellen:
- LE 2 Mio. PHY
- LE-Codec PHY
- LE-Werbeerweiterung
- Regelmäßige Werbung
- Mindestens 10 Anzeigensätze
- Mindestens 8 gleichzeitige LE-Verbindungen. Jede Verbindung kann einer der Rollen von Verbindungstopologien zugewiesen sein.
- LE-Link-Layer-Datenschutz
- Eine Auflöseliste von mindestens 8 Einträgen
7.4.4 Nahfeldkommunikation
Geräteimplementierungen:
- SOLLTEN einen Transceiver und die zugehörige Hardware für die Nahfeldkommunikation (NFC) enthalten.
- [C-0-1] MÜSSEN die APIs
android.nfc.NdefMessage
undandroid.nfc.NdefRecord
implementieren, auch wenn sie keine NFC-Unterstützung bieten oder dieandroid.hardware.nfc
-Funktion nicht deklarieren, da die Klassen ein protokollunabhängiges Datendarstellungsformat darstellen.
Wenn Geräteimplementierungen NFC-Hardware enthalten und für Drittanbieter-Apps verfügbar sein sollen, geschieht Folgendes:
- [C-1-1] MÜSSEN die Funktion
android.hardware.nfc
über die Methodeandroid.content.pm.PackageManager.hasSystemFeature()
melden. - MÜSSEN NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können:
- [C-1-2] MUSS als NFC-Forumsleser/-schreiber (gemäß der technischen Spezifikation des NFC-Forums NFCForum-TS-DigitalProtocol-1.0) über die folgenden NFC-Standards fungieren können:
- NfcA (ISO14443-3A)
- NFCB (ISO 14443-3B)
- NFCF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- NFC-Forum Tag-Typen 1, 2, 3, 4, 5 (definiert vom NFC-Forum)
[C-SR-1] EMPFOHLEN, NDEF-Nachrichten sowie Rohdaten über die folgenden NFC-Standards zu lesen und zu schreiben. Die NFC-Standards gelten zwar als UNBEDINGT EMPFOHLEN, in der Kompatibilitätsdefinition für eine zukünftige Version ist jedoch geplant, sie in "MÜSSEN" zu ändern. Diese Standards sind in dieser Version optional, werden aber in zukünftigen Versionen erforderlich sein. Bestehenden und neuen Geräten, auf denen diese Android-Version ausgeführt wird, wird dringend empfohlen, diese Anforderungen jetzt zu erfüllen, damit ein Upgrade auf die zukünftigen Plattform-Releases möglich ist.
[C-1-13] MUSS im NFC-Erkennungsmodus alle unterstützten Technologien abfragen.
Muss sich im NFC-Erkennungsmodus befinden, während das Gerät aktiv ist, der Bildschirm aktiv und der Sperrbildschirm entsperrt ist.
SOLLTEN Barcode und URL (falls codiert) von Thinfilm-NFC-Barcode-Produkten lesen können.
Hinweis: Öffentlich verfügbare Links sind für die oben genannten Spezifikationen für JIS, ISO und NFC im Forum nicht verfügbar.
Android unterstützt den NFC-Modus "Host Card Emulation" (HCE).
Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz (für NfcA und/oder NfcB) enthalten und das Routing von Anwendungs-IDs (AID) unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN die
android.hardware.nfc.hce
-Funktionskonstante melden. - [C-2-2] MÜSSEN die NFC HCE APIs unterstützen, wie im Android SDK definiert.
Wenn Geräteimplementierungen einen NFC-Controller-Chipsatz enthalten, der HCE für NfcF unterstützt, und die Funktion für Drittanbieteranwendungen implementiert wird, geschieht Folgendes:
- [C-3-1] MÜSSEN die
android.hardware.nfc.hcef
-Funktionskonstante melden. - [C-3-2] MÜSSEN die NfcF Card Emulation APIs wie im Android SDK definiert implementieren.
Wenn Geräteimplementierungen allgemeine NFC-Unterstützung wie in diesem Abschnitt beschrieben und MIFARE-Technologien (MIFARE Classic, MIFARE Ultralight, NDEF auf MIFARE Classic) in der Rolle „Reader/Writer“ unterstützen, gilt Folgendes:
- [C-4-1] MÜSSEN die entsprechenden Android APIs gemäß der Dokumentation des Android SDK implementieren.
- [C-4-2] MÜSSEN das Feature
com.nxp.mifare
über die Methodeandroid.content.pm.PackageManager.hasSystemFeature
() melden. Beachten Sie, dass dies keine Android-Standardfunktion ist und daher nicht als Konstante in derandroid.content.pm.PackageManager
-Klasse angezeigt wird.
7.4.5 Netzwerkprotokolle und APIs
7.4.5.1 Minimale Netzwerkfähigkeit
Geräteimplementierungen:
- [C-0-1] MÜSSEN eine oder mehrere Formen von Datennetzwerken unterstützen. Insbesondere MÜSSEN Geräteimplementierungen mindestens einen Datenstandard unterstützen, der 200 Kbit/s oder mehr unterstützen kann. Beispiele für Technologien, die diese Anforderung erfüllen, sind EDGE, HSPA, EV-DO, 802.11g, Ethernet und Bluetooth PAN.
- SOLLTE außerdem Unterstützung für mindestens einen gängigen WLAN-Standard bieten, z. B. 802.11 (Wi-Fi), wenn ein physischer Netzwerkstandard (z. B. Ethernet) die primäre Datenverbindung ist.
- KANN mehr als eine Form der Datenverbindung implementieren.
7.4.5.2 IPv6
Geräteimplementierungen:
- [C-0-2] MÜSSEN einen IPv6-Netzwerkstack enthalten und die IPv6-Kommunikation über die verwalteten APIs wie
java.net.Socket
undjava.net.URLConnection
sowie die nativen APIs wieAF_INET6
-Sockets unterstützen. - [C-0-3] MUSS IPv6 standardmäßig aktivieren.
- MÜSSEN sicherstellen, dass die IPv6-Kommunikation so zuverlässig ist wie IPv4, zum Beispiel:
- [C-0-4] MÜSSEN die IPv6-Verbindungen im Stromsparmodus aufrechterhalten.
- [C-0-5] Die Ratenbegrenzung DARF NICHT zu einer Unterbrechung der IPv6-Verbindung des Geräts in einem IPv6-kompatiblen Netzwerk führen, das eine RA-Lebensdauer von mindestens 180 Sekunden verwendet.
- MÜSSEN sicherstellen, dass die IPv6-Kommunikation so zuverlässig ist wie IPv4, zum Beispiel:
- [C-0-6] MÜSSEN Anwendungen von Drittanbietern eine direkte IPv6-Verbindung zum Netzwerk bereitstellen, wenn sie mit einem IPv6-Netzwerk verbunden sind. Dabei darf keine Form von Adress- oder Portübersetzung lokal auf dem Gerät erfolgen. Sowohl verwaltete APIs wie
Socket#getLocalAddress
oderSocket#getLocalPort
) als auch NDK APIs wiegetsockname()
oderIPV6_PKTINFO
MÜSSEN die IP-Adresse und den Port zurückgeben, der tatsächlich zum Senden und Empfangen von Paketen im Netzwerk verwendet wird und als Quell-IP und -Port für Internetserver (Webserver) 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] MÜSSEN Dual-Stack- und Nur-IPv6-Betrieb im WLAN unterstützen.
Wenn Geräteimplementierungen Ethernet unterstützen, gilt Folgendes:
- [C-2-1] MUSS Dual-Stack- und Nur-IPv6-Betrieb auf Ethernet unterstützen.
Wenn Geräteimplementierungen mobile Daten unterstützen, gilt Folgendes:
- [C-3-1] MUSS IPv6-Betrieb (nur IPv6 und möglicherweise Dual-Stack) auf Mobilfunk unterstützen.
Wenn Geräteimplementierungen mehr als einen Netzwerktyp unterstützen (z.B. WLAN und mobile Daten).
- [C-4-1] MÜSSEN die oben genannten Anforderungen für jedes Netzwerk gleichzeitig erfüllen, wenn das Gerät gleichzeitig mit mehr als einem Netzwerktyp verbunden ist.
7.4.5.3 Captive Portals
Ein Captive Portal bezieht sich auf ein Netzwerk, das eine Anmeldung erfordert, um Internetzugang zu erhalten.
Wenn Geräteimplementierungen eine vollständige Implementierung von android.webkit.Webview API
bieten, wird Folgendes ausgeführt:
- [C-1-1] MÜSSEN eine Captive Portal-Anwendung bereitstellen, um den Intent
ACTION_CAPTIVE_PORTAL_SIGN_IN
zu verarbeiten und die Anmeldeseite des Captive Portal anzuzeigen. Dazu wird dieser Intent bei Aufruf an die System-APIConnectivityManager#startCaptivePortalApp(Network, Bundle)
gesendet. - [C-1-2] MUSS die Erkennung von Captive Portals durchführen und die Anmeldung über die Captive Portal-Anwendung unterstützen, wenn das Gerät mit einem beliebigen Netzwerktyp verbunden ist, einschließlich Mobilfunk-/Mobilfunknetz, WLAN, Ethernet oder Bluetooth.
- [C-1-3] MUSS die Anmeldung in Captive Portals mit Klartext-DNS unterstützen, wenn das Gerät für den strikten Modus für privates DNS konfiguriert ist.
- [C-1-4] MÜSSEN gemäß der SDK-Dokumentation für
android.net.LinkProperties.getPrivateDnsServerName
undandroid.net.LinkProperties.isPrivateDnsActive
für den gesamten Netzwerkverkehr, der nicht explizit mit dem Captive Portal kommuniziert, verschlüsseltes DNS verwenden. - [C-1-5] MÜSSEN bei der Anmeldung in einem Captive Portal das von Anwendungen verwendete Standardnetzwerk (das von
ConnectivityManager.getActiveNetwork
,ConnectivityManager.registerDefaultNetworkCallback
zurückgegeben und standardmäßig von Java-Netzwerk-APIs wie java.net.Socket und nativen APIs wie connect() verwendet wird) jedem anderen verfügbaren Netzwerk entsprechen, das Internetzugriff bietet (falls verfügbar).
7.4.6 Synchronisierungseinstellungen
Geräteimplementierungen:
- [C-0-1] MÜSSEN die automatische Mastersynchronisierung standardmäßig aktiviert haben, damit die Methode
getMasterSyncAutomatically()
„true“ zurückgibt.
7.4.7 Datensparmodus
Wenn Geräteimplementierungen eine getaktete Verbindung beinhalten, gilt Folgendes:
- [C-SR-1] UNBEDINGT EMPFOHLEN, den Datensparmodus bereitzustellen.
Wenn Geräteimplementierungen den Datensparmodus unterstützen, ist Folgendes möglich:
- [C-1-1] MUSS alle APIs der Klasse
ConnectivityManager
unterstützen, wie in der SDK-Dokumentation beschrieben.
Wenn Geräteimplementierungen den Datensparmodus nicht unterstützen, kann das folgende Gründe haben:
- [C-2-1] MUSS den Wert
RESTRICT_BACKGROUND_STATUS_DISABLED
fürConnectivityManager.getRestrictBackgroundStatus()
zurückgeben. - [C-2-2] DARF NICHT
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
übertragen.
7.4.8 Secure Elemente
Wenn Geräteimplementierungen Open Mobile API-fähige sichere Elemente unterstützen und für Drittanbieter-Apps verfügbar machen, geschieht Folgendes:
[C-1-1] MÜSSEN die verfügbaren Lesegeräte für sichere Elemente über die
android.se.omapi.SEService.getReaders()
API aufzählen.[C-1-2] MÜSSEN die korrekten Funktions-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 undandroid.hardware.se.omapi.sd
für das Gerät mit SD-basierten sicheren Elementen deklarieren.
7.4.9 UWB
Wenn Geräteimplementierungen 802.1.15.4 unterstützen und die Funktionalität einer Drittanbieteranwendung zugänglich machen, gilt Folgendes:
- [C-1-1] MÜSSEN die entsprechende Android API in android.uwb implementieren.
- [C-1-2] MÜSSEN das Hardwarefunktions-Flag „android.hardware.uwb“ melden.
- [C-1-3] MUSS alle relevanten UWB-Profile unterstützen, die in der Android-Implementierung definiert sind.
- [C-1-4] MÜSSEN eine Funktion anbieten, mit der der Nutzer das UWB-Radio ein- oder ausschalten kann.
- [C-1-5] MÜSSEN erzwingen, dass Apps, die die UWB-Funkschnittstelle verwenden, die Berechtigung UWB_RANGING (in der Berechtigungsgruppe NEARBY_GERÄTE) enthalten.
- [C-SR-1] wird dringend empfohlen, die relevanten Konformitäts- und Zertifizierungstests zu bestehen, die von Standardorganisationen wie FIRA, CCC und CSA festgelegt wurden.
- [C-1-6] MÜSSEN bei einer Entfernung von 1 m in einer nicht reflektierenden Kammer bei 95 % der Messungen in der Sichtlinie in einer Entfernung von 1 m zwischen +/-15 cm liegen.
- [C-1-7] MÜSSEN darauf achten, dass der Medianwert der Entfernungsmessungen in 1 m vom Referenzgerät innerhalb von [0,75 m, 1,25 m] liegt, wobei der Ground-Truth-Abstand vom oberen Rand des DUTs gemessen wird.
Das Gerät muss mit dem Display nach oben gehalten und um 45 Grad geneigt sein. - [C-SR-2] wird dringend empfohlen, die unter Anforderungen für die Anwesenheitskalibrierung angegebenen Schritte zur Einrichtung der Messung zu befolgen.
7.5 Kameras
Wenn eine Geräteimplementierung mindestens eine Kamera umfasst, gilt Folgendes:
- [C-1-1] MUSS das Funktions-Flag
android.hardware.camera.any
deklarieren. - [C-1-2] MÜSSEN in einer Anwendung gleichzeitig 3 RGBA_8888-Bitmaps zugewiesen werden, die der Größe der Bilder entsprechen, die der Kamerasensor mit der höchsten Auflösung des Geräts erzeugt, während die Kamera für eine einfache Vorschau und dennoch für Aufnahmen geöffnet ist.
- [C-1-3] MÜSSEN darauf achten, dass die vorinstallierten Standard-Kamera-Anwendungs-Intents
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
oderMediaStore.ACTION_VIDEO_CAPTURE
dafür verantwortlich sind, den Nutzerstandort in den Bildmetadaten zu entfernen, bevor er an die empfangende Anwendung gesendet wird, wenn die empfangende Anwendung nichtACCESS_FINE_LOCATION
hat.
Wenn Geräteimplementierungen die 10-Bit-HDR-Ausgabe unterstützen, gilt Folgendes:
- [C-2-1] MUSS mindestens das HLG-HDR-Profil für jedes Kameragerät unterstützen, das eine 10-Bit-Ausgabe unterstützt.
- [C-2-2] MUSS die 10-Bit-Ausgabe entweder für die primäre rückseitige oder für die primäre Frontkamera unterstützen.
- [C-SR-1] Es wird dringend empfohlen, die 10-Bit-Ausgabe für beide primären Kameras zu unterstützen.
- [C-2-3] MUSS für alle BACKWARD_COMPATIBLE-fähigen physischen Unterkameras einer logischen Kamera und die logische Kamera selbst dieselben HDR-Profile unterstützen.
Für logische Kamerageräte, die 10-Bit-HDR unterstützen und die android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API implementieren, gilt Folgendes:
- [C-3-1] MUSS den Wechsel zwischen allen abwärtskompatiblen physischen Kameras über das Steuerelement
CONTROL_ZOOM_RATIO
der logischen Kamera unterstützen.
7.5.1 Rückkamera
Eine Kamera auf der Rückseite ist eine Kamera, die sich an der Seite des Geräts gegenüber dem Display befindet. Sie nimmt also wie eine herkömmliche Kamera Szenen auf der anderen Seite des Geräts auf.
Neue Anforderungen erstellen
Eine Rückkamera ist eine nach außen gerichtete Kamera, die wie bei einer herkömmlichen Kamera Szenen auf der anderen Seite des Geräts erfasst. Bei Handheld-Geräten ist dies eine Kamera, die sich an der Seite des Geräts gegenüber dem Display befindet.
Neue Anforderungen beenden
Geräteimplementierungen:
- SOLLTE eine Rückkamera enthalten.
Wenn Geräteimplementierungen mindestens eine Kamera auf der Rückseite enthalten, ist Folgendes zu beachten:
- [C-1-1] MÜSSEN die Funktions-Flags
android.hardware.camera
undandroid.hardware.camera.any
melden. - [C-1-2] MUSS eine Auflösung von mindestens 2 Megapixel haben.
- Im Kameratreiber sollte entweder Hardware-Autofokus oder Software-Autofokus implementiert sein (für die Anwendungssoftware transparent).
- KÖNNEN mit Fixfokus oder EDOF-Hardware (erweiterte Tiefenschärfe) ausgestattet sein.
- KANN einen Blitz enthalten.
Wenn die Kamera einen Blitz hat:
- [C-2-1] Die Blitzlampe DARF NICHT eingeschaltet werden, solange eine
android.hardware.Camera.PreviewCallback
-Instanz auf einer Kameravorschauoberfläche registriert ist, es sei denn, die Anwendung hat den Blitz explizit durch Aktivieren der AttributeFLASH_MODE_AUTO
oderFLASH_MODE_ON
einesCamera.Parameters
-Objekts aktiviert. Diese Einschränkung gilt nicht für die integrierte Systemkamera-App des Geräts, sondern nur für Drittanbieter-Apps, dieCamera.PreviewCallback
verwenden.
7.5.2 Frontkamera
Eine Frontkamera ist eine Kamera, die sich an der gleichen Seite des Geräts wie das Display befindet. Das ist eine Kamera, die in der Regel zum Abbilden des Nutzers verwendet wird, z. B. für Videokonferenzen und ähnliche Anwendungen.
Neue Anforderungen erstellen
Eine Frontkamera ist eine Kamera, die in der Regel zum Abbilden des Nutzers verwendet wird, z. B. für Videokonferenzen und ähnliche Anwendungen. Bei Handheld-Geräten ist dies eine Kamera, die sich auf derselben Seite des Geräts wie der Bildschirm befindet.
Neue Anforderungen beenden
Geräteimplementierungen:
- KANN eine Frontkamera enthalten.
Wenn Geräteimplementierungen mindestens eine Frontkamera umfassen, ist Folgendes zu beachten:
- [C-1-1] MÜSSEN die Funktions-Flags
android.hardware.camera.any
undandroid.hardware.camera.front
melden. - [C-1-2] MUSS mindestens eine Auflösung von mindestens VGA (640 x 480 Pixel) haben.
- [C-1-3] DARF KEINE Frontkamera als Standard für die Camera API verwenden und die API NICHT so konfigurieren, dass eine Frontkamera als Standardrückkamera behandelt wird, selbst wenn sie die einzige Kamera des Geräts ist.
- [C-1-4] Die Kameravorschau MÜSSEN horizontal relativ zur von der Anwendung angegebenen Ausrichtung gespiegelt werden, wenn die aktuelle Anwendung ausdrücklich das Drehen des Kameradisplays über einen Aufruf der Methode
android.hardware.Camera.setDisplayOrientation()
angefordert hat. Umgekehrt muss die Vorschau entlang der horizontalen Standardachse des Geräts gespiegelt werden, wenn die aktuelle Anwendung das Drehen des Kameradisplays nicht explizit über einen Aufruf der Methodeandroid.hardware.Camera.setDisplayOrientation()
anfordert. - [C-1-5] DÜRFEN NICHT die endgültig aufgenommenen Standbilder oder Videostreams spiegeln, die an Anwendungs-Callbacks zurückgegeben oder in den Medienspeicher übergeben werden.
- [C-1-6] MÜSSEN das von PostView angezeigte Bild auf dieselbe Weise spiegeln wie der Bildstream der Kameravorschau.
- KÖNNEN Funktionen wie Autofokus, Blitz usw. für Rückkameras enthalten, 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 Nutzereingabe):
- [C-2-1] Die Kameravorschau MUSS horizontal relativ zur aktuellen Ausrichtung des Geräts gespiegelt werden.
7.5.3 Externe Kamera
Neue Anforderungen erstellen
Eine externe Kamera ist eine Kamera, die jederzeit an der Geräteimplementierung angebracht oder von ihr getrennt werden kann und in alle Richtungen zeigen kann, zum Beispiel USB-Kameras.
Neue Anforderungen beenden
Geräteimplementierungen:
- KANN auch Unterstützung für eine externe Kamera beinhalten, die nicht unbedingt immer angeschlossen ist.
Wenn Geräteimplementierungen eine externe Kamera unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die Funktions-Flags für die Plattform
android.hardware.camera.external
undandroid.hardware camera.any
deklarieren. - [C-1-2] MUSS die USB-Videoklasse (UVC 1.0 oder höher) unterstützen, wenn die externe Kamera über den USB-Hostport verbunden wird.
- [C-1-3] MÜSSEN die CTS-Tests der Kamera mit einem angeschlossenen physischen Kameragerät bestehen. Details zu den CTS-Tests für Kameras finden Sie unter source.android.com.
- SOLLTEN Videokomprimierungen wie MJPEG unterstützen, um die Übertragung hochwertiger, nicht codierter Streams (d.h. rohe oder unabhängig komprimierte Bildstreams) zu ermöglichen.
- KANN mehrere Kameras unterstützen.
- KANN die kamerabasierte Videocodierung unterstützen.
Wenn die kamerabasierte Videocodierung unterstützt wird:
- [C-2-1] Ein gleichzeitiger unverschlüsselter / MJPEG-Stream (QVGA oder höhere Auflösung) MUSS für die Geräteimplementierung zugänglich sein.
7.5.4 Verhalten der Camera API
Android umfasst zwei API-Pakete für den Zugriff auf die Kamera. Die neuere API android.hardware.camera2 ermöglicht die Kamerasteuerung auf niedrigerer Ebene für die App. Dazu gehören effiziente Bilderfolge für Zero-Copy-Burst-/Streamingdaten und Steuerungen pro Frame für Belichtung, Verstärkung, Weißabgleichzunahme, Farbkonvertierung, Geräuschunterdrückung, Schärfe und mehr.
Das ältere API-Paket android.hardware.Camera
ist in Android 5.0 als veraltet gekennzeichnet, sollte aber weiterhin für Apps zur Verfügung stehen. Implementierungen von Android-Geräten MÜSSEN die API wie in diesem Abschnitt und im Android SDK beschrieben weiterhin unterstützen.
Alle Funktionen, die in der veralteten Klasse „android.hardware.Camera“ und dem neueren Paket „android.hardware.camera2“ vorkommen, MÜSSEN in beiden APIs gleichwertige Leistung und Qualität haben. Beispielsweise müssen bei gleichwertigen Einstellungen die Geschwindigkeit und Genauigkeit des Autofokus sowie die Qualität der aufgenommenen Bilder identisch sein. Funktionen, die von der unterschiedlichen Semantik der beiden APIs abhängen, müssen nicht unbedingt eine übereinstimmende Geschwindigkeit oder Qualität haben, SOLLTEN aber so genau 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] MUSS
android.hardware.PixelFormat.YCbCr_420_SP
für Vorschaudaten verwenden, die an Anwendungs-Callbacks bereitgestellt werden, wenn eine Anwendungandroid.hardware.Camera.Parameters.setPreviewFormat(int)
nie aufgerufen hat. - [C-0-2] MUSS außerdem im NV21-Codierungsformat vorliegen, wenn eine Anwendung eine
android.hardware.Camera.PreviewCallback
-Instanz registriert, das System die MethodeonPreviewFrame()
aufruft und das Vorschauformat YCbCr_420_SP ist. Die Daten im Byte[] werden anonPreviewFrame()
übergeben. Das heißt, NV21 MUSS die Standardeinstellung sein. - [C-0-3] MUSS das YV12-Format (wie durch die Konstante
android.graphics.ImageFormat.YV12
angegeben) für Kameravorschauen sowohl für Front- als auch für rückseitige Kameras fürandroid.hardware.Camera
unterstützen. Der Hardware-Videoencoder und die Kamera können jedes native Pixelformat verwenden. Die Geräteimplementierung muss jedoch die Konvertierung in YV12 unterstützen. - [C-0-4] MUSS die Formate
android.hardware.ImageFormat.YUV_420_888
undandroid.hardware.ImageFormat.JPEG
als Ausgaben über dieandroid.media.ImageReader
API fürandroid.hardware.camera2
-Geräte unterstützen, die dieREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
-Funktion inandroid.request.availableCapabilities
bewerben. - [C-0-5] MÜSSEN weiterhin die vollständige Camera API implementieren, die in der Android SDK-Dokumentation enthalten ist, unabhängig davon, ob das Gerät über Hardware-Autofokus oder andere Funktionen verfügt. Beispielsweise MÜSSEN Kameras ohne Autofokus weiterhin registrierte
android.hardware.Camera.AutoFocusCallback
-Instanzen aufrufen, auch wenn dies keine Relevanz für eine Kamera ohne Autofokus hat. Dies gilt für Frontkameras. Auch wenn die meisten Frontkameras beispielsweise keinen Autofokus unterstützen, müssen die API-Callbacks wie beschrieben „gefälscht“ werden. - [C-0-6] MÜSSEN jeden Parameternamen erkennen und berücksichtigen, der in den Klassen
android.hardware.Camera.Parameters
undandroid.hardware.camera2.CaptureRequest
als Konstante definiert ist. Umgekehrt DÜRFEN Geräteimplementierungen Stringkonstanten, die an die Methodeandroid.hardware.Camera.setParameters()
übergeben werden, NICHT berücksichtigen oder erkennen, sofern sie nicht als Konstanten inandroid.hardware.Camera.Parameters
dokumentiert sind. Das heißt, Geräteimplementierungen MÜSSEN alle Standardkameraparameter unterstützen, wenn dies die Hardware zulässt. Benutzerdefinierte Kameraparametertypen DARF NICHT unterstützt werden. Beispielsweise MÜSSEN Geräteimplementierungen, die die Bilderfassung mit HDR-Bildverarbeitungstechniken unterstützen, den KameraparameterCamera.SCENE_MODE_HDR
unterstützen. - [C-0-7] MÜSSEN die korrekte Unterstützung mit dem Attribut
android.info.supportedHardwareLevel
, wie im Android SDK beschrieben, und die entsprechenden Flags für Framework-Funktionen melden. - [C-0-8] MÜSSEN auch die individuellen Kamerafunktionen von
android.hardware.camera2
über die Propertyandroid.request.availableCapabilities
und die entsprechenden Funktions-Flags deklarieren. Das Funktions-Flag muss definiert werden, wenn eine der angeschlossenen Kamerageräte diese Funktion unterstützt. - [C-0-9] MÜSSEN den
Camera.ACTION_NEW_PICTURE
-Intent jedes Mal übertragen, wenn ein neues Bild mit der Kamera aufgenommen und das Bild dem Medienspeicher hinzugefügt wurde. - [C-0-10] MÜSSEN den Intent
Camera.ACTION_NEW_VIDEO
übertragen, wenn die Kamera ein neues Video aufzeichnet und der Eintrag des Bildes dem Media Store hinzugefügt wurde. - [C-0-11] MÜSSEN alle Kameras über die verworfene
android.hardware.Camera
API und über dieandroid.hardware.camera2
API zugänglich sein. - [C-0-12] MUSS dafür sorgen, dass die Gesichtsdarstellung NICHT verändert wird. Dies gilt auch für die Änderung der Gesichtsgeometrie, des Gesichtshauttons oder der Gesichtsglättung für die
android.hardware.camera2
oderandroid.hardware.Camera
API. - [C-SR-1] Bei Geräten mit mehreren RGB-Kameras in unmittelbarer Nähe und, die in die gleiche Richtung gerichtet sind, wird dringend empfohlen, ein logisches Kameragerät mit der Funktion
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
zu unterstützen, die aus allen RGB-Kameras besteht, die in diese Richtung gerichtet sind, als physische Untergeräte.
Wenn Geräteimplementierungen eine proprietäre Kamera-API für Drittanbieter-Apps bereitstellen, gilt Folgendes:
- [C-1-1] MÜSSEN eine solche Kamera-API mit der
android.hardware.camera2
API implementieren. - KANN für die
android.hardware.camera2
API Anbieter-Tags und/oder Erweiterungen zur Verfügung gestellt werden.
7.5.5 Kameraausrichtung
Wenn Geräte eine Front- oder Rückkamera haben, z. B. eine oder mehrere Kameras:
- [C-1-1] MÜSSEN so ausgerichtet sein, dass die lange Seite der Kamera mit der des Bildschirms übereinstimmt. Wenn das Gerät also in Querformat gehalten wird, MÜSSEN Kameras Bilder in Querformat aufnehmen. Dies gilt unabhängig von der natürlichen Ausrichtung des Geräts, d. h. für Primärgeräte im Querformat sowie für Geräte im Hochformat.
Geräte, die alle der folgenden Kriterien erfüllen, sind von der oben genannten Anforderung ausgenommen:
- Das Gerät implementiert Bildschirme mit variabler Geometrie, wie z. B. faltbare oder aufklappbare Displays.
- Wenn sich das Gerät zuklappt oder das Scharnier ändert, wechselt das Gerät zwischen der primären zur primären Ausrichtung im Querformat und umgekehrt.
Neue Anforderungen erstellen
- Geräteimplementierungen, die nicht vom Nutzer gedreht werden können, z. B. Automobilgeräte.
Neue Anforderungen beenden
7.6 Arbeitsspeicher und Datenspeicher
7.6.1 Mindestanforderungen an Arbeitsspeicher und Speicherplatz
Geräteimplementierungen:
- [C-0-1] MUSS einen Download-Manager enthalten, mit dem Anwendungen Datendateien herunterladen dürfen, und sie MÜSSEN in der Lage sein, einzelne Dateien mit einer Größe von mindestens 100 MB in den Cache-Standardspeicherort herunterzuladen.
7.6.2 Freigegebener Anwendungsspeicher
Geräteimplementierungen:
- [C-0-1] MÜSSEN Ihnen Speicher anbieten, der von Anwendungen gemeinsam genutzt werden kann. Dieser Speicher wird oft als "freigegebener externer Speicher", "freigegebener Anwendungsspeicher" oder unter dem Linux-Pfad "/sdcard" bezeichnet, auf dem der Speicher bereitgestellt ist.
- [C-0-2] MÜSSEN mit freigegebenem Speicher konfiguriert werden, der standardmäßig bereitgestellt wird, also „out of the box“, unabhängig davon, ob der Speicher in einer internen Speicherkomponente oder auf einem Wechselmedium (z.B. Secure Digital-Kartensteckplatz) implementiert ist.
- [C-0-3] MÜSSEN den freigegebenen Speicher der Anwendung direkt unter dem Linux-Pfad
sdcard
bereitstellen oder einen symbolischen Linux-Link vonsdcard
zum tatsächlichen Bereitstellungspunkt einfügen. - [C-0-4] MUSS standardmäßig für alle Apps, die auf API-Level 29 oder höher ausgerichtet sind, den begrenzten Speicher aktivieren. Eine Ausnahme gilt, wenn Folgendes zutrifft:
- Wenn die App
android:requestLegacyExternalStorage="true"
in ihrem Manifest angefordert hat.
- Wenn die App
- [C-0-5] MÜSSEN Standortmetadaten wie GPS-EXIF-Tags, die in Mediendateien gespeichert sind, entfernen, wenn der Zugriff auf diese Dateien über
MediaStore
erfolgt, es sei denn, die aufrufende App hat die BerechtigungACCESS_MEDIA_LOCATION
.
Geräteimplementierungen KÖNNEN die oben genannten Anforderungen erfüllen, wenn eine der folgenden Möglichkeiten genutzt wird:
- Vom Nutzer zugänglicher Wechselspeicher, z. B. ein SD-Kartensteckplatz (Secure Digital).
- Ein Teil des internen (nicht entfernbaren) Speichers, wie er im Android Open Source Project (AOSP) implementiert ist.
Wenn auf Geräten Wechseldatenträger verwendet werden, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:
- [C-1-1] MÜSSEN eine Toast- oder Pop-up-Benutzeroberfläche implementieren, die den Nutzer warnt, wenn sich kein Speichermedium im Slot befindet.
- [C-1-2] MÜSSEN Sie ein Speichermedium im Format FAT (z.B. eine SD-Karte) beifügen oder auf der Verpackung und anderem Material, das zum Zeitpunkt des Kaufs verfügbar war, nachweisen, dass das Speichermedium separat erworben werden muss.
Wenn Geräteimplementierungen einen Teil des nicht entfernbaren Speichers nutzen, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:
- SOLLTEN 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-Port mit Unterstützung für den USB-Peripheriemodus haben, gilt Folgendes:
- [C-3-1] MÜSSEN einen Mechanismus bereitstellen, mit dem von einem Hostcomputer aus auf die Daten im freigegebenen Anwendungsspeicher zugegriffen werden kann.
- SOLLTEN Inhalte aus beiden Speicherpfaden transparent über den Medienscanner-Dienst von Android und über
android.provider.MediaStore
verfügbar gemacht werden. - KANN USB-Massenspeicher verwenden, sollte jedoch das Media Transfer Protocol verwenden, um diese Anforderung zu erfüllen.
Wenn Geräteimplementierungen einen USB-Port mit USB-Peripheriemodus haben und Media Transfer Protocol unterstützen, gilt Folgendes:
- SOLLTEN mit dem Android-MTP-Referenzhost Android File Transfer kompatibel sein.
- SOLLTE eine USB-Geräteklasse von 0x00 melden.
- MÜSSEN den Namen „MTP“ für die USB-Schnittstelle melden.
7.6.3 Verwendbare Speicher
Wenn das Gerät – im Gegensatz zum Fernseher – mobil sein soll, werden folgende Geräteimplementierungen implementiert:
- [C-SR-1] DRINGEND, den nutzbaren Speicher an einem langfristig stabilen Standort zu implementieren, da das versehentliche Trennen der Verbindung zu Datenverlust/-beschädigungen führen kann.
Wenn sich der Anschluss für das Wechselmedium an einem langfristigen stabilen Standort befindet, z. B. im Batteriefach oder in einer anderen Schutzabdeckung, sind folgende Geräteimplementierungen möglich:
- [C-SR-2] UNBEDINGT EMPFOHLEN, adaptiven Speicher zu implementieren.
7.7 USB
Wenn Geräteimplementierungen einen USB-Port haben, ist Folgendes zu beachten:
- SOLLTEN den USB-Peripheriemodus und den USB-Hostmodus unterstützen.
- SOLLTEN die Deaktivierung der Datensignalisierung über USB unterstützen.
7.7.1 USB-Peripheriemodus
Wenn Geräte einen USB-Port enthalten, der den Peripheriemodus unterstützt:
- [C-1-1] Der Port MUSS mit einem USB-Host mit einem Standard-USB-Port vom Typ A oder Typ C verbunden werden können.
- [C-1-2] MÜSSEN den korrekten Wert von
iSerialNumber
in der USB-Standard-Gerätebeschreibung überandroid.os.Build.SERIAL
melden. - [C-1-3] MÜSSEN Ladegeräte mit 1,5 A und 3,0 A gemäß dem Typ-C-Standardwiderstand erkennen und MÜSSEN Änderungen in der Werbung erkennen, wenn sie Typ-C-USB-Geräte unterstützen.
- [C-SR-1] Der Port sollte den Formfaktor micro-B, micro-AB oder den USB-Typ-C-Anschluss verwenden. Bestehende und neue Android-Geräte EMPFOHLEN, diese Anforderungen zu erfüllen, damit ein Upgrade auf die zukünftigen Plattform-Releases möglich ist.
- [C-SR-2] Der Anschluss sollte sich (entsprechend der natürlichen Ausrichtung) an der Unterseite des Geräts befinden oder die Softwarebildschirmdrehung für alle Apps aktivieren (einschließlich des Startbildschirms), sodass der Bildschirm korrekt dargestellt wird, wenn das Gerät mit dem Anschluss unten ausgerichtet ist. Bestehende und neue Android-Geräte EMPFOHLEN, diese Anforderungen zu erfüllen, sodass ein Upgrade auf zukünftige Plattform-Releases möglich ist.
- [C-SR-3] SOLLTEN die Nutzung von 1,5 A für den HS-Piepton und Traffic unterstützen, wie in der Spezifikation für das USB-Akkuladevorgang, Version 1.2 beschrieben. Bestehende und neue Android-Geräte EMPFOHLEN, diese Anforderungen zu erfüllen, damit ein Upgrade auf die zukünftigen Plattform-Releases möglich ist.
- [C-SR-4] DRINGEND, keine proprietären Lademethoden zu unterstützen, die die Vbus-Spannung über die Standardniveaus hinaus ändern oder die Rollen von Senken/Quellen so ändern, dass dies zu Interoperabilitätsproblemen mit den Ladegeräten oder Geräten führen kann, die die standardmäßigen USB-Power Delivery-Methoden unterstützen. Auch wenn dies als „DRINGEND EMPFOHLEN“ bezeichnet wird, benötigen wir in zukünftigen Android-Versionen möglicherweise alle Typ-C-Geräte, um die vollständige Interoperabilität mit standardmäßigen Typ-C-Ladegeräten zu unterstützen.
- [C-SR-5] WIRD DRINGEND empfohlen, Power Delivery für das Ändern von Daten und Power-Rollen zu unterstützen, wenn Typ-C-USB- und USB-Hostmodus unterstützt werden.
- SOLLTEN Power Delivery für Hochspannungsladevorgänge und alternative Modi wie Display-out unterstützen.
- SOLLTEN die Android Open Accessory (AOA) API und die Spezifikation implementieren, wie in der Android SDK-Dokumentation beschrieben.
Wenn Geräteimplementierungen einen USB-Port umfassen und die AOA-Spezifikation implementieren, gilt Folgendes:
- [C-2-1] MÜSSEN die Unterstützung für die Hardwarefunktion
android.hardware.usb.accessory
deklarieren. - [C-2-2] Die USB-Massenspeicherklasse MÜSSEN den String "android" am Ende der Schnittstellenbeschreibung
iInterface
des USB-Massenspeichers enthalten. - SOLLTEN NICHT AOAv2-Audio implementiert werden, das in der Android Open Accessory Protocol 2.0-Dokumentation dokumentiert ist. AOAv2 Audio wird mit Android-Version 8.0 (API-Level 26) eingestellt.
7.7.2 USB-Hostmodus
Wenn Geräte einen USB-Port enthalten, der den Hostmodus unterstützt, gilt Folgendes:
- [C-1-1] MÜSSEN die Android-USB-Host-API gemäß der Dokumentation im Android SDK implementieren und die Unterstützung für die Hardwarefunktion
android.hardware.usb.host
deklarieren. - [C-1-2] MÜSSEN Unterstützung für den Anschluss standardmäßiger USB-Peripheriegeräte implementieren. Sie MÜSSEN also eine der folgenden Aktionen ausführen:
- Das Gerät muss über einen Typ-C-Anschluss verfügen oder mit einem oder mehreren Kabeln geliefert werden, die einen proprietären Port auf dem Gerät an einen Standard-USB-Typ-C-Port (USB-Typ-C-Gerät) anpassen.
- Ein Gerät vom Typ A muss auf dem Gerät vorhanden sein oder mit einem oder mehreren Kabeln für einen proprietären On-Device-Port an einen Standard-USB-Typ-A-Port angepasst werden.
- einen Micro-AB-Port auf dem Gerät haben, der mit einem Kabel für einen Standard-Typ-A-Port ausgeliefert werden sollte
- [C-1-3] DARF NICHT mit einem Adapter geliefert werden, der von USB Typ-A- oder Micro-AB-Ports in einen Typ-C-Port (Buchse) umgewandelt wird.
- [C-SR-1] wird dringend empfohlen, die USB-Audioklasse zu implementieren, wie in der Android SDK-Dokumentation beschrieben.
- SOLLTE das Laden des verbundenen USB-Peripheriegeräts im Hostmodus unterstützen.Angeben einer Stromquelle von mindestens 1,5 A, wie im Abschnitt „Beendigungsparameter“ des Abschnitts USB Typ-C-Kabel und -Connector-Spezifikation Version 1.2(Version 1.2) für USB-Typ-C-Anschlüsse oder Verwendung des CDP-Ausgangsstrombereichs angegeben, wie in den USB-Ladespezifikationen für USB-Akkus für Micro-AB-Anschlüsse angegeben.
- SOLLTEN USB-Typ-C-Standards implementieren und unterstützen.
Wenn Geräteimplementierungen einen USB-Port enthalten, der den Hostmodus und die USB-Audioklasse unterstützt, gilt Folgendes:
- [C-2-1] MUSS die USB HID-Klasse unterstützen.
- [C-2-2] MUSS die Erkennung und Zuordnung der folgenden HID-Datenfelder, die in den USB-HID-Nutzungstabellen und der Anfrage zur Nutzung von Sprachbefehlen angegeben sind, den
KeyEvent
-Konstanten unterstützen (siehe unten):- Nutzungsseite (0xC) Nutzungs-ID (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- Nutzungsseite (0xC) Nutzungs-ID (0x0E9):
KEYCODE_VOLUME_UP
- Nutzungsseite (0xC) Nutzungs-ID (0x0EA):
KEYCODE_VOLUME_DOWN
- Nutzungsseite (0xC) Nutzungs-ID (0x0CF):
KEYCODE_VOICE_ASSIST
- Nutzungsseite (0xC) Nutzungs-ID (0x0CD):
Wenn Geräteimplementierungen einen USB-Port enthalten, der den Hostmodus und das Storage Access Framework (SAF) unterstützt, gilt Folgendes:
- [C-3-1] MÜSSEN alle remote verbundenen MTP-Geräte (Media Transfer Protocol) erkennen und ihre Inhalte über die Intents
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
undACTION_CREATE_DOCUMENT
zugänglich machen. .
Wenn Geräteimplementierungen einen USB-Port enthalten, der den Hostmodus und USB Typ-C unterstützt, gilt Folgendes:
- [C-4-1] MÜSSEN die Port-Funktion für zwei Rollen gemäß der Definition der USB Typ-C-Spezifikation (Abschnitt 4.5.1.3.3) implementieren. Bei Dual-Rollen-Ports ist die Erkennung von USB-Senken (Hostmodus) auf Geräten mit 3,5-mm-Audiobuchse möglicherweise standardmäßig deaktiviert.Der Nutzer muss sie jedoch aktivieren können.
- [C-SR-2] WIRD DRINGEND zur Unterstützung von DisplayPort empfohlen, sollten SuperSpeed-USB-Datenübertragungsraten unterstützen und UNBEDINGT EMPFOHLEN, Power Delivery zum Austauschen von Daten- und Energierollen zu unterstützen.
- [C-SR-3] WIRD DRINGEND empfohlen, den Audioadapter-Zubehörmodus nicht zu unterstützen, wie in Anhang A der Version 1.2 des USB Typ-C-Kabels und der Connector-Spezifikation beschrieben.
- SOLLTEN das für den Geräteformfaktor geeignetste Try.*-Modell implementieren. Auf einem Handheld sollte beispielsweise das Modell „Try.SNK“ implementiert werden.
7.8 Audio
7.8.1 Mikrofon
Wenn Geräte ein Mikrofon enthalten, gilt Folgendes:
- [C-1-1] MÜSSEN die
android.hardware.microphone
-Funktionskonstante melden. - [C-1-2] MUSS die Anforderungen für Audioaufnahmen in Abschnitt 5.4 erfüllen.
- [C-1-3] MUSS die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
- [C-SR-1] wird dringend empfohlen, die Nah-Ultraschallaufzeichnung wie in Abschnitt 7.8.3 beschrieben zu unterstützen.
Wenn Geräteimplementierungen kein Mikrofon enthalten, geschieht Folgendes:
- [C-2-1] DARF NICHT die
android.hardware.microphone
-Funktionskonstante melden. - [C-2-2] MÜSSEN die Audio-Aufzeichnungs-API mindestens gemäß Abschnitt 7 im Nullmodus implementieren.
7.8.2 Audioausgabe
Wenn Geräteimplementierungen einen Lautsprecher oder einen Audio-/Multimedia-Ausgabeport für ein Peripheriegerät für die Audioausgabe, z. B. eine 3,5-mm-Audiobuchse mit 4 Kabeln oder einen USB-Hostmodus-Port mit USB-Audioklasse, enthalten, gilt Folgendes:
- [C-1-1] MÜSSEN die
android.hardware.audio.output
-Funktionskonstante melden. - [C-1-2] MUSS die Anforderungen an die Audiowiedergabe in Abschnitt 5.5 erfüllen.
- [C-1-3] MUSS die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
- [C-SR-1] WIRD DRINGEND zur Unterstützung der Wiedergabe mit Nah-Ultraschall empfohlen, wie in Abschnitt 7.8.3 beschrieben.
Wenn Geräteimplementierungen keinen Lautsprecher- oder Audioausgabeport umfassen, ist Folgendes zu beachten:
- [C-2-1] DÜRFEN NICHT die Funktion
android.hardware.audio.output
melden. - [C-2-2] MÜSSEN die APIs zur Audioausgabe zumindest als managementfrei implementieren.
In diesem Abschnitt ist ein „Ausgabeport“ eine physische Schnittstelle, z. B. eine 3, 5-mm-Audiobuchse, ein HDMI-Port oder ein USB-Hostmodus-Port mit USB-Audioklasse. Die Unterstützung der Audioausgabe über Funkprotokolle wie Bluetooth, WLAN oder Mobilfunknetz umfasst keinen „Ausgabeport“.
7.8.2.1 Analoge Audioanschlüsse
Zur Kompatibilität mit den Headsets und anderem Audiozubehör, das den 3,5-mm-Audiostecker des gesamten Android-Ökosystems verwendet, müssen die Geräteimplementierungen einen oder mehrere analoge Audioanschlüsse enthalten:
- [C-SR-1] Es wird dringend empfohlen, mindestens einen der Audioports als 3,5-mm-Audioanschluss mit vier Kabeln anzugeben.
Geräteimplementierungen mit einem 3, 5-mm-Audioanschluss mit 4 Kabeln:
- [C-1-1] MUSS die Audiowiedergabe auf Stereo-Kopfhörern und Stereo-Headsets mit Mikrofon unterstützen.
- [C-1-2] MUSS TRRS-Audiostecker mit CTIA-Pin-out-Reihenfolge unterstützen.
- [C-1-3] MUSS die Erkennung und Zuordnung zu den Keycodes für die folgenden drei Bereiche der entsprechenden Impedanz zwischen dem Mikrofon und den Erdleitern am Audiostecker unterstützen:
- Max. 70 Ohm:
KEYCODE_HEADSETHOOK
- 210–290 Ohm:
KEYCODE_VOLUME_UP
- 360–680 Ohm:
KEYCODE_VOLUME_DOWN
- Max. 70 Ohm:
- [C-1-4] MÜSSEN bei einem Steckerstecker
ACTION_HEADSET_PLUG
auslösen, aber erst, wenn alle Kontakte am Stecker die entsprechenden Segmente an der Buchse berühren. - [C-1-5] MUSS mindestens 150 mV ± 10% der Ausgangsspannung an eine 32-Ohm-Lautsprecherimpedanz liefern können.
- [C-1-6] MÜSSEN über eine Mikrofonspannung zwischen 1,8 und 2,9 V verfügen.
- [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
- 110–180 Ohm:
- [C-SR-2] wird dringend empfohlen, Audiostecker mit der OMTP-Pin-out-Reihenfolge zu unterstützen.
- [C-SR-3] wird dringend empfohlen, die Audioaufnahme von Stereo-Headsets mit Mikrofon zu unterstützen.
Wenn Geräteimplementierungen eine 3,5-mm-Audiobuchse mit 4 Kabeln haben, ein Mikrofon unterstützen und das android.intent.action.HEADSET_PLUG
mit dem zusätzlichen Mikrofon auf „1“ übertragen, geschieht Folgendes:
- [C-2-1] MUSS die Erkennung des Mikrofons auf dem angeschlossenen Audiozubehör unterstützen.
7.8.2.2 Digitale Audioanschlüsse
Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.2.1.
7.8.3 Nah-Ultraschall
Nah-Ultraschall-Audio ist das Frequenzband von 18,5 kHz bis 20 kHz.
Geräteimplementierungen:
- MÜSSEN die Unterstützung von Nah-Ultraschall-Audiofunktionen über die AudioManager.getProperty API wie folgt gemeldet werden:
Wenn PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
„true“ ist, MÜSSEN die folgenden Anforderungen von den Audioquellen VOICE_RECOGNITION
und UNPROCESSED
erfüllt sein:
- [C-1-1] Der durchschnittliche Stromausgang des Mikrofons im Band von 18,5 kHz bis 20 kHz DARF nicht mehr als 15 dB unter dem Antwortbereich bei 2 kHz liegen.
- [C-1-2] Das ungewichtete Signal-Rausch-Verhältnis des Mikrofons über 18,5 kHz bis 20 kHz für einen Ton von 19 kHz bei -26 dBFS DARF nicht unter 50 dB liegen.
Wenn PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
„true“ ist:
- [C-2-1] Der Mittelwert des Lautsprechers in einem Bereich von 18,5 kHz bis 20 kHz DARF nicht unter 40 dB unter dem Wert bei 2 kHz liegen.
7.8.4 Signalintegrität
Geräteimplementierungen:
- SOLLTEN SIE einen störungsfreien Audiosignalpfad für Ein- und Ausgabestreams auf Handheld-Geräten bereitstellen, der durch keine Fehler definiert wird, die während eines Tests von einer Minute pro Pfad gemessen werden. Verwenden Sie zum Testen den "Automated Glitch Test" von OboeTester.
Für den Test ist ein Audio-Loopback-Dongle erforderlich, der direkt in einer 3,5-mm-Buchse und/oder in Kombination mit einem Adapter für USB-C auf 3,5 mm verwendet wird. Alle Audioausgangsports SOLLTEN getestet werden.
OboeTester unterstützt derzeit AAudio-Pfade. Die folgenden Kombinationen SOLLTEN daher mit AAudio auf Fehler getestet werden:
Performance-Modus | Inhalte teilen | Aus Stichprobenrate | In Chans | Out Chans |
---|---|---|---|---|
NIEDRIGE_LATENZ | EXKLUSIV | KEINE ANGABE | 1 | 2 |
NIEDRIGE_LATENZ | EXKLUSIV | KEINE ANGABE | 2 | 1 |
NIEDRIGE_LATENZ | Weiterempfohlen | KEINE ANGABE | 1 | 2 |
NIEDRIGE_LATENZ | Weiterempfohlen | KEINE ANGABE | 2 | 1 |
KEINS | Weiterempfohlen | 48000 | 1 | 2 |
KEINS | Weiterempfohlen | 48000 | 2 | 1 |
KEINS | Weiterempfohlen | 44100 | 1 | 2 |
KEINS | Weiterempfohlen | 44100 | 2 | 1 |
KEINS | Weiterempfohlen | 16000 | 1 | 2 |
KEINS | Weiterempfohlen | 16000 | 2 | 1 |
Ein zuverlässiger Stream sollte die folgenden Kriterien für das Signal-Rausch-Verhältnis (SNR) und die THD (Total Harmonic Distortion) für einen Sinus von 2.000 Hz erfüllen.
Wandler | THD | SNR-Fehler |
---|---|---|
primärer eingebauter 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 dem Loopback-Adapter | < 1 % | >= 60 dB |
Mit dem Smartphone gelieferte USB-Adapter, die mit dem Loopback-Adapter getestet wurden | < 1,0% | >= 60 dB |
7.9. Virtual Reality
Android umfasst APIs und Einrichtungen zum Erstellen von Virtual-Reality-Anwendungen (VR-Anwendungen), einschließlich hochwertiger mobiler VR-Erlebnisse. Geräteimplementierungen MÜSSEN diese APIs und Verhaltensweisen ordnungsgemäß implementieren, wie in diesem Abschnitt beschrieben.
7.9.1 Virtual-Reality-Modus
Android unterstützt den VR-Modus, eine Funktion, die stereoskopisches Rendering von Benachrichtigungen verarbeitet und monokulare System-UI-Komponenten deaktiviert, während eine VR-Anwendung auf den Nutzer ausgerichtet ist.
7.9.2 Virtual-Reality-Modus – hohe Leistung
Wenn Geräteimplementierungen den VR-Modus unterstützen, gilt Folgendes:
- [C-1-1] MUSS mindestens zwei physische Kerne haben.
- [C-1-2] MÜSSEN die Funktion
android.hardware.vr.high_performance
deklarieren. - [C-1-3] MÜSSEN den Modus für kontinuierliche Leistung unterstützen.
- [C-1-4] MUSS OpenGL ES 3.2 unterstützen.
- [C-1-5] MUSS
android.hardware.vulkan.level
0 unterstützen. - SOLLTEN
android.hardware.vulkan.level
1 oder höher unterstützen. - [C-1-6] MÜSSEN
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
undEGL_EXT_image_gl_colorspace
implementieren und die EGL-Erweiterungen in der Liste der verfügbaren Erweiterungen bereitstellen. - [C-1-8] MÜSSEN
GL_EXT_multisampled_render_to_texture2
,GL_OVR_multiview
,GL_OVR_multiview2
,GL_EXT_protected_textures
implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen anzeigen. - [C-SR-1] wird dringend empfohlen,
GL_EXT_external_buffer
,GL_EXT_EGL_image_array
undGL_OVR_multiview_multisampled_render_to_texture
zu implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen anzuzeigen. - [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, Vulkan 1.1 zu unterstützen.
- [C-SR-3] Es wird dringend empfohlen,
VK_ANDROID_external_memory_android_hardware_buffer
,VK_GOOGLE_display_timing
undVK_KHR_shared_presentable_image
zu implementieren und in der Liste der verfügbaren Vulkan-Erweiterungen anzuzeigen. - [C-SR-4] Es wird dringend empfohlen, mindestens eine Vulkan-Warteschlangenfamilie offenzulegen, bei der
flags
sowohlVK_QUEUE_GRAPHICS_BIT
als auchVK_QUEUE_COMPUTE_BIT
undqueueCount
mindestens 2 enthält. - [C-1-7] GPU und Display MÜSSEN in der Lage sein, den Zugriff auf den gemeinsamen Front-Zwischenspeicher zu synchronisieren, sodass VR-Inhalte mit 60 fps und zwei Renderingkontexten ohne sichtbare Tearing-Artefakte gerendert werden.
- [C-1-9] MÜSSEN die Unterstützung für die
AHardwareBuffer
-FlagsAHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
undAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
implementieren, wie im NDK beschrieben. - [C-1-10] MÜSSEN Unterstützung für
AHardwareBuffer
s mit einer beliebigen Kombination der Nutzungs-FlagsAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
,AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
für mindestens die folgenden Formate implementieren:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
. - [C-SR-5] wird dringend empfohlen, die Zuweisung von
AHardwareBuffer
s mit mehr als einer Ebene und Flags und Formaten zu unterstützen, die in C-1-10 angegeben sind. - [C-1-11] MÜSSEN H.264-Decodierung bei mindestens 3840 × 2160 bei 30 fps, komprimiert auf durchschnittlich 40 Mbit/s, unterstützen (entspricht 4 Instanzen von 1920 x 1080 bei 30 fps–10 Mbit/s oder 2 Instanzen mit 1080 Mbit/s x 20 Mbit/s).
- [C-1-12] MÜSSEN HEVC und VP9 unterstützen, MÜSSEN mindestens 1920 × 1080 bei 30 fps decodieren können, die auf durchschnittlich 10 Mbit/s komprimiert sind, und SOLLTEN in der Lage sein, 3840 × 2160 bei 30 fps – 20 fps bis 10 fps – 20 fps zu decodieren.
- [C-1-13] MUSS die
HardwarePropertiesManager.getDeviceTemperatures
API unterstützen und genaue Werte für die Hauttemperatur zurückgeben. - [C-1-14] MÜSSEN einen eingebetteten Bildschirm haben und die Auflösung muss mindestens 1920 x 1080 betragen.
- [C-SR-6] Eine Bildschirmauflösung von mindestens 2560 x 1440 wird dringend empfohlen.
- [C-1-15] Im VR-Modus MUSS das Display mindestens 60 Hz aktualisiert werden.
- [C-1-17] Die Anzeige MUSS einen Modus mit niedriger Persistenz mit einer Persistenz von weniger als 5 Millisekunden unterstützen. Die Persistenz ist definiert als der Zeitraum, über den ein Pixel Licht ausstrahlt.
- [C-1-18] MÜSSEN Bluetooth 4.2 und Bluetooth LE-Datenlängenerweiterung unterstützen Abschnitt 7.4.3.
- [C-1-19] MUSS den direkten Kanaltyp für die folgenden Standardsensortypen unterstützen und ordnungsgemäß melden:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] wird dringend empfohlen, den direkten Kanaltyp
TYPE_HARDWARE_BUFFER
für alle oben aufgeführten Typen für direkte Kanäle zu unterstützen. - [C-1-21] MUSS die Anforderungen in Bezug auf Gyroskop, Beschleunigungsmesser und Magnetometer für
android.hardware.hifi_sensors
erfüllen, wie in Abschnitt 7.3.9 beschrieben. - [C-SR-8] wird dringend empfohlen, das Feature
android.hardware.sensor.hifi_sensors
zu unterstützen. - [C-1-22] MUSS eine End-to-End-Latenz von Bewegung zu Photon eine Latenz von nicht mehr als 28 Millisekunden haben.
- [C-SR-9] Es wird dringend empfohlen, eine End-to-End-Latenz von Bewegung zu Photon auf maximal 20 Millisekunden zu haben.
- [C-1-23] MÜSSEN das Verhältnis für den ersten Frame haben. Dies ist das Verhältnis zwischen der Helligkeit der Pixel im ersten Frame nach einem Übergang von Schwarz zu Weiß und der Helligkeit weißer Pixel bei konstantem Zustand von mindestens 85%.
- [C-SR-10] Es wird dringend empfohlen, ein Verhältnis für den ersten Frame von mindestens 90 % zu haben.
- KANN einen exklusiven Kern für die Anwendung im Vordergrund bereitstellen und die API
Process.getExclusiveCores
unterstützen, um die Anzahl der CPU-Kerne zurückzugeben, die ausschließlich für die Anwendung im Vordergrund gelten.
Wenn der exklusive Kern unterstützt wird, gilt für den Kern Folgendes:
- [C-2-1] DARF keine anderen Userspace-Prozesse darauf zulassen (mit Ausnahme der von der Anwendung verwendeten Gerätetreiber). Möglicherweise können jedoch einige Kernel-Prozesse nach Bedarf ausgeführt werden.
7:10. Haptik
Neue Anforderungen erstellen
Geräte, die in der Hand gehalten oder getragen werden, können einen haptischen Bedienungselement für allgemeine Zwecke enthalten, das für verschiedene Zwecke zur Verfügung steht, einschließlich zum Erzeugen von Aufmerksamkeit durch Klingeltöne, Alarme, Benachrichtigungen und allgemeines Touch-Feedback.
Wenn Geräteimplementierungen KEINEN derartigen haptischen Bedienungselement für allgemeine Zwecke enthalten, ist Folgendes zu beachten:
- [7.10/C] MUSS für
Vibrator.hasVibrator()
"false" zurückgeben.
Wenn Geräteimplementierungen mindestens einen solchen haptischen Bedienelement für allgemeine Zwecke enthalten, ist Folgendes möglich:
- [C-1-1] MUSS für
Vibrator.hasVibrator()
"true" zurückgeben. - DU DARF KEINEN haptischen Bedienungselement mit exzentrischer rotierender Masse (ERM) verwendet werden.
- SOLLTEN alle öffentlichen Konstanten für eine klare Haptik in
android.view.HapticFeedbackConstants
implementieren: (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
undGESTURE_END
). - SOLLTEN alle öffentlichen Konstanten für eindeutige Haptik in
android.os.VibrationEffect
{2, d. h. nur {2/7 f/7 f/7 f, 1, 1, 1, 1, 1, 1, 1, 1, Vibritor}, {18/Primitive , {2, 1, 1, 1, 1, 1, 1, 1, 1, 1}:}EFFECT_TICK
EFFECT_CLICK
EFFECT_HEAVY_CLICK
EFFECT_DOUBLE_CLICK
PRIMITIVE_*
android.os.VibrationEffect.Composition
CLICK
TICK
LOW_TICK
LOW_TICK
QUICK_FALL
QUICK_RISE
SLOW_RISE
SPIN
SPIN
THUD
- SOLLTE der Anleitung zum Zuordnen öffentlicher Konstanten in
android.view.HapticFeedbackConstants
den empfohlenenandroid.os.VibrationEffect
-Konstanten mit den entsprechenden Amplitudenbeziehungen folgen. - SOLLTE diese verknüpften Zuordnungen der haptischen Konstanten verwenden.
- SOLLTEN Sie die Qualitätsprüfung für
createOneShot()
undcreateWaveform()
APIs durchführen. - MÜSSEN verifizieren, dass das Ergebnis der öffentlichen
android.os.Vibrator.hasAmplitudeControl()
API die Vibrationsfunktionen korrekt wiedergibt. - SOLLTEN die Funktionen für die Amplituden-Skalierbarkeit durch Ausführung von
android.os.Vibrator.hasAmplitudeControl()
prüfen.
Wenn Geräteimplementierungen der Zuordnung der haptischen Konstanten folgen, gilt Folgendes:
- MÜSSEN den Implementierungsstatus durch Ausführen der APIs
android.os.Vibrator.areAllEffectsSupported()
undandroid.os.Vibrator.arePrimitivesSupported()
prüfen. - SOLLTEN SIE eine Qualitätsprüfung für haptische Konstanten durchführen.
- SOLLTEN Sie die Fallback-Konfiguration für nicht unterstützte Primitive überprüfen und bei Bedarf aktualisieren, wie in der Implementierungsanleitung für Konstanten beschrieben.
- SOLLTEN SIE wie hier beschrieben Fallback-Unterstützung anbieten, um das Fehlerrisiko zu minimieren.
Neue Anforderungen beenden
Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.2.1.
7:11. Media Performance-Klasse
Die Medienleistungsklasse der Geräteimplementierung kann über die android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
API abgerufen werden. Die Anforderungen an die Medienleistungsklasse werden für jede Android-Version beginnend mit R (Version 30) definiert. Der spezielle Wert 0 gibt an, dass das Gerät keine Medienleistungsklasse ist.
Wenn Geräteimplementierungen für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
einen Wert ungleich null zurückgeben, geschieht Folgendes:
[C-1-1] MUSS mindestens den Wert
android.os.Build.VERSION_CODES.R
zurückgeben.[C-1-2] MUSS die Implementierung eines Handheld-Geräts sein.
[C-1-3] MÜSSEN alle in Abschnitt 2.2.7 beschriebenen Anforderungen für die Medienleistungsklasse erfüllen.
Mit anderen Worten: Die Medienleistungsklasse in Android T ist nur für Handheld-Geräte der Version T, S oder R definiert.
Informationen zu gerätespezifischen Anforderungen finden Sie im Abschnitt 2.2.7.
8. Leistung und Leistung
Einige Mindestleistungs- und Leistungskriterien sind für die Nutzerfreundlichkeit entscheidend und beeinflussen die grundlegenden Annahmen, die Entwickler bei der Entwicklung einer Anwendung haben.
8.1. Konsistente Nutzererfahrung
Wenn bestimmte Mindestanforderungen erfüllt werden, um eine konsistente Framerate und konsistente Antwortzeiten für Apps und Spiele zu gewährleisten, kann eine reibungslose Benutzeroberfläche für den Endnutzer bereitgestellt werden. Geräteimplementierungen haben je nach Gerätetyp messbare Anforderungen an die Latenz der Benutzeroberfläche und den Aufgabenwechsel, wie in Abschnitt 2 beschrieben.
8.2. Leistung des Datei-E/A-Zugriffs
Die Bereitstellung einer gemeinsamen Basis für eine konsistente Dateizugriffsleistung im privaten Datenspeicher der Anwendung (Partition /data
) ermöglicht es App-Entwicklern, eine angemessene Erwartung für ihr Softwaredesign festzulegen. Bei Geräteimplementierungen gelten je nach Gerätetyp möglicherweise bestimmte in Abschnitt 2 beschriebene Anforderungen für die folgenden Lese- und Schreibvorgänge:
- Leistung sequentieller Schreibvorgänge: Dieser Wert wird ermittelt, indem eine 256 MB große Datei mit einem 10-MB-Schreibpuffer geschrieben wird.
- Zufällige Schreibleistung: Gemessen durch Schreiben einer 256 MB großen Datei mit einem 4-KB-Schreibpuffer.
- Leistung sequentieller Lesevorgänge: Gemessen durch Lesen einer 256 MB großen Datei mit einem 10-MB-Schreibpuffer.
- Zufällige Leseleistung: Gemessen durch Lesen einer 256 MB großen Datei mit einem 4-KB-Schreibpuffer.
8.3. Energiesparmodi
Wenn Geräteimplementierungen Funktionen zur Verbesserung der Energieverwaltung von Geräten enthalten, die in AOSP enthalten sind (z.B. App-Standby-Bucket, Stromsparmodus), oder eine Erweiterung der Funktionen so erweitern, dass strengere Einschränkungen als der EINGESCHRÄNKTE App-Standby-Bucket angewendet werden, gilt Folgendes:
- [C-1-1] DARF NICHT von der AOSP-Implementierung für die Trigger-, Wartungs-, Wakeup-Algorithmen und die Verwendung von globalen Systemeinstellungen oder DeviceConfig der Energiesparmodi für App-Standby und Stromsparmodus abweichen.
- [C-1-2] DARF NICHT von der AOSP-Implementierung abweichen, wenn Sie globale Einstellungen oder DeviceConfig zur Verwaltung der Drosselung von Jobs, Alarmen und Netzwerken für Anwendungen in jedem Bucket für App-Standby verwenden.
- [C-1-3] DARF NICHT von der AOSP-Implementierung für die Anzahl der für App-Standby verwendeten App-Standby-Buckets abweichen.
- [C-1-4] MÜSSEN App-Standby-Buckets und den Stromsparmodus wie unter Energiesparmodus beschrieben implementieren.
- [C-1-5] MUSS
true
fürPowerManager.isPowerSaveMode()
zurückgeben, wenn sich das Gerät im Energiesparmodus befindet. - [C-1-6] MÜSSEN alle Apps anzeigen, die vom App-Stand-by- und Stromsparmodus oder von Akkuoptimierungen ausgenommen sind, und MÜSSEN den Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS implementieren, um den Nutzer aufzufordern, Akkuoptimierungen zu ignorieren.
- [C-SR-1] wird dringend empfohlen, Nutzern die Möglichkeit zu bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.
- [C-SR-2] EMPFOHLEN, Nutzern die Möglichkeit zu bieten, alle Apps anzuzeigen, die vom App-Standby- und dem Stromsparmodus ausgenommen sind
Wenn Geräteimplementierungen Energieverwaltungsfunktionen erweitern, die in AOSP enthalten sind, und für diese Erweiterung strengere Einschränkungen als für den Standby-Bucket für seltene Apps gelten, lesen Sie Abschnitt 3.5.1.
Zusätzlich zu den Energiesparmodi KÖNNEN Implementierungen von Android-Geräten einen oder alle der vier Stromzustände für den Ruhemodus implementieren, die in der Advanced Configuration and Power Interface (ACPI) definiert sind.
Wenn Geräteimplementierungen den S4-Stromzustand gemäß Definition des ACPI implementieren, geschieht Folgendes:
- [C-1-1] MÜSSEN diesen Status erst erhalten, nachdem der Nutzer explizit eine Aktion ausgeführt hat, um das Gerät in den inaktiven Zustand zu versetzen (z.B. durch Schließen eines Deckels, der Teil des Geräts ist, oder Ausschalten eines Fahrzeugs oder Fernsehers) und bevor der Nutzer das Gerät wieder aktiviert (z.B. durch Öffnen des Deckels oder Anschalten des Fahrzeugs oder Fernsehers).
Wenn Geräteimplementierungen den S3-Leistungsstatus gemäß der Definition des ACPI implementieren, geschieht Folgendes:
[C-2-1] MÜSSEN die obigen C-1-1-Anforderungen erfüllen oder MÜSSEN nur dann in den S3-Status wechseln, wenn Anwendungen von Drittanbietern die Systemressourcen (z.B. Bildschirm, CPU) nicht benötigen.
Umgekehrt MÜSSEN sie den S3-Status beenden, wenn Drittanbieteranwendungen die Systemressourcen benötigen, wie in diesem SDK beschrieben.
Während die Drittanbieteranwendungen beispielsweise anfordern, dass der Bildschirm über
FLAG_KEEP_SCREEN_ON
eingeschaltet bleibt oder die CPU überPARTIAL_WAKE_LOCK
läuft, DARF das Gerät NICHT in den S3-Status wechseln, es sei denn, der Nutzer hat wie in C-1-1 beschrieben explizit Maßnahmen ergriffen, um das Gerät in den Status „Inaktiv“ zu versetzen. Umgekehrt muss das Gerät den S3-Status beenden, wenn eine Aufgabe ausgelöst wird, die Drittanbieter-Apps über den JobScheduler implementieren, oder Firebase Cloud Messaging an Drittanbieter-Apps gesendet wird, es sei denn, der Nutzer hat das Gerät in den Status „Inaktiv“ versetzt. Dies sind keine umfassenden Beispiele. AOSP implementiert umfangreiche Wakeup-Signale, die einen Wakeup aus diesem Status auslösen.
8.4. Berechnung des Stromverbrauchs
Eine genauere Berechnung und Berichterstellung des Stromverbrauchs bietet dem App-Entwickler sowohl Anreize als auch Tools zur Optimierung des Stromnutzungsmusters der Anwendung.
Geräteimplementierungen:
- [C-SR-1] EMPFOHLEN, ein Leistungsprofil pro Komponente anzugeben, das den Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkukapazität durch die Komponenten im Laufe der Zeit definiert, wie auf der Website des Android Open Source-Projekts dokumentiert.
- [C-SR-2] EMPFOHLEN, alle Werte des Energieverbrauchs in Milliamperestunden (mAh) zu melden.
- [C-SR-3] UNBEDINGT EMPFOHLEN, den CPU-Energieverbrauch pro Prozess-UID zu melden.
Das Android Open Source-Projekt erfüllt die Anforderung durch die Implementierung des Kernelmoduls
uid_cputime
. - [C-SR-4] EMPFOHLEN, diesen Stromverbrauch dem App-Entwickler über den Shell-Befehl
adb shell dumpsys batterystats
zur Verfügung zu stellen. - SOLLTEN der Hardwarekomponente selbst zugeordnet werden, wenn sie einer Anwendung den Stromverbrauch der Hardwarekomponente nicht zuordnen können.
8.5. Konstante Leistung
Die Leistung von leistungsstarken Anwendungen mit langer Laufzeit kann stark schwanken – entweder aufgrund der anderen Anwendungen, die im Hintergrund ausgeführt werden, oder der CPU-Drosselung aufgrund von Temperaturlimits. Android enthält programmatische Schnittstellen, sodass die oberste Vordergrundanwendung bei kompatiblen Geräten anfordern kann, dass das System die Zuweisung von Ressourcen optimiert, um solche Schwankungen zu beheben.
Geräteimplementierungen:
[C-0-1] MÜSSEN die Unterstützung des Modus für kontinuierliche Leistung mithilfe der API-Methode
PowerManager.isSustainedPerformanceModeSupported()
korrekt melden.SOLLTEN den Modus für kontinuierliche Leistung unterstützen.
Wenn Geräteimplementierungen den Modus für kontinuierliche Leistung unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN der Anwendung im Vordergrund, wenn die Anwendung sie anfordert, mindestens 30 Minuten lang eine konstante Leistung erzielen.
- [C-1-2] MÜSSEN die
Window.setSustainedPerformanceMode()
API und andere zugehörige APIs berücksichtigen.
Wenn Geräteimplementierungen zwei oder mehr CPU-Kerne umfassen, gilt Folgendes:
- SOLLTEN mindestens einen exklusiven Kern bereitstellen, der von der Anwendung im Vordergrund reserviert werden kann.
Wenn Geräteimplementierungen die Reservierung eines exklusiven Kerns für die Anwendung im Vordergrund unterstützen, geschieht Folgendes:
- [C-2-1] MÜSSEN die ID-Nummern der exklusiven Kerne, die von der obersten Anwendung im Vordergrund reserviert werden können, über die API-Methode
Process.getExclusiveCores()
melden. - [C-2-2] DARF keine Userspace-Prozesse mit Ausnahme der von der Anwendung verwendeten Gerätetreiber auf den exklusiven Kernen ausführen, aber KANN die Ausführung einiger Kernel-Prozesse nach Bedarf zulassen.
Wenn Geräteimplementierungen keinen exklusiven Kern unterstützen, geschieht Folgendes:
- [C-3-1] MUSS mit der API-Methode
Process.getExclusiveCores()
eine leere Liste zurückgeben.
9. Kompatibilität des Sicherheitsmodells
Geräteimplementierungen:
[C-0-1] MÜSSEN ein Sicherheitsmodell implementieren, das dem Sicherheitsmodell der Android-Plattform entspricht, wie in den APIs in der Android-Entwicklerdokumentation im Referenzdokument zu Sicherheit und Berechtigungen definiert.
[C-0-2] MUSS die Installation selbst signierter Anwendungen unterstützen, ohne dass zusätzliche Berechtigungen/Zertifikate von Dritten oder Behörden erforderlich sind.
Wenn in Geräteimplementierungen die Funktion android.hardware.security.model.compatible
deklariert wird, geschieht Folgendes:
- [C-1-1] MUSS die in den folgenden Unterabschnitten aufgeführten Anforderungen erfüllen.
9.1 Berechtigungen
Geräteimplementierungen:
[C-0-1] MÜSSEN das Android-Berechtigungsmodell und das Android-Rollenmodell gemäß der Definition in der Android-Entwicklerdokumentation unterstützen. Insbesondere MÜSSEN sie alle Berechtigungen und Rollen erzwingen, die in der SDK-Dokumentation beschrieben sind. Berechtigungen und Rollen dürfen nicht weggelassen, geändert oder ignoriert werden.
KANN zusätzliche Berechtigungen hinzufügen, sofern sich die neuen Berechtigungs-ID-Strings nicht im Namespace
android.\*
befinden.[C-0-2] Berechtigungen mit dem
protectionLevel
PROTECTION_FLAG_PRIVILEGED
DÜRFEN nur Anwendungen gewährt werden, die im privilegierten Pfad des System-Images (sowie in den APEX-Dateien) vorinstalliert sind und sich innerhalb der Teilmenge der explizit zugelassenen Berechtigungen für jede Anwendung befinden. Die AOSP-Implementierung erfüllt diese Anforderung, indem die Berechtigungen auf der Zulassungsliste für jede Anwendung aus den Dateien im Pfadetc/permissions/
gelesen und berücksichtigt werden. Außerdem wird der privilegiertesystem/priv-app
-Pfad für jede Anwendung verwendet.
Berechtigungen mit dem Schutzniveau „gefährlich“ sind Laufzeitberechtigungen.
Anwendungen mit targetSdkVersion
> 22 fordern sie zur Laufzeit an.
Geräteimplementierungen:
- [C-0-3] MÜSSEN eine dedizierte Schnittstelle anzeigen, über die der Nutzer entscheiden kann, ob die angeforderten Laufzeitberechtigungen gewährt werden sollen, und dem Nutzer außerdem eine Schnittstelle zur Verwaltung der Laufzeitberechtigungen zur Verfügung stellen.
- [C-0-4] MUSS nur eine Implementierung beider Benutzeroberflächen haben.
[C-0-5] Apps DARF KEINE Laufzeitberechtigungen gewähren, es sei denn:
- Sie werden zum Zeitpunkt der Gerätelieferung installiert UND
Die Einwilligung des Nutzers kann eingeholt werden, bevor die Anwendung die Berechtigung verwendet.
ODER
Die Laufzeitberechtigungen werden durch die Standardrichtlinie zur Gewährung von Berechtigungen oder durch das Behalten einer Plattformrolle gewährt.
[C-0-6] MUSS die Berechtigung
android.permission.RECOVER_KEYSTORE
nur System-Apps erteilen, die einen ordnungsgemäß gesicherten Wiederherstellungs-Agent registrieren. Ein ordnungsgemäß gesicherter Wiederherstellungs-Agent ist ein Software-Agent auf dem Gerät, der sich mit einem Remote-Speicher auf dem Gerät synchronisiert. Dieser ist mit einer sicheren Hardware ausgestattet, die einen Schutz aufweist, der dem im Google Cloud Key Vault-Dienst beschriebenen Schutz entspricht oder höher ist, um Brute-Force-Angriffe auf den Sperrbildschirm-Wissensfaktor zu verhindern.
Geräteimplementierungen:
[C-0-7] MÜSSEN die Properties der Android-Berechtigung zur Standortermittlung einhalten, wenn eine App die Daten zum Standort oder zu körperlichen Aktivitäten über die Standard-Android API oder einen proprietären Mechanismus anfordert. Zu diesen Daten gehören unter anderem:
- Standort des Geräts (z.B. Breiten- und Längengrad), wie in Abschnitt 9.8.8 beschrieben.
- Informationen, mit denen der Standort des Geräts ermittelt oder geschätzt werden kann (z.B. SSID, BSSID, Cell-ID oder Standort des Netzwerks, mit dem das Gerät verbunden ist).
- Die körperliche Aktivität des Nutzers oder die Einordnung der körperlichen Aktivität.
Genauer gesagt, Geräteimplementierungen:
- [C-0-8] MÜSSEN die Einwilligung des Nutzers eingeholt werden, damit eine App auf Daten zu Standortdaten oder körperlichen Aktivitäten zugreifen kann.
- [C-0-9] MUSS NUR der App eine Laufzeitberechtigung gewähren, die wie im SDK beschrieben die ausreichende Berechtigung enthält.
TelephonyManager#getServiceState erfordert beispielsweise
android.permission.ACCESS_FINE_LOCATION
.
Die einzigen Ausnahmen von den oben genannten Eigenschaften für die Android-Berechtigung zur Standortermittlung gelten für Apps, die nicht auf den Standort zugreifen, um den Nutzerstandort abzuleiten oder zu ermitteln:
- Wenn Apps die Berechtigung „
RADIO_SCAN_WITHOUT_LOCATION
“ haben. - Für die Gerätekonfiguration und -einrichtung, wenn System-Apps die Berechtigung
NETWORK_SETTINGS
oderNETWORK_SETUP_WIZARD
haben.
Berechtigungen können als eingeschränkt gekennzeichnet werden und so ihr Verhalten ändern.
[C-0-10] Berechtigungen, die mit dem Flag
hardRestricted
gekennzeichnet sind, DÜRFEN einer Anwendung NICHT gewährt werden, es sei denn:- In der Systempartition befindet sich eine APK-Datei der App.
- Der Nutzer weist einer App eine Rolle zu, die mit den Berechtigungen
hardRestricted
verknüpft ist. - Das Installationsprogramm gewährt einer App die Berechtigung „
hardRestricted
“. - Einer App wird auf einer älteren Android-Version der
hardRestricted
gewährt.
[C-0-11] Apps mit der Berechtigung
softRestricted
DÜRFEN nur eingeschränkten Zugriff erhalten und DÜRFEN KEINEN vollständigen Zugriff erhalten, bis sie wie im SDK beschrieben auf die Zulassungsliste gesetzt werden, wenn für jedesoftRestricted
-Berechtigung vollständiger und eingeschränkter Zugriff definiert ist (z. B.READ_EXTERNAL_STORAGE
).[C-0-12] DARF KEINE benutzerdefinierten Funktionen oder APIs zur Verfügung stellen, um die in den APIs setPermissionPolicy und setPermissionGrantState definierten Berechtigungsbeschränkungen zu umgehen.
[C-0-13] MÜSSEN die AppOpsManager APIs verwenden, um jeden programmatischen Zugriff auf Daten aufzuzeichnen und zu verfolgen, die durch gefährliche Berechtigungen aus Android-Aktivitäten und -Diensten geschützt sind.
[C-0-14] Rollen DARF nur Anwendungen mit Funktionen zugewiesen werden, die die Rollenanforderungen erfüllen.
[C-0-15] DÜRFEN keine Rollen definieren, die Duplikate oder Obermengen von Rollen sind, die von der Plattform definiert sind.
Wenn Geräte android.software.managed_users
melden, geschieht Folgendes:
- [C-1-1] DÜRFEN die folgenden Berechtigungen NICHT ohne Ton vom Administrator gewährt haben:
- Standort (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION)
- Kamera (KAMERA)
- Mikrofon (RECORD_AUDIO)
- Körpersensor (BODY_SENSORS)
- Körperliche Aktivität (ACTIVITY_RECOGNITION)
Wenn Geräteimplementierungen Nutzern die Möglichkeit bieten zu entscheiden, welche Apps auf anderen Apps mit einer Aktivität basieren können, die den ACTION_MANAGE_OVERLAY_PERMISSION
-Intent verarbeitet, geschieht Folgendes:
- [C-2-1] MÜSSEN dafür sorgen, dass alle Aktivitäten mit Intent-Filtern für den Intent
ACTION_MANAGE_OVERLAY_PERMISSION
denselben UI-Bildschirm haben, unabhängig von der initiierenden App und den von ihr bereitgestellten Informationen.
Wenn Geräteimplementierungen „android.software.device_admin“ melden, geschieht Folgendes:
- [C-3-1] MÜSSEN bei der Einrichtung des vollständig verwalteten Geräts (Einrichtung des Geräteeigentümers) einen Haftungsausschluss einblenden, der besagt, dass der IT-Administrator Apps erlauben kann, die Einstellungen auf dem Smartphone zu steuern, einschließlich Mikrofon, Kamera und Standort. Der Nutzer kann mit der Einrichtung fortfahren oder die Einrichtung beenden, ES SEI DENN der Administrator der Kontrolle über die Geräteberechtigungen entzogen hat.
Wenn bei Geräteimplementierungen alle Pakete vorinstalliert werden, die eine der Rollen System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence oder System Visual Intelligence enthalten, gilt Folgendes:
- [C-4-1] MÜSSEN alle Anforderungen erfüllen, die in den Abschnitten
9.8.6 Inhalte erfassenund 9.8.6 Betriebssystem- und Umgebungsdaten und 9.8.15 Implementierungen von APIs in einer Sandbox beschrieben werden.
- [C-4-2] DÜRFEN KEINE Berechtigung „android.permission.INTERNET“ haben. Dies ist strenger als die in Abschnitt 9.8.6 UNBEDINGT EMPFOHLENE EMPFEHLUNG.
- [C-4-3] DÜRFEN NICHT an andere Apps gebunden werden, mit Ausnahme der folgenden System-Apps: Bluetooth, Kontakte, Medien, Telefonie, SystemUI und Komponenten, die Internet-APIs bereitstellen. Dies ist strenger als in Abschnitt 9.8.6 UNBEDINGT EMPFOHLEN.
Neue Anforderungen erstellen
Wenn Geräteimplementierungen eine Standardanwendung zur Unterstützung von VoiceInteractionService
enthalten, gilt Folgendes:
- [C-5-1] DARF
ACCESS_FINE_LOCATION
NICHT als Standard für diese Anwendung zuweisen.
Neue Anforderungen beenden
9.2. UID und Prozessisolierung
Geräteimplementierungen:
- [C-0-1] MUSS das Sandbox-Modell der Android-Anwendung unterstützen, bei dem jede Anwendung als eindeutige Unixstyle-UID und in einem separaten Prozess ausgeführt wird.
- [C-0-2] MUSS die Ausführung mehrerer Anwendungen unter derselben Linux-Nutzer-ID unterstützen, vorausgesetzt, die Anwendungen sind ordnungsgemäß signiert und konstruiert (siehe Referenz zu Sicherheit und Berechtigungen).
9.3 Dateisystemberechtigungen
Geräteimplementierungen:
- [C-0-1] MUSS das Berechtigungsmodell für den Dateizugriff von Android unterstützen, wie in der Referenz zu Sicherheit und Berechtigungen definiert.
9.4 Alternative Ausführungsumgebungen
Geräteimplementierungen MÜSSEN Konsistenz des Android-Sicherheits- und Berechtigungsmodells aufrechterhalten, auch wenn sie Laufzeitumgebungen enthalten, in denen Anwendungen mit einer anderen Software oder Technologie als dem Dalvik Executable Format 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 an anderer Stelle in Abschnitt 9 beschrieben.
[C-0-2] Alternative Laufzeiten DÜRFEN KEINEN Zugriff auf Ressourcen erhalten, die durch Berechtigungen geschützt sind, die nicht in der Datei
AndroidManifest.xml
der Laufzeit über den <uses-permission
>-Mechanismus angefordert werden.[C-0-3] Alternative Laufzeiten DÜRFEN NICHT zulassen, dass Anwendungen Funktionen verwenden, die durch Android-Berechtigungen geschützt sind, die auf Systemanwendungen beschränkt sind.
[C-0-4] Alternative Laufzeiten MÜSSEN dem Android-Sandbox-Modell entsprechen und installierte Anwendungen, die eine alternative Laufzeit verwenden, DÜRFEN NICHT die Sandbox einer anderen auf dem Gerät installierten App wiederverwenden, außer über die Android-Standardmechanismen einer gemeinsamen Nutzer-ID und eines Signaturzertifikats.
[C-0-5] Alternative Laufzeiten DÜRFEN NICHT mit den Sandboxes gestartet werden, die anderen Android-Apps entsprechen, oder ihnen Zugriff darauf gewähren.
[C-0-6] Alternative Laufzeiten DÜRFEN NICHT mit anderen Anwendungen gestartet, gewährt oder ihnen die Berechtigungen des Superuser (Root) oder einer anderen Nutzer-ID zugewiesen werden.
[C-0-7] Wenn die
.apk
-Dateien alternativer Laufzeiten im System-Image von Geräteimplementierungen enthalten sind, MÜSSEN sie mit einem Schlüssel signiert werden, der sich von dem Schlüssel unterscheidet, mit dem andere Anwendungen in den Geräteimplementierungen signiert werden.[C-0-8] Bei der Installation von Anwendungen MÜSSEN alternative Laufzeiten die Nutzereinwilligung für die von der App verwendeten Android-Berechtigungen einholen.
[C-0-9] Wenn eine App eine Geräteressource verwenden muss, für die eine entsprechende Android-Berechtigung vorhanden ist (z. B. Kamera, GPS usw.), MUSS die alternative Laufzeit den Nutzer darüber informieren, dass die App auf diese Ressource zugreifen kann.
[C-0-10] Wenn die Laufzeitumgebung die Anwendungsfunktionen nicht auf diese Weise aufzeichnet, MUSS die Laufzeitumgebung alle Berechtigungen der Laufzeit selbst auflisten, wenn eine Anwendung installiert wird, die diese Laufzeit verwendet.
Alternative Laufzeiten sollten Apps über
PackageManager
in separaten Android-Sandboxes (Linux-Nutzer-IDs usw.) installieren.Alternative Laufzeiten KÖNNEN eine einzelne Android-Sandbox bereitstellen, die von allen Anwendungen gemeinsam genutzt wird, die die alternative Laufzeit verwenden.
9.5 Unterstützung mehrerer Nutzer
Android unterstützt mehrere Nutzer sowie die vollständige Nutzerisolierung und das Klonen von Nutzerprofilen mit teilweiser Isolierung(d.h. ein einzelnes zusätzliches Nutzerprofil des Typs android.os.usertype.profile.CLONE
).
- Bei Geräteimplementierungen MÖGLICHERWEISE MÖGLICHERWEISE jedoch NICHT für mehrere Nutzer geeignet sein, wenn als primären externen Speicher Wechselmedien verwendet werden.
Wenn Geräteimplementierungen mehrere Nutzer unterstützen, gilt Folgendes:
- [C-1-2] MÜSSEN für jeden Nutzer ein Sicherheitsmodell implementieren, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument zu Sicherheit und Berechtigungen in den APIs definiert.
- [C-1-3] MÜSSEN separate und isolierte gemeinsame Anwendungsspeicherverzeichnisse (auch als
/sdcard
bezeichnet) für jede Nutzerinstanz haben. - [C-1-4] MÜSSEN sicherstellen, dass Anwendungen, die einem bestimmten Nutzer gehören und im Namen eines bestimmten Nutzers ausgeführt werden, keine Dateien auflisten, lesen oder bearbeiten können, auch wenn die Daten beider Nutzer auf demselben Volume oder Dateisystem gespeichert sind.
- [C-1-5] MÜSSEN den Inhalt der SD-Karte verschlüsseln, wenn die Mehrnutzer-Funktion aktiviert ist. Verwenden Sie dazu einen Schlüssel, der nur auf nicht entfernbaren Medien gespeichert ist, auf die nur das System zugreifen kann, wenn bei Geräteimplementierungen Wechseldatenträger für die externen Speicher-APIs verwendet werden. 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.
Wenn Geräteimplementierungen mehrere Nutzer unterstützen, gilt für alle Nutzer mit Ausnahme von Nutzern, die speziell zum Ausführen von doppelten Instanzen derselben App erstellt wurden:
- [C-2-1] MÜSSEN separate und isolierte gemeinsame Anwendungsspeicherverzeichnisse (auch bekannt als /sdcard) für jede Nutzerinstanz haben.
- [C-2-2] MÜSSEN sicherstellen, dass Anwendungen, die einem bestimmten Nutzer gehören und in dessen Namen ausgeführt werden, die Dateien eines anderen Nutzers nicht auflisten, lesen oder schreiben können, selbst wenn die Daten beider Nutzer auf demselben Volume oder Dateisystem gespeichert sind.
Bei Geräteimplementierungen KÖNNEN ein einzelnes zusätzliches Nutzerprofil des Typs android.os.usertype.profile.CLONE
für den Hauptnutzer (und nur für den Hauptnutzer) erstellt werden, um zwei Instanzen derselben App auszuführen. Diese doppelten Instanzen teilen sich einen teilweise isolierten Speicher, werden dem Endnutzer gleichzeitig im Launcher präsentiert und erscheinen in derselben Ansicht, in der auch der Hauptnutzer angezeigt wird.
So könnte der Nutzer beispielsweise zwei separate Instanzen einer einzelnen App auf einem Dual-SIM-Gerät installieren.
Wenn das oben beschriebene zusätzliche Nutzerprofil bei Geräteimplementierungen erstellt wird, geschieht Folgendes:
- [C-3-1] DARF nur Zugriff auf Speicher oder Daten gewähren, die entweder bereits für das übergeordnete Nutzerprofil zugänglich sind oder direkt zu diesem zusätzlichen Nutzerprofil gehören.
- [C-3-2] DÜRFEN NICHT als Arbeitsprofil verwendet werden.
- [C-3-3] MÜSSEN die privaten Datenverzeichnisse der Anwendung vom übergeordneten Nutzerkonto getrennt haben.
- [C-3-4] DARF NICHT die Erstellung des zusätzlichen Nutzerprofils zulassen, wenn ein Geräteinhaber bereitgestellt wird (siehe Abschnitt 3.9.1), oder die Bereitstellung eines Geräteinhabers zulassen, ohne vorher das zusätzliche Nutzerprofil zu entfernen.
Neue Anforderungen erstellen
Wenn das oben beschriebene zusätzliche Nutzerprofil bei Geräteimplementierungen erstellt wird, geschieht Folgendes:
- [C-4-5] MÜSSEN die Symbole der Dual-Instanz-Anwendung visuell abgrenzen, wenn sie den Nutzern angezeigt werden.
- [C-4-6] MÜSSEN ein Nutzerangebot zum Löschen vollständiger Klonprofildaten angeben.
- [C-4-7] MÜSSEN alle geklonten Apps deinstalliert, die privaten App-Datenverzeichnisse und deren Inhalte sowie die Klonprofildaten gelöscht werden, wenn sich der Nutzer entscheidet, gesamte geklonte Profildaten zu löschen.
- SOLLTE den Nutzer auffordern, alle Daten des Klonprofils zu löschen, wenn die letzte Klon-App gelöscht wird.
- [C-4-8] MÜSSEN den Nutzer darüber informieren, dass die App-Daten gelöscht werden, wenn die geklonte App deinstalliert wird, oder Nutzern die Möglichkeit bieten, die App-Daten zu behalten, wenn die App vom Gerät deinstalliert wird.
- [C-4-9] MÜSSEN die privaten App-Datenverzeichnisse und deren Inhalte löschen, wenn der Nutzer sich entscheidet, die Daten während der Deinstallation zu löschen.
[C-4-1] MÜSSEN die folgenden Intents, die aus dem zusätzlichen Profil stammen, von Anwendungen des Hauptnutzers auf dem Gerät verarbeiten:
Intent.ACTION_VIEW
Intent.ACTION_SENDTO
Intent.ACTION_SEND
Intent.ACTION_EDIT
Intent.ACTION_INSERT
Intent.ACTION_INSERT_OR_EDIT
Intent.ACTION_SEND_MULTIPLE
Intent.ACTION_PICK
Intent.ACTION_GET_CONTENT
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] MÜSSEN alle Nutzereinschränkungen für Geräterichtlinien und ausgewählte, nicht nutzerbezogene Einschränkungen(Liste unten) übernehmen, die auf den Hauptnutzer des Geräts auf dieses zusätzliche Nutzerprofil angewendet werden.
[C-4-3] DARF nur das Schreiben von Kontakten aus diesem zusätzlichen Profil über die folgenden Intents zulassen:
[C-4-4] DÜRFEN KEINE Kontaktsynchronisierungen für Anwendungen in diesem zusätzlichen Nutzerprofil ausführen.
- [C-4-14] MUSS für die in diesem zusätzlichen Profil ausgeführten Anwendungen eine separate Berechtigungs- und Speicherverwaltung haben
- [C-4-5] DARF nur Apps im zusätzlichen Profil mit einer Launcher-Aktivität den Zugriff auf Kontakte erlauben, die für das übergeordnete Nutzerprofil bereits zugänglich sind.
Neue Anforderungen beenden
9.6 Warnung bei Premium-SMS
Unter Android können Nutzer vor ausgehenden Premium-SMS gewarnt werden. Premium-SMS sind SMS, die an einen bei einem Mobilfunkanbieter registrierten Dienst gesendet werden und für den Nutzer Gebühren anfallen können.
Wenn in Geräteimplementierungen die Unterstützung von android.hardware.telephony
deklariert wird, gilt Folgendes:
- [C-1-1] MÜSSEN Nutzer warnen, bevor sie eine SMS an Nummern senden, die durch reguläre Ausdrücke identifiziert werden, die in der Datei
/data/misc/sms/codes.xml
auf dem Gerät definiert sind. Das vorgelagerte Open-Source-Projekt von Android bietet eine Implementierung, die diese Anforderung erfüllt.
9.7 Sicherheitsfunktionen
Geräteimplementierungen MÜSSEN sicherstellen, dass die unten beschriebenen Sicherheitsfunktionen sowohl im Kernel als auch auf der Plattform eingehalten werden.
Die Android-Sandbox umfasst Funktionen, die das MAC-System (Security-Enhanced Linux, SELinux) und andere Sicherheitsfunktionen im Linux-Kernel verwenden. Geräteimplementierungen:
- [C-0-1] MÜSSEN die Kompatibilität mit vorhandenen Anwendungen aufrechterhalten, auch wenn SELinux oder andere Sicherheitsfunktionen unterhalb des Android-Frameworks implementiert sind.
- [C-0-2] DÜRFEN KEINE sichtbare Benutzeroberfläche haben, wenn ein Sicherheitsverstoß erkannt und erfolgreich durch die Sicherheitsfunktion unterhalb des Android-Frameworks blockiert wird. KANN jedoch eine sichtbare Benutzeroberfläche haben, wenn ein nicht blockierter Sicherheitsverstoß zu einem erfolgreichen Exploit führt.
- [C-0-3] DÜRFEN SELinux oder andere Sicherheitsfunktionen, die unter dem Android-Framework implementiert sind, NICHT für den Nutzer oder App-Entwickler konfigurieren.
- [C-0-4] DARF NICHT zulassen, dass eine Anwendung, die sich über eine API (z. B. eine Device Administration API) auf eine andere Anwendung auswirkt, die Konfiguration einer Richtlinie erlaubt, die gegen die Kompatibilität verstößt.
- [C-0-5] MÜSSEN das Medien-Framework in mehrere Prozesse aufteilen, damit es möglich ist, den Zugriff für jeden Prozess präziser zu gewähren, wie auf der Website des Android Open Source Project beschrieben.
- [C-0-6] MÜSSEN einen Sandbox-Mechanismus für Kernel-Anwendungen implementieren, der das Filtern von Systemaufrufen mithilfe einer konfigurierbaren Richtlinie aus Multithread-Programmen ermöglicht. Das vorgelagerte Android-Open-Source-Projekt erfüllt diese Anforderung durch Aktivieren des seccomp-BPF mit Threadgroup-Synchronisierung (TSYNC), wie im Abschnitt zur Kernel-Konfiguration von source.android.com beschrieben.
Die Kernel-Integrität und Selbstschutzfunktionen sind entscheidend für die Android-Sicherheit. Geräteimplementierungen:
- [C-0-7] MÜSSEN Mechanismen zum Schutz vor Überlauf des Kernel-Stack-Zwischenspeichers implementieren.
Beispiele für solche Mechanismen sind
CC_STACKPROTECTOR_REGULAR
undCONFIG_CC_STACKPROTECTOR_STRONG
. - [C-0-8] MÜSSEN strenge Kernel-Speicherschutzmaßnahmen implementieren, wenn ausführbarer Code schreibgeschützt, schreibgeschützte Daten nicht ausführbar und nicht beschreibbar sind und beschreibbare Daten nicht ausführbar sind (z.B.
CONFIG_DEBUG_RODATA
oderCONFIG_STRICT_KERNEL_RWX
). - [C-0-9] MÜSSEN auf Geräten, deren ursprünglicher API-Level 28 oder höher war, statische und dynamische Grenzen für die Prüfung der Objektgröße zwischen Nutzer- und Kernel-Bereich (z.B.
CONFIG_HARDENED_USERCOPY
) implementieren. - [C-0-10] DARF KEINEN User-Space-Speicher bei Ausführung im Kernelmodus (z.B. Hardware-PXN oder emuliert über
CONFIG_CPU_SW_DOMAIN_PAN
oderCONFIG_ARM64_SW_TTBR0_PAN
) auf Geräten ausgeführt werden, die ursprünglich API-Level 28 oder höher haben. - [C-0-11] DARF NICHT auf Geräten, deren ursprünglicher API-Level 28 oder höher war, außerhalb von normalen APIs für den Nutzerkopie-Zugriff (z.B. Hardware-PAN oder emuliert über
CONFIG_CPU_SW_DOMAIN_PAN
oderCONFIG_ARM64_SW_TTBR0_PAN
) im Nutzerspeicher im Kernel lesen oder schreiben. - [C-0-12] MÜSSEN die Isolierung der Kernel-Seitentabelle implementieren, wenn die Hardware auf allen Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden (z.B.
CONFIG_PAGE_TABLE_ISOLATION
oderCONFIG_UNMAP_KERNEL_AT_EL0
), anfällig für CVE-2017-5754 ist. [C-0-13] MÜSSEN die Zweigvorhersage-Härtung implementieren, wenn die Hardware auf allen Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden (z.B.
CONFIG_HARDEN_BRANCH_PREDICTOR
), anfällig für CVE-2017-5715 ist.[C-SR-1] wird dringend empfohlen, die Stack-Initialisierung im Kernel zu aktivieren, um die Verwendung nicht initialisierter lokaler Variablen (
CONFIG_INIT_STACK_ALL
oderCONFIG_INIT_STACK_ALL_ZERO
) zu verhindern. Außerdem sollten Geräteimplementierungen NICHT den Wert annehmen, der vom Compiler zum Initialisieren der lokalen Variablen verwendet wird.[C-SR-2] WIRD UNBEDINGT EMPFOHLEN, Kerneldaten, die nur während der Initialisierung geschrieben werden, nach der Initialisierung als schreibgeschützt markiert zu behalten (z.B.
__ro_after_init
).[C-SR-3] wird dringend empfohlen, das Layout des Kernel-Codes und des Arbeitsspeichers zufällig zu gestalten und Kontakte zu vermeiden, die die Randomisierung beeinträchtigen würden (z.B.
CONFIG_RANDOMIZE_BASE
mit Bootloader-Entropie über/chosen/kaslr-seed Device Tree node
oderEFI_RNG_PROTOCOL
).[C-SR-4] WIRD UNBEDINGT EMPFOHLEN, CFI (Control Flow Integrity) im Kernel zu aktivieren, um zusätzlichen Schutz vor Code-Wiederverwendungsangriffen (z.B.
CONFIG_CFI_CLANG
undCONFIG_SHADOW_CALL_STACK
) zu bieten.[C-SR-5] Es wird dringend empfohlen, Control-Flow Integrity (CFI), Shadow Call Stack (SCS) oder Integer Overflow Sanitization (IntSan) für Komponenten, für die sie aktiviert ist, nicht zu deaktivieren.
[C-SR-6] wird dringend empfohlen, CFI, SCS und IntSan für alle zusätzlichen sicherheitsrelevanten Userspace-Komponenten zu aktivieren, wie unter CFI und IntSan erläutert.
[C-SR-7] Es wird dringend empfohlen, die Stack-Initialisierung im Kernel zu aktivieren, um die Verwendung nicht initialisierter lokaler Variablen (
CONFIG_INIT_STACK_ALL
oderCONFIG_INIT_STACK_ALL_ZERO
) zu verhindern. Außerdem sollten Geräteimplementierungen NICHT den Wert annehmen, der vom Compiler zur Initialisierung der lokalen Variablen verwendet wird.[C-SR-8] 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, und SOLLTE NICHT von dem Wert ausgehen, der vom Kernel zum Initialisieren dieser Zuweisungen verwendet wird.
Wenn Geräteimplementierungen einen Linux-Kernel verwenden, der SELinux unterstützt, geschieht Folgendes:
- [C-1-1] MUSS SELinux implementieren.
- [C-1-2] MÜSSEN SELinux in den globalen Erzwingungsmodus setzen.
- [C-1-3] MÜSSEN alle Domains im Erzwingungsmodus konfigurieren. Domains im Sperrmodus sind nicht zulässig, auch nicht geräte- oder anbieterspezifische Domains.
- [C-1-4] DARF die „Neverallow“-Regeln, die im Ordner „system/sepolicy“ im vorgelagerten Open Source Project (AOSP) von Android vorhanden sind, NICHT geändert, weggelassen oder ersetzt werden. Die Richtlinie MÜSSEN sowohl für AOSP SELinux-Domains als auch geräte-/anbieterspezifische Domains mit allen „Neverallow“-Regeln kompiliert werden.
- [C-1-5] MÜSSEN Drittanbieteranwendungen mit API-Level 28 oder höher in SELinux-Sandboxes pro Anwendung mit SELinux-Einschränkungen für einzelne Apps im Verzeichnis für private Daten ausführen.
- SOLLTEN die standardmäßige SELinux-Richtlinie beibehalten, die im Ordner "system/sepolicy" des vorgelagerten Android-Open-Source-Projekts bereitgestellt wird, und dieser Richtlinie nur für ihre eigene gerätespezifische Konfiguration hinzufügen.
Wenn Geräteimplementierungen einen anderen Kernel als Linux oder Linux ohne SELinux verwenden, geschieht Folgendes:
- [C-2-1] MÜSSEN ein obligatorisches Zugriffssteuerungssystem verwenden, das SELinux entspricht.
Wenn Geräteimplementierungen E/A-Geräte verwenden, die DMA unterstützen, gilt Folgendes:
- [C-SR-9] Es wird dringend empfohlen, jedes E/A-Gerät, das DMA-fähig ist, mithilfe einer IOMMU (z.B.ARM SMMU) zu isolieren.
Android enthält mehrere gestaffelte Sicherheitsebenen, die für die Gerätesicherheit von zentraler Bedeutung sind. Darüber hinaus konzentriert sich Android darauf, wichtige Klassen häufiger Fehler zu reduzieren, die zu schlechter Qualität und Sicherheit beitragen.
Um Speicherfehler zu reduzieren, sollten bei den Geräteimplementierungen folgende Schritte ausgeführt werden:
- [C-SR-10] WIRD UNBEDINGT EMPFOHLEN, mit Tools zur Erkennung von Fehlern im Nutzerbereich wie MTE für ARMv9-Geräte, HWASan für ARMv8+-Geräte oder ASan für andere Gerätetypen zu testen.
- [C-SR-11] WIRD UNBEDINGT zum Testen mit Tools zur Erkennung von Kernel-Arbeitsspeicherfehlern wie KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS für ARMv9-Geräte, CONFIG_KASAN_SW_TAGS für ARMv8-Geräte oder CONFIG_KASAN_GENERIC für andere Gerätetypen) empfohlen.
- [C-SR-12] wird dringend empfohlen, in der Produktion Tools zur Speicherfehlererkennung wie MTE, GWP-ASan und KFENCE zu verwenden.
Wenn Geräteimplementierungen einen TrustZone-basierten Arm-TEE verwenden, geschieht Folgendes:
- [C-SR-13] wird dringend empfohlen, ein Standardprotokoll für die Arbeitsspeicherfreigabe zwischen Android und TEE zu verwenden, z. B. das Arm Firmware Framework für Armv8-A (FF-A).
- [C-SR-14] Es wird dringend empfohlen, vertrauenswürdige Anwendungen auf Arbeitsspeicher zu beschränken, der explizit über das oben genannte Protokoll für sie freigegeben wurde. Wenn das Gerät die Ausnahmestufe Arm S-EL2 unterstützt, sollte dies vom Secure Partition Manager erzwungen werden. Andernfalls sollte dies vom TEE-Betriebssystem erzwungen werden.
Neue Anforderungen erstellen
Eine Speichersicherheitstechnologie ist eine Technologie, mit der mindestens die folgenden Klassen von Fehlern mit einer hohen Wahrscheinlichkeit (> 90%) in Anwendungen behoben werden, die die Manifestoption android:memtagMode
verwenden:
- Heap-Pufferüberlauf
- Nach Ablauf der kostenlosen Testversion verwenden
- Double Free
- Wild Free (ohne Nicht-Malloc-Pointer)
Geräteimplementierungen:
- [C-SR-15] wird dringend empfohlen,
ro.arm64.memtag.bootctl_supported
festzulegen.
Wenn das Systemattribut ro.arm64.memtag.bootctl_supported
bei Implementierungen auf Geräten auf „true“ gesetzt wird, geschieht Folgendes:
[C-3-1] MÜSSEN der Systemeigenschaft
arm64.memtag.bootctl
erlauben, eine durch Kommas getrennte Liste der folgenden Werte zu akzeptieren, wobei der gewünschte Effekt beim nächsten nachfolgenden Neustart angewendet wird:memtag
: Eine der oben definierten Speichersicherheitstechnologien ist aktiviert.memtag-once
: Eine wie oben definierte Speichersicherheitstechnologie ist vorübergehend aktiviert und beim nächsten Neustart automatisch deaktiviert.memtag-off
: Eine der oben definierten Speichersicherheitstechnologien ist deaktiviert.
[C-3-2] MÜSSEN dem Shell-Nutzer erlauben,
arm64.memtag.bootctl
festzulegen.[C-3-3] MÜSSEN jedem Prozess erlauben,
arm64.memtag.bootctl
zu lesen.[C-3-4] MÜSSEN
arm64.memtag.bootctl
beim Booten auf den aktuell angeforderten Status setzen. Wenn die Geräteimplementierung den Status ändern kann, ohne die Systemeigenschaft zu ändern, MUSS auch die Eigenschaft aktualisiert werden.[C-SR-16] wird dringend empfohlen, eine Entwicklereinstellung anzuzeigen, die das Memtag-Ereignis einmalig festlegt und das Gerät neu startet. Mit einem kompatiblen Bootloader erfüllt das Android-Open-Source-Projekt die oben genannten Anforderungen über das MTE-Bootloader-Protokoll.
- [C-SR-17] Es wird dringend empfohlen, im Menü "Sicherheitseinstellungen" eine Einstellung anzuzeigen, mit der Nutzer
memtag
aktivieren können.
Neue Anforderungen beenden
9.8 Datenschutz
9.8.1 Nutzungsverlauf
Android speichert den Verlauf der Auswahl des Nutzers und verwaltet diesen Verlauf durch UsageStatsManager.
Geräteimplementierungen:
- [C-0-1] MÜSSEN eine angemessene Aufbewahrungsdauer für einen solchen Nutzerverlauf beibehalten.
- [C-SR-1] wird dringend empfohlen, die in der AOSP-Implementierung konfigurierte 14-tägige Aufbewahrungsdauer beizubehalten.
Android speichert die Systemereignisse mit den StatsLog
-IDs und verwaltet diesen Verlauf über die System-API StatsManager
und IncidentManager
.
Geräteimplementierungen:
- [C-0-2] DARF nur die mit
DEST_AUTOMATIC
gekennzeichneten Felder im Vorfallsbericht enthalten, der von der System-API-KlasseIncidentManager
erstellt wurde. - [C-0-3] DÜRFEN die Systemereignis-IDs nicht verwenden, um andere Ereignisse als in den
StatsLog
SDK-Dokumenten beschrieben zu protokollieren. Wenn zusätzliche Systemereignisse protokolliert werden, KÖNNEN sie eine andere Atomkennung im Bereich zwischen 100.000 und 200.000 verwenden.
9.8.2 Aufnahme läuft
Geräteimplementierungen:
- [C-0-1] Dürfen Softwarekomponenten, die die privaten Informationen des Nutzers (z.B. Tastenanschläge, auf dem Bildschirm angezeigter Text, Fehlerbericht) senden, NICHT vorab laden oder verbreiten, ohne dass der Nutzer seine Zustimmung eingeholt oder die Benachrichtigungen gelöscht hat.
- [C-0-2] MÜSSEN eine Nutzerwarnung anzeigen und die ausdrückliche Einwilligung des Nutzers einholen, damit alle auf dem Bildschirm des Nutzers angezeigten vertraulichen Informationen erfasst werden können
, die genau die gleiche Nachricht wie AOSP enthalten,wennjeder Mal eine Sitzung zur Erfassung des Bildschirm-Streams oder der Bildschirmaufzeichnungaktiviert ist}{/1/MediaProjection.createVirtualDisplay()
.} 0.VirtualDeviceManager.createVirtualDisplay()
DÜRFEN Nutzern NICHT die Möglichkeit geben, die spätere Anzeige der Nutzereinwilligung zu deaktivieren. - [C-0-3] MUSS eine fortlaufende Benachrichtigung an den Nutzer erhalten, während die Bildschirmübertragung oder die Bildschirmaufzeichnung aktiviert ist. AOSP erfüllt diese Anforderung durch ein fortlaufendes Benachrichtigungssymbol in der Statusleiste.
Neue Anforderungen erstellen
[C-SR-1] Es wird dringend empfohlen, eine Nutzerwarnung anzuzeigen, die genau der in AOSP implementierten Nachricht entspricht, die jedoch geändert werden kann, solange der Nutzer deutlich darauf hingewiesen wird, dass vertrauliche Informationen auf dem Bildschirm des Nutzers erfasst werden.
[C-0-4] DÜRFEN Nutzern die Möglichkeit bieten, zukünftige Aufforderungen der Nutzereinwilligung zur Bildschirmaufnahme zu deaktivieren, es sei denn, die Sitzung wird von einer System-App gestartet, der der Nutzer
associate()
mit demandroid.app.role.COMPANION_DEVICE_APP_STREAMING
- oder demandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
-Geräteprofil gestattet hat.Neue Anforderungen beenden
Wenn Geräteimplementierungen Funktionen im System umfassen, die entweder die auf dem Bildschirm angezeigten Inhalte erfassen und/oder den auf dem Gerät wiedergegebenen Audiostream aufzeichnen, außer über die System-API ContentCaptureService
, oder andere proprietäre Maßnahmen, die in Abschnitt 9.8.6 auf Betriebssystemebene und Umgebungsdaten beschrieben sind, gilt Folgendes:
- [C-1-1] MÜSSEN eine fortlaufende Benachrichtigung an den Nutzer gesendet werden, wenn diese Funktion aktiviert ist und die Aufzeichnung/Aufzeichnung aktiv ist.
Wenn Geräteimplementierungen eine standardmäßig aktivierte Komponente enthalten, die Umgebungsgeräusche aufzeichnen und/oder die auf dem Gerät wiedergegebenen Audiodaten aufzeichnen kann, um nützliche Informationen zum Nutzerkontext abzuleiten, gilt Folgendes:
- [C-2-1] DARF NICHT im dauerhaften Speicher auf dem Gerät gespeichert oder das aufgezeichnete Rohaudio oder ein anderes Format, das zurück in die Originalaudioinhalte oder ein Nahefeld konvertiert werden kann, vom Gerät übertragen, es sei denn, dies wurde ausdrücklich genehmigt.
Eine „Mikrofonanzeige“ bezieht sich auf eine Ansicht auf dem Bildschirm, die für den Nutzer ständig sichtbar ist und nicht verdeckt werden kann. Nutzer erkennen sie als Mikrofon, das verwendet wird(durch eindeutige Texte, Farben, Symbole oder Kombinationen).
Eine „Kameraanzeige“ bezieht sich auf eine Ansicht auf dem Bildschirm, die für den Nutzer ständig sichtbar ist und nicht verdeckt werden kann und die Nutzer als eine Kamera verwenden (durch eindeutige Texte, Farben, Symbole oder Kombinationen davon).
Nach der ersten Sekunde kann sich ein Indikator visuell verändern und wird z. B. kleiner. Er muss nicht so dargestellt werden, wie er ursprünglich präsentiert und verstanden wurde.
Die Mikrofonanzeige kann mit einer aktiv angezeigten Kameraanzeige zusammengeführt werden, sofern Text, Symbole oder Farben den Nutzer darauf hinweisen, dass die Mikrofonnutzung begonnen hat.
Die Kameraanzeige kann mit einer aktiv angezeigten Mikrofonanzeige zusammengeführt werden, sofern Text, Symbole oder Farben den Nutzer darauf hinweisen, dass die Kameranutzung begonnen hat.
Wenn in Geräteimplementierungen android.hardware.microphone
deklariert wird, gilt Folgendes:
- [C-SR-1] Es wird dringend empfohlen, die Mikrofonanzeige einzublenden, wenn eine App auf Audiodaten vom Mikrofon zugreift. Es wird jedoch nicht auf das Mikrofon zugegriffen, wenn nur
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
oder Apps mit den in Abschnitt 9.1 „Berechtigungen mit CDD-Kennung [C-3-X]“ aufgeführten Rollen auf das Mikrofon zugreifen. . - [C-SR-2] wird dringend empfohlen, die Liste der zuletzt verwendeten und aktiven Apps, die das Mikrofon verwenden, wie von
PermissionManager.getIndicatorAppOpUsageData()
zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen anzuzeigen. - [C-SR-3] Es wird dringend empfohlen, die Mikrofonanzeige für System-Apps, die sichtbare Benutzeroberflächen oder direkte Nutzerinteraktionen haben, nicht auszublenden.
Wenn in Geräteimplementierungen android.hardware.camera.any
deklariert wird, gilt Folgendes:
- [C-SR-4] Es wird dringend empfohlen, die Kameraanzeige einzublenden, wenn eine App auf Live-Kameradaten zugreift, jedoch nicht, wenn nur Apps mit den in Abschnitt 9.1 „Berechtigungen“ genannten Rollen mit der CDD-Kennung [C-3-X] auf die Kamera zugreifen.
- [C-SR-5] Es wird dringend empfohlen, kürzlich verwendete und aktive Apps mit der Kamera, wie sie von
PermissionManager.getIndicatorAppOpUsageData()
zurückgegeben wird, zusammen mit allen damit verbundenen Quellenangaben anzuzeigen. - [C-SR-6] Es wird dringend empfohlen, die Kameraanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen nicht auszublenden.
9.8.3 Internetverbindung
Wenn Geräteimplementierungen einen USB-Port mit Unterstützung für den USB-Peripheriemodus haben, gilt Folgendes:
- [C-1-1] MÜSSEN eine Benutzeroberfläche einblenden, in der die Zustimmung des Nutzers eingeholt wird, bevor der Zugriff auf den Inhalt des freigegebenen Speichers über den USB-Port möglich ist.
9.8.4 Netzwerkverkehr
Geräteimplementierungen:
- [C-0-1] MÜSSEN dieselben Root-Zertifikate für den vom System vertrauenswürdigen CA-Speicher vorinstallieren, die im vorgelagerten Android-Open-Source-Projekt bereitgestellt sind.
- [C-0-2] MÜSSEN mit einem leeren Root-CA-Nutzerspeicher ausgeliefert werden.
- [C-0-3] MÜSSEN dem Nutzer eine Warnung anzeigen, die besagt, dass der Netzwerkverkehr möglicherweise überwacht wird, wenn eine Root-Zertifizierungsstelle des Nutzers hinzugefügt wird.
Wenn Gerätetraffic über ein VPN weitergeleitet wird, gilt für Geräteimplementierungen Folgendes:
- [C-1-1] MUSS dem Nutzer eine Warnung anzeigen, die entweder
- Dieser Netzwerkverkehr wird möglicherweise überwacht.
- Dieser Netzwerktraffic wird über die spezifische VPN-Anwendung geleitet, die das VPN bereitstellt.
Wenn Geräteimplementierungen einen Mechanismus haben, der standardmäßig standardmäßig aktiviert ist und Netzwerkdatenverkehr über einen Proxyserver oder VPN-Gateway weiterleitet (z. B. durch Vorabladen eines VPN-Dienstes mit gewährtem android.permission.CONTROL_VPN
), gilt Folgendes:
- [C-2-1] MÜSSEN vor der Aktivierung dieses Mechanismus die Einwilligung des Nutzers einholen, es sei denn, das VPN wird vom Device Policy Controller über die
DevicePolicyManager.setAlwaysOnVpnPackage()
aktiviert. In diesem Fall muss der Nutzer keine gesonderte Einwilligung geben, sondern nur benachrichtigt werden.
Wenn in Geräteimplementierungen die Funktion „durchgehend aktives VPN“ einer Drittanbieter-VPN-App für Nutzer aktiviert werden soll, gilt Folgendes:
- [C-3-1] MUSS dieses Nutzerangebot für Apps, die den durchgehend aktiven VPN-Dienst nicht in der Datei
AndroidManifest.xml
nicht unterstützen, deaktivieren. Dazu setzen Sie das AttributSERVICE_META_DATA_SUPPORTS_ALWAYS_ON
auffalse
.
9.8.5 Geräte-IDs
Geräteimplementierungen:
- [C-0-1] MÜSSEN den Zugriff auf die Seriennummer und gegebenenfalls die IMEI/MEID, die SIM-Seriennummer und die International Mobile Subscriber Identity (IMSI) einer App verhindern, sofern keine der folgenden Anforderungen erfüllt ist:
- ist eine signierte Mobilfunkanbieter-App, die von Geräteherstellern verifiziert wird.
- hat die Berechtigung
READ_PRIVILEGED_PHONE_STATE
erhalten. - verfügt über Mobilfunkanbieterberechtigungen, die in den UICC-Mobilfunkanbieterberechtigungen definiert sind.
- ist ein Geräte- oder Profilinhaber mit der Berechtigung
READ_PHONE_STATE
. - (Nur für SIM-Seriennummer/ICCID) Gemäß den lokalen Vorschriften muss die App Änderungen an der Identität des Abonnenten erkennen.
9.8.6. Aufnahme von Inhalten und App-SucheDaten auf Betriebssystemebene und Umgebungsdaten
Android unterstützt über die System-APIs einen Mechanismus für Geräteimplementierungen, mit dem die folgenden ContentCaptureService
, AugmentedAutofillService
, AppSearchGlobalManager.query
oder mit anderen proprietären MittelnInteraktionen zwischen Anwendungsdaten zwischen den Anwendungen und dem Nutzer für sensible Daten erfasst werden:
- Auf dem Bildschirm gerenderte Texte und Grafiken, einschließlich, aber nicht beschränkt auf Benachrichtigungen und Unterstützungsdaten über die
AssistStructure
API. - Mediendaten wie Audio oder Video, die vom Gerät aufgenommen oder abgespielt wurden.
- Eingabeereignisse (z. B. Taste, Maus, Touch-Geste, Sprache, Video und Bedienungshilfen)
Neue Anforderungen erstellen
- Alle Bildschirm- oder anderen Daten, die über
AugmentedAutofillService
an das System gesendet werden. - Alle Bildschirme oder andere Daten, auf die über die
Content Capture
API zugegriffen werden kann. - Alle Bildschirme oder andere Daten, auf die über die
FieldClassificationService
API zugegriffen werden kann - Alle Anwendungsdaten, die über die
AppSearchManager
API an das System übergeben und überAppSearchGlobalManager.query
zugänglich sind.
Neue Anforderungen beenden
- Alle anderen Ereignisse, die eine App dem System über die
Content Capture
API oder dieAppSearchManager
API, eine ähnlich leistungsfähige Android- und proprietäre API, zur Verfügung stellt.
- Text oder andere Daten, die über
TextClassifier API
an den System TextClassifier, also an den Systemdienst, gesendet werden, um die Bedeutung von Text zu verstehen und basierend auf dem Text vorhergesagte nächste Aktionen zu generieren. - Daten, die von der AppSearch-Implementierung der Plattform indexiert wurden, einschließlich, aber nicht beschränkt auf Text, Grafiken, Mediendaten oder andere ähnliche Daten.
Neue Anforderungen erstellen
- Audiodaten, die durch die Verwendung von
SpeechRecognizer#onDeviceSpeechRecognizer()
durch die Implementierung der Spracherkennung abgerufen wurden. - Audiodaten, die im Hintergrund (fortlaufend) über
AudioRecord
,SoundTrigger
oder andere Audio-APIs abgerufen werden, ohne dass sie für den Nutzer sichtbar sind - Kameradaten, die im Hintergrund (fortlaufend) über CameraManager oder andere Kamera-APIs abgerufen werden, ohne dass für den Nutzer ein Indikator angezeigt wird
Neue Anforderungen beenden
Wenn Geräteimplementierungen eines der oben genannten Daten erheben, geschieht Folgendes:
- [C-1-1] MÜSSEN alle diese Daten verschlüsseln, wenn sie auf dem Gerät gespeichert werden. Diese Verschlüsselung KANN mithilfe der dateibasierten Android-Verschlüsselung oder einer der im Cipher SDK beschriebenen Chiffren mit API-Version 26 oder höher erfolgen.
- [C-1-2] DÜRFEN KEINE Rohdaten oder verschlüsselten Daten mit Android-Sicherungsmethoden oder anderen Sicherungsmethoden sichern.
- [C-1-3] MUSS nur alle diese Daten
und das Logüber eine datenschutzfreundliche Methode vom Gerät senden, außer bei jeder Freigabe der Daten mit ausdrücklicher Zustimmung des Nutzers. Der Datenschutzmechanismus ist definiert als „Mechanismen, die nur Analysen in aggregierter Form ermöglichen und den Abgleich protokollierter Ereignisse oder abgeleiteter Ergebnisse mit einzelnen Nutzern verhindern“, um zu verhindern, dass nutzerspezifische Daten introspektiv sind (z.B. durch Implementierung einer Differential Privacy-Technologie wieRAPPOR
). - [C-1-4] DÜRFEN solche Daten NICHT mit einer Nutzeridentität (z. B.
Account
) auf dem Gerät verknüpfen, es sei denn, die ausdrückliche Einwilligung des Nutzers für die Verknüpfung von Daten ist erforderlich. - [C-1-5] Diese Daten dürfen NICHT an andere Betriebssystemkomponenten weitergegeben werden, die nicht den im aktuellen Abschnitt (9.8.6
Inhaltserfassung) auf Betriebssystemebene und Umgebungsdaten beschriebenen Anforderungen entsprechen, es sei denn, die Freigabe erfolgt mit ausdrücklicher Zustimmung des Nutzers. Sofern diese Funktionen nicht als Android SDK API (AmbientContext
,HotwordDetectionService
) erstellt werden. - [C-1-6] MÜSSEN Nutzern die Möglichkeit bieten, solche Daten zu löschen, die von der
-Implementierung oder den proprietären Mitteln erhoben werden,ContentCaptureService
wennwann die Daten in irgendeiner Form auf dem Gerät gespeichert werden. Wenn der Nutzer die Daten löschen möchte, MÜSSEN alle gesammelten Verlaufsdaten entfernt werden. - [C-1-7] MÜSSEN Nutzern die Möglichkeit bieten, die über AppSearch oder proprietären Verfahren erhobenen Daten zu deaktivieren, damit sie nicht auf der Android-Plattform, z.B. Launcher angezeigt werden.
- [C-SR-1] Es wird dringend empfohlen, die Berechtigung INTERNET NICHT anzufordern.
- [C-SR-2] wird dringend empfohlen, nur über strukturierte APIs auf das Internet zuzugreifen, die von öffentlich verfügbaren Open-Source-Implementierungen unterstützt werden.
Neue Anforderungen erstellen
- [C-SR-4] EMPFOHLENE Implementierung mit der Android SDK API oder einem ähnlichen Open-Source-Repository eines OEMs und / oder in einer Sandbox-Implementierung (siehe Abschnitt 9.8.15 Sandboxed API-Implementierungen).
Neue Anforderungen beenden
Wenn Geräteimplementierungen einen Dienst umfassen, der die System API ContentCaptureService
, AppSearchManager.index
oder einen proprietären Dienst implementiert, der die Daten wie oben beschrieben erfasst, geschieht Folgendes:
- [C-2-1] DÜRFEN Nutzern NICHT erlauben, die Dienste durch eine vom Nutzer installierbare Anwendung oder einen vom Nutzer installierbaren Dienst zu ersetzen, und MÜSSEN nur den vorinstallierten Diensten erlauben, solche Daten zu erfassen.
- [C-2-2] DÜRFEN NICHT zulassen, dass mit Ausnahme der vorinstallierten Dienste andere Apps solche Daten erheben.
- [C-2-3] MÜSSEN Nutzern angeboten werden, die Dienste deaktivieren können.
- [C-2-4] DARF NICHT auf die Nutzerangebote verzichten, um Android-Berechtigungen der Dienste zu verwalten und dem Android-Berechtigungsmodell zu folgen, wie in Abschnitt 9.1 beschrieben. Berechtigung:
[C-SR-3] Es wird dringend empfohlen, die Dienste von anderen Systemkomponenten zu trennen(z.B. nicht die Dienst- oder Prozess-IDs zu binden), mit Ausnahme der folgenden:
- Telefonie, Kontakte, System-UI und Medien
Android bietet über SpeechRecognizer#onDeviceSpeechRecognizer()
die Möglichkeit, auf dem Gerät eine Spracherkennung durchzuführen, ohne das Netzwerk einzubeziehen.
Jede Implementierung der Spracherkennung auf dem Gerät MUSS den in diesem Abschnitt beschriebenen Richtlinien entsprechen.
9.8.7 Zugriff auf Zwischenablage
Geräteimplementierungen:
[C-0-1] DARF KEINE abgeschnittenen Daten aus der Zwischenablage zurückgeben (z.B. über die
ClipboardManager
API), es sei denn, die Drittanbieter-App ist der Standard-IME oder die App, auf die derzeit der Fokus liegt.[C-0-2] MÜSSEN die Daten in der Zwischenablage höchstens 60 Minuten, nachdem sie zuletzt in der Zwischenablage abgelegt oder aus der Zwischenablage gelesen wurden, gelöscht werden.
9.8.8 Standort
Der Standort umfasst Informationen in der Android-Standortklasse, z. B. Breiten-, Längengrad und Höhe sowie Kennungen, die in „Standort“ umgewandelt werden können. Der Standort kann so genau wie DGPS (Differential Global Positioning System) oder nur auf Länderebene angegeben werden (z. B. Standort mit Ländercode – MCC – Mobile Country Code).
Im Folgenden finden Sie eine Liste von Standorttypen, die entweder direkt den Standort eines Nutzers ableiten oder in ihn umgewandelt werden können. Dies ist keine vollständige Liste, sondern sollte als Beispiel dafür verwendet werden, wovon der Standort direkt oder indirekt abgeleitet werden kann:
- GPS/GNSS/DGPS/PPP
- Global Positioning Solution, Global Navigation Satellite System oder Differential Global Positioning Solution
- Dazu gehören auch GNSS-Rohdaten und der GNSS-Status.
- Der genaue Standort kann aus den GNSS-Rohmessungen abgeleitet werden.
- Funktechnologien mit eindeutigen IDs wie:
- WLAN-Zugangspunkte (MAC, BSSID, Name oder SSID)
- Bluetooth/BLE (MAC, BSSID, Name oder SSID)
- UWB (MAC, BSSID, Name oder SSID)
- Mobilfunkmast-ID (3G, 4G, 5G... einschließlich aller zukünftigen Mobilfunkmodemtechnologien mit eindeutigen IDs)
Sehen Sie sich als Hauptreferenz die Android-APIs an, für die die Berechtigungen ACCESS_FINE_Location oder ACCESS_COARSE_Location erforderlich sind.
Geräteimplementierungen:
- [C-0-1] DÜRFEN NICHT die Einstellung für den Gerätestandort und die Einstellungen für die WLAN-/Bluetooth-Suche ohne ausdrückliche Nutzereinwilligung oder Initiierung durch den Nutzer aktivieren/deaktivieren.
- [C-0-2] MÜSSEN dem Nutzer die Möglichkeit bieten, auf standortbezogene Informationen zuzugreifen, einschließlich der letzten Standortanfragen, Berechtigungen auf App-Ebene und die Nutzung der WLAN-/Bluetooth-Suche zur Standortbestimmung.
- [C-0-3] MÜSSEN Sie sicherstellen, dass die Anwendung, die die Emergency Location Bypass API [LocationRequest.setLocationSettingsignored()] verwendet, eine vom Nutzer initiierte Notfallsitzung ist (z.B. 911 wählen oder eine SMS an 911 senden). In der Automobilbranche KANN ein Fahrzeug jedoch ohne aktive Nutzerinteraktion eine Notfallsitzung starten, wenn ein Unfall oder Unfall erkannt wird (z.B. um die Anforderungen für eCall zu erfüllen).
- [C-0-4] Die Emergency Location Bypass API MUSS die Möglichkeit erhalten, die Einstellungen für den Gerätestandort zu umgehen, ohne die Einstellungen zu ändern.
- [C-0-5] MÜSSEN eine Benachrichtigung planen, mit der der Nutzer erinnert wird, nachdem eine App im Hintergrund mit der Berechtigung [
ACCESS_BACKGROUND_LOCATION
] auf seinen Standort zugegriffen hat.
9.8.9. Installierte Apps
Android-Apps, die auf API-Level 30 oder höher ausgerichtet sind, können standardmäßig keine Details zu anderen installierten Apps sehen. Weitere Informationen finden Sie in der Android SDK-Dokumentation unter Paketsichtbarkeit.
Geräteimplementierungen:
- [C-0-1] DÜRFEN KEINE Details zu anderen installierten Apps für das App-Targeting auf API-Level 30 oder höher sichtbar machen, es sei denn, die App kann bereits über die verwalteten APIs Details zur anderen installierten App abrufen. Dazu gehören unter anderem Details, die über benutzerdefinierte APIs bereitgestellt werden, die vom Geräte-Implementierer hinzugefügt wurden oder über das Dateisystem zugänglich sind.
- [C-0-2] DÜRFEN keiner Anwendung Lese- oder Schreibzugriff auf Dateien im dedizierten, anwendungsspezifischen Verzeichnis innerhalb des externen Speichers gewähren. Es gelten nur die folgenden Ausnahmen:
- Die Zertifizierungsstelle des externen Speicheranbieters (z. B. Apps wie DocumentsUI)
- Downloadanbieter, der die Anbieterberechtigung „Downloads“ zum Herunterladen von Dateien in den App-Speicher verwendet.
- MTP-Apps (Platform Signed Media Transfer Protocol), die die privilegierte Berechtigung ACCESS_MTP verwenden, um die Übertragung von Dateien auf ein anderes Gerät zu ermöglichen.
- Apps, bei denen andere Apps installiert werden und die die Berechtigung INSTALL_PACKAGES haben, dürfen nur zur Verwaltung von APK-Erweiterungsdateien auf „obb“-Verzeichnisse zugreifen.
9.8.10. Fehlerbericht zur Verbindung
Wenn Geräteimplementierungen das Funktions-Flag android.hardware.telephony
deklarieren, geschieht Folgendes:
- [C-1-1] MUSS das Generieren von Verbindungsfehlerberichten über
BUGREPORT_MODE_TELEPHONY
mit BugreportManager unterstützen. - [C-1-2] MÜSSEN jedes Mal die Nutzereinwilligung einholen, wenn
BUGREPORT_MODE_TELEPHONY
zum Generieren eines Berichts verwendet wird, und DARF den Nutzer NICHT dazu auffordern, bei zukünftigen Anfragen von der Anwendung zuzustimmen. - [C-1-3] DÜRFEN den erstellten Bericht ohne ausdrückliche Nutzereinwilligung NICHT an die anfragende App zurückgeben.
- [C-1-4] Mit
BUGREPORT_MODE_TELEPHONY
generierte Berichte MÜSSEN mindestens die folgenden Informationen enthalten:TelephonyDebugService
-DumpTelephonyRegistry
-DumpWifiService
-DumpConnectivityService
-Dump- Dump der Instanz
CarrierService
des aufrufenden Pakets (falls gebunden) - Funkprotokollzwischenspeicher
SubscriptionManagerService
-Dump
- [C-1-5] DÜRFEN Folgendes in den erstellten Berichten NICHT enthalten:
- Alle Arten von Informationen, die nicht direkt mit dem Beheben von Verbindungsfehlern zusammenhängen.
- Jegliche Art von vom Nutzer installierten Traffic-Logs für Anwendungen oder detaillierten Profile von vom Nutzer installierten Anwendungen/Paketen (UIDs sind in Ordnung, Paketnamen nicht).
- KANN zusätzliche Informationen enthalten, die mit keiner Nutzeridentität in Verbindung stehen. (z.B. Anbieterprotokolle).
Wenn Geräteimplementierungen zusätzliche Informationen (z.B. Anbieterprotokolle) in Fehlerbericht enthält und diese Informationen Auswirkungen auf Datenschutz, Sicherheit, Akku, Speicher oder Arbeitsspeicher haben, gilt Folgendes:
- [C-SR-1] Es wird dringend empfohlen, die Entwicklereinstellung standardmäßig auf "Deaktiviert" zu setzen. Die AOSP-Referenzimplementierung erfüllt diese Anforderungen durch die Option
Enable verbose vendor logging
in den Entwicklereinstellungen, um zusätzliche gerätespezifische Anbieterlogs in die Fehlerberichte aufzunehmen.
9.8.11. Freigabe von Daten-Blobs
Android ermöglicht über BlobStoreManager Apps, Daten-Blobs an das System zu senden, damit diese für einen ausgewählten Satz von Apps freigegeben werden.
Wenn Geräteimplementierungen freigegebene Daten-BLOBs unterstützen, wie in der SDK-Dokumentation beschrieben, gilt Folgendes:
- [C-1-1] DÜRFEN KEINE Daten-Blobs von Apps über die vorgesehenen Berechtigungen hinaus freigeben (d.h. über den Umfang des Standardzugriffs und die anderen Zugriffsmodi, die mit BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() oder BlobStoreManager.session#allowPublicAccess() festgelegt werden können) NICHT geändert werden. Die AOSP-Referenzimplementierung erfüllt diese Anforderungen.
- [C-1-2] DÜRFEN KEINE sicheren Hashes von Daten-BLOBs (die zur Zugriffssteuerung verwendet werden) vom Gerät senden oder an andere Anwendungen weitergeben.
9.8.12. Musikerkennung
Android unterstützt über die System API MusicRecognitionManager einen Mechanismus für Geräteimplementierungen, um Musikerkennung anhand eines Audioeintrags anzufordern und die Musikerkennung an eine privilegierte App zu delegieren, die die MusicRecognitionService API implementiert.
Wenn Geräteimplementierungen einen Dienst umfassen, der den MusicRecognitionManager der System API oder einen proprietären Dienst implementiert, der Audiodaten wie oben beschrieben streamt, gilt Folgendes:
- [C-1-1] MÜSSEN erzwingen, dass der Aufrufer von MusicRecognitionManager die Berechtigung
MANAGE_MUSIC_RECOGNITION
hat. - [C-1-2] MÜSSEN erzwingen, dass MusicRecognitionService von einer einzelnen vorinstallierten Musikerkennungsanwendung implementiert wird.
- [C-1-3] DÜRFEN Nutzern NICHT erlauben, den MusicRecognitionManagerService oder MusicRecognitionService durch eine vom Nutzer installierbare Anwendung oder einen vom Nutzer installierbaren Dienst zu ersetzen.
- [C-1-4] MÜSSEN sicherstellen, dass der Audiozugriff über Aufrufe von AppOpsManager.noteOp / startOp erfasst wird, wenn MusicRecognitionManagerService auf den Audioeintrag zugreift und ihn an die Anwendung weiterleitet, die den MusicRecognitionService implementiert.
Wenn Geräteimplementierungen von MusicRecognitionManagerService oder MusicRecognitionService erfasste Audiodaten speichern, geschieht Folgendes:
- [C-2-1] DÜRFEN KEINE unformatierten Audio- oder Audio-Fingerabdrücke auf der Festplatte oder länger als 14 Tage im Speicher speichern.
- [C-2-2] DÜRFEN derartige Daten NICHT über MusicRecognitionService hinaus weitergeben, außer bei jeder Freigabe mit ausdrücklicher Zustimmung des Nutzers.
9.8.13. SensorPrivacyManager
Wenn Geräteimplementierungen Nutzern die Möglichkeit bieten, die Kamera und/oder den Mikrofoneingang auszuschalten, gilt Folgendes:
- [C-1-1] MUSS für die relevante API-Methode supportsSensorToggle() korrekt "true" zurückgeben.
- [C-1-2] MÜSSEN, wenn eine App versucht, auf ein blockiertes Mikrofon oder eine blockierte Kamera zuzugreifen, dem Nutzer eine Anzeige zu präsentieren, die sich nicht schließen lässt und die deutlich darauf hinweist, dass der Sensor blockiert ist und dass gemäß der AOSP-Implementierung, die diese Anforderung erfüllt, eine Option zum weiteren Blockieren oder Aufheben der Blockierung erforderlich ist.
- [C-1-3] DARF nur leere (oder gefälschte) Kamera- und Audiodaten an Apps übergeben und keinen Fehlercode melden, wenn der Nutzer die Kamera oder das Mikrofon nicht über die oben in [C-1-2] dargestellten Funktionen einschaltet.
Neue Anforderungen erstellen
9.8.14. Anmeldedaten-Manager
Entfernt.
9.8.15. Sandbox-API-Implementierungen
Android bietet über eine Reihe von delegierten APIs einen Mechanismus, um sichere Betriebssystem- und Umgebungsdaten zu verarbeiten. Eine solche Verarbeitung kann an ein vorinstalliertes APK mit privilegiertem Zugriff und eingeschränkten Kommunikationsfunktionen delegiert werden. Dies wird als „Sandboxed API-Implementierung“ bezeichnet.
Jede Sandboxed API-Implementierung:
- [C-0-1] DARF NICHT die INTERNET-Berechtigung anfordern.
- [C-0-2] DARF nur über strukturierte APIs auf das Internet zugreifen, die auf öffentlich verfügbaren Open-Source-Implementierungen basieren, die datenschutzfreundliche Mechanismen verwenden, oder indirekt über Android SDK APIs. Der Datenschutzmechanismus ist definiert als „Mechanismen, die nur die Analyse in aggregierter Form ermöglichen und den Abgleich protokollierter Ereignisse oder abgeleiteter Ergebnisse mit einzelnen Nutzern verhindern“, um zu verhindern, dass nutzerspezifische Daten nehmbar sind (z.B. implementiert mit einer Differential Privacy-Technologie wie RAPPOR).
- [C-0-3] MÜSSEN die Dienste von anderen Systemkomponenten getrennt halten (z.B. nicht die Dienst- oder Freigabeprozess-IDs binden), mit folgenden Ausnahmen:
- Telefonie, Kontakte, System-UI und Medien
- [C-0-4] Nutzern DARF NICHT erlauben, die Dienste durch eine vom Nutzer installierbare Anwendung oder einen Dienst zu ersetzen
- [C-0-5] MUSS nur den vorinstallierten Diensten erlauben, solche Daten zu erfassen. Es sei denn, die Ersatzfunktion ist in AOSP integriert (z.B. für Apps für digitale Assistenten).
- [C-0-6] DÜRFEN zulassen, dass außer den Mechanismen der vorinstallierten Dienste nur die Apps der vorinstallierten Dienste solche Daten erfassen. Es sei denn, eine solche Erfassungsfunktion ist mit einer Android SDK API implementiert.
- [C-0-7] MÜSSEN die Dienste zur Deaktivierung von Nutzerfunktionen anbieten.
- [C-0-8] DARF NICHT auf die Nutzerangebote verzichten, um Android-Berechtigungen der Dienste zu verwalten und dem Android-Berechtigungsmodell zu folgen, wie in Abschnitt 9.1. Berechtigung:
9.8.16. Kontinuierliche Audio- und Kameradaten
Zusätzlich zu den in 9.8.2 Aufzeichnung, 9.8.6 Implementierungen auf Betriebssystem- und Umgebungsdaten und 9.8.15 API-Implementierungen in einer Sandbox beschriebenen Anforderungen, Implementierungen, die Audiodaten verwenden, die im Hintergrund (ständig) über AudioRecord, SoundTrigger oder andere Audio-APIs ODER Kamera-Daten im Hintergrund (fortlaufend) über CameraManager oder andere Kamera-APIs abgerufen werden:
- [C-0-1] MÜSSEN eine entsprechende Anzeige (Kamera und/oder Mikrofon gemäß Abschnitt 9.8.2 Aufzeichnung) erzwingen, es sei denn:
- Dieser Zugriff erfolgt in einer Sandbox-Implementierung (siehe 9.8.15 Sandboxed API-Implementierung) über ein Paket mit einer oder mehreren der folgenden Rollen: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence oder System Visual Intelligence.
- Der Zugriff wird über eine Sandbox ausgeführt, implementiert und durch Mechanismen in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
) erzwungen. - Der Audiozugriff wird zu unterstützenden Zwecken von der App „Digital Assistant“ durchgeführt, wobei
SOURCE_HOTWORD
als Audioquelle angegeben wird. - Der Zugriff wird vom System durchgeführt und mit Open-Source-Code implementiert.
- [C-SR-1] Es wird dringend empfohlen, für jede Funktion, die solche Daten verwendet, die Einwilligung der Nutzer einzuholen. Diese Funktion sollte standardmäßig deaktiviert sein.
- [C-SR-2] EMPFOHLEN, Kameradaten von einem tragbaren Remote-Gerät gleich zu behandeln (d.h., die in 9.8.2 Aufzeichnung, 9.8.6 Betriebssystem- und Umgebungsdaten, 9.8.15 Sandboxed API-Implementierungen und 9.8.16 Continuous Audio- und Kameradaten beschriebenen Einschränkungen) auf Kameradaten anzuwenden.
Wenn die Kameradaten von einem Wearable-Remote-Gerät bereitgestellt werden und außerhalb des Android-Betriebssystems in unverschlüsselter Form außerhalb des Android-Betriebssystems, einer Sandbox-Implementierung oder einer von WearableSensingManager
erstellten Sandbox-Funktion zugegriffen wird, gilt Folgendes:
- [C-1-1] MUSS dem tragbaren Remote-Gerät angeben, dass dort eine zusätzliche Anzeige eingeblendet wird.
Wenn Geräte die Möglichkeit bieten, ohne das zugewiesene Schlüsselwort mit einer Digital Assistant-Anwendung zu interagieren (entweder zur Verarbeitung allgemeiner Nutzeranfragen oder zur Analyse der Nutzerpräsenz über die Kamera):
- [C-2-1] MÜSSEN dafür sorgen, dass eine solche Implementierung von einem Paket mit der Rolle
android.app.role.ASSISTANT
bereitgestellt wird. - [C-2-2] MÜSSEN darauf achten, dass bei dieser Implementierung
HotwordDetectionService
- und/oderVisualQueryDetectionService
-Android-APIs verwendet werden.
9.8.17. Telemetry
Android speichert System- und App-Protokolle mithilfe von StatsLog APIs. Diese Logs werden über StatsManager APIs verwaltet, die von privilegierten Systemanwendungen verwendet werden können.
StatsManager bietet auch eine Möglichkeit zum Erfassen von Daten, die von Geräten mit einem datenschutzfreundlichen Mechanismus als datenschutzsensibel eingestuft werden. Insbesondere bietet die StatsManager::query
API die Möglichkeit, eingeschränkte Messwertkategorien abzufragen, die in StatsLog definiert sind.
Jede Implementierungsabfrage und das Erfassen eingeschränkter Messwerte von StatsManager:
- [C-0-1] MUSS die einzige Anwendung/Implementierung auf dem Gerät sein und die Berechtigung
READ_RESTRICTED_STATS
haben. - [C-0-2] DARF nur Telemetriedaten und das Protokoll des Geräts unter Verwendung eines Mechanismus zur Einhaltung des Datenschutzes senden. Der Datenschutzmechanismus ist definiert als „Mechanismen, die nur Analysen in aggregierter Form ermöglichen und den Abgleich protokollierter Ereignisse oder abgeleiteter Ergebnisse mit einzelnen Nutzern verhindern“, um zu verhindern, dass nutzerspezifische Daten introspektiv sind (z.B. Implementierung mit einer Differential Privacy-Technologie wie RAPPOR).
- [C-0-3] DÜRFEN solche Daten NICHT mit einer Nutzeridentität (z. B. Account) auf dem Gerät verknüpfen.
- [C-0-4] DÜRFEN derartige Daten NICHT an andere Betriebssystemkomponenten weitergeben, die nicht den im aktuellen Abschnitt (9.8.17 Datenschutzfreundliche Telemetrie) beschriebenen Anforderungen entsprechen.
- [C-0-5] MÜSSEN eine Funktion zum Aktivieren/Deaktivieren der datenschutzfreundlichen Erfassung, Verwendung und Weitergabe von Telemetriedaten zur Verfügung stellen.
- [C-0-6] MÜSSEN Nutzern die Möglichkeit bieten, solche Daten zu löschen, die von der Implementierung erhoben werden, wenn diese in irgendeiner Form auf dem Gerät gespeichert werden. Wenn der Nutzer die Daten löschen möchte, MÜSSEN alle aktuell auf dem Gerät gespeicherten Daten entfernt werden.
- [C-0-7] MÜSSEN die zugrunde liegende datenschutzfreundliche Protokollimplementierung in einem Open-Source-Repository offenlegen.
- [C-0-8 ]MÜSSEN in diesem Abschnitt Richtlinien für ausgehenden Datentraffic erzwingen, um die Erfassung von Daten in eingeschränkten Messwertkategorien, die in StatsLog definiert sind, zu steuern.
Neue Anforderungen beenden
9.9. Verschlüsselung der Datenspeicherung
Alle Geräte MÜSSEN die Anforderungen in Abschnitt 9.9.1 erfüllen. Geräte, die auf einer API-Ebene vor dem in diesem Dokument auf den Markt gebracht wurden, sind von den Anforderungen der Abschnitte 9.9.2 und 9.9.3 ausgenommen. Sie müssen stattdessen die Anforderungen in Abschnitt 9.9 des Dokuments zur Android-Kompatibilitätsdefinition erfüllen, das dem API-Level entspricht, auf dem das Gerät gestartet wurde.
9.9.1 Direct Boot
Geräteimplementierungen:
[C-0-1] MÜSSEN die APIs für den Direct Boot Mode auch dann implementieren, wenn sie die Speicherverschlüsselung nicht unterstützen.
[C-0-2] Die Intents
ACTION_LOCKED_BOOT_COMPLETED
undACTION_USER_UNLOCKED
MÜSSEN weiterhin übertragen werden, um Direct Boot-fähige Anwendungen zu signalisieren, dass die Speicherstandorte für Geräte mit Verschlüsselung (Device Encrypted (DE) und Credential Encrypted (CE) für den Nutzer verfügbar sind.
9.9.2 Verschlüsselungsanforderungen
Geräteimplementierungen:
- [C-0-1] MÜSSEN die privaten Daten der Anwendung (Partition
/data
) sowie die Partition des freigegebenen Speichers der Anwendung (Partition/sdcard
) verschlüsseln, wenn es sich dabei um einen dauerhaften, nicht entfernbaren Teil des Geräts handelt. - [C-0-2] MÜSSEN die Verschlüsselung von Datenspeichern standardmäßig zu dem Zeitpunkt aktivieren, zu dem der Nutzer die vorkonfigurierte Einrichtung abgeschlossen hat.
[C-0-3] MUSS die oben genannte Anforderung zur Datenspeicherverschlüsselung durch Implementierung einer der folgenden beiden Verschlüsselungsmethoden erfüllen:
- Dateibasierte Verschlüsselung (File-Based Encryption, FBE) und Metadatenverschlüsselung, wie in Abschnitt 9.9.3.1 beschrieben.
- Verschlüsselung auf Blockebene pro Nutzer, wie in Abschnitt 9.9.3.2 beschrieben.
9.9.3 Verschlüsselungsmethoden
Bei verschlüsselten Geräteimplementierungen gilt Folgendes:
- [C-1-1] MÜSSEN gestartet werden, ohne dass der Nutzer nach Anmeldedaten gefragt wird. Außerdem müssen Direct Boot-fähige Anwendungen auf den DE-Speicher (Device Encrypted) zugreifen können, nachdem die Nachricht
ACTION_LOCKED_BOOT_COMPLETED
gesendet wurde. - [C-1-2] DARF erst den Zugriff auf den CE-Speicher (Credential Encrypted) erlauben, nachdem der Nutzer das Gerät durch Angabe seiner Anmeldedaten (z. B. Sicherheitscode, PIN, Muster oder Fingerabdruck) entsperrt hat und die Nachricht
ACTION_USER_UNLOCKED
übertragen wurde. - [C-1-13] DARF KEINE Methode zum Freischalten des CE-geschützten Speichers ohne vom Nutzer bereitgestellte Anmeldedaten, einen registrierten Treuhandschlüssel oder einen Lebenslauf bei der Implementierung des Neustarts anbieten, die die Anforderungen in Abschnitt 9.9.4 erfüllt.
- [C-1-4] MÜSSEN den verifizierten Bootmodus verwenden.
9.9.3.1 Dateibasierte Verschlüsselung mit Metadatenverschlüsselung
Wenn Geräteimplementierungen die dateibasierte Verschlüsselung mit Metadatenverschlüsselung verwenden, gilt Folgendes:
- [C-1-5] MÜSSEN Dateiinhalte und Dateisystemmetadaten mit AES-256-XTS oder Adiantum verschlüsseln. AES-256-XTS bezieht sich auf den Advanced Encryption Standard mit einer Länge eines Chiffreschlüssels von 256 Bit, der im XTS-Modus betrieben wird. Die volle 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, Eigentümerschaft, Modi und erweiterte Attribute (Xattrs).
- [C-1-6] MÜSSEN Dateinamen mit AES-256-CBC-CTS, AES-256-HCTR2 oder Adiantum verschlüsseln.
- [C-1-12] Wenn das Gerät über AES-Anweisungen (Advanced Encryption Standard) verfügt (z. B. ARMv8 Cryptography Extensions auf ARM-basierten Geräten oder AES-NI auf x86-basierten Geräten), MÜSSEN die oben genannten AES-basierten Optionen für Dateinamen, Dateiinhalte und Verschlüsselung von Dateisystem-Metadaten verwendet werden, nicht Adiantum.
- [C-1-13] MÜSSEN eine kryptografisch starke und nicht umkehrbare Schlüsselableitungsfunktion (z.B. HKDF-SHA512) verwenden, um alle erforderlichen Unterschlüssel (z.B. Schlüssel pro Datei) aus den CE- und DE-Schlüsseln abzuleiten. "Kryptografisch stark und nicht umkehrbar" bedeutet, dass die Schlüsselableitungsfunktion eine Sicherheitsstärke von mindestens 256 Bit hat und sich über ihre Eingaben wie eine Pseudozufallsfunktionsfamilie verhält.
- [C-1-14] DÜRFEN NICHT dieselben FBE-Schlüssel oder -Unterschlüssel für unterschiedliche kryptografische Zwecke verwenden, z.B. sowohl für die Verschlüsselung als auch für die Schlüsselableitung oder für zwei verschiedene Verschlüsselungsalgorithmen.
- [C-1-15] MÜSSEN sicherstellen, dass alle nicht gelöschten Blöcke verschlüsselter Dateiinhalte im nichtflüchtigen Speicher mit Kombinationen aus Verschlüsselungsschlüssel und Initialisierungsvektor (IV) verschlüsselt wurden, die sowohl von der Datei als auch vom Offset innerhalb der Datei abhängen. Darüber hinaus MÜSSEN alle derartigen Kombinationen unterschiedlich sein, es sei denn, die Verschlüsselung erfolgt mit Inline-Verschlüsselungshardware, die nur eine IV-Länge von 32 Bit unterstützt.
- [C-1-16] MÜSSEN sicherstellen, dass alle nicht gelöschten verschlüsselten Dateinamen im nichtflüchtigen Speicher in verschiedenen Verzeichnissen mit unterschiedlichen Kombinationen aus Verschlüsselungsschlüssel und Initialisierungsvektor (IV) verschlüsselt wurden.
[C-1-17] MÜSSEN sicherstellen, dass alle verschlüsselten Metadatenblöcke des Dateisystems im nichtflüchtigen Speicher mit unterschiedlichen Kombinationen aus Verschlüsselungsschlüssel und Initialisierungsvektor (IV) verschlüsselt wurden.
Schlüssel zum Schutz der CE- und DE-Speicherbereiche und Dateisystemmetadaten:
- [C-1-7] MÜSSEN kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. Dieser Schlüsselspeicher MÜSSEN an den verifizierten Bootmodus und den Hardware-Root of Trust des Geräts gebunden sein.
- [C-1-8] CE-Schlüssel MÜSSEN an die Anmeldedaten des Nutzers auf dem Sperrbildschirm 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 eindeutig sein. Mit anderen Worten: Der CE- oder DE-Schlüssel eines Nutzers stimmt nicht mit den CE- oder DE-Schlüsseln anderer Nutzer überein.
- [C-1-11] MÜSSEN die vorgeschriebenen Chiffren, Schlüssellängen und Modi verwenden.
- [C-1-12] MÜSSEN beim Entsperren und Sperren des Bootloaders sicher gelöscht werden, wie hier beschrieben.
SOLLTE Vorinstallierte wichtige Apps (z.B. Wecker, Telefon, Messenger) mit Direct Boot-Modus ausgestattet werden.
Das vorgelagerte Open-Source-Projekt von Android bietet eine bevorzugte Implementierung der dateibasierten Verschlüsselung basierend auf dem Verschlüsselungsfeature „fscrypt“ des Linux-Kernels und der Metadatenverschlüsselung auf Grundlage des Features „dm-default-key“ des Linux-Kernels.
9.9.3.2 Verschlüsselung auf Blockebene pro Nutzer
Wenn in Geräteimplementierungen die Verschlüsselung auf Blockebene pro Nutzer verwendet wird, gilt Folgendes:
- [C-1-1] MÜSSEN die Unterstützung für mehrere Nutzer wie in Abschnitt 9.5 beschrieben aktivieren.
- [C-1-2] MÜSSEN Partitionen pro Nutzer bereitstellen, entweder mithilfe von Rohpartitionen oder logischen Volumes.
- [C-1-3] MÜSSEN für die Verschlüsselung der zugrunde liegenden Blockgeräte pro Nutzer eindeutige und eindeutige Verschlüsselungsschlüssel verwenden.
[C-1-4] MÜSSEN AES-256-XTS für die Verschlüsselung der Nutzerpartitionen auf Blockebene verwenden.
Die Schlüssel zum Schutz der auf Blockebene verschlüsselten Geräte pro Nutzer:
- [C-1-5] MÜSSEN kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. Dieser Schlüsselspeicher MÜSSEN an den verifizierten Bootmodus und den Hardware-Root of Trust des Geräts gebunden sein.
- [C-1-6] MÜSSEN an die Anmeldedaten des entsprechenden Nutzers für den Sperrbildschirm gebunden sein.
Die nutzerspezifische Verschlüsselung auf Blockebene kann mit dem Linux-Kernel-Feature „dm-crypt“ über nutzerspezifische Partitionen implementiert werden.
9.9.4 Bei Neustart fortsetzen
„Beim Neustart fortsetzen“ ermöglicht das Entsperren des CE-Speichers aller Anwendungen, einschließlich der Apps, die Direct Boot noch nicht unterstützen, nach einem von einem OTA initiierten Neustart. Mit dieser Funktion können Nutzer nach dem Neustart Benachrichtigungen von installierten Apps erhalten.
Eine Implementierung von „Fortsetzen beim Neustart“ muss weiterhin dafür sorgen, dass es für den Angreifer extrem schwierig ist, die CE-verschlüsselten Daten des Nutzers wiederherzustellen, wenn ein Gerät in die Hände eines Angreifers fällt, selbst wenn das Gerät eingeschaltet, der CE-Speicher entsperrt und der Nutzer das Gerät nach Erhalt eines OTA-Geräts entsperrt hat. Für die Abwehr von Insiderangriffen gehen wir außerdem davon aus, dass der Angreifer Zugriff auf die Übertragung kryptografischer Signaturschlüssel erhält.
Im Detail:
[C-0-1] Der CE-Speicher DARF selbst für Angreifer, die das Gerät in der Hand haben und dann die folgenden Funktionen und Einschränkungen haben, NICHT lesbar sein:
- Kann mit dem Signaturschlüssel eines beliebigen Anbieters oder Unternehmens zum Signieren beliebiger Nachrichten verwendet werden.
- Kann dazu führen, dass ein Over-the-air-Update (OTA) auf dem Gerät empfangen wird.
- Kann den Betrieb jeder Hardware (z. B. ZP, Flash) mit Ausnahme der unten aufgeführten Details ändern. Solche Änderungen erfordern jedoch eine Verzögerung von mindestens einer Stunde und einen Neustart, durch den die RAM-Inhalte gelöscht werden.
- Der Betrieb von manipulationssicherer Hardware (z. B. Titan M) kann nicht geändert werden.
- RAM des Live-Geräts kann nicht gelesen werden.
- Die Anmeldedaten des Nutzers (PIN, Muster, Passwort) können nicht abgerufen oder anderweitig eingegeben werden.
Beispielsweise entspricht eine Geräteimplementierung, die alle hier aufgeführten Beschreibungen implementiert und befolgt, [C-0-1].
9:10. Geräteintegrität
Die folgenden Anforderungen sorgen dafür, dass der Status der Geräteintegrität transparent ist. Geräteimplementierungen:
[C-0-1] MÜSSEN über die System-API-Methode
PersistentDataBlockManager.getFlashLockState()
korrekt melden, ob ihr Bootloader-Status das Flashen des System-Images zulässt.[C-0-2] MUSS zur Geräteintegrität den verifizierten Bootmodus unterstützen.
Geräteimplementierungen, die bereits in einer früheren Android-Version ohne Unterstützung des verifizierten Bootmodus gestartet wurden und diese Funktion nicht durch ein Systemsoftwareupdate unterstützen können, sind MÖGLICHERWEISE von dieser Anforderung ausgenommen.
Der verifizierte Bootmodus ist eine Funktion, die die Integrität der Gerätesoftware garantiert. Wenn Geräteimplementierungen die Funktion unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN das Funktions-Flag für die Plattform
android.software.verified_boot
deklarieren. - [C-1-2] MUSS bei jeder Startsequenz eine Überprüfung durchführen.
- [C-1-3] MÜSSEN die Überprüfung von einem unveränderlichen Hardwareschlüssel starten, der die Root of Trust ist, und bis zur Systempartition gehen.
- [C-1-4] MÜSSEN in der nächsten Phase jede Überprüfungsphase implementieren, um die Integrität und Authentizität aller Byte zu prüfen, bevor der Code in der nächsten Phase ausgeführt wird.
- [C-1-5] MÜSSEN Verifikationsalgorithmen verwenden, die den aktuellen Empfehlungen des NIST für Hash-Algorithmen (SHA-256) und Größen öffentlicher Schlüssel (RSA-2048) entsprechen.
- [C-1-6] DARF NICHT zulassen, dass der Bootvorgang abgeschlossen wird, wenn die Systemüberprüfung fehlschlägt, es sei denn, der Nutzer willigt ein, trotzdem zu starten. In diesem Fall DÜRFEN die Daten aus nicht verifizierten Speicherblöcken nicht verwendet werden.
- [C-1-7] DARF NICHT zulassen, dass verifizierte Partitionen auf dem Gerät geändert werden, es sei denn, der Nutzer hat den Bootloader explizit entsperrt.
- [C-SR-1] Wenn das Gerät mehrere separate Chips enthält (z.B. Funkschnittstelle oder ein spezialisierter Bildprozessor), wird dringend empfohlen, für den Startvorgang von jedem dieser Chips jede Phase beim Starten zu überprüfen.
- [C-1-8] MÜSSEN einen manipulationssicheren Speicher verwenden, um zu speichern, ob der Bootloader entsperrt ist. Ein fälschungssicherer Speicher bedeutet, dass der Bootloader erkennen kann, ob der Speicher in Android manipuliert wurde.
- [C-1-9] MÜSSEN den Nutzer bei der Verwendung des Geräts auffordern und vor einem Wechsel vom gesperrten Bootloader-Modus zum entsperrten Bootloader-Modus eine physische Bestätigung erfordern.
- [C-1-10] MÜSSEN für von Android verwendete Partitionen (z.B. Booten, Systempartitionen) einen Rollback-Schutz implementieren und einen manipulationssicheren Speicher zum Speichern der Metadaten verwenden, mit denen die mindestens zulässige Betriebssystemversion ermittelt wird.
- [C-1-11] MÜSSEN alle Nutzerdaten während des Entsperrens und Sperrens des Bootloaders sicher löschen (gemäß 9.12). Data Deletion“ (Daten löschen)“ (einschließlich der Nutzerdatenpartition und aller NVRAM-Bereiche).
- [C-SR-2] Es wird dringend empfohlen, alle privilegierten APK-Dateien von privilegierten Apps mit einer Vertrauenskette zu prüfen, die sich in Partitionen befindet, die durch den verifizierten Bootmodus geschützt sind.
- [C-SR-3] Es wird dringend empfohlen, ausführbare Artefakte, die von einer privilegierten App von außerhalb ihrer APK-Datei geladen werden (z. B. dynamisch geladener oder kompilierter Code), vor der Ausführung zu prüfen, oder UNBEDINGT EMPFOHLEN, sie nicht auszuführen.
- SOLLTEN für alle Komponenten mit beständiger Firmware (z.B. Modem, Kamera) einen Rollback-Schutz implementieren und einen manipulationssicheren Speicher zum Speichern der Metadaten verwenden, die zum Ermitteln der zulässigen Mindestversion verwendet werden.
Geräteimplementierungen, die bereits auf einer früheren Version von Android ohne Unterstützung von C-1-8 bis C-1-11 eingeführt wurden und diese Anforderungen nicht durch ein Systemsoftwareupdate unterstützen können, sind MÖGLICHERWEISE von den Anforderungen ausgenommen.
Das vorgelagerte Android-Open-Source-Projekt bietet eine bevorzugte Implementierung dieser Funktion im Repository external/avb/
, das in den Bootloader integriert werden kann, der zum Laden von Android verwendet wird.
Geräteimplementierungen
Wenn Geräteimplementierungen Dateiinhalte auf Seitenbasis prüfen können, gilt Folgendes:
[
C-0-3C-2-1] unterstützt die kryptografische Überprüfung von Dateiinhaltenmit einem vertrauenswürdigen Schlüssel, ohne die gesamte Datei zu lesen.[
C-0-4C-2-2] DARF NICHT zulassen, dass Leseanfragen für eine geschützte Datei erfolgreich sind, wenn der gelesene Inhaltnicht anhand eines vertrauenswürdigen Schlüssels verifiziertwird und nicht gemäß [C-2-1] oben überprüft wird.
Neue Anforderungen erstellen
- [C-2-4] MÜSSEN für aktivierte Dateien Datei-Prüfsumme in O(1) zurückgeben.
Neue Anforderungen beenden
Geräteimplementierungen, die bereits auf einer früheren Android-Version ohne die Möglichkeit zur Prüfung des Dateiinhalts anhand eines vertrauenswürdigen Schlüssels gestartet wurden und diese Funktion nicht durch ein Systemsoftwareupdate unterstützen können, sind MÖGLICHERWEISE von dieser Anforderung ausgenommen. Das vorgelagerte Open-Source-Projekt von Android bietet eine bevorzugte Implementierung dieser Funktion, die auf dem Feature fs-verity des Linux-Kernels basiert.
Geräteimplementierungen:
- [C-SR-4] wird dringend empfohlen, die Android Protected Confirmation API zu unterstützen.
Wenn Geräteimplementierungen die Android Protected Confirmation API unterstützen, gilt Folgendes:
[C-3-1] MÜSSEN
true
für dieConfirmationPrompt.isSupported()
API melden.[C-3-2] MÜSSEN sicherstellen, dass Code, der im Android-Betriebssystem einschließlich seines Kernels ausgeführt wird, ob bösartig oder anderweitig, ohne Nutzerinteraktion eine positive Antwort erzeugen kann.
[C-3-3] MÜSSEN sicherstellen, dass der Nutzer die entsprechende Meldung prüfen und genehmigen konnte, auch 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 über die KeyChain API oder die Keystore API für kryptografische Vorgänge verwenden. Geräteimplementierungen:
- [C-0-1] MÜSSEN zulassen,dass mindestens 8.192 Schlüssel importiert oder generiert werden.
- [C-0-2] Bei der Authentifizierung auf dem Sperrbildschirm MÜSSEN ein Zeitintervall zwischen den fehlgeschlagenen Versuchen implementiert werden. Bei n als Anzahl der fehlgeschlagenen Versuche MUSS das Zeitintervall mindestens 30 Sekunden für 9 < n < 30 betragen. Bei n > 29 MUSS der Zeitintervallwert mindestens 30*2^floor((n-30)/10) Sekunden oder mindestens 24 Stunden betragen, je nachdem, welcher Wert kleiner ist.
- SOLLTE die Anzahl der Schlüssel, die generiert werden können, nicht einschränken
Neue Anforderungen erstellen
- [C-0-3] MÜSSEN die Anzahl der fehlgeschlagenen primären Authentifizierungsversuche begrenzen.
- [C-SR-2] Es wird dringend empfohlen, eine Obergrenze von 20 fehlgeschlagenen primären Authentifizierungsversuchen zu implementieren. Wenn Nutzer einwilligen und der Funktion zustimmen, sollten sie nach Überschreiten der maximalen Anzahl fehlgeschlagener primärer Authentifizierungsversuche ein Zurücksetzen auf die Werkseinstellungen durchführen.
Wenn bei Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden, wenn dies auf einem bekannten Secret basiert, und eine neue Authentifizierungsmethode verwendet wird, die als sichere Methode zum Sperren des Bildschirms behandelt wird, dann:
- [C-SR-3] Eine PIN sollte mindestens 6 Ziffern oder eine 20-Bit-Entropie enthalten.
- [C-2-1] Bei einer PIN mit weniger als 6 Ziffern DARF die automatische Eingabe ohne Nutzerinteraktion NICHT erlaubt werden, damit die PIN-Länge nicht offengelegt wird.
Neue Anforderungen beenden
Wenn die Geräteimplementierung einen sicheren Sperrbildschirm unterstützt, geschieht Folgendes:
- [C-1-1] MÜSSEN die Schlüsselspeicherimplementierung in einer isolierten Ausführungsumgebung sichern.
- [C-1-2] MÜSSEN Implementierungen von RSA, AES, ECDSA, ECDH (wenn IKeyMintDevice), 3DES und HMAC kryptografische Algorithmen sowie MD5-, SHA1- und SHA-2-Familien-Hash-Funktionen haben, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich zu unterstützen, der sicher von dem Code isoliert ist, der im Kernel und darüber ausgeführt wird. Sichere Isolation MÜSSEN alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das vorgelagerte Open-Source-Projekt von Android (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternativ können auch eine andere ARM TrustZone-basierte Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer ordnungsgemäßen Hypervisor-basierten Isolierung verwendet werden.
- [C-1-3] MÜSSEN die Sperrbildschirm-Authentifizierung in der isolierten Ausführungsumgebung ausführen und nur bei erfolgreicher Ausführung die Verwendung der authentifizierungsgebundenen Schlüssel zulassen. Sperrbildschirm-Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Sperrbildschirm-Authentifizierung durchführen kann. Das vorgelagerte Android-Open-Source-Projekt bietet den Gatekeeper Hardware Abstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
- [C-1-4] MÜSSEN die Schlüsselattestierung unterstützen, wenn der Attestierungssignaturschlüssel durch sichere Hardware geschützt und die Signatur auf sicherer Hardware erfolgt. Die Signaturschlüssel für die Attestierung MÜSSEN für eine ausreichend große Anzahl von Geräten freigegeben werden, um zu verhindern, dass die Schlüssel als Gerätekennungen verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer Artikelnummer erzeugt werden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, kann für 100.000 Einheiten ein anderer Schlüssel verwendet werden.
Wenn eine Geräteimplementierung bereits unter einer früheren Android-Version gestartet wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen Schlüsselspeicher in einer isolierten Ausführungsumgebung zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert die Funktion android.hardware.fingerprint
, die einen Schlüsselspeicher erfordert, der von einer isolierten Ausführungsumgebung unterstützt wird.
- [C-1-5] MÜSSEN dem Nutzer die Auswahl des Ruhemodus-Timeouts für den Wechsel vom entsperrten in den gesperrten Zustand mit einem zulässigen Mindestzeitlimit von bis zu 15 Sekunden ermöglichen. Automobilgeräte, die den Bildschirm sperren, wenn die Haupteinheit ausgeschaltet oder der Nutzer gewechselt wird, KANN NICHT die Konfiguration für das Zeitlimit für den Ruhemodus haben.
- [C-1-6] MUSS IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice Version 1 oder IKeyMintDevice Version 2 unterstützen.
- [C-SR-1] wird dringend empfohlen, IKeyMintDevice Version 1 zu unterstützen.
9.11.1. Sicherer Sperrbildschirm, Authentifizierung und virtuelle Geräte
Die AOSP-Implementierung folgt einem gestaffelten Authentifizierungsmodell, bei dem eine auf Wissenswerk basierende primäre Authentifizierung entweder durch eine sekundäre starke biometrische Methode oder durch schwächere tertiäre Modalitäten gestützt werden kann.
Geräteimplementierungen:
[C-SR-1] Es wird dringend empfohlen, nur eine der folgenden Optionen als primäre Authentifizierungsmethode festzulegen:
- Eine numerische PIN
- Ein alphanumerisches Passwort
Ein Wischmuster auf einem Raster mit genau 3 x 3 Punkten
Die oben genannten Authentifizierungsmethoden werden in diesem Dokument als empfohlene primäre Authentifizierungsmethoden bezeichnet.
Neue Anforderungen erstellen
- [C-0-1] MÜSSEN die Anzahl der fehlgeschlagenen primären Authentifizierungsversuche begrenzen.
- [C-SR-5] Es wird dringend empfohlen, eine Obergrenze von 20 fehlgeschlagenen primären Authentifizierungsversuchen zu implementieren. Wenn Nutzer der Funktion zustimmen und der Funktion zustimmen, nach Überschreiten des Limits für fehlgeschlagene primäre Authentifizierungsversuche ein Zurücksetzen auf die Werkseinstellungen durchführen.
Wenn in Geräteimplementierungen eine numerische PIN als empfohlene primäre Authentifizierungsmethode festgelegt ist, gehe so vor:
- [C-SR-6] Eine PIN sollte mindestens 6 Ziffern oder eine 20-Bit-Entropie haben.
- [C-SR-7] Bei einer PIN mit weniger als 6 Ziffern wird dringend empfohlen, die automatische Eingabe ohne Nutzerinteraktion NICHT zu erlauben, um zu verhindern, dass die PIN offengelegt wird.
Neue Anforderungen beenden
Wenn bei Geräteimplementierungen die empfohlenen primären Authentifizierungsmethoden hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode als sichere Methode zum Sperren des Bildschirms verwendet wird, gilt die neue Authentifizierungsmethode:
- [C-2-1] MUSS die Nutzerauthentifizierungsmethode sein, wie unter Nutzerauthentifizierung für Schlüsselverwendung erforderlich beschrieben.
Wenn bei Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden, sofern dies auf einem bekannten Secret basiert, und eine neue Authentifizierungsmethode verwenden, die als sichere Methode zum Sperren des Bildschirms 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 MÜSSEN deaktiviert werden, wenn die Device Policy Controller-Anwendung (DPC) die Richtlinie zu Passwortanforderungen über die DevicePolicyManager.setRequiredPasswordComplexity() mit einer restriktiveren Komplexitätskonstante als PASSWORD_COMPLEXITY_NONE oder über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Konstante als PASSWORTQUALITY festgelegt hat.
- [C-3-5] Neue Authentifizierungsmethoden MÜSSEN entweder höchstens alle 72 Stunden auf die empfohlenen primären Authentifizierungsmethoden (z.B. PIN, Muster, Passwort) zurückgreifen ODER dem Nutzer unmissverständlich offenlegen, dass einige Daten aus Datenschutzgründen nicht gesichert werden.
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 biometrischen Verfahren als sichere Methode zum Sperren des Bildschirms basiert, gilt die neue Methode:
- [C-4-1] MÜSSEN alle in Abschnitt 7.3.10 beschriebenen Anforderungen für Klasse 1 (früher Komfort) erfüllen.
- [C-4-2] MÜSSEN einen Fallback-Mechanismus haben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Secret basieren.
- [C-4-3] MÜSSEN deaktiviert sein und nur die empfohlene primäre Authentifizierung zum Entsperren des Bildschirms zulassen, wenn die Device Policy Controller-Anwendung (DPC) die Keyguard-Funktionsrichtlinie durch Aufrufen der Methode
DevicePolicyManager.setKeyguardDisabledFeatures()
mit einem der zugehörigen biometrischen Flags (z.B.KEYGUARD_DISABLE_BIOMETRICS
,KEYGUARD_DISABLE_FINGERPRINT
,KEYGUARD_DISABLE_FACE
oderKEYGUARD_DISABLE_IRIS
) festgelegt hat.
Wenn die biometrischen Authentifizierungsmethoden nicht die in Abschnitt 7.3.10 beschriebenen Anforderungen für Klasse 3 (früher Strong) erfüllen:
- [C-5-1] Die Methoden MÜSSEN deaktiviert werden, wenn die Device Policy Controller-Anwendung (DPC) die Qualitätsrichtlinie für Passwortanforderungen über DevicePolicyManager.setRequiredPasswordComplexity() mit einem restriktiveren Komplexitäts-Bucket als
PASSWORD_COMPLEXITY_LOW
oder über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante alsPASSWORD_QUALITY_BIOMETRIC_WEAK
festgelegt hat. - [C-5-2] Der Nutzer MUSS zur empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden, wie in [C-1-7] und [C-1-8] in Abschnitt 7.3.10 beschrieben.
- [C-5-3] Die Methoden DÜRFEN NICHT als sicherer Sperrbildschirm behandelt werden und MÜSSEN die Anforderungen erfüllen, die mit C-8 in diesem Abschnitt 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] Sie MÜSSEN über einen Fallback-Mechanismus verfügen, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Secret basieren und die Anforderungen für einen sicheren Sperrbildschirm erfüllen.
- [C-6-2] Die neue Methode MÜSSEN deaktiviert werden und nur eine der empfohlenen primären Authentifizierungsmethoden zum Entsperren des Bildschirms zulassen, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie mit einem der folgenden Werte festgelegt hat:
- Die Methode
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
- Die Methode
DevicePolicyManager.setPasswordQuality()
mit einer restriktiveren Qualitätskonstante alsPASSWORD_QUALITY_NONE
. - Die Methode
DevicePolicyManager.setRequiredPasswordComplexity()
mit einem restriktiveren Komplexitäts-Bucket alsPASSWORD_COMPLEXITY_NONE
.
- Die Methode
- [C-6-3] Der Nutzer MUSS mindestens einmal alle 4 Stunden zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z.B.PIN, Muster, Passwort) aufgefordert werden. Wenn ein physisches Token die Anforderungen für TrustAgent-Implementierungen in C-X erfüllt, gelten stattdessen die in C-9-5 definierten Zeitlimitbeschränkungen.
- [C-6-4] Die neue Methode DARF NICHT als sicherer Sperrbildschirm behandelt werden und MÜSSEN den unten in C-8 aufgeführten Einschränkungen entsprechen.
Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agenten enthalten, die die TrustAgentService
System API implementieren, geschieht Folgendes:
- [C-7-1] MUSS im Einstellungsmenü und auf dem Sperrbildschirm deutlich erkennbar sein, wenn die Gerätesperre ausgesetzt ist oder von Trust Agenten entsperrt werden kann. AOSP erfüllt diese Anforderung beispielsweise mit einer Textbeschreibung für die Einstellung „Automatische Sperre“ und „Ein/Aus-Taste wird sofort gesperrt“ im Einstellungsmenü und ein gut erkennbares Symbol auf dem Sperrbildschirm.
- [C-7-2] MÜSSEN alle Trust Agent-APIs in der Klasse
DevicePolicyManager
, z. B. die KonstanteKEYGUARD_DISABLE_TRUST_AGENTS
, respektieren und vollständig implementieren. - [C-7-3] DARF die
TrustAgentService.addEscrowToken()
-Funktion NICHT vollständig auf einem Gerät implementieren, das als primäres persönliches Gerät verwendet wird (z.B. Handheld), aber KANN vollständig auf Geräteimplementierungen implementiert werden, die normalerweise gemeinsam genutzt werden (z.B. Android TV- oder Automotive-Geräte). - [C-7-4] MÜSSEN alle von
TrustAgentService.addEscrowToken()
hinzugefügten gespeicherten Tokens verschlüsseln. - [C-7-5] DARF den Verschlüsselungsschlüssel bzw. das Treuhandtoken NICHT auf dem Gerät speichern, auf dem der Schlüssel verwendet wird. Beispielsweise ist es mit einem auf einem Smartphone gespeicherten Schlüssel zulässig, ein Nutzerkonto auf einem Fernseher zu entsperren. Bei Automotive-Geräten darf das Treuhandtoken nicht in einem Teil des Fahrzeugs gespeichert werden.
- [C-7-6] MÜSSEN den Nutzer über die Auswirkungen auf die Sicherheit informieren, bevor das Treuhandtoken zum Entschlüsseln des Datenspeichers aktiviert wird.
- [C-7-7] MÜSSEN einen Fallback-Mechanismus haben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden.
[C-7-8] Der Nutzer MUSS mindestens alle 72 Stunden zu einer der empfohlenen Methoden zur primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden, es sei denn, die Sicherheit des Nutzers (z. B. Ablenkung des Fahrers) ist ein Problem.- [C-7-9] Der Nutzer MUSS zur Eingabe einer der empfohlenen Methoden zur primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden, wie in [C-1-7] und [C-1-8] in Abschnitt 7.3.10 beschrieben, es sei denn, die Sicherheit des Nutzers (z. B. Ablenkung des Fahrers) ist ein Problem.
- [C-7-10] DARF NICHT als sicherer Sperrbildschirm behandelt werden und MÜSSEN die in C-8 unten aufgeführten Einschränkungen einhalten.
- [C-7-11] DÜRFEN TrustAgents auf primären persönlichen Geräten (z. B. Handheld) NICHT erlauben, das Gerät zu entsperren. Sie können damit ein bereits entsperrtes Gerät maximal 4 Stunden lang im entsperrten Zustand halten. Die Standardimplementierung von TrustManagerService in AOSP erfüllt diese Anforderung.
- [C-7-12] MÜSSEN einen kryptografisch sicheren Kommunikationskanal (z. B. UKEY2) verwenden, um das Treuhandtoken vom Speichergerät an das Zielgerät zu übergeben.
Wenn bei Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden, der kein sicherer Sperrbildschirm ist, wie oben beschrieben, und eine neue Authentifizierungsmethode zum Entsperren des Keyguard verwenden, gilt Folgendes:
- [C-8-1] Die neue Methode MÜSSEN deaktiviert werden, wenn die Device Policy Controller-Anwendung (DPC) die Richtlinie für die Passwortqualität über die Methode
DevicePolicyManager.setPasswordQuality()
mit einer restriktiveren Qualitätskonstante alsPASSWORD_QUALITY_NONE
oder über dieDevicePolicyManager.setRequiredPasswordComplexity()
mit einer restriktiveren Komplexitätskonstante als "PASSWORD_COMPLEXITY_NONE" festgelegt hat. - [C-8-2] Sie DÜRFEN die von
DevicePolicyManager.setPasswordExpirationTimeout()
festgelegten Timer für das Ablaufen des Passworts NICHT zurücksetzen. - [C-8-3] Sie DÜRFEN KEINE API zur Verwendung durch Drittanbieter-Apps verfügbar machen, um den Sperrstatus zu ermitteln.
Wenn Geräteimplementierungen Anwendungen das Erstellen sekundärer virtueller Displays ermöglichen und zugehörige Eingabeereignisse nicht unterstützen, z. B. über VirtualDeviceManager
, gilt Folgendes:
- [C-9-1] MÜSSEN diese sekundären virtuellen Displays sperren, wenn das Standarddisplay des Geräts gesperrt ist, und sie entsperren, wenn das Standarddisplay des Geräts entsperrt ist.
Wenn Geräteimplementierungen Anwendungen erlauben, sekundäre virtuelle Displays zu erstellen und damit verknüpfte Eingabeereignisse zu unterstützen, z. B. über VirtualDeviceManager, gilt Folgendes:
- [C-10-1] MUSS für jedes virtuelle Gerät einen separaten Sperrstatus unterstützen
- [C-10-2] MÜSSEN bei Zeitüberschreitung bei Inaktivität die Verbindung aller virtuellen Geräte getrennt werden
- [C-10-3] MUSS ein Zeitlimit bei Inaktivität haben
- [C-10-4] MÜSSEN alle Displays gesperrt werden, wenn der Nutzer eine Sperrung einleitet, auch über die für Handheld-Geräte erforderliche Funktion zur Nutzersperrung (siehe Abschnitt 2.2.5[9.11/H-1-2]).
- [C-10-5] MÜSSEN separate virtuelle Geräteinstanzen pro Nutzer haben
- [C-10-6] MÜSSEN die Erstellung verknüpfter Eingabeereignisse über
VirtualDeviceManager
deaktivieren, wenn dies durchDevicePolicyManager.setNearbyAppStreamingPolicy
angegeben wird. - [C-10-7] MÜSSEN für jedes virtuelle Gerät eine separate Zwischenablage verwenden (oder die Zwischenablage für virtuelle Geräte deaktivieren).
- [C-10-11] MÜSSEN die Authentifizierungs-UI auf virtuellen Geräten deaktivieren, einschließlich der Eingabe des Wissensfaktors und der biometrischen Aufforderung
- [C-10-12] MÜSSEN die von einem virtuellen Gerät initiierten Intents so einschränken, dass sie nur auf demselben virtuellen Gerät angezeigt werden.
- [C-10-13] DARF keinen virtuellen Gerätesperrstatus als Autorisierung für die Nutzerauthentifizierung mit dem Android-Schlüsselspeichersystem verwenden. Weitere Informationen finden Sie unter
KeyGenParameterSpec.Builder.setUserAuthentication*
.
Wenn Geräteimplementierungen es dem Nutzer ermöglichen, den primären Wissensfaktor für die Authentifizierung von einem Quellgerät auf ein Zielgerät zu übertragen, z. B. bei der Ersteinrichtung des Zielgeräts, geschieht Folgendes:
- [C-11-1] MÜSSEN den Wissensfaktor beim Übertragen des Wissensfaktors vom Quellgerät auf das Zielgerät mit Schutzgarantien, die denen im Sicherheits-Whitepaper von Google Cloud Key Vault beschrieben werden, so verschlüsseln, dass der Wissensfaktor nicht per Fernzugriff entschlüsselt oder zum Entsperren eines der Geräte per Fernzugriff verwendet werden kann.
- [C-11-2] MÜSSEN den Nutzer auf dem Quellgerät bitten, den Wissensfaktor des Quellgeräts zu bestätigen , bevor der Wissensfaktor auf das Zielgerät übertragen wird.
- [C-11-3] MÜSSEN Sie den Nutzer auf einem Zielgerät ohne festgelegten primären Authentifizierungsfaktor bitten, einen übertragenen Wissensfaktor auf dem Zielgerät zu bestätigen, bevor Sie diesen Wissensfaktor als primären Authentifizierungsfaktor für das Zielgerät festlegen und bevor Sie Daten verfügbar machen, die von einem Quellgerät übertragen wurden.
Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agents enthalten, die die TrustAgentService.grantTrust()
System API mit dem Flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
aufrufen:
- [C-12-1] MUSS
grantTrust()
nur dann mit dem Flag aufrufen, wenn sie mit einem nahe gelegenen physischen Gerät mit einem eigenen Sperrbildschirm verbunden ist und der Nutzer seine Identität auf diesem Sperrbildschirm authentifiziert hat. Geräte, die sich in der Nähe befinden, können nach einer einmaligen Entsperrung durch den Nutzer Mechanismen zur Erkennung am Handgelenk oder am Körper verwenden, um die Anforderung zur Nutzerauthentifizierung zu erfüllen. - [C-12-2] MÜSSEN die Geräteimplementierung in den Status
TrustState.TRUSTABLE
versetzen, wenn der Bildschirm ausgeschaltet ist (z. B. durch Drücken einer Schaltfläche oder eine Zeitüberschreitung beim Display) und der TrustAgent das Vertrauen nicht widerrufen hat. Der AOSP erfüllt diese Anforderung. - [C-12-3] DARF das Gerät nur dann von
TrustState.TRUSTABLE
in den StatusTrustState.TRUSTED
versetzen, wenn der TrustAgent gemäß den Anforderungen in C-12-1 weiterhin Vertrauen gewährt. - [C-12-4] MÜSSEN
TrustManagerService.revokeTrust()
maximal 24 Stunden nach Erteilung einer Vertrauensstellung, nach einem 8-stündigen Inaktivitätsfenster oder nach dem Verlust der zugrunde liegenden Verbindung zum nahe gelegenen physischen Gerät aufrufen.
Wenn Geräteimplementierungen Anwendungen erlauben, sekundäre virtuelle Displays zu erstellen und zugehörige Eingabeereignisse wie z. B. VirtualDeviceManager zu unterstützen und die Bildschirme nicht mit VIRTUAL_DISPLAY_FLAG_SECURE gekennzeichnet sind, gilt Folgendes:
- [C-13-8] MÜSSEN activities mit dem Attribut „android:canDisplayOnRemoteDevices“ oder dem Metadaten-Attribut „android.activity.can_display_on_remote_devices“ blockieren, damit sie auf dem virtuellen Gerät nicht gestartet werden.
- [C-13-9] MÜSSEN Aktivitäten blockieren, die Streaming nicht explizit ermöglichen und angeben, dass sie sensible Inhalte anzeigen, einschließlich über SurfaceView#setSecure, FLAG_SECURE oder SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, damit sie auf dem virtuellen Gerät gestartet werden.
[C-13-10] MÜSSEN die Installation von Apps deaktivieren, die über virtuelle Geräte initiiert wurden.
Wenn Geräteimplementierungen separate Energiezustände für das Display über DeviceStateManager
UND über KeyguardDisplayManager
separate Status für die Displaysperre unterstützen, gilt Folgendes:
- [C-SR-2] wird dringend empfohlen, einen Berechtigungsnachweis zu verwenden, der die in Abschnitt 9.11.1 definierten Anforderungen erfüllt, oder ein biometrisches Verfahren, das mindestens die in Abschnitt 7.3.10 definierten Spezifikationen der Klasse 1 erfüllt, um ein unabhängiges Entsperren vom Standard-Gerätedisplay zu ermöglichen.
- [C-SR-3] wird dringend empfohlen, die separate Entsperrung des Displays über ein festgelegtes Zeitlimit für die Anzeige einzuschränken.
- [C-SR-4] Es wird dringend empfohlen, Nutzern das globale Sperren aller Bildschirme durch Sperren des primären Handheld-Geräts zu ermöglichen.
9.11.2. Kofferraum
Mit dem Android-Schlüsselspeichersystem können App-Entwickler kryptografische Schlüssel in einem dedizierten sicheren Prozessor sowie in der oben beschriebenen isolierten Ausführungsumgebung speichern. Ein solcher dedizierter sicherer Prozessor wird als „StrongBox“ bezeichnet. In den nachfolgenden Anforderungen C-1-3 bis C-1-11 werden die Anforderungen definiert, die ein Gerät erfüllen muss, um sich als StrongBox zu qualifizieren.
Geräteimplementierungen mit einem dedizierten sicheren Prozessor:
- [C-SR-1] wird dringend empfohlen, StrongBox zu unterstützen. StrongBox wird wahrscheinlich in einer zukünftigen Version zu einer Voraussetzung werden.
Wenn Geräteimplementierungen StrongBox unterstützen, gilt Folgendes:
[C-1-1] MUSS FEATURE_STRONGBOX_KEYSTORE deklarieren.
[C-1-2] MÜSSEN dedizierte sichere Hardware bereitstellen, die zur Sicherung des Schlüsselspeichers und der sicheren Nutzerauthentifizierung verwendet wird. Die dedizierte Hardware kann auch für andere Zwecke verwendet werden.
[C-1-3] MUSS eine diskrete CPU haben, die keinen Cache, DRAM, Koprozessoren oder andere Kernressourcen mit dem Anwendungsprozessor (AP) teilt.
[C-1-4] MÜSSEN sicherstellen, dass Peripheriegeräte, die mit dem AP gemeinsam genutzt werden, die StrongBox-Verarbeitung in keiner Weise verändern und keine Informationen von der StrongBox abrufen können. Der AP kann den Zugriff auf StrongBox deaktivieren oder blockieren.
[C-1-5] MÜSSEN eine interne Uhr mit angemessener Genauigkeit (+-10%) haben, die nicht von Manipulation durch den ZP betroffen ist.
[C-1-6] MUSS einen echten Zufallszahlengenerator haben, der eine gleichmäßig verteilte und unvorhersehbare Ausgabe erzeugt.
[C-1-7] MUSS manipulationsgeschützt sein, einschließlich Schutz vor physischem Eindringen und Störungen.
[C-1-8] MUSS einen Seitenkanalwiderstand haben, einschließlich des Widerstands gegen das Auslaufen von Informationen über die Seitenkanäle für Strom, Zeit, elektromagnetische Strahlung und Wärmestrahlung.
[C-1-9] MÜSSEN einen sicheren Speicher haben, der Vertraulichkeit, Integrität, Authentizität, Konsistenz und Aktualität der Inhalte gewährleistet. Der Speicher DÜRFEN NICHT gelesen oder geändert werden, sofern dies nicht gemäß den StrongBox-APIs zulässig ist.
Um die Einhaltung von [C-1-3] bis [C-1-9] zu prüfen, Geräteimplementierungen:
- [C-1-10] MÜSSEN die Hardware enthalten, die gemäß dem Secure IC Protection Profile BSI-CC-PP-0084-2014 zertifiziert oder von einem landesweit akkreditierten Testlabor bewertet wurde, das eine Bewertung von Sicherheitslücken mit hohem Angriffspotenzial gemäß der Common Criteria-Anwendung des Angriffspotenzials auf Smartcards anbietet.
- [C-1-11] MUSS die Firmware enthalten, die von einem landesweit akkreditierten Testlabor bewertet wird, das eine Bewertung des Sicherheitslückenpotenzials mit hohem Angriffspotenzial gemäß der Common Criteria-Anwendung des Angriffspotenzials auf Chipkarten bewertet.
- [C-SR-2] wird dringend empfohlen, die Hardware einzubeziehen, die mit einem Sicherheitsziel, EAL 5 (Evaluation Assurance Level, EAL) 5 (erweitert durch AVA_VAN.5) bewertet wird. Die EAL 5-Zertifizierung wird voraussichtlich in einem zukünftigen Release eine Voraussetzung werden.
- [C-SR-3] wird dringend empfohlen, IAR (Insider-Angriffsschutz) bereitzustellen. Dies bedeutet, dass ein Insider mit Zugriff auf Firmware-Signaturschlüssel keine Firmware produzieren kann, die dazu führt, dass StrongBox Secrets sprengt, funktionale Sicherheitsanforderungen umgeht oder anderweitig den Zugriff auf vertrauliche Nutzerdaten ermöglicht. Die empfohlene Methode zur Implementierung von IAR besteht darin, Firmwareupdates nur dann zuzulassen, wenn das Passwort des primären Nutzers über den IAuthSecret-HAL bereitgestellt wird.
9.11.3. Anmeldedaten für Identität
Das Identity Credential System wird definiert und erreicht, indem alle APIs im Paket android.security.identity.*
implementiert werden. Mit diesen APIs können Anwendungsentwickler Dokumente zur Nutzeridentität speichern und abrufen. Geräteimplementierungen:
- [C-SR-1] wird dringend empfohlen, das Identitäts-Anmeldedatensystem zu implementieren.
Wenn das Identity Credential System in Geräteimplementierungen implementiert ist, gilt Folgendes:
[C-1-1] MUSS für die Methode IdentityCredentialStore#getInstance() einen anderen Wert als null zurückgeben.
[C-1-2] MÜSSEN das Identity Credential System (z.B. die
android.security.identity.*
APIs) mit Code implementieren, 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. Sichere Isolation MÜSSEN alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA.[C-1-3] Die zur Implementierung des Identity Credential System erforderlichen kryptografischen Vorgänge (z. B. die
android.security.identity.*
APIs) MÜSSEN vollständig in der vertrauenswürdigen Anwendung ausgeführt werden. Das Material des privaten Schlüssels DARF die isolierte Ausführungsumgebung niemals verlassen, es sei denn, dies wird von übergeordneten APIs gefordert, z. B. die Methode createEphemeralKeyPair().[C-1-4] Die vertrauenswürdige Anwendung MÜSSEN so implementiert werden, dass ihre Sicherheitseigenschaften nicht beeinträchtigt werden (z.B. werden Anmeldedaten nur freigegeben, wenn die Bedingungen der Zugriffssteuerung erfüllt sind, oder MACs können nicht für beliebige Daten erstellt werden), selbst wenn Android falsch funktioniert oder manipuliert wird.
Das vorgelagerte Open-Source-Projekt von Android bietet eine Referenzimplementierung einer vertrauenswürdigen Anwendung (Liberic), mit der das Identitätsanmeldedatensystem implementiert werden kann.
9.12. Löschen von Daten
Alle Geräteimplementierungen:
- [C-0-1] MÜSSEN Nutzern eine Methode zum Zurücksetzen auf die Werkseinstellungen zur Verfügung stellen.
- [C-0-2] MÜSSEN beim Zurücksetzen auf die Werkseinstellungen alle Daten im Dateisystem der Nutzer gelöscht werden.
- [C-0-3] MÜSSEN die Daten beim Zurücksetzen auf die Werkseinstellungen so löschen, dass die relevanten Branchenstandards wie NIST SP800-88 erfüllt werden.
- [C-0-4] MÜSSEN den oben beschriebenen Prozess zum Zurücksetzen auf die Werkseinstellungen auslösen, wenn die
DevicePolicyManager.wipeData()
API von der Device Policy Controller-App des primären Nutzers aufgerufen wird. - KANN eine Option zur schnellen Datenlöschung anbieten, bei der nur eine logische Löschung durchgeführt wird.
9:13. Abgesicherter Modus
Android bietet den abgesicherten Bootmodus, mit dem Nutzer in einem Modus starten können, in dem nur vorinstallierte System-Apps ausgeführt und alle Drittanbieter-Apps deaktiviert sind. Dieser Modus, der als „Abgesicherter Modus“ bezeichnet wird, bietet dem Nutzer die Möglichkeit, potenziell schädliche Apps von Drittanbietern zu deinstallieren.
Es gibt folgende Geräteimplementierungen:
- [C-SR-1] EMPFOHLEN, den abgesicherten Bootmodus zu implementieren.
Wenn Geräteimplementierungen den abgesicherten Bootmodus implementieren, gilt Folgendes:
[C-1-1] MÜSSEN dem Nutzer die Möglichkeit geben, den abgesicherten Bootmodus so zu starten, dass er von auf dem Gerät installierten Drittanbieter-Apps nicht unterbrochen werden kann, es sei denn, die Drittanbieter-App ist ein Device Policy Controller und hat das Flag
UserManager.DISALLOW_SAFE_BOOT
auf „true“ gesetzt.[C-1-2] MÜSSEN dem Nutzer die Möglichkeit geben, Drittanbieter-Apps im abgesicherten Modus zu deinstallieren.
SOLLTE dem Nutzer eine Option anbieten, mit der er über das Bootmenü in den abgesicherten Modus wechseln kann.
9:14. Kfz-Systemisolierung
Von Android Automotive-Geräten wird erwartet, dass sie Daten mit kritischen Fahrzeug-Subsystemen austauschen. Dazu verwenden sie den Fahrzeug-HAL, um Nachrichten über Fahrzeugnetzwerke wie den CAN-Bus zu senden und zu empfangen.
Der Datenaustausch kann abgesichert werden, indem Sicherheitsfunktionen unterhalb der Android-Framework-Ebenen implementiert werden, um bösartige oder unbeabsichtigte Interaktionen mit diesen Subsystemen zu verhindern.
9:15. Abos
„Abos“ beziehen sich auf die Details zur Abrechnungsbeziehung, die von einem Mobilfunkanbieter über SubscriptionManager.setSubscriptionPlans()
bereitgestellt werden.
Alle Geräteimplementierungen:
- [C-0-1] MÜSSEN Abonnements nur an die App des Mobilfunkanbieters zurückgeben, von der sie ursprünglich bereitgestellt wurden.
- [C-0-2] DÜRFEN KEINE Abos per Remotezugriff sichern oder hochladen.
- [C-0-3] DARF nur Überschreibungen wie
SubscriptionManager.setSubscriptionOverrideCongested()
aus der Mobilfunkanbieter-App zulassen, die aktuell gültige Abos anbietet.
9:16. Migration von Anwendungsdaten
Wenn Geräteimplementierungen eine Funktion zum Migrieren von Daten von einem Gerät auf ein anderes Gerät enthalten und die kopierten App-Daten nicht auf die Einstellungen beschränkt sind, die vom App-Entwickler im Manifest über das Attribut android:fullBackupContent konfiguriert wurden, gilt Folgendes:
- [C-1-1] DARF KEINE Übertragungen von Anwendungsdaten von Geräten initiieren, auf denen der Nutzer keine primäre Authentifizierung festgelegt hat, wie unter 9.11.1 Sicherer Sperrbildschirm und Authentifizierung beschrieben.
- [C-1-2] MÜSSEN die primäre Authentifizierung auf dem Quellgerät sicher bestätigen und mit dem Nutzerabsicht bestätigen, dass die Daten auf dem Quellgerät kopiert werden sollen, bevor Daten übertragen werden.
- [C-1-3] MÜSSEN die Sicherheitsschlüsselattestierung verwenden, um sicherzustellen, dass sowohl das Quellgerät als auch das Zielgerät bei der Geräte-zu-Gerät-Migration legitime Android-Geräte sind und einen gesperrten Bootloader haben.
- [C-1-4] MUSS nur App-Daten mit demselben Paketnamen UND Signaturzertifikat in dieselbe App auf dem Zielgerät migrieren.
- [C-1-5] MUSS im Einstellungsmenü einen Hinweis anzeigen, dass auf dem Quellgerät Daten durch eine Geräte-zu-Gerät-Datenmigration migriert wurden. Ein Nutzer sollte diese Angabe NICHT entfernen können.
9:17. Android Virtualisierungs-Framework
Wenn auf dem Gerät die Unterstützung der Android Virtualization Framework APIs (android.system.virtualmachine.*
) implementiert ist, gilt für den Android-Host Folgendes:
- [C-1-1] MUSS alle im Paket
android.system.virtualmachine
definierten APIs unterstützen. - [C-1-2] DARF NICHT das Android SELinux und das Berechtigungsmodell für die Verwaltung von geschützten virtuellen Maschinen (pVM) ändern.
- [C-1-3] DARF die Neverallow-Regeln, die im vorgelagerten Android Open Source Project (AOSP) im vorgelagerten Android Open Source Project (AOSP) vorhanden sind, NICHT geändert, weggelassen oder ersetzt werden. Die Richtlinie MÜSSEN mit allen vorhandenen „Neverallow“-Regeln kompiliert werden.
- [C-1-4] DÜRFEN nur von der Plattform signierten Code und privilegierte Anwendungen zulassen
DÜRFEN NICHT zulassen, dass nicht vertrauenswürdiger Code (z.B. Drittanbieter-Apps)einegeschützte virtuelle MaschinepVM erstellt und ausführt. Hinweis: Das kann sich in zukünftigen Android-Versionen ändern.
- [C-1-5] DARF einer
geschützten virtuellen MaschinepVM NICHT erlauben, Code auszuführen, der nicht Teil des Factory-Images oder ihrer Updates ist.Alles, was nicht vom Android Verified Boot abgedeckt wird, z.B. Dateien, die aus dem Internet heruntergeladen oder per Sideload übertragen werden, DÜRFEN NICHT auf einer geschützten virtuellen Maschine ausgeführt werden.
Neue Anforderungen erstellen
- [C-1-5] MUSS nur einer nicht Debug-fähigen pVM erlauben, Code vom Factory-Image oder von deren Plattformupdates auszuführen, was auch alle Aktualisierungen privilegierter Anwendungen umfasst.
Neue Anforderungen beenden
Wenn das Gerät Unterstützung für die Android Virtualization Framework APIs (android.system.virtualmachine.*
) implementiert, gilt für jede Protected Virtual Machine
pVM
-Instanz Folgendes:
- [C-2-1] MÜSSEN alle in der Virtualisierungs-APEX verfügbaren Betriebssysteme in einer
geschützten virtuellen MaschinepVM ausführen können. - [C-2-2] DARF NICHT zulassen, dass eine
geschützte virtuelle MaschinepVM ein Betriebssystem ausführt, das nicht vom Geräteimplementierer oder Betriebssystemanbieter signiert ist. - [C-2-3] DARF NICHT zulassen, dass eine
geschützte virtuelle MaschinepVM Daten als Code ausführt (z.B. SELinux niemals erlaubt Ausführung von Ausführungen).
- [C-2-4] DARF die „Neverallow“-Regeln im vorgelagerten Android Open Source Project (AOSP) im System/sepolicy/microdroid NICHT ändern, weglassen oder ersetzen.
- [C-2-5] MÜSSEN auch für andere Betriebssysteme, die keine Microdroid-Betriebssysteme verwenden,
Protected Virtual MachinepVM -Defense-in-Depth-Mechanismen implementieren (z.B. SELinux für pVMs). - [C-2-6] MÜSSEN sicherstellen, dass die pVM fehlschlägt
die Firmware nicht startet, wenndie anfänglichenImages, die die Ausführung der VM nicht verifizieren können, nicht verifiziert werden kann. Die Überprüfung MUSS innerhalb der VM durchgeführt werden. - [C-2-7] MÜSSEN sicherstellen, dass die pVM ausfällt .
Die Firmware verweigertden Start, wenn die Integrität von „instance.img“ kompromittiert wird.
Wenn das Gerät die Unterstützung für die Android Virtualization Framework APIs (android.system.virtualmachine.*
) implementiert, gilt für den Hypervisor Folgendes:
- [C-3-1] MÜSSEN sicherstellen, dass Speicherseiten, die ausschließlich einer VM (entweder pVM oder Host-VM) gehören, nur für die virtuelle Maschine oder den Hypervisor zugänglich sind und nicht über andere virtuelle Maschinen – ob geschützt oder nicht geschützt.
DÜRFEN KEINEN pVM Zugriff auf eine Seite gewähren, die zu einer anderen Entität wie einer anderen pVM oder einem Hypervisor gehört, es sei denn, der Seiteninhaber hat dies explizit freigegeben. Dies schließt die Host-VM ein. Dies gilt sowohl für CPU- als auch für DMA-Zugriffe. - [C-3-2] MÜSSEN eine Seite auf Werkseinstellungen zurücksetzen, nachdem sie von einer pVM verwendet wurde und bevor sie an den Host zurückgegeben wird (z.B. wenn die pVM gelöscht wird).
- [C-
3-3SR-1] Es wird dringend empfohlen,sicherzustellen, dass die pVM-Firmware vor Code in einer pVM geladen und ausgeführt wird. - [C-3-4] MÜSSEN sicherstellen, dass jede VM ein Secret pro VM ableitet, das
{der einer pVM-Instanz bereitgestellten Boot Certificate Chain (BCC) und Compound Device Identifier (CDIs)nur von dieser bestimmten VM-Instanz abgeleitet werden kann und sich beim Zurücksetzen auf die Werkseinstellungen und OTA ändert.
Wenn das Gerät die Unterstützung für die Android Virtualization Framework APIs implementiert, gilt für alle Bereiche:
- [C-4-1] DARF KEINE Funktionen für eine pVM bereitstellen, die das Umgehen des Android-Sicherheitsmodells ermöglicht.
Wenn auf dem Gerät die Unterstützung für die Android Virtualization Framework APIs implementiert ist, gilt Folgendes:
- [C-5-1] MUSS in der Lage sein, die isolierte Kompilierung zu unterstützen, kann aber die Funktion für die isolierte Kompilierung auf der Gerätelieferung
eines ART-Laufzeitupdatesdeaktivieren.
Wenn auf dem Gerät die Unterstützung für Android Virtualization Framework APIs implementiert ist, gilt für die Schlüsselverwaltung Folgendes:
- [C-6-1] MÜSSEN die DICE-Kette an einem Punkt starten, den der Nutzer selbst auf entsperrten Geräten nicht ändern kann. (Um sicherzustellen, dass es nicht gefälscht werden kann)
- [C-SR-2
6-2] Dringend empfohlen, DICE als Mechanismus zur Secret-Ableitung pro VM zu verwenden.MÜSSEN die DICES richtig ausführen, d.h. die richtigen Werte angeben.
10. Software-Kompatibilitätstests
Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen. Beachten Sie jedoch, dass kein Softwaretestpaket vollständig umfassend ist. Aus diesem Grund wird Geräten-Implementierern Dringend empfohlen, die im Android Open Source Project verfügbare Referenz und bevorzugte Implementierung von Android so gering wie möglich zu ändern. Dadurch wird das Risiko von Programmfehlern minimiert, die zu Inkompatibilitäten führen, die eine Nacharbeit und potenzielle Geräteupdates erfordern.
10.1. Kompatibilitätstest-Suite
Geräteimplementierungen:
[C-0-1] MÜSSEN die im Android Open Source Project verfügbare Android Compatibility Test Suite (CTS) mit der endgültigen Versandsoftware auf dem Gerät übergeben.
[C-0-2] MÜSSEN die Kompatibilität bei Mehrdeutigkeiten in CTS und bei Neuimplementierungen von Teilen des Referenzquellcodes gewährleisten.
Das CTS ist für die Ausführung auf einem echten Gerät konzipiert. Wie jede Software kann auch auch die CTS Fehler enthalten. Die CTS wird unabhängig von dieser Kompatibilitätsdefinition versioniert und für Android 14 können mehrere Versionen der CTS veröffentlicht werden.
Geräteimplementierungen:
[C-0-3] MÜSSEN die zum Zeitpunkt der Ausführung der Gerätesoftware verfügbare aktuelle CTS-Version übergeben.
SOLLTEN so weit wie möglich die Referenzimplementierung in der Android Open Source-Struktur verwenden.
10.2. CTS-Prüfung
Der CTS Verifier ist in der Kompatibilitätstest-Suite enthalten und sollte von einem menschlichen Bediener ausgeführt werden, um Funktionen zu testen, die von einem automatisierten System nicht getestet werden können, z. B. die korrekte Funktion einer Kamera und von Sensoren.
Geräteimplementierungen:
- [C-0-1] MÜSSEN alle anwendbaren Fälle in der CTS-Prüfung korrekt ausführen.
Der CTS Verifier bietet Tests für viele Arten von Hardware, einschließlich einiger optionaler Hardware.
Geräteimplementierungen:
- [C-0-2] MÜSSEN alle Tests für ihre Hardware bestehen. Wenn ein Gerät beispielsweise einen Beschleunigungsmesser hat, MÜSSEN diese den Testlauf des Beschleunigungsmessers im CTS Verifier ordnungsgemäß ausführen.
Testläufe für Funktionen, die in diesem Dokument zur Kompatibilitätsdefinition als optional gekennzeichnet sind, können übersprungen oder weggelassen werden.
- [C-0-2] Jedes Gerät und jeder Build MÜSSEN den CTS Verifier ordnungsgemäß ausführen, wie oben erwähnt. Da viele Builds sehr ähnlich sind, wird jedoch nicht erwartet, dass Geräte-Implementierer den CTS Verifier explizit auf Builds ausführen, die sich nur geringfügig unterscheiden. Insbesondere bei Geräteimplementierungen, die sich von einer Implementierung unterscheiden, bei der der CTS-Verifizierer nur durch die Gruppe der enthaltenen Sprachen, das Branding usw. übergeben wurde, KANN den CTS-Verifizierer-Test weggelassen werden.
11. Software zum Aktualisieren
[C-0-1] Geräteimplementierungen MÜSSEN einen Mechanismus enthalten, der die gesamte Systemsoftware ersetzt. Der Mechanismus muss keine „Live“-Upgrades ausführen, d. h. ein Geräteneustart KANN erforderlich sein. Es kann jede Methode verwendet werden, vorausgesetzt, sie kann die gesamte auf dem Gerät vorinstallierte Software ersetzen. Diese Anforderung wird beispielsweise von jedem der folgenden Ansätze erfüllt:
- Downloads von "Over-the-Air" (OTA) mit Offline-Aktualisierung durch Neustart
- Aktualisierungen per USB-Verbindung von einem Host-PC
- „Offline“-Updates werden nach einem Neustart durchgeführt und über eine Datei auf einem Wechseldatenträger aktualisiert.
[C-0-2] Der verwendete Aktualisierungsmechanismus MÜSSEN Updates unterstützen, ohne die Nutzerdaten zu löschen. Das heißt, der Aktualisierungsmechanismus MÜSSEN die privaten Daten der Anwendung und die freigegebenen Daten der Anwendung beibehalten. Beachten Sie, dass die vorgelagerte Android-Software einen Aktualisierungsmechanismus enthält, der diese Anforderung erfüllt.
[C-0-3] Das gesamte Update MUSS signiert sein und der Updatemechanismus auf dem Gerät MÜSSEN die Aktualisierung und Signatur anhand eines öffentlichen Schlüssels prüfen, der auf dem Gerät gespeichert ist.
[C-SR-1] Für den Signaturmechanismus wird dringend empfohlen, das Update mit SHA-256 zu hashen und mit ECDSA NIST P-256 gegen den öffentlichen Schlüssel zu validieren.
Wenn die Geräteimplementierung eine nicht getaktete Datenverbindung unterstützt, z. B. ein 802.11- oder Bluetooth PAN-Profil (Personal Area Network), gilt Folgendes:
- [C-1-1] MÜSSEN OTA-Downloads mit Offline-Updates per Neustart unterstützen.
Bei Geräteimplementierungen SOLLTEN Sie prüfen, ob das System-Image binär identisch mit dem erwarteten Ergebnis nach einem OTA-Problem ist. Die blockbasierte OTA-Implementierung im vorgelagerten Android-Open-Source-Projekt, die seit Android 5.1 hinzugefügt wurde, erfüllt diese Anforderung.
Außerdem sollten Geräteimplementierungen A/B-Systemupdates unterstützen. Der AOSP implementiert diese Funktion mithilfe des Boot-Steuerelement-HAL.
Wenn in einer Geräteimplementierung ein Fehler gefunden wird, nachdem diese veröffentlicht wurde, aber innerhalb der angemessenen Produktlebensdauer, die in Absprache mit dem Android-Kompatibilitätsteam ermittelt wurde, um die Kompatibilität von Drittanbieteranwendungen zu beeinflussen, dann:
- [C-2-1] Der Geräte-Implementierer MÜSSEN den Fehler über ein verfügbares Softwareupdate beheben, das mit dem soeben beschriebenen Mechanismus angewendet werden kann.
Android enthält Funktionen, mit denen die Geräteinhaber-App (falls vorhanden) die Installation von Systemupdates steuern kann. Wenn das Systemupdate-Subsystem für Geräte „android.software.device_admin“ meldet, geschieht Folgendes:
- [C-3-1] MÜSSEN das in der Klasse SystemUpdatePolicy beschriebene Verhalten implementieren.
12. Änderungsprotokoll für Dokumente
Für eine Zusammenfassung der Änderungen an der Kompatibilitätsdefinition in diesem Release:
13. Kontakt
Sie können dem Android-Kompatibilitätsforum beitreten und um Erläuterungen bitten oder Probleme melden, die im Dokument Ihrer Meinung nach nicht behandelt werden.