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.

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:

• [7.1.4.2/H-1-1] MUSS die Anforderungen erfüllen im Profil Android Baseline 2021 angegeben.

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:

• [7.1.4.6/H-1-1] MÜSSEN als Ausgabe melden: protobuf-Trace, das dem Schema für GPU-Zähler und GPU entspricht den in der Perfetto-Dokumentation definierten Renderingphasen.
• [7.1.4.6/H-1-2] MÜSSEN konforme Werte melden für die GPU-Zähler des Geräts GPU-Zähler-Trace-Paket-Proto.
• [7.1.4.6/H-1-3] MÜSSEN konforme Werte melden für die GPU RenderStages des Geräts Trace-Paket-Protokoll der Rendering-Phase
• [7.1.4.6/H-1-4] MÜSSEN eine GPU-Frequenz melden. Tracepoint gemäß dem Format power/gpu_frequency.

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)

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

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:

• [7.10/H]* SOLLTEN Sie den Implementierungsstatus überprüfen, indem Sie Folgendes ausführen: android.os.Vibrator.areAllEffectsSupported() und android.os.Vibrator.arePrimitivesSupported() APIs

• [7.10/H]* SOLLTEN eine Qualitätsbewertung für haptische Konstanten.

• [7.10/H]* SOLLTEN das Fallback überprüft und bei Bedarf aktualisiert werden. für nicht unterstützte Primitive konfigurieren, wie im Implementierungsleitfaden nach Konstanten.

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:

  • Wenn auf dem Gerät config_supportsMultiWindow=true festgelegt ist und die App die Metadaten deklariert META_DATA_PANEL_ACTIVITY in der ControlsProviderService -Deklaration, einschließlich des ComponentName einer gültige Aktivität (wie von der API definiert) gilt, MUSS die App die folgenden in diesem Angebot.
  • Wenn in der App keine Metadaten META_DATA_PANEL_ACTIVITY deklariert sind, dann MÜSSEN die angegebenen Felder wie vom ControlsProviderService API sowie in den vom Steuere-APIs.

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

• [3.8.16/H-2-1] MÜSSEN null melden für ControlsProviderService und Control APIs
• [3.8.16/H-2-2] MUSS die Funktion deklarieren android.software.controls melden und legen Sie dafür false fest.

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:

• [7.5.4/H-1-1] MUSS die android.media.action.STILL_IMAGE_CAMERA berücksichtigen und android.media.action.STILL_IMAGE_CAMERA_SECURE und die Kamera wie im SDK beschrieben im Standbildmodus starten.
• [7.5.4/H-1-2] MUSS die android.media.action.VIDEO_CAMERA berücksichtigen die Kamera wie im SDK beschrieben im Videomodus starten.

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

• [3.2.3.1/ H-1-1] MÜSSEN über eine Aktivität verfügen, Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY, wenn die Aufteilungsfunktion aktiviert ist. Die Aktivität MUSS geschützt sein durch android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK und es MÜSSEN MÜSSEN Aktivität des Intents starten, der geparst wird von Einstellungen#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

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

• [7.4.1.2/H-0-1] MUSS das Funktions-Flag android.software.telecom deklarieren.
• [7.4.1.2/H-0-2] MÜSSEN das Telekommunikations-Framework implementieren.

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:

• [8.4/H-1-1] MUSS die android.intent.action.POWER_USAGE_SUMMARY und zeigt ein Einstellungsmenü an, das diesen Energieverbrauch anzeigt.

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)

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)

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)

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)

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)

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:

• MÜSSEN die in Android 14 CDD, Abschnitt 2.2.7.1 aufgeführten Anforderungen an Medien erfüllen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

• [5.2/H-2-1] MÜSSEN das im Video definierte Mindestqualitätsziel erfüllen Verzerrungskurven der Encoder-Rate für AVC- und HEVC-Codecs der Hardware gemäß Definition in Führe Tests der Leistungsklasse 14 (PC14) – VEQ-Tests (Videocodierungsqualität) durch.

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:

• MÜSSEN die in Android 14 CDD, Abschnitt 2.2.7.2 aufgeführten Anforderungen an Medien erfüllen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

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:

• MÜSSEN die in Android 14 CDD, Abschnitt 2.2.7.3 aufgeführten Anforderungen an Medien erfüllen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

• [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-3-1] MUSS einen HDR-Bildschirm mit mindestens 1.000 cd/m2 haben Durchschnitt.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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:

• MÜSSEN die in Android 14 CDD, Abschnitt 2.2.7.4 aufgeführten Leistungsanforderungen erfüllen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

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:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2
• [5.3.2/T-0-7] AV1

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)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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:

• [8.3/T-1-2] MÜSSEN das Gerät als ein akkubetriebenes Gerät verwenden, wie unter Batterielose Geräte unterstützen beschrieben.

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)

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)

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:

• [7.1.4.2/W-1-1] MUSS die Anforderungen erfüllen im Profil Android Baseline 2021 angegeben.

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

• [7.1.4.2/A-1-1] MUSS die Anforderungen erfüllen im Profil Android Baseline 2021 angegeben.

Implementierungen von Automobilgeräten:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

• [7.2.3/A-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.3/A-0-1] MÜSSEN implementieren und melden GEAR_SELECTION NIGHT_MODE, PERF_VEHICLE_SPEED und PARKING_BRAKE_ON.
• [7.3/A-0-2] Der Wert des NIGHT_MODE Flag MÜSSEN mit dem Tag-/Nachtmodus im Dashboard übereinstimmen und auf dem Eingang des Umgebungslicht-Sensors. Der zugrunde liegende Umgebungslicht-Sensor KANN derselbe sein als Fotometer.
• [7.3/A-0-3] MUSS zusätzliches Infofeld für den Sensor angeben TYPE_SENSOR_PLACEMENT als Teil von SensorAdditionalInfo für jeden bereitgestellten Sensor.
• [7.3/A-SR1] KANN Standort durch Kombination von GPS/GNSS mit zusätzlichen Sensoren. Wenn Standort ist UNBEDINGT EMPFOHLEN, zugehöriger Sensor und/oder Fahrzeugeigenschaften-IDs verwendet.

• [7.3/A-0-4] Der Standort angefragt über LocationManager#requestLocationUpdates() DÜRFEN KEINE Zuordnung zu einer Karte erhalten.

• [7.3.1/A-0-4] MUSS den Koordinatensystem der Autosensoren.

• [7.3/A-SR-1] Sind STRONGLY_RECOMMENDED, um eine 3-Achse zu enthalten. Beschleunigungsmesser und 3-Achsen-Gyroskop.

• [7.3/A-SR-2] Implementierung und Berichterstattung STRONGLY_RECOMMENDED TYPE_HEADING-Sensor.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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:

• [7.5/A-7-1] MÜSSEN eine solche Kamera-API mithilfe von android.hardware.camera2 API oder Extended View System API.

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)

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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)

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)

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)

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:

• [3.9.3/A-1-1] MÜSSEN alle Properties für den Nutzerlebenszyklus <ph type="x-smartling-placeholder">
  </ph>
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

Implementierungen von Automobilgeräten:

• [3.14/A-0-1] MUSS ein UI-Framework zur Unterstützung enthalten. Drittanbieter-Apps, die die im Abschnitt 3.14.
• [3.14/A-0-2] MUSS dem Nutzer eine sichere Interaktion ermöglichen mit Medienanwendungen während der Fahrt.
• [3.14/A-0-3] MUSS die CAR_INTENT_ACTION_MEDIA_TEMPLATE impliziten Intent-Aktion mit dem CAR_EXTRA_MEDIA_PACKAGE extra.
• [3.14/A-0-4] MUSS eine Option zum Aufrufen von einer Medienanwendung Präferenz Aktivitäten, MUSS sie aber nur aktivieren, wenn die UX-Einschränkungen für das Auto nicht gelten.
• [3.14/A-0-5] MUSS angezeigt werden Fehlermeldungen von Medien-Apps festgelegt und MÜSSEN die optionalen Extras unterstützen. ERROR_RESOLUTION_ACTION_LABEL und ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] MUSS eine In-App-Suchoption für Apps, die die Suche unterstützen.
• [3.14/A-0-7] MUSS respektieren CONTENT_STYLE_BROWSABLE_HINT und CONTENT_STYLE_PLAYABLE_HINT wenn Sie den MediaBrowser aufrufen, Hierarchie.

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

• [3.14/A-1-1] MÜSSEN Mediendienste angeben und öffnen mit dem CAR_INTENT_ACTION_MEDIA_TEMPLATE die Nutzerabsicht verstehen.

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:

• [9.5/A-1-1] DÜRFEN Nutzern NICHT gestatten, mit noch nicht zum Headless System User wechseln, mit Ausnahme der Gerätebereitstellung.
• [9.5/A-1-2] MUSS zu einem Sekundärnutzer wechseln vor dem BOOT_COMPLETED.
• [9.5/A-1-3] MUSS die Fähigkeit unterstützen, ein Gastnutzer selbst wenn die maximale Anzahl von Nutzern auf einem Gerät erreicht ist.

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)

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)

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)

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)

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_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_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_ABIS	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) der nativen Anzeige Code. Siehe Abschnitt 3.3. Native API Kompatibilität.
UNTERSTÜTZT_32_BIT_ABIS	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) der nativen Anzeige Code. Siehe Abschnitt 3.3. Native API Kompatibilität.
UNTERSTÜTZT_64_BIT_ABIS	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) von nativen Code. Siehe Abschnitt 3.3. Nativ API-Kompatibilität.
CPU_ABI	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) der nativen Anzeige Code. Siehe Abschnitt 3.3. Native API Kompatibilität.
CPU_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_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_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_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:

• [C-1-1] MUSS die android.settings.HOME_SETTINGS berücksichtigen Standard-App-Einstellungsmenü für den Startbildschirm anzuzeigen.

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

• [C-2-1] MÜSSEN ein Einstellungsmenü bereitstellen, android.provider.Telephony.ACTION_CHANGE_DEFAULT ein Dialogfeld zum Ändern der Standard-SMS-App anzuzeigen.

• [C-2-2] MUSS die android.telecom.action.CHANGE_DEFAULT_DIALER berücksichtigen Intent, ein Dialogfeld anzuzeigen, über das der Nutzer die Standard-Telefonnummer ändern kann. .

  • MUSS die Benutzeroberfläche der vom Nutzer ausgewählten Standard-Telefon-App für eingehende mit Ausnahme von Notrufen, bei denen das Telefon App vorinstalliert.

• [C-2-3] MÜSSEN die android.telecom.action.CHANGE_PHONE_ACCOUNTS berücksichtigen Nutzer sollen die Möglichkeit haben, die ConnectionServices zu konfigurieren. die mit PhoneAccounts verknüpft sind, wie sowie ein standardmäßiges PhoneAccount, das der Telekommunikationsanbieter für ausgehende Anrufe verwendet. Die AOSP-Implementierung erfüllt diese Anforderung durch einschließlich der Option „Anrufkonten“ im Menü „Anrufe“ im Menü „Einstellungen“.

• [C-2-4] MUSS android.telecom.CallRedirectionService zulassen für eine App, die den android.app.role.CALL_REDIRECTION enthält Rolle.

• [C-2-5] MÜSSEN Nutzern die Möglichkeit bieten, eine App mit dem android.app.role.CALL_REDIRECTION Rolle.

• [C-2-6] MUSS die Richtlinie android.intent.action.SENDTO berücksichtigen und android.intent.action.VIEW Intents erstellen und eine Aktivität zum Senden/Anzeigen von SMS-Nachrichten bereitstellen.

• [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, android.intent.action.ANSWER zu berücksichtigen, android.intent.action.CALL, android.intent.action.CALL_button, android.intent.action.VIEW und android.intent.action.DIAL Intents mit einer vorinstallierten Telefonanwendung, die diese Intents verarbeiten kann, die im SDK beschriebene Auftragsausführung zu ermöglichen.

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

• [C-3-1] MUSS die android.settings.NFC_PAYMENT_SETTINGS berücksichtigen. wird ein Standardmenü für App-Einstellungen für kontaktloses Bezahlen angezeigt.
• [C-3-2] MUSS android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT berücksichtigen eine Aktivität anzuzeigen, die ein Dialogfeld öffnet, in dem der Nutzer aufgefordert wird, Standardkartenemulationsdienst für eine bestimmte Kategorie, wie im SDK beschrieben.

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

• [C-4-1] MÜSSEN diese Intents android.nfc.action.NDEF_DISCOVERED berücksichtigen, android.nfc.action.TAG_DISCOVERED und android.nfc.action.TECH_DISCOVERED, eine Aktivität zu zeigen, die die Erwartungen der Entwickler an diese Intents erfüllt, wie im SDK beschrieben.

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

• [C-5-1] MUSS die Richtlinie 'android.bluetooth.adapter.action.REQUEST_ENABLE' berücksichtigen und eine Systemaktivität anzeigen, damit der Nutzer Bluetooth aktivieren kann.
• [C-5-2] MÜSSEN die „android.bluetooth.adapter.action.REQUEST_DISCOVERABLE“ und zeigen eine Systemaktivität an, die den Erkennbarkeitsmodus anfordert.

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

• [C-6-1] MÜSSEN eine Aktivität implementieren, die auf den Intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, 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:

• [C-9-1] MUSS die Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI implementieren Intent-APIs wie in der SDK-Dokumentation beschrieben.

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

• [C-10-1] MÜSSEN in den Einstellungen eine Benutzeroberfläche bereitstellen, Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS damit Nutzer Anwendungen hinzufügen oder entfernen können. auf der Zulassungsliste steht.

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

• [C-11-1] MÜSSEN über eine Aktivität verfügen, Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS aber KANN als No-Op implementiert werden.

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

• [C-12-3] MÜSSEN und nur vorinstallierte Android-Apps zulassen zur Verarbeitung der folgenden Intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, und MediaStore.ACTION_VIDEO_CAPTURE enthalten, wie im SDK-Dokument beschrieben.

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

• [C-13-1] MÜSSEN den Intent android.app.action.ADD_DEVICE_ADMIN berücksichtigen zum Aufrufen einer Benutzeroberfläche, um den Nutzer durch Hinzufügen des Geräteadministrators zu das System nicht verarbeiten oder es ablehnen kann.

• [C-13-2] MÜSSEN die Intents respektieren android.app.action.PROVISION_MANAGED_PROFILE android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD und android.app.action.START_ENCRYPTION und eine Aktivität haben, die die Auftragsausführung für diese Intents ermöglicht, wie beschrieben hier im SDK.

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

• [C-14-1] MUSS die AutofillService vollständig implementieren und AutofillManager APIs verwenden und den android.settings.REQUEST_SET_AUTOFILL_SERVICE berücksichtigen ein Standardmenü für App-Einstellungen anzuzeigen, um Autofill zu aktivieren und zu deaktivieren. den standardmäßigen Autofill-Service für den Nutzer ändern.

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:

• [C-18-1] MUSS die android.settings.ACTION_VOICE_INPUT_SETTINGS respektieren Standard-App-Einstellungsmenü für Spracheingabe und Unterstützung anzeigen.

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:

• [C-19-1] MUSS die Funktion NfcAdapter.ACTION_TRANSACTION_DETECTED implementieren. Intent API (als „EVT_TRANSACTION“ gemäß der technischen Spezifikation der GSM Association TS.26 – Anforderungen an NFC-Mobilgeräte)

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-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">
  </ph>
  • Anwendungscache/Offlinevorgang
  • <Video> Tag
  • Standortbestimmung
• [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. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

Die obige Liste ist nicht vollständig. 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:

• [C-2-1] MÜSSEN true melden für ShortcutManager.isRequestPinShortcutSupported()
• [C-2-2] MÜSSEN Nutzer vor dem Hinzufügen einer Verknüpfung gefragt werden, welche Funktion das Nutzerangebot nutzen kann. von Apps über den ShortcutManager.requestPinShortcut() API-Methode.
• [C-2-3] MÜSSEN angepinnte Verknüpfungen sowie dynamische und statische Tastenkombinationen unterstützen. wie auf der Seite „App-Verknüpfungen“ beschrieben.

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

• [C-3-1] MÜSSEN false melden für ShortcutManager.isRequestPinShortcutSupported()

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:

• [C-2-1] MÜSSEN true melden für AppWidgetManager.html.isRequestPinAppWidgetSupported()
• [C-2-2] MÜSSEN Nutzer vor dem Hinzufügen einer Verknüpfung gefragt werden, welche Funktion das Nutzerangebot nutzen kann. von Apps über den AppWidgetManager.requestPinAppWidget() API-Methode.

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

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.

• Bei Geräteimplementierungen können die Attribute des Gerätestandard-Designs, die Anwendungen.

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,

• [C-1-2] MÜSSEN den aktuellen Status des Standorts anzeigen. im Menü „Standort“ in den Einstellungen.
• [C-1-3] DÜRFEN KEINE Standortmodi anzeigen im Menü „Standort“ in den Einstellungen.

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)

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)

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)

3.9.1.2 Bereitstellung verwalteter Profile

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

• [C-1-1] MÜSSEN die APIs implementieren. sodass eine DPC-Anwendung (Device Policy Controller) zur Inhaber eines neuen verwalteten Profils

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

• [C-2-1] Geräteimplementierungen MÜSSEN die Bereitstellung ohne Gerät unterstützen Richtlinienmanagement-Bewerbung für Rolleninhaber AOSP bietet eine Referenzimplementierung.

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:

• [C-1-1] MÜSSEN Konflikte mit Geräterichtlinien gemäß der Dokumentation Device Policy Resolution Framework

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:

• [C-1-1] MUSS die Android TTS-Framework APIs

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

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:

• [C-1-1] MUSS das Funktions-Flag FEATURE_COMPANION_DEVICE_SETUP deklarieren. .
• [C-1-2] MÜSSEN sicherstellen, dass die APIs in der android.companion -Paket vollständig implementiert ist.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

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	WebM (WebM) WEBM Matroska (.mkv)
VP9	Weitere Informationen finden Sie in Abschnitt 5.3.	WebM (WebM) WEBM Matroska (.mkv)
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-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:

  • Format:Lineare PCM, 16 Bit
  • Abtastraten:8.000, 11.025, 16.000, 44.100, 48.000 Hz
  • Kanäle:Mono
  • Audioquellen:DEFAULT MIC, CAMCORDER VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, oder VOICE_PERFORMANCE. Dies gilt auch für die entsprechenden Eingabevoreinstellungen in AAudio, Beispiel: AAUDIO_INPUT_PRESET_CAMCORDER.

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

• [C-SR-1] sollte dies STRONGLY_RECOMMENDED über AcousticEchoCanceler erklären. API-Methode AcousticEchoCanceler.isAvailable()
• [C-SR-2] sind STRONGLY_RECOMMENDED, damit dieser Audioeffekt verwendet werden kann steuerbar mit AcousticEchoCanceler der API erstellen.
• [C-SR-3] dienen zur eindeutigen Identifizierung jeder AEC-Technologie STRONGLY_RECOMMENDED. Implementierung über die Methode AudioEffect.Descriptor.uuid ein.

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)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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)

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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:

  • USB-Hostmodus, Abschnitt 7.7
  • MIDI over Bluetooth LE in zentraler Rolle, Abschnitt 7.4.3

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

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräte eine 3,5-mm-Audiobuchse mit 4 Kabeln enthalten, ist Folgendes zu beachten:

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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:

• [C-0-1] MUSS die Android-Entwicklertools unterstützen, die im SDK.
• Android Debug Bridge (ADB)

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

  • [C-2-1] MUSS true zurückgeben für ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] MÜSSEN den Test-Harnischmodus wie in Dokumentation zum Test-Harnischmodus

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

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:

• [C-1-1] MÜSSEN korrekte Werte für alle mit Android kompatiblen Displays gemeldet werden die in den android.util.DisplayMetrics API

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)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

• [C-0-1] MUSS einen Eingabemechanismus wie eine Touchscreen oder Navigation ohne Touchscreen, um zwischen den UI-Elementen zu navigieren.

