Android 15-Kompatibilitätsdefinition

1. Einführung

In diesem Dokument werden die Anforderungen aufgeführt, die bei Geräten erfüllt werden müssen. um mit Android 15 kompatibel zu sein.

Die Verwendung von "MUSS", "DARF NICHT", "ERFORDERLICH", "WIRD", "WIRD NICHT", "SOLLTE", „Sollte nicht“, „EMPFOHLEN“, „KANN“ und „OPTIONAL“ entspricht dem IETF-Standard die in RFC 2119 definiert sind.

Wie in diesem Dokument verwendet, oder „Implementierer“ ist eine Person oder eine Organisation, die eine Hardware-/Softwarelösung mit Android entwickelt 15. Eine „Geräteimplementierung“ oder „Implementierung“ ist der Hardware-/Softwarelösung entwickelt.

Damit das Gerät mit Android 15 kompatibel ist, muss das Gerät Implementierungen MÜSSEN den Anforderungen dieser Kompatibilitäts- Definition, einschließlich aller Dokumente, die durch Verweis aufgenommen wurden.

Wenn diese Definition oder die im Abschnitt Abschnitt 10 nicht verständlich, mehrdeutig oder ist es in der Verantwortung der Geräteimplementierung, sicherzustellen, Kompatibilität mit bestehenden Implementierungen.

Aus diesem Grund bietet das Open-Source-Projekt von Android ist sowohl die Referenz als auch die bevorzugte Implementierung von Android. Gerät Implementierer wird dringend empfohlen, ihre Implementierungen auf die größtmögliche Reichweite bei der "Upstream"- im Quellcode verfügbar: Open-Source-Projekt von Android Auch wenn einige Komponenten hypothetisch durch alternative Implementierungen ersetzt werden, wird UNBEDINGT EMPFOHLEN, befolgen Sie diese Praxis, da das Bestehen der Softwaretests im Wesentlichen schwieriger wird. Es liegt in der Verantwortung der implementierenden Person, Verhaltenskompatibilität mit der standardmäßigen Android-Implementierung, einschließlich und über die Kompatibilitätstest-Suite hinaus. Beachten Sie, dass bestimmte Komponenten Ersetzungen und Änderungen sind in diesem Dokument ausdrücklich untersagt.

Viele der in diesem Dokument verlinkten Ressourcen sind direkt abgeleitet oder indirekt vom Android SDK bereitgestellt werden. Außerdem sind sie funktionell identisch mit dem in der Dokumentation des SDKs. In allen Fällen, in denen diese Kompatibilität Die Definition oder die Kompatibilitätstest-Suite stimmt nicht mit dem SDK überein Dokumentation als maßgeblich gilt die SDK-Dokumentation. Alle technischen Details, die in den verlinkten Ressourcen in diesem Dokument enthalten sind, werden als Teil dieser Kompatibilitätsdefinition angesehen.

1.1 Dokumentstruktur

1.1.1 Anforderungen nach Gerätetyp

Abschnitt 2 enthält alle Anforderungen, die für eine Gerätetyp verwendet werden. Jeder Unterabschnitt von Paragraf 2 die für einen bestimmten Gerätetyp vorgesehen sind.

Alle anderen Anforderungen, die allgemein für alle Android-Geräte gelten finden Sie in den Abschnitten nach Abschnitt 2. Diese Anforderungen werden als „zentrale Anforderungen“ bezeichnet. in diesem Dokument.

1.1.2 Anforderungs-ID

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

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

Jede ID ist wie folgt definiert:

  • Gerätetyp-ID (weitere Informationen unter 2. Gerätetypen) <ph type="x-smartling-placeholder">
      </ph>
    • C: Kern (Anforderungen, die für alle Implementierungen von Android-Geräten gelten)
    • H: Android-Handheld-Gerät
    • T: Android TV-Gerät
    • A: Android Automotive-Implementierung
    • W: Android Watch-Implementierung
    • Tab: Android-Tablet-Implementierung
  • Bedingungs-ID <ph type="x-smartling-placeholder">
      </ph>
    • Wenn die Anforderung unbedingt erforderlich ist, wird diese ID auf 0 gesetzt.
    • Wenn die Anforderung bedingt ist, wird für die erste und die Zahl erhöht sich im selben Abschnitt um 1 denselben Gerätetyp.
  • Anforderungs-ID <ph type="x-smartling-placeholder">
      </ph>
    • Diese ID beginnt bei 1 und erhöht sich im selben Abschnitt Bedingung erfüllt werden.

1.1.3 Anforderungs-ID in Abschnitt 2

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

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

  • Die in Abschnitt 2 aufgeführte ID setzt sich wie folgt zusammen : Abschnitts-ID / Gerätetyp-ID – Bedingungs-ID – Anforderungs-ID (z.B. 7.4.3/A-0-1).

2. Gerätetypen

Das Open-Source-Projekt von Android bietet einen Software-Stack, für verschiedene Gerätetypen und Formfaktoren. Um die Sicherheit auf Geräten zu unterstützen, Softwarestack, einschließlich eines Ersatzbetriebssystems oder eines alternativen Kernels in einer sicheren Umgebung ausgeführt werden, und an anderen Stellen dieser CDD-Datei. Es gibt verschiedene Gerätetypen, die über ein besser etabliertes Ökosystem für die Anwendungsverteilung verfügen.

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

Alle Implementierungen von Android-Geräten, die in keine der beschriebenen Gerätetypen MÜSSEN weiterhin alle Anforderungen in den anderen Abschnitten dieser Kompatibilitätsdefinition.

2.1 Gerätekonfigurationen

Für die wichtigsten Unterschiede bei der Hardwarekonfiguration nach Gerät finden Sie in den gerätespezifischen Anforderungen in diesem Abschnitt.

2.2. Anforderungen an Handhelds

Ein Android-Handheld-Gerät bezieht sich auf eine Android-Geräteimplementierung, die in der Regel in der Hand gehalten werden, etwa bei einem MP3-Player, einem Telefon oder Tablet.

Implementierungen von Android-Geräten werden als Handhelds eingestuft, wenn sie alle folgenden Kriterien:

  • eine Stromquelle nutzen, die Mobilität ermöglicht, z. B. einen Akku.
  • Bildschirmgröße in einem Bereich von 4 Zoll bis 8 Zoll.
  • über eine Touchscreen-Eingabeoberfläche verfügen.

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

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

2.2.1. Hardware

Implementierungen von Handheld-Geräten:

  • [7.1.1.1/H-0-1] MUSS mindestens einen Wert haben Android-kompatibles Display mit einer Größe von mindestens 2,2 Zoll an der kurzen Seite und 3,4" an der langen Seite.
  • [7.1.1.3/H-SR-1] sind DRINGEND empfohlen, Nutzern die Möglichkeit bieten, die Displaygröße (Bildschirmdichte) zu ändern.

  • [7.1.1.1/H-0-2] MUSS die GPU-Zusammensetzung von Grafikpuffer, die mindestens so groß sind wie die höchste Auflösung Display.

  • [7.1.1.1/H-0-3]* MÜSSEN jeden UI_MODE_NORMAL zuordnen. Display, das für Anwendungen von Drittanbietern zur Verfügung gestellt wird, auf einem gut sichtbaren mit einer Fläche von mindestens 2,2" Zoll an der kurzen Seite und 8,9 cm Zoll an der langen Seite.

  • [7.1.1.3/H-0-1]* MUSS den Wert von DENSITY_DEVICE_STABLE muss mindestens 92% der tatsächlichen physischen Dichte entsprechen. des entsprechenden Bildschirms.

Wenn Implementierungen von Handheld-Geräten Vulkan unterstützen, gilt Folgendes:

Wenn die Implementierung von Handheld-Geräten Unterstützung für High Dynamic Range fordert wird bis Configuration.isScreenHdr() angezeigt , Sie:

  • [7.1.4.5/H-1-1] MUSS Support für den 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 Erweiterungen.

Implementierungen von Handheld-Geräten:

  • [7.1.4.6/H-0-1] MÜSSEN melden, ob das Gerät unterstützt die GPU-Profilerstellung über ein Systemattribut graphics.gpu.profiler.support

Wenn Implementierungen von Handheld-Geräten die Unterstützung über eine Systemeigenschaft deklarieren graphics.gpu.profiler.support, sie/er:

Implementierungen von Handheld-Geräten:

  • [7.1.5/H-0-1] MUSS Unterstützung für ältere Versionen umfassen. App-Kompatibilitätsmodus, wie er von den vorgelagerten offenen Android-Geräten implementiert wurde Quellcode verfügbar. Das heißt, Geräteimplementierungen DÜRFEN NICHT die Auslöser oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert ist, und DÜRFEN NICHT verändern, des Kompatibilitätsmodus selbst.
  • [7.2.1/H-0-1] MÜSSEN Support für Drittanbieter IME-Anwendungen (Input Method Editor)
  • [7.2.3/H-0-2] MÜSSEN sowohl das normale als auch das lange Drücken senden. Ereignis der Zurück-Funktion (KEYCODE_BACK) zur Anwendung im Vordergrund. Diese Ereignisse DÜRFEN NICHT vom System verarbeitet werden. und KANN von außerhalb des Android-Geräts ausgelöst werden (z. B. durch externe Hardware). Tastatur, die mit dem Android-Gerät verbunden ist).
  • [7.2.3/H-0-3] MUSS die Home-Funktion auf auf allen mit Android kompatiblen Bildschirmen, die den Startbildschirm nutzen.
  • [7.2.3/H-0-4] MUSS die Funktion „Back“ bei allen die mit Android kompatiblen Displays und die Funktion „Zuletzt verwendet“ auf mindestens einem der auf den mit Android kompatiblen Displays.
  • [7.2.4/H-0-1] MUSS die Touchscreen-Eingabe unterstützen.
  • [7.2.4/H-SR-1] wird dringend empfohlen, vom Nutzer ausgewählte Assistent-App, d. h. die App, die VoiceInteractionService oder eine Aktivität, die ACTION_ASSIST verarbeitet, durch langes Drücken von KEYCODE_MEDIA_PLAY_PAUSE oder KEYCODE_HEADSETHOOK wenn diese Ereignisse durch langes Drücken bei der Vordergrundaktivität nicht verarbeitet werden.
  • [7.3.1/H-SR-1] WIRD UNBEDINGT ZU 3-Achsen EMPFOHLEN Beschleunigungsmesser.

Wenn Handheld-Geräte einen dreiachsigen Beschleunigungsmesser enthalten, gilt Folgendes:

  • [7.3.1/H-1-1] MÜSSEN in der Lage sein, Ereignisse bis zu einer bestimmten Häufigkeit zu melden. von mindestens 100 Hz.

Wenn die Implementierung von Handheld-Geräten einen GPS/GNSS-Empfänger umfasst und über die android.hardware.location.gps-Funktion verfügbar machen. melden sie:

  • [7.3.3/H-2-1] MÜSSEN GNSS-Messungen melden, sobald sie gefunden werden, auch wenn ein über GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
  • [7.3.3/H-2-2] MÜSSEN GNSS-Pseudorange und Pseudorange melden nach der Bestimmung des Standorts unter freiem Himmel, während oder sich bewegen, weniger als 0,2 Meter pro Sekunde zum Quadrat beschleunigen, reichen aus, um die Position innerhalb von 20 Metern zu berechnen, und die Geschwindigkeit. in mindestens 95% der Fälle mit einer Geschwindigkeit von 0, 2 Metern pro Sekunde.

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

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

Implementierungen von Handheld-Geräten, die einen Sprachanruf tätigen und beliebiger Wert außer PHONE_TYPE_NONE in getPhoneType:

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

Implementierungen von Handheld-Geräten:

  • [7.3.11/H-SR-1] WERDEN DRINGEND zur Unterstützung des Positionssensors empfohlen mit 6 Freiheitsgraden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [7.4.3/H] SOLLTEN Support für Bluetooth und Bluetooth LE.

Implementierungen von Handheld-Geräten, die Bluetooth LE unterstützen:

  • [7.4.3/H-SR-1] Support wird dringend empfohlen. Bluetooth LE-Erweiterung zur Datenpaketlänge.

Neue Anforderungen beenden

Wenn die Geräte das NAN-Protokoll (Wi-Fi Neighbor Awareness Networking) unterstützen, Angeben von PackageManager.FEATURE_WIFI_AWARE und WLAN-Standort (Wi-Fi Round Fahrtzeit – RTT), indem sie PackageManager.FEATURE_WIFI_RTT deklarieren, dann gilt Folgendes:

  • [7.4.2.5/H-1-1] MÜSSEN den Bereich genau an innerhalb von +/- 1 Meter bei einer Bandbreite von 160 MHz im 68. Perzentil (gemäß Berechnung mit der kumulativen Verteilungsfunktion) +/- 2 Meter bei 80 MHz Bandbreite bei das 68. Perzentil, +/- 4 Meter bei 40 MHz Bandbreite beim 68. Perzentil, und +/- 8 Meter bei einer Bandbreite von 20 MHz im 68. Perzentil bei Entfernungen von 10 cm, 1 m, 3 m und 5 m, wie aus dem WifiRttManager#startRanging Android API

  • [7.4.2.5/H-SR-1] wird dringend empfohlen, Bereich genau im Bereich +/- 1 Meter bei 160 MHz Bandbreite am 90. Perzentil (wie mit der Funktion für kumulierte Verteilung berechnet), +/-2 Meter bei einer Bandbreite von 80 MHz beim 90. Perzentil, +/- 4 Meter bei 40 MHz Bandbreite beim 90. Perzentil und +/- 8 Meter bei 20 MHz Bandbreite bei 90. Perzentil bei einem Abstand von 10 cm, aus Sicht des WifiRttManager#startRanging Android API

Es wird dringend empfohlen, die unter Anwesenheitskalibrierung:

Wenn in Implementierungen von Handheld-Geräten FEATURE_BLUETOOTH_LE deklariert ist, gilt Folgendes:

  • [7.4.3/H-1-3] MUSS Rx messen und kompensieren Offset, um sicherzustellen, dass der Medianwert BLE RSSI bei -50 dBm +/-15 dB bei 1 m Abstand von einem Referenzgerät, das um ADVERTISE_TX_POWER_HIGH überträgt.
  • [7.4.3/H-1-4] MÜSSEN die Tx messen und kompensieren. Offset, um sicherzustellen, dass der Medianwert für BLE RSSI bei -50 dBm +/-15 dB beim Scannen von einer Referenzgerät, das in 1 m Entfernung positioniert ist und bei ADVERTISE_TX_POWER_HIGH

Wenn Handheld-Implementierungen ein logisches Kameragerät enthalten, das mit CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, Sie:

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

Implementierungen von Handheld-Geräten:

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

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

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

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

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

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

Wenn Implementierungen von Handheld-Geräten die Unterstützung von 64-Bit-ABIs (mit oder ohne 32-Bit-ABI) deklarieren:

  • [7.6.1/H-5-1] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 816 MB groß, wenn der Standardbildschirm höhere Framebuffer-Auflösungen verwendet zu qHD (z.B. FWVGA).

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

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

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

Beachten Sie, dass der für Kernel und Userspace verfügbare Arbeitsspeicher bezieht sich auf den Arbeitsspeicher zusätzlich zu dem bereits für Hardware vorgesehenen Arbeitsspeicher wie Radio, Video usw., die sich nicht im Kernel- Geräteimplementierungen steuern.

Implementierung von Handheld-Geräten mit weniger als oder gleich 1 GB Arbeitsspeicher dem Kernel und Userspace zur Verfügung stehen,

  • [7.6.1/H-9-1] MUSS das Funktions-Flag deklarieren. android.hardware.ram.low
  • [7.6.1/H-9-2] MUSS mindestens 1,1 GB an nichtflüchtiger Speicher für Anwendungen private Daten (auch als „/data“-Partition bezeichnet).

Wenn Handheld-Implementierungen mehr als 1 GB Speicherplatz enthalten an den Kernel und Userspace haben,

  • [7.6.1/H-10-1] MUSS mindestens 4 GB an nichtflüchtiger Speicher verfügbar für Anwendungsdaten (auch als "/data"-Partition bezeichnet).
  • SOLLTEN das Funktions-Flag android.hardware.ram.normal deklarieren.

Wenn Implementierungen von Handheld-Geräten größer oder gleich 2 GB sind und weniger als 4 GB Speicher für den Kernel und Userspace verfügbar sind, gilt Folgendes:

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

Wenn die Implementierung von Handheld-Geräten weniger als 2 GB Speicherplatz Kernel und Userspace fest:

  • [7.6.1/H-1-1] DARF nur eine einzige ABI unterstützen (entweder nur 64-Bit oder 32-Bit). )

Implementierungen von Handheld-Geräten:

  • [7.6.2/H-0-1] DARF KEINEN Antrag einreichen gemeinsam genutzter Speicher kleiner als 1 GiB ist.
  • [7.7.1/H] SOLLTEN einen USB-Anschluss haben, der den Peripheriemodus unterstützt.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Handheld-Geräte einen USB-Port enthalten unterstützen mit einem Controller in Peripheriemodus verwenden sie:

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

Neue Anforderungen beenden

Wenn die Implementierung von Handheld-Geräten einen USB-Port umfasst, der den Hostmodus unterstützt, Sie:

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

Implementierungen von Handheld-Geräten:

  • [7.8.1/H-0-1] MUSS ein Mikrofon enthalten.
  • [7.8.2/H-0-1] MUSS einen Audioausgang haben und deklarieren android.hardware.audio.output

Ob Handheld-Implementierungen die gesamte Leistung Voraussetzungen für die Unterstützung des VR-Modus:

  • [7.9.1/H-1-1] MUSS die Funktions-Flag android.hardware.vr.high_performance.
  • [7.9.1/H-1-2] MUSS eine App enthalten Implementierung von android.service.vr.VrListenerService, die mit VR aktiviert werden können über android.app.Activity#setVrModeEnabled bewerben.

Implementierungen von Handheld-Geräten mit mindestens einem USB-C-Anschluss im Host zu verwenden (USB-Audioklasse), zusätzlich zu den Anforderungen in Abschnitt 7.7.2, sie:

  • [7.8.2.2/H-1-1] MUSS die folgende Softwarezuordnung bereitstellen der HID-Codes:
Funktion Zuordnungen Kontext Verhalten
A HID-Nutzungsseite: 0x0C
HID-Nutzung: 0x0CD
Kernelschlüssel: KEY_PLAYPAUSE
Android-Schlüssel: KEYCODE_MEDIA_PLAY_PAUSE
Medienwiedergabe Eingang: Kurz drücken
Ausgabe: Wiedergabe oder Pause
Eingabe: Lange drücken
Ausgabe: Sprachbefehl starten
Sendet: android.speech.action.VOICE_SEARCH_HANDS_FREE, wenn das Gerät gesperrt ist oder das Display ausgeschaltet ist. Sendet Andernfalls android.speech.RecognizerIntent.ACTION_WEB_SEARCH
Eingehender Anruf Eingang: Kurz drücken
Ausgabe: Anruf annehmen
Eingabe: Lange drücken
Ausgabe: Anruf ablehnen
Aktiver Anruf Eingang: Kurz drücken
Ausgabe: Anruf beenden
Eingabe: Lange drücken
Ausgabe: Mikrofon stummschalten oder Stummschaltung aufheben
B HID-Nutzungsseite: 0x0C
HID-Nutzung: 0x0E9
Kernelschlüssel: KEY_VOLUMEUP
Android-Schlüssel: VOLUME_UP
Medienwiedergabe, Aktiver Anruf Eingang: 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 Eingang: 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. Eingang: Kurz oder lang drücken
Ausgabe: Sprachbefehl starten
  • [7.8.2.2/H-1-2] MUSS ACTION_HEADSET_PLUG auslösen nach dem Einstecken, aber erst, nachdem die USB-Audioschnittstellen und -Endpunkte um den Typ des angeschlossenen Terminals zu ermitteln.

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

  • [7.8.2.2/H-2-1] MÜSSEN Intent ACTION_HEADSET_PLUG übertragen mit „Mikrofon“ auf 0 gesetzt.

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

  • [7.8.2.2/H-3-1] MÜSSEN Intent ACTION_HEADSET_PLUG übertragen mit „Mikrofon“ zusätzlich auf 1 gesetzt.

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

  • [7.8.2.2/H-4-1] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_HEADSET auflisten. und isSink(), wenn das Feld für den USB-Audio-Terminaltyp 0x0302 lautet.

  • [7.8.2.2/H-4-2] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_HEADSET und Rolle isSink(), wenn das USB-Audio-Terminal Typ ist 0x0402.

  • [7.8.2.2/H-4-3] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_HEADSET und Rolle isSource(), wenn das USB-Audio-Terminal Typ ist 0x0402.

  • [7.8.2.2/H-4-4] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE auflisten. und isSink(), wenn das Feld für den USB-Audio-Terminaltyp 0x603 lautet.

  • [7.8.2.2/H-4-5] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_DEVICE und Rolle isSource(), wenn das USB-Audioterminal Typ ist 0x604.

  • [7.8.2.2/H-4-6] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_DEVICE und Rolle isSink(), wenn der USB-Audio-Terminaltyp 0x400 ist.

  • [7.8.2.2/H-4-7] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_DEVICE und Rolle isSource(), wenn das USB-Audioterminal Typ ist 0x400.

  • [7.8.2.2/H-SR-1] werden dringend empfohlen bei Anschluss eines USB-C-Audio-Peripheriegerät, um eine Aufzählung der USB-Deskriptoren durchzuführen, Terminaltypen und Broadcast-Intent ACTION_HEADSET_PLUG in weniger als 1.000 Millisekunden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Für Implementierungen von Handheld-Geräten die erklären, android.hardware.audio.output und android.hardware.microphone, er/sie: Weitere Informationen zu RTL- und TTL-Anforderungen im Abschnitt 5.6

  • [5.6/H-1-1] MUSS einen mittleren kontinuierlichen Hin- und Rückflug haben eine Latenz von 300 Millisekunden weniger über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 30 ms, mehr die folgenden Datenpfade: „Lautsprecher zu Mikrofon“, 3,5-mm-Loopback-Adapter (falls unterstützt), USB-Loopback-Adapter (falls unterstützt).

  • [5.6/H-1-2] MUSS eine durchschnittliche Latenz von Tap-to-Ton haben. von 300 Millisekunden oder Weniger als mindestens 5 Messungen über dem Lautsprecher zum Mikrofondatenpfad.

Neue Anforderungen beenden

Ein linearer Resonanzaktuator (LRA) ist ein System mit einer Massenfeder, das dominante Resonanzfrequenz, bei der sich die Masse in Richtung des gewünschte Bewegung.

Wenn Implementierungen für Handheld-Geräte mindestens einen allgemeinen Zweck erfüllen: 7.10 linearen Resonanzantrieb,

  • [7.10/H] SOLLTE die Position des Bedienelements in der Nähe von Die Stelle, an der das Gerät normalerweise mit den Händen gehalten oder berührt wird.

  • [7,10/H] SOLLTEN Sie den haptischen Auslöser in der X-Achse verschieben. (links-rechts) der natürlichen Ausrichtung des Geräts entspricht.

Wenn Implementierungen von Handheld-Geräten einem allgemeinen Zweck dienen einen haptischen Aktivator, also einen X-Achsen-Linear-Resonantenaktuator (Linear Resonant Actuator, LRA), ihn:

  • [7,10/H] SOLLTE die Resonanzfrequenz des LRA auf der X-Achse unter 200 Hz liegen.

Wenn Implementierungen von Handheld-Geräten der Zuordnung haptischer Konstanten folgen, gilt Folgendes:

2.2.2. Multimedia

Implementierungen von Handheld-Geräten MÜSSEN die folgenden Audiocodierung und Decodierungsformaten und stellen sie für Anwendungen von Drittanbietern zur Verfügung:

  • [5.1/H-0-1] AMR-NB
  • [5.1/H-0-2] AMR-WB
  • [5.1/H-0-3] MPEG-4 AAC Profile (AAC LC)
  • [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/H-0-5] AAC ELD (Optimierte AAC mit niedriger Verzögerung)

Implementierungen von Handheld-Geräten MÜSSEN die folgende Videocodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:

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

Implementierungen von Handheld-Geräten MÜSSEN die folgende Videodecodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:

  • [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 von Handheld-Geräten:

  • [3.2.3.1/H-0-1] MUSS einen die ACTION_GET_CONTENT verarbeitet, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE und ACTION_CREATE_DOCUMENT Intents entsprechend der Beschreibung in den SDK-Dokumenten und bieten der Nutzerfreundlichkeit um über die DocumentsProvider API auf die Daten des Dokumentanbieters zuzugreifen.
  • [3.2.3.1/H-0-2]* MUSS einen vorab laden. oder mehr Anwendungen oder Dienstkomponenten mit Intent-Handlern enthalten, alle öffentlichen Intent-Filtermuster, die von der folgenden Anwendung definiert wurden Hier finden Sie eine Liste der Intents.
  • [3.2.3.1/H-SR-1] sind STARK EMPFOHLEN, eine E-Mail-Anwendung vorab zu laden, die ACTION_SENDTO verarbeiten kann oder ACTION_SEND oder ACTION_SEND_MULTIPLE eine E-Mail zu senden.
  • [3.4.1/H-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API
  • [3.4.2/H-0-1] MUSS einen eigenständigen Browser enthalten für das allgemeine Surfen im Web.
  • [3.8.1/H-SR-1] werden dringend empfohlen. zur Implementierung eines Standard-Launchers, der das Anpinnen von Verknüpfungen in der App unterstützt, Widgets und widgetFeatures.
  • [3.8.1/H-SR-2] werden dringend empfohlen. zur Implementierung eines Standard-Launchers, der schnellen Zugriff auf die zusätzlichen Verknüpfungen von Drittanbieter-Apps über ShortcutManager der API erstellen.
  • [3.8.1/H-SR-3] werden dringend empfohlen. um eine Standard-Launcher-App hinzuzufügen, bei der Kennzeichen für die App-Symbole angezeigt werden.
  • [3.8.2/H-SR-1] werden dringend empfohlen. um Widgets von Drittanbieter-Apps zu unterstützen.
  • [3.8.3/H-0-1] MUSS Drittanbieter-Cookies zulassen, Apps, um Nutzer über die Notification und über wichtige Ereignisse zu informieren. NotificationManager API-Klassen.
  • [3.8.3/H-0-2] MUSS Rich Media unterstützen Benachrichtigungen.
  • [3.8.3/H-0-3] MUSS die Warnmeldung unterstützen Benachrichtigungen.
  • [3.8.3/H-0-4] MUSS mit einem Benachrichtigungsleiste, über die der Nutzer direkt steuern kann (z.B. Antworten, Schlummerfunktion, Schließen, Sperren) der Benachrichtigungen durch Nutzerangebote wie Aktionsschaltflächen oder das Steuerfeld, wie im AOSP implementiert.
  • [3.8.3/H-0-5] MÜSSEN die Auswahlmöglichkeiten anzeigen. bereitgestellt über RemoteInput.Builder setChoices() in der Benachrichtigungsleiste.
  • [3.8.3/H-SR-1] werden dringend empfohlen. um die erste Auswahl von RemoteInput.Builder setChoices() anzuzeigen. ohne zusätzliche Nutzerinteraktion in der Benachrichtigungsleiste.
  • [3.8.3/H-SR-2] werden dringend empfohlen. um alle Auswahlmöglichkeiten in RemoteInput.Builder setChoices() anzuzeigen. in der Benachrichtigungsleiste angezeigt, wenn der Nutzer alle Benachrichtigungen in der Benachrichtigungsleiste.
  • [3.8.3.1/H-SR-1] werden dringend empfohlen. um Aktionen anzuzeigen, für die Notification.Action.Builder.setContextual ist auf true in der Zeile mit den Antworten festgelegt, die von Notification.Remoteinput.Builder.setChoices
  • [3.8.4/H-SR-1] werden dringend empfohlen. um einen Assistenten für die Unterstützungsaktion auf dem Gerät zu implementieren.

Wenn Implementierungen von Handheld-Geräten MediaStyle-Benachrichtigungen unterstützen Sie:

  • [3.8.3.1/H-SR-2] werden dringend empfohlen. um Nutzern Angebote (z. B. Ausgabeauswahl) zu bieten, auf die über System-UI, die es Nutzern ermöglicht, zwischen geeigneten verfügbaren Medien zu wechseln (z. B. Bluetooth-Geräte und Routen, die für MediaRouter2Manager) Eine App postet eine MediaStyle-Benachrichtigung mit einem MediaSession-Token.

Wenn Geräteimplementierungen die Navigationstaste für die Funktion „Recents“ (Zuletzt verwendet) als wie in Abschnitt 7.2.3 beschrieben, verändern sich die Oberfläche wie folgt:

  • [3.8.3/H-1-1] MUSS den Bildschirm implementieren Funktion zum Anpinnen und stellen dem Nutzer ein Einstellungsmenü zur Verfügung, in dem er die Einstellungen .

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

  • [3.8.4/H-SR-2] werden dringend empfohlen. um die entsprechende Interaktion zu starten, indem du die HOME-Taste lange drückst. wie in Abschnitt 7.2.3 beschrieben beschrieben. MUSS gestartet werden die vom Nutzer ausgewählte Assistent-App, d. h. die App, VoiceInteractionService, oder eine Aktivität, die den Intent ACTION_ASSIST verarbeitet.

Wenn Implementierungen von Handheld-Geräten conversation notifications unterstützen und gruppieren Sie sie in einem separaten Abschnitt Benachrichtigungen erhalten, können sie:

  • [3.8.4/H-1-1]* MUSS angezeigt werden. Unterhaltungsbenachrichtigungen vor Benachrichtigungen ohne Unterhaltung mit mit Ausnahme von laufenden Benachrichtigungen zu Diensten im Vordergrund wichtigkeit:hoch Benachrichtigungen.

Wenn Implementierungen von Android-Handheld-Geräten einen Sperrbildschirm unterstützen, gilt Folgendes:

  • [3.8.10/H-1-1] MÜSSEN das Schloss anzeigen Screen Notifications einschließlich der Media Notification Template.

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

  • [3.9/H-1-1] MUSS die gesamte Bandbreite an Geräteverwaltung die in der Android SDK-Dokumentation definiert sind.

Wenn Implementierungen von Handheld-Geräten Unterstützung für ControlsProviderService und Control APIs und Apps von Drittanbietern die Veröffentlichung von Gerätesteuerungen erlauben, geschieht Folgendes:

  • [3.8.16/H-1-1] MUSS die Funktion deklarieren android.software.controls melden und legen Sie dafür true fest.
  • [3.8.16/H-1-2] MUSS einen Nutzer Angebote mit der Möglichkeit zum Hinzufügen, Bearbeiten, Auswählen und Steuerelemente für bevorzugte Geräte über die vom Drittanbieter registrierten Steuerelemente über die ControlsProviderService und Control APIs
  • [3.8.16/H-1-3] MUSS Zugriff auf innerhalb von drei Interaktionen über einen Standard-Launcher.
  • [3.8.16/H-1-4] MUSS korrekt gerendert werden in diesem Nutzerangebot den Namen und das Symbol jeder Drittanbieter-App, die stellt Steuerelemente über die ControlsProviderService bereit API sowie in den vom Control APIs

  • [3.8.16/H-1-5] MUSS einen Nutzer Möglichkeit der Deaktivierung von App-spezifischen, authentifizierungsrelevanten Gerätesteuerungen von die Kontrollen, die von den Drittanbieter-Anwendungen über die ControlsProviderService und Control Control.isAuthRequired API verwenden.

  • [3.8.16/H-1-6] Geräteimplementierungen MÜSSEN die Nutzerangebote wie folgt korrekt wiedergeben:

  • [3.8.16/H-1-7] Wenn die App die Metadaten deklariert META_DATA_PANEL_ACTIVITY, Es MUSS den Wert der in [3.8.16/H-1-5] definierten Einstellung mit EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS beim Starten der eingebetteten Aktivität.

Umgekehrt gilt: Wenn solche Steuerungen nicht in Handheld-Implementierungen implementiert sind, Sie:

Wenn Implementierungen von Handheld-Geräten nicht im Sperrmodus ausgeführt werden und Inhalte in die Zwischenablage kopiert werden, geschieht Folgendes:

  • [3.8.17/H-1-1] MÜSSEN dem Nutzer eine Bestätigung vorlegen, dass die Daten in die Zwischenablage kopiert (z. B. eine Miniaturansicht oder die Meldung „Inhalt kopiert“). Gib hier außerdem an, ob die Daten in der Zwischenablage synchronisiert werden geräteübergreifend.

Implementierungen von Handheld-Geräten:

  • [3.10/H-0-1] MUSS die Barrierefreiheit von Drittanbietern unterstützen .
  • [3.10/H-SR-1] wird dringend empfohlen, vorab zu laden. Bedienungshilfen auf dem Gerät, die mit der Funktionalität vergleichbar oder sogar übertreffen des Schalterzugriffs und von TalkBack (für Sprachen, die vom vorinstallierten Bedienungshilfen (Text-in-Sprache-Engine), die in der offenen TalkBack-Funktion bereitgestellt werden Quellprojekt.
  • [3.11/H-0-1] MUSS die Installation von Sprachausgabe-Engines von Drittanbietern.
  • [3.11/H-SR-1] wird dringend empfohlen, Folgendes anzugeben: Sprachausgabe-Engine, die die auf dem Gerät verfügbaren Sprachen unterstützt
  • [3.13/H-SR-1] wird dringend empfohlen, Folgendes anzugeben: UI-Komponente für Schnelleinstellungen

Wenn in Implementierungen von Android-Handheld-Geräten FEATURE_BLUETOOTH oder FEATURE_WIFI-Support, sie:

  • [3.16/H-1-1] MUSS die Kopplung von Begleitgeräten unterstützen .

Wenn die Navigationsfunktion als bewegungsbasierte Aktion auf dem Bildschirm bereitgestellt wird:

  • [7.2.3/H] Der Bereich für die Bewegungserkennung des Zuhauses dürfen nicht mehr als 32 dp vom unteren Rand des Bildschirm.

Wenn Implementierungen von Handheld-Geräten eine Navigationsfunktion als Geste bieten an einer beliebigen Stelle am linken und rechten Bildschirmrand:

  • [7.2.3/H-0-1] Der Touch-Gestenbereich der Navigationsfunktion MÜSSEN auf jeder Seite weniger als 40 dp breit sein. Der Gestenbereich SOLLTE Die Standardbreite beträgt 24 dp.

Ob Handheld-Implementierungen einen sicheren Sperrbildschirm unterstützen und mindestens 2 GB Arbeitsspeicher, der dem Kernel und Userspace zur Verfügung steht, geschieht Folgendes:

  • [3.9/H-1-2] MÜSSEN die Unterstützung verwalteter Profile Funktions-Flag „android.software.managed_users“.

Wenn Implementierungen von Android-Handheld-Geräten die Kamera-Unterstützung android.hardware.camera.any:

Wenn die Einstellungsanwendung der Geräteimplementierung ein Aufteilungsfunktion, mithilfe der Aktivitätseinbettung:

Wenn Geräte, die es Nutzern ermöglichen, beliebige Anrufe zu tätigen,

2.2.4 Leistung und Leistung

  • [8.1/H-0-1] Konsistente Framelatenz. Inkonsistente Frame-Latenz oder Verzögerungen beim Rendern von Frames DÜRFEN NICHT öfter auftreten häufiger als 5 Frames pro Sekunde und SOLLTEN unter 1 Frames pro Sekunde liegen.
  • [8.1/H-0-2] Latenz der Benutzeroberfläche. Geräteimplementierungen MÜSSEN die Nutzererfahrung mit niedriger Latenz durch Scrollen nach Liste mit 10.000 Listeneinträgen gemäß der Definition der Android Compatibility Test Suite (CTS) in weniger als 36 Sekunden.
  • [8.1/H-0-3] Aufgabenwechsel. Wann? mehrere Anwendungen gestartet wurden, startet eine bereits laufende nach dem Start MUSS weniger als eine Sekunde dauern.

Implementierungen von Handheld-Geräten:

  • [8.2/H-0-1] MÜSSEN sicherstellen, dass eine sequenzielle von mindestens 5 MB/s schreiben.
  • [8.2/H-0-2] MÜSSEN sicherstellen, dass ein zufälliger Schreibvorgang stattfindet. mit mindestens 0,5 MB/s arbeiten.
  • [8.2/H-0-3] MUSS einen sequenziellen Lesevorgang sicherstellen mit mindestens 15 MB/s arbeiten.
  • [8.2/H-0-4] MUSS einen zufälligen Lesevorgang sicherstellen mit mindestens 3,5 MB/s arbeiten.

Wenn Implementierungen von Handheld-Geräten Funktionen zur Verbesserung der Geräteleistung enthalten die in AOSP enthalten sind, oder die Funktionen zu erweitern, bei AOSP:

  • [8.3/H-1-1] MUSS zum Aktivieren die Nutzeroptionen zur Verfügung stellen. und den Energiesparmodus deaktivieren.
  • [8.3/H-1-2] MUSS zum Anzeigen die Nutzereigenschaften bieten. Alle Apps, die vom App-Standby- und Stromsparmodus ausgenommen sind

Implementierungen von Handheld-Geräten:

  • [8.4/H-0-1] MÜSSEN eine Leistungsprofil pro Komponente, das den aktuellen Verbrauchswert definiert für jede Hardwarekomponente und die ungefähre Entladung des Akkus aufgrund der wie auf der Website des Android Open Source Project dokumentiert.
  • [8.4/H-0-2] MÜSSEN die gesamte Stromversorgung melden. Verbrauchswerte in Milliamperestunden (mAh) angegeben.
  • [8.4/H-0-3] MÜSSEN die CPU-Leistung melden pro Prozess UID. Das Open-Source-Projekt von Android erfüllt Anforderung durch die Implementierung des Kernelmoduls uid_cputime.
  • [8.4/H-0-4] MUSS diesen Stromverbrauch nutzen verfügbar über adb shell dumpsys batterystats Shell-Befehl an den App-Entwickler senden.
  • [8.4/H] SOLLTE dem Hardwarekomponente selbst, wenn der Stromverbrauch der Hardwarekomponente nicht zugeordnet werden kann zu einer Anwendung hinzufügen.

Implementierungen von Handheld-Geräten, die eine Bildschirm- oder Videoausgabe beinhalten:

Implementierungen von Handheld-Geräten:

  • [8.5/H-0-1] MUSS angegeben werden die Möglichkeit des Nutzers, alle Apps mit aktiven Diensten im Vordergrund zu sehen oder vom Nutzer initiierte Jobs, einschließlich der Dauer jedes dieser Dienste da er wie im SDK-Dokument beschrieben gestartet wurde.

  • [8.5/H-0-2]MÜSSEN Nutzern ein Kauferlebnis bieten. App beenden, die einen Dienst im Vordergrund ausführt, oder einen vom Nutzer initiierten Job

2.2.5 Sicherheitsmodell

Implementierungen von Handheld-Geräten:

  • [9/H-0-1] MUSS die android.hardware.security.model.compatible deklarieren .
  • [9.1/H-0-1] MÜSSEN Drittanbieter-Apps Zugriff auf Nutzungsstatistiken über die Berechtigung android.permission.PACKAGE_USAGE_STATS und einen für den Nutzer zugänglichen Mechanismus bereitstellen, den Zugriff auf solche Apps in Reaktion auf android.settings.ACTION_USAGE_ACCESS_SETTINGS die Nutzerabsicht verstehen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Geräteimplementierungen MÜSSEN Support für Folgendes erklären: android.software.credentials und:

  • [9/H-0-2] MÜSSEN den Intent android.settings.CREDENTIAL_PROVIDER berücksichtigen um einen bevorzugten Anbieter für die Anmeldedatenverwaltung auszuwählen. Dieser Anbieter wird für Autofill und ist auch der Standardspeicherort zum Speichern neuer Anmeldedaten über die Anmeldedaten-Manager eingegeben.

  • [9/H-0-3] MUSS mindestens zwei gleichzeitige Anmeldedatenanbieter unterstützen und in der App „Settings“ (Einstellungen) , um Anbieter zu aktivieren oder zu deaktivieren.

Neue Anforderungen beenden

Wenn in Geräteimplementierungen die Unterstützung von android.hardware.telephony deklariert wird, Sie:

  • [9.5/H-1-1] DARF NICHT UserManager.isHeadlessSystemUserMode festlegen an true.

Implementierungen von Handheld-Geräten:

  • [9.11/H-0-2] MUSS die Schlüsselspeicher-Implementierung sichern mit einer isolierten Ausführungsumgebung.
  • [9.11/H-0-3] MUSS Implementierungen von RSA, AES, Die kryptografischen Algorithmen ECDSA und HMAC sowie die MD5-, SHA-1- und SHA-2-Familie Hash-Funktionen genutzt werden, um die vom Android-Schlüsselspeichersystem unterstützten in einem Bereich, der sicher vom Code isoliert ist, Kernel und höher. Sichere Isolation MUSS alle potenziellen Mechanismen blockieren über den Kernel- oder Userspace-Code auf den internen Status des einer isolierten Umgebung, einschließlich DMA. Die vorgelagerte Open-Source-Version von Android Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung, aber eine andere ARM TrustZone-basierte Lösung oder von einem Drittanbieter geprüfte sichere Lösung Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation sind eine Alternative Optionen.
  • [9.11/H-0-4] MUSS den Sperrbildschirm starten in der isolierten Ausführungsumgebung und nur dann, erfolgreich war, können die mit der Authentifizierung gebundenen Schlüssel verwendet werden. Sperrbildschirm Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführung für die Sperrbildschirm-Authentifizierung. Die vorgelagerte Android- Open-Source-Projekt bietet Gatekeeper-Hardwareabstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [9.11/H-0-5] MUSS die Schlüsselattestierung unterstützen, wenn die Der Attestierungssignaturschlüssel wird durch sichere Hardware geschützt und die Signatur ist auf sicherer Hardware ausgeführt werden. Die Signaturschlüssel der Attestierung MÜSSEN gemeinsam verwendet werden Geräte groß genug ist, um die Schlüssel zu verhindern. verhindert nicht als dauerhaft Gerätekennungen. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel, es sei denn, mindestens 100.000 Einheiten einer SKU produziert wurden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, für je 100.000 Einheiten.

Neue Anforderungen beenden

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

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

  • [9.11/H-1-1] MUSS dem Nutzer die Möglichkeit geben, das kürzeste Ruhemodus-Timeout, d. h. eine Übergangszeit vom entsperrten zum gesperrten Zustand 15 Sekunden oder weniger anzeigen.
  • [9.11/H-1-2] MUSS Nutzern die Möglichkeit bieten, Inhalte auszublenden. und deaktivieren alle Formen der Authentifizierung mit Ausnahme der primäre Authentifizierung, beschrieben in 9.11.1 Sicherer Sperrbildschirm. Der AOSP trifft die als Sperrmodus erforderlich.

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

  • [9.11.1/H-1-1] MÜSSEN den Nutzer häufiger als alle 72 Stunden zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) auffordern.

Wenn die Implementierung von Handheld-Geräten mehrere Nutzer und Das Funktions-Flag android.hardware.telephony wird nicht deklariert, sie werden:

  • [9.5/H-2-1] MUSS eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteeigentümer zusätzliche Nutzer und ihre Funktionen auf dem Gerät. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen einrichten, in denen zusätzliche Nutzende arbeiten können, mit der Möglichkeit, differenziertere Einschränkungen in den Apps zu verwalten, die in diesen Umgebungen verfügbar sind.

Wenn die Implementierung von Handheld-Geräten mehrere Nutzer und das Funktions-Flag android.hardware.telephony deklarieren, wenn folgende Aktionen ausgeführt werden:

  • [9.5/H-3-1] DÜRFEN KEINE Unterstützung eingeschränkter Einschränkungen unterstützen Profile, MÜSSEN aber mit der AOSP-Implementierung der Kontrollen übereinstimmen. , um zu aktivieren /deaktivieren, dass andere Nutzer auf die Sprachanrufe und SMS zugreifen können.

Wenn bei Handheld-Implementierungen UserManager.isHeadlessSystemUserMode festgelegt ist an true, sie

  • [9.5/H-4-1] DÜRFEN KEINE Unterstützung für eUICCs enthalten, noch für eSIMs mit Anruffunktion.
  • [9.5/H-4-2] DÜRFEN KEINE Unterstützung für Folgendes deklarieren: android.hardware.telephony

Android unterstützt VoiceInteractionService über die System-API einen Mechanismus zur Sichere Hotword-Erkennung, die ständig aktiviert ist, aber keine Mikrofonzugriffserkennung anzeigt und Always-on-Abfrageerkennung, ohne Mikrofon oder Kamera Zugriffsanzeige hinzugefügt.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Eingeschränkte Einstellungen

Bei eingeschränkten Einstellungen werden Nutzern sichtbare Warnungen angezeigt und fordert den Nutzer zur Erteilung von Berechtigungen an. für jede Anwendung, die entweder

  • Installation nach dem Download über eine Anwendung (z. B. eine Messaging-Anwendung oder ein Browser), ein „App Store“ Anwendung identifiziert von PackageManager als PACKAGE_DOWNLOADED_FILE
  • Installation aus einer lokalen Datei (z. B. wenn die Anwendung per Sideload übertragen wurde) von PackageManager identifiziert als PACKAGE_SOURCE_LOCAL_FILE

Für alle erzwungenen Berechtigungen und zugehörigen Kennzeichnungen:

  • Wecker und Erinnerungen: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • Gesamter Dateizugriff: 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 Nutzungsdaten: AppOpsManager.OPSTR_GET_USAGE_STATS
  • Geräteadministrator: Manifest.permission.BIND_DEVICE_ADMIN
  • Bitte nicht stören: Manifest.permission.MANAGE_NOTIFICATIONS

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

Geräteimplementierungen:

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

    • Besondere Berechtigungen <ph type="x-smartling-placeholder">
        </ph>
      • Bedienungshilfen (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
      • Benachrichtigungs-Listener (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
      • Apps zur Geräteverwaltung (Manifest.permission.BIND_DEVICE_ADMIN)
      • Über anderen Apps einblenden (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
      • Zugriff auf Nutzungsdaten (AppOpsManager.OPSTR_GET_USAGE_STATS)
    • Rollen (Standard-Apps) <ph type="x-smartling-placeholder">
        </ph>
      • Telefon (RoleManager.ROLE_DIALER)
      • SMS (RoleManager.ROLE_SMS)
    • Laufzeitberechtigungen <ph type="x-smartling-placeholder">
        </ph>
      • SMS-Laufzeit (Manifest.permission_group.SMS)
  • [9.8/H-0-2] MÜSSEN die eingeschränkten Einstellungen standardmäßig aktivieren und sind EMPFOHLEN, keine Angebote für Nutzer zu bieten, um eingeschränkte Einstellungen für alle Apps zu deaktivieren.

  • [9.8/H-0-3] MÜSSEN sicherstellen, dass die Nutzerbestätigung für jedes Abgedeckte Anwendung, bevor eine der erzwungenen Berechtigungen gewährt werden kann.

  • [9.8/H-0-4] MUSS dem Nutzer nur die Bestätigung erlauben, eingeschränkte Einstellungen zu aktivieren. erhalten Sie über die Seite „AppInfo“ der abgedeckten App. mit der EnhancedConfirmationManager API an.

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

    • Wecker und Erinnerungen: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
    • Gesamter Dateizugriff: 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 Nutzungsdaten: AppOpsManager.OPSTR_GET_USAGE_STATS
    • Geräteadministrator: Manifest.permission.BIND_DEVICE_ADMIN
    • Bitte nicht stören: Manifest.permission.MANAGE_NOTIFICATIONS

Neue Anforderungen beenden

Wenn Implementierungen von Handheld-Geräten die System API unterstützen HotwordDetectionService oder ein anderer Mechanismus zur Hotword-Erkennung ohne Mikrofonzugriff anzeigt, können sie:

  • [9.8/H-1-1] MÜSSEN sicherstellen, dass der Hotword-Erkennungsdienst Daten an das System, ContentCaptureService, oder On-Device-Spracherkennungsdienst SpeechRecognizer#createOnDeviceSpeechRecognizer().
  • [9.8/H-1-2] MÜSSEN sicherstellen, dass der Hotword-Erkennungsdienst Audiodaten oder Daten, die vom Mikrofon an den Systemserver über HotwordDetectionService API oder ContentCaptureService durch ContentCaptureManager API verwenden.
  • [9.8/H-1-3] DÜRFEN KEIN Mikrofon-Audio ausgeben, der länger als 30 Sekunden einzelne hardware ausgelöste Anfrage an den Hotword-Erkennungsdienst.
  • [9.8/H-1-4] DÜRFEN KEINE gepufferten Mikrofone bereitstellen, die älter als 8 Sekunden sind, Anfrage an den Hotword-Erkennungsdienst gesendet.
  • [9.8/H-1-5] DÜRFEN KEIN zwischengespeichertes Mikrofon, das älter als 30 Sekunden ist, an den Sprachinteraktionsdienst oder ähnliche Entität.
  • [9.8/H-1-6] DÜRFEN NICHT mehr als 100 Byte an Daten zulassen (ohne Audiostreams) die bei jeder erfolgreichen Ausführung Hotword-Ergebnis.
  • [9.8/H-1-7] DÜRFEN NICHT zulassen, dass mehr als 5 Bits an Daten übertragen werden. des Hotword-Erkennungsdienstes für jedes negative Hotword-Ergebnis.
  • [9.8/H-1-8] DARF nur die Übertragung von Daten aus dem Hotword zulassen Erkennungsdienst für eine Anfrage zur Hotword-Validierung vom Systemserver.
  • [9.8/H-1-9] DÜRFEN NICHT zulassen, dass eine vom Nutzer installierbare Anwendung zur Bereitstellung des Hotword-Erkennungsdienst.
  • [9.8/H-1-10] DÜRFEN KEINE quantitativen Daten zur Mikrofonnutzung durch den Hotword-Erkennungsdienst.
  • [9.8/H-1-11] MÜSSEN die Anzahl von Byte in jeder Übertragung protokollieren aus dem Hotword-Erkennungsdienst Forschenden.
  • [9.8/H-1-12] MÜSSEN einen Debug-Modus unterstützen, der die Rohinhalte aller die vom Hotword-Erkennungsdienst übertragen werden, für Sicherheitsexperten.
  • [9.8/H-1-14] MÜSSEN die Mikrofonanzeige einblenden, wie im Abschnitt 9.8.2, wenn ein erfolgreiches Hotword-Ergebnis an die Stimme übertragen wird oder eine ähnliche Entität.

  • [9.8/H-1-15] MÜSSEN sicherstellen, dass Audiostreams bei erfolgreichen Hotwords bereitgestellt werden. werden die Ergebnisse vom Hotword-Erkennungsdienst in eine Richtung an den Sprachinteraktionsdienst.

  • [9.8/H-SR-1] Es wird dringend empfohlen, Nutzer vor dem Festlegen einer als Anbieter des Hotword-Erkennungsdienstes.

  • [9.8/H-SR-2] WIRD UNBEDINGT EMPFOHLEN, die Übertragung von unstrukturierte Daten aus dem Hotword-Erkennungsdienst.

  • [9.8/H-SR-3] Es wird dringend empfohlen, den Prozess, Dienst zur Hotword-Erkennung mindestens einmal pro Stunde oder alle 30 Hardware-Trigger-Ereignissen auslösen, je nachdem, was zuerst eintritt.

Wenn die Geräteimplementierung eine Anwendung umfasst, die die System-API verwendet HotwordDetectionService, oder einen ähnlichen Mechanismus zur Hotword-Erkennung ohne Mikrofonnutzung anzeigt, führt die Anwendung folgende Schritte aus:

  • [9.8/H-2-1] MÜSSEN Nutzer explizit auf jede Hotword-Wortgruppe hinweisen. unterstützt.
  • [9.8/H-2-2] DÜRFEN KEINE Audio-Rohdaten oder daraus abgeleitete Daten beibehalten, über den Hotword-Erkennungsdienst.
  • [9.8/H-2-3] DÜRFEN KEINE Audiodaten vom Dienst zur Hotword-Erkennung übertragen. Daten, mit denen die Audiodaten (ganz oder teilweise) rekonstruiert werden können, oder Audioinhalte, die nichts mit dem Hotword selbst zu tun haben, ContentCaptureService oder Spracheingabe auf dem Gerät Erkennungsdienst.

Wenn Implementierungen von Handheld-Geräten die System API unterstützen VisualQueryDetectionService oder ein anderer Mechanismus zur Abfrageerkennung ohne Hinweis auf den Zugriff auf das Mikrofon und/oder die Kamera, geschieht Folgendes:

  • [9.8/H-3-1] MÜSSEN sicherstellen, dass der Anfrageerkennungsdienst Daten an das System, ContentCaptureService oder Sprachausgabe auf dem Gerät Erkennungsdienst (erstellt von SpeechRecognizer#createOnDeviceSpeechRecognizer()).
  • [9.8/H-3-2] DÜRFEN NICHT zulassen, dass Audio- oder Videoinformationen übertragen werden. von VisualQueryDetectionService mit Ausnahme von ContentCaptureService oder einen Spracherkennungsdienst auf dem Gerät.
  • [9.8/H-3-3] MÜSSEN in der System-UI ein Nutzerhinweis angezeigt werden, wenn das Gerät einen Nutzer erkennt. die Absicht, mit der App für digitale Assistenten zu interagieren (z. B. durch Erkennung Nutzerpräsenz über die Kamera).
  • [9.8/H-3-4] MÜSSEN eine Mikrofonanzeige und die erkannte direkt nach der Erkennung der Nutzeranfrage in der Benutzeroberfläche.
  • [9.8/H-3-5] DÜRFEN NICHT zulassen, dass eine vom Nutzer installierbare Anwendung zur Bereitstellung des visuellen Abfrageerkennungsdienst.

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

  • [9.8.2/H-4-1] MUSS die Mikrofonanzeige einblenden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn das Mikrofon Nur HotwordDetectionService hat Zugriff auf das Mikrofon. SOURCE_HOTWORD,ContentCaptureService oder Apps mit den so genannten Rollen in Abschnitt 9.1 mit der CDD-Kennung [C-4-X].
  • [9.8.2/H-4-2] MUSS die Liste der zuletzt aktiven und aktiven Nutzer Apps, die das Mikrofon wie von PermissionManager.getIndicatorAppOpUsageData(), mit allen Quellenangaben Nachrichten, die mit ihnen verknüpft sind.
  • [9.8.2/H-4-3] DARF die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
  • [9.8.2/H-4-4] MUSS die Liste der zuletzt aktiven und aktiven Nutzer Apps, die das Mikrofon verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, sowie mit allen damit verbundenen Quellenangaben.

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

  • [9.8.2/H-5-1] MUSS die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn die Kamera auf die Apps zugreifen, die die in den Abschnitt 9.1 mit der CDD-Kennung [C-4-X].
  • [9.8.2/H-5-2] MÜSSEN kürzlich geöffnete und aktive Apps angezeigt werden mit Kamera wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, sowie mit allen damit verbundenen Quellenangaben.
  • [9.8.2/H-5-3] DARF die Kameraanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Der verifizierte Bootmodus ist eine Funktion, die die Integrität der Gerätesoftware gewährleistet. Wenn Geräteimplementierungen die Funktion unterstützen, gilt Folgendes:

  • [9.10/H-1-1] MÜSSEN alle schreibgeschützten Partitionen überprüfen. während des Android-Startvorgangs eingesetzt wird und der VBMeta-Digest alle verifizierten Partitionen in die Berechnung mit einfließen.

Neue Anforderungen beenden

2.2.6 Kompatibilität von Entwicklertools und -optionen

Implementierungen von Handheld-Geräten (* Nicht zutreffend für Tablets):

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Implementierungen von Handheld-Geräten (* Nicht zutreffend für Tablets):

  • Perfetto <ph type="x-smartling-placeholder">
      </ph>
    • [6.1/H-0-2]* MUSS einen /system/bin/perfetto anzeigen Binärdatei, die der cmdline entspricht Perfetto-Dokumentation.
    • [6.1/H-0-3]* Das Perfetto-Binärprogramm MUSS akzeptiert werden als Geben Sie eine protobuf-Konfiguration ein, die dem in Perfetto-Dokumentation.
    • [6.1/H-0-4]* Das Perfetto-Binärprogramm MUSS schreiben als einen protobuf-Trace ausgeben, der dem in Perfetto-Dokumentation.
    • [6.1/H-0-5]* MÜSSEN bereitgestellt werden, binär, zumindest die unter Perfetto-Dokumentation.
    • [6.1/H-0-6]* Der perfetto verfolgte Daemon MUSS standardmäßig aktiviert (Systemeigenschaft persist.traced.enable).

Neue Anforderungen beenden

2.2.7 Handheld Media Performance-Kurs

In Abschnitt 7.11 finden Sie eine Definition für der Medienleistung.

2.2.7.1 Medien

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn die Implementierung von Handheld-Geräten wieder funktioniert android.os.Build.VERSION_CODES.V Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

Neue Anforderungen beenden

  • [5.1/H-1-1] MUSS die maximale Anzahl von Hardware-Videodecoder bewerben Sitzungen, die gleichzeitig in einer beliebigen Codec-Kombination über den CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints()-Methoden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-2] MUSS 6 Instanzen von 8-Bit-Hardware-Videodecoder unterstützen Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination, die ausgeführt wird gleichzeitig mit 3 Sitzungen bei 1080p-Auflösung bei 30 fps und 3 Sitzungen bei 4K Auflösung bei 30 fps, außer AV1. Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codecs sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen. Es sind aber auch sechs Instanzen mit 1080p30 fps erforderlich.

Neue Anforderungen beenden

  • [5.1/H-1-3] MÜSSEN die maximale Anzahl von Hardware-Video-Encodern bewerben. Sitzungen, die gleichzeitig in einer beliebigen Codec-Kombination über den CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints()-Methoden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-4] MUSS 6 Instanzen von 8-Bit-Hardware-Videoencoder (SDR) unterstützen Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination, die ausgeführt wird gleichzeitig mit 4 Sitzungen bei einer Auflösung von 1080p bei 30 fps und 2 Sitzungen bei 4K Auflösung bei 30 fps, außer AV1. Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codecs sind nur für 1080p-Auflösung erforderlich, werden aber erforderlich, um 6 Instanzen mit 1080p30 fps zu unterstützen.

Neue Anforderungen beenden

  • [5.1/H-1-5] MÜSSEN die maximale Anzahl von Hardware-Video-Encodern und Decoder-Sitzungen, die gleichzeitig in einer beliebigen Codec-Kombination über den CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints()-Methoden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-6] MUSS 6 Instanzen von 8-Bit-Hardware-Videodecoder unterstützen und Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebigen gleichzeitig mit 3 Sitzungen bei 4K bei 30 fps ausgeführt Auflösung (außer AV1), von denen maximal 2 Encoder-Sitzungen und 3 mit einer Auflösung von 1080p. Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codecs sind nur für 1080p-Auflösung erforderlich, werden aber erforderlich, um 6 Instanzen mit 1080p30 fps zu unterstützen.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-19] MUSS drei Instanzen eines 10-Bit-Hardware-Videodecoders (HDR) unterstützen und Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebigen Codec-Kombination, die gleichzeitig mit einer Auflösung von 4K bei 30 fps ausgeführt wird (außer AV1) von denen höchstens eine eine Encoder-Sitzung ist, die in RGBA_1010102-Eingabeformat über eine GL-Oberfläche. Für bei allen Sitzungen DÜRFEN NICHT mehr als 1 Frame pro 2. HDR-Metadatengenerierung durch den Encoder ist bei der Codierung von der GL-Oberfläche nicht erforderlich. AV1-Codec-Sitzungen sind nur erforderlich, um 1080p-Auflösung zu unterstützen, auch wenn diese Anforderung ruft für 4K.

Neue Anforderungen beenden

  • [5.1/H-1-7] MÜSSEN eine Codec-Initialisierungslatenz von 40 ms oder weniger für eine Videocodierungssitzung mit 1080p oder kleiner für alle Hardware-Videoencoder, wenn unter Last aus. Hier wird die Auflösung als gleichzeitige Videoaufnahme zwischen 1080 und 720p definiert Transcodierungssitzung mit Hardware-Video-Codecs zusammen mit 1080p die Initialisierung von Audio-Video-Aufzeichnungen. Für den Dolby Vision-Codec Die Initialisierungslatenz MUSS höchstens 50 ms betragen.
  • [5.1/H-1-8] MÜSSEN eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiocodierungssitzung mit 128 kbit/s oder niedrigerer Bitrate für alle Audio-Encoder, wenn unter Last aus. Hier wird die Auflösung als gleichzeitige Videoaufnahme zwischen 1080 und 720p definiert Transcodierungssitzung mit Hardware-Video-Codecs zusammen mit 1080p die Initialisierung von Audio-Video-Aufzeichnungen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-9] MUSS zwei Instanzen eines sicheren Hardware-Videodecoder unterstützen Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination, die ausgeführt wird gleichzeitig bei 4K-Auflösung bei 30 fps (außer AV1) für 8-Bit (SDR) und 10-Bit-HDR-Inhalte Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, selbst wenn Diese Anforderung erfordert 4K.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-10] MUSS drei Instanzen eines nicht sicheren Hardware-Videodecoders unterstützen Sitzungen zusammen mit einer Instanz einer sicheren Hardware-Videodecoder-Sitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination gleichzeitig mit 3 Sitzungen bei 4K-Auflösung bei 30 fps (außer AV1) einschließlich einer sicheren Decodersitzung und 1 nn-sicheren Sitzung bei 1080p Auflösung bei 30 fps, wobei maximal 2 Sitzungen in 10-Bit-HDR-Qualität möglich sind Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, selbst wenn Diese Anforderung erfordert 4K.

Neue Anforderungen beenden

  • [5.1/H-1-11] MÜSSEN einen sicheren Decoder für alle Hardware-AVC-, HEVC- VP9- oder AV1-Decoder auf dem Gerät.
  • [5.1/H-1-12] MÜSSEN eine Codec-Initialisierungslatenz von 40 ms oder weniger für eine Videodecodierungssitzung mit 1080p oder kleiner für alle Hardware-Videodecoder wenn sie unter Last sind. Hier wird die Last als gleichzeitige Auflösung von 1080 bis 720p definiert mit Hardware-Video-Codecs zusammen mit dem Initialisierung der Wiedergabe von Audio und Video mit 1080p. Für den Dolby Vision-Codec Die Initialisierungslatenz MUSS höchstens 50 ms betragen.
  • [5.1/H-1-13] MÜSSEN eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiodecodierungssitzung mit einer Bitrate von 128 kbit/s für alle Audiodecoder bei einer unter Last aus. Hier wird die Auflösung als gleichzeitige Videoaufnahme zwischen 1080 und 720p definiert Transcodierungssitzung mit Hardware-Video-Codecs zusammen mit 1080p Initialisierung der Audio-Video-Wiedergabe.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-14] MÜSSEN AV1-Hardwaredecoder Main 10, Level 4.1 unterstützen und Filmkörnung mit Filmkörnung über GPU-Zusammensetzung

Neue Anforderungen beenden

  • [5.1/H-1-15] MUSS mindestens einen Hardware-Videodecoder haben, der 4K60 unterstützt.
  • [5.1/H-1-16] MUSS mindestens einen Hardware-Video-Encoder haben, der 4K60 unterstützt.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-21] MUSS FEATURE_DynamicColorAspect für alle Hardwarevideos unterstützen Decoder (AVC, HEVC, VP9, AV1 oder höher) verwenden. Hinweis: Das bedeutet, dass Anwendungen die Farbaspekte des Videocontents während der Decodierung aktualisieren. Decodierer, die 10-Bit- und 8-Bit-Inhalte unterstützen, MÜSSEN die dynamische Unterstützung zwischen 8- und 10-Bit-Inhalten im Oberflächenmodus wechseln. Unterstützte Decodierer Die HDR-Transferfunktion MUSS den dynamischen Wechsel zwischen SDR und HDR unterstützen Inhalte.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-22] MÜSSEN Codierung, Decodierung, GPU-Bearbeitung und Wiedergabe von Videos unterstützen. Inhalte im Hochformat, unabhängig von den Rotationsmetadaten für die größte von der Kamera unterstützte Auflösung oder 4K, je nachdem, welcher Wert geringer ist. Hinweis: enthält HDR-Profile, wenn der Codec HDR unterstützt. AV1-Codecs sind nur erforderlich, um unterstützen eine Auflösung von 1080p. Diese Anforderung gilt nur für Hardware-Codecs, und die Datenschutzaufsichtsbehörde.

Neue Anforderungen beenden

  • [5.3/H-1-1] DARF NICHT mehr als einen Frame in 10 Sekunden (d.h. weniger als 0,167 % Framerate) bei einer 4K-Videositzung mit 60 fps unter Last.
  • [5.3/H-1-2] Während eines Videos DARF NICHT mehr als 1 Frame in 10 Sekunden verworfen werden Änderung der Auflösung in einer Videositzung mit 60 fps unter Last bei einer 4K-Sitzung.
  • [5.6/H-1-1] MUSS eine Tap-to-Tone-Latenz von 80 Millisekunden oder weniger mit der den Tap-to-Ton-Test von CTS Verifier.
  • [5.6/H-1-2] MÜSSEN eine Umlauf-Audio-Latenz von 80 Millisekunden haben oder weniger über mindestens einen unterstützten Datenpfad.
  • [5.6/H-1-3] MUSS mindestens 24-Bit-Audio für eine Stereoausgabe über 3,5 mm unterstützen Anschlüsse, falls vorhanden, und über USB-Audio, sofern dies durch den gesamten Datenbestand unterstützt wird für niedrige Latenz- und Streamingkonfigurationen. Für die niedrige Latenz AAudio sollte von der App in einem Callback mit niedriger Latenz verwendet werden. . Für die Streaming-Konfiguration sollte ein Java-Audiotrack verwendet werden. in der App. Sowohl in den Konfigurationen mit niedriger Latenz als auch bei Streamingkonfigurationen weist der HAL Die Ausgabesenke sollte entweder AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT oder AUDIO_FORMAT_PCM_FLOAT als Zielausgabeformat.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.6/H-1-4] MUSS mehr als 4-Kanal-USB-Audiogeräte unterstützen. (Diese werden von DJ-Controllern für die Vorschau von Songs verwendet.)

Neue Anforderungen beenden

  • [5.6/H-1-5] MÜSSEN klassenkonforme MIDI-Geräte unterstützen und die MIDI-Funktions-Flag.
  • [5.6/H-1-9] MUSS mindestens 12 Kanäle unterstützen. Dies impliziert, dass AudioTrack mit 7.1.4-Kanal-Maske und ordnungsgemäß alle Kanäle auf Stereo zu verzerren.
  • [5.6/H-SR] WIRD UNBEDINGT EMPFOHLEN, 24-Kanal-Mix mit mindestens Unterstützung für Kanalmasken der Versionen 9.1.6 und 22.2.
  • [5.7/H-1-2] MUSS MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL mit dem Funktionen zur Inhaltsentschlüsselung.
Mindeststichprobengröße 4 MiB
Mindestanzahl von Teilstichproben – H264 oder HEVC 32
Mindestanzahl von Teilstichproben – VP9 9
Mindestanzahl von Teilstichproben – AV1 288
Minimale Zwischenspeichergröße für Teilstichproben 1 MiB
Mindestgröße des generischen Krypto-Zwischenspeichers 500 KiB
Mindestanzahl gleichzeitiger Sitzungen 30
Mindestanzahl von Schlüsseln pro Sitzung 20
Mindestanzahl von Schlüsseln (alle Sitzungen) 80
Mindestanzahl von DRM-Schlüsseln (alle Sitzungen) 6
Nachrichtengröße 16 KiB
Entschlüsselte Frames pro Sekunde 60 fps
  • [5.1/H-1-17] MUSS mindestens einen Hardware-Bilddecoder haben, der AVIF unterstützt Baseline-Profil.
  • [5.1/H-1-18] MUSS AV1-Encoder unterstützen, der bis zu 480p codieren kann bei 30 fps und 1 Mbit/s.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [5.1/H-1-20] MUSS den Feature_HdrEditing unterstützen für alle auf dem Gerät vorhandenen AV1- und HEVC-Encoder in 4K-Qualität. oder die höchste von der Kamera unterstützte Auflösung, je nachdem, welcher Wert geringer ist.

Neue Anforderungen beenden

  • [5.12/H-SR] werden dringend empfohlen, um die Feature_HdrEditing für AV1- und HEVC-Encoder auf dem Gerät.
  • [5.12/H-1-2] MÜSSEN das RGBA_1010102-Farbformat für alle Hardware-Geräte mit AV1 und Auf dem Gerät sind HEVC-Encoder vorhanden.
  • [5.12/H-1-3] MÜSSEN die Unterstützung für die Erweiterung EXT_YUV_target bekannt geben für Stichprobe aus YUV-Texturen in 8 und 10 Bit.
  • [7.1.4/H-1-1] MÜSSEN mindestens 6 Hardware-Overlays in der Displayverarbeitung haben. , von denen mindestens zwei 10-Bit-Videocontent wiedergeben können.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn die Implementierung von Handheld-Geräten wieder funktioniert android.os.Build.VERSION_CODES.V für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS und sie enthalten Hardware-AVC- oder HEVC-Encoder unterstützen, gilt Folgendes:

Neue Anforderungen beenden

2.2.7.2 Kamera

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn die Implementierung von Handheld-Geräten wieder funktioniert android.os.Build.VERSION_CODES.V Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

Neue Anforderungen beenden

  • [7.5/H-1-2] MUSS eine primäre Frontkamera mit einer Auflösung von mindestens 6 Megapixel und eine Videoaufnahme mit 1080p bei 30 fps unterstützen. Die primäre Die Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
  • [7.5/H-1-3] MUSS die Property android.info.supportedHardwareLevel als FULL oder besser für vorderes primäres Gerät und LIMITED oder besser für vordere Grundleitung Kamera.
  • [7.5/H-1-4] MUSS unterstützt werden. CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME für beide primäre Kameras.
  • [7.5/H-1-5] MUSS eine JPEG-Aufnahmelatenz von „camera2“ < 1.000 ms für eine Auflösung von 1080p, gemessen durch den Leistungstest der CTS-Kamera unter ITS-Lichtverhältnisse (3.000 K) für beide Hauptkameras.
  • [7.5/H-1-6] MUSS die Startlatenz von „camera2“ haben (Kamera für erste Vorschau öffnen). Frame) < 500 ms gemäß Messung durch Leistungstest der CTS-Kamera gemäß ITS (3.000 K) für beide primären Kameras.
  • [7.5/H-1-8] MUSS CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW unterstützen und android.graphics.ImageFormat.RAW_SENSOR für die primäre Rückkamera.
  • [7.5/H-1-9] MUSS eine primäre Kamera auf der Rückseite haben, die 720p oder 1080p unterstützt. bei 240 fps.
  • [7.5/H-1-10] MUSS mindestens ZOOM_RATIO < 1.0 für die primären Kameras, wenn ist eine Ultraweitwinkel-RGB-Kamera, die in die gleiche Richtung gerichtet ist.
  • [7.5/H-1-11] MUSS gleichzeitiges Front-Back-Streaming auf der primären Instanz implementieren. Kameras.
  • [7.5/H-1-12] MUSS unterstützt werden. CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION für beide primäre Front- und Hauptkamera auf der Rückseite.
  • [7.5/H-1-13] MUSS die Funktion LOGICAL_MULTI_CAMERA unterstützen für die Hauptkamera auf der Rückseite, wenn auf der Rückseite mehr als ein RGB-Bild verwendet wird. Kameras.
  • [7.5/H-1-14] MUSS die Funktion STREAM_USE_CASE für beide primäre Front- und Hauptkamera auf der Rückseite.
  • [7.5/H-1-15] MUSS unterstützt werden. Nachtmodus-Erweiterungen über CameraX- und Camera2-Erweiterungen für primäre Kameras.
  • [7.5/H-1-16] MUSS die Funktion DYNAMIC_RANGE_TEN_BIT für die primäre Datenbank unterstützen Kameras.
  • [7.5/H-1-17] MUSS CONTROL_SCENE_MODE_FACE_PRIORITY unterstützen und Gesichtserkennung (STATISTICS_FACE_DETECT_MODE_SIMPLE oder STATISTICS_FACE_DETECT_MODE_FULL) für die primären Kameras.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [7.5/H-1-18] MUSS JPEG_R für die primäre Rück- und primären Frontkameras.
  • [7.5/H-1-19] MUSS unterstützt werden. CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION für 1080p HLG10 Vorschau mit maximaler JPEG-Datei mit einem Seitenverhältnis von 16:9 und für 720p-HLG10-Vorschau JPEG-Stream-Kombinationen mit einem Seitenverhältnis von 16:9 für die primäre Rückkamera.
  • [7.5/H-1-20] MUSS standardmäßig JPEG_R für die primäre Ausgabe ausgeben mit der Rück- und der primären Frontkamera in der nativen Kamera-App.

Neue Anforderungen beenden

2.2.7.3 Hardware

Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.U für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn die Implementierung von Handheld-Geräten wieder funktioniert android.os.Build.VERSION_CODES.V Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

Neue Anforderungen beenden

  • [7.1.1.1/H-2-1] MUSS eine Bildschirmauflösung von mindestens 1080p haben.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [7.1.1.3/H-2-1] MUSS eine Bildschirmdichte von mindestens 400 dpi haben wenn die Bildschirmbreite des Geräts &lt; 600 dp.

Neue Anforderungen beenden

  • [7.1.1.3/H-3-1] MUSS einen HDR-Bildschirm mit mindestens 1.000 cd/m2 haben Durchschnitt.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen beenden

2.2.7.4 Leistung

Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.U für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn die Implementierung von Handheld-Geräten wieder funktioniert android.os.Build.VERSION_CODES.V Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

Neue Anforderungen beenden

  • [8.2/H-1-1] MÜSSEN eine sequentielle Schreibleistung von mindestens 150 MB/s gewährleisten.
  • [8.2/H-1-2] MÜSSEN eine zufällige Schreibleistung von mindestens 10 MB/s gewährleisten.
  • [8.2/H-1-3] MÜSSEN eine sequentielle Leseleistung von mindestens 250 MB/s gewährleisten.
  • [8.2/H-1-4] MÜSSEN eine zufällige Leseleistung von mindestens 100 MB/s gewährleisten.
  • [8.2/H-1-5] MÜSSEN eine parallele sequenzielle Lese- und Schreibleistung gewährleisten mit 2-facher Lese- und 1-facher Schreibleistung von mindestens 50 MB/s.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

2.2.7.5 Grafik

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

Neue Anforderungen beenden

2.3. Fernsehanforderungen

Der Begriff Android-Fernsehgerät bezieht sich auf eine Implementierung auf Android-Geräten, ist eine Unterhaltungsoberfläche für den Konsum von digitalen Medien, Filmen, Spielen, Apps und/oder Live-TV für Nutzer, die etwa drei Meter entfernt sitzen (d. h. eine Benutzeroberfläche“).

Implementierungen von Android-Geräten werden als Fernseher eingestuft, wenn sie alle folgende Kriterien erfüllen:

  • Bereitstellung eines Mechanismus zur Remote-Steuerung der gerenderten Benutzeroberfläche auf des Bildschirms, der etwa drei Meter vom Nutzer entfernt sein könnte.
  • Sie haben einen eingebetteten Bildschirm mit einer diagonalen Länge von mehr als 24 Pixeln. Zoll ODER einen Videoausgangsanschluss wie VGA, HDMI, DisplayPort oder einen WLAN-Port für die Anzeige.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten nur für Android. Implementierung von Fernsehgeräten

2.3.1 Hardware

Implementierungen von Fernsehgeräten:

  • [7.2.2/T-0-1] MUSS das Steuerkreuz unterstützen.
  • [7.2.3/T-0-1] MÜSSEN die Startbildschirm- und Back-End-Werte Funktionen.
  • [7.2.3/T-0-2] MÜSSEN sowohl das normale als auch das lange Drücken senden. Ereignis der Zurück-Funktion (KEYCODE_BACK) zur Anwendung im Vordergrund.
  • [7.2.6.1/T-0-1] MUSS Support für ein Spiel enthalten Controller und deklarieren das Funktions-Flag android.hardware.gamepad.
  • [7.2.7/T] SOLLTEN eine Fernbedienung bereitstellen, mit der Nutzer können auf die berührungslose Navigation und Eingaben für die Hauptnavigationstasten

Wenn Fernsehgeräte ein 3-Achsen-Gyroskop enthalten, ist Folgendes zu beachten:

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

Implementierungen von Fernsehgeräten:

  • [7.4.3/T-0-1] MUSS Bluetooth und Bluetooth LE.
  • [7.6.1/T-0-1] MUSS mindestens 4 GB an nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet).

Wenn Fernsehgeräte einen USB-Port enthalten, der den Hostmodus unterstützt, Sie:

  • [7.5.3/T-1-1] MUSS eine externe Kamera unterstützen der über diesen USB-Anschluss angeschlossen wird, aber nicht unbedingt immer verbunden ist.

Bei 32-Bit-Implementierungen von TV-Geräten:

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

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

Bei 64-Bit-Implementierungen von TV-Geräten:

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

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

Beachten Sie, dass der für Kernel und Userspace verfügbare Arbeitsspeicher bezieht sich auf den Arbeitsspeicher zusätzlich zu vorhandenem Arbeitsspeicher für Hardware-Komponenten wie Radio, Video usw. vorgesehen sind, die nicht der Kontrolle über die Geräteimplementierung durch den Kernel.

Implementierungen von Fernsehgeräten:

  • [7.8.1/T] SOLLTEN ein Mikrofon enthalten.
  • [7.8.2/T-0-1] MUSS einen Audioausgang haben und deklarieren android.hardware.audio.output

2.3.2 Multimedia

Implementierungen auf Fernsehgeräten MÜSSEN die folgende Audiocodierung unterstützen und Decodierungsformaten und stellen sie für Anwendungen von Drittanbietern zur Verfügung:

  • [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
  • [5.1/T-0-2] MPEG-4 HE AAC-Profil (AAC+)
  • [5.1/T-0-3] AAC ELD (Optimierte AAC mit niedriger Verzögerung)

Implementierungen auf Fernsehgeräten MÜSSEN die folgende Videocodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:

  • [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] Support wird dringend empfohlen. H.264-Codierung von Videos mit einer Auflösung von 720p und 1080p bei 30 Bildern pro Sekunde

Implementierungen auf Fernsehgeräten MÜSSEN die folgende Videodecodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:

Implementierungen von Fernsehgeräten MÜSSEN die MPEG-2-Decodierung unterstützen, wie im Abschnitt 5.3.1 bei standardmäßigen Video-Framerates und -Auflösungen bis zu einschließlich:

  • [5.3.1/T-1-1] HD 1080p bei 29,97 Bildern pro Sekunde mit dem Hauptprofil auf hoher Ebene.
  • [5.3.1/T-1-2] HD 1080i bei 59,94 Bildern pro Sekunde mit dem Hauptprofil auf hoher Ebene. Sie MÜSSEN MPEG-2-Videos mit Zeilenentflechtung per Deinterlacing konvertiert werden und sie für Drittanbieter-Anwendungen verfügbar zu machen.

Implementierungen von Fernsehgeräten MÜSSEN die H.264-Decodierung unterstützen, wie im Abschnitt 5.3.4 bei standardmäßigen Video-Framerates und ‐auflösungen bis zu einschließlich:

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

Implementierungen von Fernsehgeräten mit H.265-Hardwaredecoder müssen dies unterstützen. H.265-Decodierung, wie in Abschnitt 5.3.5 beschrieben, bei Standard-Video-Framerates und Auflösungen bis einschließlich:

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

Wenn Implementierungen von Fernsehgeräten mit H.265-Hardwaredecoder unterstützt werden Für die H.265-Decodierung und das UHD-Decodierungsprofil gilt Folgendes:

  • [5.3.5/T-2-1] MUSS das UHD-Decodierungsprofil unterstützen bei 60 Bildern pro Sekunde mit Main10 Level 5 in der Hauptstufe

Implementierungen von Fernsehgeräten MÜSSEN die VP8-Decodierung unterstützen, wie in den Abschnitt 5.3.6 bei standardmäßigen Video-Framerates und -Auflösungen bis zu einschließlich:

  • [5.3.6/T-1-1] Decodierungsprofil in HD 1080p bei 60 Bildern pro Sekunde

Implementierungen von Fernsehgeräten mit VP9-Hardwaredecoder müssen VP9 unterstützen. Decodierung, wie in Abschnitt 5.3.7 beschrieben, bei Standard-Video-Framerates und Auflösungen bis einschließlich:

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

Wenn Implementierungen von Fernsehgeräten mit VP9-Hardwaredecoder VP9 unterstützen und das UHD-Decodierungsprofil:

  • [5.3.7/T-2-1] MUSS das UHD-Decodierungsprofil unterstützen bei 60 Bildern pro Sekunde mit Profil 0 (8 Bit Farbtiefe).
  • [5.3.7/T-SR1] werden dringend empfohlen, die UHD-Decodierungsprofil bei 60 Bildern pro Sekunde mit Profil 2 (10-Bit-Farbtiefe).

Implementierungen von Fernsehgeräten:

  • [5.5/T-0-1] MUSS Unterstützung für den System-Master Dämpfung der Lautstärke und der digitalen Audioausgabe an unterstützten Ausgängen außer bei der komprimierten Audio-Passthrough-Ausgabe, bei der keine Audiodecodierung durchgeführt wird. auf dem Gerät.

Haben Fernsehgeräte keinen integrierten Bildschirm, aber unterstützen stattdessen einen über HDMI angeschlossenen externen Bildschirm:

  • [5.8/T-0-1] MUSS den HDMI-Ausgabemodus auf die höchste Auflösung für das ausgewählte Pixelformat, das mit 50 Hz oder 60 Hz funktioniert Aktualisierungsrate des externen Bildschirms, abhängig von der Videoaktualisierungsrate des die Region, in der das Gerät verkauft wird.
  • [5.8/T-SR-1] werden dringend empfohlen, konfigurierbare Auswahl für die HDMI-Aktualisierungsrate.
  • [5.8] SOLLTEN die Aktualisierungsrate des HDMI-Ausgabemodus festlegen, entweder auf 50 oder 60 Hz, je nach Videoaktualisierungsrate für die Region, unter dem das Gerät verkauft wird.

Haben Fernsehgeräte keinen integrierten Bildschirm, aber unterstützen stattdessen einen über HDMI angeschlossenen externen Bildschirm:

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

Wenn Implementierungen für Fernsehgeräte die UHD-Decodierung nicht unterstützen, unterstützen einen externen Bildschirm, der über HDMI angeschlossen ist. Sie:

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

2.3.3 Software

Implementierungen von Fernsehgeräten:

  • [3/T-0-1] MÜSSEN die Funktionen deklarieren android.software.leanback und android.hardware.type.television.
  • [3.2.3.1/T-0-1] MÜSSEN einen oder mehrere Anwendungen oder Dienstkomponenten mit Intent-Handlern für alle von den folgenden Anwendungs-Intents definierte öffentliche Intent-Filtermuster finden Sie hier.
  • [3.4.1/T-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API

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

  • [3.8.10/T-1-1] MÜSSEN das Schloss anzeigen Screen Notifications einschließlich der Media Notification Template.

Implementierungen von Fernsehgeräten:

  • [3.8.14/T-SR-1] werden dringend empfohlen. um den Bild-im-Bild-Modus (BiB) den Mehrfenstermodus zu unterstützen.
  • [3.10/T-0-1] MÜSSEN Bedienungshilfen für Drittanbieter unterstützen. .
  • [3.10/T-SR-1] EMPFOHLEN: Bedienungshilfen, die mit denen von vergleichbaren oder mehr als des Schalterzugriffs und von TalkBack (für Sprachen, die von vorinstallierten Text-in-Sprache-Funktionen, wie in den das Open-Source-Projekt „Talkback“.

Wenn Implementierungen von Fernsehgeräten die Funktion melden android.hardware.audio.output, sie/er:

  • [3.11/T-SR-1] wird dringend empfohlen, Sprachausgabe-Engine, die die auf dem Gerät verfügbaren Sprachen unterstützt
  • [3.11/T-1-1] MUSS die Installation von Sprachausgabe-Engines von Drittanbietern.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Implementierungen von Fernsehgeräten:

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

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Das Android Television Input Framework (TIF) vereinfacht Bereitstellung von Live-Inhalten an Android-Fernsehgeräte TIF stellt eine Standard- API zum Erstellen von Eingabemodulen, die Android TV-Geräte steuern

Implementierungen von Fernsehgeräten:

  • [3/T-0-2] MUSS die Plattformfunktion deklarieren android.software.live_tv
  • [3/T-0-3] MUSS alle TIF APIs unterstützen, sodass eine Anwendung das diese APIs und die TIF-basierte Eingaben von Drittanbietern auf dem Gerät installiert und verwendet werden kann.

Das Android Television Tuner Framework (TF) Vereinheitlicht die Verarbeitung von Live-Inhalten aus dem Tuner mit Streaming-Inhalten von IP-Adressen auf Android TV-Geräten. Das Turner-Framework stellt eine Standard-API zum Erstellen von Eingabediensten, die den Android Television Tuner verwenden.

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

  • [3/T-1-1] MUSS alle Tuner Framework APIs unterstützen, sodass ein Anwendungen, die diese APIs verwenden, auf dem Gerät installiert und verwendet werden können.

Neue Anforderungen beenden

2.3.4 Leistung und Leistung

  • [8.1/T-0-1] Konsistente Framelatenz. Inkonsistente Frame-Latenz oder Verzögerungen beim Rendern von Frames DÜRFEN NICHT öfter auftreten häufiger als 5 Frames pro Sekunde und SOLLTEN unter 1 Frames pro Sekunde liegen.
  • [8.2/T-0-1] MÜSSEN sicherstellen, dass eine sequenzielle mit mindestens 5 MB/s schreiben.
  • [8.2/T-0-2] MÜSSEN sicherstellen, dass ein zufälliger Schreibvorgang stattfindet. mit mindestens 0,5 MB/s arbeiten.
  • [8.2/T-0-3] MÜSSEN sicherstellen, dass eine sequenzielle von mindestens 15 MB/s lesen.
  • [8.2/T-0-4] MUSS einen zufälligen Lesevorgang sicherstellen mindestens 3,5 MB/s erreichen.

Wenn Implementierungen von Fernsehgeräten Funktionen zur Verbesserung der Geräteleistung enthalten die in AOSP enthalten sind, oder die Funktionen zu erweitern, bei AOSP:

  • [8.3/T-1-1] MÜSSEN die Nutzeroptionen zur Aktivierung und den Energiesparmodus deaktivieren.

Fernsehgeräte ohne Akku:

Wenn Fernsehgeräte einen Akku haben, gilt Folgendes:

  • [8.3/T-1-3] MÜSSEN die angezeigten Nutzeroptionen bieten. Alle Apps, die vom App-Standby- und Stromsparmodus ausgenommen sind

Implementierungen von Fernsehgeräten:

  • [8.4/T-0-1] MÜSSEN eine Leistungsprofil pro Komponente, das den aktuellen Verbrauchswert definiert für jede Hardwarekomponente und die ungefähre Entladung des Akkus aufgrund der wie auf der Website des Android Open Source Project dokumentiert.
  • [8.4/T-0-2] MÜSSEN die gesamte Stromversorgung melden. Verbrauchswerte in Milliamperestunden (mAh) angegeben.
  • [8.4/T-0-3] MÜSSEN die CPU-Leistung melden pro Prozess UID. Das Open-Source-Projekt von Android erfüllt Anforderung durch die Implementierung des Kernelmoduls uid_cputime.
  • [8.4/T] SOLLTE dem Hardwarekomponente selbst, wenn der Stromverbrauch der Hardwarekomponente nicht zugeordnet werden kann zu einer Anwendung hinzufügen.
  • [8.4/T-0-4] MUSS diesen Stromverbrauch nutzen verfügbar über adb shell dumpsys batterystats Shell-Befehl an den App-Entwickler senden.

2.3.5 Sicherheitsmodell

Implementierungen von Fernsehgeräten:

  • [9/T-0-1] MÜSSEN die android.hardware.security.model.compatible deklarieren .
  • [9.11/T-0-1] MÜSSEN die Schlüsselspeicherimplementierung sichern. mit einer isolierten Ausführungsumgebung.
  • [9.11/T-0-2] MUSS Implementierungen von RSA, AES, Die kryptografischen Algorithmen ECDSA und HMAC sowie die MD5-, SHA-1- und SHA-2-Familie Hash-Funktionen genutzt werden, um die vom Android-Schlüsselspeichersystem unterstützten in einem Bereich, der sicher vom Code isoliert ist, Kernel und höher. Sichere Isolation MUSS alle potenziellen Mechanismen blockieren über den Kernel- oder Userspace-Code auf den internen Status des einer isolierten Umgebung, einschließlich DMA. Die vorgelagerte Open-Source-Version von Android Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung, aber eine andere ARM TrustZone-basierte Lösung oder von einem Drittanbieter geprüfte sichere Lösung Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation sind eine Alternative Optionen.
  • [9.11/T-0-3] MUSS den Sperrbildschirm starten in der isolierten Ausführungsumgebung und nur dann, erfolgreich war, können die mit der Authentifizierung gebundenen Schlüssel verwendet werden. Sperrbildschirm Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführung für die Sperrbildschirm-Authentifizierung. Die vorgelagerte Android- Open-Source-Projekt bietet Gatekeeper-Hardwareabstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [9.11/T-0-4] MUSS die Schlüsselattestierung unterstützen, wenn die Der Attestierungssignaturschlüssel wird durch sichere Hardware geschützt und die Signatur ist auf sicherer Hardware ausgeführt werden. Die Signaturschlüssel der Attestierung MÜSSEN gemeinsam verwendet werden Geräte groß genug ist, um die Schlüssel zu verhindern. verhindert nicht als dauerhaft Gerätekennungen. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel, es sei denn, mindestens 100.000 Einheiten einer SKU produziert wurden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, für je 100.000 Einheiten.

Neue Anforderungen beenden

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

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

  • [9.11/T-1-1] MUSS dem Nutzer die Möglichkeit geben, den Schlafmodus Zeitlimit für den Wechsel vom entsperrten in den gesperrten Zustand, wobei ein Das minimale zulässige Zeitlimit beträgt maximal 15 Sekunden.

Wenn die Implementierung von Fernsehgeräten mehrere Nutzer umfasst und Das Funktions-Flag android.hardware.telephony wird nicht deklariert, sie werden:

  • [9.5/T-2-1] MUSS eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteeigentümer zusätzliche Nutzer und ihre Funktionen auf dem Gerät. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen einrichten, in denen zusätzliche Nutzende arbeiten können, mit der Möglichkeit, differenziertere Einschränkungen in den Apps zu verwalten, die in diesen Umgebungen verfügbar sind.

Wenn die Implementierung von Fernsehgeräten mehrere Nutzer umfasst und das Funktions-Flag android.hardware.telephony deklarieren, wenn folgende Aktionen ausgeführt werden:

  • [9.5/T-3-1] DÜRFEN KEINE Unterstützung eingeschränkter Einschränkungen unterstützen Profile, MÜSSEN jedoch mit der AOSP-Implementierung der Kontrollen übereinstimmen. , um zu aktivieren /deaktivieren, dass andere Nutzer auf die Sprachanrufe und SMS zugreifen können.

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

  • [9.8.2/T-4-1] MUSS die Mikrofonanzeige einblenden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn das Mikrofon auf das Mikrofon nur durch HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 beschriebenen Rollen Berechtigungen mit CDD-Kennung C-3-X.
  • [9.8.2/T-4-2] DARF die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen

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

  • [9.8.2/T-5-1] MUSS die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn die Kamera nur auf die Apps zugreifen, die die in Abschnitt 9.1 genannten Rollen innehaben Berechtigungen mit CDD-Kennung [C-3-X].
  • [9.8.2/T-5-2] DARF die Kameraanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen

2.3.6. Kompatibilität von Entwicklertools und -optionen

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Implementierungen von Fernsehgeräten:

  • Perfetto <ph type="x-smartling-placeholder">
      </ph>
    • [6.1/T-0-1] MUSS eine /system/bin/perfetto-Angabe verfügbar machen Binärdatei, die der cmdline entspricht Perfetto-Dokumentation.
    • [6.1/T-0-2] Das Perfetto-Binärprogramm MUSS akzeptiert werden als Geben Sie eine protobuf-Konfiguration ein, die dem in Perfetto-Dokumentation.
    • [6.1/T-0-3] Das Perfetto-Binärprogramm MUSS schreiben als einen protobuf-Trace ausgeben, der dem in Perfetto-Dokumentation.
    • [6.1/T-0-4] MÜSSEN im Rahmen des Perfettos angeben. binär, zumindest die unter Perfetto-Dokumentation.
    • [6.1/T-0-5] Der perfetto verfolgte Daemon MÜSSEN standardmäßig aktiviert sein (Systemeigenschaft persist.traced.enable).

Neue Anforderungen beenden

2.4. Smartwatch-Anforderungen

Android Watch-Gerät bezieht sich auf eine Android-Geräteimplementierung, die am Körper getragen werden, vielleicht am Handgelenk.

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

  • Die Bildschirmdiagonale muss zwischen 1,1 und 2,5 liegen. Zoll.
  • Ein Mechanismus zum Tragen am Körper muss vorhanden sein.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten nur für Android. Sehen Sie sich die Implementierungen der Geräte an.

2.4.1 Hardware

Implementierungen von Smartwatch-Geräten:

  • [7.1.1.1/W-0-1] MUSS einen Bildschirm mit der der physischen Diagonale im Bereich von 2,9 bis 6,8 cm.

  • [7.2.3/W-0-1] MUSS die Home-Funktion verfügbar haben. und die Back-Funktion, es sei denn, sie befindet sich in UI_MODE_TYPE_WATCH.

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

  • [7.3.1/W-SR-1] WIRD UNBEDINGT ZU 3-Achsen EMPFOHLEN Beschleunigungsmesser.

Wenn Implementierungen auf Smartwatch-Geräten Vulkan unterstützen, gilt Folgendes:

Wenn die Implementierung der Uhr einen GPS-/GNSS-Empfänger umfasst und das über die android.hardware.location.gps-Funktion verfügbar machen. melden sie:

  • [7.3.3/W-1-1] MÜSSEN GNSS-Messungen melden, sobald sie gefunden werden, auch wenn ein über GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
  • [7.3.3/W-1-2] MÜSSEN GNSS-Pseudorange und Pseudorange melden nach der Bestimmung des Standorts unter freiem Himmel, während oder sich bewegen, weniger als 0,2 Meter pro Sekunde zum Quadrat beschleunigen, reichen aus, um die Position innerhalb von 20 Metern zu berechnen, und die Geschwindigkeit. in mindestens 95% der Fälle mit einer Geschwindigkeit von 0, 2 Metern pro Sekunde.

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

  • [7.3.4/W-2-1] MUSS Ausrichtungsänderungen messen können bis zu 1000 Grad pro Sekunde.

Implementierungen von Smartwatch-Geräten:

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

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

  • [7.6.1/W-0-2] MUSS mindestens 416 MB Arbeitsspeicher haben für den Kernel und Userspace.

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

  • [7.8.2/W] KÖNNEN Audioausgang haben.

2.4.2 Multimedia

Keine zusätzlichen Anforderungen.

2.4.3 Software

Implementierungen von Smartwatch-Geräten:

  • [3/W-0-1] MUSS das Element deklarieren android.hardware.type.watch
  • [3/W-0-2] MUSS uiMode = unterstützen UI_MODE_TYPE_WATCH.
  • [3.2.3.1/W-0-1] MUSS einen vorab laden. oder mehr Anwendungen oder Dienstkomponenten mit Intent-Handlern enthalten, alle öffentlichen Intent-Filtermuster, die von der folgenden Anwendung definiert wurden Hier finden Sie eine Liste der Intents.

Implementierungen von Smartwatch-Geräten:

  • [3.8.4/W-SR-1] werden dringend empfohlen. um einen Assistenten für die Unterstützungsaktion auf dem Gerät zu implementieren.

Implementierungen von Geräten beobachten, die die android.hardware.audio.output deklarieren Funktions-Flag:

  • [3.10/W-1-1] MUSS Bedienungshilfen für Drittanbieter unterstützen .
  • [3.10/W-SR-1] wird dringend empfohlen, vorab zu laden Bedienungshilfen auf dem Gerät, die mit der Funktionalität vergleichbar oder sogar übertreffen des Schalterzugriffs und von TalkBack (für Sprachen, die vom vorinstallierten Bedienungshilfen (Text-in-Sprache-Engine), die in den Talkback-Open-Source-Projekt.

Wird bei Implementierungen der Smartwatch die Funktion „android.hardware.audio.output“ gemeldet, Sie:

  • [3.11/W-SR-1] wird dringend empfohlen, Folgendes anzugeben: Sprachausgabe-Engine, die die auf dem Gerät verfügbaren Sprachen unterstützt

  • [3.11/W-0-1] MUSS die Installation von Sprachausgabe-Engines von Drittanbietern.

2.4.4 Leistung und Leistung

Ob Smartwatch-Implementierungen Funktionen zur Verbesserung der Geräteleistung enthalten die in AOSP enthalten sind, oder die Funktionen zu erweitern, bei AOSP:

  • [8.3/W-SR-1] werden dringend empfohlen, die Möglichkeit, alle Apps anzuzeigen, die vom App-Standby-Modus ausgenommen sind, Stromsparmodi
  • [8.3/W-SR-2] werden dringend empfohlen, Nutzer können den Energiesparmodus aktivieren und deaktivieren.

Implementierungen von Smartwatch-Geräten:

  • [8.4/W-0-1] MUSS eine Leistungsprofil pro Komponente, das den aktuellen Verbrauchswert definiert für jede Hardwarekomponente und die ungefähre Entladung des Akkus aufgrund der wie auf der Website des Android Open Source Project dokumentiert.
  • [8.4/W-0-2] MÜSSEN die gesamte Stromversorgung melden Verbrauchswerte in Milliamperestunden (mAh) angegeben.
  • [8.4/W-0-3] MÜSSEN die CPU-Leistung melden pro Prozess UID. Das Open-Source-Projekt von Android erfüllt Anforderung durch die Implementierung des Kernelmoduls uid_cputime.
  • [8.4/W-0-4] MUSS diesen Stromverbrauch nutzen verfügbar über adb shell dumpsys batterystats Shell-Befehl an den App-Entwickler senden.
  • [8.4/W] SOLLTE dem Hardwarekomponente selbst, wenn der Stromverbrauch der Hardwarekomponente nicht zugeordnet werden kann zu einer Anwendung hinzufügen.

2.4.5 Sicherheitsmodell

Implementierungen von Smartwatch-Geräten:

  • [9/W-0-1] MUSS die android.hardware.security.model.compatible deklarieren .

Wenn die Implementierung von Smartwatch-Geräten von mehreren Nutzern Das Funktions-Flag android.hardware.telephony wird nicht deklariert, sie werden:

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

Wenn die Implementierung von Smartwatch-Geräten von mehreren Nutzern das Funktions-Flag android.hardware.telephony deklarieren, wenn folgende Aktionen ausgeführt werden:

  • [9.5/W-2-1] DÜRFEN KEINE Unterstützung eingeschränkter Einschränkungen unterstützen Profile, MÜSSEN jedoch mit der AOSP-Implementierung der Kontrollen übereinstimmen. , um zu aktivieren /deaktivieren, dass andere Nutzer auf die Sprachanrufe und SMS zugreifen können.

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

  • [9.11.1/W-1-1] MÜSSEN den Nutzer häufiger als alle 72 Stunden zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) auffordern.

2.5. Fahrzeuganforderungen

Die Android Automotive-Implementierung bezieht sich auf die Haupteinheit eines Fahrzeugs, Android als Betriebssystem für einen Teil oder das gesamte System und/oder Infotainmentfunktionen.

Implementierungen von Android-Geräten werden als Automobil klassifiziert, wenn das Feature android.hardware.type.automotive oder alle folgenden Kriterien.

  • Sie sind als Teil eines Fahrzeugs eingebettet oder können an das angeschlossene Fahrzeug angeschlossen werden.
  • ein Display in der Fahrersitzreihe als primäres Display verwenden.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten nur für Android. Implementierungen von Automobilgeräten

2.5.1 Hardware

Implementierungen von Automobilgeräten:

  • [7.1.1.1/A-0-1] MUSS mindestens einen Bildschirm haben 6 Zentimeter in physikalischer diagonaler Größe.
  • [7.1.1.1/A-0-2] MUSS ein Layout mit der Bildschirmgröße haben mindestens 750 dp x 480 dp.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen bei denen mehrere Android-Nutzer gleichzeitig mit dem Gerät interagieren können, die alle ihr eigenes Display verwenden, config_multiuserVisibleBackgroundUsers aktiviert ist, werden sie:

  • [7.1.1.1/A-1-1] MUSS einen separaten Bildschirm mit in jedem Insassenbereich der Kamera Hauptdisplay. Dies sollte wie folgt gekennzeichnet werden: CarOccupantZoneManager.DISPLAY_TYPE_MAIN für jeden Insassenbereich festlegen.
  • [7.1.1.1/A-1-2] MUSS ein Layout mit der Bildschirmgröße haben von mindestens 750 dp x 480 dp für jeden Hauptbildschirm.

Neue Anforderungen beenden

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

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

Wenn Implementierungen von Automobil-Geräten Vulkan unterstützen, gilt Folgendes:

Implementierungen von Automobilgeräten:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [7.2.3/A-0-1] MÜSSEN das Zuhause und Zurück-Funktionen und KÖNNEN eine Zurück und die Letzte Funktionen.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen bei denen mehrere Android-Nutzer gleichzeitig mit dem Gerät interagieren können, die alle ihr eigenes Display verwenden, config_multiuserVisibleBackgroundUsers aktiviert ist, werden sie:

  • [7.3/A-1-1] MÜSSEN die NIGHT_MODE Werte konsistent mit dem Tag-/Nachtmodus des Dashboards allen Displays, auch die Displays für die Rücksitze.

Neue Anforderungen beenden

Wenn Automobil-Geräte einen Beschleunigungsmesser enthalten, gilt Folgendes:

  • [7.3.1/A-1-1] MÜSSEN in der Lage sein, Ereignisse bis zu einer bestimmten Häufigkeit zu melden. von mindestens 100 Hz.

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

  • [7.3.1/A-SR-1] wird dringend empfohlen, die Komposit-Sensor für den begrenzten Achsen-Beschleunigungsmesser.

Wenn Automobil-Geräte einen Beschleunigungsmesser mit weniger als 3 Achsen:

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

Wenn Automobil-Geräteimplementierungen ein Gyroskop enthalten, ist Folgendes zu beachten:

  • [7.3.4/A-2-1] MÜSSEN in der Lage sein, Ereignisse bis zu einer bestimmten Häufigkeit zu melden. von mindestens 100 Hz.
  • [7.3.4/A-2-3] MÜSSEN in der Lage sein, Ausrichtungsänderungen zu messen. bis zu 250 Grad pro Sekunde.
  • [7.3.4/A-SR-1] wird dringend empfohlen, die Messbereich des Gyroskops auf +/-250 dps setzen, um die Auflösung zu maximieren möglich.

Wenn Automobil-Geräteimplementierungen ein 3-Achsen-Gyroskop umfassen, ist Folgendes zu beachten:

  • [7.3.4/A-SR-2] wird dringend empfohlen, die Komposit-Sensor für ein begrenztes Achsen-Gyroskop.

Wenn Geräte in der Automobilbranche ein Gyroskop mit weniger als 3 Achsen enthalten, gilt Folgendes:

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

Wenn Automobil-Geräte einen GPS-/GNSS-Empfänger enthalten, aber nicht umfassen:

  • [7.3.3/A-3-1] MÜSSEN den Standort beim ersten Mal bestimmen. der GPS/GNSS-Empfänger eingeschaltet oder nach mehr als 4 Tagen innerhalb von 60 Sekunden eingeschaltet ist.
  • [7.3.3/A-3-2] MUSS die Kriterien für die Zeit bis zur ersten Behebung erfüllen wie beschrieben in 7.3.3/C-1-2 und 7.3.3/C-1-6 für alle anderen Standortanfragen (d. h. Anfragen, die nicht das erste Mal sind, oder nach mehr als 4 Tagen. Die Anforderung 7.3.3/C-1-2 ist die in der Regel in Fahrzeugen ohne mobilfunkbasierte Datenverbindung erfüllt sind. indem Sie die vom Empfänger berechnete GNSS-Umlaufbahnvorhersage oder die Funktion letzten bekannten Fahrzeugstandorts und der Fähigkeit, mit einer Positionsgenauigkeit, die 7.3.3/C-1-3 oder eine Kombination aus beiden verwenden.

Wenn Fahrzeugimplementierungen einen TYPE_HEADING-Sensor enthalten, gilt Folgendes:

  • [7.3.4/A-4-3] MÜSSEN in der Lage sein, Ereignisse bis zu einer bestimmten Häufigkeit zu melden, von mindestens 1 Hz.
  • [7.3.4/A-SR-3] STRONGLY_RECOMMENDED zum Melden von Ereignissen bis zu Frequenz von mindestens 10 Hz.
  • SOLLTE sich auf den geografischen Norden beziehen.
  • SOLLTEN auch verfügbar sein, wenn das Fahrzeug stillsteht.
  • SOLLTE eine Auflösung von mindestens 1 Grad haben.

Implementierungen von Automobilgeräten:

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [7.4.3/A-SR-1] Support wird dringend empfohlen. Message Access Profile (MAP), wenn das Gerät eine Insassenzone hat.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen bei denen mehrere Android-Nutzer gleichzeitig mit dem Gerät interagieren können, die alle ihr eigenes Display verwenden, config_multiuserVisibleBackgroundUsers aktiviert ist, werden sie:

  • [7.4.3/A-1-1] MUSS unabhängig sein und NICHT stören mit denen anderer Nutzer BT-Erfahrung.

Neue Anforderungen beenden

Implementierungen von Automobilgeräten:

  • [7.4.5/A] SOLLTEN Support für Mobilfunk beinhalten netzwerkbasierte Datenverbindung.
  • [7.4.5/A] KANN die System API verwenden. NetworkCapabilities#NET_CAPABILITY_OEM_PAID-Konstante für die für System-Apps verfügbar sein sollen.

Wenn Geräteimplementierungen AM/FM-Radio unterstützen und die Funktionalität in jeder Anwendung zu nutzen,

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

Eine nach hinten gerichtete Kamera ist eine nach außen gerichtete Kamera, die an jedem beliebigen Ort angebracht werden kann am Fahrzeug platzieren und zur Außenseite des Fahrzeugkabins zeigen; Das heißt, es am anderen Ende der Karosserie, z. B. von der Rückkamera.

Eine Frontkamera ist eine Kamera für den Nutzer, die an jeder beliebigen Stelle am Fahrzeug montieren und in den Innenraum des Fahrzeugs zeigen; Das war's z. B. für Videokonferenzen und ähnliche Anwendungen.

Implementierungen von Automobilgeräten:

  • [7.5/A-SR-1] WIRD UNBEDINGT EMPFOHLEN, eine oder mehrere weltweit sichtbare Kameras.
  • KANN eine oder mehrere Kameras für den Nutzer enthalten.
  • [7.5/A-SR-2] WIRD UNBEDINGT EMPFOHLEN, das gleichzeitige Streaming von mehrere Kameras verwenden.

Wenn Implementierungen für Automobilgeräte mindestens eine Kamera umfassen, die für eine solche Kamera:

  • [7.5/A-1-1] MUSS so ausgerichtet werden, dass die lange Seite der Kamera mit der x-y-Ebene von Android-Automobilsensorachsen.
  • [7.5/A-SR-3] WIRDEN UNBEDINGT EMPFOHLEN, entweder Fixfokus oder EDOF zu verwenden Hardware für die erweiterte Tiefenschärfe.
  • [7.5/A-1-2] MUSS die primäre Kamera, die nach links gerichtet ist, als nach außen gerichtete Kamera verwenden. Kamera mit der niedrigsten Kamera-ID.

Wenn Implementierungen für Automobilgeräte mindestens eine Kamera umfassen, die für den Nutzer:

  • [7.5/A-2-1] Die primäre Kamera für den Nutzer MUSS die Kamera für den Nutzer sein. mit der niedrigsten Kamera-ID.
  • KANN so ausgerichtet werden, dass die lange Dimension der Kamera auf X-Y ausgerichtet ist. Ebene von Android-Automotive-Sensorachsen.

Wenn Automotive-Geräte eine Kamera umfassen, die über entweder android.hardware.Camera oder android.hardware.camera2 API, dann geschieht Folgendes:

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

Wenn Automotive-Geräte eine Kamera enthalten, die nicht zugänglich ist über die android.hardware.Camera- oder android.hardware.camera2-API, dann Sie:

  • [7.5/A-4-1] MÜSSEN über den Extended View System-Dienst zugänglich sein.

Wenn Automotive-Geräteimplementierungen eine oder mehrere Kameras umfassen, die über Extended View System Service:

  • [7.5/A-5-1] Dürfen die Kameravorschau NICHT drehen oder horizontal spiegeln.
  • [7.5/A-SR-4] Eine Auflösung von mindestens 1,3 wird dringend empfohlen. Megapixel.

Wenn die Implementierung von Automobilgeräten eine oder mehrere Kameras umfasst, die zugänglich sowohl über den Extended View System Service als auch über android.hardware.Camera oder android.hardware.Camera2 API verwenden, wird für eine solche Kamera Folgendes ausgeführt:

  • [7.5/A-6-1] MÜSSEN dieselbe Kamera-ID melden.

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

Implementierungen von Automobilgeräten:

  • [7.6.1/A-0-1] MUSS mindestens 4 GB an nichtflüchtiger Speicher für private Anwendungsdaten (Partition /data)

  • [7.6.1/A] SOLLTEN die Datenpartition formatieren. um die Leistung und Langlebigkeit des Flash-Speichers zu verbessern (z. B. mithilfe des Dateisystems f2fs).

Wenn Automotive-Geräteimplementierungen gemeinsamen externen Speicher über ein des internen nicht entfernbaren Speichers verwendet werden,

  • [7.6.1/A-SR-1] wird dringend empfohlen, die E/A-Overhead bei Vorgängen auf dem externen Speicher, zum Beispiel von mit SDCardFS.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen bei denen mehrere Android-Nutzer gleichzeitig mit dem Gerät interagieren können, die alle ihr eigenes Display verwenden, config_multiuserVisibleBackgroundUsers aktiviert ist, werden sie:

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

Neue Anforderungen beenden

Bei Automotive-Geräten mit 64-Bit-Implementierungen:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

    • Maximal 280 dpi 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 verfügbare Arbeitsspeicher und Nutzerbereich MUSS mindestens 944 MB groß sein. pro Hauptdisplay wenn eine der folgenden Dichten verwendet wird:

    • xhdpi oder höher auf kleinen/normalen Bildschirmen
    • HDPI oder mehr auf großen Bildschirmen
    • mdpi oder höher auf extragroßen Bildschirmen
  • [7.6.1/A-2-3] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerbereich MUSS mindestens 1.280 MB groß sein. pro Hauptdisplay wenn eine der folgenden Dichten verwendet wird:

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

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

Beachten Sie, dass der für Kernel und Userspace verfügbare Arbeitsspeicher bezieht sich auf den Arbeitsspeicher zusätzlich zu dem bereits für Hardware vorgesehenen Arbeitsspeicher wie Radio, Video usw., die sich nicht im Kernel- Geräteimplementierungen steuern.

Neue Anforderungen beenden

Implementierungen von Automobilgeräten:

  • [7.7.1/A] SOLLTEN einen USB-Port haben, der den Peripheriemodus unterstützt.

Implementierungen von Automobilgeräten:

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

Implementierungen von Automobilgeräten:

  • [7.8.2/A-0-1] MUSS einen Audioausgang haben und deklarieren android.hardware.audio.output

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen bei denen mehrere Android-Nutzer gleichzeitig mit dem Gerät interagieren können, die alle ihr eigenes Display verwenden, config_multiuserVisibleBackgroundUsers aktiviert ist, werden sie:

  • [7.8.2/A-1-1] MUSS für jeden Hauptanschluss ein Audioausgabegerät haben. gleichzeitige Nutzersysteme anzeigen.
  • [7.8.2/A-1-2] MUSS einen Audiobereich für den Fahrer haben, der die globalen Innenraumlautsprecher. Im Beifahrerbereich kann Audio vom Fahrer geteilt werden oder eine eigene Audioausgabe haben.

Neue Anforderungen beenden

2.5.2 Multimedia

Implementierungen für Automobilgeräte MÜSSEN die folgende Audiocodierung unterstützen und Decodierungsformaten und stellen sie für Anwendungen von Drittanbietern zur Verfügung:

  • [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
  • [5.1/A-0-2] MPEG-4 HE AAC-Profil (AAC+)
  • [5.1/A-0-3] AAC ELD (Optimierte AAC mit niedriger Verzögerung)

Implementierungen für Automobilgeräte MÜSSEN die folgende Videocodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:

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

Implementierungen für Automobilgeräte MÜSSEN die folgende Videodecodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:

  • [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

Implementierungen für Automobilgeräte werden UNBEDINGT empfohlen, um die folgende Videodecodierung:

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen bei denen mehrere Android-Nutzer gleichzeitig mit dem Gerät interagieren können, die alle ihr eigenes Display verwenden, config_multiuserVisibleBackgroundUsers aktiviert ist, werden sie:

  • [5.5.3/A-1-1] MÜSSEN identische Volumenkurven für dass alle Audioausgabestreams derselben Lautstärkegruppe gemäß Definition in Auto-Audio-Konfigurationsdatei.

Neue Anforderungen beenden

2.5.3 Software

Implementierungen von Automobilgeräten:

  • [3/A-0-1] MUSS das Element deklarieren 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 android.car.* -Namespace auf sie zugegriffen werden.

Wenn Automotive-Geräteimplementierungen eine proprietäre API mit android.car.CarPropertyManager mit android.car.VehiclePropertyIds, Sie:

  • [3/A-1-1] DÜRFEN KEINE Sonderberechtigungen an das System anhängen oder Anwendungen von Drittanbietern verhindern. diese Eigenschaften zu schützen.
  • [3/A-1-2] DÜRFEN KEINE Fahrzeugeigenschaft replizieren, die bereits ist im SDK enthalten.

Implementierungen von Automobilgeräten:

  • [3.2.1/A-0-1] MUSS alle Berechtigungskonstanten, wie auf der Referenzseite für Automotive-Berechtigungen dokumentiert.

  • [3.2.3.1/A-0-1] MÜSSEN einen oder mehrere mehr Anwendungen oder Dienstkomponenten mit einem Intent-Handler, von den folgenden Anwendungs-Intents definierte öffentliche Intent-Filtermuster finden Sie hier.

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [3.8/A-0-1] DÜRFEN NICHT erlauben, dass sekundäre Nutzer, die nicht der aktuelle Nutzer im Vordergrund sind, Aktivitäten starten und auf allen Bildschirmen Zugriff auf die Benutzeroberfläche haben.

Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen bei denen mehrere Android-Nutzer gleichzeitig mit dem Gerät interagieren können, die alle ihr eigenes Display verwenden, config_multiuserVisibleBackgroundUsers aktiviert ist) für sekundäre Nutzer, die nicht der aktuelle Nutzer im Vordergrund sind aber mit UI-Zugriff auf die Anzeige ausgeführt werden, gilt Folgendes:

Neue Anforderungen beenden

Implementierungen von Automobilgeräten:

  • [3.8.3/A-0-1] MUSS angezeigt werden. Benachrichtigungen mit dem Notification.CarExtender API, wenn sie von Drittanbieteranwendungen angefordert werden.

  • [3.8.4/A-SR-1] dringend empfohlen um einen Assistenten für die Unterstützungsaktion auf dem Gerät zu implementieren.

Wenn Implementierungen von Automobil-Geräten eine Push-to-Talk-Taste enthalten, gilt Folgendes:

  • [3.8.4/A-1-1] MÜSSEN kurz die Taste die entsprechende Interaktion zum Starten des vom Nutzer ausgewählte Assistent-App, d. h. die App, die VoiceInteractionService

Implementierungen von Automobilgeräten:

  • [3.8.3.1/A-0-1] MUSS korrekt Renderingressourcen wie in Notifications on Automotive OS beschrieben SDK-Dokumentation
  • [3.8.3.1/A-0-2] MÜSSEN ABSPIELEN und STUMMSCHALTEN für Benachrichtigungsaktionen anstelle derjenigen, die über Notification.Builder.addAction()
  • [3.8.3.1/A] SOLLTE Einschränkung der Umfangreiche Verwaltungsaufgaben wie die Steuerung einzelner Benachrichtigungskanäle nutzen. KANN die UI-Angebote pro Anwendung verwenden, um die Steuerungsmöglichkeiten zu reduzieren.

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

Implementierungen von Automobilgeräten:

Wenn Implementierungen für Automotive-Geräte eine Standard-Launcher-App enthalten, gilt Folgendes:

Implementierungen von Automobilgeräten:

  • [3.8/A] KANN die Anwendung einschränken. um in den Vollbildmodus zu wechseln, wie unter immersive documentation beschrieben.
  • [3.8/A] KANN die Statusleiste und immer sichtbar ist.
  • [3.8/A] KANN die Anwendung einschränken. die Farben hinter den UI-Elementen des Systems zu ändern, und diese Elemente immer deutlich sichtbar sind.

2.5.4 Leistung und Leistung

Implementierungen von Automobilgeräten:

  • [8.2/A-0-1] MUSS die Anzahl der Byte für den nichtflüchtigen Speicher gemäß der UID jedes Prozesses, Statistiken stehen Entwicklern über die System-API zur Verfügung android.car.storagemonitoring.CarStorageMonitoringManager Android Open Das Quellprojekt erfüllt die Anforderung über das Kernelmodul uid_sys_stats.
  • [8.3/A-1-3] MUSS den Garagemodus unterstützen.
  • [8.3/A] SOLLTE mindestens im Garagenmodus sein 15 Minuten nach jeder Fahrt, es sei denn: <ph type="x-smartling-placeholder">
      </ph>
    • Der Akku ist leer.
    • Es sind keine inaktiven Jobs geplant.
    • Der Fahrer beendet den Garagenmodus.
  • [8.4/A-0-1] MUSS einen Leistungsprofil pro Komponente, das den aktuellen Verbrauchswert definiert für jede Hardwarekomponente und die ungefähre Entladung des Akkus aufgrund der wie auf der Website des Android Open Source Project dokumentiert.
  • [8.4/A-0-2] MÜSSEN die gesamte Stromversorgung melden. Verbrauchswerte in Milliamperestunden (mAh) angegeben.
  • [8.4/A-0-3] MÜSSEN die CPU-Leistung melden pro Prozess UID. Das Open-Source-Projekt von Android erfüllt Anforderung durch die Implementierung des Kernelmoduls uid_cputime.
  • [8.4/A] SOLLTE dem Hardwarekomponente selbst, wenn der Stromverbrauch der Hardwarekomponente nicht zugeordnet werden kann zu einer Anwendung hinzufügen.
  • [8.4/A-0-4] MUSS diesen Stromverbrauch nutzen verfügbar über adb shell dumpsys batterystats Shell-Befehl an den App-Entwickler senden.

2.5.5 Sicherheitsmodell

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

Wenn in den Implementierungen von Automobil-Geräten android.hardware.microphone deklariert ist, Sie:

  • [9.8.2/A-1-1] MUSS die Mikrofonanzeige einblenden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn das Mikrofon Auf das Mikrofon zugreifen nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in folgendem Dokument genannten Rollen: Abschnitt 9.1 mit der CDD-Kennung [C-4-X].
  • [9.8.2/A-1-2] DARF die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
  • [9.8.2/A-1-3] MUSS zum Aktivieren/Deaktivieren der in der App „Einstellungen“.

Wenn in Implementierungen von Automobil-Geräten android.hardware.camera.any deklariert ist, gilt Folgendes: Sie:

  • [9.8.2/A-2-1] MUSS die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn die Kamera Zugriff von Apps mit den in den Abschnitt 9.1 Berechtigungen mit der CDD-Kennung [C-4-X].
  • [9.8.2/A-2-2] DARF die Kameraanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
  • [9.8.2/A-2-3] MÜSSEN Nutzern die Möglichkeit bieten, die Kamera in den Einstellungen ein- und auszuschalten.
  • [9.8.2/A-2-4] MÜSSEN bei Rückgabe kürzlich verwendete und aktive Apps, die die Kamera verwenden, angezeigt werden. von PermissionManager.getIndicatorAppOpUsageData(), zusammen mit Attributionsbotschaften, die mit ihnen verknüpft sind.

Implementierungen von Automobilgeräten:

  • [9/A-0-1] MUSS die android.hardware.security.model.compatible deklarieren .
  • [9.11/A-0-1] MUSS die Schlüsselspeicherimplementierung sichern mit einer isolierten Ausführungsumgebung.
  • [9.11/A-0-2] MUSS Implementierungen von RSA, AES, Die kryptografischen Algorithmen ECDSA und HMAC sowie die MD5-, SHA-1- und SHA-2-Familie Hash-Funktionen genutzt werden, um die vom Android-Schlüsselspeichersystem unterstützten in einem Bereich, der sicher vom Code isoliert ist, Kernel und höher. Sichere Isolation MUSS alle potenziellen Mechanismen blockieren über den Kernel- oder Userspace-Code auf den internen Status des einer isolierten Umgebung, einschließlich DMA. Die vorgelagerte Open-Source-Version von Android Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung, aber eine andere ARM TrustZone-basierte Lösung oder von einem Drittanbieter geprüfte sichere Lösung Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation sind eine Alternative Optionen.
  • [9.11/A-0-3] MUSS den Sperrbildschirm starten in der isolierten Ausführungsumgebung und nur dann, erfolgreich war, können die mit der Authentifizierung gebundenen Schlüssel verwendet werden. Sperrbildschirm Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführung für die Sperrbildschirm-Authentifizierung. Die vorgelagerte Android- Open-Source-Projekt bietet Gatekeeper-Hardwareabstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [9.11/A-0-4] MUSS die Schlüsselattestierung unterstützen, wenn die Der Attestierungssignaturschlüssel wird durch sichere Hardware geschützt und die Signatur ist auf sicherer Hardware ausgeführt werden. Die Signaturschlüssel der Attestierung MÜSSEN gemeinsam verwendet werden Geräte groß genug ist, um die Schlüssel zu verhindern. verhindert nicht als dauerhaft Gerätekennungen. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel, es sei denn, mindestens 100.000 Einheiten einer SKU produziert wurden. Werden mehr als 100.000 Einheiten einer Artikelnummer hergestellt, wird eine andere für je 100.000 Einheiten.

Neue Anforderungen beenden

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

Implementierungen von Automobilgeräten:

  • [9.14/A-0-1] MÜSSEN Gatekeep-Nachrichten verarbeiten. von Fahrzeug-Subsystemen von Android-Frameworks, z.B. Mitteilung, die auf die Zulassungsliste gesetzt wurde Nachrichtenquellen und Nachrichtenquellen.
  • [9.14/A-0-2] MÜSSEN überwacht werden, ob Denial-of-Service-Angriffe des Android-Frameworks oder von Drittanbieter-Apps Dieses Schutz vor schädlicher Software, die das Fahrzeugnetzwerk mit Traffic überflutet. was zu defekten Fahrzeug-Subsystemen führen kann.

2.5.6 Kompatibilität von Entwicklertools und -optionen

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Implementierungen von Automobilgeräten:

  • Perfetto <ph type="x-smartling-placeholder">
      </ph>
    • [6.1/A-0-1] MUSS eine /system/bin/perfetto-Angabe verfügbar machen Binärdatei, die der cmdline entspricht Perfetto-Dokumentation.
    • [6.1/A-0-2] Das Perfetto-Binärprogramm MUSS akzeptiert werden als Geben Sie eine protobuf-Konfiguration ein, die dem in Perfetto-Dokumentation.
    • [6.1/A-0-3] Das Perfetto-Binärprogramm MUSS schreiben als einen protobuf-Trace ausgeben, der dem in Perfetto-Dokumentation.
    • [6.1/A-0-4] MÜSSEN über das Zusatzsymbol angeben. binär, zumindest die unter Perfetto-Dokumentation.
    • [6.1/A-0-5] Der perfetto verfolgte Daemon MÜSSEN standardmäßig aktiviert sein (Systemeigenschaft persist.traced.enable).

Neue Anforderungen beenden

2.6. Tablet-Anforderungen

Android-Tablet bezieht sich auf eine Android-Geräteimplementierung, die erfüllt in der Regel alle folgenden Kriterien:

  • Wird durch Halten in beiden Händen verwendet.
  • Hat keine Clamshell- oder Convertible-Konfiguration.
  • Implementierungen für physische Tastaturen, die mit dem Gerät verwendet werden, verbinden sich über über eine Standardverbindung (z.B. USB oder Bluetooth).
  • Das Gerät hat eine Stromquelle, die Mobilität ermöglicht, z. B. einen Akku.

  • Das Display des Displays ist größer als 7 Zoll und kleiner als 18 Zoll, gemessen an diagonaler Messung.

Bei der Implementierung von Tablets gelten ähnliche Anforderungen wie auf Mobilgeräten. Implementierungen. Die Ausnahmen sind in diesem Abschnitt mit einem * gekennzeichnet und werden in diesem Abschnitt als Referenz vermerkt.

2.6.1 Hardware

Gyroskop

Wenn Tablet-Geräte ein 3-Achsen-Gyroskop enthalten, ist Folgendes erforderlich:

  • [7.3.4/Tab-1-1] MUSS die Ausrichtung messen können um bis zu 1000 Grad pro Sekunde.

Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)

Die angegebenen Bildschirmdichten für kleine/normale Bildschirme im Handheld- gelten nicht für Tablets.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

USB-Peripheriemodus (Abschnitt 7.7.1)

Wenn Tablet-Implementierungen einen USB-Port enthalten, der Peripheriegeräte unterstützt haben sie folgende Möglichkeiten:

  • [7.7.1/Tab] KANN die Android Open Accessory (AOA) API implementieren.

Neue Anforderungen beenden

Virtual-Reality-Modus (Abschnitt 7.9.1)

Virtual Reality: High Performance (Abschnitt 7.9.2)

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

2.6.2 Sicherheitsmodell

Schlüssel und Anmeldedaten (Abschnitt 9.11)

Siehe Abschnitt [9.11].

Wenn Tablet-Geräteimplementierungen von mehreren Nutzern und Das Funktions-Flag android.hardware.telephony wird nicht deklariert, sie werden:

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

Wenn Tablet-Geräteimplementierungen von mehreren Nutzern und das Funktions-Flag android.hardware.telephony deklarieren, wenn folgende Aktionen ausgeführt werden:

  • [9.5/T-2-1] DÜRFEN KEINE Unterstützung eingeschränkter Einschränkungen unterstützen Profile, MÜSSEN aber mit der AOSP-Implementierung der Kontrollen übereinstimmen. , um zu aktivieren /deaktivieren, dass andere Nutzer auf die Sprachanrufe und SMS zugreifen können.

2.6.2 Software

  • [3.2.3.1/Tab-0-1] MUSS einen vorab laden. oder mehr Anwendungen oder Dienstkomponenten mit Intent-Handlern für alle von den folgenden Anwendungs-Intents definierte öffentliche Intent-Filtermuster finden Sie hier.

3. Software

3.1. Kompatibilität mit verwalteten APIs

Die verwaltete Dalvik-Bytecode-Ausführungsumgebung Android-Apps Die Android-API (Application Programming Interface) ist die Android-Plattformschnittstellen, die für Anwendungen in der verwaltete Laufzeitumgebung.

Geräteimplementierungen:

  • [C-0-1] MÜSSEN vollständige Implementierungen einschließlich aller dokumentierten jeder dokumentierten API, die durch den Android SDK oder eine beliebige API, die mit „@SystemApi“ Markierung in den vorgelagerten Android- Quellcode verfügbar.

  • [C-0-2] MÜSSEN alle Klassen, Methoden und zugehörigen Elemente unterstützen/bewahren. durch die TestApi-Annotation (@TestApi) gekennzeichnet.

  • [C-0-3] DÜRFEN KEINE verwalteten APIs auslassen, API-Schnittstellen oder Signaturen ändern, vom dokumentierten Verhalten abweichen oder No-Ops-Werte enthalten, es sei denn, gemäß dieser Kompatibilitätsdefinition gestattet.

  • [C-0-4] MÜSSEN die APIs weiterhin vorhanden sein und funktionieren. selbst wenn einige Hardwarefunktionen, für die Android beinhaltet keine APIs. Siehe Abschnitt 7 .

  • [C-0-5] DÜRFEN NICHT zulassen, dass Drittanbieter-Apps Nicht-SDK-Schnittstellen verwenden, die werden als Methoden und Felder in den Java-Sprachpaketen im Boot-Klassenpfad in AOSP, und sind nicht Teil der öffentlichen SDK. Dies gilt auch für APIs, die mit der Annotation @hide, aber nicht mit ein @SystemAPI, wie in den SDK-Dokumenten beschrieben und private und Paket-private Klassenmitglieder.

  • [C-0-6] MÜSSEN mit allen Nicht-SDK-Schnittstellen auf derselben eingeschränkten wie über die Flags „Vorläufig“ und „Sperrliste“ in prebuilts/runtime/appcompat/hiddenapi-flags.csv Pfad für den entsprechenden API-Level-Zweig im AOSP.

  • [C-0-7] MUSS die signierte Konfiguration unterstützen Mechanismus für dynamische Updates, um Nicht-SDK-Schnittstellen aus einer eingeschränkten Liste zu entfernen Durch Einbetten der signierten Konfiguration in ein beliebiges APK unter Verwendung der vorhandenen öffentlichen Schlüssel die in AOSP vorhanden sind.

    Allerdings gilt:

    • MÖGLICH, wenn eine verborgene API fehlt oder auf dem Gerät anders implementiert wurde Implementierung, verschieben Sie die verborgene API in die Sperrliste oder lassen Sie sie aus alle eingeschränkten Listen.
    • MAG. Wenn eine ausgeblendete API noch nicht in der AOSP vorhanden ist, fügen Sie die ausgeblendete API API zu einer der eingeschränkten Listen hinzufügen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-0-8] DARF NICHT die Installation von Anwendungen unterstützen, die auf ein API-Level ausgerichtet sind. weniger als 23 24.

Neue Anforderungen beenden

3.1.1. Android-Erweiterungen

Android unterstützt die Erweiterung der verwalteten API-Oberfläche einer bestimmten API-Ebene um die Erweiterungsversion für diese API-Ebene aktualisieren. Die Die android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API gibt den Fehlerwert Erweiterungsversion der angegebenen apiLevel, falls es Erweiterungen dafür gibt API-Level.

Implementierungen auf Android-Geräten:

  • [C-0-1] MÜSSEN die AOSP-Implementierung sowohl der gemeinsam genutzten Bibliothek ExtShared und Dienste ExtServices mit Versionen größer oder gleich die minimal zulässigen Versionen pro API-Level. Beispiel: Android 7.0 Geräteimplementierungen mit API-Level 24 MÜSSEN mindestens Version 1.

  • [C-0-2] MUSS nur eine gültige Erweiterungsversionsnummer zurückgeben, die AOSP definiert ist.

  • [C-0-3] MUSS alle von den Erweiterungsversionen definierten APIs unterstützen zurückgegeben von android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) genau wie andere verwaltete APIs unterstützt werden. Anforderungen in Abschnitt 3.1.

3.1.2. Android-Bibliothek

Aufgrund der Einstellung des Apache HTTP-Clients Implementierungen auf Geräten:

  • [C-0-1] DARF die org.apache.http.legacy-Bibliothek NICHT im bootclasspath an.
  • [C-0-2] MÜSSEN der Anwendung die org.apache.http.legacy-Bibliothek hinzufügen. classpath nur dann, wenn die App eine der folgenden Bedingungen erfüllt: <ph type="x-smartling-placeholder">
      </ph>
    • Ausrichtung auf API-Level 28 oder niedriger.
    • Deklariert in seinem Manifest, dass die Bibliothek benötigt wird, indem das Attribut Attribut android:name von <uses-library> zu org.apache.http.legacy.

Die AOSP-Implementierung erfüllt diese Anforderungen.

3.2. Soft API-Kompatibilität

Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 Android beinhaltet auch eine erhebliche API in Form von wie Intents, Berechtigungen und ähnliche Aspekte von Android-Apps, kann bei der Kompilierung der Anwendung nicht erzwungen werden.

3.2.1. Berechtigungen

  • [C-0-1] Geräteimplementierungen MÜSSEN alle Berechtigungen unterstützen und erzwingen wie auf der Referenzseite für Berechtigungen dokumentiert. In Abschnitt 9 finden Sie weitere Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell.

3.2.2. Build-Parameter

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

  • [C-0-1] Um einheitliche, aussagekräftige Werte auf allen Geräten bereitzustellen Implementierungen implementiert haben, enthält die folgende Tabelle zusätzliche Einschränkungen für die Formate mit denen die Geräteimplementierungen übereinstimmen MÜSSEN.
Parameter Details
VERSION.VERÖFFENTLICHUNG Die Version des derzeit ausgeführten Android-Systems in visuell lesbarer Form Format. Dieses Feld MUSS einen der Zeichenfolgewerte enthalten, die in Zulässige Versionsstrings für Android 15
SDK VERSION Die Version des derzeit ausgeführten Android-Systems in einem Format Anwendungscode von Drittanbietern zugänglich sein. Bei Android 15 Dieses Feld MUSS den Ganzzahlwert 15_INT haben.
VERSION.SDK&lowbar;INT Die Version des derzeit ausgeführten Android-Systems in einem Format Anwendungscode von Drittanbietern zugänglich sein. Bei Android 15 dieses Feld MUSS den Ganzzahlwert 15&lowbar;INT haben.
VERSION.INCREMENTAL Wert, der vom Geräte-Implementierer ausgewählt wird, der den spezifischen Build bezeichnet des derzeit ausgeführten Android-Systems in menschenlesbarem Format. Dieses DÜRFEN NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. A Dieses Feld wird üblicherweise verwendet, um anzugeben, welche Build-Nummer oder Die Änderungs-ID der Versionsverwaltung wurde zum Generieren des Builds verwendet. Der Wert dieses Feld MUSS als druckbarer 7-Bit-ASCII codiert werden und mit den regulärer Ausdruck ^[^ :\/~]+$
BRETTSPIEL Ein Wert, der vom Geräte-Implementierer ausgewählt wird, der das spezifische interne Hardware, die vom Gerät verwendet wird, in menschenlesbarem Format. Ein möglicher Dieses Feld dient dazu, die spezifische Überarbeitung der Leiterplatte anzugeben auf dem Gerät. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden und Sie entsprechen dem regulären Ausdruck ^[a-zA-Z0-9_-]+$.
MARKE Ein Wert für den Markennamen, der dem Gerät zugeordnet ist (bekannt für die Endanwendenden. MÜSSEN in für Menschen lesbarem Format vorliegen und SOLLTEN die Hersteller des Geräts oder die Unternehmensmarke, unter der das Gerät verkauft wird vermarktet werden. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden und übereinstimmen den regulären Ausdruck ^[a-zA-Z0-9_-]+$.
UNTERSTÜTZTE&lowbar;ABIS Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) der nativen Anzeige Code. Siehe Abschnitt 3.3. Native API Kompatibilität.
UNTERSTÜTZT&lowbar;32&lowbar;BIT&lowbar;ABIS Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) der nativen Anzeige Code. Siehe Abschnitt 3.3. Native API Kompatibilität.
UNTERSTÜTZT&lowbar;64&lowbar;BIT&lowbar;ABIS Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) von nativen Code. Siehe Abschnitt 3.3. Nativ API-Kompatibilität.
CPU&lowbar;ABI Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) der nativen Anzeige Code. Siehe Abschnitt 3.3. Native API Kompatibilität.
CPU&lowbar;ABI2 Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) von nativen Code. Siehe Abschnitt 3.3. Nativ API-Kompatibilität.
GERÄT Wert, der vom Geräte-Implementierer ausgewählt wird und den Entwicklungsnamen enthält oder Codenamen, der die Konfiguration der Hardwarefunktionen und Industriedesign des Geräts. Der Wert dieses Felds MUSS codierbar sein als 7-Bit-ASCII-Zeichen und müssen dem regulären Ausdruck entsprechen. ^[a-zA-Z0-9_-]+$ Dieser Gerätename DARF NICHT während der Lebensdauer des Produkts.
Fingerabdruck Ein String, der diesen Build eindeutig identifiziert. SOLLTE plausibel sein visuell lesbar ist. Sie MUSS dieser Vorlage folgen:

$(BRAND)/$(PRODUKT)/
$(GERÄT):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Beispiel:

acme/meinprodukt/
meinGerät:15/LMYXX/3359:NutzerDebug/Testschlüssel

Der Fingerabdruck DARF KEINE Leerzeichen enthalten. Der Wert von MUSS dieses Feld als 7-Bit-ASCII codiert werden können.

Hardware Der Name der Hardware (aus der Kernel-Befehlszeile oder aus „/proc“). Es SOLLTEN menschenlesbar sein. In diesem Feld MUSS der Wert als 7-Bit-ASCII codiert und entspricht dem regulären Ausdruck ^[a-zA-Z0-9_-]+$
Moderator Ein String, der den Host eindeutig identifiziert, auf dem der Build erstellt wurde. menschenlesbares Format. Es gibt keine Anforderungen bezüglich des spezifischen Formats in dieses Feld, außer dass es NICHT null sein oder die leere Zeichenfolge ("").
ID Eine Kennung, die vom Geräte-Implementierer ausgewählt wird, um sich auf eine bestimmte in menschenlesbarem Format. Dieses Feld kann mit android.os.Build.VERSION.INCREMENTAL, SOLLTE aber ein ausreichender Wert sein. sodass Endnutzer zwischen Software-Builds unterscheiden können. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und mit dem regulären Ausdruck ^[a-zA-Z0-9._-]+$.
HERSTELLER Der Handelsname des Erstausrüsters (Original Equipment Manufacturer, OEM) des Produkt. Es gibt keine Anforderungen an das Format dieses Felds. außer dass er NICHT null oder die leere Zeichenfolge ("") sein darf. Dieses Feld DÜRFEN NICHT während der Lebensdauer des Produkts geändert werden.
SOC&lowbar;Hersteller Der Handelsname des Herstellers des primären Systems auf Chip (SOC) des Produkts. Geräte desselben SOC-Herstellers konstanten Wert verwenden. Fragen Sie beim SOC-Hersteller nach die richtige Konstante zu verwenden. Der Wert dieses Felds MUSS codierbar sein als 7-Bit-ASCII, MUSS mit dem regulären Ausdruck übereinstimmen ^([0-9A-Za-z ]+) darf NICHT mit einem Leerzeichen beginnen oder enden, und DÜRFEN NICHT gleich "unbekannt" sein. Dieses Feld DARF NICHT während der Lebensdauer des Produkts.
SOC-Modell Der Modellname des primären Systems-on-Chips (SOC), das in für das Produkt. Geräte mit demselben SOC-Modell sollten dieselbe Konstante verwenden. Wert. Fragen Sie den SOC-Hersteller nach der richtigen Konstante. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden können und mit dem regulärer Ausdruck ^([0-9A-Za-z ._/+-]+)$, DARF NICHT beginnen oder mit einem Leerzeichen enden und DARF NICHT gleich "unknown" sein. Dieses Feld DÜRFEN NICHT während der Lebensdauer des Produkts geändert werden.
MODELL Ein vom Geräte-Implementierer ausgewählter Wert, der den Namen des wie dem Endanwendenden bekannt ist. Dies SOLLTE der gleiche Name sein, unter dem das Gerät an Endnutzer vermarktet und verkauft wird. Es gibt keine Anforderungen das spezifische Format dieses Feldes, außer dass es NICHT NULL oder der Leerer String (""). Dieses Feld DARF NICHT während der Lebensdauer des Produkts.
PRODUKT/FUNKTION Wert, der vom Geräte-Implementierer ausgewählt wird und den Entwicklungsnamen enthält oder Codename des jeweiligen Produkts (SKU), der innerhalb der für dieselbe Marke. MÜSSEN lesbar sein, sind aber nicht unbedingt zur Ansicht gedacht. von den Endnutzern. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden und Sie entsprechen dem regulären Ausdruck ^[a-zA-Z0-9_-]+$. Dieses Produkt Der Name DÜRFEN sich während der Lebensdauer des Produkts NICHT ändern.
ODM&lowbar;SKU Ein optionaler Wert, der vom Geräte-Implementierer ausgewählt wird und Folgendes enthält: SKU (Stock Keeping Unit), mit der bestimmte Konfigurationen der Gerät enthalten, z. B. alle Peripheriegeräte, die beim Verkauf im Lieferumfang des Geräts enthalten waren. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden können und mit dem regulärer Ausdruck ^([0-9A-Za-z.,_-]+)$
Seriennummer MÜSSEN "UNKNOWN" zurückgeben.
TAGS Eine durch Kommas getrennte Liste von Tags, die von der Geräteimplementierung ausgewählt wurden und den Build noch besser unterscheidet. Die Tags MÜSSEN als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck ^[a-zA-Z0-9._-]+ übereinstimmen und MUSS haben einen der Werte, die den drei typischen Android-Plattformen Signaturkonfigurationen: Release-, Entwicklungs- und Testschlüssel.
UHRZEIT Ein Wert, der den Zeitstempel für den Build darstellt.
SCHREIBMASCHINE Wert, der vom Geräte-Implementierer ausgewählt wird, der die Laufzeit angibt Konfiguration des Builds. Dieses Feld MUSS einen der Werte enthalten. entspricht den drei typischen Android-Laufzeitkonfigurationen: Nutzer, userdebug.
NUTZER Name oder User-ID des Nutzers (oder des automatisierten Nutzers), der die Generierung der erstellen. Es gibt keine Anforderungen an das Format dieses Felds. außer dass er NICHT null oder die leere Zeichenfolge ("") sein darf.
SICHERHEIT&lowbar;PATCH Ein Wert, der die Sicherheitspatch-Ebene eines Builds angibt. Es MUSS bedeuten, Der Build ist in keiner Weise anfällig für die beschriebenen Probleme. im öffentlichen Sicherheitsbulletin für Android verfügbar. Sie MUSS in diesem Land sein: das Format [JJJJ-MM-TT] haben und einer definierten Zeichenfolge entsprechen, die im Öffentliche Sicherheit bei Android Bulletin oder im Android-Sicherheitshinweise, z. B. „2015-11-01“.
BASIS-Betriebssystem Wert, der den Parameter FINGERprint des Builds darstellt und der die ansonsten mit diesem Build identisch sind, mit Ausnahme der Patches in den Öffentliches Sicherheitsbulletin für Android Er MÜSSEN den richtigen Wert melden und so ein Build nicht existiert, melden Sie einen leeren String ("").
BOOTLOADER Ein Wert, der vom Geräte-Implementierer ausgewählt wird, der das spezifische Auf dem Gerät verwendete interne Bootloader-Version in einem visuell lesbaren Format. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden können und mit dem regulärer Ausdruck ^[a-zA-Z0-9._-]+$
getRadioVersion() MÜSSEN (oder zurückgeben) ein Wert, der von der Geräteimplementierung ausgewählt wurde die spezifische interne Radio-/Modemversion identifiziert, die auf dem Gerät verwendet wird, in menschenlesbarem Format. Wenn ein Gerät keine internen Radio/Modem MUSS NULL zurückgegeben werden. In diesem Feld MUSS der Wert als 7-Bit-ASCII codiert und entspricht dem regulären Ausdruck ^[a-zA-Z0-9._-,]+$
getSerial() MUSS eine Hardware-Seriennummer (MÜSSEN verfügbar sein oder zurückgegeben werden) und auf allen Geräten mit demselben MODELL und MANUFACTURER einzigartig sein. Der Wert von Dieses Feld MUSS als 7-Bit-ASCII codiert werden und dem regulären Ausdruck entsprechen. ^[a-zA-Z0-9]+$

3.2.3 Intent-Kompatibilität

3.2.3.1 Allgemeine Anwendungs-Intents

Android-Intents ermöglichen es Anwendungskomponenten, Funktionen von anderen Android-Komponenten. Das Android-Upstream-Projekt enthält eine Liste Anwendungen, die mehrere Intent-Muster zum Ausführen gängiger Aktionen implementieren.

Geräteimplementierungen:

  • [C-SR-1] wird dringend empfohlen, eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filter von den folgenden Anwendungs-Intents definierte Muster, die hier aufgeführt sind zu erfüllen, d.h. die Erwartungen der Entwickler in Bezug auf diese gängigen Anwendungs-Intents, wie im SDK beschrieben.

Informationen zu obligatorischen Anwendungs-Intents finden Sie in Abschnitt 2. für jeden Gerätetyp ein.

3.2.3.2 Intent-Auflösung
  • [C-0-1] Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen MÜSSEN alle in Abschnitt 3.2.3.1 referenzierten Intent-Muster zulassen, außer den Einstellungen, die von Drittanbieteranwendungen überschrieben werden. Die Dies wird standardmäßig durch die Open-Source-Implementierung von Android ermöglicht.

  • [C-0-2] Geräteimplementierungen DÜRFEN KEINE Sonderberechtigungen an das System anhängen Anwendungen oder verhindern, dass Drittanbieter-Apps von der Bindung an diese Muster und der Übernahme der Kontrolle über diese Muster. Dieses Verbot insbesondere das Deaktivieren der Funktion Nutzer Oberfläche, in der Nutzer zwischen mehreren Anwendungen wählen können, die alle mit demselben Intent-Muster verarbeitet werden.

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

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

Android umfasst auch einen Mechanismus, mit dem Drittanbieter-Apps eine autoritatives standardmäßiges Verhalten beim Verknüpfen von Apps für bestimmte Arten von Web-URI-Intents. Wenn solche verlässlichen Erklärungen in den Intent-Filtermustern einer App, Geräteimplementierungen:

  • [C-0-4] MÜSSEN versuchen, Intent-Filter zu validieren, indem in der Digital Asset Links-Spezifikation definierte Überprüfungsschritte wie vom Paketmanager in der vorgelagerten Open-Source-Version von Android implementiert. Projekt
  • [C-0-5] MÜSSEN versucht werden, die Validierung der Intent-Filter während der Installation von der Anwendung und legen Sie alle erfolgreich validierten URI-Intent-Filter als fest. Standard-App-Handler für ihre URIs zu verwenden.
  • spezifische URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen, Wenn sie erfolgreich überprüft werden, aber andere mögliche URI-Filter fehlschlagen Überprüfung. Ist dies bei einer Geräteimplementierung der Fall, MÜSSEN sie den Parameter Überschreibungen von nutzerspezifischen Überschreibungen von Pro-URI-Mustern im Einstellungsmenü.
  • Nutzer MUSS dem Nutzer in den Einstellungen Einstellungen für App-Links wie folgt zur Verfügung stellen: folgt: <ph type="x-smartling-placeholder">
      </ph>
    • [C-0-6] Der Nutzer MUSS in der Lage sein, die Standard-App ganzheitlich zu überschreiben. für eine App: immer offen, immer fragen oder nie öffnen, die für alle möglichen URI-Intent-Filter gleichermaßen gelten muss.
    • [C-0-7] Der Nutzer MUSS die Liste des möglichen URI-Intents sehen können. Filter.
    • Die Geräteimplementierung MÖGLICHERWEISE dem Nutzer die Möglichkeit geben, Bestimmte mögliche URI-Intent-Filter überschreiben, die erfolgreich waren können auf Basis von Intent-Filtern überprüft werden.
    • [C-0-8] Die Geräteimplementierung MUSS Nutzern die Möglichkeit geben, Bestimmte mögliche URI-Intent-Filter aufrufen und überschreiben, wenn das Gerät Bei der Implementierung sind einige mögliche URI-Intent-Filter erfolgreich. während andere nicht erfolgreich sein können.
3.2.3.3 Intent-Namespaces
  • [C-0-1] Geräteimplementierungen DÜRFEN KEINE Android-Komponente enthalten, die alle neuen Intent- oder Broadcast-Intent-Muster mit einer ACTION-, CATEGORY- oder Anderer Schlüsselstring im Namespace „android.*“ oder „com.android.*“ sein.
  • [C-0-2] Geräteimplementierungen DÜRFEN KEINE Android-Komponenten enthalten, die neue Intents oder Broadcast-Intent-Muster mit einer ACTION-, CATEGORY- oder anderer Schlüsselstring in einem Paketbereich, der zu einer anderen Organisation gehört.
  • [C-0-3] Nutzer, die auf Geräten implementiert sind, DÜRFEN den Intent NICHT verändern oder erweitern die in Abschnitt 3.2.3.1 aufgeführt sind.
  • Geräteimplementierungen KÖNNEN Intent-Muster mit Namespaces enthalten und offensichtlich mit dem Unternehmen in Verbindung gebracht werden. Dieses Verbot ist analog zu den Java-Sprachklassen in Abschnitt 3.6.
3.2.3.4 Übertragungs-Intents

Drittanbieter-Apps nutzen die Plattform, um bestimmte Intents über Änderungen in der Hardware- oder Softwareumgebung zu informieren.

Geräteimplementierungen:

  • [C-0-1] MÜSSEN die hier aufgeführten öffentlichen Übertragungs-Intents übertragen. als Reaktion auf entsprechende Systemereignisse, wie in der SDK-Dokumentation beschrieben. Diese Anforderung steht nicht im Widerspruch zu Abschnitt 3.5, da Einschränkungen für Hintergrundanwendungen werden auch im SDK beschrieben. Dokumentation. Bestimmte Broadcast-Intents sind an die Hardware gebunden. -Support. Wenn das Gerät die erforderliche Hardware unterstützt, MUSS er die Intents und stellen die Funktionsweise in der SDK-Dokumentation bereit.
3.2.3.5 Bedingte Anwendungs-Intents

Android bietet Einstellungen, die Nutzern eine einfache Möglichkeit bieten, Standard-Apps, z. B. für den Startbildschirm oder für SMS.

Wo es sinnvoll ist, MÜSSEN bei der Geräteimplementierung ähnliche Einstellungen bereitgestellt werden. und mit dem beschriebenen Intent-Filtermuster und den beschriebenen API-Methoden kompatibel sein. in der SDK-Dokumentation wie unten beschrieben.

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

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

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

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

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

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

  • [C-6-1] MÜSSEN eine Aktivität implementieren, die auf den Intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, Bei Implementierungen mit UI_MODE_TYPE_NORMAL MUSS dies eine Aktivität sein, bei der Der Nutzer kann der App Zugriff auf die nicht störenden Richtlinienkonfigurationen gewähren oder verweigern.

Wenn die Geräteimplementierung den Nutzern die Verwendung von Drittanbieter-Eingabemethoden auf der Gerät:

  • [C-7-1] MÜSSEN einen für den Nutzer zugänglichen Mechanismus zum Hinzufügen und Konfigurieren bereitstellen. Eingabemethoden von Drittanbietern als Reaktion auf android.settings.INPUT_METHOD_SETTINGS die Nutzerabsicht verstehen.

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

  • [C-8-1] MUSS die android.settings.ACCESSIBILITY_SETTINGS berücksichtigen einen für den Nutzer zugänglichen Mechanismus zum Aktivieren und Deaktivieren Bedienungshilfen von Drittanbietern neben den vorinstallierten .

Wenn Geräteimplementierungen Wi-Fi Easy Connect unterstützen und den Drittanbieter-Apps funktionieren, müssen sie:

Wenn Geräteimplementierungen den Datensparmodus unterstützen, ist Folgendes möglich:

Wenn Geräteimplementierungen den Datensparmodus nicht unterstützen, kann das folgende Gründe haben:

Wenn Geräteimplementierungen die Unterstützung der Kamera per android.hardware.camera.any, sie/er:

Wenn Geräteimplementierungen android.software.device_admin melden, geschieht Folgendes:

Wenn in Geräteimplementierungen die android.software.autofill deklariert ist Funktions-Flag:

Ob Geräteimplementierungen eine vorinstallierte App enthalten oder Sie dies zulassen möchten Drittanbieter-Apps für den Zugriff auf Nutzungsstatistiken:

  • [C-SR-2] wird dringend empfohlen, eine Option für Nutzer zugänglich zu machen, oder den Zugriff auf die Nutzungsstatistiken aufheben, android.settings.ACTION_USAGE_ACCESS_SETTINGS Absicht von Apps, die die android.permission.PACKAGE_USAGE_STATS deklarieren Berechtigung.

Wenn in Geräteimplementierungen keine Apps, einschließlich vorinstallierter Apps, nicht zugelassen werden sollen Apps auf die Nutzungsstatistiken zugreifen,

  • [C-15-1] MUSS immer noch eine Aktivität haben, android.settings.ACTION_USAGE_ACCESS_SETTINGS Intent-Muster, MUSS es aber als No-Op implementieren, d. h., es muss ein Äquivalent wenn der Zugriff für den Nutzer abgelehnt wird.

Wenn Geräteimplementierungen Links zu den Aktivitäten anzeigen, die von AutofillService_passwordsActivity in den Einstellungen oder über einen ähnlichen Mechanismus auf Nutzerpasswörter verweist, geschieht Folgendes:

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

Wenn Geräteimplementierungen das VoiceInteractionService unterstützen und mehr als bei einer Anwendung, die diese API verwendet, gleichzeitig Folgendes tun:

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

  • [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA und Für android.speech.tts.engine.GET_SAMPLE_TEXT-Intents muss eine Aktivität bereitgestellt werden Auftragsausführung für diese Intents, wie hier im SDK beschrieben.

Android bietet Unterstützung für interaktive Bildschirmschoner, die zuvor als als Träume. Mithilfe der Bildschirmschoner können Nutzer mit Apps interagieren, an eine Stromquelle angeschlossen ist, inaktiv oder in einem Dock angedockt ist. Geräteimplementierungen:

  • SOLLTEN Bildschirmschoner unterstützen und eine Einstellungsoption für die Konfiguration von Bildschirmschonern als Reaktion auf den android.settings.DREAM_SETTINGS Intent.

Wenn Geräteimplementierungen android.hardware.nfc.uicc oder android.hardware.nfc.ese melden, Sie:

3.2.4 Aktivitäten auf sekundären/mehreren Displays

Wenn die Geräteimplementierung das Starten normaler Android-Aktivitäten auf mehr als auf einem Display:

  • [C-1-1] MUSS die android.software.activities_on_secondary_displays festlegen Funktions-Flag.
  • [C-1-2] MUSS die API-Kompatibilität ähnlich einer Aktivität garantieren, die auf das primäre Display.
  • [C-1-3] Die neue Aktivität muss auf dem gleichen Display angezeigt werden wie die Aktivität, Er wurde gestartet, wenn die neue Aktivität ohne Angabe eines Ziels gestartet wird. Anzeige über das ActivityOptions.setLaunchDisplayId() der API erstellen.
  • [C-1-4] MUSS alle Aktivitäten vernichten, wenn eine Anzeige mit dem Display.FLAG_PRIVATE entfernt.
  • [C-1-5] MÜSSEN Inhalte auf allen Bildschirmen sicher verstecken, wenn das Gerät gesperrt ist mit einem sicheren Sperrbildschirm, es sei denn, die App lässt die Anzeige über dem Schloss zu Bildschirm mit Activity#setShowWhenLocked() der API erstellen.
  • SOLLTEN android.content.res.Configuration haben die dieser Anzeige entspricht, damit sie angezeigt werden kann, und die Kompatibilität aufrechterhalten, wenn eine Aktivität am sekundäre Displayanzeige.

Wenn die Geräteimplementierung das Starten normaler Android-Aktivitäten auf sekundären Websites ermöglicht und ein sekundäres Display mit android.view.Display.FLAG_PRIVATE Flag:

  • [C-3-1] Nur der Eigentümer dieses Displays, Systems und Aktivitäten, die die bereits auf diesem Display angezeigt werden, MUSS in der Lage sein, sie aufzurufen. Jeder kann ein Display mit android.view.Display.FLAG_PUBLIC melden.

3.3 Native API-Kompatibilität

Die Kompatibilität mit nativem Code ist schwierig. Aus diesem Grund Implementierung von Geräten:

  • [C-SR-1] EMPFOHLEN, Implementierungen der Bibliotheken zu verwenden aus dem vorgelagerten Android Open Source-Projekt stammen.

3.3.1 Binäre Anwendungsschnittstellen

Mit verwaltetem Dalvik-Bytecode kann nativen Code aufgerufen werden, der in der Anwendung bereitgestellt wird. .apk-Datei als ELF-.so-Datei, die für die entsprechende Gerätehardware kompiliert wurde Architektur. Da nativer Code stark vom zugrunde liegenden Prozessor abhängt definiert, definiert Android eine Reihe von Binärschnittstellen (Application Binary Interfaces, ABIs) in das Android NDK.

Geräteimplementierungen:

  • [C-0-1] MÜSSEN mit einem oder mehreren definierten Android-NDK-ABIs kompatibel sein.
  • [C-0-2] MÜSSEN Support für Code bereitstellen, der in der verwalteten Umgebung ausgeführt wird, um -Aufruf in nativen Code mithilfe des standardmäßigen Java Native Interface (JNI) Semantik.
  • [C-0-3] MÜSSEN quellkompatibel (d.h. header-kompatibel) sein und binär kompatibel (für die ABI) mit jeder erforderlichen Bibliothek in der Liste unten.
  • [C-0-5] MÜSSEN die native binäre Binärschnittstelle korrekt melden (ABI), die vom Gerät unterstützt werden, über android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS und android.os.Build.SUPPORTED_64_BIT_ABIS Parameter, jeweils durch Kommas getrennt Liste der ABIs, sortiert vom größten bis zum am wenigsten bevorzugten.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-0-6] MÜSSEN mithilfe der oben genannten Parameter eine Teilmenge der und DÜRFEN KEINE ABIs melden, die nicht auf der Liste stehen.

Neue Anforderungen beenden

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

    • libaaudio.so (Unterstützung für natives AAudio-Audio)
    • libamidi.so (native MIDI-Unterstützung, wenn Funktion android.software.midi) wie in Abschnitt 5.9 beschrieben beansprucht)
    • libandroid.so (native Unterstützung für Android-Aktivitäten)
    • libc (C-Bibliothek)
    • libcamera2ndk.so
    • libdl (dynamische Verknüpfung)
    • libEGL.so (natives OpenGL-Oberflächenmanagement)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • Liblog (Android-Protokollierung)
    • libmediandk.so (Unterstützung für native Media APIs)
    • libm (Mathematikbibliothek)
    • libneuralnetworks.so (Neural Networks API)
    • libOpenMAXAL.so (Unterstützung von OpenMAX AL 1.0.1)
    • libOpenSLES.so (Audiounterstützung von OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (Minimale Unterstützung für C++)
    • libvulkan.so (Vulkan)
    • libz (Zlib-Komprimierung)
    • JNI-Schnittstelle
  • [C-0-8] Dürfen die öffentlichen Funktionen für die nativen Bibliotheken NICHT hinzufügen oder entfernen oben aufgeführt.

  • [C-0-9] MÜSSEN zusätzliche Nicht-AOSP-Bibliotheken auflisten, die direkt Drittanbieter-Apps in /vendor/etc/public.libraries.txt.

  • [C-0-10] DÜRFEN KEINE anderen nativen Bibliotheken, implementiert und in AOSP als Systembibliotheken für Drittanbieter-Apps für Targeting API ab Level 24, da diese reserviert sind.

  • [C-0-11] MÜSSEN alle OpenGL ES 3.1-Dateien und das gesamte Android-Erweiterungspaket exportieren. wie im NDK über die Bibliothek libGLESv3.so definiert. Alle Symbole MÜSSEN zwar vorhanden sein, in Abschnitt 7.1.4.1 wird jedoch beschrieben, die Anforderungen an die vollständige Implementierung der einzelnen Funktionen erwartet werden.

  • [C-0-12] MÜSSEN Funktionssymbole für den Kern exportieren Vulkan 1.1-Funktion sowie den VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 und VK_KHR_get_physical_device_properties2-Erweiterungen über die libvulkan.so. Beachten Sie, dass zwar alle Symbole vorhanden sein MÜSSEN, Abschnitt 7.1.4.2 die Anforderungen an den Zeitpunkt, an dem die vollständigen dass die Implementierung der jeweiligen Funktionen erwartet wird.

  • SOLLTE mit dem Quellcode und den Header-Dateien erstellt werden, die im Open-Source-Projekt von Android.

Beachten Sie, dass in zukünftigen Android-Versionen möglicherweise weitere ABIs.

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

Wenn Geräteimplementierungen die Unterstützung des ABI für armeabi melden, geschieht Folgendes:

  • [C-3-1] MÜSSEN auch armeabi-v7a unterstützen und dies melden als armeabi dient nur der Abwärtskompatibilität mit älteren Apps.

Wenn Geräteimplementierungen die Unterstützung des armeabi-v7a-ABIs melden, für Apps mit diesem ABI:

  • [C-2-1] MUSS die folgenden Zeilen in /proc/cpuinfo enthalten und sollte NICHT ändern die Werte auf demselben Gerät, auch wenn sie von anderen ABIs gelesen werden.

    • Features:, gefolgt von einer Liste optionaler ARMv7-CPU-Features die vom Gerät unterstützt werden.
    • CPU architecture:, gefolgt von einer Ganzzahl für die höchst unterstützte ARM-Architektur (z.B. „8“ für ARMv8-Geräte).
  • [C-2-2] MÜSSEN die folgenden Vorgänge immer verfügbar halten, auch im in denen das ABI in einer ARMv8-Architektur implementiert ist, entweder über native CPU-Unterstützung oder durch Softwareemulation:

    • Anweisungen zu SWP und SWPB.
    • CP15ISB-, CP15DSB- und CP15DMB-Hürdenoperationen
  • [C-2-3] MÜSSEN Support für Advanced SIMD (auch bekannt als NEON).

3.4 Webkompatibilität

3.4.1 WebView-Kompatibilität

Wenn Geräteimplementierungen eine vollständige Implementierung der android.webkit.Webview-API kann Folgendes ausgeführt werden:

  • [C-1-1] MÜSSEN android.software.webview melden.
  • [C-1-2] MUSS den Chromium-Projekt-Build verwenden aus dem vorgelagerten Open-Source-Projekt von Android 15 Branch für die Implementierung der android.webkit.WebView der API erstellen.
  • [C-1-3] Der von WebView gemeldete User-Agent-String MUSS folgendes Format haben:

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

    • Der Wert des Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE.
    • Der String $(MODEL) KANN leer sein, aber wenn er nicht leer ist, MUSS er denselben Wert wie android.os.Build.MODEL.
    • „Build/$(BUILD)“ KANN weggelassen werden, aber wenn es vorhanden ist, ist $(BUILD) erforderlich. String MUSS mit dem Wert für android.os.Build.ID identisch sein.
    • Der Wert des Strings $(CHROMIUM_VER) MUSS die Version von Chromium sein im vorgelagerten Android Open Source-Projekt.
    • Bei Geräteimplementierungen KANN „Mobile“ im User-Agent-String weggelassen werden.
  • Die WebView-Komponente SOLLTE Unterstützung für so viele HTML5-Funktionen wie möglich und wenn die Funktion unterstützt wird, SOLLTEN Sie den HTML5-Spezifikation

  • [C-1-4] MÜSSEN die bereitgestellten Inhalte oder Remote-URL-Inhalte in einem Prozess gerendert werden. die sich von der Anwendung unterscheidet, die die WebView instanziiert. Insbesondere Der separate Renderer-Prozess MUSS geringere Berechtigungen haben, ausführen als separate Nutzer-ID haben, keinen Zugriff auf das Datenverzeichnis der Anwendung, keinen direkten Netzwerkzugriff haben und nur auf das Minimum Systemdienste über Binder. Die AOSP-Implementierung von WebView erfüllt diese Anforderung erfüllen.

Hinweis: Bei 32-Bit-Implementierungen von Geräten oder zum Deklarieren des Funktions-Flags android.hardware.ram.low sind sie von C-1-3 ausgenommen.

3.4.2 Browserkompatibilität

Wenn Geräteimplementierungen eine eigenständige Browseranwendung für allgemeine wenn sie im Web surfen,

  • [C-1-1] MUSS alle der folgenden APIs unterstützen, die mit HTML5: <ph type="x-smartling-placeholder">
  • [C-1-2] MUSS HTML5/W3C unterstützen Webstorage API verwenden und HTML5/W3C unterstützen IndexedDB API Beachten Sie, dass als Web- stellen Stellen mit Entwicklungsstandards zur Bevorzugung von IndexedDB gegenüber wird IndexedDB zu einer erforderlichen Komponente zukünftige Android-Version.
  • KANN einen benutzerdefinierten User-Agent-String in der eigenständigen Browseranwendung versenden.
  • SOLLTE Support möglichst viel von HTML5 wie möglich auf der eigenständigen Version Browser-Anwendung (ob auf dem vorgeschalteten WebKit-Browser basiert) oder eine Ersatzanwendung durch einen Drittanbieter).

Wenn Geräteimplementierungen jedoch keinen eigenständigen Browser umfassen, Anwendung finden, gilt Folgendes:

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

3.5 API-Verhaltenskompatibilität

Geräteimplementierungen:

  • [C-0-9] MÜSSEN sicherstellen, dass die API-Verhaltenskompatibilität auf alle angewendet wird, installierten Apps, es sei denn, sie sind wie unter Abschnitt 3.5.1:
  • [C-0-10] DÜRFEN NICHT die Zulassungsliste implementieren, mit der sichergestellt wird, Verhaltenskompatibilität nur für Apps, die nach Gerät ausgewählt sind und Implementierungsteams.

Das Verhalten der einzelnen API-Typen (verwaltet, weich, nativ und Web) muss mit der bevorzugten Implementierung der vorgelagerten Open-Source-Projekt für Android Bestimmte Gebiete Kompatibilität sind:

  • [C-0-1] Geräte DÜRFEN NICHT das Verhalten oder die Semantik eines Geräts ändern. Standard-Intent.
  • [C-0-2] Geräte DÜRFEN den Lebenszyklus oder die Lebenszyklussemantik von eine bestimmte Art von Systemkomponente (wie Dienst, Aktivität, ContentProvider usw.).
  • [C-0-3] Geräte DÜRFEN die Semantik einer Standardberechtigung NICHT ändern.
  • Auf den Geräten DÜRFEN die Beschränkungen für Hintergrund-Apps NICHT geändert werden. Genauer gesagt für Hintergrund-Apps: <ph type="x-smartling-placeholder">
      </ph>
    • [C-0-4] Sie MÜSSEN die Ausführung von Callbacks beenden, die vom App, um Ausgaben vom GnssMeasurement zu empfangen und GnssNavigationMessage.
    • [C-0-5] MÜSSEN die Häufigkeit von Updates, die die der App über die LocationManager API-Klasse oder der WifiManager.startScan() .
    • [C-0-6] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, DÜRFEN SIE NICHT Broadcast-Empfänger für implizite Broadcasts von Standard-Android-Intents im Manifest der App, es sei denn, der Broadcast Für Intent ist ein "signature" oder "signatureOrSystem" erforderlich protectionLevel oder sich im Ausnahmeliste.
    • [C-0-7] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MUSS die App beendet werden. die Hintergrunddienste der App, als ob sie die Dienste stopSelf() aus, es sei denn, die App wird auf eine temporäre Zulassungsliste gesetzt, die für die Nutzenden sichtbar ist.
    • [C-0-8] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN sie MÜSSEN lassen Sie die Wakelocks in der App los.
  • [C-0-11] Geräte MÜSSEN die folgenden Sicherheitsanbieter als erste sieben Array-Werte aus der Security.getProviders() in der angegebenen Reihenfolge und mit den angegebenen Namen (wie von Provider.getName()) und Klassen, es sei denn, die App hat die Liste über insertProviderAt() oder removeProvider(). Geräte KANN nach der angegebenen Liste von Anbietern weitere Anbieter zurückgeben. unten.
    1. AndroidNSSPandroid.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSLcom.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvidersun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaroundandroid.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BCcom.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSEcom.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStoreandroid.security.keystore.AndroidKeyStoreProvider

Die obige Liste ist nicht vollständig. CTS-Tests (Compatibility Test Suite) für Verhaltenskompatibilität, aber nicht alle. Der Implementierer ist dafür verantwortlich, die Verhaltenskompatibilität sicherzustellen. mit dem Open-Source-Projekt von Android. Daher sollten Geräte-Implementierer SOLLTE den über das Android Open Source Project verfügbaren Quellcode verwenden, wobei anstatt große Teile des Systems neu zu implementieren.

3.5.1 Anwendungseinschränkung

Wenn Geräteimplementierungen einen proprietären Mechanismus zum Einschränken von Apps implementieren (z.B. Änderung oder Einschränkung von API-Verhaltensweisen, im SDK beschrieben) und Dieser Mechanismus ist restriktiver als der eingeschränkte App-Standby-Bucket:

  • [C-1-1] MÜSSEN dem Nutzer erlauben, die Liste der eingeschränkten Apps aufzurufen.
  • [C-1-2] MÜSSEN Nutzern die Möglichkeit bieten, all diese proprietäre Einschränkungen für jede App.
  • [C-1-3] DÜRFEN diese proprietären Einschränkungen nicht automatisch anwenden, ohne Hinweise auf schlechtes Systemzustand, MÖGLICHERWEISE jedoch die Einschränkungen für Apps anwenden bei Erkennung eines schlechten Systemzustandsverhaltens wie hängenden Wakelocks, Langzeitlaufzeiten Dienstleistungen und andere Kriterien. Die Kriterien KÖNNEN vom Gerät abhängen Implementierer, MÜSSEN jedoch mit den Auswirkungen der App auf den Systemzustand in Verbindung stehen. Sonstiges Kriterien, die sich nicht nur auf den Systemzustand beziehen, z. B. geringe Beliebtheit auf dem Markt, DARF NICHT als Kriterien verwendet werden.

  • [C-1-4] DARF diese proprietären Einschränkungen nicht automatisch auf Apps anwenden. Ein Nutzer hat App-Einschränkungen manuell deaktiviert und KANN dem Nutzer vorschlagen, um diese proprietären Einschränkungen anzuwenden.

  • [C-1-5] MÜSSEN Nutzer informieren, wenn diese proprietären Einschränkungen für automatisch eine App. Solche Informationen MÜSSEN innerhalb von 24 Stunden zur Verfügung gestellt werden. vor der Anwendung dieser proprietären Einschränkungen.

  • [C-1-6] MUSS für ActivityManager.isBackgroundRestricted() "true" zurückgeben für API-Aufrufe aus einer App.

  • [C-1-7] DÜRFEN NICHT die im Vordergrund verwendete App einschränken, die explizit von Nutzenden.

  • [C-1-8] MÜSSEN diese proprietären Einschränkungen für eine App aussetzen, wenn ein Der Nutzer beginnt, die App explizit zu verwenden, wodurch sie im Vordergrund angezeigt wird. .

  • [C-1-10] MÜSSEN ein öffentliches und klares Dokument oder eine Website zur Verfügung gestellt werden, wie proprietäre Einschränkungen angewendet werden. Dieses Dokument oder diese Website MUSS aus den Android SDK-Dokumenten verknüpfbar und MÜSSEN Folgendes enthalten:

    • Bedingungen für proprietäre Einschränkungen auslösen
    • Welche Einschränkungen für Apps gelten und wie sie eingeschränkt werden können
    • Wie eine App von solchen Einschränkungen ausgenommen werden kann
    • Wie eine App eine Ausnahme von proprietären Einschränkungen beantragen kann, eine solche Ausnahme für Apps, die der Nutzer installieren kann.

Wenn eine App auf dem Gerät vorinstalliert ist und noch nie von einem mehr als 30 Tage lang genutzt werden, sind [C-1-3] [C-1-5] ausgenommen.

Wenn Geräteimplementierungen die implementierten App-Einschränkungen erweitern bei AOSP:

  • [C-2-1]MÜSSEN der in diesem Dokument beschriebenen Implementierung folgen.

3.5.2 Ruhezustand von Anwendungen

Wenn Geräteimplementierungen den App-Ruhemodus beinhalten, der in AOSP enthalten ist, oder die in AOSP enthaltene Funktion erweitern, dann:

  • [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] MUSS die Einschränkung für die App nur auf einen Nutzer anwenden, wenn den Nachweis, dass der Nutzer die App über einen längeren Zeitraum nicht verwendet hat. Dieses Dauer wird UNBEDINGT zu einem Monat oder länger empfohlen. Nutzung MÜSSEN sein durch explizite Nutzerinteraktion über die UsageStats#getLastTimeVisible() über eine API oder ein anderes Element, das dazu führen würde, dass eine App einschließlich Dienstbindungen, Contentanbieterbindungen, expliziten Broadcasts usw., die von einer neuen API UsageStats#getLastTimeAnyComponentUsed() nachverfolgt werden.
  • [C-1-3] MUSS nur Einschränkungen anwenden, die alle Gerätenutzer betreffen, ist der Beweis dafür, dass das Paket über einen bestimmten Zeitraum . Diese Dauer wird UNBEDINGT zu einem Monat oder länger empfohlen.
  • [C-1-4] DÜRFEN die App nicht in der Lage machen, auf Aktivitäts-Intents zu reagieren, z. B. Dienstbindungen, Contentanbieteranfragen oder explizite Übertragungen.

Der App-Ruhezustand in AOSP erfüllt die oben genannten Anforderungen.

3.6. API-Namespaces

Android folgt den Konventionen für Paket- und Klassen-Namespaces, die von der Java- Programmiersprache. Um die Kompatibilität mit Anwendungen von Drittanbietern sicherzustellen, Geräte-Implementierungen DÜRFEN KEINE verbotenen Änderungen (siehe unten) an diese Paket-Namespaces:

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

Das heißt:

  • [C-0-1] DÜRFEN die auf der Android-Plattform öffentlich zugänglichen APIs NICHT verändern. durch Ändern beliebiger Methoden oder Klassensignaturen oder Entfernen von Klassen oder Klassen .
  • [C-0-2] DÜRFEN KEINE öffentlich zugänglichen Elemente wie Klassen oder Schnittstellen oder Felder oder Methoden auf vorhandene Klassen oder Schnittstellen) oder Test oder System-APIs zu den APIs in den oben genannten Namespaces hinzu. Ein „öffentlich exponiertes Element“ ist ein Konstrukt, das nicht mit „@hide“ dekoriert ist Markierung als die im vorgelagerten Android-Quellcode verwendet werden.

Geräte-Implementierer KÖNNEN die zugrunde liegende Implementierung der APIs ändern, aber Änderungen vornehmen:

  • [C-0-3] DÜRFEN NICHT das angegebene Verhalten und die Java-Sprachsignatur von öffentlich zugänglichen APIs.
  • [C-0-4] DÜRFEN NICHT beworben und nicht auf andere Weise Entwicklern zugänglich gemacht werden.

Geräte-Implementierer KÖNNEN jedoch benutzerdefinierte APIs außerhalb des standardmäßigen Android- Namespace, aber die benutzerdefinierten APIs:

  • [C-0-5] Dürfen sich NICHT in einem Namespace befinden, der einem anderen Namespace gehört oder auf diesen verweist Unternehmen. Beispielsweise DÜRFEN Personen, die Geräte implementieren, com.google.* oder ähnlicher Namespace: Nur Google kann dies tun. In ähnlicher Weise Google DARF KEINE APIs zu den APIs anderer Unternehmen hinzufügen. Namespaces.
  • [C-0-6] MÜSSEN in einer gemeinsam genutzten Bibliothek von Android gepackt sein, damit nur Apps die sie explizit (über den Mechanismus <uses-library>) verwenden, sind die von der erhöhten Arbeitsspeichernutzung dieser APIs betroffen sind.

Geräte-Implementierer KÖNNEN benutzerdefinierte APIs in Muttersprachen außerhalb des NDK hinzufügen. APIs, aber die benutzerdefinierten APIs:

  • [C-1-1] Darf sich NICHT in einer NDK-Bibliothek oder einer Bibliothek eines anderen Nutzers befinden des Unternehmens wie beschrieben hier.

Wenn ein Geräte-Implementierer vorschlägt, einen der oben genannten Paket-Namespaces zu verbessern z. B. durch Hinzufügen nützlicher neuer Funktionen zu einer vorhandenen API oder Hinzufügen einer neuen API) verwendet, SOLLTE der Implementierer source.android.com aufrufen. und beginnen damit, Änderungen beizutragen, gemäß den Informationen auf der Website.

Beachten Sie, dass die oben genannten Einschränkungen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java soll dies lediglich darauf abzielen, und binden sie durch Einbeziehung in diese Kompatibilitäts- Definition:

3.7 Laufzeitkompatibilität

Geräteimplementierungen:

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

  • [C-0-2] MÜSSEN Dalvik-Laufzeiten konfigurieren, um Arbeitsspeicher zuzuweisen in entsprechend der vorgelagerten Android-Plattform und in der folgenden Tabelle. (Siehe Abschnitt 7.1.1 für Definitionen für Bildschirmgröße und Bildschirmdichte.)

  • SOLLTEN Android RunTime (ART), die Upstream-Referenz, verwenden Implementierung des Dalvik Executable Formats und die Referenz im Paketverwaltungssystem der Implementierung.

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

Die unten angegebenen Speicherwerte gelten als Mindestwerte und Geräteimplementierungen KÖNNEN mehr Speicher pro Anwendung zuweisen.

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

3.8 Kompatibilität der Benutzeroberfläche

3.8.1 Launcher (Startbildschirm)

Android umfasst eine Launcher-App (Startbildschirm) und Unterstützung für Drittanbieter-Apps als Ersatz für den Geräte-Launcher (Startbildschirm) aus.

Wenn die Geräteimplementierung das Gerät durch Drittanbieter-Apps ersetzen kann Startbildschirm eingeblendet wird, geschieht Folgendes:

  • [C-1-1] MÜSSEN die Plattformfunktion android.software.home_screen deklarieren.
  • [C-1-2] MUSS den AdaptiveIconDrawable zurückgeben. Objekt, wenn die Drittanbieter-App das Tag <adaptive-icon> verwendet, das eigene Symbol und die PackageManager zum Abrufen von Symbolen aufgerufen.

Ob Geräteimplementierung einen Standard-Launcher enthalten, der In-App unterstützt das Anpinnen von Tastenkombinationen:

Umgekehrt gilt: Wenn Geräteimplementierungen das In-App-Pinning nicht unterstützen, können:

Wenn in der Geräteimplementierung ein Standard-Launcher implementiert ist, Zugriff auf die zusätzlichen Verknüpfungen von Drittanbieter-Apps über die ShortcutManager API können sie:

  • [C-4-1] MÜSSEN alle dokumentierten Tastenkombinationen unterstützen (z.B. statische und dynamische Verknüpfungen, Anpinnen von Verknüpfungen) und die vollständige Implementierung der APIs der ShortcutManager API-Klasse.

Wenn Geräte eine Standard-Launcher-App enthalten, die Kennzeichen für App-Symbole:

  • [C-5-1] MUSS die NotificationChannel.setShowBadge() respektieren API-Methode. Mit anderen Worten: Zeigen Sie ein visuelles Angebot, das mit dem App-Symbol verbunden ist, wenn das Der Wert ist auf true festgelegt. Es wird kein App-Symbol-Badge-Schema angezeigt, wenn alle der Benachrichtigungskanäle der App haben den Wert auf false gesetzt.
  • KÖNNEN die App-Symbol-Logos durch das eigene Logo-Schema überschrieben werden, wenn Anwendungen von Drittanbietern zeigen, dass sie das proprietäre Logo-Schema unterstützen. proprietäre APIs, aber SOLLTEN die Ressourcen und Werte über die im SDK beschriebenen APIs für Benachrichtigungskennzeichen bereitgestellt werden, z. B. Notification.Builder.setNumber() und Notification.Builder.setBadgeIconType() der API erstellen.

Wenn Geräteimplementierungen dies unterstützen Einfarbig Symbole, diese Symbole:

  • [C-6-1] MUSS nur verwendet werden, wenn ein Nutzer dies explizit aktiviert (z.B. über Einstellungen oder Hintergrundauswahl).

3.8.2 Widgets

Android unterstützt Widgets von Drittanbieter-Apps, indem ein Komponententyp und zugehörigen API und Lebenszyklus, mit denen Anwendungen eine „AppWidget“ für die Endanwendenden.

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

  • [C-1-1] MÜSSEN die Unterstützung für Plattformfunktionen erklären android.software.app_widgets
  • [C-1-2] MÜSSEN integrierte Unterstützung für AppWidgets beinhalten und Angebote der Benutzeroberfläche zum Hinzufügen, Konfigurieren, Anzeigen und Entfernen von AppWidgets
  • [C-1-3] MÜSSEN Widgets mit dem Format 4 x 4 rendern können. in der Standardrastergröße. Weitere Informationen finden Sie in den Designrichtlinien für App-Widgets. finden Sie in der Android SDK-Dokumentation.
  • KANN App-Widgets auf dem Sperrbildschirm unterstützen.

Ob Geräteimplementierungen App-Widgets und In-App-Apps von Drittanbietern unterstützen das Anpinnen von Tastenkombinationen:

3.8.3 Benachrichtigungen

Android umfasst Notification und NotificationManager APIs, mit denen Entwickler von Drittanbieter-Apps Nutzer über wichtige Ereignisse und das Interesse der Nutzenden die Aufmerksamkeit durch Hardwarekomponenten (z.B. Ton, Vibration und leuchten) sowie Softwarefunktionen (z.B. Benachrichtigungsleiste, Systemleiste) des .

3.8.3.1 Darstellung von Benachrichtigungen

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

  • [C-1-1] MÜSSEN Benachrichtigungen unterstützen, die Hardwarefunktionen verwenden, wie in der SDK-Dokumentation und, soweit dies mit der Geräteimplementierung möglich ist, Hardware. Wenn eine Geräteimplementierung beispielsweise einen Vibrationsalarm beinhaltet, MÜSSEN sie MÜSSEN die Vibrations-APIs korrekt implementiert. Wenn die Implementierung eines Geräts Hardware verwenden, MÜSSEN die entsprechenden APIs als managementfrei implementiert werden. Dieses Verhalten ist wird in Abschnitt 7 genauer beschrieben.
  • [C-1-2] MUSS alle resources korrekt rendern (Symbole, Animationsdateien usw.), die in den APIs oder in den Styleguide für Status-/Systemleistensymbole, obwohl sie eine alternative Nutzererfahrung für Benachrichtigungen bieten KÖNNEN als durch die Open-Source-Referenzimplementierung für Android bereitgestellt.
  • [C-1-3] MÜSSEN die für APIs Benachrichtigungen zu aktualisieren, zu entfernen und zu gruppieren.
  • [C-1-4] MUSS das vollständige Verhalten von NotificationChannel bereitstellen API, die im SDK dokumentiert ist.
  • [C-1-5] MÜSSEN eine Nutzeroption zum Blockieren und Ändern einer bestimmten Benachrichtigung der Drittanbieter-App für jede Kanal- und App-Paketebene.
  • [C-1-6] MÜSSEN auch Angebote zum Anzeigen gelöschter Benachrichtigungen enthalten. Kanäle.
  • [C-1-7] MÜSSEN alle Ressourcen (Bilder, Sticker, Symbole usw.) korrekt rendern. über Notification.MessagingStyle bereitgestellt neben dem Benachrichtigungstext ohne zusätzliche Nutzerinteraktion. Für MÜSSEN beispielsweise alle Ressourcen angezeigt werden, auch die Symbole, die über android.app.Person in einer Gruppenunterhaltung, die durch setGroupConversation:

  • [C-SR-1] EMPFOHLEN, Nutzern ein Angebot zu bieten, festlegen, welche Benachrichtigungen Apps angezeigt werden, denen die Berechtigung für Mitteilungs-Listener. Der Detaillierungsgrad MUSS so sein, dass die Nutzenden Steuerelement für jeden solchen Benachrichtigungs-Listener, welche Benachrichtigungstypen mit diesem Listener verbunden. Die Typen MÜSSEN „Unterhaltungen“, „Benachrichtigungen“, „Lautlos“ und „Wichtige fortlaufende Inhalte“ Benachrichtigungen.

  • [C-SR-2] EMPFOHLEN, dürfte Nutzern ein Angebot bieten Apps, bei denen ein bestimmter Benachrichtigungs-Listener nicht benachrichtigt werden soll.

  • [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, ein Nutzerangebot automatisch anzeigen zu lassen Um die Benachrichtigung einer bestimmten Drittanbieter-App für jeden Kanal und jede App zu blockieren nachdem der Nutzer die Benachrichtigung mehrmals geschlossen hat.

  • SOLLTEN erweiterte Benachrichtigungen unterstützen.

  • SOLLTEN Benachrichtigungen mit höherer Priorität als Vorabbenachrichtigungen präsentiert werden.

  • SOLLTEN die Nutzer die Möglichkeit haben, Benachrichtigungen zurückzustellen.

  • KANN nur die Sichtbarkeit und den Zeitpunkt festlegen, zu dem Drittanbieter-Apps benachrichtigt werden können von wichtigen Ereignissen, um Sicherheitsprobleme wie die Ablenkung des Fahrers zu mindern.

Mit Android 11 werden Unterhaltungsbenachrichtigungen unterstützt: Benachrichtigungen mit MessagingStyle und gibt eine veröffentlichte Kurzbefehl-ID für Personen an.

Geräteimplementierungen:

  • [C-SR-4] EMPFOHLENE Gruppierung und Kennzeichnung conversation notifications vor Benachrichtigungen, die keine Unterhaltung sind, mit Ausnahme von laufende Benachrichtigungen zu Diensten im Vordergrund und importance:high Benachrichtigungen.

Wenn Geräteimplementierungen conversation notifications unterstützen und die App stellt die erforderlichen Daten bereit, bubbles:

  • [C-SR-5] Wir empfehlen dringend, diese Unterhaltung als Bubble anzuzeigen. Die AOSP-Implementierung erfüllt diese Anforderungen mit der standardmäßigen System-UI, Einstellungen und Launcher.

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

  • [C-2-1] MÜSSEN die exakten Ressourcen wie über die Notification.Style bereitgestellt API-Klasse und ihre abgeleiteten Klassen für die dargestellten Ressourcenelemente.
  • SOLLTEN Sie jedes einzelne Ressourcenelement (z.B. Symbol, Titel und Zusammenfassungstext) definiert in Notification.Style API-Klasse und ihre abgeleiteten Klassen.

Vorwarnungen sind Benachrichtigungen, die dem Nutzer unabhängig von der Oberfläche präsentiert werden, aktiviert. Wenn Geräteimplementierungen eine Warnmeldung unterstützen Benachrichtigungen erhalten, geschieht Folgendes:

  • [C-3-1] MUSS die Ansicht mit Vorabbenachrichtigungen und die Ressourcen verwenden wie in Notification.Builder beschrieben API-Klasse, wenn Vorabbenachrichtigungen angezeigt werden.
  • [C-3-2] MÜSSEN die in Notification.Builder.addAction() ohne zusätzliche Nutzerinteraktion gemeinsam mit dem Inhalt der Benachrichtigung wie im SDK beschrieben.
3.8.3.2 Mitteilungs-Listener-Dienst

Android umfasst die NotificationListenerService APIs, die es Apps (sobald der Nutzer explizit aktiviert hat) erlauben, eine Kopie von alle Benachrichtigungen, sobald sie gepostet oder aktualisiert werden.

Geräteimplementierungen:

  • [C-0-1] MÜSSEN die Benachrichtigungen korrekt und umgehend vollständig aktualisieren. an alle derartigen installierten und nutzeraktivierten Hörerdienste, einschließlich aller und Alle Metadaten, die an das Benachrichtigungsobjekt angehängt sind.
  • [C-0-2] MÜSSEN die snoozeNotification() respektieren API-Aufruf aufrufen, die Benachrichtigung schließen und nach der Schlummerfunktion einen Rückruf starten Dauer, die im API-Aufruf festgelegt wird.

Wenn Geräteimplementierungen Nutzern die Möglichkeit bieten, Benachrichtigungen zurückzustellen, geschieht Folgendes:

  • [C-1-1] MÜSSEN den Status der zurückgestellten Benachrichtigungen richtig wiedergeben. Standard-APIs wie NotificationListenerService.getSnoozedNotifications()
  • [C-1-2] MÜSSEN diesem Nutzer die Möglichkeit geben, Benachrichtigungen zu deaktivieren. aus jeder installierten Drittanbieter-App, es sei denn, sie stammen von dauerhafte Dienste im Vordergrund.
3.8.3.3 Nicht stören/Prioritätsmodus

Wenn Geräteimplementierungen die Funktion „Nicht stören“ unterstützen (auch Prioritätsmodus genannt), haben sie folgende Möglichkeiten:

  • [C-1-1] MÜSSEN, wenn die Geräteimplementierung dem Nutzer die Möglichkeit bietet, Drittanbieter-Apps Zugriff auf die Konfiguration der „Nicht stören“-Richtlinie zu gewähren oder zu verweigern, Automatische DND-Regeln anzeigen die von Anwendungen zusammen mit den vom Nutzer erstellten und vordefinierten Regeln erstellt werden.
  • [C-1-3] MUSS die suppressedVisualEffects berücksichtigen Werte, die über NotificationManager.Policy übergeben werden Wenn eine App einen der SUPPRESSED_EFFEKT_SCREEN_OFF oder SUPPRESSED_EFFEKT_SCREEN_ON gekennzeichnet ist, SOLLTEN Sie dem Nutzer anzeigen, dass die Visuelle Effekte werden im Einstellungsmenü „Nicht stören“ unterdrückt.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

3.8.3.4 Schutz sensibler Benachrichtigungen

Zu vertraulichen Benachrichtigungsdaten gehören Inhalte wie Einmalpasswörter, einmalige Bestätigungscodes und ähnliche Authentifizierungs- oder Zurücksetzen-Codes, können in Benachrichtigungen für Nutzende zu machen.

Ob Drittanbieter-Apps bei der Geräteimplementierung Nutzer über wichtige Ereignisse zu benachrichtigen, Sie:

  • [C-1-1] MÜSSEN vertrauliche Benachrichtigungsinformationen aus der Weitergabe an Benachrichtigungs-Listener, es sei denn, der Listener-Dienst ist einer der folgenden:

    • Vom System signierte Apps mit einem uid < 10.000
    • System-UI
    • Muschel
    • Ausgewählte Companion-Geräte-App (definiert durch CompanionDeviceManager)
    • Rolle „SYSTEM_AUTOMOTIVE_PROJECTION
    • Rolle „SYSTEM_NOTIFICATION_INTELLIGENCE
    • HOME-Rolle

Die AOSP-Implementierung von NotificationAssistantServices diese Anforderungen beispielhaft darstellt und erfüllt. Weitere Informationen finden Sie unter android.ext.services.notification finden Sie ein Beispiel.

Neue Anforderungen beenden

3.8.4. Assist-APIs

Android enthält die Assist APIs. damit Anwendungen auswählen können, wie viele Informationen des aktuellen Kontextes die für den Assistant auf dem Gerät freigegeben sind.

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

  • [C-2-1] MÜSSEN Endnutzer deutlich darauf hinweisen, wenn der Kontext bereitgestellt wird, indem Entweder: <ph type="x-smartling-placeholder">
      </ph>
    • Jedes Mal, wenn die Assistent-App auf den Kontext zugreift, wird ein weißes Symbol an den Rändern des Bildschirms an, die die Dauer der Open-Source-Projekt-Implementierung von Android.
    • Die vorinstallierte Assistent-App bietet den Nutzern weniger Geld. als zwei Navigationen von der Standardeinstellungen für Spracheingabe und in der Assistant App, und nur dann den Kontext teilen, wenn die Assistent-App explizit durch über die Eingabe eines Hotwords oder einer unterstützenden Navigationstaste.
  • [C-2-2] Die vorgesehene Interaktion zum Starten der Assist-App, wie beschrieben. in Abschnitt 7.2.3 MÜSSEN die vom Nutzer ausgewählte Assistent-App, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die den Intent ACTION_ASSIST verarbeitet.

3.8.5 Benachrichtigungen und Toasts

Anwendungen können den Toast verwenden API zur Anzeige kurzer, nicht modaler Strings für Endnutzer, die nach einer und verwenden Sie die TYPE_APPLICATION_OVERLAY Fenstertyp-API, um Warnfenster als Overlay über anderen Apps anzuzeigen.

Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:

  • [C-1-1] MÜSSEN eine Funktion bieten, mit der eine App daran gehindert werden kann, Benachrichtigungen anzuzeigen. Fenster, die TYPE_APPLICATION_OVERLAY verwenden. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente in der Benachrichtigungsleiste.

  • [C-1-2] MÜSSEN die Toast API berücksichtigen und Endnutzern in einigen sichtbar sind.

3.8.6. Designs

Android bietet „Designs“ als Mechanismus verwendet, mit dem Stile einer gesamten Aktivität oder einer App geöffnet.

Android enthält ein "Holo" und „Material“ Designfamilie als eine Reihe definierter Stile für Anwendungsentwickler:innen, die den Holo-Design wie vom Android SDK definiert.

Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:

  • [C-1-1] DÜRFEN KEINE der Holo-Designattribute verändern, die Anwendungen.
  • [C-1-2] MUSS das Attribut „Material“ unterstützen Theme-Themenfamilie und DÜRFEN KEINE der folgenden Attribute des Materialdesigns oder deren Assets für Anwendungen zugänglich sind.
  • [C-1-3] MUSS entweder "sans-serif" Schriftfamilie zu Roboto Version 2.x für die Sprachen die Roboto unterstützt, oder bieten Nutzern die Möglichkeit, die verwendete Schriftart für „sans-serif“ Schriftfamilie auf Roboto Version 2.x für die Sprachen, die von Roboto unterstützt werden.

  • [C-1-4] MÜSSEN dynamische Farbtonpaletten gemäß AOSP generieren. Dokumentation von Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (siehe android.theme.customization.system_palette und android.theme.customization.theme_style.

  • [C-1-5] MÜSSEN dynamische Farbtonpaletten mithilfe von Farbdesignstilen generieren. in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES aufgezählt Dokumentation (siehe android.theme.customization.theme_styles), nämlich TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD und MONOCHROMATIC.

    „Quellfarbe“ zum Generieren dynamischer Farbtonpaletten beim Senden mit android.theme.customization.system_palette (wie in den Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

  • [C-1-6] MUSS einen CAM16-Chromawert von 5 oder höher haben.

    • SOLLTE vom Hintergrund über com.android.systemui.monet.ColorScheme#getSeedColors bietet mehrere gültige Quellfarben zur Auswahl stehen.

    • SOLLTEN Sie den Wert 0xFF1B6EF3 verwenden, wenn keine der angegebenen Farben Anforderung an die Quellfarbe erfüllt.

Android umfasst auch eine „Gerätestandard“- Designfamilie als eine Reihe definierter Stile für Anwendungsentwickler, die das Design an das Design Gerätedesign entsprechend der Definition der Geräteimplementierung.

Android unterstützt ein Variantendesign mit durchscheinenden Systemleisten, Anwendungsentwicklern den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten. Damit Entwickler in dieser Phase Konfiguration ist es wichtig, dass der Stil der Statusleistensymbole unterschiedliche Geräteimplementierungen.

Wenn Geräteimplementierungen eine Systemstatusleiste enthalten, gilt Folgendes:

  • [C-2-1] MUSS Weiß für Systemstatussymbole (wie Signalstärke und Akkuladestand) und vom System ausgegebene Benachrichtigungen, es sei denn, das Symbol weist auf einen problematischen Status hin oder eine App fordert eine helle Statusleiste mithilfe von WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS melden.
  • [C-2-2] Bei Android-Geräten MÜSSEN die Systemfarbe geändert werden werden Statussymbole schwarz dargestellt (weitere Informationen finden Sie unter R.style), wenn eine App fordert eine LED-Statusleiste an.

3.8.7 Live-Hintergründe

Android definiert einen Komponententyp sowie eine entsprechende API und einen entsprechenden Lebenszyklus, Anwendungen, um eine oder mehrere „Live-Hintergründe“ für die Endanwendenden. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabemöglichkeiten, die als Hintergrund, hinter anderen Anwendungen.

Hardware wird als in der Lage angesehen, Live-Hintergründe zuverlässig auszuführen, wenn sie alle Live-Hintergründe ohne Einschränkung der Funktionalität in einem angemessenen Frame ohne negative Auswirkungen auf andere Anwendungen. Wenn Einschränkungen in der Hardware verursachen, die Hintergründe und/oder Anwendungen abstürzen, nicht ordnungsgemäß funktionieren, zu viel CPU- oder Akkuleistung oder mit inakzeptablen niedrigen Frame-Rates läuft, wird davon ausgegangen, dass auf Hardware keine Live-Hintergründe ausgeführt werden können. Zum Beispiel haben einige Live-Hintergründe können zur Darstellung ihrer Inhalte einen OpenGL 2.0- oder 3.x-Kontext verwenden. Live-Hintergrund funktioniert nicht zuverlässig auf Hardware, die nicht mehrere OpenGL-Kontexte, da die Verwendung eines OpenGL-Kontextes bei der Live-Hintergrundnutzung zu Konflikten führen kann mit anderen Anwendungen, die ebenfalls einen OpenGL-Kontext nutzen.

  • Geräteimplementierungen, die Live-Hintergründe zuverlässig ausführen können (siehe Beschreibung) SOLLTEN Live-Hintergründe implementieren.

Wenn Live-Hintergründe auf Geräten implementiert sind, gilt Folgendes:

  • [C-1-1] MÜSSEN das Funktions-Flag „android.software.live_wallpaper“ der Plattform melden.

3.8.8. Wechseln zwischen Aktivitäten

Der vorgelagerte Android-Quellcode enthält die Übersichtsbildschirm angezeigt, ein Benutzeroberfläche auf Systemebene zum Wechseln zwischen Aufgaben und Anzeigen der zuletzt aufgerufenen Aktivitäten und Aufgaben mithilfe einer Miniaturansicht der grafischen zu dem Zeitpunkt, zu dem der Nutzer die App das letzte Mal verlassen hat.

Geräteimplementierungen einschließlich der Navigationstaste für die Funktion „Recents“, wie in den Abschnitt 7.2.3 KÖNNEN die Schnittstelle verändern.

Bei Geräteimplementierungen mit der Navigationstaste für die Funktion „Recents“ wie in den Abschnitt 7.2.3 ändert die Benutzeroberfläche, sie:

  • [C-1-1] MUSS mindestens bis zu sieben angezeigte Aktivitäten unterstützen.
  • SOLLTE mindestens den Titel von vier Aktivitäten gleichzeitig anzeigen.
  • SOLLTEN unter „Letzte“ die Farbe, das Symbol und den Bildschirmtitel hervorheben.
  • SOLLTE ein abschließendes Angebot („x“) angezeigt werden, aber KANN die Anzeige verzögern, bis der Nutzer mit den Bildschirmen interagiert.
  • SOLLTEN Sie eine Verknüpfung implementieren, um einfach zur vorherigen Aktivität zu wechseln.
  • SOLLTE ein schneller Wechsel zwischen den beiden zuletzt verwendeten Apps, wenn zweimal auf die Funktionstaste „Letzte Apps“ getippt wird.
  • SOLLTE den Splitscreen-Mehrfenstermodus auslösen, sofern unterstützt, wenn das langes Drücken der letzten Funktionstaste
  • KANN verbundene zuletzt verwendete Elemente als Gruppe angezeigt werden, die zusammen verschoben wird.
  • [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die vorgelagerten Android-Nutzer zu verwenden (oder eine ähnliche Miniaturansicht-basierte Oberfläche) für den Übersichtsbildschirm.

3.8.9. Eingabeverwaltung

Android unterstützt Eingabeverwaltung und Unterstützung für Eingabemethoden-Editoren von Drittanbietern.

Wenn die Geräteimplementierung den Nutzern die Verwendung von Drittanbieter-Eingabemethoden auf der Gerät:

  • [C-1-1] MÜSSEN die Plattformfunktion android.software.input_methods und unterstützen IME APIs wie in der Android SDK-Dokumentation definiert.

3.8.10 Mediensteuerung auf dem Sperrbildschirm

Die Remote Control Client API wird von Android 5.0 zugunsten der Medienbenachrichtigungsvorlage mit der Medien-Apps in die Wiedergabesteuerung integriert werden können, auf dem Sperrbildschirm angezeigt.

3.8.11 Bildschirmschoner (früher „Dreams“)

Einstellungen finden Sie in Abschnitt 3.2.3.5. Bildschirmschoner konfigurieren.

3.8.12. Standort

Wenn die Geräteimplementierung einen kompatiblen Hardwaresensor (z.B. GPS) umfasst Standortkoordinaten angegeben werden,

3.8.13. Unicode und Schriftart

Android unterstützt die Emoji-Zeichen in den Unicode 10.0.

Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:

  • [C-1-1] MUSS diese Emoji-Zeichen in Farbglyphen rendern können.
  • [C-1-2] MÜSSEN folgende unterstützen: <ph type="x-smartling-placeholder">
      </ph>
    • Roboto 2-Schriftart mit unterschiedlichen Schriftstärken: sans-serif-thin, sans-serif-light, serif-medium, sans-serif-black, sans-serif-kondensed, Sans Serif-Condensed-light für die auf dem Gerät verfügbaren Sprachen.
    • Vollständige Unicode 7.0-Abdeckung für Latein, Griechisch und Kyrillisch, einschließlich der Erweiterte A-, B-, C- und D-Bereiche des lateinischen Alphabets sowie alle Glyphen in der Währung Unicode 7.0-Symbolblock.
  • [C-1-3] DARF KEINE NotoColorEmoji.tff aus dem System-Image entfernen oder verändern. (Es ist zulässig, eine neue Emoji-Schriftart hinzuzufügen, um Emojis in NotoColorEmoji.tff)
  • SOLLTEN den Hautton und die verschiedenen Familien-Emojis gemäß den Angaben in den Unicode Technical Report Nr. 51

Wenn Geräteimplementierungen einen IME enthalten, gilt Folgendes:

  • SOLLTE dem Nutzer eine Eingabemethode für diese Emoji-Zeichen zur Verfügung stellen.

Android unterstützt das Rendern von myanmarischen Schriftarten. Myanmar hat mehrere nicht-Unicode-kompatible Schriftarten, bekannt als Zawgyi, verwenden, für das Rendern von Myanmar Sprachen.

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

  • [C-2-1] Text muss standardmäßig mit Unicode-konformer Schriftart dargestellt werden. Nicht-Unicode-konforme Schriftart DARF NICHT als Standardschriftart festgelegt werden, es sei denn, der Nutzer in der Sprachauswahl aus.
  • [C-2-2] MUSS eine Unicode-Schriftart und eine nicht-Unicode-konforme Schriftart unterstützen, wenn ein Nicht-Unicode-konforme Schriftart wird auf dem Gerät unterstützt. Nicht-Unicode konforme Schriftart darf die Unicode-Schriftart NICHT entfernen oder überschreiben.
  • [C-2-3] Text in nicht Unicode-konformer Schriftart NUR WENN a Sprachcode mit Skriptcode Qaag angegeben ist (z.B. my-Qaag). Keine anderen ISO-Sprach- oder Regionscodes (ob „zugewiesen“, „nicht zugewiesen“ oder „reserviert“) können für Nicht-Unicode-Zeichen verwendet werden. Schriftart für Myanmar. App-Entwickler und Webseiten-Autoren können Geben Sie my-Qaag genau wie bei jedem anderen Anbieter als Sprachcode an. in einer anderen Sprache.

3.8.14. Mehrere Fenster

Wenn Geräteimplementierungen die Möglichkeit haben, mehrere Aktivitäten auf gleichzeitig geschieht Folgendes:

  • [C-1-1] MÜSSEN derartige Mehrfenstermodi gemäß den Anwendungsverhalten und APIs, die im Android SDK beschrieben sind Dokumentation zum Mehrfenstermodus und erfüllen die folgenden Anforderungen erfüllen:
  • [C-1-2] MUSS android:resizeableActivity anerkennen der von einer App in der Datei AndroidManifest.xml festgelegt wird, wie unter diesem SDK.
  • [C-1-3] DÜRFEN KEINEN Splitscreen- oder Freiformmodus anbieten, wenn Die Bildschirmhöhe liegt unter 440 dp und die Bildschirmbreite unter 440 dp. dp.
  • [C-1-4] Die Größe einer Aktivität DARF NICHT auf eine Größe unter 220 dp im anderen Mehrfenstermodus als „Bild im Bild“ verwenden.
  • Geräteimplementierungen mit einer Bildschirmgröße von xlarge SOLLTEN freies Format unterstützen .

Ob Geräteimplementierungen den Mehrfenstermodus unterstützen und der Splitscreen-Modus haben sie folgende Möglichkeiten:

  • [C-2-2] MUSS die angedockte Aktivität bei einem Mehrfenstermodus mit geteiltem Bildschirm zuschneiden, aber SOLLTE einige Inhalte davon zu sehen sein, wenn die Launcher-App das Fenster im Fokus ist.
  • [C-2-3] MUSS die deklarierten AndroidManifestLayout_minWidth einhalten und AndroidManifestLayout_minHeight Werte der Drittanbieter-Launcher-App und überschreiben diese Werte nicht während einige Inhalte der angedockten Aktivität gezeigt werden.

Wenn Geräteimplementierungen den Mehrfenstermodus und die Funktion „Bild im Bild“ unterstützen Mehrfenstermodus aktivieren, werden sie:

  • [C-3-1] MÜSSEN Aktivitäten im Bild-im-Bild-Mehrfenstermodus gestartet werden wenn die App: * Ausrichtung auf API-Level 26 oder höher und deklariert android:supportsPictureInPicture * Ausrichtung auf API-Level 25 oder niedriger und deklariert android:resizeableActivity und android:supportsPictureInPicture.
  • [C-3-2] MÜSSEN die Aktionen in der System-UI als angegeben durch die aktuelle PIP-Aktivität durch die setActions() der API erstellen.
  • [C-3-3] MUSS Seitenverhältnisse größer oder gleich 1:2,39 und kleiner oder gleich 2,39:1, wie von der PIP-Aktivität durch setAspectRatio() der API erstellen.
  • [C-3-4] MUSS KeyEvent.KEYCODE_WINDOW verwenden um das BiB-Fenster zu steuern. Ist der BiB-Modus nicht implementiert, MUSS der Schlüssel die für die Vordergrundaktivität verfügbar sind.
  • [C-3-5] MÜSSEN Nutzern die Möglichkeit bieten, das Anzeigen einer App in BiB-Modus; erfüllt die AOSP-Implementierung diese Anforderung in der Benachrichtigungsleiste.
  • [C-3-6] MÜSSEN der BiB-Anzeige die folgende Mindestbreite und -höhe zuweisen wenn in einer Anwendung kein Wert für AndroidManifestLayout_minWidth und AndroidManifestLayout_minHeight:

    • Geräte mit dem Configuration.uiMode, der nicht festgelegt ist UI_MODE_TYPE_TELEVISION MÜSSEN eine Mindestbreite und -höhe von 108 dp zugewiesen werden.
    • Geräte mit dem Parameter „Configuration.uiMode“, der auf UI_MODE_TYPE_TELEVISION MÜSSEN eine Mindestbreite von 240 dp und eine Mindesthöhe von 135 dp zugewiesen werden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräteimplementierungen mehr als eine Android-kompatible Flächen anzeigen und diese für Apps zur Verfügung stellen, geschieht Folgendes:

  • [C-4-1] MUSS den Mehrfenstermodus unterstützen.

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

  • [C-5-1] MÜSSEN die richtige Version der Fenstermanager-Erweiterungen implementieren. API-Ebene beschrieben in WindowManager Erweiterungen.

Neue Anforderungen beenden

3.8.15. Display-Aussparung

Android unterstützt eine Display-Aussparung, wie beschrieben im SDK-Dokument. Mit der DisplayCutout API wird Einen Bereich am Rand des Displays, der möglicherweise nicht für eine App geeignet ist Display-Aussparung oder gewölbtes Display an den Rändern.

Wenn Geräteimplementierungen Display-Aussparungen enthalten, gilt Folgendes:

  • [C-1-5] DÜRFEN KEINE Aussparungen haben, wenn das Seitenverhältnis des Geräts 1,0 (1:1) beträgt.
  • [C-1-2] DÜRFEN NICHT mehr als eine Aussparung pro Rand haben.
  • [C-1-3] MÜSSEN die in der App festgelegten Flags für Display-Aussparungen WindowManager.LayoutParams API wie im SDK beschrieben.
  • [C-1-4] MÜSSEN korrekte Werte für alle in der DisplayCutout API

3.8.16. Gerätesteuerung

Android enthält ControlsProviderService und Control APIs, mit denen Drittanbieter-Apps Gerätesteuerungen schnell veröffentlichen können und Aktionen für Nutzende.

Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2_2_3.

3.8.17. Zwischenablage

Geräteimplementierungen:

  • [C-0-1] DÜRFEN KEINE Daten aus der Zwischenablage an eine Komponente, eine Aktivität, einen Dienst oder ohne explizite Nutzeraktion (z.B. das Drücken einer Schaltfläche im Overlay), mit Ausnahme der Dienste, die in den 9.8.6 Erfassung von Inhalten und App-Suche.

Wenn Geräteimplementierungen eine für den Nutzer sichtbare Vorschau beim Kopieren von Inhalten generieren in die Zwischenablage für jedes ClipData-Element, bei dem ClipData.getDescription().getExtras() enthält android.content.extra.IS_SENSITIVE, sie:

  • [C-1-1] MUSS die sichtbare Vorschau des Nutzers entfernen.

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

3.9. Geräteverwaltung

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Android umfasst Funktionen, die sicherheitsbewusste Apps aktivieren Device Policy Controller-Anwendungen, Geräteverwaltungsfunktionen auf Systemebene, z. B. das Erzwingen von Passwörtern oder eine Remote-Löschung durchführen, Android Device Administration API Device Policy Manager APIs

<ph type="x-smartling-placeholder"></ph> Wenn Geräteimplementierungen die gesamte Palette der Geräteverwaltung implementieren die in der Android SDK-Dokumentation definiert sind,

  • [C-1-1] MUSS android.software.device_admin deklarieren.
  • [C-1-2] MÜSSEN die Bereitstellung von Geräteinhabern unterstützen, wie in den Abschnitt 3.9.1 und Abschnitt 3.9.1.1.

Neue Anforderungen beenden

3.9.1 Gerätebereitstellung

3.9.1.1 Nutzerverwaltung für Geräteinhaber

Wenn in Geräteimplementierungen android.software.device_admin deklariert wird, gilt Folgendes:

  • [C-1-1] MUSS die Registrierung eines Device Policy-Clients (DPC) als App „Geräteinhaber“ wie unten beschrieben: <ph type="x-smartling-placeholder">
      </ph>
    • Wenn bei der Geräteimplementierung weder Nutzer noch konfiguriert sind, geschieht Folgendes: <ph type="x-smartling-placeholder">
        </ph>
      • [C-1-5] MÜSSEN die DPC-Anwendung als Geräteinhaber-App registrieren oder aktivieren Sie die DPC-App, um Geräteinhaber oder Profilinhaber werden, wenn das Gerät NFC-Unterstützung (Nahfeldkommunikation) über das Funktions-Flag android.hardware.nfc und empfängt eine NFC-Nachricht. Enthält einen Datensatz mit einem MIME-Typ MIME_TYPE_PROVISIONING_NFC
      • [C-1-8] MUSS die ACTION_GET_PROVISIONING_MODE senden Intent nach der Auslösung der Bereitstellung des Geräteeigentümers, Die DPC-App kann auswählen, ob sie Geräteinhaber oder Profil werden soll Inhaber, abhängig von den Werten android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, es sei denn, es lässt sich anhand dass es nur eine gültige Option gibt.
      • [C-1-9] MÜSSEN die ACTION_ADMIN_POLICY_COMPLIANCE Intent an die App „Geräteinhaber“, wenn ein Geräteinhaber eingerichtet wird während der Bereitstellung, unabhängig von der verwendeten Bereitstellungsmethode. Die Nutzer darf den Einrichtungsassistenten erst verwenden, Die App „Geräteinhaber“ ist fertig.
    • Wenn bei der Geräteimplementierung oder Nutzerdaten verwenden können, werden: <ph type="x-smartling-placeholder">
        </ph>
      • [C-1-7] DARF keine DPC-Anwendung als Geräteinhaber-App registrieren noch mehr.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-2] MUSS einen entsprechenden Offenlegungshinweis anzeigen (wie in AOSP angegeben) und vor der Veröffentlichung der App die Einwilligung des Endnutzers einholen. als Geräteinhaber festgelegt, es sei denn, das Gerät wurde programmatisch konfiguriert für den Demomodus für den Einzelhandel vor der Endnutzerinteraktion auf dem Bildschirm. Wenn in der Geräteimplementierung android.software.device_admin deklariert ist, aber auch gehören eine proprietäre und bieten einen Mechanismus, eine in der Lösung konfigurierte Anwendung als „Geräteinhaber“ hochstufen Äquivalent“ den standardmäßigen „Geräteinhaber“ wie sie vom standardmäßigen Android- DevicePolicyManager APIs:

  • [C-2-1] MÜSSEN über einen Prozess verfügen, mit dem geprüft wird, ob die betreffende App der beworben wird, gehört zu einer legitimen Unternehmensgeräteverwaltung. -Lösung und wurde in der proprietären Lösung konfiguriert. um die entsprechenden Rechte als Geräteinhaber zu haben.

  • [C-2-2] MUSS dieselbe Offenlegung zur Einwilligung des AOSP-Geräteinhabers anzeigen wie in Vorgang initiiert von android.app.action.PROVISION_MANAGED_DEVICE bevor Sie die DPC-Anwendung als "Geräteinhaber" registrieren.

  • [C-2-3] DÜRFEN die Einwilligung NICHT hartcodieren oder verhindern, die Nutzung anderer Apps von Geräteeigentümern.

Neue Anforderungen beenden

3.9.1.2 Bereitstellung verwalteter Profile

Wenn in Geräteimplementierungen android.software.managed_users deklariert wird, gilt Folgendes:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-2] Der Bereitstellungsprozess für verwaltete Profile, also der vom DPC mithilfe der android.app.action.PROVISION_MANAGED_PROFILE) oder der Plattform), der Zustimmungsbildschirm und die Nutzererfahrung MÜSSEN mit den der AOSP-Implementierung.

Neue Anforderungen beenden

  • [C-1-3] MÜSSEN die folgenden Nutzereigenschaften in den Einstellungen dem Nutzer anzeigen, wenn eine bestimmte Systemfunktion durch Device Policy Controller (DPC):

    • Ein einheitliches Symbol oder ein anderes Angebot für Nutzer (zum Beispiel das vorgelagerte Angebot) AOSP-Infosymbol), um anzuzeigen, dass eine bestimmte Einstellung durch ein Device Admin.
    • Eine kurze Erklärung, die vom Device Admin über die setShortSupportMessage
    • Das Symbol der DPC-Anwendung.
  • [C-1-4] MÜSSEN den Handler für ACTION_PROVISIONING_SUCCESSFUL starten. im Arbeitsprofil, wenn ein Profilinhaber festgelegt wird, Die Bereitstellung wird durch android.app.action.PROVISION_MANAGED_PROFILE eingeleitet und der DPC hat den Handler implementiert.

  • [C-1-5] MUSS ACTION_PROFILE_PROVISIONING_COMPLETE gesendet werden an den DPC des Arbeitsprofils übertragen, wenn die Bereitstellung vom android.app.action.PROVISION_MANAGED_PROFILE die Nutzerabsicht verstehen.

  • [C-1-6] MÜSSEN die ACTION_GET_PROVISIONING_MODE senden Intent nach Auslösung der DPC-App-Bereitstellung des Profilinhabers. können festlegen, ob sie Geräteinhaber oder Profilinhaber werden möchten, es sei denn, Die Bereitstellung wird durch den Intent android.app.action.PROVISION_MANAGED_PROFILE ausgelöst.

  • [C-1-7] MUSS die ACTION_ADMIN_POLICY_COMPLIANCE senden Intent für das Arbeitsprofil, wenn während unabhängig von der verwendeten Bereitstellungsmethode, ausgenommen wenn die Bereitstellung durch den Intent android.app.action.PROVISION_MANAGED_PROFILE ausgelöst wird. Der Nutzer darf den Einrichtungsassistenten erst verwenden, wenn das Profil Inhaber-App beendet.

  • [C-1-8] MUSS ACTION_MANAGED_PROFILE_PROVISIONED senden an den privaten Profil-DPC übertragen, wenn ein Profilinhaber eingerichtet wird, unabhängig von der verwendeten Bereitstellungsmethode.

3.9.2 Unterstützung für verwaltete Profile

Wenn in Geräteimplementierungen android.software.managed_users deklariert wird, gilt Folgendes:

  • [C-1-1] MUSS verwaltete Profile über die android.app.admin.DevicePolicyManager unterstützen APIs
  • [C-1-2] MUSS die Erstellung nur eines einzigen verwalteten Profils zulassen.
  • [C-1-3] MUSS ein Symbol (ähnlich dem AOSP-Upstream-Arbeitsabzeichen) verwenden, um die verwalteten Anwendungen und Widgets und andere gekennzeichnete UI-Elemente darstellen, wie Recents und Benachrichtigungen.
  • [C-1-4] MÜSSEN ein Benachrichtigungssymbol anzeigen (ähnlich der AOSP-Upstream-Arbeit). ) angezeigt, wenn sich der Nutzer in einer Anwendung mit einem verwalteten Profil befindet.
  • [C-1-5] MÜSSEN ein Toast anzeigen, der darauf hinweist, dass sich der Nutzer im verwalteten Konto befindet. wenn das Gerät aktiviert wird (ACTION_USER_PRESENT) und die Die Anwendung im Vordergrund befindet sich im verwalteten Profil.
  • [C-1-6] Wenn ein verwaltetes Profil vorhanden ist, MUSS im Intent-Auswahl damit der Nutzer den Intent aus dem verwalteten Bereich an den Hauptnutzer oder umgekehrt, wenn diese Funktion über die Device Policy aktiviert wurde. Controller.
  • [C-1-7] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN die folgenden Nutzer angezeigt werden Angebote für den Hauptnutzer und das verwaltete Profil: <ph type="x-smartling-placeholder">
      </ph>
    • Separate Berechnung von Akku-, Standort-, mobiler Daten- und Speichernutzung für den Hauptnutzer und das verwaltete Profil.
    • Unabhängige Verwaltung von VPN-Anwendungen, die in der primären Instanz installiert sind Nutzer- oder verwalteten Profils.
    • Unabhängige Verwaltung von Anwendungen, die innerhalb des Hauptnutzers installiert sind oder einem verwalteten Profil.
    • Unabhängige Verwaltung von Konten innerhalb des primären Nutzers oder verwalteten Konten zu erstellen.
  • [C-1-8] MÜSSEN sicherstellen, dass Telefon, Kontakte und Messaging vorinstalliert sind. können Anruferinformationen in den verwalteten Apps (sofern vorhanden) zusätzlich zum primären Profil, wenn das Device Policy Controller lässt dies zu.
  • [C-1-9] MÜSSEN sicherstellen, dass alle Sicherheitsanforderungen erfüllt werden. gilt für ein Gerät mit mehreren aktivierten Nutzern (siehe Abschnitt 9.5), auch wenn das verwaltete Profil wird nicht zusätzlich zum primären Nutzer als weiterer Nutzer gezählt.
  • [C-1-10] MÜSSEN sicherstellen, dass die Screenshot-Daten im Arbeitsprofil gespeichert sind. wenn ein Screenshot mit einem topActivity Fenster mit Fokus (der der Nutzer zuletzt unter allen Aktivitäten interagiert hat) und zu dem er gehört eine Arbeitsprofil-App.
  • [C-1-11] DÜRFEN KEINE anderen Bildschirminhalte (Systemleiste, Benachrichtigungen oder Inhalte im privaten Profil), mit Ausnahme des Arbeitsprofils Fenster/Fenster der Anwendung wenn Sie einen Screenshot im Arbeitsprofil speichern. Profildaten nicht im Arbeitsprofil gespeichert werden.

Wenn in der Geräteimplementierung android.software.managed_users und android.software.secure_lock_screen:

  • [C-2-1] MUSS die Möglichkeit unterstützen, eine separate Besprechung auf dem Sperrbildschirm anzugeben. die folgenden Anforderungen, um Zugriff auf Apps zu gewähren, die in einer verwalteten
    • Geräteimplementierungen MÜSSEN die DevicePolicyManager.ACTION_SET_NEW_PASSWORD Intent angezeigt und eine Benutzeroberfläche zum Konfigurieren eines separaten Sperrbildschirms angezeigt werden. Anmeldedaten für das verwaltete Profil.
    • Die Anmeldedaten für den Sperrbildschirm des verwalteten Profils MÜSSEN dieselben die Mechanismen zum Speichern und Verwalten von Anmeldedaten als übergeordnetes Profil. wie auf der Website des Open-Source-Projekts von Android.
    • DPC-Passwortrichtlinien MUSS sich nur auf die Anmeldedaten für den Sperrbildschirm des verwalteten Profils beziehen, es sei denn, für die DevicePolicyManager-Instanz aufgerufen, die von getParentProfileInstance
  • Wenn Kontakte aus dem verwalteten Profil angezeigt werden in der vorinstallierten Anrufliste, auf der Benutzeroberfläche für laufende Anrufe, in Bearbeitung und verpassten Anrufen Benachrichtigungen, Kontakte und Messaging-Apps, SOLLTEN sie mit dem Symbol Badge, das auch für Anwendungen mit verwalteten Profilen verwendet wird.

3.9.3 Support für verwaltete Nutzer

Wenn in Geräteimplementierungen android.software.managed_users deklariert wird, gilt Folgendes:

  • [C-1-1] MÜSSEN Nutzern die Möglichkeit bieten, sich vom aktuellen Nutzer abzumelden und wechseln Sie in einer Sitzung mit mehreren Nutzern zurück zum primären Nutzer, isLogoutEnabled gibt true zurück. Das Nutzerangebot MUSS über den Sperrbildschirm zugänglich sein. ohne das Gerät zu entsperren.

Wenn in der Geräteimplementierung android.software.device_admin deklariert ist und Möglichkeit für Nutzer auf dem Gerät, zusätzliche sekundäre Nutzer hinzuzufügen, die sie:

  • [C-SR-1] WIRD DRINGEND EMPFOHLEN, die gleiche Einwilligung des AOSP-Geräteinhabers zu zeigen Offenlegungen angezeigt, die während des android.app.action.PROVISION_MANAGED_DEVICE bevor das Hinzufügen von Konten im neuen sekundären Nutzer zugelassen wird, damit Nutzer erkennen, dass das Gerät verwaltet wird.

3.9.4. Rollenanforderungen für die Device Policy Management-Rolle

Wenn Geräteimplementierungen android.software.device_admin oder android.software.managed_users:

  • [C-1-1] MUSS die Rolle zur Verwaltung von Geräterichtlinien gemäß der Definition in Abschnitt 9.1. Die Anwendung, die die Rolle zur Verwaltung von Geräterichtlinien hat KANN definiert werden, indem config_devicePolicyManagement auf den Paketnamen festgelegt wird. Auf den Paketnamen MÜSSEN : und das Signaturzertifikat folgen, es sei denn, die Anwendung ist vorab geladen.

Wenn für config_devicePolicyManagement kein Paketname als wie oben beschrieben:

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

  • [C-3-1] Die App MUSS auf allen Geräten installiert werden, Profile für einen Nutzer.
  • [C-3-2] Geräteimplementierungen KÖNNEN eine Anwendung definieren, die die Rolleninhaber für die Verwaltung von Geräterichtlinien vor der Bereitstellung durch Einstellung config_devicePolicyManagementUpdater

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

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

3.9.5 Framework zur Auflösung von Geräterichtlinien

Wenn Geräteimplementierungen android.software.device_admin oder android.software.managed_users:

3:10. Bedienungshilfen

Android bietet eine Ebene der Bedienungshilfen, über die Nutzer mit Beeinträchtigungen einfacher zu bedienen. Außerdem bietet Android Plattform-APIs die es Bedienungshilfen ermöglichen, Callbacks für Nutzer zu empfangen. und Systemereignisse zu identifizieren und alternative Feedbackmechanismen zu generieren, z. B. Sprachausgabe, haptisches Feedback und Navigation per Trackball oder Steuerkreuz

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

  • [C-1-1] MÜSSEN eine Implementierung der Android-Bedienungshilfen wie in den Bedienungshilfen-APIs SDK-Dokumentation
  • [C-1-2] MÜSSEN Bedienungshilfen-Ereignisse generieren und die AccessibilityEvent an alle registrierten AccessibilityService Implementierung, wie im SDK dokumentiert.
  • [C-1-4] MÜSSEN ein Nutzerangebot zur Steuerung der Barrierefreiheit bieten. die die AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_button. Bei Geräteimplementierungen mit einer Systemnavigationsleiste SOLLTE dem Nutzer die Option für eine Schaltfläche im System Navigationsleiste verwenden, um diese Dienste zu steuern.

Wenn Geräteimplementierungen vorinstallierte Bedienungshilfen enthalten, gilt Folgendes:

  • [C-2-1] MÜSSEN diese vorinstallierten Bedienungshilfen so implementieren, Direct Boot Aware Apps, wenn der Datenspeicher per File-Based Encryption (FBE) verschlüsselt ist.
  • SOLLTEN in der vorkonfigurierten Einrichtung einen Mechanismus bereitstellen, mit dem Nutzer relevante Bedienungshilfen sowie Optionen zur Anpassung der Schriftgröße, Anzeigegröße und Vergrößerungsbewegungen.

3:11. Sprachausgabe

Android umfasst APIs, mit denen Anwendungen die Sprachausgabe verwenden können Dienste für die Sprachausgabe, die es Dienstanbietern ermöglichen, die Text-in-Sprache-Funktion implementieren zu können .

Wenn Geräteimplementierungen die Funktion „android.hardware.audio.output“ melden, Sie:

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

  • [C-2-1] MÜSSEN Nutzern Angebote machen, damit sie eine Sprachausgabe auswählen können. zur Verwendung auf Systemebene.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

3:12. TV-Eingabe-Framework

Das Android Television Input Framework (TIF) vereinfacht die Bereitstellung von Live-Inhalten an Android-Fernsehgeräte TIF stellt eine Standard- API zum Erstellen von Eingabemodulen, die Android TV-Geräte steuern

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

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

Neue Anforderungen beenden

3:13. Schnelleinstellungen

Android bietet eine UI-Komponente für die Schnelleinstellungen, mit der Sie schnell auf häufig genutzte oder dringend benötigte Maßnahmen.

Wenn Geräteimplementierungen eine UI-Komponente für Schnelleinstellungen enthalten und einen Drittanbieter unterstützen Über die Schnelleinstellungen können Sie Folgendes tun:

  • [C-1-1] MÜSSEN Nutzer die über die quicksettings APIs einer Drittanbieter-App
  • [C-1-2] DÜRFEN KEINE Kacheln direkt direkt aus einer Drittanbieter-App hinzufügen zu den Schnelleinstellungen.
  • [C-1-3] MÜSSEN alle vom Nutzer hinzugefügten Kacheln aus Drittanbieter-Apps angezeigt werden neben den vom System bereitgestellten Kacheln für die Schnelleinstellungen.

3:14. Medien-UI

Wenn Geräteimplementierungen Apps umfassen, die nicht sprachgesteuert sind (die Apps), die mit Drittanbieter-Apps über MediaBrowser oder MediaSession, der Apps:

  • [C-1-2] MÜSSEN die über getIconBitmap() oder getIconUri() erhaltenen Symbole und Titel deutlich anzeigen. abgerufen über getTitle(), wie in MediaDescription beschrieben. Titel können zur Einhaltung von Sicherheitsvorschriften gekürzt werden (z.B. Ablenkung des Autofahrers).

  • [C-1-3] MUSS das Symbol für die Drittanbieter-App immer anzeigen, wenn Inhalte angezeigt werden, die von für diese Drittanbieter-App.

  • [C-1-4] MÜSSEN dem Nutzer die Interaktion mit dem gesamten MediaBrowser ermöglichen. Hierarchie. KANN den Zugriff auf einen Teil der Hierarchie einschränken, um Sicherheitsvorschriften einzuhalten. (z. B. Ablenkung des Autofahrers), DARF aber NICHT basierend auf Inhalten oder Inhalten bevorzugt behandelt werden. Contentanbieter.

  • [C-1-5] MUSS doppeltes Antippen von KEYCODE_HEADSETHOOK oder KEYCODE_MEDIA_PLAY_PAUSE als KEYCODE_MEDIA_NEXT für MediaSession.Callback#onMediaButtonEvent.

3:15. Android Instant Apps

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

  • [C-1-1] Instant Apps DÜRFEN nur Berechtigungen gewährt werden, die die android:protectionLevel auf "instant" festgelegt.
  • [C-1-2] Instant Apps DÜRFEN NICHT über implizite Intents mit installierten Apps interagieren es sei denn, eine der folgenden Bedingungen ist erfüllt: <ph type="x-smartling-placeholder">
      </ph>
    • Der Intent-Musterfilter der Komponente ist verfügbar und enthält CATEGORY_BROWSABLE
    • Es handelt sich um eine der folgenden Aktionen: ACTION_SEND, ACTION_SENDTO oder ACTION_SEND_MULTIPLE
    • Das Ziel wird explizit mit android:visibleToInstantApps bereitgestellt.
  • [C-1-3] Instant Apps DÜRFEN NICHT explizit mit installierten Apps interagieren, es sei denn, Komponente wird über android:visibleToInstantApps bereitgestellt.
  • [C-1-4] Installierte Apps DÜRFEN KEINE Details zu Instant Apps auf der Gerät, es sei denn, die Instant App stellt explizit eine Verbindung installierte Anwendung.
  • Geräteimplementierungen MÜSSEN die folgenden Nutzerangebote für mit Instant Apps interagieren. Der AOSP erfüllt die Anforderungen mit der Standard-System-UI, Einstellungen und Launcher. Geräteimplementierungen:

    • [C-1-5] MÜSSEN Nutzern die Möglichkeit bieten, Instant Apps aufzurufen und zu löschen. für jedes einzelne App-Paket im lokalen Cache gespeichert.
    • [C-1-6] MÜSSEN eine dauerhafte Nutzerbenachrichtigung bereitstellen, die minimiert werden, während eine Instant-App im Vordergrund ausgeführt wird. Dieser Nutzer Benachrichtigung MUSS enthalten, dass Instant Apps keine Installation erfordern und ihnen Angebote bieten, die sie zur App weiterleiten. Infobildschirm in den Einstellungen. Bei Instant Apps, die über Web Intents gestartet werden, wie definiert durch einen Intent, dessen Aktion auf Intent.ACTION_VIEW festgelegt ist, und mit dem Schema "http" oder „https“, eine zusätzliche Angebotsmöglichkeit für Nutzer, SOLLTE dem Nutzer erlauben, die Instant App nicht zu starten und startet den zugehörigen Link mit dem konfigurierten Webbrowser, falls ein Browser auf dem Gerät verfügbar ist.
    • [C-1-7] MÜSSEN den Zugriff auf ausgeführte Instant Apps über die App „Letzte“ erlauben , wenn die Funktion „Zuletzt verwendet“ auf dem Gerät verfügbar ist.
  • [C-1-8] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten vorab laden. mit einem Intent-Handler für die Intents, die hier im SDK aufgeführt sind und die Intents für Instant Apps sichtbar machen.

3:16. Begleitgerät koppeln

Android unterstützt die Kopplung von Begleitgeräten für eine effektivere Verwaltung. Verknüpfung mit Companion-Geräten und bietet die CompanionDeviceManager API für Apps, die auf diese Funktion zugreifen können.

Wenn Geräteimplementierungen die Kopplungsfunktion von Begleitgeräten unterstützen, gilt Folgendes:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-3] MÜSSEN Nutzern Angebote zur Auswahl/Bestätigung bereitgestellt werden. Begleitgerät vorhanden und betriebsbereit ist, die dieselbe Nachricht wie in AOSP implementiert ohne Addition oder Änderung.

Neue Anforderungen beenden

3:17. Komplexe Apps

Wenn in Geräteimplementierungen die Funktion FEATURE_CANT_SAVE_STATE deklariert ist, dann:

  • [C-1-1] DÜRFEN nur eine App installiert haben, die folgende Anforderungen erfüllt: cantSaveState gleichzeitig im System ausgeführt werden. Wenn der Nutzer verlässt eine solche App, ohne sie explizit zu beenden (z. B. durch Drücken von wenn das System eine aktive Aktivität verlässt, anstatt ohne verbleibende aktive Aktivitäten im System), dann Geräteimplementierungen MÜSSEN diese App wie bei anderen Apps im RAM priorisieren. Dinge, die weiterhin ausgeführt werden sollen, z. B. Dienste im Vordergrund. Auch wenn eine solche App im Hintergrund läuft, kann das System trotzdem Strom liefern. z. B. die Begrenzung des CPU- und Netzwerkzugriffs.
  • [C-1-2] MÜSSEN eine UI-Option bereitstellen, mit der die App ausgewählt werden kann, die nicht den normalen Speicher-/Wiederherstellungsmechanismus nutzen, startet eine zweite App, die mit cantSaveState deklariert wurde .
  • [C-1-3] DÜRFEN KEINE anderen Richtlinienänderungen auf Apps anwenden, für die Folgendes angegeben ist: cantSaveState, z. B. die CPU-Leistung oder die Planungspriorisierung ändern.

Wenn die Funktion in der Geräteimplementierung nicht deklariert wird FEATURE_CANT_SAVE_STATE, dann:

  • [C-1-1] MUSS cantSaveState ignorieren. von Apps festgelegt wurde und DÜRFEN das App-Verhalten NICHT basierend auf diesem Attribut ändern. .

3:18. Kontakte

Android umfasst Contacts Provider APIs, mit denen Anwendungen die auf dem Gerät gespeicherten Kontaktdaten verwalten können Direkt in das Gerät eingegebene Kontaktdaten werden in der Regel synchronisiert. mit einem Webdienst verknüpft sein, aber die Daten KÖNNEN auch nur lokal auf dem Gerät gespeichert sein. Kontakte, die nur auf dem Gerät gespeichert sind, werden als lokale Kontakte.

Rohkontakte „verknüpft mit“ oder „gespeichert in“ eine Konto wenn das Ereignis ACCOUNT_NAME, und ACCOUNT_TYPE Spalten für die unverarbeiteten Kontakte mit den entsprechenden Konto.name und Kontotyp des Kontos.

Lokales Standardkonto: ein Konto für unformatierte Kontakte, die nur in und nicht mit einem Konto im AccountManager, die mit null-Werten für die ACCOUNT_NAME, und ACCOUNT_TYPE Spalten.

Benutzerdefiniertes lokales Konto: ein Konto für unformatierte Kontakte, die nur auf dem Gerät und nicht mit einem Konto im AccountManager verknüpft ist. Diese können erstellt mit mindestens einem Nicht-Null-Wert für die ACCOUNT_NAME, und ACCOUNT_TYPE Spalten.

Geräteimplementierungen:

  • [C-SR-1] Es wird dringend empfohlen, keine benutzerdefinierten lokalen Konten zu erstellen.

Wenn für Geräteimplementierungen ein benutzerdefiniertes lokales Konto verwendet wird:

  • [C-1-1] Die ACCOUNT_NAME, des benutzerdefinierten lokalen Kontos MÜSSEN von ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] Die ACCOUNT_TYPE, des benutzerdefinierten lokalen Kontos MÜSSEN von ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] Rohkontakte, die von Anwendungen von Drittanbietern mit das lokale Standardkonto (d.h. durch Festlegen von Nullwerten für ACCOUNT_NAME und ACCOUNT_TYPE) MÜSSEN in den benutzerdefinierten lokalen Konto.
  • [C-1-4] Rohkontakte, die in das benutzerdefinierte lokale Konto eingefügt wurden, DÜRFEN nicht sein werden entfernt, wenn Konten hinzugefügt oder entfernt werden.
  • [C-1-5] Löschvorgänge für das benutzerdefinierte lokale Konto MUSS dazu führen, dass unbearbeitete Kontakte sofort dauerhaft gelöscht werden (als CALLER_IS_SYNCADAPTER Parameter auf "true" gesetzt wurde), auch wenn der Parameter CALLER\_IS\_SYNCADAPTER festgelegt wurde. auf „false“ gesetzt oder nicht angegeben.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

3:19. Spracheinstellungen

Geräteimplementierungen:

  • [C-0-1] DÜRFEN KEINE Nutzerangebote zur Auswahl geschlechtsspezifischer Angebote machen. Behandlung von Sprachen, die keine geschlechtsspezifischen Informationen unterstützen Übersetzungen. Grammatikalische Ressourcen .

Neue Anforderungen beenden

4. Kompatibilität der App-Paketerstellung

Implementierungen auf Geräten:

  • [C-0-1] MUSS Android ".apk" installieren und ausführen können Dateien unter generiert von „aapt“ im offiziellen Android SDK.

    • Da die obige Anforderung eine Herausforderung sein kann, werden Geräteimplementierungen EMPFOHLEN, die Paketverwaltung der AOSP-Referenzimplementierung zu verwenden System.
  • [C-0-2] MUSS die Überprüfung von ".apk" unterstützen Dateien mithilfe der APK-Signaturschema v3.1, APK Signature Scheme v3 APK-Signaturschema v2 und JAR-Signatur.

  • [C-0-3] DÜRFEN NICHT die .apk Android-Manifest, Dalvik-Bytecode oder RenderScript-Bytecodeformate so, dass diese Dateien nicht auf anderen kompatiblen Geräten installiert werden kann.

  • [C-0-4] DÜRFEN KEINE anderen Apps als die aktuellen zulassen. „Installer of Record“ damit das Paket die App unbemerkt und ohne Nutzerbestätigung, wie im SDK für den DELETE_PACKAGE Berechtigung. Die einzige Ausnahme ist die App, die die Systempaketprüfung verarbeitet, PAKET_ERFORDERLICH_BESTÄTIGUNG der Intent- und Speichermanager-App, ACTION_MANAGE_STORAGE die Nutzerabsicht verstehen.

  • [C-0-5] MÜSSEN über eine Aktivität verfügen, android.settings.MANAGE_UNKNOWN_APP_SOURCES die Nutzerabsicht verstehen.

  • [C-0-6] DÜRFEN KEINE Anwendungspakete von unbekannten Quellen, es sei denn, die App, die die Installation anfordert alle folgenden Anforderungen erfüllt:

    • Es MÜSSEN die REQUEST_INSTALL_PACKAGES deklariert werden. oder android:targetSdkVersion auf 24 oder niedriger eingestellt haben.
    • Der Nutzer MUSS die Berechtigung erhalten haben, Apps aus unbekannten Quellen.
  • SOLLTEN Sie dem Nutzer die Möglichkeit bieten, Apps aus unbekannten Quellen pro App installieren, aber KANN implementieren als No-Op und geben RESULT_CANCELED für startActivityForResult(), Wenn die Geräteimplementierung den Nutzern diese Auswahl nicht ermöglichen soll. Aber selbst in solchen Fällen SOLLTEN sie dem Nutzer mitteilen, warum eine solche Auswahl.

  • [C-0-7] MÜSSEN ein Warndialogfeld mit der Zeichenfolge für die Warnung über die System-API PackageManager.setHarmfulAppWarning bevor eine Aktivität in einer Anwendung gestartet wird, die als System-API PackageManager.setHarmfulAppWarning als potenziell schädlich ist.

  • SOLLTEN den Nutzern die Möglichkeit bieten, ein Produkt zu deinstallieren oder zu starten. Anwendung im Dialogfeld „Warnung“ angezeigt.

  • [C-0-8] MÜSSEN wie dokumentiert die Unterstützung für inkrementelles Dateisystem implementieren hier.

  • [C-0-9] MUSS die Überprüfung von APK-Dateien mit dem APK Signature Scheme v4 und APK-Signaturschema v4.1.

5. Multimedia-Kompatibilität

Geräteimplementierungen:

  • [C-0-1] MÜSSEN die Medienformate, Encoder, Decoder, Dateitypen sowie Container-Formate, die in Abschnitt 5.1 definiert sind. für jeden von MediaCodecList deklarierten Codec.
  • [C-0-2] MÜSSEN die verfügbaren Encoder und Decoder deklarieren und die Unterstützung dafür melden. Drittanbieteranwendungen über MediaCodecList
  • [C-0-3] MÜSSEN in der Lage sein, ordnungsgemäß zu decodieren und Dritten zur Verfügung zu stellen. alle Formate, die codiert werden können. Dazu gehören alle Bitstreams, die von Encodern generiert werden, und die in den CamcorderProfile

Geräteimplementierungen:

  • SOLLTE eine minimale Codec-Latenz anstreben, <ph type="x-smartling-placeholder">
      </ph>
    • SOLLTEN KEINE Eingabepuffer verbrauchen und speichern und nur Eingabepuffer zurückgeben. nach der Verarbeitung.
    • Decodierte Puffer sollten NICHT länger aufbewahrt werden, als in den Standard (z.B. SPS).
    • Sie sollten codierte Puffer NICHT länger aufbewahren, als von der GoP gefordert. Struktur.

Alle im folgenden Abschnitt aufgeführten Codecs werden als Softwareprogramme bereitgestellt. Implementierungen in der bevorzugten Android-Implementierung aus dem Quellprojekt.

Bitte beachten Sie, dass weder Google noch die Open Handset Alliance Erklärung, dass diese Codecs frei von Patenten Dritter sind. Diese wird empfohlen, diesen Quellcode in Hardware- oder Softwareprodukten zu verwenden. dass Implementierungen dieses Codes, auch in Open-Source-Software oder Shareware erfordern möglicherweise Patentlizenzen von den entsprechenden Patentinhabern.

5.1. Medien-Codecs

5.1.1 Audiocodierung

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

Wenn in der Geräteimplementierung android.hardware.microphone deklariert ist, Sie MÜSSEN die Codierung der folgenden Audioformate unterstützen und bereitstellen. Drittanbieter-Apps:

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

Alle Audioencoder MÜSSEN unterstützen:

  • [C-3-1] 16-Bit-Audioframes für native PCM-Bytereihenfolge in PCM über den android.media.MediaCodec der API erstellen.

5.1.2 Audiodecodierung

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

Wenn in den Geräteimplementierungen die android.hardware.audio.output-Funktion verwenden, müssen sie die Decodierung unterstützen, folgenden Audioformaten verwenden:

  • [C-1-1] MPEG-4 AAC Profile (AAC LC)
  • [C-1-2] MPEG-4 HE AAC-Profil (AAC+)
  • [C-1-3] MPEG-4 HE AACv2 Profile (erweitertes AAC+)
  • [C-1-4] AAC ELD (Optimierte AAC mit niedriger Verzögerung)
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, einschließlich USAC Baseline Profile und ISO/IEC 23003-4 Dynamic Range Einstellungsprofil)
  • [C-1-5] FLAC
  • [C-1-6] MP3-Datei
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE einschließlich hochauflösendem Audio Formate mit bis zu 24 Bit, Abtastrate von 192 kHz und 8 Kanälen. Beachten Sie, dass diese Anforderung nur für die Decodierung gilt und dass ein Gerät während der Wiedergabe ein Downsampling oder Downmix zulassen.
  • [C-1-10] Opus

Wenn Geräteimplementierungen die Decodierung von AAC-Eingabepuffern von Multi-Channel-Streams (d.h. mehr als zwei Kanäle) über die Standardeinstellung zu PCM AAC-Audiodecoder in der android.media.MediaCodec API. Folgendes MÜSSEN sein: unterstützt:

  • [C-2-1] Decodierung MUSS ohne Downmixing durchgeführt werden (z.B. eine 5,0-AAC-Datei). Der Stream muss in fünf PCM-Kanäle decodiert werden, ein 5.1-AAC-Stream muss decodiert werden bis zu sechs Kanäle für PCM).
  • [C-2-2] Die Metadaten für den dynamischen Bereich MÜSSEN der Definition in "Dynamic Range Control" entsprechen. Demokratische Republik Kongo" in ISO/IEC 14496-3 und die android.media.MediaFormat DRC-Schlüssel zur Dynamikumfang-bezogenes Verhalten des Audiodecoders konfigurieren 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 die oben genannten Anforderungen C-2-1 und C-2-2 die von allen AAC-Audiodecoder erfüllt werden.

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

  • [C-3-1] Lautheit und Metadaten im DRC MÜSSEN interpretiert und angewendet werden gemäß MPEG-D DRC Dynamic Range Control Profile Level 1.
  • [C-3-2] Der Decoder MUSS sich wie die Konfiguration verhalten. mit den folgenden android.media.MediaFormat-Schlüsseln festgelegt: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL und KEY_AAC_DRC_EFFECT_TYPE.

MPEG-4 AAC-, HE AAC- und HE AACv2-Profildecoder:

  • KANN die Lautstärke- und Dynamiksteuerung gemäß ISO/IEC 23003-4 unterstützen Profil für Dynamic Range Control.

Wenn ISO/IEC 23003-4 unterstützt wird und sowohl ISO/IEC 23003-4 als auch Metadaten gemäß ISO/IEC 14496-3 sind in einem decodierten Bitstream vorhanden. Dann gilt:

  • ISO/IEC 23003-4-Metadaten WERDEN Vorrang haben.

Alle Audiodecoder müssen die Ausgabe unterstützen:

  • [C-6-1] 16-Bit-Audioframes für native PCM-Bytereihenfolge in PCM über den android.media.MediaCodec der API erstellen.

Wenn Geräteimplementierungen die Decodierung von AAC-Eingabepuffern von Multi-Channel-Streams (d.h. mehr als zwei Kanäle) über die Standardeinstellung zu PCM AAC-Audiodecoder in der android.media.MediaCodec API verwenden MÜSSEN: unterstützt werden:

  • [C-7-1] MUSS in der Lage sein, von der Anwendung mithilfe der Decodierung mit dem Schlüssel KEY_MAX_OUTPUT_CHANNEL_COUNT zur Steuerung, ob der Inhalt auf Stereo heruntergemixt wird (bei Verwendung des Werts 2) oder die Ausgabe erfolgt mit der nativen Anzahl von Channels (bei Verwendung eines Werts gleich oder größer als diese Zahl). Beispiel: Mit einem Wert von 6 oder höher wird einen Decoder für 6 Kanäle, wenn 5.1-Inhalte eingespeist werden.
  • [C-7-2] Beim Decodieren MUSS der Decoder die verwendete Kanalmaske bewerben. zum Ausgabeformat mit dem KEY_CHANNEL_MASK unter Verwendung der android.media.AudioFormat-Konstanten (Beispiel: CHANNEL_OUT_5POINT1)

Wenn Geräteimplementierungen andere Audiodecoder als die Standard-AAC unterstützen Audiodecoder und können mehrkanalige Audiosignale ausgeben (d.h. mehr als 2 Kanälen), wenn komprimierte Inhalte aus mehreren Kanälen zugespeist werden, geschieht Folgendes:

  • [C-SR-2] Der Decoder wird dringend empfohlen, dass er vom Anwendung mit der Decodierung mit dem Schlüssel KEY_MAX_OUTPUT_CHANNEL_COUNT zur Steuerung, ob der Inhalt auf Stereo heruntergemixt wird (bei Verwendung des Werts 2) oder die Ausgabe erfolgt mit der nativen Anzahl von Channels (bei Verwendung eines Werts gleich oder größer als diese Zahl). Beispiel: Mit einem Wert von 6 oder höher wird einen Decoder für 6 Kanäle, wenn 5.1-Inhalte eingespeist werden.
  • [C-SR-3] Beim Decodieren wird der Decodierer UNBEDINGT empfohlen, den Kanalmaske, die für das Ausgabeformat mit dem Parameter KEY_CHANNEL_MASK unter Verwendung der android.media.AudioFormat-Konstanten (Beispiel: CHANNEL_OUT_5POINT1).

5.1.3 Details zu Audio-Codecs

Format/Codec Details Zu unterstützende Dateitypen/Containerformate
MPEG-4 AAC Profile
(AAC LC)
Unterstützung für Mono-/Stereo-/5.0/5.1-Inhalte mit Standardinhalten Abtastraten von 8 bis 48 kHz.
  • 3GPP (3GP)
  • MPEG-4 (MP4, M4A)
  • ADTS-Roh-AAC (AAC, ADIF nicht unterstützt)
  • MPEG-TS (.ts, nicht suchbar, nur decodieren)
  • Matroska (.mkv, nur decodieren)
MPEG-4 HE AAC Profile (AAC+) Unterstützung für Mono-/Stereo-/5.0/5.1-Inhalte mit Standardinhalten Abtastraten 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 Standardinhalten Abtastraten von 16 bis 48 kHz.
  • 3GPP (3GP)
  • MPEG-4 (MP4, M4A)
AAC ELD (Optimierte AAC mit geringer Verzögerung) Unterstützung für Mono-/Stereoinhalte mit Standardabtastraten von 16 bis 48 kHz.
  • 3GPP (3GP)
  • MPEG-4 (MP4, M4A)
Logo: USAC Unterstützung für Mono-/Stereoinhalte mit Standardabtastraten ab 7,35 auf 48 kHz zu reduzieren. MPEG-4 (MP4, M4A)
AMR-NB 4,75 bis 12,2 kbit/s, Stichproben bei 8 kHz 3GPP (3GP)
AMR-WB 9 Raten von 6,60 kbit/s bis 23,85 kbit/s, abgetastet bei 16 kHz, definiert unter <ph type="x-smartling-placeholder"></ph> AMR-WB, adaptive Multi-Rate – Wideband Speech Codec 3GPP (3GP)
FLAC Sowohl für Encoder als auch Decoder: MÜSSEN mindestens die Mono- und Stereomodi verwendet werden. unterstützt. Abtastraten von bis zu 192 kHz MÜSSEN unterstützt werden. 16-Bit und 24-Bit Auflösung MUSS unterstützt werden. Die Verarbeitung von FLAC-24-Bit-Audiodaten MÜSSEN Gleitkomma-Audio-Konfiguration verfügbar.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, nur decodieren)
  • Matroska (.mkv, nur decodieren)
MP3 Mono/Stereo, 8–320 Kbit/s konstant (CBR) oder variable Bitrate (VBR)
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, nur decodieren)
  • Matroska (.mkv, nur decodieren)
MIDI MIDI-Typ 0 und 1. DLS Version 1 und 2. XMF und XMF für Mobilgeräte Unterstützung für Klingeltonformate RTTTL/RTX, OTA und iMelody
  • Geben Sie 0 und 1 (.mid, .xmf, .mxmf) ein
  • RTTTL/RTX (.rtttl, .rtx)
  • iMelody (Imy)
Vorbis Decodierung: Unterstützung für Mono-, Stereo-, 5.0- und 5.1-Inhalte mit Sampling Frequenzen 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 decodieren)
  • Matroska (.mkv)
  • WEBM (.webm)
PCM/WAVE Der PCM-Codec muss lineare 16-Bit-PCM und 16-Bit-Gleitkommazahl unterstützen. WAVE Extrahierer muss lineare 16-Bit-, 24-Bit- und 32-Bit-PCM sowie 32-Bit-Gleitkommazahl unterstützen. (Raten bis zur Hardwarebegrenzung) Abtastraten MÜSSEN unterstützt werden von 8 kHz bis 192 kHz. WAVE (WAV)
Opus Decodierung: Unterstützung von Mono-, Stereo-, 5.0- und 5.1-Inhalten 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 decodieren)
  • Matroska (.mkv)
  • WEBM (.webm)

5.1.4. Bildcodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Image-Codecs.

Geräteimplementierungen MÜSSEN die Codierung der folgenden Bildcodierung unterstützen:

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP
  • [C-0-4] AVIF <ph type="x-smartling-placeholder">
      </ph>
    • Geräte müssen BITRATE_MODE_CQ und Baseline-Profil unterstützen.

Wenn Geräteimplementierungen die HEIC-Codierung über android.media.MediaCodec unterstützen für den Medientyp MIMETYPE_IMAGE_ANDROID_HEIC Sie:

  • [C-1-1] MUSS einen hardwarebeschleunigten HEVC-Encoder-Codec bereitstellen, der unterstützt BITRATE_MODE_CQ Bitratenkontrollmodus HEVCProfileMainStill und eine Frame-Größe von 512 x 512 Pixeln.

5.1.5 Bilddecodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Image-Codecs.

Geräteimplementierungen MÜSSEN die Decodierung der folgenden Bildcodierung unterstützen:

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Roh
  • [C-0-7] AVIF (Baseline-Profil)

Wenn Geräteimplementierungen die HEVC-Videodecodierung unterstützen, gilt Folgendes:

  • [C-1-1] MUSS die HEIF-Bilddecodierung (HEIC) unterstützen.

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

  • [C-2-1] MUSS die Ausgabe eines entsprechenden 8-Bit-Formats unterstützen, wenn dies von Die Anwendung, z. B. über ARGB_8888 Konfiguration von android.graphics.Bitmap.

5.1.6. Details zu Image-Codecs

Format/Codec Details Unterstützte Dateitypen/Containerformate
JPEG Base+progressiv JPEG (JPG)
GIF GIF (.gif)
PNG PNG (PNG)
BMP BMP (BMP)
WebP WebP (WebP)
Raw ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF Bild, Bildersammlung, Bildsequenz HEIF (.heif), HEIC (.heic)
AVIF (Baseline-Profil) Bild, Bilderfassung, Bildsequenz-Baseline-Profil HEIF-Container (AVIF)

Bild-Encoder und -Decodierer, die über die MediaCodec API verfügbar gemacht werden

  • [C-1-1] MUSS die flexible Farbe YUV420 im Format 8:8:8 unterstützen (COLOR_FormatYUV420Flexible) bis CodecCapabilities formatieren.

  • [C-SR-1] WIRD DRINGEND empfohlen, das RGB888-Farbformat für die Eingabeoberfläche zu unterstützen .

  • [C-1-3] MUSS mindestens einen Planaren oder semiplanaren Bereich unterstützen. YUV420 8:8:8-Farbformat: COLOR_FormatYUV420PackedPlanar (entspricht COLOR_FormatYUV420Planar) oder COLOR_FormatYUV420PackedSemiPlanar (entsprechend an COLOR_FormatYUV420SemiPlanar). Sie werden dringend empfohlen, beides.

5.1.7. Video-Codecs

  • Für akzeptable Qualität von Webvideostreaming und Videokonferenzen Dienste verwenden, SOLLTEN bei Geräteimplementierungen ein VP8-Hardware-Codec verwendet werden, der den Anforderungen erfüllen.

Wenn Geräteimplementierungen einen Videodecoder oder Encoder umfassen:

  • [C-1-1] Video-Codecs MÜSSEN Ausgabe- und Eingabe-Bytebuffer-Größen unterstützen, die den größtmöglichen komprimierten und unkomprimierten Frame entsprechend den Vorgaben und der Konfiguration, aber auch nicht zu viel.

  • [C-1-2] Video-Encoder und -Decodierer MÜSSEN die flexible Farbe YUV420 im Format 8:8:8 unterstützen. (COLOR_FormatYUV420Flexible) bis CodecCapabilities.

  • [C-1-3] Video-Encoder und -Decodierer MÜSSEN mindestens einen Planar- oder semiplanares YUV420-Farbformat, 8:8:8: COLOR_FormatYUV420PackedPlanar (entspricht COLOR_FormatYUV420Planar) oder COLOR_FormatYUV420PackedSemiPlanar (entspricht COLOR_FormatYUV420SemiPlanar). Es wird dringend empfohlen, beide zu unterstützen.

  • [C-SR-1] Video-Encoder und -Decodierer werden dringend empfohlen, Mindestens eine hardwareoptimierte planare oder semiplanare YUV420-Farbe 8:8:8 (YV12, NV12, NV21 oder ein gleichwertiges, anbieteroptimiertes Format).

  • [C-1-5] Videodecoder, die ein Format mit hoher Bittiefe unterstützen (9+ Bit pro Kanal) MUSS die Ausgabe eines 8-Bit-äquivalenten Formats unterstützen, wenn die von der Anwendung angefordert werden. Dies MUSS sich daran orientieren, YUV420 8:8:8-Farbformat über android.media.MediaCodecInfo.

Wenn Geräteimplementierungen Support für HDR-Profile bewerben, Display.HdrCapabilities, Sie:

  • [C-2-1] MUSS das Parsen und die Verarbeitung statischer HDR-Metadaten unterstützen.

Wenn Geräteimplementierungen Support für Intra-Refresh-Anzeigen bewerben, FEATURE_IntraRefresh in MediaCodecInfo.CodecCapabilities Klasse:

  • [C-3-1] MÜSSEN die Aktualisierungszeiträume im Bereich von 10 bis 60 Frames unterstützen und funktionieren innerhalb von 20% des konfigurierten Aktualisierungszeitraums korrekt.

Sofern in der Anwendung nichts anderes mit dem KEY_COLOR_FORMAT-Element angegeben ist, Formatschlüssel, Implementierungen von Videodecoder:

  • [C-4-1] MÜSSEN standardmäßig das für Hardware-Display optimierte Farbformat verwenden. falls dies mit der Surface-Ausgabe konfiguriert wurde.
  • [C-4-2] MÜSSEN standardmäßig ein YUV420-Farbformat 8:8:8 verwenden, das für die CPU optimiert ist. Lesevorgang, 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 decodieren)
H.264-AVC Siehe Abschnitt 5.2 und 5.3 für weitere Informationen
  • 3GPP (3GP)
  • MPEG-4 (MP4)
  • MPEG-2-TS (Ts, nicht suchbar)
  • Matroska (.mkv, nur decodieren)
H.265 HEVC Weitere Informationen finden Sie in Abschnitt 5.3.
  • MPEG-4 (MP4)
  • Matroska (.mkv, nur decodieren)
MPEG-2 Profil "Main"
  • MPEG2-TS (.ts, nicht suchbar)
  • MPEG-4 (.mp4, nur decodieren)
  • Matroska (.mkv, nur decodieren)
MPEG-4 SP
  • 3GPP (3GP)
  • MPEG-4 (MP4)
  • Matroska (.mkv, nur decodieren)
VP8 Siehe Abschnitt 5.2 und 5.3 für weitere Informationen
VP9 Weitere Informationen finden Sie in Abschnitt 5.3.
AV1 Weitere Informationen finden Sie in Abschnitt 5.2 und Abschnitt 5.3.
  • MPEG-4 (MP4)
  • Matroska (.mkv, nur decodieren)

5.1.9. Medien-Codec-Sicherheit

Geräteimplementierungen MÜSSEN die Einhaltung der Sicherheitsfunktionen für Medien-Codec sicherstellen wie unten beschrieben.

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

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

  • [C-1-1] MÜSSEN Support für Medien-Codecs entweder über OMX oder Codec 2.0 bereitstellen. APIs (oder beides) wie im Android Open Source-Projekt und nicht deaktiviert oder um die Sicherheitsvorkehrungen zu umgehen. Das bedeutet insbesondere nicht, dass jede Codec MUSS entweder die OMX- oder die Codec 2.0 API verwenden. Nur die Unterstützung für mindestens Eine dieser APIs MUSS verfügbar sein und der Support für die verfügbaren APIs MÜSSEN MÜSSEN die vorhandenen Sicherheitsvorkehrungen.
  • [C-SR-1] wird dringend empfohlen, Support für die Codec 2.0 API aufzunehmen.

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

  • [C-2-1] MÜSSEN den entsprechenden OMX-Software-Codec aus dem Open-Source-Projekt (sofern verfügbar) für jedes Medienformat und jeden Medientyp (Encoder oder Decoder), der vom Gerät unterstützt wird.
  • [C-2-2] Codecs, deren Namen mit „OMX.google“ beginnen. MÜSSEN aufgestellt sein. im Quellcode ihres Android Open Source Project.
  • [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, dass die OMX-Software-Codecs in einem Codec ausgeführt werden Prozess, der keinen Zugriff auf andere Hardwaretreiber als Speicher-Mapper hat.

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

  • [C-3-1] MÜSSEN den entsprechenden Codec 2.0-Software-Codec aus dem Open-Source-Projekt von Android (sofern verfügbar) für jedes Medienformat und jeden Medientyp (Encoder oder Decoder), der vom Gerät unterstützt wird.
  • [C-3-2] MÜSSEN die Codec 2.0-Software-Codecs im Software-Codec enthalten. wie im Android Open Source Project beschrieben, um enger Zugriff auf Software-Codecs zu gewähren.
  • [C-3-3] Codecs, deren Namen mit „c2.android“ beginnen. MÜSSEN aufgestellt sein. im Quellcode ihres Android Open Source Project.

5.1.10. Charakterisierung von Medien-Codec

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

  • [C-1-1] MÜSSEN korrekte Werte für die Media-Codec-Charakterisierung über die MediaCodecInfo der API erstellen.

Insbesondere

  • [C-1-2] Codecs, deren Namen mit „OMX“ beginnen. MÜSSEN die OMX-APIs verwenden. und deren Namen den Benennungsrichtlinien von OMX IL entsprechen.
  • [C-1-3] Codecs mit Namen, die mit „c2“ beginnen. MÜSSEN die Codec 2.0 API und deren Namen den Codec 2.0-Benennungsrichtlinien für Android entsprechen.
  • [C-1-4] Codecs, deren Namen mit „OMX.google“ beginnen. oder „c2.android“. MUSS Sie dürfen NICHT als Anbieter oder hardwarebeschleunigt bezeichnet werden.
  • [C-1-5] Codecs, die in einem Codec-Prozess (Anbieter oder System) ausgeführt werden, Der Zugriff auf andere Hardwaretreiber als Speicherzuordnungen und Mapper DÜRFEN NICHT sind reine Softwareprodukte.
  • [C-1-6] Codecs, die nicht im Android Open Source Project vorhanden sind oder nicht basieren im Quellcode in diesem Projekt MUSS als Anbieter gekennzeichnet werden.
  • [C-1-7] Codecs, die die Hardwarebeschleunigung nutzen, MÜSSEN gekennzeichnet werden, als hardwarebeschleunigt wurde.
  • [C-1-8] Codec-Namen DÜRFEN NICHT irreführend sein. Beispiele für Codecs mit der Bezeichnung "Decoder" MÜSSEN die Decodierung und solche mit der Bezeichnung „Encoder“ unterstützen MÜSSEN unterstützen Codierung. Codecs mit Namen, die Medienformate enthalten, MÜSSEN diese unterstützen. Formaten.

Wenn Geräteimplementierungen Video-Codecs unterstützen:

  • [C-2-1] Alle Video-Codecs MÜSSEN erreichbare Frame-Rate-Daten für die folgenden Größen, wenn der Codec unterstützt wird:
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p UHD
Videoauflösung
  • 176 x 144 Pixel (H263, MPEG2, MPEG4)
  • 352 x 288 Pixel (MPEG4-Encoder, H263, MPEG2)
  • 320 x 180 Pixel (VP8, VP8)
  • 320 x 240 px (sonstige)
  • 704 x 576 Pixel (H263)
  • 640 x 360 Pixel (VP8, VP9)
  • 640 x 480 Pixel (MPEG4-Encoder)
  • 720 x 480 Pixel (Sonstiges, AV1)
  • 1408 x 1152 Pixel (H263)
  • 1280 x 720 px (Sonstiges, AV1)
1920 x 1080 Pixel (außer MPEG4, AV1) 3840 x 2160 Pixel (HEVC, VP9, AV1)
  • [C-2-2] Video-Codecs, die als hardwarebeschleunigt gekennzeichnet sind, MÜSSEN MÜSSEN Informationen zu Leistungspunkten veröffentlichen. Sie MÜSSEN jeweils alle unterstützten Punkte der standardmäßigen Leistung (aufgeführt in PerformancePoint) API), sofern sie nicht von einem anderen unterstützten Standard-Leistungspunkt abgedeckt sind.
  • Außerdem SOLLTEN sie erweiterte Leistungspunkte veröffentlichen, die anhaltende Videoleistung aufweisen, außer einer der oben aufgeführten.

5.2. Videocodierung

Wenn Geräteimplementierungen Video-Encoder unterstützen und für alle Drittanbieter-Apps und legen Sie die
Von MediaFormat.KEY_BITRATE_MODE an BITRATE_MODE_VBR sodass der Encoder im Modus mit variabler Bitrate arbeitet, Solange sie sich nicht auf die Mindestqualitätsstufe auswirken, die codierte Bitrate :

  • SOLLTE NICHT sein, mehr als eins gleitendes Fenster, mehr als 15% über der Bitrate zwischen Intraframe (I-Frame) Intervalle.
  • SOLLTE NICHT mehr sein als 100% über der Bitrate über ein gleitendes Fenster von 1 Sekunde.

Wenn Geräteimplementierungen Video-Encoder unterstützen und für alle Drittanbieter-Apps und legen Sie MediaFormat.KEY_BITRATE_MODE bis BITRATE_MODE_CBR sodass der Encoder im Modus mit konstanter Bitrate arbeitet, wird die codierte Bitrate verwendet:

  • [C-SR-2] wird dringend empfohlen, NICHT mehr als 15% über der Zielbitrate bei einem gleitenden Fenster von 1 Sekunde liegen

Wenn Geräteimplementierungen ein eingebettetes Display mit der mindestens 2,5 Zoll diagonal sein oder einen Videoausgangsanschluss oder die Unterstützung einer Kamera über die android.hardware.camera.any erklären Funktions-Flag:

  • [C-1-1] MÜSSEN die Unterstützung mindestens eines VP8- oder H.264-Videos beinhalten. und für Drittanbieteranwendungen zur Verfügung stellen.
  • SOLLTEN sowohl VP8- als auch H.264-Videoencoder unterstützen und für Drittanbieter-Anwendungen.

Wenn Geräteimplementierungen H.264-, VP8-, VP9- oder HEVC-Videos unterstützen und sie für Anwendungen von Drittanbietern verfügbar machen, müssen sie:

  • [C-2-1] MUSS dynamisch konfigurierbare Bitraten unterstützen.
  • SOLLTE variable Frame-Rates unterstützen, wobei der Video-Encoder bestimmen sollte, sofortige Frame-Dauer basierend auf den Zeitstempeln der Eingabepuffer und Ordnen Sie seinen Bit-Bucket basierend auf dieser Frame-Dauer zu.

Wenn Geräteimplementierungen den Video-Encoder MPEG-4 SP unterstützen, Drittanbieter-Apps zur Verfügung, gilt Folgendes:

  • SOLLTEN für den unterstützten Encoder dynamisch konfigurierbare Bitraten unterstützen.

Wenn Geräteimplementierungen hardwarebeschleunigte Video- oder Bild-Encoder bieten, und eine oder mehrere angeschlossene oder steckbare Hardwarekameras unterstützen, die durch den android.camera-APIs:

  • [C-4-1] Alle hardwarebeschleunigten Video- und Bild-Encoder MÜSSEN unterstützen. das Codieren von Frames der Hardwarekamera(s).
  • SOLLTEN die Codierung von Frames der Hardwarekamera(s) in allen Videos unterstützen. oder Bildencoder nutzen.

Wenn Geräteimplementierungen eine HDR-Codierung ermöglichen, geschieht Folgendes:

  • [C-SR-1] wird dringend empfohlen, ein Plug-in für die nahtlose Transcodierungs-API zur Konvertierung vom HDR- in das SDR-Format.

5.2.1 H.263

Wenn Geräteimplementierungen H.263-Encoder unterstützen und verfügbar machen Drittanbieter-Apps:

  • [C-1-1] MUSS die QCIF-Auflösung unterstützen (176 x 144) mit Baseline-Profillevel 45. Die SQCIF-Auflösung ist optional.

5.2.2 H.264

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

  • [C-1-1] MUSS Baseline-Profilebene 3 unterstützen. Die Unterstützung für ASO (Arbitrary Slice Ordering), FMO (Flexible Funktion) Macroblock Ordering) und RS (Redundante Slices) sind OPTIONAL. Außerdem können Sie mit anderen Android-Geräten kompatibel zu sein, wird EMPFOHLEN, Encoder verwenden keine ASO, FMO und RS für das Baseline-Profil.
  • [C-1-2] MÜSSEN die SD-Videocodierungsprofile (Standard Definition) unterstützen in der folgenden Tabelle.
  • SOLLTEN die Hauptprofilebene 4 unterstützen.
  • SOLLTEN die Codierungsprofile für HD-Videos (High Definition) wie folgt unterstützen: wie in der folgenden Tabelle angegeben.

Wenn Geräteimplementierungen die Unterstützung der H.264-Codierung für 720p oder 1080p melden Medien-APIs die Auflösung von Videos zu verwenden,

  • [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
Videoauflösung 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Video-Framerate 20 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 384 kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

5.2.3 VP8

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

  • [C-1-1] MUSS die SD-Video-Codierungsprofile unterstützen.
  • SOLLTEN die folgenden HD-Videocodierungsprofile (High Definition) unterstützen.
  • [C-1-2] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
  • SOLLTEN SIE einen Hardware-VP8-Codec bereitstellen, der die Codierungsanforderungen für RTC-Hardware von WebM-Projekten, um sicherzustellen, akzeptable Qualität der Dienste für Webvideostreaming und Videokonferenzen

Wenn Geräteimplementierungen die Unterstützung der VP8-Codierung für 720p oder 1080p melden Medien-APIs die Auflösung von Videos zu verwenden,

  • [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
Videoauflösung 320 x 180 Pixel 640 x 360 Pixel 1280 x 720 px 1920 x 1080 px
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 800 kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

5.2.4 VP9

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

  • [C-1-2] MUSS Profil 0 Level 3 unterstützen.
  • [C-1-1] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
  • [C-1-3] MÜSSEN CodecPrivate-Daten generieren.
  • SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
  • [C-SR-1] wird dringend empfohlen, HD-Decodierungsprofile als in der folgenden Tabelle, wenn es einen Hardware-Encoder gibt.
SD HD 720p HD 1080p UHD
Videoauflösung 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 Pixel
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Wenn Geräteimplementierungen Profil 2 oder Profil 3 über die Medien-APIs:

  • Unterstützung für das 12-Bit-Format ist optional.

5.2.5 H.265

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

  • [C-1-1] MUSS Hauptprofilebene 3 bis zu Auflösung: 512 x 512
  • [C-SR-1] wird dringend empfohlen, 720 x 480-SD-Profil und das HD-Codierungsprofile wie in der folgenden Tabelle angegeben, wenn ein Hardware-Encoder.
SD HD 720p HD 1080p UHD
Videoauflösung 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 Pixel
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

5.2.6. AV1

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

  • [C-1-1] MUSS das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalte unterstützen.
  • [C-1-2] MÜSSEN Leistungsdaten veröffentlichen, d.h., die Leistungsdaten über das getSupportedFrameRatesFor() oder getSupportedPerformancePoints() APIs für unterstützte Auflösungen finden Sie in der Tabelle unten.

  • [C-1-3] MUSS HDR-Metadaten akzeptieren und im Bitstream ausgeben

Wenn der AV1-Encoder hardwarebeschleunigt ist, geschieht Folgendes:

  • [C-2-1] MUSS bis einschließlich HD1080p-Codierungsprofil aus dem Tabelle unten:
SD HD 720p HD 1080p UHD
Videoauflösung 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 Pixel
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 5 Mbit/s 8 Mbit/s 16 Mbit/s 50 Mbit/s

5.3. Videodecodierung

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 den Wechsel der Framerate unterstützen über die standardmäßigen Android-APIs im selben Stream für alle VP8-, VP9-, H.264- und H.265-Codecs in Echtzeit und bis zur maximal unterstützten Auflösung von jedem Codec auf dem Gerät.

5.3.1 MPEG-2

Wenn Geräteimplementierungen MPEG-2-Decodierer unterstützen, gilt Folgendes:

  • [C-1-1] MUSS die allgemeine Ebene "Hauptprofil" unterstützen.

5.3.2 H.263

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

  • [C-1-1] MUSS Baseline-Profilebene 30 unterstützen (CIF-, QCIF- und SQCIF-Auflösungen bei 30 fps, 384 kbit/s) und Level 45 (QCIF und SQCIF-Auflösungen bei 30 fps und 128 kbit/s).

5.3.3 MPEG-4

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

  • [C-1-1] MÜSSEN die einfache Profilebene 3 unterstützen.

5.3.4. H.264

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

  • [C-1-1] MÜSSEN die Hauptprofilebene 3.1 und das Basisprofil unterstützen. Support für ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (redundante Segmente) ist OPTIONAL.
  • [C-1-2] MUSS Videos mit SD (Standardauflösung) decodieren können Profile, die in der folgenden Tabelle aufgeführt und mit dem Baseline-Profil codiert sind und Hauptprofilebene 3.1 (einschließlich 720p30).
  • SOLLTEN in der Lage sein, Videos mit HD-Profilen (High Definition) zu decodieren. wie in der folgenden Tabelle angegeben.

Wenn die von der Methode Display.getSupportedModes() gemeldete Höhe so lautet gleich oder größer als die Videoauflösung ist, implementierten Geräte:

  • [C-2-1] MUSS die HD-Videodecodierungsprofile mit 720p in den folgenden .
  • [C-2-2] MÜSSEN die HD-1080p-Video-Decodierungsprofile in den folgenden .
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
Videoauflösung 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps 60 fps 30 fps (60 fpsFernsehen)
Video-Bitrate 800 kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

5.3.5. H.265 (HEVC)

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

  • [C-1-1] MUSS die Hauptstufe 3 des Hauptprofils und das SD-Video unterstützen. Decodierung von Profilen, wie in der folgenden Tabelle angegeben.
  • SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
  • [C-1-2] MUSS die HD-Decodierungsprofile wie unten angegeben unterstützen wenn es einen Hardwaredecoder gibt.

Wenn die von der Methode Display.getSupportedModes() gemeldete Höhe so lautet gleich oder größer als die Videoauflösung ist, dann:

  • [C-2-1] Geräteimplementierungen MÜSSEN mindestens H.265 oder VP9 unterstützen. Decodierung von 720-, 1080- und UHD-Profilen.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p UHD
Videoauflösung 352 x 288 px 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 Pixel
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps 30/60 fps (60 fpsFernsehen mit H.265-Hardware-Decodierung) 60 fps
Video-Bitrate 600 Kbit/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Wenn Geräteimplementierungen angeblich ein HDR-Profil über die Medien unterstützen APIs:

  • [C-3-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR-Metadaten von sowie das Extrahieren und Ausgeben der erforderlichen HDR-Inhalte Metadaten aus dem Bitstream und/oder Container.
  • [C-3-2] Geräteimplementierungen MÜSSEN HDR-Inhalte auf der Gerätebildschirm oder an einem Standard-Videoausgabeanschluss (z.B. HDMI).

5.3.6. VP8

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

  • [C-1-1] MÜSSEN die SD-Decodierungsprofile in der folgenden Tabelle unterstützen.
  • SOLLTEN SIE einen Hardware-VP8-Codec verwenden, der die Anforderungen erfüllen.
  • SOLLTEN die HD-Decodierungsprofile in der folgenden Tabelle unterstützen.

Wenn die von der Display.getSupportedModes()-Methode gemeldete Höhe gleich oder größer als die Videoauflösung ist, dann:

  • [C-2-1] Geräteimplementierungen MÜSSEN 720p-Profile im folgenden Tabelle.
  • [C-2-2] Geräteimplementierungen MÜSSEN 1080p-Profile im folgenden Tabelle.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
Videoauflösung 320 x 180 Pixel 640 x 360 Pixel 1280 x 720 px 1920 x 1080 px
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps 30 fps (60 fpsFernsehen) 30 (60 fpsFernsehen)
Video-Bitrate 800 kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

5.3.7. VP9

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

  • [C-1-1] MÜSSEN die SD-Video-Decodierungsprofile unterstützen, wie in den folgenden Tabelle.
  • SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.

Wenn Geräteimplementierungen den VP9-Codec und einen Hardwaredecoder unterstützen:

  • [C-2-1] MUSS die HD-Decodierungsprofile wie unten angegeben unterstützen. .

Wenn die von der Methode Display.getSupportedModes() gemeldete Höhe so lautet gleich oder größer als die Videoauflösung ist, dann:

  • [C-3-1] Geräteimplementierungen MÜSSEN mindestens entweder VP9 oder H.265 unterstützen. Decodierung der 720-, 1080- und UHD-Profile.
SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p UHD
Videoauflösung 320 x 180 Pixel 640 x 360 Pixel 1280 x 720 px 1920 x 1080 px 3840 x 2160 Pixel
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps 30 fps (60 fpsFernsehen mit VP9-Hardware-Decodierung) 60 fps
Video-Bitrate 600 Kbit/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Wenn Geräteimplementierungen VP9Profile2 oder VP9Profile3 unterstützen über 'CodecProfileLevel' Medien-APIs:

  • Unterstützung für das 12-Bit-Format ist optional.

Wenn Geräteimplementierungen angeblich ein HDR-Profil unterstützen (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) über die Medien-APIs:

  • [C-4-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR-Metadaten akzeptieren KEY_HDR_STATIC_INFO für alle HDR-Profile sowie 'KEY_HDR10_PLUS_INFO' für HDR10Plus-Profile) aus der Anwendung. Sie MÜSSEN auch unterstützen, das die erforderlichen HDR-Metadaten aus dem Bitstream und/oder dem Container.
  • [C-4-2] Geräteimplementierungen MÜSSEN HDR-Inhalte auf der Gerätebildschirm oder an einem Standard-Videoausgabeanschluss (z.B. HDMI).

5.3.8. Dolby Vision

Wenn Geräteimplementierungen die Unterstützung des Dolby Vision-Decoders durch HDR_TYPE_DOLBY_VISION, Sie:

  • [C-1-1] MÜSSEN einen Dolby Vision-fähigen Extraktor bereitstellen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-2] MÜSSEN Dolby Vision-Inhalte korrekt angezeigt werden entweder auf dem Gerät auf einem externen Display über einen Standard-Videoausgabeport (z.B. HDMI).

Neue Anforderungen beenden

  • [C-1-3] MUSS die Titel-ID festlegen. der abwärtskompatiblen Basisebenen (falls vorhanden) müssen mit der der Track-ID der Dolby Vision-Ebene kombiniert.

5.3.9. AV1

Wenn Geräteimplementierungen den AV1-Codec unterstützen und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

  • [C-1-1] MUSS das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalte unterstützen.

Wenn Geräteimplementierungen Unterstützung für den AV1-Codec mit einer Hardware bieten beschleunigt werden, geschieht Folgendes:

  • [C-2-1] MÜSSEN in der Lage sein, mindestens HD-Videodecodierungsprofile mit 720p von der Tabelle unten, wenn die von Display.getSupportedModes() gemeldete Höhe gleich oder größer als 720p ist.
  • [C-2-2] MÜSSEN in der Lage sein, mindestens HD-Videodecodierungsprofile mit 1080p zu decodieren aus der Tabelle unten, wenn die von Display.getSupportedModes() gemeldete Höhe gleich oder größer als 1080p ist.
SD HD 720p HD 1080p UHD
Videoauflösung 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 Pixel
Video-Framerate Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps Frame-Rate: 30 fps
Video-Bitrate 5 Mbit/s 8 Mbit/s 16 Mbit/s 50 Mbit/s

Wenn Geräteimplementierungen HDR-Profile über die Media APIs unterstützen, dann Sie:

  • [C-3-1] MUSS die Extraktion und Ausgabe von HDR-Metadaten aus dem Bitstream und/oder Container.
  • [C-3-2] HDR-Inhalte MUSS richtig auf dem Gerätebildschirm oder auf einem Standard-Videoausgangsport (z. B. HDMI)

5.4. Audioaufnahmen

Während einige der in diesem Abschnitt beschriebenen Anforderungen aufgelistet werden sollten, SOLLTEN Sie eine Kompatibilitätsdefinition für zukünftige Versionen um sie in MUSS zu ändern. Bestehende und neue Android-Geräte sind UNBEDINGT EMPFOHLEN, diese Anforderungen zu erfüllen, die als SOLLTEN aufgeführt sind, oder wird bei einem Upgrade auf die Zukunft nicht mehr mit Android kompatibel sein. Version.

5.4.1 Aufzeichnung von Rohdaten und Mikrofon

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

  • [C-1-1] MUSS die Aufnahme von Audio-Rohinhalten für beliebiger AudioRecord- oder AAudio-INPUT-Stream, der geöffnet ist erfolgreich war. Es MÜSSEN mindestens die folgenden Eigenschaften unterstützt werden:

  • SOLLTEN die Erfassung von unbearbeiteten Audioinhalten mit Eigenschaften:

    • Format: Lineare PCM, 16-Bit und 24-Bit
    • Abtastraten: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 Hz
    • Kanäle: so viele Kanäle wie die Mikrofone im Gerät
  • [C-1-2] MÜSSEN bei den obigen Stichprobenraten ohne Up-Sampling erfassen.

  • [C-1-3] MÜSSEN einen geeigneten Kantenglättungsfilter verwenden, wenn Die oben angegebenen Stichprobenraten werden durch Downsampling erfasst.

  • SOLLTEN die Aufnahme von Audioinhalten in AM-Radio- und DVD-Qualität ermöglichen, bedeutet Folgendes:

    • Format: Lineare PCM, 16 Bit
    • Abtastraten: 22.050, 48.000 Hz
    • Kanäle: Stereo
  • [C-1-4] MUSS die MicrophoneInfo API berücksichtigen und die Informationen für die auf dem Gerät verfügbaren Mikrofone korrekt eingegeben haben. Anwendungen von Drittanbietern über die AudioManager.getMicrophones() API für aktiven AudioRecord mit MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED oder VOICE_PERFORMANCE. Ob die Geräteimplementierung die Aufnahme von Audiorohdaten in AM-Radio- und DVD-Qualität ermöglicht Inhalte:

  • [C-2-1] MÜSSEN ohne Upsampling mit einem Verhältnis erfasst werden, das höher ist als 16000:22050 oder 44100:48000.

  • [C-2-2] MÜSSEN für Upsampling einen geeigneten Anti-Aliasing-Filter verwenden. oder Downsampling.

5.4.2 Für Spracherkennung aufnehmen

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

  • [C-1-1] MÜSSEN erfassen android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION Audioquelle bei einer der Stichprobenraten 44.100 und 48.000.
  • [C-1-2] MÜSSEN standardmäßig die Audioverarbeitung zur Rauschunterdrückung deaktivieren, wenn Sie nehmen einen Audiostream aus dem Audioteil „AudioSource.VOICE_RECOGNITION“ auf Quelle.
  • [C-1-3] MÜSSEN standardmäßig die automatische Verstärkungsregelung bei der Aufnahme deaktivieren. Ein Audiostream von der Audioquelle „AudioSource.VOICE_RECOGNITION“.

  • SOLLTE etwa flache Amplitude-gegen-Frequenz-Eigenschaften aufweisen. im mittleren Frequenzbereich: jeweils ±3 dB von 100 Hz bis 4.000 Hz sowie jedes Mikrofon, das für die Aufzeichnung der Spracherkennungs-Audioquelle verwendet wird.

  • Für [C-SR-1] wird dringend empfohlen, Amplitudenwerte im unteren Bereich Frequenzbereich: von ±20 dB von 30 Hz bis 100 Hz im Vergleich zu mittlerer Frequenzbereich für jedes einzelne Mikrofon, mit dem die Stimme aufgezeichnet wird Audioquelle mit Erkennungsfunktion.

  • Für [C-SR-2] wird dringend empfohlen, Amplitudenwerte im hohen Frequenzbereich: von ±30 dB von 4.000 Hz bis 22 kHz im Vergleich zu den mittleren Frequenzbereich für jedes einzelne Mikrofon, mit dem die Stimme aufgezeichnet wird Audioquelle mit Erkennungsfunktion.

  • SOLLTEN SIE die Empfindlichkeit der Audioeingabe so einstellen, dass eine sinusoidale Tonquelle von 1.000 Hz eingestellt wird. Wiedergabe bei 90 dB Schalldruckpegel (neben dem Mikrofon gemessen) eine ideale Reaktion von 2500 RMS im Bereich von 1770 bis 3530 für 16 Bit-Samples (oder -22,35 db ±3 dB Full Scale für Gleitkomma/doppelte Genauigkeit) Samples) für jedes Mikrofon, das für die Aufzeichnung der Spracherkennung verwendet wird, Audioquelle.

  • SOLLTEN den Audiostream der Spracherkennung so aufzeichnen, dass die PCM-Amplitude Pegel verfolgen Änderungen des Eingangs-SPL linear über mindestens einen 30-dB-Bereich von -18 dB bis +12 dB, 90 dB Schalldruckpegel am Mikrofon.

  • SOLLTEN den Audiostream der Spracherkennung mit dem gesamten Oberton aufzeichnen. Verzerrung (THD) von weniger als 1% für 1 kHz bei 90 dB SPL am Eingang Mikrofon.

Wenn in der Geräteimplementierung android.hardware.microphone und Rauschen deklariert sind zur Unterdrückung (Reduzierung) von Technologien, die auf Spracherkennung ausgelegt sind:

  • [C-2-1] MUSS erlauben, dass dieser Audioeffekt mit der Funktion android.media.audiofx.NoiseSuppressor-API.
  • [C-2-2] MÜSSEN jede Technologie zur Rauschunterdrückung eindeutig identifizieren. über das Feld AudioEffect.Descriptor.uuid implementieren.

5.4.3 Aufnahme für Umleitung der Wiedergabe

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

Wenn in Geräteimplementierungen sowohl android.hardware.audio.output als auch android.hardware.microphone:

  • [C-1-1] MÜSSEN die Audioquelle REMOTE_SUBMIX ordnungsgemäß implementieren, sodass wenn eine Anwendung die android.media.AudioRecord API verwendet, um aus diesem Audioquelle wird eine Mischung aus allen Audiostreams erfasst, mit Ausnahme der folgenden:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.4.4. Akustik-Echo-Canceler

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

  • SOLLTEN SIE einen Acoustic Echo Canceler implementieren (AEC)-Technologie, die für die Sprachkommunikation optimiert und auf den Erfassungspfad angewendet wird beim Aufnehmen mit AudioSource.VOICE_COMMUNICATION.

Wenn Geräteimplementierungen einen Akustik-Echo-Canceler bereitstellen, der in den Pfad zur Audioaufnahme eingefügt, wenn AudioSource.VOICE_COMMUNICATION ausgewählt ist, gilt Folgendes:

5.4.5. Gleichzeitige Aufnahme

Wenn in der Geräteimplementierung „android.hardware.microphone“ deklariert ist,MÜSSEN sie MÜSSEN die gleichzeitige Erfassung implementieren, wie in diesem Dokument beschrieben. Im Detail:

  • [C-1-1] MUSS gleichzeitigen Zugriff auf das Mikrofon durch Bedienungshilfen erlauben. Diensterfassung mit AudioSource.VOICE_RECOGNITION und mindestens einem Anwendungserfassung mit AudioSource.
  • [C-1-2] MÜSSEN den gleichzeitigen Zugriff auf das Mikrofon durch ein vorinstalliertes Anwendung mit einer Assistant-Rolle und mindestens einer Anwendung Erfassung mit AudioSource, außer für AudioSource.VOICE_COMMUNICATION oder AudioSource.CAMCORDER.
  • [C-1-3] MÜSSEN die Audioaufnahme für alle anderen Anwendungen stummschalten, mit Ausnahme von eine Bedienungshilfe, während eine Anwendung Daten mit AudioSource.VOICE_COMMUNICATION oder AudioSource.CAMCORDER. Wenn Sie jedoch Eine App nimmt über AudioSource.VOICE_COMMUNICATION auf, dann eine andere App kann den Sprachanruf aufzeichnen, wenn es sich um eine privilegierte (vorinstallierte) App mit Berechtigung „CAPTURE_AUDIO_OUTPUT
  • [C-1-4] Wenn zwei oder mehr Anwendungen gleichzeitig Daten erfassen und Keine der Apps hat eine Benutzeroberfläche, Audio empfängt.

5.5. Audiowiedergabe

Unter Android können Apps auch Audio über Audio wiedergeben. Peripheriegerät gemäß Definition in Abschnitt 7.8.2.

5.5.1 Raw-Audiowiedergabe

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

  • [C-1-1] MUSS die Wiedergabe von unbearbeiteten Audioinhalten mit den folgenden Eigenschaften:

    • Quellformate: Lineare PCM, 16-Bit, 8-Bit, Gleitkommazahl
    • Kanäle: Mono, Stereo, gültige Mehrkanalkonfigurationen mit bis zu 8 Kanälen
    • Abtastraten (in Hz): <ph type="x-smartling-placeholder">
        </ph>
      • 8000, 11025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 auf dem Kanal oben aufgeführte Konfigurationen
      • 96.000 in Mono und Stereo

5.5.2 Audioeffekte

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

Wenn in Geräteimplementierungen die Funktion android.hardware.audio.output deklariert ist, Sie:

  • [C-1-1] MUSS die EFFECT_TYPE_EQUALIZER und EFFECT_TYPE_LOUDNESS_ENHANCER-Implementierungen steuerbar über die Die AudioEffect-Unterklassen Equalizer und LoudnessEnhancer
  • [C-1-2] MÜSSEN die Visualizer-API-Implementierung unterstützen, die über die Klasse Visualizer.
  • [C-1-3] MUSS die EFFECT_TYPE_DYNAMICS_PROCESSING-Implementierung unterstützen lässt sich über die AudioEffect-Unterklasse DynamicsProcessing steuern.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-4] MUSS Audioeffekte unterstützen mit Gleitkomma-Eingabe und -Ausgabe, wenn der Effekt werden die Ergebnisse an die Framework-Audiopipeline zurückgegeben. Dies bezieht sich auf typische -Insert- oder AUX-Effekte wie dem Equalizer. Gleichwertiges Verhalten ist stark empfohlen, wenn die Effektergebnisse vom Framework-Audio nicht sichtbar sind (z. B. Nachbearbeitung oder ausgelagerte Effekte).

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-5] MÜSSEN sicherstellen, dass Audioeffekte mehrere Kanäle bis zu die Anzahl der Mixerkanäle, auch bekannt als FCC_LIMIT, wenn die Effektergebnisse an die Framework-Audiopipeline zurückgegeben werden. Dieses bezieht sich auf typische Insert- oder Aux-Effekte, schließt Spezialeffekte wie als Downmix-, Upmix- oder Verräumungseffekte, die die Kanalzahl verändern. Ein gleichwertiges Verhalten wird empfohlen, wenn die Auswirkungen nicht sichtbar sind. Framework-Audio-Pipeline (z. B. Nachverarbeitung oder Auslagerung Effekte).

Neue Anforderungen beenden

  • SOLLTEN die EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, Implementierungen mit EFFECT_TYPE_PRESET_REVERB und EFFECT_TYPE_VIRTUALIZER über die AudioEffect-Unterklassen BassBoost steuerbar, EnvironmentalReverb, PresetReverb und Virtualizer.
  • [C-SR-1] wird dringend empfohlen, Effekte in Gleitkomma- und mehrere Kanäle.

5.5.3 Audioausgabelautstärke

Implementierungen von Automobilgeräten:

  • SOLLTEN die Anpassung der Audiolautstärke zulassen. separat pro Audiostream unter Verwendung des Inhaltstyps oder der Nutzung, wie sie definiert sind nach AudioAttributes und die Nutzung von Auto-Audio, wie in android.car.CarAudioManager öffentlich definiert.

5.5.4 Audio-Offload

Wenn Geräteimplementierungen die Wiedergabe von Audioauslagerungen unterstützen, geschieht Folgendes:

  • [C-SR-1] WIRD DRINGEND empfohlen, die Wiedergabe von Audioinhalten ohne Unterbrechung zu kürzen zwischen zwei Clips mit demselben Format, wenn dies durch den lückenlose AudioTrack API und den Media-Container für MediaPlayer.

5.6. Audiolatenz

Die Audiolatenz ist die Zeitverzögerung, wenn ein Audiosignal ein System durchläuft. Viele Klassen von Anwendungen nutzen kurze Latenzen, um Soundeffekte.

Verwenden Sie für die Zwecke dieses Abschnitts die folgenden Definitionen:

  • Ausgabelatenz. Das Intervall zwischen dem Schreiben eines Frames durch eine Anwendung von PCM-codierten Daten und wenn der entsprechende Ton dem Umgebung an einem Transducer auf dem Gerät oder das Signal verlässt das Gerät über Port und können extern beobachtet werden.
  • Latenz der kalten Ausgabe. Die Zeit zwischen dem Start eines Ausgabestreams und dem des ersten Frames basierend auf Zeitstempeln, wenn die Audioausgabe das System vor der Anfrage inaktiv war und heruntergefahren wurde.
  • Kontinuierliche Ausgabelatenz: Die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät Audio wiedergibt.
  • Eingabelatenz Das Intervall zwischen der Wiedergabe eines Tons die Umgebung zum Gerät über einen geräteinternen Transducer oder ein Signal und wenn eine Anwendung den entsprechenden Frame von PCM-codierten Daten liest.
  • keine Eingabe mehr. Der erste Teil eines Eingabesignals, der nicht nutzbar oder nicht verfügbar.
  • Kalteingabelatenz Die Zeit zwischen dem Start des Streams und dem Zeitpunkt, zu dem der wenn das Audioeingabesystem inaktiv war und der erste gültige Frame empfangen wird. vor der Anfrage heruntergefahren wurden.
  • Kontinuierliche Eingabelatenz. Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufzeichnet.
  • Kontinuierliche Umlauflatenz. Die Summe der kontinuierlichen Eingabelatenz plus die kontinuierliche Ausgabelatenz plus einen Pufferzeitraum. Der Pufferzeitraum ermöglicht es, Zeit, die die App zum Verarbeiten des Signals benötigt, und die Zeit, die die App zur Entschärfung benötigt. zwischen Eingabe- und Ausgabestreams.
  • OpenSL ES PCM Buffer Queue API Die Gruppe der PCM-bezogenen OpenSL Spanien APIs in Android NDK
  • Native Audio API von Audio. Die Gruppe der AAudio-APIs im Android NDK.
  • Zeitstempel. Ein Paar, das aus einer relativen Frame-Position innerhalb eines -Stream und die geschätzte Zeit, zu der dieser Frame den Audioverarbeitungspipeline auf dem zugehörigen Endpunkt. Siehe auch AudioTimestamp:
  • Fehler. Eine vorübergehende Unterbrechung oder ein falscher Samplewert im Audiosignal ist in der Regel auf buffer underrun für die Ausgabe, Pufferüberlauf für die Eingabe oder eine andere Quelle von digitalem oder analogem Rauschen.
  • mittlere absolute Abweichung (MAD). Durchschnitt des absoluten Werts der Abweichungen vom Mittelwert für eine Reihe von Werten.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • Die Tap-to-Tone-Latenz (TTL) wird von CTS Verifier gemessen und ist die Zeit, zwischen dem Antippen des Bildschirms und dem generierten Ton auf dem Lautsprecher zu hören ist. Dieser Wert wird über 5 Messungen gemittelt, wobei das AAudio native Audio API für die Ausgabe

  • Die Round-Trip-Latenz (RTL) ist der durchschnittliche Kontinuierliche Latenz über 5 Messungen, gemessen über einen Loopback-Pfad, der Feeds mithilfe der AAudio Native Audio API zurückgeben. Es gibt folgende Loopback-Pfade:

    • Lautsprecher/Mikrofon: Integrierter Lautsprecher und integriertes Mikrofon.
    • Analog: Analoger 3,5-mm-Anschluss und Loopback-Adapter.
    • USB: USB-auf-3,5-mm-Adapter und Loopback-Adapter oder USB-Audioadapter Schnittstellen- und Loopback-Kabel verwenden.
  • FEATURE_AUDIO_PRO Die Funktion „android.hardware.audio.pro“ ist .

  • MPC Media Performance-Klasse

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • Head-Tracking-Latenz. Die Zeit, zu der es bezieht sich auf die Kopfbewegung, die von der Trägheitsmaßeinheit (IMU) erfasst wurde zu den Kopfhöreraufnehmern der Geräuschänderung aufgrund von Bewegung.

Neue Anforderungen beenden

Wenn in der Geräteimplementierung android.hardware.audio.output deklariert ist, wird MÜSSEN die folgenden Anforderungen erfüllen oder übertreffen:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen beenden

  • [C-1-2] Kalte Ausgabelatenz von 500 Millisekunden oder weniger.

  • [C-1-3] Öffnen eines Ausgabestreams mit AAudioStreamBuilder_openStream() MÜSSEN weniger als 1.000 Millisekunden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-4] Die berechneten Umlauflatenzen basierend auf Ein- und Ausgabe Von AAudioStream_getTimestamp zurückgegebene Zeitstempel MÜSSEN innerhalb von 200 ms nach dem die gemessene Umlauflatenz für AAUDIO_PERFORMANCE_MODE_NONE und AAUDIO_PERFORMANCE_MODE_LOW_LATENCY für Lautsprecher, kabelgebunden und kabellos Headsets.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn in Geräteimplementierungen android.hardware.audio.output deklariert wird, sind sie EMPFOHLEN, die folgenden Anforderungen zu erfüllen oder zu übertreffen:

  • [C-SR-1] Kalte Ausgabelatenz von maximal 100 Millisekunden über den Lautsprecher Datenpfad.

  • [C-SR-2] Die Tonwahl-Latenz beträgt maximal 80 Millisekunden.

  • [C-SR-4] Die berechneten Umlauflatenzen auf der Grundlage von Ein- und Ausgabe Die von AAudioStream_getTimestamp zurückgegebenen Zeitstempel werden UNBEDINGT EMPFOHLEN maximal 30 Millisekunden von der gemessenen Umlauflatenz für AAUDIO_PERFORMANCE_MODE_NONE und AAUDIO_PERFORMANCE_MODE_LOW_LATENCY für Lautsprecher sowie kabelgebundene und kabellose Headsets.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräteimplementierungen die oben genannten Anforderungen erfüllen, können Sie Kalibrierung bei Verwendung der AAudio Native Audio API für eine kontinuierliche Ausgabe Latenz und Kaltausgabelatenz für mindestens ein unterstütztes Audio Ausgabegerät, sind sie:

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräteimplementierungen die Anforderungen an Audio mit niedriger Latenz nicht erfüllen über die AAudio Native Audio API:

  • [C-2-1] DÜRFEN KEINE Unterstützung für Audio mit niedriger Latenz melden.

Neue Anforderungen beenden

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-3-1] Begrenzen Sie den Fehler in Eingabezeitstempeln, wie von AudioRecord.getTimestamp oder AAudioStream_getTimestamp auf +/- 2 ms. „Fehler“ bedeutet hier die Abweichung vom richtigen Wert.

Neue Anforderungen beenden

  • [C-3-2] Kalte Eingabe-Latenz von 500 Millisekunden oder weniger.
  • [C-3-3] Ein Eingabestream mit AAudioStreamBuilder_openStream() öffnen MÜSSEN weniger als 1.000 Millisekunden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräteimplementierungen android.hardware.microphone enthalten, sind sie EMPFOHLEN, die folgenden Anforderungen für die Audioeingabe zu erfüllen:

  • [C-SR-8] Kalteingabelatenz von maximal 100 Millisekunden über dem Mikrofon Datenpfad.
  • [C-SR-11] Begrenzen Sie den Fehler in Eingabezeitstempeln, wie von AudioRecord.getTimestamp oder AAudioStream_getTimestamp in +/- 1 ms.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn in der Geräteimplementierung android.hardware.audio.output und android.hardware.microphone:

  • [C-SR-12] WIRD UNBEDINGT EMPFOHLEN, eine durchschnittliche Umlauflatenz zu haben 50 Millisekunden oder weniger über 5 Messungen mit einer mittleren absoluten Abweichung weniger als 10 Millisekunden über mindestens einen unterstützten Pfad

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

In der folgenden Tabelle sind die Anforderungen für RTL-Dateien für Handheld-Geräte definiert. Implementierungen gemäß 2.2.1, die android.hardware.audio.output und android.hardware.microphone.

Gerät und Erklärungen Linksläufig (ms) MAD (ms) Loopback-Pfade
Handkamera 250 30 Lautsprecher/Mikrofon, 3,5 mm analog (falls unterstützt), USB (falls unterstützt)
>= MPC_T (14) 80 15 mindestens einen Pfad
FUNKTION_AUDIO_NIEDRIGE_LATENZ 50 10 mindestens einen Pfad
Audiopro-Funktion 25 5 mindestens einen Pfad
Audiopro-Funktion 20 5 analog (falls unterstützt)
Audiopro-Funktion 25 5 USB (wenn analoges Gerät nicht unterstützt wird)

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

In der folgenden Tabelle sind die Anforderungen für die TTL auf einem Handheld-Gerät definiert. Implementierungen gemäß 2.2.1, die android.hardware.audio.output und android.hardware.microphone.

Gerät und Erklärungen TTL (ms)
Handkamera 250
>= MPC_T (14) 80
MPC_S (13) 100
Audiopro-Funktion 80

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräteimplementierungen Unterstützung für spatial audio mit Erfassung von Kopfbewegungen und deklarieren Sie PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY melden sie:

  • [C-4-1] MÜSSEN eine maximale Latenz von Head-Tracking zu Audio-Updates von 300 ms aufweisen.

Neue Anforderungen beenden

5.7. Netzwerkprotokolle

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

Für jeden Codec und jedes Containerformat, für das eine Geräteimplementierung erforderlich ist, Support, die Geräteimplementierung:

  • [C-1-1] MUSS diesen Codec oder Container über HTTP und HTTPS unterstützen.

  • [C-1-2] MÜSSEN die entsprechenden Mediensegmentformate unterstützen, wie in der Tabelle „Mediensegmentformate“ Entwurfsprotokoll für HTTP-Livestreaming, Version 7

  • [C-1-3] MUSS die entsprechenden RTSP-Nutzlastformate unterstützen, wie in der RTSP-Tabelle unten. Ausnahmen finden Sie in den Fußnoten der Tabelle Abschnitt 5.1.

Formate für Mediensegmente

Segmentformate Referenz(en) Codec-Unterstützung erforderlich
MPEG-2-Transportstrom ISO 13818 Video-Codecs: <ph type="x-smartling-placeholder">
    </ph>
  • H264-AVC
  • MPEG-4 SP
  • MPEG-2
Weitere Informationen zu H264 AVC, MPEG2-4 SP,
siehe Abschnitt 5.1.8 und MPEG-2.

Audio-Codecs:

  • AAC
Weitere Informationen zu AAC und ihren Varianten finden Sie in Abschnitt 5.1.3.
AAC mit ADTS-Framing und ID3-Tags ISO 13818-7 Siehe Abschnitt 5.1.1 finden Sie weitere Informationen zu AAC und seinen Varianten.
WebVTT WebVTT

RTSP (RTP, SDP)

Profilname Referenz(en) Codec-Unterstützung erforderlich
H264-AVC RFC 6184 Siehe Abschnitt 5.1.8 für Details zu H264 AVC
MP4A-LATM RFC 6416 Siehe Abschnitt 5.1.3 finden Sie weitere Informationen zu AAC und seinen Varianten.
H263–1998 RFC 3551
RFC 4629
RFC 2190
Siehe Abschnitt 5.1.8 für Details zu H263
H263–2000 RFC 4629 Siehe Abschnitt 5.1.8 für Details zu H263
Logo: AMR RFC 4867 Siehe Abschnitt 5.1.3 für Details zu AMR-NB
AMR-WB RFC 4867 Siehe Abschnitt 5.1.3 für Details zu AMR-WB
MP4V-ES RFC 6416 Siehe Abschnitt 5.1.8 für Details zu MPEG-4 SP
MPEG4-generisch RFC 3640 Siehe Abschnitt 5.1.3 finden Sie weitere Informationen zu AAC und seinen Varianten.
MP2T RFC 2250 Weitere Informationen findest du im Abschnitt MPEG-2 Transport Stream unter "HTTP Live Streaming"

5.8. Sichere Medien

Ob Geräteimplementierungen die sichere Videoausgabe unterstützen und in der Lage sind, sichere Oberflächen unterstützen:

  • [C-1-1] MÜSSEN die Unterstützung für Display.FLAG_SECURE erklären.

Wenn in Geräteimplementierungen die Unterstützung von Display.FLAG_SECURE und der Support gemeldet werden Wireless Display Protocol, nutzen sie:

  • [C-2-1] MÜSSEN den Link mit einem kryptografisch starken Mechanismus wie als HDCP 2.x oder höher für die Bildschirme, die über WLAN-Protokolle verbunden sind wie Miracast.

Wenn Geräteimplementierungen Unterstützung für Display.FLAG_SECURE und unterstützen kabelgebundene externe Bildschirme:

  • [C-3-1] MUSS HDCP 1.2 oder höher für alle angeschlossenen externen Bildschirme unterstützen. über einen für den Nutzer zugänglichen kabelgebundenen Port.

5.9. MIDI (Musical Instrument Digital Interface)

Wenn Geräteimplementierungen die Unterstützung der Funktion android.software.midi melden über das android.content.pm.PackageManager Klasse:

  • [C-1-1] MUSS MIDI über alle MIDI-fähigen Hardwaretransporte für für die generische Nicht-MIDI-Konnektivität bereitgestellt wird. Solche Transporte sind:

  • [C-1-2] MUSS die MIDI-Softwareübertragung zwischen Apps unterstützen. (virtuelle MIDI-Geräte)

  • [C-1-3] MÜSSEN libamidi.so (native MIDI-Unterstützung) enthalten

  • SOLLTEN MIDI-over-USB-Peripheriemodus-Modus unterstützen, Abschnitt 7.7.

5.10. Professionelles Audio

Wenn Geräteimplementierungen eine Funktionsunterstützung melden android.hardware.audio.pro über die android.content.pm.PackageManager Klasse:

  • [C-1-1] MÜSSEN die Unterstützung für diese Funktion melden. android.hardware.audio.low_latency

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-2] MÜSSEN den durchgehenden Round-Trip-Ton haben. die Latenz, die Latenz Anforderungen für FEATURE_AUDIO_PRO gemäß Definition in Abschnitt 5.6 Audiolatenz von 25 Millisekunden oder weniger über mindestens einem unterstützten Typ Pfad.

Neue Anforderungen beenden

  • [C-1-3] MUSS einen oder mehrere USB-Ports haben, die den USB-Hostmodus und USB unterstützen. Peripheriemodus.
  • [C-1-4] MÜSSEN die Unterstützung für Funktion android.software.midi melden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-5] MUSS die Anforderungen erfüllen Latenzen und USB-Audio Anforderungen an die Latenz mithilfe der Natives Audio-Audio API und AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

Neue Anforderungen beenden

  • [C-1-6] MUSS eine Latenz für die kalte Ausgabe von 200 Millisekunden oder weniger haben.
  • [C-1-7] MÜSSEN eine Kalteingabelatenz von maximal 200 Millisekunden haben.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-8] MUSS eine durchschnittliche Tap-to-Ton-Latenz von 80 Millisekunden oder weniger haben über mindestens 5 Messungen über den Datenpfad zwischen Lautsprecher und Mikrofon.
  • [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die im Abschnitt definierten Latenzen zu erfüllen 5.6 Audiolatenz von 20 Millisekunden oder weniger, über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden über den Weg vom Lautsprecher zum Mikrofon.
  • [C-SR-2] wird dringend empfohlen, die Pro Audio-Anforderungen für Kontinuierliche Umlauf-Audiolatenz, Cold-Input-Latenz und Cold-Ausgabe Latenz- und USB-Audioanforderungen bei Verwendung der AAudio Native Audio API über den MMAP-Pfad.
  • [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, ein konsistentes CPU-Level bereitzustellen bei aktivem Audio und schwankender CPU-Auslastung. Dies sollte getestet werden, mit der Android-App SynthMark. SynthMark nutzt einen Software-Synthesizer, der auf einem simulierten Audio-Framework ausgeführt wird. die die Systemleistung misst. Weitere Informationen finden Sie in der SynthMark-Dokumentation finden Sie eine Erläuterung der Benchmarks. SynthMark ausgeführt werden muss, „Automatisierter Test“ und folgende Ergebnisse erzielen:

    • Stimmmarke.90 >= 32 Stimmen
    • Latenzmark.Fixed.little <= 15 ms
    • Latenzmark.dynamic.little <= 50 ms
  • SOLLTEN die Ungenauigkeit der Audiouhr und die Abweichung gegenüber der Standardzeit minimieren.

  • SOLLTEN die Abweichung des Audiotakts relativ zur CPU minimieren: CLOCK_MONOTONIC wenn beide aktiv sind.

  • SOLLTEN die Audiolatenz über geräteinterne Transducer minimieren.

  • SOLLTEN die Audiolatenz im Vergleich zu digitalen USB-Audioquellen minimieren.

  • SOLLTEN die Messungen der Audiolatenz für alle Pfade dokumentieren.

  • SOLLTEN Sie den Jitter bei den Callback-Eingabezeiten für die Beendigung des Audiopuffers minimieren, da wirkt sich auf den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback aus.

  • SOLLTEN bei normaler Nutzung mit der gemeldeten Latenz keine Audiostörungen auftreten.

  • SOLLTEN keinen Unterschied bei der kanalübergreifenden Latenz haben.

  • SOLLTEN die durchschnittliche MIDI-Latenz für alle Transporte minimieren.

  • SOLLTEN die MIDI-Latenzvariabilität unter Last (Jitter) bei allen Transporten minimieren.

  • SOLLTEN für alle Transporte genaue MIDI-Zeitstempel angeben.

  • SOLLTEN Störungen des Audiosignals über geräteinterne Wandler, einschließlich der Periode direkt nach dem Kaltstart.

  • SOLLTE 0 Audiotaktdifferenz zwischen den Ein- und Ausgabeseiten des wenn beide aktiv sind. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher des Geräts oder der Audioanschluss und Ausgabe.

  • SOLLTE Callbacks für die Beendigung des Audiopuffers auf der Ein- und Ausgabeseite verarbeiten. der entsprechenden Endpunkte im selben Thread, wenn beide aktiv sind, und direkt nach der Rückgabe des Eingabe-Callbacks den Ausgabe-Callback. Oder Wenn die Callbacks nicht im selben Thread verarbeitet werden können, geben Sie den Parameter kurz nach der Eingabe des Eingabe-Callbacks übergeben, um den um ein einheitliches Timing der Ein- und Ausgabeseite zu gewährleisten.

  • SOLLTEN den Phasenunterschied zwischen der HAL-Audiozwischenspeicherung für die Eingabe minimieren. und Ausgabeseiten der entsprechenden Endpunkte.

  • SOLLTEN die Berührungslatenz minimieren.

  • SOLLTEN Sie die Schwankungen der Berührungslatenz unter Last (Jitter) minimieren.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

Neue Anforderungen beenden

Wenn Geräte eine 3,5-mm-Audiobuchse mit 4 Kabeln enthalten, ist Folgendes zu beachten:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-2-1] MUSS eine durchschnittliche Continuous Round-Trip-Audiolatenz haben, wie in Abschnitt 5.6 Audiolatenz von 20 Millisekunden oder weniger, über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden im den Pfad der Audiobuchse mithilfe eines Audio-Loopback-Dongle.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen beenden

Wenn Geräte keine 3,5-mm-Audiobuchse mit 4 Kabeln und keine verfügen über einen oder mehrere USB-Ports, die den USB-Hostmodus unterstützen. Sie:

  • [C-3-1] MÜSSEN die USB-Audioklasse implementieren.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-3-2] MUSS eine durchschnittliche Continuous Round-Trip-Audiolatenz von 25 Millisekunden oder weniger, über 5 Messungen mit einer mittleren absoluten Abweichung weniger als 5 Millisekunden über den USB-Hostmodus-Port bei Verwendung der USB-Audioklasse (Dies kann mit einem USB-3,5-mm-Adapter und einem Audio-Loopback gemessen werden. oder eine USB-Audioschnittstelle mit Patchkabeln verwenden, Ein- und Ausgaben).
  • [C-SR-6] WIRDEN DRINGEND empfohlen, die gleichzeitige E/A für bis zu 8 Kanäle zu unterstützen in jede Richtung, eine Abtastrate von 96 kHz und eine Tiefe von 24 Bit oder 32 Bit, wenn verwendet mit USB-Audio-Peripheriegeräten, die diese Anforderungen ebenfalls erfüllen.
  • [C-SR-7] EMPFOHLEN, diese Gruppe von Anforderungen zu erfüllen, das native AAudio-Audio-API über den MMAP-Pfad.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräteimplementierungen einen HDMI-Port enthalten, ist Folgendes erforderlich:

  • SOLLTEN die Ausgabe in Stereo und acht Kanäle mit 20-Bit oder 24-Bit-Tiefe und 192 kHz ohne Bittiefenverlust oder -resampling, in mindestens einer Konfiguration.

Neue Anforderungen beenden

5:11. Für unverarbeitet erfassen

Android bietet Unterstützung für die Aufzeichnung von unverarbeiteten Audioinhalten über die android.media.MediaRecorder.AudioSource.UNPROCESSED Audioquelle. In OpenSL ES, kann über die Aufnahmevoreinstellung SL_ANDROID_RECORDING_PRESET_UNPROCESSED

Wenn die Geräteimplementierung eine unverarbeitete Audioquelle unterstützen soll, Drittanbieter-Apps zur Verfügung stehen,

  • [C-1-1] MÜSSEN den Support über android.media.AudioManager melden. Property PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

  • [C-1-2] MÜSSEN annähernd flache Amplitude-gegen-Frequenz aufweisen. im mittleren Frequenzbereich, genauer gesagt ±10 dB von 100 Hz bis 7.000 Hz für jedes Mikrofon, das für die Aufzeichnung der unverarbeiteten Audioquelle.

  • [C-1-3] MUSS die Amplitudenwerte in der niedrigen Frequenz von ±20 dB von 5 z bis 100 Hz im Vergleich zu für jedes Mikrofon, das für die Aufnahme verwendet wird, unverarbeitete Audioquelle.

  • [C-1-4] MUSS Amplitudenpegel bei hoher Frequenz von ±30 dB von 7.000 Hz bis 22 kHz im Vergleich zum für jedes Mikrofon, das für die Aufnahme verwendet wird, unverarbeitete Audioquelle.

  • [C-1-5] MÜSSEN die Empfindlichkeit der Audioeingabe auf eine sinusoidale 1.000-Hz-Angabe einstellen. Tonquelle, die bei 94 dB Schalldruckpegel (SPL) wiedergegeben wird, ergibt eine Antwort mit RMS von 520 für 16-Bit-Samples (oder -36 dB Full Scale für Gleitkomma/Doppel) Precision-Samples) für jedes Mikrofon, das für die Aufzeichnung der nicht verarbeiteten Audioquelle.

  • [C-1-6] MUSS für jedes einzelne Mikrofon, das zur Aufzeichnung der unverarbeiteten Audioquelle verwendet wird. (der SNR-Wert wird als Differenz zwischen 94 dB Schalldruckpegel und Äquivalent gemessen. SPL des Selbstrauschens, A-gewichtet).

  • [C-1-7] MUSS eine insgesamte harmonische Verzerrung (THD) haben, die kleiner als sein darf als 1% für 1 kHz bei 90 dB Schalldruckpegel bei jedem Mikrofon, das für Folgendes verwendet wird: Aufzeichnung der unverarbeiteten Audioquelle.

  • [C-1-8] DÜRFEN keine andere Signalverarbeitung haben (z. B. Automatische Verstärkung). Steuerung, High-Pass-Filter oder Echo-Unterdrückung) im Pfad außer einem um das Level auf den gewünschten Bereich zu bringen. Mit anderen Worten:

    • [C-1-9] Wenn in der Architektur eine Signalverarbeitung für deaktiviert werden und eine Verzögerung von null oder zusätzliche Latenz zum Signalpfad.
    • [C-1-10] Der Levelmultiplikator darf zwar im Pfad enthalten sein, DARF aber NICHT oder Latenz im Signalpfad verursachen.

Alle Schallpegelmessungen erfolgen direkt neben dem zu testenden Mikrofon. Bei mehreren Mikrofonkonfigurationen gelten diese Anforderungen für Mikrofons verwenden.

Wenn in der Geräteimplementierung android.hardware.microphone deklariert wird, aber nicht unterstützen unverarbeitete Audioquellen:

  • [C-2-1] MUSS null für AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) zurückgeben. API-Methode, um die fehlende Unterstützung korrekt anzuzeigen.
  • [C-SR-1] wird weiterhin dringend empfohlen, möglichst viele der Anforderungen zu erfüllen. als Signalpfad für die unverarbeitete Aufzeichnungsquelle.

5:12. HDR-Video

Android 13 unterstützt die HDR-Technologien, die in einem der folgenden Dokumente beschrieben werden.

Pixelformat

Wenn ein Videodecoder bewirbt, dass COLOR_FormatYUVP010 unterstützt wird, dann gilt:

  • [C-1-1] MÜSSEN das P010-Format für CPU-Read unterstützen (ImageReader, MediaImage, ByteBuffer). In Android 13 wird P010 gelockert, um willkürliche Schritte für das Y zuzulassen. und UV-Flugzeugen.

  • [C-1-2] Der P010-Ausgabepuffer MUSS von der GPU abgetastet werden können (wenn mit GPU_SAMPLING-Nutzung zugewiesen). Dies ermöglicht die GPU-Zusammensetzung und Tone Mapping durch Apps.

Wenn ein Videodecoder COLOR_Format32bitABGR2101010 unterstützt, geschieht Folgendes:

  • [C-2-1] MÜSSEN das RGBA_1010102-Format für die Ausgabeoberfläche und CPU-lesbar (ByteBuffer-Ausgabe).

Wenn ein Video-Encoder die Unterstützung für COLOR_FormatYUVP010 bewirbt, geschieht Folgendes:

  • [C-3-1] MUSS das P010-Format für die Eingabeoberfläche und das Format „CPU-beschreibbar“ unterstützen (ImageWriter, MediaImage, ByteBuffer) eingeben.

Wenn ein Video-Encoder die Unterstützung für COLOR_Format32bitABGR2101010 bewirbt, geschieht Folgendes:

  • [C-4-1] MUSS das RGBA_1010102-Format für Eingabeoberfläche und CPU-beschreibbar unterstützen (ImageWriter, ByteBuffer) ein. Hinweis: Zwischen verschiedenen Übertragungen wechseln ist für Encoder NICHT erforderlich.

Anforderungen für HDR-Aufnahmen

Geräteimplementierungen für alle Video-Encoder, die HDR-Profile unterstützen:

  • [C-5-1] DARF NICHT davon ausgehen, dass die HDR-Metadaten präzise sind. Beispiel: Der Parameter könnte ein codierter Frame Pixel jenseits der maximalen Leuchtdichte aufweisen. ist das Histogramm möglicherweise nicht repräsentativ für den Frame.

  • MÜSSEN dynamische HDR-Metadaten aggregieren, um geeignete statische HDR-Metadaten zu generieren für codierte Streams verwenden, und sie sollten am Ende jedes Streams ausgegeben werden. Codierungssitzung.

Wenn Geräteimplementierungen HDR-Aufnahmen über die CamcorderProfile APIs unterstützen dann:

  • [C-6-1] MUSS HDR-Aufnahmen auch über die Camera2 APIs unterstützen.

  • [C-6-2] MUSS mindestens einen hardwarebeschleunigten Videoencoder für unterstützt.

  • [C-6-3] MUSS mindestens die HLG-Aufnahme unterstützen.

  • [C-6-4] MUSS das Schreiben der HDR-Metadaten unterstützen (falls für HDR verfügbar) Technologie) in die aufgezeichnete Videodatei übertragen. Für AV1, HEVC und DolbyVision Das bedeutet, die Metadaten in den codierten Bitstream aufzunehmen.

  • [C-6-5] MUSS P010 und COLOR_FormatYUVP010 unterstützen.

  • [C-6-6] MUSS die Tonzuordnung für HDR zu SDR standardmäßig unterstützen hardwarebeschleunigter Decoder für das erfasste Profil. Mit anderen Worten: Wenn ein Gerät HDR10+ HEVC aufnehmen kann, MUSS der Standard-HEVC-Decoder in der Lage sein, um den aufgezeichneten Stream in SDR zu decodieren.

Anforderungen für die HDR-Bearbeitung

Wenn auf Geräten Videoencoder eingesetzt werden, die die HDR-Bearbeitung unterstützen, Sie:

  • zum Generieren der HDR-Metadaten sollte die Latenz minimal sein, und SOLLTEN anmutig mit Situationen umgehen, in denen Metadaten für einige und nicht für andere. Diese Metadaten SOLLTEN präzise sein (z. B. stellen die tatsächliche Leuchtdichte von Spitzenwerten und das Histogramm des Frames dar.

Wenn die Geräteimplementierung Codecs umfasst, die FEATURE_HdrEditing unterstützen, dann: diese Codecs:

  • [C-7-1] MUSS mindestens ein HDR-Profil unterstützen.

  • [C-7-2] MUSS FEATURE_HdrEditing für alle HDR-Profile unterstützen, die von Codec angelangt. Mit anderen Worten, sie MÜSSEN die Erstellung von HDR-Metadaten unterstützen, wenn nicht für alle unterstützten HDR-Profile vorhanden, die HDR-Metadaten verwenden.

  • [C-7-3] MUSS die folgenden Video-Encoder-Eingabeformate unterstützen, die das decodierte HDR-Signal beibehalten:

    • RGBA_1010102 (bereits in der Zieltransferkurve) für beide Eingaben und ByteBuffer und MUSS die Unterstützung für COLOR_Format32BitABGR2101010.

Wenn die Geräteimplementierung Codecs enthält, die FEATURE_HdrEditing unterstützen, dann gilt: das Gerät:

  • [C-7-4] MÜSSEN die Unterstützung für die Erweiterung EXT_YUV_target OpenGL anbieten.

6. Kompatibilität von Entwicklertools und -optionen

6.1 Entwicklertools

Geräteimplementierungen:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-0-2] MÜSSEN ADB gemäß der Dokumentation im Android SDK und in der Shell unterstützen. die im AOSP bereitgestellt werden und die von App-Entwicklern verwendet werden können, einschließlich dumpsys, cmd statsund Simpleperf

Neue Anforderungen beenden

  • [C-0-11] MUSS den Shell-Befehl cmd testharness unterstützen. Upgrade wird durchgeführt früheren Android-Versionen ohne eine persistente Datensperre KANN von C-0-11 ausgenommen werden.
  • [C-0-3] Dürfen das Format oder den Inhalt des Gerätesystems NICHT verändern -Ereignisse (batterystats, diskstats, fingerabdruck, grafikstats, netstats, Notification, procstats), die über den Befehl dumpsys protokolliert wurden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-0-10] MÜSSEN die folgenden Ereignisse ohne Auslassung aufnehmen und durchführen. und für den Shell-Befehl cmd stats und den System-API-Klasse StatsManager.
    • AktivitätsforegroundState geändert
    • Anomalie erkannt
    • AppBreadcrumbReported
    • App-Absturz aufgetreten
    • AppStartAuftreten
    • Akkustand geändert
    • Energiesparmodus geändert
    • BleScanResultReceived
    • BleScanStateGeändert
    • Ladestatus geändert
    • DeviceIdleModeStateGeändert
    • Dienststatus im Vordergrund geändert
    • GpsScanStateGeändert
    • InputDeviceUsageReported
    • JobStateChanged (Jobstatus geändert)
    • Mit der Tastatur konfiguriert
    • KeyboardSystemsEventReported
    • PluggedStateChanged
    • ScheduledJobStateGeändert
    • Bildschirmstatus geändert
    • Synchronisierungsstatus geändert
    • SystemElapsedRealtime
    • Touchpad-Nutzung
    • UidProcessStateGeändert
    • WakelockStateGeändert
    • Wakeup-Alarm aufgetreten
    • WifiLockStateGeändert
    • WifiMulticastLockStateGeändert
    • WifiScanStateGeändert

Neue Anforderungen beenden

  • [C-0-4] MÜSSEN der geräteseitige ADB-Daemon standardmäßig inaktiv sein und Es muss einen für den Nutzer zugänglichen Mechanismus zum Aktivieren von Android Debug Brücke.
  • [C-0-5] MUSS sicheres ADB unterstützen. Android unterstützt sichere ADB. „Secure adb“ aktiviert ADB auf bekannten authentifizierten Hosts.
  • [C-0-6] MÜSSEN einen Mechanismus bereitstellen, der die Verbindung von adb über eine Hostcomputer. Im Detail:

Wenn Geräteimplementierungen ohne USB-Port den Peripheriemodus unterstützen, gilt Folgendes:

  • [C-3-1] MÜSSEN ADB über ein lokales Netzwerk (z. B. Ethernet) implementieren. oder WLAN).
  • [C-3-2] MÜSSEN Treiber für Windows 7, 8 und 10 bereitstellen, Entwicklern über das ADB-Protokoll eine Verbindung zum Gerät herzustellen.

Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet, verwenden sie Folgendes:

  • [C-4-1] MUSS die Methode AdbManager#isAdbWifiSupported() haben true zurückgeben.

Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet verwenden und über mindestens eine Kamera verfügt, werden sie:

  • [C-5-1] MUSS die Methode AdbManager#isAdbWifiQrSupported() haben true zurückgeben.

  • Dalvik Debug Monitor-Dienst (ddms)

    • [C-0-7] MUSS alle im Android SDK dokumentierten ddms-Funktionen unterstützen. Da ddms ADB verwendet, sollte die Unterstützung für ddms standardmäßig inaktiv sein, aber MÜSSEN immer unterstützt werden, wenn der Nutzer die Android Debug Bridge aktiviert hat. wie oben beschrieben.
  • SysTrace

    • [C-0-9] MUSS das systrace-Tool unterstützen, wie im Android SDK dokumentiert. Systrace muss standardmäßig inaktiv sein und es MÜSSEN ein Nutzer zugänglich sein. um Systrace zu aktivieren.
  • Perfetto

    • [C-SR-1] wird dringend empfohlen, /system/bin/perfetto Binärdatei, die der cmdline entspricht Perfetto-Dokumentation.
    • [C-SR-2] Das Perfetto-Binärprogramm wird UNBEDINGT empfohlen, als Eingabe ein protobuf-Konfiguration, die dem in folgendem Dokument definierten Schema entspricht: Perfetto-Dokumentation.
    • [C-SR-3] Das Perfetto-Binärprogramm wird UNBEDINGT empfohlen, als Ausgabe einen Wert zu schreiben: protobuf-Trace zu erstellen, das dem in Perfetto-Dokumentation.
    • [C-SR-4] Es wird dringend empfohlen, über das Perfetto-Binärprogramm mindestens den in der Perfetto-Dokumentation beschriebenen Datenquellen.
  • Low Memory Killer

    • [C-0-12] MUSS ein LMK_KILL_OCCURRED_FIELD_NUMBER-Atom in die statsd-Protokolls erhalten, wenn eine App durch den Low Memory Killer beendet wird.
  • Test-Harnischmodus Wenn Geräteimplementierungen den Shell-Befehl cmd testharness und cmd testharness enable ausführen, wird Folgendes ausgeführt:

  • Informationen zur Arbeit mit GPUs

    Geräteimplementierungen:

    • [C-0-13] MÜSSEN den Shell-Befehl dumpsys gpu --gpuwork implementieren, um Die aggregierten GPU-Arbeitsdaten, die vom power/gpu_work_period-Kernel zurückgegeben werden Tracepoint oder zeigen Sie keine Daten an, wenn der Tracepoint nicht unterstützt wird. Der AOSP Implementierung ist frameworks/native/services/gpuservice/gpuwork/.

Wenn Geräteimplementierungen die Unterstützung von Vulkan 1.0 oder höher über das android.hardware.vulkan.version-Funktions-Flags. Sie:

  • [C-1-1] MÜSSEN dem App-Entwickler eine Option zum Aktivieren/Deaktivieren anbieten. GPU-Debug-Ebenen.
  • [C-1-2] MÜSSEN, wenn GPU-Debug-Ebenen aktiviert sind, Layers in Bibliotheken, die von externen Tools bereitgestellt werden (d.h. nicht Teil der Plattform oder Anwendungspaket) in den debug-fähigen Anwendungen Basisverzeichnis zu vkEnumerateInstanceLayerProperties() unterstützen und vkCreateInstance() API-Methoden.

6.2 Entwickleroptionen

Android bietet Unterstützung für Entwickler bei der Konfiguration von Anwendungen entwicklungsbezogene Einstellungen.

Geräteimplementierungen MÜSSEN für eine einheitliche Nutzererfahrung Entwickleroptionen:

  • [C-0-1] MÜSSEN die android.settings.APPLICATION_DEVELOPMENT_SETTINGS zur Anzeige von Einstellungen für die Anwendungsentwicklung. Die vorgelagerte Android- Bei der Implementierung wird das Menü "Entwickleroptionen" standardmäßig ausgeblendet und Nutzer können die Entwickleroptionen starten, indem Sie sieben (7)-mal unter Settings > Über das Gerät > Build-Nummer.
  • [C-0-2] MÜSSEN die Entwickleroptionen standardmäßig ausblenden.
  • [C-0-3] MÜSSEN einen klaren Mechanismus bereitstellen, der keine Präferenz einer Drittanbieter-App statt einer anderen, damit der Entwickler Optionen. MÜSSEN ein öffentlich sichtbares Dokument oder eine Website vorgelegt werden, in der beschrieben wird, Entwickleroptionen aktivieren Dieses Dokument oder diese Website MUSS verlinkbar sein von in den Android SDK-Dokumenten.
  • SOLLTE eine visuelle Benachrichtigung an den Nutzer eingeblendet werden, wenn der Entwickler Die Optionen sind aktiviert und die Sicherheit des Nutzers ist wichtig.
  • KÖNNEN den Zugriff auf das Menü "Entwickleroptionen" vorübergehend einschränken, indem Sie Ausblenden oder Deaktivieren des Menüs, um Ablenkungen zu vermeiden, wenn das Menü die Sicherheit der Nutzenden angeht.

7. Hardwarekompatibilität

Beinhaltet ein Gerät eine bestimmte Hardwarekomponente, die über eine entsprechende API für Drittanbieter-Entwickler:

  • [C-0-1] In der Geräteimplementierung MUSS die API wie in der Android SDK-Dokumentation beschrieben.

Wenn eine API im SDK mit einer Hardwarekomponente interagiert, die als optional angegeben wird, und bei der Implementierung auf dem Gerät diese Komponente nicht vorhanden ist:

  • [C-0-2] Vollständige Klassendefinitionen (wie im SDK dokumentiert) für die Komponente APIs MÜSSEN weiterhin angezeigt werden.
  • [C-0-3] Das Verhalten der API MÜSSEN in angemessenen Mode.
  • [C-0-4] API-Methoden MÜSSEN NULL-Werte zurückgeben, wenn dies laut SDK zulässig ist. Dokumentation.
  • [C-0-5] API-Methoden MÜSSEN No-Op-Implementierungen von Klassen zurückgeben, bei denen Nullwerte vorliegen. sind laut SDK-Dokumentation nicht zulässig.
  • [C-0-6] API-Methoden DÜRFEN KEINE Ausnahmen auslösen, die nicht im SDK dokumentiert sind Dokumentation.
  • [C-0-7] Geräteimplementierungen MÜSSEN immer die korrekte Hardware melden Konfigurationsinformationen über die getSystemAvailableFeatures()- und hasSystemFeature(String)-Methoden für die android.content.pm.PackageManager für denselben Build-Fingerabdruck.

Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telefonie. API: Auch auf anderen Geräten als Smartphones müssen diese APIs in angemessenem Maße implementiert werden. im Nullkommanichts.

7.1. Display und Grafik

Android umfasst Einrichtungen, die App-Assets und die Benutzeroberfläche automatisch anpassen die für das Gerät geeignet sind, um sicherzustellen, dass Drittanbieter-Apps laufen gut auf einer Vielzahl von Hardware-Displays und -Konfigurationen. Eine Die Android-kompatible Anzeige ist ein Bildschirm, auf dem alle Android-Entwickler: Bildschirmkompatibilität Übersicht angezeigt wird, Abschnitt (7.1) und die zugehörigen Unterabschnitte sowie alle weiteren Gerätetypen, spezifischen Verhaltensweisen, die in Abschnitt 2 dieser CDD

Geräteimplementierungen:

  • [C-0-1] MÜSSEN Anwendungen von Drittanbietern standardmäßig nur auf Mit Android kompatible Displays.

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

  • physische diagonale Größe. Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Teils des Displays.
  • density definieren. Die Anzahl der von einer linearen Linie eingeschlossenen Pixel Horizontale oder vertikale Spanne von 1", ausgedrückt als Pixel pro Zoll (ppi oder dpi) Wenn ppi- und dpi-Werte aufgeführt sind, Die DPI sowohl horizontal als auch vertikal müssen im angegebenen Bereich liegen.
  • Seitenverhältnis. Das Verhältnis der Pixel der längeren Seite zur kürzere Dimension des Bildschirms. Ein Display mit 480 x 854 Pixeln 854/480 = 1, 779 oder ungefähr "16:9".
  • dichteunabhängige Pixel (dp): Eine virtuelle Pixeleinheit, normalisiert auf eine Bildschirmdichte von 160 Für eine gewisse Dichte d und die Anzahl der Pixel p, die Anzahl der dichteunabhängigen Pixel dp, Berechnung: dp = (160 ÷ d) × p.

7.1.1 Bildschirmkonfiguration

7.1.1.1 Displaygröße und -form

Das Android-UI-Framework unterstützt eine Vielzahl verschiedener logischer Bildschirmlayouts Größen und ermöglicht Anwendungen, den Bildschirm der aktuellen Konfiguration abzufragen Layoutgröße über Configuration.screenLayout mit dem SCREENLAYOUT_SIZE_MASK und Configuration.smallestScreenWidthDp.

Geräteimplementierungen:

  • [C-0-1] MÜSSEN die richtige Layoutgröße für die Configuration.screenLayout gemäß der Definition in der Android SDK-Dokumentation. Insbesondere müssen Geräteimplementierungen die korrekten logischen Dichte-unabhängige Pixel-Bildschirmabmessungen (dp):

    • Geräte, bei denen Configuration.uiMode auf einen anderen Wert als UI_MODE_TYPE_WATCH abruft und eine small-Größe für die Configuration.screenLayout muss mindestens 426 dp x 320 dp haben.
    • Geräte, die eine Größe von normal für Configuration.screenLayout melden, MUSS mindestens 480 dp x 320 dp haben.
    • Geräte, die eine Größe von large für Configuration.screenLayout melden, MUSS mindestens 640 dp x 480 dp haben.
    • Geräte, die eine Größe von xlarge für Configuration.screenLayout melden, MUSS mindestens 960 dp x 720 dp haben.
  • [C-0-2] MÜSSEN die Bewerbungen korrekt berücksichtigen angegeben Unterstützung für Bildschirmgrößen durch den <supports-screens> in der Datei "AndroidManifest.xml", wie beschrieben in der Android SDK-Dokumentation.

  • KÖNNEN die Android-kompatiblen Bildschirme mit abgerundeten Ecken angezeigt werden.

Wenn Geräteimplementierungen Bildschirme unterstützen, die UI_MODE_TYPE_NORMAL-Größenkonfiguration und verwenden Sie physische Bildschirme mit abgerundeten Ecken zum Rendern dieser Bildschirme, Sie:

  • [C-1-1] MÜSSEN sicherstellen, dass mindestens eine der folgenden Anforderungen für jede Anzeige erfüllt ist:

    • Der Radius der abgerundeten Ecken ist kleiner oder gleich 38 dp.
    • Wenn ein Feld mit 18 dp mal 18 dp an jeder Ecke des logischen angezeigt wird, ist mindestens ein Pixel jedes Feldes auf dem Bildschirm sichtbar.
  • SOLLTEN Sie die Nutzerfreundlichkeit einbeziehen, um mit der von rechteckigen Ecken.

Wenn in Geräteimplementierungen nur die NO_KEYS-Tastaturkonfiguration unterstützt wird, und möchten die Unterstützung für den UI-Modus „UI_MODE_TYPE_NORMAL“ melden Konfiguration:

  • [C-4-1] MUSS ein Layout von mindestens Mindestens 596 dp x 384 dp

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Ob Geräteimplementierungen einen oder mehrere Android-kompatible Anzeigebereiche enthalten die faltbar sind oder ein faltbares Scharnier zwischen mehreren Android-kompatible Anzeigebereiche und stellen diese Anwendungen:

  • [C-4-1] MÜSSEN die richtige Version der Fenstermanager-Erweiterungen implementieren. API-Ebene, wie unter WindowManager-Erweiterungen beschrieben.

Neue Anforderungen beenden

7.1.1.2 Bildschirmseitenverhältnis

Dieser Abschnitt wurde in Android 14 gelöscht.

7.1.1.3 Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe von logischen Standarddichten, um Anwendungsentwickler zielen auf Anwendungsressourcen ab.

Geräteimplementierungen:

  • [C-0-1] MÜSSEN eine der aufgeführten Android-Framework-Dichten melden. am DisplayMetrics über die DENSITY_DEVICE_STABLE API Dieser Wert muss für jedes physische Display ein statischer Wert sein. Das Gerät KANN jedoch Anderes DisplayMetrics.density melden entsprechend den vom Nutzer vorgenommenen Änderungen an der Anzeigekonfiguration (für (z. B. Anzeigegröße), die nach dem ersten Start festgelegt wird.

  • SOLLTE die numerisch Standard-Android-Framework-Dichte definieren der physischen Dichte des Bildschirms am nächsten ist, oder einen Wert, der der Äquivalente des Sichtfelds von Handheld-Geräten.

Wenn Geräteimplementierungen die Anzeigegröße des Geräts ändern,

  • [C-1-1] DÜRFEN den Bildschirm NICHT auf mehr als 1,5-fach skalieren DENSITY_DEVICE_STABLE oder eine Bildschirmgröße von unter 320 dp (entspricht an den Ressourcenqualifizierer sw320dp übergeben, je nachdem, was zuerst eintritt.
  • [C-1-2] DARF NICHT das Display skalieren kleiner als das 0,85-Fache des DENSITY_DEVICE_STABLE ist.
  • Um eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen zu gewährleisten, wird EMPFOHLEN, die folgende Skalierung der nativen Displayoptionen zur Verfügung steht (unter Einhaltung der Beschränkungen) oben angegeben) <ph type="x-smartling-placeholder">
      </ph>
    • Klein: 0,85x
    • Standardeinstellung: 1x (Skalierung für native Displayanzeige)
    • Groß: 1,15x
    • Größer: 1,3x
    • Größte 1,45x

7.1.2 Messwerte anzeigen

Wenn Geräte die Android-kompatiblen Bildschirme oder auf die mit Android kompatiblen Bildschirmen übertragen:

Wenn Geräteimplementierungen keinen eingebetteten Bildschirm oder keine Videoausgabe enthalten, Sie:

  • [C-2-1] MÜSSEN die richtigen Werte des Android-kompatiblen Bildschirms melden wie in der android.util.DisplayMetrics API definiert für den emulierten Standardwert view.Display.

7.1.3 Displayausrichtung

Geräteimplementierungen:

  • [C-0-1] MÜSSEN angeben, welche Bildschirmausrichtungen sie unterstützen. (android.hardware.screen.portrait und/oder android.hardware.screen.landscape) und MÜSSEN mindestens einen unterstützten Ausrichtung. Beispiel: Ein Gerät mit einer festen Ausrichtung im Querformat (z. B. ein Fernseher oder Laptop), SOLLTEN nur Bericht android.hardware.screen.landscape.
  • [C-0-2] MÜSSEN den richtigen Wert für die aktuelle Ausrichtung, wenn über die android.content.res.Configuration.orientation, android.view.Display.getOrientation() oder andere APIs verwendet werden.

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

  • [C-1-1] MUSS die dynamische Ausrichtung durch Anwendungen im Hoch- oder Querformat unterstützen Ausrichtung. Das heißt, das Gerät muss die Anwendungsanforderung für einen bestimmten Bildschirm respektieren. Ausrichtung.
  • [C-1-2] DÜRFEN die gemeldete Bildschirmgröße oder -dichte beim Ändern der Ausrichtung NICHT ändern.
  • Sie können als Standardeinstellung das Hoch- oder Querformat auswählen.

7.1.4 2D- und 3D-Grafikbeschleunigung

7.1.4.1 OpenGL ES

Geräteimplementierungen:

  • [C-0-1] MÜSSEN die unterstützten OpenGL ES-Versionen (1.1, 2.0, 3.0, 3.1, 3.2) über die verwalteten APIs (z. B. über die GLES10.getString()) und die nativen APIs verwenden.
  • [C-0-2] MÜSSEN die Unterstützung für alle entsprechenden verwalteten APIs und native APIs für jede OpenGL ES-Version, die sie unterstützen möchten.

Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-1] MUSS beide unterstützen OpenGL ES 1.1 sowie 2.0, 3.0 und 3.1, wie gesprochen und detailliert in der Android SDK-Dokumentation.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-SR-1] Wir empfehlen dringend, OpenGL ES 3.1 zu unterstützen.

Neue Anforderungen beenden

  • SOLLTEN OpenGL ES 3.2 unterstützen.

Die OpenGL ES-dEQP-Tests sind in eine Reihe von Testlisten aufgeteilt, die jeweils eine eine zugehörige Datums-/Versionsnummer. Diese befinden sich in der Android-Quellstruktur unter external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt Ein Gerät, das OpenGL ES auf einem selbst angegebenen Level unterstützt, bedeutet, dass es den dEQP-Wert bestehen kann. Tests in allen Testlisten dieser und früheren Stufen.

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

  • [C-2-1] MÜSSEN über die von OpenGL ES verwalteten APIs und nativen APIs andere von ihnen implementierte OpenGL ES-Erweiterungen, und MÜSSEN umgekehrt MÜSSEN, KEINE Erweiterungsstrings melden, die sie nicht unterstützen.
  • [C-2-2] MUSS 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.
  • [C-2-3] MÜSSEN die höchste Version der OpenGL ES dEQP-Tests melden wird über das Funktions-Flag android.software.opengles.deqp.level unterstützt.
  • [C-2-4] MÜSSEN mindestens Version 132383489 (ab 1. März 2020) unterstützen als im Funktions-Flag android.software.opengles.deqp.level angegeben.
  • [C-2-5] MÜSSEN alle OpenGL ES dEQP-Tests in den Testlisten für die einzelnen Versionen bestehen. 132383489 und die in der Funktions-Flag „android.software.opengles.deqp.level“ für jeden unterstützten OpenGL ES-Version.
  • [C-SR-2] wird dringend empfohlen, EGL_KHR_partial_update und OES_EGL_image_external Erweiterungen.
  • SOLLTEN Sie genau mit der getString()-Methode melden, unabhängig von Texturen. Komprimierungsformat, das sie unterstützen und das in der Regel anbieterspezifisch ist.

  • SOLLTEN die EGL_IMG_context_priority und EGL_EXT_protected_content Erweiterungen.

Wenn in Geräteimplementierungen OpenGL ES 3.0, 3.1 oder 3.2 unterstützt werden, gilt Folgendes:

  • [C-3-1] MÜSSEN die entsprechenden Funktionssymbole für diese Versionen in zu den OpenGL ES 2.0-Funktionssymbolen in der libGLESv2.so-Bibliothek hinzugefügt.
  • [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, OES_EGL_image_external_essl3 zu unterstützen .

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

  • [C-4-1] MUSS das gesamte OpenGL ES Android Extension Pack unterstützen.

Wenn die Geräteimplementierung das Android-Erweiterungspaket OpenGL ES in der zugehörigen werden:

  • [C-5-1] MUSS den Support über die android.hardware.opengles.aep identifizieren. Funktions-Flag.

Wenn Geräteimplementierungen Unterstützung für EGL_KHR_mutable_render_buffer bieten Erweiterung haben, können sie:

  • [C-6-1] MUSS auch EGL_ANDROID_front_buffer_auto_refresh unterstützen .
7.1.4.2 Vulkan

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

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

  • [C-SR-1] wird dringend empfohlen, Support für Vulkan 1.3.
  • [C-4-1] DARF KEINE Vulkan-Variante (d.h. die Variante) unterstützen Teil der Vulkan-Kernversion MUSS Null sein).

Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:

  • [C-SR-2] wird dringend empfohlen, Support für Vulkan 1.3.

Die Vulkan-dEQP-Tests sind in mehrere Testlisten aufgeteilt, die jeweils einen das zugehörige Datum bzw. die zugehörige Version. Diese befinden sich in der Android-Quellstruktur unter external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt Ein Gerät, das unterstützt Vulkan auf einer selbst angegebenen Ebene. Dies bedeutet, dass er den dEQP-Wert erreichen kann. Tests in allen Testlisten dieser und früheren Stufen.

Wenn Geräteimplementierungen Vulkan-Unterstützung beinhalten, gilt Folgendes:

  • [C-1-1] MÜSSEN den richtigen Ganzzahlwert mit dem android.hardware.vulkan.level und android.hardware.vulkan.version Funktions-Flags.
  • [C-1-2] MUSS angeben, mindestens ein VkPhysicalDevice für den Vulkan die native API vkEnumeratePhysicalDevices().
  • [C-1-3] MÜSSEN die Vulkan 1.1-APIs für jede der aufgeführten APIs vollständig implementieren. VkPhysicalDevice
  • [C-1-4] MÜSSEN Ebenen aufzählen, die in nativen Bibliotheken mit dem Namen libVkLayer*.so im nativen Bibliotheksverzeichnis des Anwendungspakets. über die nativen Vulkan-APIs vkEnumerateInstanceLayerProperties() und vkEnumerateDeviceLayerProperties().
  • [C-1-5] DARF KEINE Layer aufzählen, die von Bibliotheken außerhalb des Anwendungspaket enthalten oder andere Möglichkeiten zum Verfolgen oder Abfangen des Vulkan API, es sei denn, die Anwendung hat das Attribut android:debuggable als true oder die Metadaten com.android.graphics.injectLayers.enable festgelegt auf true festgelegt.
  • [C-1-6] MÜSSEN alle Erweiterungs-Strings, die von ihnen unterstützt werden, über die Native Vulkan-APIs und umgekehrt DÜRFEN KEINE Erweiterungsstrings melden. die sie nicht richtig unterstützen.
  • [C-1-7] MUSS VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, und VK_KHR_incremental_present.
  • [C-1-8] MÜSSEN die Höchstversion der Vulkan dEQP-Tests melden wird über das Funktions-Flag android.software.vulkan.deqp.level unterstützt.
  • [C-1-9] MUSS mindestens Version 132317953 (vom 1. März 2019) unterstützen als im Funktions-Flag „android.software.vulkan.deqp.level“ aufgeführt.
  • [C-1-10] MÜSSEN alle Vulkan-dEQP-Tests in den Testlisten zwischen Version 132317953 und die Version, die im Funktions-Flag android.software.vulkan.deqp.level.
  • [C-1-11] DARF NICHT die Unterstützung für die VK_KHR_video_queue, die Erweiterungen VK_KHR_video_decode_queue oder VK_KHR_video_encode_queue.
  • [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, VK_KHR_driver_properties zu unterstützen und VK_GOOGLE_display_timing Erweiterungen.
  • [C-1-12] DARF NICHT die Unterstützung für die Erweiterung „VK_KHR_performance_query“ aufzählen.
  • [C-SR-4] EMPFOHLEN, die folgenden Anforderungen zu erfüllen, das Profil Android Baseline 2022.
  • [C-SR-5] WIRD UNBEDINGT EMPFOHLEN, VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory zu unterstützen und VK_EXT_global_priority.
  • [C-SR-6] wird dringend empfohlen, SkiaVk mit HWUI zu verwenden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräteimplementierungen Vulkan-Unterstützung beinhalten, gilt Folgendes:

  • [C-SR-8] wird dringend empfohlen, den Vulkan-Loader nicht zu verändern.
  • [C-1-14] DÜRFEN KEINE Vulkan-Geräteerweiterungen vom Typ „KHR“, „GOOGLE“ oder „ANDROID“ es sei denn, diese Erweiterungen sind im Funktions-Flag „android.software.vulkan.deqp.level“.

Neue Anforderungen beenden

Wenn Geräteimplementierungen Vulkan 1.0 nicht unterstützen, passiert Folgendes:

  • [C-2-1] DÜRFEN KEINE Hinweise auf Vulkan-Features (z.B. android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] DARF KEINE VkPhysicalDevice für die native Vulkan-API aufzählen vkEnumeratePhysicalDevices().

Wenn Geräteimplementierungen Unterstützung für Vulkan 1.1 beinhalten und eines der Hier werden die hier beschriebenen Vulkan-Funktions-Flags beschrieben. Sie:

  • [C-3-1] MÜSSEN die Unterstützung für die externe Semaphore und den Handle SYNC_FD anzeigen und die Erweiterung VK_ANDROID_external_memory_android_hardware_buffer.

  • [C-SR-7] wird dringend empfohlen, die VK_KHR_external_fence_fd Erweiterung für Drittanbieter-Anwendungen und aktivieren die Anwendung um Zaunnutzlasten in eine POSIX-Datei zu exportieren und diese zu importieren Beschreibungen wie beschrieben finden Sie hier.

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 Apps angeben können, dass sie die Hardwarebeschleunigung für 2D-Grafiken unter Fenster- oder Datenansichtsebene durch Verwendung eines Manifest-Tags android:hardwareAccelerated oder direkte API-Aufrufe.

Geräteimplementierungen:

  • [C-0-1] MÜSSEN die Hardwarebeschleunigung standardmäßig aktivieren und Deaktivieren Sie die Hardwarebeschleunigung, wenn der Entwickler dies anfordert, indem Sie android:hardwareAccelerated="false" oder Deaktivieren der Hardwarebeschleunigung direkt über die Android View APIs.
  • [C-0-2] MÜSSEN ein Verhalten zeigen, das mit dem Android SDK-Dokumentation zur Hardwarebeschleunigung

Android enthält ein TextureView-Objekt, mit dem Entwickler hardwarebeschleunigte OpenGL ES-Texturen als Renderingziele in einer UI-Hierarchie.

Geräteimplementierungen:

  • [C-0-3] MÜSSEN die TextureView API unterstützen und angeben, einheitliches Verhalten bei der vorgelagerten Android-Implementierung.
7.1.4.5 Wide-Gamut-Displays

Wenn Geräteimplementierungen Unterstützung für Weitwinkel-Displays durch Configuration.isScreenWideColorGamut(), sie:

  • [C-1-1] MUSS ein farbkalibriertes Display haben.
  • [C-1-2] MÜSSEN über ein Display verfügen, dessen Farbumfang die sRGB-Farbgamut abdeckt. vollständig im CIE-1931-xyY-Bereich.
  • [C-1-3] MÜSSEN über ein Display verfügen, dessen Umfang einen Bereich von mindestens 90% des DCI-P3 im CIE 1931-xyY-Bereich.
  • [C-1-4] MUSS OpenGL ES 3.1 oder 3.2 unterstützen und ordnungsgemäß melden.
  • [C-1-5] MÜSSEN Support für EGL_KHR_no_config_context bewerben, 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 Erweiterungen.
  • [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, GL_EXT_sRGB zu unterstützen.

Umgekehrt gilt: Wenn Geräteimplementierungen keine Wide-Gamut-Displays unterstützen, kann das folgende Gründe haben:

  • [C-2-1] SOLLTEN mindestens 100% des sRGB-Bereichs im xyY-Bereich von CIE 1931 abdecken, Bildschirmfarbgamut ist nicht definiert.

7.1.5 Legacy-App-Kompatibilitätsmodus

Android gibt einen „Kompatibilitätsmodus“ an bei dem das Framework in einem 'normal' [normal] Bildschirmgröße entspricht (320 dp Breite) zugunsten der alten Apps, die nicht für ältere Versionen von Android entwickelt wurden, unabhängig von Bildschirmgröße.

7.1.6 Bildschirmtechnologie

Die Android-Plattform umfasst APIs, mit denen komplexe Anwendungen auf ein Android-kompatibles Display übertragen. Geräte MÜSSEN alle diese Funktionen unterstützen APIs gemäß der Definition im Android SDK, sofern in diesem Dokument nicht ausdrücklich zulässig.

Alle mit Android kompatiblen Displays einer Geräteimplementierung:

  • [C-0-1] MUSS 16-Bit-Farbgrafiken unterstützen können.
  • SOLLTEN Bildschirme unterstützt werden, die 24-Bit-Farbgrafiken unterstützen.
  • [C-0-2] MUSS Animationen rendern können.
  • [C-0-3] MUSS ein Pixel-Seitenverhältnis (PAR) haben zwischen 0,9 und 1,15 liegt. Das Pixel-Seitenverhältnis MUSS also nahe quadratisch sein. (1,0) mit einer Toleranz von 10 bis 15 %.

7.1.7 Sekundäre Displays

Android unterstützt sekundäre, mit Android kompatible Displays, Funktionen zum Teilen von Medien und Entwickler-APIs für den Zugriff auf externe Bildschirme

Wenn Geräteimplementierungen einen externen Bildschirm unterstützen, entweder über ein kabelgebundenes oder drahtlos oder über eine eingebettete zusätzliche Displayverbindung verfügen, geschieht Folgendes:

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

7.2. Eingabegeräte

Geräteimplementierungen:

7.2.1 Tastatur

Wenn Geräteimplementierungen Drittanbieter-Unterstützung beinhalten IME-Anwendungen (Eingabemethoden-Editoren) müssen folgende Voraussetzungen erfüllen:

Geräteimplementierungen:

  • [C-0-1] DÜRFEN KEINE Hardwaretastatur enthalten, die nicht mit einer der Formate angegeben in android.content.res.Configuration.keyboard (QWERTY oder 12-Tasten).
  • SOLLTEN zusätzliche Implementierungen von Softtastaturen beinhalten.
  • KANN eine Hardware-Tastatur enthalten.

7.2.2 Berührungslose Navigation

Android unterstützt das Steuerkreuz, den Trackball und das Rad, berührungslose Navigation.

Geräteimplementierungen:

Wenn Geräteimplementierungen keine berührungslose Navigation haben, kann das folgende Gründe haben:

  • [C-1-1] MÜSSEN eine vernünftige alternative Benutzeroberfläche für die Auswahl und Bearbeitung von Text, kompatibel mit Input Management Engines. Die vorgelagerte Open-Source-Implementierung von Android beinhaltet einen Auswahlmechanismus Geeignet für Geräte ohne berührungsempfindliche Navigationseingaben.

7.2.3 Navigationstasten

Die Startseite, Letzte und Zurück Funktionen, die in der Regel über eine Interaktion mit einer dedizierten physischen Taste bereitgestellt werden oder einen bestimmten Teil des Touchscreens für die Android-App Navigationsparadigma und damit auch Geräteimplementierungen:

  • [C-0-1] MÜSSEN eine Nutzeroption zum Starten installierter Apps anbieten. für die eine Aktivität mit dem <intent-filter> mit ACTION=MAIN und CATEGORY=LAUNCHER oder CATEGORY=LEANBACK_LAUNCHER für Fernsehgerät Implementierungen. Die Home-Funktion SOLLTE der Mechanismus für dieses Nutzerangebot sein.
  • SOLLTEN Schaltflächen für die Funktionen Recents und Zurück bereitstellen.

Wenn die Funktionen „Startbildschirm“, „Letzte“ und „Zurück“ verfügbar sind, geschieht Folgendes:

  • [C-1-1] MUSS mit einer einzigen Aktion (z.B. Tippen, Doppelklick oder wenn eine davon barrierefrei ist.
  • [C-1-2] MÜSSEN deutlich darauf hinweisen, welche Aktion ausgelöst werden würde. für die einzelnen Funktionen. Ein sichtbares Symbol auf der Schaltfläche, das eine Software zeigt auf dem Navigationsleistenteil des Bildschirms klicken oder den Nutzer durch eine Schritt-für-Schritt-Demo-Workflows während der Einrichtung sind Beispiele für einen solchen Hinweis.

Geräteimplementierungen:

  • [C-SR-1] wird dringend empfohlen, nicht den Eingabemechanismus für den Menüfunktion da sie seit Android 4.0 zugunsten der Aktionsleiste eingestellt wird.

  • [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, alle Navigationsfunktionen als stornierbar. „Kündigbar“ ist definiert als die Fähigkeit der Nutzenden, ausgeführt werden (z.B. nach Hause gehen, zurück usw.), wenn der Das Wischen wird nicht über einen bestimmten Grenzwert hinaus aufgehoben.

Wenn Geräteimplementierungen die Menüfunktion bieten, geschieht Folgendes:

  • [C-2-1] MÜSSEN die Überlaufschaltfläche für die Aktion immer dann angezeigt werden, wenn die Aktion Pop-up für das Dreipunkt-Menü ist nicht leer und die Aktionsleiste ist sichtbar.
  • [C-2-2] DÜRFEN die Position des Aktions-Überlauf-Pop-ups NICHT ändern angezeigt durch Auswählen der Überlaufschaltfläche in der Aktionsleiste, aber KANN rendern das Überlauf-Pop-up für Aktionen an einer veränderten Position auf dem Bildschirm, wenn es indem Sie die Menüfunktion auswählen.

Wenn Geräteimplementierungen die Menüfunktion nicht bereitstellen, Kompatibilität:

  • [C-3-1] MUSS die Menüfunktion für Apps verfügbar machen, wenn targetSdkVersion ist kleiner als 10, entweder durch eine physische Taste, einen Softwareschlüssel oder Gesten. Diese Menüfunktion sollte zugänglich sein, sofern sie nicht zusammen mit andere Navigationsfunktionen nutzen.

Wenn Geräte die Unterstützungsfunktion bieten, Sie:

  • [C-4-1] MÜSSEN die Unterstützungsfunktion mit einer einzigen Aktion zugänglich machen. (z.B. Tippen, Doppelklick oder Touch-Geste), wenn andere Navigationstasten verfügbar sind.
  • [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, die Startbildschirm-Funktion lange zu drücken, da Interaktion.

Wenn Geräteimplementierungen einen bestimmten Teil des Bildschirms nutzen, um die Navigationstasten verwenden:

  • [C-5-1] Die Navigationstasten MÜSSEN einen deutlichen Teil des Bildschirms einnehmen, für Anwendungen zur Verfügung stehen und DÜRFEN NICHT verdeckt oder auf sonstige Weise gestört werden Teil des Bildschirms, der Anwendungen zur Verfügung steht.
  • [C-5-2] MÜSSEN einen Teil des Bildschirms für Anwendungen verfügbar machen, die die in Abschnitt 7.1.1 definierten Anforderungen erfüllt.
  • [C-5-3] MÜSSEN die von der App über die View.setSystemUiVisibility() festgelegten Flags berücksichtigen sodass dieser bestimmte Teil des Bildschirms (auch bekannt als Navigationsleiste) ordnungsgemäß versteckt ist, wie in den des SDK.

Wenn die Navigationsfunktion als bewegungsbasierte Aktion auf dem Bildschirm bereitgestellt wird:

Wenn am linken und rechten Rand eine Navigationsfunktion vorhanden ist der aktuellen Bildschirmausrichtung:

  • [C-7-1] Die Navigationsfunktion MUSS "Zurück" sein und als Wischen Sie vom linken und rechten Rand der aktuellen Ausrichtung des Bildschirm.
  • [C-7-2] Wenn auf der linken oder linken Seite rechten Kanten, MÜSSEN sie im oberen Drittel des Bildschirms und mit ein klarer, dauerhafter visueller Hinweis, dass durch Ziehen bereits erwähnten Panels und folglich nicht „Zurück“. Ein Steuerfeld KÖNNEN wurde vom Nutzer so konfiguriert, dass er unter dem oberen Drittel des Bildschirms erscheint. Kanten, aber das Steuerfeld DÜRFEN NICHT länger als ein Drittel der Kanten verwenden.
  • [C-7-3] Wenn die Vordergrund-App entweder View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT oder WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE Flags gesetzt, Wischen von den Rändern MUSS wie bei AOSP implementiert werden, die im SDK dokumentiert sind.
  • [C-7-4] Wenn die Vordergrund-App entweder View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT oder WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE Flags gesetzt, Benutzerdefinierte wischbare Systembereiche MÜSSEN ausgeblendet werden, bis der Nutzer sie einbringt oder hebt die Helligkeit der Systemleisten (auch Navigations- und Statusleiste) auf, wie sie implementiert wurde. bei AOSP.

Wenn die Zurück-Navigationsfunktion verfügbar ist und die Nutzenden die Schaltfläche „Zurück“ und dann:

  • [C-8-1] OnBackInvokedCallback.onBackCancelled() MUSS aufgerufen werden.
  • [C-8-2] OnBackInvokedCallback.onBackInvoked() DARF NICHT aufgerufen werden.
  • [C-8-3] Das KEYCODE_BACK-Ereignis DARF NICHT gesendet werden.

Wenn die Zurück-Navigationsfunktion vorhanden ist, die App im Vordergrund jedoch KEINE OnBackInvokedCallback registriert haben, dann:

  • Das System SOLLTE eine Animation für die Anwendung im Vordergrund bereitstellen, die schlägt vor, dass der Nutzer wie in AOSP angegeben zurückkehrt.

Wenn Geräteimplementierungen die System-API setNavBarMode unterstützen, System-Apps mit der Berechtigung android.permission.STATUS_BAR erlauben, die Einstellung Navigationsleistenmodus aktiviert, geschieht Folgendes:

  • [C-9-1] MÜSSEN Support für kinderfreundliche Symbole oder wie im AOSP-Code angegeben.

7.2.4 Touchscreeneingabe

Android unterstützt eine Vielzahl von Zeiger-Eingabesystemen, darunter Touchscreens, Touchpads und gefälschte Berührungseingabegeräte. Geräte mit Touchscreen implementieren die mit einer Anzeige verknüpft sind, sodass der Nutzer direkt den Eindruck Elemente auf dem Bildschirm zu manipulieren. Da die Nutzenden den Bildschirm direkt berühren, benötigt das System keine zusätzlichen Angebote, um die Objekte manipuliert werden.

Geräteimplementierungen:

  • SOLLTEN ein Zeigereingabesystem haben (z. B. Maus- oder Touchbedienung).
  • SOLLTEN vollständig unabhängig nachverfolgte Zeiger unterstützen.

Wenn Geräte einen Touchscreen (Single Touch oder besser) auf einem primären Android-kompatiblen Displays:

  • [C-1-1] MÜSSEN TOUCHSCREEN_FINGER für Configuration.touchscreen melden API-Feld ein.
  • [C-1-2] MÜSSEN die android.hardware.touchscreen und Funktions-Flags von android.hardware.faketouch.

Wenn Geräte einen Touchscreen haben, mit dem mehr als durch einmaliges Tippen auf einem primären mit Android kompatiblen Bildschirm:

  • [C-2-1] MÜSSEN die entsprechenden Funktions-Flags android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand je nach Art des Touchscreens des Geräts.

Wenn Geräteimplementierungen auf ein externes Eingabegerät wie Maus oder Trackball (d.h. ohne direktes Berühren des Bildschirms) für die Eingabe auf einem primären Android-kompatiblen Bildschirm und erfüllen die gefälschten Anforderungen in Bezug auf die Touchbedienung in Abschnitt 7.2.5, sie:

  • [C-3-1] DÜRFEN KEINE Funktions-Flags melden, die mit android.hardware.touchscreen
  • [C-3-2] MÜSSEN nur android.hardware.faketouch melden.
  • [C-3-3] MÜSSEN TOUCHSCREEN_NOTOUCH für die Configuration.touchscreen API-Feld ein.

7.2.5 Eingabe von gefälschten Berührungen

Die Fake-Touch-Oberfläche bietet ein Eingabesystem für den Nutzer, Touchscreen-Funktionen nutzen. Zum Beispiel eine Maus oder Fernbedienung, ein Bildschirmcursor annähernd eine Berührung annähert, der Nutzer jedoch zunächst Fokus und dann klicken. Zahlreiche Eingabegeräte wie Maus, Touchpad, Gyroskop Luftmaus, Gyroskop, Joystick und Multi-Touch-Trackpad unterstützen Fälschungen Touch-Interaktionen. Android beinhaltet die Funktionskonstante „android.hardware.faketouch“, was einem High-Fidelity-Gerät ohne Touchscreen entspricht (zeigerbasiertes Eingabegerät), z. B. eine Maus oder ein Touchpad, das nur die berührungsbasierte Eingabe zu emulieren, einschließlich der grundlegenden Unterstützung von Touch-Gesten, und zeigt an, dass unterstützt das Gerät eine emulierte Teilmenge von Touchscreen-Funktionen.

Geräteimplementierungen ohne Touchscreen, aber mit das sie zur Verfügung stellen möchte,

  • SOLLTEN die Unterstützung für das Funktions-Flag android.hardware.faketouch deklarieren.

Wenn in Geräteimplementierungen die Unterstützung von android.hardware.faketouch deklariert wird, Sie:

  • [C-1-1] MÜSSEN die absoluten X- und Y-Bildschirmpositionen melden. der Zeigerposition und zeigt einen visuellen Zeiger auf dem Bildschirm an.
  • [C-1-2] MÜSSEN das Touch-Ereignis mit dem Aktionscode melden, der die Statusänderung auf dem Zeiger nach unten oder oben auf dem Bildschirm.
  • [C-1-3] MUSS den Zeiger nach unten und oben auf einem Objekt auf dem Bildschirm unterstützen, was ermöglicht Nutzern, das Tippen auf ein Objekt auf dem Bildschirm zu emulieren.
  • [C-1-4] MÜSSEN Zeiger nach unten, nach oben, nach unten und dann nach oben unterstützen innerhalb einer Zeitgrenze an derselben Stelle auf einem Bildschirmelement platzieren, ermöglicht Nutzern, Doppeltippen zu emulieren auf ein Objekt auf dem Bildschirm.
  • [C-1-5] MUSS den Mauszeiger auf einen beliebigen Punkt auf dem Bildschirm nach unten unterstützen, bewegen sich den Zeiger zu einer beliebigen anderen Stelle auf dem Bildschirm, gefolgt von einem Zeiger. nach oben, sodass Nutzende einen Touch-Ziehvorgang emulieren können.
  • [C-1-6] MUSS den Zeiger nach unten unterstützen, damit Nutzer das Gerät schnell bewegen können. Objekt an eine andere Position auf dem Bildschirm verschieben und dann mit dem Mauszeiger nach oben zeigen, mit der Nutzende ein Objekt auf den Bildschirm werfen können.

Wenn Geräteimplementierungen Unterstützung für android.hardware.faketouch.multitouch.distinct, sie/er:

  • [C-2-1] MÜSSEN die Unterstützung für android.hardware.faketouch erklären.
  • [C-2-2] MUSS das eindeutige Tracking von zwei oder mehr unabhängigen Zeigern unterstützen Eingaben.

Wenn Geräteimplementierungen Unterstützung für android.hardware.faketouch.multitouch.jazzhand, sie/er:

  • [C-3-1] MÜSSEN die Unterstützung für android.hardware.faketouch erklären.
  • [C-3-2] MUSS eindeutiges Tracking von 5 (Zeichnen einer Hand mit Fingern) unterstützen oder mehr Zeigereingaben ganz unabhängig voneinander ausführen.

7.2.6 Unterstützung für Gamecontroller

7.2.6.1 Schaltflächenzuordnungen

Geräteimplementierungen:

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

Wenn bei der Geräteimplementierung ein Controller eingebettet ist oder ein separater Controller beigefügt wird, damit alle in den folgenden Tabellen aufgeführten Ereignisse eingegeben werden können, gilt Folgendes:

  • [C-2-1] MÜSSEN das Funktions-Flag android.hardware.gamepad deklarieren.
Schaltfläche HID-Nutzung2 Android-Taste
A1 0x09 0x0001 KEYCODE_SCHALTFLÄCHE (96)
B1 0x09 0x0002 KEYCODE_SCHALTFLÄCHE (97)
X1 0x09 0x0004 KEYCODE_button_X (99)
J1 0x09 0x0005 KEYCODE_SCHALTFLÄCHE (100)
Steuerkreuz oben1
Steuerkreuz unten1
0x01 0x00393 AXIS_HAT_Y4
Steuerkreuz links1
Steuerkreuz rechts1
0x01 0x00393 AXIS_HAT_X4
Taste auf der linken Schulter1 0x09 0x0007 KEYCODE_button_L1 (102)
Rechte Schultertaste1 0x09 0x0008 KEYCODE_button_R1 (103)
Mit linker Maustaste klicken1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Mit der rechten Maustaste klicken1 0x09 0x000F KEYCODE_button_THUMBR (107)
Zurück1 0x0c 0x0224 KEYCODE_BACK (4)

1 Schlüsselereignis

2 Die oben genannten HID-Nutzungen müssen innerhalb eines Spiels deklariert werden. PAT-CA (0x01 0x0005).

3 Diese Nutzung muss ein logisches Minimum von 0, a Logisches Maximum von 7, ein physisches Minimum von 0, ein physisches Maximum von 315 Einheiten in Grad und die Berichtgröße 4. Der logische Wert ist definiert als Drehen im Uhrzeigersinn von der vertikalen Achse weg; z. B. ein logischer Wert von 0 steht für keine Drehung und das Drücken der Nach-oben-Schaltfläche, während ein logischer Wert 1 bedeutet eine Drehung um 45 Grad, wobei die Nach-oben- und Nach-links-Taste gedrückt.

4 MotionEvent

Analoge Steuerelemente1 HID-Nutzung Android-Taste
Linker Trigger 0x02 0x00C5 WASSERGRÖSSE
Rechter Trigger 0x02 0x00C4 AXIS_RTRIGGER
Linker Joystick 0 x 01, 0 x 0030
0x01 0x0031
AXIS_X
Achse_y
Rechter Joystick 0x01 0x0032
0x01 0x0035
AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7 Fernbedienung

Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.3.1.

7.3. Sensoren

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

Geräteimplementierungen:

  • [C-0-1] MÜSSEN das Vorhandensein oder Fehlen von Sensoren gemäß den android.content.pm.PackageManager .
  • [C-0-2] MÜSSEN über das SensorManager.getSensorList() und ähnliche Methoden.
  • [C-0-3] MÜSSEN sich in Bezug auf alle anderen Sensor-APIs (z. B. durch Gibt true oder false zurück, wenn versucht wird, sich durch Anwendungen zu registrieren Listener, die Sensor-Listener nicht aufrufen, wenn die entsprechenden Sensoren vorhanden; usw.).

Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechende API für Drittentwickler:

  • [C-1-1] MÜSSEN alle Sensormessungen melden. unter Verwendung der relevanten Werte des internationalen Maßeinheitensystems für jedes wie in der Android SDK-Dokumentation definiert.
  • [C-1-2] MÜSSEN Sensordaten mit einer maximalen Latenz von 100 melden Millisekunden + 2 * sample_time für einen Sensorstream mit einem Maximale angeforderte Latenz von 0 ms bei aktivem Anwendungsprozessor. Diese Verzögerung umfasst keine Filterverzögerungen.
  • [C-1-3] MÜSSEN die erste Sensorprobe innerhalb von 400 Millisekunden + 2 * sample_time des Sensors, der aktiviert wird. Es ist für diese Stichprobe akzeptabel, eine Genauigkeit von 0 haben.
  • [C-1-4] Für alle in der Android SDK-Dokumentation als Dauersensor, Geräteimplementierungen MÜSSEN fortlaufend bereitstellen, periodische Datenstichproben mit einem Jitter unter 3%, wobei der Jitter als Standardabweichung der Differenz des gemeldete Zeitstempelwerte zwischen aufeinanderfolgenden Ereignissen.
  • [C-1-5] MÜSSEN sicherstellen, dass der Sensorereignisstream DÜRFEN NICHT verhindern, dass die CPU des Geräts in den Ruhemodus wechselt oder aktiviert wird gesperrt werden.
  • [C-1-6] MÜSSEN die Ereigniszeit melden. in Nanosekunden, wie in der Android SDK-Dokumentation definiert, wann das Ereignis eingetreten ist und mit dem Ereignis synchronisiert wurde, SystemClock.elapsedRealtimeNano()-Uhr.
  • [C-SR-1] Uns wird dringend empfohlen, einen Zeitstempel-Synchronisierungsfehler zu haben unter 100 Millisekunden und SOLLTE ein Zeitstempel-Synchronisierungsfehler unter 1 haben Millisekunden.
  • Wenn mehrere Sensoren aktiviert sind, sollte der Stromverbrauch NICHT übersteigen. die Summe des gemeldeten Stromverbrauchs eines einzelnen Sensors.

Die obige Liste ist nicht vollständig. das dokumentierte Verhalten des Android SDK und die Open-Source-Dokumentation von Android sensors als maßgeblich ist.

Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechende API für Drittentwickler:

  • [C-1-6] MÜSSEN für alle Sensoren eine Auflösung ungleich null festlegen und den Wert melden. über Sensor.getResolution() API-Methode.

Einige Sensortypen sind zusammengesetzt, d. h., sie können aus bereitgestellten Daten abgeleitet werden von einem oder mehreren anderen Sensoren erfasst. (Beispiele hierfür sind der Ausrichtungssensor und die linearen Beschleunigungssensors aus.)

Geräteimplementierungen:

  • SOLLTEN Sie diese Sensortypen implementieren, die erforderlichen physischen Sensoren enthalten, wie in der Beschreibung unter Sensortypen.

Wenn Geräteimplementierungen einen zusammengesetzten Sensor enthalten, gilt Folgendes:

  • [C-2-1] MÜSSEN den Sensor wie in Android Open Source beschrieben implementieren. Dokumentation zu Verbundsensoren

Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechende API für Drittentwickler und der Sensor meldet nur eine und dann auf Geräteimplementierungen:

  • [C-3-1] MÜSSEN die Auflösung für den Sensor auf 1 einstellen und den Wert melden. über Sensor.getResolution() API-Methode.

Wenn Geräteimplementierungen einen bestimmten Sensortyp beinhalten, der SensorAdditionalInfo#TYPE_VEC3_CALIBRATION und der Sensor mit Drittanbietern konfrontiert wird, geschieht Folgendes:

  • [C-4-1] DÜRFEN KEINE festen, werkseitig festgelegten Kalibrierungen enthalten in den bereitgestellten Daten.

Wenn Geräte eine Kombination aus dreiachsigen Beschleunigungsmessern, einem 3-Achsen-Gyroskopsensor oder Magnetometersensor:

  • [C-SR-2] EMPFOHLEN, Beschleunigungsmesser, Gyroskop und Magnetometer eine feste relative Position haben, sodass sie, wenn das Gerät veränderbar (z.B. faltbar), bleiben die Sensorachsen ausgerichtet und einheitlich mit dem Sensorkoordinatensystem auf allen Transformationsstatus.

7.3.1 Beschleunigungsmesser

Geräteimplementierungen:

  • [C-SR-1] wird dringend empfohlen, einen dreiachsigen Beschleunigungsmesser zu verwenden.

Wenn Geräte einen Beschleunigungsmesser enthalten, gilt Folgendes:

  • [C-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 50 Hz melden können.
  • [C-1-3] MUSS den Android-Sensorkoordinatensystem wie in den Android-APIs beschrieben.
  • [C-1-4] MUSS ab dem freien Fall bis zum vierfachen Wert des gravity(4g) oder mehr auf einer beliebigen Achse.
  • [C-1-5] MUSS eine Auflösung von mindestens 12 Bit haben.
  • [C-1-6] MUSS eine Standardabweichung von nicht größer als 0,05 m/s^ haben, wobei Die Standardabweichung sollte auf Achsenbasis auf Stichproben berechnet werden mindestens 3 Sekunden lang mit der schnellsten Stichprobe erfasst werden.
  • SOLLTE Ereignisse mit bis zu 200 Hz melden.
  • SOLLTEN eine Auflösung von mindestens 16 Bit haben.
  • SOLLTEN während der Verwendung kalibriert werden, wenn sich die Eigenschaften Lebenszyklus und kompensiert und die Vergütungsparameter zwischen Geräteneustarts.
  • SOLLTE temperaturkompensiert werden.

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

  • [C-2-1] MÜSSEN den TYPE_ACCELEROMETER-Sensor implementieren und melden.
  • [C-SR-4] wird dringend empfohlen, die TYPE_SIGNIFICANT_MOTION zu implementieren zusammengesetzten Sensors.
  • [C-SR-5] EMPFOHLENE Implementierung und Berichterstellung TYPE_ACCELEROMETER_UNCALIBRATED-Sensor. Android-Geräte sind UNBEDINGT EMPFOHLEN, diese Anforderung zu erfüllen, damit sie ein Upgrade auf die bei zukünftigen Plattformversionen, bei denen dies möglicherweise ERFORDERLICH ist.
  • SOLLTEN die TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER wie im Android SDK-Dokument beschrieben.

Wenn Geräte einen Beschleunigungsmesser mit weniger als drei Achsen enthalten, ist Folgendes zu beachten:

  • [C-3-1] MÜSSEN den TYPE_ACCELEROMETER_LIMITED_AXES-Sensor implementieren und melden.
  • [C-SR-6] Implementierung und Berichterstattung STRONGLY_RECOMMENDED TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED-Sensor.

Wenn Geräte einen dreiachsigen Beschleunigungsmesser und eine der TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR TYPE_STEP_COUNTER-Sensoren sind implementiert:

  • [C-4-1] Die Summe ihrer Der Stromverbrauch MUSS immer unter 4 mW liegen.
  • SOLLTEN jeweils unter 2 mW bzw.0,5 mW liegen, wenn das Gerät in einem dynamischen oder statische Bedingung verwendet wird.

Wenn die Geräte einen 3-Achsen-Beschleunigungsmesser und einen 3-Achsen-Gyroskopsensor umfassen, Sie:

  • [C-5-1] MUSS TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren zusammengesetzten Sensoren.
  • [C-SR-7] wird dringend empfohlen, TYPE_GAME_ROTATION_VECTOR-Komposit-Sensor.

Wenn die Geräte einen 3-Achsen-Beschleunigungsmesser, einen 3-Achsen-Gyroskopsensor, und einem Magnetometer-Sensor:

  • [C-6-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Sensoren implementieren.

7.3.2 Magnetometer

Geräteimplementierungen:

  • [C-SR-1] Wir empfehlen dringend, einen dreiachsigen Magnetometer (Kompass) mitzunehmen.

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

  • [C-1-1] MÜSSEN den TYPE_MAGNETIC_FIELD-Sensor implementieren.
  • [C-1-2] MÜSSEN in der Lage sein, Ereignisse bis zu einer Frequenz von mindestens 10 Hz zu melden. und SOLLTEN Ereignisse mit bis zu 50 Hz melden.
  • [C-1-3] MUSS den Anforderungen des Android-Sensorkoordinatensystems entsprechen wie in den Android-APIs
  • [C-1-4] MUSS jeweils zwischen -900 μT und +900 μT messen können vor der Sättigung.
  • [C-1-5] MUSS einen Offset-Wert des harten Eisens unter 700 μT haben und eine einen Wert unter 200 μT, indem Sie das Magnetometer in großer Entfernung dynamische (strominduzierte) und statische (magnetinduzierte) Magnetfelder.
  • [C-1-6] MUSS eine Auflösung von mindestens 0,6 μT haben.
  • [C-1-7] MUSS die Online-Kalibrierung und -Kompensation des harten Eisens unterstützen. und die Kompensationsparameter zwischen Geräteneustarts beizubehalten.
  • [C-1-8] MUSS die Kompensation für weiches Eisen angewendet werden – die Kalibrierung kann während der Verwendung oder während der Produktion des Geräts durchgeführt wird.
  • [C-1-9] MUSS eine Standardabweichung haben, berechnet pro Achse von Stichproben, die bei der schnellsten Stichprobenerhebung in einem Zeitraum von mindestens 3 Sekunden erfasst wurden Rate, nicht größer als 1,5 μT; SOLLTE eine Standardabweichung von maximal 0,5 μT.
  • [C-1-10] MÜSSEN die TYPE_MAGNETIC_FIELD_UNCALIBRATED Sensor.

Wenn die Geräte ein 3-Achsen-Magnetometer oder einen Beschleunigungsmesser umfassen und einem 3-Achsen-Gyroskopsensor:

  • [C-2-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Sensoren implementieren.

Wenn Geräteimplementierungen ein dreiachsiges Magnetometer oder einen Beschleunigungsmesser enthalten, ist Folgendes zu beachten:

  • KANN den TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor implementieren.

Wenn Geräte ein 3-Achsen-Magnetometer, einen Beschleunigungsmesser und TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor wird Folgendes ausgeführt:

  • [C-3-1] MUSS weniger als 10 mW verbrauchen.
  • SOLLTE weniger als 3 mW verbrauchen, wenn der Sensor für den Batchmodus registriert ist bei 10 Hz.

7.3.3 GPS

Geräteimplementierungen:

  • [C-SR-1] wird dringend empfohlen, einen GPS-/GNSS-Empfänger mitzunehmen.

Wenn Geräte einen GPS-/GNSS-Empfänger umfassen und die Funktion melden über das Funktions-Flag android.hardware.location.gps an Anwendungen übergeben, geschieht Folgendes:

  • [C-1-1] MUSS die Standortausgaben mit einer Frequenz von mindestens 1 Hz unterstützen, wenn über LocationManager#requestLocationUpdate angefordert.
  • [C-1-2] MÜSSEN in der Lage sein, den Ort unter freiem Himmel zu bestimmen. (starke Signale, vernachlässigbarer Multipath, HDOP < 2) innerhalb von 10 Sekunden (schnell Zeit bis zur ersten Fehlerbehebung), bei einer Geschwindigkeit von mindestens 0,5 Mbit/s eine Internetverbindung. Diese Anforderung wird in der Regel durch die Verwendung einiger Form der unterstützten oder vorhergesagten GPS-/GNSS-Technik um die GPS-/GNSS-Verriegelungszeit zu minimieren (Unterstützungsdaten umfassen Referenzzeit, Referenzstandort und Satelliten-Ephemeris/Uhr).
    • [C-1-6] Nach der Berechnung des Standorts wird das Gerät Implementierungen MÜSSEN seinen Standort unter freiem Himmel innerhalb 5 Sekunden, wenn Standortanfragen neu gestartet werden, bis zu eine Stunde danach Berechnung des Standorts, auch wenn die nachfolgende Anfrage ohne Datenverbindung und/oder nach dem Ein- und Ausschalten.
  • Bei freiem Himmel, nachdem der Standort ermittelt wurde, bei stehendem oder bei Bewegung mit weniger als 1 Meter pro Sekunde zum Quadrat der Beschleunigung:

    • [C-1-3] MÜSSEN den Standort innerhalb von 20 Metern und die Geschwindigkeit ermitteln können. mit einer Geschwindigkeit von mindestens 0, 5 Metern pro Sekunde.
    • [C-1-4] MÜSSEN gleichzeitig über GnssStatus.Callback mindestens 8 Satelliten aus einer Konstellation.
    • SOLLTEN in der Lage sein, gleichzeitig mindestens 24 Satelliten von mehrere Sternbilder (z.B. GPS und mindestens eines der Sternbilder Glonass, Beidou, Galileo.
  • [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, weiterhin normales GPS/GNSS bereitzustellen Standortausgaben über GNSS Location Provider APIs während eines Notrufs aufrufen.

  • [C-SR-3] Es wird dringend empfohlen, GNSS-Messungen von allen Nutzern zu melden. Erfasste Panoramengruppen (wie in GnssStatus-Nachrichten angegeben), mit Ausnahme von SBAS.

  • [C-SR-4] DRINGEND empfohlen, AGC und die Häufigkeit von GNSS zu melden zu messen.

  • [C-SR-5] Es wird dringend empfohlen, alle Genauigkeitsschätzungen anzugeben. (einschließlich Peilung, Geschwindigkeit und vertikaler Ausrichtung) als Teil jedes GPS-/GNSS-Standorts angegeben werden.

  • [C-SR-6] GNSS-Messungen werden dringend empfohlen, sobald gefunden werden, auch wenn ein über GPS/GNSS berechneter Standort noch nicht gemeldet.

  • [C-SR-7] wird dringend empfohlen, GNSS-Pseudobereiche und Pseudorangeraten, die bei freiem Himmel nach der Bestimmung des Standorts sich nicht bewegen, mit weniger als 0,2 Metern pro Sekunde zum Quadrat beschleunigen, reichen aus, um die Position innerhalb von 20 Metern zu berechnen, und die Geschwindigkeit. in mindestens 95% der Fälle mit einer Geschwindigkeit von 0, 2 Metern pro Sekunde.

7.3.4 Gyroskop

Geräteimplementierungen:

  • [C-SR-1] wird dringend empfohlen, einen Gyroskopsensor zu verwenden.

Wenn Geräteimplementierungen ein Gyroskop umfassen, gilt Folgendes:

  • [C-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 50 Hz melden können.
  • [C-1-4] MUSS eine Auflösung von mindestens 12 Bit haben.
  • [C-1-5] MUSS temperaturkompensiert werden.
  • [C-1-6] MÜSSEN bei der Verwendung kalibriert und kompensiert werden und den zwischen Geräteneustarts kompensieren.
  • [C-1-7] MUSS eine Varianz von nicht größer als 1e–7 rad^2 / s^2 pro Hz haben (Abweichung pro Hz oder Rad^2 / s). Die Varianz darf mit dem Stichprobenrate, MUSS aber durch diesen Wert eingeschränkt werden. Mit anderen Worten, wenn Sie Die Varianz des Gyroskops mit einer Abtastrate von 1 Hz messen. Sie SOLLTE nicht höher sein. als 1e–7 rad^2/s^2.
  • [C-SR-2] Ein Kalibrierungsfehler unter 0,01 rad/s wird dringend empfohlen wenn das Gerät bei Raumtemperatur steht.
  • [C-SR-3] Eine Auflösung von mindestens 16 Bit wird dringend empfohlen.
  • SOLLTE Ereignisse mit bis zu 200 Hz melden.

Wenn Geräteimplementierungen ein 3-Achsen-Gyroskop umfassen, ist Folgendes erforderlich:

  • [C-2-1] MÜSSEN den TYPE_GYROSCOPE-Sensor implementieren.
  • [C-SR-4] Wir empfehlen dringend, TYPE_GYROSCOPE_UNCALIBRATED zu implementieren Sensor.

Wenn Geräteimplementierungen ein Gyroskop mit weniger als 3 Achsen enthalten, ist Folgendes zu beachten:

  • [C-3-1] MÜSSEN den TYPE_GYROSCOPE_LIMITED_AXES-Sensor implementieren und melden.
  • [C-SR-5] Implementierung und Berichterstattung STRONGLY_RECOMMENDED TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED-Sensor.

Wenn die Geräte ein 3-Achsen-Gyroskop, einen Beschleunigungsmessersensor enthalten und einem Magnetometer-Sensor:

  • [C-4-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Sensoren implementieren.

Wenn die Geräte einen 3-Achsen-Beschleunigungsmesser und ein 3-Achsen-Gyroskop umfassen Sensor verwenden sie:

  • [C-5-1] MUSS TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren zusammengesetzten Sensoren.
  • [C-SR-6] wird dringend empfohlen, die TYPE_GAME_ROTATION_VECTOR zusammengesetzten Sensors.

7.3.5 Barometer

Geräteimplementierungen:

  • [C-SR-1] wird dringend empfohlen, ein Barometer (Umgebungsluftdruck) mitzunehmen Sensor).

Wenn Geräteimplementierungen ein Barometer enthalten, gilt Folgendes:

  • [C-1-1] MÜSSEN den TYPE_PRESSURE-Sensor implementieren und melden.
  • [C-1-2] MUSS Ereignisse bei 5 Hz oder mehr liefern können.
  • [C-1-3] MUSS temperaturkompensiert werden.
  • [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, Druckmessungen in der im Bereich von 300 hPa bis 1100 hPa.
  • SOLLTEN eine absolute Genauigkeit von 1 hPa haben.
  • SOLLTEN eine relative Genauigkeit von 0,12 hPa über einen Bereich von 20 hPa haben. (entspricht einer Genauigkeit von ca. 1 m über eine Änderung von ca. 200 m auf Meereshöhe).

7.3.6 Thermometer

Wenn in den Geräten ein Umgebungsthermometer (Temperatursensor) vorhanden ist, Sie:

  • [C-1-1] MUSS SENSOR_TYPE_AMBIENT_TEMPERATURE definieren für den Umgebungstemperatur-Sensor und der Sensor MÜSSEN die (Raum-/Fahrzeugraum) Temperatur, von der aus der Nutzer mit dem in Grad Celsius angegeben.

Wenn Geräte einen Thermometersensor enthalten, der einen eine andere Temperatur als die Umgebungstemperatur, wie etwa die CPU-Temperatur,

Wenn Geräte einen Sensor zur Überwachung der Hauttemperatur enthalten, dann:

7.3.7 Fotometer

  • Sie können ein Fotometer (Umgebungslicht-Sensor) verwenden, in dem ein entsprechendes Gerät implementiert ist.

7.3.8 Näherungssensor

  • Geräteimplementierungen KÖNNEN einen Näherungssensor enthalten.

Wenn Geräte einen Näherungssensor enthalten und nur ein Binärprogramm "in der Nähe" oder "weit" lesen:

  • [C-1-1] MÜSSEN die Nähe eines Objekts in derselben Richtung wie die des Bildschirm. Das heißt, der Näherungssensor MUSS darauf ausgerichtet sein, Objekte zu erkennen. Bildschirm zu platzieren, da dieser Sensortyp ein Telefon erkennen, das der Nutzer verwendet. Wenn Geräteimplementierungen ein Näherungssensors mit einer anderen Ausrichtung verwenden, DARF ER NICHT zugänglich sein. über diese API.
  • [C-1-2] MUSS mindestens eine Genauigkeit von 1 Bit haben.
  • [C-1-3] MÜSSEN 0 Zentimeter als Näherungswert und 5 Zentimeter als der weiterlesen.
  • [C-1-4] MÜSSEN einen Höchstwert und eine Auflösung von 5 angeben.

7.3.9 Hochwertige Sensoren

Wenn Geräteimplementierungen eine Reihe hochwertigerer Sensoren umfassen, wie definiert, und für Drittanbieter-Apps zur Verfügung stellen, geschieht Folgendes:

  • [C-1-1] MUSS die Fähigkeit über das Funktions-Flag „android.hardware.sensor.hifi_sensors“.

Wenn in der Geräteimplementierung android.hardware.sensor.hifi_sensors deklariert ist, Sie:

  • [C-2-1] MUSS einen TYPE_ACCELEROMETER-Sensor haben, der:

    • MUSS einen Messbereich zwischen -8 g und +8 g haben und EMPFOHLENE Messbereiche von mindestens -16 g und +16 g.
    • MÜSSEN eine Auflösung von mindestens 2.048 LSB/g haben.
    • MUSS eine Mindest-Messfrequenz von 12,5 Hz oder weniger haben.
    • MUSS eine maximale Messfrequenz von 400 Hz oder höher haben. SOLLTEN SensorDirectChannel RATE_VERY_FAST unterstützt.
    • MUSS ein Messrauschen nicht über 400 μg/√Hz haben.
    • MÜSSEN bei diesem Sensor eine Nicht-Aktivierungsform mit Pufferung implementiert werden. mindestens 3.000 Sensorereignisse.
    • MUSS einen Batch-Stromverbrauch haben, der nicht unter 3 mW liegt.
    • [C-SR-1] Es wird dringend empfohlen, eine 3-dB-Messbandbreite von bei mindestens 80% der Nyquist-Frequenz und Bandbreite.
    • SOLLTEN bei zufälliger Beschleunigung von weniger als 30 μg √Hz bei die Raumtemperatur haben.
    • SOLLTE eine Verzerrungsänderung gegenüber der Temperatur von ≤ +/- 1 mg/°C auftreten.
    • SOLLTEN eine optimale Linien-Nichtlinearität von ≤ 0,5 % und Empfindlichkeitsänderung gegenüber Temperatur ≤ 0,03%/C°.
    • SOLLTEN die Querachsenempfindlichkeit < 2,5 % und Variation von Querachsenempfindlichkeit < 0,2% im Betriebstemperaturbereich des Geräts.
  • [C-2-2] MUSS eine TYPE_ACCELEROMETER_UNCALIBRATED mit demselben Qualitätsanforderungen wie TYPE_ACCELEROMETER.

  • [C-2-3] MUSS einen TYPE_GYROSCOPE-Sensor haben, der:

    • MUSS einen Messbereich zwischen -1.000 und +1.000 dps haben.
    • MÜSSEN eine Auflösung von mindestens 16 LSB/dps haben.
    • MUSS eine Mindest-Messfrequenz von 12,5 Hz oder weniger haben.
    • MUSS eine maximale Messfrequenz von 400 Hz oder höher haben. SOLLTEN SensorDirectChannel RATE_VERY_FAST unterstützt.
    • MUSS ein Messrauschen von maximal 0,014°/s/√Hz haben.
    • [C-SR-2] Es wird dringend empfohlen, eine 3-dB-Messbandbreite von bei mindestens 80% der Nyquist-Frequenz und Bandbreite.
    • SOLLTE eine Zufallsfrequenz von unter 0,001°/s √Hz im Raum testen Temperatur.
    • SOLLTE eine Verzerrungsänderung gegenüber der Temperatur von ≤ +/- 0,05 °/ s / °C auftreten.
    • SOLLTE eine Änderung der Empfindlichkeit gegenüber der Temperatur von ≤ 0,02% / °C betragen.
    • SOLLTEN eine Nichtlinearität der bestmöglichen Linie von ≤ 0,2 % haben.
    • SOLLTEN eine Rauschdichte von ≤ 0,007°/s/√Hz haben.
    • SOLLTEN Kalibrierungsfehler unter 0,002 rad/s im Bereich von 10 bis 40 °C bei stehendem Gerät.
    • SOLLTE eine G-Empfindlichkeit unter 0,1°/s/g aufweisen.
    • SOLLTEN die Querachsenempfindlichkeit < 4,0 % und Querachsenempfindlichkeit Variante < 0,3% im Betriebstemperaturbereich des Geräts.
  • [C-2-4] MUSS eine TYPE_GYROSCOPE_UNCALIBRATED mit derselben Qualität haben als TYPE_GYROSCOPE.

  • [C-2-5] MUSS einen TYPE_GEOMAGNETIC_FIELD-Sensor haben, der:

    • MÜSSEN einen Messbereich zwischen -900 und +900 μT haben.
    • MÜSSEN eine Auflösung von mindestens 5 LSB/uT haben.
    • MUSS eine Mindest-Messfrequenz von 5 Hz oder niedriger haben.
    • MUSS eine maximale Messfrequenz von 50 Hz oder höher haben.
    • MUSS ein Messrauschen aufweisen, das nicht über 0,5 uT liegt.
  • [C-2-6] MUSS eine TYPE_MAGNETIC_FIELD_UNCALIBRATED mit derselben Qualität haben Anforderungen als TYPE_GEOMAGNETIC_FIELD und zusätzlich:

    • MÜSSEN bei diesem Sensor eine Nicht-Aktivierungsform mit Pufferung implementiert werden. mindestens 600 Sensorereignisse.
    • [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, ein weißes Rauschenspektrum von 1 Hz bis mindestens 10 Hz, wenn die Berichtsfrequenz 50 Hz oder höher ist.
  • [C-2-7] MUSS einen TYPE_PRESSURE-Sensor haben, der:

    • MÜSSEN einen Messbereich zwischen mindestens 300 und 1100 hPa aufweisen.
    • MÜSSEN eine Auflösung von mindestens 80 LSB/hPa haben.
    • MUSS eine Mindest-Messfrequenz von 1 Hz oder niedriger haben.
    • MUSS eine maximale Messfrequenz von 10 Hz oder höher haben.
    • MUSS ein Messrauschen von maximal 2 P/√Hz haben.
    • MÜSSEN bei diesem Sensor eine Nicht-Aktivierungsform mit Pufferung implementiert werden. mindestens 300 Sensorereignisse.
    • Der Stromverbrauch für die Batchverarbeitung MUSS nicht unter 2 mW liegen.
  • [C-2-8] MUSS einen TYPE_GAME_ROTATION_VECTOR-Sensor haben.

  • [C-2-9] MUSS einen TYPE_SIGNIFICANT_MOTION-Sensor haben, der:

    • MUSS einen Stromverbrauch von nicht mehr als 0,5 mW haben, wenn das Gerät statisch und 1,5 mW in Bewegung.
  • [C-2-10] MUSS einen TYPE_STEP_DETECTOR-Sensor haben, der:

    • MÜSSEN bei diesem Sensor eine Nicht-Aktivierungsform mit Pufferung implementiert werden. mindestens 100 Sensorereignisse.
    • MUSS einen Stromverbrauch von nicht mehr als 0,5 mW haben, wenn das Gerät statisch und 1,5 mW in Bewegung.
    • MUSS einen Batch-Stromverbrauch haben, der nicht unter 4 mW liegt.
  • [C-2-11] MUSS einen TYPE_STEP_COUNTER-Sensor haben, der:

    • MUSS einen Stromverbrauch von nicht mehr als 0,5 mW haben, wenn das Gerät statisch und 1,5 mW in Bewegung.
  • [C-2-12] MUSS einen TILT_DETECTOR-Sensor haben, der:

    • MUSS einen Stromverbrauch von nicht mehr als 0,5 mW haben, wenn das Gerät statisch und 1,5 mW in Bewegung.
  • [C-2-13] Der Ereigniszeitstempel desselben physischen Ereignisses, der vom Beschleunigungsmesser, Gyroskop und Magnetometer MÜSSEN innerhalb von 2, 5 Millisekunden liegen. voneinander zu lernen. Ereigniszeitstempel desselben physischen Ereignisses, gemeldet von Beschleunigungsmesser und Gyroskop sollten in einem Umkreis von 0,25 Millisekunden Sonstiges.

  • [C-2-14] MUSS die Ereigniszeitstempel des Gyroskopsensors gleichzeitig verwenden. als Kamera-Subsystem und innerhalb von 1 Millisekunde Fehler.

  • [C-2-15] MÜSSEN Muster innerhalb von 5 Millisekunden nach Die Zeit, zu der die Daten über einen der oben genannten physischen Sensoren verfügbar sind an die Anwendung gesendet.

  • [C-2-16] DÜRFEN KEINEN Stromverbrauch über 0,5 mW haben. bei statischem Gerät und 2,0 mW in Bewegung wenn eine Kombination der folgenden Sensoren aktiviert ist:

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] KANN einen TYPE_PROXIMITY-Sensor haben, aber wenn vorhanden MUSS eine Mindestpufferkapazität von 100 Sensorereignissen.

Beachten Sie, dass bei den Anforderungen an den Stromverbrauch in diesem Abschnitt nicht die Stromverbrauch des Anwendungsprozessors. Es beinhaltet auch die Macht, Sensorkette, d. h. alle unterstützenden Schaltkreise, spezielles Sensorverarbeitungssystem usw.

Wenn Geräte eine direkte Sensorunterstützung bieten, gilt Folgendes:

  • [C-3-1] MÜSSEN die Unterstützung von direkten und direkten Kanaltypen korrekt deklariert werden. Preisebene über die isDirectChannelTypeSupported und getHighestDirectReportRateLevel der API erstellen.
  • [C-3-2] MUSS mindestens einen der beiden direkten Sensorkanaltypen unterstützen für alle Sensoren, die angeben, dass sie den direkten Sensorkanal unterstützen.
  • SOLLTEN die Ereignismeldung über den direkten Sensorkanal für den primären Sensor (Variante ohne Weckfunktion) der folgenden Typen: <ph type="x-smartling-placeholder">
      </ph>
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10 Biometrische Sensoren

Weitere Informationen zum Messen der Sicherheit biometrischer Entsperrung finden Sie unter Dokumentation zum Messen der biometrischen Sicherheit

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm beinhalten, gilt Folgendes:

  • SOLLTE einen biometrischen Sensor enthalten

Biometrische Sensoren können der Klasse 3 (früher Stark) zugeordnet werden, Klasse 2 (früher Weak) oder Klasse 1 (früher Convenience) der Akzeptanzraten von Parodien und Irrtümern sowie der Sicherheit der biometrische Pipeline. Diese Klassifizierung bestimmt die Funktionen, Der biometrische Sensor muss mit der Plattform und dem Drittanbieter verbunden sein. Anwendungen. Die Sensoren müssen die unten aufgeführten zusätzlichen Anforderungen erfüllen, wenn möchten, dass sie in Klasse 1, Klasse 2 oder Klasse 3 klassifiziert werden. Sowohl die Klasse 2 als auch die Klasse 3 haben zusätzliche Funktionen, (siehe unten).

Wenn Geräteimplementierungen einen biometrischen Sensor für Drittanbieter zur Verfügung stellen android.hardware.biometrics.BiometricManager android.hardware.biometrics.BiometricPrompt und android.provider.Settings.ACTION_BIOMETRIC_ENROLL, Sie:

  • [C-4-1] MUSS die Anforderungen für biometrische Daten der Klasse 3 oder Klasse 2 erfüllen wie in diesem Dokument definiert.
  • [C-4-2] MÜSSEN jeden als Konstanten definierten Parameternamen erkennen und berücksichtigen im Abschnitt Authenticators und allen Kombinationen daraus. Umgekehrt DÜRFEN KEINE Ganzzahlkonstanten, die an die canAuthenticate(int): und setAllowedAuthenticators(int) als öffentliche Konstanten dokumentiert sind, Authenticator und jegliche Kombinationen daraus.
  • [C-4-3] MÜSSEN die ACTION_BIOMETRIC_ENROLL implementieren Aktion auf Geräten mit biometrischen Verfahren der Klasse 3 oder Klasse 2. Diese Aktion DARF nur die Einstiegspunkte zur Anmeldung für Klasse 3 anzeigen oder Kurs 2.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-4-4] MÜSSEN Anwendungen erlauben, benutzerdefinierte Inhalte zu BiometricPrompt hinzuzufügen mit den PromptContentView-Formaten für die Inhaltsanzeige. Der Inhalt wird angezeigt Formate DÜRFEN NICHT erweitert werden, um Bilder, Links, interaktive Inhalte, oder andere Arten von Medien, die noch nicht Teil des BiometricPrompt sind der API erstellen. Stilistische Anpassungen, die den Text nicht verändern, verdecken oder kürzen Elemente festgelegt werden können (z. B. Position, Abstand, Ränder und Typografie).

Neue Anforderungen beenden

Wenn Geräteimplementierungen passives biometrisches Verfahren unterstützen, gilt Folgendes:

  • [C-5-1] MUSS standardmäßig einen zusätzlichen Bestätigungsschritt erfordern (z.B. Drücken einer Taste).
  • [C-SR-1] Wir empfehlen dringend, eine Einstellung zu haben, mit der Nutzer Folgendes tun können: Anwendungseinstellung überschreiben und immer eine begleitende Bestätigungsschritts.
  • [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, die Bestätigungsaktion zu sichern sodass ein Betriebssystem- oder Kernel-Manipulation das Spoofing nicht verhindern kann. Das bedeutet zum Beispiel, dass die Bestätigung über eine physische Taste wird über einen GPIO-Pin (Input-Only General-purpose Input/Output) weitergeleitet ein Secure Element (SE), das ausschließlich durch ein Tastendruck.
  • [C-5-2] MÜSSEN zusätzlich einen impliziten Authentifizierungsvorgang implementieren. (ohne Bestätigungsschritt) entspricht setConfirmationRequired(boolean) welche Anwendungen für Anmeldeabläufe genutzt werden können.

Geräteimplementierungen mit mehreren biometrischen Sensoren:

  • [C-7-1] MÜSSEN, wenn ein biometrisches Verfahren gesperrt ist, d.h. das biometrische Verfahren bis der Nutzer das Gerät mit der primären Authentifizierung entsperrt) oder eine zeitgebundene Sperrung (d. h. das biometrische Verfahren ist vorübergehend deaktiviert, bis der Nutzer eine Weile wartet. Intervall) aufgrund zu vieler fehlgeschlagener Versuche, sperren Sie auch alle anderen biometrischen Verfahren einer niedrigeren biometrischen Klasse. Bei einer zeitgebundenen Sperrung Die Backoff-Zeit für die biometrische Überprüfung MUSS der maximalen Backoff-Zeit entsprechen aller biometrischen Daten unter zeitgebundener Lockout-Regelung.

  • [C-SR-12] werden dringend empfohlen, wenn ein biometrisches Verfahren gesperrt ist (d.h. ist deaktiviert, bis der Nutzer das Gerät mit der primären Authentifizierung entsperrt. zeitgebundene Sperrung (d.h. das biometrische Verfahren wird bis zum Wartezeit des Nutzers) aufgrund zu vieler fehlgeschlagener Versuche, um auch alle anderen biometrischen Verfahren derselben biometrischen Klasse sperren. Im Fall von zeitgebundene Sperrung, ist die Backoff-Zeit für die biometrische Überprüfung UNBEDINGT EMPFOHLEN, die maximale Backoff-Zeit aller biometrischen Daten in terminierter

  • [C-7-2] MUSS den Nutzer zur empfohlenen primären Authentifizierung auffordern (z. B. PIN, Muster, Passwort), um den Sperrzähler für ein biometrisches Verfahren ausgesperrt zu sein. Klasse 3: Die Sperrfunktion für biometrische Verfahren KANN zurückgesetzt werden. für ein gesperrtes biometrisches Verfahren derselben oder einer niedrigeren Klasse. Kurs 2 oder Klasse 1 – biometrische Verfahren DÜRFEN NICHT die Sperre für das Zurücksetzen auf die Werkseinstellungen durchführen für jedes biometrische Verfahren.

  • [C-SR-3] Es wird dringend empfohlen, nur eine biometrische Methode zu bestätigen pro Authentifizierung (z.B. wenn sowohl Fingerabdruck- als auch Gesichtserkennung verfügbar sind) auf dem Gerät, onAuthenticationSucceeded. sollte gesendet werden, nachdem einer davon bestätigt wurde.

Damit Geräteimplementierungen den Zugriff auf Schlüsselspeicherschlüssel ermöglichen, Anwendungen von Drittanbietern:

  • [C-6-1] MÜSSEN die hier definierten Anforderungen für Klasse 3 erfüllen. weiter unten.
  • [C-6-2] MUSS bei der Authentifizierung nur biometrische Daten der Klasse 3 anzeigen erfordert BIOMETRIC_STRONG, oder die Authentifizierung wird mit einem CryptoObject aufgerufen.

Wenn ein biometrischer Sensor in Geräteimplementierungen als Klasse 1 behandelt werden soll (früher Convenience) verwenden, gilt Folgendes:

  • [C-1-1] MUSS eine falsche Annahmequote unter 0,002 % haben.
  • [C-1-2] MÜSSEN offenlegen, dass dieser Modus möglicherweise weniger sicher ist als eine starke PIN, oder Passwort haben und die Risiken einer Aktivierung klar aufführen, falls der Die Akzeptanzrate von Spoofing und Hochstapler-Syndrom liegt über 7 %, Biometrische Testprotokolle von Android.
  • [C-1-9] MUSS den Nutzer zur empfohlenen primären Authentifizierung auffordern (z.B. PIN, Muster, Passwort), nach maximal 20 falschen Versuchen Backoff-Zeit von weniger als 90 Sekunden für die biometrische Überprüfung, Falsche Aufnahme hat eine angemessene Aufnahmequalität. (BIOMETRIC_ACQUIRED_GOOD), der nicht mit einem registrierten biometrischen Verfahren übereinstimmt.
  • [C-SR-4] WIRD UNBEDINGT EMPFOHLEN, die Gesamtzahl der falschen Versuche zu verringern für die biometrische Überprüfung gemäß [C-1-9], wenn die Parodien und Betrüger Akzeptanzraten sind höher als 7 %, wie von Android Biometrics ermittelt Testprotokolle.
  • [C-1-3] MUSS die Anzahl der Versuche für die biometrische Überprüfung begrenzen, wenn Falsche Aufnahme hat eine angemessene Aufnahmequalität. (BIOMETRIC_ACQUIRED_GOOD) die nicht mit einem registrierten biometrischen Verfahren übereinstimmen.
  • [C-SR-5] Dringend empfohlen, Ratenbegrenzungen für mindestens 30 Sekunden nach fünf Fehlversuchen zur biometrischen Überprüfung der maximale Anzahl falscher Versuche pro [C-1-9], wobei ein falscher Test eins mit eine angemessene Aufnahmequalität (BIOMETRIC_ACQUIRED_GOOD), die nicht mit biometrischen Verfahren ein.
  • [C-SR-6] Es wird dringend empfohlen, die gesamte Ratenbegrenzungslogik in TEE zu verwenden.
  • [C-1-10] MÜSSEN das biometrische Verfahren deaktivieren, sobald der Backoff für die primäre Authentifizierung wie in [C-0-2] in Abschnitt 9.11 beschrieben ausgelöst.
  • [C-1-11] MUSS eine Akzeptanzrate von Spoofing und Identitätsdiebstahl aufweisen, die nicht über 30 % liegt. mit (1) einer Akzeptanzrate von Parodien und Irrtümern für die Präsentation der Stufe A Angriffsinstrumentenarten, die nicht mehr als 30 % ausmachen, und (2) eine Parodien und Hochstapler-Akzeptanzrate von Level-B-PAI-Spezies nicht höher als 40%, da gemäß den Android Biometrics Test Protocols gemessen werden.
  • [C-1-4] MUSS das Hinzufügen neuer biometrischer Daten MUSS verhindern, ohne zuvor ein Vertrauenskette, indem Nutzer das vorhandene Gerät bestätigen oder ein neues hinzufügen Von TEE gesicherte Anmeldedaten (PIN/Muster/Passwort) die Android Open Die Quellprojektimplementierung stellt den zu tunden Mechanismus im Framework bereit also.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-5] MÜSSEN alle identifizierbaren biometrischen Daten eines Nutzers vollständig entfernen Das Nutzerkonto wird entfernt (z. B. durch das Zurücksetzen auf die Werkseinstellungen). oder wenn die empfohlene primäre Authentifizierung (z.B. PIN, Muster, Passwort) entfernt werden.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-7] MUSS den Nutzer zur empfohlenen primären Authentifizierung auffordern (z. B. PIN, Muster, Passwort) mindestens einmal alle 24 Stunden. Hinweis: Das Upgrade von Geräten, die mit Android 9 oder niedriger gestartet wurden, MÜSSEN MÜSSEN den Nutzer nach der empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) und höchstens alle 72 Stunden.

Neue Anforderungen beenden

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-8] MÜSSEN den Nutzer zur Empfehlung für Hauptkonten auffordern Authentifizierung (z. B. PIN, Muster, Passwort) oder biometrisches Verfahren der Klasse 3 (STRONG) nach einer der folgenden Aktionen: <ph type="x-smartling-placeholder">
      </ph>
    • ein Zeitlimit von 4 Stunden bei Inaktivität ODER
    • 3 fehlgeschlagene biometrische Authentifizierungsversuche.
    • Das Zeitlimit bei Inaktivität und die Anzahl der fehlgeschlagenen Authentifizierungen werden zurückgesetzt. nach erfolgreicher Bestätigung der Geräteanmeldedaten. Hinweis: Aktualisieren von Geräten, die mit Android Version 9 gestartet wurden oder früher KANN von C-1-8 ausgenommen werden.

Neue Anforderungen beenden

  • [C-SR-7] wird dringend empfohlen, die Logik des bereitgestellten Frameworks zu verwenden. des Android Open Source-Projekts, um die in den [C-1-7] und [C-1-8] für neue Geräte.
  • [C-SR-8] WIRD UNBEDINGT EMPFOHLEN, eine Rate falscher Ablehnungen zu verwenden von weniger als 10 % gemessen.
  • [C-SR-9] Wir empfehlen dringend, eine Latenz von unter 1 Sekunde (gemessen) zu haben. ab dem Zeitpunkt, an dem das biometrische Verfahren erkannt wird, bis zum Entsperren des Bildschirms. biometrischen Verfahren ein.
  • [C-1-12] DÜRFEN eine Akzeptanzrate von Parodien und Betrügern von maximal 40 % aufweisen. pro Art des Präsentationsangriffs (PAI), gemessen von der Biometrische Testprotokolle von Android.
  • [C-SR-13] Parodien und Die Akzeptanzrate für Hacker nicht höher als 30% pro Art des Präsentationsangriffs (PAI), gemessen von der Biometrische Testprotokolle von Android.
  • [C-SR-8] WIRD UNBEDINGT EMPFOHLEN, eine Rate falscher Ablehnungen zu verwenden von weniger als 10 % gemessen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-15] MÜSSEN Nutzern die Entfernung eines oder mehrerer biometrischer Daten erlauben. Registrierungen.

Neue Anforderungen beenden

  • [C-SR-14] WIRD UNBEDINGT EMPFOHLEN, die biometrische Klasse des biometrischen Sensor und die damit verbundenen Risiken ihrer Aktivierung.

  • [C-SR-17] WIRD DRINGEND empfohlen, die neuen AIDL-Schnittstellen zu implementieren (z. B. IFace.aidl und IFingerprint.aidl).

Wenn ein biometrischer Sensor in Geräteimplementierungen als Klasse 2 behandelt werden soll (früher Weak) werden sie:

  • [C-2-1] MÜSSEN alle Anforderungen für Klasse 1 oben erfüllen.
  • [C-2-2] MUSS eine Akzeptanzrate von Spoofing und Nichtbetrügern von maximal 20 % aufweisen. mit (1) einer Akzeptanzrate von Spoofing und PAI-Spezies, Level A, die nicht höher als 20 % sind und (2) eine Akzeptanzrate von Parodien und Hochstapler-Spezies von PAI-Arten der Stufe B, die nicht über 30%, gemessen am Biometrische Testprotokolle von Android.
  • [C-SR-15] Parodien und Betrüger raten dringend davon ab. Akzeptanzrate nicht höher als 20% pro Art des Präsentationsangriffs (PAI), gemessen von der Biometrische Testprotokolle von Android.
  • [C-2-3] MUSS die biometrischer Abgleich in einer isolierten Ausführungsumgebung außerhalb von Android Nutzer- oder Kernel-Bereich wie die vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) auf einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder auf einer geschützten virtuellen Maschine, die die Anforderungen in Abschnitt 9.17 erfüllt.
  • [C-2-4] MÜSSEN alle identifizierbaren Daten verschlüsselt und kryptografisch verschlüsselt werden. so authentifiziert, dass sie außerhalb des die isolierte Ausführungsumgebung, oder einen Chip mit einem sicheren Kanal, isolierten Ausführungsumgebung, wie in der Implementierungsumgebung Richtlinien auf der Website des Open-Source-Projekts von Android oder einer geschützten virtuellen Maschine vom Hypervisor gesteuert, der die Anforderungen in Abschnitt 9.17 erfüllt.
  • [C-2-5] Für kamerabasierte biometrische Verfahren und biometrische Authentifizierung oder eine Registrierung stattfindet: <ph type="x-smartling-placeholder">
      </ph>
    • MÜSSEN die Kamera in einem Modus betrieben werden, der verhindert, dass die Kamerarahmen außerhalb der isolierten Ausführungsumgebung oder eines Chips gelesen oder geändert werden. mit einem sicheren Kanal in die isolierte Ausführungsumgebung oder Virtuelle Maschine, die vom Hypervisor gesteuert wird und die Anforderungen in Abschnitt erfüllt 9:17.
    • Bei RGB-Lösungen mit einer Kamera können die Kamerarahmen Außerhalb der isolierten Ausführungsumgebung lesbar, um Vorgänge zu unterstützen wie die Vorschau für die Anmeldung, DARF aber trotzdem NICHT geändert werden.
  • [C-2-6] DÜRFEN Anwendungen von Drittanbietern NICHT ermöglichen, zwischen biometrische Anmeldungen.
  • [C-2-7] DÜRFEN KEINEN unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder alle daraus abgeleiteten Daten (z. B. Einbettungen) an den Anwendungsprozessor außerhalb des Kontexts des TEE oder der geschützten virtuellen Maschine der die Anforderungen in Paragraf 9.17 erfüllt. Upgrades von Geräten, die mit Android 9 oder niedriger gestartet wurden, sind nicht ausgenommen C-2-7.
  • [C-2-8] MÜSSEN über eine sichere Verarbeitungspipeline verfügen, eine Manipulation des Systems oder Kernels nicht zulassen, dass Daten direkt in sich fälschlicherweise als Nutzer authentifizieren. Hinweis: Wenn Geräteimplementierungen bereits unter Android 9 veröffentlicht werden oder früher und kann die Anforderung C-2-8 nicht über eine Systemsoftware erfüllen. aktualisiert wurde, sind sie von der Anforderung ausgenommen.

  • [C-SR-10] Wir empfehlen dringend, die Aktivitätserkennung für alle biometrische Modalitäten und Aufmerksamkeitserkennung für biometrische Verfahren.

  • [C-2-9] MUSS den biometrischen Sensor Drittanbietern zur Verfügung stellen Anwendungen.

Wenn ein biometrischer Sensor in Geräteimplementierungen als Klasse 3 behandelt werden soll (früher Strong) gilt Folgendes:

  • [C-3-1] MÜSSEN alle Anforderungen der obigen Klasse 2 erfüllen, mit Ausnahme von [C-1-7] und [C-1-8].
  • [C-3-2] MÜSSEN eine hardwaregestützte Schlüsselspeicherimplementierung haben.
  • [C-3-3] MUSS eine Akzeptanzrate von Parodien und Betrügern von maximal 7 % aufweisen. mit (1) einer Akzeptanzrate von Spoofing und PAI-Spezies, Level A, die nicht über 7 % liegen und (2) die Akzeptanzrate von Parodien und Hochstapler-Spezies von PAI-Arten der Stufe B nicht höher als 20%, gemessen am Biometrische Testprotokolle von Android.
  • [C-3-4] MÜSSEN den Nutzer zur empfohlenen primären IP-Adresse herausfordern. Authentifizierung (z. B. PIN, Muster oder Passwort) einmal alle 72 Stunden oder weniger.
  • [C-3-5] MÜSSEN die Authenticator-ID neu generieren. für alle biometrischen Verfahren der Klasse 3, die auf dem Gerät unterstützt werden, sofern eines davon erneut angemeldet wurden.
  • [C-3-6] Biometrische gesicherte Schlüsselspeicherschlüssel müssen für Drittanbieter aktiviert werden. Anwendungen.
  • [C-SR-16] Parodien und Betrüger raten dringend davon ab. Akzeptanzrate nicht höher als 7% pro Art des Präsentationsangriffs, gemessen von der Biometrische Testprotokolle von Android. Wenn Geräteimplementierungen einen Fingerabdrucksensor unter dem Display enthalten, Sie:

  • [C-SR-11] WIRD UNBEDINGT EMPFOHLEN, den antippbaren Bereich des Fingerabdrucksensors unter dem Display zu verhindern die die Bedienung über 3 Schaltflächen beeinträchtigen können( was einige Nutzer und Barrierefreiheit).

7.3.11 Positionssensor

Geräteimplementierungen:

  • KANN Positionssensor mit 6 Freiheitsgraden unterstützen.

Wenn Geräteimplementierungen einen Positionssensor mit 6 Freiheitsgraden unterstützen, ist Folgendes möglich:

  • [C-1-1] MÜSSEN TYPE_POSE_6DOF implementieren und melden. Sensor.
  • [C-1-2] MUSS genauer sein als der Rotationsvektor allein.

7.3.12 Scharnierwinkelsensor

Wenn Geräteimplementierungen einen Scharnierwinkelsensor unterstützen, ist Folgendes zu beachten:

7.3.13 IEEE 802.1.15.4 (UWB)

Wenn Geräteimplementierungen 802.1.15.4 unterstützen und den Funktionalität in Anwendungen von Drittanbietern zur Verfügung stellen, gilt Folgendes:

  • [C-1-2] MÜSSEN das Hardwarefunktions-Flag android.hardware.uwb melden.
  • [C-1-3] MUSS alle folgenden Konfigurationssätze (vordefiniert) unterstützen Kombinationen der Parameter FIRA UCI die in der AOSP-Implementierung definiert sind.
    • CONFIG_ID_1: FiRa-definiertes Unicast-STATIC STS DS-TWR-Bereich, verzögerten Modus mit einem Bereichsintervall von 240 ms.
    • CONFIG_ID_2: Von FiRa definierter 1:n-STATIC STS DS-TWR-Bereich, verzögerten Modus mit einem Bereichsintervall von 200 ms. Typischer Anwendungsfall: Smartphone mit vielen Smart-Home-Geräten interagieren.
    • CONFIG_ID_3: Entspricht CONFIG_ID_1 mit Ausnahme des Ankunftswinkels (AoA) werden keine Daten gemeldet.
    • CONFIG_ID_4: Entspricht CONFIG_ID_1, mit dem Unterschied, dass der P-STS-Sicherheitsmodus ist aktiviert.
    • CONFIG_ID_5: Entspricht CONFIG_ID_2, mit dem Unterschied, dass der P-STS-Sicherheitsmodus ist aktiviert.
    • CONFIG_ID_6: Entspricht CONFIG_ID_3, mit dem Unterschied, dass der P-STS-Sicherheitsmodus ist aktiviert.
    • CONFIG_ID_7: Entspricht CONFIG_ID_2, mit Ausnahme von P-STS-Steuerelementen für einzelne Nutzer Schlüsselmodus aktiviert ist.
  • [C-1-4] MÜSSEN eine Funktion anbieten, mit der Nutzer das UWB aktivieren und deaktivieren können. aktiviert/deaktiviert.
  • [C-1-5] MÜSSEN erzwingen, dass Apps, die UWB-Funkschnittstellen verwenden, das UWB_RANGING Berechtigung (unter der Berechtigungsgruppe NEARBY_DEVICES).

Das Bestehen der relevanten Konformitäts- und Zertifizierungstests gemäß der Norm einschließlich FIRA, CC und CSA sorgt dafür, dass 802.1.15.4 ordnungsgemäß funktioniert.

7.4 Datenverbindung

7.4.1 Telefonie

„Telefonie“ die von den Android-APIs verwendet werden. Dieses Dokument bezieht sich auf Hardware zum Tätigen von Sprachanrufen und Senden von SMS-Nachrichten oder Einrichten von mobilen Daten über ein Mobilfunknetz (z.B. GSM, CDMA, LTE, NR),GSM oder CDMA Netzwerk. Ein Gerät, das „Telefonie“ unterstützt einige oder alle Anruf-, Messaging- und Datendienste entsprechend dem Produkt.

  • Android KANN auf Geräten ohne Telefonie-Hardware verwendet werden. Das Android ist mit Geräten kompatibel, bei denen es sich nicht um Smartphones handelt.

Wenn Geräteimplementierungen GSM- oder CDMA-Telefonie umfassen, gilt Folgendes:

  • [C-1-1] MÜSSEN das Funktions-Flag android.hardware.telephony und anderen Unterelementen-Flags entsprechend der Technologie.
  • [C-1-2] MÜSSEN für diese Technologie den vollen Support für die API implementieren.
  • SOLLTEN alle verfügbaren Mobilfunkdienste zulassen (2G, 3G, 4G, 5G usw.). bei Notrufen (unabhängig von den Netzwerktypen, SetAllowedNetworkTypeBitmap().

Wenn Geräteimplementierungen keine Telefoniehardware enthalten, gilt Folgendes:

  • [C-2-1] MÜSSEN die vollständigen APIs als managementfrei implementieren.

Wenn Geräteimplementierungen eUICCs oder eSIMs/eingebettete SIMs unterstützen und einen proprietären Mechanismus, um die eSIM-Funktion für Drittanbieter verfügbar zu machen Entwickler:innen:

Wenn die Systemeigenschaft ro.telephony.iwlan\_operation\_mode bei Geräteimplementierungen nicht auf „Legacy“ gesetzt wird, geschieht Folgendes:

Wenn Geräteimplementierungen ein einzelnes IP Multimedia Subsystem (IMS) unterstützen für den Multimedia-Telefoniedienst (MMTEL) und Rich Communication Service (RCS) profitieren und mit den Anforderungen des Mobilfunkanbieters bezüglich der Verwendung eines einzigen IMS-Registrierung für den gesamten IMS-Signalisierungs-Traffic:

Wenn Geräteimplementierungen die Funktion android.hardware.telephony melden, dann:

Wenn Geräteimplementierungen die Funktion android.hardware.telephony melden und eine Systemstatusleiste anzeigen. Gehen Sie dann so vor:

  • [C-7-1] MÜSSEN für eine bestimmte Zielgruppe Gruppen-UUID die dem Nutzer in allen Angeboten angezeigt werden, die den SIM-Status Informationen. Beispiele für solche Angebote sind die Statusleiste „Mobilfunk“ oder die Kachel für die Schnelleinstellungen.
  • [C-SR-1] Es wird UNBEDINGT EMPFOHLEN, dass das Abo eines Bevollmächtigten die wir ausgewählt haben, Abo mit aktiven Daten es sei denn, das Gerät ist mit einer Stimme ausgestattet. während dieses Anrufs sehr wichtig ist. „subscription“ ist das aktive Voice-Abo.

Wenn Geräteimplementierungen die Funktion android.hardware.telephony melden, dann:

  • [C-6-7] MUSS in der Lage sein, den Grenzwert Anzahl der logischen Kanäle (insgesamt 20) für jede UICC gemäß ETSI TS 102 221.
  • [C-6-8] Die folgenden Verhaltensweisen DÜRFEN NICHT auf aktive Mobilfunkanbieter-Apps angewendet werden. (wie von TelephonyManager#getCarrierServicePackageName angegeben) automatisch oder ohne ausdrückliche Bestätigung durch den Nutzer: <ph type="x-smartling-placeholder">
      </ph>
    • Netzwerkzugriff widerrufen oder einschränken
    • Berechtigungen widerrufen
    • Die Ausführung von Apps im Hintergrund oder im Vordergrund über die vorhandenen Energieverwaltungsfunktionen von AOSP hinaus einschränken
    • App deaktivieren oder deinstallieren

Wenn Geräteimplementierungen die Funktion android.hardware.telephony melden und alle aktiven, nicht opportunistische Abos Gruppen-UUIDs deaktiviert sind. vom Gerät entfernt oder als opportunistisch gekennzeichnet wurde, geschieht Folgendes:

  • [C-8-1] MÜSSEN automatisch alle verbleibenden aktiven opportunistisch Abos in derselben Gruppe.

Wenn Geräteimplementierungen GSM-Telefonie, aber keine CDMA-Telefonie umfassen, gilt Folgendes:

  • [C-9-1] DARF NICHT PackageManager#FEATURE_TELEPHONY_CDMA deklarieren.
  • [C-9-2] MÜSSEN bei Versuchen, einen Wert festzulegen, den Fehler IllegalArgumentException auslösen. 3GPP2-Netzwerktypen in bevorzugten oder zulässigen Bitmasken des Netzwerktyps.
  • [C-9-3] MUSS eine leere Zeichenfolge aus TelephonyManager#getMeid

Wenn die Geräteimplementierungen eUICCs mit mehreren Ports und Profilen unterstützen, gilt Folgendes:

7.4.1.1 Kompatibilität mit Nummernblockierungen

Wenn Geräteimplementierungen die Funktion android.hardware.telephony.calling melden, geschieht Folgendes:

  • [C-1-1] MUSS die Unterstützung für das Blockieren von Nummern enthalten.
  • [C-1-2] MUSS BlockedNumberContract vollständig implementieren und die entsprechende API, wie in der SDK-Dokumentation beschrieben.
  • [C-1-3] MÜSSEN alle Anrufe und Nachrichten von einer Telefonnummer in „BlockingNumberProvider“ ohne Interaktion mit Apps. Die einzige Ausnahme wenn die Blockierung von Nummern wie im SDK beschrieben vorübergehend aufgehoben wird Dokumentation.

  • [C-1-4] MUSS in den Plattformanbieter für Anruflisten schreiben für einen blockierten Anruf und MÜSSEN Anrufe mit BLOCKED_TYPE von Standardansicht in der Anrufliste in der vorinstallierten Telefon-App

  • [C-1-5] DARF NICHT an den Telefonieanbieter schreiben für eine blockierte Nachricht.

  • [C-1-6] MÜSSEN eine UI für die Verwaltung blockierter Nummern implementieren, die geöffnet wird. mit dem von TelecomManager.createManageBlockedNumbersIntent() zurückgegebenen Intent .

  • [C-1-7] DÜRFEN sekundäre Nutzer NICHT erlauben, die blockierten Nummern anzusehen oder zu bearbeiten da die Android-Plattform davon ausgeht, dass der Hauptnutzer Kontrolle über die Telefoniedienste in einer einzigen Instanz auf dem Gerät. Alle Benutzeroberfläche zum Blockieren von Nutzern MUSS für sekundäre Nutzer ausgeblendet sein und die Liste der blockierten Nutzer MÜSSEN MÜSSEN respektiert werden.

  • SOLLTEN Sie die blockierten Nummern zum Anbieter migrieren, wenn ein Gerät aktualisiert wird Android 7.0.

  • SOLLTEN Sie die blockierten Anrufe in der vorinstallierten App Telefon App

7.4.1.2 Telekommunikations-API

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

  • [C-1-1] MUSS die im SDK beschriebenen ConnectionService APIs unterstützen.
  • [C-1-2] MÜSSEN einen neuen eingehenden Anruf anzeigen und dem Nutzer Eingehenden Anruf annehmen oder ablehnen, während der Nutzer in einem aktiven Anruf ist die von einer Drittanbieter-App stammen, die die Hold-Funktion nicht unterstützt angegeben über CAPABILITY_SUPPORT_HOLD
  • [C-1-3] MUSS eine Anwendung haben, die InCallService übergeben.
  • [C-SR-1] Es wird dringend empfohlen, den Nutzer über die eingehender Anruf wird ein laufender Anruf beendet.

    Die AOSP-Implementierung erfüllt diese Anforderungen mit einer Vorabbenachrichtigung was dem Nutzer signalisiert, dass das Annehmen eines eingehenden Anrufs ein anderer zu löschender Anruf.

  • [C-SR-2] EMPFOHLEN, die Standard-Telefon-App vorab zu laden, einen Eintrag aus der Anrufliste und den Namen einer Drittanbieter-App in der Anrufliste zeigt wenn die Drittanbieter-App EXTRA_LOG_SELF_MANAGED_CALLS Extras-Schlüssel auf PhoneAccount zu true.

  • [C-SR-3] EMPFOHLEN KEYCODE_MEDIA_PLAY_PAUSE- und KEYCODE_HEADSETHOOK-Ereignisse für den android.telecom APIs wie unten beschrieben:

    • Connection.onDisconnect() anrufen Ein kurzes Drücken des Schlüsselereignisses während eines laufenden Anrufs wird erkannt.
    • Connection.onAnswer() anrufen Bei einem eingehenden Anruf wird kurz das Schlüsselereignis gedrückt.
    • Connection.onReject() anrufen Ein langes Drücken des Schlüsselereignisses wird während eines eingehenden Anrufs erkannt.
    • Stummschaltung des CallAudioState aktivieren oder deaktivieren.
7.4.1.3 Mobilfunk-NAT-T-Keepalive-Abladung

Geräteimplementierungen:

  • SOLLTEN die Unterstützung für die Keepalive-Auslagerung über Mobilfunk beinhalten.

Wenn Geräteimplementierungen Unterstützung für die Keepalive-Auslagerung in Mobilfunk und Drittanbieter-Apps die Funktionalität zur Verfügung stellen, werden sie:

  • [C-1-1] MUSS die SocketKeepAlive API unterstützen.
  • [C-1-2] MUSS mindestens einen gleichzeitigen Keepalive-Slot über das Mobilfunknetz unterstützen.
  • [C-1-3] MUSS so viele gleichzeitige Mobilfunk-Keepalive-Slots unterstützen, wie vorhanden vom Mobilfunk-HAL unterstützt.
  • [C-SR-1] wird dringend empfohlen, mindestens drei Mobilfunk-Keepalive-Daten zu unterstützen Slots pro Radioinstanz.

Wenn Geräteimplementierungen die mobile Keepalive-Auslagerung nicht unterstützen, Sie:

  • [C-2-1] MUSS ERROR_UNSUPPORTED zurückgeben.

7.4.2 IEEE 802.11 (Wi-Fi)

Geräteimplementierungen:

  • SOLLTEN eine oder mehrere 802.11-Formulare unterstützen.

Wenn Geräteimplementierungen 802.11 unterstützen und den Funktionalität in Anwendungen von Drittanbietern zur Verfügung stellen, gilt Folgendes:

  • [C-1-1] MÜSSEN die entsprechende Android API implementieren.
  • [C-1-2] MÜSSEN das Hardwarefunktions-Flag android.hardware.wifi melden.
  • [C-1-3] MÜSSEN die Multicast API implementieren wie in der SDK-Dokumentation beschrieben.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

  • [C-1-4] MÜSSEN Multicast-DNS (mDNS) unterstützen und mDNS-Pakete NICHT filtern (224.0.0.251 oder ff02::fb) auch dann, wenn das Display nicht aktiv ist, es sei denn, das Verwerfen oder Filtern dieser Pakete ist erforderlich, um innerhalb der gesetzlich vorgeschriebenen Bereiche des Stromverbrauchs zu bleiben die für den Zielmarkt gelten.

  • [C-1-4] MUSS mDNS unterstützen und DÜRFEN KEINE mDNS-Pakete filtern (224.0.0.251 oder ff02::fb) zur Verfügung, auch wenn der der Bildschirm nicht aktiv ist, es sei denn, die Multicast-Sperre ist aktiviert und werden die Pakete vom APF gefiltert. Die Pakete sind nicht erforderlich, um mDNS-Vorgänge, die derzeit von Anwendungen über den NsdManager angefordert werden APIs Das Gerät KANN jedoch mDNS-Pakete filtern, wenn dies erforderlich ist. um den Stromverbrauchsbereichen einzuhalten, die gesetzlich vorgeschrieben sind die für den Zielmarkt relevant sind.

Neue Anforderungen beenden

  • [C-1-5] DARF NICHT den WifiManager.enableNetwork() behandeln API-Methodenaufruf als ausreichender Hinweis zum Wechseln der derzeit aktiven Network, die standardmäßig für Anwendungstraffic verwendet und zurückgegeben wird von ConnectivityManager API-Methoden wie getActiveNetwork und registerDefaultNetworkCallback. Mit anderen Worten, sie KÖNNEN nur den Internetzugriff von beliebigen Personen deaktivieren, einen anderen Netzanbieter (z.B. mobile Daten) nutzen, dass das WLAN Internetzugang bereitstellt.
  • [C-1-6] EMPFOHLEN sind UNBEDINGT, wenn ConnectivityManager.reportNetworkConnectivity() API-Methode aufgerufen, prüfen Sie den Internetzugriff auf der Network neu und sobald bei der Auswertung festgestellt wird, dass der aktuelle Network keine Internetzugriff, wechseln Sie zu einem anderen verfügbaren Netzwerk (z.B. Mobilfunknetz) die einen Internetzugang ermöglichen.
  • [C-1-7] MUSS die Quell-MAC-Adresse und die Sequenznummer der Prüfung zufällig anordnen. Frames anfordern, einmal zu Beginn jedes Scans, während STA nicht verbunden.
  • [C-1-8] MUSS eine konsistente MAC-Adresse verwenden (MAC-ZUFALLSZAHL NICHT zufällig anordnen) Adresse nach der Hälfte des Scans).
  • [C-1-9] MÜSSEN die Sequenznummer der Prüfungsanfrage wie gewohnt (sequentiell) iterieren. zwischen den Prüfungsanfragen in einem Scan.
  • [C-1-10] MÜSSEN die Sequenznummer der Prüfungsanforderung zwischen der letzten Prüfung zufällig anordnen. und die erste Prüfungsanfrage des nächsten Scans.
  • [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die MAC-Quelladresse für die gesamte STA-Kommunikation mit einem Zugangspunkt (Zugangspunkt) zu verbinden, während verknüpft sind.
    • Das Gerät muss für jede SSID eine andere zufällige MAC-Adresse verwenden. (FQDN für Passpoint), mit dem er kommuniziert.
    • Das Gerät MUSS dem Nutzer eine Option zum Steuern des Randomisierung pro SSID (FQDN für Passpoint) mit nicht zufälligen und Zufällig ausgewählte Optionen und MÜSSEN den Standardmodus für das neue WLAN festlegen. Konfigurationen ausgewählt werden.
  • [C-SR-2] Es wird dringend empfohlen, für jeden Zugangspunkt eine zufällige BSSID zu verwenden, erstellen.
    • Die MAC-Adresse MUSS für jede vom ZP.
    • Über das GERÄT KANN der Nutzer diese Funktion deaktivieren. Wenn eine solche Option angegeben wird, MUSS die Zufallsauswahl standardmäßig aktiviert sein.

Wenn Geräteimplementierungen wie definiert den WLAN-Energiesparmodus unterstützen gemäß IEEE 802.11-Standard:

  • SOLLTEN Sie den WLAN-Energiesparmodus ausschalten, wenn eine App WIFI_MODE_FULL_HIGH_PERF-Sperre oder WIFI_MODE_FULL_LOW_LATENCY-Sperre über WifiManager.createWifiLock() undWifiManager.WifiLock.acquire() APIs und die Sperre ist aktiv.
  • [C-3-2] Die durchschnittliche Umlauflatenz zwischen dem Gerät und einem Zugangspunkt, während sich das Gerät in einer WLAN-Sperre mit niedriger Latenz befindet Modus (WIFI_MODE_FULL_LOW_LATENCY) MUSS kleiner als der Modus sein. Latenz während eines Wi-Fi High Perf Lock-Modus (WIFI_MODE_FULL_HIGH_PERF)
  • [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, die WLAN-Umlaufzeit zu minimieren wenn eine Sperre mit niedriger Latenz (WIFI_MODE_FULL_LOW_LATENCY) empfangen wird und wird wirksam.

Wenn Geräteimplementierungen WLAN unterstützen und WLAN für die Standortsuche verwenden, Sie:

7.4.2.1 Wi-Fi Direct

Geräteimplementierungen:

  • SOLLTE Unterstützung für Wi-Fi Direct (Wi-Fi Peer-to-Peer) beinhalten.

Wenn Geräteimplementierungen Wi-Fi Direct unterstützen, gilt Folgendes:

  • [C-1-1] MÜSSEN die entsprechende Android API implementieren. wie in der SDK-Dokumentation beschrieben.
  • [C-1-2] MÜSSEN die Hardwarefunktion android.hardware.wifi.direct melden.
  • [C-1-3] MUSS den normalen WLAN-Betrieb unterstützen.
  • [C-1-4] MUSS die gleichzeitige Verwendung von Wi-Fi und Wi-Fi Direct unterstützen.
  • [C-SR-1] Es wird dringend empfohlen, die MAC-Quelladresse für alle Nutzer zufällig zu wählen. neu aufgebaute Wi-Fi Direct-Verbindungen.

Geräteimplementierungen:

Wenn Geräteimplementierungen die Unterstützung von TDLS und TDLS durch das WiFiManager API zu verwenden, werden sie:

  • [C-1-1] MÜSSEN die Unterstützung für TDLS über WifiManager.isTdlsSupported deklarieren.
  • SOLLTEN TDLS nur verwenden, wenn es möglich UND vorteilhaft ist.
  • SOLLTEN heuristisch sein und KEIN TDLS verwenden, wenn die Leistung als über den WLAN-Zugangspunkt.
7.4.2.3 WLAN-fähig

Geräteimplementierungen:

Wenn Geräteimplementierungen Unterstützung für Wi-Fi Aware umfassen und die Drittanbieter-Apps zur Verfügung stehen, geschieht Folgendes:

  • [C-1-1] MÜSSEN die WifiAwareManager APIs wie in den SDK-Dokumentation.
  • [C-1-2] MÜSSEN das Funktions-Flag android.hardware.wifi.aware deklarieren.
  • [C-1-3] MUSS die gleichzeitige Verwendung von WLAN und Wi-Fi Aware unterstützen.
  • [C-1-4] MUSS die Adresse der Wi-Fi Aware-Verwaltungsoberfläche in regelmäßigen Abständen zufällig festlegen nicht länger als 30 Minuten und immer dann, wenn Wi-Fi Aware aktiviert ist, es sei denn, ein Bereichsing-Vorgang oder ein Aware-Datenpfad aktiv ist (die Randomisierung ist keine solange der Datenpfad aktiv ist).

Wenn Geräteimplementierungen Unterstützung für Wi-Fi Aware und WLAN-Standort gemäß Beschreibung in Abschnitt 7.4.2.5 und diese Funktionen in Drittanbieter-Apps zur Verfügung stellt, dann:

7.4.2.4 WLAN-Passpoint

Wenn Geräteimplementierungen 802.11 (WLAN) unterstützen, gilt Folgendes:

  • [C-1-1] MUSS Unterstützung für Wi-Fi Passpoint beinhalten.
  • [C-1-2] MÜSSEN die Passpoint-bezogenen WifiManager APIs wie folgt implementieren: in der SDK-Dokumentation beschrieben.
  • [C-1-3] MÜSSEN den IEEE 802.11u-Standard unterstützen, insbesondere zugehörige Netzwerkerkennung und -auswahl, wie z. B. generische Anzeige Service (GAS) und Access Network Query Protocol (ANQP).
  • [C-1-4] MÜSSEN das Funktions-Flag „android.hardware.wifi.passpoint“ deklarieren.
  • [C-1-5] MUSS der AOSP-Implementierung folgen, um zu erkennen, abzugleichen und zu verknüpfen mit Passpoint-Netzwerken.
  • [C-1-6] MUSS mindestens die folgende Teilmenge der Gerätebereitstellung unterstützen Protokolle entsprechend der Definition im Wi-Fi Alliance Passpoint R2: EAP-TTLS -Authentifizierung und SOAP-XML.
  • [C-1-7] MÜSSEN das AAA-Serverzertifikat wie in Hotspot 2.0 R3-Spezifikation.
  • [C-1-8] MÜSSEN die Nutzersteuerung der Bereitstellung über die WLAN-Auswahl unterstützen.
  • [C-1-9] MÜSSEN Passpoint-Konfigurationen auch nach einem Neustart beibehalten werden.
  • [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die Nutzungsbedingungen zu unterstützen Akzeptanzfunktion zu finden.
  • [C-SR-2] wird dringend empfohlen, die Funktion „Informationen zu Veranstaltungsorten“ zu unterstützen.

Wenn ein globaler Nutzersteuerungsschalter mit Passpoint-Deaktivierung verfügbar ist, werden folgende Implementierungen angewendet:

  • [C-3-1] MÜSSEN Passpoint standardmäßig aktivieren.
7.4.2.5 WLAN-Standort (WLAN-Umlaufzeit – RTT)

Geräteimplementierungen:

Wenn die Geräteimplementierung die WLAN-Funktion unterstützt und die Drittanbieter-Apps zur Verfügung stehen, geschieht Folgendes:

  • [C-1-1] MÜSSEN die WifiRttManager APIs wie in den SDK-Dokumentation.
  • [C-1-2] MÜSSEN das Funktions-Flag android.hardware.wifi.rtt deklarieren.
  • [C-1-3] MÜSSEN die Quell-MAC-Adresse für jeden RTT-Burst zufällig anordnen. der ausgeführt wird, während die WLAN-Schnittstelle, auf der die RTT läuft, ausgeführt wird. ausgeführt wird, ist keinem Zugangspunkt zugeordnet.
  • [C-1-4] MÜSSEN am 68. und bei einer Bandbreite von 80 MHz auf einen Bereich von 2 Metern genau sein Perzentil (wie mit der kumulativen Verteilungsfunktion berechnet).
  • [C-SR-1] Es wird dringend empfohlen, Daten in einem Umkreis von 1,5 Metern zu melden. bei einer Bandbreite von 80 MHz beim 68. Perzentil (wie mit der Kumulative Verteilungsfunktion).
7.4.2.6 Wi-Fi Keepalive Offload

Geräteimplementierungen:

  • SOLLTEN die Unterstützung für Wi-Fi-Keepalive-Auslagerung umfassen.

Wenn Geräteimplementierungen Unterstützung für die Wi-Fi-Keepalive-Auslagerung beinhalten und die Funktionalität für Drittanbieter-Apps verfügbar ist, 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 Geräteimplementierungen die Wi-Fi-Keepalive-Auslagerung nicht unterstützen, Sie:

7.4.2.7 Wi-Fi Easy Connect (Protokoll für die Gerätebereitstellung)

Geräteimplementierungen:

Wenn Geräteimplementierungen Wi-Fi Easy Connect unterstützen und den Drittanbieter-Apps funktionieren, müssen sie:

7.4.2.8 Validierung des Unternehmens-WLAN-Serverzertifikats

Wenn das WLAN-Serverzertifikat nicht bestätigt wurde oder der WLAN-Server Domainname nicht festgelegt, Geräteimplementierungen:

  • [C-SR-1] Es wird dringend empfohlen, dem Nutzer keine Option zu bieten, Unternehmens-WLAN manuell hinzufügen in der App „Einstellungen“.
7.4.2.9 Vertrauen bei der ersten Verwendung

Wenn Geräteimplementierungen Trust on first use (TOFU) unterstützen und Erlaubt es dem Nutzer, WPA-/WPA2-/WPA3-Enterprise-Konfigurationen zu definieren, dann:

  • [C-4-1] MÜSSEN dem Nutzer die Möglichkeit geben, TOFU zu verwenden.

7.4.3 Bluetooth

Wenn Geräteimplementierungen das Bluetooth Audio-Profil unterstützen, gilt Folgendes:

  • SOLLTEN erweiterte Audio-Codecs und Bluetooth-Audio-Codecs unterstützen. (z.B. LDAC)

Wenn Geräteimplementierungen HFP, A2DP und AVRCP unterstützen, gilt Folgendes:

  • SOLLTEN mindestens 5 verbundene Geräte unterstützen.

Wenn in der Geräteimplementierung android.hardware.vr.high_performance deklariert wird Funktion:

  • [C-1-1] MÜSSEN Bluetooth 4.2 und Bluetooth LE-Datenlängenerweiterung unterstützen.

Android unterstützt Bluetooth und Bluetooth Low Energy.

Ob die Geräteimplementierung Bluetooth und Bluetooth unterstützt Energiesparend können sie:

  • [C-2-1] MÜSSEN die relevanten Plattformfunktionen deklariert werden. (android.hardware.bluetooth und android.hardware.bluetooth_le) und die Plattform-APIs implementieren.
  • SOLLTEN Sie relevante Bluetooth-Profile implementieren wie A2DP, AVRCP, OBEX, HFP usw., je nach Gerät.

Wenn Geräteimplementierungen Bluetooth Low Energy (BLE) unterstützen, gilt Folgendes:

  • [C-3-1] MÜSSEN die Hardwarefunktion android.hardware.bluetooth_le deklarieren.
  • [C-3-2] MÜSSEN das auf GATT (allgemeine Attributprofil) basierende Bluetooth aktivieren APIs wie in der SDK-Dokumentation beschrieben und android.bluetooth.
  • [C-3-3] MÜSSEN den richtigen Wert für BluetoothAdapter.isOffloadedFilteringSupported() ein, um anzugeben, ob der Filterlogik für den ScanFilter API-Klassen implementiert sind.
  • [C-3-4] MÜSSEN den richtigen Wert für BluetoothAdapter.isMultipleAdvertisementSupported() zum Anzeigen von ob energiesparende Werbung unterstützt wird.
  • [C-3-5] MÜSSEN kein Zeitlimit für eine auflösbare Privatadresse (RPA) mehr implementieren als 15 Minuten dauern und die Adresse bei einer Zeitüberschreitung rotieren, um die Privatsphäre der Nutzer zu schützen wenn das Gerät BLE zum Scannen oder Werben verwendet. Um Timing-Angriffe zu verhindern, MÜSSEN Zeitüberschreitungsintervalle ebenfalls zufällig festgelegt werden. zwischen 5 und 15 Minuten.

  • SOLLTEN die Übertragung der Filterlogik auf den Bluetooth-Chipsatz unterstützen. wenn Sie die ScanFilter API implementieren.

  • SOLLTEN die Übertragung des Batch-Scans auf den Bluetooth-Chipsatz unterstützen.

  • SOLLTEN mehrere Anzeigen mit mindestens 4 Anzeigenflächen unterstützen.

Wenn Geräteimplementierungen Bluetooth LE unterstützen und Bluetooth LE für Standortsuche:

  • [C-4-1] MÜSSEN eine Funktion zum Aktivieren/Deaktivieren des Lesens des Werts anbieten. über die System API BluetoothAdapter.isBleScanAlwaysAvailable().

Wenn Geräteimplementierungen Unterstützung für Bluetooth LE und Hörgeräte umfassen Profil, wie in Unterstützung von Hörgeräten über Bluetooth LE:

Wenn Geräteimplementierungen Bluetooth oder Bluetooth Low Energy unterstützen, Sie:

  • [C-6-1] MÜSSEN den Zugriff auf alle Bluetooth-Metadaten (z. B. Scans) einschränken. Ergebnisse), die zur Ableitung des Gerätestandorts verwendet werden können, es sei denn, Die anfragende App besteht erfolgreich ein android.permission.ACCESS_FINE_LOCATION Berechtigungsprüfung anhand des aktuellen Vorder-/Hintergrundstatus

Ob die Geräteimplementierung Bluetooth oder Bluetooth Low Energy unterstützt und das App-Manifest keine Erklärung des Entwicklers enthält, die angibt, dass sie ihren Standort nicht von Bluetooth, Dann geschieht Folgendes:

Wenn Geräteimplementierungen true für die BluetoothAdapter.isLeAudioSupported() API verwenden, geschieht Folgendes:

  • [C-7-1] MUSS den Unicast-Client unterstützen.
  • [C-7-2] MUSS 2 Mio. PHY unterstützen.
  • [C-7-3] MUSS LE Extended-Werbung unterstützen.
  • [C-7-4] MUSS mindestens zwei CIS-Verbindungen in einem CIG unterstützen.
  • [C-7-5] MÜSSEN BAP-Unicast-Client, CSIP-Set-Koordinator, MCP-Server, VCP-Controller und CCP-Server gleichzeitig.
  • [C-SR-1] Es wird dringend empfohlen, den HAP-Unicast-Client zu aktivieren.

Wenn Geräteimplementierungen true für die BluetoothAdapter.isLeAudioBroadcastSourceSupported() API verwenden, geschieht Folgendes:

  • [C-8-1] MUSS mindestens zwei BIS-Links in einem BIG unterstützen.
  • [C-8-2] MÜSSEN BAP-Broadcast-Quelle, BAP-Broadcast-Assistent aktiviert werden. gleichzeitig.
  • [C-8-3] MUSS Periodic Advertising von LE unterstützen.

Wenn Geräteimplementierungen true für die BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API verwenden, geschieht Folgendes:

  • [C-9-1] MUSS Past (Periodic Advertising Sync Transfer) unterstützen.
  • [C-9-2] MUSS Periodic Advertising von LE unterstützen.

Wenn in Geräteimplementierungen FEATURE_BLUETOOTH_LE deklariert wird, gilt Folgendes:

  • [C-10-1] RSSI-Messungen MUSS bei 95% des Temperaturbereichs zwischen +/-9 dB liegen. Messungen in 1 m Entfernung von einem Referenzgerät, das ADVERTISE_TX_POWER_HIGH in Sichtweite.
  • [C-10-2] MÜSSEN Rx/Tx-Korrekturen aufnehmen, um Abweichungen pro Kanal zu reduzieren. sodass die Messungen auf jedem der drei Kanäle an jeder Antenne (bei Verwendung mehrerer) in einem Bereich von +/-3 dB zu 95% des Messungen.
  • [C-SR-2] wird dringend empfohlen, den Rx-Versatz zu messen und zu kompensieren. Achten Sie darauf, dass der Medianwert für BLE RSSI -60 dBm +/-10 dB in 1 m Entfernung von einem Referenzgerät, das an ADVERTISE_TX_POWER_HIGH sendet, wobei die Geräte die so ausgerichtet sind, dass sie auf „parallelen Ebenen“ wobei die Bildschirme in die gleiche Richtung Richtung.
  • [C-SR-3] Es wird dringend empfohlen, die Tx-Abweichung zu messen und zu kompensieren. Achten Sie darauf, dass der Medianwert für BLE RSSI beim Scannen von einer Referenz -60 dBm +/-10 dB beträgt. Gerät in 1 m Entfernung positioniert und sendet ADVERTISE_TX_POWER_HIGH, wo die Geräte so ausgerichtet sind, dass sie eingeschaltet sind "parallele Ebenen" mit Bildschirmen, die in die gleiche Richtung zeigen.

Es wird dringend empfohlen, die unter Voraussetzungen für die Anwesenheitskalibrierung

7.4.4 Nahfeldkommunikation

Geräteimplementierungen:

  • SOLLTEN einen Transceiver und die zugehörige Hardware für den Nahfeldbereich enthalten. Kommunikation (NFC).
  • [C-0-1] MÜSSEN android.nfc.NdefMessage und android.nfc.NdefRecord APIs auch dann, wenn sie keine Unterstützung für NFC oder das Feature android.hardware.nfc deklarieren, da die Klassen ein protokollunabhängigen Datendarstellungsformat.

Wenn Geräteimplementierungen NFC-Hardware beinhalten und planen, sie für alle Drittanbieter-Apps:

  • [C-1-1] MÜSSEN die android.hardware.nfc-Funktion über den Methode android.content.pm.PackageManager.hasSystemFeature().
  • MUSS NDEF-Nachrichten über folgende NFC-Funktion lesen und schreiben können wie unten dargestellt:
  • [C-1-2] MUSS als NFC-Forumsleser/-Schreiber fungieren können (gemäß den technischen Spezifikationen des NFC-Forums). NFCForum-TS-DigitalProtocol-1.0) über die folgenden NFC-Standards: <ph type="x-smartling-placeholder">
      </ph>
    • NfcA (ISO14443-3A)
    • NFCB (ISO 14443-3B)
    • NFCF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC-Forum Tag-Typen 1, 2, 3, 4, 5 (definiert vom NFC-Forum)
  • [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, NDEF zu lesen und zu schreiben Nachrichten sowie Rohdaten über die folgenden NFC-Standards. Beachten Sie, dass NFC-Standards sind zwar als AUSSCHLIEẞLICH EMPFOHLEN, Die Kompatibilitätsdefinition für eine zukünftige Version wird diese an MUSS. Diese Standards sind in dieser Version optional, erforderlich in zukünftigen Versionen. Vorhandene und neue Geräte, auf denen diese Version von ausgeführt wird Android wird dringend geraten, diese Anforderungen jetzt zu erfüllen, können sie ein Upgrade auf die zukünftigen Plattform-Releases durchführen.

  • [C-1-13] MÜSSEN während der NFC-Erkennung alle unterstützten Technologien abrufen. .

  • SOLLTEN Sie sich im NFC-Erkennungsmodus befinden, während das Gerät aktiv ist und das Gerät Bildschirm aktiv und der Sperrbildschirm entsperrt.

  • SOLLTEN Barcode und URL (falls codiert) von NFC-Barcode von Thinfilm zu verbessern.

Beachten Sie, dass öffentlich verfügbare Links für JIS, ISO und NFC nicht verfügbar sind. oben zitierte Forenspezifikationen.

Android unterstützt den NFC-Modus "Host Card Emulation" (HCE).

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz enthalten (für NfcA und/oder NfcB und unterstützen das Routing von Anwendungs-IDs (AID) wie folgt:

  • [C-2-1] MÜSSEN die android.hardware.nfc.hce-Funktionskonstante melden.
  • [C-2-2] MÜSSEN NFC HCE APIs als die im Android SDK definiert sind.

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz enthalten für NfcF und zur Implementierung der Funktion für Anwendungen von Drittanbietern:

  • [C-3-1] MÜSSEN die android.hardware.nfc.hcef-Funktionskonstante melden.
  • [C-3-2] MÜSSEN die NfcF Card Emulation APIs implementieren wie im Android SDK definiert.

Wenn Geräteimplementierungen allgemeinen NFC-Support wie in diesem MIFARE-Technologien (MIFARE Classic, MIFARE Ultralight, NDEF auf MIFARE Classic) in der Rolle „Leser/Autor“:

  • [C-4-1] MÜSSEN die entsprechenden Android-APIs gemäß den das Android SDK.
  • [C-4-2] MÜSSEN die Funktion com.nxp.mifare aus dem android.content.pm.PackageManager.hasSystemFeature() . Beachten Sie, dass dies keine Standardfunktion von Android ist und dementsprechend auch nicht werden in der Klasse android.content.pm.PackageManager als Konstante angezeigt.

7.4.5 Netzwerkprotokolle und APIs

7.4.5.1 Minimale Netzwerkfähigkeit

Geräteimplementierungen:

  • [C-0-1] MÜSSEN Support für eine oder mehrere Formen der Datennetzwerken. Insbesondere MÜSSEN Geräteimplementierungen Support für mindestens einen Datenstandard, der 200 Kbit/s oder mehr unterstützen kann. Beispiele für Technologien, die diese Anforderung erfüllen, sind EDGE, HSPA, EV-DO, 802.11g, Ethernet- und Bluetooth-PAN.
  • SOLLTEN auch mindestens eine gängige drahtlose Datenverbindung unterstützt werden. wie 802.11 (Wi-Fi), wenn ein physischer Netzwerkstandard (z. B. Ethernet) ist die primäre Datenverbindung.
  • KANN mehr als eine Form der Datenverbindung implementieren.
7.4.5.2 IPv6

Geräteimplementierungen:

  • [C-0-2] MÜSSEN einen IPv6-Netzwerkstack enthalten und IPv6 unterstützen Kommunikation über verwaltete APIs wie java.net.Socket und java.net.URLConnection und die nativen APIs wie AF_INET6 Sockets.
  • [C-0-3] MUSS IPv6 standardmäßig aktivieren.
    • MÜSSEN sicherstellen, dass die IPv6-Kommunikation so zuverlässig ist wie IPv4, zum Beispiel: <ph type="x-smartling-placeholder">
        </ph>
      • [C-0-4] MÜSSEN die IPv6-Verbindungen im Stromsparmodus aufrechterhalten.
      • [C-0-5] Ratenbegrenzung DARF NICHT zum Verlust von IPv6 auf dem Gerät führen. mit einem IPv6-kompatiblen Netzwerk, das RA-Lebensdauer mindestens 180 Sekunden lang.
  • [C-0-6] MÜSSEN Anwendungen von Drittanbietern eine direkte IPv6-Verbindung zur Verfügung stellen. mit dem Netzwerk verbunden, wenn eine Verbindung mit einem IPv6-Netzwerk besteht, ohne dass die Portübersetzung lokal auf dem Gerät erfolgt. Sowohl verwaltete APIs wie Socket#getLocalAddress oder Socket#getLocalPort) und NDK APIs wie getsockname() oder IPV6_PKTINFO MÜSSEN die IP-Adresse und Port, der zum Senden und Empfangen von Paketen auf der Netzwerk und ist für Internetserver (Webserver) als Quell-IP und Quellport sichtbar.

Die erforderliche IPv6-Unterstützung hängt vom Netzwerktyp ab, wie in die folgenden Anforderungen erfüllen.

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

  • [C-1-1] MÜSSEN Dual-Stack- und Nur-IPv6-Betrieb im WLAN unterstützen.

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

  • [C-2-1] MUSS Dual-Stack- und Nur-IPv6-Betrieb unterstützen auf Ethernet

Wenn Geräteimplementierungen mobile Daten unterstützen, gilt Folgendes:

  • [C-3-1] MUSS IPv6-Betrieb (nur IPv6 und möglicherweise Dual-Stack) unterstützen auf Mobilfunk.

Wenn Geräteimplementierungen mehr als einen Netzwerktyp unterstützen (z.B. WLAN und mobile Daten), gilt Folgendes:

  • [C-4-1] MÜSSEN die oben genannten Anforderungen für jedes Netzwerk gleichzeitig erfüllen. Das Gerät ist gleichzeitig mit mehr als einem Netzwerktyp verbunden.
7.4.5.3 Captive Portals

Ein Captive Portal bezieht sich auf ein Netzwerk, Zugang zum Internet zu erhalten.

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

  • [C-1-1] MÜSSEN eine Captive Portal-Anwendung zur Verarbeitung des Intents bereitstellen. ACTION_CAPTIVE_PORTAL_SIGN_IN und die Anmeldeseite des Captive Portal anzeigen, indem der Intent gesendet wird, Aufruf der System-API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
  • [C-1-2] MÜSSEN die Erkennung von Captive Portals und die Support-Anmeldung durchführen. über die Captive Portal-Anwendung, wenn das Gerät verbunden ist mit jedem Netzwerktyp, einschließlich Mobilfunk-/Mobilfunknetz, WLAN, Ethernet oder Bluetooth.
  • [C-1-3] MUSS die Anmeldung in Captive Portals mit Klartext-DNS unterstützen Das Gerät ist für den strikten Modus für privates DNS konfiguriert.
  • [C-1-4] MÜSSEN gemäß der SDK-Dokumentation für android.net.LinkProperties.getPrivateDnsServerName und android.net.LinkProperties.isPrivateDnsActive Netzwerkverkehr, der nicht explizit mit dem Captive Portal.
  • [C-1-5] MUSS sicherstellen, dass Nutzer sich bei der Anmeldung in einem Captive das von Anwendungen verwendete Standardnetzwerk (wie vom ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback, und wird standardmäßig von Java-Netzwerk-APIs wie java.net.Socket, und native APIs wie connect()) ist ein beliebiges anderes die gegebenenfalls einen Internetzugang bietet.

7.4.6 Synchronisierungseinstellungen

Geräteimplementierungen:

  • [C-0-1] MÜSSEN die automatische Master-Synchronisierung standardmäßig aktiviert haben, damit die Methode getMasterSyncAutomatically() gibt "true" zurück.

7.4.7 Datensparmodus

Wenn Geräteimplementierungen eine getaktete Verbindung beinhalten, gilt Folgendes:

  • [C-SR-1] UNBEDINGT EMPFOHLEN, den Datensparmodus bereitzustellen.

Wenn Geräteimplementierungen den Datensparmodus unterstützen, ist Folgendes möglich:

  • [C-1-1] MUSS alle APIs im ConnectivityManager unterstützen enthalten, wie in der SDK-Dokumentation beschrieben

Wenn Geräteimplementierungen den Datensparmodus nicht unterstützen, kann das folgende Gründe haben:

7.4.8 Secure Elemente

Wenn Geräteimplementierungen Open Mobile API-fähige Funktionen unterstützen Elemente zu sichern und sie für Drittanbieter-Apps zur Verfügung zu stellen, geschieht Folgendes:

7.4.9 UWB

Wenn Geräteimplementierungen Support beinhalten für 802.1.15.4 und stellen die Funktionalität einer Drittanbieteranwendung zur Verfügung. dann:

  • [C-1-1] MÜSSEN die entsprechende Android API in android.uwb implementieren.
  • [C-1-2] MÜSSEN das Hardwarefunktions-Flag „android.hardware.uwb“ melden.
  • [C-1-3] MUSS alle relevanten UWB-Profile unterstützen, die in Android definiert sind Implementierung.
  • [C-1-4] MÜSSEN eine Funktion anbieten, mit der Nutzer das UWB aktivieren und deaktivieren können. aktiviert/deaktiviert.
  • [C-1-5] MÜSSEN erzwingen, dass Apps, die die UWB-Funkschnittstelle verwenden, die Berechtigung UWB_RANGING verwenden (unter der Berechtigungsgruppe NEARBY_GERÄTE).
  • [C-SR-1] EMPFOHLEN, die relevanten Konformitäts- und Zertifizierungstests, die von Standardorganisationen definiert wurden, darunter: FIRA und CC und CSA.
  • [C-1-6] MÜSSEN darauf achten, dass die Entfernungsmessungen bei 95 % zwischen +/-15 cm liegen der Messungen in der Sichtweite bei 1 m Entfernung in einem nicht reflektierende Kammer.
  • [C-1-7] MÜSSEN darauf achten, dass der Medianwert der Entfernungsmessungen bei 1 m liegt. vom Referenzgerät entfernt liegt [0,75 m bis 1,25 m], wo Ground-Truth-Wert Der Abstand wird vom oberen Rand des DUTs gemessen.
  • [C-SR-2] Wir empfehlen dringend, die Schritte zur Einrichtung der Analyse zu befolgen angegeben in Voraussetzungen für die Anwesenheitskalibrierung

7.5 Kameras

Wenn eine Geräteimplementierung mindestens eine Kamera umfasst, gilt Folgendes:

  • [C-1-1] MUSS das Funktions-Flag android.hardware.camera.any deklarieren.
  • [C-1-2] MÜSSEN möglich sein, damit eine Anwendung gleichzeitig 3 RGBA_8888-Bitmaps, die der Größe der Bilder entsprechen, Kamerasensor mit der größten Auflösung des Geräts, während die Kamera für die und trotzdem erfassen.
  • [C-1-3] MÜSSEN sicherstellen, dass die vorinstallierte Kamera-App Umgang mit Intents MediaStore.ACTION_IMAGE_CAPTURE MediaStore.ACTION_IMAGE_CAPTURE_SECURE, oder MediaStore.ACTION_VIDEO_CAPTURE, ist dafür verantwortlich, den Nutzerstandort aus den Bildmetadaten zu entfernen, bevor wenn diese nicht an die empfangende Anwendung haben ACCESS_FINE_LOCATION.

Wenn Geräteimplementierungen die 10-Bit-HDR-Ausgabe unterstützen, gilt Folgendes:

  • [C-2-1] MUSS mindestens das HLG-HDR-Profil für jedes Kameragerät unterstützen die 10-Bit-Ausgabe unterstützt.
  • [C-2-2] MUSS 10-Bit-Ausgabe für die Primärseite der Rückseite oder den primären Frontkamera.
  • [C-SR-1] Es wird dringend empfohlen, die 10-Bit-Ausgabe für die primäre Kameras.
  • [C-2-3] MUSS für alle dieselben HDR-Profile unterstützen BACKWARD_COMPATIBLE-fähige physische Teilkameras einer logischen Kamera und der logischen Kamera selbst.

Für logische Kamerageräte, die 10-Bit-HDR-Video unterstützen und die android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO-API kann Folgendes ausgeführt werden:

  • [C-3-1] MUSS den Wechsel zwischen allen abwärtskompatiblen physischen über das Steuerelement „CONTROL_ZOOM_RATIO“ an der logischen Kamera.

7.5.1 Rückkamera

Eine Kamera auf der Rückseite ist eine nach außen gerichtete Kamera, die Szenen von der äußeren Seite wie bei einer herkömmlichen Kamera; auf Handheld-Geräten, d. h. eine Kamera an der Seite des Geräts gegenüber dem Display.

Geräteimplementierungen:

  • SOLLTE eine Rückkamera enthalten.

Wenn Geräteimplementierungen mindestens eine Kamera auf der Rückseite enthalten, ist Folgendes zu beachten:

  • [C-1-1] MÜSSEN die Funktions-Flags android.hardware.camera und android.hardware.camera.any.
  • [C-1-2] MUSS eine Auflösung von mindestens 2 Megapixel haben.
  • SOLLTEN entweder Hardware-Autofokus oder Software-Autofokus implementiert werden. im Kameratreiber (für die Anwendungssoftware sichtbar) ein.
  • KÖNNEN mit Fixfokus oder EDOF-Hardware (erweiterte Tiefenschärfe) ausgestattet sein.
  • KANN einen Blitz enthalten.

Wenn die Kamera einen Blitz hat:

  • [C-2-1] Die Blitzlampe DARF NICHT eingeschaltet werden, wenn android.hardware.Camera.PreviewCallback Instanz wurde registriert auf einer Kamera-Vorschauoberfläche, es sei denn, die App hat durch Aktivieren der Attribute FLASH_MODE_AUTO oder FLASH_MODE_ON eines Camera.Parameters-Objekts. Beachten Sie, dass diese Einschränkung nicht für den über die integrierte Systemkamera-App Ihres Geräts, aber nur für Drittanbieter Anwendungen, die Camera.PreviewCallback verwenden.

7.5.2 Frontkamera

Eine Frontkamera ist eine Kamera, die für den Nutzer in der Regel zum Aufnehmen von Fotos z. B. für Videokonferenzen und ähnliche Anwendungen; auf Handheld Geräte, also eine Kamera, die sich an der Seite des Geräts wie das Display befindet.

Geräteimplementierungen:

  • KANN eine Frontkamera enthalten.

Wenn Geräteimplementierungen mindestens eine Frontkamera umfassen, ist Folgendes zu beachten:

  • [C-1-1] MÜSSEN die Funktions-Flags android.hardware.camera.any und android.hardware.camera.front.
  • [C-1-2] MUSS mindestens eine Auflösung von mindestens VGA (640 x 480 Pixel) haben.
  • [C-1-3] DÜRFEN KEINE Frontkamera als Standardkamera für Camera API und DÜRFEN die API NICHT so konfigurieren, dass eine Frontkamera als Standardrückkamera verwenden, auch wenn es die einzige Kamera des Geräts ist.
  • [C-1-4] Die Kameravorschau MUSS horizontal relativ zum Ausrichtung, die von der Anwendung angegeben wird, wenn die aktuelle Anwendung ausdrücklich verlangt, dass die Kamera Anzeige über einen Aufruf des android.hardware.Camera.setDisplayOrientation() . Umgekehrt muss die Vorschau mit den Standardeinstellungen des Geräts gespiegelt werden. horizontale Achse, wenn die aktuelle Anwendung nicht explizit anfordert dass das Kameradisplay durch einen Aufruf des android.hardware.Camera.setDisplayOrientation() .
  • [C-1-5] DÜRFEN NICHT das fertig aufgenommene Standbild oder die endgültigen Videostreams spiegeln. an Anwendungs-Callbacks zurückgegeben oder an den Medienspeicher übergeben werden.
  • [C-1-6] MÜSSEN das in PostView angezeigte Bild auf dieselbe Weise spiegeln. als Bildstream der Kameravorschau ein.
  • KÖNNEN Funktionen wie Autofokus oder Blitz enthalten, die für Kameras auf der Rückseite, 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 relativ zur Kamera gespiegelt werden. aktuellen Ausrichtung des Geräts angezeigt.

7.5.3 Externe Kamera

Eine externe Kamera ist eine Kamera, die an ihr angeschlossen oder von ihr getrennt werden kann. Geräteimplementierung und kann in jede Richtung ausgerichtet werden; wie USB Kameras.

Geräteimplementierungen:

  • KÖNNEN auch Support für eine externe Kamera anbieten, die nicht unbedingt immer verbunden.

Wenn Geräteimplementierungen eine externe Kamera unterstützen, gilt Folgendes:

  • [C-1-1] MÜSSEN das Funktions-Flag für die Plattform angeben. android.hardware.camera.external und android.hardware camera.any.
  • [C-1-2] MUSS die USB-Videoklasse (UVC 1.0 oder höher) unterstützen, wenn die externe Die Kamera wird über den USB-Hostport verbunden.
  • [C-1-3] MÜSSEN die CTS-Tests der Kamera mit einem physischen externen Kameragerät bestehen. verbunden. Details zu den CTS-Tests für Kameras finden Sie unter source.android.com.
  • SOLLTEN Komprimierungen von Videos wie MJPEG unterstützen, um die Übertragung von nicht codierte Streams von hoher Qualität (d. h. rohe oder unabhängig komprimiertes Bild). Streams).
  • KANN mehrere Kameras unterstützen.
  • KANN die kamerabasierte Videocodierung unterstützen.

Wenn die kamerabasierte Videocodierung unterstützt wird:

  • [C-2-1] Eine gleichzeitige nicht codierter / MJPEG-Stream (QVGA oder höhere Auflösung) für Nutzer der Geräteimplementierung.

7.5.4 Verhalten der Camera API

Android beinhaltet zwei API-Pakete für den Zugriff auf die Kamera: das neuere über die API android.hardware.camera2 die untergeordnete Kamerasteuerung der App einschließlich effizienter Zero-Copy-Burst-/Streaming-Abläufe und Kontrollen pro Frame Belichtung, Verstärkung, Erhöhung des Weißabgleichs, Farbkonvertierung, Rauschunterdrückung, Schärfe, und vieles mehr.

Das ältere API-Paket android.hardware.Camera ist in Android 5.0, aber da es weiterhin für Apps zur Verfügung stehen sollte. Android-Gerät Implementierungen MÜSSEN eine kontinuierliche Unterstützung der API gewährleisten, wie in den und im Android SDK.

Alle Funktionen der veralteten android.hardware.Camera-Klasse und das neuere android.hardware.camera2-Paket MÜSSEN gleichwertige Leistung aufweisen. und die Qualität in beiden APIs. Bei gleichwertigen Einstellungen Geschwindigkeit und Genauigkeit des Autofokus müssen identisch sein und die Qualität der aufgenommenen Bilder muss identisch sein. müssen identisch sein. Funktionen, die von der unterschiedlichen Semantik der beiden APIs abhängen müssen keine übereinstimmende Geschwindigkeit oder Qualität haben, SOLLTEN aber genauso genau übereinstimmen. wie möglich.

Bei Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs für alle verfügbaren Kameras. Geräteimplementierungen:

  • [C-0-1] MUSS android.hardware.PixelFormat.YCbCr_420_SP für die Vorschau verwenden Daten, die Anwendungs-Callbacks zur Verfügung gestellt werden, wenn eine Anwendung noch nie aufgerufen wurde android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] MUSS weiter im NV21-Codierungsformat vorliegen, wenn eine Anwendung registriert ein android.hardware.Camera.PreviewCallback und das System ruft die Methode onPreviewFrame() und die Vorschau Format YCbCr_420_SP ist, die Daten im Byte[], die an onPreviewFrame() übergeben werden. Das heißt, NV21 MUSS die Standardeinstellung sein.
  • [C-0-3] MUSS das YV12-Format unterstützen (gemäß den android.graphics.ImageFormat.YV12 konstant) für die Kameravorschau für beide Front- und Rückkameras für android.hardware.Camera. (Die Hardware Video-Encoder und Kamera können beliebige native Pixelformate verwenden, aber das Gerät -Implementierung MUSS die Konvertierung in YV12 unterstützen.)
  • [C-0-4] MUSS die android.hardware.ImageFormat.YUV_420_888 und android.hardware.ImageFormat.JPEG-Formate als Ausgaben über den android.media.ImageReader API für android.hardware.camera2 Geräte, die werben für REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities.
  • [C-0-5] MUSS trotzdem die vollständige Camera API implementieren die in der Android SDK-Dokumentation enthalten sind, unabhängig davon, ob das Gerät wie z. B. Hardware-Autofokus. Zum Beispiel Kameras, die ohne Autofokus MUSS trotzdem alle registrierten android.hardware.Camera.AutoFocusCallback Instanzen (obwohl diese keine für eine Kamera ohne Autofokus.) Dies gilt jedoch für die Front- Kameras obwohl die meisten Frontkameras keine Autofokus steht, müssen die API-Callbacks dennoch "gefälscht" sein. wie beschrieben.
  • [C-0-6] MÜSSEN alle Parameternamen erkennen und berücksichtigen. als Konstante in der android.hardware.Camera.Parameters und die Klasse android.hardware.camera2.CaptureRequest. Umgekehrt DÜRFEN Geräteimplementierungen Stringkonstanten NICHT berücksichtigen oder erkennen an die Methode android.hardware.Camera.setParameters() übergeben, die nicht die als Konstanten in der android.hardware.Camera.Parameters dokumentiert. Das heißt: Geräteimplementierungen MÜSSEN alle standardmäßigen Kameraparameter unterstützen, wenn die Hardware erlaubt und DÜRFEN KEINE benutzerdefinierten Kameraparametertypen unterstützen. Zum Beispiel Geräteimplementierungen, die die Bilderfassung unterstützen mit HDR-Bildverarbeitungstechniken MÜSSEN die Kameraparameter unterstützen. Camera.SCENE_MODE_HDR
  • [C-0-7] MÜSSEN die richtige Supportstufe beim android.info.supportedHardwareLevel wie im Android SDK beschrieben, und melde die entsprechenden Flags für Framework-Funktionen.
  • [C-0-8] MÜSSEN auch die Kamerafunktionen android.hardware.camera2 über die android.request.availableCapabilities-Property und die entsprechenden Funktions-Flags deklarieren. MÜSSEN das Funktions-Flag definiert werden, wenn eines der angeschlossenen Kamerageräte vorhanden ist. unterstützt die Funktion.
  • [C-0-9] MUSS die Camera.ACTION_NEW_PICTURE übertragen wenn ein neues Bild mit der Kamera aufgenommen wird und der Bild wurde dem Medienspeicher hinzugefügt.
  • [C-0-10] MUSS die Camera.ACTION_NEW_VIDEO übertragen wenn ein neues Video von der Kamera aufgenommen wird und der Bild wurde dem Medienspeicher hinzugefügt.
  • [C-0-11] MÜSSEN alle Kameras über die veraltete android.hardware.Camera API auch über android.hardware.camera2 zugänglich der API erstellen.
  • [C-0-12] MÜSSEN sicherstellen, dass die Gesichtsdarstellung NICHT verändert wird, einschließlich jedoch nicht beschränkt auf das Ändern von Gesichtsgeometrie, Gesichtshautton oder Hautglättung für jede android.hardware.camera2 oder android.hardware.Camera der API erstellen.
  • [C-SR-1] Für Geräte mit mehreren RGB-Kameras in in die gleiche Richtung zeigen, Es wird dringend empfohlen, ein logisches Kameragerät zu verwenden, das Capability CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, bestehend aus allen RGB-Kameras, die als physische Untergeräte in diese Richtung weisen.

Wenn die Geräteimplementierungen eine proprietäre Kamera-API für Drittanbieter-Apps bereitstellen, Sie:

7.5.5 Kameraausrichtung

Wenn Geräte eine Front- oder Rückkamera haben, z. B. eine oder mehrere Kameras:

  • [C-1-1] MÜSSEN so ausgerichtet werden, dass die lange Seite der Kamera die lange Dimension des Bildschirms. Das heißt, wenn das Gerät im Querformat gehalten wird MÜSSEN Kameras Bilder im Querformat erfassen. Dieses wird unabhängig von der natürlichen Ausrichtung des Geräts angewendet; d. h., sie gilt für primär Geräte im Querformat und primäre Geräte im Hochformat.

Geräte, die alle der folgenden Kriterien erfüllen, sind von der oben genannten Anforderung ausgenommen:

  • Das Gerät verfügt über Displays mit variabler Geometrie, wie z. B. faltbare oder klappbare Displays. angezeigt wird.
  • Wenn sich das zuklappen oder Scharnier des Geräts ändert, wechselt das Gerät zwischen Hochformat und primären zum Querformat und umgekehrt.
  • Geräteimplementierungen, die nicht vom Nutzer rotiert werden können, z. B. wie Automobilgeräte.

7.6 Arbeitsspeicher und Datenspeicher

7.6.1 Mindestanforderungen an Arbeitsspeicher und Speicherplatz

Geräteimplementierungen:

  • [C-0-1] MUSS mit einem Download-Manager die Anwendungen zum Herunterladen von Datendateien verwenden MÖCHTEN, und MÜSSEN in der Lage sein, Herunterladen einzelner Dateien von mindestens 100 MB „Cache“ Standort.

7.6.2 Freigegebener Anwendungsspeicher

Geräteimplementierungen:

  • [C-0-1] MÜSSEN Speicherplatz anbieten, der von Anwendungen gemeinsam genutzt werden kann, auch häufig verwiesene als „freigegebener externer Speicher“, „freigegebener Anwendungsspeicher“ oder von der Linux- Pfad „/sdcard“ auf dem es bereitgestellt ist.
  • [C-0-2] MÜSSEN so konfiguriert sein, dass standardmäßig freigegebener Speicher in anderen sofort einsatzbereit ist, unabhängig davon, ob die Speicherkapazität eine interne Speicherkomponente oder ein austauschbares Speichermedium (z.B. Secure Steckplatz für digitale Karte).
  • [C-0-3] MÜSSEN den freigegebenen Speicher der Anwendung direkt unter dem Linux-Pfad bereitstellen. sdcard oder symbolischen Linux-Link von sdcard zur tatsächlichen Bereitstellung hinzufügen Punkt.
  • [C-0-4] MUSS aktivieren begrenzter Speicher standardmäßig für alle Apps, die auf API-Level 29 oder höher ausgerichtet sind, außer in folgenden Fällen: <ph type="x-smartling-placeholder">
      </ph>
    • Wenn die App android:requestLegacyExternalStorage="true" angefordert hat in ihrem Manifest.
  • [C-0-5] MÜSSEN Standortmetadaten wie GPS-EXIF-Tags entfernt werden, die in Mediendateien, wenn über MediaStore auf diese Dateien zugegriffen wird, es sei denn, die aufrufende App die Berechtigung ACCESS_MEDIA_LOCATION hat.

Geräteimplementierungen KÖNNEN die oben genannten Anforderungen mit einer der Folgendes:

  • Vom Nutzer zugänglicher Wechselspeicher, z. B. ein SD-Kartensteckplatz (Secure Digital).
  • Ein Teil des internen (nicht entfernbaren) Speichers, wie er in den Android Open Source Project (AOSP):

Wenn auf Geräten Wechseldatenträger verwendet werden, um die oben genannten Anforderungen zu erfüllen Anforderungen:

  • [C-1-1] MÜSSEN eine Toast- oder Pop-up-Warnung implementieren, die den Nutzer wenn sich kein Speichermedium im Steckplatz befindet.
  • [C-1-2] MUSS ein Speichermedium im Format FAT enthalten (z. B. eine SD-Karte) oder ein Speichermedium im Format FAT enthalten. auf der Verpackung und anderem Material, das beim Kauf verfügbar war, muss separat erworben werden.

Wenn Geräteimplementierungen einen Teil des nicht entfernbaren Speichers nutzen, Anforderungen erfüllt werden, gilt Folgendes:

  • SOLLTEN die AOSP-Implementierung der internen Speicherplatz.
  • KANN den Speicherplatz mit den privaten Daten der Anwendung teilen.

Wenn Geräte einen USB-Port mit Unterstützung für den USB-Peripheriemodus haben, Sie:

  • [C-3-1] MÜSSEN einen Mechanismus für den Zugriff auf die Daten in der Anwendung bereitstellen. freigegebenen Speicher von einem Hostcomputer.
  • SOLLTEN Inhalte aus beiden Speicherpfaden transparent dargestellt werden: Der Medienscanner-Dienst von Android und android.provider.MediaStore.
  • KANN USB-Massenspeicher verwenden, sollte jedoch das Media Transfer Protocol verwenden, um diese Anforderung erfüllen.

Geräteimplementierungen mit USB-Port mit USB-Peripheriemodus und Unterstützung Media Transfer Protocol, werden sie:

7.6.3 Verwendbare Speicher

Wenn das Gerät – im Gegensatz zum Fernseher – mobil sein soll, Implementierungen auf Geräten:

  • [C-SR-1] UNBEDINGT EMPFOHLEN, den nutzbaren Speicher in an einem dauerhaften, stabilen Standort zu platzieren, da die Verbindung zu Datenverlust/-beschädigung führen.

Wenn sich der Port des Wechseldatenträgers an einem langfristigen stabilen Standort befindet, wie im Batteriefach oder in einer anderen Schutzabdeckung, Implementierungen auf Geräten:

7.7 USB

Wenn Geräteimplementierungen einen USB-Port haben, ist Folgendes zu beachten:

  • SOLLTEN den USB-Peripheriemodus und den USB-Hostmodus unterstützen.
  • SOLLTEN die Deaktivierung der Datensignalisierung über USB unterstützen.

7.7.1 USB-Peripheriemodus

Wenn Geräte einen USB-Port enthalten, der den Peripheriemodus unterstützt:

  • [C-1-1] Der Port MUSS mit einem USB-Host mit einer Typ-A- oder Typ-C-USB-Anschluss.
  • [C-1-2] MÜSSEN den richtigen Wert für iSerialNumber gemäß USB-Standard melden Gerätedeskriptor über android.os.Build.SERIAL.
  • [C-1-3] MÜSSEN Ladegeräte mit 1,5 A und 3,0 A je Typ-C-Widerstand erkennen und MÜSSEN Änderungen an der Anzeige erkennen, sofern sie Typ-C-USB-Port
  • [C-SR-1] Der Port sollte den Formfaktor micro-B, micro-AB oder den USB-Typ-C-Anschluss verwenden. Diese Anforderungen werden dringend für bestehende und neue Android-Geräte empfohlen. Anforderungen erfüllt, damit sie ein Upgrade auf zukünftige Plattform-Releases durchführen können.
  • [C-SR-2] Der Anschluss sollte sich an der Unterseite des Geräts befinden (entsprechend der natürlichen Ausrichtung) oder aktivieren Sie die Software-Bildschirmdrehung für einschließlich des Startbildschirms, sodass das Display beim dass das Gerät am Anschluss unten ausgerichtet ist. Bestehendes und neues Android-Gerät Geräte EMPFOHLEN, diese Anforderungen zu erfüllen, damit sie ein Upgrade auf zukünftige Plattform-Releases ausführen.
  • [C-SR-3] SOLLTEN beim Hochfrequenz-Piepton den Strom von 1,5 A unterstützen und Verkehr entsprechend den Angaben in den Spezifikationen zum Laden des USB-Akkus, Version 1.2. Diese Anforderungen werden dringend für bestehende und neue Android-Geräte empfohlen. Anforderungen erfüllt, damit sie ein Upgrade auf zukünftige Plattform-Releases durchführen können.
  • [C-SR-4] EMPFOHLEN, keine proprietären Produkte zu unterstützen Lademethoden verwenden, bei denen die Vbus-Spannung über die Standardniveaus hinaus verändert oder Senken- und Quellrollen können zu Interoperabilitätsproblemen mit dem Ladegeräte oder Geräte, die die standardmäßigen USB-Power Delivery-Methoden unterstützen. Während Diese wird als „Dringend empfohlen“ bezeichnet. In zukünftigen Android-Versionen Möglicherweise sind alle Typ-C-Geräte ERFORDERLICH, um vollständige Interoperabilität mit Standard- Typ-C-Ladegeräte.
  • [C-SR-5] UNBEDINGT EMPFOHLEN, um Power Delivery für Daten- und Wechsel der Ein/Aus-Rolle, wenn Typ-C-USB- und USB-Hostmodus unterstützt werden.
  • SOLLTEN für Hochspannungsladevorgänge Power Delivery unterstützen und Alternative Modi, z. B. „Display out“.
  • SOLLTEN die Android Open Accessory (AOA) API und die Spezifikation wie folgt implementieren: die in der Android SDK-Dokumentation dokumentiert sind.

Wenn Geräteimplementierungen einen USB-Port umfassen und AOA implementieren spezifizieren, dass sie:

  • [C-2-1] MÜSSEN die Unterstützung für die Hardwarefunktion erklären. android.hardware.usb.accessory
  • [C-2-2] Die USB-Massenspeicherklasse MUSS den String „android“ enthalten. im Ende der Schnittstellenbeschreibung iInterface String des USB-Massenspeichers

7.7.2 USB-Hostmodus

Wenn Geräte einen USB-Port enthalten, der den Hostmodus unterstützt, gilt Folgendes:

  • [C-1-1] MÜSSEN die Android USB Host API entsprechend den Android SDK und MÜSSEN die Unterstützung für die Hardwarefunktion erklären android.hardware.usb.host
  • [C-1-2] MÜSSEN Support für den Anschluss standardmäßiger USB-Peripheriegeräte implementieren, mit anderen Worten, sie MÜSSEN entweder: <ph type="x-smartling-placeholder">
      </ph>
    • Einen Typ-C-Anschluss auf dem Gerät haben oder mit einem oder mehreren Kabeln für das entsprechende Gerät versenden proprietären Port mit einem Standard-USB-Typ-C-Port (USB-Typ-C-Gerät) verbinden.
    • ein Gerät Typ A auf dem Gerät haben oder mit einem oder mehreren Kabeln ausgeliefert werden, die das Gerät anpassen Anschluss an einen Standard-USB-Typ-A-Port.
    • über einen Micro-AB-Port auf dem Gerät verfügen, der mit einem Kabeladapter geliefert werden sollte Standard-A-Port anzuschließen.
  • [C-1-3] DÜRFEN NICHT mit einem Adapter geliefert werden, der von USB Typ A oder micro-AB-Ports mit einem Typ-C-Port (Buchse).
  • [C-SR-1] wird dringend empfohlen, die USB-Audiokurs wie in der Android SDK-Dokumentation beschrieben.
  • SOLLTEN das Laden des verbundenen USB-Peripheriegeräts unterstützen, während es auf dem Host ist mode; mit einer Stromquelle von mindestens 1,5 A gemäß den Abschnitt "Kündigungsparameter" der USB Typ-C-Kabel und -Anschlussspezifikation, Version 1.2 für USB Typ-C Anschlussstecker oder verwenden Sie den CDP-Ausgangsstrombereich des Ladekabels als in den Spezifikationen zum Laden des USB-Akkus, Version 1.2 für Micro-AB-Connectors.
  • SOLLTEN USB-Typ-C-Standards implementieren und unterstützen.

Wenn die Geräteimplementierung einen USB-Anschluss umfasst, der den Hostmodus unterstützt, und das USB-Kabel Audioklasse:

  • [C-2-1] MUSS die USB HID-Klasse unterstützen.
  • [C-2-2] MUSS die Erkennung und Zuordnung der folgenden HID-Daten unterstützen Felder, die in den USB HID-Nutzungstabellen angegeben sind und die Anfrage zur Nutzung von Voice Command für KeyEvent wie unten dargestellt:
    • Nutzungsseite (0xC) Nutzungs-ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Nutzungsseite (0xC) Nutzungs-ID (0x0E9): KEYCODE_VOLUME_UP
    • Nutzungsseite (0xC) Nutzungs-ID (0x0EA): KEYCODE_VOLUME_DOWN
    • Nutzungsseite (0xC) Nutzungs-ID (0x0CF): KEYCODE_VOICE_ASSIST

Wenn die Geräteimplementierung einen USB-Port mit Unterstützung für den Hostmodus und des Storage Access Framework (SAF) erhalten sie:

  • [C-3-1] MÜSSEN ein remote verbundenes MTP (Media Transfer Protocol) erkennen. Geräte und machen ihre Inhalte über ACTION_GET_CONTENT zugänglich, ACTION_OPEN_DOCUMENT- und ACTION_CREATE_DOCUMENT-Intents. .

Wenn Geräte einen USB-Port enthalten, der den Hostmodus und USB unterstützt Typ-C:

  • [C-4-1] MÜSSEN die Funktion „Dual Role Port“ gemäß Definition in Typ-C-Spezifikation (Abschnitt 4.5.1.3.3). Für Dual Rollenports, auf Geräten mit 3, 5-mm-Audiobuchse Erkennung (Hostmodus) KANN standardmäßig deaktiviert sein, aber für den um sie zu aktivieren.
  • [C-SR-2] WIRD DRINGEND zur Unterstützung von DisplayPort empfohlen, SOLLTE USB unterstützen. SuperSpeed-Datenraten und werden UNBEDINGT empfohlen, um Power Delivery zu unterstützen. für den Austausch von Daten und Power-Rollen.
  • [C-SR-3] EMPFOHLEN, den Zubehörmodus des Audioadapters NICHT zu unterstützen als die in Anhang A der USB Typ-C-Kabel und Spezifikationen des USB-Typ-C, Version 1.2
  • SOLLTEN das Try.*-Modell implementieren, das für das Formfaktor des Geräts. Auf einem Handheld sollte beispielsweise „Try.SNK“-Modell.

7.8 Audio

7.8.1 Mikrofon

Wenn Geräte ein Mikrofon enthalten, gilt Folgendes:

  • [C-1-1] MÜSSEN die android.hardware.microphone-Funktionskonstante melden.
  • [C-1-2] MÜSSEN die Anforderungen für Audioaufnahmen in Abschnitt 5.4.
  • [C-1-3] MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6.
  • [C-SR-1] wird dringend empfohlen, die Nah-Ultraschallaufzeichnung wie beschrieben zu unterstützen. in Abschnitt 7.8.3.

Wenn Geräteimplementierungen kein Mikrofon enthalten, geschieht Folgendes:

  • [C-2-1] DARF NICHT die android.hardware.microphone-Funktionskonstante melden.
  • [C-2-2] MÜSSEN die Audio-Aufnahme-API mindestens als managementfrei implementieren, Abschnitt 7.

7.8.2 Audioausgabe

Wenn Geräteimplementierungen einen Lautsprecher oder eine Audio-/Multimedia-Ausgabe umfassen Anschluss für ein Peripheriegerät für die Audioausgabe, z. B. einen 3,5-mm-Audioanschluss mit vier Kabeln oder USB-Hostmodus mit der USB-Audioklasse:

  • [C-1-1] MÜSSEN die android.hardware.audio.output-Funktionskonstante melden.
  • [C-1-2] MUSS die Anforderungen für die Audiowiedergabe in Abschnitt 5.5.
  • [C-1-3] MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6.
  • [C-SR-1] WIRD DRINGEND empfohlen, die Wiedergabe mit Nah-Ultraschall wie beschrieben zu unterstützen in Abschnitt 7.8.3.

Wenn Geräteimplementierungen keinen Lautsprecher- oder Audioausgabeport umfassen, ist Folgendes zu beachten:

  • [C-2-1] DÜRFEN NICHT die Funktion android.hardware.audio.output melden.
  • [C-2-2] MÜSSEN die APIs zur Audioausgabe zumindest als managementfrei implementieren.

In diesem Abschnitt bezieht sich ein „Ausgabeport“ ist ein Physische Schnittstelle 3, 5-mm-Audioanschluss, HDMI oder USB-Hostmodus mit USB-Audioklasse. Unterstützung der Audioausgabe über Funkprotokolle wie Bluetooth, Bei WLAN oder Mobilfunknetzen ist kein „Ausgabeport“ enthalten.

7.8.2.1 Analoge Audioanschlüsse

Um mit den Headsets und anderes Audiozubehör über den 3,5-mm-Audiostecker aus dem Android-Ökosystem, Implementierungen umfassen einen oder mehrere analoge Audioports. Sie:

  • [C-SR-1] Es wird dringend empfohlen, mindestens eines der Audioport(s) als 3,5-mm-Audioanschluss mit 4 Kabeln.

Geräteimplementierungen mit einem 3, 5-mm-Audioanschluss mit 4 Kabeln:

  • [C-1-1] MÜSSEN die Audiowiedergabe über Stereo-Kopfhörer und -Headsets unterstützen. mit einem Mikrofon.
  • [C-1-2] MUSS TRRS-Audiostecker mit CTIA-Pin-out-Reihenfolge unterstützen.
  • [C-1-3] MUSS die Erkennung und Zuordnung zu den Keycodes für die der dreifachen äquivalenten Impedanz zwischen Mikrofon und Erde Kabeln am Audiostecker: <ph type="x-smartling-placeholder">
      </ph>
    • Max. 70 Ohm: KEYCODE_HEADSETHOOK
    • 210–290 Ohm: KEYCODE_VOLUME_UP
    • 360–680 Ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] MUSS ACTION_HEADSET_PLUG bei Steckereinsatz auslösen, aber Erst nachdem alle Kontakte der Steckdose die relevanten Segmente berührt haben am Anschluss.
  • [C-1-5] MUSS mindestens 150 mV ± 10% der Ausgangsspannung eine Lautsprecherimpedanz von 32 Ohm.
  • [C-1-6] MÜSSEN über eine Mikrofonspannung zwischen 1,8 und 2,9 V verfügen.
  • [C-1-7] MUSS den Schlüsselcode für Folgendes erkennen und zuordnen Bereich der äquivalenten Impedanz zwischen Mikrofon und Erdleitern am Audiostecker: <ph type="x-smartling-placeholder">
      </ph>
    • 110–180 Ohm: KEYCODE_VOICE_ASSIST
  • [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, Audiostecker mit OMTP zu unterstützen in der Reihenfolge der Markierungen.
  • [C-SR-3] wird dringend empfohlen, die Audioaufnahme über Stereo zu unterstützen Headsets mit einem Mikrofon.

Geräteimplementierungen mit 4-adrigem 3,5-mm-Audioanschluss und Unterstützung für und das android.intent.action.HEADSET_PLUG mit dem auf „1“ gesetzt ist, können sie:

  • [C-2-1] MUSS die Erkennung des Mikrofons auf dem angeschlossenen Audio unterstützen Zubehörteils.
7.8.2.2 Digitale Audioanschlüsse

Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.2.1.

7.8.3 Nah-Ultraschall

Nah-Ultraschall-Audio ist das Frequenzband von 18,5 kHz bis 20 kHz.

Geräteimplementierungen:

Wenn PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND „true“ ist, MÜSSEN die folgenden Anforderungen vom Audioquellen VOICE_RECOGNITION und UNPROCESSED:

  • [C-1-1] Der durchschnittliche Stromeingang des Mikrofons im Band von 18,5 kHz bis 20 kHz DÜRFEN nicht mehr als 15 dB unter dem Antwortwert bei 2 kHz liegen.
  • [C-1-2] Ungewichtetes Signal-Rausch-Verhältnis des Mikrofons über 18,5 kHz bis 20 kHz für einen 19-kHz-Ton bei -26 dBFS MUSS nicht niedriger als 50 dB sein.

Wenn PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ist „true“:

  • [C-2-1] Der Mittelwert des Lautsprechers in einem Bereich von 18,5 kHz bis 20 kHz DARF nicht unter 40 dB unter dem Wert bei 2 kHz liegen.

7.8.4 Signalintegrität

Geräteimplementierungen:

  • SOLLTEN Sie für beide Eingänge einen störungsfreien Audiosignalpfad bereitstellen. und Ausgabestreams auf Handheld-Geräten. während eines Tests von einer Minute pro Pfad gemessen. Mit OboeTester testen „Automatisierter Glitch-Test“.

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

OboeTester unterstützt derzeit AAudio-Pfade, sodass der folgende Kombinationen SOLLTEN mit AAudio auf Fehler getestet werden:

Performance-Modus Inhalte teilen Aus Stichprobenrate In Chans Out Chans
NIEDRIGE_LATENZ EXKLUSIV KEINE ANGABE 1 2
NIEDRIGE_LATENZ EXKLUSIV KEINE ANGABE 2 1
NIEDRIGE_LATENZ Weiterempfohlen KEINE ANGABE 1 2
NIEDRIGE_LATENZ Weiterempfohlen KEINE ANGABE 2 1
KEINE Weiterempfohlen 48000 1 2
KEINE Weiterempfohlen 48000 2 1
KEINE Weiterempfohlen 44100 1 2
KEINE Weiterempfohlen 44100 2 1
KEINE Weiterempfohlen 16000 1 2
KEINE Weiterempfohlen 16000 2 1

Ein zuverlässiger Stream sollte die folgenden Kriterien für Signal-Rauschen erfüllen Verhältnis (SNR) und Total Harmonic Distortion (THD) für einen Sinus von 2.000 Hz.

Wandler THD SNR-Fehler
primärer eingebauter Lautsprecher, gemessen mit einem externen Referenzmikrofon &lt; 3,0% >= 50 dB
primäres integriertes Mikrofon, gemessen mit einem externen Referenzlautsprecher &lt; 3,0% >= 50 dB
Integrierte analoge 3,5-mm-Anschlüsse, getestet mit dem Loopback-Adapter < 1 % >= 60 dB
Mit dem Smartphone gelieferte USB-Adapter, die mit dem Loopback-Adapter getestet wurden &lt; 1,0% >= 60 dB

7.9. Virtual Reality

Android umfasst APIs und Einrichtungen zur Entwicklung von Virtual Reality (VR) einschließlich hochwertiger VR-Erlebnisse für Mobilgeräte. Gerät Implementierungen MÜSSEN diese APIs und Verhaltensweisen ordnungsgemäß implementieren. wie in diesem Abschnitt beschrieben.

7.9.1 Virtual-Reality-Modus

Android unterstützt VR-Modus, eine Funktion, die Benachrichtigungen stereoskopisch darstellt und monoculare System-UI-Komponenten, während eine VR-App den Fokus auf den Nutzer legt.

7.9.2 Virtual-Reality-Modus – hohe Leistung

Wenn Geräteimplementierungen den VR-Modus unterstützen, gilt Folgendes:

  • [C-1-1] MUSS mindestens zwei physische Kerne haben.
  • [C-1-2] MÜSSEN die Funktion android.hardware.vr.high_performance deklarieren.
  • [C-1-3] MÜSSEN den Modus für kontinuierliche Leistung unterstützen.
  • [C-1-4] MUSS OpenGL ES 3.2 unterstützen.
  • [C-1-5] MUSS android.hardware.vulkan.level 0 unterstützen.
  • SOLLTEN android.hardware.vulkan.level 1 oder höher unterstützen.
  • [C-1-6] MUSS die EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, und die Erweiterungen in der Liste der verfügbaren EGL-Erweiterungen anzeigen.
  • [C-1-8] MUSS die GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen anzeigen.
  • [C-SR-1] sollte unbedingt implementiert werden, GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen anzeigen.
  • [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, Vulkan 1.1 zu unterstützen.
  • [C-SR-3] sollte unbedingt implementiert werden VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, und in der Liste der verfügbaren Vulkan-Erweiterungen angezeigt.
  • [C-SR-4] Es wird dringend empfohlen, mindestens eine Vulkan-Warteschlange offenzulegen, in der flags sowohl VK_QUEUE_GRAPHICS_BIT als auch VK_QUEUE_COMPUTE_BIT enthalten, und queueCount ist mindestens 2.
  • [C-1-7] GPU und Display MÜSSEN in der Lage sein, den Zugriff auf den freigegebenen Frontpuffer, sodass VR-Inhalte mit 60 fps und zwei Renderingkontexte werden ohne sichtbare Tearing-Artefakte angezeigt.
  • [C-1-9] MÜSSEN die Unterstützung für AHardwareBuffer implementieren Flags AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA und AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT. wie im NDK beschrieben.
  • [C-1-10] MÜSSEN die Unterstützung für AHardwareBuffers implementieren mit Kombination der Nutzungs-Flags AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT für mindestens die folgenden Formate: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
  • [C-SR-5] WIRD UNBEDINGT EMPFOHLEN, die Zuweisung von AHardwareBuffers zu unterstützen mit mehr als einem Layer sowie Flags und Formaten, die in C-1-10 angegeben sind.
  • [C-1-11] MUSS H.264-Decodierung mindestens 3840 x 2160 bei 30 fps unterstützen auf durchschnittlich 40 Mbit/s komprimiert (entspricht 4 Instanzen von 1920 × 1080 bei 30 fps–10 Mbit/s oder zwei Instanzen von 1920 × 1080 bei 60 fps–20 Mbit/s).
  • [C-1-12] MUSS HEVC und VP9 unterstützen, MUSS mindestens in der Lage sein, decodieren zu können 1920 x 1080 bei 30 fps, komprimiert auf durchschnittlich 10 Mbit/s, SOLLTE in der Lage sind, 3840 x 2160 bei 30 fps bis 20 Mbit/s zu decodieren (entspricht 4 Instanzen von 1920 × 1080 bei 30 fps–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] MÜSSEN einen eingebetteten Bildschirm haben und die Auflösung MUSS mindestens betragen. 1920 x 1080.
  • [C-SR-6] Eine Bildschirmauflösung von mindestens 2560 x 1440.
  • [C-1-15] Im VR-Modus MUSS das Display mindestens 60 Hz aktualisiert werden.
  • [C-1-17] Das Display MUSS einen Modus mit niedriger Persistenz mit ≤ 5 Millisekunden unterstützen Persistenz, wobei sie als Dauer definiert wird, bei dem ein Pixel Licht ausstrahlt.
  • [C-1-18] MÜSSEN Bluetooth 4.2 und Bluetooth LE-Datenlängenerweiterung unterstützen Abschnitt 7.4.3.
  • [C-1-19] MÜSSEN ordnungsgemäß gemeldet werden Direkter Channeltyp für alle der folgenden Standardsensortypen: <ph type="x-smartling-placeholder">
      </ph>
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] WIRDEN DRINGEND empfohlen, TYPE_HARDWARE_BUFFER Direktkanaltyp für alle oben aufgeführten Arten von direkten Kanälen.
  • [C-1-21] MUSS die Anforderungen des Gyroskops, des Beschleunigungsmessers und des Magnetometers erfüllen. Anforderungen für android.hardware.hifi_sensors, wie angegeben in Abschnitt 7.3.9.
  • [C-SR-8] WIRDEN DRINGEND empfohlen, Funktion „android.hardware.sensor.hifi_sensors“.
  • [C-1-22] MUSS eine End-to-End-Latenz von Bewegung zu Photon aufweisen, die nicht höher ist als 28 Millisekunden.
  • [C-SR-9] WIRD UNBEDINGT EMPFOHLEN, eine End-to-End-Latenz von Bewegung zu Photon zu haben höchstens 20 Millisekunden.
  • [C-1-23] MÜSSEN das Verhältnis für den ersten Frame haben. Dies ist das Verhältnis zwischen Helligkeit der Pixel im ersten Frame nach einem Übergang von Schwarz zu Weiß und die Helligkeit weißer Pixel im stabilen Zustand von mindestens 85%.
  • [C-SR-10] Es wird dringend empfohlen, ein Verhältnis für den ersten Frame von mindestens 90 % zu haben.
  • KANN einen exklusiven Kern für den Vordergrund bereitstellen. Anwendung und KÖNNEN die Process.getExclusiveCores API unterstützen, um die Anzahl der CPU-Kerne, die ausschließlich im oberen Vordergrund vorhanden sind .

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

  • [C-2-1] DÜRFEN die Ausführung anderer Userspace-Prozesse auf dem Tab zulassen (außer Gerätetreiber, die von der Anwendung verwendet werden), aber einige Kernel zulassen KÖNNEN Prozesse nach Bedarf auszuführen.

7:10. Haptik

Geräte, die in der Hand gehalten oder getragen werden, können eine allgemeine Haptik enthalten Bedienelement, das für Anwendungen wie das Erzeugen von Aufmerksamkeit verfügbar ist durch Klingeltöne, Alarme, Benachrichtigungen und allgemeines Touch-Feedback.

Wenn Geräteimplementierungen KEINEN derartigen haptischen Bedienelements für allgemeine Zwecke enthalten, Sie:

  • [7.10/C] MUSS für Vibrator.hasVibrator() "false" zurückgeben.

Wenn Geräteimplementierungen mindestens eine solche Universalhaptik enthalten Bedienelement:

Wenn Geräteimplementierungen der Zuordnung der haptischen Konstanten folgen, gilt Folgendes:

7:11. Media Performance-Klasse

Die Medienleistungsklasse der Geräteimplementierung finden Sie hier: die android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API. Anforderungen für Medienleistungsklasse sind für jede Android-Version definiert, beginnend mit R (Version 30). Der spezielle Wert 0 bedeutet, dass das Gerät kein der Medienleistung.

Wenn Geräteimplementierungen einen Wert ungleich null zurückgeben für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, sie/er:

  • [C-1-1] MUSS mindestens den Wert android.os.Build.VERSION_CODES.R zurückgeben.

  • [C-1-2] MUSS die Implementierung eines Handheld-Geräts sein.

  • [C-1-3] MÜSSEN alle Anforderungen für die Medienleistungsklasse erfüllen. beschrieben in Abschnitt 2.2.7.

Mit anderen Worten: Die Medienleistungsklasse in Android T ist nur für der Version T, S oder R.

Siehe Abschnitt 2.2.7 für gerätespezifische Anforderungen.

8. Leistung und Leistung

Einige Mindestanforderungen an Leistung und Leistung sind entscheidend für die User Experience und wirken sich auf die grundlegenden Annahmen aus, von denen Entwickelnde bei der Entwicklung

8.1. Konsistente Nutzererfahrung

Eine reibungslose Benutzeroberfläche kann für Endanwendende bereitgestellt werden, wenn bestimmte Mindestanforderungen, um eine konsistente Framerate und konsistente Antwortzeiten für Apps und Spiele. Geräteimplementierungen je nach Gerätetyp KÖNNEN messbare Anforderungen an die Latenz der Benutzeroberfläche und die Aufgabe wie in Abschnitt 2 beschrieben.

8.2. Leistung des Datei-E/A-Zugriffs

Bereitstellung einer gemeinsamen Basis für eine konsistente Leistung beim Dateizugriff auf der Der private Datenspeicher einer Anwendung (/data Partition) ermöglicht App-Entwicklern eine angemessene Erwartung festzulegen, die ihrem Softwaredesign helfen würde. Gerät für Implementierungen, KANN je nach Gerätetyp bestimmte Anforderungen erfüllen wie in Abschnitt 2 beschrieben und Schreibvorgänge:

  • Leistung sequentieller Schreibvorgänge: Gemessen durch Schreiben einer 256 MB-Datei mit 10 MB Zwischenspeicher
  • Zufällige Schreibleistung: Gemessen durch Schreiben einer 256 MB großen Datei mit 4 KB Schreibpuffer.
  • Leistung sequentieller Lesevorgänge: Gemessen durch Lesen einer 256 MB-Datei mit 10 MB Zwischenspeicher
  • Zufällige Leseleistung: Gemessen durch Lesen einer 256 MB großen Datei mit 4 KB Schreibpuffer.

8.3. Energiesparmodi

Wenn Geräteimplementierungen Funktionen zur Verbesserung der Energieverwaltung von Geräten enthalten die in AOSP enthalten sind (z.B. App Standby-Bucket, Stromsparmodus) oder die Funktionen erweitern um stärkere Einschränkungen als den EINGESCHRÄNKTEN App-Standby-Bucket anzuwenden, gilt Folgendes:

  • [C-1-1] DARF NICHT von der AOSP-Implementierung für das Auslösen abweichen, Wartung, Wakeup-Algorithmen und der Verwendung globaler Systemeinstellungen Gerätekonfiguration des App-Standbys und des Stromsparmodus.
  • [C-1-2] DÜRFEN NICHT von der AOSP-Implementierung abweichen, wenn Sie globale oder DeviceConfig nutzen, um die Drosselung von Jobs, Alarmen und Netzwerk für Anwendungen in jedem Bucket für Anwendungs-Standby-Modus.
  • [C-1-3] DÜRFEN NICHT von der AOSP-Implementierung bezüglich der Anzahl der App-Standby-Buckets die für App-Standby verwendet werden.
  • [C-1-4] MÜSSEN App-Standby-Buckets implementieren. und Stromsparmodus, wie unter Energiesparmodus beschrieben.
  • [C-1-5] MUSS true zurückgeben für PowerManager.isPowerSaveMode() wenn sich das Gerät im Energiesparmodus befindet.
  • [C-1-6] MÜSSEN Nutzern Angebote zur Anzeige aller ausgenommenen Apps anbieten. aus den Energiesparmodi „App Standby“ und „Stromsparmodus“ oder und MÜSSEN die ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS implementieren. Absicht, den Nutzer aufzufordern, einer App das Ignorieren des Akkus zu erlauben Optimierungen vor.
  • [C-SR-1] EMPFOHLEN, Nutzern ein solches Angebot zu bieten, um den Energiesparmodus zu deaktivieren.
  • [C-SR-2] EMPFOHLEN, Nutzern alle Inhalte anzuzeigen Apps, die vom App-Standby- und Stromsparmodus ausgenommen sind

Wenn bei der Implementierung von Geräten die enthaltenen Energieverwaltungsfunktionen erweitert werden in AOSP ist und diese Erweiterung strengere Einschränkungen anwendet den Seltenen App-Standby-Bucket, siehe Abschnitt 3.5.1.

Zusätzlich zu den Energiesparmodi können Implementierungen auf Android-Geräten einen oder alle der vier Schlaf-Leistungsstatus gemäß Definition in der Configuration and Power Interface (ACPI)

Wenn Geräteimplementierungen den S4-Leistungsstatus gemäß Definition durch den ACPI führen sie

  • [C-1-1] MÜSSEN diesen Status erst erhalten, nachdem der Nutzer eine explizite Aktion ausgeführt hat. das Gerät in den inaktiven Zustand zu versetzen, etwa durch Schließen eines Teil des Geräts oder zum Abschalten eines Fahrzeugs oder Fernsehers) und bevor die Nutzer aktiviert das Gerät wieder, z.B. durch Öffnen des Deckels oder Drehen des Fahrzeugs oder den Fernseher wieder einschalten).

Wenn Geräteimplementierungen den S3-Stromzustand gemäß Definition durch den ACPI führen sie

  • [C-2-1] MÜSSEN die obigen C-1-1-Anforderungen erfüllen oder nur in den S3-Status wechseln, wenn Drittanbieter Anwendungen benötigen keine Systemressourcen (z.B. Bildschirm, CPU).

    Umgekehrt MÜSSEN den S3-Status beendet werden, wenn Drittanbieter-Anwendungen den Systemressourcen, wie in diesem SDK beschrieben.

    Beispiel: Während Anwendungen von Drittanbietern anfordern, dass der Bildschirm bis FLAG_KEEP_SCREEN_ON weiterlaufen lassen, PARTIAL_WAKE_LOCK, DARF das Gerät NICHT in den S3-Status wechseln, außer wie beschrieben In C-1-1 hat der Nutzer eine explizite Aktion ausgeführt, um das Gerät in einen inaktiv. Umgekehrt kann eine Aufgabe, die von Drittanbieter-Apps durch JobScheduler implementiert wird oder Firebase Cloud Messaging Drittanbieter-Apps bereitgestellt werden, MUSS das Gerät den S3-Status beenden, es sei denn, Nutzer hat das Gerät in den Status „Inaktiv“ versetzt. Sie sind nicht umfassend Beispiele und AOSP im