1. Einführung
In diesem Dokument werden die Anforderungen aufgeführt, die bei Geräten erfüllt werden müssen. um mit Android 13 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 13. Eine „Geräteimplementierung“ oder „Implementierung“ ist der Hardware-/Softwarelösung entwickelt.
Damit das Gerät mit Android 13 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)
- C: Kern (Anforderungen, die für alle Implementierungen von Android-Geräten gelten)
- H: Android-Handheld-Gerät
- T: Android TV-Gerät
- A: Android Automotive-Implementierung
- W: Android Watch-Implementierung
- Tab: Android-Tablet-Implementierung
- Bedingungs-ID
- Wenn die Anforderung unbedingt erforderlich ist, wird diese ID auf 0 gesetzt.
- Wenn die Anforderung bedingt ist, wird für die erste und die Zahl erhöht sich im selben Abschnitt um 1 denselben Gerätetyp.
- Anforderungs-ID
- 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.
- Das Display sollte 3,3 Zoll (oder 2,5" für Geräteimplementierungen, die mit API-Level 29 oder zuvor) auf 8 Zoll.
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. Ein mit Android kompatibles Display, das alle hier beschriebenen Anforderungen erfüllt Dokument.
[7.1.1.3/H-SR-1] sind DRINGEND empfohlen, Nutzern die Möglichkeit bieten, die Anzeigegröß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.
Wenn Implementierungen von Handheld-Geräten die Bildschirmdrehung durch Software unterstützen, gilt Folgendes:
- [7.1.1.1/H-1-1]* MÜSSEN den logischen Bildschirm der für Anwendungen von Drittanbietern zur Verfügung gestellt wird, beträgt mindestens 5 cm kurze Kante(n) und 2,7" an den langen Kanten. Geräte, die mit Android API-Level 29 oder niedriger ausgeliefert wurden, KÖNNEN von dieser Anforderung ausgenommen sind.
Wenn Implementierungen von Handheld-Geräten die Bildschirmdrehung durch Software nicht unterstützen, Sie:
- [7.1.1.1/H-2-1]* MÜSSEN den logischen Bildschirm der für Anwendungen von Drittanbietern zur Verfügung gestellt wird, die kurzen Kanten. Geräte, die mit Android API-Level 29 oder niedriger ausgeliefert wurden, KÖNNEN von dieser Anforderung ausgenommen sind.
Wenn die Implementierung von Handheld-Geräten Unterstützung für High Dynamic Range fordert
wird bis Configuration.isScreenHdr()
angezeigt
:
- [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
undVK_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 gemäß der vorgelagerten offenen Android-Plattform 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 bereitstellen.
- [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 vonKEYCODE_MEDIA_PLAY_PAUSE
oderKEYCODE_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.
- [7.4.3/H] SOLLTE Unterstützung für Bluetooth und Bluetooth LE.
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 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 Die Temperatur muss zwischen 50 und 95 Grad liegen.
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.
Implementierung von Handheld-Geräten über einen USB-Port, der Peripheriegeräte unterstützt haben sie folgende Möglichkeiten:
- [7.7.1/H-1-1] MUSS Android Open Accessory (AOA) implementieren. der API erstellen.
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 überandroid.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 Rolle „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-Audioterminal 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 Rolle „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 Typ des USB-Audioterminals 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.
Wenn in Implementierungen von Handheld-Geräten android.hardware.audio.output
und
android.hardware.microphone
:
[5.6/H-1-1] MUSS einen mittleren kontinuierlichen Hin- und Rückflug haben eine Latenz von 500 Millisekunden weniger über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 50 ms über die folgenden Datenpfade: „Lautsprecher zu Mikrofon“, 3,5-mm-Loopback-Adapter (falls unterstützt), USB-Loopback-Adapter (falls unterstützt).
[5.6/H-1-2] MUSS eine durchschnittliche Latenz von Tap-to-Ton haben. von 500 Millisekunden oder weniger bei mindestens 5 Messungen über dem Lautsprecher zum Mikrofondatenpfad.
Implementierungen von Handheld-Geräten, die mindestens einen haptischen Bedienungselement enthalten:
- [7,10/H]* DÜRFEN KEINE exzentrische rotierende Masse (ERM) verwenden haptischen Bedienungselement (Vibrator).
- [7.10/H]* SOLLTE die Position des Bedienelements positionieren. in der Nähe der Stelle, an der das Gerät normalerweise mit den Händen gehalten oder berührt wird.
- [7.10/H]* SOLLTEN alle öffentlichen Konstanten für gutes Haptik in android.view.HapticFeedbackConstants (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START und GESTURE_END).
- [7.10/H]* SOLLTEN alle öffentlichen Konstanten für
gutes Haptik
in android.os.VibrationEffect
(EFFEKT_TICK, EFFEKT_CLICK, EFFEKT_HEAVY_CLICK und
EFFEKT_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, THUD). Einige dieser Primitive, z. B. LOW_TICK und SPIN sind möglicherweise nur praktikabel, wenn die Vibration relativ niedrigen Frequenzen. [7.10/H]* SOLLTEN den Richtlinien zur Kartierung öffentlicher Konstanten entsprechen. in android.view.HapticFeedbackConstants empfohlenen Konstanten für android.os.VibrationEffect mit den entsprechenden Amplitudenbeziehungen.
[7.10/H]* SOLLTE FOLGENDES Qualitätsbewertung für createOneShot() und createWaveform() APIs
[7.10/H]* SOLLTEN prüfen, ob das Ergebnis der öffentlichen android.os.Vibrator.hasAmplitudeControl() API die Vibrationsfähigkeiten des Nutzers korrekt widerspiegelt.
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 von Handheld-Geräten mindestens einen linearen Resonanten enthalten Bedienelement:
- [7.10/H]* SOLLTEN den haptischen Auslöser in der X-Achse bewegen. (links-rechts) im Hochformat.
Implementierungen von Handheld-Geräten mit haptischem Bedienelement auf der X-Achse Linear Resonant Actuator (LRA) können sie:
- [7,10/H]* SOLLTEN die Resonanzfrequenz der X-Achse haben. LRA muss 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:
Implementierungen von Handheld-Geräten MÜSSEN die folgende Videodecodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:
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
, undACTION_CREATE_DOCUMENT
Intents entsprechend der Beschreibung in den SDK-Dokumenten und bieten der Nutzerfreundlichkeit um über dieDocumentsProvider
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 auftrue
in der Zeile mit den Antworten festgelegt, die vonNotification.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 eineMediaStyle
-Benachrichtigung mit einemMediaSession
-Token.
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 IntentACTION_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ürtrue
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
undControl
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 vomControl
bereitgestellten Feldern 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
undControl
Control.isAuthRequired
API verwenden.
Umgekehrt gilt: Wenn solche Steuerungen nicht in Handheld-Implementierungen implementiert sind, Sie:
- [3.8.16/H-2-1] MÜSSEN
null
melden fürControlsProviderService
undControl
APIs - [3.8.16/H-2-2] MUSS die Funktion deklarieren
android.software.controls
melden und legen Sie dafürfalse
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 eine Warnung, dass der Inhalt kopiert wurde). 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 undandroid.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 Implementierung von Handheld-Geräten eine Aufteilungsfunktion, mithilfe der Aktivitätseinbettung:
- [3.2.3.1/ H-1-1]
MUSS eine Aktivität haben, die den
Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY, wenn die Aufteilungsfunktion aktiviert ist. Die Aktivität MUSS durch
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
geschützt werden und MÜSSEN MÜSSEN Aktivität des Intents starten, der geparst wird von Einstellungen#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
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 ein Nutzerangebot in
Das Menü „Einstellungen“ mit der Möglichkeit, eine App zu beenden, in der ein Vordergrund ausgeführt wird
und zeigt alle Apps mit aktiven Diensten im Vordergrund sowie die
Dauer der einzelnen Dienste seit dem Start, wie im SDK beschrieben
Dokument.
- Einige Apps KÖNNEN vom Beenden oder Eintragen in einer solchen wie im SDK-Dokument beschrieben bietet.
2.2.5 Sicherheitsmodell
Implementierungen von Handheld-Geräten:
- [9.1/H-0-1] MÜSSEN Drittanbieter-Apps Zugriff auf
über die Berechtigung
android.permission.PACKAGE_USAGE_STATS
und einen für Nutzer zugänglichen Mechanismus bereitzustellen, mit dem der Zugriff auf solche Apps Antwort aufandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
Nutzerabsicht verstehen.
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-, SHA1- 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. Open-Source-Code 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.
- [9.11/H-0-5] MUSS die Schlüsselattestierung unterstützen, wenn die Der Attestierungssignaturschlüssel wird durch sichere Hardware geschützt und die Signatur ist auf sicherer Hardware ausgeführt werden. Die Signaturschlüssel der Attestierung MÜSSEN freigegeben werden auf einer ausreichend großen Anzahl von Geräten, um zu verhindern, dass die Schlüssel verwendet werden. als Gerätekennungen. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel, es sei denn, mindestens 100.000 Einheiten einer SKU produziert wurden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, Schlüssel KANN für je 100.000 Einheiten verwendet werden.
- [9/H-0-1] MÜSSEN die Parameter „android.hardware.security.model.compatible“ .
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 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.
Android unterstützt VoiceInteractionService über die System-API einen Mechanismus zur Sichere Hotword-Erkennung, die ständig aktiviert ist, aber keine Mikrofonzugriffserkennung anzeigt
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 an das System oder ContentCaptureService
- [9.8/H-1-2] MÜSSEN sicherstellen, dass der Hotword-Erkennungsdienst
Audiodaten oder Daten, die vom Mikrofon an den Systemserver über
HotwordDetectionService
API oderContentCaptureService
durchContentCaptureManager
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] DARF NICHT mehr als 100 Byte an Nicht-Audiodaten zulassen. die bei jedem erfolgreichen Hotword vom Hotword-Erkennungsdienst übertragen werden. 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, um die Sicherheit zu überprüfen 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 Das erfolgreiche Hotword-Ergebnis wird an die Stimme übermittelt. oder eine ähnliche Entität.
- [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
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.
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.
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
Implementierungen von Handheld-Geräten (* Nicht zutreffend für Tablets):
- Perfetto
- [6.1/H-0-2]* MUSS eine
/system/bin/perfetto
-Angabe verfügbar machen Binärdatei, die der cmdline entspricht Perfetto-Dokumentation. - [6.1/H-0-3]* Das Perfetto-Binärprogramm MUSS akzeptiert werden als Geben Sie eine protobuf-Konfiguration ein, die dem in Perfetto-Dokumentation.
- [6.1/H-0-4]* Das Perfetto-Binärprogramm MUSS schreiben als einen protobuf-Trace ausgeben, der dem in Perfetto-Dokumentation.
- [6.1/H-0-5]* MÜSSEN über das Perfetto angeben. binär, mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen.
- [6.1/H-0-6]* Der perfetto verfolgte Daemon MUSS
standardmäßig aktiviert (Systemeigenschaft
persist.traced.enable
).
- [6.1/H-0-2]* MUSS eine
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.S
zurückgeben
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- MÜSSEN die in Android 12 CDD aufgeführten Medienanforderungen erfüllen Abschnitt 2.2.7.1.
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.T
zurückgeben
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- [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()
undVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] MUSS 6 Instanzen von Hardware-Videodecodersitzungen unterstützen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination, die ausgeführt wird gleichzeitig bei 1080p-Auflösung bei 30 fps.
- [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()
undVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] MUSS 6 Instanzen von Hardware-Video-Encoder unterstützen Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination bei einer Auflösung von 1080p bei 30 fps.
- [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
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] MUSS 6 Instanzen von Hardware-Videodecoder und -hardware unterstützen Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebigen Codec die gleichzeitig mit einer Auflösung von 1080p bei 30 fps läuft.
- [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 sie unter Last sind. Hier wird die Last als gleichzeitige Auflösung von 1080 bis 720p definiert Video-Transcodierungssitzung mit Hardware-Video-Codecs zusammen mit dem Initialisierung von 1080p-Audio-/Videoaufnahmen. Für den Dolby Vision-Codec Die Latenz der Codec-Initialisierung 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 einer Bitrate von 128 kbit/s 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.
- [5.1/H-1-9] MUSS zwei Instanzen eines sicheren Hardware-Videodecoder unterstützen Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination gleichzeitig bei 1080p-Auflösung bei 30 fps.
- [5.1/H-1-10] MUSS drei Instanzen eines nicht sicheren Hardware-Videodecoder unterstützen Sitzungen zusammen mit einer Instanz einer sicheren Hardware-Videodecoder-Sitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination mit einer Auflösung von 1080p bei 30 fps.
- [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 Video-Transcodierungssitzung 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.
- [5.1/H-1-14] MÜSSEN AV1-Hardwaredecoder Main 10, Level 4.1 unterstützen.
- [5.1/H-SR-1] WIRD UNBEDINGT ZUR Unterstützung von Filmkörnung für AV1-Hardware empfohlen Decoder
- [5.1/H-1-15] MUSS mindestens einen Hardware-Videodecoder haben, der 4K60 unterstützt.
- [5.1/H-1-16] MUSS mindestens einen Hardware-Video-Encoder haben, der 4K60 unterstützt.
- [5.3/H-1-1] DARF NICHT mehr als 1 Frame in 10 Sekunden fallen (d.h.weniger als 0,167 % Frame-Abfall) bei einer Videositzung mit 1080p und 60 fps unter Last aus. Auslastung ist definiert als gleichzeitige Videoübertragung zwischen 1080 und 720p mit Hardware-Video-Codecs und einer 128 kbit/s AAC-Audiowiedergabe.
- [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. Die Last ist definiert als gleichzeitige reine Videotranscodierungssitzung mit 1080p bis 720p über Hardware Video-Codecs sowie eine AAC-Audiowiedergabe mit 128 kbit/s.
- [5.6/H-1-1] MUSS eine Tap-to-Ton-Latenz von maximal 80 Millisekunden haben mit dem Tap-to-Tone-Test von OboeTester oder dem Tap-to-Tone-Test von CTS Verifier.
- [5.6/H-1-2] MÜSSEN eine Umlauf-Audiolatenz von maximal 80 Millisekunden haben über mindestens einen unterstützten Datenpfad.
- [5.6/H-1-3] MÜSSEN bei einer Stereoausgabe über 3,5 mm Audio mindestens 24 Bit unterstützen
Anschlussbuchsen, falls vorhanden, und über USB-Audio, wenn dies durch den
für niedrige Latenz- und Streaming-Konfigurationen. Für Niedrige
Latenzkonfiguration angezeigt wird, sollte AAudio von der App mit niedriger Latenz verwendet werden.
Callback-Modus an. Für Streaming
Konfiguration muss die App einen Java-Audiotrack verwenden. In den beiden unteren
Latenz- und Streaming-Konfigurationen festlegen, sollte die HAL-Ausgabesenke
entweder
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
oderAUDIO_FORMAT_PCM_FLOAT
für die Zielausgabe Format. - [5.6/H-1-4] MÜSSEN USB-Audiogeräte mit mindestens 4 Kanälen unterstützen (wird von DJ verwendet) Controller für die Vorschau von Songs.)
- [5.6/H-1-5] MÜSSEN klassenkonforme MIDI-Geräte unterstützen und MIDI deklarieren Funktions-Flag.
- [5.7/H-1-2] MUSS
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
mit die unten aufgeführten Funktionen zur Inhaltsentschlüsselung nutzen.
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 |
2.2.7.2 Kamera
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.S
zurückgeben
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- MÜSSEN die unter Android 12 CDD aufgeführten Kameraanforderungen erfüllen Abschnitt 2.2.7.2.
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.T
zurückgeben
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- [7.5/H-1-1] MUSS eine primäre Rückkamera mit einer Auflösung von mindestens 12 Megapixel, die eine Videoaufnahme mit 4K bei 30 fps unterstützen Die primäre „Kamera auf der Rückseite“ ist die Kamera auf der Rückseite mit der niedrigsten Kamera-ID.
- [7.5/H-1-2] MUSS eine primäre Frontkamera mit einer Auflösung von mindestens 5 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
unterstützen als MindestensFULL
für hinteres Hauptgeschäft undLIMITED
oder höher für Hauptleitung 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] MÜSSEN eine JPEG-Aufnahmelatenz von „camera2“ < 1.000 ms für 1080p-Auflösung, gemessen durch Leistungstest der CTS-Kamera unter ITS (3.000 K) für beide primären Kameras.
- [7.5/H-1-6] MÜSSEN eine 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 undandroid.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] MÜSSEN gleichzeitiges Front-Back-Streaming auf der primären Instanz implementieren. Kameras.
- [7.5/H-1-12] MUSS
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
unterstützen für die primäre Rückkamera. - [7.5/H-1-13] MUSS die Funktion
LOGICAL_MULTI_CAMERA
für die primäre Datenbank unterstützen Kamera auf der Rückseite, wenn mehr als eine RGB-Rückkamera vorhanden ist. - [7.5/H-1-14] MUSS die
STREAM_USE_CASE
-Funktion für beide primären Front- und Hauptkamera auf der Rückseite.
2.2.7.3 Hardware
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.S
für
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- MÜSSEN die in Android 12 CDD aufgeführten Hardwareanforderungen erfüllen Abschnitt 2.2.7.3.
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.T
für
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- [7.1.1.1/H-2-1] MUSS eine Bildschirmauflösung von mindestens 1080p haben.
- [7.1.1.3/H-2-1] MUSS eine Bildschirmdichte von mindestens 400 dpi haben.
- [7.6.1/H-2-1] MUSS mindestens 8 GB physischen Arbeitsspeicher haben.
2.2.7.4 Leistung
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.S
für
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- MÜSSEN die in Android 12 CDD aufgeführten Leistungsanforderungen erfüllen Abschnitt 2.2.7.4.
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.T
für
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- [8.2/H-1-1] MÜSSEN eine sequentielle Schreibleistung von mindestens 125 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 40 MB/s gewährleisten.
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] MÜSSEN Support für Spiele
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:
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
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 Wähle die maximale Auflösung aus, die bei 50 Hz oder 60 Hz unterstützt wird Aktualisierungsrate.
- [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
undandroid.hardware.type.television
. - [3.2.3.1/T-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/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.
Implementierungen von Fernsehgeräten:
- [3.12/T-0-1] MUSS das TV Input Framework unterstützen.
2.3.4 Leistung und Leistung
- [8.1/T-0-1] Konsistente Framelatenz. Inkonsistente Frame-Latenz oder 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.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-, SHA1- 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. Open-Source-Code 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.
- [9.11/T-0-4] MUSS die Schlüsselattestierung unterstützen, wenn die Der Attestierungssignaturschlüssel wird durch sichere Hardware geschützt und die Signatur ist auf sicherer Hardware ausgeführt werden. Die Signaturschlüssel der Attestierung MÜSSEN freigegeben werden auf einer ausreichend großen Anzahl von Geräten, um zu verhindern, dass die Schlüssel verwendet werden. als Gerätekennungen. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel, es sei denn, mindestens 100.000 Einheiten einer SKU produziert wurden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, Schlüssel KANN für je 100.000 Einheiten verwendet werden.
- [9/T-0-1] MÜSSEN die Parameter „android.hardware.security.model.compatible“ .
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 aber 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
Implementierungen von Fernsehgeräten:
- Perfetto
- [6.1/T-0-1] MUSS eine
/system/bin/perfetto
-Angabe verfügbar machen Binärdatei, die der cmdline entspricht Perfetto-Dokumentation. - [6.1/T-0-2] Das Perfetto-Binärprogramm MUSS akzeptiert werden als Geben Sie eine protobuf-Konfiguration ein, die dem in Perfetto-Dokumentation.
- [6.1/T-0-3] Das Perfetto-Binärprogramm MUSS schreiben als einen protobuf-Trace ausgeben, der dem in Perfetto-Dokumentation.
- [6.1/T-0-4] MÜSSEN im Rahmen des Perfettos angeben. binär, mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen.
- [6.1/T-0-1] MUSS eine
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 die Implementierung der Uhr einen GPS-/GNSS-Empfänger umfasst und
ü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, 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 aber mit der AOSP-Implementierung der Kontrollen übereinstimmen. , um zu aktivieren /deaktivieren, dass andere Nutzer auf die Sprachanrufe und SMS zugreifen können.
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.
[7.2.3/A-0-1] MÜSSEN die Home-Funktion bereitstellen und KANN die Funktion die Funktionen „Zurück“ und „Letzte“ bereitstellen.
[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
undPARKING_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.
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 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:
- Telefonanrufe über Hands-Free Profile (HFP).
- Medienwiedergabe über das Audio Distribution Profile (A2DP)
- Steuerung der Medienwiedergabe über das Remote Control Profile (AVRCP)
- Kontaktfreigabe über das Phone Book Access Profile (PBAP)
[7.4.3/A-SR-1] wird dringend zum Support empfohlen. Message Access Profile (MAP).
[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.
Eine Außenkamera ist eine Kamera, die Aufnahmen von außerhalb des Geräts macht. implementiert werden, z. B. bei der Rückkamera.
Implementierungen von Automobilgeräten:
- SOLLTEN eine oder mehrere Außenkameras enthalten.
Wenn die Implementierung von Automobil-Geräten eine Außenkamera umfasst, eine Kamera haben:
- [7.5/A-1-1] DÜRFEN KEINE Außenkameras zugänglich machen über die Android Camera APIs, es sei denn, sie mit den Hauptanforderungen der Kamera.
[7.5/A-SR-1] wird dringend empfohlen, nicht zu drehen oder Kameravorschau horizontal spiegeln.
[7.5/A-SR-2] wird dringend empfohlen, eine Lösung zu finden. mindestens 1,3 Megapixel haben.
SOLLTEN entweder über Fixfokus- oder EDOF-Hardware verfügen.
KÖNNEN in der App entweder Hardware-Autofokus oder Software-Autofokus implementiert werden. Kameratreiber.
Wenn die Implementierung von Fahrzeugen eine oder mehrere Kameras mit Außenansicht umfasst, und den EVS-Dienst (Exterior View System) laden, dann gilt für eine solche Kamera Folgendes:
- [7.5/A-2-1] DÜRFEN NICHT das Modell drehen oder horizontal spiegeln. Kameravorschau.
Implementierungen von Automobilgeräten:
- KÖNNEN eine oder mehrere Kameras enthalten, die für Drittanbieter erhältlich sind Anwendungen.
Wenn die Implementierung von Fahrzeugen mindestens eine Kamera umfasst, Anwendungen von Drittanbietern zur Verfügung stehen, geschieht Folgendes:
- [7.5/A-3-1] MÜSSEN das Funktions-Flag melden.
android.hardware.camera.any
- [7.5/A-3-2] DARF die Kamera nicht als Systemkamera.
- KANN externe Kameras unterstützen, wie in Abschnitt 7.5.3 beschrieben.
- KANN Funktionen wie Autofokus enthalten, die für die Rückkamera verfügbar sind. wie in Abschnitt 7.5.1 beschrieben.
Implementierungen von Automobilgeräten:
[7.6.1/A-0-1] MUSS mindestens 4 GB an nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet).
[7.6.1/A] SOLLTEN die Datenpartition formatieren. um die Leistung und Langlebigkeit von Flash-Speicher zu verbessern. mit
f2fs
-Dateisystem.
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
.
Bei Automotive-Geräten mit 64-Bit-Implementierungen:
[7.6.1/A-2-1] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 816 MB groß sein, wenn eine der folgenden Dichten verwendet wird:
- 280 dpi oder niedriger auf kleinen/normalen Bildschirmen
- LDPI oder niedriger auf sehr großen Bildschirmen
- mdpi oder niedriger auf großen Bildschirmen
[7.6.1/A-2-2] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 944 MB groß sein, wenn eine der folgenden Dichten verwendet wird:
- xhdpi oder höher auf kleinen/normalen Bildschirmen
- HDPI oder mehr auf großen Bildschirmen
- mdpi oder höher auf extragroßen Bildschirmen
[7.6.1/A-2-3] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerbereich MÜSSEN mindestens 1.280 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
[7.6.1/A-2-4] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 1.824 MB groß sein, wenn eine der folgenden Dichten verwendet wird:
- 560 dpi oder höher auf kleinen/normalen Bildschirmen
- Mindestens 400 dpi auf großen Bildschirmen
- xhdpi oder höher auf extragroßen Bildschirmen
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.
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
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:
Implementierungen für Automobilgeräte MÜSSEN die folgende Videodecodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:
Implementierungen für Automobilgeräte werden UNBEDINGT empfohlen, um die folgende Videodecodierung:
- [5.3/A-SR-1] H.265 HEVC
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 Anwendungen oder Dienstkomponenten mit Intent-Handlern für alle 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[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
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 demCAR_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
undERROR_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
undCONTENT_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 der
CAR_INTENT_ACTION_MEDIA_TEMPLATE
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 Kernelmoduluid_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:
- Der Akku ist leer.
- Es sind keine inaktiven Jobs geplant.
- Der Fahrer beendet den Garagenmodus.
- [8.4/A-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/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 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 auf die Apps zugreifen, die die in den Abschnitt 9.1 Berechtigungen mit der CDD-Kennung [C-3-X].
- [9.8.2/A-2-2] DARF die Kameraanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
Implementierungen von Automobilgeräten:
- [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-, SHA1- 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.
- [9.11/A-0-4] MUSS die Schlüsselattestierung unterstützen, wenn die Der Attestierungssignaturschlüssel wird durch sichere Hardware geschützt und die Signatur ist auf sicherer Hardware ausgeführt werden. Die Signaturschlüssel der Attestierung MÜSSEN freigegeben werden auf einer ausreichend großen Anzahl von Geräten, um zu verhindern, dass die Schlüssel verwendet werden. als Gerätekennungen. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel, es sei denn, mindestens 100.000 Einheiten einer SKU produziert wurden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, Schlüssel KANN für je 100.000 Einheiten verwendet werden.
- [9/A-0-1] MÜSSEN die Parameter „android.hardware.security.model.compatible“ .
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
Implementierungen von Automobilgeräten:
- Perfetto
- [6.1/A-0-1] MUSS eine
/system/bin/perfetto
-Angabe verfügbar machen Binärdatei, die der cmdline entspricht Perfetto-Dokumentation. - [6.1/A-0-2] Das Perfetto-Binärprogramm MUSS akzeptiert werden als Geben Sie eine protobuf-Konfiguration ein, die dem in Perfetto-Dokumentation.
- [6.1/A-0-3] Das Perfetto-Binärprogramm MUSS schreiben als einen protobuf-Trace ausgeben, der dem in Perfetto-Dokumentation.
- [6.1/A-0-4] MÜSSEN über das Zusatzsymbol angeben. binär, mindestens die in der Perfetto-Dokumentation beschriebenen Datenquellen.
- [6.1/A-0-1] MUSS eine
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.
USB-Peripheriemodus (Abschnitt 7.7.1)
Wenn Tablet-Implementierungen einen USB-Port enthalten, der Peripheriegeräte unterstützt haben sie folgende Möglichkeiten:
- [7.7.1/Tab] KANN die Android Open Accessory (AOA) API implementieren.
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 Verhaltensweisen aller dokumentierten APIs, die durch das Android SDK offengelegt werden oder eine beliebige API mit der Markierung „@SystemApi“ in den vorgelagerten Android-Versionen 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.
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 aktualisiert. 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 DiensteExtServices
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:- 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>
zuorg.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 umfasst auch ein erhebliches, reines „Soft-API“ nur zur Laufzeit, in Form eines solchen 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 13. |
SDK VERSION | Die Version des derzeit ausgeführten Android-Systems in einem Format Anwendungscode von Drittanbietern zugänglich sein. Bei Android 13 Dieses Feld MUSS den Ganzzahlwert 13_INT haben. |
VERSION.SDK_INT | Die Version des derzeit ausgeführten Android-Systems in einem Format Anwendungscode von Drittanbietern zugänglich sein. Bei Android 13 Dieses Feld MUSS den Ganzzahlwert 13_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 Verwenden Sie dieses Feld, um die spezifische Überarbeitung der Leiterplatte anzugeben auf dem Gerät. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden und dem regulären Ausdruck "^[a-zA-Z0-9_-]+$" entsprechen. |
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 regulärer 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)/ Beispiel: acme/meinprodukt/ 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 an das spezifische Format in dieses Feld ein, außer dass es NICHT null oder der leere String ("") sein darf. |
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 DARF 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 Der reguläre Ausdruck "^([0-9A-Za-z ._/+-]+)$" DARF NICHT beginnen oder mit einem Leerzeichen enden und DARF NICHT gleich „unbekannt“ 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 dem regulären Ausdruck "^[a-zA-Z0-9_-]+$" entsprechen. 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 dem regulären Ausdruck "^[a-zA-Z0-9._-]+" entsprechen, 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: user, user, 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. |
SICHERHEITSPATCH | 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 Öffentliches Sicherheitsbulletin für Android oder in der Android-Sicherheitshinweise, z. B. „2015-11-01“. |
BASIS_OS | Wert, der den Parameter FINGERPrint des Builds darstellt und in 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 einem visuell lesbaren 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 , mit Ausnahme von Einstellungen, die von Drittanbieteranwendungen überschrieben werden sollen. 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 die Deaktivierung des Nutzers „Auswahl“, 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 die Angabe des Daten-URI "http://www.android.com" ist spezifischer als der 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 versucht werden, alle 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 zu überprüfen. Ist dies bei einer Geräteimplementierung der Fall, MÜSSEN sie den Parameter Überschreibungen für nutzerspezifische Per-URI-Muster im Einstellungsmenü.
- Nutzer MUSS dem Nutzer in den Einstellungen Einstellungen für App-Links wie folgt zur Verfügung stellen:
folgt:
- [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 mitPhoneAccounts
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 denandroid.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 & 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 & 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
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 MUSS nur vorinstallierte Android-Apps möglich sein
zur Verarbeitung der folgenden Intents
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, undMediaStore.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 (oder dem System zu erlauben, es abzulehnen).[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 & 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 undAutofillManager
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.
[C-17-1] [Übernommen mit 2.2.3]
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.
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 .
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 weiter 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
undandroid.os.Build.SUPPORTED_64_BIT_ABIS
Parameter, jeweils durch Kommas getrennt Liste der ABIs, sortiert vom größten bis zum am wenigsten bevorzugten. [C-0-6] MÜSSEN mithilfe der oben genannten Parameter eine Teilmenge der und DÜRFEN KEINE ABIs melden, die nicht auf der Liste stehen.
armeabi
(wird vom NDK nicht mehr als Ziel unterstützt)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] MÜSSEN alle folgenden Bibliotheken, die native APIs bereitstellen, für 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 die Vulkan 1.0-Kernfunktion exportieren. sowie den
VK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
undVK_KHR_get_physical_device_properties2
-Erweiterungen über dielibvulkan.so
. Beachten Sie, dass zwar alle Symbole vorhanden sein MÜSSEN, Abschnitt 7.1.4.2 ausführlicher 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 vorgelagertes Android-Open-Source-Projekt
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 alsarmeabi
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
13 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:
- [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:
- [C-0-4] Sie MÜSSEN die Ausführung von Callbacks beenden, die vom
App, um Ausgaben vom
GnssMeasurement
zu empfangen undGnssNavigationMessage
. - [C-0-5] MÜSSEN die Häufigkeit von Updates, die
die der App über die
LocationManager
zur Verfügung gestellt werden, API-Klasse oderWifiManager.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"
erforderlichprotectionLevel
Berechtigung haben oder auf der Ausnahmeliste stehen. - [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-4] Sie MÜSSEN die Ausführung von Callbacks beenden, die vom
App, um Ausgaben vom
- [C-0-11] Geräte MÜSSEN die folgenden Sicherheitsanbieter als erste
sieben Array-Werte aus
Security.getProviders()
in der angegebenen Reihenfolge und mit den angegebenen Namen (wie vonProvider.getName()
) und Klassen, es sei denn, die App hat die Liste überinsertProviderAt()
oderremoveProvider()
. Geräte KANN nach der angegebenen Liste von Anbietern weitere Anbieter zurückgeben. weiter unten.- AndroidNSSP –
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL –
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider –
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround –
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC –
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE –
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore –
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP –
Die obige Liste ist nicht vollständig. 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 implementieren, MUSS aber einen Bezug zu den Auswirkungen der App auf den Systemzustand haben. 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 definiert durch explizite Nutzerinteraktion über 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 diePackageManager
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ürShortcutManager.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ürShortcutManager.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 auftrue
festgelegt. Es wird kein App-Symbol-Badge-Schema angezeigt, wenn alle der Benachrichtigungskanäle der App haben den Wert auffalse
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()
undNotification.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 Funktionen 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ürAppWidgetManager.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. Enthält eine Geräteimplementierung beispielsweise einen Vibrationsalarm, MUSS diese 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 in der Open-Source-Referenzimplementierung angegeben.
- [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 werden Nutzern UNBEDINGT empfohlen, 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 undimportance:high
Benachrichtigungen.
Wenn Geräteimplementierungen conversation notifications
unterstützen
und die App liefert die erforderlichen Daten
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. 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 den einzelnen installierten Drittanbieter-Apps, es sei denn, sie stammen aus 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 benutzerdefinierten und vordefinierten Regeln erstellt werden.
- [C-1-3] MUSS die
suppressedVisualEffects
berücksichtigen Werte, die überNotificationManager.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.
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:
- 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 IntentACTION_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 den
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, mit dem in Apps Stile angewendet werden können. einer gesamten Aktivität oder einer App geöffnet.
Android umfasst ein „Holo“ und „Material“ Designfamilie als eine Reihe definierter Stile für Anwendungsentwickler:innen, die den Anforderungen 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 die Designfamilie "Material" unterstützen und DÜRFEN KEINE der folgenden Elemente ändern: 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 Farbpalettenpaletten gemäß AOSP generieren. Dokumentation von
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(sieheandroid.theme.customization.system_palette
undandroid.theme.customization.theme_style
.[C-1-5] MÜSSEN dynamische Farbtonpaletten mithilfe von Farbdesignstilen generieren. in
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
aufgezählt Dokumentation (sieheandroid.theme.customization.theme_styles
), nämlichTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
„Quellfarbe“ zum Generieren dynamischer Farbtonpaletten beim Senden mit
android.theme.customization.system_palette
(wie in denSettings.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 Designfamilie „Gerätestandard“ 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 .
- [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.
- [C-1-2] MÜSSEN das Verhalten der Bildschirmfixierung implementieren und stellen dem Nutzer ein Einstellungsmenü zur Verfügung, in dem er die Funktion aktivieren und deaktivieren kann.
- 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, an Miniaturansichten 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 Geräteimplementierungen einen Hardwaresensor (z.B. GPS) beinhalten, der 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:
- 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 verschiedene Familien-Emojis wie 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-konforme Schriftarten, allgemein als "Zawgyi" bezeichnet, für die Darstellung 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 DateiAndroidManifest.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 Mehrfenstermodi als „Bild im Bild“.
- 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 SOLLTEN einige Inhalte davon angezeigt werden, wenn die Launcher-App das Fenster im Fokus ist.
- [C-2-3] MUSS die deklarierten
AndroidManifestLayout_minWidth
einhalten undAndroidManifestLayout_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 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 deklariertandroid:resizeableActivity
undandroid: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
undAndroidManifestLayout_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.
- Geräte mit dem Configuration.uiMode, der nicht festgelegt ist
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 Flags für Display-Aussparungen berücksichtigen, die von der App
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
Android bietet Funktionen, die sicherheitsbewusste Anwendungen Geräteverwaltungsfunktionen auf Systemebene, z. B. das Erzwingen von Passwörtern oder eine Remote-Löschung durchführen, Android Device Administration API
Wenn bei allen Implementierungen die gesamte Geräteverwaltung implementiert ist die in der Android SDK-Dokumentation definiert sind,
- [C-1-1] MUSS
android.software.device_admin
deklarieren. - [C-1-2] MÜSSEN die Bereitstellung von Geräteinhabern unterstützen, wie in den Abschnitt 3.9.1 und Abschnitt 3.9.1.1.
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:
- Wenn bei der Geräteimplementierung
weder Nutzer noch
konfiguriert sind, geschieht Folgendes:
- [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-TypMIME_TYPE_PROVISIONING_NFC
- [C-1-8] MUSS die Aktion 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.
- [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
- Wenn bei der Geräteimplementierung
oder
Nutzerdaten verwenden können, werden:
- [C-1-7] DARF keine DPC-Anwendung als Geräteinhaber-App registrieren noch mehr.
- Wenn bei der Geräteimplementierung
weder Nutzer noch
konfiguriert sind, geschieht Folgendes:
- [C-1-2] MUSS einen entsprechenden Offenlegungshinweis anzeigen (wie in AOSP angegeben) und vor der Veröffentlichung der App die Einwilligung des Endnutzers einholen. als Geräteinhaber festgelegt, es sei denn, das Gerät wurde programmatisch konfiguriert für den Demomodus für den Einzelhandel vor der Endnutzerinteraktion auf dem Bildschirm.
Wenn in der Geräteimplementierung android.software.device_admin
deklariert ist, aber auch
eine proprietäre Lösung zur Geräteverwaltung und einen Mechanismus bereitzustellen,
eine in der Lösung konfigurierte Anwendung als „Geräteinhaber“ hochstufen
Äquivalent“ den standardmäßigen „Geräteinhaber“ wie sie vom standardmäßigen Android-
DevicePolicyManager
APIs:
- [C-2-1] MÜSSEN über einen Prozess verfügen, mit dem geprüft wird, ob die betreffende App der beworben wird, gehört zu einer legitimen Unternehmensgeräteverwaltung. -Lösung und wurde in der proprietären Lösung konfiguriert. um die entsprechenden Rechte als Geräteinhaber zu haben.
- [C-2-2] MUSS dieselbe Offenlegung zur Einwilligung des AOSP-Geräteinhabers anzeigen wie in
Vorgang initiiert von
android.app.action.PROVISION_MANAGED_DEVICE
bevor Sie die DPC-Anwendung als "Geräteinhaber" registrieren. - [C-2-3] DÜRFEN die Einwilligung NICHT hartcodieren oder verhindern, die Nutzung anderer Apps von Geräteeigentümern.
3.9.1.2 Verwaltete Bereitstellung von Profilen
Wenn in Geräteimplementierungen android.software.managed_users
deklariert wird, gilt Folgendes:
[C-1-1] MÜSSEN die APIs implementieren. sodass eine DPC-Anwendung (Device Policy Controller) zur Inhaber eines neuen verwalteten Profils
[C-1-2] Der Bereitstellungsprozess für verwaltete Profile, also der vom DPC mithilfe der android.app.action.PROVISION_MANAGED_PROFILE) oder der Plattform), der Zustimmungsbildschirm und die Nutzererfahrung MÜSSEN mit den der AOSP-Implementierung.
[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 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 stehen für verwaltete Anwendungen und Widgets sowie andere gekennzeichnete UI-Elemente. 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 senden oder umgekehrt, wenn dies ü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:
- 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.
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 verwenden.
- Geräteimplementierungen MÜSSEN die
- 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
gibttrue
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 Anforderungen an Rollen zur Verwaltung von Geräterichtlinien
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: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 registriertenAccessibilityService
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.
3:12. TV-Eingabe-Framework
Das Android Television Input Framework (TIF) vereinfacht die Bereitstellung von auf Android TV-Geräten übertragen. TIF stellt eine Standard-API zum Erstellen Eingabemodule, die Android TV-Geräte steuern.
Wenn Geräteimplementierungen TIF unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die Plattformfunktion
android.software.live_tv
deklarieren. - [C-1-2] MUSS alle TIF APIs unterstützen, sodass eine Anwendung, die diesen APIs und den TIF-basierten Eingaben von Drittanbietern auf dem Gerät installiert und verwendet werden kann.
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()
odergetIconUri()
erhaltenen Symbole und Titel deutlich anzeigen. abgerufen übergetTitle()
, wie inMediaDescription
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
oderKEYCODE_MEDIA_PLAY_PAUSE
alsKEYCODE_MEDIA_NEXT
fürMediaSession.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:
- 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. Für 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.
Verbindung zu 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. - [C-1-3] MÜSSEN Nutzern Angebote zur Auswahl/Bestätigung einer Companion-Anzeige zur Verfügung gestellt werden. Gerät vorhanden und betriebsbereit ist.
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 in diesem Zusammenhang NICHT ändern. .
3:18. Kontakte
Android enthält 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
dem Gerät und nicht mit einem Konto im AccountManager verknüpft. Dies sind
erstellt 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 vonContactsContract.RawContacts.getLocalAccountName
- [C-1-2] Die
ACCOUNT_TYPE
, des benutzerdefinierten lokalen Kontos MÜSSEN vonContactsContract.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
undACCOUNT_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 ParameterCALLER\_IS\_SYNCADAPTER
festgelegt wurde. auf „false“ gesetzt oder nicht angegeben.
4. Kompatibilität der App-Paketerstellung
Implementierungen auf Geräten:
[C-0-1] MÜSSEN in der Lage sein, Android-APK-Dateien folgendermaßen zu installieren und auszuführen: mit dem Tool „aapt“ generiert, das 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-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 die
DELETE_PACKAGE
dokumentiert Berechtigung. Die einzige Ausnahme ist die App, die die Systempaketprüfung verarbeitet, PAKET_ERFORDERLICH_BESTÄTIGUNG Intent und der Speichermanager-App, die ACTION_MANAGE_STORAGE verarbeitet Nutzerabsicht verstehen.[C-0-5] MÜSSEN über eine Aktivität verfügen,
android.settings.MANAGE_UNKNOWN_APP_SOURCES
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. oderandroid:targetSdkVersion
auf 24 oder niedriger eingestellt haben. - Der Nutzer MUSS die Berechtigung erhalten haben, Apps aus unbekannten Quellen.
- Es MÜSSEN die
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ürstartActivityForResult()
zurück. 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 vorgelegt.[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-APIPackageManager.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,
- 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 Software zur Verfügung gestellt. 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 Audio-Encoder 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
undKEY_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
undKEY_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 derandroid.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. |
|
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. |
|
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. |
|
AAC ELD (Optimierte AAC mit geringer Verzögerung) | Unterstützung für Mono-/Stereoinhalte mit Standardabtastraten von 16 bis 48 kHz. |
|
Logo: USAC | Unterstützung für Mono-/Stereoinhalte mit Standardabtastraten 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 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. |
|
MP3 | Mono/Stereo, 8–320 Kbit/s konstant (CBR) oder variable Bitrate (VBR) |
|
MIDI | MIDI-Typ 0 und 1. DLS Version 1 und 2. XMF und XMF für Mobilgeräte Unterstützung für Klingeltonformate RTTTL/RTX, OTA und iMelody |
|
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. |
|
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. |
|
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
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
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 vonandroid.graphics.Bitmap
.
5.1.6. Details zu Image-Codecs
Format/Codec | Details | Unterstützte Dateitypen/Containerformate |
---|---|---|
JPEG | Base+progressiv | JPEG (JPG) |
GIF | GIF (.gif) | |
PNG | PNG (PNG) | |
BMP | BMP (BMP) | |
WebP | WebP (WebP) | |
Raw | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIFS | Bild, Bildersammlung, Bildsequenz | HEIF (.heif), HEIC (.heic) |
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
) bisCodecCapabilities
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
(entsprichtCOLOR_FormatYUV420Planar
) oderCOLOR_FormatYUV420PackedSemiPlanar
(entsprechend anCOLOR_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 VP8-Hardware-Codec verwendet werden, die 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
) bisCodecCapabilities
.[C-1-3] Video-Encoder und -Decodierer MÜSSEN mindestens einen Planar- oder semiplanares YUV420-Farbformat, 8:8:8:
COLOR_FormatYUV420PackedPlanar
(entsprichtCOLOR_FormatYUV420Planar
) oderCOLOR_FormatYUV420PackedSemiPlanar
(entsprichtCOLOR_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 |
|
|
H.264-AVC | Siehe Abschnitt 5.2 und 5.3 für weitere Informationen |
|
H.265 HEVC | Weitere Informationen finden Sie in Abschnitt 5.3. |
|
MPEG-2 | Profil "Main" |
|
MPEG-4 SP |
|
|
VP8 | Siehe Abschnitt 5.2 und 5.3 für weitere Informationen |
|
VP9 | Weitere Informationen finden Sie in Abschnitt 5.3. |
|
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 Multimedia-Beschleunigungs-API mit Low-Overhead.
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 Android Open Source Project (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 |
|
|
|
1920 x 1080 Pixel (außer MPEG4) | 3840 x 2160 Pixel (HEVC, VP9) |
- [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 ihn Drittanbieter-Apps:
- Über zwei gleitende Fenster NICHT mehr als 15% über der Bitrate liegen zwischen Intraframe-Intervallen (I-Frames)
- NICHT mehr als 100% über der Bitrate auf einem gleitenden Fenster liegen von 1 Sekunde.
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 Baseline-Profilebene 45 unterstützen.
- SOLLTEN für den unterstützten Encoder dynamisch konfigurierbare Bitraten unterstützen.
5.2.2 H.264
Wenn Geräteimplementierungen den H.264-Codec unterstützen, gilt Folgendes:
- [C-1-1] MUSS Baseline-Profilebene 3 unterstützen. Die Unterstützung für ASO (Arbitrary Slice Ordering), FMO (Flexible 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 Pixel | 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 Pixel | 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 Pixel | 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 unterstützen.
- SOLLTEN die HD-Codierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
- [C-SR-1] wird dringend empfohlen, HD-Codierungsprofile 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 Pixel | 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.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] MÜSSEN Baseline-Profillevel 30 und -Level 45 unterstützen.
5.3.3 MPEG-4
Bei Geräteimplementierungen mit MPEG-4-Decodierern gilt Folgendes:
- [C-1-1] MÜSSEN die einfache Profilebene 3 unterstützen.
5.3.4. H.264
Wenn Geräteimplementierungen H.264-Decoder unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die Hauptprofilebene 3.1 und das Basisprofil unterstützen. 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 Pixel | 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 Pixel | 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 Bildschirm des Geräts 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 Pixel | 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 Pixel | 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 Bildschirm des Geräts 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
:
- [C-1-1] MÜSSEN einen Dolby Vision-fähigen Extraktor bereitstellen.
- [C-1-2] MÜSSEN Dolby Vision-Inhalte auf dem Gerätebildschirm oder an einem Standard-Videoausgangsport (z.B. HDMI).
- [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, gilt Folgendes:
- [C-1-1] MUSS Profil 0 einschließlich 10-Bit-Inhalten unterstützen.
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
- oderAAudio
-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
, oderVOICE_PERFORMANCE
. Dies gilt auch für die entsprechenden Eingabevoreinstellungen inAAudio
, 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 dieAudioManager.getMicrophones()
API für aktiven AudioRecord mitMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
oderVOICE_PERFORMANCE
.
Ob die Geräteimplementierung die Aufzeichnung von Audio-Rohdaten 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
Aufnahme eines Audiostreams aus
AudioSource.VOICE_RECOGNITION
-Audio 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, die Amplitudenwerte im unteren 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 dieandroid.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 angeben. 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 App-Aufnahme mit einem beliebigenAudioSource
. - [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ürAudioSource.VOICE_COMMUNICATION
oderAudioSource.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
oderAudioSource.CAMCORDER
. Wenn Sie jedoch Eine App nimmt überAudioSource.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, sondern diejenige, mit der die zuletzt verwendeten Audio empfängt.
5.4.6. Mikrofonverstärkungspegel [verschoben zu 5.4.2]
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):
- 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
undEFFECT_TYPE_LOUDNESS_ENHANCER
-Implementierungen steuerbar über die Die AudioEffect-UnterklassenEqualizer
undLoudnessEnhancer
- [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-UnterklasseDynamicsProcessing
steuern. - SOLLTEN die
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
, Implementierungen mitEFFECT_TYPE_PRESET_REVERB
undEFFECT_TYPE_VIRTUALIZER
über dieAudioEffect
-UnterklassenBassBoost
steuerbar,EnvironmentalReverb
,PresetReverb
undVirtualizer
. - [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
von
AudioAttributes
und die Nutzung von Auto-Audio, wie inandroid.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 lückenlosen Audioinhalte zu kürzen die dasselbe Format haben, wie vom 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 den 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. Durchschnitt des absoluten Werts der Abweichungen vom Mittelwert für eine Reihe von Werten.
- Tap-to-Ton-Latenz. Die Zeit zwischen dem Antippen des Bildschirms und der ein durch das Tippen erzeugter Ton auf dem Lautsprecher zu hören ist.
Wenn in der Geräteimplementierung android.hardware.audio.output
deklariert ist, wird
MÜSSEN die folgenden Anforderungen erfüllen oder übertreffen:
- [C-1-1] Der von
AudioTrack.getTimestamp
und
AAudioStream_getTimestamp
auf +/- 2 ms genau ist. [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.
Wenn in Geräteimplementierungen android.hardware.audio.output
deklariert wird, sind sie
EMPFOHLEN, die folgenden Anforderungen zu erfüllen oder zu übertreffen:
- [C-SR-1] Latenz der Kaltausgabe über die Sprecherdaten von maximal 100 Millisekunden Pfad.
[C-SR-2] Die Tonwahl-Latenz beträgt maximal 80 Millisekunden.
[C-SR-4] Der Ausgabezeitstempel, der von AudioTrack.getTimestamp und
AAudioStream_getTimestamp
auf +/- 1 ms genau ist.
Wenn Geräteimplementierungen die oben genannten Anforderungen erfüllen, können Sie Kalibrierung bei Verwendung der AAudio Native Audio API für eine kontinuierliche Ausgabe Latenz und Kaltausgabelatenz für mindestens ein unterstütztes Audio Ausgabegerät, sind sie:
- [C-SR-5] EMPFOHLEN, Audio mit niedriger Latenz zu melden, indem Sie Folgendes erklären:
Funktions-Flag „
android.hardware.audio.low_latency
“. - [C-SR-6] EMPFOHLEN, die Anforderungen an niedrige Latenz zu erfüllen über die AAudio API.
- [C-SR-7] EMPFEHLUNG:
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
vonAAudioStream_getPerformanceMode()
, den vonAAudioStream_getFramesPerBurst()
zurückgegebenen Wert ist kleiner oder gleich dem vonandroid.media.AudioManager.getProperty(String)
zurückgegebenen Wert. für den Property-SchlüsselAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
Wenn Geräteimplementierungen die Anforderungen an Audio mit niedriger Latenz nicht erfüllen über die AAudio Native Audio API:
- [C-2-1] DÜRFEN KEINE Unterstützung für Audio mit niedriger Latenz melden.
Wenn Geräteimplementierungen android.hardware.microphone
enthalten,
MÜSSEN die folgenden Anforderungen für die Audioeingabe erfüllen:
[C-3-1] Begrenzen Sie den Fehler in Eingabezeitstempeln, wie von AudioRecord.getTimestamp oder
AAudioStream_getTimestamp
auf +/- 2 ms. „Fehler“ bedeutet hier die Abweichung vom richtigen Wert.[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.
Wenn Geräteimplementierungen android.hardware.microphone
enthalten, sind sie
EMPFOHLEN, die folgenden Anforderungen für die Audioeingabe zu erfüllen:
[C-SR-8] Kalteingabelatenz von maximal 100 Millisekunden über dem Mikrofon Datenpfad.
[C-SR-11] Begrenzen Sie den Fehler in Eingabezeitstempeln, wie von AudioRecord.getTimestamp oder
AAudioStream_getTimestamp
in +/- 1 ms.
Wenn in der Geräteimplementierung android.hardware.audio.output
und
android.hardware.microphone
:
- [C-SR-12] WIRD UNBEDINGT EMPFOHLEN, eine durchschnittliche Umlauflatenz zu haben 50 Millisekunden oder weniger über 5 Messungen mit einer mittleren absoluten Abweichung weniger als 10 Millisekunden über mindestens einen unterstützten Pfad
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:
siehe Abschnitt 5.1.8 und MPEG-2. Audio-Codecs:
|
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
- [C-1-2] MUSS die kontinuierliche Umlauf-Audiolatenz haben, wie in Abschnitt 5.6 Audiolatenz von 25 Millisekunden oder weniger über mindestens einen unterstützten Pfad.
- [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. - [C-1-5] MÜSSEN die Anforderungen an Latenzen und USB-Audioinhalte gemäß der
Natives AAudio
API und
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-6] MUSS eine Latenz für die kalte Ausgabe von 200 Millisekunden oder weniger haben.
- [C-1-7] MÜSSEN eine Kalteingabelatenz von maximal 200 Millisekunden haben.
- [C-1-8] MUSS eine durchschnittliche Tap-to-Ton-Latenz von 80 Millisekunden oder weniger haben über mindestens 5 Messungen über den Datenpfad zwischen Lautsprecher und Mikrofon.
- [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die im Abschnitt definierten Latenzen zu erfüllen 5.6 Audiolatenz von 20 Millisekunden oder weniger, über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden über den Weg vom Lautsprecher zum Mikrofon.
- [C-SR-2] wird dringend empfohlen, die Pro Audio-Anforderungen für Kontinuierliche Umlauf-Audiolatenz, Cold-Input-Latenz und Cold-Ausgabe Latenz- und USB-Audioanforderungen bei Verwendung der AAudio Native Audio API über den MMAP-Pfad.
[C-SR-3] WIRD UNBEDINGT EMPFOHLEN, ein konsistentes CPU-Level bereitzustellen bei aktivem Audio und schwankender CPU-Auslastung. Dies sollte getestet werden, mit der Android-App SynthMark. SynthMark nutzt einen Software-Synthesizer, der auf einem simulierten Audio-Framework ausgeführt wird. die die Systemleistung misst. Weitere Informationen finden Sie in der SynthMark-Dokumentation finden Sie eine Erläuterung der Benchmarks. SynthMark ausgeführt werden muss, „Automatisierter Test“ und erzielen Sie folgende Ergebnisse:
- Stimmmarke.90 >= 32 Stimmen
- Latenzmark.Fixed.little <= 15 ms
- Latenzmark.dynamic.little <= 50 ms
SOLLTEN die Ungenauigkeit der Audiouhr und die Abweichung gegenüber der Standardzeit minimieren.
SOLLTEN die Abweichung des Audiotakts relativ zur CPU minimieren:
CLOCK_MONOTONIC
wenn beide aktiv sind.SOLLTEN die Audiolatenz über geräteinterne Transducer minimieren.
SOLLTEN die Audiolatenz im Vergleich zu digitalen USB-Audioquellen minimieren.
SOLLTEN die Messungen der Audiolatenz für alle Pfade dokumentieren.
SOLLTEN Sie den Jitter bei den Callback-Eingabezeiten für die Beendigung des Audiopuffers minimieren, da wirkt sich auf den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback aus.
SOLLTEN bei normaler Nutzung mit der gemeldeten Latenz keine Audiostörungen auftreten.
SOLLTEN keinen Unterschied bei der kanalübergreifenden Latenz haben.
SOLLTEN die durchschnittliche MIDI-Latenz für alle Transporte minimieren.
SOLLTEN die MIDI-Latenzvariabilität unter Last (Jitter) bei allen Transporten minimieren.
SOLLTEN für alle Transporte genaue MIDI-Zeitstempel angeben.
SOLLTEN Störungen des Audiosignals über geräteinterne Wandler, einschließlich der Periode direkt nach dem Kaltstart.
SOLLTE 0 Audiotaktdifferenz zwischen den Ein- und Ausgabeseiten des wenn beide aktiv sind. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher des Geräts oder der Audioanschluss und Ausgabe.
SOLLTE Callbacks für die Beendigung des Audiopuffers auf der Ein- und Ausgabeseite verarbeiten. der entsprechenden Endpunkte im selben Thread, wenn beide aktiv sind, und direkt nach der Rückgabe des Eingabe-Callbacks den Ausgabe-Callback. Oder Wenn die Callbacks nicht im selben Thread verarbeitet werden können, geben Sie den Parameter kurz nach der Eingabe des Eingabe-Callbacks übergeben, um den um ein einheitliches Timing der Ein- und Ausgabeseite zu gewährleisten.
SOLLTEN den Phasenunterschied zwischen der HAL-Audiozwischenspeicherung für die Eingabe minimieren. und Ausgabeseiten der entsprechenden Endpunkte.
SOLLTEN die Berührungslatenz minimieren.
SOLLTEN Sie die Schwankungen der Berührungslatenz unter Last (Jitter) minimieren.
Wenn Geräteimplementierungen alle oben genannten Anforderungen erfüllen, gilt Folgendes:
- [C-SR-4] WIRD DRINGEND empfohlen, die Unterstützung dieser Funktion zu melden
android.hardware.audio.pro
über dieandroid.content.pm.PackageManager
.
Wenn Geräte eine 3,5-mm-Audiobuchse mit 4 Kabeln enthalten, ist Folgendes zu beachten:
- [C-2-1] MUSS eine durchschnittliche Continuous Round-Trip-Audiolatenz haben, wie in Abschnitt 5.6 Audiolatenz von 20 Millisekunden oder weniger, über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden im Den Pfad der Audiobuchse mithilfe eines Audio-Loopback-Dongles.
- [C-SR-5] EMPFOHLEN, Abschnitt Technische Daten für Mobilgeräte (Anschlussbuchse) der Spezifikation für Kabel-Audio-Headsets (Version 1.1).
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.
- [C-3-2] MUSS eine durchschnittliche Continuous Round-Trip-Audiolatenz von 25 Millisekunden oder weniger, über 5 Messungen mit einer mittleren absoluten Abweichung weniger als 5 Millisekunden über den USB-Hostmodus-Port bei Verwendung der USB-Audioklasse (Dies kann mit einem USB-3,5-mm-Adapter und einem Audio-Loopback gemessen werden. oder eine USB-Audioschnittstelle mit Patchkabeln verwenden, Ein- und Ausgaben).
- [C-SR-6] WIRDEN DRINGEND empfohlen, die gleichzeitige E/A für bis zu 8 Kanäle zu unterstützen in jede Richtung, eine Abtastrate von 96 kHz und eine Tiefe von 24 Bit oder 32 Bit, wenn verwendet mit USB-Audio-Peripheriegeräten, die diese Anforderungen ebenfalls erfüllen.
- [C-SR-7] EMPFOHLEN, diese Gruppe von Anforderungen zu erfüllen, das native AAudio-Audio-API über den MMAP-Pfad.
Wenn Geräteimplementierungen einen HDMI-Port enthalten, ist Folgendes erforderlich:
- SOLLTEN die Ausgabe in Stereo und acht Kanäle mit 20-Bit oder 24-Bit-Tiefe und 192 kHz ohne Bittiefenverlust oder -resampling, in mindestens einer Konfiguration.
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 nicht verarbeiteten 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 Gleitpunkt/Doppelwert) 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ürAudioManager.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 standardmäßig die Tonzuordnung für HDR zu SDR 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 enthält, die FEATURE_HdrEditing unterstützen, dann gilt: 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.
-
- [C-0-2] MÜSSEN ADB gemäß der Dokumentation im Android SDK und in der Shell unterstützen.
die im AOSP bereitgestellt werden und
die von App-Entwicklern verwendet werden können,
einschließlich
dumpsys
cmd stats
- [C-0-11] MUSS den Shell-Befehl
cmd testharness
unterstützen. Upgrade wird durchgeführt früheren Android-Versionen ohne eine persistente Datensperre KANN von C-0-11 ausgenommen werden. - [C-0-3] Dürfen das Format oder den Inhalt des Gerätesystems NICHT verändern Ereignisse (batterystats , diskstats, Fingerabdruck, Grafiksstatistik, Netstats, Notification, procstats), die über den Befehl dumpsys protokolliert wurden.
- [C-0-10] MÜSSEN die folgenden Ereignisse ohne Auslassung aufnehmen und durchführen.
und für den Shell-Befehl
cmd stats
und den System-API-KlasseStatsManager
.- AktivitätsforegroundState geändert
- Anomalie erkannt
- AppBreadcrumbReported
- App-Absturz aufgetreten
- AppStartAuftreten
- Akkustand geändert
- Energiesparmodus geändert
- BleScanResultReceived
- BleScanStateGeändert
- Ladestatus geändert
- DeviceIdleModeStateGeändert
- Dienststatus im Vordergrund geändert
- GpsScanStateGeändert
- JobStateChanged (Jobstatus geändert)
- PluggedStateChanged
- ScheduledJobStateGeändert
- Bildschirmstatus geändert
- Synchronisierungsstatus geändert
- SystemElapsedRealtime
- UidProcessStateGeändert
- WakelockStateGeändert
- Wakeup-Alarm aufgetreten
- WifiLockStateGeändert
- WifiMulticastLockStateGeändert
- WifiScanStateGeändert
- [C-0-4] MÜSSEN der geräteseitige ADB-Daemon standardmäßig inaktiv sein und Es muss einen für den Nutzer zugänglichen Mechanismus zum Aktivieren von Android Debug Brücke.
- [C-0-5] MUSS sicheres ADB unterstützen. Android unterstützt sichere ADB. „Secure adb“ aktiviert ADB auf bekannten authentifizierten Hosts.
- [C-0-6] MÜSSEN einen Mechanismus bereitstellen, der die Verbindung von adb über eine Hostcomputer. Im Detail:
Wenn Geräteimplementierungen ohne USB-Port den Peripheriemodus unterstützen, gilt Folgendes:
- [C-3-1] MÜSSEN ADB über ein Local Area Network (z. B. Ethernet) implementieren. oder WLAN).
- [C-3-2] MÜSSEN Treiber für Windows 7, 8 und 10 bereitstellen, Entwicklern über das ADB-Protokoll eine Verbindung zum Gerät herzustellen.
Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet, verwenden sie Folgendes:
- [C-4-1] MUSS die Methode
AdbManager#isAdbWifiSupported()
habentrue
zurückgeben.
Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet verwenden und über mindestens eine Kamera verfügt, werden sie:
- [C-5-1] MUSS die Methode
AdbManager#isAdbWifiQrSupported()
habentrue
zurückgeben.
- [C-0-2] MÜSSEN ADB gemäß der Dokumentation im Android SDK und in der Shell unterstützen.
die im AOSP bereitgestellt werden und
die von App-Entwicklern verwendet werden können,
einschließlich
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.
-
- [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.
-
- [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.
- [C-SR-1] wird dringend empfohlen,
-
- [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.
- [C-0-12] MUSS ein
Test-Harnischmodus Wenn Geräteimplementierungen den Shell-Befehl
cmd testharness
undcmd testharness enable
ausführen, wird Folgendes ausgeführt:- [C-2-1] MUSS
true
zurückgeben fürActivityManager.isRunningInUserTestHarness()
- [C-2-2] MÜSSEN den Test-Harnischmodus wie in Dokumentation zum Test-Harnischmodus
- [C-2-1] MUSS
Informationen zur Arbeit mit GPUs
Geräteimplementierungen:
- [C-0-13] MÜSSEN den Shell-Befehl
dumpsys gpu --gpuwork
implementieren, um Die aggregierten GPU-Arbeitsdaten, die vom Kernelpower/gpu_work_period
zurückgegeben werden Tracepoint oder zeigen Sie keine Daten an, wenn der Tracepoint nicht unterstützt wird. Der AOSP Implementierung istframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] MÜSSEN den Shell-Befehl
Wenn Geräteimplementierungen die Unterstützung von Vulkan 1.0 oder höher über 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 MÜSSEN 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()
- undhasSystemFeature(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 einwandfrei mit verschiedenen Hardwarekonfigurationen laufen. Auf den mit Android kompatiblen Displays, auf denen alle mit Android kompatiblen Anwendungen ausgeführt werden können, MÜSSEN diese APIs bei Geräteimplementierungen ordnungsgemäß implementiert werden. und Verhaltensweisen, wie in diesem Abschnitt beschrieben.
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.
- DPI (Punkte pro Zoll) Die Anzahl der von einer linearen Linie eingeschlossenen Pixel Horizontale oder vertikale Spannweite von 2,5 cm. Die dpi-Werte sind horizontal und und die vertikale dpi muss im 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): Die virtuelle Pixeleinheit normalisiert Bildschirm mit 160 dpi, berechnet wie folgt: Pixel = dps * (Dichte/160).
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 einesmall
-Größe für dieConfiguration.screenLayout
muss mindestens 426 dp x 320 dp haben. - Geräte, die eine Größe von
normal
fürConfiguration.screenLayout
melden, MUSS mindestens 480 dp x 320 dp haben. - Geräte, die eine Größe von
large
fürConfiguration.screenLayout
melden, MUSS mindestens 640 dp x 480 dp haben. - Geräte, die eine Größe von
xlarge
fürConfiguration.screenLayout
melden, MUSS mindestens 960 dp x 720 dp haben.
- Geräte, bei denen
[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 UI_MODE_TYPE_NORMAL
unterstützen und fügen Sie
Android-kompatible Bildschirme mit abgerundeten Ecken:
[C-1-1] MÜSSEN sicherstellen, dass mindestens eine der folgenden Anforderungen erfüllt ist:
- Der Radius der abgerundeten Ecken ist kleiner oder gleich 38 dp.
- Wenn ein Feld mit einer Größe von 15 dp x 15 dp in 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 Geräteimplementierungen Android-kompatible Bildschirme umfassen, die faltbar oder verfügt über ein faltbares Scharnier zwischen mehreren Displays zum Rendern von Drittanbieter-Apps zur Verfügung stehen,
- [C-2-1] MUSS die neueste stabile Version des Extensions API oder die stabile Version der Sidecar API von der Window Manager-Jetpack-Bibliothek verwendet werden.
Wenn Geräteimplementierungen Android-kompatible Bildschirme umfassen, die faltbar oder verfügt über ein faltbares Scharnier zwischen mehreren Displays und das Scharnier oder die Faltung durch ein Anwendungsfenster im Vollbildmodus verläuft, geschieht Folgendes:
- [C-3-1] MÜSSEN die Position, Begrenzungen und den Zustand des Scharniers angeben oder das oder Sidecar-APIs zur Anwendung hinzufügen.
Weitere Informationen zur korrekten Implementierung der Sidecar- oder Erweiterungs-APIs finden Sie unter der öffentlichen Dokumentation von Window Manager Jetpack.
7.1.1.2 Bildschirmseitenverhältnis
Zwar gibt es keine Einschränkungen im Hinblick auf das Seitenverhältnis des physischen Bildschirms für
die mit Android kompatiblen Displays sowie das Seitenverhältnis der logischen Anzeige
bei denen Drittanbieter-Apps gerendert werden.
Dies lässt sich anhand der Höhe und
Werte für die Breite im view.Display
APIs und Konfiguration
APIs MÜSSEN die folgenden Anforderungen erfüllen:
[C-0-1] Geräteimplementierungen mit
Configuration.uiMode
auf Das Seitenverhältnis vonUI_MODE_TYPE_NORMAL
MUSS kleiner als oder gleich sein. auf 1,86 (etwa 16:9), es sei denn, die App erfüllt eine der folgenden Anforderungen Bedingungen:- Die App hat erklärt, dass sie ein größeres Bildschirmseitenverhältnis unterstützt
über die
android.max_aspect
Metadata-Wert. - Die App deklariert über die android:resizeableActivity, dass ihre Größe angepasst werden kann. .
- Die App ist auf API-Level 24 oder höher ausgerichtet und deklariert kein
android:maxAspectRatio
das das zulässige Seitenverhältnis einschränken würde.
- Die App hat erklärt, dass sie ein größeres Bildschirmseitenverhältnis unterstützt
über die
[C-0-3] Geräteimplementierungen mit dem
Configuration.uiMode
FürUI_MODE_TYPE_WATCH
muss das Seitenverhältnis auf 1,0 (1:1) eingestellt sein.
7.1.1.3 Bildschirmdichte
Das Android-UI-Framework definiert eine Reihe von logischen Standarddichten, um Anwendungsentwickler zielen auf Anwendungsressourcen ab.
[C-0-1] Standardmäßig MUSS bei Geräteimplementierungen nur eines der Hier sind die Android-Framework-Dichten aufgeführt.
DisplayMetrics
über dieDENSITY_DEVICE_STABLE
API und dieser Wert DARF NICHT geändert werden. Das Gerät KANN jedoch eine mit unterschiedlicher Dichte, je nach Anzeigekonfiguration vom Nutzer vorgenommene Änderungen (z. B. an der Anzeigegröße), die nach der anfangs starten.Geräteimplementierungen SOLLTEN die standardmäßige Android-Framework-Dichte definieren die der physischen Dichte des Bildschirms am nächsten kommt, es sei denn, Mit der logischen Dichte wird die gemeldete Bildschirmgröße unter die unterstützte Mindestgröße verschoben. Wenn der standardmäßigen Android-Framework-Dichte, die numerisch der führt zu einer Bildschirmgröße, die kleiner ist als unterstützte kompatible Bildschirmgröße (320 dp), Geräteimplementierungen SOLLTEN melden die nächstniedrigere Standard-Android-Framework-Dichte.
Wenn es eine Möglichkeit gibt, die Anzeigegröße des Geräts zu ändern:
- [C-1-1] Die Displaygröße DARF NICHT größer als das 1,5-fache der nativen Dichte oder eine effektive Mindestbildschirmgröße von unter 320 dp (entspricht an den Ressourcenqualifizierer sw320dp übergeben, je nachdem, was zuerst eintritt.
- [C-1-2] Die Anzeigegröße DARF NICHT kleiner als das 0,85-Fache der nativen Dichte skaliert werden.
- 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)
- 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, geschieht Folgendes:
- [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 Standardwertview.Display
.
7.1.3 Displayausrichtung
Geräteimplementierungen:
- [C-0-1] MÜSSEN angeben, welche Bildschirmausrichtungen sie unterstützen.
(
android.hardware.screen.portrait
und/oderandroid.hardware.screen.landscape
) und 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 Berichtandroid.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 Anforderung der Anwendung 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:
- [C-1-1] MUSS sowohl OpenGL ES 1.1 als auch 2.0 unterstützen, wie in der Grafik in der Android SDK-Dokumentation.
- [C-SR-1] Wir empfehlen dringend, OpenGL ES 3.1 zu unterstützen.
- SOLLTEN OpenGL ES 3.2 unterstützen.
Die OpenGL ES-dEQP-Tests sind in eine Reihe von Testlisten aufgeteilt, die jeweils eine
eine zugehörige Datums-/Versionsnummer. Diese befinden sich in der Android-Quellstruktur unter
external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
Ein Gerät, das
OpenGL ES auf 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 anderen von ihnen implementierten OpenGL ES-Erweiterungen befinden, und MÜSSEN umgekehrt MÜSSEN, Meldet KEINE Erweiterungsstrings, die nicht von ihnen unterstützt werden.
- [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
undEGL_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
undOES_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
undEGL_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 , ein plattformübergreifendes 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, Unterstützung für Vulkan 1.3 hinzuzufügen.
- [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, Unterstützung für Vulkan 1.3 hinzuzufügen.
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-main-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 1.0 oder höher unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN den richtigen Ganzzahlwert mit dem
android.hardware.vulkan.level
undandroid.hardware.vulkan.version
Funktions-Flags. - [C-1-2] MUSS angeben, mindestens ein
VkPhysicalDevice
für den Vulkan native APIvkEnumeratePhysicalDevices()
. - [C-1-3] MÜSSEN die Vulkan 1.0-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-APIsvkEnumerateInstanceLayerProperties()
undvkEnumerateDeviceLayerProperties()
. - [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
festgelegt alstrue
. - [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-Flagandroid.software.vulkan.deqp.level
. - [C-1-11] DARF NICHT die Unterstützung für die VK_KHR_video_queue, VK_KHR_video_decode_queue- oder VK_KHR_video_encode_queue-Erweiterungen.
- [C-SR-3] WIRD UNBEDINGT EMPFOHLEN,
VK_KHR_driver_properties
zu unterstützen undVK_GOOGLE_display_timing
Erweiterungen. - SOLLTEN
VkPhysicalDeviceProtectedMemoryFeatures
undVK_EXT_global_priority
. - [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 2021“.
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ählenvkEnumeratePhysicalDevices()
.
Wenn Geräteimplementierungen Unterstützung für Vulkan 1.1 beinhalten und eines der Vulkan-Feature-Flags:
- [C-3-1] MÜSSEN die Unterstützung für die externe Semaphore und den Handle
SYNC_FD
anzeigen und die ErweiterungVK_ANDROID_external_memory_android_hardware_buffer
.
7.1.4.3 RenderScript
- [C-0-1] Geräteimplementierungen MÜSSEN Android RenderScript unterstützen. in der Android SDK-Dokumentation.
7.1.4.4 Beschleunigung der 2D-Grafik
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 Deaktivierung 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 Breitwinkel-Displays
Wenn Geräteimplementierungen Unterstützung für Weitwinkel-Displays durch
Configuration.isScreenWideColorGamut()
:
- [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
undEGL_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, in dem das Framework '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] MUSS die
DisplayManager
implementieren 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, die in android.content.res.Configuration.keyboard angegeben sind (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>
mitACTION=MAIN
undCATEGORY=LAUNCHER
oderCATEGORY=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 Anwendungen 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 vonWindowInsets#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ürView#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 VordergrundMotionEvent.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 die 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 überView#setSystemGestureExclusionRects()
Wenn am linken und rechten Rand eine Navigationsfunktion vorhanden ist der aktuellen Bildschirmausrichtung:
- [C-7-1] Die Navigationsfunktion muss "Zurück" sein und durch Wischen rechten und linken Rand der aktuellen Bildschirmausrichtung.
- [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ürConfiguration.touchscreen
melden API-Feld ein. - [C-1-2] MÜSSEN die
android.hardware.touchscreen
und Funktions-Flags vonandroid.hardware.faketouch
.
Wenn Geräte einen Touchscreen haben, mit dem mehr als auf einem mit Android kompatiblen primären Bildschirm durch einmaliges Tippen darauf zugreifen:
- [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 dieConfiguration.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 eine Statusänderung beim Zeiger, die auf dem Zeiger nach unten oder oben .
- [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) |
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.
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 | 0 x 01, 0 x 0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
7.2.7 Fernbedienung
Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.3.1.
7.3. Sensoren
Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer 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
oderfalse
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 ihres Stromverbrauchs MUSS immer kleiner als 4 mW sein.
- 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 die
TYPE_GRAVITY
- undTYPE_LINEAR_ACCELERATION
-Sensoren. - [C-SR-7] wird dringend empfohlen,
TYPE_GAME_ROTATION_VECTOR
zusammengesetzten Sensors.
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 der 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
undTYPE_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ären „nahe“ oder „ferne“ Werte sind:
- [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 wieTYPE_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 alsTYPE_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 alsTYPE_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 weniger 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 weniger 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 weniger 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 weniger 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
undgetHighestDirectReportRateLevel
der API erstellen. - [C-3-2] MUSS mindestens einen der beiden direkten Sensorkanaltypen unterstützen für alle Sensoren, die angeben, dass sie den direkten Sensorkanal unterstützen.
- SOLLTEN die Ereignismeldung über den direkten Sensorkanal für den primären
Sensor (Variante ohne Weckfunktion) der folgenden Typen:
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.
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-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 Tests. 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.
- [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.
- [C-1-5] MÜSSEN alle identifizierbaren biometrischen Daten eines Nutzers vollständig entfernen Das Konto des Nutzers wird entfernt (auch durch Zurücksetzen auf die Werkseinstellungen).
- [C-1-6] MÜSSEN die individuelle Flagge für diese biometrische (d.h.
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
oderDevicePolicymanager.KEYGUARD_DISABLE_IRIS
). - [C-1-7] MUSS den Nutzer zur empfohlenen primären Authentifizierung auffordern (z.B. PIN, Muster, Passwort) mindestens einmal alle 24 Stunden. Hinweis: Geräteupgrades MÜSSEN mit Android 9 oder niedriger MÜSSEN Nutzer auffordern, die empfohlene primäre Authentifizierung (z.B. PIN, Muster, Passwort), einmal alle 72 Stunden oder seltener.
- [C-1-8] MÜSSEN den Nutzer zur Empfehlung für Hauptkonten auffordern
Authentifizierung (z. B. PIN, Muster, Passwort) oder biometrisches Verfahren der Klasse 3 (STRONG)
nach einer der folgenden Aktionen:
- ein Zeitlimit von 4 Stunden bei Inaktivität ODER
- 3 fehlgeschlagene biometrische Authentifizierungsversuche.
- Das Zeitlimit bei Inaktivität und die Anzahl der fehlgeschlagenen Authentifizierungen werden zurückgesetzt. nach erfolgreicher Bestätigung der Geräteanmeldedaten. Hinweis: Geräteupgrades, die mit Android 9 oder niedriger gestartet wurden, KÖNNEN von der C-1-8 ausgenommen ist.
- [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 von weniger als 10 % (gemessen auf dem Gerät)
- [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.
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 Parodien und Irrtümern für die Präsentation der Stufe A Angriffsinstrumentenarten, die nicht mehr als 20 % ausmachen, und (2) eine Parodien und Hochstapler-Akzeptanzrate von Level-B-PAI-Spezies nicht höher als 30%, da gemessen durch die 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) oder auf einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung.
[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 Android Open Source Project.
[C-2-5] Für kamerabasierte biometrische Verfahren und biometrische Authentifizierung oder eine Registrierung stattfindet:
- 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 zur isolierten Ausführungsumgebung.
- 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. Upgrade für unter Android gestartete Geräte ausführen Version 9 oder älter sind nicht von C-2-7 ausgenommen.
[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) werden:
- [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 Gruppe herausfordern Authentifizierung (z.B. mit 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.
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 [Verschoben zu 7.4.9]
7.4 Datenverbindung
7.4.1 Telefonie
Der Begriff „Telefonie“ wird von den Android-APIs verwendet. Dieses Dokument bezieht sich speziell auf Hardware zum Tätigen von Sprachanrufen und Senden von SMS-Nachrichten über ein GSM oder CDMA-Netzwerk. Diese Sprachanrufe können zwar durch Paketvermittlungen übertragen werden, Sie sind für die Zwecke von Android gedacht, die unabhängig von jeglichen Daten sind Konnektivität, die über dasselbe Netzwerk eingerichtet werden kann. Mit anderen Worten: beziehen sich die Android-Telefoniefunktionen und APIs speziell auf Sprachfunktionen Anrufe und SMS. z. B. bei Geräteimplementierungen, die keine Anrufe oder SMS-Nachrichten werden nicht als Telefoniegerät betrachtet, unabhängig davon, ob sie ein Mobilfunknetz für die Datenverbindung nutzen.
- 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 „alt“ gesetzt wird, geschieht Folgendes:
- [C-4-1] DARF NICHT „NETWORK_TYPE_IWLAN“ melden über NetworkRegistrationInfo#getAccessNetworkTechnology() wenn NetworkRegistrationInfo#getTransportType() wird als TRANSPORT_TYPE_WWAN für dieselbe NetworkRegistrationInfo-Instanz gemeldet.
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
undSmsManager#sendMultipartTextMessage
MÜSSEN zu entsprechenden Aufrufen an führen.CarrierMessagingService
zur Bereitstellung von SMS-Funktionen.SmsManager#sendMultimediaMessage
undSmsManager#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 entsprechendeTelephonyManager#ACTION_SECRET_CODE
Nachricht an alle. - [C-6-4] Die Anwendung, die auf
Intent#ACTION_DIAL
MÜSSEN verwendenVoicemailContract.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
oderEuiccManager#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:- 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 bis 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] wird dringend empfohlen, die Standard-Telefon-App vorab zu laden, einen Eintrag aus einer Anrufliste und den Namen einer Drittanbieter-App in der Anrufliste zeigt wenn die Drittanbieter-App
EXTRA_LOG_SELF_MANAGED_CALLS
Extras-Schlüssel aufPhoneAccount
zutrue
.[C-SR-3] EMPFOHLEN
KEYCODE_MEDIA_PLAY_PAUSE
- undKEYCODE_HEADSETHOOK
-Ereignisse für denandroid.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.
- [C-1-4] MÜSSEN Multicast-DNS (mDNS) unterstützen und mDNS-Pakete NICHT filtern
(224.0.0.251) zu jeder Betriebszeit, einschließlich:
- Auch wenn der Bildschirm nicht aktiv ist.
- Für Implementierungen von Android TV-Geräten, auch im Stand-by-Modus Energiezustände.
- [C-1-5] DARF NICHT den
WifiManager.enableNetwork()
behandeln API-Methodenaufruf als ausreichender Hinweis zum Wechseln der derzeit aktivenNetwork
, die standardmäßig für Anwendungstraffic verwendet und zurückgegeben wird vonConnectivityManager
API-Methoden wiegetActiveNetwork
undregisterDefaultNetworkCallback
. 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 derNetwork
neu und sobald bei der Auswertung festgestellt wird, dass der aktuelleNetwork
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) die 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 (Access Point, ZP) während der Verknüpfung und
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 können 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 oderWIFI_MODE_FULL_LOW_LATENCY
-Sperre überWifiManager.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. allgemeine Werbung 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 mit einer Entfernung von maximal 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) mit A2DP.
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
undandroid.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 Anwesenheitskalibrierung:
Wenn Geräteimplementierungen die Bluetooth-Version 5.0 unterstützen, gilt Folgendes:
- [C-SR-4] Wir empfehlen Ihnen dringend, folgende Fragen zu unterstützen:
- LE 2 Mio. PHY
- LE-Codec PHY
- LE-Werbeerweiterung
- Regelmäßige Werbung
- Mindestens 10 Anzeigensätze
- Mindestens 8 gleichzeitige LE-Verbindungen. Jede Verbindung kann entweder Verbindungstopologie-Rollen.
- LE-Link-Layer-Datenschutz
- Eine „Lösungsliste“ Größe von mindestens 8 Einträgen
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
undandroid.nfc.NdefRecord
APIs auch dann, wenn sie keine Unterstützung für NFC oder das Featureandroid.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 Methodeandroid.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:
- 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 demandroid.content.pm.PackageManager.hasSystemFeature
() . Beachten Sie, dass dies keine Standardfunktion von Android ist und dementsprechend auch nicht werden in der Klasseandroid.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
undjava.net.URLConnection
und die nativen APIs wieAF_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:
- [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.
- MÜSSEN sicherstellen, dass die IPv6-Kommunikation so zuverlässig ist wie IPv4, zum Beispiel:
- [C-0-6] MÜSSEN Anwendungen von Drittanbietern eine direkte IPv6-Verbindung 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
oderSocket#getLocalPort
) und NDK APIs wiegetsockname()
oderIPV6_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-APIConnectivityManager#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
undandroid.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ürConnectivityManager.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 Elementenandroid.hardware.se.omapi.sd
für das Gerät mit SD-basierten sicheren Elementen.
7.4.9 UWB
Wenn Geräteimplementierungen 802.1.15.4 unterstützen und den Funktionalität in Drittanbieter-Anwendungen zur Verfügung stellen, geschieht Folgendes:
- [C-1-1] MÜSSEN die entsprechende Android API in android.uwb implementieren.
- [C-1-2] MÜSSEN das Hardwarefunktions-Flag „android.hardware.uwb“ melden.
- [C-1-3] MUSS alle relevanten UWB-Profile unterstützen, die in 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, der mit der Vorderseite nach oben gehalten und geneigt ist 45 Grad.
- [C-SR-2] Wir empfehlen dringend, die Schritte zur Einrichtung der Analyse zu befolgen angegeben in 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
, oderMediaStore.ACTION_VIDEO_CAPTURE
, ist dafür verantwortlich, den Nutzerstandort aus den Bildmetadaten zu entfernen, bevor wenn diese nicht an die empfangende Anwendung habenACCESS_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 Kamera an der Seite dem Gerät gegenüber dem Bildschirm; d. h., es werden Szenen am anderen Ende des wie bei einer herkömmlichen Kamera.
Geräteimplementierungen:
- SOLLTE eine Rückkamera enthalten.
Wenn Geräteimplementierungen mindestens eine Kamera auf der Rückseite enthalten, ist Folgendes zu beachten:
- [C-1-1] MÜSSEN die Funktions-Flags
android.hardware.camera
undandroid.hardware.camera.any
. - [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 AttributeFLASH_MODE_AUTO
oderFLASH_MODE_ON
einesCamera.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, dieCamera.PreviewCallback
verwenden.
7.5.2 Frontkamera
Eine Frontkamera ist eine Kamera, die sich auf der gleichen Seite des Geräts befindet wie Display; d. h. eine Kamera, die in der Regel zur Aufnahme des Nutzers verwendet wird, z. B. für Videokonferenzen und ähnliche Anwendungen.
Geräteimplementierungen:
- KANN eine Frontkamera enthalten.
Wenn Geräteimplementierungen mindestens eine Frontkamera umfassen, ist Folgendes zu beachten:
- [C-1-1] MÜSSEN die Funktions-Flags
android.hardware.camera.any
undandroid.hardware.camera.front
. - [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 desandroid.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
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
undandroid.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 wurdeandroid.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 MethodeonPreviewFrame()
und die Vorschau Format YCbCr_420_SP, sind die Daten in byte[], die anonPreviewFrame()
ü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ürandroid.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
undandroid.hardware.ImageFormat.JPEG
-Formate als Ausgaben über denandroid.media.ImageReader
API fürandroid.hardware.camera2
Geräte, die werben fürREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
inandroid.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 müssen die API-Callbacks wie beschrieben "gefälscht" werden. - [C-0-6] MÜSSEN alle Parameternamen erkennen und berücksichtigen.
als Konstante in der
android.hardware.Camera.Parameters
und die Klasseandroid.hardware.camera2.CaptureRequest
. Umgekehrt DÜRFEN Geräteimplementierungen Stringkonstanten NICHT berücksichtigen oder erkennen an die Methodeandroid.hardware.Camera.setParameters()
übergeben, die nicht die als Konstanten in derandroid.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 dieandroid.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 überandroid.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
oderandroid.hardware.Camera
der API erstellen. - [C-SR-1] Bei Geräten mit mehreren RGB-Kameras, die in dieselbe Richtung weisen,
werden dringend empfohlen, ein logisches Kameragerät zu unterstützen, 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.
7.6 Arbeitsspeicher und Datenspeicher
7.6.1 Mindestanforderungen an Arbeitsspeicher und Speicherplatz
Geräteimplementierungen:
- [C-0-1] MUSS mit 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 vonsdcard
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:
- Wenn die App
android:requestLegacyExternalStorage="true"
angefordert hat in ihrem Manifest.
- Wenn die App
- [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 BerechtigungACCESS_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 überandroid.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:
- 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-Audioklasse zu implementieren. 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 gemäß den Spezifikationen zum Laden von USB-Batterien, 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
- Nutzungsseite (0xC) Nutzungs-ID (0x0CD):
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
- undACTION_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, Für WLAN oder das Mobilfunknetz ist kein „Ausgabeport“ enthalten.
7.8.2.1 Analoge Audioanschlüsse
Um mit den Headsets und anderem Audiozubehör kompatibel zu sein ü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:
- Max. 70 Ohm:
KEYCODE_HEADSETHOOK
- 210–290 Ohm:
KEYCODE_VOLUME_UP
- 360–680 Ohm:
KEYCODE_VOLUME_DOWN
- Max. 70 Ohm:
- [C-1-4] MUSS
ACTION_HEADSET_PLUG
bei Steckereinsatz auslösen, aber Erst nachdem alle Kontakte der Steckdose ihre 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:
- 110–180 Ohm:
KEYCODE_VOICE_ASSIST
- 110–180 Ohm:
- [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 Nahezu-Ultraschall-Audiofunktion über 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 | < 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
sowohlVK_QUEUE_GRAPHICS_BIT
als auchVK_QUEUE_COMPUTE_BIT
enthalten, undqueueCount
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 FlagsAHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
undAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
wie im NDK beschrieben. - [C-1-10] MÜSSEN die Unterstützung für
AHardwareBuffer
s implementieren mit Kombination der Nutzungs-FlagsAHARDWAREBUFFER_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
AHardwareBuffer
s 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:
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
Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.2.1.
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 für 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 Für Apps verwendete App-Standby-Buckets Bitte warten.
- [C-1-4] MÜSSEN App-Standby-Buckets und den Stromsparmodus implementieren als wie unter Energiesparmodus beschrieben.
- [C-1-5] MUSS
true
fürPowerManager.isPowerSaveMode()
zurückgeben 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 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 muss der S3-Status beendet werden, wenn Anwendungen von Drittanbietern die 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 um die Zuweisung von Ressourcen zu 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] MUSS die
Window.setSustainedPerformanceMode()
berücksichtigen 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()
melden. 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
vonPROTECTION_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 imetc/permissions/
-Pfad und die Verwendung dessystem/priv-app
-Pfads als privilegierten Pfad.
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-4] MUSS eine und nur eine Implementierung beider Schnittstellen. Wenn die Geräteimplementierung ein Begleitgerät unterstützt, wird das Begleitgerät eine zusätzliche Schnittstelle bieten KÖNNEN.
[C-0-5] DÜRFEN KEINEN Laufzeitberechtigungen zu Apps, 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 werden vom 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 dem Remote-Speicher außerhalb des Geräts synchronisiert, 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
- oderNETWORK_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 jedesoftRestricted
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:
- 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] MUSS alle im Abschnitt „9.8.6 Inhaltserfassung“ beschriebenen Anforderungen für Geräteimplementierungen erfüllen.
- [C-4-2] DÜRFEN KEINE Berechtigung „android.permission.INTERNET“ haben. Dies ist strenger als in Abschnitt 9.8.6 UNBEDINGT EMPFOHLEN.
- [C-4-3] DÜRFEN NICHT an andere Apps binden, mit Ausnahme der folgenden System-Apps: Bluetooth, Kontakte, Medien, Telefonie, SystemUI und Komponenten, die Internet-APIs bereitstellen.Diese Vorgehensweise ist strenger als die in Abschnitt 9.8.6 UNBEDINGT EMPFOHLENE.
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.
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 (obligatorische Zugriffssteuerung), Seccomp-Sandboxing und andere (SELinux) 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
undCONFIG_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
oderCONFIG_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
oderCONFIG_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
oderCONFIG_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
oderCONFIG_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 DRINGEND 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
oderEFI_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
undCONFIG_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
oderCONFIG_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 die Verwendung nicht initialisierter Heap-Zuweisungen zu verhindern (
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] MUSS 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 dies TEE OS durchgesetzt wird.
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 die 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-KlasseIncidentManager
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 die ausdrückliche Zustimmung des Nutzers anzeigen und einholen, wenn sensible
die auf dem Bildschirm der Nutzenden angezeigt werden und erfasst werden,
Bildschirmstreaming oder Bildschirmaufzeichnung ist aktiviert über
MediaProjection
oder proprietäre APIs. DÜRFEN Nutzern NICHT die Möglichkeit bieten, die Funktion in der Zukunft zu deaktivieren. die Anzeige der Nutzereinwilligung. - [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.
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 Erfassung von Inhalten, 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, müssen 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 jeden sichtbar ist. für den Nutzer sichtbar und nicht verdeckt sein, da Nutzer als eine Kamera in Verwendung 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] WIRDEN UNBEDINGT EMPFOHLEN, die Kameraanzeige einzublenden, wenn eine App Auf Live-Kameradaten zugreifen, aber nicht, wenn nur auf die Kamera zugegriffen wird Apps, die die in Paragraf 9.1 „Berechtigungen“ für CDD genannten Rollen haben Kennung [C-3-X].
- [C-SR-5] wird dringend empfohlen, kürzlich verwendete und aktive Apps mit folgenden Funktionen anzuzeigen:
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:
- 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 EinstellungSERVICE_META_DATA_SUPPORTS_ALWAYS_ON
zufalse
.
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:
- 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. Inhaltserfassung und App-Suche
Android über die System API ContentCaptureService
AugmentedAutofillService
, AppSearchGlobalManager.query
oder durch eine andere Person
proprietär, unterstützt einen Mechanismus für Geräteimplementierungen,
Anwendungsdateninteraktionen zwischen den Anwendungen und
für den Nutzer:
- 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 anderen Ereignisse, die eine Anwendung dem System über das Ereignis
Content Capture
API oderAppSearchManager
API ein ähnlich fähiges Android- und proprietären APIs. - 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.
Wenn Geräteimplementierungen die oben genannten Daten erfassen, 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] MUSS nur alle diese Daten und das Geräteprotokoll mit einem
datenschutzfreundlichen Mechanismus auf. Der datenschutzfreundliche Mechanismus
sind definiert als „Maßnahmen, die nur Analyse in aggregierter Form ermöglichen und
der protokollierten Ereignisse oder abgeleiteten Ergebnisse
mit einzelnen Nutzern 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 Erfassung von Inhalten), außer mit ausdrücklicher Zustimmung des Nutzers jedes Mal wenn es freigegeben wird.
- [C-1-6] MÜSSEN Nutzern die Möglichkeit bieten, Daten zu löschen,
die
ContentCaptureService
oder die proprietären Mittel erheben, wenn Daten werden in beliebiger Form auf dem Gerät gespeichert. - [C-1-7] MÜSSEN Nutzern die Möglichkeit bieten, die erhobenen Daten zu deaktivieren. über AppSearch oder proprietäre Methoden von der Anzeige auf der Android-Plattform 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.
Wenn Geräteimplementierungen einen Dienst umfassen, der die System API implementiert
ContentCaptureService
, AppSearchManager.index
oder ein proprietärer Dienst
die 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
Android bietet über SpeechRecognizer#onDeviceSpeechRecognizer()
die Möglichkeit,
, um eine Spracherkennung auf dem Gerät durchzuführen, ohne das Netzwerk einzubeziehen.
Die Implementierung von „SpeechDetectr“ auf dem Gerät MUSS den Richtlinien entsprechen.
die in diesem Abschnitt beschrieben werden.
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), es sei denn, die Drittanbieter-App ist der Standard-IME oder die App, im Fokus steht. - [C-0-2] MÜSSEN die Daten in der Zwischenablage höchstens 60 Minuten nach dem letzten Löschen löschen in der Zwischenablage gespeichert 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, aus denen entweder oder in den Standort eines Nutzers umgewandelt werden kann. Dies ist keine umfassende aber als Beispiel dafür verwendet werden, indirekt aus Folgendem abgeleitet werden:
- GPS/GNSS/DGPS/PPP
- Global Positioning Solution oder Global Navigation Satellite System oder Differential Global Positioning-Lösung
- Dazu gehören auch GNSS-Rohmessungen und der GNSS-Status
- Der genaue Standort kann aus den GNSS-Rohmessungen abgeleitet werden.
- Funktechnologien mit eindeutigen IDs wie:
- WLAN-Zugangspunkte (MAC, BSSID, Name oder SSID)
- Bluetooth/BLE (MAC, BSSID, Name oder SSID)
- UWB (MAC, BSSID, Name oder SSID)
- Mobilfunkmast-ID (3G, 4G, 5G... einschließlich aller zukünftigen 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] Die Emergency Location Bypass API MUSS 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 spezielle App-spezifische Verzeichnis der App.
im externen Speicher. Es gelten nur die folgenden Ausnahmen:
- Die Zertifizierungsstelle des externen Speicheranbieters (z. B. Apps wie DocumentsUI)
- Downloadanbieter, der die Anbieterberechtigung „Downloads“ 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 nur auf „obb“-Verzeichnisse zugreifen kann, um 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:TelephonyDebugService
-DumpTelephonyRegistry
-DumpWifiService
-DumpConnectivityService
-Dump- Dump der Instanz
CarrierService
des aufrufenden Pakets (falls gebunden) - Funkprotokollzwischenspeicher
- [C-1-5] DÜRFEN Folgendes in den erstellten Berichten NICHT enthalten:
- 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 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.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
undACTION_USER_UNLOCKED
Intents MÜSSEN weiterhin ü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 512 Bit beträgt. Adiantum bezieht sich auf Adiantum-XChaCha12-AES, wie unter https://github.com/google/adiantum Dateisystemmetadaten sind Daten wie z. B. die Datei Größen, Eigentumsrechte, Modi und erweiterte Attribute (xattrs).
- [C-1-6] MÜSSEN Dateinamen mit AES-256-CBC-CTS 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 Metadatenblöcke des Dateisystems Nichtflüchtiger Speicher wurde mit unterschiedlichen Kombinationen von Verschlüsselungsschlüsseln verschlüsselt. und Initialisierungsvektor (IV).
Schlüssel zum Schutz der CE- und DE-Speicherbereiche und Dateisystemmetadaten:
- [C-1-7] MÜSSEN kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. Dieser Schlüsselspeicher MÜSSEN an den verifizierten Bootmodus und 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 den Signaturschlüssel eines beliebigen Anbieters oder Unternehmens verwenden, um beliebige Produkte zu 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 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 ermöglicht 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 diese Funktion nicht unterstützen. 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] MUSS 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-SR-1] Wenn das Gerät mehrere separate Chips hat (z.B. Funk-, einem speziellen Bildprozessor), ist der Bootvorgang jedes Chips EMPFOHLEN, alle Phasen beim Starten zu überprüfen.
- [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 verwenden 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).
- [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.
Wenn bereits Geräteimplementierungen ohne Unterstützung von C-1-8 bis C-1-11 auf einer früheren Android-Version und kann keine Unterstützung für diese Anforderungen durch ein Systemsoftware-Update erfüllen, KÖNNEN sie von der Anforderungen.
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
Geräteimplementierungen:
- [C-0-3] MÜSSEN die kryptografisch überprüfte Dateiinhalte anhand eines ohne die gesamte Datei zu lesen.
- [C-0-4] DARF NICHT zulassen, dass Leseanfragen für eine geschützte Datei erfolgreich sind Wenn der gelesene Inhalt nicht anhand eines vertrauenswürdigen Schlüssels verifiziert wird.
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.
Geräteimplementierungen:
- [C-SR-4] wird dringend empfohlen, die Android Protected Confirmation API zu unterstützen.
Ob Geräteimplementierungen die Android Protected-Bestätigung unterstützen API:
[C-3-1] MÜSSEN
true
fürConfirmationPrompt.isSupported()
melden der API erstellen.[C-3-2] MÜSSEN sicherstellen, dass der unter Android ausgeführte Code einschließlich seiner ob ein Kernel, bösartig oder anderweitig, keine positive Antwort generieren kann, der Nutzerinteraktion.
[C-3-3] MÜSSEN sicherstellen, dass der Nutzer die selbst wenn das Android-Betriebssystem einschließlich Kernel gefährdet ist.
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 Intervall MUSS mindestens 30 Sekunden betragen für 9 < n < 30. Für n > 29, die Zeitintervallwert MUSS mindestens 30*2^floor((n-30)/10) Sekunden betragen oder mindestens 24 Stunden, je nachdem, welcher Wert kleiner ist.
- SOLLTE 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, SHA1 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. Open-Source-Code 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.
- [C-1-4] MUSS die Schlüsselattestierung unterstützen, wenn der entsprechende Signaturschlüssel durch sichere Hardware geschützt ist, und die Signatur erfolgt auf sicherer Hardware. Die Signaturschlüssel für die Attestierung MÜSSEN für eine ausreichend große Anzahl von um zu verhindern, dass die Schlüssel als Gerätekennungen verwendet werden. Nur Hinflug zur Erfüllung dieser Anforderung besteht darin, denselben Attestierungsschlüssel zu verwenden, es sei denn, werden mindestens 100.000 Einheiten einer Artikelnummer hergestellt. Wenn mehr als 100.000 Einheiten einer Artikelnummer erstellt werden, kann für 100.000 Einheiten ein anderer Schlüssel verwendet werden.
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:
- 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.
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 allen zugehörigen biometrischen Flags (d.h.KEYGUARD_DISABLE_BIOMETRICS
,KEYGUARD_DISABLE_FINGERPRINT
KEYGUARD_DISABLE_FACE
oderKEYGUARD_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 alsPASSWORD_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:
- Die
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
Methode - Die
DevicePolicyManager.setPasswordQuality()
mit einer restriktiveren Qualitätskonstante alsPASSWORD_QUALITY_NONE
. - Die
DevicePolicyManager.setRequiredPasswordComplexity()
mit einem restriktiveren Komplexitäts-Bucket alsPASSWORD_COMPLEXITY_NONE
.
- Die
- [C-6-3] Der Nutzer MUSS zu 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 sofort“ in der Einstellungsmenü und ein gut erkennbares Symbol auf dem Sperrbildschirm.
- [C-7-2] MÜSSEN alle Trust Agent APIs im
DevicePolicyManager
, z. B. dieKEYGUARD_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-8] Der Nutzer MUSS für eine der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) mindestens einmal alle 72 Stunden oder weniger, es sei denn, die Sicherheit des Nutzers (z.B. Ablenkung des Fahrers) ist bedenklich.
- [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 alsPASSWORD_QUALITY_NONE
oder über dasDevicePolicyManager.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
- [C-10-6] MUSS die Erstellung verknüpfter Eingabeereignisse über deaktivieren.
VirtualDeviceManager
, wenn angegeben durchDevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] MUSS für jedes virtuelle Gerät eine separate Zwischenablage verwenden (oder die Zwischenablage für virtuelle Geräte deaktivieren)
- [C-10-11] MÜSSEN die Authentifizierungs-UI auf virtuellen Geräten deaktivieren, einschließlich Eingabe von Wissensfaktoren und biometrischer Prompt
- [C-10-12] MÜSSEN von einem virtuellen Gerät initiierte Intents auf die Anzeige beschränkt werden nur auf demselben virtuellen Gerät
- [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*
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 denTrustState.TRUSTED
, wenn der TrustAgent immer noch Vertrauen gewährt, basierend auf die Anforderungen in C-12-1. - [C-12-4] MUSS
TrustManagerService.revokeTrust()
anrufen- 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:
- Implementierungen mit UWB:
- 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):
- 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:
- Implementierungen mit UWB:
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 Aktivitäten mit dem Attribut „android:canDisplayOnRemoteDevices“ oder dem Metadatenelement „android.activity.can_display_on_remote_devices“ blockieren, das auf „false“ gesetzt ist, damit es nicht auf dem virtuellen Gerät gestartet werden kann .
- [C-13-9] MUSS Aktivitäten blockieren die nicht explizit Streaming und die darauf hinweisen, dass sie sensible Inhalte zeigen, z. B. über SurfaceView#setSecure, FLAG_SECURE oder SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS auf dem virtuellen Gerät gestartet.
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-10] MÜSSEN die gemäß der Secure IC Protection Profile BSI-CC-PP-0084-2014 oder von einem national akkreditierten Testlabor mit Bewertung eines hohen Angriffspotenzials gemäß Common Criteria-Anwendung des Angriffspotenzials Smartcards
- [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 zu verwenden, 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] 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 Untersysteme mit dem 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.
9:17. Android Virtualisierungs-Framework
Wenn auf dem Gerät die Unterstützung der Android Virtualization Framework APIs (android.system.virtualmachine.*
) implementiert ist, gilt für den Android-Host Folgendes:
- [C-1-1] MUSS alle APIs unterstützen, die in den
android.system.virtualmachine.*
-Paket. - [C-1-2] DÜRFEN NICHT das Android SELinux und das Berechtigungsmodell für die der geschützten virtuellen Maschinen verwalten.
- [C-1-3] DÜRFEN die im das System/die Richtlinie, die im vorgelagerten Android-Open-Source-Projekt bereitgestellt werden (AOSP) und die Richtlinie MÜSSEN mit allen "Niezulassen"-Regeln kompiliert werden.
- [C-1-4] DÜRFEN NICHT zulassen, dass mit nicht vertrauenswürdigem Code (z.B. Drittanbieter-Apps) ein Geschützte virtuelle Maschine. Hinweis: Das kann sich in zukünftigen Android-Versionen ändern.
- [C-1-5] DÜRFEN NICHT zulassen, dass eine geschützte virtuelle Maschine Code ausführt, der nicht Teil des Factory Images oder ihrer Updates sind. Alles, was nicht abgedeckt ist durch Android Verified Boot (z.B. Dateien, die aus dem Internet oder Sideloads) DÜRFEN NICHT in einer geschützten virtuellen Maschine ausgeführt werden.
Wenn das Gerät die Unterstützung der Android Virtualization Framework APIs (android.system.virtualmachine.*
) implementiert, gilt für jede Protected Virtual Machine-Instanz Folgendes:
- [C-2-1] MÜSSEN alle Betriebssysteme ausführen können, die in der Virtualisierungs-APEX in einer geschützten virtuellen Maschine.
- [C-2-2] DÜRFEN NICHT zulassen, dass auf einer geschützten virtuellen Maschine ein Betriebssystem ausgeführt wird das nicht vom Geräte-Implementierer oder Betriebssystemanbieter signiert ist.
- [C-2-3] DÜRFEN NICHT zulassen, dass eine geschützte virtuelle Maschine Daten als Code ausführt (Beispiel: SELinux niemals erlaubt Ausführung).
- [C-2-4] DÜRFEN die im das System/sepolicy/microdroid, das in der vorgelagerten Open-Source-Version von Android bereitgestellt wird Projekt (AOSP).
- [C-2-5] MÜSSEN Abwehrmechanismen der Protected Virtual Machine implementieren (z.B. SELinux für pVMs) sogar für Nicht-Microdroid-Betriebssysteme.
- [C-2-6] MÜSSEN sicherstellen, dass die pVM-Firmware nicht gestartet werden kann, wenn sie nicht verifiziert werden kann das Ausgangsbild.
- [C-2-7] MÜSSEN sicherstellen, dass die pVM-Firmware nicht startet, wenn die Integrität Instanz.img wurde manipuliert.
Wenn das Gerät die Unterstützung für die Android Virtualization Framework APIs (android.system.virtualmachine.*
) implementiert, gilt für den Hypervisor Folgendes:
- [C-3-1] DÜRFEN keiner pVM Zugriff auf eine Seite gewähren, die einer anderen Entität (d.h. eine andere pVM oder einen anderen Hypervisor), es sei denn, dies wird von der Seite explizit freigegeben Inhaber. Dies schließt die Host-VM ein. Dies gilt sowohl für CPU- als auch für DMA-Zugriffe.
- [C-3-2] MÜSSEN eine Seite auf Werkseinstellungen zurückgesetzt werden, nachdem sie von einer VM verwendet wird und bevor sie zurückgegeben wird. zum Host (z.B. wenn die pVM gelöscht wird).
- [C-3-3] MÜSSEN sicherstellen, dass die pVM-Firmware geladen und ausgeführt wird, Code in einer pVM.
- [C-3-4] MÜSSEN sicherstellen, dass BCC- und CDIs, die einer pVM-Instanz bereitgestellt werden, nur die von dieser speziellen Instanz abgeleitet wurden.
Wenn auf dem Gerät die Android Virtualization Framework-APIs unterstützt werden, dann für alle Bereiche:
- [C-4-1] DARF KEINE Funktion für eine pVM bereitstellen, die das Umgehen des Android-Sicherheitsmodell
Wenn auf dem Gerät die Unterstützung für die Android Virtualization Framework APIs implementiert ist, gilt Folgendes:
- [C-5-1] MUSS die isolierte Kompilierung einer ART-Laufzeitaktualisierung unterstützen.
Wenn das Gerät die Unterstützung für Android Virtualization Framework APIs implementiert, gilt für die Schlüsselverwaltung Folgendes:
- [C-6-1] MÜSSEN die DICE-Kette an einem Punkt gestartet werden, den der Nutzer nicht ändern kann, auch nicht auf Geräte ohne SIM-Lock. (Um sicherzustellen, dass es nicht gefälscht werden kann)
- [C-6-2] MÜSSEN die richtigen Werte angeben.
10. Software-Kompatibilitätstests
Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen. Beachten Sie jedoch, dass kein Softwaretestpaket vollständig umfassend ist. Aus diesem Grund wird 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 13
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, vorausgesetzt, sie ersetzt das 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 einen Aktualisierungsmechanismus, der 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
Im Folgenden finden Sie eine Zusammenfassung der Änderungen an der Kompatibilitätsdefinition in diesem Release:
4. Oktober 2023
2. Gerätetypen
-
Überarbeitung ansehen
- [9.8/H-1-14] MÜSSEN die Mikrofonanzeige einblenden, wie in Abschnitt 9.8.2 beschrieben.
[9.8/C-3-1], wenn ein erfolgreiches Hotword-Ergebnis an die Stimme übertragen wird
- [9.8/H-1-14] MÜSSEN die Mikrofonanzeige einblenden, wie in Abschnitt 9.8.2 beschrieben.
-
Überarbeitung ansehen
[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 sie unter Last sind. Hier wird die Last als gleichzeitige Auflösung von 1080 bis 720p definiert Video-Transcodierungssitzung mit Hardware-Video-Codecs zusammen mit dem Initialisierung von 1080p-Audio-/Videoaufnahmen. Für den Dolby Vision-Codec Die Latenz der Codec-Initialisierung MUSS höchstens 50 ms betragen.
[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 Video-Transcodierungssitzung 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.
7.4 Datenverbindung
7.4.1.1 Kompatibilität mit Nummernblockierungen:
Überarbeitung ansehen
Wenn Geräteimplementierungen die Funktion
android.hardware.telephony.calling
melden, geschieht Folgendes:-
Überarbeitung ansehen
Wenn Geräteimplementierungen
android.hardware.telephony.calling
melden, geschieht Folgendes:
9.11 Schlüssel und Anmeldedaten
-
Überarbeitung ansehen
wird über den IAuthSecret HAL bereitgestellt.
Entfernt: IAR wird in Android 14 eine MUSS-Anforderung sein.
26. Juni 2023
2. Gerätetypen
-
Entfernte Anforderungen 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7
Anderes Update:
Überarbeitung ansehen
Es wird dringend empfohlen, die unter
Anforderungen für die Anwesenheitskalibrierung:
-
Überarbeitung ansehen
Bei Automotive-Geräten mit 32-Bit-Implementierungen:
[7.6.1/A-1-1] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 512 MB groß sein, wenn eine der folgenden Dichten verwendet wird:
- 280 dpi oder niedriger auf kleinen/normalen Bildschirmen
- LDPI oder niedriger auf sehr großen Bildschirmen
- mdpi oder niedriger auf großen Bildschirmen
[7.6.1/A-1-2] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerbereich MUSS mindestens 608 MB betragen, wenn eine der folgenden Dichten verwendet wird:
- xhdpi oder höher auf kleinen/normalen Bildschirmen
- HDPI oder mehr auf großen Bildschirmen
- mdpi oder höher auf extragroßen Bildschirmen
[7.6.1/A-1-3] 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
[7.6.1/A-1-4] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 1.344 MB groß sein, wenn eine der folgenden Dichten verwendet:
- 560 dpi oder höher auf kleinen/normalen Bildschirmen
- Mindestens 400 dpi auf großen Bildschirmen
- xhdpi oder höher auf extragroßen Bildschirmen
3. Software
3.2.3.5 Bedingte Anwendungs-Intents
Überarbeitung ansehen
Wenn Geräteimplementierungen die Meldung android.hardware.telephony.calling erhalten
Sie:android.hardware.telephony
7. Hardwarekompatibilität
-
Überarbeitung ansehen
Anforderungen für die Anwesenheitskalibrierung:
9. Kompatibilität des Sicherheitsmodells
-
Überarbeitung ansehen
Geräteimplementierungen:
[C-0-5]
VorinstalliertDARF KEINE Laufzeitberechtigungen gewährt werden. Apps, es sei denn:- Sie werden zum Zeitpunkt der Gerätelieferung installiert UND
- Die Einwilligung des Nutzers kann vor der Anwendung eingeholt werden
verwendet
itdie Berechtigung,
OR
- Laufzeitberechtigungen werden vom Nutzer gewährt,
Standardrichtlinie zur Erteilung von Berechtigungen
oder für eine Plattformfunktion.
, die mit einem Intent-Muster verknüpft sind für die die vorinstallierte App als Standard-Handler festgelegt ist.
9.11 Schlüssel und Anmeldedaten
- Anforderungen [C-13-10] und 9.11.4 entfernt.
20. März 2023
2. Gerätetypen
-
Überarbeitung ansehen
Wenn die Einstellungsanwendung der Implementierung von Handheld-Geräten eine Aufteilungsfunktion, mithilfe der Aktivitätseinbettung:
- [
C-17-13.2.3.1/ H-1-1] MUSS eine Aktivität haben, die den Einstellungen#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY Intent erstellt, wenn die Aufteilungsfunktion aktiviert ist. Die Aktivität MUSS geschützt sein durchandroid.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.
Neue Anforderungen beenden
- [
-
Überarbeitung ansehen
Wenn Implementierungen von Fernsehgeräten mit VP9-Hardwaredecoder VP9 unterstützen und das UHD-Decodierungsprofil:
- [5.3.7/T-
2-1SR1] WIRD UNBEDINGT EMPFOHLEN, die UHD-Decodierung zu unterstützen Profil bei 60 Bildern pro Sekunde mit Profil 2 (10 Bit Farbtiefe).
- [5.3.7/T-
-
Überarbeitung ansehen
Implementierungen von Automobilgeräten:
[7.3/A-
0-1SR1] KANN höchstwahrscheinlich die Standortermittlung durch die Kombination von GPS/GNSS mit zusätzlichen Sensoren beeinträchtigen. Wenn Standort ist UNBEDINGT EMPFOHLEN, zugehöriger Sensor und/oder Fahrzeugeigenschaften-IDs verwendet.[7.3/A-
0-20-4] Standort angefordert über LocationManager#requestLocationUpdates() DÜRFEN KEINE Zuordnung zu einer Karte erhalten.
3. Software
-
Überarbeitung ansehen
Standardkonto für neue Kontakte:Der Contacts Provider stellt APIs zur Verwaltung bereit. die Einstellung des Standardkontos, wenn Sie einen neuen Kontakt erstellen.
Wenn auf Geräten eine App „Kontakte“ vorab geladen wird, App:
[C-2-1] MÜSSEN den Intent verarbeiten.
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
zum Starten einer Benutzeroberfläche für Kontoauswahl und speichern Sie die Einstellung in Contacts Provider, wenn ein Konto ausgewählt.[C-2-2] MÜSSEN bei der Handhabung von
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
für denContactsContracts.Contacts.CONTENT_TYPE
undContactsContract.RawContacts.CONTENT_TYPE
festlegen, indem Sie zuerst die Konto.
Neue Anforderungen beenden
3.2.3.5 Bedingte Anwendungs-Intents
Überarbeitung ansehen
[Zu 2.2.3 verschoben]
Wenn in den Einstellungen der Geräteimplementierung ein Aufteilungsfunktion, mithilfe der Aktivitätseinbettung:
- [C-17-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 durch
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
geschützt werden und MÜSSEN MÜSSEN Aktivität des Intents starten, der geparst wird von Einstellungen#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
Neue Anforderungen beenden
- [C-17-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 durch
6. Kompatibilität von Entwicklertools und -optionen
-
Überarbeitung ansehen
- Affe
- [C-0-8] MÜSSEN das Monkey-Framework enthalten und für Anwendungen.
- Affe
7. Hardwarekompatibilität
-
Überarbeitung ansehen
[In Version 7.4.9 verschoben]
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-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-1-6] WIRD UNBEDINGT EMPFOHLEN, die relevanten Konformitäts- und Zertifizierungstests, die von Standardorganisationen definiert wurden, darunter: FIRA und CC und CSA.
Neue Anforderungen beenden
-
Überarbeitung ansehen
Wenn Geräteimplementierungen
GSM- oder CDMA-Telefoniedieandroid.hardware.telephony
-Funktion melden, dann:- [C-6-1] Die
SmsManager#sendTextMessage
undSmsManager#sendMultipartTextMessage
MÜSSEN zu entsprechenden Aufrufen an führen.CarrierMessagingService
zur Bereitstellung von SMS-Funktionen.SmsManager#sendMultimediaMessage
undSmsManager#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 entsprechendeTelephonyManager#ACTION_SECRET_CODE
Nachricht an alle. - [C-6-4] Die Anwendung, die auf
Intent#ACTION_DIAL
MÜSSEN verwendenVoicemailContract.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
oderEuiccManager#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 die Geräteimplementierungen
GSM- oder CDMA-Telefoniebeinhalten, melden Sie denandroid.hardware.telephony
und stellen Sie eine Systemstatusleiste bereit. Gehen Sie dann so vor:- [C-
6-7-1] MUSS ein repräsentatives aktives Abo für eine bestimmte 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
GSM- oder CDMA-Telefonie umfassen, melden Sie denandroid.hardware.telephony
Funktion und dann:- [C-6-
87] 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-
108] DÜRFEN KEINE der folgenden Verhaltensweisen auf aktive Mobilfunkanbieter-Apps anwenden. (gemäßTelephonyManager#getCarrierServicePackageName
) automatisch oder ohne ausdrückliche Bestätigung durch den Nutzer:- 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
GSM- oder CDMA-Telefonieeinschließen, melden Sie dieandroid.hardware.telephony
-Funktion und alle aktive, nicht opportunistische Abos Gruppen-UUIDs deaktiviert sind,vom Gerät entfernt werden, als opportunistisch gekennzeichnet ist,- [C-
78-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-
89-1] DARF NICHTPackageManager#FEATURE_TELEPHONY_CDMA
deklarieren. - [C-
89-2] MÜSSEN bei Versuchen, einen beliebigen Wert festzulegen,IllegalArgumentException
auslösen. 3GPP2-Netzwerktypen in bevorzugten oder zulässigen Bitmasken des Netzwerktyps. - [C-
89-3] MUSS einen leeren String ausTelephonyManager#getMeid
Wenn die Geräteimplementierungen eUICCs mit mehreren Ports und Profilen unterstützen, gilt Folgendes:
- [C-
1110-1] MUSS dieandroid.hardware.telephony.euicc.mep
Funktions-Flag.
- [C-6-1] Die
-
Überarbeitung ansehen
Wenn Geräteimplementierungen die Unterstützung einer Funktion meldenWenn Geräteimplementierungen Support für 802.1.15.4 und stellen die Funktionalität einer Drittanbieteranwendung zur Verfügung. dann:android.hardware.uwb
über dieandroid.content.pm.PackageManager
- [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-
16] MUSS 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-
27] MUSS 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, der mit der Vorderseite nach oben gehalten und geneigt ist 45 Grad. - [C-SR-2] Wir empfehlen dringend, die Schritte zur Einrichtung der Analyse zu befolgen angegeben in Voraussetzungen für die Anwesenheitskalibrierung
Es wird dringend empfohlen, Einrichtungsschritte, die unter Anforderungen für die Anwesenheitskalibrierung aufgeführt sind.Neue Anforderungen beenden
7.8.2.2 Digitale Audioanschlüsse
Überarbeitung ansehen
Um mit den Headsets und anderen Audiozubehör mit USB-C-Anschlüssen und Implementierung (USB-Audioklasse) im gesamten Android-Ökosystem gemäß Definition in der Android-Spezifikation für USB-Headsets.
19. Oktober 2022
2. Gerätetypen
-
Überarbeitung ansehen
Wenn Handheld-Implementierungen nicht in Sperrmodus Wenn Inhalte in die Zwischenablage kopiert werden, gilt Folgendes:
- [3.8.17/H-1-1] MUSS eine Bestätigung für dass die Daten in die Zwischenablage kopiert (z. B. eine Miniaturansicht oder eine Warnung, dass der Inhalt kopiert wurde). Gib hier außerdem an, ob die Daten in der Zwischenablage synchronisiert werden geräteübergreifend.
3. Software
3.2.3.5 Bedingte Anwendungs-Intents
Überarbeitung ansehen
Wenn in den -Einstellungen der Geräteimplementierung ein Aufteilungsfunktion, mithilfe der Aktivitätseinbettung dann:
- [C-17-1] MÜSSEN über eine Aktivität verfügen,
Einstellungen#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
Intent erstellt, wenn die Aufteilungsfunktion aktiviert ist. Die Aktivität MUSS geschützt sein
von
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
und sie MÜSSEN die Aktivität des Intents starten, der geparst von Einstellungen#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
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
berücksichtigen Standard-App-Einstellungsmenü für Spracheingabe und Unterstützung anzeigen.
- [C-17-1] MÜSSEN über eine Aktivität verfügen,
Einstellungen#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
Intent erstellt, wenn die Aufteilungsfunktion aktiviert ist. Die Aktivität MUSS geschützt sein
von
-
Überarbeitung ansehen
- [C-1-4]MÜSSEN die oder Remote-URL-Inhalte in einem Prozess, der von der Anwendung abweicht, die die WebView instanziiert. Insbesondere MUSS der separate Renderer-Prozess weniger Berechtigungen haben, als separate Nutzer-ID ausgeführt werden, keinen Zugriff auf das Datenverzeichnis der App haben, keinen direkten Netzwerkzugriff haben und nur auf die mindestens erforderlichen Systemdienste über Binder zugreifen können. Die AOSP-Implementierung von WebView erfüllt diese Anforderung.