7.2.1 Tastatur

Wenn Geräteimplementierungen Drittanbieter-Unterstützung beinhalten IME-Anwendungen (Eingabemethoden-Editoren) müssen folgende Voraussetzungen erfüllen:

• [C-1-1] MUSS die android.software.input_methods deklarieren Funktions-Flag.
• [C-1-2] MUSS Input Management Framework vollständig implementieren
• [C-1-3] MUSS eine vorinstallierte Softwaretastatur haben.

Geräteimplementierungen:

• [C-0-1] DÜRFEN KEINE Hardwaretastatur enthalten, die nicht 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:

• [C-0-1] MÜSSEN den richtigen Wert für android.content.res.Configuration.navigation.

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:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() MUSS nur verwendet werden, um den Bereich zur Gestenerkennung für das Zuhause zu melden.
• [C-6-2] Gesten, die innerhalb eines Ausschlussrechtecks beginnen, wie vom Anwendung im Vordergrund über View#setSystemGestureExclusionRects(), aber außerhalb von WindowInsets#getMandatorySystemGestureInsets(), DÜRFEN NICHT von der Navigationsfunktion abgefangen werden, solange der Ausschluss rect innerhalb des maximalen Ausschlusslimits zulässig ist, wie in den Dokumentation für View#setSystemGestureExclusionRects()
• [C-6-3] MÜSSEN der App im Vordergrund ein MotionEvent.ACTION_CANCEL sobald eine Berührung von einer Systemgeste abgefangen wird, an die App im Vordergrund MotionEvent.ACTION_DOWN .
• [C-6-4] MÜSSEN Nutzern die Möglichkeit bieten, zu einem Bildschirm zu wechseln. Navigationsschaltflächen nutzen (z. B. in den Einstellungen).
• SOLLTEN Sie die Startbildschirm-Funktion bereitstellen, indem Sie vom unteren Rand des Displays nach oben wischen. aktuelle Ausrichtung des Bildschirms.
• SOLLTE vor dem Loslassen der Funktion „Letzte Apps“ als Wischen nach oben und Halten vor dem Loslassen dienen. wie bei der Touch-Geste für den Startbildschirm.
• Gesten, die innerhalb WindowInsets#getMandatorySystemGestureInsets() SOLLTEN NICHT von den vom Vordergrund bereitgestellten Ausschlusskriterien betroffen sein. Bewerbung über View#setSystemGestureExclusionRects()

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,

• [C-2-1] DARF NICHT SENSOR_TYPE_AMBIENT_TEMPERATURE definieren für den Temperatursensor.

Wenn Geräte einen Sensor zur Überwachung der Hauttemperatur enthalten, dann:

• [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die PowerManager.getThermalHeadroom der API erstellen.

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.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• 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)

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-6] MÜSSEN die individuelle Flagge für diese biometrische (d.h. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE, oder DevicePolicymanager.KEYGUARD_DISABLE_IRIS.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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

• [C-1-1] MÜSSEN TYPE_HINGLE_ANGLE implementieren und melden.
• [C-1-2] MUSS mindestens zwei Messwerte zwischen 0 und 360 Grad unterstützen (einschließlich 0 und 360 Grad).
• [C-1-3] MUSS einen Wakeup zurückgeben. Sensor für getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

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:

• [C-3-1] MÜSSEN die android.hardware.telephony.euicc Funktions-Flag.

Wenn die Systemeigenschaft ro.telephony.iwlan\_operation\_mode bei Geräteimplementierungen nicht auf „Legacy“ gesetzt wird, geschieht Folgendes:

• [C-4-1] DARF NICHT 'NETWORK_TYPE_IWLAN' melden über NetworkRegistrationInfo#getAccessNetworkTechnology() wenn NetworkRegistrationInfo#getTransportType() wird als TRANSPORT_TYPE_WWAN gemeldet für dieselbe NetworkRegistrationInfo-Instanz an.

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:

• [C-5-1] MUSS die android.hardware.telephony.ims deklarieren und eine vollständige Implementierung der ImsService API für MMTEL und RCS User Capability Exchange API.
• [C-5-2] MUSS die android.hardware.telephony.ims.singlereg deklarieren Funktions-Flag und bieten eine vollständige Implementierung der SipTransport API, die GbaService API dedizierten Inhaber über IRadio 1.6 HAL und die Bereitstellung über den Auto Configuration Server (ACS) oder eine andere proprietäre Bereitstellung mithilfe der IMS-Konfigurations-API.

Wenn Geräteimplementierungen die Funktion android.hardware.telephony melden, dann:

• [C-6-1] Die SmsManager#sendTextMessage und SmsManager#sendMultipartTextMessage MÜSSEN zu entsprechenden Aufrufen an führen. CarrierMessagingService zur Bereitstellung von SMS-Funktionen. SmsManager#sendMultimediaMessage und SmsManager#downloadMultimediaMessage MÜSSEN zu entsprechenden Aufrufen an führen. CarrierMessagingService zur Bereitstellung von Multimedia-Messaging-Funktionen.
• [C-6-2] Die von android.provider.Telephony.Sms#getDefaultSmsPackage MÜSSEN verwenden SmsManager APIs beim Senden und Empfangen von SMS und MMS verwendet werden. Die AOSP-Referenz Implementierung in Paketen/Apps/Messaging erfüllt diese Anforderung.
• [C-6-3] Die Anwendung, die auf Intent#ACTION_DIAL MÜSSEN die Eingabe beliebiger Wählcodes im Format *#*#CODE#*#* und eine entsprechende TelephonyManager#ACTION_SECRET_CODE Nachricht an alle.
• [C-6-4] Die Anwendung, die auf Intent#ACTION_DIAL MÜSSEN verwenden VoicemailContract.Voicemails#TRANSCRIPTION wird Nutzern die visuelle Sprache-zu-Text-Umwandlung von Mailboxnachrichten angezeigt, wenn sie visuelle Sprache-zu-Text-Umwandlungen von Mailboxnachrichten.
• [C-6-5] MÜSSEN alle SubscriptionInfo mit entsprechenden Gruppen-UUIDs als einzelnes Abo in allen für den Nutzer sichtbaren Angebote Informationen zur SIM-Karte verwalten Beispiele für solche Angebote sind Einstellungen Schnittstellen, die den Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS oder EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
• [C-6-6] DÜRFEN KEINE Kontrolle von SubscriptionInfo mit einem Nicht-Null-Gruppen-UUID und opportunistischer Teil, in allen für den Nutzer sichtbaren Angebote, Konfiguration und Kontrolle der Einstellungen der SIM-Karte zulassen

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:

• [C-10-1] MÜSSEN die android.hardware.telephony.euicc.mep Funktions-Flag.

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

• [C-2-1] MÜSSEN eine Funktion zum Aktivieren/Deaktivieren des Lesens des Werts anbieten. über die WifiManager.isScanAlwaysAvailable API-Methode.

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.

7.4.2.2 WLAN: Tunneled Direct Link-Einrichtung

Geräteimplementierungen:

• SOLLTEN Support für Wi-Fi Tunneled Direct Link Setup (TDLS) wie in der Android SDK-Dokumentation beschrieben.

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:

• SOLLTE Support für Wi-Fi Aware beinhalten.

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:

• [C-2-1] MÜSSEN die APIs zur Standorterkennung implementieren: setRangingEnabled, setMinDistanceMm setMaxDistanceMm und onServiceDiscoveredWithinRange verwendet.

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:

• SOLLTE Unterstützung für WLAN-Standort beinhalten.

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:

• [C-2-1] MUSS ERROR_UNSUPPORTED zurückgeben.

7.4.2.7 Wi-Fi Easy Connect (Protokoll für die Gerätebereitstellung)

Geräteimplementierungen:

• SOLLTEN Wi-Fi Easy Connect (DPP) unterstützen.

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

• [C-1-1] MUSS die Funktion WifiManager#isEasyConnectSupported() gibt true zurück.

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:

• [C-5-1] MUSS true zurückgeben für BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) aus.

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:

• [C-6-2] MÜSSEN den Bluetooth-Zugriff hinter dem android.permission.ACCESS_FINE_LOCATION steuern.

Wenn Geräteimplementierungen true für die BluetoothAdapter.isLeAudioSupported() API 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:

• [C-2-1] MUSS den Wert RESTRICT_BACKGROUND_STATUS_DISABLED für ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] DARF NICHT übertragen werden ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

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:

• [C-1-1] MÜSSEN die verfügbaren Lesegeräte für sichere Elemente über android.se.omapi.SEService.getReaders() API

• [C-1-2] MÜSSEN die korrekten Funktions-Flags über android.hardware.se.omapi.uicc für das Gerät mit UICC-basierten sicheren Elementen, android.hardware.se.omapi.ese für das Gerät mit eSE-basierten sicheren Elementen android.hardware.se.omapi.sd für das Gerät mit SD-basierten sicheren Elementen.

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:

• [C-1-1] MÜSSEN eine solche Kamera-API mit android.hardware.camera2 implementieren. der API erstellen.
• KANN für android.hardware.camera2 Anbieter-Tags und/oder Erweiterungen bereitgestellt werden. der API erstellen.

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:

• SOLLTE mit dem Android-MTP-Referenzhost kompatibel sein, Android File Transfer (Android-Datenübertragung)
• SOLLTE eine USB-Geräteklasse von 0x00 melden.
• MÜSSEN den Namen „MTP“ für die USB-Schnittstelle melden.

7.6.3 Verwendbare Speicher

Wenn das Gerät – im Gegensatz zum Fernseher – mobil sein soll, 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:

• [C-SR-2] EMPFOHLENE Implementierung adaptiven Speicherplatz.

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:

• MÜSSEN die Unterstützung von Nah-Ultraschall-Audiofunktion über die AudioManager.getProperty API so:

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	< 3,0%	>= 50 dB
primäres integriertes Mikrofon, gemessen mit einem externen Referenzlautsprecher	< 3,0%	>= 50 dB
Integrierte analoge 3,5-mm-Anschlüsse, getestet mit dem Loopback-Adapter	< 1 %	>= 60 dB
Mit dem Smartphone gelieferte USB-Adapter, die mit dem Loopback-Adapter getestet wurden	&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:

• [C-1-1] MUSS für Vibrator.hasVibrator() "true" zurückgeben.
• DU DARF KEINEN haptischen Bedienungselement mit exzentrischer rotierender Masse (ERM) verwendet werden.
• SOLLTEN alle öffentlichen Konstanten für eine eindeutige Haptik implementieren in android.view.HapticFeedbackConstants nämlich (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START und GESTURE_END).
• SOLLTEN alle öffentlichen Konstanten für eine eindeutige Haptik implementieren in android.os.VibrationEffect nämlich (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK und EFFECT_DOUBLE_CLICK) und alle zulässigen öffentlichen PRIMITIVE_*-Konstanten für Hohe Haptik in android.os.VibrationEffect.Composition (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN und THUD). Einige dieser Primitive, z. B. LOW_TICK und SPIN sind möglicherweise nur realisierbar, wenn die Vibration relativ niedrige Frequenzen.
• SOLLTEN Sie den Richtlinien für die Kartierung öffentlicher Konstanten folgen. in android.view.HapticFeedbackConstants den empfohlenen android.os.VibrationEffect mit den entsprechenden Amplitudenbeziehungen.
• SOLLTE diese verknüpften Zuordnungen der haptischen Konstanten verwenden.
• SOLLTEN Sie die Qualitätsprüfung durchlaufen für createOneShot() und createWaveform() APIs
• SOLLTEN bestätigt werden, dass das Ergebnis der öffentlichen android.os.Vibrator.hasAmplitudeControl() API die Vibrationsfähigkeiten des Nutzers korrekt widerspiegelt.
• SOLLTEN die Funktionen für die Amplituden-Skalierbarkeit durch Ausführung von android.os.Vibrator.hasAmplitudeControl() prüfen.

Wenn Geräteimplementierungen der Zuordnung der haptischen Konstanten folgen, gilt Folgendes:

• SOLLTEN Sie den Implementierungsstatus überprüfen, indem Sie android.os.Vibrator.areAllEffectsSupported() ausführen. und android.os.Vibrator.arePrimitivesSupported() APIs
• SOLLTE eine Qualitätsprüfung durchführen für haptische Konstanten.
• SOLLTEN Sie die Fallback-Konfiguration für nicht unterstützte Primitive wie im Implementierungsleitfaden beschrieben nach Konstanten.
• SOLLTE Fallback-Unterstützung bereitgestellt werden, um das Fehlerrisiko wie beschrieben zu minimieren. hier.

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 implementiert umfangreiche Wakeup-Signale, die einen Wakeup auslösen aus diesem Bundesstaat.

8.4. Berechnung des Stromverbrauchs

Eine genauere Berechnung und Berichterstellung des Energieverbrauchs liefert App-Entwickler sowohl Anreize als auch Tools zur Optimierung des Stromverbrauchs Muster der Anwendung.

Geräteimplementierungen:

