Android 15-Kompatibilitätsdefinition

1. Einführung

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

Die Verwendung von „MUST“ (MUSS), „MUST NOT“ (DARF NICHT), „REQUIRED“ (ERFORDERLICH), „SHALL“ (SHALL), „SHALL NOT“ (DARF NICHT), „SHOULD“ (SOLLTE), „SHOULD NOT“ (SOLLTE NICHT), „RECOMMENDED“ (EMPFOHLEN), „MAY“ (DARF) und „OPTIONAL“ (OPTIONAL) erfolgt gemäß dem IETF-Standard, der in RFC2119 definiert ist.

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

Damit Geräteimplementierungen als mit Android 15 kompatibel gelten, MÜSSEN sie die in dieser Definition der Kompatibilität aufgeführten Anforderungen erfüllen, einschließlich aller Dokumente, die durch Verweis einbezogen werden.

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

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

Viele der in diesem Dokument verlinkten Ressourcen stammen direkt oder indirekt aus dem Android SDK und sind funktional mit den Informationen in der Dokumentation dieses SDK identisch. Wenn diese Definition der Kompatibilität oder die Compatibility Test Suite nicht mit der SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als verbindlich. Alle technischen Details, die in den verlinkten Ressourcen in diesem Dokument enthalten sind, gelten als Teil dieser Kompatibilitätsdefinition.

1.1 Dokumentstruktur

1.1.1. Anforderungen nach Gerätetyp

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

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

1.1.2. Anforderungs-ID

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

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

Jede ID wird so definiert:

  • Gerätetyp-ID (weitere Informationen finden Sie unter 2. Gerätetypen)
    • C: Kern (Anforderungen, die auf alle Android-Geräteimplementierungen angewendet werden)
    • H: Android-Mobilgerät
    • T: Android TV-Gerät
    • A: Android Automotive-Implementierung
    • W: Implementierung für Android-Smartwatches
    • Tab: Implementierung für Android-Tablets
  • Bedingungs-ID
    • Wenn die Anforderung nicht bedingt ist, wird diese ID auf „0“ gesetzt.
    • Wenn die Anforderung bedingt ist, wird der ersten Bedingung 1 zugewiesen. Die Zahl wird innerhalb desselben Abschnitts und desselben Gerätetyps um 1 erhöht.
  • Anforderungs-ID
    • Diese ID beginnt bei 1 und wird innerhalb desselben Abschnitts und derselben Bedingung um 1 erhöht.

1.1.3. Anforderungs-ID in Abschnitt 2

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

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

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

2. Gerätetypen

Das Android Open Source Project bietet einen Software-Stack, der für eine Vielzahl von Gerätetypen und Formfaktoren verwendet werden kann. Zur Unterstützung der Sicherheit auf Geräten wird erwartet, dass der Softwarestack, einschließlich eines Ersatzbetriebssystems oder einer alternativen Kernelimplementierung, in einer sicheren Umgebung ausgeführt wird, wie in Abschnitt 9 und an anderer Stelle in dieser Gerätedatenbeschreibung beschrieben. Es gibt einige Gerätetypen, für die das System zur App-Bereitstellung relativ gut etabliert ist.

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

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

2.1 Gerätekonfigurationen

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

2.2. Anforderungen an Handhelds

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

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

  • Sie haben eine Stromquelle, die Mobilität bietet, z. B. einen Akku.
  • Die Bildschirmdiagonale muss zwischen 4 und 8 Zoll liegen.
  • eine Touchscreen-Eingabeoberfläche haben.

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

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

2.2.1. Hardware

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

  • [7.1.1.1/H-0-1] Es muss mindestens ein Android-kompatibles Display mit einer kurzen Kante von mindestens 5,6 cm und einer langen Kante von mindestens 8,6 cm vorhanden sein.
  • [7.1.1.3/H-SR-1] Es wird EMPFOHLEN, Nutzern die Möglichkeit zu geben, die Displaygröße (Bildschirmdichte) zu ändern.

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

  • [7.1.1.1/H-0-3]* Jedes UI_MODE_NORMAL-Display, das für Drittanbieter-Apps verfügbar gemacht wird, MUSS einem ungehinderten physischen Displaybereich zugeordnet werden, der an der kürzeren Seite mindestens 5,6 cm und an der längeren Seite mindestens 8,6 cm groß ist.

  • [7.1.1.3/H-0-1]* Der Wert von DENSITY_DEVICE_STABLE muss mindestens 92% der tatsächlichen physischen Dichte des entsprechenden Displays betragen.

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

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

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

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

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

Wenn Implementierungen von Handheld-Geräten die Unterstützung über eine Systemeigenschaft angebengraphics.gpu.profiler.support, gilt Folgendes:

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

  • [7.1.5/H-0-1] MUSS den Modus für die Abwärtskompatibilität von Anwendungen unterstützen, wie er im Upstream-Android-Open-Source-Code implementiert ist. Das heißt, Geräteimplementierungen dürfen NICHT die Auslöser oder Grenzwerte ändern, bei denen der Kompatibilitätsmodus aktiviert wird, und NICHT das Verhalten des Kompatibilitätsmodus selbst ändern.
  • [7.2.1/H-0-1] MUSS die Unterstützung von IME-Anwendungen (Eingabemethoden-Editor) von Drittanbietern umfassen.
  • [7.2.3/H-0-2] Es MUSS sowohl das Ereignis für das normale Drücken als auch das Ereignis für das lange Drücken der Zurück-Funktion (KEYCODE_BACK) an die App im Vordergrund gesendet werden. Diese Ereignisse DÜRFEN NICHT vom System verwendet werden und KÖNNEN außerhalb des Android-Geräts ausgelöst werden (z.B. über eine externe Hardwaretastatur, die mit dem Android-Gerät verbunden ist).
  • [7.2.3/H-0-3] Die Startbildschirmfunktion MUSS auf allen Android-kompatiblen Displays verfügbar sein.
  • [7.2.3/H-0-4] Die Funktion „Zurück“ muss auf allen Android-kompatiblen Displays und die Funktion „Letzte Apps“ auf mindestens einem der Android-kompatiblen Displays verfügbar sein.
  • [7.2.4/H-0-1] MUSS die Eingabe per Touchscreen unterstützen.
  • [7.2.4/H-SR-1] Es wird DRINGEND empfohlen, die vom Nutzer ausgewählte Assistenz-App zu starten, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die das ACTION_ASSIST-Symbol beim langen Drücken von KEYCODE_MEDIA_PLAY_PAUSE oder KEYCODE_HEADSETHOOK verarbeitet, wenn die Aktivität im Vordergrund diese Ereignisse nicht verarbeitet.
  • [7.3.1/H-SR-1] Es wird DRINGEND empfohlen, ein 3‑Achsen-Beschleunigungsmesser einzusetzen.

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

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

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

  • [7.3.3/H-2-1] GNSS-Messungen MÜSSEN gemeldet werden, sobald sie verfügbar sind, auch wenn ein aus GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
  • [7.3.3/H-2-2] MÜSSEN GNSS-Pseudostrecken und Pseudostreckenraten melden, die bei freiem Blick nach der Standortbestimmung, während sie stationär sind oder sich mit weniger als 0, 2 Metern pro Sekunde im Quadrat beschleunigen, mindestens 95% der Zeit ausreichen, um die Position innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0, 2 Metern pro Sekunde zu berechnen.

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

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

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

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

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

  • [7.3.11/H-SR-1] Es wird EMPFOHLEN, einen 6-Achsen-Pose-Sensor zu unterstützen.

Einführung neuer Anforderungen für Android 15

  • [7.4.3/H] Es MUSS Bluetooth und Bluetooth LE unterstützen.

Implementierungen von Handheld-Geräten mit Unterstützung für Bluetooth LE:

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

Ende der neuen Anforderungen

Wenn Geräte das NAN-Protokoll (Wi-Fi Neighbor Awareness Networking) unterstützen, indem sie PackageManager.FEATURE_WIFI_AWARE angeben, und den WLAN-Standort (Wi-Fi Round Trip Time – RTT), indem sie PackageManager.FEATURE_WIFI_RTT angeben, haben sie folgende Vorteile:

  • [7.4.2.5/H-1-1] MUSS den Bereich genau innerhalb von +/- 1 Meter bei 160 MHz Bandbreite im 68. Perzentil (wie mit der kumulativen Verteilungsfunktion berechnet), +/- 2 Meter bei 80 MHz Bandbreite im 68. Perzentil, +/- 4 Meter bei 40 MHz Bandbreite im 68. Perzentil und +/- 8 Meter bei 20 MHz Bandbreite im 68. Perzentil bei Entfernungen von 10 cm, 1 m, 3 m und 5 m melden, wie über die WifiRttManager#startRanging Android API erfasst.

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

Es wird dringend empfohlen, die Schritte zur Messeinrichtung unter Präsenzkalibrierung auszuführen.

Wenn bei Implementierungen von Handheld-Geräten FEATURE_BLUETOOTH_LE deklariert wird, gilt Folgendes:

  • [7.4.3/H-1-3] Der Rx-Offset muss gemessen und kompensiert werden, damit der mediane BLE-RSSI in 1 m Entfernung von einem Referenzgerät, das mit ADVERTISE_TX_POWER_HIGH sendet, -50 dBm ± 15 dB beträgt.
  • [7.4.3/H-1-4] Der Tx-Offset muss gemessen und kompensiert werden, damit der mediane BLE-RSSI -50 dBm ± 15 dB beträgt, wenn von einem Referenzgerät in 1 m Entfernung gescannt wird, das mit ADVERTISE_TX_POWER_HIGH sendet.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wenn für die Implementierung von Handheld-Geräten mindestens 2 GB und weniger als 4 GB Arbeitsspeicher für den Kernel und den Userspace verfügbar sind, gilt Folgendes:

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

Wenn für die Implementierung von Handheld-Geräten weniger als 2 GB Arbeitsspeicher für den Kernel und den Userspace verfügbar sind, gilt Folgendes:

  • [7.6.1/H-1-1] Es MUSS nur eine einzige ABI unterstützt werden (entweder nur 64-Bit oder nur 32-Bit).

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

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

Einführung neuer Anforderungen für Android 15

Wenn Implementierungen von Handheld-Geräten einen USB-Anschluss haben, der von einem Controller unterstützt wird, der im Peripheriemodus arbeitet, gilt Folgendes:

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

Ende der neuen Anforderungen

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

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

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

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

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

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

Wenn Implementierungen von Handheld-Geräten einen oder mehrere USB-C-Anschlüsse im Hostmodus haben und die USB Audio Class implementieren, müssen sie zusätzlich zu den Anforderungen in Abschnitt 7.7.2 Folgendes erfüllen:

  • [7.8.2.2/H-1-1] MUSS die folgende Softwarezuordnung von HID-Codes bereitstellen:
Funktion Zuordnungen Kontext Verhalten
A HID-Nutzungsseite: 0x0C
HID-Nutzung: 0x0CD
Kernel-Schlüssel: KEY_PLAYPAUSE
Android-Schlüssel: KEYCODE_MEDIA_PLAY_PAUSE
Medienwiedergabe Eingabe: Kurzes Drücken
Ausgabe: Wiedergabe oder Pause
Eingabe: Lang drücken
Ausgabe: Sprachbefehl starten
Sendet: android.speech.action.VOICE_SEARCH_HANDS_FREE, wenn das Gerät gesperrt ist oder das Display ausgeschaltet ist. Andernfalls wird android.speech.RecognizerIntent.ACTION_WEB_SEARCH gesendet.
Eingehender Anruf Eingabe: Kurzes Drücken
Ausgabe: Anruf annehmen
Eingabe: Lang drücken
Ausgabe: Anruf ablehnen
Aktiver Anruf Eingabe: Kurzes Drücken
Ausgabe: Anruf beenden
Eingabe: Lang drücken
Ausgabe: Mikrofon stummschalten oder Stummschaltung aufheben
B HID-Nutzungsseite: 0x0C
HID-Nutzung: 0x0E9
Kernel-Schlüssel: KEY_VOLUMEUP
Android-Schlüssel: VOLUME_UP
Medienwiedergabe, aktiver Anruf Eingabe: Kurz oder lang drücken
Ausgabe: Erhöht die System- oder Headsetlautstärke
C HID-Nutzungsseite: 0x0C
HID-Nutzung: 0x0EA
Kernelschlüssel: KEY_VOLUMEDOWN
Android-Schlüssel: VOLUME_DOWN
Medienwiedergabe, aktiver Anruf Eingabe: Kurz oder lang drücken
Ausgabe: Verringert die System- oder Headsetlautstärke
D HID-Nutzungsseite: 0x0C
HID-Nutzung: 0x0CF
Kernelschlüssel: KEY_VOICECOMMAND
Android-Schlüssel: KEYCODE_VOICE_ASSIST
Alle. Kann in jeder Instanz ausgelöst werden. Eingabe: Kurzes oder langes Drücken
Ausgabe: Sprachbefehl starten
  • [7.8.2.2/H-1-2] MUSS ACTION_HEADSET_PLUG beim Einstecken eines Steckers auslösen, aber erst, nachdem die USB-Audioschnittstellen und ‑endpunkte korrekt nummeriert wurden, um den Anschlusstyp zu identifizieren.

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

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

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

  • [7.8.2.2/H-3-1] MUSS Intent ACTION_HEADSET_PLUG mit dem zusätzlichen Parameter „microphone“ auf „1“ senden.

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

  • [7.8.2.2/H-4-1] Es MUSS ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_HEADSET und der Rolle isSink() aufgeführt sein, wenn das Feld „USB audio terminal type“ den Wert 0x0302 hat.

  • [7.8.2.2/H-4-2] Es MUSS ein Gerät vom Typ „AudioDeviceInfo.TYPE_USB_HEADSET“ und der Rolle „isSink()“ aufgeführt werden, wenn das Feld „USB audio terminal type“ den Wert „0x0402“ hat.

  • [7.8.2.2/H-4-3] Es MUSS ein Gerät vom Typ „AudioDeviceInfo.TYPE_USB_HEADSET“ und der Rolle „isSource()“ aufgeführt sein, wenn das Feld „USB audio terminal type“ den Wert „0x0402“ hat.

  • [7.8.2.2/H-4-4] Es MUSS ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE und mit der Rolle isSink() aufgeführt werden, wenn das Feld „USB audio terminal type“ den Wert 0x603 hat.

  • [7.8.2.2/H-4-5] Es MUSS ein Gerät vom Typ „AudioDeviceInfo.TYPE_USB_DEVICE“ und mit der Rolle „isSource()“ aufgeführt werden, wenn das Feld „USB audio terminal type“ den Wert „0x604“ hat.

  • [7.8.2.2/H-4-6] Es MUSS ein Gerät vom Typ „AudioDeviceInfo.TYPE_USB_DEVICE“ und mit der Rolle „isSink()“ aufgeführt sein, wenn das Feld „USB audio terminal type“ den Wert „0x400“ hat.

  • [7.8.2.2/H-4-7] MUSS ein Gerät vom Typ „AudioDeviceInfo.TYPE_USB_DEVICE“ und die Rolle „isSource()“ angeben, wenn das Feld „USB audio terminal type“ den Wert „0x400“ hat.

  • [7.8.2.2/H-SR-1] Es wird DRINGEND empfohlen, nach dem Anschluss eines USB-C-Audio-Peripheriegeräts die USB-Beschreibungen aufzuzählen, die Anschlusstypen zu identifizieren und die Absicht ACTION_HEADSET_PLUG in weniger als 1.000 Millisekunden zu senden.

Einführung neuer Anforderungen für Android 15

Wenn für Implementierungen auf Mobilgeräten, die android.hardware.audio.output und android.hardware.microphone angeben, gilt Folgendes: Siehe die RTL- und TTL-Anforderungen unter 5.6.

  • [5.6/H-1-1] Die durchschnittliche kontinuierliche Round-Trip-Latenz muss bei fünf Messungen 300 Millisekunden oder weniger betragen und die durchschnittliche absolute Abweichung muss unter 30 Millisekunden liegen.Dies gilt für die folgenden Datenpfade: „Lautsprecher zu Mikrofon“, 3,5-mm-Loopback-Adapter (falls unterstützt) und USB-Loopback (falls unterstützt).

  • [5.6/H-1-2] Die durchschnittliche Latenz bei der Funktion „Zum Anrufen tippen“ muss bei mindestens fünf Messungen über den Datenpfad zwischen Lautsprecher und Mikrofon 300 Millisekunden oder weniger betragen.

Ende der neuen Anforderungen

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

Wenn Implementierungen von Handheld-Geräten mindestens einen linearen ResonanzAktor vom Typ 7.10 für allgemeine Zwecke enthalten, gilt Folgendes:

  • [7.10/H] Der Aktuator sollte sich in der Nähe des Bereichs befinden, an dem das Gerät normalerweise gehalten oder berührt wird.

  • [7.10/H] Der haptische Aktor sollte sich in der X-Achse (links-rechts) der natürlichen Ausrichtung des Geräts bewegen.

Wenn die Implementierungen von Handheld-Geräten einen allgemeinen haptischen Aktor haben, der ein linearer ResonanzAktor (LRA) in X-Achse ist, haben sie folgende Vorteile:

  • [7.10/H] Die Resonanzfrequenz der X‑Achsen-LRA sollte unter 200 Hz liegen.

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

2.2.2. Multimedia

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

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

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

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

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

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

2.2.3. Software

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

  • [3.2.3.1/H-0-1] Es MUSS eine Anwendung geben, die die ACTION_GET_CONTENT-, ACTION_OPEN_DOCUMENT-, ACTION_OPEN_DOCUMENT_TREE- und ACTION_CREATE_DOCUMENT-Intents wie in den SDK-Dokumenten beschrieben verarbeitet und den Nutzern die Möglichkeit bietet, über die DocumentsProvider API auf die Daten des Dokumentanbieters zuzugreifen.
  • [3.2.3.1/H-0-2]* Es müssen mindestens eine Anwendung oder Dienstkomponente mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorgeladen werden, die durch die hier aufgeführten Anwendungs-Intents definiert sind.
  • [3.2.3.1/H-SR-1] Es wird DRINGEND empfohlen, eine E-Mail-Anwendung vorab zu laden, die die Intents ACTION_SENDTO, ACTION_SEND oder ACTION_SEND_MULTIPLE zum Senden einer E-Mail verarbeiten kann.
  • [3.4.1/H-0-1] Es MUSS eine vollständige Implementierung der android.webkit.Webview API bereitgestellt werden.
  • [3.4.2/H-0-1] MUSS eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten.
  • [3.8.1/H-SR-1] Es wird DRINGEND empfohlen, einen Standard-Launcher zu implementieren, der das Anpinnen von Verknüpfungen, Widgets und widgetFeatures in Apps unterstützt.
  • [3.8.1/H-SR-2] Es wird DRINGEND empfohlen, einen Standard-Launcher zu implementieren, der über die ShortcutManager API schnellen Zugriff auf die zusätzlichen Verknüpfungen von Drittanbieter-Apps bietet.
  • [3.8.1/H-SR-3] Es wird EMPFOHLEN, eine Standard-Launcher-App einzubinden, die Logos für die App-Symbole anzeigt.
  • [3.8.2/H-SR-1] Es wird DRINGEND empfohlen, Widgets von Drittanbieter-Apps zu unterstützen.
  • [3.8.3/H-0-1] Drittanbieter-Apps MÜSSEN Nutzer über wichtige Ereignisse über die API-Klassen Notification und NotificationManager informieren können.
  • [3.8.3/H-0-2] MUSS Rich-Benachrichtigungen unterstützen.
  • [3.8.3/H-0-3] MÜSSEN Push-Benachrichtigungen unterstützen.
  • [3.8.3/H-0-4] Es MUSS einen Benachrichtigungs-Schirm geben, über den Nutzer die Benachrichtigungen direkt steuern können (z. B. antworten, pausieren, schließen, blockieren) – z. B. über Aktionsschaltflächen oder das Steuerfeld, wie im AOSP implementiert.
  • [3.8.3/H-0-5] Die über RemoteInput.Builder setChoices() verfügbaren Optionen MÜSSEN in der Benachrichtigungsleiste angezeigt werden.
  • [3.8.3/H-SR-1] Es wird DRINGEND empfohlen, die erste Option, die über RemoteInput.Builder setChoices() bereitgestellt wird, im Benachrichtigungs-Schieberegler ohne zusätzliche Nutzerinteraktion anzuzeigen.
  • [3.8.3/H-SR-2] Es wird EMPFINDLICH EMPFOHLEN, alle Optionen, die über RemoteInput.Builder setChoices() in der Benachrichtigungsleiste verfügbar sind, anzuzeigen, wenn der Nutzer alle Benachrichtigungen in der Benachrichtigungsleiste maximiert.
  • [3.8.3.1/H-SR-1] Es wird EMPFOHLEN, Aktionen anzuzeigen, für die Notification.Action.Builder.setContextual als true festgelegt ist, und zwar in der gleichen Zeile wie die Antworten, die von Notification.Remoteinput.Builder.setChoices angezeigt werden.
  • [3.8.4/H-SR-1] Es wird EMPFOHLEN, auf dem Gerät einen Assistenten zu implementieren, der die Hilfeaktion verarbeitet.

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

  • [3.8.3.1/H-SR-2] Es wird DRINGEND empfohlen, eine Nutzerfunktion (z. B. einen Ausgabeschalter) bereitzustellen, auf die über die System-UI zugegriffen werden kann und mit der Nutzer zwischen geeigneten verfügbaren Medienrouten wechseln können (z. B. Bluetooth-Geräte und Routen, die für MediaRouter2Manager bereitgestellt werden), wenn eine App eine MediaStyle-Benachrichtigung mit einem MediaSession-Token sendet.

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

  • [3.8.3/H-1-1] Die App MUSS die Funktion zum Anpinnen von Bildschirmen implementieren und den Nutzern ein Einstellungsmenü zum Aktivieren und Deaktivieren der Funktion zur Verfügung stellen.

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

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

Wenn die Implementierung von Mobilgeräten conversation notifications unterstützt und sie in einem separaten Bereich von Benachrichtigungen mit Ton und stummen Benachrichtigungen ohne Unterhaltung gruppiert, gilt Folgendes:

  • [3.8.4/H-1-1]* Unterhaltungsbenachrichtigungen MÜSSEN vor nicht zu Unterhaltungen gehörenden Benachrichtigungen angezeigt werden, mit Ausnahme von Benachrichtigungen zu laufenden Diensten im Vordergrund und Benachrichtigungen mit der Benachrichtigungspriorität „hoch“.

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

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

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

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

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

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

  • [3.8.16/H-1-5] Es MUSS eine Nutzerfunktion geben, mit der sich die von der App für die Authentifizierung vorgesehenen gerätebezogenen Steuerelemente von den Steuerelementen deaktivieren lassen, die von den Drittanbieter-Apps über die ControlsProviderService und die Control Control.isAuthRequired API registriert wurden.

  • [3.8.16/H-1-6] Geräteimplementierungen müssen die Nutzeraffordance wie unten beschrieben korrekt darstellen:

    • Wenn auf dem Gerät config_supportsMultiWindow=true festgelegt ist und die App die Metadaten META_DATA_PANEL_ACTIVITY in der ControlsProviderService-Deklaration angibt, einschließlich des ComponentName einer gültigen Aktivität (wie von der API definiert), MUSS die App diese Aktivität in diese Nutzerleihe einbetten.
    • Wenn die App keine Metadaten META_DATA_PANEL_ACTIVITY deklariert, MÜSSEN die angegebenen Felder so gerendert werden, wie sie von der ControlsProviderService API und allen angegebenen Feldern der Control APIs bereitgestellt werden.
  • [3.8.16/H-1-7] Wenn die App die Metadaten META_DATA_PANEL_ACTIVITY deklariert, MUSS sie beim Starten der eingebetteten Aktivität den Wert der in [3.8.16/H-1-5] definierten Einstellung mit EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS übergeben.

Wenn solche Steuerelemente bei der Implementierung von Handheld-Geräten nicht implementiert werden, gilt Folgendes:

Wenn Implementierungen für Mobilgeräte nicht im Modus „Task sperren“ ausgeführt werden, geschieht Folgendes, wenn Inhalte in die Zwischenablage kopiert werden:

  • [3.8.17/H-1-1] Dem Nutzer muss bestätigt werden, dass Daten in die Zwischenablage kopiert wurden (z. B. durch ein Thumbnail oder eine Benachrichtigung „Inhalt kopiert“). Geben Sie hier außerdem an, ob Zwischenablagedaten zwischen Geräten synchronisiert werden.

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

  • [3.10/H-0-1] MÜSSEN Dienste zur Barrierefreiheit von Drittanbietern unterstützen.
  • [3.10/H-SR-1] Es wird DRINGEND empfohlen, Bedienungshilfen auf dem Gerät vorinstalliert zu haben, die mit den Funktionen von Switch Access und TalkBack (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden) vergleichbar sind oder diese übertreffen, wie im Open-Source-Projekt TalkBack bereitgestellt.
  • [3.11/H-0-1] MUSS die Installation von TTS-Engines von Drittanbietern unterstützen.
  • [3.11/H-SR-1] Es wird DRINGEND empfohlen, eine TTS-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
  • [3.13/H-SR-1] Es wird DRINGEND empfohlen, eine UI-Komponente für die Schnelleinstellungen hinzuzufügen.

Wenn für die Implementierung von Android-Handheld-Geräten die Unterstützung von FEATURE_BLUETOOTH oder FEATURE_WIFI deklariert wird, gilt Folgendes:

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

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

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

Wenn bei Implementierungen von Handheld-Geräten eine Navigationsfunktion als Geste von überall am linken und rechten Displayrand verfügbar ist:

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

Wenn Implementierungen von Handheld-Geräten einen sicheren Sperrbildschirm unterstützen und mindestens 2 GB Arbeitsspeicher für den Kernel und den Userspace verfügbar haben, gilt Folgendes:

  • [3.9/H-1-2] Die Unterstützung verwalteter Profile muss über das Feature-Flag android.software.managed_users deklariert werden.

Wenn die Implementierung von Android-Handheld-Geräten die Unterstützung der Kamera über android.hardware.camera.any deklariert, gilt Folgendes:

Wenn die Einstellungen-App der Geräteimplementierung eine getrennte Funktion mithilfe der Aktivitäts-Embedding-Funktion implementiert, gilt Folgendes:

Wenn Nutzer über Geräteimplementierungen Anrufe jeglicher Art starten können,

2.2.4. Leistung und Akkulaufzeit

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

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

  • [8.2/H-0-1] Die sequenzielle Schreibleistung muss mindestens 5 MB/s betragen.
  • [8.2/H-0-2] Die Zufallsschreibleistung muss mindestens 0,5 MB/s betragen.
  • [8.2/H-0-3] Die sequenzielle Leseleistung muss mindestens 15 MB/s betragen.
  • [8.2/H-0-4] Die Leistung bei zufälligen Lesevorgängen MUSS mindestens 3,5 MB/s betragen.

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

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

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

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

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

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

  • [8.5/H-0-1] Es MUSS eine Nutzerfunktion geben, mit der alle Apps mit aktiven Diensten im Vordergrund oder von Nutzern initiierten Jobs angezeigt werden, einschließlich der Dauer jedes dieser Dienste seit Beginn, wie im SDK-Dokument beschrieben.

  • [8.5/H-0-2]Es MUSS eine Nutzerfunktion geben, mit der eine App angehalten werden kann, in der ein Dienst im Vordergrund oder ein vom Nutzer initiierter Job ausgeführt wird.

2.2.5. Sicherheitsmodell

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

  • [9/H-0-1] Die Funktion android.hardware.security.model.compatible MUSS deklariert werden.
  • [9.1/H-0-1] Drittanbieter-Apps MÜSSEN über die Berechtigung android.permission.PACKAGE_USAGE_STATS auf die Nutzungsstatistiken zugreifen dürfen und einen nutzerzugänglichen Mechanismus bereitstellen, um den Zugriff auf solche Apps als Reaktion auf die Absicht android.settings.ACTION_USAGE_ACCESS_SETTINGS zu gewähren oder zu widerrufen.

Einführung neuer Anforderungen für Android 15

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

  • [9/H-0-2] MUSS die android.settings.CREDENTIAL_PROVIDER-Intention einhalten, die Auswahl eines bevorzugten Anbieters für den Anmeldedaten-Manager zu ermöglichen. Dieser Anbieter wird für Autofill aktiviert und ist auch der Standardspeicherort für neue Anmeldedaten, die über den Anmeldedaten-Manager eingegeben werden.

  • [9/H-0-3] Es müssen mindestens zwei gleichzeitige Anmeldedatenanbieter unterstützt werden und es muss in den Einstellungen eine Option für Nutzer geben, Anbieter zu aktivieren oder zu deaktivieren.

Ende der neuen Anforderungen

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

  • [9.5/H-1-1] UserManager.isHeadlessSystemUserMode darf NICHT auf true gesetzt werden.

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

  • [9.11/H-0-2] Die Implementierung des Schlüsselspeichers MUSS mit einer isolierten Ausführungsumgebung gesichert werden.
  • [9.11/H-0-3] Es MÜSSEN Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie Hash-Funktionen der MD5-, SHA-1- und SHA-2-Familie vorhanden sein, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich zu unterstützen, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird. Bei der sicheren Isolation MÜSSEN alle potenziellen Mechanismen blockiert werden, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternativ sind auch eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation möglich.
  • [9.11/H-0-4] Die Authentifizierung über den Sperrbildschirm MUSS in der isolierten Ausführungsumgebung erfolgen und nur bei Erfolg dürfen die authentifizierten Schlüssel verwendet werden. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Sperrbildschirmauthentifizierung durchführen kann. Das Upstream-Android-Open-Source-Projekt bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.

Einführung neuer Anforderungen für Android 15

  • [9.11/H-0-5] MUSS die Schlüsselattestierung unterstützen, bei der der Attestierungssignaturschlüssel durch sichere Hardware geschützt und die Signatur auf sicherer Hardware ausgeführt wird. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten freigegeben werden, um zu verhindern, dass die Schlüssel verwendet werden, um Geräte dauerhaft zu identifizieren. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, es sei denn, es werden mindestens 100.000 Einheiten einer bestimmten SKU produziert. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, kann für jede 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Ende der neuen Anforderungen

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

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

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

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Vertrauensagenten enthalten, die die TrustAgentService System API implementieren, gilt Folgendes:

  • [9.11.1/H-1-1] Der Nutzer muss häufiger als alle 72 Stunden mit einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) herausgefordert werden.

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

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

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

  • [9.5/H-3-1] Es dürfen KEINE eingeschränkten Profile unterstützt werden. Die Steuerelemente zur Aktivierung oder Deaktivierung des Zugriffs anderer Nutzer auf Sprachanrufe und SMS MÜSSEN der AOSP-Implementierung entsprechen.

Wenn bei Implementierungen für Mobilgeräte UserManager.isHeadlessSystemUserMode auf true festgelegt ist,

  • [9.5/H-4-1] Darf KEINE Unterstützung für eUICCs und KEINE Unterstützung für eSIMs mit Anruffunktion enthalten.
  • [9.5/H-4-2] DARF KEINE Unterstützung für android.hardware.telephony angeben.

Android unterstützt über die System-API „VoiceInteractionService“ einen Mechanismus für die sichere, ständige Hotword-Erkennung ohne Mikrofonzugriffsanzeige und die ständige Erkennung von Suchanfragen ohne Mikrofon- oder Kamerazugriffsanzeige.

Einführung neuer Anforderungen für Android 15

Eingeschränkte Einstellungen

Unter „Eingeschränkte Einstellungen“ werden Nutzern sichtbare Warnungen angezeigt und sie werden aufgefordert, Berechtigungen für jede Anwendung zu erteilen, die

  • Sie werden installiert, nachdem sie über eine andere Anwendung (z. B. eine Messaging-Anwendung oder einen Browser) als eine „App-Shop-Anwendung“ heruntergeladen wurden, die von PackageManager als PACKAGE_DOWNLOADED_FILE identifiziert wurde.
  • Die Anwendung wurde aus einer lokalen Datei installiert (z. B. per Sideload), die von PackageManager als PACKAGE_SOURCE_LOCAL_FILE identifiziert wurde.

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

Solche Anwendungen sind für die in diesem Abschnitt aufgeführten Anforderungen mit dem Label „Abgedeckte Anwendungen“ gekennzeichnet.

Geräteimplementierungen:

  • [9.8/H-0-1] Es MÜSSEN die oben beschriebenen eingeschränkten Einstellungen für Folgendes implementiert werden:

    • Besondere Berechtigungen
      • Barrierefreiheit (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
      • Benachrichtigungs-Listener (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
      • Geräteverwaltungs-Apps (Manifest.permission.BIND_DEVICE_ADMIN)
      • Über anderen Apps einblenden (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
      • Zugriff auf die Nutzung (AppOpsManager.OPSTR_GET_USAGE_STATS)
    • Rollen (Standard-Apps)
      • Telefon (RoleManager.ROLE_DIALER)
      • SMS (RoleManager.ROLE_SMS)
    • Laufzeitberechtigungen
      • SMS-Laufzeit (Manifest.permission_group.SMS)
  • [9.8/H-0-2] Die eingeschränkten Einstellungen MÜSSEN standardmäßig aktiviert sein. Es wird DRINGEND empfohlen, keine Nutzeroptionen zu haben, mit denen Nutzer die eingeschränkten Einstellungen für alle Apps deaktivieren können.

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

  • [9.8/H-0-4] Es MUSS nur eine Nutzerbestätigung zulassen, um eingeschränkte Einstellungen über die EnhancedConfirmationManager API von der Seite „App-Info“ der abgedeckten App abzurufen.

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

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

Ende der neuen Anforderungen

Wenn Implementierungen von Handheld-Geräten die System APIHotwordDetectionService oder einen anderen Mechanismus zur Hotword-Erkennung ohne Angabe des Mikrofonzugriffs unterstützen, gilt Folgendes:

  • [9.8/H-1-1] Der Dienst zur Hotword-Erkennung darf Daten nur an das System, ContentCaptureService oder den On-Device-Spracherkennungsdienst von SpeechRecognizer#createOnDeviceSpeechRecognizer() senden.
  • [9.8/H-1-2] Der Dienst zur Hotword-Erkennung darf Mikrofonaudiodaten oder daraus abgeleitete Daten nur über die HotwordDetectionService API an den Systemserver oder über die ContentCaptureManager API an ContentCaptureService senden.
  • [9.8/H-1-3] Für eine einzelne hardwaregetriggerte Anfrage an den Dienst zur Hotword-Erkennung darf KEIN Mikrofonaudio länger als 30 Sekunden gesendet werden.
  • [9.8/H-1-4] Es darf KEIN gepuffertes Mikrofonaudio älter als 8 Sekunden für eine einzelne Anfrage an den Hotword-Erkennungsdienst bereitgestellt werden.
  • [9.8/H-1-5] Der Dienst für die Sprachinteraktion oder eine ähnliche Entität DARF KEIN gepuffertes Mikrofonaudio bereitstellen, das älter als 30 Sekunden ist.
  • [9.8/H-1-6] Es dürfen bei jedem erfolgreichen Hotword-Ergebnis nicht mehr als 100 Byte an Daten (ohne Audiostreams) vom Hotword-Erkennungsdienst übertragen werden.
  • [9.8/H-1-7] Es dürfen nicht mehr als 5 Bit Daten von jedem negativen Hotword-Ergebnis aus dem Hotword-Erkennungsdienst übertragen werden.
  • [9.8/H-1-8] Die Übertragung von Daten aus dem Dienst zur Hotword-Erkennung darf nur bei einer Hotword-Bestätigungsanfrage vom Systemserver erfolgen.
  • [9.8/H-1-9] Es DARF KEINE Anwendung geben, die vom Nutzer installiert werden kann und den Dienst zur Erkennung von Hotwords bereitstellt.
  • [9.8/H-1-10] Quantitative Daten zur Mikrofonnutzung durch den Dienst zur Hotword-Erkennung dürfen NICHT auf der Benutzeroberfläche angezeigt werden.
  • [9.8/H-1-11] Die Anzahl der Bytes, die in jeder Übertragung vom Dienst zur Hotword-Erkennung enthalten sind, MUSS protokolliert werden, damit Sicherheitsforscher die Daten prüfen können.
  • [9.8/H-1-12] MUSS einen Debug-Modus unterstützen, der den Rohinhalt jeder Übertragung vom Dienst zur Hotword-Erkennung protokolliert, um Sicherheitsforschern die Prüfung zu ermöglichen.
  • [9.8/H-1-14] Die Mikrofonanzeige muss wie in Abschnitt 9.8.2 beschrieben angezeigt werden, wenn ein erfolgreiches Hotword-Ergebnis an den Dienst für die Sprachinteraktion oder eine ähnliche Entität gesendet wird.

  • [9.8/H-1-15] MUSS dafür sorgen, dass Audiostreams, die bei erfolgreichen Hotword-Ergebnissen bereitgestellt werden, nur in eine Richtung vom Hotword-Erkennungsdienst an den Sprachinteraktionsdienst übertragen werden.

  • [9.8/H-SR-1] Es wird DRINGEND empfohlen, Nutzer zu informieren, bevor eine Anwendung als Anbieter des Dienstes zur Hotword-Erkennung festgelegt wird.

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

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

Wenn Geräteimplementierungen eine Anwendung enthalten, die die System APIHotwordDetectionService oder einen ähnlichen Mechanismus zur Hotword-Erkennung ohne Angabe der Mikrofonnutzung verwendet, gilt für die Anwendung Folgendes:

  • [9.8/H-2-1] Der Nutzer muss für jedes unterstützte Hotword ausdrücklich informiert werden.
  • [9.8/H-2-2] Rohe Audiodaten oder daraus abgeleitete Daten dürfen NICHT über den Dienst zur Hotword-Erkennung gespeichert werden.
  • [9.8/H-2-3] Es DÜRFEN KEINE Audiodaten, Daten, die zur (vollständigen oder teilweisen) Rekonstruktion des Audios verwendet werden können, oder Audioinhalte, die nicht mit dem Hotword selbst in Verbindung stehen, vom Dienst zur Hotword-Erkennung übertragen werden, es sei denn, sie werden an den Dienst ContentCaptureService oder den Dienst zur Spracherkennung auf dem Gerät gesendet.

Wenn Implementierungen von Handheld-Geräten die System APIVisualQueryDetectionService oder einen anderen Mechanismus zur Erkennung von Suchanfragen ohne Angabe des Mikrofon- und/oder Kamerazugriffs unterstützen, gilt Folgendes:

  • [9.8/H-3-1] Der Dienst zur Erkennung von Suchanfragen darf Daten nur an das System, ContentCaptureService oder den On-Device-Spracherkennungsdienst (von SpeechRecognizer#createOnDeviceSpeechRecognizer() erstellt) senden.
  • [9.8/H-3-2] Es dürfen KEINE Audio- oder Videoinformationen aus dem VisualQueryDetectionService übertragen werden, ausgenommen an ContentCaptureService oder an den Spracherkennungsdienst auf dem Gerät.
  • [9.8/H-3-3] Es muss eine Nutzerbenachrichtigung in der System-UI angezeigt werden, wenn das Gerät erkennt, dass der Nutzer mit der digitalen Assistentenanwendung interagieren möchte (z. B. durch Erkennen der Nutzerpräsenz über die Kamera).
  • [9.8/H-3-4] Es MUSS eine Mikrofonanzeige und die erkannte Nutzeranfrage direkt nach der Erkennung auf der Benutzeroberfläche angezeigt werden.
  • [9.8/H-3-5] Es DARF KEINE vom Nutzer installierbare Anwendung geben, die den Dienst zur Erkennung visueller Suchanfragen bereitstellt.

Wenn bei Implementierungen von Handheld-Geräten android.hardware.microphone deklariert wird, gilt Folgendes:

  • [9.8.2/H-4-1] Die Mikrofonanzeige MUSS angezeigt werden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 genannten Rollen mit CDD-ID [C-4-X] auf das Mikrofon zugreifen.
  • [9.8.2/H-4-2] MUSS die Liste der zuletzt verwendeten und aktiven Apps anzeigen, die das Mikrofon verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen.
  • [9.8.2/H-4-3] Die Mikrofonanzeige darf bei System-Apps, die eine sichtbare Benutzeroberfläche oder eine direkte Nutzerinteraktion haben, NICHT ausgeblendet werden.
  • [9.8.2/H-4-4] Es MUSS die Liste der zuletzt verwendeten und aktiven Apps angezeigt werden, die das Mikrofon verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen.

Wenn bei Implementierungen von Handheld-Geräten android.hardware.camera.any deklariert wird, gilt Folgendes:

  • [9.8.2/H-5-1] Die Kameraanzeige MUSS angezeigt werden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn nur Apps mit den in Abschnitt 9.1 genannten Rollen mit der CDD-ID [C-4-X] auf die Kamera zugreifen.
  • [9.8.2/H-5-2] Zuletzt verwendete und aktive Apps, die die Kamera verwenden, MÜSSEN zusammen mit allen zugehörigen Attributionsmeldungen angezeigt werden, die von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben wurden.
  • [9.8.2/H-5-3] Die Kameraanzeige darf bei System-Apps, die eine sichtbare Benutzeroberfläche oder eine direkte Nutzerinteraktion haben, NICHT ausgeblendet werden.

Einführung neuer Anforderungen für Android 15

Der verifizierte Bootmodus ist eine Funktion, die die Integrität der Gerätesoftware sicherstellt. Wenn die Funktion von Geräteimplementierungen unterstützt wird, gilt Folgendes:

  • [9.10/H-1-1] Alle während der Android-Startsequenz bereitgestellten Nur-Lese-Partitionen MÜSSEN überprüft werden und der VBMeta-Digest muss alle diese überprüften Partitionen in die Berechnung einbeziehen.

Ende der neuen Anforderungen

2.2.6. Kompatibilität von Entwicklertools und ‑optionen

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

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

Einführung neuer Anforderungen für Android 15

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

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

Ende der neuen Anforderungen

2.2.7. Leistungsklasse für Mobilgeräte

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

2.2.7.1. Medien

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

Einführung neuer Anforderungen für Android 15

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

Ende der neuen Anforderungen

  • [5.1/H-1-1] MÜSSEN die maximale Anzahl von Hardware-Videodecodersitzungen angeben, die in einer beliebigen Kombination von Codecs gleichzeitig ausgeführt werden können, und zwar über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints().

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-2] MÜSSEN 6 Instanzen von 8‑Bit-Hardware-Videodecodersitzungen (SDR) (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen bei 1080p-Auflösung bei 30 fps und 3 Sitzungen bei 4K-Auflösung bei 30 fps ausgeführt werden. Bei allen Sitzungen darf maximal ein Frame pro Sekunde verloren gehen. AV1-Codecs müssen nur eine Auflösung von 1080p unterstützen, aber dennoch sechs Instanzen bei 1080p30fps.

Ende der neuen Anforderungen

  • [5.1/H-1-3] MÜSSEN die maximale Anzahl von Hardware-Videoencoder-Sitzungen angeben, die gleichzeitig in beliebiger Codec-Kombination über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() ausgeführt werden können.

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-4] MUSS 6 Instanzen von 8‑Bit-Hardware-Videoencoder-Sitzungen (SDR) (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination unterstützen, die gleichzeitig mit 4 Sitzungen bei 1080p-Auflösung bei 30 fps und 2 Sitzungen bei 4K-Auflösung bei 30 fps ausgeführt werden. Bei allen Sitzungen darf maximal ein Frame pro Sekunde verloren gehen. AV1-Codecs müssen nur eine Auflösung von 1080p unterstützen, aber dennoch sechs Instanzen bei 1080p30fps.

Ende der neuen Anforderungen

  • [5.1/H-1-5] MÜSSEN die maximale Anzahl von Hardware-Video-Encoder- und ‑Decoder-Sitzungen angeben, die in beliebiger Codec-Kombination gleichzeitig ausgeführt werden können, und zwar über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints().

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-6] MUSS 6 Instanzen von 8‑Bit-Hardware-Videodecodern (SDR) und Hardware-Videoencoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen mit einer Auflösung von 4K@30 fps ausgeführt werden, von denen höchstens 2 Encoder-Sitzungen und 3 Sitzungen mit einer Auflösung von 1080p sind. Bei allen Sitzungen darf maximal ein Frame pro Sekunde verloren gehen. AV1-Codecs müssen nur eine Auflösung von 1080p unterstützen, aber dennoch sechs Instanzen bei 1080p30fps.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-19] MUSS drei Instanzen von 10-Bit-Hardware-Videodecodern (HDR) und Hardware-Videoencoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 4K bei 30 fps ausgeführt werden. Davon darf höchstens eine Encoder-Sitzung sein, die über eine GL-Oberfläche im Eingabeformat RGBA_1010102 konfiguriert werden kann. Bei allen Sitzungen darf maximal ein Frame pro Sekunde verloren gehen. Die Generierung von HDR-Metadaten durch den Encoder ist nicht erforderlich, wenn die Codierung von der GL-Oberfläche aus erfolgt. AV1-Codec-Sitzungen müssen nur eine Auflösung von 1080p unterstützen, auch wenn diese Anforderung 4K erfordert.

Ende der neuen Anforderungen

  • [5.1/H-1-7] Die Latenz bei der Codec-Initialisierung für eine Videocodierungssitzung mit 1080p oder weniger muss für alle Hardware-Videoencoder bei Belastung 40 ms oder weniger betragen. „Auslastung“ wird hier als eine gleichzeitige Transcodierungssitzung für 1080p-zu-720p-Videos mit Hardware-Video-Codecs und der Initialisierung der 1080p-Audio-/Videoaufnahme definiert. Bei Dolby Vision-Codecs darf die Codec-Initialisierungslatenz maximal 50 ms betragen.
  • [5.1/H-1-8] Die Latenz bei der Codec-Initialisierung für eine Audiocodierungssitzung mit einer Bitrate von 128 kbit/s oder weniger für alle Audioencoder muss unter Last 30 ms oder weniger betragen. „Auslastung“ wird hier als eine gleichzeitige Transcodierungssitzung für 1080p-zu-720p-Videos mit Hardware-Video-Codecs und der Initialisierung der 1080p-Audio-/Videoaufnahme definiert.

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-9] MÜSSEN zwei Instanzen sicherer Hardware-Videodecoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps sowohl für 8-Bit- (SDR) als auch für 10-Bit-HDR-Inhalte ausgeführt werden. Bei allen Sitzungen darf maximal ein Frame pro Sekunde verloren gehen.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-10] MÜSSEN 3 Instanzen von nicht sicheren Hardware-Video-Dekodierungssitzungen zusammen mit 1 Instanz einer sicheren Hardware-Video-Dekodierungssitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen mit 4K-Auflösung bei 30 fps ausgeführt werden, einschließlich einer sicheren Dekodierungssitzung und einer nicht sicheren Sitzung mit 1080p-Auflösung bei 30 fps, wobei maximal 2 Sitzungen in 10-Bit-HDR sein können. Bei allen Sitzungen darf maximal ein Frame pro Sekunde verloren gehen. AV1-Codec-Sitzungen müssen nur eine Auflösung von 1080p unterstützen, auch wenn diese Anforderung 4K erfordert.

Ende der neuen Anforderungen

  • [5.1/H-1-11] Es MUSS ein sicherer Decoder für jeden Hardware-AVC-, HEVC-, VP9- oder AV1-Decoder auf dem Gerät unterstützt werden.
  • [5.1/H-1-12] Für alle Hardware-Videodekoder muss die Codec-Initialisierungslatenz bei einer Videodekodierungssitzung mit 1080p oder weniger bei Belastung 40 ms oder weniger betragen. Die Auslastung wird hier als gleichzeitige Transcodierungssitzung für 1080p auf 720p definiert, bei der Hardware-Video-Codecs zusammen mit der Initialisierung der 1080p-Audio-Videowiedergabe verwendet werden. Bei Dolby Vision-Codecs darf die Codec-Initialisierungslatenz maximal 50 ms betragen.
  • [5.1/H-1-13] Die Codec-Initialisierungslatenz für eine Audiodekodierungssitzung mit einer Bitrate von 128 kbit/s oder weniger für alle Audiodekoder muss unter Last 30 ms oder weniger betragen. „Auslastung“ wird hier als eine gleichzeitige Transcodierungssitzung für nur Video von 1080p auf 720p mit Hardware-Video-Codecs und der Initialisierung der Audio-/Videowiedergabe in 1080p definiert.

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-14] MUSS den AV1-Hardware-Decoder Main 10, Level 4.1 sowie Filmkörnung mit Filmkörnungseffekt über die GPU-Komposition unterstützen.

Ende der neuen Anforderungen

  • [5.1/H-1-15] Es muss mindestens einen Hardware-Videodecoder mit Unterstützung für 4K60 geben.
  • [5.1/H-1-16] Es muss mindestens ein Hardware-Videoencoder vorhanden sein, der 4K60 unterstützt.

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-21] FEATURE_DynamicColorAspect muss für alle Hardware-Videodekoder (AVC, HEVC, VP9, AV1 oder höher) unterstützt werden. Hinweis: Das bedeutet, dass Anwendungen die Farbaspekte der Videoinhalte während der Dekodierungssitzung aktualisieren können. Decoder, die 10-Bit- und 8-Bit-Inhalte unterstützen, MÜSSEN im Surface-Modus dynamisch zwischen 8- und 10-Bit-Inhalten wechseln können. Decoder, die die HDR-Übertragungsfunktion unterstützen, MÜSSEN das dynamische Umschalten zwischen SDR- und HDR-Inhalten unterstützen.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-22] MUSS die Codierung, Dekodierung, GPU-Bearbeitung und Anzeige von Videoinhalten im Hochformat unabhängig von den Metadaten zur Drehung für die größte von der Kamera unterstützte Auflösung oder 4K unterstützen, je nachdem, was niedriger ist. Hinweis: Dazu gehören auch HDR-Profile, wenn der Codec HDR unterstützt. AV1-Codecs müssen nur die Auflösung 1080p unterstützen. Diese Anforderung gilt nur für Hardware-Codecs, die GPU und die DPU.

Ende der neuen Anforderungen

  • [5.3/H-1-1] Bei einer Video-Sitzung mit 4K und 60 fps darf bei Belastung KEIN Frame mehr als einmal in 10 Sekunden ausfallen (d. h. weniger als 0,167 % Frame-Drop).
  • [5.3/H-1-2] Bei einer Videoauflösungsänderung in einer Video-Sitzung mit 60 fps bei Belastung für eine 4K-Sitzung darf KEIN Frame in 10 Sekunden verloren gehen.
  • [5.6/H-1-1] Die Latenz beim Tippen-zum-Tönen muss beim CTS-Verifier-Test für das Tippen-zum-Tönen maximal 80 Millisekunden betragen.
  • [5.6/H-1-2] Die Audio-Roundtrip-Latenz muss über mindestens einen unterstützten Datenpfad 80 Millisekunden oder weniger betragen.
  • [5.6/H-1-3] MUSS mindestens 24-Bit-Audio für den Stereoausgang über 3,5-mm-Audioanschlüsse unterstützen, sofern vorhanden, und über USB-Audio, sofern dies über den gesamten Datenpfad für niedrige Latenz und Streamingkonfigurationen unterstützt wird. Für die Konfiguration mit niedriger Latenz sollte AAudio von der App im Callback-Modus mit niedriger Latenz verwendet werden. Für die Streamingkonfiguration sollte die App einen Java AudioTrack verwenden. Sowohl bei der Low-Latency- als auch bei der Streamingkonfiguration sollte der HAL-Ausgabe-Sink entweder AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT oder AUDIO_FORMAT_PCM_FLOAT als Zielausgabeformat akzeptieren.

Einführung neuer Anforderungen für Android 15

  • [5.6/H-1-4] MUSS mindestens 4-Kanal-USB-Audiogeräte unterstützen. (Diese Funktion wird von DJ-Controllern für die Vorschau von Titeln verwendet.)

Ende der neuen Anforderungen

  • [5.6/H-1-5] MUSS MIDI-Geräte der Klasse unterstützen und das MIDI-Funktionsflag angeben.
  • [5.6/H-1-9] MÜSSEN mindestens eine 12-Kanal-Mischung unterstützen. Das bedeutet, dass ein AudioTrack mit einer 7.1.4-Kanalmaske geöffnet und alle Kanäle richtig in Stereo geräumig dargestellt oder gedownmixt werden können.
  • [5.6/H-SR] Es wird DRINGEND empfohlen, eine 24-Kanal-Mischung mit mindestens 9.1.6- und 22.2-Kanalmasken zu unterstützen.
  • [5.7/H-1-2] Muss MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL mit den folgenden Funktionen zur Entschlüsselung von Inhalten unterstützen.
Mindeststichprobengröße 4 MiB
Mindestanzahl der Subsamples – H264 oder HEVC 32
Mindestanzahl von Subsamples – VP9 9
Mindestanzahl der Subsamples – AV1 288
Mindestgröße des Sub-Sample-Puffers 1 MiB
Minimale Größe des generischen Krypto-Buffers 500 KiB
Mindestzahl gleichzeitiger Sitzungen 30
Mindestanzahl von Schlüsseln pro Sitzung 20
Mindestgesamtzahl der Schlüssel (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] Es muss mindestens einen Hardware-Bilddecoder geben, der das AVIF-Baseline-Profil unterstützt.
  • [5.1/H-1-18] MUSS den AV1-Encoder unterstützen, der eine Auflösung von bis zu 480p bei 30 fps und 1 Mbit/s codieren kann.

Einführung neuer Anforderungen für Android 15

  • [5.1/H-1-20] Die Funktion Feature_HdrEditing muss für alle auf dem Gerät vorhandenen Hardware-AV1- und HEVC-Encoder in 4K-Auflösung oder der maximal von der Kamera unterstützten Auflösung unterstützt werden, je nachdem, was niedriger ist.

Ende der neuen Anforderungen

  • [5.12/H-SR] Es wird dringend empfohlen, die Funktion Feature_HdrEditing für alle Hardware-AV1- und HEVC-Encoder auf dem Gerät zu unterstützen.
  • [5.12/H-1-2] Das Farbformat RGBA_1010102 muss für alle Hardware-AV1- und HEVC-Encoder auf dem Gerät unterstützt werden.
  • [5.12/H-1-3] Es MUSS die Unterstützung für die Erweiterung „EXT_YUV_target“ angegeben werden, um YUV-Texturen sowohl in 8- als auch in 10-Bit-Auflösung zu beproben.
  • [7.1.4/H-1-1] Die Display Processing Unit (DPU) muss mindestens 6 Hardware-Overlays haben, von denen mindestens zwei 10‑Bit-Videoinhalte anzeigen können.

Einführung neuer Anforderungen für Android 15

Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.V für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben und die Unterstützung eines Hardware-AVC- oder HEVC-Encoders umfassen, gilt Folgendes:

Ende der neuen Anforderungen

2.2.7.2. Kamera

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

Einführung neuer Anforderungen für Android 15

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

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

  • [7.5/H-1-1] MUSS eine primäre Rückkamera mit einer Auflösung von mindestens 12 Megapixeln haben, die Videoaufnahmen mit 4K bei 30 fps, 1080p bei 60 fps und 720p bei 60 fps unterstützt. Die primäre Rückkamera ist die Rückkamera mit der niedrigsten Kamera-ID.

Ende der neuen Anforderungen

  • [7.5/H-1-2] MUSS eine primäre Frontkamera mit einer Auflösung von mindestens 6 Megapixeln haben und die Videoaufzeichnung mit 1080p bei 30 fps unterstützen. Die primäre Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
  • [7.5/H-1-3] Die Eigenschaft android.info.supportedHardwareLevel muss FULL oder höher für die primäre Rückkamera und LIMITED oder höher für die primäre Frontkamera unterstützen.
  • [7.5/H-1-4] MUSS CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME für beide primären Kameras unterstützen.
  • [7.5/H-1-5] Die Latenz der JPEG-Aufnahme von camera2 für eine Auflösung von 1080p muss unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Hauptkameras unter 1.000 ms liegen, wie im CTS-Kamera-Leistungstest gemessen.
  • [7.5/H-1-6] Die Startlatenz von camera2 (Öffnen der Kamera bis zum ersten Vorschauframe) muss unter ITS-Beleuchtungsbedingungen (3000 K) für beide Hauptkameras unter 500 ms liegen, gemessen mit dem CTS-Kamera-Leistungstest.
  • [7.5/H-1-8] MUSS CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW und android.graphics.ImageFormat.RAW_SENSOR für die primäre Rückkamera unterstützen.
  • [7.5/H-1-9] MUSS eine Rückkamera mit 720p oder 1080p bei 240 fps haben.
  • [7.5/H-1-10] Für die Hauptkameras MUSS min ZOOM_RATIO < 1,0 sein, wenn es eine RGB-Ultraweitwinkelkamera in derselben Richtung gibt.
  • [7.5/H-1-11] Die primären Kameras MÜSSEN gleichzeitiges Front- und Rückkamera-Streaming unterstützen.
  • [7.5/H-1-12] MUSS CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION sowohl für die primäre Front- als auch für die primäre Rückkamera unterstützen.
  • [7.5/H-1-13] Die primäre Rückkamera MUSS die LOGICAL_MULTI_CAMERA-Funktion unterstützen, wenn es mehr als eine RGB-Rückkamera gibt.
  • [7.5/H-1-14] Die Funktion STREAM_USE_CASE muss sowohl für die primäre Front- als auch für die primäre Rückkamera unterstützt werden.
  • [7.5/H-1-15] Der Nachtmodus muss sowohl über CameraX- als auch über Camera2-Erweiterungen für die Hauptkamera unterstützt werden.
  • [7.5/H-1-16] Die primären Kameras MÜSSEN DYNAMIC_RANGE_TEN_BIT unterstützen.
  • [7.5/H-1-17] MUSS CONTROL_SCENE_MODE_FACE_PRIORITY und die Gesichtserkennung (STATISTICS_FACE_DETECT_MODE_SIMPLE oder STATISTICS_FACE_DETECT_MODE_FULL) für die Hauptkameras unterstützen.

Einführung neuer Anforderungen für Android 15

  • [7.5/H-1-18] JPEG_R muss für die Hauptrückkamera und die Hauptfrontkamera unterstützt werden.
  • [7.5/H-1-19] MUSS CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION für die 1080p HLG10-Vorschau mit JPEG-Streams im Seitenverhältnis 16:9 mit maximaler Größe und für die 720p HLG10-Vorschau mit JPEG-Streams im Seitenverhältnis 16:9 mit maximaler Größe für die primäre Rückkamera unterstützen.
  • [7.5/H-1-20] MUSS standardmäßig JPEG_R für die primäre Rück- und primäre Frontkamera in der nativen Kamera-App ausgeben.

Ende der neuen Anforderungen

2.2.7.3. Hardware

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

Einführung neuer Anforderungen für Android 15

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

Ende der neuen Anforderungen

  • [7.1.1.1/H-2-1] Die Bildschirmauflösung muss mindestens 1080p betragen.

Einführung neuer Anforderungen für Android 15

  • [7.1.1.3/H-2-1] Die Bildschirmdichte MUSS mindestens 400 dpi betragen, wenn die Bildschirmbreite des Geräts < 600 dp ist.

Ende der neuen Anforderungen

  • [7.1.1.3/H-3-1] Es MUSS ein HDR-Display mit einer durchschnittlichen Helligkeit von mindestens 1.000 Nits haben.

Einführung neuer Anforderungen für Android 15

Ende der neuen Anforderungen

2.2.7.4. Leistung

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

Einführung neuer Anforderungen für Android 15

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

Ende der neuen Anforderungen

  • [8.2/H-1-1] MÜSSEN eine sequenzielle Schreibleistung von mindestens 150 MB/s gewährleisten.
  • [8.2/H-1-2] Die zufällige Schreibleistung muss mindestens 10 MB/s betragen.
  • [8.2/H-1-3] MÜSSEN eine sequenzielle Leseleistung von mindestens 250 MB/s gewährleisten.
  • [8.2/H-1-4] Die Leistung bei zufälligen Lesevorgängen muss mindestens 100 MB/s betragen.
  • [8.2/H-1-5] Parallele sequenzielle Lese- und Schreibleistung mit einer 2-fachen Lese- und 1-fachen Schreibleistung von mindestens 50 MB/s MÜSSEN gewährleistet sein.

Einführung neuer Anforderungen für Android 15

2.2.7.5. Grafik

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

Ende der neuen Anforderungen

2.3. Anforderungen an Fernseher

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

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

  • Sie haben einen Mechanismus zur Fernsteuerung der gerenderten Benutzeroberfläche auf dem Display bereitgestellt, das sich möglicherweise drei Meter vom Nutzer entfernt befindet.
  • Sie haben ein integriertes Display mit einer Diagonale von mehr als 61 cm ODER einen Videoausgang (z. B. VGA, HDMI, DisplayPort oder einen kabellosen Anschluss) für das Display.

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

2.3.1. Hardware

Implementierungen von Fernsehgeräten:

  • [7.2.2/T-0-1] MUSS ein D-Pad unterstützen.
  • [7.2.3/T-0-1] MUSS die Funktionen „Zurück“ und „Startseite“ bereitstellen.
  • [7.2.3/T-0-2] Es MUSS sowohl das normale als auch das lange Drücken der Rückwärtsfunktion (KEYCODE_BACK) an die Anwendung im Vordergrund gesendet werden.
  • [7.2.6.1/T-0-1] MUSS die Unterstützung von Gamecontrollern umfassen und die android.hardware.gamepad-Funktionsflag deklarieren.
  • [7.2.7/T] Es sollte eine Fernbedienung vorhanden sein, über die Nutzer auf die Bedienung ohne Touchbedienung und die wichtigsten Navigationstasten zugreifen können.

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

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

Implementierungen von Fernsehgeräten:

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

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

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

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

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

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

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

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

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

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

Implementierungen von Fernsehgeräten:

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

2.3.2. Multimedia

Fernsehgeräteimplementierungen MÜSSEN die folgenden Audiocodierungs- und -decodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

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

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

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

Implementierungen von Fernsehgeräten:

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

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

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

  • [5.3.1/T-1-1] HD 1080p bei 29,97 Bildern pro Sekunde mit Main Profile High Level.
  • [5.3.1/T-1-2] HD 1080i bei 59,94 Bildern pro Sekunde mit Main Profile High Level. Sie MÜSSEN interlaced MPEG-2-Videos deinterlacen und für Drittanbieteranwendungen verfügbar machen.

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

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

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

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

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

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

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

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

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

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

Wenn Fernsehgeräte mit VP9-Hardwaredekodern die VP9-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:

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

Implementierungen von Fernsehgeräten:

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

Wenn Fernsehgeräte keine integrierten Displays haben, aber stattdessen ein externes Display unterstützen, das über HDMI verbunden ist, gilt Folgendes:

  • [5.8/T-0-1] Der HDMI-Ausgabemodus muss auf die höchste Auflösung für das ausgewählte Pixelformat eingestellt sein, die mit einer Bildwiederholrate von 50 Hz oder 60 Hz für das externe Display funktioniert, je nach Videowiederholrate für die Region, in der das Gerät verkauft wird.
  • [5.8/T-SR-1] Es wird EMPFOHLEN, eine vom Nutzer konfigurierbare HDMI-Bildwiederholratenauswahl bereitzustellen.
  • [5.8] Die Aktualisierungsrate des HDMI-Ausgabemodus sollte entweder auf 50 Hz oder 60 Hz festgelegt werden, je nach Videoaktualisierungsrate für die Region, in der das Gerät verkauft wird.

Wenn Fernsehgeräte keine integrierten Displays haben, aber stattdessen ein externes Display unterstützen, das über HDMI verbunden ist, gilt Folgendes:

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

Wenn Fernseher keine UHD-Decodierung unterstützen, aber stattdessen ein externes Display über HDMI 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] Die Funktionen android.software.leanback und android.hardware.type.television MÜSSEN deklariert werden.
  • [3.2.3.1/T-0-1] Es MUSS eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorgeladen werden, die durch die hier aufgeführten Anwendungsabsichten definiert sind.
  • [3.4.1/T-0-1] Es MUSS eine vollständige Implementierung der android.webkit.Webview API bereitgestellt werden.

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

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

Implementierungen von Fernsehgeräten:

  • [3.8.14/T-SR-1] Es wird DRINGEND empfohlen, den Modus „Bild-im-Bild“ (PIP) für mehrere Fenster zu unterstützen.
  • [3.10/T-0-1] MUSS Dienste zur Barrierefreiheit von Drittanbietern unterstützen.
  • [3.10/T-SR-1] Es wird DRINGEND empfohlen, Bedienungshilfen auf dem Gerät vorinstalliert zu haben, die mit den Bedienungshilfen „Schalterzugriff“ und „TalkBack“ (für Sprachen, die von der vorinstallierten Text-to-Speech-Engine unterstützt werden) vergleichbar sind oder diese übertreffen. Diese Bedienungshilfen müssen dem TalkBack Open Source Project entsprechen.

Wenn die Implementierung von Fernsehgeräten die Funktion android.hardware.audio.output meldet, gilt Folgendes:

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

Einführung neuer Anforderungen für Android 15

Implementierungen von Fernsehgeräten:

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

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

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

Implementierungen von Fernsehgeräten:

  • [3/T-0-2] Die Plattformfunktion muss deklariert werdenandroid.software.live_tv.
  • [3/T-0-3] MÜSSEN alle TIF-APIs unterstützen, damit eine Anwendung, die diese APIs und den Dienst für TIF-basierte Eingaben von Drittanbietern verwendet, auf dem Gerät installiert und verwendet werden kann.

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

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

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

Ende der neuen Anforderungen

2.3.4. Leistung und Akkulaufzeit

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

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

  • [8.3/T-1-1] Es MUSS eine Nutzerinteraktion geben, mit der der Energiesparmodus aktiviert und deaktiviert werden kann.

Wenn Fernsehgeräte keine Akkus haben, gilt Folgendes:

Wenn Fernsehgeräte einen Akku haben, gilt Folgendes:

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

Implementierungen von Fernsehgeräten:

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

2.3.5. Sicherheitsmodell

Implementierungen von Fernsehgeräten:

  • [9/T-0-1] Die Funktion android.hardware.security.model.compatible muss deklariert werden.
  • [9.11/T-0-1] Die Implementierung des Schlüsselspeichers MUSS mit einer isolierten Ausführungsumgebung gesichert werden.
  • [9.11/T-0-2] MUSS Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie Hash-Funktionen der MD5-, SHA-1- und SHA-2-Familie haben, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich ordnungsgemäß zu unterstützen, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird. Bei der sicheren Isolation MÜSSEN alle potenziellen Mechanismen blockiert werden, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternativ sind auch eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation möglich.
  • [9.11/T-0-3] Die Authentifizierung auf dem Sperrbildschirm MUSS in der isolierten Ausführungsumgebung erfolgen und nur bei Erfolg dürfen die an die Authentifizierung gebundenen Schlüssel verwendet werden. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Sperrbildschirmauthentifizierung durchführen kann. Das Upstream-Android-Open-Source-Projekt bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.

Einführung neuer Anforderungen für Android 15

  • [9.11/T-0-4] MUSS die Schlüsselattestierung unterstützen, bei der der Attestierungssignaturschlüssel durch sichere Hardware geschützt und die Signatur auf sicherer Hardware ausgeführt wird. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten freigegeben werden, um zu verhindern, dass die Schlüssel verwendet werden, um Geräte dauerhaft zu identifizieren. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, es sei denn, es werden mindestens 100.000 Einheiten einer bestimmten SKU produziert. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, kann für jede 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Ende der neuen Anforderungen

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

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

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

Wenn Fernseherimplementierungen mehrere Nutzer umfassen und das android.hardware.telephony-Funktionsflag nicht deklariert wird, gilt Folgendes:

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

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

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

Wenn bei der Implementierung von Fernsehgeräten android.hardware.microphone angegeben wird, gilt Folgendes:

  • [9.8.2/T-4-1] Die Mikrofonanzeige MUSS angezeigt werden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 genannten Rollen mit der CDD-ID C-3-X auf das Mikrofon zugreifen.
  • [9.8.2/T-4-2] Die Mikrofonanzeige darf bei System-Apps mit sichtbarer Benutzeroberfläche oder direkter Nutzerinteraktion NICHT ausgeblendet werden.

Wenn bei der Implementierung von Fernsehgeräten android.hardware.camera.any angegeben wird, gilt Folgendes:

  • [9.8.2/T-5-1] Die Kameraanzeige MUSS angezeigt werden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn nur Apps auf die Kamera zugreifen, die die in Abschnitt 9.1 genannten Rollen mit CDD-ID haben [C-3-X].
  • [9.8.2/T-5-2] Die Kamera-Anzeige darf bei System-Apps, die eine sichtbare Benutzeroberfläche oder eine direkte Nutzerinteraktion haben, NICHT ausgeblendet werden.

2.3.6. Kompatibilität von Entwicklertools und ‑optionen

Einführung neuer Anforderungen für Android 15

Implementierungen von Fernsehgeräten:

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

Ende der neuen Anforderungen

2.4. Smartwatch-Anforderungen

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

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

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

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

2.4.1. Hardware

Smartwatch-Implementierungen:

  • [7.1.1.1/W-0-1] MUSS ein Display mit einer physischen Diagonale von 2,8 bis 6,4 cm haben.

  • [7.2.3/W-0-1] Der Nutzer muss die Startbildschirmfunktion und die Zurück-Funktion nutzen können, es sei denn, er befindet sich in UI_MODE_TYPE_WATCH.

  • [7.2.4/W-0-1] MUSS die Eingabe über einen Touchscreen unterstützen.

  • [7.3.1/W-SR-1] Es wird DRINGEND empfohlen, ein 3-Achsen-Beschleunigungsmesser einzubauen.

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

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

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

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

Smartwatch-Implementierungen:

  • [7.4.3/W-0-1] MUSS Bluetooth unterstützen.

  • [7.6.1/W-0-1] Es muss mindestens 1 GB nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) verfügbar sein.

  • [7.6.1/W-0-2] Für den Kernel und den Userspace müssen mindestens 416 MB Arbeitsspeicher verfügbar sein.

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

  • [7.8.2/W] KANN eine Audioausgabe haben.

2.4.2. Multimedia

Es gelten keine zusätzlichen Anforderungen.

2.4.3. Software

Smartwatch-Implementierungen:

  • [3/W-0-1] Die Funktion muss deklariert werden: android.hardware.type.watch.
  • [3/W-0-2] MUSS uiMode = UI_MODE_TYPE_WATCH unterstützen.
  • [3.2.3.1/W-0-1] Es MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler vorab geladen werden, für alle öffentlichen Intent-Filtermuster, die durch die hier aufgeführten Anwendungsabsichten definiert sind.

Smartwatch-Implementierungen:

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

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

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

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

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

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

2.4.4. Leistung und Akkulaufzeit

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

  • [8.3/W-SR-1] Es wird DRINGEND empfohlen, Nutzern die Möglichkeit zu geben, alle Apps anzuzeigen, die von den Energiesparmodi „App-Standby“ und „Ruhemodus“ ausgenommen sind.
  • [8.3/W-SR-2] Es wird DRINGEND empfohlen, Nutzern die Möglichkeit zu geben, den Energiesparmodus zu aktivieren und zu deaktivieren.

Smartwatch-Implementierungen:

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

2.4.5. Sicherheitsmodell

Smartwatch-Implementierungen:

  • [9/W-0-1] Die Funktion android.hardware.security.model.compatible MUSS deklariert werden.

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

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

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

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

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Vertrauensagenten enthalten, die die TrustAgentService System API implementieren, gilt Folgendes:

  • [9.11.1/W-1-1] Der Nutzer muss häufiger als alle 72 Stunden aufgefordert werden, eine der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) anzugeben.

2.5. Anforderungen für die Automobilbranche

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

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

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

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

2.5.1. Hardware

Implementierungen von Fahrzeuggeräten:

  • [7.1.1.1/A-0-1] Das Display muss eine Diagonale von mindestens 6 Zoll haben.
  • [7.1.1.1/A-0-2] Das Layout muss eine Bildschirmgröße von mindestens 750 dp × 480 dp haben.

Einführung neuer Anforderungen für Android 15

Wenn die Implementierung von Automotive-Geräten die gleichzeitige Nutzung durch mehrere Nutzer unterstützt (d. h., mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren, wobei jeder sein eigenes Display verwendet, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

  • [7.1.1.1/A-1-1] Für jedes Insassensegment muss es ein separates Display mit einer physischen Diagonale von mindestens 15,2 cm für das Hauptdisplay geben. Dieser Bereich sollte für jede Belegungszone mit CarOccupantZoneManager.DISPLAY_TYPE_MAIN getaggt werden.
  • [7.1.1.1/A-1-2] Die Bildschirmgröße muss für jedes Hauptdisplay mindestens 750 dp × 480 dp betragen.

Ende der neuen Anforderungen

Wenn Implementierungen von Automotive-Geräten OpenGL ES 3.1 unterstützen, gilt Folgendes:

  • [7.1.4.1/A-0-1] MUSS OpenGL ES 3.1 oder höher angeben.
  • [7.1.4.1/A-0-2] MUSS Vulkan 1.1 unterstützen.
  • [7.1.4.1/A-0-3] MUSS den Vulkan-Ladeprogramm enthalten und alle Symbole exportieren.

Implementierungen von Fahrzeuggeräten:

Einführung neuer Anforderungen für Android 15

Ende der neuen Anforderungen

  • [7.2.3/A-0-1] MUSS die Startbildschirmfunktion und KANN die Funktionen „Zurück“ und „Letzte Apps“ bereitstellen.

  • [7.2.3/A-0-2] Es MUSS sowohl das normale als auch das lange Drücken der Rückwärtsfunktion (KEYCODE_BACK) an die App im Vordergrund gesendet werden.

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

  • [7.3/A-0-2] Der Wert des Flags NIGHT_MODE MUSS mit dem Tag-/Nachtmodus des Dashboards übereinstimmen und SOLLTE auf dem Eingang des Umgebungslichtsensors basieren. Der zugrunde liegende Umgebungslichtsensor kann mit dem Photometer identisch sein.

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

  • [7.3/A-SR1] Der Standort kann durch Fusion von GPS/GNSS mit zusätzlichen Sensoren per Positionsbestimmung ohne Satelliten ermittelt WERDEN. Wenn Standort anhand der Positionsbestimmung per Dreiecksmessung ermittelt wird, wird DRINGEND empfohlen, die entsprechenden Sensor-Typen und/oder Fahrzeugeigenschafts-IDs zu implementieren und anzugeben.

  • [7.3/A-0-4] Der über LocationManager#requestLocationUpdates() angeforderte Standort DARF NICHT mit einer Karte abgeglichen werden.

  • [7.3.1/A-0-4] MUSS dem Koordinatensystem des Android-Autosensors entsprechen.

  • [7.3/A-SR-1] Es wird dringend empfohlen, ein 3-Achsen-Beschleunigungsmesser und ein 3-Achsen-Gyroskop einzubauen.

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

Einführung neuer Anforderungen für Android 15

Wenn die Implementierung von Automotive-Geräten die gleichzeitige Nutzung durch mehrere Nutzer unterstützt (d. h., mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren, wobei jeder sein eigenes Display verwendet, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

  • [7.3/A-1-1] Der Flag-Wert NIGHT_MODE muss auf allen Displays, einschließlich der Displays im Fond, einheitlich mit dem Tag-/Nachtmodus des Dashboards übereinstimmen.

Ende der neuen Anforderungen

Wenn Implementierungen von Automotive-Geräten einen Beschleunigungsmesser enthalten, gilt Folgendes:

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

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

  • [7.3.1/A-SR-1] Es wird DRINGEND empfohlen, den Composite-Sensor für Beschleunigungsmesser mit begrenzten Achsen zu implementieren.

Wenn die Implementierung von Automotive-Geräten einen Beschleunigungsmesser mit weniger als 3 Achsen enthält, gilt Folgendes:

  • [7.3.1/A-1-3] MUSS den Sensor TYPE_ACCELEROMETER_LIMITED_AXES implementieren und melden.
  • [7.3.1/A-1-4] MUSS den Sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED implementieren und melden.

Wenn in der Implementierung eines Auto-Geräts ein Gyroskop enthalten ist, gilt Folgendes:

  • [7.3.4/A-2-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz erfassen können.
  • [7.3.4/A-2-3] MUSS in der Lage sein, Ausrichtungsänderungen von bis zu 250 Grad pro Sekunde zu messen.
  • [7.3.4/A-SR-1] Es wird DRINGEND empfohlen, den Messbereich des Gyroskops auf +/- 250 dps zu konfigurieren, um die Auflösung so weit wie möglich zu maximieren.

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

  • [7.3.4/A-SR-2] Es wird DRINGEND empfohlen, den Composite-Sensor für den Gyroskop mit begrenzten Achsen zu implementieren.

Wenn in der Implementierung eines Fahrzeuggeräts ein Gyroskop mit weniger als drei Achsen verwendet wird, gilt Folgendes:

  • [7.3.4/A-4-1] MUSS den Sensor TYPE_GYROSCOPE_LIMITED_AXES implementieren und melden.
  • [7.3.4/A-4-2] MUSS den Sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED implementieren und melden.

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

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

Wenn in der Implementierung von Fahrzeuggeräten ein TYPE_HEADING-Sensor enthalten ist, gilt Folgendes:

  • [7.3.4/A-4-3] MÜSSEN Ereignisse mit einer Häufigkeit von mindestens 1 Hz erfassen können.
  • [7.3.4/A-SR-3] Es wird dringend empfohlen, Ereignisse mit einer Häufigkeit von mindestens 10 Hz zu erfassen.
  • MÜSSEN sich auf den wahren Norden beziehen.
  • MÜSSEN auch dann verfügbar sein, wenn das Fahrzeug steht.
  • MÜSSEN eine Auflösung von mindestens 1 Grad haben.

Implementierungen von Fahrzeuggeräten:

  • [7.4.3/A-0-1] MUSS Bluetooth und SOLLTE Bluetooth LE unterstützen.
  • [7.4.3/A-0-2] Android Automotive-Implementierungen MÜSSEN die folgenden Bluetooth-Profile unterstützen:
    • Telefonanrufe über das Hands-Free Profile (HFP)
    • Medienwiedergabe über Audio Distribution Profile (A2DP)
    • Steuerung der Medienwiedergabe über das Remote Control Profile (AVRCP).
    • Kontaktfreigabe über das Phone Book Access Profile (PBAP)

Einführung neuer Anforderungen für Android 15

  • [7.4.3/A-SR-1] Es wird DRINGEND empfohlen, das Message Access Profile (MAP) zu unterstützen, wenn das Gerät die Zone für den Fahrer hat.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

Wenn die Implementierung von Automotive-Geräten die gleichzeitige Nutzung durch mehrere Nutzer unterstützt (d. h., mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren, wobei jeder sein eigenes Display verwendet, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

  • [7.4.3/A-1-1] MÜSSEN unabhängig sein und dürfen die Nutzung von Bluetooth durch andere Nutzer nicht beeinträchtigen.

Ende der neuen Anforderungen

Implementierungen von Fahrzeuggeräten:

  • [7.4.5/A] Es sollte Unterstützung für die datenbasierte Mobilfunkverbindung geben.
  • [7.4.5/A] Die System API-Konstante NetworkCapabilities#NET_CAPABILITY_OEM_PAID darf für Netzwerke verwendet werden, die für System-Apps verfügbar sein sollten.

Wenn Geräteimplementierungen die Unterstützung von AM/FM-Radiosendern umfassen und die Funktion für alle Anwendungen freigeben, gilt Folgendes:

  • [7.4/A-1-1] Es MUSS Unterstützung für FEATURE_BROADCAST_RADIO erklärt werden.

Eine Rückkamera ist eine Kamera, die nach außen gerichtet ist und sich an einer beliebigen Stelle am Fahrzeug befindet. Sie nimmt also Bilder auf der Rückseite des Fahrzeugs auf, ähnlich wie eine Rückkamera.

Eine Frontkamera ist eine Kamera, die auf den Nutzer gerichtet ist und sich an einer beliebigen Stelle im Fahrzeug befindet. Sie ist auf die Fahrzeugkabine gerichtet und nimmt den Nutzer auf, z. B. für Videokonferenzen und ähnliche Anwendungen.

Implementierungen von Fahrzeuggeräten:

  • [7.5/A-SR-1] Es wird dringend empfohlen, eine oder mehrere nach außen gerichtete Kameras zu verwenden.
  • KANN eine oder mehrere nach vorne gerichtete Kameras enthalten.
  • [7.5/A-SR-2] Es wird DRINGEND empfohlen, das gleichzeitige Streaming mehrerer Kameras zu unterstützen.

Wenn die Implementierung von Automotive-Geräten mindestens eine nach vorne gerichtete Kamera enthält, gilt für diese Kamera Folgendes:

  • [7.5/A-1-1] MUSS so ausgerichtet sein, dass die lange Dimension der Kamera mit der X‑Y-Ebene der Sensorachsen von Android Automotive übereinstimmt.
  • [7.5/A-SR-3] Es wird DRINGEND empfohlen, entweder eine Hardware mit fester Brennweite oder eine Hardware mit erweitertem Schärfebereich zu verwenden.
  • [7.5/A-1-2] Die primäre nach außen gerichtete Kamera MUSS die nach außen gerichtete Kamera mit der niedrigsten Kamera-ID sein.

Wenn in der Implementierung eines Fahrzeuggeräts mindestens eine Kamera zum Nutzer gerichtet ist, gilt für diese Kamera Folgendes:

  • [7.5/A-2-1] Die primäre Frontkamera MUSS die Frontkamera mit der niedrigsten Kamera-ID sein.
  • KANN so ausgerichtet sein, dass die lange Dimension der Kamera mit der X‑Y-Ebene der Sensorachsen von Android Automotive übereinstimmt.

Wenn in der Implementierung eines Auto-Geräts eine Kamera enthalten ist, auf die über die android.hardware.Camera- oder android.hardware.camera2-API zugegriffen werden kann, gilt Folgendes:

  • [7.5/A-3-1] MÜSSEN den grundlegenden Kameraanforderungen in Abschnitt 7.5 entsprechen.

Wenn in der Implementierung eines Auto-Geräts eine Kamera enthalten ist, auf die nicht über die android.hardware.Camera- oder android.hardware.camera2-API zugegriffen werden kann, gilt Folgendes:

  • [7.5/A-4-1] MUSS über den Dienst „Extended View System“ zugänglich sein.

Wenn in der Implementierung von Automotive-Geräten eine oder mehrere Kameras vorhanden sind, auf die über den Dienst „Extended View System“ zugegriffen werden kann, gilt für eine solche Kamera Folgendes:

  • [7.5/A-5-1] Die Kameravorschau darf NICHT gedreht oder horizontal gespiegelt werden.
  • [7.5/A-SR-4] Es wird DRINGEND empfohlen, eine Auflösung von mindestens 1,3 Megapixeln zu verwenden.

Wenn die Implementierung von Fahrzeuggeräten eine oder mehrere Kameras umfasst, auf die sowohl über den erweiterten Ansichtssystemdienst als auch über die android.hardware.Camera- oder android.hardware.Camera2-API zugegriffen werden kann, gilt für eine solche Kamera Folgendes:

  • [7.5/A-6-1] Es MUSS dieselbe Kamera-ID angegeben werden.

Wenn Implementierungen von Automotive-Geräten eine proprietäre Kamera-API bereitstellen, gilt Folgendes:

  • [7.5/A-7-1] Eine solche Kamera-API muss mit der android.hardware.camera2 API oder der Extended View System API implementiert werden.

Implementierungen von Fahrzeuggeräten:

  • [7.6.1/A-0-1] Es muss mindestens 4 GB nichtflüchtiger Speicherplatz für private Daten der Anwendung (/data-Partition) verfügbar sein.

  • [7.6.1/A] Die Datenpartition sollte formatiert werden, um eine bessere Leistung und Langlebigkeit des Flash-Speichers zu ermöglichen (z. B. mit dem Dateisystem f2fs).

Wenn bei der Implementierung von Automotive-Geräten freigegebener externer Speicher über einen Teil des internen nicht entfernbaren Speichers bereitgestellt wird, gilt Folgendes:

  • [7.6.1/A-SR-1] Es wird DRINGEND empfohlen, den E/A-Overhead bei Vorgängen auf dem externen Speicher zu reduzieren, z. B. mit SDCardFS.

Einführung neuer Anforderungen für Android 15

Wenn die Implementierung von Automotive-Geräten die gleichzeitige Nutzung durch mehrere Nutzer unterstützt (d. h., mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren, wobei jeder sein eigenes Display verwendet, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

  • [7.6.1/A-1-1] In einer einzelnen AAOS-Instanz MÜSSEN für jeden gleichzeitigen Android-Nutzer mindestens 4 GB nichtflüchtiger Speicher für private Anwendungsdaten (/data-Partition) verfügbar sein.

Ende der neuen Anforderungen

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

Einführung neuer Anforderungen für Android 15

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

    • 280 dpi oder weniger auf kleinen/normalen Bildschirmen
    • ldpi oder niedriger auf sehr großen Bildschirmen
    • mdpi oder niedriger auf großen Bildschirmen
  • [7.6.1/A-2-2] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 944 MB betragen, pro Hauptdisplay, wenn eine der folgenden Pixeldichten verwendet wird:

    • xhdpi oder höher auf kleinen/normalen Displays
    • hdpi oder höher auf großen Bildschirmen
    • mdpi oder höher auf sehr großen Bildschirmen
  • [7.6.1/A-2-3] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 1.280 MB betragen, pro Hauptdisplay, wenn eine der folgenden Pixeldichten verwendet wird:

    • 400 dpi oder höher auf kleinen/normalen Bildschirmen
    • xhdpi oder höher auf großen Bildschirmen
    • tvdpi oder höher auf sehr großen Bildschirmen
  • [7.6.1/A-2-4] Der für den Kernel und den Userspace verfügbare Arbeitsspeicher MUSS mindestens 1.824 MB betragenpro Hauptdisplay, wenn eine der folgenden Pixeldichten verwendet wird:

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

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

Ende der neuen Anforderungen

Implementierungen von Fahrzeuggeräten:

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

Implementierungen von Fahrzeuggeräten:

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

Implementierungen von Fahrzeuggeräten:

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

Einführung neuer Anforderungen für Android 15

Wenn die Implementierung von Automotive-Geräten die gleichzeitige Nutzung durch mehrere Nutzer unterstützt (d. h., mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren, wobei jeder sein eigenes Display verwendet, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

  • [7.8.2/A-1-1] Für Systeme mit mehreren gleichzeitigen Nutzern MUSS es für jedes Hauptdisplay ein Audioausgabegerät geben.
  • [7.8.2/A-1-2] Es MUSS eine Audiozone für den Fahrer geben, die den Lautsprecher für die gesamte Kabine abdeckt. Die Zone für den Beifahrer kann die Audiozone des Fahrers teilen oder eine eigene Audioausgabe haben.

Ende der neuen Anforderungen

2.5.2. Multimedia

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

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

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

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

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

  • [5.3/A-0-1] H.264 AVC
  • [5.3/A-0-2] MPEG-4 SP
  • [5.3/A-0-3] VP8
  • [5.3/A-0-4] VP9

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

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

Einführung neuer Anforderungen für Android 15

Wenn die Implementierung von Automotive-Geräten die gleichzeitige Nutzung durch mehrere Nutzer unterstützt (d. h., mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren, wobei jeder sein eigenes Display verwendet, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

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

Ende der neuen Anforderungen

2.5.3. Software

Implementierungen von Fahrzeuggeräten:

  • [3/A-0-1] Die Funktion muss deklariert werden: android.hardware.type.automotive.

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

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

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

  • [3/A-1-1] Es dürfen KEINE speziellen Berechtigungen für die Verwendung dieser Properties durch die Systemanwendung festgelegt oder die Verwendung dieser Properties durch Drittanbieteranwendungen verhindert werden.
  • [3/A-1-2] Darf KEINE Fahrzeugeigenschaft replizieren, die bereits im SDK vorhanden ist.

Implementierungen von Fahrzeuggeräten:

  • [3.2.1/A-0-1] MUSS alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der Referenzseite für Berechtigungen für die Automobilbranche dokumentiert.

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

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

Einführung neuer Anforderungen für Android 15

  • [3.8/A-0-1] Sekundären Nutzern mit Vollzugriff, die nicht der aktuelle Nutzer im Vordergrund sind, darf NICHT erlaubt werden, Aktivitäten zu starten und auf die Benutzeroberfläche auf allen Displays zuzugreifen.

Wenn die Implementierung von Automotive-Geräten die gleichzeitige Nutzung durch mehrere Nutzer unterstützt (d. h., mehrere Android-Nutzer können gleichzeitig mit dem Gerät interagieren, wobei jeder sein eigenes Display verwendet, wenn config_multiuserVisibleBackgroundUsers aktiviert ist), gilt Folgendes:

  • [3.8/A-1-1] Die folgende vordefinierte Liste von UserRestrictions für sekundäre Nutzer mit Vollzugriff MUSS implementiert werden, die nicht der aktuelle Nutzer im Vordergrund sind, aber UI-Zugriff auf das Display haben, das ihnen zugewiesen ist. Die Liste der UserRestrictions-Werte ist DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE und DISALLOW_MICROPHONE_TOGGLE.

  • [3.8/A-1-2] Sekundäre Nutzer, die nicht der aktuelle Nutzer im Vordergrund sind, aber über die Benutzeroberfläche Zugriff auf das Display haben, dürfen NICHT die volle Berechtigung haben, den Tag-/Nachtmodus, die Sprache, das Datum, die Uhrzeit, die Zeitzone oder die Displayfarben (einschließlich Helligkeit, Nachtlicht, Graustufenmodus von Digital Wellbeing und Reduzierung greller Farben) für andere Nutzer über die Einstellungen oder über eine API zu ändern.

Ende der neuen Anforderungen

Implementierungen von Fahrzeuggeräten:

  • [3.8.3/A-0-1] MUSS Benachrichtigungen anzeigen, die die Notification.CarExtender API verwenden, wenn sie von Drittanbieteranwendungen angefordert werden.

  • [3.8.4/A-SR-1] Es wird dringend empfohlen, auf dem Gerät einen Assistenten zu implementieren, der die Hilfeaktion verarbeitet.

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

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

Implementierungen von Fahrzeuggeräten:

  • [3.8.3.1/A-0-1] MUSS Ressourcen wie in der Notifications on Automotive OS SDK-Dokumentation beschrieben korrekt rendern.
  • [3.8.3.1/A-0-2] MUSS für Benachrichtigungsaktionen die Optionen „WIEDERGAUEN“ und „STILL“ anstelle der über Notification.Builder.addAction() bereitgestellten Optionen anzeigen
  • [3.8.3.1/A] Die Verwendung erweiterter Verwaltungsaufgaben wie Einstellungen für Benachrichtigungskanäle sollte EINGESCRENKT sein. Es ist zulässig, pro Anwendung UI-Affordances zu verwenden, um die Anzahl der Steuerelemente zu reduzieren.

Wenn Implementierungen von Automotive-Geräten HAL-Nutzereigenschaften unterstützen, gilt Folgendes:

Implementierungen von Fahrzeuggeräten:

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

Implementierungen von Fahrzeuggeräten:

  • [3.8/A] Die App darf die Anfragen zum Wechsel in den Vollbildmodus gemäß immersive documentation einschränken.
  • [3.8/A] Die Statusleiste und die Navigationsleiste können jederzeit sichtbar sein.
  • [3.8/A] Die Anwendung darf die Anfragen zum Ändern der Farben hinter den System-UI-Elementen einschränken, damit diese Elemente jederzeit gut sichtbar sind.

2.5.4. Leistung und Akkulaufzeit

Implementierungen von Fahrzeuggeräten:

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

2.5.5. Sicherheitsmodell

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

Wenn für die Implementierung eines Auto-Geräts android.hardware.microphone deklariert wird, gilt Folgendes:

  • [9.8.2/A-1-1] Die Mikrofonanzeige MUSS angezeigt werden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 genannten Rollen mit CDD-ID [C-4-X] auf das Mikrofon zugreifen.
  • [9.8.2/A-1-2] Die Mikrofonanzeige darf bei System-Apps, die eine sichtbare Benutzeroberfläche oder eine direkte Nutzerinteraktion haben, NICHT ausgeblendet werden.
  • [9.8.2/A-1-3] Es MUSS eine Nutzerfunktion geben, mit der das Mikrofon in den Einstellungen aktiviert und deaktiviert werden kann.

Wenn in der Implementierung eines Automotive-Geräts android.hardware.camera.any deklariert wird, gilt Folgendes:

  • [9.8.2/A-2-1] Die Kameraanzeige MUSS angezeigt werden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn nur Apps mit den Rollen zugreifen, die in Abschnitt 9.1 Berechtigungen mit der CDD-ID [C-4-X] definiert sind.
  • [9.8.2/A-2-2] Die Kamera-Anzeige darf bei System-Apps, die eine sichtbare Benutzeroberfläche oder eine direkte Nutzerinteraktion haben, NICHT ausgeblendet werden.
  • [9.8.2/A-2-3] Es MUSS eine Nutzerfunktion geben, mit der die Kamera in den Einstellungen aktiviert und deaktiviert werden kann.
  • [9.8.2/A-2-4] MÜSSEN die zuletzt verwendeten und aktiven Apps, die die Kamera verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen zugehörigen Attributionsmeldungen anzeigen.

Implementierungen von Fahrzeuggeräten:

  • [9/A-0-1] Die Funktion android.hardware.security.model.compatible MUSS erklärt werden.
  • [9.11/A-0-1] Die Implementierung des Schlüsselspeichers MUSS mit einer isolierten Ausführungsumgebung gesichert werden.
  • [9.11/A-0-2] MUSS Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie Hash-Funktionen der MD5-, SHA-1- und SHA-2-Familie haben, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich ordnungsgemäß zu unterstützen, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird. Bei der sicheren Isolation MÜSSEN alle potenziellen Mechanismen blockiert werden, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternativ sind auch eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation möglich.
  • [9.11/A-0-3] Die Sperrbildschirm-Authentifizierung MUSS in der isolierten Ausführungsumgebung erfolgen und nur bei Erfolg dürfen die an die Authentifizierung gebundenen Schlüssel verwendet werden. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Sperrbildschirmauthentifizierung durchführen kann. Das Upstream-Android-Open-Source-Projekt bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.

Einführung neuer Anforderungen für Android 15

  • [9.11/A-0-4] MUSS die Schlüsselattestierung unterstützen, bei der der Attestierungssignaturschlüssel durch sichere Hardware geschützt und die Signatur in sicherer Hardware ausgeführt wird. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten freigegeben werden, um zu verhindern, dass die Schlüssel verwendet werden, um Geräte dauerhaft zu identifizieren. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, es sei denn, es werden mindestens 100.000 Einheiten einer bestimmten SKU produziert. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, kann für jede 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Ende der neuen Anforderungen

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

Implementierungen von Fahrzeuggeräten:

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

2.5.6. Kompatibilität von Entwicklertools und ‑optionen

Einführung neuer Anforderungen für Android 15

Implementierungen von Fahrzeuggeräten:

  • Perfetto
    • [6.1/A-0-1] Dem Shell-Nutzer MUSS ein /system/bin/perfetto-Binärprogramm zur Verfügung gestellt werden, dessen Befehlszeile der Perfetto-Dokumentation entspricht.
    • [6.1/A-0-2] Die perfetto-Binärdatei MUSS als Eingabe eine Protobuf-Konfiguration akzeptieren, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
    • [6.1/A-0-3] Die perfetto-Binärdatei MUSS einen Protokoll-Trace ausgeben, der dem in der Perfetto-Dokumentation definierten Schema entspricht.
    • [6.1/A-0-4] Muss über die perfetto-Binärdatei mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitstellen.
    • [6.1/A-0-5] Der perfetto-Traced-Daemon MUSS standardmäßig aktiviert sein (Systemeigenschaft persist.traced.enable).

Ende der neuen Anforderungen

2.6. Tabletanforderungen

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

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

  • Das Display hat eine Größe von mehr als 7 Zoll und weniger als 18 Zoll, gemessen diagonal.

Die Implementierung von Tablets hat ähnliche Anforderungen wie die von Mobilgeräten. Die Ausnahmen sind in diesem Abschnitt mit einem * gekennzeichnet und werden hier zur Information aufgeführt.

2.6.1. Hardware

Gyroskop

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

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

Mindestarbeitsspeicher und Mindestspeicherplatz (Abschnitt 7.6.1)

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

Einführung neuer Anforderungen für Android 15

USB-Peripheriegerätemodus (Abschnitt 7.7.1)

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

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

Ende der neuen Anforderungen

Virtueller Realitätsmodus (Abschnitt 7.9.1)

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

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

2.6.2. Sicherheitsmodell

Schlüssel und Anmeldedaten (Abschnitt 9.11)

Weitere Informationen finden Sie unter [9.11].

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

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

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

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

2.6.2. Software

  • [3.2.3.1/Tab-0-1] Es MUSS mindestens eine Anwendung oder Dienstkomponente mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorgeladen werden, die durch die hier aufgeführten Anwendungsabsichten definiert sind.

3. Software

3.1. Kompatibilität mit verwalteten APIs

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

Geräteimplementierungen:

  • [C-0-1] Es MÜSSEN vollständige Implementierungen aller dokumentierten APIs bereitgestellt werden, die vom Android SDK oder von APIs mit dem Markierungs-Tag „@SystemApi“ im Upstream-Android-Quellcode bereitgestellt werden, einschließlich aller dokumentierten Verhaltensweisen.

  • [C-0-2] Alle Klassen, Methoden und zugehörigen Elemente, die mit der TestApi-Annotation (@TestApi) gekennzeichnet sind, MÜSSEN unterstützt/erhalten werden.

  • [C-0-3] Es dürfen KEINE verwalteten APIs ausgelassen, API-Schnittstellen oder ‑Signaturen geändert, vom dokumentierten Verhalten abgewichen oder No-Ops verwendet werden, es sei denn, dies ist ausdrücklich in dieser Kompatibilitätsdefinition erlaubt.

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

  • [C-0-5] Drittanbieter-Apps dürfen KEINE Nicht-SDK-Schnittstellen verwenden, die als Methoden und Felder in den Java-Sprachpaketen definiert sind, die sich im Boot-Classpath in AOSP befinden und nicht Teil des öffentlichen SDK sind. Dazu gehören APIs, die mit der Anmerkung @hide, aber nicht mit einer @SystemAPI versehen sind, wie in den SDK-Dokumenten beschrieben, sowie private und paketinterne Klassenmitglieder.

  • [C-0-6] Jede nicht SDK-Schnittstelle MUSS in denselben eingeschränkten Listen enthalten sein, die über die vorläufigen und Deaktivierungslisten im Pfad prebuilts/runtime/appcompat/hiddenapi-flags.csv für den entsprechenden API-Level-Zweig im AOSP angegeben sind.

  • [C-0-7] MUSS den dynamischen Aktualisierungsmechanismus für die signierte Konfiguration unterstützen, um Nicht-SDK-Schnittstellen aus einer eingeschränkten Liste zu entfernen, indem die signierte Konfiguration in ein APK eingebettet wird, wobei die vorhandenen öffentlichen Schlüssel in AOSP verwendet werden.

    Allerdings gilt:

    • MÖGLICH: Wenn eine ausgeblendete API nicht vorhanden ist oder in der Geräteimplementierung anders implementiert wird, können Sie die ausgeblendete API in die Sperrliste verschieben oder aus allen Sperrlisten entfernen.
    • MÖGLICH: Wenn eine versteckte API noch nicht im AOSP vorhanden ist, fügen Sie sie einer der eingeschränkten Listen hinzu.

Einführung neuer Anforderungen für Android 15

  • [C-0-8] Die Installation von Anwendungen, die auf ein API-Level unter 23 24 ausgerichtet sind, DARF NICHT unterstützt werden.

Ende der neuen Anforderungen

3.1.1. Android-Erweiterungen

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

Implementierungen von Android-Geräten:

  • [C-0-1] Die AOSP-Implementierung der freigegebenen Bibliothek ExtShared und der Dienste ExtServices MUSS mit Versionen vorgeladen werden, die mindestens den für jede API-Ebene zulässigen Mindestversionen entsprechen. Beispiel: Geräteimplementierungen für Android 7.0 mit API-Level 24 MÜSSEN mindestens Version 1 enthalten.

  • [C-0-2] Es MUSS nur eine gültige Erweiterungsversionsnummer zurückgegeben werden, die vom AOSP definiert wurde.

  • [C-0-3] MUSS alle APIs unterstützen, die von den von android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) zurückgegebenen Erweiterungsversionen definiert sind, auf die gleiche Weise wie andere verwaltete APIs gemäß den Anforderungen in Abschnitt 3.1.

3.1.2. Android-Bibliothek

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

  • [C-0-1] Die org.apache.http.legacy-Bibliothek DARF NICHT in der Boot-Classpath platziert werden.
  • [C-0-2] Die org.apache.http.legacy-Bibliothek darf der Anwendungs-Classpath nur dann hinzugefügt werden, wenn die App eine der folgenden Bedingungen erfüllt:
    • Sie ist auf API-Level 28 oder niedriger ausgerichtet.
    • Deklariert in seinem Manifest, dass die Bibliothek erforderlich ist, indem das android:name-Attribut von <uses-library> auf org.apache.http.legacy festgelegt wird.

Die AOSP-Implementierung erfüllt diese Anforderungen.

3.2 Soft API Compatibility

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

3.2.1. Berechtigungen

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

3.2.2. Parameter erstellen

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

  • [C-0-1] Um für alle Geräteimplementierungen einheitliche, aussagekräftige Werte bereitzustellen, enthält die folgende Tabelle zusätzliche Einschränkungen für die Formate dieser Werte, die von Geräteimplementierungen einzuhalten SIND.
Parameter Details
VERSION.RELEASE Die Version des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format. Dieses Feld MUSS einen der Stringwerte enthalten, die in Zulässige Versionsstrings für Android 15 definiert sind.
VERSION.SDK Die Version des derzeit ausgeführten Android-Systems in einem Format, auf das der Anwendungscode von Drittanbietern zugreifen kann. Bei Android 15 MUSS dieses Feld den Ganzzahlwert 15_INT haben.
VERSION.SDK&lowbar;INT Die Version des derzeit ausgeführten Android-Systems in einem Format, auf das der Anwendungscode von Drittanbietern zugreifen kann. Bei Android 15 MUSS dieses Feld den Ganzzahlwert 15&lowbar;INT haben.
VERSION.INCREMENTAL Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Build-Version des derzeit ausgeführten Android-Systems in einem visuell lesbaren Format angibt. Dieser Wert darf NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. In der Regel wird in diesem Feld angegeben, welche Build-Nummer oder Änderungs-ID der Quellkontrollversion zum Generieren des Builds verwendet wurde. Der Wert dieses Felds MUSS als ausdruckbarer 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^[^ :\/~]+$ entsprechen.
BRETTSPIEL Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Hardware des Geräts in einem visuell lesbaren Format angibt. Dieses Feld kann beispielsweise verwendet werden, um die spezifische Version des Boards anzugeben, das das Gerät mit Strom versorgt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^[a-zA-Z0-9_-]+$ entsprechen.
MARKE Ein Wert, der den Markennamen des Geräts widerspiegelt, wie er den Endnutzern bekannt ist. MÜSSEN in einem für Menschen lesbaren Format vorliegen und SOLLEN den Hersteller des Geräts oder die Marke des Unternehmens repräsentieren, unter dem das Gerät vertrieben wird. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^[a-zA-Z0-9_-]+$ entsprechen.
UNTERSTÜTZTE&lowbar;ABIS Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
UNTERSTÜTZTE&lowbar;32&lowbar;BIT&lowbar;ABIS Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
UNTERSTÜTZTE&lowbar;64&lowbar;BIT&lowbar;ABIS Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
CPU&lowbar;ABI Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
CPU&lowbar;ABI2 Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
GERÄT Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen enthält, der die Konfiguration der Hardwarefunktionen und das Industriedesign des Geräts identifiziert. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^[a-zA-Z0-9_-]+$ entsprechen. Dieser Gerätename darf sich während der Lebensdauer des Produkts NICHT ändern.
FINGERPRINT Ein String, der diesen Build eindeutig identifiziert. Er sollte in einem für Menschen lesbaren Format vorliegen. Es MUSS dieser Vorlage entsprechen:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Beispiel:

acme/myproduct/
    mydevice:15/LMYXX/3359:userdebug/test-keys

Der Fingerabdruck darf KEINE Leerzeichen enthalten. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein.

Hardware Der Name der Hardware (aus der Kernel-Befehlszeile oder /proc). Sie sollte für Menschen gut lesbar sein. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^[a-zA-Z0-9_-]+$ entsprechen.
HOST Ein String, der den Host, auf dem der Build erstellt wurde, eindeutig identifiziert, in einem für Menschen lesbaren Format. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
ID Eine vom Geräteimplementierer ausgewählte Kennung für eine bestimmte Version in einem für Menschen lesbaren Format. Dieses Feld kann mit „android.os.Build.VERSION.INCREMENTAL“ identisch sein, sollte aber einen ausreichend aussagekräftigen Wert haben, damit Endnutzer zwischen Software-Builds unterscheiden können. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^[a-zA-Z0-9._-]+$ entsprechen.
HERSTELLER Der Handelsname des Erstausrüsters (Original Equipment Manufacturer, OEM) des Produkts. Es gibt keine Anforderungen an das spezifische Format dieses Felds, mit Ausnahme der folgenden: Es darf NICHT null oder der leere String („"") sein. Dieses Feld darf sich während der Lebensdauer des Produkts NICHT ändern.
SOC&lowbar;HERSTELLER Der Handelsname des Herstellers des primären System-on-a-Chip (SOC), der im Produkt verwendet wird. Für Geräte mit demselben SOC-Hersteller sollte derselbe Konstantenwert verwendet werden. Bitten Sie den SOC-Hersteller um die richtige Konstante. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein, MUSS dem regulären Ausdruck ^([0-9A-Za-z ]+) entsprechen, DARF nicht mit einem Leerzeichen beginnen oder enden und DARF nicht „unbekannt“ sein. Dieses Feld darf sich während der Lebensdauer des Produkts NICHT ändern.
SOC&lowbar;MODELL Der Modellname des primären System-on-a-Chip (SOC), das im Produkt verwendet wird. Für Geräte mit demselben SOC-Modell sollte derselbe Konstantenwert verwendet werden. Bitten Sie den SOC-Hersteller um die richtige Konstante. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^([0-9A-Za-z ._/+-]+)$ entsprechen. Er darf nicht mit einem Leerzeichen beginnen oder enden und darf nicht „unbekannt“ sein. Dieses Feld darf sich während der Lebensdauer des Produkts NICHT ändern.
MODELL Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endnutzer bekannt ist. Dies sollte derselbe Name sein, unter dem das Gerät vermarktet und an Endnutzer verkauft wird. Es gibt keine Anforderungen an das spezifische Format dieses Felds, es darf jedoch NICHT null oder der leere String („"") sein. Dieses Feld darf sich während der Lebensdauer des Produkts NICHT ändern.
PRODUKT/FUNKTION Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des jeweiligen Produkts (SKU) enthält und innerhalb derselben Marke eindeutig sein MUSS. MÜSSEN für Menschen lesbar sein, sind aber nicht unbedingt für Endnutzer gedacht. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^[a-zA-Z0-9_-]+$ entsprechen. Dieser Produktname darf sich während der Lebensdauer des Produkts NICHT ändern.
ODM&lowbar;SKU Ein optionaler Wert, der vom Geräteimplementierer ausgewählt wird und die SKU (Stock Keeping Unit) enthält, mit der bestimmte Konfigurationen des Geräts erfasst werden, z. B. alle Peripheriegeräte, die beim Verkauf im Lieferumfang enthalten sind. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und mit dem regulären Ausdruck ^([0-9A-Za-z.,_-]+)$ übereinstimmen.
SERIAL MUSS „UNKNOWN“ zurückgeben.
TAGS Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt werden und die das Build weiter unterscheiden. Die Tags MÜSSEN als 7-Bit-ASCII codierbar sein, dem regulären Ausdruck ^[a-zA-Z0-9._-]+ entsprechen und einen der Werte haben, die den drei gängigen Signaturkonfigurationen der Android-Plattform entsprechen: Release-Schlüssel, Entwicklerschlüssel und Testschlüssel.
UHRZEIT Ein Wert, der den Zeitstempel des Builds angibt.
SCHREIBMASCHINE Ein vom Geräteimplementierer ausgewählter Wert, der die Laufzeitkonfiguration des Builds angibt. Dieses Feld MUSS einen der Werte haben, die den drei gängigen Android-Laufzeitkonfigurationen entsprechen: „user“, „userdebug“ oder „eng“.
NUTZER Ein Name oder eine Nutzer-ID des Nutzers (oder automatisierten Nutzers), der den Build generiert hat. Es gibt keine Anforderungen an das Format dieses Felds, es darf nur nicht null oder der leere String ("") sein.
SICHERHEIT&lowbar;PATCH Ein Wert, der den Stand der Sicherheits-Patches eines Builds angibt. Sie MUSS darauf hinweisen, dass der Build in keiner Weise anfällig für die in dem angegebenen öffentlichen Sicherheitsbulletin für Android beschriebenen Probleme ist. Es MUSS im Format [JJJJ-MM-TT] angegeben sein und mit einem definierten String übereinstimmen, der im öffentlichen Sicherheitsbulletin für Android oder in der Sicherheitswarnung für Android dokumentiert ist, z. B. „2015-11-01“.
BASE&lowbar;OS Ein Wert, der dem FINGERPRINT-Parameter des Builds entspricht, der mit Ausnahme der im Android Public Security Bulletin bereitgestellten Patches mit diesem Build identisch ist. Es MUSS der richtige Wert angegeben werden. Wenn ein solcher Build nicht vorhanden ist, muss ein leerer String („"") angegeben werden.
BOOTLOADER Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Bootloader-Version des Geräts in einem visuell lesbaren Format angibt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und mit dem regulären Ausdruck ^[a-zA-Z0-9._-]+$ übereinstimmen.
getRadioVersion() MUSS (sein oder zurückgeben) ein vom Geräteimplementierer ausgewählter Wert sein, der die spezifische interne Funk-/Modemversion des Geräts in einem für Menschen lesbaren Format angibt. Wenn ein Gerät kein internes Funkmodul/Modem hat, MUSS NULL zurückgegeben werden. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^[a-zA-Z0-9._-,]+$ entsprechen.
getSerial() Es MUSS eine Hardware-Seriennummer angegeben werden, die für alle Geräte mit demselben MODELL und HERSTELLER verfügbar und eindeutig sein MUSS. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^[a-zA-Z0-9]+$ entsprechen.

3.2.3. Intent-Kompatibilität

3.2.3.1. Gängige Anwendungsabsichten

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

Geräteimplementierungen:

  • [C-SR-1] Es wird DRINGEND empfohlen, eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorzuladen, die durch die hier aufgeführten Anwendungsabsichten definiert sind, und die Erfüllung zu ermöglichen, d.h. die Erwartungen der Entwickler an diese gängigen Anwendungsabsichten wie im SDK beschrieben zu erfüllen.

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

3.2.3.2. Intent-Auflösung
  • [C-0-1] Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen zulassen, dass jedes Intent-Muster, auf das in Abschnitt 3.2.3.1 verwiesen wird, mit Ausnahme der Einstellungen, von Drittanbieter-Apps überschrieben werden kann. Die Upstream-Open-Source-Implementierung von Android ermöglicht dies standardmäßig.

  • [C-0-2] Geräteimplementierer DÜRFEN der Verwendung dieser Intent-Muster durch Systemanwendungen KEINE speziellen Berechtigungen zuweisen oder verhindern, dass Drittanbieteranwendungen eine Bindung an diese Muster herstellen und die Kontrolle übernehmen. Dieses Verbot umfasst insbesondere, aber nicht ausschließlich, die Deaktivierung der Benutzeroberfläche „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 die Daten-URI enthält. Ein Intent-Filtermuster, das den Daten-URI „http://www.android.com“ angibt, ist beispielsweise spezifischer als das Haupt-Intent-Muster des Browsers für „http://“.

Android bietet auch einen Mechanismus, mit dem Drittanbieter-Apps ein autoritatives standardmäßiges App-Verknüpfungsverhalten für bestimmte Arten von Web-URI-Intents angeben können. Wenn solche autorisierten Deklarationen in den Intent-Filtermustern einer App definiert sind, gilt für Geräteimplementierungen Folgendes:

  • [C-0-4] MÜSSEN alle Intent-Filter validieren, indem die in der Digital Asset Links-Spezifikation definierten Validierungsschritte ausgeführt werden, die vom Paketmanager im Upstream-Android-Open-Source-Projekt implementiert wurden.
  • [C-0-5] Die Intent-Filter MÜSSEN während der Installation der Anwendung validiert werden und alle erfolgreich validierten URI-Intent-Filter müssen als Standard-App-Handler für ihre URIs festgelegt werden.
  • KÖNNEN bestimmte URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen, wenn sie erfolgreich verifiziert wurden, andere infrage kommende URI-Filter jedoch nicht. Wenn eine Geräteimplementierung dies tut, MUSS sie dem Nutzer im Einstellungsmenü entsprechende URI-spezifische Musterüberschreibungen zur Verfügung stellen.
  • Sie MÜSSEN Nutzern in den Einstellungen App-Links-Einstellungen für einzelne Apps zur Verfügung stellen:
    • [C-0-6] Der Nutzer MUSS in der Lage sein, das Standardverhalten von App-Links für eine App ganzheitlich zu überschreiben: „Immer öffnen“, „Immer fragen“ oder „Nie öffnen“. Dies muss für alle infrage kommenden URI-Intent-Filter gleichermaßen gelten.
    • [C-0-7] Der Nutzer MUSS eine Liste der potenziellen URI-Intent-Filter sehen können.
    • Die Geräteimplementierung KANN dem Nutzer die Möglichkeit bieten, bestimmte URI-Intent-Filter, die erfolgreich überprüft wurden, pro Intent-Filter zu überschreiben.
    • [C-0-8] Die Geräteimplementierung MUSS Nutzern die Möglichkeit bieten, bestimmte Filter für URI-Intents anzusehen und zu überschreiben, wenn bei der Geräteimplementierung einige Filter für URI-Intents die Überprüfung bestehen, andere aber nicht.
3.2.3.3. Intent-Namespaces
  • [C-0-1] Geräteimplementierungen DÜRFEN KEINE Android-Komponenten enthalten, die neue Intent- oder Broadcast-Intent-Muster mit einer ACTION, CATEGORY oder einem anderen Schlüsselstring im Namensbereich „android.*“ oder „com.android.*“ berücksichtigen.
  • [C-0-2] Geräteimplementierer dürfen KEINE Android-Komponenten einbinden, die neue Intent- oder Broadcast-Intent-Muster mit einer ACTION, CATEGORY oder einem anderen Schlüsselstring in einem Paketbereich berücksichtigen, der einer anderen Organisation gehört.
  • [C-0-3] Geräteimplementierer DÜRFEN KEINE der in Abschnitt 3.2.3.1 aufgeführten Intent-Muster ändern oder erweitern.
  • Geräteimplementierungen KÖNNEN Intent-Muster mit Namespaces enthalten, die eindeutig und offensichtlich mit der eigenen Organisation verknüpft sind. Dieses Verbot entspricht dem für Java-Sprachklassen in Abschnitt 3.6.
3.2.3.4. Broadcast-Intents

Drittanbieteranwendungen nutzen die Plattform, um bestimmte Intents zu senden, um über Änderungen in der Hardware- oder Softwareumgebung informiert zu werden.

Geräteimplementierungen:

  • [C-0-1] MUSS die hier aufgeführten Intents für öffentliche Übertragungen als Reaktion auf entsprechende Systemereignisse senden, wie in der SDK-Dokumentation beschrieben. Diese Anforderung steht nicht im Widerspruch zu Abschnitt 3.5, da die Einschränkung für Hintergrundanwendungen auch in der SDK-Dokumentation beschrieben ist. Bestimmte Broadcast-Intents sind außerdem an die Hardwareunterstützung gebunden. Wenn das Gerät die erforderliche Hardware unterstützt, MÜSSEN die Intents gesendet und das Verhalten gemäß der SDK-Dokumentation bereitgestellt werden.
3.2.3.5. Bedingte Anwendungsabsichten

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

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

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

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

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

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

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

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

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

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

  • [C-6-1] Es MUSS eine Aktivität implementiert werden, die auf die Absicht ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS reagiert. Bei Implementierungen mit UI_MODE_TYPE_NORMAL MUSS es sich dabei um eine Aktivität handeln, bei der der Nutzer der App Zugriff auf die Konfigurationen der Einstellungen für die Funktion „Bitte nicht stören“ 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] Es MUSS ein für Nutzer zugänglicher Mechanismus zum Hinzufügen und Konfigurieren von Eingabemethoden von Drittanbietern als Reaktion auf den android.settings.INPUT_METHOD_SETTINGS-Intent vorhanden sein.

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

  • [C-8-1] MUSS die android.settings.ACCESSIBILITY_SETTINGS-Bestimmung einhalten, dass ein nutzerzugänglicher Mechanismus zur Verfügung gestellt wird, mit dem die Bedienungshilfen von Drittanbietern neben den vorinstallierten Bedienungshilfen aktiviert und deaktiviert werden können.

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

Wenn Geräteimplementierungen den Datensparmodus bieten, gilt Folgendes:

Wenn Geräteimplementierungen keinen Datensparmodus bieten, gilt Folgendes:

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

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

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

Wenn Geräteimplementierungen eine vorinstallierte App enthalten oder Apps von Drittanbietern auf die Nutzungsstatistiken zugreifen sollen, müssen sie:

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

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

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

Wenn Geräteimplementierungen Links zu den Aktivitäten anzeigen, die in den Einstellungen unter AutofillService_passwordsActivity angegeben sind, oder Links zu Nutzerpasswörtern über einen ähnlichen Mechanismus, gilt Folgendes:

  • [C-16-1] Es MÜSSEN solche Links für alle installierten Autofill-Dienste angezeigt werden.

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

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

  • [C-SR-3] Es wird DRINGEND empfohlen, für die Intents „android.intent.action.TTS_SERVICE“, „android.speech.tts.engine.INSTALL_TTS_DATA“ und „android.speech.tts.engine.GET_SAMPLE_TEXT“ eine Aktivität zu implementieren, um die Ausführung dieser Intents zu ermöglichen, wie im SDK hier 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 an einem Dock angedockt ist. Geräteimplementierungen:

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

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

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

Wenn die Geräteimplementierung das Starten normaler Android-Aktivitäten auf mehr als einem Display zulässt, gilt Folgendes:

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

Wenn Geräteimplementierungen das Starten normaler Android-Aktivitäten auf sekundären Displays zulassen und ein sekundäres Display das Flag android.view.Display.FLAG_PRIVATE hat:

  • [C-3-1] Nur der Eigentümer des Displays, des Systems und der Aktivitäten, die sich bereits auf dem Display befinden, MUSS es starten können. Jeder kann auf einem Display starten, das das Flag android.view.Display.FLAG_PUBLIC hat.

3.3 Kompatibilität mit nativen APIs

Die Kompatibilität mit nativem Code ist eine Herausforderung. Aus diesem Grund gilt für Geräteimplementierer Folgendes:

  • [C-SR-1] Es wird DRINGEND empfohlen, die Implementierungen der unten aufgeführten Bibliotheken aus dem Upstream-Android Open Source Project zu verwenden.

3.3.1. Application Binary Interfaces

Verwalteter Dalvik-Bytecode kann nativen Code aufrufen, der in der Anwendungsdatei .apk als ELF-Datei .so bereitgestellt wird, die für die entsprechende Gerätehardwarearchitektur kompiliert wurde. Da nativer Code stark von der zugrunde liegenden Prozessortechnologie abhängt, definiert Android im Android NDK eine Reihe von Application Binary Interfaces (ABIs).

Geräteimplementierungen:

  • [C-0-1] MUSS mit mindestens einer der definierten Android-NDK-ABIs kompatibel sein.
  • [C-0-2] MUSS die Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code mithilfe der Standard-Java Native Interface (JNI)-Semantik aufzurufen.
  • [C-0-3] MUSS mit jeder erforderlichen Bibliothek in der folgenden Liste quellenkompatibel (d.h. Header-kompatibel) und binärkompatibel (für das ABI) sein.
  • [C-0-5] Die vom Gerät unterstützte native Application Binary Interface (ABI) MUSS über die Parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS und android.os.Build.SUPPORTED_64_BIT_ABIS korrekt angegeben werden. Dabei muss es sich jeweils um eine kommagetrennte Liste von ABIs handeln, die von der am häufigsten bis zur am wenigsten bevorzugten sortiert ist.

Einführung neuer Anforderungen für Android 15

  • [C-0-6] Es MUSS über die oben genannten Parameter eine Teilmenge der folgenden Liste von ABIs gemeldet werden. Es DÜRFEN KEINE ABIs gemeldet werden, die nicht auf der Liste stehen.

Ende der neuen Anforderungen

  • [C-0-7] Alle folgenden Bibliotheken, die native APIs bereitstellen, MÜSSEN für Apps mit nativem Code verfügbar sein:

    • libaaudio.so (native Audiounterstützung von AAudio)
    • libamidi.so (native MIDI-Unterstützung, wenn die Funktion android.software.midi wie in Abschnitt 5.9 beschrieben beansprucht wird)
    • libandroid.so (Unterstützung für native Android-Aktivitäten)
    • libc (C-Bibliothek)
    • libcamera2ndk.so
    • libdl (dynamischer Linker)
    • libEGL.so (native OpenGL-Oberflächenverwaltung)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (Android-Protokollierung)
    • libmediandk.so (Unterstützung nativer Medien-APIs)
    • libm (Mathematische Bibliothek)
    • libneuralnetworks.so (Neural Networks API)
    • libOpenMAXAL.so (Unterstützung von OpenMAX AL 1.0.1)
    • libOpenSLES.so (OpenSL ES 1.0.1-Audiounterstützung)
    • libRS.so
    • libstdc++ (minimale Unterstützung für C++)
    • libvulkan.so (Vulkan)
    • libz (Zlib-Komprimierung)
    • JNI-Schnittstelle
  • [C-0-8] Es dürfen KEINE öffentlichen Funktionen für die oben aufgeführten nativen Bibliotheken hinzugefügt oder entfernt werden.

  • [C-0-9] In /vendor/etc/public.libraries.txt MÜSSEN zusätzliche Bibliotheken aufgeführt werden, die nicht zu AOSP gehören und direkt für Drittanbieter-Apps freigegeben sind.

  • [C-0-10] Andere native Bibliotheken, die in AOSP als Systembibliotheken implementiert und bereitgestellt werden, dürfen Drittanbieter-Apps, die auf API-Ebene 24 oder höher ausgerichtet sind, NICHT zugänglich gemacht werden, da sie reserviert sind.

  • [C-0-11] Alle OpenGL ES 3.1- und Android Extension Pack-Funktionssymbole, wie im NDK definiert, MÜSSEN über die libGLESv3.so-Bibliothek exportiert werden. Alle Symbole MÜSSEN vorhanden sein. In Abschnitt 7.1.4.1 werden die Anforderungen beschrieben, wann die vollständige Implementierung der einzelnen Funktionen erwartet wird.

  • [C-0-12] Es MÜSSEN Funktionssymbole für die Vulkan 1.1-Kernfunktionssymbole sowie die Erweiterungen VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 und VK_KHR_get_physical_device_properties2 über die libvulkan.so-Bibliothek exportiert werden. Alle Symbole MÜSSEN vorhanden sein. In Abschnitt 7.1.4.2 werden die Anforderungen beschrieben, wann die vollständige Implementierung der einzelnen Funktionen erwartet wird.

  • MÜSSEN mit dem Quellcode und den Headerdateien erstellt werden, die im Upstream-Android-Open-Source-Projekt verfügbar sind.

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

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

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

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

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

  • [C-2-1] Die folgenden Zeilen MÜSSEN in /proc/cpuinfo enthalten sein und die Werte auf demselben Gerät DÜRFEN NICHT geändert werden, auch wenn sie von anderen ABIs gelesen werden.

    • Features:, gefolgt von einer Liste aller optionalen ARMv7-CPU-Funktionen, die vom Gerät unterstützt werden.
    • CPU architecture:, gefolgt von einer Ganzzahl, die die höchste unterstützte ARM-Architektur des Geräts beschreibt (z.B. „8“ für ARMv8-Geräte).
  • [C-2-2] Die folgenden Vorgänge MÜSSEN immer verfügbar sein, auch wenn das ABI auf einer ARMv8-Architektur implementiert ist, entweder durch native CPU-Unterstützung oder durch Softwareemulation:

    • SWP- und SWPB-Anweisungen
    • Barriere-Vorgänge CP15ISB, CP15DSB und CP15DMB
  • [C-2-3] MUSS die Unterstützung für die Advanced SIMD-Erweiterung (auch NEON genannt) umfassen.

3.4. Webkompatibilität

3.4.1. WebView-Kompatibilität

Wenn Geräteimplementierungen eine vollständige Implementierung der android.webkit.Webview API bieten, gilt Folgendes:

  • [C-1-1] MUSS android.software.webview melden.
  • [C-1-2] Für die Implementierung der android.webkit.WebView API MUSS der Build des Chromium-Projekts aus dem Upstream-Android-Open-Source-Projekt auf dem Android 15-Branch verwendet werden.
  • [C-1-3] Der von WebView gemeldete User-Agent-String MUSS dieses Format haben:

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, wie Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • Der Wert des Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE übereinstimmen.
    • Der String $(MODEL) DARF leer sein. Wenn er nicht leer ist, MUSS er mit dem Wert von „android.os.Build.MODEL“ übereinstimmen.
    • „Build/$(BUILD)“ kann weggelassen werden. Wenn er vorhanden ist, MUSS der String $(BUILD) mit dem Wert für „android.os.Build.ID“ übereinstimmen.
    • Der Wert des Strings $(CHROMIUM_VER) MUSS der Version von Chromium im Upstream-Android-Open-Source-Projekt entsprechen.
    • Bei Geräteimplementierungen kann „Mobile“ im User-Agent-String weggelassen werden.
  • Die WebView-Komponente sollte möglichst viele HTML5-Funktionen unterstützen und, sofern sie eine Funktion unterstützt, der HTML5-Spezifikation entsprechen.

  • [C-1-4] Die bereitgestellten Inhalte oder die Inhalte der Remote-URL MÜSSEN in einem Prozess gerendert werden, der sich von der Anwendung unterscheidet, die die WebView instanziiert. Insbesondere muss der separate Renderer-Prozess weniger Berechtigungen haben, als separate Nutzer-ID ausgeführt werden, keinen Zugriff auf das Datenverzeichnis der App haben, keinen direkten Netzwerkzugriff haben und nur über Binder auf die minimal erforderlichen Systemdienste zugreifen können. Die AOSP-Implementierung von WebView erfüllt diese Anforderung.

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

3.4.2. Browserkompatibilität

Wenn Geräteimplementierungen eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten, gilt Folgendes:

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

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

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

3.5. API-Verhaltenskompatibilität

Geräteimplementierungen:

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

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

  • [C-0-1] Geräte dürfen das Verhalten oder die Semantik einer Standardabsicht NICHT ändern.
  • [C-0-2] Geräte dürfen den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, Content-Provider usw.) NICHT ändern.
  • [C-0-3] Die Semantik einer Standardberechtigung darf von Geräten NICHT geändert werden.
  • Geräte dürfen die Einschränkungen für Hintergrund-Apps NICHT ändern. Für Apps im Hintergrund gilt Folgendes:
    • [C-0-4] Sie MÜSSEN die Ausführung von Callbacks beenden, die von der App registriert wurden, um Ausgaben von GnssMeasurement und GnssNavigationMessage zu erhalten.
    • [C-0-5] Die Häufigkeit der Updates, die der App über die API-Klasse LocationManager oder die Methode WifiManager.startScan() zur Verfügung gestellt werden, MUSS begrenzt werden.
    • [C-0-6] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, dürfen im Manifest der App keine Broadcastempfänger für die impliziten Broadcasts von Standard-Android-Intents registriert werden, es sei denn, für den Broadcast-Intent ist eine "signature"- oder "signatureOrSystem"-Berechtigung protectionLevel erforderlich oder die App steht auf der Befreiungsliste.
    • [C-0-7] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN die Hintergrunddienste der App beendet werden, als hätte die App die Methode stopSelf() der Dienste aufgerufen, es sei denn, die App wird auf eine temporäre Zulassungsliste gesetzt, um eine Aufgabe zu erledigen, die für den Nutzer sichtbar ist.
    • [C-0-8] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN die Wakelocks, die die App hält, freigegeben werden.
  • [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 von Provider.getName() zurückgegeben) und Klassen zurückgeben, es sei denn, die App hat die Liste über insertProviderAt() oder removeProvider() geändert. Geräte können nach der unten aufgeführten Liste zusätzliche Anbieter zurückgeben.
    1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider – sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaround – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

Die oben genannte Liste ist nicht vollständig. Die Compatibility Test Suite (CTS) testet einen Großteil der Plattform auf Verhaltenskompatibilität, aber nicht alle Bereiche. Der Implementierer ist dafür verantwortlich, die Verhaltenskompatibilität mit dem Android Open Source-Projekt sicherzustellen. Aus diesem Grund sollten Geräteimplementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt wichtige Teile des Systems neu zu implementieren.

3.5.1. Anwendungsbeschränkung

Wenn in Geräteimplementierungen ein proprietärer Mechanismus zum Einschränken von Apps implementiert ist (z.B. Änderung oder Einschränkung des im SDK beschriebenen API-Verhaltens) und dieser Mechanismus strenger ist als der Bucket „Restricted App Standby“, gilt Folgendes:

  • [C-1-1] Der Nutzer muss die Liste der eingeschränkten Apps sehen können.
  • [C-1-2] Es MUSS eine Nutzerfunktion geben, mit der alle diese proprietären Einschränkungen für jede App aktiviert oder deaktiviert werden können.
  • [C-1-3] Diese proprietären Einschränkungen dürfen nicht automatisch angewendet werden, ohne dass ein Nachweis für eine schlechte Systemgesundheit vorliegt. Sie können jedoch auf Apps angewendet werden, wenn eine schlechte Systemgesundheit erkannt wird, z. B. durch steckengebliebene Wakelocks, langlaufende Dienste und andere Kriterien. Die Kriterien KÖNNEN von Geräteimplementierern festgelegt werden, MÜSSEN aber mit der Auswirkung der App auf den Systemzustand in Verbindung stehen. Andere Kriterien, die nicht ausschließlich mit der Systemintegrität zusammenhängen, wie z. B. die geringe Beliebtheit der App auf dem Markt, DÜRFEN NICHT als Kriterien verwendet werden.

  • [C-1-4] Diese proprietären Einschränkungen dürfen nicht automatisch für Apps angewendet werden, wenn ein Nutzer die App-Einschränkungen manuell deaktiviert hat. Es darf dem Nutzer jedoch vorgeschlagen werden, diese proprietären Einschränkungen anzuwenden.

  • [C-1-5] Nutzer MÜSSEN darüber informiert werden, ob diese proprietären Einschränkungen automatisch auf eine App angewendet werden. Diese Informationen MÜSSEN innerhalb von 24 Stunden vor der Anwendung dieser proprietären Einschränkungen zur Verfügung gestellt werden.

  • [C-1-6] Für alle API-Aufrufe einer App MUSS die Methode ActivityManager.isBackgroundRestricted() den Wert „true“ zurückgeben.

  • [C-1-7] Die oberste App im Vordergrund, die vom Nutzer explizit verwendet wird, DARF NICHT eingeschränkt werden.

  • [C-1-8] Diese proprietären Einschränkungen für eine App MÜSSEN aufgehoben werden, wenn ein Nutzer die App explizit verwendet und sie damit zur aktiven App im Vordergrund macht.

  • [C-1-10] Es MUSS ein öffentliches und eindeutiges Dokument oder eine öffentliche und 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 MUSS von den Android SDK-Dokumenten verlinkbar sein und MUSS Folgendes enthalten:

    • Auslösen von Bedingungen für proprietäre Einschränkungen
    • Was und wie eine App eingeschränkt werden kann.
    • Wie eine App von solchen Einschränkungen ausgenommen werden kann.
    • Wie eine App eine Ausnahme von proprietären Einschränkungen beantragen kann, wenn diese für vom Nutzer installierbare Apps unterstützt wird.

Wenn eine App auf dem Gerät vorinstalliert ist und seit mehr als 30 Tagen nicht ausdrücklich von einem Nutzer verwendet wurde, sind [C-1-3] [C-1-5] ausgenommen.

Wenn Geräteimplementierungen die in AOSP implementierten App-Einschränkungen erweitern, gilt Folgendes:

  • [C-2-1]Die Implementierung MUSS der in diesem Dokument beschriebenen entsprechen.

3.5.2. Anwendungsruhezustand

Wenn Geräteimplementierungen die in AOSP enthaltene App-Ruhezustandsfunktion oder eine Erweiterung dieser Funktion enthalten, gilt Folgendes:

  • [C-1-1] MUSS alle Anforderungen in Abschnitt 3.5.1 erfüllen, mit Ausnahme von [C-1-6] und [C-1-3].
  • [C-1-2] Die Einschränkung für die App für einen Nutzer darf NUR angewendet werden, wenn es Hinweise darauf gibt, dass der Nutzer die App seit einiger Zeit nicht mehr verwendet hat. Dieser Zeitraum sollte mindestens einen Monat betragen. Die Nutzung muss entweder durch eine explizite Nutzerinteraktion über die API UsageStats#getLastTimeVisible() oder durch etwas anderes definiert werden, das dazu führt, dass eine App den Zustand „Zwangsweise beendet“ verlässt. Dazu gehören Dienstbindungen, Inhaltsanbieterbindungen, explizite Übertragungen usw., die über die neue API UsageStats#getLastTimeAnyComponentUsed() erfasst werden.
  • [C-1-3] Einschränkungen, die alle Nutzer des Geräts betreffen, dürfen NUR angewendet werden, wenn es einen Nachweis dafür gibt, dass das Paket seit einiger Zeit von KEINEM Nutzer verwendet wurde. Dieser Zeitraum sollte mindestens einen Monat betragen.
  • [C-1-4] Die App DARF NICHT daran gehindert werden, auf Aktivitätsabsichten, Dienstbindungen, Anfragen von Inhaltsanbietern oder explizite Übertragungen zu reagieren.

Die App-Ruhezustandsfunktion in AOSP erfüllt die oben genannten Anforderungen.

3.6. API-Namespaces

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

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

Das bedeutet:

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

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

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

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

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

Geräteimplementierer KÖNNEN benutzerdefinierte APIs in nativen Sprachen außerhalb der NDK-APIs hinzufügen. Die benutzerdefinierten APIs müssen jedoch folgende Anforderungen erfüllen:

  • [C-1-1] Darf sich NICHT in einer NDK-Bibliothek oder einer Bibliothek befinden, die einer anderen Organisation gehört, wie hier beschrieben.

Wenn ein Geräteimplementierer vorschlägt, einen der oben genannten Paket-Namespaces zu verbessern (z. B. durch Hinzufügen nützlicher neuer Funktionen zu einer vorhandenen API oder durch Hinzufügen einer neuen API), sollte er source.android.com aufrufen und gemäß den Informationen auf dieser Website mit dem Einreichen von Änderungen und Code beginnen.

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

3.7. Laufzeitkompatibilität

Geräteimplementierungen:

  • [C-0-1] MUSS das vollständige Dalvik-Ausführformat (DEX) und die Dalvik-Bytecode-Spezifikation und -Semantik unterstützen.

  • [C-0-2] Dalvik-Laufzeiten MÜSSEN so konfiguriert werden, dass Arbeitsspeicher gemäß der Upstream-Android-Plattform und wie in der folgenden Tabelle angegeben zugewiesen wird. (Definitionen für Bildschirmgröße und Bildschirmdichte finden Sie unter Abschnitt 7.1.1.)

  • Es sollte Android Runtime (ART), die Referenz-Upstream-Implementierung des Dalvik-Ausführbaren-Formats und das Paketverwaltungssystem der Referenzimplementierung verwenden.

  • MÜSSEN Fuzz-Tests unter verschiedenen Ausführungsmodi und Zielarchitekturen ausführen, um die Stabilität der Laufzeit zu gewährleisten. Weitere Informationen finden Sie auf der Website des Android Open Source-Projekts unter JFuzz und DexFuzz.

Die unten angegebenen Speicherwerte gelten als Mindestwerte. Geräteimplementierungen können mehr Arbeitsspeicher pro Anwendung zuweisen.

Bildschirmlayout Bildschirmdichte Mindestarbeitsspeicher für die Anwendung
Android-Uhr 120 dpi (ldpi) 32 MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi)
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi) 36 MB
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 48 MB
360 dpi (360dpi)
400 dpi (400dpi) 56 MB
420 dpi (420dpi) 64 MB
480 dpi (xxhdpi) 88 MB
560 dpi (560dpi) 112 MB
640 dpi (xxxhdpi) 154 MB
klein/normal 120 dpi (ldpi) 32 MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi) 48 MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 80 MB
360 dpi (360dpi)
400 dpi (400dpi) 96 MB
420 dpi (420dpi) 112 MB
480 dpi (xxhdpi) 128 MB
560 dpi (560dpi) 192 MB
640 dpi (xxxhdpi) 256 MB
groß 120 dpi (ldpi) 32 MB
140 dpi (140dpi) 48 MB
160 dpi (mdpi)
180 dpi (180dpi) 80 MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 96 MB
320 dpi (xhdpi) 128 MB
360 dpi (360dpi) 160 MB
400 dpi (400dpi) 192 MB
420 dpi (420dpi) 228 MB
480 dpi (xxhdpi) 256 MB
560 dpi (560dpi) 384 MB
640 dpi (xxxhdpi) 512 MB
xlarge 120 dpi (ldpi) 48 MB
140 dpi (140dpi) 80 MB
160 dpi (mdpi)
180 dpi (180dpi) 96 MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 144 MB
320 dpi (xhdpi) 192 MB
360 dpi (360dpi) 240 MB
400 dpi (400dpi) 288 MB
420 dpi (420dpi) 336 MB
480 dpi (xxhdpi) 384 MB
560 dpi (560dpi) 576 MB
640 dpi (xxxhdpi) 768 MB

3.8. Kompatibilität der Benutzeroberfläche

3.8.1. Launcher (Startbildschirm)

Android enthält einen Launcher (Startbildschirm) und unterstützt Drittanbieter-Apps, die den Launcher des Geräts (Startbildschirm) ersetzen.

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

  • [C-1-1] Die Plattformfunktion android.software.home_screen MUSS deklariert werden.
  • [C-1-2] MUSS das AdaptiveIconDrawable-Objekt zurückgeben, wenn die Drittanbieteranwendung das <adaptive-icon>-Tag zum Angeben ihres Symbols verwendet und die PackageManager-Methoden zum Abrufen von Symbolen aufgerufen werden.

Wenn Geräteimplementierungen einen Standard-Launcher enthalten, der das Anpinnen von Verknüpfungen in Apps unterstützt, gilt Folgendes:

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

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

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

Wenn die Geräteimplementierungen eine Standard-Launcher-App enthalten, die Logos für die App-Symbole anzeigt, gilt Folgendes:

  • [C-5-1] MUSS die API-Methode NotificationChannel.setShowBadge() einhalten. Mit anderen Worten: Zeigen Sie eine visuelle Aufforderung für das App-Symbol an, wenn der Wert auf true festgelegt ist, und zeigen Sie kein App-Symbol-Badge-Schema an, wenn der Wert für alle Benachrichtigungskanäle der App auf false festgelegt ist.
  • Sie KÖNNEN die App-Symbol-Kennzeichen mit ihrem eigenen Kennzeichensystem überschreiben, wenn Drittanbieteranwendungen die Unterstützung des eigenen Kennzeichensystems durch die Verwendung proprietärer APIs angeben. Sie SOLLTEN jedoch die Ressourcen und Werte verwenden, die über die im SDK beschriebenen APIs für Benachrichtigungskennzeichen bereitgestellt werden, z. B. die Notification.Builder.setNumber()- und die Notification.Builder.setBadgeIconType()-API.

Wenn Geräteimplementierungen einfarbige Symbole unterstützen, gelten für diese Symbole die folgenden Anforderungen:

  • [C-6-1] MÜSSEN nur verwendet werden, wenn ein Nutzer sie explizit aktiviert (z.B. über die Einstellungen oder das Menü zur Auswahl des Hintergrunds).

3.8.2. Widgets

Android unterstützt App-Widgets von Drittanbietern, indem ein Komponententyp und eine entsprechende API und ein Lebenszyklus definiert werden, mit denen Anwendungen Endnutzern einen App-Widget zur Verfügung stellen können.

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

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

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

3.8.3. Benachrichtigungen

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

3.8.3.1. Darstellung von Benachrichtigungen

Wenn bei Geräteimplementierungen 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 nach Möglichkeit mit der Hardware der Geräteimplementierung. Wenn eine Geräteimplementierung beispielsweise einen Vibrator enthält, MÜSSEN die Vibrations-APIs korrekt implementiert sein. Wenn bei einer Geräteimplementierung die Hardware fehlt, MÜSSEN die entsprechenden APIs als No-Ops implementiert werden. Dieses Verhalten wird in Abschnitt 7 näher beschrieben.
  • [C-1-2] Alle Ressourcen (Symbole, Animationsdateien usw.), die in den APIs oder im Symbolstilhandbuch für die Status-/Systemleiste bereitgestellt werden, MÜSSEN korrekt gerendert werden. Die Benachrichtigungen können jedoch eine andere Nutzererfahrung bieten als die der Referenzimplementierung von Android Open Source.
  • [C-1-3] Sie MÜSSEN das für die APIs beschriebene Verhalten einhalten und ordnungsgemäß implementieren, um Benachrichtigungen zu aktualisieren, zu entfernen und zu gruppieren.
  • [C-1-4] MÜSSEN das vollständige Verhalten der im SDK dokumentierten NotificationChannel API angeben.
  • [C-1-5] Es MUSS eine Nutzerfunktion geben, mit der Benachrichtigungen einer bestimmten Drittanbieter-App auf Ebene jedes Kanals und App-Pakets blockiert und geändert werden können.
  • [C-1-6] MUSS Nutzern auch die Möglichkeit bieten, gelöschte Benachrichtigungskanäle anzuzeigen.
  • [C-1-7] Alle über Notification.MessagingStyle bereitgestellten Ressourcen (Bilder, Sticker, Symbole usw.) MÜSSEN zusammen mit dem Benachrichtigungstext korrekt gerendert werden, ohne dass der Nutzer etwas tun muss. Beispielsweise MÜSSEN alle Ressourcen einschließlich Symbole, die über android.app.Person bereitgestellt werden, in einer Gruppenunterhaltung angezeigt werden, die über setGroupConversation festgelegt wird.

  • [C-SR-1] Es wird EMPFOHLEN, Nutzern die Möglichkeit zu geben, die Benachrichtigungen zu steuern, die für Apps angezeigt werden, denen die Berechtigung „Benachrichtigungslistener“ gewährt wurde. Die Detaillierung MUSS so sein, dass der Nutzer für jeden Benachrichtigungs-Listener festlegen kann, welche Benachrichtigungstypen an diesen Listener weitergeleitet werden. Die Typen MÜSSEN „Unterhaltungen“, „Benachrichtigungen“, „Lautlos“ und „Wichtige fortlaufende Benachrichtigungen“ enthalten.

  • [C-SR-2] Es wird EMPFOHLEN, Nutzern die Möglichkeit zu geben, Apps anzugeben, die von der Benachrichtigung bestimmter Benachrichtigungslistener ausgeschlossen werden sollen.

  • [C-SR-3] Es wird DRINGEND empfohlen, Nutzern die Möglichkeit zu geben, die Benachrichtigungen einer bestimmten Drittanbieter-App auf Kanal- und App-Paketebene automatisch zu blockieren, nachdem der Nutzer diese Benachrichtigung mehrmals geschlossen hat.

  • MÜSSEN umfassende Benachrichtigungen unterstützen.

  • MÜSSEN einige Benachrichtigungen mit höherer Priorität als Vorabbenachrichtigungen angezeigt werden.

  • Es sollte eine Nutzerfunktion geben, mit der Benachrichtigungen pausiert werden können.

  • Sie dürfen nur die Sichtbarkeit und das Timing verwalten, zu dem Drittanbieter-Apps Nutzer über wichtige Ereignisse benachrichtigen können, um Sicherheitsrisiken wie Ablenkungen des Fahrers zu minimieren.

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

Geräteimplementierungen:

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

Wenn die Geräteimplementierungen conversation notifications unterstützen und die App die erforderlichen Daten für bubbles bereitstellt, gilt Folgendes:

  • [C-SR-5] Es wird dringend empfohlen, diese Unterhaltung als Sprechblase anzuzeigen. Die AOSP-Implementierung erfüllt diese Anforderungen mit der standardmäßigen Systemoberfläche, den Einstellungen und dem Launcher.

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

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

Push-Benachrichtigungen werden dem Nutzer unabhängig von der Oberfläche angezeigt, auf der er sich gerade befindet. Wenn Geräteimplementierungen die Funktion „Live-Anzeige“ unterstützen, gilt Folgendes:

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

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

Geräteimplementierungen:

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

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

  • [C-1-1] Der Status der Schlummerfunktion für Benachrichtigungen MUSS über die Standard-APIs wie NotificationListenerService.getSnoozedNotifications() korrekt angegeben werden.
  • [C-1-2] Nutzer müssen die Möglichkeit haben, Benachrichtigungen von jeder installierten Drittanbieter-App zu pausieren, es sei denn, sie stammen von Diensten im Hintergrund oder im Vordergrund.
3.8.3.3. „Bitte nicht stören“ / Prioritätsmodus

Wenn die Geräteimplementierungen die Funktion „Bitte nicht stören“ (auch als Prioritätsmodus bezeichnet) unterstützen, gilt Folgendes:

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

Einführung neuer Anforderungen für Android 15

3.8.3.4. Schutz vor vertraulichen Benachrichtigungen

Vertrauliche Benachrichtigungsinformationen umfassen Inhalte wie Einmalpasswörter, Einmalbestätigungscodes und ähnliche Authentifizierungs- oder Zurücksetzungscodes, die in Benachrichtigungen für Nutzer erscheinen können.

Wenn bei Geräteimplementierungen Drittanbieter-Apps Nutzer über wichtige Ereignisse benachrichtigen dürfen, gilt Folgendes:

  • [C-1-1] Es MUSS verhindert werden, dass vertrauliche Benachrichtigungsinformationen an Benachrichtigungs-Listener übergeben werden, es sei denn, der Listener-Dienst ist einer der folgenden:

    • Vom System signierte Apps mit einer uid < 10.000
    • System-UI
    • Muschel
    • Von CompanionDeviceManager festgelegte Companion-App
    • Rolle SYSTEM_AUTOMOTIVE_PROJECTION
    • Rolle SYSTEM_NOTIFICATION_INTELLIGENCE
    • HOME-Rolle

Die AOSP-Implementierung von NotificationAssistantServices ist ein Beispiel für diese Anforderungen und erfüllt sie. Ein Beispiel findest du unter android.ext.services.notification.

Ende der neuen Anforderungen

3.8.4. Assist-APIs

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

Wenn die Geräteimplementierungen die Aktion „Hilfe“ unterstützen, gilt Folgendes:

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

3.8.5. Benachrichtigungen und Toasts

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

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

  • [C-1-1] Es MUSS eine Nutzerfunktion geben, mit der die Anzeige von Benachrichtigungsfenstern durch eine App, die das Symbol TYPE_APPLICATION_OVERLAY verwendet, blockiert werden kann. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente im Benachrichtigungs-Schieberegler.

  • [C-1-2] Die Toast API MUSS verwendet werden und Toasts von Anwendungen müssen Endnutzern auf sehr auffällige Weise angezeigt werden.

3.8.6. Designs

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

Android enthält die Themenfamilien „Holo“ und „Material“ als Reihe von definierten Stilen, die App-Entwickler verwenden können, wenn sie das Aussehen und die Benutzerfreundlichkeit des Holo-Designs, wie im Android SDK definiert, nachahmen möchten.

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

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

  • [C-1-4] MUSS dynamische Farbtonpaletten generieren, wie in der AOSP-Dokumentation von Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES angegeben (siehe android.theme.customization.system_palette und android.theme.customization.theme_style).

  • [C-1-5] MÜSSEN dynamische Farbtonpaletten mithilfe von Farbthemenstilen generieren, die in der Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES-Dokumentation (siehe android.theme.customization.theme_styles) aufgeführt sind, nämlich TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD und MONOCHROMATIC.

    „Quellfarbe“ wird verwendet, um dynamische Farbtonpaletten zu generieren, wenn sie mit android.theme.customization.system_palette gesendet werden (wie in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES beschrieben).

  • [C-1-6] Der Chromawert CAM16 MUSS mindestens 5 betragen.

    • MÜSSEN über com.android.systemui.monet.ColorScheme#getSeedColors aus dem Hintergrund abgeleitet werden. Dabei stehen mehrere gültige Quellfarben zur Auswahl.

    • Es sollte der Wert 0xFF1B6EF3 verwendet werden, wenn keine der angegebenen Farben die oben genannte Anforderung an die Quellfarbe erfüllt.

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

Android unterstützt ein Variante-Design mit durchsichtigen Systemleisten, mit dem App-Entwickler den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten füllen können. Damit Entwickler in dieser Konfiguration einheitlich arbeiten können, ist es wichtig, dass der Symbolstil der Statusleiste bei verschiedenen Geräteimplementierungen beibehalten wird.

Wenn Geräteimplementierungen eine Systemstatusleiste enthalten, gilt Folgendes:

  • [C-2-1] Die Statusleistensymbole für den Systemstatus (z. B. Signalstärke und Akkustand) und die vom System ausgegebene Benachrichtigungen MÜSSEN weiß sein, es sei denn, das Symbol weist auf einen problematischen Status hin oder eine App fordert über das Flag WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS eine helle Statusleiste an.
  • [C-2-2] Bei Android-Geräten muss die Farbe der Systemstatussymbole zu Schwarz geändert werden, wenn eine App eine helle Statusleiste anfordert (weitere Informationen finden Sie unter R.style).

3.8.7. Live-Hintergründe

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

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

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

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

  • [C-1-1] MUSS das Plattform-Funktions-Flag „android.software.live_wallpaper“ melden.

3.8.8. Aktivitätswechsel

Der Upstream-Android-Quellcode enthält den Übersichtsbildschirm, eine Benutzeroberfläche auf Systemebene zum Wechseln von Aufgaben und zum Anzeigen kürzlich aufgerufener Aktivitäten und Aufgaben mit einem Thumbnail-Bild des grafischen Zustands der Anwendung zum Zeitpunkt, als der Nutzer die Anwendung zuletzt verlassen hat.

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

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

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

3.8.9. Eingabeverwaltung

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

Wenn Nutzer bei der Geräteimplementierung Eingabemethoden von Drittanbietern auf dem Gerät verwenden können, gilt Folgendes:

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

3.8.10. Mediensteuerung auf dem Sperrbildschirm

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

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

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

3.8.12. Standort

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

3.8.13. Unicode und Schriftart

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

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

  • [C-1-1] MUSS diese Emoji-Zeichen als farbiges Glyph rendern können.
  • [C-1-2] MUSS Folgendes unterstützen:
    • Roboto 2-Schriftart mit verschiedenen Stärken: „sans-serif-thin“, „sans-serif-light“, „sans-serif-medium“, „sans-serif-black“, „sans-serif-condensed“ und „sans-serif-condensed-light“ für die auf dem Gerät verfügbaren Sprachen.
    • Vollständige Unicode 7.0-Abdeckung für lateinische, griechische und kyrillische Schrift, einschließlich der Bereiche „Latin Extended A“, „Latin Extended B“, „Latin Extended C“ und „Latin Extended D“ sowie aller Schriftzeichen im Block „Währungssymbole“ von Unicode 7.0.
  • [C-1-3] NotoColorEmoji.tff darf im System-Image NICHT entfernt oder geändert werden. Es ist zulässig, eine neue Emoji-Schriftart hinzuzufügen, um Emojis in NotoColorEmoji.tff zu überschreiben.
  • MÜSSEN die Emojis für Hauttöne und vielfältige Familien unterstützen, wie im Unicode Technical Report #51 angegeben.

Wenn Geräteimplementierungen eine IME enthalten, gilt Folgendes:

  • MÜSSEN Nutzern eine Eingabemethode für diese Emoji-Zeichen zur Verfügung stellen.

Android unterstützt das Rendern von Myanmar-Schriftarten. In Myanmar gibt es mehrere nicht Unicode-kompatible Schriftarten, die allgemein als „Zawgyi“ bezeichnet werden und zum Rendern von birmanischen Sprachen verwendet werden.

Wenn die Geräteimplementierung die Unterstützung von Birmanisch umfasst, gilt Folgendes:

  • [C-2-1] Der Text muss standardmäßig mit einer Unicode-kompatiblen Schriftart gerendert werden. Eine nicht Unicode-kompatible Schriftart darf nur dann als Standardschriftart festgelegt werden, wenn der Nutzer sie in der Sprachauswahl auswählt.
  • [C-2-2] MUSS eine Unicode-Schrift und eine nicht Unicode-konforme Schrift unterstützen, wenn eine nicht Unicode-konforme Schrift auf dem Gerät unterstützt wird. Eine nicht Unicode-konforme Schriftart darf die Unicode-Schriftart NICHT entfernen oder überschreiben.
  • [C-2-3] Text muss NUR dann mit einer nicht Unicode-kompatiblen Schriftart gerendert werden, wenn ein Sprachcode mit dem Scriptcode „Qaag“ angegeben ist (z.B. „my-Qaag“). Keine anderen ISO-Sprach- oder Regionscodes (zugewiesen, nicht zugewiesen oder reserviert) können verwendet werden, um auf eine nicht Unicode-kompatible Schriftart für Myanmar zu verweisen. App-Entwickler und Webdesigner können my-Qaag als Sprachcode angeben, wie sie es für jede andere Sprache tun würden.

3.8.14. Mehrfenstermodus

Wenn Geräteimplementierungen mehrere Aktivitäten gleichzeitig anzeigen können, gilt Folgendes:

  • [C-1-1] Müssen solche Mehrfenstermodi gemäß den Anwendungsverhalten und APIs implementieren, die in der Dokumentation zur Unterstützung des Mehrfenstermodus des Android SDK beschrieben sind, und die folgenden Anforderungen erfüllen:
  • [C-1-2] MUSS android:resizeableActivity einhalten, die von einer App in der Datei AndroidManifest.xml wie in diesem SDK beschrieben festgelegt werden.
  • [C-1-3] Der Splitscreen- oder Freiformmodus darf NICHT angeboten werden, wenn die Bildschirmhöhe weniger als 440 dp und die Bildschirmbreite weniger als 440 dp beträgt.
  • [C-1-4] Die Größe einer Aktivität darf in anderen Multifenstermodi als „Bild-im-Bild“ NICHT auf unter 220 dp verkleinert werden.
  • Geräteimplementierungen mit einer Bildschirmgröße von xlarge MÜSSEN den Freiformmodus unterstützen.

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

  • [C-2-2] Die angedockte Aktivität eines Splitscreen-Multifensters MUSS zugeschnitten werden, sollte aber einige Inhalte davon zeigen, wenn die Launcher-App das Fenster mit dem Fokus ist.
  • [C-2-3] MÜSSEN die angegebenen Werte AndroidManifestLayout_minWidth und AndroidManifestLayout_minHeight der Launcher-Anwendung des Drittanbieters einhalten und diese Werte nicht überschreiben, wenn Inhalte der angedockten Aktivität angezeigt werden.

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

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

    • Geräte mit einem anderen Wert für „Configuration.uiMode“ als UI_MODE_TYPE_TELEVISION müssen eine Mindestbreite und -höhe von 108 dp haben.
    • Geräte mit dem Konfigurationsparameter „Configuration.uiMode“, der auf UI_MODE_TYPE_TELEVISION festgelegt ist, MÜSSEN eine Mindestbreite von 240 dp und eine Mindesthöhe von 135 dp haben.

Einführung neuer Anforderungen für Android 15

Wenn Geräteimplementierungen mehrere Android-kompatible Displaybereiche umfassen und diese Bereiche für Apps verfügbar machen, gelten folgende Anforderungen:

  • [C-4-1] Der Mehrfenstermodus MUSS unterstützt werden.

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

  • [C-5-1] MUSS die richtige Version der Window Manager Extensions API-Ebene implementieren, wie unter WindowManager Erweiterungen beschrieben.

Ende der neuen Anforderungen

3.8.15. Display-Aussparung

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

Wenn Geräteimplementierungen Displayausschnitte enthalten, gelten folgende Anforderungen:

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

3.8.16. Gerätesteuerung

Android enthält die APIs ControlsProviderService und Control, mit denen Drittanbieter-Apps Gerätesteuerelemente veröffentlichen können, um Nutzern einen schnellen Überblick über den Status und Aktionen zu geben.

Gerätespezifische Anforderungen finden Sie unter 2_2_3.

3.8.17. Zwischenablage

Geräteimplementierungen:

  • [C-0-1] Es DÜRFEN KEINE Zwischenablagedaten an Komponenten, Aktivitäten, Dienste oder über eine Netzwerkverbindung gesendet werden, ohne dass der Nutzer eine explizite Aktion ausführt (z.B. eine Schaltfläche im Overlay drückt) oder eine Angabe dazu macht, dass Inhalte gesendet werden, mit Ausnahme der in 9.8.6 Inhaltserfassung und App-Suche genannten Dienste.

Wenn bei Geräteimplementierungen eine für Nutzer sichtbare Vorschau generiert wird, wenn Inhalte für ein ClipData-Element, dessen ClipData.getDescription().getExtras() android.content.extra.IS_SENSITIVE enthält, in die Zwischenablage kopiert werden, gilt Folgendes:

  • [C-1-1] Die für Nutzer sichtbare Vorschau MUSS unkenntlich gemacht werden.

Die AOSP-Referenzimplementierung erfüllt diese Anforderungen an die Zwischenablage.

3.9. Geräteverwaltung

Einführung neuer Anforderungen für Android 15

Android bietet Funktionen, die es sicherheitsbewussten Device Policy Controller-Anwendungen ermöglichen, über die Android Device Administration API und die Device Policy Manager APIs Geräteverwaltungsfunktionen auf Systemebene auszuführen, z. B. Passwortrichtlinien durchzusetzen oder das Gerät per Fernzugriff zu löschen.

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

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

Ende der neuen Anforderungen

3.9.1. Gerätebereitstellung

3.9.1.1. Geräteeigentümer-Bereitstellung

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

  • [C-1-1] MUSS die Registrierung eines Device Policy Clients (DPC) als App des Geräteeigentümers unterstützen, wie unten beschrieben:
    • Wenn für die Geräteimplementierung weder Nutzer noch Nutzerdaten konfiguriert sind, gilt Folgendes:
      • [C-1-5] Die DPC-Anwendung MUSS als App des Geräteeigentümers registriert werden oder die DPC-Anwendung muss die Möglichkeit haben, zu wählen, ob sie Geräteeigentümer oder Profilinhaber werden soll, wenn das Gerät die NFC-Unterstützung (Near Field Communication) über das Feature-Flag android.hardware.nfc angibt und eine NFC-Nachricht mit einem Datensatz vom MIME-Typ MIME_TYPE_PROVISIONING_NFC empfängt.
      • [C-1-8] MUSS die Absicht ACTION_GET_PROVISIONING_MODE senden, nachdem die Geräteeigentümer-Bereitstellung ausgelöst wurde, damit die DPC-App je nach Werten von android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES auswählen kann, ob sie Geräteeigentümer oder Profilinhaber werden soll, es sei denn, aus dem Kontext geht hervor, dass nur eine gültige Option vorhanden ist.
      • [C-1-9] MUSS die Absicht ACTION_ADMIN_POLICY_COMPLIANCE an die App „Device Owner“ senden, wenn bei der Bereitstellung ein Geräteeigentümer festgelegt wird, unabhängig von der verwendeten Bereitstellungsmethode. Der Nutzer darf erst mit dem Einrichtungsassistenten fortfahren, wenn die App „Geräteeigentümer“ beendet ist.
    • Wenn die Geräteimplementierung Nutzer oder Nutzerdaten hat, gilt Folgendes:
      • [C-1-7] Es darf KEINE DPC-Anwendung mehr als App des Geräteinhabers registriert werden.

Einführung neuer Anforderungen für Android 15

  • [C-1-2] Es MUSS eine entsprechende Offenlegungsmitteilung (wie in AOSP beschrieben) angezeigt werden und die Einwilligung des Endnutzers eingeholt werden, bevor eine App als Geräteeigentümer festgelegt wird, es sei denn, das Gerät wird vor der Interaktion des Endnutzers auf dem Bildschirm programmatisch für den Demomodus für den Einzelhandel konfiguriert. Wenn Geräteimplementierungen android.software.device_admin angeben, aber auch eine proprietäre Lösung zur Geräteverwaltung enthalten und einen Mechanismus bereitstellen, um eine in ihrer Lösung konfigurierte Anwendung als „Device Owner-Äquivalent“ zum Standard-Device Owner zu präsentieren, der von den standardmäßigen Android-DevicePolicyManager APIs erkannt wird, gilt Folgendes:

  • [C-2-1] Es MUSS ein Verfahren geben, mit dem überprüft werden kann, ob die beworbene App zu einer legitimen Lösung zur Geräteverwaltung für Unternehmen gehört und in der proprietären Lösung so konfiguriert wurde, dass sie die Rechte eines „Geräteeigentümers“ hat.

  • [C-2-2] Es muss dieselbe AOSP-Offenlegung zur Einwilligung des Geräteeigentümers wie im von android.app.action.PROVISION_MANAGED_DEVICE initiierten Ablauf angezeigt werden, bevor die DPC-Anwendung als „Geräteeigentümer“ registriert wird.

  • [C-2-3] Die Einwilligung darf NICHT hartcodiert sein und die Verwendung anderer Apps des Geräteeigentümers darf NICHT verhindert werden.

Ende der neuen Anforderungen

3.9.1.2. Bereitstellung verwalteter Profile

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

Einführung neuer Anforderungen für Android 15

  • [C-1-2] Der Bereitstellungsprozess für verwaltete Profile (der Ablauf, der vom DPC mithilfe von android.app.action.PROVISION_MANAGED_PROFILE oder von der Plattform initiiert wird), der Einwilligungsbildschirm und die Nutzererfahrung MÜSSEN der AOSP-Implementierung entsprechen.

Ende der neuen Anforderungen

  • [C-1-3] MÜSSEN in den Einstellungen die folgenden Nutzeroptionen zur Verfügung stellen, um dem Nutzer anzuzeigen, wenn eine bestimmte Systemfunktion vom Device Policy Controller (DPC) deaktiviert wurde:

    • Ein einheitliches Symbol oder eine andere Nutzerfunktion (z. B. das Infosymbol von AOSP) für den Fall, dass eine bestimmte Einstellung durch einen Geräteadministrator eingeschränkt ist.
    • Eine kurze Erklärung, die der Geräteadministrator über die setShortSupportMessage angegeben hat.
    • Das Symbol der DPC-Anwendung.
  • [C-1-4] MUSS den Handler für die Absicht ACTION_PROVISIONING_SUCCESSFUL im Arbeitsprofil starten, wenn ein Profilinhaber festgelegt wird, wenn die Bereitstellung durch die Absicht android.app.action.PROVISION_MANAGED_PROFILE initiiert wird und der DPC den Handler implementiert hat.

  • [C-1-5] MUSS die ACTION_PROFILE_PROVISIONING_COMPLETE-Broadcast an den DPC des Arbeitsprofils senden, wenn die Bereitstellung durch die android.app.action.PROVISION_MANAGED_PROFILE-Intent initiiert wird.

  • [C-1-6] MUSS die Intent ACTION_GET_PROVISIONING_MODE senden, nachdem die Bereitstellung des Profilinhabers ausgelöst wurde, damit die DPC-App auswählen kann, ob sie Geräteinhaber oder Profilinhaber werden soll, es sei denn, die Bereitstellung wird durch die Intent android.app.action.PROVISION_MANAGED_PROFILE ausgelöst.

  • [C-1-7] MUSS die Intent ACTION_ADMIN_POLICY_COMPLIANCE an das Arbeitsprofil senden, wenn bei der Bereitstellung ein Profilinhaber festgelegt wird, unabhängig davon, welche Bereitstellungsmethode verwendet wird, es sei denn, die Bereitstellung wird durch die Intent android.app.action.PROVISION_MANAGED_PROFILE ausgelöst. Der Nutzer darf erst mit dem Einrichtungsassistenten fortfahren, wenn die App „Profilinhaber“ beendet ist.

  • [C-1-8] Es MUSS ein ACTION_MANAGED_PROFILE_PROVISIONED-Broadcast an den DPC des privaten Profils gesendet werden, wenn ein Profilinhaber festgelegt wurde, unabhängig von der verwendeten Bereitstellungsmethode.

3.9.2. Support für verwaltete Profile

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

  • [C-1-1] Es MÜSSEN verwaltete Profile über die android.app.admin.DevicePolicyManager-APIs unterstützt werden.
  • [C-1-2] Es darf nur ein einziges verwaltetes Profil erstellt werden.
  • [C-1-3] Es MUSS ein Symbolsymbol (ähnlich dem AOSP-Upstream-Arbeitssymbol) verwendet werden, um die verwalteten Anwendungen und Widgets sowie andere UI-Elemente mit Symbolen wie „Letzte“ und „Benachrichtigungen“ darzustellen.
  • [C-1-4] Es MUSS ein Benachrichtigungssymbol (ähnlich dem AOSP-Logo für Upstream-Arbeiten) angezeigt werden, um anzuzeigen, dass sich der Nutzer in einer Anwendung mit verwaltetem Profil befindet.
  • [C-1-5] Es MUSS ein Toast angezeigt werden, das darauf hinweist, dass sich der Nutzer im verwalteten Profil befindet, wenn das Gerät aktiviert wird (ACTION_USER_PRESENT) und die App im Vordergrund sich im verwalteten Profil befindet.
  • [C-1-6] Wenn ein verwaltetes Profil vorhanden ist, MUSS in der Intent-Auswahl eine visuelle Aufforderung angezeigt werden, damit der Nutzer den Intent vom verwalteten Profil an den Hauptnutzer oder umgekehrt weiterleiten kann, sofern dies vom Device Policy Controller aktiviert wurde.
  • [C-1-7] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN die folgenden Nutzerfunktionen sowohl für den Hauptnutzer als auch für das verwaltete Profil verfügbar sein:
    • Separate Erfassung der Akku-, Standort-, mobilen Daten- und Speichernutzung für den Hauptnutzer und das verwaltete Profil.
    • Unabhängige Verwaltung von VPN-Anwendungen, die im primären Nutzer- oder verwalteten Profil installiert sind.
    • Unabhängige Verwaltung von Anwendungen, die im primären Nutzer- oder verwalteten Profil installiert sind.
    • Unabhängige Verwaltung von Konten im primären Nutzer- oder verwalteten Profil.
  • [C-1-8] Die vorinstallierten Telefon-, Kontakt- und Messaging-Apps MÜSSEN die Möglichkeit haben, Anruferinformationen aus dem verwalteten Profil (falls vorhanden) zusammen mit denen aus dem primären Profil zu suchen und abzurufen, sofern dies vom Device Policy Controller zulässig ist.
  • [C-1-9] MUSS alle Sicherheitsanforderungen erfüllen, die für ein Gerät mit mehreren Nutzern gelten (siehe Abschnitt 9.5), auch wenn das verwaltete Profil nicht zusätzlich zum primären Nutzer gezählt wird.
  • [C-1-10] Es MUSS dafür gesorgt werden, dass die Screenshot-Daten im Arbeitsprofilspeicher gespeichert werden, wenn ein Screenshot mit einem topActivity-Fenster erstellt wird, das den Fokus hat (das Fenster, mit dem der Nutzer zuletzt unter allen Aktivitäten interagiert hat) und zu einer App im Arbeitsprofil gehört.
  • [C-1-11] Es dürfen KEINE anderen Bildschirminhalte (Systemleiste, Benachrichtigungen oder Inhalte des privaten Profils) erfasst werden, mit Ausnahme des Fenster/der Fenster der Arbeitsprofil-App, wenn ein Screenshot im Arbeitsprofil gespeichert wird. So wird sichergestellt, dass keine Daten des privaten Profils im Arbeitsprofil gespeichert werden.

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

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

3.9.3. Support für verwaltete Nutzer

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

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

Wenn bei Geräteimplementierungen android.software.device_admin deklariert und eine Nutzerfunktion auf dem Gerät bereitgestellt wird, mit der zusätzliche sekundäre Nutzer hinzugefügt werden können, gilt Folgendes:

  • [C-SR-1] Es wird EMPFOHLEN, dieselben Offenlegungen zur Einwilligung des Geräteeigentümers gemäß AOSP zu zeigen, die im Ablauf angezeigt wurden, der durch android.app.action.PROVISION_MANAGED_DEVICE initiiert wurde, bevor Konten dem neuen sekundären Nutzer hinzugefügt werden dürfen, damit Nutzer wissen, dass das Gerät verwaltet wird.

3.9.4. Rollenanforderungen für die Verwaltung von Geräterichtlinien

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

  • [C-1-1] MUSS die Rolle „Device Policy Management“ gemäß Abschnitt 9.1 unterstützen. Die Anwendung, die die Rolle zur Verwaltung von Geräterichtlinien hat, kann durch Festlegen von config_devicePolicyManagement als Paketname definiert werden. Auf den Paketnamen MUSS : und das Signaturzertifikat folgen, es sei denn, die Anwendung ist vorab geladen.

Wenn für config_devicePolicyManagement wie oben beschrieben kein Paketname definiert ist:

Wenn für config_devicePolicyManagement wie oben beschrieben ein Paketname definiert ist:

  • [C-3-1] Die Anwendung MUSS in allen Profilen eines Nutzers installiert sein.
  • [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 für config_devicePolicyManagementUpdater wie oben beschrieben ein Paketname definiert ist:

  • [C-4-1] Die App MUSS auf dem Gerät vorinstalliert sein.
  • [C-4-2] Die Anwendung MUSS einen Intent-Filter implementieren, der android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER auflöst.

3.9.5. Device Policy Resolution Framework

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

3.10. Bedienungshilfen

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

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

  • [C-1-1] Es MUSS eine Implementierung des Android-Bedienungshilfen-Frameworks wie in der SDK-Dokumentation für Bedienungshilfen-APIs beschrieben bereitgestellt werden.
  • [C-1-2] MUSS Ereignisse zur Barrierefreiheit generieren und die entsprechenden AccessibilityEvent an alle registrierten AccessibilityService-Implementierungen senden, wie im SDK dokumentiert.
  • [C-1-4] Es MUSS eine Nutzerfunktion zur Steuerung von Bedienungshilfen geben, für die AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON deklariert ist. Bei Geräteimplementierungen mit einer Navigationsleiste des Systems sollte dem Nutzer die Möglichkeit gegeben werden, diese Dienste über eine Schaltfläche in der Navigationsleiste des Systems zu steuern.

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

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

3.11. Sprachausgabe

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

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

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

  • [C-2-1] Es MUSS eine Nutzerfunktion geben, mit der Nutzer eine TTS-Engine für die Verwendung auf Systemebene auswählen können.

Einführung neuer Anforderungen für Android 15

3.12. TV Input Framework

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

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

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

Ende der neuen Anforderungen

3.13. Schnelleinstellungen

Android bietet eine UI-Komponente für die Schnelleinstellungen, die schnellen Zugriff auf häufig verwendete oder dringend benötigte Aktionen ermöglicht.

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

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

3.14. Media-UI

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

  • [C-1-2] MÜSSEN Symbole enthalten, die über getIconBitmap() oder getIconUri() und Titel, die über getTitle() abgerufen wurden, wie in MediaDescription beschrieben. Titel können gekürzt werden, um Sicherheitsvorschriften einzuhalten (z.B. Ablenkung des Fahrers).

  • [C-1-3] Das Symbol der Drittanbieter-App MUSS immer angezeigt werden, wenn Inhalte dieser Drittanbieter-App präsentiert werden.

  • [C-1-4] Der Nutzer MUSS mit der gesamten MediaBrowser-Hierarchie interagieren können. Der Zugriff auf einen Teil der Hierarchie kann eingeschränkt werden, um Sicherheitsvorschriften einzuhalten (z. B. Ablenkung des Fahrers). Es darf jedoch keine Bevorzugung aufgrund von Inhalten oder Inhaltsanbietern geben.

  • [C-1-5] DAS Doppeltippen auf KEYCODE_HEADSETHOOK oder KEYCODE_MEDIA_PLAY_PAUSE MUSS als KEYCODE_MEDIA_NEXT für MediaSession.Callback#onMediaButtonEvent betrachtet werden.

3.15. Android Instant Apps

Wenn Geräteimplementierungen Instant Apps unterstützen, MÜSSEN sie die folgenden Anforderungen erfüllen:

  • [C-1-1] Instant-Apps dürfen nur Berechtigungen gewährt werden, für die android:protectionLevel auf "instant" festgelegt ist.
  • [C-1-2] Instant-Apps dürfen NUR dann über implizite Intents mit installierten Apps interagieren, wenn eine der folgenden Bedingungen erfüllt ist:
    • Der Intent-Musterfilter der Komponente ist freigegeben und hat CATEGORY_BROWSABLE
    • Die Aktion ist eine der folgenden: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • Das Ziel wird explizit mit android:visibleToInstantApps freigegeben.
  • [C-1-3] Instant-Apps dürfen NICHT explizit mit installierten Apps interagieren, es sei denn, die Komponente wird über „android:visibleToInstantApps“ freigegeben.
  • [C-1-4] Installierte Apps DÜRFEN KEINE Details zu Instant Apps auf dem Gerät sehen, es sei denn, die Instant App stellt ausdrücklich eine Verbindung zur installierten Anwendung her.
  • Geräteimplementierungen MÜSSEN die folgenden Nutzerfunktionen für die Interaktion mit Instant-Apps bereitstellen. Das AOSP erfüllt die Anforderungen mit der Standard-Benutzeroberfläche, den Standardeinstellungen und dem Standard-Launcher. Geräteimplementierungen:

    • [C-1-5] Es MUSS eine Nutzerfunktion zum Ansehen und Löschen von lokal im Cache gespeicherten Instant Apps für jedes einzelne App-Paket geben.
    • [C-1-6] Es MUSS eine dauerhafte Nutzerbenachrichtigung geben, die minimiert werden kann, während eine Instant-App im Vordergrund ausgeführt wird. Diese Nutzerbenachrichtigung MUSS darauf hinweisen, dass Instant-Apps nicht installiert werden müssen, und eine Nutzerinteraktion enthalten, die den Nutzer zum Bildschirm mit den App-Informationen in den Einstellungen weiterleitet. Bei Instant Apps, die über Webintents gestartet werden, wie durch die Verwendung eines Intents mit der Aktion „Intent.ACTION_VIEW“ und dem Schema „http“ oder „https“ definiert, sollte eine zusätzliche Nutzerfunktion dem Nutzer die Möglichkeit geben, die Instant App nicht zu starten und den zugehörigen Link mit dem konfigurierten Webbrowser zu starten, sofern auf dem Gerät ein Browser verfügbar ist.
    • [C-1-7] Es MUSS möglich sein, über die Funktion „Letzte Aktivitäten“ auf laufende Instant Apps zuzugreifen, wenn diese Funktion auf dem Gerät verfügbar ist.
  • [C-1-8] Sie MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für die im SDK aufgeführten Intents vorab laden und die Intents für Instant Apps sichtbar machen.

3.16. Kopplung von Begleitgeräten

Android unterstützt die Kopplung von Zusatzgeräten, um die Verknüpfung mit Zusatzgeräten effektiver zu verwalten. Außerdem bietet die CompanionDeviceManager API Apps Zugriff auf diese Funktion.

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

Einführung neuer Anforderungen für Android 15

  • [C-1-3] Es MUSS eine Funktion geben, mit der Nutzer ein verbundenes Gerät auswählen und bestätigen können, dass es vorhanden und funktionsfähig ist.Dabei MUSS dieselbe Meldung wie in AOSP verwendet werden, ohne Ergänzungen oder Änderungen.

Ende der neuen Anforderungen

3:17. Ressourcenintensive Apps

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

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

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

  • [C-1-1] Das von Apps festgelegte Attribut cantSaveState MUSS ignoriert werden und das App-Verhalten darf nicht auf der Grundlage dieses Attributs geändert werden.

3.18. Kontakte

Android enthält Contacts Provider-APIs, mit denen Anwendungen die auf dem Gerät gespeicherten Kontaktdaten verwalten können. Kontaktdaten, die direkt auf dem Gerät eingegeben werden, werden in der Regel mit einem Webdienst synchronisiert. Die Daten können aber auch nur lokal auf dem Gerät gespeichert sein. Kontakte, die nur auf dem Gerät gespeichert sind, werden als lokale Kontakte bezeichnet.

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

Standardlokales Konto: Ein Konto für Rohkontakte, die nur auf dem Gerät gespeichert und nicht mit einem Konto in AccountManager verknüpft sind. Sie werden mit Null-Werten für die Spalten ACCOUNT_NAME und ACCOUNT_TYPE erstellt.

Benutzerdefiniertes lokales Konto: Ein Konto für Rohkontakte, die nur auf dem Gerät gespeichert und nicht mit einem Konto im AccountManager verknüpft sind. Sie werden mit mindestens einem nicht nullwertigen Wert für die Spalten ACCOUNT_NAME und ACCOUNT_TYPE erstellt.

Geräteimplementierungen:

  • [C-SR-1] Es wird DRINGEND empfohlen, keine benutzerdefinierten lokalen Konten zu erstellen.

Wenn für die Geräteimplementierung ein benutzerdefiniertes lokales Konto verwendet wird:

  • [C-1-1] Die ACCOUNT_NAME des benutzerdefinierten lokalen Kontos MUSS bis ContactsContract.RawContacts.getLocalAccountName zurückgegeben werden.
  • [C-1-2] Die ACCOUNT_TYPE des benutzerdefinierten lokalen Kontos MUSS bis ContactsContract.RawContacts.getLocalAccountType zurückgegeben werden.
  • [C-1-3] Raw-Kontakte, die von Drittanbieter-Apps mit dem Standardlokalkonto eingefügt werden (d.h. durch Festlegen von Nullwerten für ACCOUNT_NAME und ACCOUNT_TYPE), MÜSSEN in das benutzerdefinierte lokale Konto eingefügt werden.
  • [C-1-4] Rohkontakte, die in das benutzerdefinierte lokale Konto eingefügt wurden, dürfen nicht entfernt werden, wenn Konten hinzugefügt oder entfernt werden.
  • [C-1-5] Löschvorgänge, die für das benutzerdefinierte lokale Konto ausgeführt werden, MÜSSEN dazu führen, dass Rohkontakte sofort gelöscht werden (als wäre der Parameter CALLER_IS_SYNCADAPTER auf „wahr“ gesetzt), auch wenn der Parameter CALLER\_IS\_SYNCADAPTER auf „falsch“ gesetzt oder nicht angegeben wurde.

Einführung neuer Anforderungen für Android 15

3.19. Spracheinstellungen

Geräteimplementierungen:

  • [C-0-1] Es darf KEINE Optionen für Nutzer geben, die eine geschlechtsspezifische Sprache für Sprachen auswählen, die keine geschlechtsspezifischen Übersetzungen unterstützen. Weitere Informationen finden Sie unter Ressourcen zur Grammatik.

Ende der neuen Anforderungen

4. Kompatibilität von Anwendungspaketen

Geräteimplementierungen:

  • [C-0-1] MUSS in der Lage sein, Android-„.apk“-Dateien zu installieren und auszuführen, die mit dem im offiziellen Android SDK enthaltenen Tool „aapt“ generiert wurden.

    • Da die oben genannte Anforderung eine Herausforderung darstellen kann, wird für Geräteimplementierungen das Paketverwaltungssystem der AOSP-Referenzimplementierung EMPFOHLEN.
  • [C-0-2] MUSS die Überprüfung von „.apk“-Dateien mit dem APK-Signaturschema 3.1, dem APK-Signaturschema 3, dem APK-Signaturschema 2 und der JAR-Signatur unterstützen.

  • [C-0-3] Die Dateiformate .apk, Android-Manifest, Dalvik-Bytecode und RenderScript-Bytecode dürfen NICHT so erweitert werden, dass die Installation und Ausführung dieser Dateien auf anderen kompatiblen Geräten verhindert wird.

  • [C-0-4] Es darf KEINE Apps außer dem aktuellen „installer of record“ für das Paket geben, die die App ohne Nutzerbestätigung im Hintergrund deinstallieren dürfen, wie im SDK für die Berechtigung DELETE_PACKAGE dokumentiert. Die einzigen Ausnahmen sind die App zur Überprüfung von Systempaketen, die den Intent PACKAGE_NEEDS_VERIFICATION verarbeitet, und die App zum Speichermanager, die den Intent ACTION_MANAGE_STORAGE verarbeitet.

  • [C-0-5] Es MUSS eine Aktivität geben, die den Intent android.settings.MANAGE_UNKNOWN_APP_SOURCES verarbeitet.

  • [C-0-6] Es dürfen KEINE App-Pakete aus unbekannten Quellen installiert werden, es sei denn, die App, die die Installation anfordert, erfüllt alle folgenden Anforderungen:

    • Es MUSS die Berechtigung REQUEST_INSTALL_PACKAGES angeben oder der Wert für android:targetSdkVersion muss 24 oder niedriger sein.
    • Der Nutzer MUSS die Berechtigung erteilt haben, Apps aus unbekannten Quellen zu installieren.
  • Es sollte Nutzern ermöglicht werden, die Berechtigung zum Installieren von Apps aus unbekannten Quellen pro Anwendung zu gewähren oder zu widerrufen. Es ist jedoch zulässig, diese Funktion als No-Op zu implementieren und RESULT_CANCELED für startActivityForResult() zurückzugeben, wenn Nutzer diese Wahlmöglichkeit nicht haben sollen. Auch in solchen Fällen sollte der Nutzer jedoch darüber informiert werden, warum keine solche Auswahl angezeigt wird.

  • [C-0-7] Es MUSS ein Warndialogfeld mit dem Warnstring angezeigt werden, der dem Nutzer über die System-API PackageManager.setHarmfulAppWarning zur Verfügung gestellt wird, bevor eine Aktivität in einer Anwendung gestartet wird, die von derselben System-API PackageManager.setHarmfulAppWarning als potenziell schädlich gekennzeichnet wurde.

  • SOLLTE Nutzern die Möglichkeit bieten, im Warndialogfeld eine Anwendung zu deinstallieren oder zu starten.

  • [C-0-8] Es MUSS Unterstützung für das inkrementelle Dateisystem gemäß dieser Dokumentation implementiert werden.

  • [C-0-9] MUSS die Überprüfung von APK-Dateien mit dem APK-Signaturschema v4 und dem APK-Signaturschema v4.1 unterstützen.

5. Multimedia-Kompatibilität

Geräteimplementierungen:

  • [C-0-1] MUSS die in Abschnitt 5.1 definierten Medienformate, Encoder, Dekoder, Dateitypen und Containerformate für jeden von MediaCodecList deklarierten Codec unterstützen.
  • [C-0-2] MUSS die Unterstützung der Encoder und Decoder angeben und melden, die Drittanbieter-Apps über MediaCodecList zur Verfügung stehen.
  • [C-0-3] MUSS alle Formate, die es codieren kann, korrekt decodieren und für Drittanbieter-Apps verfügbar machen. Dazu gehören alle Bitstreams, die von den Encodern generiert werden, und die Profile, die in CamcorderProfile gemeldet werden.

Geräteimplementierungen:

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

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

Weder Google noch die Open Handset Alliance geben eine Zusicherung dafür, dass diese Codecs frei von Patenten Dritter sind. Nutzer, die diesen Quellcode in Hardware- oder Softwareprodukten verwenden möchten, werden darauf hingewiesen, dass für die Implementierung dieses Codes, einschließlich in Open-Source-Software oder Shareware, möglicherweise Patentlizenzen der entsprechenden Patentinhaber 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 sie für Drittanbieter-Apps verfügbar machen:

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

Alle Audioencoder MÜSSEN Folgendes unterstützen:

5.1.2. Audiodekodierung

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

Wenn die Geräteimplementierung die Unterstützung der Funktion android.hardware.audio.output angibt, muss sie die Dekodierung der folgenden Audioformate unterstützen:

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

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

  • [C-2-1] Die Dekodierung MUSS ohne Downmix erfolgen (z.B. muss ein 5.0-AAC-Stream in fünf PCM-Kanäle decodiert werden, ein 5.1-AAC-Stream in sechs PCM-Kanäle).
  • [C-2-2] Die Metadaten für den dynamischen Bereich MÜSSEN gemäß der Definition in „Dynamic Range Control (DRC)“ in ISO/IEC 14496-3 und den android.media.MediaFormat-DRC-Schlüsseln für die Konfiguration des dynamisch bereichsbezogenen Verhaltens des Audiodekoders sein. Die AAC-DRC-Schlüssel wurden in API 21 eingeführt und sind: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL und KEY_AAC_ENCODED_TARGET_LEVEL.
  • [C-SR-1] Es wird DRINGEND empfohlen, dass alle AAC-Audiodekoder die Anforderungen C-2-1 und C-2-2 oben erfüllen.

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

  • [C-3-1] Lautstärke- und DRC-Metadaten MÜSSEN gemäß dem MPEG-D DRC Dynamic Range Control Profile Level 1 interpretiert und angewendet werden.
  • [C-3-2] Der Decoder MUSS sich gemäß der Konfiguration verhalten, die mit den folgenden android.media.MediaFormat-Schlüsseln festgelegt wurde: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL und KEY_AAC_DRC_EFFECT_TYPE.

MPEG-4 AAC-, HE AAC- und HE AACv2-Profil-Decoder:

  • KANN die Lautstärke- und Dynamikbereichssteuerung mit dem Dynamic Range Control Profile (ISO/IEC 23003-4) unterstützen.

Wenn ISO/IEC 23003-4 unterstützt wird und sowohl ISO/IEC 23003-4- als auch ISO/IEC 14496-3-Metadaten in einem decodierten Bitstream vorhanden sind, gilt Folgendes:

  • Die Metadaten nach ISO/IEC 23003-4 MÜSSEN Vorrang haben.

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

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

  • [C-7-1] MUSS von der Anwendung, die die Dekodierung verwendet, mit dem Schlüssel KEY_MAX_OUTPUT_CHANNEL_COUNT konfiguriert werden können, um festzulegen, ob die Inhalte zu Stereo heruntergemischt (bei einem Wert von 2) oder mit der nativen Anzahl von Kanälen ausgegeben werden (bei einem Wert, der dieser Zahl entspricht oder höher ist). Bei einem Wert von 6 oder höher wird ein Decoder beispielsweise so konfiguriert, dass er bei 5.1-Inhalten sechs Kanäle ausgibt.
  • [C-7-2] Bei der Dekodierung MUSS der Dekoder die verwendete Kanalmaske im Ausgabeformat mit dem Schlüssel KEY_CHANNEL_MASK und den android.media.AudioFormat-Konstanten angeben (Beispiel: CHANNEL_OUT_5POINT1).

Wenn Geräteimplementierungen andere Audiodekoder als den standardmäßigen AAC-Audiodekoder unterstützen und Mehrkanal-Audio (d.h. mehr als zwei Kanäle) ausgeben können, wenn komprimierte Mehrkanalinhalte bereitgestellt werden, gilt Folgendes:

  • [C-SR-2] Es wird EMPFOHLEN, dass der Decoder von der Anwendung mithilfe der Dekodierung mit dem Schlüssel KEY_MAX_OUTPUT_CHANNEL_COUNT konfiguriert werden kann, um zu steuern, ob die Inhalte zu Stereo heruntergemischt (bei einem Wert von 2) oder mit der nativen Anzahl von Kanälen ausgegeben werden (bei einem Wert, der dieser Zahl entspricht oder höher ist). Bei einem Wert von 6 oder höher wird ein Decoder beispielsweise so konfiguriert, dass er bei 5.1-Inhalten sechs Kanäle ausgibt.
  • [C-SR-3] Beim Dekodieren sollte der Decoder EMPFINDLICH die Kanalmaske, die für das Ausgabeformat verwendet wird, mit dem Schlüssel KEY_CHANNEL_MASK angeben. Dabei sollten die Konstanten von android.media.AudioFormat verwendet werden (Beispiel: CHANNEL_OUT_5POINT1).

5.1.3. Audio-Codecs – Details

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

5.1.4. Bildcodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Bildcodecs

Geräteimplementierungen MÜSSEN die folgenden Bildcodierungen unterstützen:

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP
  • [C-0-4] AVIF
    • Die Geräte müssen BITRATE_MODE_CQ und das Baseline-Profil unterstützen.

Wenn Geräteimplementierungen die HEIC-Codierung über android.media.MediaCodec für den Medientyp MIMETYPE_IMAGE_ANDROID_HEIC unterstützen, gilt Folgendes:

  • [C-1-1] Es MUSS ein hardwaregestützter HEVC-Encoder-Codec bereitgestellt werden, der den Modus zur Bitratesteuerung, das Profil HEVCProfileMainStill und eine Framegröße von 512 × 512 Pixeln unterstützt.BITRATE_MODE_CQ

5.1.5. Bild-Decodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Bildcodecs

Geräteimplementierungen MÜSSEN die Dekodierung der folgenden Bildcodierungen unterstützen:

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Roh
  • [C-0-7] AVIF (Baseline-Profil)

Wenn die Geräteimplementierungen die HEVC-Videodekodierung unterstützen, gilt Folgendes:

  • [C-1-1] Die HEIF-Bilddekodierung (HEIC) MUSS unterstützt werden.

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

  • [C-2-1] MUSS die Ausgabe eines 8‑Bit-äquivalenten Formats unterstützen, wenn dies von der Anwendung angefordert wird, z. B. über die ARGB_8888-Konfiguration von android.graphics.Bitmap.

5.1.6. Details zu Bildcodecs

Format/Codec Details Unterstützte Dateitypen/Containerformate
JPEG Basispreis + progressiver Preis JPEG (JPG)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
Raw ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF Bild, Bildsammlung, Bildsequenz HEIF (.heif), HEIC (.heic)
AVIF (Baseline-Profil) Baseline-Profil für Bilder, Bildsammlungen und Bildsequenzen HEIF-Container (.avif)

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

  • [C-1-1] MUSS das flexible Farbformat YUV420 8:8:8 (COLOR_FormatYUV420Flexible) bis CodecCapabilities unterstützen.

  • [C-SR-1] Es wird dringend empfohlen, das RGB888-Farbformat für den Eingabe-Surface-Modus zu unterstützen.

  • [C-1-3] Es MUSS mindestens eines der planaren oder semiplanaren YUV420 8:8:8-Farbformate unterstützt werden: COLOR_FormatYUV420PackedPlanar (entspricht COLOR_FormatYUV420Planar) oder COLOR_FormatYUV420PackedSemiPlanar (entspricht COLOR_FormatYUV420SemiPlanar). Es wird DRINGEND empfohlen, beide zu unterstützen.

5.1.7. Video-Codecs

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

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

  • [C-1-1] Videocodecs MÜSSEN Ausgabe- und Eingabe-Bytebuffergrößen unterstützen, die den größten möglichen komprimierten und unkomprimierten Frame gemäß Standard und Konfiguration aufnehmen, aber auch nicht überbelegen.

  • [C-1-2] Videoencoder und ‑decoder MÜSSEN flexible YUV420 8:8:8-Farbformate (COLOR_FormatYUV420Flexible) bis CodecCapabilities unterstützen.

  • [C-1-3] Videoencoder und ‑decoder MÜSSEN mindestens ein planares oder semiplanares YUV420 8:8:8-Farbformat unterstützen: COLOR_FormatYUV420PackedPlanar (entspricht COLOR_FormatYUV420Planar) oder COLOR_FormatYUV420PackedSemiPlanar (entspricht COLOR_FormatYUV420SemiPlanar). Wir EMPFEHLEN dringend, beide zu unterstützen.

  • [C-SR-1] Videoencoder und ‑decoder sollten mindestens eines der hardwareoptimierten planaren oder semiplanaren YUV420 8:8:8-Farbformate (YV12, NV12, NV21 oder ein entsprechendes vom Anbieter optimiertes Format) unterstützen.

  • [C-1-5] Videodekoder, die ein Format mit hoher Bittiefe (mehr als 9 Bit pro Kanal) unterstützen, MÜSSEN die Ausgabe eines 8‑Bit-äquivalenten Formats unterstützen, wenn dies von der Anwendung angefordert wird. Dies MUSS durch die Unterstützung eines YUV420 8:8:8-Farbformats über android.media.MediaCodecInfo widergespiegelt werden.

Wenn die Geräteimplementierung die Unterstützung von HDR-Profilen über Display.HdrCapabilities angibt, gilt Folgendes:

  • [C-2-1] MUSS das Parsen und die Verarbeitung statischer HDR-Metadaten unterstützen.

Wenn Geräteimplementierungen die Unterstützung von Zwischenaktualisierungen über FEATURE_IntraRefresh in der Klasse MediaCodecInfo.CodecCapabilities angeben, gilt Folgendes:

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

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

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

5.1.8. Liste der Video-Codecs

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

5.1.9. Medien-Codec-Sicherheit

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

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

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

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

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

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

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

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

5.1.10. Medien-Codec-Charakterisierung

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

  • [C-1-1] Es MÜSSEN korrekte Werte für die Medien-Codec-Charakterisierung über die MediaCodecInfo API zurückgegeben werden.

Insbesondere

  • [C-1-2] Codecs mit Namen, die mit „OMX“ beginnen. MÜSSEN die OMX APIs verwenden und Namen haben, die den OMX IL-Namenskonventionen entsprechen.
  • [C-1-3] Codecs mit Namen, die mit „c2.“ beginnen Sie MÜSSEN die Codec 2.0 API verwenden und Namen haben, die den Codec 2.0-Richtlinien für Android entsprechen.
  • [C-1-4] Codecs mit Namen, die mit „OMX.google.“ oder „c2.android.“ beginnen Darf NICHT als Anbieter- oder Hardwarebeschleunigung gekennzeichnet sein.
  • [C-1-5] Codecs, die in einem Codec-Prozess (Anbieter- oder System) ausgeführt werden und Zugriff auf andere Hardwaretreiber als Speicherallokatoren und ‑mapper haben, DÜRFEN NICHT als reine Software bezeichnet werden.
  • [C-1-6] Codecs, die nicht im Android Open Source Project enthalten sind oder nicht auf dem Quellcode dieses Projekts basieren, MÜSSEN als Anbieter gekennzeichnet sein.
  • [C-1-7] Codecs, die die Hardwarebeschleunigung nutzen, MÜSSEN als hardwarebeschleunigt gekennzeichnet sein.
  • [C-1-8] Codec-Namen DÜRFEN NICHT irreführend sein. Beispielsweise MÜSSEN Codecs mit dem Namen „decoders“ die Dekodierung unterstützen und Codecs mit dem Namen „encoders“ die Codierung. Codecs mit Namen, die Medienformate enthalten, MÜSSEN diese Formate unterstützen.

Wenn die Geräteimplementierungen Videocodecs unterstützen:

  • [C-2-1] Alle Videocodecs MÜSSEN Daten zur erreichbaren Framerate für die folgenden Größen veröffentlichen, sofern vom Codec unterstützt:
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p UHD
Videoauflösung
  • 176 × 144 Pixel (H263, MPEG2, MPEG4)
  • 352 × 288 Pixel (MPEG4-Encoder, H263, MPEG2)
  • 320 × 180 Pixel (VP8, VP8)
  • 320 × 240 Pixel (andere)
  • 704 x 576 Pixel (H263)
  • 640 × 360 px (VP8, VP9)
  • 640 x 480 Pixel (MPEG4-Encoder)
  • 720 × 480 Pixel (andere, AV1)
  • 1408 × 1152 Pixel (H263)
  • 1280 × 720 Pixel (Sonstiges, AV1)
1920 x 1080 Pixel (außer MPEG4, AV1) 3840 × 2160 Pixel (HEVC, VP9, AV1)
  • [C-2-2] Für Videocodecs, die als hardwarebeschleunigt gekennzeichnet sind, MÜSSEN Informationen zu Leistungspunkten veröffentlicht werden. Sie MÜSSEN alle unterstützten Standard-Leistungspunkte (in der PerformancePoint API aufgeführt) auflisten, es sei denn, sie werden von einem anderen unterstützten Standard-Leistungspunkt abgedeckt.
  • Außerdem sollten sie erweiterte Leistungspunkte veröffentlichen, wenn sie eine andere als die aufgeführten Standardoptionen für eine nachhaltige Videoleistung unterstützen.

5.2. Videocodierung

Wenn Geräteimplementierungen einen Videoencoder unterstützen und für Drittanbieter-Apps verfügbar machen und
MediaFormat.KEY_BITRATE_MODE auf BITRATE_MODE_VBR festlegen, damit der Encoder im Modus mit variabler Bitrate arbeitet, gilt für die codierte Bitrate Folgendes, sofern sich dies nicht auf die Mindestqualität auswirkt :

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

Wenn Geräteimplementierungen einen Videoencoder unterstützen und für Drittanbieter-Apps verfügbar machen und die MediaFormat.KEY_BITRATE_MODE auf BITRATE_MODE_CBR festlegen, damit der Encoder im Modus mit konstanter Bitrate arbeitet, gilt für die codierte Bitrate Folgendes:

  • [C-SR-2] Die Bitrate darf in einem gleitenden Fenster von 1 Sekunde NICHT um mehr als 15% über der Zielbitrate liegen.

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

  • [C-1-1] MUSS mindestens einen der Videoencoder VP8 oder H.264 unterstützen und für Drittanbieteranwendungen verfügbar machen.
  • SOLLTE sowohl VP8- als auch H.264-Videoencoder unterstützen und diese für Drittanbieteranwendungen verfügbar machen.

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

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

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

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

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

  • [C-4-1] Alle hardwarebeschleunigten Video- und Bildencoder MÜSSEN die Codierung von Frames von den Hardwarekameras unterstützen.
  • MÜSSEN das Codieren von Frames von der Hardwarekamera(s) über alle Video- oder Bildencoder unterstützen.

Wenn Geräteimplementierungen eine HDR-Codierung bieten, müssen sie:

  • [C-SR-1] Es wird DRINGEND empfohlen, ein Plug-in für die nahtlose Transcodierungs-API bereitzustellen, um von HDR- in SDR-Format zu konvertieren.

5.2.1. H.263

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

  • [C-1-1] MUSS die QCIF-Auflösung (176 × 144) mit dem Basisprofil der Stufe 45 unterstützen. Die SQCIF-Auflösung ist optional.

5.2.2. H.264

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

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

Wenn Geräteimplementierungen über die Media APIs die Unterstützung der H.264-Codierung für Videos mit einer Auflösung von 720p oder 1080p melden, gilt Folgendes:

  • [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
Videoauflösung 320 × 240 px 720 x 480 px 1.280 × 720 Pixel 1920 × 1080 Pixel
Video-Framerate 20 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 384 kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

5.2.3. VP8

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

  • [C-1-1] MUSS die SD-Videocodierungsprofile unterstützen.
  • MÜSSEN die folgenden HD-Videocodierungsprofile (High Definition) unterstützen.
  • [C-1-2] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
  • MÜSSEN einen Hardware-VP8-Codec bereitstellen, der den Anforderungen an die RTC-Hardwarecodierung des WebM-Projekts entspricht, um eine akzeptable Qualität von Webvideostreaming und Videokonferenzdiensten zu gewährleisten.

Wenn Geräteimplementierungen über die Media APIs die Unterstützung der VP8-Codierung für Videos mit einer Auflösung von 720p oder 1080p melden, gilt Folgendes:

  • [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
Videoauflösung 320 × 180 px 640 x 360 px 1.280 × 720 Pixel 1920 × 1080 Pixel
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 800 kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

5.2.4. VP9

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

  • [C-1-2] MUSS Profil 0 Level 3 unterstützen.
  • [C-1-1] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
  • [C-1-3] MÜSSEN CodecPrivate-Daten generieren.
  • MÜSSEN die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
  • [C-SR-1] Es wird DRINGEND empfohlen, die in der folgenden Tabelle aufgeführten HD-Decodierungsprofile zu unterstützen, wenn ein Hardware-Encoder vorhanden ist.
SD HD 720p HD 1080p UHD
Videoauflösung 720 x 480 px 1.280 × 720 Pixel 1920 × 1080 Pixel 3840 x 2160 px
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Wenn in der Geräteimplementierung angegeben wird, dass Profil 2 oder Profil 3 über die Media APIs unterstützt wird:

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

5.2.5. H.265

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

  • [C-1-1] MUSS das Hauptprofil der Stufe 3 mit einer Auflösung von bis zu 512 x 512 unterstützen.
  • [C-SR-1] Es wird DRINGEND empfohlen, das SD-Profil 720 × 480 und die HD-Codierungsprofile wie in der folgenden Tabelle angegeben zu unterstützen, wenn ein Hardware-Encoder vorhanden ist.
SD HD 720p HD 1080p UHD
Videoauflösung 720 x 480 px 1.280 × 720 Pixel 1920 × 1080 Pixel 3840 x 2160 px
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

5.2.6. AV1

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

  • [C-1-1] MUSS das Hauptprofil unterstützen, einschließlich 8‑Bit- und 10‑Bit-Inhalten.
  • [C-1-2] MÜSSEN Leistungsdaten veröffentlichen, d.h. Leistungsdaten über die APIs getSupportedFrameRatesFor() oder getSupportedPerformancePoints() für die in der folgenden Tabelle aufgeführten unterstützten Auflösungen melden.

  • [C-1-3] MÜSSEN HDR-Metadaten akzeptieren und an den Bitstream ausgeben

Wenn der AV1-Encoder hardwarebeschleunigt ist, gilt Folgendes:

  • [C-2-1] MUSS das Codierungsprofil HD1080p aus der folgenden Tabelle unterstützen:
SD HD 720p HD 1080p UHD
Videoauflösung 720 x 480 px 1.280 × 720 Pixel 1920 × 1080 Pixel 3840 x 2160 px
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 5 Mbit/s 8 Mbit/s 16 Mbit/s 50 Mbit/s

5.3. Videodekodierung

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

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

5.3.1. MPEG-2

Wenn Geräteimplementierungen MPEG-2-Decoder unterstützen, gilt Folgendes:

  • [C-1-1] MUSS das Hauptprofil auf hoher Ebene unterstützen.

5.3.2. H.263

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

  • [C-1-1] MUSS das Basisprofil der Ebene 30 (CIF-, QCIF- und SQCIF-Auflösungen bei 30 fps und 384 kbit/s) und der Ebene 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-Decodern gilt Folgendes:

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

5.3.4. H.264

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

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

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

  • [C-2-1] MUSS die Video-Decodierungsprofile für HD 720p in der folgenden Tabelle unterstützen.
  • [C-2-2] MUSS die Video-Decodierungsprofile für HD 1080p in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
Videoauflösung 320 × 240 px 720 x 480 px 1.280 × 720 Pixel 1920 × 1080 Pixel
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps 60 fps 30 fps (60 fpsFernseher)
Video-Bitrate 800 kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

5.3.5. H.265 (HEVC)

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

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

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

  • [C-2-1] Geräteimplementierungen MÜSSEN mindestens eine von H.265 oder VP9-Decodierung von 720p-, 1080p- und UHD-Profilen unterstützen.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p UHD
Videoauflösung 352 × 288 px 720 x 480 px 1.280 × 720 Pixel 1920 × 1080 Pixel 3840 x 2160 px
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps 30/60 fps (60 fpsFernseher mit H.265-Hardwaredekodierung) 60 fps
Video-Bitrate 600 Kbit/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

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

  • [C-3-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR-Metadaten aus 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 Bildschirm des Geräts oder über einen Standard-Videoausgang (z.B. HDMI).

5.3.6. VP8

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

  • [C-1-1] MUSS die SD-Dekodierungsprofile in der folgenden Tabelle unterstützen.
  • Es sollte ein Hardware-VP8-Codec verwendet werden, der die Anforderungen erfüllt.
  • MÜSSEN die HD-Dekodierungsprofile in der folgenden Tabelle unterstützen.

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

  • [C-2-1] Geräteimplementierungen MÜSSEN die 720p-Profile in der folgenden Tabelle unterstützen.
  • [C-2-2] Geräteimplementierungen MÜSSEN die 1080p-Profile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
Videoauflösung 320 × 180 px 640 x 360 px 1.280 × 720 Pixel 1920 × 1080 Pixel
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps 30 fps (60 fpsFernseher) 30 (60 fpsFernseher)
Video-Bitrate 800 kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

5.3.7. VP9

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

  • [C-1-1] MUSS die SD-Video-Dekodierungsprofile unterstützen, die in der folgenden Tabelle aufgeführt sind.
  • MÜSSEN die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.

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

  • [C-2-1] MUSS die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.

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

  • [C-3-1] Geräteimplementierungen MÜSSEN mindestens eine von VP9 oder H.265-Decodierung der 720p-, 1080p- und UHD-Profile unterstützen.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p UHD
Videoauflösung 320 × 180 px 640 x 360 px 1.280 × 720 Pixel 1920 × 1080 Pixel 3840 x 2160 px
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps 30 fps (60 fpsFernseher mit VP9-Hardware-Decodierung) 60 fps
Video-Bitrate 600 Kbit/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Wenn Geräteimplementierungen VP9Profile2 oder VP9Profile3 über die Medien-APIs 'CodecProfileLevel' unterstützen:

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

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

  • [C-4-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR-Metadaten (KEY_HDR_STATIC_INFO für alle HDR-Profile sowie KEY_HDR10_PLUS_INFO für HDR10Plus-Profile) von der Anwendung akzeptieren. Außerdem MÜSSEN sie das Extrahieren und Ausgeben der erforderlichen HDR-Metadaten aus dem Bitstream und/oder Container unterstützen.
  • [C-4-2] HDR-Inhalte MÜSSEN auf dem Display des Geräts oder über einen Standard-Videoausgang (z.B. HDMI).

5.3.8. Dolby Vision

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

  • [C-1-1] Es MUSS ein Dolby Vision-fähiger Extractor bereitgestellt werden.

Einführung neuer Anforderungen für Android 15

  • [C-1-2] Dolby Vision-Inhalte MÜSSEN entweder auf dem Display des Geräts oder auf einem externen Display korrekt angezeigt werden, das über einen Standard-Videoausgang (z.B. HDMI).

Ende der neuen Anforderungen

  • [C-1-3] Die Track-ID der rückwärtskompatiblen Basisebenen (falls vorhanden) MUSS mit der Track-ID der kombinierten Dolby Vision-Ebene übereinstimmen.

5.3.9. AV1

Wenn Geräteimplementierungen den AV1-Codec unterstützen und für Drittanbieteranwendungen verfügbar machen, gilt Folgendes:

  • [C-1-1] MUSS das Hauptprofil unterstützen, einschließlich 8‑Bit- und 10‑Bit-Inhalten.

Wenn Geräteimplementierungen den AV1-Codec mit einem hardwarebeschleunigten Decoder unterstützen, gilt Folgendes:

  • [C-2-1] MUSS mindestens HD 720p-Videodekodierungsprofile aus der folgenden Tabelle decodieren können, wenn die mit der Methode Display.getSupportedModes() gemeldete Höhe mindestens 720p beträgt.
  • [C-2-2] MUSS mindestens HD 1080p-Videodekodierungsprofile aus der folgenden Tabelle decodieren können, wenn die mit der Methode Display.getSupportedModes() gemeldete Höhe mindestens 1080p beträgt.
SD HD 720p HD 1080p UHD
Videoauflösung 720 x 480 px 1.280 × 720 Pixel 1920 × 1080 Pixel 3840 x 2160 px
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 5 Mbit/s 8 Mbit/s 16 Mbit/s 50 Mbit/s

Wenn die Geräteimplementierungen das HDR-Profil über die Media APIs unterstützen, gilt Folgendes:

  • [C-3-1] MUSS das Extrahieren und Ausgeben von HDR-Metadaten aus dem Bitstream und/oder Container unterstützen.
  • [C-3-2] HDR-Inhalte MÜSSEN korrekt auf dem Display des Geräts oder über einen Standard-Videoausgang (z. B. HDMI) angezeigt werden.

5.4. Audioaufnahmen

Einige der in diesem Abschnitt beschriebenen Anforderungen sind seit Android 4.3 als „SOLLTE“ aufgeführt. In der Kompatibilitätsdefinition für zukünftige Versionen werden diese jedoch in „MUSS“ geändert. Für bestehende und neue Android-Geräte wird DRINGEND empfohlen, diese Anforderungen zu erfüllen, die als „SOLLTE“ aufgeführt sind. Andernfalls sind sie beim Upgrade auf die zukünftige Version nicht mit Android kompatibel.

5.4.1. Rohe Audioaufnahme und Mikrofoninformationen

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

  • [C-1-1] MÜSSEN die Erfassung von Roh-Audioinhalten für jeden AudioRecord- oder AAudio-EINGANGS-Stream zulassen, der erfolgreich geöffnet wurde. Mindestens die folgenden Eigenschaften MÜSSEN unterstützt werden:

  • MÜSSEN die Erfassung von Roh-Audioinhalten 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 Mikrofone auf dem Gerät
  • [C-1-2] Die Aufnahme muss mit den oben genannten Abtastraten erfolgen, ohne Upsampling.

  • [C-1-3] Es MUSS ein geeigneter Anti-Aliasing-Filter verwendet werden, wenn die oben genannten Abtastrate mit Downsampling erfasst wird.

  • MÜSSEN die Aufnahme von Roh-Audioinhalten in AM-Radio- und DVD-Qualität ermöglichen. Das bedeutet, dass die folgenden Eigenschaften erfüllt sein müssen:

    • Format: Lineare PCM, 16 Bit
    • Abtastraten: 22.050, 48.000 Hz
    • Kanäle: Stereo
  • [C-1-4] MUSS die MicrophoneInfo API einhalten und Informationen zu den verfügbaren Mikrofonen auf dem Gerät korrekt ausfüllen, auf die die Drittanbieter-Apps über die AudioManager.getMicrophones() API zugreifen können, für aktive Audioaufzeichnung mit MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED oder VOICE_PERFORMANCE. Wenn die Geräteimplementierungen die Aufnahme von Roh-Audioinhalten in AM-Radio- und DVD-Qualität ermöglichen, gilt Folgendes:

  • [C-2-1] Die Aufnahme muss ohne Upsampling bei einem Verhältnis von über 16.000:22.050 oder 44.100:48.000 erfolgen.

  • [C-2-2] Muss einen geeigneten Anti-Aliasing-Filter für jede Art von Up- oder Downsampling enthalten.

5.4.2. Für Spracherkennung aufnehmen

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

  • [C-1-1] Die android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION-Audioquelle MUSS mit einer der Abtastraten 44.100 oder 48.000 aufgenommen werden.
  • [C-1-2] Die Audioverarbeitung zur Rauschunterdrückung MUSS standardmäßig deaktiviert werden, wenn ein Audiostream von der AudioSource.VOICE_RECOGNITION-Audioquelle aufgezeichnet wird.
  • [C-1-3] Die automatische Verstärkungsregelung MUSS standardmäßig deaktiviert werden, wenn ein Audiostream von der AudioSource.VOICE_RECOGNITION-Audioquelle aufgezeichnet wird.

  • MÜSSEN im mittleren Frequenzbereich eine nahezu flache Amplitude-zu-Frequenz-Charakteristik aufweisen: insbesondere ± 3 dB von 100 Hz bis 4.000 Hz für jedes Mikrofon, das zum Aufzeichnen der Audioquelle für die Spracherkennung verwendet wird.

  • [C-SR-1] Es wird DRINGEND empfohlen, dass die Amplituden im niedrigen Frequenzbereich für jedes Mikrofon, das zur Aufnahme der Audioquelle für die Spracherkennung verwendet wird, ± 20 dB von 30 Hz bis 100 Hz im Vergleich zum mittleren Frequenzbereich betragen.

  • [C-SR-2] Es wird DRINGEND empfohlen, dass die Amplituden im Hochfrequenzbereich für jedes Mikrofon, das zur Aufnahme der Audioquelle für die Spracherkennung verwendet wird, ± 30 dB von 4.000 Hz bis 22.000 Hz im Vergleich zum Mittelfrequenzbereich betragen.

  • Die Empfindlichkeit der Audioeingabe sollte so eingestellt sein, dass eine Sinustonquelle mit 1.000 Hz, die bei einem Schalldruckpegel (SPL) von 90 dB abgespielt wird (gemessen neben dem Mikrofon), eine ideale Antwort von RMS 2.500 innerhalb eines Bereichs von 1.770 und 3.530 für 16‑Bit-Samples (oder −22,35 dB ± 3 dB Vollskala für Gleitkomma-/Doppelpräzision-Samples) für jedes Mikrofon liefert, das zum Aufzeichnen der Audioquelle für die Spracherkennung verwendet wird.

  • Der Audiostream für die Spracherkennung sollte so aufgezeichnet werden, dass die PCM-Amplitudenstufen die Änderungen des Eingangs-SPL über einen Bereich von mindestens 30 dB von −18 dB bis +12 dB bezogen auf 90 dB SPL am Mikrofon linear verfolgen.

  • Der Audiostream für die Spracherkennung sollte mit einer Gesamtharmonischen Verzerrung (Total Harmonic Distortion, THD) von weniger als 1% für 1 kHz bei einem Eingangspegel von 90 dB SPL am Mikrofon aufgezeichnet werden.

Wenn bei Geräteimplementierungen android.hardware.microphone und Technologien zur Geräuschunterdrückung (-reduzierung) deklariert werden, die für die Spracherkennung optimiert sind, gilt Folgendes:

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

5.4.3. Daten für die Weiterleitung der Wiedergabe erfassen

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

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

  • [C-1-1] Die REMOTE_SUBMIX-Audioquelle MUSS richtig implementiert sein, damit eine Anwendung, die die android.media.AudioRecord API verwendet, um von dieser Audioquelle aufzunehmen, einen Mix aller Audiostreams aufnimmt, mit folgenden Ausnahmen:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.4.4. Akustische Echounterdrückung

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

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

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

5.4.5. Gleichzeitige Aufnahme

Wenn Geräteimplementierungen android.hardware.microphone angeben,MÜSSEN sie die gleichzeitige Erfassung wie in diesem Dokument beschrieben implementieren. Im Detail:

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

5.5. Audiowiedergabe

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

5.5.1. Rohe Audiowiedergabe

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

  • [C-1-1] MÜSSEN die Wiedergabe von Roh-Audioinhalten mit den folgenden Eigenschaften zulassen:

    • Quellformate: Lineare PCM, 16-Bit, 8-Bit, Float
    • Kanäle: Mono, Stereo, gültige Mehrkanalkonfigurationen mit bis zu 8 Kanälen
    • Abtastfrequenzen (in Hz):
      • 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 bei den oben aufgeführten Kanalkonfigurationen
      • 96.000 Hz in Mono und Stereo

5.5.2. Audioeffekte

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

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

  • [C-1-1] MUSS die EFFECT_TYPE_EQUALIZER- und EFFECT_TYPE_LOUDNESS_ENHANCER-Implementierungen unterstützen, die über die AudioEffect-Unterklassen Equalizer und LoudnessEnhancer gesteuert werden.
  • [C-1-2] Die Visualizer API-Implementierung MUSS über die Klasse Visualizer steuerbar sein.
  • [C-1-3] Die EFFECT_TYPE_DYNAMICS_PROCESSING-Implementierung MUSS über die AudioEffect-Unterklasse DynamicsProcessing steuerbar sein.

Einführung neuer Anforderungen für Android 15

  • [C-1-4] MUSS Audioeffekte mit Gleitkommaeingabe und ‑ausgabe unterstützen, wenn die Effektergebnisse an die Audiopipeline des Frameworks zurückgegeben werden. Dies bezieht sich auf typische Insert- oder Aux-Effekte wie den Equalizer. Ein ähnliches Verhalten wird dringend empfohlen, wenn die Effektergebnisse für die Audiopipeline des Frameworks nicht sichtbar sind (z. B. bei der Nachbearbeitung oder bei ausgelagerten Effekten).

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

  • [C-1-5] Audioeffekte MÜSSEN mehrere Kanäle bis zur Anzahl der Mixerkanäle unterstützen, auch FCC_LIMIT genannt, wenn die Effektergebnisse an die Audiopipeline des Frameworks zurückgegeben werden. Dies bezieht sich auf typische Insert- oder Aux-Effekte, schließt aber Spezialeffekte wie Downmix-, Upmix- und Spatialisierungseffekte aus, die die Kanalanzahl ändern. Ein ähnliches Verhalten wird empfohlen, wenn die Effekte für die Audiopipeline des Frameworks nicht sichtbar sind (z. B. bei der Nachbearbeitung oder bei ausgelagerten Effekten).

Ende der neuen Anforderungen

  • MÜSSEN die EFFECT_TYPE_BASS_BOOST-, EFFECT_TYPE_ENV_REVERB-, EFFECT_TYPE_PRESET_REVERB- und EFFECT_TYPE_VIRTUALIZER-Implementierungen unterstützen, die über die AudioEffect-Unterklassen BassBoost, EnvironmentalReverb, PresetReverb und Virtualizer gesteuert werden können.
  • [C-SR-1] Es wird DRINGEND empfohlen, Effekte in Gleitkomma- und Mehrkanalformaten zu unterstützen.

5.5.3. Lautstärke der Audioausgabe

Implementierungen von Fahrzeuggeräten:

  • MÜSSEN die Audiolautstärke für jeden Audiostream separat anhand des Inhaltstyps oder der Verwendung anpassen, wie in AudioAttributes und in android.car.CarAudioManager öffentlich definiert.

5.5.4. Audio-Offload

Wenn Geräteimplementierungen die Audio-Offload-Wiedergabe unterstützen, gilt Folgendes:

  • [C-SR-1] Es wird DRINGEND empfohlen, die abgespielten Audioinhalte ohne Pause zwischen zwei Clips mit demselben Format zu kürzen, wenn dies von der AudioTrack Gapless API und dem Mediencontainer für den MediaPlayer angegeben wird.

5.6. Audiolatenz

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

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

  • Ausgabelatenz. Das Intervall zwischen dem Schreiben eines Frames mit PCM-codierten Daten durch eine Anwendung und dem Zeitpunkt, zu dem der entsprechende Ton über einen Transducer auf dem Gerät an die Umgebung abgegeben wird oder das Signal das Gerät über einen Anschluss verlässt und extern beobachtet werden kann.
  • Cold-Output-Latenz. Die Zeit zwischen dem Starten eines Ausgabestreams und der Präsentationszeit des ersten Frames basierend auf Zeitstempeln, wenn das Audioausgabesystem vor der Anfrage inaktiv und ausgeschaltet war.
  • Kontinuierliche Ausgabelatenz Die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät Audio wiedergegeben hat.
  • Eingabelatenz. Das Intervall zwischen dem Zeitpunkt, zu dem ein Ton von der Umgebung an einen On-Device-Transducer oder ein Signal über einen Anschluss an das Gerät gelangt, und dem Zeitpunkt, zu dem eine Anwendung den entsprechenden Frame mit PCM-codierten Daten liest.
  • Eingabe verloren Der anfängliche Teil eines Eingabesignals, der unbrauchbar oder nicht verfügbar ist.
  • Cold-Input-Latenz. Die Zeit zwischen dem Starten des Streams und dem Empfang des ersten gültigen Frames, wenn das Audioeingabesystem vor der Anfrage inaktiv und ausgeschaltet war.
  • kontinuierliche Eingabelatenz. Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufnimmt.
  • kontinuierliche Umlauflatenz. Die Summe aus kontinuierlicher Eingabelatenz, kontinuierlicher Ausgabelatenz und einer Pufferzeit. Die Pufferzeit gibt der App Zeit, das Signal zu verarbeiten und die Phasendifferenz zwischen Eingabe- und Ausgabestreams zu verringern.
  • OpenSL ES PCM-Puffer-Queue-API Die PCM-bezogenen OpenSL ES-APIs im Android NDK.
  • AAudio Native Audio API Die AAudio APIs im Android NDK.
  • Zeitstempel. Ein Paar, das aus einer relativen Frameposition innerhalb eines Streams und der geschätzten Zeit besteht, zu der dieser Frame die Audioverarbeitungspipeline am zugehörigen Endpunkt betritt oder verlässt. Siehe auch AudioTimestamp.
  • glitch. Eine vorübergehende Unterbrechung oder ein falscher Samplewert im Audiosignal, der in der Regel durch einen Buffer-Unterlauf bei der Ausgabe, einen Buffer-Überlauf bei der Eingabe oder eine andere Quelle digitaler oder analoger Störungen verursacht wird.
  • Mittlerer absoluter Fehler (MAD) Der Durchschnitt des absoluten Werts der Abweichungen vom Mittelwert für eine Reihe von Werten.

Einführung neuer Anforderungen für Android 15

  • Die Tap-to-Tone-Latenz (TTL), gemessen mit dem CTS Verifier, ist die Zeitspanne zwischen dem Tippen auf das Display und dem Ertönen eines durch das Tippen generierten Tons aus dem Lautsprecher. Dieser Wert ist der Durchschnitt aus fünf Messungen mit der nativen Audio-API von AAudio für die Ausgabe.

  • Die Round-Trip-Latenz (RTL), gemessen mit dem CTS-Verifier, ist die durchschnittliche kontinuierliche Latenz über fünf Messungen, gemessen über einen Loopback-Pfad, der die Ausgabe mithilfe der nativen Audio-API von AAudio zurück an die Eingabe weitergibt. Die Loopback-Pfade sind:

    • Lautsprecher/Mikrofon: Integrierter Lautsprecher zu integriertem Mikrofon.
    • Analog: 3,5-mm-analoger Anschluss und ein Loopback-Adapter.
    • USB: USB-auf-3,5-mm-Adapter und Loopback-Adapter oder USB-Audioschnittstelle und Loopback-Kabel
  • FEATURE_AUDIO_LOW_LATENCY. Die Funktion android.hardware.audio.low_latency ist deklariert.

  • FEATURE_AUDIO_PRO. Die Funktion android.hardware.audio.pro ist deklariert.

  • MPC. Media Performance Class

  • Latenz der Kopfverfolgung. Die Zeit, die vergeht, bis die Kopfhörer-Wandler die durch die Kopfbewegung verursachte Änderung des Klangs erkennen.

Ende der neuen Anforderungen

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

Einführung neuer Anforderungen für Android 15

  • [C-1-1] Der Ausgabezeitstempel, der von AudioTrack.getTimestamp und AAudioStream_getTimestamp zurückgegeben wird, ist auf +/- 2 ms genau.

Ende der neuen Anforderungen

  • [C-1-2] Die Ausgabelatenz nach dem Kaltstart beträgt maximal 500 Millisekunden.

  • [C-1-3] Das Öffnen eines Ausgabestreams mit AAudioStreamBuilder_openStream() DARF nicht länger als 1.000 Millisekunden dauern.

Einführung neuer Anforderungen für Android 15

  • [C-1-4] Die berechneten Umlauflatenzen, die auf den von AAudioStream_getTimestamp zurückgegebenen Eingabe- und Ausgabezeitstempeln basieren, MÜSSEN innerhalb von 200 ms von der gemessenen Umlauflatenz für AAUDIO_PERFORMANCE_MODE_NONE und AAUDIO_PERFORMANCE_MODE_LOW_LATENCY für Lautsprecher, kabelgebundene und kabellose Headsets liegen.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

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

  • [C-SR-1] Die Latenz der Ausgabe nach dem Einschalten darf über den Lautsprecherdatenpfad maximal 100 Millisekunden betragen.

  • [C-SR-2] Die Latenz zwischen Tippen und Ton darf 80 Millisekunden nicht überschreiten.

  • [C-SR-4] Die berechneten Umlaufzeiten basierend auf den von AAudioStream_getTimestamp zurückgegebenen Eingabe- und Ausgabezeitstempeln sollten möglichst innerhalb von 30 Millisekunden von der gemessenen Umlaufzeit für AAUDIO_PERFORMANCE_MODE_NONE und AAUDIO_PERFORMANCE_MODE_LOW_LATENCY für Lautsprecher, kabelgebundene und kabellose Headsets liegen.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

Wenn die Geräteimplementierungen die oben genannten Anforderungen erfüllen, sind nach der anfänglichen Kalibrierung bei Verwendung der nativen Audio-API von AAudio die folgenden Werte für die kontinuierliche Ausgabelatenz und die Kaltstartlatenz über mindestens ein unterstütztes Audioausgabegerät zulässig:

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

Wenn die Geräteimplementierungen die Anforderungen für Audio mit niedriger Latenz über die native Audio-API von AAudio nicht erfüllen, gilt Folgendes:

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

Ende der neuen Anforderungen

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

Einführung neuer Anforderungen für Android 15

  • [C-3-1] Begrenzen Sie den Fehler bei den Eingabezeitstempeln, die von AudioRecord.getTimestamp oder AAudioStream_getTimestamp zurückgegeben werden, auf +/- 2 ms. Mit „Fehler“ ist hier die Abweichung vom korrekten Wert gemeint.

Ende der neuen Anforderungen

  • [C-3-2] Die Latenz der Eingabe nach dem Kaltstart beträgt maximal 500 Millisekunden.
  • [C-3-3] Das Öffnen eines Eingabestreams mit AAudioStreamBuilder_openStream() DARF nicht länger als 1.000 Millisekunden dauern.

Einführung neuer Anforderungen für Android 15

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

  • [C-SR-8] Die Eingabelatenz bei kaltem Start über den Mikrofondatenpfad darf 100 Millisekunden nicht überschreiten.
  • [C-SR-11] Begrenzen Sie den Fehler bei den Eingabezeitstempeln, die von AudioRecord.getTimestamp oder AAudioStream_getTimestamp zurückgegeben werden, auf +/- 1 ms.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

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

  • [C-SR-12] Es wird DRINGEND empfohlen, eine durchschnittliche kontinuierliche Round-Trip-Latenz von 50 Millisekunden oder weniger über fünf Messungen mit einer durchschnittlichen absoluten Abweichung von weniger als 10 Millisekunden über mindestens einen unterstützten Pfad zu haben.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

In der folgenden Tabelle sind die Anforderungen für RTL für Implementierungen auf Mobilgeräten gemäß 2.2.1 definiert, die android.hardware.audio.output und android.hardware.microphone angeben.

Geräte und Erklärungen RTL (ms) MAD (ms) Loopback-Pfade
Handkamera 250 30 Lautsprecher/Mikrofon, analoger 3,5-mm-Anschluss (falls unterstützt), USB (falls unterstützt)
>= MPC_T (14) 80 15 mindestens einen Pfad
FEATURE_AUDIO_LOW_LATENCY 50 10 mindestens einen Pfad
FEATURE_AUDIO_PRO 25 5 mindestens einen Pfad
FEATURE_AUDIO_PRO 20 5 analog (falls unterstützt)
FEATURE_AUDIO_PRO 25 5 USB (wenn analog nicht unterstützt wird)

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

In der folgenden Tabelle sind die Anforderungen an die TTL für Implementierungen auf Mobilgeräten gemäß 2.2.1 definiert, bei denen android.hardware.audio.output und android.hardware.microphone deklariert werden.

Geräte und Erklärungen TTL (ms)
Handkamera 250
>= MPC_T (14) 80
MPC_S (13) 100
FEATURE_AUDIO_PRO 80

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

Wenn Geräteimplementierungen spatial audio mit Kopf-Tracking unterstützen und das Flag PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY angeben, gilt Folgendes:

  • [C-4-1] Die Latenz zwischen der Kopfverfolgung und der Audioaktualisierung darf maximal 300 ms betragen.

Ende der neuen Anforderungen

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 eine Geräteimplementierung unterstützen muss, gilt Folgendes:

  • [C-1-1] Dieser Codec oder Container MUSS über HTTP und HTTPS unterstützt werden.

  • [C-1-2] MUSS die entsprechenden Mediensegmentformate unterstützen, die in der Tabelle unten aufgeführt sind, über das HTTP Live Streaming-Entwurfsprotokoll, Version 7.

  • [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 unter Abschnitt 5.1.

Mediensegmentformate

Segmentformate Referenzen Erforderliche Codec-Unterstützung
MPEG-2-Transportstream ISO 13818 Video-Codecs:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Weitere Informationen zu H264 AVC, MPEG2-4 SP und MPEG-2 findest du unter Abschnitt 5.1.8.

Audio-Codecs:

  • AAC
Weitere Informationen zu AAC und seinen Varianten findest du unter Abschnitt 5.1.3.
AAC mit ADTS-Framing und ID3-Tags ISO 13818-7 Weitere Informationen zu AAC und seinen Varianten findest du in Abschnitt 5.1.1 .
WebVTT WebVTT

RTSP (RTP, SDP)

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

5.8. Secure Media

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

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

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

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

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

  • [C-3-1] MUSS HDCP 1.2 oder höher für alle externen Displays unterstützen, die über einen für Nutzer zugänglichen kabelgebundenen Anschluss verbunden sind.

5.9. Musical Instrument Digital Interface (MIDI)

Wenn Geräteimplementierungen die Unterstützung der Funktion android.software.midi über die Klasse android.content.pm.PackageManager melden, gilt Folgendes:

  • [C-1-1] MUSS MIDI über alle MIDI-fähigen Hardware-Transporte unterstützen, für die eine generische Nicht-MIDI-Verbindung bereitgestellt wird. Diese Transporte sind:

  • [C-1-2] MUSS den Inter-App-MIDI-Software-Transport (virtuelle MIDI-Geräte) unterstützen

  • [C-1-3] MUSS libamidi.so (native MIDI-Unterstützung) enthalten

  • SOLLTE MIDI über USB-Peripheriegerätemodus unterstützen, Abschnitt 7.7

5.10. Professionelles Audio

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

  • [C-1-1] MUSS Unterstützung für die Funktion android.hardware.audio.low_latency angeben.

Einführung neuer Anforderungen für Android 15

  • [C-1-2] MÜSSEN eine kontinuierliche Audio-Rundlauflatenz haben und die Latenzanforderungen für FEATURE_AUDIO_PRO gemäß Abschnitt 5.6 Audiolatenz von maximal 25 Millisekunden über mindestens einen unterstützten Pfad erfüllen.

Ende der neuen Anforderungen

  • [C-1-3] MUSS USB-Ports haben, die den USB-Host-Modus und den USB-Peripheriegerätemodus unterstützen.
  • [C-1-4] MUSS die Unterstützung für die Funktion android.software.midi angeben.

Einführung neuer Anforderungen für Android 15

  • [C-1-5] MUSS die Latenzen und Latenz-Anforderungen für USB-Audio mit der nativen Audio-API von AAudio und AAUDIO_PERFORMANCE_MODE_LOW_LATENCY erfüllen.

Ende der neuen Anforderungen

  • [C-1-6] Die Latenz der Kaltstartausgabe muss 200 Millisekunden oder weniger betragen.
  • [C-1-7] Die Eingabelatenz bei kaltem Start muss 200 Millisekunden oder weniger betragen.

Einführung neuer Anforderungen für Android 15

  • [C-1-8] Die durchschnittliche Latenz für die Funktion „Zum Anrufen tippen“ darf bei mindestens fünf Messungen über den Datenpfad zwischen Lautsprecher und Mikrofon 80 Millisekunden nicht überschreiten.
  • [C-SR-1] Es wird DRINGEND empfohlen, die in Abschnitt 5.6 Audiolatenz definierten Latenzen von 20 Millisekunden oder weniger über fünf Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden auf dem Pfad zwischen Lautsprecher und Mikrofon einzuhalten.
  • [C-SR-2] Es wird DRINGEND empfohlen, die Anforderungen für Pro Audio für kontinuierliche Audio-Roundtrip-Latenz, Kaltstart-Eingabelatenz und Kaltstart-Ausgabelatenz sowie die USB-Audioanforderungen mit der AAudio Native Audio API über den MMAP-Pfad zu erfüllen.
  • [C-SR-3] Es wird DRINGEND empfohlen, eine gleichbleibende CPU-Leistung zu bieten, während Audio aktiv ist und die CPU-Auslastung variiert. Dies sollte mit der Android-App SynthMark getestet werden. SynthMark verwendet einen Softwaresynthesizer, der in einem simulierten Audio-Framework ausgeführt wird, um die Systemleistung zu messen. Eine Erläuterung der Benchmarks finden Sie in der SynthMark-Dokumentation. Die SynthMark-App muss mit der Option „Automatischer Test“ ausgeführt werden und die folgenden Ergebnisse erzielen:

    • voicemark.90 >= 32 Stimmen
    • latencymark.fixed.little <= 15 ms
    • latencymark.dynamic.little <= 50 ms
  • MÜSSEN Abweichungen und Abweichungen der Audiouhr relativ zur Standardzeit minimieren.

  • MÜSSEN die Audiotaktdrift im Verhältnis zur CPU-CLOCK_MONOTONIC minimieren, wenn beide aktiv sind.

  • MÜSSEN die Audiolatenz über die On-Device-Wandler minimieren.

  • MÜSSEN die Audiolatenz über USB Digital Audio minimieren.

  • MÜSSEN Audiolatenzmessungen über alle Pfade dokumentieren.

  • Der Jitter bei den Aufrufzeiten des Callbacks für den Abschluss des Audiopuffers sollte minimiert werden, da dies den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback beeinflusst.

  • Bei normalem Gebrauch und der gemeldeten Latenz sollte es KEINE Audiostörungen geben.

  • Die Latenz zwischen den Kanälen sollte gleich sein.

  • Die durchschnittliche MIDI-Latenz über alle Transports sollte MINIMIERT werden.

  • MÜSSEN die MIDI-Latenzvariabilität bei Belastung (Jitter) über alle Übertragungen minimieren.

  • MÜSSEN genaue MIDI-Zeitstempel über alle Übertragungen hinweg bereitstellen.

  • MÜSSEN Audiosignalrauschen über On-Device-Wandler minimieren, einschließlich des Zeitraums unmittelbar nach dem Kaltstart.

  • Die Audiotaktdifferenz zwischen der Eingabe- und Ausgabeseite der entsprechenden Endpunkte sollte null sein, wenn beide aktiv sind. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher auf dem Gerät oder der Audioeingang und -ausgang.

  • MÜSSEN Audio-Buffer-Fertigstellungs-Callbacks für die Eingabe- und Ausgabeseite der entsprechenden Endpunkte im selben Thread verarbeiten, wenn beide aktiv sind, und den Ausgabe-Callback sofort nach der Rückkehr aus dem Eingabe-Callback aufrufen. Wenn es nicht möglich ist, die Rückrufe im selben Thread zu verarbeiten, geben Sie den Ausgaberückruf kurz nach dem Eingaberückruf ein, damit die Anwendung eine einheitliche Zeitabfolge für die Eingabe- und Ausgabeseite hat.

  • MÜSSEN die Phasendifferenz zwischen der HAL-Audiopufferung für die Eingabe- und Ausgabeseite der entsprechenden Endpunkte minimieren.

  • MÜSSEN die Touch-Latenz minimieren.

  • Die Touch-Latenz sollte unter Last möglichst gering sein (Jitter).

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

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

Ende der neuen Anforderungen

Wenn die Geräteimplementierungen eine 4-polige 3,5-mm-Audiobuchse enthalten, müssen sie:

Einführung neuer Anforderungen für Android 15

  • [C-2-1] Die durchschnittliche kontinuierliche Audio-Round-Trip-Latenz, wie in Abschnitt 5.6 Audiolatenz definiert, muss 20 Millisekunden oder weniger betragen. Dieser Wert muss über fünf Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden über den Audio-Anschlusspfad mit einem Audio-Loopback-Dongle erreicht werden.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

Ende der neuen Anforderungen

Wenn bei Geräten keine 4-polige 3,5-mm-Audiobuchse vorhanden ist, aber USB-Ports, die den USB-Host-Modus unterstützen, gelten folgende Einschränkungen:

  • [C-3-1] Die USB-Audioklasse MUSS implementiert werden.

Einführung neuer Anforderungen für Android 15

  • [C-3-2] Die durchschnittliche kontinuierliche Audio-Round-Trip-Latenz muss bei 5 Messungen unter 25 Millisekunden liegen, wobei die mittlere absolute Abweichung unter 5 Millisekunden über den USB-Host-Modus-Port mit USB-Audioklasse liegen muss. Dies kann mit einem USB-3,5-mm-Adapter und einem Audio-Loopback-Dongle oder mit einer USB-Audioschnittstelle mit Patchkabeln gemessen werden, die die Eingänge mit den Ausgängen verbinden.
  • [C-SR-6] Es wird DRINGEND empfohlen, dass sie bei Verwendung mit USB-Audioperipheriegeräten, die diese Anforderungen ebenfalls erfüllen, eine gleichzeitige E/A-Datenübertragung mit bis zu 8 Kanälen in jede Richtung, eine Abtastrate von 96 kHz und eine Bittiefe von 24 Bit oder 32 Bit unterstützen.
  • [C-SR-7] Es wird DRINGEND empfohlen, diese Gruppe von Anforderungen mit der nativen Audio-API von AAudio über den MMAP-Pfad zu erfüllen.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

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

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

Ende der neuen Anforderungen

5.11. Aufnahme für „Unverarbeitet“

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

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

  • [C-1-1] Der Support muss über die android.media.AudioManagerProperty PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED gemeldet werden.

  • [C-1-2] MÜSSEN im mittleren Frequenzbereich eine nahezu flache Amplitude-zu-Frequenz-Charakteristik aufweisen: insbesondere ± 10 dB von 100 Hz bis 7.000 Hz für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird.

  • [C-1-3] Müssen Amplitudenwerte im niedrigen Frequenzbereich aufweisen: insbesondere von ± 20 dB von 5 Hz bis 100 Hz im Vergleich zum Mittelfrequenzbereich für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird.

  • [C-1-4] Müssen Amplitudenwerte im Hochfrequenzbereich aufweisen: insbesondere von ± 30 dB von 7.000 Hz bis 22 kHz im Vergleich zum Mittelfrequenzbereich für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird.

  • [C-1-5] Die Audioeingabeempfindlichkeit MUSS so eingestellt sein, dass eine Sinustonquelle mit 1.000 Hz, die bei einem Schalldruckpegel (SPL) von 94 dB wiedergegeben wird, für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird, eine Antwort mit einem RMS von 520 für 16‑Bit-Samples (oder −36 dB Vollskala für Gleitkomma-/Doppelpräzision-Samples) liefert.

  • [C-1-6] Für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird, MUSS ein Signal-Rausch-Verhältnis (SNR) von mindestens 60 dB vorhanden sein. Der SNR wird als Differenz zwischen 94 dB SPL und dem äquivalenten SPL des Eigenrauschens (A-bewertet) gemessen.

  • [C-1-7] Die Gesamtharmonische Verzerrung (Total Harmonic Distortion, THD) muss für jedes Mikrofon, das zum Aufzeichnen der unbehandelten Audioquelle verwendet wird, bei 1 kHz und einem Eingangspegel von 90 dB SPL unter 1% liegen.

  • [C-1-8] Der Pfad darf keine andere Signalverarbeitung (z.B. automatische Verstärkungsregelung, Hochpassfilter oder Echounterdrückung) enthalten, außer einem Pegelmultiplikator, um den Pegel in den gewünschten Bereich zu bringen. Mit anderen Worten:

    • [C-1-9] Wenn die Architektur aus irgendeinem Grund Signalverarbeitung enthält, MUSS diese deaktiviert werden und darf keine zusätzliche Latenz oder Verzögerung im Signalpfad verursachen.
    • [C-1-10] Der Pegelmultiplikator darf sich zwar auf dem Pfad befinden, darf aber KEINE Verzögerung oder Latenz im Signalpfad verursachen.

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

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

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

5.12. HDR-Video

Android 13 unterstützt die HDR-Technologien, die in einem kommenden Dokument beschrieben werden.

Pixelformat

Wenn ein Videodecoder die Unterstützung von COLOR_FormatYUVP010 angibt, gilt Folgendes:

  • [C-1-1] MUSS das P010-Format für die CPU-Lesefunktion unterstützen (ImageReader, MediaImage, ByteBuffer). In Android 13 wird P010 gelockert, um einen beliebigen Schritt für die Y- und UV-Ebenen zuzulassen.

  • [C-1-2] Der P010-Ausgabebuffer MUSS von der GPU gesampled werden können (wenn er mit der GPU_SAMPLING-Nutzung zugewiesen wird). Dadurch werden die GPU-Komposition und die benutzerdefinierte Tonanpassung durch Apps ermöglicht.

Wenn ein Videodecoder die Unterstützung von COLOR_Format32bitABGR2101010 angibt, gilt Folgendes:

  • [C-2-1] MUSS das RGBA_1010102-Format für die Ausgabefläche und CPU-lesbar (ByteBuffer-Ausgabe) unterstützen.

Wenn ein Videoencoder die Unterstützung von COLOR_FormatYUVP010 angibt, gilt Folgendes:

  • [C-3-1] MUSS das P010-Format für die Eingabeoberfläche und die CPU-schreibbare Eingabe (ImageWriter, MediaImage, ByteBuffer) unterstützen.

Wenn ein Videoencoder die Unterstützung von COLOR_Format32bitABGR2101010 angibt, gilt Folgendes:

  • [C-4-1] MUSS das RGBA_1010102-Format für die Eingabeoberfläche und die CPU-schreibbare Eingabe (ImageWriter, ByteBuffer) unterstützen. Hinweis: Für Encoder ist KEINE Umwandlung zwischen verschiedenen Übertragungskurven erforderlich.

Anforderungen an die HDR-Aufnahme

Für alle Videoencoder, die HDR-Profile unterstützen, gilt Folgendes für Geräteimplementierungen:

  • [C-5-1] Es darf NICHT davon ausgegangen werden, dass die HDR-Metadaten präzise sind. Beispielsweise können im codierten Frame Pixel über dem Spitzenwert der Leuchtdichte liegen oder das Histogramm ist möglicherweise nicht repräsentativ für den Frame.

  • MÜSSEN dynamische HDR-Metadaten zusammenführen, um geeignete statische HDR-Metadaten für codierte Streams zu generieren, und diese am Ende jeder Codierungssitzung ausgeben.

Wenn die Geräteimplementierungen die HDR-Aufnahme mit den CamcorderProfile APIs unterstützen, gilt Folgendes:

  • [C-6-1] MÜSSEN auch die HDR-Aufnahme über die Camera2 APIs unterstützen.

  • [C-6-2] Es MUSS mindestens einen hardwarebeschleunigten Videoencoder für jede unterstützte HDR-Technologie geben.

  • [C-6-3] MUSS mindestens die HLG-Aufzeichnung unterstützen.

  • [C-6-4] MUSS das Schreiben der HDR-Metadaten (falls für die HDR-Technologie zutreffend) in die aufgenommene Videodatei unterstützen. Bei AV1, HEVC und DolbyVision bedeutet das, dass die Metadaten in den codierten Bitstream aufgenommen werden.

  • [C-6-5] MUSS P010 und COLOR_FormatYUVP010 unterstützen.

  • [C-6-6] MUSS die Tonmapping-Funktion von HDR zu SDR im standardmäßigen hardwarebeschleunigten Decoder für das erfasste Profil unterstützen. Mit anderen Worten: Wenn ein Gerät HDR10+ HEVC aufnehmen kann, MUSS der Standard-HEVC-Decoder in der Lage sein, den aufgenommenen Stream in SDR zu decodieren.

Anforderungen an die HDR-Bearbeitung

Wenn Geräteimplementierungen Videoencoder enthalten, die die HDR-Bearbeitung unterstützen, gilt Folgendes:

  • Es sollte eine minimale Latenz für die Generierung der HDR-Metadaten verwendet werden, wenn diese nicht vorhanden sind. Außerdem sollte es reibungslos mit Situationen umgehen, in denen die Metadaten für einige Frames vorhanden sind, für andere aber nicht. Diese Metadaten MÜSSEN präzise sein (z. B. die tatsächliche Spitzenleuchtkraft und das Histogramm des Frames darstellen).

Wenn die Geräteimplementierung Codecs enthält, die FEATURE_HdrEditing unterstützen, gilt für diese Codecs Folgendes:

  • [C-7-1] Es muss mindestens ein HDR-Profil unterstützt werden.

  • [C-7-2] MUSS FEATURE_HdrEditing für alle HDR-Profile unterstützen, die von diesem Codec angekündigt werden. Mit anderen Worten: Es MUSS das Generieren von HDR-Metadaten unterstützen, wenn diese für alle unterstützten HDR-Profile, die HDR-Metadaten verwenden, nicht vorhanden sind.

  • [C-7-3] MÜSSEN die folgenden Videoencoder-Eingabeformate unterstützen, die das decodierte HDR-Signal vollständig beibehalten:

    • RGBA_1010102 (bereits in der Zielübertragungskurve) sowohl für die Eingabeoberfläche als auch für den ByteBuffer und MÜSSEN die Unterstützung für COLOR_Format32bitABGR2101010 angeben.

Wenn die Geräteimplementierung Codecs enthält, die FEATURE_HdrEditing unterstützen, gilt für das Gerät Folgendes:

  • [C-7-4] MUSS die Unterstützung für die OpenGL-Erweiterung EXT_YUV_target angeben.

6. Kompatibilität von Entwicklertools und ‑optionen

6.1. Entwicklertools

Geräteimplementierungen:

Einführung neuer Anforderungen für Android 15

  • [C-0-2] MUSS adb gemäß der Dokumentation im Android SDK und die im AOSP bereitgestellten Shell-Befehle unterstützen, die von App-Entwicklern verwendet werden können, einschließlich dumpsys, cmd stats und Simpleperf.

Ende der neuen Anforderungen

  • [C-0-11] MUSS den Shell-Befehl cmd testharness unterstützen. Upgrades von Geräteimplementierungen von einer früheren Android-Version ohne persistenten Datenblock KÖNNEN von C-0-11 ausgenommen werden.
  • [C-0-3] Das Format oder den Inhalt von Gerätesystemereignissen (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats), die über den Befehl „dumpsys“ protokolliert werden, DARF NICHT geändert werden.

Einführung neuer Anforderungen für Android 15

  • [C-0-10] Die folgenden Ereignisse MÜSSEN ohne Auslassung aufgezeichnet und für den cmd stats-Shell-Befehl und die StatsManager-System-API-Klasse zugänglich gemacht werden.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • InputDeviceUsageReported
    • JobStateChanged
    • KeyboardConfigured
    • KeyboardSystemsEventReported
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • TouchpadUsage
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged

Ende der neuen Anforderungen

  • [C-0-4] Der geräteseitige adb-Daemon MUSS standardmäßig inaktiv sein und es MUSS einen nutzerzugänglichen Mechanismus geben, um die Android Debug Bridge zu aktivieren.
  • [C-0-5] MUSS sicheres ADB unterstützen. Android unterstützt sicheres adb. Mit Secure adb wird adb auf bekannten authentifizierten Hosts aktiviert.
  • [C-0-6] Es MUSS ein Mechanismus vorhanden sein, mit dem adb von einem Hostcomputer aus verbunden werden kann. Im Detail:

Wenn Geräteimplementierungen ohne USB-Anschluss den Peripheriemodus unterstützen, gilt Folgendes:

  • [C-3-1] ADB MUSS über ein lokales Netzwerk (z. B. Ethernet oder WLAN) implementiert werden.
  • [C-3-2] MÜSSEN Treiber für Windows 7, 8 und 10 bereitstellen, damit Entwickler über das ADB-Protokoll eine Verbindung zum Gerät herstellen können.

Wenn Geräteimplementierungen adb-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet unterstützen, gilt Folgendes:

  • [C-4-1] Die AdbManager#isAdbWifiSupported()-Methode MUSS true zurückgeben.

Wenn Geräteimplementierungen adb-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet unterstützen und mindestens eine Kamera enthalten, gilt Folgendes:

  • [C-5-1] Die AdbManager#isAdbWifiQrSupported()-Methode MUSS true zurückgeben.

  • Dalvik Debug Monitor Service (ddms)

    • [C-0-7] MUSS alle DDMS-Funktionen unterstützen, die im Android SDK dokumentiert sind. Da ddms adb verwendet, sollte die Unterstützung für ddms standardmäßig inaktiv sein, muss aber unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben beschrieben aktiviert hat.
  • SysTrace

    • [C-0-9] MUSS das systrace-Tool unterstützen, wie im Android SDK beschrieben. Systrace muss standardmäßig inaktiv sein und es MUSS einen nutzerzugänglichen Mechanismus zum Aktivieren von Systrace geben.
  • Perfetto

    • [C-SR-1] Es wird DRINGEND empfohlen, dem Shell-Nutzer ein /system/bin/perfetto-Binärprogramm zur Verfügung zu stellen, dessen Befehlszeile der Perfetto-Dokumentation entspricht.
    • [C-SR-2] Es wird EMPFOHLEN, dass die perfetto-Binärdatei als Eingabe eine Protobuf-Konfiguration akzeptiert, die dem in der Perfetto-Dokumentation definierten Schema entspricht.
    • [C-SR-3] Es wird DRINGEND empfohlen, dass die perfetto-Binärdatei als Ausgabe einen Protobuf-Trace schreibt, der dem in der Perfetto-Dokumentation definierten Schema entspricht.
    • [C-SR-4] Es wird DRINGEND empfohlen, über die perfetto-Binärdatei mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen bereitzustellen.
  • Low Memory Killer

    • [C-0-12] Es MUSS ein LMK_KILL_OCCURRED_FIELD_NUMBER-Atom in das statsd-Protokoll geschrieben werden, wenn eine App vom Low Memory Killer beendet wird.
  • Test-Harnischmodus Wenn Geräteimplementierungen den Shell-Befehl cmd testharness unterstützen und cmd testharness enable ausführen, gilt Folgendes:

    • [C-2-1] MUSS true für ActivityManager.isRunningInUserTestHarness() zurückgeben
    • [C-2-2] Der Test-Harnischmodus MUSS wie in der Dokumentation zum Test-Harnischmodus beschrieben implementiert werden.
  • GPU-Arbeitsinformationen

    Geräteimplementierungen:

    • [C-0-13] Der Shell-Befehl dumpsys gpu --gpuwork MUSS implementiert werden, um die aggregierten GPU-Arbeitsdaten anzuzeigen, die vom power/gpu_work_period-Kernel-Tracepoint zurückgegeben werden, oder keine Daten, wenn der Tracepoint nicht unterstützt wird. Die AOSP-Implementierung ist frameworks/native/services/gpuservice/gpuwork/.

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

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

6.2. Entwickleroptionen

Android bietet Entwicklern die Möglichkeit, entwicklungsbezogene Einstellungen für Apps zu konfigurieren.

Geräteimplementierungen MÜSSEN eine einheitliche Nutzung der Entwickleroptionen ermöglichen. Sie müssen:

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

7. Hardwarekompatibilität

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

  • [C-0-1] Die Geräteimplementierung MUSS diese API wie in der Android SDK-Dokumentation beschrieben implementieren.

Wenn eine API im SDK mit einer Hardwarekomponente interagiert, die als optional angegeben ist und die Geräteimplementierung diese Komponente nicht hat:

  • [C-0-2] Vollständige Klassendefinitionen (wie im SDK dokumentiert) für die Komponenten-APIs MÜSSEN weiterhin angegeben werden.
  • [C-0-3] Das Verhalten der API MUSS auf angemessene Weise als No-Op implementiert werden.
  • [C-0-4] API-Methoden MÜSSEN Nullwerte zurückgeben, sofern dies in der SDK-Dokumentation zulässig ist.
  • [C-0-5] API-Methoden MÜSSEN No-Op-Implementierungen von Klassen zurückgeben, bei denen Nullwerte gemäß der SDK-Dokumentation nicht zulässig sind.
  • [C-0-6] API-Methoden DÜRFEN KEINE Ausnahmen auslösen, die nicht in der SDK-Dokumentation beschrieben sind.
  • [C-0-7] Geräteimplementierungen MÜSSEN für dieselbe Build-Fingerabdruck-Kennung über die Methoden getSystemAvailableFeatures() und hasSystemFeature(String) der Klasse android.content.pm.PackageManager korrekte Informationen zur Hardwarekonfiguration melden.

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

7.1. Display und Grafik

Android bietet Funktionen, mit denen Anwendungs-Assets und UI-Layouts automatisch an das Gerät angepasst werden, damit Drittanbieter-Apps auf einer Vielzahl von Hardwaredisplays und Konfigurationen reibungslos funktionieren. Ein Android-kompatibles Display ist ein Bildschirm, auf dem alle Verhaltensweisen und APIs implementiert sind, die in Android Developers – Screen compatibility overview, in diesem Abschnitt (7.1) und in den Unterabschnitten sowie in allen zusätzlichen gerätespezifischen Verhaltensweisen beschrieben sind, die in Abschnitt 2 dieser CDD dokumentiert sind.

Geräteimplementierungen:

  • [C-0-1] Drittanbieter-Apps MÜSSEN standardmäßig nur auf Android-kompatiblen Displays gerendert werden.

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

  • die physische Diagonale. Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Bereichs des Displays.
  • density. Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spannweite von 1" abgedeckt werden, ausgedrückt in Pixeln pro Zoll (ppi oder dpi). Wenn ppi- und dpi-Werte aufgeführt sind, müssen sowohl die horizontalen als auch die vertikalen dpi-Werte in den angegebenen Bereich fallen.
  • Seitenverhältnis. Das Verhältnis der Pixel der längeren zur kürzeren Bildschirmseite. Ein Display mit 480 × 854 Pixeln hat beispielsweise ein Seitenverhältnis von 854 ÷ 480 = 1, 779, also ungefähr „16:9“.
  • Dichteunabhängiges Pixel (dp). Eine virtuelle Pixeleinheit, die auf eine Bildschirmdichte von 160 Pixeln normiert ist. Bei einer bestimmten Dichte d und einer bestimmten Anzahl von Pixeln p wird die Anzahl der dichteunabhängigen Pixel dp so berechnet: dp = (160 ÷ d) × p.

7.1.1. Bildschirmkonfiguration

7.1.1.1. Bildschirmgröße und -form

Das Android-UI-Framework unterstützt eine Vielzahl verschiedener logischer Bildschirmlayoutgrößen und ermöglicht es Apps, die Größe des Bildschirmlayouts der aktuellen Konfiguration über Configuration.screenLayout mit SCREENLAYOUT_SIZE_MASK und Configuration.smallestScreenWidthDp abzufragen.

Geräteimplementierungen:

  • [C-0-1] MUSS die richtige Layoutgröße für die Configuration.screenLayout gemäß der Definition in der Android SDK-Dokumentation angeben. Insbesondere müssen Geräteimplementierungen die korrekten logischen Bildschirmabmessungen in Dichte-unabhängigen Pixeln (dp) wie unten angegeben angeben:

    • Geräte, für die Configuration.uiMode auf einen anderen Wert als UI_MODE_TYPE_WATCH festgelegt ist und die eine small-Größe für Configuration.screenLayout angeben, MÜSSEN mindestens 426 dp × 320 dp haben.
    • Geräte, die eine normal-Größe für die Configuration.screenLayout melden, MÜSSEN mindestens 480 dp × 320 dp haben.
    • Geräte, die eine large-Größe für die Configuration.screenLayout melden, MÜSSEN mindestens 640 dp × 480 dp haben.
    • Geräte, die eine xlarge-Größe für die Configuration.screenLayout melden, MÜSSEN mindestens 960 dp × 720 dp haben.
  • [C-0-2] Die angegebene Unterstützung von Bildschirmgrößen durch Anwendungen MUSS über das Attribut <supports-screens> in der AndroidManifest.xml korrekt berücksichtigt werden, wie in der Android SDK-Dokumentation beschrieben.

  • KANN Android-kompatible Displays mit abgerundeten Ecken haben.

Wenn Geräteimplementierungen Bildschirme mit der Größe UI_MODE_TYPE_NORMAL unterstützen und physische Displays mit abgerundeten Ecken zum Rendern dieser Bildschirme verwenden, gilt Folgendes:

  • [C-1-1] Es MUSS dafür gesorgt werden, dass für jedes solche Display mindestens eine der folgenden Anforderungen erfüllt ist:

    • Der Radius der abgerundeten Ecken darf maximal 38 dp betragen.
    • Wenn an jeder Ecke des logischen Displays ein Feld mit 18 dp × 18 dp verankert ist, ist auf dem Bildschirm mindestens ein Pixel jedes Felds sichtbar.
  • Es sollte eine Nutzerinteraktion zum Wechseln in den Displaymodus mit rechteckigen Ecken geben.

Wenn Geräteimplementierungen nur die NO_KEYS-Tastaturkonfiguration unterstützen und die Unterstützung für die UI_MODE_TYPE_NORMAL-UI-Moduskonfiguration melden möchten, müssen sie Folgendes tun:

  • [C-4-1] Das Layout muss ohne Displayausschnitte mindestens 596 × 384 dp groß sein.

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

Einführung neuer Anforderungen für Android 15

Wenn Geräteimplementierungen einen oder mehrere Android-kompatible Displaybereiche enthalten, die faltbar sind, oder ein Scharnier zwischen mehreren Android-kompatiblen Displaybereichen haben und diese Displaybereiche für Anwendungen verfügbar machen, gelten folgende Anforderungen:

  • [C-4-1] Es MUSS die richtige Version der Window Manager Extensions API-Ebene implementiert werden, wie unter WindowManager Extensions beschrieben.

Ende der neuen Anforderungen

7.1.1.2. Seitenverhältnis des Bildschirms

Dieser Abschnitt wurde in Android 14 entfernt.

7.1.1.3. Bildschirmdichte

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

Geräteimplementierungen:

  • [C-0-1] Es MUSS eine der Android-Framework-Dichten gemeldet werden, die auf DisplayMetrics aufgeführt sind, und zwar über die DENSITY_DEVICE_STABLE API. Dieser Wert muss für jedes physische Display statisch sein. Das Gerät kann jedoch eine andere DisplayMetrics.density melden, je nachdem, welche Änderungen der Nutzer nach dem ersten Start an der Displaykonfiguration vorgenommen hat (z. B. Displaygröße).

  • MÜSSEN die Standarddichte des Android-Frameworks definieren, die der physischen Dichte des Bildschirms numerisch am nächsten kommt, oder einen Wert, der denselben äquivalenten Winkel des Sichtfelds eines Mobilgeräts entspricht.

Wenn Geräteimplementierungen die Möglichkeit bieten, die Displaygröße des Geräts zu ändern, gilt Folgendes:

  • [C-1-1] Das Display darf maximal 1,5-mal skaliert werdenDENSITY_DEVICE_STABLE oder eine effektive Mindestbildschirmgröße von weniger als 320 dp (entspricht dem Ressourcenqualifizierer „sw320dp“) haben, je nachdem, was zuerst eintritt.
  • [C-1-2] Das Display darf NICHT auf weniger als 0,85 mal DENSITY_DEVICE_STABLE skaliert werden.
  • Für eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen wird empfohlen, die folgenden Optionen für die Skalierung der nativen Anzeige zu verwenden (unter Einhaltung der oben genannten Limits):
    • Klein: 0,85x
    • Standard: 1x (native Displayskala)
    • Groß: 1,15-fach
    • Größer: 1,3-fach
    • Größter Wert: 1,45-fach

7.1.2. Displaymesswerte

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

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

Wenn die Geräteimplementierungen kein eingebettetes Display oder einen Videoausgang haben, gilt Folgendes:

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

7.1.3. Displayausrichtung

Geräteimplementierungen:

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

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

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

7.1.4. 2D- und 3D-Grafikbeschleunigung

7.1.4.1. OpenGL ES

Geräteimplementierungen:

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

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

Einführung neuer Anforderungen für Android 15

  • [C-1-1] MUSS sowohl GL ES 1.1 als auch und 2.0, 3.0 und 3.1 unterstützen, wie in der Android SDK-Dokumentation beschrieben.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

  • [C-SR-1] Es wird DRINGEND empfohlen, OpenGL ES 3.1 zu unterstützen.

Ende der neuen Anforderungen

  • MÜSSEN OpenGL ES 3.2 unterstützen.

Die OpenGL ES-dEQP-Tests sind in mehrere Testlisten unterteilt, die jeweils mit einer Datums-/Versionsnummer verknüpft sind. Sie befinden sich im Android-Quellcodebaum unter external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Ein Gerät, das OpenGL ES auf einer selbst gemeldeten Stufe unterstützt, gibt an, dass es die dEQP-Tests in allen Testlisten ab dieser Stufe bestehen kann.

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

  • [C-2-1] MÜSSEN über die verwalteten OpenGL ES-APIs und nativen APIs alle anderen implementierten OpenGL ES-Erweiterungen melden und MÜSSEN im Umkehrschluss KEINE Erweiterungsstrings melden, die sie nicht unterstützen.
  • [C-2-2] MUSS die Erweiterungen EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable und EGL_ANDROID_GLES_layers unterstützen.
  • [C-2-3] MUSS die maximale Version der OpenGL ES-dEQP-Tests angeben, die über das android.software.opengles.deqp.level-Funktionsflag unterstützt werden.
  • [C-2-4] MUSS mindestens Version 132383489 (ab dem 1. März 2020) unterstützen, wie im android.software.opengles.deqp.level-Funktionsflag angegeben.
  • [C-2-5] Für jede unterstützte OpenGL ES-Version MÜSSEN alle OpenGL ES-dEQP-Tests in den Testlisten zwischen Version 132383489 und der im android.software.opengles.deqp.level-Funktionsflag angegebenen Version bestanden werden.
  • [C-SR-2] Es wird DRINGEND empfohlen, die Erweiterungen EGL_KHR_partial_update und OES_EGL_image_external zu unterstützen.
  • MÜSSEN alle unterstützten Texturkomprimierungsformate, die in der Regel anbieterspezifisch sind, korrekt über die Methode getString() melden.

  • MÜSSEN die Erweiterungen EGL_IMG_context_priority und EGL_EXT_protected_content unterstützen.

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

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

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

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

Wenn Geräteimplementierungen das gesamte OpenGL ES-Erweiterungspaket für Android unterstützen, gilt Folgendes:

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

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

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

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

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

  • [C-SR-1] Es wird DRINGEND empfohlen, Unterstützung für Vulkan 1.3 hinzuzufügen.
  • [C-4-1] Darf KEINE Vulkan-Variantenversion unterstützen (d.h. der Variantenteil der Vulkan-Kernversion MUSS null sein).

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

  • [C-SR-2] Es wird DRINGEND empfohlen, Unterstützung für Vulkan 1.3 hinzuzufügen.

Die Vulkan-dEQP-Tests sind in mehrere Testlisten unterteilt, die jeweils mit einem Datum/einer Version verknüpft sind. Sie befinden sich im Android-Quellcodebaum unter external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Ein Gerät, das Vulkan auf einer selbst gemeldeten Stufe unterstützt, gibt an, dass es die dEQP-Tests in allen Testlisten ab dieser Stufe bestehen kann.

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

  • [C-1-1] Es MUSS der richtige Ganzzahlwert mit den android.hardware.vulkan.level- und android.hardware.vulkan.version-Funktions-Flags angegeben werden.
  • [C-1-2] Es MUSS mindestens eine VkPhysicalDevice für die native Vulkan API vkEnumeratePhysicalDevices() aufgelistet werden.
  • [C-1-3] Die Vulkan 1.1 APIs MÜSSEN für jede aufgezählte VkPhysicalDevice vollständig implementiert sein.
  • [C-1-4] MUST enumerate layers, contained in native libraries named as libVkLayer*.so in the native library directory of the application package, through the Vulkan native APIs vkEnumerateInstanceLayerProperties() and vkEnumerateDeviceLayerProperties().
  • [C-1-5] Es DÜRFEN KEINE Ebenen aufgelistet werden, die von Bibliotheken außerhalb des Anwendungspakets bereitgestellt werden, und es DÜRFEN KEINE anderen Möglichkeiten zum Überwachen oder Abfangen der Vulkan API bereitgestellt werden, es sei denn, das Attribut android:debuggable der Anwendung ist auf true oder die Metadaten com.android.graphics.injectLayers.enable auf true gesetzt.
  • [C-1-6] MÜSSEN alle Erweiterungsstrings melden, die sie über die nativen Vulkan-APIs unterstützen, und umgekehrt MÜSSEN sie keine Erweiterungsstrings melden, die sie nicht korrekt unterstützen.
  • [C-1-7] MUSS die Erweiterungen VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain und VK_KHR_incremental_present unterstützen.
  • [C-1-8] MÜSSEN die maximale Version der Vulkan-dEQP-Tests angeben, die über das android.software.vulkan.deqp.level-Funktionsflag unterstützt wird.
  • [C-1-9] MUSS mindestens Version 132317953 (ab dem 1. März 2019) unterstützen, wie im Feature-Flag android.software.vulkan.deqp.level angegeben.
  • [C-1-10] Alle Vulkan-dEQP-Tests in den Testlisten zwischen Version 132317953 und der im android.software.vulkan.deqp.level-Funktionsflag angegebenen Version MÜSSEN bestanden werden.
  • [C-1-11] Die Unterstützung der Erweiterungen VK_KHR_video_queue, VK_KHR_video_decode_queue oder VK_KHR_video_encode_queue DARF NICHT aufgelistet werden.
  • [C-SR-3] Es wird DRINGEND empfohlen, die Erweiterungen VK_KHR_driver_properties und VK_GOOGLE_display_timing zu unterstützen.
  • [C-1-12] Die Unterstützung für die Erweiterung VK_KHR_performance_query DARF NICHT aufgelistet werden.
  • [C-SR-4] Es wird DRINGEND empfohlen, die Anforderungen des Android Baseline 2022-Profils zu erfüllen.
  • [C-SR-5] Es wird DRINGEND empfohlen, VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory und VK_EXT_global_priority zu unterstützen.
  • [C-SR-6] Es wird DRINGEND empfohlen, SkiaVk mit HWUI zu verwenden.

Einführung neuer Anforderungen für Android 15

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

  • [C-SR-8] Es wird DRINGEND empfohlen, den Vulkan-Ladeprogramm nicht zu ändern.
  • [C-1-14] Vulkan-Geräteerweiterungen vom Typ „KHR“, „GOOGLE“ oder „ANDROID“ DÜRFEN NICHT aufgelistet werden, es sei denn, diese Erweiterungen sind im android.software.vulkan.deqp.level-Funktionsflag enthalten.

Ende der neuen Anforderungen

Wenn Geräteimplementierungen keine Unterstützung für Vulkan 1.0 enthalten, gilt Folgendes:

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

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

  • [C-3-1] MUSS Unterstützung für die externen Semaphoren- und Handletypen von SYNC_FD und die Erweiterung VK_ANDROID_external_memory_android_hardware_buffer bereitstellen.

  • [C-SR-7] Es wird DRINGEND empfohlen, die VK_KHR_external_fence_fd-Erweiterung für Drittanbieteranwendungen verfügbar zu machen und die Anwendung so zu konfigurieren, dass sie die Fence-Nutzlast wie hier beschrieben in POSIX-Dateieinträge exportieren und aus diesen importieren kann.

7.1.4.3. RenderScript

Geräteimplementierungen:

  • [C-0-1] MUSS Android RenderScript unterstützen, wie in der Android SDK-Dokumentation beschrieben.
7.1.4.4. 2D-Grafikbeschleunigung

Android bietet einen Mechanismus, mit dem Anwendungen die Hardwarebeschleunigung für 2D-Grafiken auf Anwendungs-, Aktivitäts-, Fenster- oder Ansichtsebene mithilfe des Manifest-Tags android:hardwareAccelerated oder direkter API-Aufrufe aktivieren können.

Geräteimplementierungen:

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

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

Geräteimplementierungen:

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

Wenn bei Geräteimplementierungen die Unterstützung von Wide-Gamut-Displays über Configuration.isScreenWideColorGamut() angegeben ist, gilt Folgendes:

  • [C-1-1] MUSS ein farbkalibriertes Display haben.
  • [C-1-2] MUSS ein Display haben, dessen Farbraum den sRGB-Farbraum vollständig im CIE 1931 xyY-Farbraum abdeckt.
  • [C-1-3] Es MUSS ein Display mit einem Farbraum haben, dessen Fläche mindestens 90% des DCI-P3-Farbraums im CIE 1931 xyY-Farbraum hat.
  • [C-1-4] MUSS OpenGL ES 3.1 oder 3.2 unterstützen und dies korrekt melden.
  • [C-1-5] Es MUSS Unterstützung für die Erweiterungen EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear und EGL_EXT_gl_colorspace_display_p3_passthrough beworben werden.
  • [C-SR-1] Es wird DRINGEND empfohlen, GL_EXT_sRGB zu unterstützen.

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

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

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

Android bietet einen „Kompatibilitätsmodus“, in dem das Framework in einem Modus mit einer „normalen“ Bildschirmgröße (320 dp Breite) ausgeführt wird. Dieser Modus ist für ältere Anwendungen gedacht, die nicht für alte Android-Versionen entwickelt wurden, die noch nicht unabhängig von der Bildschirmgröße waren.

7.1.6. Displaytechnologie

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

Alle Android-kompatiblen Displays einer Geräteimplementierung:

  • [C-0-1] MUSS 16-Bit-Farbgrafiken rendern können.
  • SOLLTE Displays mit 24-Bit-Farbgrafik unterstützen.
  • [C-0-2] MUSS Animationen rendern können.
  • [C-0-3] Das Pixelseitenverhältnis (Pixel Aspect Ratio, PAR) muss zwischen 0,9 und 1,15 liegen. Das Pixelseitenverhältnis muss also nahezu quadratisch (1,0) sein, mit einer Toleranz von 10 bis 15 %.

7.1.7. Sekundäre Displays

Android unterstützt sekundäre Android-kompatible Displays, um Funktionen zur Medienfreigabe und Entwickler-APIs für den Zugriff auf externe Displays zu ermöglichen.

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

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

7.2. Eingabegeräte

Geräteimplementierungen:

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

7.2.1. Tastatur

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

Geräteimplementierungen:

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

7.2.2. Bedienung ohne Touchscreen

Android unterstützt D-Pad, Trackball und Rad als Mechanismen für die Navigation ohne Touchbedienung.

Geräteimplementierungen:

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

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

7.2.3. Navigationstasten

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

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

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

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

Geräteimplementierungen:

  • [C-SR-1] Es wird DRINGEND empfohlen, keinen Eingabemechanismus für die Menüfunktion bereitzustellen, da diese seit Android 4.0 zugunsten der Aktionsleiste eingestellt wurde.

  • [C-SR-2] Es wird DRINGEND empfohlen, alle Navigationsfunktionen so zu gestalten, dass sie abgebrochen werden können. „Abbrechen“ bedeutet, dass der Nutzer die Ausführung der Navigationsfunktion (z.B. Startseite aufrufen, zurückgehen usw.) verhindern kann, wenn der Wisch nicht über einen bestimmten Grenzwert hinausgeht.

Wenn Geräteimplementierungen die Menüfunktion bieten, gilt Folgendes:

  • [C-2-1] Die Schaltfläche für den Aktionsüberlauf MUSS angezeigt werden, wenn das Pop-up-Menü für den Aktionsüberlauf nicht leer ist und die Aktionsleiste sichtbar ist.
  • [C-2-2] Die Position des Pop-ups für die Aktionsleiste darf NICHT geändert werden, wenn die Schaltfläche „Overflow“ in der Aktionsleiste ausgewählt wird. Das Pop-up für die Aktionsleiste darf jedoch an einer anderen Position auf dem Bildschirm gerendert werden, wenn es durch Auswahl der Menüfunktion angezeigt wird.

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

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

Wenn Geräteimplementierungen die Hilfefunktion bieten, gilt Folgendes:

  • [C-4-1] Die Assistenzfunktion muss mit einer einzelnen Aktion (z.B. Tippen, Doppeltippen oder Geste) zugänglich sein, wenn andere Navigationstasten zugänglich sind.
  • [C-SR-3] Es wird dringend empfohlen, die Funktion „ZUM HAUS HALTEN“ zu verwenden, da dies die vorgesehene Interaktion ist.

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

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

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

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

Wenn eine Navigationsfunktion von überall am linken und rechten Rand der aktuellen Bildschirmausrichtung aus verfügbar ist:

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

Wenn die Funktion zum Zurückgehen verfügbar ist und der Nutzer die Geste zum Zurückgehen abbricht, geschieht Folgendes:

  • [C-8-1] OnBackInvokedCallback.onBackCancelled() MUSS aufgerufen werden.
  • [C-8-2] OnBackInvokedCallback.onBackInvoked() DARF NICHT aufgerufen werden.
  • [C-8-3] Das Ereignis KEYCODE_BACK darf NICHT gesendet werden.

Wenn die Funktion zum Zurückgehen vorhanden ist, für die Anwendung im Vordergrund aber KEINE OnBackInvokedCallback registriert ist, geschieht Folgendes:

  • Das System sollte eine Animation für die Anwendung im Vordergrund bereitstellen, die darauf hinweist, dass der Nutzer zurückgeht, wie in AOSP vorgesehen.

Wenn Geräteimplementierungen die System-API setNavBarMode unterstützen, damit jede System-App mit der Berechtigung android.permission.STATUS_BAR den Navigationsleistenmodus festlegen kann, gilt Folgendes:

  • [C-9-1] Es MUSS Unterstützung für kinderfreundliche Symbole oder eine Schaltflächennavigation wie im AOSP-Code bereitgestellt werden.

7.2.4. Touchscreen-Eingabe

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

Geräteimplementierungen:

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

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

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

Wenn Geräteimplementierungen einen Touchscreen haben, der mehr als eine Berührung auf einem primären Android-kompatiblen Display verfolgen kann, müssen sie:

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

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

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

7.2.5. Gefälschte Eingabe per Berührung

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

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

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

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

  • [C-1-1] MÜSSEN die absoluten X- und Y-Bildschirmpositionen des Cursors melden und einen visuellen Cursor auf dem Bildschirm anzeigen.
  • [C-1-2] Es MUSS ein Touch-Ereignis mit dem Aktionscode gemeldet werden, der die Statusänderung angibt, die auftritt, wenn der Cursor auf dem Bildschirm nach unten oder oben bewegt wird.
  • [C-1-3] Es MUSS möglich sein, den Cursor auf ein Objekt auf dem Bildschirm zu bewegen und dann nach unten oder oben zu bewegen, damit Nutzer das Tippen auf ein Objekt auf dem Bildschirm emulieren können.
  • [C-1-4] Es MUSS möglich sein, innerhalb eines bestimmten Zeitlimits den Cursor an derselben Stelle auf einem Objekt auf dem Display nacheinander nach unten und nach oben zu bewegen, damit Nutzer ein Doppeltippen auf ein Objekt auf dem Display emulieren können.
  • [C-1-5] Es MUSS möglich sein, den Cursor an einer beliebigen Stelle auf dem Display anzuklicken, den Cursor an eine andere beliebige Stelle auf dem Display zu bewegen und dann den Cursor wieder anzuklicken, damit Nutzer ein Ziehen per Touch emulieren können.
  • [C-1-6] MUSS die Maustaste gedrückt halten und es Nutzern dann ermöglichen, das Objekt schnell an eine andere Position auf dem Bildschirm zu verschieben und dann die Maustaste loszulassen, damit Nutzer ein Objekt auf dem Bildschirm werfen können.

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

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

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

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

7.2.6. Unterstützung für Gamecontroller

7.2.6.1. Tastenbelegung

Geräteimplementierungen:

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

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

  • [C-2-1] DAS Funktions-Flag android.hardware.gamepad MUSS deklariert werden.
Schaltfläche HID-Nutzung2 Android-Schaltfläche
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-Pad nach oben1
D-Pad nach unten1
0x01 0x00393 AXIS_HAT_Y4
Steuerkreuz links1
Steuerkreuz rechts1
0x01 0x00393 AXIS_HAT_X4
Linke Schultertaste1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Rechte Schultertaste1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Linker Stick klicken1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Rechter Stick klicken1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Zurück1 0x0c 0x0224 KEYCODE_BACK (4)

KeyEvent

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

3 Dieser Messwert muss ein logisches Minimum von 0, ein logisches Maximum von 7, ein physikalisches Minimum von 0, ein physikalisches Maximum von 315, Einheiten in Grad und eine Berichtsgröße von 4 haben. Der logische Wert wird als Drehung im Uhrzeigersinn weg von der vertikalen Achse definiert. Ein logischer Wert von 0 steht beispielsweise für keine Drehung und die gedrückte Aufwärtstaste, während ein logischer Wert von 1 für eine Drehung von 45 Grad und die gedrückten Tasten „Aufwärts“ und „Links“ steht.

MotionEvent

Analoge Steuerelemente1 HID-Nutzung Android-Schaltfläche
Linker Trigger 0x02 0x00C5 AXIS_LTRIGGER
Rechter Trigger 0x02 0x00C4 AXIS_RTRIGGER
Linker Joystick 0x01 0x0030
0x01 0x0031
AXIS_X
AXIS_Y
Rechter Joystick 0x01 0x0032
0x01 0x0035
AXIS_Z
AXIS_RZ

MotionEvent

7.2.7. Fernbedienung

Gerätespezifische Anforderungen finden Sie unter Abschnitt 2.3.1.

7.3. Sensoren

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

Geräteimplementierungen:

  • [C-0-1] Das Vorhandensein oder Fehlen von Sensoren muss gemäß der android.content.pm.PackageManager-Klasse korrekt gemeldet werden.
  • [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. true oder false zurückgeben, wenn Anwendungen versuchen, Listener zu registrieren, Sensor-Listener nicht aufrufen, wenn die entsprechenden Sensoren nicht vorhanden sind usw.).

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

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

Die Liste oben ist nicht vollständig. Das dokumentierte Verhalten des Android SDK und die Android Open Source-Dokumentationen zu Sensoren sind maßgebend.

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

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

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

Geräteimplementierungen:

  • MÜSSEN diese Sensortypen implementiert werden, wenn sie die erforderlichen physischen Sensoren enthalten, wie unter Sensortypen beschrieben.

Wenn Geräteimplementierungen einen zusammengesetzten Sensor enthalten, gilt Folgendes:

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

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

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

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

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

  • [C-SR-2] Es wird DRINGEND empfohlen, dass Beschleunigungsmesser, Gyroskop und Magnetometer eine feste relative Position haben, damit die Sensorachsen bei verformbaren Geräten (z.B. faltbar) in allen möglichen Gerätetransformationszuständen ausgerichtet und mit dem Sensorkoordinatensystem übereinstimmen.

7.3.1. Beschleunigungsmesser

Geräteimplementierungen:

  • [C-SR-1] Es wird dringend empfohlen, einen dreiachsigen Beschleunigungsmesser zu verwenden.

Wenn Geräteimplementierungen einen Beschleunigungsmesser enthalten, gilt Folgendes:

  • [C-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 50 Hz erfassen können.
  • [C-1-3] MUSS dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben.
  • [C-1-4] MÜSSEN in der Lage sein, in jeder Achse von einem freien Fall bis zu viermal gravity(4g) oder mehr zu messen.
  • [C-1-5] MÜSSEN eine Auflösung von mindestens 12 Bit haben.
  • [C-1-6] Die Standardabweichung darf maximal 0,05 m/s² betragen.Die Standardabweichung sollte pro Achse anhand von Stichproben berechnet werden, die über einen Zeitraum von mindestens 3 Sekunden mit der höchsten Abtastrate erfasst wurden.
  • MÜSSEN Ereignisse mit mindestens 200 Hz erfassen.
  • MÜSSEN eine Auflösung von mindestens 16 Bit haben.
  • MÜSSEN während der Nutzung kalibriert werden, wenn sich die Eigenschaften im Laufe des Lebenszyklus ändern und kompensiert werden, und die Kompensationsparameter zwischen den Neustarts des Geräts beibehalten.
  • SOLLTE temperaturkompensiert sein.

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

  • [C-2-1] Der TYPE_ACCELEROMETER-Sensor MUSS implementiert und erfasst werden.
  • [C-SR-4] Es wird DRINGEND empfohlen, den TYPE_SIGNIFICANT_MOTION-Kompositsensor zu implementieren.
  • [C-SR-5] Es wird DRINGEND empfohlen, den TYPE_ACCELEROMETER_UNCALIBRATED-Sensor zu implementieren und zu erfassen. Wir EMPFEHLEN Android-Geräten dringend, diese Anforderung zu erfüllen, damit sie auf die zukünftige Plattformversion umstellen können, bei der dies möglicherweise ERFORDERLICH sein wird.
  • MÜSSEN die zusammengesetzten Sensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR und TYPE_STEP_COUNTER wie im Android SDK-Dokument beschrieben implementieren.

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

  • [C-3-1] Der TYPE_ACCELEROMETER_LIMITED_AXES-Sensor MUSS implementiert und erfasst werden.
  • [C-SR-6] Es wird dringend empfohlen, den Sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED zu implementieren und zu erfassen.

Wenn die Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser und einen der zusammengesetzten Sensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR oder TYPE_STEP_COUNTER enthalten:

  • [C-4-1] Die Summe ihres Energieverbrauchs DARF immer unter 4 mW liegen.
  • MÜSSEN jeweils unter 2 mW und 0,5 mW liegen, wenn sich das Gerät in einem dynamischen oder statischen Zustand befindet.

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

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

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

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

7.3.2. Magnetometer

Geräteimplementierungen:

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

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

  • [C-1-1] Der TYPE_MAGNETIC_FIELD-Sensor MUSS implementiert sein.
  • [C-1-2] MUSS Ereignisse mit einer Häufigkeit von mindestens 10 Hz melden und SOLLTE Ereignisse mit einer Häufigkeit von mindestens 50 Hz melden.
  • [C-1-3] MUSS dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben.
  • [C-1-4] MUSS in der Lage sein, in jeder Achse Werte zwischen -900 µT und +900 µT zu messen, bevor es zu einer Sättigung kommt.
  • [C-1-5] Der Wert für den harten Eisenabstand MUSS unter 700 µT liegen und SOLLTE unter 200 µT liegen, wenn der Magnetometer weit von dynamischen (strominduzierten) und statischen (magnetinduzierten) Magnetfeldern entfernt platziert wird.
  • [C-1-6] Die Auflösung MUSS mindestens 0,6 µT betragen.
  • [C-1-7] MUSS die Onlinekalibrierung und ‑kompensation der Hard-Iron-Vorspannung unterstützen und die Kompensationsparameter zwischen den Geräteneustarts beibehalten.
  • [C-1-8] Die Weicheisenkompensation MUSS angewendet werden. Die Kalibrierung kann entweder während der Nutzung oder während der Herstellung des Geräts erfolgen.
  • [C-1-9] Die Standardabweichung, die auf Achsenbasis anhand von Stichproben berechnet wird, die über einen Zeitraum von mindestens 3 Sekunden mit der höchsten Abtastrate erfasst wurden, darf maximal 1,5 µT betragen. Die Standardabweichung sollte maximal 0,5 µT betragen.
  • [C-1-10] Der Sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED MUSS implementiert sein.

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

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

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

  • Der TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor kann implementiert werden.

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

  • [C-3-1] Der Energieverbrauch DARF nicht über 10 mW liegen.
  • Sollte weniger als 3 mW verbrauchen, wenn der Sensor für den Batchmodus bei 10 Hz registriert ist.

7.3.3. GPS

Geräteimplementierungen:

  • [C-SR-1] Es wird dringend empfohlen, einen GPS-/GNSS-Empfänger hinzuzufügen.

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

  • [C-1-1] MUSS Standortausgaben mit einer Rate von mindestens 1 Hz unterstützen, wenn sie über LocationManager#requestLocationUpdate angefordert werden.
  • [C-1-2] MUSS in einem offenen Gelände (starke Signale, vernachlässigbare Mehrwegeausbreitung, HDOP < 2) innerhalb von 10 Sekunden (schnelle Zeit bis zur ersten Fixierung) den Standort bestimmen können, wenn eine Internetverbindung mit einer Datenübertragungsrate von mindestens 0,5 Mbit/s besteht. Diese Anforderung wird in der Regel durch die Verwendung einer Form von unterstütztem oder prognostiziertem GPS/GNSS-Verfahren erfüllt, um die GPS/GNSS-Anlaufzeit zu minimieren. Zu den Hilfsdaten gehören Referenzzeit, Referenzstandort und Satellitenephemeris/-uhr.
    • [C-1-6] Nach einer solchen Standortberechnung MÜSSEN Geräteimplementierungen ihren Standort unter freiem Himmel innerhalb von 5 Sekunden bestimmen, wenn Standortanfragen neu gestartet werden, bis zu einer Stunde nach der ersten Standortberechnung, auch wenn die nachfolgende Anfrage ohne Datenverbindung und/oder nach einem Neustart erfolgt.
  • Bei freiem Himmel nach der Standortbestimmung, wenn Sie stehen oder sich mit weniger als 1 Meter pro Sekunde² bewegen:

    • [C-1-3] MUSS in mindestens 95% der Fälle in der Lage sein, den Standort innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0, 5 Metern pro Sekunde zu bestimmen.
    • [C-1-4] MUSS mindestens acht Satelliten aus einer Konstellation gleichzeitig über GnssStatus.Callback verfolgen und melden.
    • MÜSSEN mindestens 24 Satelliten gleichzeitig aus mehreren Konstellationen (z.B. GPS + mindestens einer von Glonass, Beidou, Galileo) erfassen können.
  • [C-SR-2] Es wird DRINGEND empfohlen, während eines Notanrufs weiterhin normale GPS-/GNSS-Standortausgaben über GNSS-Standortanbieter-APIs zu liefern.

  • [C-SR-3] Es wird DRINGEND empfohlen, GNSS-Messungen von allen verfolgten Konstellationen (wie in GnssStatus-Nachrichten angegeben) zu melden, mit Ausnahme von SBAS.

  • [C-SR-4] Es wird DRINGEND empfohlen, AGC und die Häufigkeit der GNSS-Messung anzugeben.

  • [C-SR-5] Es wird DRINGEND empfohlen, alle Genauigkeitsschätzungen (einschließlich Peilung, Geschwindigkeit und Vertikale) als Teil jedes GPS-/GNSS-Standorts anzugeben.

  • [C-SR-6] Es wird DRINGEND empfohlen, GNSS-Messungen zu melden, sobald sie gefunden werden, auch wenn ein aus GPS/GNSS berechneter Standort noch nicht gemeldet wurde.

  • [C-SR-7] Es wird DRINGEND empfohlen, GNSS-Pseudostrecken und Pseudostreckenraten zu melden, die bei freiem Blick nach der Standortbestimmung, bei Stillstand oder bei einer Beschleunigung von weniger als 0, 2 Metern pro Sekunde zum Quadrat ausreichen, um mindestens 95% der Zeit die Position innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0, 2 Metern pro Sekunde zu berechnen.

7.3.4. Gyroskop

Geräteimplementierungen:

  • [C-SR-1] Es wird dringend empfohlen, einen Gyroskopsensor einzubauen.

Wenn Geräteimplementierungen ein Gyroskop enthalten, gilt Folgendes:

  • [C-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 50 Hz erfassen können.
  • [C-1-4] MUSS eine Auflösung von mindestens 12 Bit haben.
  • [C-1-5] MUSS temperaturkompensiert sein.
  • [C-1-6] MUSS während der Verwendung kalibriert und kompensiert werden und die Kompensationsparameter zwischen den Neustarts des Geräts beibehalten.
  • [C-1-7] Die Abweichung darf maximal 1 × 10−7 rad² / s² pro Hz betragen (Abweichung pro Hz oder rad² / s). Die Abweichung darf mit der Abtastrate variieren, muss aber auf diesen Wert beschränkt sein. Mit anderen Worten: Wenn Sie die Abweichung des Gyroskops bei einer Abtastrate von 1 Hz messen, sollte sie nicht größer als 1 E-7 rad²/s² sein.
  • [C-SR-2] Der Kalibrierungsfehler sollte UNTER 0,01 rad/s liegen, wenn sich das Gerät bei Raumtemperatur nicht bewegt.
  • [C-SR-3] Es wird DRINGEND empfohlen, eine Auflösung von mindestens 16 Bit zu verwenden.
  • MÜSSEN Ereignisse mit mindestens 200 Hz erfassen.

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

  • [C-2-1] Der TYPE_GYROSCOPE-Sensor MUSS implementiert sein.
  • [C-SR-4] Es wird dringend empfohlen, den TYPE_GYROSCOPE_UNCALIBRATED-Sensor zu implementieren.

Wenn Geräteimplementierungen ein Gyroskop mit weniger als drei Achsen enthalten, gilt Folgendes:

  • [C-3-1] Der TYPE_GYROSCOPE_LIMITED_AXES-Sensor MUSS implementiert und erfasst werden.
  • [C-SR-5] Es wird dringend empfohlen, den TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED-Sensor zu implementieren und zu melden.

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

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

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

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

7.3.5. Barometer

Geräteimplementierungen:

  • [C-SR-1] Es wird dringend empfohlen, ein Barometer (Umgebungsluftdrucksensor) einzubauen.

Wenn Geräteimplementierungen ein Barometer enthalten, gilt Folgendes:

  • [C-1-1] Der TYPE_PRESSURE-Sensor MUSS implementiert und erfasst werden.
  • [C-1-2] MUSS Ereignisse mit mindestens 5 Hz senden können.
  • [C-1-3] MUSS temperaturkompensiert sein.
  • [C-SR-2] Es wird dringend empfohlen, Druckmessungen im Bereich von 300 hPa bis 1.100 hPa erfassen zu können.
  • MÜSSEN eine absolute Genauigkeit von 1 hPa haben.
  • SOLLTE eine relative Genauigkeit von 0,12 hPa über einen Bereich von 20 hPa haben (entspricht einer Genauigkeit von etwa 1 m bei einer Änderung von etwa 200 m über dem Meeresspiegel).

7.3.6. Thermometer

Wenn Geräteimplementierungen ein Umgebungsthermometer (Temperatursensor) enthalten, gilt Folgendes:

  • [C-1-1] SENSOR_TYPE_AMBIENT_TEMPERATURE für den Umgebungstemperatursensor MUSS definiert sein und der Sensor MUSS die Umgebungstemperatur (Raum-/Fahrzeuginnenraumtemperatur) an dem Ort messen, an dem der Nutzer mit dem Gerät interagiert, in Grad Celsius.

Wenn Geräteimplementierungen einen Thermometersensor enthalten, der eine andere Temperatur als die Umgebungstemperatur misst, z. B. die CPU-Temperatur, gilt Folgendes:

Wenn Geräteimplementierungen einen Sensor zur Überwachung der Hauttemperatur enthalten, gilt Folgendes:

7.3.7. Fotometer

  • Geräteimplementierungen KÖNNEN einen Photometer (Umgebungslicht-Sensor) enthalten.

7.3.8. Näherungssensor

  • Geräteimplementierungen KÖNNEN einen Näherungssensor enthalten.

Wenn Geräteimplementierungen einen Näherungssensor enthalten und nur eine binäre „Nah“- oder „Weit“-Messung melden, gilt Folgendes:

  • [C-1-1] Die Nähe eines Objekts MUSS in derselben Richtung wie der Bildschirm gemessen werden. Der Näherungssensor MUSS so ausgerichtet sein, dass er Objekte in der Nähe des Displays erkennt, da dieser Sensortyp in erster Linie dazu dient, ein vom Nutzer verwendetes Smartphone zu erkennen. Wenn Geräteimplementierungen einen Näherungssensor mit einer anderen Ausrichtung enthalten, darf dieser NICHT über diese API zugänglich sein.
  • [C-1-2] MÜSSEN eine Genauigkeit von mindestens 1 Bit haben.
  • [C-1-3] Es MÜSSEN 0 Zentimeter als Nahwert und 5 Zentimeter als Fernwert verwendet werden.
  • [C-1-4] Es MUSS ein maximaler Bereich und eine maximale Auflösung von 5 angegeben werden.

7.3.9. Hochpräzise Sensoren

Wenn Geräteimplementierungen eine Reihe von Sensoren mit höherer Qualität wie in diesem Abschnitt definiert enthalten und diese für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

  • [C-1-1] Die Funktion MUSS über das Feature-Flag android.hardware.sensor.hifi_sensors angegeben werden.

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

  • [C-2-1] MUSS einen TYPE_ACCELEROMETER-Sensor haben, der:

    • Der Messbereich muss mindestens -8 g bis +8 g betragen. Wir empfehlen einen Messbereich von mindestens -16 g bis +16 g.
    • Die Messauflösung muss mindestens 2.048 LSB/g betragen.
    • Die Mindestmessungsfrequenz muss 12,5 Hz oder niedriger sein.
    • MUSS eine maximale Messfrequenz von mindestens 400 Hz haben; SOLLTE den SensorDirectChannel RATE_VERY_FAST unterstützen.
    • Der Messrauschen darf maximal 400 μg/√Hz betragen.
    • Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 3.000 Sensorereignissen implementiert werden.
    • Der Batch-Stromverbrauch darf maximal 3 mW betragen.
    • [C-SR-1] Es wird DRINGEND empfohlen, eine 3-dB-Messbandbreite von mindestens 80% der Nyquist-Frequenz und ein Weißrauschenspektrum innerhalb dieser Bandbreite zu verwenden.
    • MÜSSEN einen Zufallspfad der Beschleunigung von weniger als 30 μg √Hz bei Raumtemperatur haben.
    • Die Vorabweichung sollte bei Temperaturänderungen ≤ ± 1 mg/°C betragen.
    • Die Nichtlinearität der Bestfit-Linie sollte ≤ 0,5 % und die Empfindlichkeitsänderung bei Temperaturschwankungen ≤ 0,03%/°C betragen.
    • MÜSSEN eine Achsenkreuzempfindlichkeit von weniger als 2,5 % und eine Abweichung der Achsenkreuzempfindlichkeit von weniger als 0,2% im Betriebstemperaturbereich des Geräts haben.
  • [C-2-2] Es MUSS ein TYPE_ACCELEROMETER_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_ACCELEROMETER haben.

  • [C-2-3] MUSS einen TYPE_GYROSCOPE-Sensor haben, der:

    • Der Messbereich muss mindestens -1.000 und +1.000 dps betragen.
    • MÜSSEN eine Messauflösung von mindestens 16 LSB/dps haben.
    • Die Mindestmessungsfrequenz muss 12,5 Hz oder niedriger sein.
    • MUSS eine maximale Messfrequenz von mindestens 400 Hz haben; SOLLTE den SensorDirectChannel RATE_VERY_FAST unterstützen.
    • Der Messrauschen darf maximal 0,014 °/s/√Hz betragen.
    • [C-SR-2] Es wird DRINGEND empfohlen, eine 3-dB-Messbandbreite von mindestens 80% der Nyquist-Frequenz und ein Weißrauschenspektrum innerhalb dieser Bandbreite zu verwenden.
    • Die Rate des zufälligen Ausschlags sollte bei Raumtemperatur unter 0,001 °/s √Hz liegen.
    • Die Vorabweichung sollte bei Temperaturänderungen ≤ ± 0,05 °/ s / °C betragen.
    • Die Empfindlichkeit sollte sich bei Temperaturänderungen um maximal 0,02 % pro °C ändern.
    • Die Nichtlinearität der Ausgleichsgerade sollte ≤ 0,2 % betragen.
    • MÜSSEN eine Rauschdichte von ≤ 0,007 °/s/√Hz haben.
    • Der Kalibrierungsfehler sollte bei einem stationären Gerät im Temperaturbereich von 10 bis 40 °C unter 0,002 rad/s liegen.
    • Die G-Empfindlichkeit sollte unter 0,1 °/s/g liegen.
    • MÜSSEN eine kreuzaxiale Empfindlichkeit von weniger als 4,0 % und eine kreuzaxiale Empfindlichkeitsabweichung von weniger als 0,3% im Betriebstemperaturbereich des Geräts haben.
  • [C-2-4] TYPE_GYROSCOPE_UNCALIBRATED MUSS dieselben Qualitätsanforderungen wie TYPE_GYROSCOPE erfüllen.

  • [C-2-5] MUSS einen TYPE_GEOMAGNETIC_FIELD-Sensor haben, der:

    • Der Messbereich muss mindestens -900 und +900 μT betragen.
    • Die Messauflösung muss mindestens 5 LSB/uT betragen.
    • Die Mindestmessungsfrequenz muss 5 Hz oder weniger betragen.
    • Die maximale Messfrequenz muss mindestens 50 Hz betragen.
    • Der Messrauschen darf maximal 0,5 µT betragen.
  • [C-2-6] Es MUSS ein TYPE_MAGNETIC_FIELD_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_GEOMAGNETIC_FIELD haben und zusätzlich:

    • Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 600 Sensorereignissen implementiert werden.
    • [C-SR-3] Es wird DRINGEND empfohlen, ein Weißgeräuschspektrum von 1 Hz bis mindestens 10 Hz zu verwenden, wenn die Berichtsrate 50 Hz oder höher ist.
  • [C-2-7] MUSS einen TYPE_PRESSURE-Sensor haben, der:

    • Der Messbereich muss mindestens 300 bis 1.100 hPa betragen.
    • MÜSSEN eine Messauflösung von mindestens 80 LSB/hPa haben.
    • Die Mindestmessungsfrequenz muss 1 Hz oder weniger betragen.
    • Die maximale Messfrequenz muss mindestens 10 Hz betragen.
    • Der Messrauschen darf maximal 2 Pa/√Hz betragen.
    • Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 300 Sensorereignissen implementiert werden.
    • Der Batch-Stromverbrauch darf maximal 2 mW betragen.
  • [C-2-8] MUSS einen TYPE_GAME_ROTATION_VECTOR-Sensor haben.

  • [C-2-9] MUSS einen TYPE_SIGNIFICANT_MOTION-Sensor haben, der:

    • Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
  • [C-2-10] Es MUSS einen TYPE_STEP_DETECTOR-Sensor haben, der:

    • Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 100 Sensorereignissen implementiert werden.
    • Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
    • Der Batch-Stromverbrauch darf maximal 4 mW betragen.
  • [C-2-11] MUSS einen TYPE_STEP_COUNTER-Sensor haben, der:

    • Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
  • [C-2-12] MUSS einen TILT_DETECTOR-Sensor haben, der:

    • Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
  • [C-2-13] Der Zeitstempel desselben physischen Ereignisses, der vom Beschleunigungsmesser, Gyroskop und Magnetometer erfasst wird, MUSS innerhalb von 2,5 Millisekunden voneinander liegen. Der Zeitstempel des Ereignisses für dasselbe physische Ereignis, das vom Beschleunigungsmesser und Gyroskop erfasst wird, sollte innerhalb von 0,25 Millisekunden voneinander liegen.

  • [C-2-14] Die Zeitstempel der Gyroskopsensorereignisse MÜSSEN auf derselben Zeitbasis wie das Kamera-Subsystem liegen und innerhalb von 1 Millisekunde Abweichung liegen.

  • [C-2-15] Die Samples MÜSSEN innerhalb von 5 Millisekunden nach dem Zeitpunkt, zu dem die Daten auf einem der oben genannten physischen Sensoren verfügbar sind, an die Anwendung gesendet werden.

  • [C-2-16] Die Leistungsaufnahme darf 0,5 mW nicht überschreiten, wenn sich das Gerät nicht bewegt, und 2,0 mW, wenn sich das Gerät bewegt, wenn eine beliebige Kombination der folgenden Sensoren aktiviert ist:

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] KANN einen TYPE_PROXIMITY-Sensor haben, muss aber einen Mindestpuffer von 100 Sensorereignissen haben.

Hinweis: Alle in diesem Abschnitt aufgeführten Anforderungen an den Stromverbrauch umfassen nicht den Stromverbrauch des Anwendungsprozessors. Sie umfasst den Stromverbrauch der gesamten Sensorkette – des Sensors, aller unterstützenden Schaltkreise und aller speziellen Sensorverarbeitungssysteme usw.

Wenn Geräteimplementierungen die direkte Sensorunterstützung umfassen, gilt Folgendes:

  • [C-3-1] MÜSSEN die Unterstützung von direkten Kanaltypen und Berichtsraten für direkte Channels über die isDirectChannelTypeSupported- und getHighestDirectReportRateLevel-API korrekt angeben.
  • [C-3-2] Es muss mindestens einer der beiden Kanaltypen für den direkten Sensor unterstützt werden.
  • MÜSSEN Ereignisberichte über den direkten Sensorkanal für den primären Sensor (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 zur Messung der Sicherheit bei der biometrischen Entsperrung finden Sie in der Dokumentation zur Messung der biometrischen Sicherheit.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm enthalten, gilt Folgendes:

  • SOLLTE einen biometrischen Sensor enthalten

Biometrische Sensoren können anhand der Akzeptanzraten von Spoofing und Identitätsdiebstahl sowie der Sicherheit der biometrischen Pipeline in die Klassen 3 (früher Stark), 2 (früher Schwach) oder 1 (früher Nutzerfreundlichkeit) eingestuft werden. Diese Klassifizierung bestimmt die Funktionen, die der biometrische Sensor für die Interaktion mit der Plattform und Drittanbieteranwendungen haben muss. Sensoren müssen die unten aufgeführten zusätzlichen Anforderungen erfüllen, wenn sie als Klasse 1, Klasse 2 oder Klasse 3 eingestuft werden sollen. Sowohl Klasse 2 als auch Klasse 3 erhalten zusätzliche Funktionen, wie unten beschrieben.

Wenn Geräteimplementierungen einen biometrischen Sensor über android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt und android.provider.Settings.ACTION_BIOMETRIC_ENROLL für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

  • [C-4-1] MUSS die Anforderungen für biometrische Verfahren der Klasse 3 oder Klasse 2 erfüllen, wie in diesem Dokument definiert.
  • [C-4-2] MUSS jeden Parameternamen erkennen und berücksichtigen, der in der Klasse Authenticators als Konstante definiert ist, sowie alle Kombinationen davon. Andernfalls dürfen keine anderen Ganzzahlkonstanten als die als öffentliche Konstanten in Authenticators dokumentierten und alle Kombinationen davon an die Methoden canAuthenticate(int) und setAllowedAuthenticators(int) übergeben werden.
  • [C-4-3] Die Aktion ACTION_BIOMETRIC_ENROLL MUSS auf Geräten mit biometrischen Funktionen der Klasse 3 oder Klasse 2 implementiert werden. Bei dieser Aktion MÜSSEN nur die Anmeldepunkte für biometrische Verfahren der Klasse 3 oder Klasse 2 angezeigt werden.

Einführung neuer Anforderungen für Android 15

  • [C-4-4] Es MUSS Anwendungen erlaubt sein, BiometricPrompt mithilfe der PromptContentView-Inhaltsanzeigeformate benutzerdefinierte Inhalte hinzuzufügen. Die Formate für die Anzeige von Inhalten DÜRFEN NICHT erweitert werden, um Bilder, Links, interaktive Inhalte oder andere Medienformen zuzulassen, die nicht bereits Teil der BiometricPrompt API sind. Stilistische Anpassungen, die diesen Inhalt nicht verändern, verdecken oder abschneiden, sind zulässig (z. B. Position, Abstand, Ränder und Typografie).

Ende der neuen Anforderungen

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

  • [C-5-1] Es MUSS standardmäßig ein zusätzlicher Bestätigungsschritt erforderlich sein (z.B. das Drücken einer Schaltfläche).
  • [C-SR-1] Es wird DRINGEND empfohlen, eine Einstellung zu haben, mit der Nutzer die App-Einstellungen überschreiben können, und immer einen Bestätigungsschritt vorauszusetzen.
  • [C-SR-2] Es wird DRINGEND empfohlen, die Bestätigungsaktion so zu sichern, dass sie nicht durch einen manipulierten Betriebssystem- oder Kernel gefälscht werden kann. Das bedeutet beispielsweise, dass die Bestätigungsaktion, die auf einer physischen Taste basiert, über einen GPIO-Pin (General Purpose Input/Output) eines Secure Elements (SE) mit nur Eingabefunktion geleitet wird, der nur durch Drücken einer physischen Taste betätigt werden kann.
  • [C-5-2] Es MUSS zusätzlich ein impliziter Authentifizierungsablauf (ohne Bestätigungsschritt) implementiert werden, der setConfirmationRequired(boolean) entspricht und von Anwendungen für Anmeldeabläufe verwendet werden kann.

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

  • [C-7-1] MÜSSEN, wenn ein biometrisches Verfahren aufgrund zu vieler fehlgeschlagener Versuche gesperrt ist (d.h. das biometrische Verfahren ist deaktiviert, bis der Nutzer die Sperre mit der primären Authentifizierung aufhebt) oder eine zeitgebundene Sperre vorliegt (d.h. das biometrische Verfahren ist vorübergehend deaktiviert, bis der Nutzer ein Zeitintervall abwartet), auch alle anderen biometrischen Verfahren einer niedrigeren biometrischen Klasse sperren. Bei einer zeitgebundenen Sperrung MUSS die Wartezeit für die biometrische Bestätigung der maximale Backoff-Zeitraum aller biometrischen Verfahren bei einer zeitgebundenen Sperrung sein.

  • [C-SR-12] Es wird DRINGEND empfohlen, dass alle anderen biometrischen Merkmale derselben biometrischen Klasse gesperrt werden, wenn ein biometrisches Merkmal aufgrund zu vieler fehlgeschlagener Versuche gesperrt wird (d.h. das biometrische Merkmal ist deaktiviert, bis der Nutzer die Sperre mit der primären Authentifizierung aufhebt) oder eine zeitgebundene Sperre erfolgt (d.h. das biometrische Merkmal ist vorübergehend deaktiviert, bis der Nutzer ein bestimmtes Zeitintervall abwartet). Bei einer zeitgebundenen Sperrung wird dringend empfohlen, dass die Backoff-Zeit für die biometrische Bestätigung der maximale Backoff-Zeitraum für alle biometrischen Verfahren bei einer zeitgebundenen Sperrung ist.

  • [C-7-2] Der Nutzer MUSS zur empfohlenen primären Authentifizierung aufgefordert werden (z. B. PIN, Muster, Passwort), um den Sperrzähler für eine biometrische Sperrung zurückzusetzen. Bei biometrischen Verfahren der Klasse 3 ist es unter Umständen zulässig, den Sperrzähler für ein gesperrtes biometrisches Verfahren derselben oder einer niedrigeren Klasse zurückzusetzen. Für biometrische Authentifizierungsmethoden der Klasse 2 oder Klasse 1 darf KEIN Zurücksetzen der Sperre möglich sein.

  • [C-SR-3] Es wird DRINGEND empfohlen, pro Authentifizierung nur eine biometrische Bestätigung zu verlangen. Wenn z. B. sowohl ein Fingerabdruck- als auch ein Gesichtssensor auf dem Gerät verfügbar sind, sollte onAuthenticationSucceeded gesendet werden, nachdem einer von beiden bestätigt wurde.

Damit Geräteimplementierungen Drittanbieter-Apps den Zugriff auf Schlüsselspeicherschlüssel gewähren können, müssen sie:

  • [C-6-1] MÜSSEN die Anforderungen für Klasse 3 erfüllen, wie in diesem Abschnitt unten definiert.
  • [C-6-2] Es DÜRFEN nur biometrische Daten der Klasse 3 verwendet werden, wenn für die Authentifizierung BIOMETRIC_STRONG erforderlich ist oder die Authentifizierung mit einem CryptoObject aufgerufen wird.

Wenn bei Geräteimplementierungen ein biometrischer Sensor als Klasse 1 (früher Nutzerfreundlichkeit) behandelt werden soll, müssen folgende Anforderungen erfüllt sein:

  • [C-1-1] Die Falsch-Akzeptanzrate DARF nicht über 0,002 % liegen.
  • [C-1-2] Es MUSS offengelegt werden, dass dieser Modus möglicherweise weniger sicher ist als eine starke PIN, ein starkes Muster oder ein starkes Passwort. Außerdem müssen die Risiken der Aktivierung klar aufgelistet werden, wenn die Akzeptanzraten für Spoofing und Identitätsdiebstahl gemäß den Android-Biometrie-Testprotokollen über 7% liegen.
  • [C-1-9] Der Nutzer MUSS zur empfohlenen primären Authentifizierung aufgefordert werden (z.B. PIN, Muster, Passwort) nach maximal 20 falschen Versuchen und einer Wartezeit von mindestens 90 Sekunden für die biometrische Bestätigung. Ein falscher Versuch ist ein Versuch mit einer ausreichenden Erfassungsqualität (BIOMETRIC_ACQUIRED_GOOD), der nicht mit einem registrierten biometrischen Merkmal übereinstimmt.
  • [C-SR-4] Es wird DRINGEND empfohlen, die Gesamtzahl der gefälschten Versuche für die biometrische Bestätigung gemäß [C-1-9] zu senken, wenn die Akzeptanzraten für Spoofing und Identitätsdiebstahl gemäß den Android-Biometrie-Testprotokollen über 7% liegen.
  • [C-1-3] Es MUSS eine Ratenbegrenzung für Versuche bei der biometrischen Bestätigung geben. Ein falscher Test ist ein Test mit einer ausreichenden Aufnahmequalität (BIOMETRIC_ACQUIRED_GOOD), der nicht mit einem registrierten biometrischen Merkmal übereinstimmt.
  • [C-SR-5] Es wird DRINGEND empfohlen, die Anzahl der Versuche nach fünf Fehlversuchen bei der biometrischen Bestätigung auf die maximale Anzahl von Fehlversuchen gemäß [C-1-9] zu begrenzen und die Versuche nach einem Fehlversuch für mindestens 30 Sekunden zu sperren. Ein Fehlversuch ist ein Versuch mit einer ausreichenden Erfassungsqualität (BIOMETRIC_ACQUIRED_GOOD), der nicht mit einer registrierten biometrischen Authentifizierung übereinstimmt.
  • [C-SR-6] Es wird DRINGEND empfohlen, die gesamte Logik zur Ratenbegrenzung in der TEE zu implementieren.
  • [C-1-10] Die biometrische Authentifizierung MUSS deaktiviert werden, sobald das Backoff der primären Authentifizierung wie in [C-0-2] in Abschnitt 9.11 beschrieben ausgelöst wurde.
  • [C-1-11] Die Akzeptanzrate für Spoofing und Identitätsdiebstahl darf maximal 30 % betragen. Dabei darf die Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten der Stufe A maximal 30 % und die Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten der Stufe B maximal 40 % betragen, gemessen gemäß den Android-Biometrie-Testprotokollen.
  • [C-1-4] Es MUSS verhindert werden, dass neue biometrische Daten hinzugefügt werden, ohne zuerst eine Vertrauenskette zu erstellen. Dazu muss der Nutzer vorhandene Anmeldedaten (PIN/Muster/Passwort) bestätigen oder neue Anmeldedaten hinzufügen, die durch die TEE gesichert sind. Die Implementierung des Android Open Source Project bietet dafür den Mechanismus im Framework.

Einführung neuer Anforderungen für Android 15

  • [C-1-5] Alle identifizierbaren biometrischen Daten eines Nutzers MÜSSEN vollständig entfernt werden, wenn das Konto des Nutzers entfernt wird (einschließlich durch Zurücksetzen auf die Werkseinstellungen) oder wenn die empfohlene primäre Authentifizierung (z.B. PIN, Muster, Passwort) entfernt wird.

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

  • [C-1-7] Der Nutzer muss mindestens alle 24 Stunden zur empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden. Hinweis: Bei der Umstellung von Geräten, die mit Android 9 oder niedriger ausgeliefert wurden, muss der Nutzer mindestens alle 72 Stunden zur empfohlenen primären Authentifizierung aufgefordert werden (z. B. PIN, Muster oder Passwort).

Ende der neuen Anforderungen

Einführung neuer Anforderungen für Android 15

  • [C-1-8] Der Nutzer muss nach einem der folgenden Ereignisse zur empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) oder biometrischen Authentifizierung der Klasse 3 (STARK) aufgefordert werden:
    • ein Zeitlimit von 4 Stunden für die Inaktivität ODER
    • 3 fehlgeschlagene biometrische Authentifizierungsversuche.
    • Die Zeitüberschreitung bei Inaktivität und die Anzahl der fehlgeschlagenen Authentifizierungen werden nach jeder erfolgreichen Bestätigung der Geräteanmeldedaten zurückgesetzt. Hinweis: Upgrades auf Geräten, die mit Android 9 oder niedriger ausgeliefert wurden, KÖNNEN von C-1-8 ausgenommen werden.

Ende der neuen Anforderungen

  • [C-SR-7] Es wird DRINGEND empfohlen, die Logik im Framework des Android Open Source Project zu verwenden, um die in [C-1-7] und [C-1-8] für neue Geräte angegebenen Einschränkungen durchzusetzen.
  • [C-SR-8] Es wird DRINGEND empfohlen, dass die Falschablehnungsrate unter 10 % liegt, gemessen auf dem Gerät.
  • [C-SR-9] Es wird DRINGEND empfohlen, für jede registrierte biometrische Authentifizierung eine Latenz von weniger als einer Sekunde zu haben, gemessen vom Zeitpunkt der Erkennung des biometrischen Faktors bis zur Entsperrung des Displays.
  • [C-1-12] Die Akzeptanzrate für Spoofing und Identitätsdiebstahl darf gemäß den Android-Biometrie-Testprotokollen nicht über 40 % pro Art von Präsentationsangriffsinstrument (PAI) liegen.
  • [C-SR-13] Es wird DRINGEND empfohlen, dass die Akzeptanzrate von Spoofing und Identitätsdiebstahl nicht über 30 % liegt, je nach Art des Präsentationsangriffsinstruments (PAI), gemessen anhand der Android-Biometrie-Testprotokolle.
  • [C-SR-8] Es wird DRINGEND empfohlen, dass die Falschablehnungsrate unter 10 % liegt, gemessen auf dem Gerät.

Einführung neuer Anforderungen für Android 15

  • [C-1-15] Nutzer MÜSSEN die Möglichkeit haben, einzelne oder mehrere biometrische Registrierungen zu entfernen.

Ende der neuen Anforderungen

  • [C-SR-14] Es wird DRINGEND empfohlen, die biometrische Klasse des biometrischen Sensors und die entsprechenden Risiken der Aktivierung offenzulegen.

  • [C-SR-17] Es wird DRINGEND empfohlen, die neuen AIDL-Schnittstellen (z. B. IFace.aidl und IFingerprint.aidl) zu implementieren.

Wenn bei Geräteimplementierungen ein biometrischer Sensor als Klasse 2 (früher schwach) behandelt werden soll, müssen folgende Anforderungen erfüllt sein:

  • [C-2-1] MÜSSEN alle Anforderungen für Klasse 1 oben erfüllen.
  • [C-2-2] Die Akzeptanzrate für Spoofing und Identitätsdiebstahl darf maximal 20 % betragen. Dabei darf (1) die Akzeptanzrate für Spoofing und Identitätsdiebstahl bei PAI-Arten der Stufe A maximal 20 % und (2) die Akzeptanzrate für Spoofing und Identitätsdiebstahl bei PAI-Arten der Stufe B maximal 30 % betragen. Dies wird gemäß den Android-Biometrie-Testprotokollen gemessen.
  • [C-SR-15] Es wird DRINGEND empfohlen, dass die Akzeptanzrate von Spoofing und Identitätsdiebstahl nicht über 20 % liegt, je nach Art des Präsentationsangriffsinstruments (PAI), gemessen anhand der Android-Biometrie-Testprotokolle.
  • [C-2-3] Der biometrische Abgleich MUSS in einer isolierten Ausführungsumgebung außerhalb des Android-Nutzer- oder Kernel-Bereichs erfolgen, z. B. in der Trusted Execution Environment (TEE), auf einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder auf einer geschützten virtuellen Maschine, die die Anforderungen in Abschnitt 9.17 erfüllt.
  • [C-2-4] Alle identifizierbaren Daten MÜSSEN verschlüsselt und kryptografisch authentifiziert sein, sodass sie außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal zur isolierten Ausführungsumgebung nicht abgerufen, 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 beschrieben, die von einem Hypervisor gesteuert wird und die Anforderungen in Abschnitt 9.17 erfüllt.
  • [C-2-5] Bei kamerabasierter Biometrie während der biometrischen Authentifizierung oder Registrierung:
    • Die Kamera MUSS in einem Modus betrieben werden, der verhindert, dass Kameraframes außerhalb der isolierten Ausführungsumgebung gelesen oder geändert werden. Alternativ kann ein Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder eine vom Hypervisor gesteuerte geschützte virtuelle Maschine verwendet werden, die die Anforderungen in Abschnitt 9.17 erfüllt.
    • Bei RGB-Einzelkameralösungen können die Kameraframes außerhalb der isolierten Ausführungsumgebung gelesen werden, um Vorgänge wie die Vorschau für die Registrierung zu unterstützen. Sie dürfen jedoch NICHT verändert werden.
  • [C-2-6] Drittanbieter-Anwendungen dürfen KEINE Möglichkeit haben, zwischen einzelnen biometrischen Registrierungen zu unterscheiden.
  • [C-2-7] Der Anwendungsprozessor darf außerhalb des Kontexts der TEE oder der geschützten virtuellen Maschine, die vom Hypervisor gesteuert wird und die Anforderungen in Abschnitt 9.17 erfüllt, KEIN unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder abgeleitete Daten (z. B. Einbettungen) erhalten. Geräte, die mit Android-Version 9 oder niedriger ausgeliefert wurden, sind von C-2-7 nicht ausgenommen.
  • [C-2-8] Es MUSS eine sichere Verarbeitungspipeline geben, damit bei einem Betriebssystem- oder Kernel-Hack keine Daten direkt eingefügt werden können, um sich als Nutzer zu fälschlicherweise zu authentifizieren. Hinweis: Wenn Geräteimplementierungen bereits mit Android-Version 9 oder niedriger gestartet wurden und die Anforderung C-2-8 nicht durch ein Systemsoftwareupdate erfüllt werden kann, können sie von der Anforderung AUSGESCHLOSSEN werden.

  • [C-SR-10] Es wird DRINGEND empfohlen, die Echtheitsprüfung für alle biometrischen Modalitäten und die Aufmerksamkeitserkennung für die Gesichtserkennung einzubinden.

  • [C-2-9] Der biometrische Sensor MUSS für Drittanbieter-Apps verfügbar sein.

Wenn bei Geräteimplementierungen ein biometrischer Sensor als Klasse 3 (früher Hoch) behandelt werden soll, müssen folgende Anforderungen erfüllt sein:

  • [C-3-1] MUSS alle Anforderungen der Klasse 2 oben erfüllen, mit Ausnahme von [C-1-7] und [C-1-8].
  • [C-3-2] Es MUSS eine hardwaregestützte Schlüsselspeicherimplementierung geben.
  • [C-3-3] Die Akzeptanzrate für Spoofing und Identitätsdiebstahl darf maximal 7 % betragen. Dabei darf die Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten der Stufe A maximal 7 % und die Akzeptanzrate für Spoofing und Identitätsdiebstahl für PAI-Arten der Stufe B maximal 20 % betragen, gemessen gemäß den Android-Biometrie-Testprotokollen.
  • [C-3-4] Der Nutzer MUSS mindestens alle 72 Stunden zur empfohlenen primären Authentifizierung aufgefordert werden (z. B. PIN, Muster, Passwort).
  • [C-3-5] Die Authenticator-ID muss für alle biometrischen Authentifizierungsmethoden der Klasse 3 neu generiert werden, die auf dem Gerät unterstützt werden, wenn eine davon neu registriert wird.
  • [C-3-6] Für Drittanbieteranwendungen müssen biometrisch gesicherte Schlüsselspeicherschlüssel aktiviert sein.

  • [C-SR-16] Es wird DRINGEND empfohlen, dass die Akzeptanzrate von Spoofing und Impostern nicht höher als 7% pro Art von Präsentationsangriffsinstrument (PAI) ist, gemessen anhand der Android-Biometrie-Testprotokolle.

Wenn Geräteimplementierungen einen Fingerabdrucksensor unter dem Display haben, gilt Folgendes:

  • [C-SR-11] Es wird DRINGEND empfohlen, zu verhindern, dass der berührbare Bereich des UDFPS die Navigation mit drei Tasten beeinträchtigt, die einige Nutzer aus Gründen der Barrierefreiheit benötigen könnten.

7.3.11. Positionssensor

Geräteimplementierungen:

  • Es wird unter Umständen ein Positionssensor mit 6 Freiheitsgraden unterstützt.

Wenn Geräteimplementierungen einen 6-Achsen-Pose-Sensor unterstützen, gilt Folgendes:

  • [C-1-1] Der TYPE_POSE_6DOF-Sensor MUSS implementiert und erfasst werden.
  • [C-1-2] MÜSSEN genauer sein als der Drehvektor allein.

7.3.12. Scharnierwinkelsensor

Wenn die Geräteimplementierung einen Scharnierwinkelsensor unterstützt, gilt Folgendes:

7.3.13. IEEE 802.1.15.4 (UWB)

Wenn Geräteimplementierungen 802.1.15.4 unterstützen und die Funktion für eine Drittanbieteranwendung freigeben, müssen sie:

  • [C-1-2] Das Hardware-Funktions-Flag android.hardware.uwb MUSS gemeldet werden.
  • [C-1-3] MUSS alle folgenden Konfigurationssätze (vordefinierte Kombinationen von FIRA UCI-Parametern) unterstützen, die in der AOSP-Implementierung definiert sind.
    • CONFIG_ID_1: Von FiRa definierte Unicast-STATIC STS DS-TWR-Messung, verzögerter Modus, Messintervall 240 ms.
    • CONFIG_ID_2: Von FiRa definierte STATIC STS DS-TWR-Triangulation „Eins-zu-viele“, verzögerter Modus, Intervall für die Triangulation 200 ms. Typischer Anwendungsfall: Smartphone interagiert mit vielen intelligenten Geräten.
    • CONFIG_ID_3: Entspricht CONFIG_ID_1, mit der Ausnahme, dass keine Daten zum Einfallswinkel (Angle of Arrival, AoA) erfasst werden.
    • CONFIG_ID_4: Entspricht CONFIG_ID_1, mit der Ausnahme, dass der P-STS-Sicherheitsmodus aktiviert ist.
    • CONFIG_ID_5: Entspricht CONFIG_ID_2, mit der Ausnahme, dass der P-STS-Sicherheitsmodus aktiviert ist.
    • CONFIG_ID_6: Entspricht CONFIG_ID_3, mit der Ausnahme, dass der P-STS-Sicherheitsmodus aktiviert ist.
    • CONFIG_ID_7: Entspricht CONFIG_ID_2, mit der Ausnahme, dass der Modus für den individuellen Schlüssel des P-STS-Kontrollobjekts aktiviert ist.
  • [C-1-4] Es MUSS eine Nutzerfunktion geben, mit der der Nutzer den UWB-Funk ein- und ausschalten kann.
  • [C-1-5] Es MUSS erzwungen werden, dass Apps, die UWB-Funk verwenden, die Berechtigung UWB_RANGING (unter der Berechtigungsgruppe NEARBY_DEVICES) haben.

Wenn die relevanten Konformitäts- und Zertifizierungstests bestanden werden, die von Standardsorganisationen wie FIRA, CCC und CSA definiert wurden, ist die korrekte Funktion von 802.1.15.4 gewährleistet.

7.4. Datenverbindung

7.4.1. Telefonie

„Telefonie“ in den Android APIs und in diesem Dokument bezieht sich speziell auf Hardware, die für das Tätigen von Sprachanrufen und das Senden von SMS oder für die Einrichtung mobiler Daten über ein Mobilfunknetz (z.B. GSM, CDMA, LTE, NR) verwendet wird. Ein Gerät, das „Telefonie“ unterstützt, kann einige oder alle Anruf-, Messaging- und Datendienste anbieten, die zum Produkt passen.

  • Android KANN auf Geräten verwendet werden, die keine Telefoniehardware enthalten. Android ist also mit Geräten kompatibel, die keine Smartphones sind.

Wenn die Geräteimplementierungen GSM- oder CDMA-Telefonie umfassen, gelten folgende Anforderungen:

  • [C-1-1] DAS android.hardware.telephony-Funktions-Flag und andere untergeordnete Funktions-Flags MÜSSEN gemäß der Technologie deklariert werden.
  • [C-1-2] Es MUSS eine vollständige Unterstützung der API für diese Technologie implementiert werden.
  • MÜSSEN alle verfügbaren Mobilfunkdiensttypen (2G, 3G, 4G, 5G usw.) bei Notrufen zulassen (unabhängig von den von SetAllowedNetworkTypeBitmap() festgelegten Netzwerktypen).

Wenn Geräteimplementierungen keine Telefoniehardware enthalten, gelten folgende Anforderungen:

  • [C-2-1] Die APIs MÜSSEN vollständig als No-Ops implementiert werden.

Wenn Geräteimplementierungen eUICCs oder eSIMs/eingebettete SIMs unterstützen und einen proprietären Mechanismus enthalten, um die eSIM-Funktion für Drittanbieter zu ermöglichen, müssen sie:

Wenn die Systemeigenschaft ro.telephony.iwlan\_operation\_mode in Geräteimplementierungen nicht auf „legacy“ gesetzt wird, gilt Folgendes:

Wenn Geräteimplementierungen eine einzelne IMS-Registrierung (IP Multimedia Subsystem) sowohl für MMTEL- (Multimedia Telephony Service) als auch für RCS-Funktionen (Rich Communication Services) unterstützen und voraussichtlich die Anforderungen von Mobilfunkanbietern zur Verwendung einer einzelnen IMS-Registrierung für den gesamten IMS-Signalisierungsverkehr erfüllen, müssen sie:

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

Wenn die Geräteimplementierungen die android.hardware.telephony-Funktion melden und eine Systemstatusleiste bereitstellen, gilt Folgendes:

  • [C-7-1] Es MUSS ein repräsentatives aktives Abo für eine bestimmte Gruppen-UUID ausgewählt werden, das dem Nutzer in allen Funktionen angezeigt wird, die Informationen zum SIM-Status enthalten. Beispiele für solche Angebote sind das Symbol für das Mobilfunksignal in der Statusleiste oder die Kachel für die Schnelleinstellungen.
  • [C-SR-1] Es wird DRINGEND empfohlen, das repräsentative Abo als aktives Datenabo auszuwählen, es sei denn, das Gerät befindet sich in einem Sprachanruf. In diesem Fall wird DRINGEND empfohlen, das repräsentative Abo als aktives Sprachabo auszuwählen.

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

  • [C-6-7] MUSS die maximale Anzahl logischer Kanäle (insgesamt 20) für jede UICC gemäß ETSI TS 102 221 öffnen und gleichzeitig nutzen können.
  • [C-6-8] Keine der folgenden Aktionen darf automatisch oder ohne explizite Nutzerbestätigung auf aktive Mobilfunkanbieter-Apps (wie von TelephonyManager#getCarrierServicePackageName angegeben) angewendet werden:
    • Netzwerkzugriff widerrufen oder einschränken
    • Berechtigungen widerrufen
    • Ausführung von Apps im Hintergrund oder im Vordergrund über die in AOSP enthaltenen Energieverwaltungsfunktionen hinaus einschränken
    • App deaktivieren oder deinstallieren

Wenn die Geräteimplementierungen die android.hardware.telephony-Funktion melden und alle aktiven, nicht opportunistischen Abos, die eine Gruppen-UUID teilen, deaktiviert, physisch vom Gerät entfernt oder als opportunistisch gekennzeichnet sind, gilt für das Gerät Folgendes:

  • [C-8-1] Alle verbleibenden aktiven opportunistischen Abos in derselben Gruppe MÜSSEN automatisch deaktiviert werden.

Wenn Geräteimplementierungen GSM-Telefonie, aber keine CDMA-Telefonie umfassen, gilt Folgendes:

  • [C-9-1] PackageManager#FEATURE_TELEPHONY_CDMA DÜRFEN NICHT deklariert werden.
  • [C-9-2] Es MUSS eine IllegalArgumentException geworfen werden, wenn versucht wird, 3GPP2-Netzwerktypen in Bitmasken für bevorzugte oder zulässige Netzwerktypen festzulegen.
  • [C-9-3] Es MUSS ein leerer String von TelephonyManager#getMeid zurückgegeben werden.

Wenn die Geräteimplementierungen eUICCs mit mehreren Ports und Profilen unterstützen, gilt Folgendes:

7.4.1.1. Kompatibilität mit der Nummernblockierung

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

  • [C-1-1] MUSS die Blockierung von Nummern unterstützen
  • [C-1-2] BlockedNumberContract und die entsprechende API MÜSSEN vollständig gemäß der SDK-Dokumentation implementiert werden.
  • [C-1-3] Alle Anrufe und Nachrichten von einer Telefonnummer in 'BlockedNumberProvider' MÜSSEN ohne Interaktion mit Apps blockiert werden. Die einzige Ausnahme ist, wenn die Blockierung von Nummern wie in der SDK-Dokumentation beschrieben vorübergehend aufgehoben wird.

  • [C-1-4] MUSS bei einem blockierten Anruf an den Anruflistenanbieter der Plattform schreiben und MUSS Anrufe mit BLOCKED_TYPE aus der Standardanruflistenansicht in der vorinstallierten Telefon-App herausfiltern.

  • [C-1-5] Darf nicht an den Telefonieanbieter wegen einer blockierten Nachricht schreiben.

  • [C-1-6] Es MUSS eine Benutzeroberfläche zum Verwalten blockierter Nummern implementiert werden, die mit dem Intent geöffnet wird, der von der TelecomManager.createManageBlockedNumbersIntent()-Methode zurückgegeben wird.

  • [C-1-7] Sekundäre Nutzer dürfen die blockierten Nummern auf dem Gerät NICHT ansehen oder bearbeiten, da die Android-Plattform davon ausgeht, dass der Hauptnutzer die vollständige Kontrolle über die Telefondienste auf dem Gerät hat. Alle blockierungsbezogenen UI-Elemente MÜSSEN für sekundäre Nutzer ausgeblendet sein und die Blockierungsliste MUSS weiterhin berücksichtigt werden.

  • Die blockierten Nummern MÜSSEN zum Anbieter migriert werden, wenn ein Gerät auf Android 7.0 aktualisiert wird.

  • Es sollte eine Option geben, blockierte Anrufe in der vorinstallierten Telefon-App anzuzeigen.

7.4.1.2. Telecom API

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

  • [C-1-1] MÜSSEN die im SDK beschriebenen ConnectionService APIs unterstützen.
  • [C-1-2] Es MUSS ein neuer eingehender Anruf angezeigt werden und der Nutzer muss die Möglichkeit haben, den Anruf anzunehmen oder abzulehnen, wenn er sich in einem laufenden Anruf befindet, der über eine Drittanbieter-App erfolgt, die die über CAPABILITY_SUPPORT_HOLD angegebene Funktion „Anruf pausieren“ nicht unterstützt.
  • [C-1-3] Es MUSS eine Anwendung geben, die InCallService implementiert.
  • [C-SR-1] Es wird DRINGEND empfohlen, den Nutzer darüber zu informieren, dass ein laufender Anruf beendet wird, wenn er einen eingehenden Anruf annimmt.

    Die AOSP-Implementierung erfüllt diese Anforderungen durch eine Benachrichtigung, die den Nutzer darüber informiert, dass durch das Annehmen eines eingehenden Anrufs der andere Anruf beendet wird.

  • [C-SR-2] Es wird DRINGEND empfohlen, die Standard-Anruf-App vorab zu laden, die einen Anrufprotokolleintrag und den Namen einer Drittanbieter-App im Anrufprotokoll anzeigt, wenn die Drittanbieter-App den Schlüssel „Extras“ in PhoneAccount auf true festlegt.EXTRA_LOG_SELF_MANAGED_CALLS

  • [C-SR-3] Es wird DRINGEND empfohlen, die Ereignisse KEYCODE_MEDIA_PLAY_PAUSE und KEYCODE_HEADSETHOOK des Audioheadsets für die android.telecom-APIs wie unten beschrieben zu verarbeiten:

    • Ruft Connection.onDisconnect() auf, wenn während eines laufenden Anrufs eine kurze Betätigung des Schlüsselereignisses erkannt wird.
    • Ruft Connection.onAnswer() auf, wenn während eines eingehenden Anrufs eine kurze Betätigung des Schlüsselereignisses erkannt wird.
    • Ruft Connection.onReject() auf, wenn während eines eingehenden Anrufs das Schlüsselereignis lange gedrückt wird.
    • Aktivieren oder deaktivieren Sie die Stummschaltung der CallAudioState.
7.4.1.3. NAT-T-Keepalive-Offload für Mobilfunk

Geräteimplementierungen:

  • MÜSSEN die Unterstützung für das Offload von keepalive-Nachrichten über das Mobilfunknetz umfassen.

Wenn die Geräteimplementierungen die Unterstützung für das Offload von keepalive-Nachrichten über das Mobilfunknetz umfassen und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

  • [C-1-1] MUSS die SocketKeepAlive API unterstützen.
  • [C-1-2] Es muss mindestens ein gleichzeitiger keepalive-Slot über das Mobilfunknetz unterstützt werden.
  • [C-1-3] MUSS so viele gleichzeitige zellulare keepalive-Slots unterstützen, wie vom HAL für Mobilfunk unterstützt werden.
  • [C-SR-1] Es wird DRINGEND empfohlen, mindestens drei Mobilfunk-Keepalive-Slots pro Funkschnittstelle zu unterstützen.

Wenn die Geräteimplementierungen keine Unterstützung für das Offload von keepalive-Nachrichten über das Mobilfunknetz bieten, gilt Folgendes:

  • [C-2-1] MUSS ERROR_UNSUPPORTED zurückgeben.

7.4.2. IEEE 802.11 (Wi‑Fi)

Geräteimplementierungen:

  • MÜSSEN eine oder mehrere Formen von 802.11 unterstützen.

Wenn Geräteimplementierungen 802.11 unterstützen und die Funktion für eine Drittanbieteranwendung freigeben, gelten folgende Anforderungen:

  • [C-1-1] Die entsprechende Android API MUSS implementiert werden.
  • [C-1-2] Das Hardware-Funktions-Flag android.hardware.wifi MUSS gemeldet werden.
  • [C-1-3] Die Multicast API muss wie in der SDK-Dokumentation beschrieben implementiert sein.

Einführung neuer Anforderungen für Android 15

  • [C-1-4] MUSS Multicast-DNS (mDNS) unterstützen und DARF mDNS-Pakete (224.0.0.251 oder ff02::fb) zu keinem Zeitpunkt während des Betriebs filtern, auch nicht, wenn sich das Display nicht im aktiven Zustand befindet, es sei denn, das Auswerfen oder Filtern dieser Pakete ist erforderlich, um den für den Zielmarkt geltenden Grenzwert für den Energieverbrauch einzuhalten.

  • [C-1-4] MDNS MUSS unterstützt und MDNS-Pakete (224.0.0.251 oder ff02::fb) MÜSSEN zu jeder Betriebszeit gefiltert werden, auch wenn sich der Bildschirm nicht im aktiven Zustand befindet, es sei denn, die Multicast-Sperre wird nicht gehalten und die Pakete werden durch APF gefiltert. Die Pakete müssen keine mDNS-Vorgänge erfüllen, die derzeit von Anwendungen über die NsdManager APIs angefordert werden. Das Gerät darf jedoch mDNS-Pakete filtern, wenn dies erforderlich ist, um den für den Zielmarkt geltenden gesetzlichen Anforderungen an den Energieverbrauch nachzukommen.

Ende der neuen Anforderungen

  • [C-1-5] Der API-Methodenaufruf WifiManager.enableNetwork() darf NICHT als ausreichender Hinweis zum Wechseln der aktuell aktiven Network behandelt werden, die standardmäßig für den Anwendungsverkehr verwendet und von ConnectivityManager-API-Methoden wie getActiveNetwork und registerDefaultNetworkCallback zurückgegeben wird. Mit anderen Worten: Sie KÖNNEN den Internetzugriff eines anderen Netzwerkanbieters (z.B. Mobilfunkanbieter) nur dann deaktivieren, wenn sie bestätigt haben, dass das WLAN-Netzwerk Internetzugriff bietet.
  • [C-1-6] Es wird DRINGEND empfohlen, den Internetzugriff auf dem Network noch einmal zu prüfen, wenn die API-Methode ConnectivityManager.reportNetworkConnectivity() aufgerufen wird. Sobald festgestellt wurde, dass der aktuelle Network keinen Internetzugriff mehr bietet, wechseln Sie zu einem anderen verfügbaren Netzwerk (z. B. mobile Daten), das Internetzugriff bietet.
  • [C-1-7] Die MAC-Quelladresse und die Sequenznummer der Probeanfrageframes MÜSSEN einmal zu Beginn jedes Scans zufällig generiert werden, während die STA getrennt ist.
  • [C-1-8] Es MUSS eine einheitliche MAC-Adresse verwendet werden. Die MAC-Adresse DARF nicht in der Mitte eines Scans zufällig generiert werden.
  • [C-1-9] Die Sequenznummer der Probeanfrage MUSS wie gewohnt (sequentiell) zwischen den Probeanfragen in einem Scan iteriert werden.
  • [C-1-10] Die Sequenznummer der Prüfanfrage MUSS zwischen der letzten Prüfanfrage eines Scans und der ersten Prüfanfrage des nächsten Scans zufällig generiert werden.
  • [C-SR-1] Es wird DRINGEND empfohlen, die MAC-Quelladresse zufällig zu generieren, die für die gesamte STA-Kommunikation mit einem Zugangspunkt (Access Point, AP) während der Verknüpfung und der Verknüpfung verwendet wird.
    • Das Gerät MUSS für jede SSID (FQDN für Passpoint), mit der es kommuniziert, eine andere zufällige MAC-Adresse verwenden.
    • Das Gerät MUSS dem Nutzer die Möglichkeit bieten, die Zufallsmix-Funktion pro SSID (FQDN für Passpoint) mit nicht zufälligen und zufälligen Optionen zu steuern und MUSS den Standardmodus für neue WLAN-Konfigurationen auf „Zufallsmix“ festlegen.
  • [C-SR-2] Es wird DRINGEND empfohlen, für jeden erstellten ZP eine zufällige BSSID zu verwenden.
    • Die MAC-Adresse MUSS zufällig generiert und für jede vom ZP verwendete SSID gespeichert werden.
    • Das GERÄT KANN dem Nutzer die Möglichkeit bieten, diese Funktion zu deaktivieren. Wenn eine solche Option vorhanden ist, MUSS die Zufallsmix-Funktion standardmäßig aktiviert sein.

Wenn die Geräteimplementierungen den im IEEE 802.11-Standard definierten WLAN-Energiesparmodus unterstützen, gilt Folgendes:

  • Der Energiesparmodus für WLAN sollte deaktiviert werden, wenn eine App über die APIs WifiManager.createWifiLock() und WifiManager.WifiLock.acquire() die Sperre WIFI_MODE_FULL_HIGH_PERF oder WIFI_MODE_FULL_LOW_LATENCY erwirkt und die Sperre aktiv ist.
  • [C-3-2] Die durchschnittliche Laufzeit zwischen dem Gerät und einem Zugangspunkt, während sich das Gerät im Modus „Wi-Fi Low Latency Lock“ (WIFI_MODE_FULL_LOW_LATENCY) befindet, MUSS kleiner sein als die Laufzeit im Modus „Wi-Fi High Perf Lock“ (WIFI_MODE_FULL_HIGH_PERF).
  • [C-SR-3] Es wird DRINGEND empfohlen, die WLAN-Rücklauflatenz zu minimieren, wenn eine Sperre für niedrige Latenz (WIFI_MODE_FULL_LOW_LATENCY) erworben und wirksam wird.

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

  • [C-2-1] Es MUSS eine Nutzerfunktion geben, mit der der über die API-Methode WifiManager.isScanAlwaysAvailable gelesene Wert aktiviert oder deaktiviert werden kann.
7.4.2.1. Wi-Fi Direct

Geräteimplementierungen:

  • MÜSSEN Wi‑Fi Direct (Wi‑Fi-Peer-to-Peer) unterstützen.

Wenn die Geräteimplementierung Wi‑Fi Direct unterstützt, gilt Folgendes:

  • [C-1-1] Die entsprechende Android API muss wie in der SDK-Dokumentation beschrieben implementiert sein.
  • [C-1-2] Die Hardwarefunktion android.hardware.wifi.direct MUSS erfasst werden.
  • [C-1-3] MUSS den regulären WLAN-Betrieb unterstützen.
  • [C-1-4] MUSS WLAN und Wi‑Fi Direct gleichzeitig unterstützen.
  • [C-SR-1] Es wird EMPFOHLEN, die MAC-Quelladresse für alle neu hergestellten Wi‑Fi Direct-Verbindungen zufällig zu generieren.

Geräteimplementierungen:

Wenn Geräteimplementierungen TDLS unterstützen und TDLS über die WiFiManager API aktiviert ist, gilt Folgendes:

  • [C-1-1] MÜSSEN die Unterstützung für TDLS über WifiManager.isTdlsSupported deklarieren.
  • TDLS sollte nur verwendet werden, wenn es möglich UND vorteilhaft ist.
  • SOLLTE eine Heuristik haben und TDLS NICHT verwenden, wenn die Leistung möglicherweise schlechter ist als über den WLAN-Zugangspunkt.
7.4.2.3. Wi‑Fi Aware

Geräteimplementierungen:

Wenn Geräteimplementierungen die Unterstützung von Wi‑Fi Aware umfassen und die Funktion für Drittanbieter-Apps freigeben, gilt Folgendes:

  • [C-1-1] Die WifiAwareManager APIs MÜSSEN wie in der SDK-Dokumentation beschrieben implementiert werden.
  • [C-1-2] Das android.hardware.wifi.aware-Funktions-Flag MUSS deklariert werden.
  • [C-1-3] MUSS WLAN- und Wi‑Fi Aware-Vorgänge gleichzeitig unterstützen.
  • [C-1-4] Die Adresse der Wi‑Fi Aware-Verwaltungsschnittstelle MUSS in Intervallen von maximal 30 Minuten und immer dann zufällig generiert werden, wenn Wi‑Fi Aware aktiviert ist, es sei denn, ein Aware-Suchvorgang ist in Bearbeitung oder ein Aware-Datenpfad ist aktiv. Die Zufallsgenerierung ist nicht erforderlich, solange der Datenpfad aktiv ist.

Wenn die Geräteimplementierungen die Unterstützung für Wi‑Fi Aware und WLAN-Standort wie in Abschnitt 7.4.2.5 beschrieben umfassen und diese Funktionen für Drittanbieter-Apps verfügbar machen, gelten folgende Anforderungen:

7.4.2.4. Wi‑Fi Passpoint

Wenn Geräteimplementierungen 802.11 (Wi‑Fi) unterstützen, gilt Folgendes:

  • [C-1-1] MUSS Wi‑Fi Passpoint unterstützen.
  • [C-1-2] Die Passpoint-bezogenen WifiManager APIs MÜSSEN wie in der SDK-Dokumentation beschrieben implementiert werden.
  • [C-1-3] MUSS den IEEE 802.11u-Standard unterstützen, insbesondere im Zusammenhang mit der Netzwerkerkennung und ‑auswahl, z. B. Generic Advertisement Service (GAS) und Access Network Query Protocol (ANQP).
  • [C-1-4] Das android.hardware.wifi.passpoint-Funktions-Flag MUSS deklariert werden.
  • [C-1-5] MUSS der AOSP-Implementierung folgen, um Passpoint-Netzwerke zu finden, abzugleichen und zu verknüpfen.
  • [C-1-6] MUSS mindestens die folgenden Protokolle zur Gerätebereitstellung unterstützen, wie in der Wi‑Fi Alliance Passpoint R2-Spezifikation definiert: EAP-TTLS-Authentifizierung und SOAP-XML.
  • [C-1-7] Das AAA-Serverzertifikat MUSS gemäß der Hotspot 2.0 R3-Spezifikation verarbeitet werden.
  • [C-1-8] Die Bereitstellung muss über die WLAN-Auswahl vom Nutzer gesteuert werden können.
  • [C-1-9] Passpoint-Konfigurationen MÜSSEN nach Neustarts beibehalten werden.
  • [C-SR-1] Es wird DRINGEND empfohlen, die Funktion zur Akzeptanz der Nutzungsbedingungen zu unterstützen.
  • [C-SR-2] Es wird DRINGEND empfohlen, die Funktion „Informationen zum Veranstaltungsort“ zu unterstützen.

Wenn ein globaler Schalter für die Deaktivierung der Nutzersteuerung für Passpoint vorhanden ist, gilt für Implementierungen Folgendes:

  • [C-3-1] Passpoint muss standardmäßig aktiviert sein.
7.4.2.5. WLAN-Standort (WLAN-Umlaufzeit – RTT)

Geräteimplementierungen:

Wenn Geräteimplementierungen die WLAN-Standortermittlung unterstützen und die Funktion für Drittanbieter-Apps freigeben, gilt Folgendes:

  • [C-1-1] Die WifiRttManager APIs MÜSSEN wie in der SDK-Dokumentation beschrieben implementiert werden.
  • [C-1-2] Das android.hardware.wifi.rtt-Funktions-Flag MUSS deklariert werden.
  • [C-1-3] Die MAC-Quelladresse für jeden RTT-Burst muss zufällig generiert werden, der ausgeführt wird, während die WLAN-Schnittstelle, auf der die RTT ausgeführt wird, keinem Zugangspunkt zugeordnet ist.
  • [C-1-4] MÜSSEN bei einer Bandbreite von 80 MHz im 68. Perzentil (berechnet mit der kumulativen Verteilungsfunktion) auf 2 Meter genau sein.
  • [C-SR-1] Es wird DRINGEND empfohlen, die Abdeckung genau auf ± 1,5 Meter bei 80 MHz Bandbreite im 68.Perzentil (berechnet mit der kumulativen Verteilungsfunktion) zu erfassen.
7.4.2.6. WLAN-Keepalive-Offload

Geräteimplementierungen:

  • MÜSSEN die Unterstützung für das Offload von keepalive-Nachrichten für WLANs umfassen.

Wenn Geräteimplementierungen die Unterstützung für das Offload von WLAN-Keepalives umfassen und die Funktion für Drittanbieter-Apps freigeben, gilt Folgendes:

  • [C-1-1] MUSS die SocketKeepAlive API unterstützen.
  • [C-1-2] MUSS mindestens drei gleichzeitige keepalive-Slots über WLAN unterstützen

Wenn die Geräteimplementierungen keine Unterstützung für das Offload von WLAN-Keepalives bieten, gilt Folgendes:

7.4.2.7. Wi‑Fi Easy Connect (Device Provisioning Protocol)

Geräteimplementierungen:

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

7.4.2.8. Validierung des Zertifikats für Enterprise-WLAN-Server

Wenn das Zertifikat des WLAN-Servers nicht validiert oder der Domainname des WLAN-Servers nicht festgelegt ist, gilt für Geräteimplementierungen Folgendes:

  • [C-SR-1] Es wird DRINGEND empfohlen, Nutzern nicht die Möglichkeit zu geben, ein Enterprise-WLAN manuell in den Einstellungen hinzuzufügen.
7.4.2.9. Bei der ersten Verwendung als vertrauenswürdig einstufen (Trust On First Use, TOFU)

Wenn Geräteimplementierungen „Vertrauen bei der ersten Verwendung“ (Trust on First Use, TOFU) unterstützen und es dem Nutzer ermöglichen, WPA-/WPA2-/WPA3-Enterprise-Konfigurationen zu definieren, gilt Folgendes:

  • [C-4-1] MUSS Nutzern die Möglichkeit bieten, TOFU zu verwenden.

7.4.3. Bluetooth

Wenn die Geräteimplementierungen das Bluetooth Audio-Profil unterstützen, gilt Folgendes:

  • MÜSSEN erweiterte Audio-Codecs und Bluetooth-Audio-Codecs unterstützen (z.B. LDAC)

Wenn Geräteimplementierungen HFP, A2DP und AVRCP unterstützen, gilt Folgendes:

  • Es sollte mindestens fünf verbundene Geräte unterstützen.

Wenn in Geräteimplementierungen die android.hardware.vr.high_performance-Funktion deklariert wird, gilt Folgendes:

  • [C-1-1] MUSS Bluetooth 4.2 und die Bluetooth LE Data Length Extension unterstützen.

Android unterstützt Bluetooth und Bluetooth Low Energy.

Wenn die Geräteimplementierungen Bluetooth und Bluetooth Low Energy unterstützen, gilt Folgendes:

  • [C-2-1] MÜSSEN die relevanten Plattformfunktionen (android.hardware.bluetooth und android.hardware.bluetooth_le) deklarieren und die Plattform-APIs implementieren.
  • MÜSSEN relevante Bluetooth-Profile wie A2DP, AVRCP, OBEX, HFP usw. implementieren, je nach Gerät.

Wenn die Geräteimplementierungen Bluetooth Low Energy (BLE) unterstützen, gilt Folgendes:

  • [C-3-1] Die Hardwarefunktion android.hardware.bluetooth_le MUSS deklariert werden.
  • [C-3-2] Sie MÜSSEN die GATT-basierten (Generic Attribute Profile) Bluetooth APIs aktivieren, wie in der SDK-Dokumentation und unter android.bluetooth beschrieben.
  • [C-3-3] Es MUSS der richtige Wert für BluetoothAdapter.isOffloadedFilteringSupported() angegeben werden, um anzugeben, ob die Filterlogik für die ScanFilter API-Klassen implementiert ist.
  • [C-3-4] Es MUSS der richtige Wert für BluetoothAdapter.isMultipleAdvertisementSupported() angegeben werden, um anzugeben, ob Werbung mit niedrigem Energieverbrauch unterstützt wird.
  • [C-3-5] Es MUSS ein Timeout für resolvable private addresses (RPA) von maximal 15 Minuten implementiert werden. Die Adresse muss nach Ablauf des Timeouts gewechselt werden, um den Datenschutz der Nutzer zu schützen, wenn das Gerät BLE aktiv zum Scannen oder für Werbung verwendet. Um Timing-Angriffe zu verhindern, MÜSSEN die Zeitüberschreitungsintervalle auch zwischen 5 und 15 Minuten zufällig sein.

  • MÜSSEN die Auslagerung der Filterlogik an den Bluetooth-Chipsatz unterstützen, wenn die ScanFilter API implementiert wird.

  • Sollte das Auslagern des Batch-Scans an den Bluetooth-Chip unterstützen.

  • MÜSSEN mehrere Anzeigen mit mindestens 4 Slots unterstützen.

Wenn Geräteimplementierungen Bluetooth LE unterstützen und Bluetooth LE für die Standortsuche verwenden, gilt Folgendes:

  • [C-4-1] Es MUSS eine Nutzerfunktion zum Aktivieren/Deaktivieren des über die System-API BluetoothAdapter.isBleScanAlwaysAvailable() gelesenen Werts geben.

Wenn die Geräteimplementierungen Bluetooth LE und Hörgeräteprofile unterstützen, wie in Unterstützung von Hörgeräten über Bluetooth LE beschrieben, gilt Folgendes:

Wenn die Geräteimplementierungen Bluetooth oder Bluetooth Low Energy unterstützen, gilt Folgendes:

  • [C-6-1] Der Zugriff auf alle Bluetooth-Metadaten (z. B. Suchergebnisse), die zur Ermittlung des Standorts des Geräts verwendet werden könnten, MUSS eingeschränkt werden, es sei denn, die anfragende App besteht eine android.permission.ACCESS_FINE_LOCATION-Berechtigungsprüfung basierend auf ihrem aktuellen Status im Vordergrund/Hintergrund.

Wenn die Geräteimplementierungen Bluetooth oder Bluetooth Low Energy unterstützen und das App-Manifest keine Erklärung des Entwicklers enthält, dass der Standort nicht über Bluetooth ermittelt wird, gilt Folgendes:

Wenn Geräteimplementierungen true für die BluetoothAdapter.isLeAudioSupported() API zurückgeben, geschieht Folgendes:

  • [C-7-1] MUSS einen Unicast-Client unterstützen.
  • [C-7-2] MUSS 2M PHY unterstützen.
  • [C-7-3] MUSS LE Extended-Anzeigen unterstützen.
  • [C-7-4] MÜSSEN mindestens zwei CIS-Verbindungen in einer CIG unterstützen.
  • [C-7-5] BAP-Unicast-Client, CSIP-Set-Koordinator, MCP-Server, VCP-Controller und CCP-Server MÜSSEN gleichzeitig aktiviert sein.
  • [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] Es müssen mindestens zwei BIS-Links in einem BIG unterstützt werden.
  • [C-8-2] BAP-Übertragungsquelle und BAP-Übertragungsassistent MÜSSEN gleichzeitig aktiviert sein.
  • [C-8-3] LE-Werbeunterbrechungen MÜSSEN unterstützt werden.

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] LE-Werbeunterbrechungen MÜSSEN unterstützt werden.

Wenn Geräteimplementierungen FEATURE_BLUETOOTH_LE angeben, gilt Folgendes:

  • [C-10-1] Die RSSI-Messungen müssen für 95% der Messungen in 1 m Entfernung von einem Referenzgerät, das mit ADVERTISE_TX_POWER_HIGH sendet, in Sichtweite innerhalb von +/- 9 dB liegen.
  • [C-10-2] MÜSSEN Rx/Tx-Korrekturen enthalten, um Abweichungen pro Kanal zu reduzieren, sodass die Messungen an jedem der drei Kanäle, an jeder der Antennen (falls mehrere verwendet werden), bei 95% der Messungen innerhalb von +/- 3 dB voneinander liegen.
  • [C-SR-2] Es wird DRINGEND empfohlen, den Rx-Offset zu messen und zu kompensieren, damit der mediane BLE-RSSI -60 dBm ± 10 dB in 1 m Entfernung von einem Referenzgerät beträgt, das mit ADVERTISE_TX_POWER_HIGH sendet. Die Geräte müssen so ausgerichtet sein, dass sie sich auf parallelen Ebenen befinden und die Bildschirme in dieselbe Richtung zeigen.
  • [C-SR-3] Es wird DRINGEND empfohlen, den Tx-Offset zu messen und zu kompensieren, damit der mediane BLE-RSSI -60 dBm ± 10 dB beträgt, wenn von einem Referenzgerät in 1 m Entfernung gescannt wird, das mit ADVERTISE_TX_POWER_HIGH überträgt. Die Geräte müssen so ausgerichtet sein, dass sie sich auf parallelen Ebenen befinden und die Bildschirme in dieselbe Richtung zeigen.

Es wird dringend empfohlen, die Schritte zur Messeinrichtung aus der Anleitung zur Kalibrierung der Anwesenheit auszuführen.

7.4.4. Nahfeldkommunikation

Geräteimplementierungen:

  • MÜSSEN einen Transceiver und zugehörige Hardware für die Nahfeldkommunikation (NFC) enthalten.
  • [C-0-1] Die android.nfc.NdefMessage- und android.nfc.NdefRecord-APIs MÜSSEN implementiert werden, auch wenn sie keine NFC-Unterstützung enthalten, oder die android.hardware.nfc-Funktion deklarieren, da die Klassen ein protokollunabhängiges Datendarstellungsformat darstellen.

Wenn Geräteimplementierungen NFC-Hardware enthalten und diese für Drittanbieter-Apps verfügbar machen sollen, müssen sie:

  • [C-1-1] Die android.hardware.nfc-Funktion MUSS über die Methode android.content.pm.PackageManager.hasSystemFeature() gemeldet werden.
  • MÜSSEN NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können:
  • [C-1-2] MUSS als NFC-Forum-Lese-/Schreibgerät (wie in der technischen NFC-Forum-Spezifikation NFCForum-TS-DigitalProtocol-1.0 definiert) über die folgenden NFC-Standards funktionieren:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC-Forum-Tag-Typen 1, 2, 3, 4 und 5 (vom NFC-Forum definiert)
  • [C-SR-1] Es wird dringend empfohlen, NDEF-Nachrichten sowie Rohdaten über die folgenden NFC-Standards lesen und schreiben zu können. Die NFC-Standards sind zwar als „EMPFOHLENE VORAUSSETZUNG“ angegeben, in der Kompatibilitätsdefinition für eine zukünftige Version wird jedoch geplant, diese in „ERFORDERLICH“ zu ändern. Diese Standards sind in dieser Version optional, werden aber in zukünftigen Versionen erforderlich sein. Wir empfehlen Ihnen dringend, diese Anforderungen jetzt auf bestehenden und neuen Geräten mit dieser Android-Version zu erfüllen, damit Sie auf die zukünftigen Plattformversionen umstellen können.

  • [C-1-13] MUSS im NFC-Suchmodus nach allen unterstützten Technologien suchen.

  • MÜSSEN sich im NFC-Erkennungsmodus befinden, während das Gerät aktiv ist, das Display eingeschaltet und der Sperrbildschirm entsperrt ist.

  • MÜSSEN den Barcode und die URL (falls codiert) von Thinfilm-NFC-Barcodes lesen können.

Für die oben genannten JIS-, ISO- und NFC-Forum-Spezifikationen sind keine öffentlich zugänglichen Links verfügbar.

Android unterstützt den HCE-Modus (Host Card Emulation) von NFC.

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz (für NfcA und/oder NfcB) enthalten und das Routing der Anwendungs-ID (AID) unterstützen, gilt Folgendes:

  • [C-2-1] Die Funktion android.hardware.nfc.hce MUSS als Konstante angegeben werden.
  • [C-2-2] MUSS NFC HCE APIs gemäß der Definition im Android SDK unterstützen.

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz für NfcF enthalten und die Funktion für Drittanbieteranwendungen implementieren, gilt Folgendes:

  • [C-3-1] Die Funktion android.hardware.nfc.hcef MUSS als Konstante angegeben werden.
  • [C-3-2] MÜSSEN die NfcF Card Emulation APIs wie im Android SDK definiert implementieren.

Wenn die Geräteimplementierungen die allgemeine NFC-Unterstützung wie in diesem Abschnitt beschrieben und MIFARE-Technologien (MIFARE Classic, MIFARE Ultralight, NDEF auf MIFARE Classic) in der Leser-/Schreiberrolle unterstützen, müssen sie:

  • [C-4-1] Die entsprechenden Android APIs MÜSSEN gemäß der Dokumentation des Android SDK implementiert werden.
  • [C-4-2] Die Funktion com.nxp.mifare aus der Methode android.content.pm.PackageManager.hasSystemFeature() MUSS erfasst werden. Hinweis: Dies ist keine standardmäßige Android-Funktion und wird daher nicht als Konstante in der Klasse android.content.pm.PackageManager angezeigt.

7.4.5. Netzwerkprotokolle und APIs

7.4.5.1. Mindestnetzwerkanforderungen

Geräteimplementierungen:

  • [C-0-1] MUSS eine oder mehrere Formen von Datennetzwerken unterstützen. Insbesondere müssen Geräteimplementierungen mindestens einen Datenstandard mit einer Geschwindigkeit von mindestens 200 Kbit/s unterstützen. Beispiele für Technologien, die diese Anforderung erfüllen, sind EDGE, HSPA, EV-DO, 802.11g, Ethernet und Bluetooth PAN.
  • MÜSSEN auch mindestens einen gängigen drahtlosen Datenstandard wie 802.11 (Wi‑Fi) unterstützen, wenn ein physischer Netzwerkstandard wie Ethernet die primäre Datenverbindung ist.
  • Es kann mehr als eine Form der Datenverbindung implementiert werden.
7.4.5.2. IPv6

Geräteimplementierungen:

  • [C-0-2] MUSS einen IPv6-Netzwerkstack enthalten und die IPv6-Kommunikation über die verwalteten APIs wie java.net.Socket und java.net.URLConnection sowie die nativen APIs wie AF_INET6-Sockets unterstützen.
  • [C-0-3] IPv6 MUSS standardmäßig aktiviert sein.
    • Die IPv6-Kommunikation muss so zuverlässig wie IPv4 sein, z. B.:
      • [C-0-4] Die IPv6-Verbindung muss im Ruhemodus aufrechterhalten werden.
      • [C-0-5] Die Ratenbegrenzung darf NICHT dazu führen, dass das Gerät die IPv6-Verbindung zu einem IPv6-kompatiblen Netzwerk verliert, das RA-Lebensdauern von mindestens 180 Sekunden verwendet.
  • [C-0-6] MUSS Drittanbieteranwendungen eine direkte IPv6-Verbindung zum Netzwerk bereitstellen, wenn eine Verbindung zu einem IPv6-Netzwerk besteht, ohne dass lokal auf dem Gerät eine Adress- oder Portübersetzung erfolgt. Sowohl verwaltete APIs wie Socket#getLocalAddress oder Socket#getLocalPort als auch NDK-APIs wie getsockname() oder IPV6_PKTINFO MÜSSEN die IP-Adresse und den Port zurückgeben, die bzw. der tatsächlich zum Senden und Empfangen von Paketen im Netzwerk verwendet wird und als Quell-IP-Adresse und Port für Internet- (Web-)Server sichtbar ist.

Die erforderliche IPv6-Unterstützung hängt vom Netzwerktyp ab, wie in den folgenden Anforderungen dargestellt.

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

  • [C-1-1] MUSS Dual-Stack und reinen IPv6-Betrieb über WLAN unterstützen.

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

  • [C-2-1] MUSS Dual-Stack- und reinen IPv6-Betrieb über Ethernet unterstützen.

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

  • [C-3-1] MUSS den IPv6-Betrieb (nur IPv6 und möglicherweise Dual-Stack) auf Mobilfunknetzen unterstützen.

Wenn Geräteimplementierungen mehr als einen Netzwerktyp unterstützen (z.B. WLAN und mobile Daten) haben folgende Vorteile:

  • [C-4-1] Die oben genannten Anforderungen MÜSSEN gleichzeitig für jedes Netzwerk erfüllt werden, wenn das Gerät gleichzeitig mit mehreren Netzwerktypen verbunden ist.
7.4.5.3. Captive Portals

Ein Captive Portal ist ein Netzwerk, in dem eine Anmeldung für den Internetzugriff erforderlich ist.

Wenn Geräteimplementierungen eine vollständige Implementierung der android.webkit.Webview API bieten, gilt Folgendes:

  • [C-1-1] Es MUSS eine Captive-Portal-Anwendung zur Verarbeitung der Intents ACTION_CAPTIVE_PORTAL_SIGN_IN und zum Anzeigen der Anmeldeseite des Captive-Portals geben. Dazu muss der Intent beim Aufruf der System API ConnectivityManager#startCaptivePortalApp(Network, Bundle) gesendet werden.
  • [C-1-2] MUSS Captive Portals erkennen und die Anmeldung über die Captive Portal-Anwendung unterstützen, wenn das Gerät mit einem beliebigen Netzwerktyp verbunden ist, einschließlich Mobilfunknetz, WLAN, Ethernet oder Bluetooth.
  • [C-1-3] MUSS die Anmeldung in Captive Portals mit DNS im Klartext unterstützen, wenn das Gerät für den strengen Modus von Privatem DNS konfiguriert ist.
  • [C-1-4] Es MUSS verschlüsseltes DNS gemäß der SDK-Dokumentation für android.net.LinkProperties.getPrivateDnsServerName und android.net.LinkProperties.isPrivateDnsActive für den gesamten Netzwerkverkehr verwendet werden, der nicht explizit mit dem Captive Portal kommuniziert.
  • [C-1-5] Es MUSS sichergestellt werden, dass während der Nutzer sich in einem Captive Portal anmeldet, das von Anwendungen verwendete Standardnetzwerk (wie von ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback zurückgegeben und standardmäßig von Java-Netzwerk-APIs wie java.net.Socket und nativen APIs wie connect() verwendet) ein anderes verfügbares Netzwerk ist, das Internetzugriff bietet, sofern verfügbar.

7.4.6. Synchronisierungseinstellungen

Geräteimplementierungen:

  • [C-0-1] Die Einstellung für die automatische Synchronisierung des Masters muss standardmäßig aktiviert sein, damit die Methode getMasterSyncAutomatically() „wahr“ zurückgibt.

7.4.7. Datensparmodus

Wenn Geräteimplementierungen eine getaktete Verbindung umfassen, gilt Folgendes:

  • [C-SR-1] Es wird DRINGEND empfohlen, den Datensparmodus bereitzustellen.

Wenn Geräteimplementierungen den Datensparmodus bieten, gilt Folgendes:

  • [C-1-1] MUSS alle APIs in der ConnectivityManager-Klasse unterstützen, wie in der SDK-Dokumentation beschrieben.

Wenn Geräteimplementierungen keinen Datensparmodus bieten, gilt Folgendes:

7.4.8. Secure Elements

Wenn Geräteimplementierungen sichere Elemente unterstützen, die die Open Mobile API unterstützen, und diese für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

7.4.9. UWB

Wenn Geräteimplementierungen 802.1.15.4 unterstützen und die Funktion für eine Drittanbieteranwendung freigeben, gilt Folgendes:

  • [C-1-1] Die entsprechende Android API MUSS in android.uwb implementiert sein.
  • [C-1-2] Das Hardware-Funktionsflag „android.hardware.uwb“ MUSS gemeldet werden.
  • [C-1-3] MUSS alle relevanten UWB-Profile unterstützen, die in der Android-Implementierung definiert sind.
  • [C-1-4] Es MUSS eine Nutzerfunktion geben, mit der der Nutzer den UWB-Funk ein- und ausschalten kann.
  • [C-1-5] Es MUSS erzwungen werden, dass Apps, die UWB-Funk verwenden, die Berechtigung „UWB_RANGING“ (unter der Berechtigungsgruppe „NEARBY_DEVICES“) haben.
  • [C-SR-1] Es wird DRINGEND empfohlen, die relevanten Konformitäts- und Zertifizierungstests zu bestehen, die von Standardsorganisationen wie FIRA, CCC und CSA definiert wurden.
  • [C-1-6] Die Entfernungsmessungen müssen für 95 % der Messungen in einer Umgebung mit Sichtverbindung bei einem Abstand von 1 m in einer nicht reflektierenden Kammer innerhalb von +/- 15 cm liegen.
  • [C-1-7] Der Median der Entfernungsmessungen in 1 m Entfernung vom Referenzgerät muss zwischen [0,75 m, 1,25 m] liegen. Die Ground-Truth-Entfernung wird vom oberen Rand des DUT gemessen.
  • [C-SR-2] Es wird DRINGEND empfohlen, die Schritte zur Messeinrichtung aus den Anforderungen an die Präsenzkalibrierung auszuführen.

7.5. Kameras

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

  • [C-1-1] Das android.hardware.camera.any-Funktions-Flag MUSS deklariert werden.
  • [C-1-2] Es MUSS möglich sein, dass eine Anwendung gleichzeitig drei RGBA_8888-Bitmaps zuweist, die der Größe der Bilder entsprechen, die vom Kamerasensor mit der höchsten Auflösung auf dem Gerät erzeugt werden, während die Kamera für eine einfache Vorschau und Standbildaufnahme geöffnet ist.
  • [C-1-3] Die vorinstallierte Standardkamera-App, die Intents vom Typ MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE oder MediaStore.ACTION_VIDEO_CAPTURE verarbeitet, MUSS dafür sorgen, dass der Standort des Nutzers aus den Bildmetadaten entfernt wird, bevor sie an die Empfänger-App gesendet werden, wenn die Empfänger-App nicht ACCESS_FINE_LOCATION hat.

Wenn die Geräteimplementierungen die HDR-10-Bit-Ausgabe unterstützen, gilt Folgendes:

  • [C-2-1] Es MUSS mindestens das HLG-HDR-Profil für jedes Kameragerät unterstützt werden, das eine 10-Bit-Ausgabe unterstützt.
  • [C-2-2] MUSS eine 10-Bit-Ausgabe entweder für die primäre Rückkamera oder die primäre Frontkamera unterstützen.
  • [C-SR-1] Es wird DRINGEND empfohlen, für beide primären Kameras eine 10-Bit-Ausgabe zu unterstützen.
  • [C-2-3] MÜSSEN dieselben HDR-Profile für alle BACKWARD_COMPATIBLE-fähigen physischen Unterkameras einer logischen Kamera und für die logische Kamera selbst unterstützen.

Für logische Kamerageräte, die 10-Bit-HDR unterstützen und die android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API implementieren, gilt Folgendes:

  • [C-3-1] Es MUSS möglich sein, über die CONTROL_ZOOM_RATIO-Steuerung der logischen Kamera zwischen allen abwärtskompatiblen physischen Kameras zu wechseln.

7.5.1. Rückkamera

Eine Rückkamera ist eine nach außen gerichtete Kamera, die wie eine herkömmliche Kamera Bilder auf der Rückseite des Geräts aufnimmt. Bei Mobilgeräten befindet sich diese Kamera auf der Seite des Geräts, die dem Display gegenüberliegt.

Geräteimplementierungen:

  • MÜSSEN eine Rückkamera haben.

Wenn Geräteimplementierungen mindestens eine Rückkamera enthalten, gilt Folgendes:

  • [C-1-1] MÜSSEN das Funktions-Flag android.hardware.camera und android.hardware.camera.any melden.
  • [C-1-2] MÜSSEN eine Auflösung von mindestens 2 Megapixeln haben.
  • Es sollte entweder ein Hardware- oder Software-Autofokus im Kameratreiber implementiert sein (für die Anwendungssoftware transparent).
  • KANN Hardware mit fester Brennweite oder erweiterter Schärfentiefe haben.
  • KANN einen Blitz enthalten.

Wenn die Kamera einen Blitz hat:

  • [C-2-1] Der Blitz darf NICHT leuchten, während eine android.hardware.Camera.PreviewCallback-Instanz auf einer Kameravorschauoberfläche registriert ist, es sei denn, die Anwendung hat den Blitz explizit aktiviert, indem sie die FLASH_MODE_AUTO- oder FLASH_MODE_ON-Attribute eines Camera.Parameters-Objekts aktiviert hat. Diese Einschränkung gilt nicht für die integrierte Systemkamera-App des Geräts, sondern nur für Drittanbieter-Apps, die Camera.PreviewCallback verwenden.

7.5.2. Frontkamera

Eine Frontkamera ist eine Kamera, die auf den Nutzer gerichtet ist und in der Regel zum Aufnehmen von Bildern des Nutzers verwendet wird, z. B. für Videokonferenzen und ähnliche Anwendungen. Bei Mobilgeräten befindet sich diese Kamera auf derselben Seite des Geräts wie das Display.

Geräteimplementierungen:

  • KANN eine Frontkamera enthalten.

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

  • [C-1-1] MÜSSEN das Funktions-Flag android.hardware.camera.any und android.hardware.camera.front melden.
  • [C-1-2] MÜSSEN eine Auflösung von mindestens VGA (640 × 480 Pixel) haben.
  • [C-1-3] Es darf KEINE Frontkamera als Standard für die Camera API verwendet werden und die API darf NICHT so konfiguriert werden, dass eine Frontkamera als Standard-Rückkamera behandelt wird, auch wenn es sich um die einzige Kamera auf dem Gerät handelt.
  • [C-1-4] Die Kameravorschau MUSS horizontal gespiegelt werden, bezogen auf die von der App angegebene Ausrichtung, wenn die aktuelle App ausdrücklich die Drehung des Kameradisplays über einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() angefordert hat. Umgekehrt muss die Vorschau entlang der Standardhorizontalachse des Geräts gespiegelt werden, wenn die aktuelle Anwendung nicht explizit über einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() anfordert, dass das Kameradisplay gedreht wird.
  • [C-1-5] Die finalen aufgenommenen Standbild- oder Videostreams, die an die Anwendungs-Callbacks zurückgegeben oder im Medienspeicher gespeichert werden, DÜRFEN NICHT gespiegelt werden.
  • [C-1-6] Das Bild, das in der Postview angezeigt wird, MUSS auf dieselbe Weise gespiegelt werden wie der Bildstream der Kameravorschau.
  • KANN Funktionen wie Autofokus und Blitz enthalten, die für Rückkameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.

Wenn Geräteimplementierungen vom Nutzer gedreht werden können (z. B. automatisch über einen Beschleunigungsmesser oder manuell über Nutzereingaben):

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

7.5.3. Externe Kamera

Eine externe Kamera kann jederzeit an das Gerät angeschlossen oder von ihm getrennt werden und kann in jede Richtung zeigen, z. B. USB-Kameras.

Geräteimplementierungen:

  • MÖGLICHERWEISE Unterstützung für eine externe Kamera, die nicht unbedingt immer verbunden ist.

Wenn die Geräteimplementierungen die Unterstützung einer externen Kamera umfassen, gilt Folgendes:

  • [C-1-1] Die Plattformfunktions-Flags android.hardware.camera.external und android.hardware camera.any MÜSSEN deklariert werden.
  • [C-1-2] MUSS USB Video Class (UVC 1.0 oder höher) unterstützen, wenn die externe Kamera über den USB-Host-Port verbunden wird.
  • [C-1-3] Die Kamera muss die CTS-Tests mit einem angeschlossenen externen Kameragerät bestehen. Details zu den CTS-Tests für Kameras finden Sie unter source.android.com.
  • MÜSSEN Videokomprimierungen wie MJPEG unterstützen, um die Übertragung von hochwertigen, nicht codierten Streams (d.h. Roh- oder unabhängig komprimierte Bildstreams) zu ermöglichen.
  • Unter Umständen wird die Nutzung mehrerer Kameras unterstützt.
  • KANN kamerabasierte Videocodierung unterstützen.

Wenn die kamerabasierte Videocodierung unterstützt wird:

  • [C-2-1] Auf der Geräteimplementierung muss ein gleichzeitiger uncodierter / MJPEG-Stream (QVGA oder höhere Auflösung) verfügbar sein.

7.5.4. Verhalten der Camera API

Android enthält zwei API-Pakete für den Zugriff auf die Kamera. Die neuere android.hardware.camera2 API stellt der App eine Kamerasteuerung auf niedriger Ebene zur Verfügung, einschließlich effizienter Zero-Copy-Burst-/Streaming-Abläufe und Frames-spezifischer Einstellungen für Belichtung, Verstärkung, Weißabgleich, Farbkonvertierung, Rauschunterdrückung, Schärfung und mehr.

Das ältere API-Paket android.hardware.Camera ist in Android 5.0 als eingestellt gekennzeichnet, sollte aber weiterhin für Apps verfügbar sein. Bei der Implementierung von Android-Geräten MUSS die API wie in diesem Abschnitt und im Android SDK beschrieben unterstützt werden.

Alle Funktionen, die der eingestellten Klasse „android.hardware.Camera“ und dem neueren Paket „android.hardware.camera2“ gemeinsam sind, MÜSSEN in beiden APIs eine vergleichbare Leistung und Qualität bieten. Bei vergleichbaren Einstellungen müssen beispielsweise die Geschwindigkeit und Genauigkeit des Autofokus identisch sein und die Qualität der aufgenommenen Bilder muss gleich sein. Funktionen, die von der unterschiedlichen Semantik der beiden APIs abhängen, müssen nicht dieselbe Geschwindigkeit oder Qualität haben, sollten aber so nah wie möglich übereinstimmen.

Geräteimplementierungen MÜSSEN das folgende Verhalten für die kamerabezogenen APIs für alle verfügbaren Kameras implementieren. Geräteimplementierungen:

  • [C-0-1] android.hardware.PixelFormat.YCbCr_420_SP MUSS für Vorschaudaten verwendet werden, die an Anwendungs-Callbacks übergeben werden, wenn eine Anwendung noch nie android.hardware.Camera.Parameters.setPreviewFormat(int) aufgerufen hat.
  • [C-0-2] MÜSSEN außerdem im NV21-Codierungsformat vorliegen, wenn eine Anwendung eine android.hardware.Camera.PreviewCallback-Instanz registriert und das System die onPreviewFrame()-Methode aufruft und das Vorschauformat YCbCr_420_SP ist, werden die Daten in den Byte[] an onPreviewFrame() übergeben. Das heißt, NV21 MUSS der Standard sein.
  • [C-0-3] MUSS das YV12-Format (wie durch die Konstante android.graphics.ImageFormat.YV12 angegeben) für Kameravorschauen sowohl für die Front- als auch für die Rückkamera von android.hardware.Camera unterstützen. Der Hardware-Videoencoder und die Kamera können beliebige native Pixelformate verwenden, aber die Geräteimplementierung MUSS die Umwandlung in YV12 unterstützen.
  • [C-0-4] Die android.hardware.ImageFormat.YUV_420_888- und android.hardware.ImageFormat.JPEG-Formate MÜSSEN als Ausgaben über die android.media.ImageReader API für android.hardware.camera2-Geräte unterstützt werden, die die Funktion REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities angeben.
  • [C-0-5] Die vollständige Camera API, die in der Android SDK-Dokumentation enthalten ist, MUSS implementiert werden, unabhängig davon, ob das Gerät einen Hardware-Autofokus oder andere Funktionen hat. Kameras ohne Autofokus MÜSSEN beispielsweise alle registrierten android.hardware.Camera.AutoFocusCallback-Instanzen aufrufen, auch wenn dies für eine Kamera ohne Autofokus keine Relevanz hat. Dies gilt auch für Frontkameras. Auch wenn die meisten Frontkameras keinen Autofokus unterstützen, müssen die API-Callbacks wie beschrieben „gefaket“ werden.
  • [C-0-6] MUSS jeden Parameternamen erkennen und berücksichtigen, der in der Klasse android.hardware.Camera.Parameters und in der Klasse android.hardware.camera2.CaptureRequest als Konstante definiert ist. Umgekehrt dürfen Geräteimplementierungen nur Stringkonstanten berücksichtigen oder erkennen, die an die android.hardware.Camera.setParameters()-Methode übergeben werden und als Konstanten in der android.hardware.Camera.Parameters dokumentiert sind. Das bedeutet, dass Geräteimplementierungen alle Standardkameraparameter unterstützen MÜSSEN, sofern die Hardware dies zulässt, und KEINE benutzerdefinierten Kameraparametertypen unterstützen DÜRFEN. Geräteimplementierungen, die die Bildaufnahme mit HDR-Bildgebungstechniken unterstützen, MÜSSEN beispielsweise den Kameraparameter Camera.SCENE_MODE_HDR unterstützen.
  • [C-0-7] Die richtige Supportstufe muss mit der Property android.info.supportedHardwareLevel gemäß der Beschreibung im Android SDK angegeben werden. Außerdem müssen die entsprechenden Framework-Funktions-Flags angegeben werden.
  • [C-0-8] MUSS die einzelnen Kamerafunktionen von android.hardware.camera2 über die Eigenschaft android.request.availableCapabilities angeben und die entsprechenden Funktions-Flags deklarieren. MUSS das Funktions-Flag definieren, wenn eines der angeschlossenen Kamerageräte die Funktion unterstützt.
  • [C-0-9] MUSS die Camera.ACTION_NEW_PICTURE-Intention senden, wenn mit der Kamera ein neues Bild aufgenommen und der Eintrag des Bildes dem Medienspeicher hinzugefügt wurde.
  • [C-0-10] Die Camera.ACTION_NEW_VIDEO-Intention MUSS gesendet werden, wenn von der Kamera ein neues Video aufgenommen und der Eintrag des Bildes dem Medienspeicher hinzugefügt wurde.
  • [C-0-11] Auf alle Kameras, auf die über die eingestellte android.hardware.Camera API zugegriffen werden kann, muss auch über die android.hardware.camera2 API zugegriffen werden können.
  • [C-0-12] Das Erscheinungsbild des Gesichts darf NICHT verändert werden, einschließlich, aber nicht beschränkt auf die Veränderung der Gesichtsgeometrie, des Hauttons oder der Hautglättung für jede android.hardware.camera2 oder android.hardware.Camera API.
  • [C-SR-1] Für Geräte mit mehreren RGB-Kameras in unmittelbarer Nähe und in dieselbe Richtung ausgerichtet, wird dringend empfohlen, ein logisches Kameragerät zu unterstützen, das die Funktion CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA auflistet und aus allen RGB-Kameras in dieser Richtung als physische Untergeräte besteht.

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

7.5.5. Kameraausrichtung

Wenn Geräte eine Front- oder Rückkamera haben, gelten für diese Kameras folgende Anforderungen:

  • [C-1-1] MUSS so ausgerichtet sein, dass die lange Seite der Kamera mit der langen Seite des Bildschirms übereinstimmt. Das bedeutet, dass die Kameras Bilder im Querformat aufnehmen MÜSSEN, wenn das Gerät im Querformat gehalten wird. Das gilt unabhängig von der natürlichen Ausrichtung des Geräts, also sowohl für Geräte mit primärem Querformat als auch für Geräte mit primärem Hochformat.

Geräte, die alle folgenden Kriterien erfüllen, sind von der oben genannten Anforderung ausgenommen:

  • Das Gerät verwendet Bildschirme mit variabler Geometrie, z. B. faltbare oder Scharnier-Displays.
  • Wenn sich der Zustand des Scharniers oder des Faltmechanismus des Geräts ändert, wechselt das Gerät zwischen der primären Hoch- und der primären Querformatausrichtung (oder umgekehrt).
  • Geräteimplementierungen, die vom Nutzer nicht gedreht werden können, z. B. Geräte in Fahrzeugen.

7.6. Arbeitsspeicher und Datenspeicher

7.6.1. Mindestarbeitsspeicher und Mindestspeicherplatz

Geräteimplementierungen:

  • [C-0-1] MUSS einen Download-Manager enthalten, den Anwendungen zum Herunterladen von Datendateien VERWENDEN DÜRFEN. Außerdem MUSS es möglich sein, einzelne Dateien mit einer Größe von mindestens 100 MB an den standardmäßigen Speicherort „cache“ herunterzuladen.

7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen

Geräteimplementierungen:

  • [C-0-1] MUSS Speicherplatz für die gemeinsame Nutzung durch Anwendungen bieten, der auch oft als „freigegebener externer Speicher“, „freigegebener Speicher für Anwendungen“ oder durch den Linux-Pfad „/sdcard“, auf dem er bereitgestellt wird, bezeichnet wird.
  • [C-0-2] MUSS mit freigegebenem Speicher konfiguriert sein, der standardmäßig bereitgestellt wird, also „out of the box“, unabhängig davon, ob der Speicher in einer internen Speicherkomponente oder auf einem Wechselspeichermedium implementiert ist (z.B. Secure Digital-Kartenlesegerät).
  • [C-0-3] Der freigegebene Speicher der Anwendung muss direkt über den Linux-Pfad sdcard bereitgestellt oder einen Linux-Symbollink von sdcard zum tatsächlichen Bereitstellungspunkt enthalten.
  • [C-0-4] Der befristete Speicher muss standardmäßig für alle Apps aktiviert sein, die auf API-Level 29 oder höher ausgerichtet sind, es sei denn, eine der folgenden Situationen liegt vor:
    • Wenn die App android:requestLegacyExternalStorage="true" in ihrem Manifest angefordert hat.
  • [C-0-5] Standortmetadaten wie GPS-EXIF-Tags, die in Mediendateien gespeichert sind, MÜSSEN entfernt werden, wenn über MediaStore auf diese Dateien zugegriffen wird, es sei denn, die aufrufende App hat die Berechtigung ACCESS_MEDIA_LOCATION.

Geräteimplementierungen KÖNNEN die oben genannten Anforderungen mit einer der folgenden Methoden erfüllen:

  • Ein für Nutzer zugänglicher Wechseldatenträger, z. B. ein SD-Kartenslot (Secure Digital).
  • Ein Teil des internen (nicht entfernbaren) Speichers, wie im Android Open Source Project (AOSP) implementiert.

Wenn bei Geräteimplementierungen ein Wechselspeicher verwendet wird, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

  • [C-1-1] Es MUSS eine Toast- oder Pop-up-Benutzeroberfläche implementiert werden, die den Nutzer warnt, wenn sich kein Speichermedium im Steckplatz befindet.
  • [C-1-2] MUSS ein FAT-formatiertes Speichermedium (z.B. SD-Karte) enthalten oder auf der Verpackung und anderen zum Kaufzeitpunkt verfügbaren Materialien muss angegeben sein, dass das Speichermedium separat erworben werden muss.

Wenn bei Geräteimplementierungen ein Teil des nicht entfernbaren Speichers verwendet wird, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

  • SOLLTE die AOSP-Implementierung des internen freigegebenen Speichers der Anwendung verwenden.
  • KANN den Speicherplatz mit den privaten Daten der Anwendung teilen.

Wenn Geräteimplementierungen einen USB-Anschluss mit Unterstützung des USB-Peripheriemodus haben, gilt Folgendes:

  • [C-3-1] Es MUSS einen Mechanismus geben, um von einem Hostcomputer aus auf die Daten im freigegebenen Speicher der Anwendung zuzugreifen.
  • MÜSSEN Inhalte aus beiden Speicherpfaden transparent über den Medienscannerdienst von Android und android.provider.MediaStore bereitstellen.
  • Es kann USB-Massenspeicher verwenden, sollte aber das Media-Transfer-Protokoll verwenden, um diese Anforderung zu erfüllen.

Wenn Geräteimplementierungen einen USB-Anschluss mit USB-Peripheriemodus haben und das Media-Transfer-Protokoll unterstützen, gilt Folgendes:

  • MÜSSEN mit dem Referenz-Android-MTP-Host Android File Transfer kompatibel sein.
  • MÜSSEN eine USB-Geräteklasse von 0x00 melden.
  • MÜSSEN den Namen „MTP“ für die USB-Schnittstelle angeben.

7.6.3. Verwendbare Speicher

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

  • [C-SR-1] Es wird dringend empfohlen, den anpassbaren Speicher an einem langfristig stabilen Ort zu implementieren, da ein versehentliches Trennen zu Datenverlusten oder Beschädigungen führen kann.

Wenn sich der Anschluss für das Wechselspeichergerät an einer dauerhaft stabilen Stelle befindet, z. B. im Batteriefach oder in einer anderen Schutzabdeckung, sind die Geräteimplementierungen:

7.7. USB

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

  • MÜSSEN den USB-Peripheriegerätemodus und den USB-Hostmodus unterstützen.
  • MÜSSEN die Deaktivierung der Datensignalisierung über USB unterstützen.

7.7.1. USB-Peripheriegerätemodus

Wenn die Geräteimplementierungen einen USB-Anschluss mit Peripheriemodus enthalten:

  • [C-1-1] Der Anschluss MUSS mit einem USB-Host mit einem Standard-USB-Typ-A- oder -Typ-C-Anschluss verbunden werden können.
  • [C-1-2] Der korrekte Wert von iSerialNumber muss im USB-Standardgerätedeskriptor über android.os.Build.SERIAL angegeben werden.
  • [C-1-3] MÜSSEN Ladegeräte mit 1,5 A und 3,0 A gemäß dem Widerstandsstandard für USB-Typ-C erkennen und MÜSSEN Änderungen in der Werbung erkennen, wenn sie USB-Typ-C unterstützen.
  • [C-SR-1] Der Port sollte den USB-Formfaktor Micro-B, Micro-AB oder Typ-C haben. Für bestehende und neue Android-Geräte wird dringend empfohlen, diese Anforderungen zu erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt werden können.
  • [C-SR-2] Der Anschluss MUSS sich an der Unterseite des Geräts befinden (entsprechend der natürlichen Ausrichtung) oder die Software-Displaydrehung für alle Apps (einschließlich Startbildschirm) aktivieren, damit das Display korrekt dargestellt wird, wenn das Gerät so gehalten wird, dass sich der Anschluss unten befindet. Wir EMPFEHLEN dringend, diese Anforderungen für bestehende und neue Android-Geräte zu erfüllen, damit sie auf zukünftige Plattformversionen umgestellt werden können.
  • [C-SR-3] Es sollte Unterstützung für einen Stromverbrauch von 1,5 A während des HS-Chirps und des Traffics implementiert werden, wie in der USB Battery Charging Specification, Revision 1.2 angegeben. Für bestehende und neue Android-Geräte wird dringend empfohlen, diese Anforderungen zu erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt werden können.
  • [C-SR-4] Es wird DRINGEND empfohlen, keine proprietären Lademethoden zu unterstützen, die die Vbus-Spannung über die Standardwerte hinaus ändern oder die Rolle des Sinks/der Quelle ändern, da dies zu Inkompatibilitätsproblemen mit Ladegeräten oder Geräten führen kann, die die standardmäßigen USB-PD-Methoden unterstützen. Auch wenn dies als „EMPFOHLENE LÖSUNG“ gekennzeichnet ist, werden in zukünftigen Android-Versionen möglicherweise alle Typ-C-Geräte zur vollständigen Interoperabilität mit Standard-Typ-C-Ladegeräten verpflichtet.
  • [C-SR-5] Es wird dringend empfohlen, die Stromversorgung für Daten und den Wechsel der Stromversorgungsrolle zu unterstützen, wenn USB-Typ-C und der USB-Hostmodus unterstützt werden.
  • MÜSSEN Power Delivery für das Laden mit hoher Spannung und Unterstützung für alternative Modi wie Displayausgang unterstützen.
  • MÜSSEN die Android Open Accessory API und ‑Spezifikation gemäß der Dokumentation des Android SDK implementieren.

Wenn Geräteimplementierungen einen USB-Anschluss und die AOA-Spezifikation implementieren, gilt Folgendes:

  • [C-2-1] MUSS die Unterstützung der Hardwarefunktion android.hardware.usb.accessory angeben.
  • [C-2-2] Die USB-Massenspeicherklasse MUSS am Ende des Interface-Beschreibungsstrings iInterface des USB-Massenspeichers den String „android“ enthalten.

7.7.2. USB-Host-Modus

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

  • [C-1-1] Die Android USB Host API muss gemäß der Dokumentation im Android SDK implementiert sein und die Unterstützung der Hardwarefunktion android.hardware.usb.host muss erklärt werden.
  • [C-1-2] MUSS die Unterstützung für die Verbindung von Standard-USB-Peripheriegeräten implementieren. Das bedeutet, dass EINE der folgenden Optionen MUSS implementiert werden:
    • Es muss einen USB-C-Anschluss haben oder mit Kabeln geliefert werden, die einen proprietären Anschluss auf dem Gerät an einen standardmäßigen USB-C-Anschluss anpassen (USB-C-Gerät).
    • Sie haben einen USB-A-Anschluss oder werden mit Kabeln geliefert, die einen proprietären Anschluss auf dem Gerät an einen Standard-USB-A-Anschluss anschließen.
    • einen Micro-AB-Anschluss auf dem Gerät haben, der MIT einem Kabel geliefert werden SOLLTE, das an einen Standard-Typ-A-Anschluss passt.
  • [C-1-3] Der Lieferumfang darf KEIN Adapter enthalten, der von USB-Typ-A- oder Micro-AB-Ports zu einem Typ-C-Port (Anschluss) konvertiert.
  • [C-SR-1] Es wird DRINGEND empfohlen, die USB-Audioklasse gemäß der Dokumentation des Android SDK zu implementieren.
  • MÜSSEN das Aufladen des angeschlossenen USB-Peripheriegeräts im Hostmodus unterstützen und einen Quellstrom von mindestens 1,5 A angeben, wie im Abschnitt „Termination Parameters“ (Begrenzungsparameter) der USB Type-C Cable and Connector Specification Revision 1.2 (USB-Typ-C-Kabel- und Anschlussspezifikation Version 1.2) für USB-Typ-C-Anschlüsse oder den CDP-Ausgangsstrombereich (Charging Downstream Port, Lade-Downstream-Port) wie in den USB Battery Charging specifications, revision 1.2 (USB-Spezifikationen für das Aufladen von Akkus, Version 1.2) für Micro-AB-Anschlüsse angegeben.
  • MÜSSEN USB-Typ-C-Standards implementieren und unterstützen.

Wenn Geräteimplementierungen einen USB-Anschluss haben, der den Hostmodus und die USB-Audioklasse unterstützt, gilt Folgendes:

  • [C-2-1] MUSS die USB HID-Klasse unterstützen.
  • [C-2-2] MUSS die Erkennung und Zuordnung der folgenden HID-Datenfelder unterstützen, die in den USB HID-Nutzungstabellen und der Nutzungsanfrage für Sprachbefehle an die KeyEvent-Konstanten unten angegeben sind:
    • Nutzungsseite (0xC) – Nutzungs-ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Nutzungsseite (0xC) – Nutzungs-ID (0x0E9): KEYCODE_VOLUME_UP
    • Seite für die Nutzung (0xC) – Nutzungs-ID (0x0EA): KEYCODE_VOLUME_DOWN
    • Nutzungsseite (0xC) – Nutzungs-ID (0x0CF): KEYCODE_VOICE_ASSIST

Wenn Geräteimplementierungen einen USB-Anschluss haben, der den Hostmodus und das Storage Access Framework (SAF) unterstützt, gilt Folgendes:

  • [C-3-1] MUSS alle per Fernzugriff verbundenen MTP-Geräte (Media Transfer Protocol) erkennen und deren Inhalte über die Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT und ACTION_CREATE_DOCUMENT zugänglich machen. .

Wenn Geräteimplementierungen einen USB-Port haben, der den Hostmodus und USB Typ-C unterstützt, gilt Folgendes:

  • [C-4-1] MÜSSEN die Funktion „Dual Role Port“ gemäß der USB-Typ-C-Spezifikation (Abschnitt 4.5.1.3.3) implementieren. Bei Geräten mit einer 3, 5-mm-Audiobuchse kann die USB-Sink-Erkennung (Host-Modus) standardmäßig deaktiviert sein, muss aber vom Nutzer aktiviert werden können.
  • [C-SR-2] DisplayPort wird DRINGEND empfohlen, USB SuperSpeed-Datenraten sollten unterstützt werden und die Unterstützung von Power Delivery für den Austausch von Daten- und Stromversorgungsrollen wird DRINGEND empfohlen.
  • [C-SR-3] Es wird DRINGEND empfohlen, den Zubehörmodus für Audioadapter NICHT zu unterstützen, wie in Anhang A der USB Type-C Cable and Connector Specification Revision 1.2 beschrieben.
  • Sie MÜSSEN das Try.*-Modell implementieren, das für den Formfaktor des Geräts am besten geeignet ist. Beispielsweise sollte ein Handheld das Try.SNK-Modell implementieren.

7.8. Audio

7.8.1. Mikrofon

Wenn Geräteimplementierungen ein Mikrofon enthalten, gilt Folgendes:

  • [C-1-1] Die Funktion android.hardware.microphone MUSS als Konstante angegeben werden.
  • [C-1-2] MÜSSEN die Anforderungen an Audioaufnahmen in Abschnitt 5.4 erfüllen.
  • [C-1-3] MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
  • [C-SR-1] Es wird DRINGEND empfohlen, die Aufzeichnung von Nahultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen.

Wenn bei Geräteimplementierungen kein Mikrofon vorhanden ist, gilt Folgendes:

  • [C-2-1] Die Funktion android.hardware.microphone darf NICHT gemeldet werden.
  • [C-2-2] Gemäß Abschnitt 7 MUSS die Audioaufzeichnungs-API mindestens als No-Op implementiert werden.

7.8.2. Audioausgabe

Wenn Geräteimplementierungen einen Lautsprecher oder einen Audio-/Multimedia-Ausgabeanschluss für ein Audioausgabegerät wie eine 4-polige 3,5-mm-Audiobuchse oder einen USB-Host-Modus-Anschluss mit USB Audio Class enthalten, müssen sie:

  • [C-1-1] Die Funktion android.hardware.audio.output MUSS als Konstante angegeben werden.
  • [C-1-2] MUSS die Anforderungen an die Audiowiedergabe in Abschnitt 5.5 erfüllen.
  • [C-1-3] MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
  • [C-SR-1] Es wird dringend empfohlen, die Wiedergabe von Near-Ultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen.

Wenn Geräteimplementierungen keinen Lautsprecher oder Audioausgang haben, gilt Folgendes:

  • [C-2-1] Die Funktion android.hardware.audio.output DARF NICHT gemeldet werden.
  • [C-2-2] Die APIs für den Audioausgang MÜSSEN mindestens als No-Ops implementiert werden.

In diesem Abschnitt bezeichnet ein „Ausgabeanschluss“ eine physische Schnittstelle, z. B. einen 3, 5-mm-Audioanschluss, einen HDMI-Anschluss oder einen USB-Hostmodus-Anschluss mit USB-Audioklasse. Die Unterstützung der Audioausgabe über drahtlose Protokolle wie Bluetooth, WLAN oder Mobilfunknetz gilt nicht als „Ausgabeport“.

7.8.2.1. Analoge Audioports

Damit Geräte mit Headsets und anderem Audiozubehör kompatibel sind, das den 3,5‑mm-Audiostecker verwendet, müssen Geräteimplementierungen, die einen oder mehrere analoge Audioports enthalten, folgende Anforderungen erfüllen:

  • [C-SR-1] Es wird dringend empfohlen, dass mindestens einer der Audioanschlüsse eine 4-polige 3,5-mm-Audiobuchse ist.

Wenn die Geräteimplementierungen eine 3,5-mm-Audiobuchse mit vier Adern haben, gilt Folgendes:

  • [C-1-1] MUSS die Audiowiedergabe über Stereokopfhörer und Stereoheadsets mit Mikrofon unterstützen.
  • [C-1-2] MÜSSEN TRRS-Audiostecker mit der CTIA-Belegung unterstützen.
  • [C-1-3] MUSS die Erkennung und Zuordnung zu den Schlüsselcodes für die folgenden drei Bereiche der äquivalenten Impedanz zwischen dem Mikrofon und den Schutzleitern am Audiostecker unterstützen:
    • 70 Ohm oder weniger: KEYCODE_HEADSETHOOK
    • 210–290 Ohm: KEYCODE_VOLUME_UP
    • 360–680 Ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] MUSS ACTION_HEADSET_PLUG beim Einstecken des Steckers auslösen, aber erst, nachdem alle Kontakte am Stecker ihre entsprechenden Segmente am Anschluss berühren.
  • [C-1-5] MUSS mindestens 150 mV ± 10% der Ausgangsspannung bei einer Lautsprecherimpedanz von 32 Ohm liefern können.
  • [C-1-6] Die Mikrofonvorspannung muss zwischen 1,8 V und 2,9 V liegen.
  • [C-1-7] MUSS den folgenden Bereich der äquivalenten Impedanz zwischen den Mikrofon- und Erdleitern am Audiostecker erkennen und dem Schlüsselcode zuordnen:
    • 110–180 Ohm:KEYCODE_VOICE_ASSIST
  • [C-SR-2] Es wird DRINGEND empfohlen, Audiostecker mit der OMTP-Belegung zu unterstützen.
  • [C-SR-3] Es wird DRINGEND empfohlen, die Audioaufnahme über Stereo-Headsets mit Mikrofon zu unterstützen.

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

  • [C-2-1] MUSS die Erkennung des Mikrofons des angeschlossenen Audiozubehörs unterstützen.
7.8.2.2. Digitale Audioports

Gerätespezifische Anforderungen finden Sie unter 2.2.1.

7.8.3. Nah-Ultraschall

Nah-Ultraschall-Audio ist das Band von 18,5 kHz bis 20 kHz.

Geräteimplementierungen:

  • Die Unterstützung der Near-Ultraschall-Audiofunktion muss über die AudioManager.getProperty API wie unten beschrieben korrekt gemeldet werden:

Wenn PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND „wahr“ ist, MÜSSEN die folgenden Anforderungen von den Audioquellen VOICE_RECOGNITION und UNPROCESSED erfüllt werden:

  • [C-1-1] Die mittlere Leistungsantwort des Mikrofons im Bereich von 18,5 kHz bis 20 kHz darf maximal 15 dB unter der Antwort bei 2 kHz liegen.
  • [C-1-2] Das ungewichtete Signal-Rausch-Verhältnis des Mikrofons bei 18,5 kHz bis 20 kHz für einen 19 kHz-Ton bei −26 dBFS darf nicht unter 50 dB liegen.

Wenn PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND „wahr“ ist:

  • [C-2-1] Die mittlere Antwort des Lautsprechers bei 18,5 kHz bis 20 kHz DARF nicht mehr als 40 dB unter der Antwort bei 2 kHz liegen.

7.8.4. Signalintegrität

Geräteimplementierungen:

  • MÜSSEN einen störungsfreien Audiosignalpfad sowohl für Eingabe- als auch für Ausgabestreams auf Mobilgeräten bereitstellen, was durch Null-Störungen während eines Tests von einer Minute pro Pfad definiert wird. Teste mit OboeTester den „Automatischen Glitch-Test“.

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

OboeTester unterstützt derzeit AAudio-Pfade. Daher sollten die folgenden Kombinationen mit AAudio auf Störungen geprüft werden:

Perf-Modus Inhalte teilen Ausgabeabtastrate In Chans Out-Channels
LOW_LATENCY EXKLUSIV KEINE ANGABE 1 2
LOW_LATENCY EXKLUSIV KEINE ANGABE 2 1
LOW_LATENCY Weiterempfohlen KEINE ANGABE 1 2
LOW_LATENCY Weiterempfohlen KEINE ANGABE 2 1
KEINE Weiterempfohlen 48000 1 2
KEINE Weiterempfohlen 48000 2 1
KEINE Weiterempfohlen 44100 1 2
KEINE Weiterempfohlen 44100 2 1
KEINE Weiterempfohlen 16000 1 2
KEINE Weiterempfohlen 16000 2 1

Ein zuverlässiger Stream MUSS die folgenden Kriterien für das Signal-Rausch-Verhältnis (SNR) und die Gesamtharmonische Verzerrung (Total Harmonic Distortion, THD) für eine Sinuswelle von 2.000 Hz erfüllen.

Wandler THD SNR
primärer integrierter Lautsprecher, gemessen mit einem externen Referenzmikrofon < 3,0% >= 50 dB
primäres integriertes Mikrofon, gemessen mit einem externen Referenzlautsprecher < 3,0% >= 50 dB
Integrierte analoge 3,5‑mm-Anschlüsse, getestet mit Loopback-Adapter < 1 % >= 60 dB
Mit dem Smartphone gelieferte USB-Adapter, getestet mit Loopback-Adapter < 1,0% >= 60 dB

7.9. Virtual Reality

Android bietet APIs und Funktionen zum Erstellen von Virtual-Reality-Anwendungen (VR), einschließlich hochwertiger mobiler VR-Erlebnisse. Geräteimplementierungen MÜSSEN diese APIs und Verhaltensweisen ordnungsgemäß implementieren, wie in diesem Abschnitt beschrieben.

7.9.1. Virtual Reality-Modus

Android unterstützt den VR-Modus, eine Funktion, die das stereoskopische Rendern von Benachrichtigungen verarbeitet und monokulare System-UI-Komponenten deaktiviert, während eine VR-Anwendung im Fokus des Nutzers steht.

7.9.2. Virtual Reality-Modus – hohe Leistung

Wenn Geräteimplementierungen den VR-Modus unterstützen, gilt Folgendes:

  • [C-1-1] Es müssen mindestens zwei physische Kerne vorhanden sein.
  • [C-1-2] Die Funktion android.hardware.vr.high_performance MUSS deklariert werden.
  • [C-1-3] MUSS den Modus für eine konstante Leistung unterstützen.
  • [C-1-4] MUSS OpenGL ES 3.2 unterstützen.
  • [C-1-5] MUSS android.hardware.vulkan.level 0 unterstützen.
  • Sollte android.hardware.vulkan.level 1 oder höher unterstützen.
  • [C-1-6] MUSS EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content und EGL_EXT_image_gl_colorspace implementieren und die Erweiterungen in der Liste der verfügbaren EGL-Erweiterungen anbieten.
  • [C-1-8] MUSS GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2 und GL_EXT_protected_textures implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen angeben.
  • [C-SR-1] Es wird DRINGEND empfohlen, GL_EXT_external_buffer, GL_EXT_EGL_image_array und GL_OVR_multiview_multisampled_render_to_texture zu implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen anzugeben.
  • [C-SR-2] Es wird DRINGEND empfohlen, Vulkan 1.1 zu unterstützen.
  • [C-SR-3] Es wird DRINGEND empfohlen, VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing und VK_KHR_shared_presentable_image zu implementieren und in der Liste der verfügbaren Vulkan-Erweiterungen anzugeben.
  • [C-SR-4] Es wird DRINGEND empfohlen, mindestens eine Vulkan-Warteschlangenfamilie bereitzustellen, bei der flags sowohl VK_QUEUE_GRAPHICS_BIT als auch VK_QUEUE_COMPUTE_BIT enthält und queueCount mindestens 2 ist.
  • [C-1-7] Die GPU und das Display MÜSSEN den Zugriff auf den freigegebenen Front-Buffer synchronisieren können, damit das abwechselnde Rendern von VR-Inhalten mit zwei Rendering-Kontexten bei 60 fps ohne sichtbare Tearing-Artefakte dargestellt wird.
  • [C-1-9] Es MUSS Unterstützung für die AHardwareBuffer-Flags AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA und AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT gemäß der Beschreibung im NDK implementiert werden.
  • [C-1-10] Es MUSS Unterstützung für AHardwareBuffers mit beliebigen Kombinationen der Nutzungsflags AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE und AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT für mindestens die folgenden Formate implementiert werden: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM und AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR-5] Es wird DRINGEND empfohlen, die Zuweisung von AHardwareBuffers mit mehr als einer Ebene und Flags und Formaten zu unterstützen, die in C-1-10 angegeben sind.
  • [C-1-11] MUSS die H.264-Dekodierung mit mindestens 3.840 × 2.160 bei 30 fps unterstützen, komprimiert auf durchschnittlich 40 Mbit/s (entspricht 4 Instanzen von 1.920 × 1.080 bei 30 fps – 10 Mbit/s oder 2 Instanzen von 1.920 × 1.080 bei 60 fps – 20 Mbit/s).
  • [C-1-12] MUSS HEVC und VP9 unterstützen, MUSS mindestens 1920 × 1080 bei 30 fps decodieren können, komprimiert auf durchschnittlich 10 Mbit/s, und SOLLTE 3840 × 2160 bei 30 fps bis 20 Mbit/s decodieren können (entspricht 4 Instanzen von 1920 × 1080 bei 30 fps bis 5 Mbit/s).
  • [C-1-13] MUSS die HardwarePropertiesManager.getDeviceTemperatures API unterstützen und genaue Werte für die Hauttemperatur zurückgeben.
  • [C-1-14] Es MUSS ein eingebetteter Bildschirm vorhanden sein und die Auflösung MUSS mindestens 1.920 × 1.080 betragen.
  • [C-SR-6] Es wird DRINGEND empfohlen, eine Bildschirmauflösung von mindestens 2.560 × 1.440 zu verwenden.
  • [C-1-15] Das Display muss im VR-Modus mindestens 60 Hz aktualisieren.
  • [C-1-17] Das Display MUSS einen Modus mit geringer Nachleuchtdauer mit einer Nachleuchtdauer von maximal 5 Millisekunden unterstützen. Die Nachleuchtdauer ist die Zeit, in der ein Pixel Licht ausstrahlt.
  • [C-1-18] MUSS Bluetooth 4.2 und die Bluetooth LE Data Length Extension (Bluetooth LE-Datenlängenerweiterung) unterstützen Abschnitt 7.4.3.
  • [C-1-19] Der Typ des direkten Kanals muss für alle folgenden