• [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, ein Leistungsprofil pro Komponente anzugeben zur Definition des Werts des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung des Akkus aufgrund der wie auf der Website des Android Open Source Project dokumentiert.
• [C-SR-2] UNBEDINGT EMPFOHLEN, alle Werte des Energieverbrauchs in Milliampere anzugeben Stunden (mAh).
• [C-SR-3] UNBEDINGT EMPFOHLEN, den CPU-Energieverbrauch pro Prozess-UID zu melden. Das Android Open Source-Projekt erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• [C-SR-4] UNBEDINGT EMPFOHLEN, diesen Stromverbrauch über das adb shell dumpsys batterystats Shell-Befehl an den App-Entwickler senden.
• SOLLTEN der Hardwarekomponente selbst zugeordnet werden, wenn einer Anwendung den Stromverbrauch von Hardwarekomponenten zuordnen.

8.5. Konstante Leistung

Bei leistungsstarken Apps mit langer Laufzeit kann die Leistung stark schwanken, Entweder, weil andere Apps im Hintergrund laufen, oder weil die CPU gedrosselt ist aufgrund von Temperaturgrenzen. Android umfasst programmatische Schnittstellen, sodass das Gerät fähig ist, kann die oberste Anwendung im Vordergrund anfordern, dass das die Zuweisung von Ressourcen optimieren, um solche Schwankungen zu beseitigen.

Geräteimplementierungen:

• [C-0-1] MÜSSEN die Unterstützung des Modus für kontinuierliche Leistung korrekt melden. über die PowerManager.isSustainedPerformanceModeSupported() API-Methode.

• SOLLTEN den Modus für kontinuierliche Leistung unterstützen.

Wenn Geräteimplementierungen den Modus für kontinuierliche Leistung unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN für die Anwendung im Vordergrund einheitlich die Leistung mindestens 30 Minuten lang angezeigt, wenn die App dies anfordert.
• [C-1-2] MÜSSEN die Window.setSustainedPerformanceMode() API und andere verwandte APIs.

Wenn Geräteimplementierungen zwei oder mehr CPU-Kerne umfassen, gilt Folgendes:

• SOLLTEN mindestens einen exklusiven Kern bereitstellen, der vom oberen Knoten reserviert werden kann. Anwendung im Vordergrund.

Wenn Geräteimplementierungen die Reservierung eines exklusiven Kerns für den oberen Anwendung im Vordergrund:

• [C-2-1] MÜSSEN über die Process.getExclusiveCores() API-Methode: die ID-Nummern der exklusiven Kerne, die reserviert werden können von der obersten App im Vordergrund aus.
• [C-2-2] DÜRFEN mit Ausnahme der Gerätetreiber keine Prozesse im Nutzerbereich zulassen die von der Anwendung für die Ausführung auf den exklusiven Kernen verwendet werden, aber KANN einige Kernel-Prozesse nach Bedarf auszuführen.

Wenn Geräteimplementierungen keinen exklusiven Kern unterstützen, geschieht Folgendes:

• [C-3-1] MÜSSEN eine leere Liste über die Process.getExclusiveCores() API-Methode.

9. Kompatibilität des Sicherheitsmodells

Geräteimplementierungen:

• [C-0-1] MÜSSEN ein einheitliches Sicherheitsmodell implementieren mit dem Sicherheitsmodell der Android-Plattform, Referenzdokument zu Sicherheit und Berechtigungen finden Sie in den APIs in der Android-Entwicklerdokumentation.

• [C-0-2] MUSS die Installation selbst signierter ohne zusätzliche Berechtigungen/Zertifikate von Dritten/Behörden.

Wenn in Geräteimplementierungen die android.hardware.security.model.compatible deklariert ist Funktion:

• [C-1-1] MUSS die in den folgenden Unterabschnitten aufgeführten Anforderungen erfüllen.

9.1 Berechtigungen

Geräteimplementierungen:

• [C-0-1] MUSS das Android-Berechtigungsmodell unterstützen und Android-Rollenmodell wie in der Android-Entwicklerdokumentation definiert. Insbesondere MÜSSEN alle Berechtigungen und Rollen erzwungen werden, die in den SDK-Dokumentation keine Berechtigungen und keine Rollen ausgelassen, geändert, ignoriert oder ignoriert werden.

• KANN zusätzliche Berechtigungen hinzufügen, sofern die neuen Berechtigungs-ID-Strings verwendet werden. befinden sich nicht im Namespace android.\*.

• [C-0-2] Berechtigungen mit protectionLevel von PROTECTION_FLAG_PRIVILEGED DÜRFEN nur Apps gewährt werden, die vorinstalliert sind unter den privilegierten Pfaden des System-Image (sowie APEX-Dateien) und müssen innerhalb der Teilmenge der explizit zugelassenen Berechtigungen für jede App. Die AOSP-Implementierung erfüllt diese Anforderung, indem die Berechtigungen für jede App aus den Dateien im etc/permissions/-Pfad und die Verwendung des system/priv-app-Pfads als privilegierten Pfad.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Berechtigungen mit dem Schutzniveau „gefährlich“ sind Laufzeitberechtigungen. Anwendungen mit targetSdkVersion > 22 fordern sie zur Laufzeit an.

Geräteimplementierungen:

• [C-0-3] MÜSSEN eine dedizierte Oberfläche angezeigt werden, auf der der Nutzer seine Entscheidung treffen kann. ob die angeforderten Laufzeitberechtigungen gewährt und auch Eine Schnittstelle, über die Nutzer Laufzeitberechtigungen verwalten können.

• [C-0-5] DÜRFEN Apps KEINERLEI Laufzeitberechtigungen gewähren, es sei denn:

  • Sie werden zum Zeitpunkt der Gerätelieferung installiert UND

  • Die Einwilligung des Nutzers kann vor der Anwendung eingeholt werden die Berechtigung verwendet,

    ODER

  • Laufzeitberechtigungen sind gewährt durch die Standardrichtlinie zur Erteilung von Berechtigungen oder eine Plattformrolle innehat.

• [C-0-6] MÜSSEN die Berechtigung android.permission.RECOVER_KEYSTORE erteilen. nur für System-Apps, die einen ordnungsgemäß gesicherten Wiederherstellungs-Agent registrieren. A ordnungsgemäß gesicherter Wiederherstellungs-Agent ist definiert als Software-Agent auf dem Gerät. der sich mit einem Remote-Speicher außerhalb des Geräts synchronisiert, der sichere Hardware mit gleichwertigen oder stärkeren Schutzfunktionen als beschrieben in Google Cloud Key Vault um Brute-Force-Angriffe auf den Wissensfaktor des Sperrbildschirms zu verhindern.

Geräteimplementierungen:

• [C-0-7] MÜSSEN die Eigenschaften der Android-Berechtigung zur Standortermittlung eingehalten werden, wenn eine App fordert die Daten zum Standort oder zur körperlichen Aktivität über die standardmäßige Android API an. proprietärer Mechanismus. Zu diesen Daten gehören unter anderem:

  • Der Standort des Geräts (z.B. Breiten- und Längengrad) gemäß der Beschreibung in Abschnitt 9.8.8.
  • Informationen zur Bestimmung oder Schätzung des Standort (z.B. SSID, BSSID, Cell-ID oder Standort des Netzwerks, mit dem das Gerät verbunden ist).
  • Die körperliche Aktivität des Nutzers oder die Einordnung der körperlichen Aktivität.

Genauer gesagt, Geräteimplementierungen:

• [C-0-8] MÜSSEN die Nutzereinwilligung eingeholt werden, damit eine App auf die Daten zu Ihrem Standort oder Ihrer körperlichen Aktivität.
• [C-0-9] MUSS NUR der App mit Berechtigung wie im SDK beschrieben. Beispiel: TelephonyManager#getServiceState erfordert android.permission.ACCESS_FINE_LOCATION).

Die einzigen Ausnahmen für die oben genannten Eigenschaften der Android-Berechtigung zur Standortermittlung gelten für Apps, die nicht auf den Standort zugreifen, um den Nutzerstandort zu ermitteln oder zu ermitteln insbesondere:

• Wenn Apps die Berechtigung „RADIO_SCAN_WITHOUT_LOCATION“ haben.
• Für die Gerätekonfiguration und ‐einrichtung, bei denen System-Apps die NETWORK_SETTINGS- oder NETWORK_SETUP_WIZARD-Berechtigung.

Berechtigungen können als eingeschränkt gekennzeichnet werden und so ihr Verhalten ändern.

• [C-0-10] Berechtigungen, die mit dem Flag hardRestricted gekennzeichnet sind, DÜRFEN NICHT sein die einer App gewährt wurden, es sei denn:

  • In der Systempartition befindet sich eine APK-Datei der App.
  • Der Nutzer weist eine Rolle zu, die mit hardRestricted verknüpft ist Berechtigungen für eine App.
  • Das Installationsprogramm gewährt einer App die Berechtigung „hardRestricted“.
  • Einer App wird auf einer älteren Android-Version der hardRestricted gewährt.

• [C-0-11] Apps mit der Berechtigung softRestricted MUSS nur eingeschränkt werden und DÜRFEN KEINEN Vollzugriff erhalten, bis Sie auf die Zulassungsliste gesetzt wurden, wie in den SDK, in dem uneingeschränkter und eingeschränkter Zugriff für jede softRestricted definiert ist Berechtigung, z. B. READ_EXTERNAL_STORAGE.

• [C-0-12] DÜRFEN KEINE benutzerdefinierten Funktionen oder APIs zur Umgehung des in setPermissionPolicy definierte Berechtigungsbeschränkungen und setPermissionGrantState APIs

• [C-0-13] MÜSSEN die AppOpsManager APIs zum Aufzeichnen und Verfolgen programmatischen Zugriff auf Daten, die durch gefährliche Berechtigungen Android-Aktivitäten und -Dienste

• [C-0-14] Rollen MUSS nur Anwendungen mit Funktionen zugewiesen werden, die die Rollenanforderungen erfüllen.

• [C-0-15] DÜRFEN keine Rollen definieren, die Duplikate oder Obermengen sind. von der Plattform definierten Rollen.

Wenn Geräte android.software.managed_users melden, geschieht Folgendes:

• [C-1-1] DÜRFEN die folgenden Berechtigungen NICHT automatisch vom Administrator: <ph type="x-smartling-placeholder">
  </ph>
  • Standort (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION) verwenden.
  • Kamera (KAMERA)
  • Mikrofon (RECORD_AUDIO)
  • Körpersensor (BODY_SENSORS)
  • Körperliche Aktivität (ACTIVITY_RECOGNITION)

Wenn Geräteimplementierung den Nutzern die Möglichkeit bietet zu entscheiden, welche Apps über andere Apps mit einer Aktivität, die die ACTION_MANAGE_OVERLAY_PERMISSION Absicht haben sie:

• [C-2-1] MÜSSEN sicherstellen, dass alle Aktivitäten mit Intent-Filtern für die ACTION_MANAGE_OVERLAY_PERMISSION Intent haben denselben UI-Bildschirm, unabhängig von der initiierenden App Informationen, die es bietet.

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

• [C-3-1] Bei der Einrichtung des vollständig verwalteten Geräts MUSS ein Haftungsausschluss angezeigt werden. (Einrichtung des Geräteeigentümers) mit der Angabe, dass der IT-Administrator Folgendes tun kann: Gestatten Sie Apps, die Einstellungen auf dem Telefon zu steuern, einschließlich Mikrofon, Kamera und Standort mit Optionen zum Fortsetzen der Einrichtung oder Beenden der Einrichtung, ES SEI DENN Der Administrator hat die Kontrolle über die Berechtigungen auf dem Gerät deaktiviert.

Wenn bei Geräteimplementierungen alle Pakete vorinstalliert werden, die eine der Rollen System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence oder System Visual Intelligence enthalten, gilt Folgendes:

• [C-4-1] MÜSSEN alle Anforderungen erfüllen, die für Geräteimplementierungen in Abschnitte „9.8.6 Daten auf Betriebssystemebene und Umgebungsdaten und 9.8.15 Sandboxed API-Implementierungen“.

Wenn Geräteimplementierungen eine Standard-App zur Unterstützung der VoiceInteractionService:

• [C-5-1] DARF ACCESS_FINE_LOCATION NICHT als Standardeinstellung zugewiesen werden .

9.2. UID und Prozessisolierung

Geräteimplementierungen:

• [C-0-1] MUSS die Android-App unterstützen. Sandbox-Modell, bei dem jede Anwendung als eindeutige Unixstyle-UID ausgeführt wird und in einem separaten Prozess.
• [C-0-2] MUSS die Ausführung mehrerer Anwendungen unterstützen als dieselbe Linux-Nutzer-ID, vorausgesetzt, die Anwendungen sind ordnungsgemäß signiert. und konstruiert sein, wie in den Referenz zu Sicherheit und Berechtigungen

9.3 Dateisystemberechtigungen

Geräteimplementierungen:

• [C-0-1] MUSS den Android-Dateizugriff unterstützen wie in den Referenz zu Sicherheit und Berechtigungen

9.4 Alternative Ausführungsumgebungen

Geräteimplementierungen MÜSSEN Konsistenz der Android-Sicherheits- und Berechtigungsmodells spezifiziert, auch wenn sie Laufzeitumgebungen enthält, die Anwendungen, die andere Software oder Technologien als Dalvik Executable nutzen Formatieren Sie oder nativen Code. Mit anderen Worten:

• [C-0-1] Alternative Laufzeiten MÜSSEN selbst Android-Apps sein, und sich an das standardmäßige Android-Sicherheitsmodell halten, das an anderer Stelle beschrieben wird. in Abschnitt 9.

• [C-0-2] Alternative Laufzeiten DÜRFEN KEIN Zugriff auf Ressourcen erhalten. durch Berechtigungen geschützt, die nicht in der AndroidManifest.xml der Laufzeit angefordert werden Datei über den <uses-permission> Mechanismus zur Verfügung.

• [C-0-3] Alternative Laufzeiten DÜRFEN NICHT zulassen, dass Anwendungen die Verwendung von Funktionen, die durch Android-Berechtigungen geschützt sind, die auf System-Apps beschränkt sind.

• [C-0-4] Alternative Laufzeiten MÜSSEN dem Android-Sandbox-Modell entsprechen. und installierte Anwendungen, die eine alternative Laufzeit verwenden, DÜRFEN NICHT die Wiederverwendung der Sandbox einer anderen auf dem Gerät installierten App, außer durch die Android-Standardmechanismen für gemeinsame Nutzer-ID und Signaturzertifikat.

• [C-0-5] Alternative Laufzeiten DÜRFEN NICHT mit dem Makro gestartet, gewährt oder gewährt werden Zugriff auf die Sandboxes für andere Android-Apps.

• [C-0-6] Alternative Laufzeiten DÜRFEN NICHT mit einem Dienst gestartet, gewährt oder gewährt werden anderen Anwendungen alle Berechtigungen des Superuser (Root) oder jeder anderen User-ID.

• [C-0-7] Wenn die .apk-Dateien alternativer Laufzeiten im Systembild von Geräteimplementierungen angezeigt wird, MUSS dieses mit einem eindeutigen Schlüssel signiert werden. über den Schlüssel, mit dem andere auf dem Gerät enthaltene Anwendungen signiert wurden Implementierungen.

• [C-0-8] Bei der Installation von Anwendungen MÜSSEN alternative Laufzeiten Nutzereinwilligung für die von der App verwendeten Android-Berechtigungen

• [C-0-9] Wenn eine App eine Geräteressource für die die eine entsprechende Android-Berechtigung (z. B. Kamera, GPS) gibt, MÜSSEN Nutzer in der alternativen Laufzeit darüber informiert werden, dass die Anwendung auf diese Ressource zugreifen können.

• [C-0-10] Wenn die Laufzeitumgebung die Anwendung nicht aufzeichnet Funktionen auf diese Weise nutzen, MÜSSEN in der Laufzeitumgebung alle Berechtigungen von der Laufzeit selbst gehalten werden, wenn eine Anwendung installiert wird, die diese Laufzeit verwendet.

• Alternative Laufzeiten SOLLTEN Apps über PackageManager in folgendem Ordner installieren: separate Android-Sandboxes (Linux-Nutzer-IDs usw.).

• Alternative Laufzeiten KÖNNEN eine einzige Android-Sandbox bereitstellen, die von allen gemeinsam genutzt wird Anwendungen, die die alternative Laufzeit verwenden.

9.5 Unterstützung mehrerer Nutzer

Android unterstützt mehrere Nutzer und bietet Unterstützung für die vollständige Nutzerisolation und das Klonen von Nutzerprofilen mit teilweise Isolation(d.h. ein einzelnes zusätzliches Nutzerprofil des Typs android.os.usertype.profile.CLONE.

• Geräteimplementierungen KÖNNEN MÖGLICHERWEISE jedoch NICHT für mehrere Nutzer aktivieren, wenn Wechselmedien für primären externen Speicher.

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

• [C-1-2] MÜSSEN für jeden Nutzer ein Sicherheitsupdate entspricht dem Sicherheitsmodell der Android-Plattform, wie in den Referenzdokument zu Sicherheit und Berechtigungen in den APIs.
• [C-1-3] MUSS über einen separaten und isolierten gemeinsamen Anwendungsspeicher verfügen (/sdcard) für jede Nutzerinstanz.
• [C-1-4] MÜSSEN sicherstellen, dass Anwendungen, die einem kann ein Nutzer die Dateien, die einem anderen Nutzer gehören, weder auflisten noch lesen oder bearbeiten. auch wenn die Daten beider Nutzer auf demselben Volume oder Dateisystem gespeichert sind.
• [C-1-5] MÜSSEN den Inhalt der SD-Karte verschlüsseln, wenn die Funktion für mehrere Nutzer aktiviert ist. Verwendung eines Schlüssels, der nur auf nicht entfernbaren Medien gespeichert ist, auf die nur das System zugreifen kann, wenn Bei Geräteimplementierungen werden Wechseldatenträger für die APIs für externe Speicher verwendet. Da die Medien dann von einem Host-PC unlesbar werden, sind Geräteimplementierungen muss auf MTP oder ein ähnliches System umgestellt werden, um Host-PCs auf die Daten des aktuellen Nutzers.

Wenn Geräteimplementierungen eine Unterstützung für mehrere Nutzer umfassen, gilt Folgendes: alle Nutzer mit Ausnahme von Nutzern, die speziell zum Ausführen von zwei Instanzen erstellt wurden der gleichen App:

• [C-2-1] MUSS über einen separaten und isolierten gemeinsamen Anwendungsspeicher verfügen. (auch „/sdcard“) für jede Nutzerinstanz.
• [C-2-2] MÜSSEN sicherstellen, dass Anwendungen, die sich im Besitz von Der Name eines bestimmten Nutzers kann die Dateien, deren Eigentümer sie sind, nicht auflisten, lesen oder bearbeiten. auch wenn die Daten beider Nutzer auf demselben oder das Dateisystem.

Bei Geräteimplementierungen KANN ein einzelnes zusätzliches Nutzerprofil des Typs erstellt werden. android.os.usertype.profile.CLONE für den primären Nutzer (und nur für den Hauptnutzer), um zwei Instanzen derselben App auszuführen. Diese Dual-Instanzen teilen sich teilweise isolierten Speicher und werden dem Endnutzer gleichzeitig im Launcher und in derselben Ansicht angezeigt. So könnte z. B. die Installation von zwei separaten Instanzen einer einzelnen App auf einem Dual-SIM-Gerät

Wenn bei Geräteimplementierungen das oben beschriebene zusätzliche Nutzerprofil erstellt wird, dann:

• [C-3-1] MUSS nur Zugriff auf Speicher oder Daten gewähren, die entweder bereits für das übergeordnete Nutzerprofil zugänglich sind oder dem für ein zusätzliches Nutzerprofil.
• [C-3-2] DÜRFEN NICHT als Arbeitsprofil verwendet werden.
• [C-3-3] MUSS private App-Datenverzeichnisse vom übergeordneten Element getrennt haben Nutzerkonto.
• [C-3-4] DÜRFEN NICHT zulassen, dass das zusätzliche Nutzerprofil erstellt wird, falls wenn ein Geräteinhaber bereitgestellt wurde (siehe Abschnitt 3.9.1) oder einen Geräteinhaber zulassen, bereitgestellt werden, ohne vorher das zusätzliche Nutzerprofil zu entfernen.

Wenn bei Geräteimplementierungen das oben beschriebene zusätzliche Nutzerprofil erstellt wird, dann:

• [C-4-1] MÜSSEN die unten stehenden Intents, die aus den zusätzlichen Profil, das von den Anwendungen des Hauptnutzers auf dem Gerät verarbeitet wird:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] MÜSSEN alle Nutzerbeschränkungen für Geräterichtlinien übernehmen und ausgewählt restrictions(list below), der kein Nutzer ist, wurde auf den Hauptnutzer des Geräts angewendet diesem zusätzlichen Nutzerprofil hinzugefügt.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] DARF nur das Schreiben von Kontakten aus diesem zusätzlichen Profil über folgende Intents erstellen:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] DÜRFEN KEINE Kontaktsynchronisierungen für Anwendungen ausführen in dieses zusätzliche Nutzerprofils.

• [C-4-5] MUSS nur Anwendungen im zusätzlichen Profil zulassen, die eine Launcher-Aktivität, um auf Kontakte zuzugreifen, die bereits übergeordnetes Nutzerprofil.

9.6 Warnung bei Premium-SMS

Android bietet Support für die Warnung von Nutzern vor ausgehenden Premium-SMS. Premium-SMS Nachrichten sind SMS, die an einen bei einem Mobilfunkanbieter registrierten Dienst gesendet werden, der möglicherweise Kosten anfallen.

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

• [C-1-1] MÜSSEN Nutzer warnen, bevor sie eine SMS an Nummern senden werden durch reguläre Ausdrücke identifiziert, die in /data/misc/sms/codes.xml definiert sind auf dem Gerät. Das vorgelagerte Open-Source-Projekt von Android bietet eine Implementierung, die diese Anforderung erfüllt.

9.7 Sicherheitsfunktionen

Geräteimplementierungen MÜSSEN die Einhaltung der Sicherheitsfunktionen in den Kernel und Plattform wie unten beschrieben.

Die Android-Sandbox enthält Funktionen, die das sicherheitsverbesserte Linux verwenden. MAC-System (obligatorisch Access Control, SELinux), Seccomp-Sandboxing und andere Sicherheitsfunktionen im Linux-Kernel verwenden. Geräteimplementierungen:

• [C-0-1] MÜSSEN die Kompatibilität mit vorhandenen Anwendungen aufrechterhalten, auch wenn SELinux oder andere Sicherheitsfunktionen sind unterhalb der Framework.
• [C-0-2] DÜRFEN KEINE sichtbare Benutzeroberfläche haben, wenn ein Verstoß erkannt und von der Sicherheitsfunktion blockiert. die unter dem Android-Framework implementiert wurden, aber eine sichtbare Benutzeroberfläche haben KÖNNEN Ein Sicherheitsverstoß, der nicht mehr blockiert ist und zu einem erfolgreichen Exploit führt,
• [C-0-3] DÜRFEN SELinux oder andere Sicherheitsfunktionen NICHT implementieren unter dem Android-Framework, das für den Nutzer oder App-Entwickler konfiguriert werden kann.
• [C-0-4] DARF KEINE Anwendung zulassen, die sich auf eine andere Anwendung auswirken kann über eine API (z. B. Device Administration API) zum Konfigurieren einer Richtlinie die die Kompatibilität beeinträchtigen.
• [C-0-5] MÜSSEN das Medien-Framework in mehrere Prozesse aufteilen, kann der Zugriff für jeden Prozess enger eingegrenzt werden, beschrieben auf der Website des Android Open Source Project.
• [C-0-6] MÜSSEN einen Sandbox-Mechanismus für die Kernel-Anwendung implementieren. Diese Funktion ermöglicht das Filtern von Systemaufrufen mithilfe einer konfigurierbaren Richtlinie aus Multithread-Programme. Das vorgelagerte Open-Source-Projekt von Android erfüllt diese durch Aktivieren von seccomp-BPF mit Threadgroup Synchronisierung (TSYNC) wie beschrieben im Abschnitt "Kernel Configuration" (Kernel-Konfiguration) von source.android.com angegeben.

Kernelintegrität und Selbstschutzfunktionen sind ein integraler Bestandteil von Android Sicherheit. Geräteimplementierungen:

• [C-0-7] MÜSSEN Mechanismen zum Schutz vor Überlauf des Kernel-Stack-Zwischenspeichers implementieren. Beispiele für solche Mechanismen sind CC_STACKPROTECTOR_REGULAR und CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] MÜSSEN strenge Kernel-Speicherschutzmaßnahmen implementieren, wenn ausführbare Dateien der Code schreibgeschützt ist, schreibgeschützte Daten nicht ausführbar und nicht beschreibbar sind und Beschreibbare Daten sind nicht ausführbar (z.B. CONFIG_DEBUG_RODATA oder CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] MÜSSEN statische und dynamische Objektgröße implementieren begrenzt die Prüfung von Kopien zwischen Nutzerbereich und Kernelbereich (z.B. CONFIG_HARDENED_USERCOPY) auf Geräten, die ursprünglich mit API-Level versendet wurden 28 oder höher.
• [C-0-10] DARF KEINEN User-Space-Speicher beim Ausführen von im Kernelmodus (z.B. Hardware-PXN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) auf Geräten der ursprünglich mit API-Level 28 oder höher versendet wurde.
• [C-0-11] DÜRFEN KEINEN User-Space-Speicher im außerhalb der normalen Usercopy Access APIs (z.B. Hardware-PAN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden.
• [C-0-12] MÜSSEN die Isolierung der Kernel-Seitentabelle implementieren, wenn die Hardware auf allen Geräten, die ursprünglich mit API-Level ausgeliefert wurden, anfällig für CVE-2017-5754 28 oder höher (z.B. CONFIG_PAGE_TABLE_ISOLATION oder CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] MÜSSEN die Zweigvorhersage-Härtung implementieren, wenn die Hardware auf allen Geräten, die ursprünglich mit API-Level ausgeliefert wurden, anfällig für CVE-2017-5715 28 oder höher (z.B. CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, Kernel-Daten zu behalten der nur während der Initialisierung geschrieben wird und nach der Initialisierung (z.B. __ro_after_init).

• [C-SR-2] wird dringend empfohlen, das Layout des Kernel-Codes zufällig zu wählen und und um Anzeigen zu vermeiden, die die Randomisierung beeinträchtigen würden. (z.B. CONFIG_RANDOMIZE_BASE mit Bootloader-Entropie über die /chosen/kaslr-seed Device Tree node oder EFI_RNG_PROTOCOL).

• [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, Kontrollflussintegrität (Control Flow Integrity, CFI) zu aktivieren in den Kernel, um zusätzlichen Schutz vor Angriffen durch Code-Wiederverwendung zu bieten (z.B. CONFIG_CFI_CLANG und CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] WIRD UNBEDINGT EMPFOHLEN, die Kontrollflussintegrität (Control-Flow Integrity, CFI) nicht zu deaktivieren, Shadow Call Stack (SCS) oder Integer Overflow Sanitization (IntSan) aktiviert Komponenten, für die es aktiviert ist.

• [C-SR-5] wird dringend empfohlen, CFI, SCS und IntSan für alle zusätzliche sicherheitsrelevante Userspace-Komponenten, wie unter CFI und IntSan:

• [C-SR-6] WIRD UNBEDINGT EMPFOHLEN, die Stack-Initialisierung im Kernel zu aktivieren um die Verwendung nicht initialisierter lokaler Variablen (CONFIG_INIT_STACK_ALL oder CONFIG_INIT_STACK_ALL_ZERO). Außerdem sollten Geräteimplementierungen NICHT davon ausgehen, dass der vom Compiler verwendete Wert die Locals initialisieren.

• [C-SR-7] WIRD UNBEDINGT EMPFOHLEN, die Heap-Initialisierung im Kernel zu aktivieren um zu verhindern, dass nicht initialisierte Heap-Zuweisungen verwendet werden (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) und DARF NICHT davon ausgehen, dass der von um diese Zuweisungen zu initialisieren.

Wenn Geräteimplementierungen einen Linux-Kernel verwenden, der SELinux:

• [C-1-1] MÜSSEN SELinux implementieren.
• [C-1-2] MÜSSEN SELinux in den globalen Erzwingungsmodus setzen.
• [C-1-3] MÜSSEN alle Domains im Erzwingungsmodus konfigurieren. Kein mäßiger Modus Domains sind zulässig, einschließlich geräte- oder anbieterspezifischer Domains.
• [C-1-4] DÜRFEN die vorhandenen "Neverallow"-Regeln NICHT ändern, weglassen oder ersetzen. im Ordner „system/sepolicy“, der im vorgelagerten Open-Source-System von Android bereitgestellt wird Projekt (AOSP) und die Richtlinie MÜSSEN mit allen "Niezulassen"-Regeln kompiliert werden, sowohl für AOSP SELinux-Domains als auch geräte-/anbieterspezifische Domains.
• [C-1-5] MÜSSEN Drittanbieter-Apps für API-Level 28 oder höher ausführen in anwendungsspezifischen SELinux-Sandboxes mit jeweils App-spezifischen SELinux-Einschränkungen privaten Datenverzeichnis der Anwendung.
• SOLLTEN die standardmäßige SELinux-Richtlinie beibehalten, die in system/sepolicy bereitgestellt wird. des vorgelagerten Open-Source-Projekts von Android und fügen diesem für ihre eigene gerätespezifische Konfiguration.

Wenn Geräteimplementierungen einen anderen Kernel als Linux oder Linux ohne SELinux verwenden, Sie:

• [C-2-1] MUSS ein obligatorisches Zugriffssteuerungssystem verwenden, das wie SELinux.

Wenn Geräteimplementierungen E/A-Geräte verwenden, die DMA unterstützen, gilt Folgendes:

• [C-SR-9] Es wird dringend empfohlen, jedes E/A-Gerät, das DMA nutzen kann, zu isolieren, mit einem IOMMU (z. B. ARM SMMU)

Android bietet mehrere, gestaffelte Sicherheitsebenen, die für das Gerät entscheidend sind Sicherheit. Darüber hinaus konzentriert sich Android darauf, die wichtigsten Klassen häufiger Fehler zu reduzieren. die zu schlechter Qualität und Sicherheit beitragen.

Um Speicherfehler zu reduzieren, sollten bei den Geräteimplementierungen folgende Schritte ausgeführt werden:

• [C-SR-10] WIRD UNBEDINGT EMPFOHLEN, mit einem Arbeitsspeicherfehler im Userspace zu testen Erkennungstools wie MTE für ARMv9-Geräte, HWASan für ARMv8+-Geräte oder ASan für andere Gerätetypen.
• [C-SR-11] WIRD UNBEDINGT EMPFOHLEN, mit einem Kernel-Speicherfehler zu testen Erkennungstools wie KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS für ARMv9-Geräte, CONFIG_KASAN_SW_TAGS für ARMv8-Geräte oder CONFIG_KASAN_GENERIC für andere Gerätetypen.
• [C-SR-12] wird dringend empfohlen, Tools zur Speicherfehlererkennung in wie MTE, GWP-ASan und KFENCE.

Wenn Geräteimplementierungen einen TrustZone-basierten Arm-TEE verwenden, geschieht Folgendes:

• [C-SR-13] wird dringend empfohlen, ein Standardprotokoll für den Speicher zu verwenden zwischen Android und dem TEE wie dem Arm Firmware Framework für Armv8-A (FF-A).
• [C-SR-14] Es wird dringend empfohlen, nur vertrauenswürdige Anwendungen auf Arbeitsspeicher zugreifen, der explizit über Protokoll. Wenn das Gerät die Ausnahmestufe Arm S-EL2 unterstützt, vom Secure Partition Manager erzwungen werden. Andernfalls sollte diese TEE OS durchgesetzt wird.

Eine Speichersicherheitstechnologie ist eine Technologie, die mindestens die folgenden mit einer hohen Wahrscheinlichkeit (> 90%) in Anwendungen, die die android:memtagMode Manifest-Option:

• Heap-Pufferüberlauf
• Nach Ablauf der kostenlosen Testversion verwenden
• Double Free
• Wild Free (ohne Nicht-Malloc-Pointer)

Geräteimplementierungen:

• [C-SR-15] Wir empfehlen dringend, Folgendes festzulegen: ro.arm64.memtag.bootctl_supported

Wenn in Geräteimplementierungen die Systemeigenschaft festgelegt wird ro.arm64.memtag.bootctl_supported auf "true" setzen, gilt Folgendes:

• [C-3-1] MÜSSEN zulassen, dass die Systemeigenschaft arm64.memtag.bootctl eine Durch Kommas getrennte Liste der folgenden Werte mit dem gewünschten Effekt beim nächsten Neustart angewendet:

  • memtag: Eine der oben definierten Speichersicherheitstechnologien ist aktiviert.
  • memtag-once: Eine der oben beschriebenen Speichersicherheitstechnologien ist vorübergehend aktiviert und wird ab dem nächsten neu starten
  • memtag-off: Eine der oben definierten Speichersicherheitstechnologien ist deaktiviert.

• [C-3-2] MÜSSEN dem Shell-Nutzer erlauben, arm64.memtag.bootctl festzulegen.

• [C-3-3] MÜSSEN jedem Prozess erlauben, arm64.memtag.bootctl zu lesen.

• [C-3-4] MUSS arm64.memtag.bootctl auf den aktuell angeforderten Status setzen beim Starten MUSS auch die Eigenschaft aktualisiert werden, wenn die den Status ändern, ohne die Systemeigenschaft zu ändern.

• [C-SR-16] EMPFOHLEN, eine Entwicklereinstellung anzuzeigen, und das Gerät wird neu gestartet. Mit einem kompatiblen Bootloader Das Android Open Source-Projekt erfüllt die oben genannten Anforderungen durch die MTE-Bootloader-Protokoll.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

9.8 Datenschutz

9.8.1 Nutzungsverlauf

Android speichert den Verlauf der Nutzerauswahl und verwaltet diesen Verlauf, UsageStatsManager

Geräteimplementierungen:

• [C-0-1] MÜSSEN eine angemessene Aufbewahrungsdauer für einen solchen Nutzerverlauf beibehalten.
• [C-SR-1] wird dringend empfohlen, die 14-tägige Aufbewahrungsdauer wird standardmäßig in der AOSP-Implementierung konfiguriert.

Android speichert die Systemereignisse mithilfe der StatsLog identifiziert und verwaltet diesen Verlauf über StatsManager und die IncidentManager-System-API.

Geräteimplementierungen:

• [C-0-2] DARF nur die mit DEST_AUTOMATIC gekennzeichneten Felder enthalten. Vorfallbericht, der von der System-API-Klasse IncidentManager erstellt wurde.
• [C-0-3] DÜRFEN die Systemereignis-IDs nicht verwenden, um andere Ereignisse zu protokollieren. als in den StatsLog beschrieben. SDK-Dokumente. Wenn zusätzliche Systemereignisse protokolliert werden, KANN ein im Bereich zwischen 100.000 und 200.000.

9.8.2 Aufnahme läuft

Geräteimplementierungen:

• [C-0-1] DÜRFEN KEINE Softwarekomponenten vorab geladen oder verteilt werden, die private Informationen des Nutzers zu senden (z.B. Tastenanschläge, auf der Bildschirm, Fehlerbericht) vom Gerät ohne Zustimmung des Nutzers dauerhafte Benachrichtigungen.

• [C-0-2] MÜSSEN eine Nutzerwarnung anzeigen und die ausdrückliche Nutzereinwilligung einholen. dass alle vertraulichen Informationen, die auf dem Bildschirm des Nutzers angezeigt werden, wird jedes Mal erfasst, wenn eine Sitzung wird der Bildschirm über die MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay(), oder proprietäre APIs.

• [C-0-3] Sie MUSS während der Bildschirmübertragung eine fortlaufende Benachrichtigung an den Nutzer erhalten. oder die Bildschirmaufzeichnung aktiviert ist. AOSP erfüllt diese Anforderung, indem Benachrichtigungssymbol für laufende Benachrichtigungen.

• [C-SR-1] Es wird dringend empfohlen, eine Nutzerwarnung anzuzeigen, dieselbe Nachricht wie in AOSP implementiert, kann jedoch geändert werden, solange der In einer Nachricht wird der Nutzer klar darauf hingewiesen, dass vertrauliche Informationen Bildschirm aufgenommen wird.

• [C-0-4] Nutzer DÜRFEN NICHT die Möglichkeit bieten, zukünftige Aufforderungen für Der Nutzer willigt in die Bildschirmaufnahme ein, es sei denn, die Sitzung wird durch einen System-App, die der Nutzer erlaubt hat, associate() mit dem android.app.role.COMPANION_DEVICE_APP_STREAMING oder die android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING Geräteprofil.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräteimplementierungen Funktionen im System umfassen, die entweder erfasst den auf dem Bildschirm angezeigten Inhalt und/oder den Audiostream die auf einem anderen Gerät als über die System-API ContentCaptureService wiedergegeben werden oder gemäß der Beschreibung Abschnitt 9.8.6 Daten auf Betriebssystemebene und Umgebungsdaten, müssen sie:

• [C-1-1] Der Nutzer MUSS eine dauerhafte Benachrichtigung erhalten, aktiviert ist und aktiv erfasst/aufzeichnet.

Wenn Geräteimplementierungen eine sofort aktivierte Komponente enthalten, das Aufzeichnen von Umgebungsgeräuschen und/oder Audiomaterial, das auf dem Gerät wiedergegeben wird um nützliche Informationen über den Kontext der Nutzenden abzuleiten, sind sie:

• [C-2-1] DÜRFEN NICHT im dauerhaften Speicher auf dem Gerät abgelegt oder vom das aufgezeichnete Rohaudio oder ein beliebiges Format, das wieder konvertiert werden kann, Originalaudio oder -faksimiles, außer mit ausdrücklicher Zustimmung des Nutzers

Eine „Mikrofonanzeige“ bezieht sich auf eine Ansicht auf dem Bildschirm, die ständig sichtbar ist. für den Nutzer sichtbar und darf nicht verdeckt sein. Nutzer erkennen, dass sich ein Mikrofon befindet. Verwendung(über eindeutigen Text, Farbe, Symbol oder eine Kombination aus eindeutig).

Eine Kameraanzeige bezieht sich auf eine Ansicht auf dem Bildschirm, die für die Nutzer für den Nutzer sichtbar und nicht verdeckt sein, da Nutzer diese als in Verwendung befindliche Kamera verstehen. (durch individuelle Texte, Farben, Symbole oder eine Kombination aus mehreren Elementen).

Nach der ersten Sekunde kann sich eine Anzeige visuell verändern, z. B. kleiner werden und nicht wie ursprünglich präsentiert und verstanden wird.

Die Mikrofonanzeige kann mit der Kamera verbunden sein, die aktiv angezeigt wird. vorausgesetzt, dass Text, Symbole oder Farben die Nutzenden Die Mikrofonnutzung hat begonnen.

Die Kameraanzeige kann mit einem aktiv angezeigten Mikrofon zusammengeführt sein angezeigt, vorausgesetzt, dass Text, Symbole oder Farben die Nutzenden darauf hinweisen, Kameranutzung begonnen hat.

Wenn in Geräteimplementierungen android.hardware.microphone deklariert wird, gilt Folgendes:

• [C-SR-1] Es wird dringend empfohlen, die Mikrofonanzeige einzublenden, wenn eine App auf Audiodaten vom Mikrofon zu. Dies funktioniert jedoch nicht, wenn das Mikrofon eingeschaltet ist. Zugriff nur von HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den im Abschnitt genannten Rollen 9.1 Berechtigungen mit CDD-Kennung [C-3-X]. .
• [C-SR-2] wird dringend empfohlen, die Liste der letzten und aktiven Apps, die das Mikrofon wie von PermissionManager.getIndicatorAppOpUsageData(), zusammen mit allen Quellenangaben Nachrichten, die mit ihnen verknüpft sind.
• [C-SR-3] Es wird dringend empfohlen, die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen

Wenn in Geräteimplementierungen android.hardware.camera.any deklariert wird, gilt Folgendes:

• [C-SR-4] Wir empfehlen dringend, die Kameraanzeige einzublenden, wenn eine App Auf Live-Kameradaten zugreifen, aber nicht, wenn nur auf die Kamera zugegriffen wird durch Apps, die die in Paragraf 9.1 „Berechtigungen“ für CDD genannten Rollen haben Kennung [C-3-X].
• [C-SR-5] Wir empfehlen dringend, kürzlich geöffnete und aktive Apps mit Kamera wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, sowie mit allen damit verbundenen Quellenangaben.
• [C-SR-6] WIRD UNBEDINGT EMPFOHLEN, die Kameraanzeige für das System nicht zu verbergen Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen

9.8.3 Konnektivität

Wenn Geräte einen USB-Port mit Unterstützung für den USB-Peripheriemodus haben, Sie:

• [C-1-1] MÜSSEN eine Benutzeroberfläche einblenden, in der der Nutzer um seine Zustimmung gebeten wird, bevor So kann über den USB-Anschluss auf den Inhalt des freigegebenen Speichers zugegriffen werden.

9.8.4 Netzwerkverkehr

Geräteimplementierungen:

• [C-0-1] MÜSSEN dieselben Root-Zertifikate für das vertrauenswürdige System CA-Speicher (Certificate Authority, CA) wie bereitgestellt im vorgelagerten Android Open Source-Projekt.
• [C-0-2] MÜSSEN mit einem leeren Root-CA-Nutzerspeicher ausgeliefert werden.
• [C-0-3] MÜSSEN dem Nutzer eine Warnung über den Netzwerkverkehr anzeigen. überwacht werden, wenn eine Nutzer-Stammzertifizierungsstelle hinzugefügt wird.

Wenn Gerätetraffic über ein VPN weitergeleitet wird, gilt für Geräteimplementierungen Folgendes:

• [C-1-1] Dem Nutzer MUSS eine Warnung mit folgenden Informationen angezeigt werden: <ph type="x-smartling-placeholder">
  </ph>
  • Dieser Netzwerkverkehr wird möglicherweise überwacht.
  • Dieser Netzwerktraffic wird über das jeweilige VPN geleitet App, die das VPN bereitstellt.

Wenn Geräteimplementierungen einen Mechanismus haben, der standardmäßig aktiviert ist, leitet den Netzwerktraffic über einen Proxyserver oder VPN-Gateway (z. B. Vorabladen eines VPN-Dienstes mit gewährtem android.permission.CONTROL_VPN), haben sie folgende Möglichkeiten:

• [C-2-1] MÜSSEN Sie die Zustimmung des Nutzers einholen, bevor Sie diesen Mechanismus aktivieren. es sei denn, das VPN wird vom Device Policy Controller über die DevicePolicyManager.setAlwaysOnVpnPackage(), In diesem Fall muss der Nutzer keine gesonderte Einwilligung geben, MÜSSEN nur benachrichtigt werden.

Wenn in der Geräteimplementierung eine Funktion zur Aktivierung der Funktion „durchgehend aktives VPN“ Funktion einer Drittanbieter-VPN-App:

• [C-3-1] MÜSSEN diese Funktion für Apps deaktivieren, die keine durchgehend aktives VPN in der Datei AndroidManifest.xml über die Einstellung SERVICE_META_DATA_SUPPORTS_ALWAYS_ON zu false.

9.8.5 Geräte-IDs

Geräteimplementierungen:

• [C-0-1] MÜSSEN den Zugriff auf die Geräte-Seriennummer verhindern und zutreffend, IMEI/MEID, SIM-Seriennummer und International Mobile Subscriber Identity (IMSI) einer Anwendung, es sei denn, sie erfüllt eine der folgenden Bedingungen Anforderungen: <ph type="x-smartling-placeholder">
  </ph>
  • ist eine signierte Mobilfunkanbieter-App, die von Geräteherstellern verifiziert wird.
  • hat die Berechtigung READ_PRIVILEGED_PHONE_STATE erhalten.
  • verfügt über Mobilfunkanbieterberechtigungen, die in den UICC-Mobilfunkanbieterberechtigungen definiert sind.
  • ein Geräte- oder Profilinhaber ist, dem die Berechtigung Berechtigung „READ_PHONE_STATE“.
  • (nur für SIM-Seriennummer/ICCID) gemäß den lokalen Vorschriften dass die App Änderungen an der Identität des Abonnenten erkennt.

9.8.6. Daten auf Betriebssystemebene und Umgebungsdaten

Android unterstützt über die System-APIs einen Mechanismus, Implementierungen zur Erfassung der folgenden sensiblen Daten:

• Auf dem Bildschirm gerenderte Texte und Grafiken, einschließlich, aber nicht beschränkt auf Benachrichtigungen und Vorbereitungsdaten über AssistStructure der API erstellen.
• Mediendaten wie Audio oder Video, die vom Gerät aufgenommen oder abgespielt wurden.

• Eingabeereignisse (z. B. Taste, Maus, Touch-Geste, Sprache, Video und Bedienungshilfen)

• Alle Bildschirm- oder sonstigen Daten, die über AugmentedAutofillService an den System.

• Jeder Bildschirm oder andere Daten, auf die über Content Capture APIs

• Alle Anwendungsdaten, die über die AppSearchManager API an das System übergeben werden und zugänglich über AppSearchGlobalManager.query.

• Text oder andere Daten, die über die TextClassifier API gesendet werden an den System TextClassifier, d.h. an den Systemdienst, die Bedeutung von Text und generiert basierend auf im Text.

• Von der AppSearch-Implementierung der Plattform indexierte Daten, einschließlich, aber nicht auf Text, Grafiken, Mediendaten oder ähnliche Daten beschränkt.

• Audiodaten, die bei der Verwendung von SpeechRecognizer#onDeviceSpeechRecognizer() durch die Spracherkennung Implementierung

• Im Hintergrund (fortlaufend) über AudioRecord abgerufene Audiodaten SoundTrigger oder anderen Audio-APIs und führt nicht zu einer für den Nutzer sichtbaren Anzeige

• Kameradaten, die im Hintergrund (fortlaufend) über CameraManager oder andere Kamera-APIs und führt nicht zu einer für den Nutzer sichtbaren Anzeige

Wenn Geräteimplementierungen eines der oben genannten Daten erheben, geschieht Folgendes:

• [C-1-1] MÜSSEN alle diese Daten verschlüsseln, wenn sie auf dem Gerät gespeichert werden. Dieses Verschlüsselung KANN mithilfe der dateibasierten Android-Verschlüsselung oder einer beliebigen der Chiffren, die unter API-Version 26 oder höher aufgeführt sind und im Cipher SDK beschrieben werden.
• [C-1-2] DÜRFEN KEINE Rohdaten oder verschlüsselten Daten mit Android-Sicherungsmethoden oder andere Back-ups nach oben zu stellen.
• [C-1-3] DÜRFEN alle derartigen Daten nur vom mit einem datenschutzfreundlichen Verfahren versehen, mit Ausnahme von mit ausdrücklicher Zustimmung des Nutzers, sobald die Daten freigegeben. Der datenschutzfreundliche Mechanismus sind definiert als solche, die nur Analyse in aggregierter Form ermöglichen und von protokollierten Ereignissen oder abgeleiteten Ergebnissen mit einzelnen Benutzern abzugleichen“, verhindern, dass nutzerspezifische Daten introspektiv sind (z.B. Implementierung durch Differential Privacy-Technologie wie RAPPOR verwenden.
• [C-1-4] DÜRFEN derartige Daten NICHT mit Benutzeridentitäten (wie als Account) auf dem Gerät, außer bei ausdrücklicher Zustimmung des Nutzers jedes Mal, wenn die Daten verknüpft sind.
• [C-1-5] Diese Daten dürfen NICHT an andere Betriebssystemkomponenten weitergegeben werden, Sie müssen die im aktuellen Abschnitt beschriebenen Anforderungen erfüllen. (9.8.6 Daten auf Betriebssystemebene und Umgebungsdaten), außer mit ausdrücklicher Zustimmung des Nutzers alle wenn es freigegeben wird. Es sei denn, diese Funktion ist erstellt als Android SDK API (AmbientContext, HotwordDetectionService).
• [C-1-6] MÜSSEN Nutzern die Möglichkeit bieten, solche Daten zu löschen, die Implementierung oder die proprietären Mittel erheben, Daten werden in beliebiger Form auf dem Gerät gespeichert. Wenn die Nutzer entscheidet sich, die Daten zu löschen, MÜSSEN alle gesammelten historischen Daten Daten.

• [C-1-7] MÜSSEN Nutzern die Möglichkeit bieten, die erhobenen Daten abzulehnen. über AppSearch oder proprietäre Mittel, um auf der Android-Plattform angezeigt zu werden (z. B. Launcher)

• [C-SR-1] Es wird dringend empfohlen, die Berechtigung INTERNET NICHT anzufordern.

• [C-SR-2] wird dringend empfohlen, nur über strukturierte APIs, die auf öffentlich verfügbaren Open-Source-Implementierungen basieren.

• [C-SR-4] EMPFOHLENE Implementierung mit der Android SDK API oder ein ähnliches OEM-eigenes Open-Source-Repository zu verwenden; und / oder in einem Implementierung in einer Sandbox (siehe Abschnitt 9.8.15 Sandboxed API-Implementierungen).

Wenn Geräteimplementierungen einen Dienst umfassen, der die System API implementiert ContentCaptureService, AppSearchManager.index oder ein proprietärer Dienst der die Daten wie oben beschrieben erfasst,

• [C-2-1] DÜRFEN Nutzern NICHT erlauben, die Dienste durch einen eine vom Nutzer installierbare App oder einen Dienst und MUSS nur die vorinstallierten Diensten installiert, um solche Daten zu erfassen.
• [C-2-2] DÜRFEN KEINE anderen Apps als die vorinstallierten Dienste zulassen um solche Daten zu erfassen.
• [C-2-3] MÜSSEN Nutzern angeboten werden, die Dienste deaktivieren können.

• [C-2-4] DARF NICHT auf die Nutzerangebote verzichten, um Android-Berechtigungen zu verwalten, die Sie sind Eigentum der Dienste und folgen den Android-Berechtigungen wie in Abschnitt 9.1 beschrieben. Berechtigung:

• [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, die Dienste von anderen zu trennen Systemkomponenten (z.B. Dienstbindung oder Freigabe von Prozess-IDs) mit Ausnahme von:

  • Telefonie, Kontakte, System-UI und Medien

9.8.7 Zugriff auf Zwischenablage

Geräteimplementierungen:

• [C-0-1] DARF KEINE gekürzten Daten aus der Zwischenablage zurückgeben, z.B. über das ClipboardManager API) verwenden, es sei denn, der Drittanbieter app ist der Standard-IME oder die App, auf die derzeit der Fokus liegt.

• [C-0-2] MÜSSEN die Daten in der Zwischenablage höchstens 60 Minuten nach dem letzten Löschen löschen in die Zwischenablage eingefügt oder aus der Zwischenablage gelesen werden.

9.8.8 Standort

Der Standort beinhaltet Informationen in der Android-Standortklasse( z. B. Latitude, Längengrad, Höhe) sowie Kennungen, die in Standort umgewandelt werden können. Die Position kann so genau wie DGPS (Differential Global Positioning System) oder ungefähre Standorte auf Länderebene (z. B. Ländercode-Standort - Kundencenter - Mobil). Ländercode).

Im Folgenden finden Sie eine Liste mit Standorttypen, die entweder direkt oder in den Standort des Nutzers umgewandelt werden kann. Dies ist keine umfassende aber als Beispiel dafür verwendet werden, indirekt aus Folgendem abgeleitet werden:

• GPS/GNSS/DGPS/PPP <ph type="x-smartling-placeholder">
  </ph>
  • Global Positioning Solution oder Global Navigation Satellite System oder Differential Global Positioning-Lösung
  • Dazu gehören auch GNSS-Rohmessungen und der GNSS-Status <ph type="x-smartling-placeholder">
    </ph>
    • Der genaue Standort kann aus den GNSS-Rohmessungen abgeleitet werden.
• Funktechnologien mit eindeutigen IDs wie: <ph type="x-smartling-placeholder">
  </ph>
  • WLAN-Zugangspunkte (MAC, BSSID, Name oder SSID)
  • Bluetooth/BLE (MAC, BSSID, Name oder SSID)
  • UWB (MAC, BSSID, Name oder SSID)
  • Mobilfunkmast-ID (3G, 4G, 5G... einschließlich aller zukünftigen Mobilfunkmodem) Technologien mit eindeutigen IDs)

Sehen Sie sich als Hauptreferenz die Android-APIs an, für die ACCESS_FINE_Location- oder ACCESS_COARSE_Location-Berechtigungen.

Geräteimplementierungen:

• [C-0-1] DÜRFEN NICHT die Einstellung für den Gerätestandort und WLAN/Bluetooth aktivieren/deaktivieren ohne ausdrückliche Nutzereinwilligung oder -initiierung.
• [C-0-2] MÜSSEN Nutzern die Möglichkeit bieten, auf standortbezogene Dienste zuzugreifen. Informationen wie letzte Standortanfragen, Berechtigungen auf App-Ebene und Nutzungsdaten WLAN-/Bluetooth-Suche zur Standortbestimmung.
• [C-0-3] MUSS sicherstellen, dass die Anwendung, die die Emergency Location Bypass API verwendet, [LocationRequest.setLocationSettingsignored()] ist ein vom Nutzer initiierter Notfall (z.B. 911 wählen oder SMS an 911 senden). Für die Automobilindustrie KANN ein Fahrzeug Notfallsitzung ohne aktive Nutzerinteraktion im Fall starten Ein Unfall/Unfall wurde erkannt (z.B. um die eCall-Anforderungen zu erfüllen).
• [C-0-4] MÜSSEN die Emergency Location Bypass APIs weiterhin in der Lage sein, die Standorteinstellungen des Geräts umgehen, ohne die Einstellungen zu ändern.
• [C-0-5] MÜSSEN eine Benachrichtigung planen, die den Nutzer erinnert, nachdem eine App in der Hintergrund über die Funktion Berechtigung [ACCESS_BACKGROUND_LOCATION].

9.8.9. Installierte Apps

Android-Apps, die auf API-Level 30 oder höher ausgerichtet sind, können keine Details zu anderen standardmäßig installierte Apps. Weitere Informationen finden Sie unter Paketsichtbarkeit in der Android-App SDK-Dokumentation).

Geräteimplementierungen:

• [C-0-1] DÜRFEN KEINE Details zu App-Targeting-API-Level 30 oder höher sehen zu anderen installierten Apps, es sei denn, die App kann bereits Details über die verwalteten APIs über die andere installierte App erfahren. Dazu gehören unter anderem nicht auf Details beschränkt, die von benutzerdefinierten APIs offengelegt werden, die vom Gerät hinzugefügt wurden Implementierer oder über das Dateisystem zugänglich sind.
• [C-0-2] DÜRFEN keiner App Lese- oder Schreibzugriff auf Dateien in anderen das dedizierte anwendungsspezifische Verzeichnis der App im externen Speicher. Es gelten nur die folgenden Ausnahmen: <ph type="x-smartling-placeholder">
  </ph>
  • Die Zertifizierungsstelle des externen Speicheranbieters (z. B. Apps wie DocumentsUI)
  • Downloadanbieter, der die „Downloads“ verwendet Provider-Befugnis für das Herunterladen von Dateien in den App-Speicher.
  • MTP-Apps (Platform Signed Media Transfer Protocol), die den die privilegierte Berechtigung ACCESS_MTP, um die Übertragung von Dateien an auf einem anderen Gerät.
  • Apps, die andere Apps installieren und die Berechtigung haben INSTALL_PAKETE kann nur auf „obb“ zugreifen Verzeichnisse für die Verwaltung von APK-Erweiterungsdateien.

9.8.10. Fehlerbericht zur Verbindung

Wenn in Geräteimplementierungen das Funktions-Flag android.hardware.telephony deklariert ist, Sie:

• [C-1-1] MÜSSEN die Erstellung von Verbindungsfehlerberichten über BUGREPORT_MODE_TELEPHONY mit BugreportManager.
• [C-1-2] MÜSSEN jedes Mal die Nutzereinwilligung einholen, wenn BUGREPORT_MODE_TELEPHONY die zur Berichterstellung verwendet wurden, und DÜRFEN den Nutzer NICHT zur Einwilligung in alle zukünftigen Anfragen von der Anwendung.
• [C-1-3] DÜRFEN den erstellten Bericht NICHT an die anfragende App zurückgeben, ohne ausdrückliche Einwilligung des Nutzers.
• [C-1-4] Mit BUGREPORT_MODE_TELEPHONY generierte Berichte MÜSSEN Folgendes enthalten: mindestens die folgenden Informationen: <ph type="x-smartling-placeholder">
  </ph>
  • TelephonyDebugService-Dump
  • TelephonyRegistry-Dump
  • WifiService-Dump
  • ConnectivityService-Dump
  • Dump der Instanz CarrierService des aufrufenden Pakets (falls gebunden)
  • Funkprotokollzwischenspeicher
  • SubscriptionManagerService-Dump
• [C-1-5] DÜRFEN Folgendes in den erstellten Berichten NICHT enthalten: <ph type="x-smartling-placeholder">
  </ph>
  • Alle Arten von Informationen, die nicht direkt mit der Konnektivität zusammenhängen Debugging.
  • Jegliche Art von vom Nutzer installierten Traffic-Logs oder detaillierten Profilen von Anwendungen nutzerinstallierter Anwendungen/Pakete (UIDs sind in Ordnung, Paketnamen sind nicht).
• KANN zusätzliche Informationen enthalten, die mit keinem Nutzer verknüpft sind. Identität. (z.B. Anbieterprotokolle).

Wenn Geräteimplementierungen zusätzliche Informationen (z.B. Anbieterprotokolle) in Fehlerberichte und diese Informationen verfügen über Datenschutz/Sicherheit/Akku/Speicher/Arbeitsspeicher. Auswirkungen:

• [C-SR-1] Wir empfehlen dringend, die Entwicklereinstellung standardmäßig auf deaktiviert. Die AOSP-Referenzimplementierung erfüllt diese Anforderungen durch Angabe des Enable verbose vendor logging Option in den Entwicklereinstellungen, um zusätzliche gerätespezifische Anbieterprotokolle hinzuzufügen in den Fehlerberichten aufgeführt.

9.8.11. Freigabe von Daten-Blobs

Android über BlobStoreManager Ermöglicht Apps, Daten-Blobs zum System beizutragen, damit diese für eine ausgewählte Person freigegeben werden können Apps zu finden.

Wenn Geräteimplementierungen freigegebene Daten-BLOBs unterstützen, wie in den SDK-Dokumentation Sie:

• [C-1-1] DÜRFEN KEINE Daten-Blobs von Apps über das hinaus (d.h. der Umfang des Standardzugriffs und der andere Zugriff Modi angegeben werden, die mit BlobStoreManager.session#allowPackageAccess() auf. BlobStoreManager.session#allowSameSignatureAccess() oder BlobStoreManager.session#allowPublicAccess() DÜRFEN NICHT geändert werden). Die AOSP-Referenzimplementierung erfüllt Anforderungen.
• [C-1-2] DÜRFEN die sicheren Hashes NICHT an andere Apps senden oder an andere Apps weitergeben. von Daten-Blobs, mit denen der Zugriff gesteuert wird.

9.8.12. Musikerkennung

Android unterstützt über den MusicRecognitionManager der System API einen Mechanismus zur Geräteimplementierungen für die Anforderung von Musikerkennung bei einer Audioaufnahme und die Musikerkennung an eine privilegierte App delegieren, MusicRecognitionService API

Wenn Geräteimplementierungen einen Dienst umfassen, der die System API implementiert MusicRecognitionManager oder andere proprietäre Dienste, die Audiodaten als wie oben beschrieben:

• [C-1-1] MÜSSEN erzwingen, dass der Aufrufer von MusicRecognitionManager das Objekt Berechtigung „MANAGE_MUSIC_RECOGNITION“
• [C-1-2] MÜSSEN erzwingen, dass eine einzelne vorinstallierte Musikerkennung -Anwendung implementiert MusicRecognitionService.
• [C-1-3] DÜRFEN Nutzern NICHT erlauben, den MusicRecognitionManagerService zu ersetzen oder MusicRecognitionService durch eine vom Nutzer installierbare Anwendung oder einen Dienst.
• [C-1-4] MÜSSEN sicherstellen, dass beim Zugriff von MusicRecognitionManagerService auf den und leitet sie an die Anwendung weiter, in der MusicRecognitionService hat, wird der Audiozugriff über Aufrufe von AppOpsManager.noteOp / startOp

Wenn Geräteimplementierungen von MusicRecognitionManagerService oder MusicRecognitionService speichert alle erfassten Audiodaten. Sie:

• [C-2-1] DÜRFEN KEINE Rohdaten oder Audio-Fingerabdrücke auf der Festplatte speichern, oder länger als 14 Tage im Arbeitsspeicher
• [C-2-2] DÜRFEN derartige Daten NICHT über den MusicRecognitionService hinaus weitergeben, mit Ausnahme von mit ausdrücklicher Zustimmung des Nutzers.

9.8.13. SensorPrivacyManager

Wenn Geräteimplementierungen dem Nutzer die Möglichkeit bieten, die Software auszuschalten Kamera- und/oder Mikrofoneingabe für die Geräteimplementierung verwendet werden, geschieht Folgendes:

• [C-1-1] MUSS genau "true" zurückgeben für die relevanten supportsSensorToggle() API-Methode.
• [C-1-2] MÜSSEN, wenn eine App versucht, auf ein blockiertes Mikrofon oder eine blockierte Kamera zuzugreifen, dem Nutzer eine Angebotsdarstellung zu präsentieren, die sich nicht schließen lässt, zeigt an, dass der Sensor blockiert ist und dass zum Fortfahren eine Option erforderlich ist Blockierung oder Aufheben der Blockierung gemäß der AOSP-Implementierung, die diese Anforderung.
• [C-1-3] DÜRFEN nur leere (oder gefälschte) Kamera- und Audiodaten an Apps übergeben und meldet keinen Fehlercode, weil der Nutzer die Kamera nicht aktiviert hat. oder das Mikrofon über das in [C-1-2] angegebene Nutzerangebot übertragen.

9.8.14. –

9.8.15. Sandbox-API-Implementierungen

Android bietet über eine Reihe von Delegat-APIs einen Mechanismus zur sicheren Verarbeitung Daten auf Betriebssystemebene und Umgebungsdaten. Diese Verarbeitung kann an einen vorinstallierten APK mit privilegiertem Zugriff und eingeschränkten Kommunikationsmöglichkeiten, API-Implementierung in einer Sandbox

Jede Sandboxed API-Implementierung:

• [C-0-1] DARF NICHT die INTERNET-Berechtigung anfordern.
• [C-0-2] MUSS nur über strukturierte APIs auf das Internet zugreifen, die von öffentlich zugängliche Open-Source-Implementierungen oder indirekt über Android SDK APIs. Die Datenschutzeinstellungen Mechanismus ist definiert als „Maßnahmen, die nur Analysen in aggregierter den Abgleich protokollierter Ereignisse oder abgeleiteter Ergebnisse mit einzelnen Nutzern zu verhindern“, um zu verhindern, dass nutzerspezifische Daten introspektiv sind (z.B. Implementierung durch Differential Privacy-Technologie wie RAPPOR.
• [C-0-3] MÜSSEN die Dienste von anderen Systemkomponenten getrennt gehalten werden. (z.B. keine Bindung der Dienst- oder Freigabeprozess-IDs), mit Ausnahme der Folgendes: <ph type="x-smartling-placeholder">
  </ph>
  • Telefonie, Kontakte, System-UI und Medien
• [C-0-4] DÜRFEN Nutzern NICHT erlauben, die Dienste durch einen vom Nutzer installierbare Anwendung oder Dienst
• [C-0-5] MUSS nur den vorinstallierten Diensten erlauben, solche Daten zu erfassen. Es sei denn, die Ersatzfunktion ist in AOSP integriert (z.B. für digitale Assistant-Apps).
• [C-0-6] DÜRFEN KEINE anderen Apps als die vorinstallierten Dienste zulassen um solche Daten zu erfassen. Sofern keine solche Aufnahmemöglichkeit ist, wird mit einer Android SDK API implementiert.
• [C-0-7] MÜSSEN Nutzern die Möglichkeit bieten, die Dienste zu deaktivieren.
• [C-0-8] DARF NICHT auf die Nutzerangebote verzichten, um Android-Berechtigungen zu verwalten, die zu den Diensten gehören und dem Berechtigungsmodell von Android folgen, beschrieben in Abschnitt 9.1: Berechtigung:

9.8.16. Kontinuierliche Audio- und Kameradaten

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

• [C-0-1] MÜSSEN eine entsprechende Anzeige erzwingen (Kamera und/oder Mikrofon als gemäß Abschnitt 9.8.2 Aufzeichnung), es sei denn: <ph type="x-smartling-placeholder">
  </ph>
  • Dieser Zugriff erfolgt in einer Sandbox-Implementierung (siehe 9.8.15 Sandboxed API-Implementierung) durch ein Paket mit einem oder der folgenden Rollen: System UI Intelligence Ambient Audio Intelligence des Systems System Audio Intelligence Intelligenz zur Systembenachrichtigung, System Text Intelligence oder System Visual Intelligence.
  • Der Zugriff erfolgt über eine Sandbox, implementiert und durch Mechanismen in AOSP erzwungen (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
  • Der Audiozugriff erfolgt zu unterstützenden Zwecken vom Assistant-Anwendung mit SOURCE_HOTWORD als Audioquelle.
  • Der Zugriff wird vom System durchgeführt und mit Open-Source-Code.
• [C-SR-1] Es wird dringend empfohlen, die Einwilligung der Nutzer für jedes die diese Daten nutzen, und standardmäßig deaktiviert sein.
• [C-SR-2] UNBEDINGT EMPFOHLEN, dieselbe Behandlung anzuwenden (d.h. die die unter 9.8.2 Aufzeichnung, 9.8.6 Betriebssystem- und Umgebungsdaten 9.8.15 API-Implementierungen in einer Sandbox und 9.8.16 Kontinuierliche Audio- und Kamerafunktionen Daten) in Kameradaten übertragen, die von einem Remote-Wearable-Gerät stammen.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

• [C-1-1] MÜSSEN auf der Wearable-Fernbedienung darauf hinweisen, wird ein zusätzlicher Indikator angezeigt.

Ob Geräte die Möglichkeit bieten, mit einer digitalen Assistenten-App zu interagieren ohne das zugewiesene Keyword zu bearbeiten (z. B. allgemeine Nutzeranfragen oder Nutzerpräsenz über die Kamera)

• [C-2-1] MÜSSEN sicherstellen, dass diese Implementierung von einem Paket bereitgestellt wird, das die Rolle android.app.role.ASSISTANT.
• [C-2-2] MÜSSEN sicherstellen, dass bei dieser Implementierung HotwordDetectionService verwendet wird. und/oder VisualQueryDetectionService Android APIs.

9.8.17. Telemetry

Android speichert System- und App-Protokolle mithilfe von StatsLog APIs. Diese Logs werden verwaltet über StatsManager APIs, die von privilegierten Systemanwendungen genutzt werden können.

StatsManager bietet auch eine Möglichkeit, Daten zu erfassen, die als Datenschutz kategorisiert sind. von Geräten mit einem datenschutzfreundlichen Mechanismus entfernt werden. Insbesondere Die StatsManager::query API bietet die Möglichkeit, eingeschränkte Messwerte abzufragen Definition von Kategorien in StatsLog.

Jegliche Implementierungsabfragen und Erfassung eingeschränkter Messwerte von StatsManager:

• [C-0-1] MUSS die einzige Anwendung/Implementierung auf dem Gerät sein und halten Sie die Berechtigung READ_RESTRICTED_STATS.
• [C-0-2] MÜSSEN nur Telemetriedaten und das Protokoll des Geräts mit einem datenschutzfreundlichen Mechanismus auf. Der datenschutzfreundliche Mechanismus wird da sie nur die Analyse in aggregierter Form ermöglichen und die Übereinstimmung von Ereignisse protokolliert oder von Ergebnissen für einzelne Nutzer abgeleitet“, um zu verhindern, Nutzerdaten, die introspektiv sind (z.B. Implementierung mit einem differenziellen Datenschutztechnologien wie RAPPOR).
• [C-0-3] DÜRFEN derartige Daten NICHT mit Benutzeridentitäten (wie Account) zurück auf dem Gerät.
• [C-0-4] Diese Daten dürfen NICHT an andere Betriebssystemkomponenten weitergegeben werden, die den folgenden Anforderungen, die im aktuellen Abschnitt (9.8.17 Datenschutzfreundlich) beschrieben sind Telemetrie).
• [C-0-5] MÜSSEN eine Funktion zum Aktivieren/Deaktivieren des Datenschutzes anbieten. Telemetriedaten erheben, verwenden und weitergeben.
• [C-0-6] MÜSSEN Nutzern die Möglichkeit bieten, solche Daten zu löschen, werden erhoben, wenn Daten in irgendeiner Form auf dem Gerät gespeichert werden. Wenn Der Nutzer hat sich entschieden, die Daten zu löschen, MÜSSEN alle aktuell gespeicherten Daten entfernen auf auf dem Gerät.
• [C-0-7] MUSS die zugrunde liegende Implementierung eines datenschutzfreundlichen Protokolls offenlegen in einem Open-Source-Repository.
• [C-0-8 ]MÜSSEN in diesem Abschnitt Richtlinien für ausgehenden Datentraffic erzwingen, um die Erfassung zu verhindern. von Daten in eingeschränkten Messwertkategorien in StatsLog.

9.9. Verschlüsselung der Datenspeicherung

Alle Geräte MÜSSEN die Anforderungen in Abschnitt 9.9.1 erfüllen. Geräte, die auf einem API-Level vor dem in diesem Dokument auf den Markt gebracht wurden, von den Anforderungen in den Abschnitten 9.9.2 und 9.9.3 ausgenommen ist, Stattdessen werden sie MÜSSEN die Anforderungen in Abschnitt 9.9 der Richtlinie zu Android-Kompatibilität Definitionsdokument, das der API-Ebene entspricht, auf der das Gerät gestartet wurde.

9.9.1 Direct Boot

Geräteimplementierungen:

• [C-0-1] MÜSSEN die APIs für den Direct Boot Mode auch dann implementieren, wenn sie unterstützen keine Speicherverschlüsselung.

• [C-0-2] Die ACTION_LOCKED_BOOT_COMPLETED und ACTION_USER_UNLOCKED Intents MÜSSEN trotzdem übertragen werden, um Direct Boot-fähige Anwendungen zu signalisieren, Die Speicherorte für DE (Geräteverschlüsselung) und Credential Encrypt (CE) sind für den Nutzer verfügbar.

9.9.2 Verschlüsselungsanforderungen

Geräteimplementierungen:

• [C-0-1] MÜSSEN die Anwendung privat verschlüsseln. Daten (Partition /data) sowie die freigegebene Speicherpartition der Anwendung (/sdcard), wenn es sich um einen dauerhaften, nicht entfernbaren Teil des Geräts handelt.
• [C-0-2] MÜSSEN die Verschlüsselung der Datenspeicher zum jeweiligen Zeitpunkt standardmäßig aktivieren. der Nutzer die vorkonfigurierte Einrichtung abgeschlossen hat.

• [C-0-3] MUSS der oben genannten Verschlüsselung der Datenspeicher entsprechen Anforderung durch Implementierung einer der folgenden beiden Verschlüsselungsmethoden:

  • Dateibasierte Verschlüsselung und Metadatenverschlüsselung wie in Abschnitt 9.9.3.1 beschrieben.
  • Verschlüsselung auf Blockebene pro Nutzer, wie in Abschnitt 9.9.3.2 beschrieben.

9.9.3 Verschlüsselungsmethoden

Bei verschlüsselten Geräteimplementierungen gilt Folgendes:

• [C-1-1] MÜSSEN gestartet werden, ohne dass der Nutzer nach Anmeldedaten und Direct Boot-fähigen Apps den Zugriff auf den DE-Speicher (Device Encrypted Encryption) erlauben nachdem die ACTION_LOCKED_BOOT_COMPLETED-Nachricht übertragen wurde.
• [C-1-2] DARF den Zugriff auf den Credential Encrypted (CE)-Speicher erst erlauben, nachdem Der Nutzer hat das Gerät durch Eingabe seiner Anmeldedaten entsperrt. (z. B. Sicherheitscode, PIN, Muster oder Fingerabdruck) und die ACTION_USER_UNLOCKED Nachricht wird gesendet.
• [C-1-13] DÜRFEN KEINE Möglichkeit zum Entsperren des CE-geschützten Speichers anbieten ohne die vom Nutzer bereitgestellten Anmeldedaten, einen registrierten Treuhandschlüssel oder einen Implementierung fortsetzen, die die Anforderungen in Abschnitt 9.9.4.
• [C-1-4] MÜSSEN den verifizierten Bootmodus verwenden.

9.9.3.1 Dateibasierte Verschlüsselung mit Metadatenverschlüsselung

Wenn Geräteimplementierungen dateibasierte Verschlüsselung mit Metadatenverschlüsselung verwenden, Sie:

• [C-1-5] MÜSSEN Dateiinhalte und Dateisystemmetadaten mit AES-256-XTS oder Adiantum. AES-256-XTS bezieht sich auf den Advanced Encryption Standard. mit einem Chiffreschlüssel von 256 Bit, der im XTS-Modus betrieben wird; die gesamte Länge des Der Schlüssel beträgt 512 Bit.Adiantum bezieht sich auf Adiantum-XChaCha12-AES, wie unter https://github.com/google/adiantum Dateisystemmetadaten sind Daten wie die Datei Größen, Eigentumsrechte, Modi und erweiterte Attribute (xattrs).
• [C-1-6] MÜSSEN Dateinamen mit AES-256-CBC-CTS, AES-256-HCTR2 verschlüsseln, oder Adiantum.
• [C-1-12] Geräte mit AES-Verschlüsselung (Advanced Encryption Standard) (z. B. ARMv8 Cryptography Extensions auf ARM-basierten Geräten oder AES-NI auf x86-basierten Geräten), dann die oben genannten AES-basierten Optionen für den Dateinamen, und die Verschlüsselung von Dateisystem-Metadaten MÜSSEN verwendet werden, nicht Adiantum.
• [C-1-13] MÜSSEN einen kryptografisch starken und nicht umkehrbaren Schlüssel verwenden. Ableitungsfunktion (z.B. HKDF-SHA512) zur Ableitung benötigter Unterschlüssel (z.B. pro Datei) aus den CE- und DE-Schlüsseln. „Kryptografisch stark und nicht reversible bedeutet, dass die Schlüsselableitungsfunktion eine Sicherheitsstärke hat von mindestens 256 Bit und verhält sich wie eine Pseudozufallsfunktion Familie über seine Eingaben.
• [C-1-14] DÜRFEN NICHT dieselben FBE-Schlüssel oder -Unterschlüssel verwenden für unterschiedliche kryptografische Zwecke (z.B. Verschlüsselung und Schlüssel) oder zwei verschiedene Verschlüsselungsalgorithmen.
• [C-1-15] MÜSSEN sicherstellen, dass alle nicht gelöschten Blöcke von verschlüsselten Dateiinhalten im nichtflüchtigen Speicher mit einer Kombination aus Verschlüsselungs- Initialisierungsvektor (IV), der sowohl von der Datei als auch vom Offset innerhalb in der Datei. Darüber hinaus MÜSSEN alle derartigen Kombinationen unterschiedlich sein, es sei denn, erfolgt die Verschlüsselung mit Inline-Verschlüsselungshardware, die nur eine IV-Länge von 32 Bit.
• [C-1-16] MÜSSEN sicherstellen, dass alle nicht gelöschten verschlüsselten Dateinamen in unterschiedlichen Verzeichnissen wurden mit unterschiedlichen Verschlüsselungsschlüssel und Initialisierungsvektor (IV).

• [C-1-17] MÜSSEN sicherstellen, dass alle verschlüsselten Dateisystem-Metadatenblöcke Nichtflüchtiger Speicher wurde mit unterschiedlichen Kombinationen von Verschlüsselungsschlüsseln verschlüsselt. und Initialisierungsvektor (IV).

• Schlüssel zum Schutz von CE- und DE-Speicherbereichen und Dateisystemmetadaten:

  • [C-1-7] MÜSSEN kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. Dieser Schlüsselspeicher MÜSSEN an den verifizierten Bootmodus und die Hardware des Geräts gebunden sein Root of Trust.
  • [C-1-8] CE-Schlüssel MÜSSEN an die Anmeldedaten des Nutzers für den Sperrbildschirm gebunden werden.
  • [C-1-9] CE-Schlüssel MÜSSEN an einen Standard-Sicherheitscode gebunden werden, wenn der Nutzer Keine Anmeldedaten für den Sperrbildschirm angegeben.
  • [C-1-10] MUSS eindeutig und eindeutig sein, mit anderen Worten: Kein CE oder DE des Nutzers Schlüssel stimmt mit den CE- oder DE-Schlüsseln anderer Nutzer überein.
  • [C-1-11] MÜSSEN die vorgeschriebenen Chiffren, Schlüssellängen und Modi.
  • [C-1-12] MÜSSEN beim Entsperren und Sperren des Bootloaders sicher gelöscht werden wie hier beschrieben.

• SOLLTEN vorinstallierte wichtige Apps erstellen (z.B. Wecker, Telefon, Messenger) Direct Boot-fähig.

Das vorgelagerte Open-Source-Projekt von Android bietet eine bevorzugte Implementierung von Dateibasierte Verschlüsselung auf Basis des Linux-Kernels „fscrypt“ Verschlüsselungsfunktion verwenden, und der Metadatenverschlüsselung auf Basis des Linux-Kernels „dm-default-key“. .

9.9.3.2 Verschlüsselung auf Blockebene pro Nutzer

Wenn in Geräteimplementierungen die Verschlüsselung auf Blockebene pro Nutzer verwendet wird, gilt Folgendes:

• [C-1-1] MÜSSEN die Unterstützung für mehrere Nutzer wie in Abschnitt 9.5 beschrieben aktivieren.
• [C-1-2] MÜSSEN nutzerspezifische Partitionen bereitstellen, entweder mithilfe von Raw-Partitionen oder logische Volumes.
• [C-1-3] MÜSSEN eindeutige und eindeutige Verschlüsselungsschlüssel pro Nutzer für Verschlüsselung der zugrunde liegenden Blockgeräte.

• [C-1-4] MÜSSEN AES-256-XTS für die Verschlüsselung des Nutzers auf Blockebene verwenden. Partitionen.

• Die Schlüssel zum Schutz der auf Blockebene verschlüsselten Geräte pro Nutzer:

  • [C-1-5] MÜSSEN kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. Dieser Schlüsselspeicher MÜSSEN an den verifizierten Bootmodus und die Hardware des Geräts gebunden sein Root of Trust.
  • [C-1-6] MÜSSEN an den Sperrbildschirm des entsprechenden Nutzers gebunden sein Anmeldedaten.

Die nutzerspezifische Verschlüsselung auf Blockebene kann mit dem Linux-Kernel implementiert werden „dm-crypt“ statt auf nutzerspezifische Partitionen.

9.9.4 Bei Neustart fortsetzen

„Beim Neustart fortsetzen“ ermöglicht das Entsperren des CE-Speichers für alle Apps, einschließlich derer die Direct Boot noch nicht unterstützen, nach einem von einem OTA initiierten Neustart. Dieses können Nutzer Benachrichtigungen von installierten Apps erhalten, nachdem neu starten.

Eine Implementierung der Funktion „Fortsetzen beim Neustart“ muss weiterhin dafür sorgen, dass bei einem in die Hände eines Angreifers fällt, ist es Angreifer, die CE-verschlüsselten Daten des Nutzers wiederherzustellen, auch wenn das Gerät eingeschaltet ist aktiviert, der CE-Speicher ist entsperrt und der Nutzer hat das Gerät nach Erhalt entsperrt. ein Onlinereisebüro. Bei der Abwehr von Insiderangriffen gehen wir davon aus, dass sich der Angreifer Zugriff verschafft. um kryptografische Signaturschlüssel zu senden.

Im Detail:

• [C-0-1] Der CE-Speicher DARF NICHT lesbar sein, selbst für den Angreifer, der physisch einen an das Gerät und hat dann folgende Funktionen und Einschränkungen:

  • Kann mit dem Signaturschlüssel eines beliebigen Anbieters oder Unternehmens beliebige Zeichen signieren Nachrichten.
  • Kann dazu führen, dass ein Over-the-air-Update (OTA) auf dem Gerät empfangen wird.
  • Kann den Betrieb jeglicher Hardware (z. B. ZP oder Flash) verändern, mit Ausnahme von jedoch mit einer Verzögerung von mindestens einem und ein Gerät aus- und wieder einschalten, das RAM-Inhalte zerstört.
  • Der Betrieb von manipulationssicherer Hardware (z. B. Titan M) kann nicht geändert werden.
  • RAM des Live-Geräts kann nicht gelesen werden.
  • Die Anmeldedaten des Nutzers (PIN, Muster, Passwort) können nicht abgerufen werden oder sonst eingegeben wird.

Beispiel: Eine Geräteimplementierung, die alle Richtlinien der Beschreibungen finden Sie hier. [C-0-1] entsprechen.

9:10. Geräteintegrität

Die folgenden Anforderungen sorgen für Transparenz in Bezug auf den Status der Geräteintegrität. Geräteimplementierungen:

• [C-0-1] MÜSSEN ordnungsgemäß über die System-API-Methode gemeldet werden. PersistentDataBlockManager.getFlashLockState(), ob ihr Bootloader state gestattet das Flashen des System-Images.

• [C-0-2] MUSS zur Geräteintegrität den verifizierten Bootmodus unterstützen.

Wenn bereits Geräteimplementierungen ohne Unterstützung des verifizierten Bootmodus gestartet wurden einer früheren Android-Version und kann keine Unterstützung dafür hinzufügen durch ein Systemsoftware-Update ersetzt werden, KÖNNEN Anforderung.

Der verifizierte Bootmodus ist eine Funktion, die die Integrität des Geräts garantiert. Software. Wenn Geräteimplementierungen die Funktion unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN das Funktions-Flag für die Plattform angeben. android.software.verified_boot
• [C-1-2] MÜSSEN bei jeder Startsequenz eine Überprüfung durchführen.
• [C-1-3] MÜSSEN die Bestätigung über einen unveränderlichen Hardwareschlüssel starten, der bis zur Systempartition.
• [C-1-4] MÜSSEN jede Überprüfungsphase implementieren, um die Integrität zu prüfen. und Authentizität aller Byte in der nächsten Phase, bevor der Code in in der nächsten Phase.
• [C-1-5] MUSS die Überprüfungsalgorithmen so stark wie die aktuellen Algorithmen verwenden. Empfehlungen von NIST für Hash-Algorithmen (SHA-256) und öffentlichen Schlüssel Größen (RSA-2048) unterstützt.
• [C-1-6] DARF NICHT zulassen, dass der Bootvorgang abgeschlossen wird, wenn die Systemüberprüfung fehlschlägt. es sei denn, der Nutzer willigt ein, trotzdem zu starten. In diesem Fall werden die Daten aus Nicht verifizierte Speicherblöcke dürfen nicht verwendet werden.
• [C-1-7] DÜRFEN NICHT zulassen, dass verifizierte Partitionen auf dem Gerät geändert werden es sei denn, der Nutzer hat den Bootloader explizit entsperrt.
• [C-1-8] MUSS eine manipulationssichere Aufbewahrung verwenden, um zu speichern, Bootloader ist entsperrt. Ein fälschungssicherer Speicher bedeutet, dass der Bootloader erkennen, ob der Speicher in Android manipuliert wurde.
• [C-1-9] MÜSSEN den Nutzer bei der Verwendung des Geräts auffordern und Physische Bestätigung vor dem Zulassen eines Wechsels vom Bootloader erforderlich vom Sperrmodus zum Bootloader-Entsperrmodus wechseln.
• [C-1-10] MÜSSEN Rollback-Schutz für Partitionen implementieren, die von Android verwendet werden. (z.B. Boot- oder Systempartitionen) und nutzen Sie einen manipulationssicheren Speicher zur Aufbewahrung der Metadaten, die zum Bestimmen der minimal zulässigen Betriebssystemversion verwendet werden.
• [C-1-11] MÜSSEN alle Nutzerdaten während der Bootloader-Entsperrung sicher gelöscht werden und fest, wie in 9.12. Datenlöschung“ (einschließlich der Partition der Nutzerdaten alle NVRAM-Bereiche).

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

• [C-SR-2] Es wird dringend empfohlen, alle APK-Dateien mit privilegierten Apps zu überprüfen mit eine Vertrauenskette in Partitionen, die durch den verifizierten Bootmodus geschützt sind.
• [C-SR-3] EMPFOHLEN, alle ausführbaren Artefakte zu überprüfen, die von einer privilegierten App außerhalb ihrer APK-Datei (wie zum Beispiel dynamisch geladenem Code oder kompilierten Code) vor der Ausführung oder UNBEDINGT EMPFOHLEN, sie nicht auszuführen überhaupt nicht.
• SOLLTEN Sie den Rollback-Schutz für jede Komponente mit dauerhafter (z.B. Modem oder Kamera) verwenden und einen manipulationssicheren Speicher für Speichern der Metadaten, die zum Bestimmen der zulässigen Mindestversion verwendet wurden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Das vorgelagerte Open-Source-Projekt von Android bietet eine bevorzugte Implementierung von diese Funktion in der external/avb/ Repository, das in den Bootloader integriert werden kann, der zum Laden Android

Ob die Datei in Geräteimplementierungen verifiziert werden kann pro Seite:

• [C-2-1] unterstützen die kryptografische Verifizierung von Dateiinhalten ohne Lesen des in der gesamten Datei.

• [C-2-2] DÜRFEN NICHT erlauben, Leseanfragen für eine geschützte Datei erfolgreich sind, wenn der gelesene Inhalt nicht gemäß [C-2-1] oben überprüft.

• [C-2-4] MÜSSEN für aktivierte Dateien Datei-Prüfsumme in O(1) zurückgeben.

Wenn Geräteimplementierungen bereits gestartet wurden, ohne dass eine Verifizierung möglich ist Dateiinhalt anhand eines vertrauenswürdigen Schlüssels in einer früheren Android-Version und kann nicht hinzugefügt werden Unterstützung dieser Funktion durch ein Systemsoftware-Update erhalten, KÖNNEN sie ausgenommen werden. von der Anforderung entfernt werden. Das vorgelagerte Open-Source-Projekt von Android bietet eine bevorzugte Implementierung dieser Funktion basierend auf dem Linux-Kernel-Feature fs-verity.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

9.11. Schlüssel und Anmeldedaten

Das Android-Schlüsselspeichersystem ermöglicht es App-Entwicklern, kryptografische Schlüssel in einem Container zu speichern und in kryptografischer Vorgänge über die KeyChain API oder die Keystore API. Geräteimplementierungen:

• [C-0-1] MÜSSEN zulassen,dass mindestens 8.192 Schlüssel importiert oder generiert werden.
• [C-0-2] Bei der Authentifizierung auf dem Sperrbildschirm MUSS ein Zeitintervall implementiert werden. zwischen fehlgeschlagenen Versuchen. Mit n als Anzahl der fehlgeschlagenen Versuche das Zeitintervall MUSS mindestens 30 Sekunden für 9 < n < 30. Für n > 29, der Wert für das Zeitintervall MUSS mindestens 30*2^floor((n-30)/10) Sekunden betragen. oder mindestens 24 Stunden, je nachdem, welcher Wert kleiner ist.
• Sie sollten die Anzahl der Schlüssel, die generiert werden können, nicht einschränken.

Wenn die Geräteimplementierung einen sicheren Sperrbildschirm unterstützt, geschieht Folgendes:

• [C-1-1] MÜSSEN die Keystore-Implementierung mit einem isolierten der Ausführungsumgebung.
• [C-1-2] MUSS über RSA-, AES-, ECDSA-, ECDH (wenn IKeyMintDevice unterstützt wird), 3DES, und HMAC-Kryptografie sowie Hash-Werte der Familien MD5, SHA-1 und SHA-2 um die unterstützten Funktionen des Android Keystore-Systems 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 Verwendung des Trusty-Implementierung, aber eine andere ARM TrustZone-basierte Lösung oder ein Drittanbieter für sichere Sicherheit Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation sind eine Alternative Optionen.
• [C-1-3] MÜSSEN die Sperrbildschirm-Authentifizierung im isolierten und nur bei erfolgreicher Ausführung die authentifizierungsgebundene die zu verwendenden Schlüssel. Anmeldedaten für den Sperrbildschirm MÜSSEN in einem sodass nur die isolierte Ausführungsumgebung Authentifizierung. Das vorgelagerte Open-Source-Projekt von Android bietet Gatekeeper-Hardwareabstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

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.

• [C-1-5] MÜSSEN dem Nutzer die Auswahl des Ruhemodus-Timeouts für den Wechsel von in den gesperrten Zustand mit einer minimalen zulässigen Zeitüberschreitung von 15 Sekunden. Automobilgeräte, die den Bildschirm sperren, wenn die Haupteinheit deaktiviert ist oder der Nutzer gewechselt hat, KANN NICHT das Zeitlimit für den Ruhemodus angewendet werden. Konfiguration.
• [C-1-6] MUSS eine der folgenden Funktionen unterstützen: <ph type="x-smartling-placeholder">
  </ph>
  • IKeymasterDevice 3.0
  • IKeymasterDevice 4.0
  • IKeymasterDevice 4.1
  • IKeyMintDevice Version 1 oder
  • IKeyMintDevice Version 2.
• [C-SR-1] wird dringend empfohlen, IKeyMintDevice Version 1 zu unterstützen.

9.11.1. Sicherer Sperrbildschirm, Authentifizierung und virtuelle Geräte

Die AOSP-Implementierung folgt einem gestaffelten Authentifizierungsmodell, bei dem ein einer auf einem Wissensbetrieb basierenden primären Authentifizierung sekundär stark biometrische oder durch schwächere tertiäre Modalitäten.

Geräteimplementierungen:

• [C-SR-1] Es wird dringend empfohlen, nur eine der folgenden Optionen als primäre Authentifizierung festzulegen. :

  • Eine numerische PIN
  • Ein alphanumerisches Passwort

  • Ein Wischmuster auf einem Raster mit genau 3 x 3 Punkten

    Beachten Sie, dass die oben genannten Authentifizierungsmethoden als die empfohlenen primären Authentifizierungsmethoden.

• [C-0-1] MÜSSEN die Anzahl der fehlgeschlagenen primären Authentifizierungsversuche begrenzen.

• [C-SR-5] Es wird dringend empfohlen, eine Obergrenze von 20 zu implementieren, die nicht bestanden wird primäre Authentifizierungsversuche und wenn die Nutzer einwilligen und der Funktion zustimmen, setzen Sie das Gerät auf die Werkseinstellungen zurück. nach Überschreiten des Limits für fehlgeschlagene primäre Anfragen Authentifizierungsversuche.

Wenn in der Geräteimplementierung eine numerische PIN als primäre PIN festgelegt wird Authentifizierungsmethode und gehen Sie dann so vor:

• [C-SR-6] Eine PIN sollte mindestens 6 Ziffern haben oder einer 20-Bit-Entropie entspricht.
• [C-SR-7] Eine PIN mit weniger als 6 Ziffern sollte NICHT verwendet werden, Automatische Eingabe ohne Nutzerinteraktion zulassen, um das Teilen der PIN zu vermeiden Länge.

Wenn bei Geräteimplementierungen die empfohlene primäre Authentifizierung hinzugefügt oder geändert wird und eine neue Authentifizierungsmethode als sichere Methode zum Sperren des Bildschirms, die neue Authentifizierungsmethode:

• [C-2-1] MUSS die Nutzerauthentifizierungsmethode wie beschrieben in Nutzerauthentifizierung für Schlüsselverwendung erforderlich

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren hinzugefügt oder geändert werden Sperrbildschirm, wenn diese auf einem bekannten Secret basieren, und eine neue Authentifizierung verwenden , um den Bildschirm sicher zu sperren:

• [C-3-1] Die Entropie der kürzesten zulässigen Länge von Eingaben MÜSSEN sein die größer als 10 Bit sind.
• [C-3-2] Die maximale Entropie aller möglichen Eingaben MUSS größer sein als 18 Bit.
• [C-3-3] Die neue Authentifizierungsmethode DARF KEINE der empfohlene primäre Authentifizierungsmethoden (z.B. PIN, Muster, Passwort) implementiert und in AOSP bereitgestellt werden.
• [C-3-4] Die neue Authentifizierungsmethode MUSS deaktiviert werden, wenn die Die DPC-Anwendung (Device Policy Controller) hat das Passwort festgelegt Richtlinie zu den Anforderungen DevicePolicyManager.setRequiredPasswordComplexity() mit einer restriktiveren Komplexitätskonstante PASSWORT_KOMPLEXITY_NONE oder über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Konstante als PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] Neue Authentifizierungsmethoden MÜSSEN entweder auf die empfohlene primäre Authentifizierungsmethoden (z.B. PIN, Muster, mindestens alle 72 Stunden eingeben ODER dies dem dass einige Daten nicht gesichert werden, den Schutz ihrer Daten zu schützen.

Wenn bei Geräteimplementierungen die empfohlene primäre Authentifizierung hinzugefügt oder geändert wird um den Sperrbildschirm zu entsperren und eine neue Authentifizierungsmethode zu verwenden, die auf biometrischen Verfahren als sichere Methode zum Sperren des Bildschirms basiert, :

• [C-4-1] MÜSSEN alle im Abschnitt 7.3.10 für Klasse 1 (früher Komfort).
• [C-4-2] MÜSSEN über einen Fallback-Mechanismus verfügen, um einen der empfohlenen primären Authentifizierungsmethoden, die auf einem bekannten Secret basieren.
• [C-4-3] MÜSSEN deaktiviert werden und nur die empfohlene primäre zum Entsperren des Bildschirms, wenn der Device Policy Controller (DPC) verwendet wird Die Anwendung hat die Funktionsrichtlinie für Keyguard durch Aufrufen der Methode festgelegt. DevicePolicyManager.setKeyguardDisabledFeatures(), mit einer der verknüpften biometrischen Flags (d.h. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT KEYGUARD_DISABLE_FACE oder KEYGUARD_DISABLE_IRIS).

Wenn die biometrischen Authentifizierungsmethoden die Anforderungen nicht erfüllen für Klasse 3 (früher Strong), wie in Abschnitt 7.3.10:

• [C-5-1] Die Methoden MÜSSEN deaktiviert werden, wenn der Device Policy Controller (DPC) Anwendung hat die Qualitätsrichtlinie für Passwortanforderungen festgelegt über DevicePolicyManager.setRequiredPasswordComplexity() mit einem restriktiveren Komplexitäts-Bucket als PASSWORD_COMPLEXITY_LOW oder DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_BIOMETRIC_WEAK
• [C-5-2] Der Nutzer MUSS für die empfohlene primäre Instanz herausgefordert werden Authentifizierung (z. B. PIN, Muster, Passwort) wie in [C-1-7] beschrieben und [C-1-8] in Abschnitt 7.3.10.
• [C-5-3] Die Methoden DÜRFEN NICHT als sicherer Sperrbildschirm behandelt werden und MÜSSEN MÜSSEN die Anforderungen erfüllen, die mit C-8 beginnen.

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren hinzugefügt oder geändert werden Sperrbildschirm und eine neue Authentifizierungsmethode basiert auf einem physischen Token. oder den Standort:

• [C-6-1] Sie MÜSSEN über einen Fallback-Mechanismus verfügen, um eine der empfohlenen primären Authentifizierungsmethoden, die auf einem bekannten Secret basieren, die Anforderungen für einen sicheren Sperrbildschirm zu erfüllen.
• [C-6-2] Die neue Methode MÜSSEN deaktiviert werden und nur eine der empfohlenen primären Authentifizierungsmethoden, um das Display zu entsperren, wenn die Die DPC-Anwendung (Device Policy Controller) hat die Richtlinie mit einem der folgenden Elemente festgelegt: <ph type="x-smartling-placeholder">
  </ph>
  • Die DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) Methode
  • Die DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_NONE.
  • Die DevicePolicyManager.setRequiredPasswordComplexity() mit einem restriktiveren Komplexitäts-Bucket als PASSWORD_COMPLEXITY_NONE.
• [C-6-3] Der Nutzer MÜSSEN bei einer der empfohlenen primären Authentifizierungsmethoden (z.B.PIN, Muster, Passwort) mindestens einmal pro Maximal 4 Stunden. Wenn ein physisches Token die Anforderungen für TrustAgent-Implementierungen in C-X, Zeitüberschreitungsbeschränkungen die in C-9-5 definiert sind.
• [C-6-4] Die neue Methode DARF NICHT als sicherer Sperrbildschirm behandelt werden und MUSS beachten Sie die in C-8 unten aufgeführten Einschränkungen.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und mindestens einen Trust Agent, der die TrustAgentService System API implementiert, führt folgende Schritte aus:

• [C-7-1] MUSS im Einstellungsmenü und auf dem Schloss deutlich zu erkennen sein. Bildschirm, wenn die Gerätesperre ausgesetzt ist oder von einem oder mehreren Trust Agenten entsperrt werden kann. AOSP erfüllt diese Anforderung beispielsweise mit einer Textbeschreibung für die Einstellung „Automatische Sperre“ und „Ein/Aus-Taste sperrt“ in der Einstellungsmenü und ein gut erkennbares Symbol auf dem Sperrbildschirm.
• [C-7-2] MÜSSEN alle Trust Agent APIs im DevicePolicyManager, z. B. die KEYGUARD_DISABLE_TRUST_AGENTS konstant.
• [C-7-3] DARF NICHT vollständig die TrustAgentService.addEscrowToken() auf einem Gerät funktionieren, das als primäres privates Gerät verwendet wird (z. B. Handheld), die Funktion KANN aber vollständig auf dem Gerät implementiert werden. Implementierungen, die in der Regel gemeinsam genutzt werden (z.B. Android Television oder Automobilgerät).
• [C-7-4] MÜSSEN alle gespeicherten Tokens verschlüsseln, die von TrustAgentService.addEscrowToken()
• [C-7-5] DÜRFEN den Verschlüsselungsschlüssel bzw. das Treuhandtoken NICHT im auf dem der Schlüssel verwendet wird. Zum Beispiel ist es für Ein auf einem Smartphone gespeicherter Schlüssel zum Entsperren eines Nutzerkontos auf einem Fernseher Bei Automotive-Geräten darf das Treuhandtoken nicht gespeichert werden an jedem Teil des Fahrzeugs.
• [C-7-6] MÜSSEN den Nutzer vor dem Wechsel über die damit das Treuhandtoken den Datenspeicher entschlüsseln kann.
• [C-7-7] MÜSSEN über einen Fallback-Mechanismus verfügen, um einen der empfohlenen primären Authentifizierungsmethoden.
• [C-7-9] Der Nutzer MUSS für eine der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) wie in den [C-1-7] und [C-1-8] in Abschnitt 7.3.10, es sei denn, ist die Sicherheit der Nutzenden (z.B. Ablenkung des Autofahrers) von Besorgnis.
• [C-7-10] DÜRFEN NICHT als sicherer Sperrbildschirm behandelt werden und MÜSSEN die die unten in C-8 aufgeführt sind.
• [C-7-11] TrustAgents DARF NICHT auf primären persönlichen Geräten zugelassen werden (z. B. Handheld) verwendet, um das Gerät zu entsperren und sie nur für folgende Zwecke zu verwenden: ein bereits entsperrtes Gerät für einen Zeitraum von bis zu maximal 4 Stunden. Die Standardimplementierung von TrustManagerService in AOSP erfüllt diese Anforderung.
• [C-7-12] MÜSSEN eine kryptografisch sichere Methode (z. B. UKEY2) verwenden. Kommunikationskanal für die Übergabe des Treuhandtokens aus dem Speicher mit dem Zielgerät.

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren hinzugefügt oder geändert werden den Sperrbildschirm zu verwenden, der kein sicherer Sperrbildschirm ist, wie oben beschrieben, und verwenden Sie eine neue Authentifizierungsmethode zum Entsperren des Keyguard:

• [C-8-1] Die neue Methode MUSS deaktiviert werden, wenn der Device Policy Controller hat die Richtlinie für die Passwortqualität über die DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_NONE oder über das DevicePolicyManager.setRequiredPasswordComplexity() mit einer restriktiveren Komplexitätskonstante 'PASSWORD_COMPLEXITY_NONE'.
• [C-8-2] Sie DÜRFEN NICHT die Timer bis zum Ablauf des Passworts zurücksetzen, die von DevicePolicyManager.setPasswordExpirationTimeout()
• [C-8-3] Sie DÜRFEN KEINE API zur Nutzung durch Drittanbieter-Apps für den Status der Sperre ändern.

Wenn die Geräteimplementierung es Apps ermöglicht, sekundäre virtuelle Displays und unterstützen keine zugehörigen Eingabeereignisse, z. B. über VirtualDeviceManager, Sie:

• [C-9-1] MÜSSEN diese sekundären virtuellen Displays gesperrt werden, wenn das Gerät das Standarddisplay gesperrt ist, und entsperren Sie diese sekundären Bildschirme, wenn ist das Standarddisplay des Geräts entsperrt.

Ob Apps sekundäre virtuelle Displays erstellen und zugehörige Eingaben unterstützen können z. B. über VirtualDeviceManager, werden:

• [C-10-1] MUSS für jedes virtuelle Gerät einen separaten Sperrstatus unterstützen
• [C-10-2] MÜSSEN bei Zeitüberschreitung bei Inaktivität die Verbindung aller virtuellen Geräte getrennt werden
• [C-10-3] MUSS eine Zeitüberschreitung bei Inaktivität haben
• [C-10-4] MÜSSEN alle Bildschirme gesperrt werden, wenn der Nutzer eine Lockdown, einschließlich über die Funktionen zum Sperren von Geräten, die für Handheld-Geräte erforderlich sind (siehe Abschnitt 2.2.5[9.11/H-1-2])
• [C-10-5] MÜSSEN separate virtuelle Geräteinstanzen pro Nutzer haben

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

• [C-10-11] MÜSSEN die Authentifizierungs-UI auf virtuellen Geräten deaktivieren, einschließlich Eingabe von Wissensfaktoren und biometrischer Prompt

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

• [C-10-13] MUSS keinen Status der virtuellen Gerätesperre als Nutzerauthentifizierung verwenden Autorisierung mit dem Android Keystore System. Weitere Informationen finden Sie unter KeyGenParameterSpec.Builder.setUserAuthentication*

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräte so implementiert sind, dass Nutzer die primäre Domain übertragen können von einem Quellgerät zum Zielgerät, z. B. bei der Ersteinrichtung des Zielgeräts:

• [C-11-1] MÜSSEN den Wissensfaktor mit ähnlichen Schutzgarantien verschlüsseln wie die in den Google Cloud Key Vault Whitepaper zum Thema Sicherheit, wenn Sie vom Quellgerät bis zum Zielgerät, Wissensfaktor kann nicht per Fernzugriff entschlüsselt oder für Remote-Entsperrung verwendet werden egal auf welchem Gerät.
• [C-11-2] MÜSSEN Nutzer auf dem Quellgerät um Bestätigung der Wissensfaktor des Quellgeräts, bevor der Wissensfaktor übertragen wird auf das Zielgerät übertragen.
• [C-11-3] MÜSSEN, auf einem Zielgerät ohne festgelegte primäre Authentifizierung Wissensfaktor nutzen, bitten Sie die Nutzenden, einen übertragenen Wissensfaktor an das Zielgerät senden, bevor Sie diesen Wissensfaktor als primären Authentifizierung für das Zielgerät und vor der Daten verfügbar, die von einem Quellgerät übertragen wurden.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und mindestens einen Trust Agents, die die TrustAgentService.grantTrust() System API mit FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE angeben, dass sie:

• [C-12-1] DARF nur grantTrust() mit dem Flag aufrufen, wenn eine Verbindung zu einem in der Nähe eines physischen Geräts mit einem eigenen Sperrbildschirm und wenn der Nutzer ihre Identität anhand dieses Sperrbildschirms authentifiziert haben. Geräte in der Nähe können Nutze die Erkennungsmechanismen am Handgelenk oder am Körper, nachdem das Gerät einmal entsperrt wurde. die Anforderungen an die Nutzerauthentifizierung erfüllen.
• [C-12-2] MÜSSEN die Geräteimplementierung in der TrustState.TRUSTABLE wenn der Bildschirm ausgeschaltet ist (z. B. durch Drücken einer Taste oder eines Displays) abgelaufen) und der TrustAgent hat das Vertrauen nicht widerrufen. Der AOSP erfüllt diese Anforderung erfüllen.
• [C-12-3] DARF das Gerät nur von TrustState.TRUSTABLE in den TrustState.TRUSTED, wenn der TrustAgent immer noch Vertrauen gewährt, basierend auf die Anforderungen in C-12-1.
• [C-12-4] MUSS TrustManagerService.revokeTrust() anrufen <ph type="x-smartling-placeholder">
  </ph>
  • Nach spätestens 24 Stunden nach Erteilung der Vertrauensstellung oder
  • Nach acht Stunden Inaktivität oder
  • Wenn die Implementierungen keine kryptografisch sichere und genaue Bereichserkennung gemäß Definition in [C-12-5], wenn die zugrunde liegende Verbindung an das nahegelegene physische Gerät verloren geht.
• [C-12-5] Implementierungen mit einer sicheren und genauen Bereichserkennung, um die Anforderungen von [C-12-4] MÜSSEN eine der folgenden Lösungen verwendet werden: <ph type="x-smartling-placeholder">
  </ph>
  • Implementierungen mit UWB: <ph type="x-smartling-placeholder">
    </ph>
    • MÜSSEN die Konformität, Zertifizierung, Fehlerfreiheit und Kalibrierungsanforderungen für UWB gemäß 7.4.9.
    • MÜSSEN einen der P-STS-Sicherheitsmodi verwendet werden, die in 7.4.9
  • Implementierungen unter Verwendung von Wi-Fi Neighborhood Awareness Networking (NAN): <ph type="x-smartling-placeholder">
    </ph>
    • MÜSSEN die Anforderungen an die Genauigkeit 2.2.1 [7.4.2.5/H-SR-1], verwenden Sie die Bandbreite von 160 MHz (oder und führen Sie die Schritte zur Einrichtung Anwesenheitskalibrierung:
    • MÜSSEN sichere LTF-Anzeigen gemäß Definition in IEEE 802.11az:

Ob Apps sekundäre virtuelle Displays erstellen und zugehörige Eingaben unterstützen können Ereignisse wie VirtualDeviceManager und die Bildschirme nicht mit VIRTUAL_DISPLAY_FLAG_SECURE gekennzeichnet sind, werden sie:

• [C-13-8] MÜSSEN activities mit dem Attribut „android:canDisplayOnRemoteDevices“ oder den Metadaten „android.activity.can_display_on_remote_devices“ blockieren, die auf „false“ gesetzt sind, damit sie nicht auf dem virtuellen Gerät gestartet werden .

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

Wenn Geräteimplementierungen separate Stromzustände für das Display durch DeviceStateManager UND unterstützen separate Displaysperrstatus über KeyguardDisplayManager:

• [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, an einem Qualifikations-Meeting teilzunehmen Anforderungen, die in Abschnitt 9.11.1 definiert sind, oder eine biometrische Besprechung Spezifikationen der Klasse 1, die in Abschnitt 7.3.10 definiert sind, um unabhängige das Entsperren über das Standard-Display des Geräts erfolgt.
• [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, die separate Display-Entsperrung einzuschränken Anzeigezeitlimit überschritten.
• [C-SR-4] Es wird dringend empfohlen, Nutzern zu erlauben, alle Bildschirme global zu sperren durch Sperren des primären Handheld-Geräts.

9.11.2. Kofferraum

Das Android-Schlüsselspeichersystem ermöglicht können App-Entwickler kryptografische Schlüssel in einem speziellen sicheren Prozessor als sowie in der oben beschriebenen isolierten Ausführungsumgebung. So eine dedizierten sicheren Prozessor als "StrongBox" bezeichnet. Anforderungen C-1-3 die Anforderungen, die ein Gerät erfüllen muss, um gelten als StrongBox.

Geräteimplementierungen mit einem dedizierten sicheren Prozessor:

• [C-SR-1] wird dringend empfohlen, StrongBox zu unterstützen. StrongBox wahrscheinlich in einer zukünftigen Version eine Voraussetzung sein.

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

• [C-1-1] MUSS FEATURE_STRONGBOX_KEYSTORE deklarieren.

• [C-1-2] MUSS spezielle, sichere Hardware bereitstellen, die für die Sicherung Schlüsselspeicher und sichere Nutzerauthentifizierung. Die dedizierte Sicherheitsfunktion Hardware auch für andere Zwecke verwendet werden kann.

• [C-1-3] MUSS eine diskrete CPU ohne Cache, DRAM, Coprozessoren haben oder andere Kernressourcen mit dem Anwendungsprozessor (AP) nutzen.

• [C-1-4] MÜSSEN sicherstellen, dass mit dem Zugangspunkt gemeinsam genutzte Peripheriegeräte keine Änderungen mehr vornehmen können StrongBox-Verarbeitung auf irgendeine Weise durchzuführen oder Informationen von StrongBox zu erhalten Der AP kann den Zugriff auf StrongBox deaktivieren oder blockieren.

• [C-1-5] MUSS eine interne Uhr mit angemessener Genauigkeit (+-10%) haben. das immun gegen Manipulation durch den AP ist.

• [C-1-6] MUSS einen echten Zufallszahlengenerator haben, der gleichmäßig verteilte und unvorhersehbare Ausgabe.

• [C-1-7] MUSS manipulationsgeschützt sein, einschließlich Widerstand gegen physische Durchdringung und Störungen.

• [C-1-8] MUSS einen Widerstand gegen den Seitenkanal haben, einschließlich Widerstand gegen Datenlecks über Stromversorgung, Zeitstrahlung, elektromagnetische Strahlung und Seitenkanäle in der Strahlung.

• [C-1-9] MÜSSEN über eine sichere Speicherung verfügen, um Vertraulichkeit zu gewährleisten. Integrität, Authentizität, Einheitlichkeit und Aktualität der Inhalte. Der Speicher DÜRFEN NICHT gelesen oder geändert werden, außer die gemäß den StrongBox-APIs zulässig sind.

• Um die Konformität mit [C-1-3] bis [C-1-9] zu validieren, Implementierungen:

• [C-1-11] MUSS die Firmware enthalten, die von einem National akkreditiertes Testlabor mit High-Attacke-Angriff Bewertung potenzieller Schwachstellen gemäß der Common Criteria-Anwendung des Angriffspotenzials auf Smartcards.
• [C-SR-2] wird dringend empfohlen, die Hardware mitzuliefern, bewertet anhand eines Sicherheitsziels und eines Bewertungssicherheitsniveaus (EAL) 5, erweitert durch AVA_VAN.5. EAL-5-Zertifizierung ist wahrscheinlich in einer zukünftigen Version eine Voraussetzung sein.
• [C-SR-3] Dringend empfohlen, gegen Insiderangriffe zu wehren Das bedeutet, dass ein Insider mit Zugriff auf die Firmware-Signatur Schlüssel können keine Firmware erzeugen, die zum Leck der StrongBox führt um funktionale Sicherheitsanforderungen zu umgehen, Zugriff auf vertrauliche Nutzerdaten zu ermöglichen. Die empfohlene Implementierungsmethode Bei IAR werden Firmware-Updates nur zugelassen, wenn das Passwort des primären Nutzers wird über den IAuthSecret HAL bereitgestellt.

9.11.3. Anmeldedaten für Identität

Das Identity Credential System wird definiert und erreicht, indem alle APIs in der android.security.identity.* Paket. Mit diesen APIs können App-Entwickler die Nutzeridentität speichern und abrufen. Dokumente. Geräteimplementierungen:

• [C-SR-1] wird dringend empfohlen, die Anmeldedaten „Identity Credential“ zu implementieren System:

Wenn das Identity Credential System in Geräteimplementierungen implementiert ist, gilt Folgendes:

• [C-1-1] MUSS für IdentityCredentialStore#getInstance() einen Wert ungleich null zurückgeben .

• [C-1-2] MÜSSEN das Identity Credential System (z.B. die android.security.identity.* APIs) über den Code, der mit einer vertrauenswürdigen in einem Bereich zu platzieren, 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.

• [C-1-3] Die kryptografischen Vorgänge zur Implementierung der Identitätsbestätigung Anmeldedatensystem (z.B. die android.security.identity.* APIs) MÜSSEN die vollständig in der vertrauenswürdigen Anwendung und dem Material des privaten Schlüssels durchgeführt werden, MUSS Verlassen Sie nie die isolierte Ausführungsumgebung, es sei denn, dies ist ausdrücklich erforderlich durch übergeordnete APIs (z.B. die createEphemeralKeyPair() -Methode).

• [C-1-4] Die vertrauenswürdige Anwendung MUSS so implementiert werden, Sicherheitseigenschaften sind nicht betroffen (z.B. werden Anmeldedaten nicht freigegeben) sofern Bedingungen der Zugriffssteuerung nicht erfüllt sind, können für willkürlich verwendet werden, selbst wenn Android falsch funktioniert oder kompromittiert wird.

Das vorgelagerte Open-Source-Projekt von Android bietet eine Referenz Implementierung einer vertrauenswürdigen Anwendung (frei verfügbar) mit denen das System für Identitätsnachweise implementiert werden kann.

9.12. Löschen von Daten

Alle Geräteimplementierungen:

• [C-0-1] MÜSSEN Nutzern eine Methode zum Zurücksetzen auf die Werkseinstellungen zur Verfügung stellen.
• [C-0-2] MÜSSEN alle Daten im Dateisystem für Nutzerdaten löschen, wenn ein „Zurücksetzen auf die Werkseinstellungen“.
• [C-0-3] MÜSSEN die Daten so gelöscht werden, dass Branchenstandards wie NIST SP800-88 bei der Durchführung einer Zurücksetzen".
• [C-0-4] MÜSSEN den obigen "Zurücksetzen auf die Werkseinstellungen" auslösen. wenn der DevicePolicyManager.wipeData() Die API wird von der Device Policy Controller-App des primären Nutzers aufgerufen.
• KANN eine Option zur schnellen Datenlöschung anbieten, bei der nur eine logische Löschung durchgeführt wird.

9:13. Abgesicherter Modus

Android bietet den abgesicherten Bootmodus, mit dem Nutzer in einem bestimmten Modus starten können. in denen nur vorinstallierte System-Apps ausgeführt werden dürfen und alle Drittanbieter-Apps, Apps sind deaktiviert. Dieser Modus, der als „Abgesicherter Modus“ bezeichnet wird, bietet dem Nutzer die Möglichkeit, potenziell schädliche Apps von Drittanbietern zu deinstallieren.

Es gibt folgende Geräteimplementierungen:

• [C-SR-1] UNBEDINGT EMPFOHLEN, den abgesicherten Bootmodus zu implementieren.

Wenn Geräteimplementierungen den abgesicherten Bootmodus implementieren, gilt Folgendes:

• [C-1-1] MÜSSEN dem Nutzer die Möglichkeit geben, den abgesicherten Startmodus so aktivieren, dass keine Unterbrechung durch Drittanbieter möglich ist Apps, die auf dem Gerät installiert sind, es sei denn, die Drittanbieter-App ist ein Device Policy Controller und hat die UserManager.DISALLOW_SAFE_BOOT Markierung als wahr.

• [C-1-2] MÜSSEN dem Nutzer die Möglichkeit geben, alle Drittanbieter-Apps im abgesicherten Modus zu deinstallieren.

• SOLLTE dem Nutzer die Möglichkeit geben, über das mit einem Workflow, der sich von dem beim normalen Booten unterscheidet.

9:14. Kfz-Systemisolierung

Android Automotive-Geräte müssen Daten mit wichtigen Fahrzeugen austauschen Untersystemen mithilfe von vehicle HAL zum Senden und Empfangen von Nachrichten über Fahrzeugnetzwerke wie den CAN-Bus.

Der Datenaustausch kann abgesichert werden, indem Sicherheitsfunktionen unterhalb der Android-Framework-Ebenen, um schädliche oder unbeabsichtigte Interaktionen mit dieser Subsysteme.

9:15. Abos

„Abos“ finden Sie in den bereitgestellten Details von einem Mobilfunkanbieter über SubscriptionManager.setSubscriptionPlans()

Alle Geräteimplementierungen:

• [C-0-1] Sie müssen Abonnements nur an die App des Mobilfunkanbieters zurückgeben, die Sie ursprünglich zur Verfügung gestellt haben.
• [C-0-2] DÜRFEN KEINE Abos per Remotezugriff sichern oder hochladen.
• [C-0-3] DARF nur Überschreibungen wie die folgenden zulassen: SubscriptionManager.setSubscriptionOverrideCongested(), über die Mobilfunkanbieter-App, die derzeit gültige Abos anbietet.

9:16. Migration von Anwendungsdaten

Wenn Geräteimplementierungen die Möglichkeit bieten, Daten von einem Gerät auf ein anderes Gerät verwenden und die App-Daten, die kopiert werden, nicht auf das vom App-Entwickler im Manifest über android:fullBackupContent verwenden, gilt Folgendes:

• [C-1-1] DÜRFEN KEINE Übertragungen von Anwendungsdaten von Geräte, auf denen der Nutzer keine primäre Authentifizierung als beschrieben in 9.11.1 Sicherer Sperrbildschirm und Authentifizierung.
• [C-1-2] MUSS die primäre Authentifizierung bei der Quelle sicher bestätigen Gerät und bestätigen Sie mit dem Nutzerabsicht, dass die Daten in die Quelle kopiert werden sollen bevor Daten übertragen werden.
• [C-1-3] MÜSSEN Sie die Attestierung des Sicherheitsschlüssels verwenden, um sicherzustellen, und das Zielgerät bei der Migration von Gerät zu Gerät und einen gesperrten Bootloader haben.
• [C-1-4] MUSS nur Anwendungsdaten in dieselbe Anwendung auf der Zielgerät mit demselben Paketnamen UND Signaturzertifikat an.
• [C-1-5] MÜSSEN einen Hinweis anzeigen, dass auf dem Quellgerät Daten vorliegen die im Rahmen einer Geräte-zu-Gerät-Datenmigration im Einstellungsmenü migriert wurden. Nutzer Diese Angabe DARF NICHT entfernt werden.

Neue Anforderungen für 15 Nutzer (AOSP experimentell)

9:17. Android Virtualisierungs-Framework

10. Software-Kompatibilitätstests

Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen. Beachten Sie jedoch, dass kein Softwaretestpaket vollständig umfassend ist. Aus diesem Grund wird dringend empfohlen, die Implementierung von möglichst viele Änderungen an der Referenz vornehmen und -Implementierung von Android, die über das Android Open Source Project verfügbar ist. Dadurch wird das Risiko von Programmfehlern minimiert, die zu Inkompatibilitäten führen die nachgearbeitet werden müssen und potenzielle Geräteupdates erforderlich sind.

10.1. Kompatibilitätstest-Suite

Geräteimplementierungen:

• [C-0-1] MUSS die Android Compatibility Test Suite (CTS) bestehen. die aus dem Android Open Source Project verfügbar sind, Software auf dem Gerät.

• [C-0-2] MÜSSEN die Kompatibilität bei Mehrdeutigkeiten in CTS und jeglichen Neuimplementierungen von Teilen des Referenzquellcodes.

Das CTS ist für die Ausführung auf einem echten Gerät konzipiert. Wie jede Software nutzt auch die CTS kann selbst Fehler enthalten. Die Version von CTS wird unabhängig davon Kompatibilitätsdefinition und mehrere Versionen der CTS können veröffentlicht werden für Android 15

Geräteimplementierungen:

• [C-0-3] MÜSSEN die aktuelle CTS-Version haben, die zum Zeitpunkt des Geräts verfügbar war. abgeschlossen ist.

• SOLLTEN die Referenzimplementierung in der Android-Open-Source-Struktur verwenden. so viel wie möglich.

10.2. CTS-Prüfung

Der CTS Verifier ist in der Kompatibilitätstest-Suite enthalten. ist darauf ausgelegt, von einem menschlichen Bediener ausgeführt zu werden, um Funktionen zu testen, die nicht werden automatisch durch ein automatisiertes System getestet, z. B. die korrekte Funktion einer Kamera und Sensoren.

Geräteimplementierungen:

• [C-0-1] MÜSSEN alle anwendbaren Fälle in der CTS-Prüfung korrekt ausführen.

Die CTS Verifier App bietet Tests für viele Arten von Hardware, darunter einige Hardware. der optional ist.

Geräteimplementierungen:

• [C-0-2] MÜSSEN alle Tests für eigene Hardware bestehen. zum Beispiel Besitzt ein Gerät einen Beschleunigungsmesser, MUSS dieses die ordnungsgemäße Ausführung des Beschleunigungsmesser-Testlauf im CTS Verifier.

Testfälle für Funktionen, die nach dieser Kompatibilitätsdefinition als optional gekennzeichnet sind Das Dokument KANN übersprungen oder weggelassen werden.

• [C-0-2] Alle Geräte und Builds MÜSSEN den CTS Verifier ordnungsgemäß ausführen. wie oben erwähnt. Da viele Builds sehr ähnlich sind, Es wird nicht erwartet, dass Implementierer den CTS Verifier explizit für Builds ausführen die sich nur geringfügig unterscheiden. Insbesondere Geräteimplementierungen, die unterscheiden sich von einer Implementierung, die den CTS Verifier nur durch den enthaltene Sprachen, Branding usw. KANN den CTS Verifier-Test weggelassen werden.

11. Software zum Aktualisieren

• [C-0-1] Geräteimplementierungen MÜSSEN einen Mechanismus enthalten, der die die gesamte Systemsoftware aus. Der Mechanismus muss nicht live ausgeführt werden. ein Geräteneustart erforderlich ist. Es kann jede Methode verwendet werden, sofern damit die gesamte auf dem Gerät vorinstallierte Software. Beispiele: die folgende Anforderung erfüllen:

  • „Over-the-Air (OTA)“ Downloads mit Offline-Update durch Neustart.
  • „Angebunden“ von einem Host-PC über USB aktualisiert.
  • „Offline“ über einen Neustart oder über eine Datei auf Wechseldatenträgern.

• [C-0-2] Der verwendete Aktualisierungsmechanismus MUSS die Updates unterstützen, ohne den Nutzer zu löschen. Daten. Das heißt, der Aktualisierungsmechanismus MUSS die privaten Daten der Anwendung erhalten und die freigegebenen Daten einer Anwendung. Beachten Sie, dass die vorgelagerte Android-Software ein die diese Anforderung erfüllt.

• [C-0-3] Das gesamte Update MUSS signiert sein und der Mechanismus für Updates auf dem Gerät MÜSSEN die Aktualisierung und Signatur anhand eines öffentlichen Schlüssels, der auf dem Gerät gespeichert ist, verifizieren.

• [C-SR-1] Der Signaturmechanismus wird dringend empfohlen, das Update zu hashen mit SHA-256 und validieren Sie den Hash anhand des öffentlichen Schlüssels mithilfe von ECDSA NIST P-256.

Wenn die Geräteimplementierung die Unterstützung kostenloser Daten umfasst 802.11- oder Bluetooth PAN-Profil (Personal Area Network) Dann geschieht Folgendes:

• [C-1-1] MÜSSEN OTA-Downloads mit Offline-Updates per Neustart unterstützen.

Bei Geräteimplementierungen SOLLTEN Sie bestätigen, dass das System-Image binär identisch ist. auf das erwartete Ergebnis nach einem Onlinereisebüro. Blockbasiertes Online-Reisebüro Implementierung im vorgelagerten Android Open Source Project, hinzugefügt seit Android diese Anforderung erfüllt.

Außerdem sollten Geräteimplementierungen A/B-Systemupdates unterstützen. Der AOSP implementiert diese Funktion mithilfe des Boot-Steuerelement-HAL.

Wenn ein Fehler in einer Geräteimplementierung gefunden wird, nachdem sie veröffentlicht wurde, innerhalb seiner angemessenen Produktlebensdauer liegt, die in Absprache mit Android-Kompatibilitätsteam bitten, die Kompatibilität von Drittanbieter-Apps Anwendungen, dann gehen Sie so vor:

• [C-2-1] Der Geräteimplementierung MÜSSEN den Fehler über eine Software beheben. Update verfügbar, das mit dem oben beschriebenen Mechanismus angewendet werden kann.

Android umfasst Funktionen, mit denen die Geräteeigentümer-App (falls vorhanden) Folgendes ermöglicht: die Installation von Systemupdates zu steuern. Wenn das Systemupdate-Subsystem für Geräte melden „android.software.device_admin“ dann:

• [C-3-1] MÜSSEN das in SystemUpdatePolicy beschriebene Verhalten implementieren. .

12. Änderungsprotokoll für Dokumente

Für eine Zusammenfassung der Änderungen an der Kompatibilitätsdefinition in diesem Release:

• Änderungsprotokoll des Dokuments

13. Kontakt

Sie können am Forum zur Android-Kompatibilität und um Klarstellungen bitten oder Probleme ansprechen, die das Dokument Ihrer Meinung nach nicht enthält, Cover.