1. Einführung
In diesem Dokument werden die Anforderungen aufgeführt, die bei Geräten erfüllt werden müssen. um mit Android 15 kompatibel zu sein.
Die Verwendung von "MUSS", "DARF NICHT", "ERFORDERLICH", "WIRD", "WIRD NICHT", "SOLLTE", „Sollte nicht“, „EMPFOHLEN“, „KANN“ und „OPTIONAL“ entspricht dem IETF-Standard die in RFC 2119 definiert sind.
Wie in diesem Dokument verwendet, oder „Implementierer“ ist eine Person oder eine Organisation, die eine Hardware-/Softwarelösung mit Android entwickelt 15. Eine „Geräteimplementierung“ oder „Implementierung“ ist der Hardware-/Softwarelösung entwickelt.
Damit das Gerät mit Android 15 kompatibel ist, muss das Gerät Implementierungen MÜSSEN den Anforderungen dieser Kompatibilitäts- Definition, einschließlich aller Dokumente, die durch Verweis aufgenommen wurden.
Wenn diese Definition oder die im Abschnitt Abschnitt 10 nicht verständlich, mehrdeutig oder ist es in der Verantwortung der Geräteimplementierung, sicherzustellen, Kompatibilität mit bestehenden Implementierungen.
Aus diesem Grund bietet das Open-Source-Projekt von Android ist sowohl die Referenz als auch die bevorzugte Implementierung von Android. Gerät Implementierer wird dringend empfohlen, ihre Implementierungen auf die größtmögliche Reichweite bei der "Upstream"- im Quellcode verfügbar: Open-Source-Projekt von Android Auch wenn einige Komponenten hypothetisch durch alternative Implementierungen ersetzt werden, wird UNBEDINGT EMPFOHLEN, befolgen Sie diese Praxis, da das Bestehen der Softwaretests im Wesentlichen schwieriger wird. Es liegt in der Verantwortung der implementierenden Person, Verhaltenskompatibilität mit der standardmäßigen Android-Implementierung, einschließlich und über die Kompatibilitätstest-Suite hinaus. Beachten Sie, dass bestimmte Komponenten Ersetzungen und Änderungen sind in diesem Dokument ausdrücklich untersagt.
Viele der in diesem Dokument verlinkten Ressourcen sind direkt abgeleitet oder indirekt vom Android SDK bereitgestellt werden. Außerdem sind sie funktionell identisch mit dem in der Dokumentation des SDKs. In allen Fällen, in denen diese Kompatibilität Die Definition oder die Kompatibilitätstest-Suite stimmt nicht mit dem SDK überein Dokumentation als maßgeblich gilt die SDK-Dokumentation. Alle technischen Details, die in den verlinkten Ressourcen in diesem Dokument enthalten sind, werden als Teil dieser Kompatibilitätsdefinition angesehen.
1.1 Dokumentstruktur
1.1.1 Anforderungen nach Gerätetyp
Abschnitt 2 enthält alle Anforderungen, die für eine Gerätetyp verwendet werden. Jeder Unterabschnitt von Paragraf 2 die für einen bestimmten Gerätetyp vorgesehen sind.
Alle anderen Anforderungen, die allgemein für alle Android-Geräte gelten finden Sie in den Abschnitten nach Abschnitt 2. Diese Anforderungen werden als „zentrale Anforderungen“ bezeichnet. in diesem Dokument.
1.1.2 Anforderungs-ID
Für MUSS-Anforderungen wird eine Anforderungs-ID zugewiesen.
- Die ID wird nur für MUSS-Anforderungen zugewiesen.
- Anforderungen werden als [SR] gekennzeichnet, aber keine ID zugewiesen.
- Die ID besteht aus folgenden Komponenten : Gerätetyp-ID - Bedingungs-ID - Anforderungs-ID (z.B. C-0-1).
Jede ID ist wie folgt definiert:
- Gerätetyp-ID (weitere Informationen unter 2. Gerätetypen)
<ph type="x-smartling-placeholder">
- </ph>
- C: Kern (Anforderungen, die für alle Implementierungen von Android-Geräten gelten)
- H: Android-Handheld-Gerät
- T: Android TV-Gerät
- A: Android Automotive-Implementierung
- W: Android Watch-Implementierung
- Tab: Android-Tablet-Implementierung
- Bedingungs-ID
<ph type="x-smartling-placeholder">
- </ph>
- Wenn die Anforderung unbedingt erforderlich ist, wird diese ID auf 0 gesetzt.
- Wenn die Anforderung bedingt ist, wird für die erste und die Zahl erhöht sich im selben Abschnitt um 1 denselben Gerätetyp.
- Anforderungs-ID
<ph type="x-smartling-placeholder">
- </ph>
- Diese ID beginnt bei 1 und erhöht sich im selben Abschnitt Bedingung erfüllt werden.
1.1.3 Anforderungs-ID in Abschnitt 2
Die Anforderungs-IDs in Abschnitt 2 bestehen aus zwei Teilen. Das erste entspricht einer Abschnitts-ID wie oben beschrieben. Der zweite Teil identifiziert die Formfaktor und die formfaktorspezifischen Anforderungen.
Abschnitts-ID gefolgt von der oben beschriebenen Anforderungs-ID.
- Die in Abschnitt 2 aufgeführte ID setzt sich wie folgt zusammen : Abschnitts-ID / Gerätetyp-ID – Bedingungs-ID – Anforderungs-ID (z.B. 7.4.3/A-0-1).
2. Gerätetypen
Das Open-Source-Projekt von Android bietet einen Software-Stack, für verschiedene Gerätetypen und Formfaktoren. Um die Sicherheit auf Geräten zu unterstützen, Softwarestack, einschließlich eines Ersatzbetriebssystems oder eines alternativen Kernels in einer sicheren Umgebung ausgeführt werden, und an anderen Stellen dieser CDD-Datei. Es gibt verschiedene Gerätetypen, die über ein besser etabliertes Ökosystem für die Anwendungsverteilung verfügen.
In diesem Abschnitt werden diese Gerätetypen und zusätzliche Anforderungen sowie Empfehlungen für jeden Gerätetyp.
Alle Implementierungen von Android-Geräten, die in keine der beschriebenen Gerätetypen MÜSSEN weiterhin alle Anforderungen in den anderen Abschnitten dieser Kompatibilitätsdefinition.
2.1 Gerätekonfigurationen
Für die wichtigsten Unterschiede bei der Hardwarekonfiguration nach Gerät finden Sie in den gerätespezifischen Anforderungen in diesem Abschnitt.
2.2. Anforderungen an Handhelds
Ein Android-Handheld-Gerät bezieht sich auf eine Android-Geräteimplementierung, die in der Regel in der Hand gehalten werden, etwa bei einem MP3-Player, einem Telefon oder Tablet.
Implementierungen von Android-Geräten werden als Handhelds eingestuft, wenn sie alle folgenden Kriterien:
- eine Stromquelle nutzen, die Mobilität ermöglicht, z. B. einen Akku.
- Bildschirmgröße in einem Bereich von 4 Zoll bis 8 Zoll.
- über eine Touchscreen-Eingabeoberfläche verfügen.
Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten nur für Android. Implementierungen von Handheld-Geräten.
2.2.1. Hardware
Implementierungen von Handheld-Geräten:
- [7.1.1.1/H-0-1] MUSS mindestens einen Wert haben Android-kompatibles Display mit einer Größe von mindestens 2,2 Zoll an der kurzen Seite und 3,4" an der langen Seite.
[7.1.1.3/H-SR-1] sind DRINGEND empfohlen, Nutzern die Möglichkeit bieten, die Displaygröße (Bildschirmdichte) zu ändern.
[7.1.1.1/H-0-2] MUSS die GPU-Zusammensetzung von Grafikpuffer, die mindestens so groß sind wie die höchste Auflösung Display.
[7.1.1.1/H-0-3]* MÜSSEN jeden
UI_MODE_NORMAL
zuordnen. Display, das für Anwendungen von Drittanbietern zur Verfügung gestellt wird, auf einem gut sichtbaren mit einer Fläche von mindestens 2,2" Zoll an der kurzen Seite und 8,9 cm Zoll an der langen Seite.[7.1.1.3/H-0-1]* MUSS den Wert von
DENSITY_DEVICE_STABLE
muss mindestens 92% der tatsächlichen physischen Dichte entsprechen. des entsprechenden Bildschirms.
Wenn Implementierungen von Handheld-Geräten Vulkan unterstützen, gilt Folgendes:
- [7.1.4.2/H-1-1] MUSS die Anforderungen erfüllen im Profil Android Baseline 2021 angegeben.
Wenn die Implementierung von Handheld-Geräten Unterstützung für High Dynamic Range fordert
wird bis Configuration.isScreenHdr()
angezeigt
,
Sie:
- [7.1.4.5/H-1-1] MUSS Support für den
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
,EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
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, wie er von den vorgelagerten offenen Android-Geräten implementiert wurde Quellcode verfügbar. Das heißt, Geräteimplementierungen DÜRFEN NICHT die Auslöser oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert ist, und DÜRFEN NICHT verändern, des Kompatibilitätsmodus selbst.
- [7.2.1/H-0-1] MÜSSEN Support für Drittanbieter IME-Anwendungen (Input Method Editor)
- [7.2.3/H-0-2] MÜSSEN sowohl das normale als auch das lange Drücken senden.
Ereignis der Zurück-Funktion (
KEYCODE_BACK
) zur Anwendung im Vordergrund. Diese Ereignisse DÜRFEN NICHT vom System verarbeitet werden. und KANN von außerhalb des Android-Geräts ausgelöst werden (z. B. durch externe Hardware). Tastatur, die mit dem Android-Gerät verbunden ist). - [7.2.3/H-0-3] MUSS die Home-Funktion auf auf allen mit Android kompatiblen Bildschirmen, die den Startbildschirm nutzen.
- [7.2.3/H-0-4] MUSS die Funktion „Back“ bei allen die mit Android kompatiblen Displays und die Funktion „Zuletzt verwendet“ auf mindestens einem der auf den mit Android kompatiblen Displays.
- [7.2.4/H-0-1] MUSS die Touchscreen-Eingabe unterstützen.
- [7.2.4/H-SR-1] wird dringend empfohlen,
vom Nutzer ausgewählte Assistent-App, d. h. die App, die
VoiceInteractionService oder eine Aktivität, die
ACTION_ASSIST
verarbeitet, durch langes Drücken 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.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn die Geräte das NAN-Protokoll (Wi-Fi Neighbor Awareness Networking) unterstützen,
Angeben von PackageManager.FEATURE_WIFI_AWARE
und WLAN-Standort (Wi-Fi Round
Fahrtzeit – RTT), indem sie PackageManager.FEATURE_WIFI_RTT
deklarieren, dann gilt Folgendes:
[7.4.2.5/H-1-1] MÜSSEN den Bereich genau an innerhalb von +/- 1 Meter bei einer Bandbreite von 160 MHz im 68. Perzentil (gemäß Berechnung mit der kumulativen Verteilungsfunktion) +/- 2 Meter bei 80 MHz Bandbreite bei das 68. Perzentil, +/- 4 Meter bei 40 MHz Bandbreite beim 68. Perzentil, und +/- 8 Meter bei einer Bandbreite von 20 MHz im 68. Perzentil bei Entfernungen von 10 cm, 1 m, 3 m und 5 m, wie aus dem WifiRttManager#startRanging Android API
[7.4.2.5/H-SR-1] wird dringend empfohlen, Bereich genau im Bereich +/- 1 Meter bei 160 MHz Bandbreite am 90. Perzentil (wie mit der Funktion für kumulierte Verteilung berechnet), +/-2 Meter bei einer Bandbreite von 80 MHz beim 90. Perzentil, +/- 4 Meter bei 40 MHz Bandbreite beim 90. Perzentil und +/- 8 Meter bei 20 MHz Bandbreite bei 90. Perzentil bei einem Abstand von 10 cm, aus Sicht des WifiRttManager#startRanging Android API
Es wird dringend empfohlen, die unter Anwesenheitskalibrierung:
Wenn in Implementierungen von Handheld-Geräten FEATURE_BLUETOOTH_LE
deklariert ist, gilt Folgendes:
- [7.4.3/H-1-3] MUSS Rx messen und kompensieren
Offset, um sicherzustellen, dass der Medianwert BLE RSSI bei -50 dBm +/-15 dB bei 1 m Abstand von einem
Referenzgerät, das um
ADVERTISE_TX_POWER_HIGH
überträgt. - [7.4.3/H-1-4] MÜSSEN die Tx messen und kompensieren.
Offset, um sicherzustellen, dass der Medianwert für BLE RSSI bei -50 dBm +/-15 dB beim Scannen von einer
Referenzgerät, das in 1 m Entfernung positioniert ist und bei
ADVERTISE_TX_POWER_HIGH
Wenn Handheld-Implementierungen ein logisches Kameragerät enthalten, das
mit
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
,
Sie:
- [7.5.4/H-1-1] MUSS standardmäßig ein normales Sichtfeld haben und er muss zwischen 50 und Grad.
Implementierungen von Handheld-Geräten:
- [7.6.1/H-0-1] MUSS mindestens 4 GB an nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet).
- [7.6.1/H-0-2] MUSS "true" zurückgeben für
ActivityManager.isLowRamDevice()
, wenn weniger als 1 GB Arbeitsspeicher vorhanden ist für den Kernel und Userspace.
Wenn Implementierungen von Handheld-Geräten nur eine 32-Bit-ABI unterstützen:
[7.6.1/H-1-1] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerfläche MUSS mindestens 416 MB betragen, wenn die Standardanzeige Framebuffer verwendet. Auflösungen bis qHD (z.B. FWVGA).
[7.6.1/H-2-1] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerfläche MUSS mindestens 592 MB betragen, wenn die Standardanzeige Framebuffer verwendet. Auflösungen bis HD+ (z.B. HD, WSVGA).
[7.6.1/H-3-1] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerfläche MUSS mindestens 896 MB betragen, wenn die Standardanzeige Framebuffer verwendet. Auflösungen bis FHD (z.B. WSXGA+).
[7.6.1/H-4-1] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerbereich MUSS mindestens 1.344 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis zu QHD (z.B. QWXGA).
Wenn Implementierungen von Handheld-Geräten die Unterstützung von 64-Bit-ABIs (mit oder ohne 32-Bit-ABI) deklarieren:
[7.6.1/H-5-1] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 816 MB groß, wenn der Standardbildschirm höhere Framebuffer-Auflösungen verwendet zu qHD (z.B. FWVGA).
[7.6.1/H-6-1] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 944 MB, wenn der Standardbildschirm Framebuffer-Auflösungen bis HD+ verwendet (z.B. HD, WSVGA).
[7.6.1/H-7-1] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 1.280 MB, wenn der Standardbildschirm Framebuffer-Auflösungen bis zu FHD verwendet (z.B. WSXGA+).
[7.6.1/H-8-1] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 1.824 MB, wenn der Standardbildschirm Framebuffer-Auflösungen bis zu QHD verwendet (z.B. QWXGA).
Beachten Sie, dass der für Kernel und Userspace verfügbare Arbeitsspeicher bezieht sich auf den Arbeitsspeicher zusätzlich zu dem bereits für Hardware vorgesehenen Arbeitsspeicher wie Radio, Video usw., die sich nicht im Kernel- Geräteimplementierungen steuern.
Implementierung von Handheld-Geräten mit weniger als oder gleich 1 GB Arbeitsspeicher dem Kernel und Userspace zur Verfügung stehen,
- [7.6.1/H-9-1] MUSS das Funktions-Flag deklarieren.
android.hardware.ram.low
- [7.6.1/H-9-2] MUSS mindestens 1,1 GB an nichtflüchtiger Speicher für Anwendungen private Daten (auch als „/data“-Partition bezeichnet).
Wenn Handheld-Implementierungen mehr als 1 GB Speicherplatz enthalten an den Kernel und Userspace haben,
- [7.6.1/H-10-1] MUSS mindestens 4 GB an nichtflüchtiger Speicher verfügbar für Anwendungsdaten (auch als "/data"-Partition bezeichnet).
- SOLLTEN das Funktions-Flag
android.hardware.ram.normal
deklarieren.
Wenn Implementierungen von Handheld-Geräten größer oder gleich 2 GB sind und weniger als 4 GB Speicher für den Kernel und Userspace verfügbar sind, gilt Folgendes:
- [7.6.1/H-SR-1] WIRD UNBEDINGT EMPFOHLEN, nur 32-Bit-Userspace zu unterstützen (sowohl Apps als auch Systemcode)
Wenn die Implementierung von Handheld-Geräten weniger als 2 GB Speicherplatz Kernel und Userspace fest:
- [7.6.1/H-1-1] DARF nur eine einzige ABI unterstützen (entweder nur 64-Bit oder 32-Bit). )
Implementierungen von Handheld-Geräten:
- [7.6.2/H-0-1] DARF KEINEN Antrag einreichen gemeinsam genutzter Speicher kleiner als 1 GiB ist.
- [7.7.1/H] SOLLTEN einen USB-Anschluss haben, der den Peripheriemodus unterstützt.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Handheld-Geräte einen USB-Port enthalten
unterstützen
mit einem Controller in
Peripheriemodus verwenden sie:
- [7.7.1/H-1-1] MUSS Android Open Accessory (AOA) implementieren. der API erstellen.
Neue Anforderungen beenden
Wenn die Implementierung von Handheld-Geräten einen USB-Port umfasst, der den Hostmodus unterstützt, Sie:
- [7.7.2/H-1-1] MUSS die USB-Audioklasse implementieren wie in der Android SDK-Dokumentation beschrieben.
Implementierungen von Handheld-Geräten:
- [7.8.1/H-0-1] MUSS ein Mikrofon enthalten.
- [7.8.2/H-0-1] MUSS einen Audioausgang haben und deklarieren
android.hardware.audio.output
Ob Handheld-Implementierungen die gesamte Leistung Voraussetzungen für die Unterstützung des VR-Modus:
- [7.9.1/H-1-1] MUSS die
Funktions-Flag
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] MUSS eine App enthalten
Implementierung von
android.service.vr.VrListenerService
, die mit VR aktiviert werden können ü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
isSink()
, wenn das Feld für den USB-Audio-Terminaltyp 0x0302 lautet.[7.8.2.2/H-4-2] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_HEADSET und Rolle
isSink()
, wenn das USB-Audio-Terminal Typ ist 0x0402.[7.8.2.2/H-4-3] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_HEADSET und Rolle
isSource()
, wenn das USB-Audio-Terminal Typ ist 0x0402.[7.8.2.2/H-4-4] MÜSSEN ein Gerät vom Typ AudioDeviceInfo.TYPE_USB_DEVICE auflisten. und
isSink()
, wenn das Feld für den USB-Audio-Terminaltyp 0x603 lautet.[7.8.2.2/H-4-5] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_DEVICE und Rolle
isSource()
, wenn das USB-Audioterminal Typ ist 0x604.[7.8.2.2/H-4-6] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_DEVICE und Rolle
isSink()
, wenn der USB-Audio-Terminaltyp 0x400 ist.[7.8.2.2/H-4-7] MUSS einen Gerätetyp angeben AudioDeviceInfo.TYPE_USB_DEVICE und Rolle
isSource()
, wenn das USB-Audioterminal Typ ist 0x400.[7.8.2.2/H-SR-1] werden dringend empfohlen bei Anschluss eines USB-C-Audio-Peripheriegerät, um eine Aufzählung der USB-Deskriptoren durchzuführen, Terminaltypen und Broadcast-Intent ACTION_HEADSET_PLUG in weniger als 1.000 Millisekunden.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn
Für
Implementierungen von Handheld-Geräten
die erklären,
android.hardware.audio.output
und android.hardware.microphone
,
er/sie:
Weitere Informationen zu RTL- und TTL-Anforderungen im Abschnitt
5.6
[5.6/H-1-1] MUSS einen mittleren kontinuierlichen Hin- und Rückflug haben eine Latenz von 300 Millisekunden weniger über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 30 ms, mehr die folgenden Datenpfade: „Lautsprecher zu Mikrofon“, 3,5-mm-Loopback-Adapter (falls unterstützt), USB-Loopback-Adapter (falls unterstützt).
[5.6/H-1-2] MUSS eine durchschnittliche Latenz von Tap-to-Ton haben. von 300 Millisekunden oder Weniger als mindestens 5 Messungen über dem Lautsprecher zum Mikrofondatenpfad.
Neue Anforderungen beenden
Ein linearer Resonanzaktuator (LRA) ist ein System mit einer Massenfeder, das dominante Resonanzfrequenz, bei der sich die Masse in Richtung des gewünschte Bewegung.
Wenn Implementierungen für Handheld-Geräte mindestens einen allgemeinen Zweck erfüllen: 7.10 linearen Resonanzantrieb,
[7.10/H] SOLLTE die Position des Bedienelements in der Nähe von Die Stelle, an der das Gerät normalerweise mit den Händen gehalten oder berührt wird.
[7,10/H] SOLLTEN Sie den haptischen Auslöser in der X-Achse verschieben. (links-rechts) der natürlichen Ausrichtung des Geräts entspricht.
Wenn Implementierungen von Handheld-Geräten einem allgemeinen Zweck dienen einen haptischen Aktivator, also einen X-Achsen-Linear-Resonantenaktuator (Linear Resonant Actuator, LRA), ihn:
- [7,10/H] SOLLTE die Resonanzfrequenz des LRA auf der X-Achse unter 200 Hz liegen.
Wenn Implementierungen von Handheld-Geräten der Zuordnung haptischer Konstanten folgen, gilt Folgendes:
- [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:
- [5.3/H-0-1] H.264 AVC
- [5.3/H-0-2] H.265 HEVC
- [5.3/H-0-3] MPEG-4 SP
- [5.3/H-0-4] VP8
- [5.3/H-0-5] VP9
- [5.3/H-0-6] AV1
2.2.3. Software
Implementierungen von Handheld-Geräten:
- [3.2.3.1/H-0-1] MUSS einen
die
ACTION_GET_CONTENT
verarbeitet,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
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 Geräteimplementierungen die Navigationstaste für die Funktion „Recents“ (Zuletzt verwendet) als wie in Abschnitt 7.2.3 beschrieben, verändern sich die Oberfläche wie folgt:
- [3.8.3/H-1-1] MUSS den Bildschirm implementieren Funktion zum Anpinnen und stellen dem Nutzer ein Einstellungsmenü zur Verfügung, in dem er die Einstellungen .
Wenn Implementierungen von Handheld-Geräten die Assist-Aktion unterstützen, gilt Folgendes:
- [3.8.4/H-SR-2] werden dringend empfohlen.
um die entsprechende Interaktion zu starten, indem du die
HOME
-Taste lange drückst. wie in Abschnitt 7.2.3 beschrieben beschrieben. MUSS gestartet werden die vom Nutzer ausgewählte Assistent-App, d. h. die App,VoiceInteractionService
, oder eine Aktivität, die den 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
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.[3.8.16/H-1-6] Geräteimplementierungen MÜSSEN die Nutzerangebote wie folgt korrekt wiedergeben:
- Wenn auf dem Gerät
config_supportsMultiWindow=true
festgelegt ist und die App die Metadaten deklariertMETA_DATA_PANEL_ACTIVITY
in derControlsProviderService
-Deklaration, einschließlich des ComponentName einer gültige Aktivität (wie von der API definiert) gilt, MUSS die App die folgenden in diesem Angebot. - Wenn in der App keine Metadaten
META_DATA_PANEL_ACTIVITY
deklariert sind, dann MÜSSEN die angegebenen Felder wie vomControlsProviderService
API sowie in den vom Steuere-APIs.
- Wenn auf dem Gerät
[3.8.16/H-1-7] Wenn die App die Metadaten deklariert
META_DATA_PANEL_ACTIVITY
, Es MUSS den Wert der in [3.8.16/H-1-5] definierten Einstellung mitEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
beim Starten der eingebetteten Aktivität.
Umgekehrt gilt: Wenn solche Steuerungen nicht in Handheld-Implementierungen implementiert sind, Sie:
- [3.8.16/H-2-1] MÜSSEN
null
melden fü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 die Meldung „Inhalt kopiert“). Gib hier außerdem an, ob die Daten in der Zwischenablage synchronisiert werden geräteübergreifend.
Implementierungen von Handheld-Geräten:
- [3.10/H-0-1] MUSS die Barrierefreiheit von Drittanbietern unterstützen .
- [3.10/H-SR-1] wird dringend empfohlen, vorab zu laden. Bedienungshilfen auf dem Gerät, die mit der Funktionalität vergleichbar oder sogar übertreffen des Schalterzugriffs und von TalkBack (für Sprachen, die vom vorinstallierten Bedienungshilfen (Text-in-Sprache-Engine), die in der offenen TalkBack-Funktion bereitgestellt werden Quellprojekt.
- [3.11/H-0-1] MUSS die Installation von Sprachausgabe-Engines von Drittanbietern.
- [3.11/H-SR-1] wird dringend empfohlen, Folgendes anzugeben: Sprachausgabe-Engine, die die auf dem Gerät verfügbaren Sprachen unterstützt
- [3.13/H-SR-1] wird dringend empfohlen, Folgendes anzugeben: UI-Komponente für Schnelleinstellungen
Wenn in Implementierungen von Android-Handheld-Geräten FEATURE_BLUETOOTH
oder
FEATURE_WIFI
-Support, sie:
- [3.16/H-1-1] MUSS die Kopplung von Begleitgeräten unterstützen .
Wenn die Navigationsfunktion als bewegungsbasierte Aktion auf dem Bildschirm bereitgestellt wird:
- [7.2.3/H] Der Bereich für die Bewegungserkennung des Zuhauses dürfen nicht mehr als 32 dp vom unteren Rand des Bildschirm.
Wenn Implementierungen von Handheld-Geräten eine Navigationsfunktion als Geste bieten an einer beliebigen Stelle am linken und rechten Bildschirmrand:
- [7.2.3/H-0-1] Der Touch-Gestenbereich der Navigationsfunktion MÜSSEN auf jeder Seite weniger als 40 dp breit sein. Der Gestenbereich SOLLTE Die Standardbreite beträgt 24 dp.
Ob Handheld-Implementierungen einen sicheren Sperrbildschirm unterstützen und mindestens 2 GB Arbeitsspeicher, der dem Kernel und Userspace zur Verfügung steht, geschieht Folgendes:
- [3.9/H-1-2] MÜSSEN die Unterstützung verwalteter Profile
Funktions-Flag „
android.software.managed_users
“.
Wenn Implementierungen von Android-Handheld-Geräten die Kamera-Unterstützung
android.hardware.camera.any
:
- [7.5.4/H-1-1] MUSS die
android.media.action.STILL_IMAGE_CAMERA
berücksichtigen 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 Geräteimplementierung ein Aufteilungsfunktion, mithilfe der Aktivitätseinbettung:
- [3.2.3.1/ H-1-1] MÜSSEN über eine Aktivität verfügen,
Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY, wenn die Aufteilungsfunktion aktiviert ist. Die Aktivität MUSS geschützt sein durch
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
und es MÜSSEN MÜSSEN Aktivität des Intents starten, der geparst wird von Einstellungen#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
Wenn Geräte, die es Nutzern ermöglichen, beliebige Anrufe zu tätigen,
- [7.4.1.2/H-0-1] MUSS das Funktions-Flag
android.software.telecom
deklarieren. - [7.4.1.2/H-0-2] MÜSSEN das Telekommunikations-Framework implementieren.
2.2.4 Leistung und Leistung
- [8.1/H-0-1] Konsistente Framelatenz. Inkonsistente Frame-Latenz oder Verzögerungen beim Rendern von Frames DÜRFEN NICHT öfter auftreten häufiger als 5 Frames pro Sekunde und SOLLTEN unter 1 Frames pro Sekunde liegen.
- [8.1/H-0-2] Latenz der Benutzeroberfläche. Geräteimplementierungen MÜSSEN die Nutzererfahrung mit niedriger Latenz durch Scrollen nach Liste mit 10.000 Listeneinträgen gemäß der Definition der Android Compatibility Test Suite (CTS) in weniger als 36 Sekunden.
- [8.1/H-0-3] Aufgabenwechsel. Wann? mehrere Anwendungen gestartet wurden, startet eine bereits laufende nach dem Start MUSS weniger als eine Sekunde dauern.
Implementierungen von Handheld-Geräten:
- [8.2/H-0-1] MÜSSEN sicherstellen, dass eine sequenzielle von mindestens 5 MB/s schreiben.
- [8.2/H-0-2] MÜSSEN sicherstellen, dass ein zufälliger Schreibvorgang stattfindet. mit mindestens 0,5 MB/s arbeiten.
- [8.2/H-0-3] MUSS einen sequenziellen Lesevorgang sicherstellen mit mindestens 15 MB/s arbeiten.
- [8.2/H-0-4] MUSS einen zufälligen Lesevorgang sicherstellen mit mindestens 3,5 MB/s arbeiten.
Wenn Implementierungen von Handheld-Geräten Funktionen zur Verbesserung der Geräteleistung enthalten die in AOSP enthalten sind, oder die Funktionen zu erweitern, bei AOSP:
- [8.3/H-1-1] MUSS zum Aktivieren die Nutzeroptionen zur Verfügung stellen. und den Energiesparmodus deaktivieren.
- [8.3/H-1-2] MUSS zum Anzeigen die Nutzereigenschaften bieten. Alle Apps, die vom App-Standby- und Stromsparmodus ausgenommen sind
Implementierungen von Handheld-Geräten:
- [8.4/H-0-1] MÜSSEN eine Leistungsprofil pro Komponente, das den aktuellen Verbrauchswert definiert für jede Hardwarekomponente und die ungefähre Entladung des Akkus aufgrund der wie auf der Website des Android Open Source Project dokumentiert.
- [8.4/H-0-2] MÜSSEN die gesamte Stromversorgung melden. Verbrauchswerte in Milliamperestunden (mAh) angegeben.
- [8.4/H-0-3] MÜSSEN die CPU-Leistung melden
pro Prozess UID. Das Open-Source-Projekt von Android erfüllt
Anforderung durch die Implementierung des Kernelmoduls
uid_cputime
. - [8.4/H-0-4] MUSS diesen Stromverbrauch nutzen
verfügbar über
adb shell dumpsys batterystats
Shell-Befehl an den App-Entwickler senden. - [8.4/H] SOLLTE dem Hardwarekomponente selbst, wenn der Stromverbrauch der Hardwarekomponente nicht zugeordnet werden kann zu einer Anwendung hinzufügen.
Implementierungen von Handheld-Geräten, die eine Bildschirm- oder Videoausgabe beinhalten:
- [8.4/H-1-1] MUSS die
android.intent.action.POWER_USAGE_SUMMARY
und zeigt ein Einstellungsmenü an, das diesen Energieverbrauch anzeigt.
Implementierungen von Handheld-Geräten:
[8.5/H-0-1] MUSS angegeben werden die Möglichkeit des Nutzers, alle Apps mit aktiven Diensten im Vordergrund zu sehen oder vom Nutzer initiierte Jobs, einschließlich der Dauer jedes dieser Dienste da er wie im SDK-Dokument beschrieben gestartet wurde.
[8.5/H-0-2]MÜSSEN Nutzern ein Kauferlebnis bieten. App beenden, die einen Dienst im Vordergrund ausführt, oder einen vom Nutzer initiierten Job
2.2.5 Sicherheitsmodell
Implementierungen von Handheld-Geräten:
- [9/H-0-1] MUSS die
android.hardware.security.model.compatible
deklarieren . - [9.1/H-0-1] MÜSSEN Drittanbieter-Apps Zugriff auf
Nutzungsstatistiken über die Berechtigung
android.permission.PACKAGE_USAGE_STATS
und einen für den Nutzer zugänglichen Mechanismus bereitstellen, den Zugriff auf solche Apps in Reaktion aufandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
die Nutzerabsicht verstehen.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Geräteimplementierungen MÜSSEN Support für Folgendes erklären:
android.software.credentials
und:
[9/H-0-2] MÜSSEN den Intent
android.settings.CREDENTIAL_PROVIDER
berücksichtigen um einen bevorzugten Anbieter für die Anmeldedatenverwaltung auszuwählen. Dieser Anbieter wird für Autofill und ist auch der Standardspeicherort zum Speichern neuer Anmeldedaten über die Anmeldedaten-Manager eingegeben.[9/H-0-3] MUSS mindestens zwei gleichzeitige Anmeldedatenanbieter unterstützen und in der App „Settings“ (Einstellungen) , um Anbieter zu aktivieren oder zu deaktivieren.
Neue Anforderungen beenden
Wenn in Geräteimplementierungen die Unterstützung von android.hardware.telephony
deklariert wird,
Sie:
- [9.5/H-1-1] DARF NICHT
UserManager.isHeadlessSystemUserMode
festlegen antrue
.
Implementierungen von Handheld-Geräten:
- [9.11/H-0-2] MUSS die Schlüsselspeicher-Implementierung sichern mit einer isolierten Ausführungsumgebung.
- [9.11/H-0-3] MUSS Implementierungen von RSA, AES, Die kryptografischen Algorithmen ECDSA und HMAC sowie die MD5-, SHA-1- und SHA-2-Familie Hash-Funktionen genutzt werden, um die vom Android-Schlüsselspeichersystem unterstützten in einem Bereich, der sicher vom Code isoliert ist, Kernel und höher. Sichere Isolation MUSS alle potenziellen Mechanismen blockieren über den Kernel- oder Userspace-Code auf den internen Status des einer isolierten Umgebung, einschließlich DMA. Die vorgelagerte Open-Source-Version von Android Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung, aber eine andere ARM TrustZone-basierte Lösung oder von einem Drittanbieter geprüfte sichere Lösung Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation sind eine Alternative Optionen.
- [9.11/H-0-4] MUSS den Sperrbildschirm starten in der isolierten Ausführungsumgebung und nur dann, erfolgreich war, können die mit der Authentifizierung gebundenen Schlüssel verwendet werden. Sperrbildschirm Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführung für die Sperrbildschirm-Authentifizierung. Die vorgelagerte Android- Open-Source-Projekt bietet Gatekeeper-Hardwareabstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
[9.11/H-0-5] MUSS die Schlüsselattestierung unterstützen, wenn die Der Attestierungssignaturschlüssel wird durch sichere Hardware geschützt und die Signatur ist auf sicherer Hardware ausgeführt werden. Die Signaturschlüssel der Attestierung MÜSSEN
gemeinsam verwendet werden Geräte groß genug ist, um die Schlüssel zu verhindern.verhindert nicht als dauerhaft Gerätekennungen.Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel, es sei denn, mindestens 100.000 Einheiten einer SKU produziert wurden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, für je 100.000 Einheiten.
Neue Anforderungen beenden
Wenn eine Geräteimplementierung bereits auf einer früheren Android-Version
-Version ist ein solches Gerät von der Anforderung ausgenommen, einen Schlüsselspeicher zu haben.
eine isolierte Ausführungsumgebung nutzen
und die Schlüsselattestierung unterstützen,
es sei denn, die Funktion android.hardware.fingerprint
wird deklariert, für die ein
Schlüsselspeicher, der von einer isolierten Ausführungsumgebung unterstützt wird.
Wenn Handheld-Geräte einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:
- [9.11/H-1-1] MUSS dem Nutzer die Möglichkeit geben, das kürzeste Ruhemodus-Timeout, d. h. eine Übergangszeit vom entsperrten zum gesperrten Zustand 15 Sekunden oder weniger anzeigen.
- [9.11/H-1-2] MUSS Nutzern die Möglichkeit bieten, Inhalte auszublenden. und deaktivieren alle Formen der Authentifizierung mit Ausnahme der primäre Authentifizierung, beschrieben in 9.11.1 Sicherer Sperrbildschirm. Der AOSP trifft die als Sperrmodus erforderlich.
Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agenten enthalten, die die TrustAgentService
System API implementieren, geschieht Folgendes:
- [9.11.1/H-1-1] MÜSSEN den Nutzer häufiger als alle 72 Stunden zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) auffordern.
Wenn die Implementierung von Handheld-Geräten mehrere Nutzer und
Das Funktions-Flag android.hardware.telephony
wird nicht deklariert, sie werden:
- [9.5/H-2-1] MUSS eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteeigentümer zusätzliche Nutzer und ihre Funktionen auf dem Gerät. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen einrichten, in denen zusätzliche Nutzende arbeiten können, mit der Möglichkeit, differenziertere Einschränkungen in den Apps zu verwalten, die in diesen Umgebungen verfügbar sind.
Wenn die Implementierung von Handheld-Geräten mehrere Nutzer und
das Funktions-Flag android.hardware.telephony
deklarieren, wenn folgende Aktionen ausgeführt werden:
- [9.5/H-3-1] DÜRFEN KEINE Unterstützung eingeschränkter Einschränkungen unterstützen Profile, MÜSSEN aber mit der AOSP-Implementierung der Kontrollen übereinstimmen. , um zu aktivieren /deaktivieren, dass andere Nutzer auf die Sprachanrufe und SMS zugreifen können.
Wenn bei Handheld-Implementierungen UserManager.isHeadlessSystemUserMode
festgelegt ist
an true
, sie
- [9.5/H-4-1] DÜRFEN KEINE Unterstützung für eUICCs enthalten, noch für eSIMs mit Anruffunktion.
- [9.5/H-4-2] DÜRFEN KEINE Unterstützung für Folgendes deklarieren:
android.hardware.telephony
Android unterstützt VoiceInteractionService über die System-API einen Mechanismus zur Sichere Hotword-Erkennung, die ständig aktiviert ist, aber keine Mikrofonzugriffserkennung anzeigt und Always-on-Abfrageerkennung, ohne Mikrofon oder Kamera Zugriffsanzeige hinzugefügt.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Eingeschränkte Einstellungen
Bei eingeschränkten Einstellungen werden Nutzern sichtbare Warnungen angezeigt und fordert den Nutzer zur Erteilung von Berechtigungen an. für jede Anwendung, die entweder
- Installation nach dem Download über eine Anwendung
(z. B. eine Messaging-Anwendung oder ein Browser),
ein „App Store“ Anwendung identifiziert von
PackageManager
alsPACKAGE_DOWNLOADED_FILE
- Installation aus einer lokalen Datei
(z. B. wenn die Anwendung per Sideload übertragen wurde)
von
PackageManager
identifiziert alsPACKAGE_SOURCE_LOCAL_FILE
Für alle erzwungenen Berechtigungen und zugehörigen Kennzeichnungen:
- Wecker und Erinnerungen:
AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Gesamter Dateizugriff:
AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Über anderen Apps einblenden:
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Unbekannte Apps installieren:
AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Medien verwalten:
AppOpsManager.OPSTR_MANAGE_MEDIA
- Systemeinstellungen ändern:
AppOpsManager.OPSTR_WRITE_SETTINGS
- Bild im Bild:
AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Display einschalten:
AppOpsManager.OPSTR_TURN_SCREEN_ON
- Vollbildbenachrichtigungen:
AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- WLAN-Steuerung:
AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Barrierefreiheit:
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Benachrichtigungs-Listener:
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Zugriff auf Nutzungsdaten:
AppOpsManager.OPSTR_GET_USAGE_STATS
- Geräteadministrator:
Manifest.permission.BIND_DEVICE_ADMIN
- Bitte nicht stören:
Manifest.permission.MANAGE_NOTIFICATIONS
Solche Anwendungen sind mit „Abgedeckte Anwendungen“ gekennzeichnet. für die Anforderungen die in diesem Abschnitt aufgeführt sind.
Geräteimplementierungen:
[9.8/H-0-1] MÜSSEN die eingeschränkten Einstellungen wie oben für Folgendes:
- Besondere Berechtigungen
<ph type="x-smartling-placeholder">
- </ph>
- Bedienungshilfen (
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
) - Benachrichtigungs-Listener (
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
) - Apps zur Geräteverwaltung (
Manifest.permission.BIND_DEVICE_ADMIN
) - Über anderen Apps einblenden (
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
) - Zugriff auf Nutzungsdaten (
AppOpsManager.OPSTR_GET_USAGE_STATS
)
- Bedienungshilfen (
- Rollen (Standard-Apps)
<ph type="x-smartling-placeholder">
- </ph>
- Telefon (
RoleManager.ROLE_DIALER
) - SMS (
RoleManager.ROLE_SMS
)
- Telefon (
- Laufzeitberechtigungen
<ph type="x-smartling-placeholder">
- </ph>
- SMS-Laufzeit (
Manifest.permission_group.SMS
)
- SMS-Laufzeit (
- Besondere Berechtigungen
<ph type="x-smartling-placeholder">
[9.8/H-0-2] MÜSSEN die eingeschränkten Einstellungen standardmäßig aktivieren und sind EMPFOHLEN, keine Angebote für Nutzer zu bieten, um eingeschränkte Einstellungen für alle Apps zu deaktivieren.
[9.8/H-0-3] MÜSSEN sicherstellen, dass die Nutzerbestätigung für jedes Abgedeckte Anwendung, bevor eine der erzwungenen Berechtigungen gewährt werden kann.
[9.8/H-0-4] MUSS dem Nutzer nur die Bestätigung erlauben, eingeschränkte Einstellungen zu aktivieren. erhalten Sie über die Seite „AppInfo“ der abgedeckten App. mit der EnhancedConfirmationManager API an.
[9.8/H-0-5] Werden dringend empfohlen, EnhancedConfirmationManager für alle speziellen Berechtigungen, um dynamisch zu ermitteln, ob es sich um eine eingeschränkte Einstellung handelt.
- Wecker und Erinnerungen:
AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Gesamter Dateizugriff:
AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Über anderen Apps einblenden:
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Unbekannte Apps installieren:
AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Medien verwalten:
AppOpsManager.OPSTR_MANAGE_MEDIA
- Systemeinstellungen ändern:
AppOpsManager.OPSTR_WRITE_SETTINGS
- Bild im Bild:
AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Display einschalten:
AppOpsManager.OPSTR_TURN_SCREEN_ON
- Vollbildbenachrichtigungen:
AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- WLAN-Steuerung:
AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Barrierefreiheit:
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Benachrichtigungs-Listener:
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Zugriff auf Nutzungsdaten:
AppOpsManager.OPSTR_GET_USAGE_STATS
- Geräteadministrator:
Manifest.permission.BIND_DEVICE_ADMIN
- Bitte nicht stören:
Manifest.permission.MANAGE_NOTIFICATIONS
- Wecker und Erinnerungen:
Neue Anforderungen beenden
Wenn Implementierungen von Handheld-Geräten die System API unterstützen
HotwordDetectionService
oder ein anderer Mechanismus zur Hotword-Erkennung ohne
Mikrofonzugriff anzeigt, können sie:
- [9.8/H-1-1] MÜSSEN sicherstellen, dass der Hotword-Erkennungsdienst
Daten an das System,
ContentCaptureService
, oder On-Device-SpracherkennungsdienstSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-2] MÜSSEN sicherstellen, dass der Hotword-Erkennungsdienst
Audiodaten oder Daten, die vom Mikrofon an den Systemserver über
HotwordDetectionService
API 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] DÜRFEN NICHT mehr als 100 Byte an Daten zulassen (ohne Audiostreams) die bei jeder erfolgreichen Ausführung Hotword-Ergebnis.
- [9.8/H-1-7] DÜRFEN NICHT zulassen, dass mehr als 5 Bits an Daten übertragen werden. des Hotword-Erkennungsdienstes für jedes negative Hotword-Ergebnis.
- [9.8/H-1-8] DARF nur die Übertragung von Daten aus dem Hotword zulassen Erkennungsdienst für eine Anfrage zur Hotword-Validierung vom Systemserver.
- [9.8/H-1-9] DÜRFEN NICHT zulassen, dass eine vom Nutzer installierbare Anwendung zur Bereitstellung des Hotword-Erkennungsdienst.
- [9.8/H-1-10] DÜRFEN KEINE quantitativen Daten zur Mikrofonnutzung durch den Hotword-Erkennungsdienst.
- [9.8/H-1-11] MÜSSEN die Anzahl von Byte in jeder Übertragung protokollieren aus dem Hotword-Erkennungsdienst Forschenden.
- [9.8/H-1-12] MÜSSEN einen Debug-Modus unterstützen, der die Rohinhalte aller die vom Hotword-Erkennungsdienst übertragen werden, für Sicherheitsexperten.
[9.8/H-1-14] MÜSSEN die Mikrofonanzeige einblenden, wie im Abschnitt 9.8.2, wenn ein erfolgreiches Hotword-Ergebnis an die Stimme übertragen wird oder eine ähnliche Entität.
[9.8/H-1-15] MÜSSEN sicherstellen, dass Audiostreams bei erfolgreichen Hotwords bereitgestellt werden. werden die Ergebnisse vom Hotword-Erkennungsdienst in eine Richtung an den Sprachinteraktionsdienst.
[9.8/H-SR-1] Es wird dringend empfohlen, Nutzer vor dem Festlegen einer als Anbieter des Hotword-Erkennungsdienstes.
[9.8/H-SR-2] WIRD UNBEDINGT EMPFOHLEN, die Übertragung von unstrukturierte Daten aus dem Hotword-Erkennungsdienst.
[9.8/H-SR-3] Es wird dringend empfohlen, den Prozess, Dienst zur Hotword-Erkennung mindestens einmal pro Stunde oder alle 30 Hardware-Trigger-Ereignissen auslösen, je nachdem, was zuerst eintritt.
Wenn die Geräteimplementierung eine Anwendung umfasst, die die System-API verwendet
HotwordDetectionService
, oder einen ähnlichen Mechanismus zur Hotword-Erkennung ohne
Mikrofonnutzung anzeigt, führt die Anwendung folgende Schritte aus:
- [9.8/H-2-1] MÜSSEN Nutzer explizit auf jede Hotword-Wortgruppe hinweisen. unterstützt.
- [9.8/H-2-2] DÜRFEN KEINE Audio-Rohdaten oder daraus abgeleitete Daten beibehalten, über den Hotword-Erkennungsdienst.
- [9.8/H-2-3] DÜRFEN KEINE Audiodaten vom Dienst zur Hotword-Erkennung übertragen.
Daten, mit denen die Audiodaten (ganz oder teilweise) rekonstruiert werden können,
oder Audioinhalte, die nichts mit dem Hotword selbst zu tun haben,
ContentCaptureService
oder Spracheingabe auf dem Gerät Erkennungsdienst.
Wenn Implementierungen von Handheld-Geräten die System API unterstützen
VisualQueryDetectionService
oder ein anderer Mechanismus zur Abfrageerkennung
ohne Hinweis auf den Zugriff auf das Mikrofon und/oder die Kamera, geschieht Folgendes:
- [9.8/H-3-1] MÜSSEN sicherstellen, dass der Anfrageerkennungsdienst
Daten an das System,
ContentCaptureService
oder Sprachausgabe auf dem Gerät Erkennungsdienst (erstellt vonSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] DÜRFEN NICHT zulassen, dass Audio- oder Videoinformationen übertragen werden.
von
VisualQueryDetectionService
mit Ausnahme vonContentCaptureService
oder einen Spracherkennungsdienst auf dem Gerät. - [9.8/H-3-3] MÜSSEN in der System-UI ein Nutzerhinweis angezeigt werden, wenn das Gerät einen Nutzer erkennt. die Absicht, mit der App für digitale Assistenten zu interagieren (z. B. durch Erkennung Nutzerpräsenz über die Kamera).
- [9.8/H-3-4] MÜSSEN eine Mikrofonanzeige und die erkannte direkt nach der Erkennung der Nutzeranfrage in der Benutzeroberfläche.
- [9.8/H-3-5] DÜRFEN NICHT zulassen, dass eine vom Nutzer installierbare Anwendung zur Bereitstellung des visuellen Abfrageerkennungsdienst.
Wenn in Implementierungen von Handheld-Geräten android.hardware.microphone
deklariert ist, gilt Folgendes:
- [9.8.2/H-4-1] MUSS die Mikrofonanzeige einblenden, wenn
eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn das Mikrofon
Nur
HotwordDetectionService
hat Zugriff auf das Mikrofon.SOURCE_HOTWORD
,ContentCaptureService
oder Apps mit den so genannten Rollen in Abschnitt 9.1 mit der CDD-Kennung [C-4-X]. - [9.8.2/H-4-2] MUSS die Liste der zuletzt aktiven und aktiven Nutzer
Apps, die das Mikrofon wie von
PermissionManager.getIndicatorAppOpUsageData()
, mit allen Quellenangaben Nachrichten, die mit ihnen verknüpft sind. - [9.8.2/H-4-3] DARF die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
- [9.8.2/H-4-4] MUSS die Liste der zuletzt aktiven und aktiven Nutzer
Apps, die das Mikrofon verwenden, wie von
PermissionManager.getIndicatorAppOpUsageData()
zurückgegeben, sowie mit allen damit verbundenen Quellenangaben.
Wenn in Implementierungen von Handheld-Geräten android.hardware.camera.any
deklariert ist, gilt Folgendes:
- [9.8.2/H-5-1] MUSS die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn die Kamera auf die Apps zugreifen, die die in den Abschnitt 9.1 mit der CDD-Kennung [C-4-X].
- [9.8.2/H-5-2] MÜSSEN kürzlich geöffnete und aktive Apps angezeigt werden mit
Kamera wie von
PermissionManager.getIndicatorAppOpUsageData()
zurückgegeben, sowie mit allen damit verbundenen Quellenangaben. - [9.8.2/H-5-3] DARF die Kameraanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Der verifizierte Bootmodus ist eine Funktion, die die Integrität der Gerätesoftware gewährleistet. Wenn Geräteimplementierungen die Funktion unterstützen, gilt Folgendes:
- [9.10/H-1-1] MÜSSEN alle schreibgeschützten Partitionen überprüfen. während des Android-Startvorgangs eingesetzt wird und der VBMeta-Digest alle verifizierten Partitionen in die Berechnung mit einfließen.
Neue Anforderungen beenden
2.2.6 Kompatibilität von Entwicklertools und -optionen
Implementierungen von Handheld-Geräten (* Nicht zutreffend für Tablets):
- [6.1/H-0-1]* MUSS den Shell-Befehl unterstützen
cmd testharness
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Implementierungen von Handheld-Geräten (* Nicht zutreffend für Tablets):
- Perfetto
<ph type="x-smartling-placeholder">
- </ph>
- [6.1/H-0-2]
*MUSS einen/system/bin/perfetto
anzeigen Binärdatei, die der cmdline entspricht Perfetto-Dokumentation. - [6.1/H-0-3]
*Das Perfetto-Binärprogramm MUSS akzeptiert werden als Geben Sie eine protobuf-Konfiguration ein, die dem in Perfetto-Dokumentation. - [6.1/H-0-4]
*Das Perfetto-Binärprogramm MUSS schreiben als einen protobuf-Trace ausgeben, der dem in Perfetto-Dokumentation. - [6.1/H-0-5]
*MÜSSEN bereitgestellt werden, binär, zumindest die unter Perfetto-Dokumentation. - [6.1/H-0-6]
*Der perfetto verfolgte Daemon MUSS standardmäßig aktiviert (Systemeigenschaftpersist.traced.enable
).
- [6.1/H-0-2]
Neue Anforderungen beenden
2.2.7 Handheld Media Performance-Kurs
In Abschnitt 7.11 finden Sie eine Definition für der Medienleistung.
2.2.7.1 Medien
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.U
zurückgeben
Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
gilt Folgendes:
- MÜSSEN die in Android 14 CDD, Abschnitt 2.2.7.1 aufgeführten Anforderungen an Medien erfüllen.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn die Implementierung von Handheld-Geräten wieder funktioniert
android.os.Build.VERSION_CODES.V
Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
Neue Anforderungen beenden
- [5.1/H-1-1] MUSS die maximale Anzahl von Hardware-Videodecoder bewerben
Sitzungen, die gleichzeitig in einer beliebigen Codec-Kombination über den
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
-Methoden.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-2] MUSS 6 Instanzen von 8-Bit-Hardware-Videodecoder unterstützen Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination, die ausgeführt wird gleichzeitig mit 3 Sitzungen bei 1080p-Auflösung bei 30 fps und 3 Sitzungen bei 4K Auflösung bei 30 fps, außer AV1. Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codecs sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen. Es sind aber auch sechs Instanzen mit 1080p30 fps erforderlich.
Neue Anforderungen beenden
- [5.1/H-1-3] MÜSSEN die maximale Anzahl von Hardware-Video-Encodern bewerben.
Sitzungen, die gleichzeitig in einer beliebigen Codec-Kombination über den
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
-Methoden.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-4] MUSS 6 Instanzen von 8-Bit-Hardware-Videoencoder (SDR) unterstützen Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination, die ausgeführt wird gleichzeitig mit 4 Sitzungen bei einer Auflösung von 1080p bei 30 fps und 2 Sitzungen bei 4K Auflösung bei 30 fps, außer AV1. Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codecs sind nur für 1080p-Auflösung erforderlich, werden aber erforderlich, um 6 Instanzen mit 1080p30 fps zu unterstützen.
Neue Anforderungen beenden
- [5.1/H-1-5] MÜSSEN die maximale Anzahl von Hardware-Video-Encodern und
Decoder-Sitzungen, die gleichzeitig in einer beliebigen Codec-Kombination über den
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
-Methoden.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-6] MUSS 6 Instanzen von 8-Bit-Hardware-Videodecoder unterstützen und Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebigen gleichzeitig mit 3 Sitzungen bei 4K bei 30 fps ausgeführt Auflösung (außer AV1), von denen maximal 2 Encoder-Sitzungen und 3 mit einer Auflösung von 1080p. Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codecs sind nur für 1080p-Auflösung erforderlich, werden aber erforderlich, um 6 Instanzen mit 1080p30 fps zu unterstützen.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-19] MUSS drei Instanzen eines 10-Bit-Hardware-Videodecoders (HDR) unterstützen und Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in beliebigen Codec-Kombination, die gleichzeitig mit einer Auflösung von 4K bei 30 fps ausgeführt wird (außer AV1) von denen höchstens eine eine Encoder-Sitzung ist, die in RGBA_1010102-Eingabeformat über eine GL-Oberfläche. Für bei allen Sitzungen DÜRFEN NICHT mehr als 1 Frame pro 2. HDR-Metadatengenerierung durch den Encoder ist bei der Codierung von der GL-Oberfläche nicht erforderlich. AV1-Codec-Sitzungen sind nur erforderlich, um 1080p-Auflösung zu unterstützen, auch wenn diese Anforderung ruft für 4K.
Neue Anforderungen beenden
- [5.1/H-1-7] MÜSSEN eine Codec-Initialisierungslatenz von 40 ms oder weniger für eine Videocodierungssitzung mit 1080p oder kleiner für alle Hardware-Videoencoder, wenn unter Last aus. Hier wird die Auflösung als gleichzeitige Videoaufnahme zwischen 1080 und 720p definiert Transcodierungssitzung mit Hardware-Video-Codecs zusammen mit 1080p die Initialisierung von Audio-Video-Aufzeichnungen. Für den Dolby Vision-Codec Die Initialisierungslatenz MUSS höchstens 50 ms betragen.
- [5.1/H-1-8] MÜSSEN eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiocodierungssitzung mit 128 kbit/s oder niedrigerer Bitrate für alle Audio-Encoder, wenn unter Last aus. Hier wird die Auflösung als gleichzeitige Videoaufnahme zwischen 1080 und 720p definiert Transcodierungssitzung mit Hardware-Video-Codecs zusammen mit 1080p die Initialisierung von Audio-Video-Aufzeichnungen.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-9] MUSS zwei Instanzen eines sicheren Hardware-Videodecoder unterstützen Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination, die ausgeführt wird gleichzeitig bei 4K-Auflösung bei 30 fps (außer AV1) für 8-Bit (SDR) und 10-Bit-HDR-Inhalte Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, selbst wenn Diese Anforderung erfordert 4K.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-10] MUSS drei Instanzen eines nicht sicheren Hardware-Videodecoders unterstützen Sitzungen zusammen mit einer Instanz einer sicheren Hardware-Videodecoder-Sitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, AV1 oder höher) in beliebiger Codec-Kombination gleichzeitig mit 3 Sitzungen bei 4K-Auflösung bei 30 fps (außer AV1) einschließlich einer sicheren Decodersitzung und 1 nn-sicheren Sitzung bei 1080p Auflösung bei 30 fps, wobei maximal 2 Sitzungen in 10-Bit-HDR-Qualität möglich sind Es DARF NICHT mehr als 1 Frame für alle Sitzungen geben. pro Sekunde reduziert. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, selbst wenn Diese Anforderung erfordert 4K.
Neue Anforderungen beenden
- [5.1/H-1-11] MÜSSEN einen sicheren Decoder für alle Hardware-AVC-, HEVC- VP9- oder AV1-Decoder auf dem Gerät.
- [5.1/H-1-12] MÜSSEN eine Codec-Initialisierungslatenz von 40 ms oder weniger für eine Videodecodierungssitzung mit 1080p oder kleiner für alle Hardware-Videodecoder wenn sie unter Last sind. Hier wird die Last als gleichzeitige Auflösung von 1080 bis 720p definiert mit Hardware-Video-Codecs zusammen mit dem Initialisierung der Wiedergabe von Audio und Video mit 1080p. Für den Dolby Vision-Codec Die Initialisierungslatenz MUSS höchstens 50 ms betragen.
- [5.1/H-1-13] MÜSSEN eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiodecodierungssitzung mit einer Bitrate von 128 kbit/s für alle Audiodecoder bei einer unter Last aus. Hier wird die Auflösung als gleichzeitige Videoaufnahme zwischen 1080 und 720p definiert Transcodierungssitzung mit Hardware-Video-Codecs zusammen mit 1080p Initialisierung der Audio-Video-Wiedergabe.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-14] MÜSSEN AV1-Hardwaredecoder Main 10, Level 4.1 unterstützen
und Filmkörnungmit Filmkörnung über GPU-Zusammensetzung
Neue Anforderungen beenden
- [5.1/H-1-15] MUSS mindestens einen Hardware-Videodecoder haben, der 4K60 unterstützt.
- [5.1/H-1-16] MUSS mindestens einen Hardware-Video-Encoder haben, der 4K60 unterstützt.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-21] MUSS
FEATURE_DynamicColorAspect
für alle Hardwarevideos unterstützen Decoder (AVC, HEVC, VP9, AV1 oder höher) verwenden. Hinweis: Das bedeutet, dass Anwendungen die Farbaspekte des Videocontents während der Decodierung aktualisieren. Decodierer, die 10-Bit- und 8-Bit-Inhalte unterstützen, MÜSSEN die dynamische Unterstützung zwischen 8- und 10-Bit-Inhalten im Oberflächenmodus wechseln. Unterstützte Decodierer Die HDR-Transferfunktion MUSS den dynamischen Wechsel zwischen SDR und HDR unterstützen Inhalte.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-22] MÜSSEN Codierung, Decodierung, GPU-Bearbeitung und Wiedergabe von Videos unterstützen. Inhalte im Hochformat, unabhängig von den Rotationsmetadaten für die größte von der Kamera unterstützte Auflösung oder 4K, je nachdem, welcher Wert geringer ist. Hinweis: enthält HDR-Profile, wenn der Codec HDR unterstützt. AV1-Codecs sind nur erforderlich, um unterstützen eine Auflösung von 1080p. Diese Anforderung gilt nur für Hardware-Codecs, und die Datenschutzaufsichtsbehörde.
Neue Anforderungen beenden
- [5.3/H-1-1] DARF NICHT mehr als einen Frame in 10 Sekunden (d.h. weniger als 0,167 % Framerate) bei einer 4K-Videositzung mit 60 fps unter Last.
- [5.3/H-1-2] Während eines Videos DARF NICHT mehr als 1 Frame in 10 Sekunden verworfen werden Änderung der Auflösung in einer Videositzung mit 60 fps unter Last bei einer 4K-Sitzung.
- [5.6/H-1-1] MUSS eine Tap-to-Tone-Latenz von 80 Millisekunden oder weniger mit der den Tap-to-Ton-Test von CTS Verifier.
- [5.6/H-1-2] MÜSSEN eine Umlauf-Audio-Latenz von 80 Millisekunden haben oder weniger über mindestens einen unterstützten Datenpfad.
- [5.6/H-1-3] MUSS mindestens 24-Bit-Audio für eine Stereoausgabe über 3,5 mm unterstützen
Anschlüsse, falls vorhanden, und über USB-Audio, sofern dies durch den gesamten Datenbestand unterstützt wird
für niedrige Latenz- und Streamingkonfigurationen. Für die niedrige Latenz
AAudio sollte von der App in einem Callback mit niedriger Latenz verwendet werden.
. Für die Streaming-Konfiguration sollte ein Java-Audiotrack verwendet werden.
in der App. Sowohl in den Konfigurationen mit niedriger Latenz als auch bei Streamingkonfigurationen weist der HAL
Die Ausgabesenke sollte entweder
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
oderAUDIO_FORMAT_PCM_FLOAT
als Zielausgabeformat.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.6/H-1-4] MUSS mehr als 4-Kanal-USB-Audiogeräte unterstützen.
(Diese werden von DJ-Controllern für die Vorschau von Songs verwendet.)
Neue Anforderungen beenden
- [5.6/H-1-5] MÜSSEN klassenkonforme MIDI-Geräte unterstützen und die MIDI-Funktions-Flag.
- [5.6/H-1-9] MUSS mindestens 12 Kanäle unterstützen. Dies impliziert, dass AudioTrack mit 7.1.4-Kanal-Maske und ordnungsgemäß alle Kanäle auf Stereo zu verzerren.
- [5.6/H-SR] WIRD UNBEDINGT EMPFOHLEN, 24-Kanal-Mix mit mindestens Unterstützung für Kanalmasken der Versionen 9.1.6 und 22.2.
- [5.7/H-1-2] MUSS
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
mit dem Funktionen zur Inhaltsentschlüsselung.
Mindeststichprobengröße | 4 MiB |
Mindestanzahl von Teilstichproben – H264 oder HEVC | 32 |
Mindestanzahl von Teilstichproben – VP9 | 9 |
Mindestanzahl von Teilstichproben – AV1 | 288 |
Minimale Zwischenspeichergröße für Teilstichproben | 1 MiB |
Mindestgröße des generischen Krypto-Zwischenspeichers | 500 KiB |
Mindestanzahl gleichzeitiger Sitzungen | 30 |
Mindestanzahl von Schlüsseln pro Sitzung | 20 |
Mindestanzahl von Schlüsseln (alle Sitzungen) | 80 |
Mindestanzahl von DRM-Schlüsseln (alle Sitzungen) | 6 |
Nachrichtengröße | 16 KiB |
Entschlüsselte Frames pro Sekunde | 60 fps |
- [5.1/H-1-17] MUSS mindestens einen Hardware-Bilddecoder haben, der AVIF unterstützt Baseline-Profil.
- [5.1/H-1-18] MUSS AV1-Encoder unterstützen, der bis zu 480p codieren kann bei 30 fps und 1 Mbit/s.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [5.1/H-1-20] MUSS den
Feature_HdrEditing
unterstützen für alle auf dem Gerät vorhandenen AV1- und HEVC-Encoder in 4K-Qualität. oder die höchste von der Kamera unterstützte Auflösung, je nachdem, welcher Wert geringer ist.
Neue Anforderungen beenden
- [5.12/H-SR] werden dringend empfohlen, um die
Feature_HdrEditing
für AV1- und HEVC-Encoder auf dem Gerät. - [5.12/H-1-2] MÜSSEN das RGBA_1010102-Farbformat für alle Hardware-Geräte mit AV1 und Auf dem Gerät sind HEVC-Encoder vorhanden.
- [5.12/H-1-3] MÜSSEN die Unterstützung für die Erweiterung EXT_YUV_target bekannt geben für Stichprobe aus YUV-Texturen in 8 und 10 Bit.
- [7.1.4/H-1-1] MÜSSEN mindestens 6 Hardware-Overlays in der Displayverarbeitung haben. , von denen mindestens zwei 10-Bit-Videocontent wiedergeben können.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn die Implementierung von Handheld-Geräten wieder funktioniert
android.os.Build.VERSION_CODES.V
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
und sie enthalten
Hardware-AVC- oder HEVC-Encoder unterstützen, gilt Folgendes:
Neue Anforderungen beenden
- [5.2/H-2-1] MÜSSEN das im Video definierte Mindestqualitätsziel erfüllen Verzerrungskurven der Encoder-Rate für AVC- und HEVC-Codecs der Hardware gemäß Definition in Führe Tests der Leistungsklasse 14 (PC14) – VEQ-Tests (Videocodierungsqualität) durch.
2.2.7.2 Kamera
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.U
zurückgeben
Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
gilt Folgendes:
- MÜSSEN die in Android 14 CDD, Abschnitt 2.2.7.2 aufgeführten Anforderungen an Medien erfüllen.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn die Implementierung von Handheld-Geräten wieder funktioniert
android.os.Build.VERSION_CODES.V
Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [7.5/H-1-1] MUSS eine primäre rückseitige Kamera mit einer Auflösung von mindestens 12 Megapixel, die Videoaufnahmen mit 4K bei 30 fps, 1080p bei 60 fps und 720p bei 60 fps. Die primäre Kamera auf der Rückseite ist Kamera auf der Rückseite mit der niedrigsten Kamera-ID.
Neue Anforderungen beenden
- [7.5/H-1-2] MUSS eine primäre Frontkamera mit einer Auflösung von mindestens 6 Megapixel und eine Videoaufnahme mit 1080p bei 30 fps unterstützen. Die primäre Die Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
- [7.5/H-1-3] MUSS die Property
android.info.supportedHardwareLevel
alsFULL
oder besser für vorderes primäres Gerät undLIMITED
oder besser für vordere Grundleitung Kamera. - [7.5/H-1-4] MUSS unterstützt werden.
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
für beide primäre Kameras. - [7.5/H-1-5] MUSS eine JPEG-Aufnahmelatenz von „camera2“ < 1.000 ms für eine Auflösung von 1080p, gemessen durch den Leistungstest der CTS-Kamera unter ITS-Lichtverhältnisse (3.000 K) für beide Hauptkameras.
- [7.5/H-1-6] MUSS die Startlatenz von „camera2“ haben (Kamera für erste Vorschau öffnen). Frame) < 500 ms gemäß Messung durch Leistungstest der CTS-Kamera gemäß ITS (3.000 K) für beide primären Kameras.
- [7.5/H-1-8] MUSS
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
unterstützen 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] MUSS gleichzeitiges Front-Back-Streaming auf der primären Instanz implementieren. Kameras.
- [7.5/H-1-12] MUSS unterstützt werden.
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
für beide primäre Front- und Hauptkamera auf der Rückseite. - [7.5/H-1-13] MUSS die Funktion
LOGICAL_MULTI_CAMERA
unterstützen für die Hauptkamera auf der Rückseite, wenn auf der Rückseite mehr als ein RGB-Bild verwendet wird. Kameras. - [7.5/H-1-14] MUSS die Funktion
STREAM_USE_CASE
für beide primäre Front- und Hauptkamera auf der Rückseite. - [7.5/H-1-15] MUSS unterstützt werden. Nachtmodus-Erweiterungen über CameraX- und Camera2-Erweiterungen für primäre Kameras.
- [7.5/H-1-16] MUSS die Funktion DYNAMIC_RANGE_TEN_BIT für die primäre Datenbank unterstützen Kameras.
- [7.5/H-1-17] MUSS CONTROL_SCENE_MODE_FACE_PRIORITY unterstützen und Gesichtserkennung (STATISTICS_FACE_DETECT_MODE_SIMPLE oder STATISTICS_FACE_DETECT_MODE_FULL) für die primären Kameras.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [7.5/H-1-18] MUSS
JPEG_R
für die primäre Rück- und primären Frontkameras. - [7.5/H-1-19] MUSS unterstützt werden.
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
für 1080p HLG10 Vorschau mit maximaler JPEG-Datei mit einem Seitenverhältnis von 16:9 und für 720p-HLG10-Vorschau JPEG-Stream-Kombinationen mit einem Seitenverhältnis von 16:9 für die primäre Rückkamera. - [7.5/H-1-20] MUSS standardmäßig
JPEG_R
für die primäre Ausgabe ausgeben mit der Rück- und der primären Frontkamera in der nativen Kamera-App.
Neue Anforderungen beenden
2.2.7.3 Hardware
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.U
für
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- MÜSSEN die in Android 14 CDD, Abschnitt 2.2.7.3 aufgeführten Anforderungen an Medien erfüllen.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn die Implementierung von Handheld-Geräten wieder funktioniert
android.os.Build.VERSION_CODES.V
Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
Neue Anforderungen beenden
- [7.1.1.1/H-2-1] MUSS eine Bildschirmauflösung von mindestens 1080p haben.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [7.1.1.3/H-2-1] MUSS eine Bildschirmdichte von mindestens 400 dpi haben wenn die Bildschirmbreite des Geräts < 600 dp.
Neue Anforderungen beenden
- [7.1.1.3/H-3-1] MUSS einen HDR-Bildschirm mit mindestens 1.000 cd/m2 haben Durchschnitt.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [7.6.1/H-2-1] MUSS mindestens 8 GB physischen Arbeitsspeicher haben,
wobei mindestens 6,64 GB für den Kernel verfügbar sind,
android.app.ActivityManager.MemoryInfo.totalMem
Neue Anforderungen beenden
2.2.7.4 Leistung
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.U
für
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
- MÜSSEN die in Android 14 CDD, Abschnitt 2.2.7.4 aufgeführten Leistungsanforderungen erfüllen.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn die Implementierung von Handheld-Geräten wieder funktioniert
android.os.Build.VERSION_CODES.V
Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
:
Neue Anforderungen beenden
- [8.2/H-1-1] MÜSSEN eine sequentielle Schreibleistung von mindestens 150 MB/s gewährleisten.
- [8.2/H-1-2] MÜSSEN eine zufällige Schreibleistung von mindestens 10 MB/s gewährleisten.
- [8.2/H-1-3] MÜSSEN eine sequentielle Leseleistung von mindestens 250 MB/s gewährleisten.
- [8.2/H-1-4] MÜSSEN eine zufällige Leseleistung von mindestens 100 MB/s gewährleisten.
- [8.2/H-1-5] MÜSSEN eine parallele sequenzielle Lese- und Schreibleistung gewährleisten mit 2-facher Lese- und 1-facher Schreibleistung von mindestens 50 MB/s.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
2.2.7.5 Grafik
Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.V
zurückgeben
Für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
gilt Folgendes:
- [7.1.4.1/H-1-1] Diese Anforderung gilt ab Android 15 (AOSP experimentell) nicht mehr.
- [7.1.4.1/H-1-2] MUSS die
EGL_IMG_context_priority
undEGL_EXT_protected_content
Erweiterungen. - [7.1.4.1/H-1-3] MUSS unterstützt werden.
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
undVK_KHR_global_priority
.
Neue Anforderungen beenden
2.3. Fernsehanforderungen
Der Begriff Android-Fernsehgerät bezieht sich auf eine Implementierung auf Android-Geräten, ist eine Unterhaltungsoberfläche für den Konsum von digitalen Medien, Filmen, Spielen, Apps und/oder Live-TV für Nutzer, die etwa drei Meter entfernt sitzen (d. h. eine Benutzeroberfläche“).
Implementierungen von Android-Geräten werden als Fernseher eingestuft, wenn sie alle folgende Kriterien erfüllen:
- Bereitstellung eines Mechanismus zur Remote-Steuerung der gerenderten Benutzeroberfläche auf des Bildschirms, der etwa drei Meter vom Nutzer entfernt sein könnte.
- Sie haben einen eingebetteten Bildschirm mit einer diagonalen Länge von mehr als 24 Pixeln. Zoll ODER einen Videoausgangsanschluss wie VGA, HDMI, DisplayPort oder einen WLAN-Port für die Anzeige.
Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten nur für Android. Implementierung von Fernsehgeräten
2.3.1 Hardware
Implementierungen von Fernsehgeräten:
- [7.2.2/T-0-1] MUSS das Steuerkreuz unterstützen.
- [7.2.3/T-0-1] MÜSSEN die Startbildschirm- und Back-End-Werte Funktionen.
- [7.2.3/T-0-2] MÜSSEN sowohl das normale als auch das lange Drücken senden.
Ereignis der Zurück-Funktion (
KEYCODE_BACK
) zur Anwendung im Vordergrund. - [7.2.6.1/T-0-1] MUSS Support für ein Spiel enthalten
Controller und deklarieren das Funktions-Flag
android.hardware.gamepad
. - [7.2.7/T] SOLLTEN eine Fernbedienung bereitstellen, mit der Nutzer können auf die berührungslose Navigation und Eingaben für die Hauptnavigationstasten
Wenn Fernsehgeräte ein 3-Achsen-Gyroskop enthalten, ist Folgendes zu beachten:
- [7.3.4/T-1-1] MÜSSEN in der Lage sein, Ereignisse bis zu einer Frequenz von mindestens 100 Hz.
- [7.3.4/T-1-2] MUSS Ausrichtungsänderungen messen können bis zu 1000 Grad pro Sekunde.
Implementierungen von Fernsehgeräten:
- [7.4.3/T-0-1] MUSS Bluetooth und Bluetooth LE.
- [7.6.1/T-0-1] MUSS mindestens 4 GB an nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet).
Wenn Fernsehgeräte einen USB-Port enthalten, der den Hostmodus unterstützt, Sie:
- [7.5.3/T-1-1] MUSS eine externe Kamera unterstützen der über diesen USB-Anschluss angeschlossen wird, aber nicht unbedingt immer verbunden ist.
Bei 32-Bit-Implementierungen von TV-Geräten:
[7.6.1/T-1-1] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerbereich MUSS mindestens 896 MB betragen, wenn eine der folgenden Dichten verwendet wird:
- Mindestens 400 dpi auf kleinen/normalen Bildschirmen
- xhdpi oder höher auf großen Bildschirmen
- tvdpi oder höher auf sehr großen Bildschirmen
Bei 64-Bit-Implementierungen von TV-Geräten:
[7.6.1/T-2-1] Der für den Kernel verfügbare Arbeitsspeicher und Userspace MUSS mindestens 1.280 MB groß sein, wenn eine der folgenden Dichten zutrifft. verwendet:
- Mindestens 400 dpi auf kleinen/normalen Bildschirmen
- xhdpi oder höher auf großen Bildschirmen
- tvdpi oder höher auf sehr großen Bildschirmen
Beachten Sie, dass der für Kernel und Userspace verfügbare Arbeitsspeicher bezieht sich auf den Arbeitsspeicher zusätzlich zu vorhandenem Arbeitsspeicher für Hardware-Komponenten wie Radio, Video usw. vorgesehen sind, die nicht der Kontrolle über die Geräteimplementierung durch den Kernel.
Implementierungen von Fernsehgeräten:
- [7.8.1/T] SOLLTEN ein Mikrofon enthalten.
- [7.8.2/T-0-1] MUSS einen Audioausgang haben und deklarieren
android.hardware.audio.output
2.3.2 Multimedia
Implementierungen auf Fernsehgeräten MÜSSEN die folgende Audiocodierung unterstützen und Decodierungsformaten und stellen sie für Anwendungen von Drittanbietern zur Verfügung:
- [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC-Profil (AAC+)
- [5.1/T-0-3] AAC ELD (Optimierte AAC mit niedriger Verzögerung)
Implementierungen auf Fernsehgeräten MÜSSEN die folgende Videocodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:
Implementierungen von Fernsehgeräten:
- [5.2.2/T-SR-1] Support wird dringend empfohlen. H.264-Codierung von Videos mit einer Auflösung von 720p und 1080p bei 30 Bildern pro Sekunde
Implementierungen auf Fernsehgeräten MÜSSEN die folgende Videodecodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
- [5.3.2/T-0-7] AV1
Implementierungen von Fernsehgeräten MÜSSEN die MPEG-2-Decodierung unterstützen, wie im Abschnitt 5.3.1 bei standardmäßigen Video-Framerates und -Auflösungen bis zu einschließlich:
- [5.3.1/T-1-1] HD 1080p bei 29,97 Bildern pro Sekunde mit dem Hauptprofil auf hoher Ebene.
- [5.3.1/T-1-2] HD 1080i bei 59,94 Bildern pro Sekunde mit dem Hauptprofil auf hoher Ebene. Sie MÜSSEN MPEG-2-Videos mit Zeilenentflechtung per Deinterlacing konvertiert werden und sie für Drittanbieter-Anwendungen verfügbar zu machen.
Implementierungen von Fernsehgeräten MÜSSEN die H.264-Decodierung unterstützen, wie im Abschnitt 5.3.4 bei standardmäßigen Video-Framerates und ‐auflösungen bis zu einschließlich:
- [5.3.4/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Referenzprofil
- [5.3.4/T-1-2] HD 1080p bei 60 Bildern pro Sekunde mit Hauptprofil
- [5.3.4/T-1-3] HD 1080p bei 60 Bildern pro Sekunde mit High Profile Level 4.2
Implementierungen von Fernsehgeräten mit H.265-Hardwaredecoder müssen dies unterstützen. H.265-Decodierung, wie in Abschnitt 5.3.5 beschrieben, bei Standard-Video-Framerates und Auflösungen bis einschließlich:
- [5.3.5/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Hauptprofilebene 4.1
Wenn Implementierungen von Fernsehgeräten mit H.265-Hardwaredecoder unterstützt werden Für die H.265-Decodierung und das UHD-Decodierungsprofil gilt Folgendes:
- [5.3.5/T-2-1] MUSS das UHD-Decodierungsprofil unterstützen bei 60 Bildern pro Sekunde mit Main10 Level 5 in der Hauptstufe
Implementierungen von Fernsehgeräten MÜSSEN die VP8-Decodierung unterstützen, wie in den Abschnitt 5.3.6 bei standardmäßigen Video-Framerates und -Auflösungen bis zu einschließlich:
- [5.3.6/T-1-1] Decodierungsprofil in HD 1080p bei 60 Bildern pro Sekunde
Implementierungen von Fernsehgeräten mit VP9-Hardwaredecoder müssen VP9 unterstützen. Decodierung, wie in Abschnitt 5.3.7 beschrieben, bei Standard-Video-Framerates und Auflösungen bis einschließlich:
- [5.3.7/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Profil 0 (8-Bit-Farbtiefe)
Wenn Implementierungen von Fernsehgeräten mit VP9-Hardwaredecoder VP9 unterstützen und das UHD-Decodierungsprofil:
- [5.3.7/T-2-1] MUSS das UHD-Decodierungsprofil unterstützen bei 60 Bildern pro Sekunde mit Profil 0 (8 Bit Farbtiefe).
- [5.3.7/T-SR1] werden dringend empfohlen, die UHD-Decodierungsprofil bei 60 Bildern pro Sekunde mit Profil 2 (10-Bit-Farbtiefe).
Implementierungen von Fernsehgeräten:
- [5.5/T-0-1] MUSS Unterstützung für den System-Master Dämpfung der Lautstärke und der digitalen Audioausgabe an unterstützten Ausgängen außer bei der komprimierten Audio-Passthrough-Ausgabe, bei der keine Audiodecodierung durchgeführt wird. auf dem Gerät.
Haben Fernsehgeräte keinen integrierten Bildschirm, aber unterstützen stattdessen einen über HDMI angeschlossenen externen Bildschirm:
- [5.8/T-0-1] MUSS den HDMI-Ausgabemodus auf die höchste Auflösung für das ausgewählte Pixelformat, das mit 50 Hz oder 60 Hz funktioniert Aktualisierungsrate des externen Bildschirms, abhängig von der Videoaktualisierungsrate des die Region, in der das Gerät verkauft wird.
- [5.8/T-SR-1] werden dringend empfohlen, konfigurierbare Auswahl für die HDMI-Aktualisierungsrate.
- [5.8] SOLLTEN die Aktualisierungsrate des HDMI-Ausgabemodus festlegen, entweder auf 50 oder 60 Hz, je nach Videoaktualisierungsrate für die Region, unter dem das Gerät verkauft wird.
Haben Fernsehgeräte keinen integrierten Bildschirm, aber unterstützen stattdessen einen über HDMI angeschlossenen externen Bildschirm:
- [5.8/T-1-1] MUSS HDCP 2.2 unterstützen.
Wenn Implementierungen für Fernsehgeräte die UHD-Decodierung nicht unterstützen, unterstützen einen externen Bildschirm, der über HDMI angeschlossen ist. Sie:
- [5.8/T-2-1] MUSS HDCP 1.4 unterstützen.
2.3.3 Software
Implementierungen von Fernsehgeräten:
- [3/T-0-1] MÜSSEN die Funktionen deklarieren
android.software.leanback
undandroid.hardware.type.television
. - [3.2.3.1/T-0-1] MÜSSEN einen oder mehrere Anwendungen oder Dienstkomponenten mit Intent-Handlern für alle von den folgenden Anwendungs-Intents definierte öffentliche Intent-Filtermuster finden Sie hier.
- [3.4.1/T-0-1] MUSS eine vollständige
Implementierung der
android.webkit.Webview
API
Wenn Android TV-Geräteimplementierungen einen Sperrbildschirm unterstützen,gilt Folgendes:
- [3.8.10/T-1-1] MÜSSEN das Schloss anzeigen Screen Notifications einschließlich der Media Notification Template.
Implementierungen von Fernsehgeräten:
- [3.8.14/T-SR-1] werden dringend empfohlen. um den Bild-im-Bild-Modus (BiB) den Mehrfenstermodus zu unterstützen.
- [3.10/T-0-1] MÜSSEN Bedienungshilfen für Drittanbieter unterstützen. .
- [3.10/T-SR-1] EMPFOHLEN: Bedienungshilfen, die mit denen von vergleichbaren oder mehr als des Schalterzugriffs und von TalkBack (für Sprachen, die von vorinstallierten Text-in-Sprache-Funktionen, wie in den das Open-Source-Projekt „Talkback“.
Wenn Implementierungen von Fernsehgeräten die Funktion melden
android.hardware.audio.output
, sie/er:
- [3.11/T-SR-1] wird dringend empfohlen, Sprachausgabe-Engine, die die auf dem Gerät verfügbaren Sprachen unterstützt
- [3.11/T-1-1] MUSS die Installation von Sprachausgabe-Engines von Drittanbietern.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Implementierungen von Fernsehgeräten:
- [3.12/T-0-1] MUSS das TV Input Framework unterstützen.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Das Android Television Input Framework (TIF) vereinfacht Bereitstellung von Live-Inhalten an Android-Fernsehgeräte TIF stellt eine Standard- API zum Erstellen von Eingabemodulen, die Android TV-Geräte steuern
Implementierungen von Fernsehgeräten:
- [3/T-0-2] MUSS die Plattformfunktion deklarieren
android.software.live_tv
- [3/T-0-3] MUSS alle TIF APIs unterstützen, sodass eine Anwendung das diese APIs und die TIF-basierte Eingaben von Drittanbietern auf dem Gerät installiert und verwendet werden kann.
Das Android Television Tuner Framework (TF) Vereinheitlicht die Verarbeitung von Live-Inhalten aus dem Tuner mit Streaming-Inhalten von IP-Adressen auf Android TV-Geräten. Das Turner-Framework stellt eine Standard-API zum Erstellen von Eingabediensten, die den Android Television Tuner verwenden.
Wenn Geräteimplementierungen den Tuner unterstützen, gilt Folgendes:
- [3/T-1-1] MUSS alle Tuner Framework APIs unterstützen, sodass ein Anwendungen, die diese APIs verwenden, auf dem Gerät installiert und verwendet werden können.
Neue Anforderungen beenden
2.3.4 Leistung und Leistung
- [8.1/T-0-1] Konsistente Framelatenz. Inkonsistente Frame-Latenz oder Verzögerungen beim Rendern von Frames DÜRFEN NICHT öfter auftreten häufiger als 5 Frames pro Sekunde und SOLLTEN unter 1 Frames pro Sekunde liegen.
- [8.2/T-0-1] MÜSSEN sicherstellen, dass eine sequenzielle mit mindestens 5 MB/s schreiben.
- [8.2/T-0-2] MÜSSEN sicherstellen, dass ein zufälliger Schreibvorgang stattfindet. mit mindestens 0,5 MB/s arbeiten.
- [8.2/T-0-3] MÜSSEN sicherstellen, dass eine sequenzielle von mindestens 15 MB/s lesen.
- [8.2/T-0-4] MUSS einen zufälligen Lesevorgang sicherstellen mindestens 3,5 MB/s erreichen.
Wenn Implementierungen von Fernsehgeräten Funktionen zur Verbesserung der Geräteleistung enthalten die in AOSP enthalten sind, oder die Funktionen zu erweitern, bei AOSP:
- [8.3/T-1-1] MÜSSEN die Nutzeroptionen zur Aktivierung und den Energiesparmodus deaktivieren.
Fernsehgeräte ohne Akku:
- [8.3/T-1-2] MÜSSEN das Gerät als ein akkubetriebenes Gerät verwenden, wie unter Batterielose Geräte unterstützen beschrieben.
Wenn Fernsehgeräte einen Akku haben, gilt Folgendes:
- [8.3/T-1-3] MÜSSEN die angezeigten Nutzeroptionen bieten. Alle Apps, die vom App-Standby- und Stromsparmodus ausgenommen sind
Implementierungen von Fernsehgeräten:
- [8.4/T-0-1] MÜSSEN eine Leistungsprofil pro Komponente, das den aktuellen Verbrauchswert definiert für jede Hardwarekomponente und die ungefähre Entladung des Akkus aufgrund der wie auf der Website des Android Open Source Project dokumentiert.
- [8.4/T-0-2] MÜSSEN die gesamte Stromversorgung melden. Verbrauchswerte in Milliamperestunden (mAh) angegeben.
- [8.4/T-0-3] MÜSSEN die CPU-Leistung melden
pro Prozess UID. Das Open-Source-Projekt von Android erfüllt
Anforderung durch die Implementierung des Kernelmoduls
uid_cputime
. - [8.4/T] SOLLTE dem Hardwarekomponente selbst, wenn der Stromverbrauch der Hardwarekomponente nicht zugeordnet werden kann zu einer Anwendung hinzufügen.
- [8.4/T-0-4] MUSS diesen Stromverbrauch nutzen
verfügbar über
adb shell dumpsys batterystats
Shell-Befehl an den App-Entwickler senden.
2.3.5 Sicherheitsmodell
Implementierungen von Fernsehgeräten:
- [9/T-0-1] MÜSSEN die
android.hardware.security.model.compatible
deklarieren . - [9.11/T-0-1] MÜSSEN die Schlüsselspeicherimplementierung sichern. mit einer isolierten Ausführungsumgebung.
- [9.11/T-0-2] MUSS Implementierungen von RSA, AES, Die kryptografischen Algorithmen ECDSA und HMAC sowie die MD5-, SHA-1- und SHA-2-Familie Hash-Funktionen genutzt werden, um die vom Android-Schlüsselspeichersystem unterstützten in einem Bereich, der sicher vom Code isoliert ist, Kernel und höher. Sichere Isolation MUSS alle potenziellen Mechanismen blockieren über den Kernel- oder Userspace-Code auf den internen Status des einer isolierten Umgebung, einschließlich DMA. Die vorgelagerte Open-Source-Version von Android Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung, aber eine andere ARM TrustZone-basierte Lösung oder von einem Drittanbieter geprüfte sichere Lösung Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation sind eine Alternative Optionen.
- [9.11/T-0-3] MUSS den Sperrbildschirm starten in der isolierten Ausführungsumgebung und nur dann, erfolgreich war, können die mit der Authentifizierung gebundenen Schlüssel verwendet werden. Sperrbildschirm Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführung für die Sperrbildschirm-Authentifizierung. Die vorgelagerte Android- Open-Source-Projekt bietet Gatekeeper-Hardwareabstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
[9.11/T-0-4] MUSS die Schlüsselattestierung unterstützen, wenn die Der Attestierungssignaturschlüssel wird durch sichere Hardware geschützt und die Signatur ist auf sicherer Hardware ausgeführt werden. Die Signaturschlüssel der Attestierung MÜSSEN
gemeinsam verwendet werden Geräte groß genug ist, um die Schlüssel zu verhindern.verhindert nicht als dauerhaft Gerätekennungen.Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel, es sei denn, mindestens 100.000 Einheiten einer SKU produziert wurden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, für je 100.000 Einheiten.
Neue Anforderungen beenden
Wenn eine Geräteimplementierung bereits auf einer früheren Android-Version
-Version ist ein solches Gerät von der Anforderung ausgenommen, einen Schlüsselspeicher zu haben.
eine isolierte Ausführungsumgebung nutzen
und die Schlüsselattestierung unterstützen,
es sei denn, die Funktion android.hardware.fingerprint
wird deklariert, für die ein
Schlüsselspeicher, der von einer isolierten Ausführungsumgebung unterstützt wird.
Wenn Implementierungen von Fernsehgeräten einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:
- [9.11/T-1-1] MUSS dem Nutzer die Möglichkeit geben, den Schlafmodus Zeitlimit für den Wechsel vom entsperrten in den gesperrten Zustand, wobei ein Das minimale zulässige Zeitlimit beträgt maximal 15 Sekunden.
Wenn die Implementierung von Fernsehgeräten mehrere Nutzer umfasst und
Das Funktions-Flag android.hardware.telephony
wird nicht deklariert, sie werden:
- [9.5/T-2-1] MUSS eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteeigentümer zusätzliche Nutzer und ihre Funktionen auf dem Gerät. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen einrichten, in denen zusätzliche Nutzende arbeiten können, mit der Möglichkeit, differenziertere Einschränkungen in den Apps zu verwalten, die in diesen Umgebungen verfügbar sind.
Wenn die Implementierung von Fernsehgeräten mehrere Nutzer umfasst und
das Funktions-Flag android.hardware.telephony
deklarieren, wenn folgende Aktionen ausgeführt werden:
- [9.5/T-3-1] DÜRFEN KEINE Unterstützung eingeschränkter Einschränkungen unterstützen Profile, MÜSSEN jedoch mit der AOSP-Implementierung der Kontrollen übereinstimmen. , um zu aktivieren /deaktivieren, dass andere Nutzer auf die Sprachanrufe und SMS zugreifen können.
Wenn in Implementierungen von Fernsehgeräten android.hardware.microphone
deklariert ist, gilt Folgendes:
- [9.8.2/T-4-1] MUSS die Mikrofonanzeige einblenden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn das Mikrofon auf das Mikrofon nur durch HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 beschriebenen Rollen Berechtigungen mit CDD-Kennung C-3-X.
- [9.8.2/T-4-2] DARF die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
Wenn in Implementierungen von Fernsehgeräten android.hardware.camera.any
deklariert ist, gilt Folgendes:
- [9.8.2/T-5-1] MUSS die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn die Kamera nur auf die Apps zugreifen, die die in Abschnitt 9.1 genannten Rollen innehaben Berechtigungen mit CDD-Kennung [C-3-X].
- [9.8.2/T-5-2] DARF die Kameraanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
2.3.6. Kompatibilität von Entwicklertools und -optionen
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Implementierungen von Fernsehgeräten:
- Perfetto
<ph type="x-smartling-placeholder">
- </ph>
- [6.1/T-0-1] MUSS eine
/system/bin/perfetto
-Angabe verfügbar machen Binärdatei, die der cmdline entspricht Perfetto-Dokumentation. - [6.1/T-0-2] Das Perfetto-Binärprogramm MUSS akzeptiert werden als Geben Sie eine protobuf-Konfiguration ein, die dem in Perfetto-Dokumentation.
- [6.1/T-0-3] Das Perfetto-Binärprogramm MUSS schreiben als einen protobuf-Trace ausgeben, der dem in Perfetto-Dokumentation.
- [6.1/T-0-4] MÜSSEN im Rahmen des Perfettos angeben. binär, zumindest die unter Perfetto-Dokumentation.
- [6.1/T-0-5] Der perfetto verfolgte Daemon
MÜSSEN standardmäßig aktiviert sein (Systemeigenschaft
persist.traced.enable
).
- [6.1/T-0-1] MUSS eine
Neue Anforderungen beenden
2.4. Smartwatch-Anforderungen
Android Watch-Gerät bezieht sich auf eine Android-Geräteimplementierung, die am Körper getragen werden, vielleicht am Handgelenk.
Implementierungen von Android-Geräten werden als Smartwatch klassifiziert, wenn sie alle folgenden Kriterien:
- Die Bildschirmdiagonale muss zwischen 1,1 und 2,5 liegen. Zoll.
- Ein Mechanismus zum Tragen am Körper muss vorhanden sein.
Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten nur für Android. Sehen Sie sich die Implementierungen der Geräte an.
2.4.1 Hardware
Implementierungen von Smartwatch-Geräten:
[7.1.1.1/W-0-1] MUSS einen Bildschirm mit der der physischen Diagonale im Bereich von 2,9 bis 6,8 cm.
[7.2.3/W-0-1] MUSS die Home-Funktion verfügbar haben. und die Back-Funktion, es sei denn, sie befindet sich in
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] MUSS die Touchscreen-Eingabe unterstützen.
[7.3.1/W-SR-1] WIRD UNBEDINGT ZU 3-Achsen EMPFOHLEN Beschleunigungsmesser.
Wenn Implementierungen auf Smartwatch-Geräten Vulkan unterstützen, gilt Folgendes:
- [7.1.4.2/W-1-1] MUSS die Anforderungen erfüllen im Profil Android Baseline 2021 angegeben.
Wenn die Implementierung der Uhr einen GPS-/GNSS-Empfänger umfasst und das
über die android.hardware.location.gps
-Funktion verfügbar machen.
melden sie:
- [7.3.3/W-1-1] MÜSSEN GNSS-Messungen melden, sobald sie gefunden werden, auch wenn ein über GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
- [7.3.3/W-1-2] MÜSSEN GNSS-Pseudorange und Pseudorange melden nach der Bestimmung des Standorts unter freiem Himmel, während oder sich bewegen, weniger als 0,2 Meter pro Sekunde zum Quadrat beschleunigen, reichen aus, um die Position innerhalb von 20 Metern zu berechnen, und die Geschwindigkeit. in mindestens 95% der Fälle mit einer Geschwindigkeit von 0, 2 Metern pro Sekunde.
Wenn Smartwatch-Implementierungen ein 3-Achsen-Gyroskop enthalten, gilt Folgendes:
- [7.3.4/W-2-1] MUSS Ausrichtungsänderungen messen können bis zu 1000 Grad pro Sekunde.
Implementierungen von Smartwatch-Geräten:
[7.4.3/W-0-1] MUSS Bluetooth unterstützen.
[7.6.1/W-0-1] MUSS mindestens 1 GB an nichtflüchtiger Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet).
[7.6.1/W-0-2] MUSS mindestens 416 MB Arbeitsspeicher haben für den Kernel und Userspace.
[7.8.1/W-0-1] MUSS ein Mikrofon enthalten.
[7.8.2/W] KÖNNEN Audioausgang haben.
2.4.2 Multimedia
Keine zusätzlichen Anforderungen.
2.4.3 Software
Implementierungen von Smartwatch-Geräten:
- [3/W-0-1] MUSS das Element deklarieren
android.hardware.type.watch
- [3/W-0-2] MUSS uiMode = unterstützen UI_MODE_TYPE_WATCH.
- [3.2.3.1/W-0-1] MUSS einen vorab laden. oder mehr Anwendungen oder Dienstkomponenten mit Intent-Handlern enthalten, alle öffentlichen Intent-Filtermuster, die von der folgenden Anwendung definiert wurden Hier finden Sie eine Liste der Intents.
Implementierungen von Smartwatch-Geräten:
- [3.8.4/W-SR-1] werden dringend empfohlen. um einen Assistenten für die Unterstützungsaktion auf dem Gerät zu implementieren.
Implementierungen von Geräten beobachten, die die android.hardware.audio.output
deklarieren
Funktions-Flag:
- [3.10/W-1-1] MUSS Bedienungshilfen für Drittanbieter unterstützen .
- [3.10/W-SR-1] wird dringend empfohlen, vorab zu laden Bedienungshilfen auf dem Gerät, die mit der Funktionalität vergleichbar oder sogar übertreffen des Schalterzugriffs und von TalkBack (für Sprachen, die vom vorinstallierten Bedienungshilfen (Text-in-Sprache-Engine), die in den Talkback-Open-Source-Projekt.
Wird bei Implementierungen der Smartwatch die Funktion „android.hardware.audio.output“ gemeldet, Sie:
[3.11/W-SR-1] wird dringend empfohlen, Folgendes anzugeben: Sprachausgabe-Engine, die die auf dem Gerät verfügbaren Sprachen unterstützt
[3.11/W-0-1] MUSS die Installation von Sprachausgabe-Engines von Drittanbietern.
2.4.4 Leistung und Leistung
Ob Smartwatch-Implementierungen Funktionen zur Verbesserung der Geräteleistung enthalten die in AOSP enthalten sind, oder die Funktionen zu erweitern, bei AOSP:
- [8.3/W-SR-1] werden dringend empfohlen, die Möglichkeit, alle Apps anzuzeigen, die vom App-Standby-Modus ausgenommen sind, Stromsparmodi
- [8.3/W-SR-2] werden dringend empfohlen, Nutzer können den Energiesparmodus aktivieren und deaktivieren.
Implementierungen von Smartwatch-Geräten:
- [8.4/W-0-1] MUSS eine Leistungsprofil pro Komponente, das den aktuellen Verbrauchswert definiert für jede Hardwarekomponente und die ungefähre Entladung des Akkus aufgrund der wie auf der Website des Android Open Source Project dokumentiert.
- [8.4/W-0-2] MÜSSEN die gesamte Stromversorgung melden Verbrauchswerte in Milliamperestunden (mAh) angegeben.
- [8.4/W-0-3] MÜSSEN die CPU-Leistung melden
pro Prozess UID. Das Open-Source-Projekt von Android erfüllt
Anforderung durch die Implementierung des Kernelmoduls
uid_cputime
. - [8.4/W-0-4] MUSS diesen Stromverbrauch nutzen
verfügbar über
adb shell dumpsys batterystats
Shell-Befehl an den App-Entwickler senden. - [8.4/W] SOLLTE dem Hardwarekomponente selbst, wenn der Stromverbrauch der Hardwarekomponente nicht zugeordnet werden kann zu einer Anwendung hinzufügen.
2.4.5 Sicherheitsmodell
Implementierungen von Smartwatch-Geräten:
- [9/W-0-1] MUSS die
android.hardware.security.model.compatible
deklarieren .
Wenn die Implementierung von Smartwatch-Geräten von mehreren Nutzern
Das Funktions-Flag android.hardware.telephony
wird nicht deklariert, sie werden:
- [9.5/W-1-1] MUSS eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteeigentümer zusätzliche Nutzer und ihre Funktionen auf dem Gerät. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen einrichten, in denen zusätzliche Nutzende arbeiten können, mit der Möglichkeit, differenziertere Einschränkungen in den Apps zu verwalten, die in diesen Umgebungen verfügbar sind.
Wenn die Implementierung von Smartwatch-Geräten von mehreren Nutzern
das Funktions-Flag android.hardware.telephony
deklarieren, wenn folgende Aktionen ausgeführt werden:
- [9.5/W-2-1] DÜRFEN KEINE Unterstützung eingeschränkter Einschränkungen unterstützen Profile, MÜSSEN jedoch mit der AOSP-Implementierung der Kontrollen übereinstimmen. , um zu aktivieren /deaktivieren, dass andere Nutzer auf die Sprachanrufe und SMS zugreifen können.
Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agenten enthalten, die die TrustAgentService
System API implementieren, geschieht Folgendes:
- [9.11.1/W-1-1] MÜSSEN den Nutzer häufiger als alle 72 Stunden zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) auffordern.
2.5. Fahrzeuganforderungen
Die Android Automotive-Implementierung bezieht sich auf die Haupteinheit eines Fahrzeugs, Android als Betriebssystem für einen Teil oder das gesamte System und/oder Infotainmentfunktionen.
Implementierungen von Android-Geräten werden als Automobil klassifiziert, wenn
das Feature android.hardware.type.automotive
oder alle folgenden
Kriterien.
- Sie sind als Teil eines Fahrzeugs eingebettet oder können an das angeschlossene Fahrzeug angeschlossen werden.
- ein Display in der Fahrersitzreihe als primäres Display verwenden.
Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten nur für Android. Implementierungen von Automobilgeräten
2.5.1 Hardware
Implementierungen von Automobilgeräten:
- [7.1.1.1/A-0-1] MUSS mindestens einen Bildschirm haben 6 Zentimeter in physikalischer diagonaler Größe.
- [7.1.1.1/A-0-2] MUSS ein Layout mit der Bildschirmgröße haben mindestens 750 dp x 480 dp.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen
bei denen mehrere Android-Nutzer gleichzeitig
mit dem Gerät interagieren können,
die alle ihr eigenes Display verwenden,
config_multiuserVisibleBackgroundUsers
aktiviert ist, werden sie:
- [7.1.1.1/A-1-1] MUSS einen separaten Bildschirm mit
in jedem Insassenbereich der Kamera
Hauptdisplay. Dies sollte wie folgt gekennzeichnet werden:
CarOccupantZoneManager.DISPLAY_TYPE_MAIN
für jeden Insassenbereich festlegen. - [7.1.1.1/A-1-2] MUSS ein Layout mit der Bildschirmgröße haben von mindestens 750 dp x 480 dp für jeden Hauptbildschirm.
Neue Anforderungen beenden
Wenn Automotive-Geräteimplementierungen OpenGL ES 3.1 unterstützen, gilt Folgendes:
- [7.1.4.1/A-0-1] MUSS OpenGL ES 3.1 oder höher.
- [7.1.4.1/A-0-2] MUSS Vulkan 1.1 unterstützen.
- [7.1.4.1/A-0-3] MUSS das Vulkan-Ladeprogramm enthalten. und alle Symbole exportieren.
Wenn Implementierungen von Automobil-Geräten Vulkan unterstützen, gilt Folgendes:
- [7.1.4.2/A-1-1] MUSS die Anforderungen erfüllen im Profil Android Baseline 2021 angegeben.
Implementierungen von Automobilgeräten:
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [7.1.7/A-0-1] MÜSSEN konfigurieren
sekundäre Displays
in der Sichtweite des Fahrers
FLAG_PRIVATE
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [7.2.3/A-0-1] MÜSSEN
dasZuhause und Zurück-Funktionen und KÖNNEN eineZurück unddie Letzte Funktionen.
Neue Anforderungen beenden
- [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.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen
bei denen mehrere Android-Nutzer gleichzeitig
mit dem Gerät interagieren können,
die alle ihr eigenes Display verwenden,
config_multiuserVisibleBackgroundUsers
aktiviert ist, werden sie:
- [7.3/A-1-1] MÜSSEN die
NIGHT_MODE
Werte konsistent mit dem Tag-/Nachtmodus des Dashboards allen Displays, auch die Displays für die Rücksitze.
Neue Anforderungen beenden
Wenn Automobil-Geräte einen Beschleunigungsmesser enthalten, gilt Folgendes:
- [7.3.1/A-1-1] MÜSSEN in der Lage sein, Ereignisse bis zu einer bestimmten Häufigkeit zu melden. von mindestens 100 Hz.
Wenn Geräte einen dreiachsigen Beschleunigungsmesser enthalten, gilt Folgendes:
- [7.3.1/A-SR-1] wird dringend empfohlen, die Komposit-Sensor für den begrenzten Achsen-Beschleunigungsmesser.
Wenn Automobil-Geräte einen Beschleunigungsmesser mit weniger als 3 Achsen:
- [7.3.1/A-1-3] MÜSSEN implementieren und melden,
TYPE_ACCELEROMETER_LIMITED_AXES
-Sensor. - [7.3.1/A-1-4] MÜSSEN implementieren und melden,
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
-Sensor.
Wenn Automobil-Geräteimplementierungen ein Gyroskop enthalten, ist Folgendes zu beachten:
- [7.3.4/A-2-1] MÜSSEN in der Lage sein, Ereignisse bis zu einer bestimmten Häufigkeit zu melden. von mindestens 100 Hz.
- [7.3.4/A-2-3] MÜSSEN in der Lage sein, Ausrichtungsänderungen zu messen. bis zu 250 Grad pro Sekunde.
- [7.3.4/A-SR-1] wird dringend empfohlen, die Messbereich des Gyroskops auf +/-250 dps setzen, um die Auflösung zu maximieren möglich.
Wenn Automobil-Geräteimplementierungen ein 3-Achsen-Gyroskop umfassen, ist Folgendes zu beachten:
- [7.3.4/A-SR-2] wird dringend empfohlen, die Komposit-Sensor für ein begrenztes Achsen-Gyroskop.
Wenn Geräte in der Automobilbranche ein Gyroskop mit weniger als 3 Achsen enthalten, gilt Folgendes:
- [7.3.4/A-4-1] MÜSSEN implementieren und melden,
TYPE_GYROSCOPE_LIMITED_AXES
-Sensor. - [7.3.4/A-4-2] MÜSSEN implementieren und melden,
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
-Sensor.
Wenn Automobil-Geräte einen GPS-/GNSS-Empfänger enthalten, aber nicht umfassen:
- [7.3.3/A-3-1] MÜSSEN den Standort beim ersten Mal bestimmen. der GPS/GNSS-Empfänger eingeschaltet oder nach mehr als 4 Tagen innerhalb von 60 Sekunden eingeschaltet ist.
- [7.3.3/A-3-2] MUSS die Kriterien für die Zeit bis zur ersten Behebung erfüllen wie beschrieben in 7.3.3/C-1-2 und 7.3.3/C-1-6 für alle anderen Standortanfragen (d. h. Anfragen, die nicht das erste Mal sind, oder nach mehr als 4 Tagen. Die Anforderung 7.3.3/C-1-2 ist die in der Regel in Fahrzeugen ohne mobilfunkbasierte Datenverbindung erfüllt sind. indem Sie die vom Empfänger berechnete GNSS-Umlaufbahnvorhersage oder die Funktion letzten bekannten Fahrzeugstandorts und der Fähigkeit, mit einer Positionsgenauigkeit, die 7.3.3/C-1-3 oder eine Kombination aus beiden verwenden.
Wenn Fahrzeugimplementierungen einen TYPE_HEADING
-Sensor enthalten, gilt Folgendes:
- [7.3.4/A-4-3] MÜSSEN in der Lage sein, Ereignisse bis zu einer bestimmten Häufigkeit zu melden, von mindestens 1 Hz.
- [7.3.4/A-SR-3] STRONGLY_RECOMMENDED zum Melden von Ereignissen bis zu Frequenz von mindestens 10 Hz.
- SOLLTE sich auf den geografischen Norden beziehen.
- SOLLTEN auch verfügbar sein, wenn das Fahrzeug stillsteht.
- SOLLTE eine Auflösung von mindestens 1 Grad haben.
Implementierungen von Automobilgeräten:
- [7.4.3/A-0-1] MUSS Bluetooth unterstützen und sollte unterstützen Bluetooth LE.
- [7.4.3/A-0-2] Android Automotive-Implementierungen
MÜSSEN die folgenden Bluetooth-Profile unterstützen:
<ph type="x-smartling-placeholder">
- </ph>
- Telefonanrufe über Hands-Free Profile (HFP).
- Medienwiedergabe über das Audio Distribution Profile (A2DP)
- Steuerung der Medienwiedergabe über das Remote Control Profile (AVRCP)
- Kontaktfreigabe über das Phone Book Access Profile (PBAP)
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [7.4.3/A-SR-1] Support wird dringend empfohlen. Message Access Profile (MAP), wenn das Gerät eine Insassenzone hat.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen
bei denen mehrere Android-Nutzer gleichzeitig
mit dem Gerät interagieren können,
die alle ihr eigenes Display verwenden,
config_multiuserVisibleBackgroundUsers
aktiviert ist, werden sie:
- [7.4.3/A-1-1] MUSS unabhängig sein und NICHT stören mit denen anderer Nutzer BT-Erfahrung.
Neue Anforderungen beenden
Implementierungen von Automobilgeräten:
- [7.4.5/A] SOLLTEN Support für Mobilfunk beinhalten netzwerkbasierte Datenverbindung.
- [7.4.5/A] KANN die System API verwenden.
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
-Konstante für die für System-Apps verfügbar sein sollen.
Wenn Geräteimplementierungen AM/FM-Radio unterstützen und die Funktionalität in jeder Anwendung zu nutzen,
- [7.4/A-1-1]
MÜSSEN die Unterstützung für
FEATURE_BROADCAST_RADIO
deklarieren.
Eine nach hinten gerichtete Kamera ist eine nach außen gerichtete Kamera, die an jedem beliebigen Ort angebracht werden kann am Fahrzeug platzieren und zur Außenseite des Fahrzeugkabins zeigen; Das heißt, es am anderen Ende der Karosserie, z. B. von der Rückkamera.
Eine Frontkamera ist eine Kamera für den Nutzer, die an jeder beliebigen Stelle am Fahrzeug montieren und in den Innenraum des Fahrzeugs zeigen; Das war's z. B. für Videokonferenzen und ähnliche Anwendungen.
Implementierungen von Automobilgeräten:
- [7.5/A-SR-1] WIRD UNBEDINGT EMPFOHLEN, eine oder mehrere weltweit sichtbare Kameras.
- KANN eine oder mehrere Kameras für den Nutzer enthalten.
- [7.5/A-SR-2] WIRD UNBEDINGT EMPFOHLEN, das gleichzeitige Streaming von mehrere Kameras verwenden.
Wenn Implementierungen für Automobilgeräte mindestens eine Kamera umfassen, die für eine solche Kamera:
- [7.5/A-1-1] MUSS so ausgerichtet werden, dass die lange Seite der Kamera mit der x-y-Ebene von Android-Automobilsensorachsen.
- [7.5/A-SR-3] WIRDEN UNBEDINGT EMPFOHLEN, entweder Fixfokus oder EDOF zu verwenden Hardware für die erweiterte Tiefenschärfe.
- [7.5/A-1-2] MUSS die primäre Kamera, die nach links gerichtet ist, als nach außen gerichtete Kamera verwenden. Kamera mit der niedrigsten Kamera-ID.
Wenn Implementierungen für Automobilgeräte mindestens eine Kamera umfassen, die für den Nutzer:
- [7.5/A-2-1] Die primäre Kamera für den Nutzer MUSS die Kamera für den Nutzer sein. mit der niedrigsten Kamera-ID.
- KANN so ausgerichtet werden, dass die lange Dimension der Kamera auf X-Y ausgerichtet ist. Ebene von Android-Automotive-Sensorachsen.
Wenn Automotive-Geräte eine Kamera umfassen, die über
entweder android.hardware.Camera
oder android.hardware.camera2
API, dann geschieht Folgendes:
- [7.5/A-3-1] MUSS den grundlegenden Kameraanforderungen in Abschnitt 7.5 entsprechen.
Wenn Automotive-Geräte eine Kamera enthalten, die nicht zugänglich ist
über die android.hardware.Camera
- oder android.hardware.camera2
-API, dann
Sie:
- [7.5/A-4-1] MÜSSEN über den Extended View System-Dienst zugänglich sein.
Wenn Automotive-Geräteimplementierungen eine oder mehrere Kameras umfassen, die über Extended View System Service:
- [7.5/A-5-1] Dürfen die Kameravorschau NICHT drehen oder horizontal spiegeln.
- [7.5/A-SR-4] Eine Auflösung von mindestens 1,3 wird dringend empfohlen. Megapixel.
Wenn die Implementierung von Automobilgeräten eine oder mehrere Kameras umfasst, die
zugänglich sowohl über den Extended View System Service als auch über android.hardware.Camera
oder android.hardware.Camera2
API verwenden, wird für eine solche Kamera Folgendes ausgeführt:
- [7.5/A-6-1] MÜSSEN dieselbe Kamera-ID melden.
Wenn Automotive-Geräteimplementierungen eine proprietäre Kamera-API bieten, gilt Folgendes:
- [7.5/A-7-1] MÜSSEN eine solche Kamera-API mithilfe von
android.hardware.camera2
API oder Extended View System API.
Implementierungen von Automobilgeräten:
[7.6.1/A-0-1] MUSS mindestens 4 GB an nichtflüchtiger Speicher für private Anwendungsdaten (Partition
/data
)[7.6.1/A] SOLLTEN die Datenpartition formatieren. um die Leistung und Langlebigkeit des Flash-Speichers zu verbessern (z. B. mithilfe des Dateisystems
f2fs
).
Wenn Automotive-Geräteimplementierungen gemeinsamen externen Speicher über ein des internen nicht entfernbaren Speichers verwendet werden,
- [7.6.1/A-SR-1] wird dringend empfohlen, die
E/A-Overhead bei Vorgängen auf dem externen Speicher, zum Beispiel von
mit
SDCardFS
.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen
bei denen mehrere Android-Nutzer gleichzeitig
mit dem Gerät interagieren können,
die alle ihr eigenes Display verwenden,
config_multiuserVisibleBackgroundUsers
aktiviert ist, werden sie:
- [7.6.1/A-1-1] MUSS auf einer einzelnen AAOS-Instanz Folgendes haben:
mindestens 4 GB für jeden gleichzeitigen Android-Nutzer von nichtflüchtigen Speicher
verfügbar für private Anwendungsdaten (Partition
/data
).
Neue Anforderungen beenden
Bei Automotive-Geräten mit 64-Bit-Implementierungen:
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
[7.6.1/A-2-1] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerbereich MUSS mindestens 816 MB groß sein. pro Hauptdisplay wenn eine der folgenden Dichten verwendet wird:
- Maximal 280 dpi auf kleinen/normalen Bildschirmen
- LDPI oder niedriger auf sehr großen Bildschirmen
- mdpi oder niedriger auf großen Bildschirmen
[7.6.1/A-2-2] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerbereich MUSS mindestens 944 MB groß sein. pro Hauptdisplay wenn eine der folgenden Dichten verwendet wird:
- xhdpi oder höher auf kleinen/normalen Bildschirmen
- HDPI oder mehr auf großen Bildschirmen
- mdpi oder höher auf extragroßen Bildschirmen
[7.6.1/A-2-3] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerbereich MUSS mindestens 1.280 MB groß sein. pro Hauptdisplay wenn eine der folgenden Dichten verwendet wird:
- Mindestens 400 dpi auf kleinen/normalen Bildschirmen
- xhdpi oder höher auf großen Bildschirmen
- tvdpi oder höher auf sehr großen Bildschirmen
[7.6.1/A-2-4] Der für den Kernel verfügbare Arbeitsspeicher und Nutzerbereich MUSS mindestens 1.824 MB groß sein. pro Hauptdisplay wenn eine der folgenden Dichten verwendet wird:
- Mindestens 560 dpi auf kleinen/normalen Bildschirmen
- Mindestens 400 dpi auf großen Bildschirmen
- xhdpi oder höher auf extragroßen Bildschirmen
Beachten Sie, dass der für Kernel und Userspace verfügbare Arbeitsspeicher bezieht sich auf den Arbeitsspeicher zusätzlich zu dem bereits für Hardware vorgesehenen Arbeitsspeicher wie Radio, Video usw., die sich nicht im Kernel- Geräteimplementierungen steuern.
Neue Anforderungen beenden
Implementierungen von Automobilgeräten:
- [7.7.1/A] SOLLTEN einen USB-Port haben, der den Peripheriemodus unterstützt.
Implementierungen von Automobilgeräten:
- [7.8.1/A-0-1] MUSS ein Mikrofon enthalten.
Implementierungen von Automobilgeräten:
- [7.8.2/A-0-1] MUSS einen Audioausgang haben und deklarieren
android.hardware.audio.output
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen
bei denen mehrere Android-Nutzer gleichzeitig
mit dem Gerät interagieren können,
die alle ihr eigenes Display verwenden,
config_multiuserVisibleBackgroundUsers
aktiviert ist, werden sie:
- [7.8.2/A-1-1] MUSS für jeden Hauptanschluss ein Audioausgabegerät haben. gleichzeitige Nutzersysteme anzeigen.
- [7.8.2/A-1-2] MUSS einen Audiobereich für den Fahrer haben, der die globalen Innenraumlautsprecher. Im Beifahrerbereich kann Audio vom Fahrer geteilt werden oder eine eigene Audioausgabe haben.
Neue Anforderungen beenden
2.5.2 Multimedia
Implementierungen für Automobilgeräte MÜSSEN die folgende Audiocodierung unterstützen und Decodierungsformaten und stellen sie für Anwendungen von Drittanbietern zur Verfügung:
- [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/A-0-2] MPEG-4 HE AAC-Profil (AAC+)
- [5.1/A-0-3] AAC ELD (Optimierte AAC mit niedriger Verzögerung)
Implementierungen für Automobilgeräte MÜSSEN die folgende Videocodierung unterstützen Formate und stellen sie für Anwendungen von Drittanbietern zur Verfügung:
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
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen
bei denen mehrere Android-Nutzer gleichzeitig
mit dem Gerät interagieren können,
die alle ihr eigenes Display verwenden,
config_multiuserVisibleBackgroundUsers
aktiviert ist, werden sie:
- [5.5.3/A-1-1] MÜSSEN identische Volumenkurven für dass alle Audioausgabestreams derselben Lautstärkegruppe gemäß Definition in Auto-Audio-Konfigurationsdatei.
Neue Anforderungen beenden
2.5.3 Software
Implementierungen von Automobilgeräten:
[3/A-0-1] MUSS das Element deklarieren
android.hardware.type.automotive
[3/A-0-2] MUSS uiMode =
UI_MODE_TYPE_CAR
unterstützen.[3/A-0-3] MUSS alle öffentlichen APIs im
android.car.*
-Namespace auf sie zugegriffen werden.
Wenn Automotive-Geräteimplementierungen eine proprietäre API mit
android.car.CarPropertyManager
mit
android.car.VehiclePropertyIds
,
Sie:
- [3/A-1-1] DÜRFEN KEINE Sonderberechtigungen an das System anhängen oder Anwendungen von Drittanbietern verhindern. diese Eigenschaften zu schützen.
- [3/A-1-2] DÜRFEN KEINE Fahrzeugeigenschaft replizieren, die bereits ist im SDK enthalten.
Implementierungen von Automobilgeräten:
[3.2.1/A-0-1] MUSS alle Berechtigungskonstanten, wie auf der Referenzseite für Automotive-Berechtigungen dokumentiert.
[3.2.3.1/A-0-1] MÜSSEN einen oder mehrere mehr Anwendungen oder Dienstkomponenten mit einem Intent-Handler, von den folgenden Anwendungs-Intents definierte öffentliche Intent-Filtermuster finden Sie hier.
[3.4.1/A-0-1] MUSS eine vollständige Implementierung der
android.webkit.Webview
API
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [3.8/A-0-1] DÜRFEN NICHT erlauben, dass sekundäre Nutzer, die nicht der aktuelle Nutzer im Vordergrund sind, Aktivitäten starten und auf allen Bildschirmen Zugriff auf die Benutzeroberfläche haben.
Wenn Automotive-Geräteimplementierungen gleichzeitig mehrere Nutzer unterstützen
bei denen mehrere Android-Nutzer gleichzeitig
mit dem Gerät interagieren können,
die alle ihr eigenes Display verwenden,
config_multiuserVisibleBackgroundUsers
aktiviert ist)
für sekundäre Nutzer, die nicht der aktuelle Nutzer im Vordergrund sind
aber mit UI-Zugriff auf die Anzeige ausgeführt werden, gilt Folgendes:
[3.8/A-1-1] MUSS die folgende vordefinierte Liste von
UserRestrictions
implementieren:[3.8/A-1-2] DARF diesem Nutzer NICHT erlauben können Sie die folgenden Einstellungen für jeden anderen Nutzer ändern, über die Einstellungen oder eine API:
- Tag-/Nachtmodus
- Sprache
- Datum
- Uhrzeit
- Zeitzone
- Farbfunktionen wie Helligkeit, Nachtlicht, Digital Wellbeing – Graustufen und „Helle Farben reduzieren“)
Neue Anforderungen beenden
Implementierungen von Automobilgeräten:
[3.8.3/A-0-1] MUSS angezeigt werden. Benachrichtigungen mit dem
Notification.CarExtender
API, wenn sie von Drittanbieteranwendungen angefordert werden.[3.8.4/A-SR-1] dringend empfohlen um einen Assistenten für die Unterstützungsaktion auf dem Gerät zu implementieren.
Wenn Implementierungen von Automobil-Geräten eine Push-to-Talk-Taste enthalten, gilt Folgendes:
- [3.8.4/A-1-1] MÜSSEN kurz die Taste
die entsprechende Interaktion zum Starten des
vom Nutzer ausgewählte Assistent-App, d. h. die App, die
VoiceInteractionService
Implementierungen von Automobilgeräten:
- [3.8.3.1/A-0-1] MUSS korrekt
Renderingressourcen wie in
Notifications on Automotive OS
beschrieben SDK-Dokumentation - [3.8.3.1/A-0-2] MÜSSEN
ABSPIELEN und STUMMSCHALTEN für Benachrichtigungsaktionen anstelle derjenigen, die über
Notification.Builder.addAction()
- [3.8.3.1/A] SOLLTE Einschränkung der Umfangreiche Verwaltungsaufgaben wie die Steuerung einzelner Benachrichtigungskanäle nutzen. KANN die UI-Angebote pro Anwendung verwenden, um die Steuerungsmöglichkeiten zu reduzieren.
Wenn Automotive-Geräteimplementierungen Nutzer-HAL-Eigenschaften unterstützen, gilt Folgendes:
- [3.9.3/A-1-1] MÜSSEN alle
Properties für den Nutzerlebenszyklus
<ph type="x-smartling-placeholder">
- </ph>
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
.
Implementierungen von Automobilgeräten:
- [3.14/A-0-1] MUSS ein UI-Framework zur Unterstützung enthalten. Drittanbieter-Apps, die die im Abschnitt 3.14.
- [3.14/A-0-2] MUSS dem Nutzer eine sichere Interaktion ermöglichen mit Medienanwendungen während der Fahrt.
- [3.14/A-0-3] MUSS die
CAR_INTENT_ACTION_MEDIA_TEMPLATE
impliziten Intent-Aktion mit 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 dem
CAR_INTENT_ACTION_MEDIA_TEMPLATE
die Nutzerabsicht verstehen.
Implementierungen von Automobilgeräten:
- [3.8/A] KANN die Anwendung einschränken.
um in den Vollbildmodus zu wechseln, wie unter
immersive documentation
beschrieben. - [3.8/A] KANN die Statusleiste und immer sichtbar ist.
- [3.8/A] KANN die Anwendung einschränken. die Farben hinter den UI-Elementen des Systems zu ändern, und diese Elemente immer deutlich sichtbar sind.
2.5.4 Leistung und Leistung
Implementierungen von Automobilgeräten:
- [8.2/A-0-1] MUSS die Anzahl der
Byte für den nichtflüchtigen Speicher gemäß der UID jedes Prozesses,
Statistiken stehen Entwicklern über die System-API zur Verfügung
android.car.storagemonitoring.CarStorageMonitoringManager
Android Open Das Quellprojekt erfüllt die Anforderung über das 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:
<ph type="x-smartling-placeholder">
- </ph>
- Der Akku ist leer.
- Es sind keine inaktiven Jobs geplant.
- Der Fahrer beendet den Garagenmodus.
- [8.4/A-0-1] MUSS einen Leistungsprofil pro Komponente, das den aktuellen Verbrauchswert definiert für jede Hardwarekomponente und die ungefähre Entladung des Akkus aufgrund der wie auf der Website des Android Open Source Project dokumentiert.
- [8.4/A-0-2] MÜSSEN die gesamte Stromversorgung melden. Verbrauchswerte in Milliamperestunden (mAh) angegeben.
- [8.4/A-0-3] MÜSSEN die CPU-Leistung melden
pro Prozess UID. Das Open-Source-Projekt von Android erfüllt
Anforderung durch die Implementierung des Kernelmoduls
uid_cputime
. - [8.4/A] SOLLTE dem Hardwarekomponente selbst, wenn der Stromverbrauch der Hardwarekomponente nicht zugeordnet werden kann zu einer Anwendung hinzufügen.
- [8.4/A-0-4] MUSS diesen Stromverbrauch nutzen
verfügbar über
adb shell dumpsys batterystats
Shell-Befehl an den App-Entwickler senden.
2.5.5 Sicherheitsmodell
Wenn Automotive-Geräteimplementierungen mehrere Nutzer unterstützen, gilt Folgendes:
- [9.5/A-1-1] DÜRFEN Nutzern NICHT gestatten, mit noch nicht zum Headless System User wechseln, mit Ausnahme der Gerätebereitstellung.
- [9.5/A-1-2] MUSS zu einem Sekundärnutzer wechseln
vor dem
BOOT_COMPLETED
. - [9.5/A-1-3] MUSS die Fähigkeit unterstützen, ein Gastnutzer selbst wenn die maximale Anzahl von Nutzern auf einem Gerät erreicht ist.
Wenn in den Implementierungen von Automobil-Geräten android.hardware.microphone
deklariert ist,
Sie:
- [9.8.2/A-1-1] MUSS die Mikrofonanzeige einblenden, wenn
eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn das Mikrofon
Auf das Mikrofon zugreifen nur
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
oder Apps mit den in folgendem Dokument genannten Rollen: Abschnitt 9.1 mit der CDD-Kennung [C-4-X]. - [9.8.2/A-1-2] DARF die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
- [9.8.2/A-1-3] MUSS zum Aktivieren/Deaktivieren der in der App „Einstellungen“.
Wenn in Implementierungen von Automobil-Geräten android.hardware.camera.any
deklariert ist, gilt Folgendes:
Sie:
- [9.8.2/A-2-1] MUSS die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn die Kamera Zugriff von Apps mit den in den Abschnitt 9.1 Berechtigungen mit der CDD-Kennung [C-4-X].
- [9.8.2/A-2-2] DARF die Kameraanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkten Nutzerinteraktionen
- [9.8.2/A-2-3] MÜSSEN Nutzern die Möglichkeit bieten, die Kamera in den Einstellungen ein- und auszuschalten.
- [9.8.2/A-2-4] MÜSSEN bei Rückgabe kürzlich verwendete und aktive Apps, die die Kamera verwenden, angezeigt werden.
von
PermissionManager.getIndicatorAppOpUsageData()
, zusammen mit Attributionsbotschaften, die mit ihnen verknüpft sind.
Implementierungen von Automobilgeräten:
- [9/A-0-1] MUSS die
android.hardware.security.model.compatible
deklarieren . - [9.11/A-0-1] MUSS die Schlüsselspeicherimplementierung sichern mit einer isolierten Ausführungsumgebung.
- [9.11/A-0-2] MUSS Implementierungen von RSA, AES, Die kryptografischen Algorithmen ECDSA und HMAC sowie die MD5-, SHA-1- und SHA-2-Familie Hash-Funktionen genutzt werden, um die vom Android-Schlüsselspeichersystem unterstützten in einem Bereich, der sicher vom Code isoliert ist, Kernel und höher. Sichere Isolation MUSS alle potenziellen Mechanismen blockieren über den Kernel- oder Userspace-Code auf den internen Status des einer isolierten Umgebung, einschließlich DMA. Die vorgelagerte Open-Source-Version von Android Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung, aber eine andere ARM TrustZone-basierte Lösung oder von einem Drittanbieter geprüfte sichere Lösung Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation sind eine Alternative Optionen.
- [9.11/A-0-3] MUSS den Sperrbildschirm starten in der isolierten Ausführungsumgebung und nur dann, erfolgreich war, können die mit der Authentifizierung gebundenen Schlüssel verwendet werden. Sperrbildschirm Anmeldedaten MÜSSEN so gespeichert werden, dass nur die isolierte Ausführung für die Sperrbildschirm-Authentifizierung. Die vorgelagerte Android- Open-Source-Projekt bietet Gatekeeper-Hardwareabstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
[9.11/A-0-4] MUSS die Schlüsselattestierung unterstützen, wenn die Der Attestierungssignaturschlüssel wird durch sichere Hardware geschützt und die Signatur ist auf sicherer Hardware ausgeführt werden. Die Signaturschlüssel der Attestierung MÜSSEN
gemeinsam verwendet werden Geräte groß genug ist, um die Schlüssel zu verhindern.verhindert nicht als dauerhaft Gerätekennungen.Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel, es sei denn, mindestens 100.000 Einheiten einer SKU produziert wurden. Werden mehr als 100.000 Einheiten einer Artikelnummer hergestellt, wird eine andere für je 100.000 Einheiten.
Neue Anforderungen beenden
Wenn eine Geräteimplementierung bereits auf einer früheren Android-Version
-Version ist ein solches Gerät von der Anforderung ausgenommen, einen Schlüsselspeicher zu haben.
eine isolierte Ausführungsumgebung nutzen
und die Schlüsselattestierung unterstützen,
es sei denn, die Funktion android.hardware.fingerprint
wird deklariert, für die ein
Schlüsselspeicher, der von einer isolierten Ausführungsumgebung unterstützt wird.
Implementierungen von Automobilgeräten:
- [9.14/A-0-1] MÜSSEN Gatekeep-Nachrichten verarbeiten. von Fahrzeug-Subsystemen von Android-Frameworks, z.B. Mitteilung, die auf die Zulassungsliste gesetzt wurde Nachrichtenquellen und Nachrichtenquellen.
- [9.14/A-0-2] MÜSSEN überwacht werden, ob Denial-of-Service-Angriffe des Android-Frameworks oder von Drittanbieter-Apps Dieses Schutz vor schädlicher Software, die das Fahrzeugnetzwerk mit Traffic überflutet. was zu defekten Fahrzeug-Subsystemen führen kann.
2.5.6 Kompatibilität von Entwicklertools und -optionen
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Implementierungen von Automobilgeräten:
- Perfetto
<ph type="x-smartling-placeholder">
- </ph>
- [6.1/A-0-1] MUSS eine
/system/bin/perfetto
-Angabe verfügbar machen Binärdatei, die der cmdline entspricht Perfetto-Dokumentation. - [6.1/A-0-2] Das Perfetto-Binärprogramm MUSS akzeptiert werden als Geben Sie eine protobuf-Konfiguration ein, die dem in Perfetto-Dokumentation.
- [6.1/A-0-3] Das Perfetto-Binärprogramm MUSS schreiben als einen protobuf-Trace ausgeben, der dem in Perfetto-Dokumentation.
- [6.1/A-0-4] MÜSSEN über das Zusatzsymbol angeben. binär, zumindest die unter Perfetto-Dokumentation.
- [6.1/A-0-5] Der perfetto verfolgte Daemon
MÜSSEN standardmäßig aktiviert sein (Systemeigenschaft
persist.traced.enable
).
- [6.1/A-0-1] MUSS eine
Neue Anforderungen beenden
2.6. Tablet-Anforderungen
Android-Tablet bezieht sich auf eine Android-Geräteimplementierung, die erfüllt in der Regel alle folgenden Kriterien:
- Wird durch Halten in beiden Händen verwendet.
- Hat keine Clamshell- oder Convertible-Konfiguration.
- Implementierungen für physische Tastaturen, die mit dem Gerät verwendet werden, verbinden sich über über eine Standardverbindung (z.B. USB oder Bluetooth).
Das Gerät hat eine Stromquelle, die Mobilität ermöglicht, z. B. einen Akku.
Das Display des Displays ist größer als 7 Zoll und kleiner als 18 Zoll, gemessen an diagonaler Messung.
Bei der Implementierung von Tablets gelten ähnliche Anforderungen wie auf Mobilgeräten. Implementierungen. Die Ausnahmen sind in diesem Abschnitt mit einem * gekennzeichnet und werden in diesem Abschnitt als Referenz vermerkt.
2.6.1 Hardware
Gyroskop
Wenn Tablet-Geräte ein 3-Achsen-Gyroskop enthalten, ist Folgendes erforderlich:
- [7.3.4/Tab-1-1] MUSS die Ausrichtung messen können um bis zu 1000 Grad pro Sekunde.
Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)
Die angegebenen Bildschirmdichten für kleine/normale Bildschirme im Handheld- gelten nicht für Tablets.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
USB-Peripheriemodus (Abschnitt 7.7.1)
Wenn Tablet-Implementierungen einen USB-Port enthalten, der Peripheriegeräte unterstützt haben sie folgende Möglichkeiten:
- [7.7.1/Tab] KANN die Android Open Accessory (AOA) API implementieren.
Neue Anforderungen beenden
Virtual-Reality-Modus (Abschnitt 7.9.1)
Virtual Reality: High Performance (Abschnitt 7.9.2)
Die Anforderungen für Virtual Reality gelten nicht für Tablets.
2.6.2 Sicherheitsmodell
Schlüssel und Anmeldedaten (Abschnitt 9.11)
Siehe Abschnitt [9.11].
Wenn Tablet-Geräteimplementierungen von mehreren Nutzern und
Das Funktions-Flag android.hardware.telephony
wird nicht deklariert, sie werden:
- [9.5/T-1-1] MUSS eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteeigentümer zusätzliche Nutzer und ihre Funktionen auf dem Gerät. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen einrichten, in denen zusätzliche Nutzende arbeiten können, mit der Möglichkeit, differenziertere Einschränkungen in den Apps zu verwalten, die in diesen Umgebungen verfügbar sind.
Wenn Tablet-Geräteimplementierungen von mehreren Nutzern und
das Funktions-Flag android.hardware.telephony
deklarieren, wenn folgende Aktionen ausgeführt werden:
- [9.5/T-2-1] DÜRFEN KEINE Unterstützung eingeschränkter Einschränkungen unterstützen Profile, MÜSSEN aber mit der AOSP-Implementierung der Kontrollen übereinstimmen. , um zu aktivieren /deaktivieren, dass andere Nutzer auf die Sprachanrufe und SMS zugreifen können.
2.6.2 Software
- [3.2.3.1/Tab-0-1] MUSS einen vorab laden. oder mehr Anwendungen oder Dienstkomponenten mit Intent-Handlern für alle von den folgenden Anwendungs-Intents definierte öffentliche Intent-Filtermuster finden Sie hier.
3. Software
3.1. Kompatibilität mit verwalteten APIs
Die verwaltete Dalvik-Bytecode-Ausführungsumgebung Android-Apps Die Android-API (Application Programming Interface) ist die Android-Plattformschnittstellen, die für Anwendungen in der verwaltete Laufzeitumgebung.
Geräteimplementierungen:
[C-0-1] MÜSSEN vollständige Implementierungen einschließlich aller dokumentierten jeder dokumentierten API, die durch den Android SDK oder eine beliebige API, die mit „@SystemApi“ Markierung in den vorgelagerten Android- Quellcode verfügbar.
[C-0-2] MÜSSEN alle Klassen, Methoden und zugehörigen Elemente unterstützen/bewahren. durch die TestApi-Annotation (@TestApi) gekennzeichnet.
[C-0-3] DÜRFEN KEINE verwalteten APIs auslassen, API-Schnittstellen oder Signaturen ändern, vom dokumentierten Verhalten abweichen oder No-Ops-Werte enthalten, es sei denn, gemäß dieser Kompatibilitätsdefinition gestattet.
[C-0-4] MÜSSEN die APIs weiterhin vorhanden sein und funktionieren. selbst wenn einige Hardwarefunktionen, für die Android beinhaltet keine APIs. Siehe Abschnitt 7 .
[C-0-5] DÜRFEN NICHT zulassen, dass Drittanbieter-Apps Nicht-SDK-Schnittstellen verwenden, die werden als Methoden und Felder in den Java-Sprachpaketen im Boot-Klassenpfad in AOSP, und sind nicht Teil der öffentlichen SDK. Dies gilt auch für APIs, die mit der Annotation
@hide
, aber nicht mit ein@SystemAPI
, wie in den SDK-Dokumenten beschrieben und private und Paket-private Klassenmitglieder.[C-0-6] MÜSSEN mit allen Nicht-SDK-Schnittstellen auf derselben eingeschränkten wie über die Flags „Vorläufig“ und „Sperrliste“ in
prebuilts/runtime/appcompat/hiddenapi-flags.csv
Pfad für den entsprechenden API-Level-Zweig im AOSP.[C-0-7] MUSS die signierte Konfiguration unterstützen Mechanismus für dynamische Updates, um Nicht-SDK-Schnittstellen aus einer eingeschränkten Liste zu entfernen Durch Einbetten der signierten Konfiguration in ein beliebiges APK unter Verwendung der vorhandenen öffentlichen Schlüssel die in AOSP vorhanden sind.
Allerdings gilt:
- MÖGLICH, wenn eine verborgene API fehlt oder auf dem Gerät anders implementiert wurde Implementierung, verschieben Sie die verborgene API in die Sperrliste oder lassen Sie sie aus alle eingeschränkten Listen.
- MAG. Wenn eine ausgeblendete API noch nicht in der AOSP vorhanden ist, fügen Sie die ausgeblendete API API zu einer der eingeschränkten Listen hinzufügen.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-0-8] DARF NICHT die Installation von Anwendungen unterstützen, die auf ein API-Level ausgerichtet sind.
weniger als
2324.
Neue Anforderungen beenden
3.1.1. Android-Erweiterungen
Android unterstützt die Erweiterung der verwalteten API-Oberfläche einer bestimmten API-Ebene um
die Erweiterungsversion für diese API-Ebene aktualisieren. Die
Die android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API gibt den Fehlerwert
Erweiterungsversion der angegebenen apiLevel
, falls es Erweiterungen dafür gibt
API-Level.
Implementierungen auf Android-Geräten:
[C-0-1] MÜSSEN die AOSP-Implementierung sowohl der gemeinsam genutzten Bibliothek
ExtShared
und 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: <ph type="x-smartling-placeholder">- </ph>
- Ausrichtung auf API-Level 28 oder niedriger.
- Deklariert in seinem Manifest, dass die Bibliothek benötigt wird, indem das Attribut
Attribut
android:name
von<uses-library>
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 beinhaltet auch eine erhebliche API in Form von wie Intents, Berechtigungen und ähnliche Aspekte von Android-Apps, kann bei der Kompilierung der Anwendung nicht erzwungen werden.
3.2.1. Berechtigungen
- [C-0-1] Geräteimplementierungen MÜSSEN alle Berechtigungen unterstützen und erzwingen wie auf der Referenzseite für Berechtigungen dokumentiert. In Abschnitt 9 finden Sie weitere Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell.
3.2.2. Build-Parameter
Die Android-APIs enthalten eine Reihe von Konstanten auf der android.os.Build-Klasse die das aktuelle Gerät beschreiben sollen.
- [C-0-1] Um einheitliche, aussagekräftige Werte auf allen Geräten bereitzustellen Implementierungen implementiert haben, enthält die folgende Tabelle zusätzliche Einschränkungen für die Formate mit denen die Geräteimplementierungen übereinstimmen MÜSSEN.
Parameter | Details |
---|---|
VERSION.VERÖFFENTLICHUNG | Die Version des derzeit ausgeführten Android-Systems in visuell lesbarer Form Format. Dieses Feld MUSS einen der Zeichenfolgewerte enthalten, die in Zulässige Versionsstrings für Android 15 |
SDK VERSION | Die Version des derzeit ausgeführten Android-Systems in einem Format Anwendungscode von Drittanbietern zugänglich sein. Bei Android 15 Dieses Feld MUSS den Ganzzahlwert 15_INT haben. |
VERSION.SDK_INT | Die Version des derzeit ausgeführten Android-Systems in einem Format Anwendungscode von Drittanbietern zugänglich sein. Bei Android 15 dieses Feld MUSS den Ganzzahlwert 15_INT haben. |
VERSION.INCREMENTAL | Wert, der vom Geräte-Implementierer ausgewählt wird, der den spezifischen Build bezeichnet
des derzeit ausgeführten Android-Systems in menschenlesbarem Format. Dieses
DÜRFEN NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. A
Dieses Feld wird üblicherweise verwendet, um anzugeben, welche Build-Nummer oder
Die Änderungs-ID der Versionsverwaltung wurde zum Generieren des Builds verwendet. Der Wert
dieses Feld MUSS als druckbarer 7-Bit-ASCII codiert werden und mit den
regulärer Ausdruck ^[^ :\/~]+$ |
BRETTSPIEL | Ein Wert, der vom Geräte-Implementierer ausgewählt wird, der das spezifische
interne Hardware, die vom Gerät verwendet wird, in menschenlesbarem Format. Ein möglicher
Dieses Feld dient dazu, die spezifische Überarbeitung der Leiterplatte anzugeben
auf dem Gerät. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden und
Sie entsprechen dem regulären Ausdruck ^[a-zA-Z0-9_-]+$ . |
MARKE | Ein Wert für den Markennamen, der dem Gerät zugeordnet ist (bekannt für
die Endanwendenden. MÜSSEN in für Menschen lesbarem Format vorliegen und SOLLTEN die
Hersteller des Geräts oder die Unternehmensmarke, unter der das Gerät verkauft wird
vermarktet werden. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden und übereinstimmen
den regulären Ausdruck ^[a-zA-Z0-9_-]+$ . |
UNTERSTÜTZTE_ABIS | Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) der nativen Anzeige Code. Siehe Abschnitt 3.3. Native API Kompatibilität. |
UNTERSTÜTZT_32_BIT_ABIS | Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) der nativen Anzeige Code. Siehe Abschnitt 3.3. Native API Kompatibilität. |
UNTERSTÜTZT_64_BIT_ABIS | Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) von nativen Code. Siehe Abschnitt 3.3. Nativ API-Kompatibilität. |
CPU_ABI | Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) der nativen Anzeige Code. Siehe Abschnitt 3.3. Native API Kompatibilität. |
CPU_ABI2 | Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) von nativen Code. Siehe Abschnitt 3.3. Nativ API-Kompatibilität. |
GERÄT | Wert, der vom Geräte-Implementierer ausgewählt wird und den Entwicklungsnamen enthält
oder Codenamen, der die Konfiguration der Hardwarefunktionen und
Industriedesign des Geräts. Der Wert dieses Felds MUSS codierbar sein
als 7-Bit-ASCII-Zeichen und müssen dem regulären Ausdruck entsprechen.
^[a-zA-Z0-9_-]+$ Dieser Gerätename DARF NICHT während der
Lebensdauer des Produkts. |
Fingerabdruck | Ein String, der diesen Build eindeutig identifiziert. SOLLTE plausibel sein
visuell lesbar ist. Sie MUSS dieser Vorlage folgen:
$(BRAND)/$(PRODUKT)/ 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 bezüglich des spezifischen Formats in dieses Feld, außer dass es NICHT null sein oder die leere Zeichenfolge (""). |
ID | Eine Kennung, die vom Geräte-Implementierer ausgewählt wird, um sich auf eine bestimmte
in menschenlesbarem Format. Dieses Feld kann mit
android.os.Build.VERSION.INCREMENTAL, SOLLTE aber ein ausreichender Wert sein.
sodass Endnutzer zwischen Software-Builds unterscheiden können. Der Wert
dieses Felds MUSS als 7-Bit-ASCII codiert werden können und mit dem regulären
Ausdruck ^[a-zA-Z0-9._-]+$ . |
HERSTELLER | Der Handelsname des Erstausrüsters (Original Equipment Manufacturer, OEM) des Produkt. Es gibt keine Anforderungen an das Format dieses Felds. außer dass er NICHT null oder die leere Zeichenfolge ("") sein darf. Dieses Feld DÜRFEN NICHT während der Lebensdauer des Produkts geändert werden. |
SOC_Hersteller | Der Handelsname des Herstellers des primären Systems auf
Chip (SOC) des Produkts. Geräte desselben SOC-Herstellers
konstanten Wert verwenden. Fragen Sie beim SOC-Hersteller nach
die richtige Konstante zu verwenden. Der Wert dieses Felds MUSS codierbar sein
als 7-Bit-ASCII, MUSS mit dem regulären Ausdruck übereinstimmen
^([0-9A-Za-z ]+) darf NICHT mit einem Leerzeichen beginnen oder enden,
und DÜRFEN NICHT gleich "unbekannt" sein. Dieses Feld DARF NICHT während der
Lebensdauer des Produkts. |
SOC-Modell | Der Modellname des primären Systems-on-Chips (SOC), das in
für das Produkt. Geräte mit demselben SOC-Modell sollten dieselbe Konstante verwenden.
Wert. Fragen Sie den SOC-Hersteller nach der richtigen Konstante.
Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden können und mit dem
regulärer Ausdruck ^([0-9A-Za-z ._/+-]+)$ , DARF NICHT beginnen oder
mit einem Leerzeichen enden und DARF NICHT gleich "unknown" sein. Dieses Feld
DÜRFEN NICHT während der Lebensdauer des Produkts geändert werden. |
MODELL | Ein vom Geräte-Implementierer ausgewählter Wert, der den Namen des wie dem Endanwendenden bekannt ist. Dies SOLLTE der gleiche Name sein, unter dem das Gerät an Endnutzer vermarktet und verkauft wird. Es gibt keine Anforderungen das spezifische Format dieses Feldes, außer dass es NICHT NULL oder der Leerer String (""). Dieses Feld DARF NICHT während der Lebensdauer des Produkts. |
PRODUKT/FUNKTION | Wert, der vom Geräte-Implementierer ausgewählt wird und den Entwicklungsnamen enthält
oder Codename des jeweiligen Produkts (SKU), der innerhalb der
für dieselbe Marke. MÜSSEN lesbar sein, sind aber nicht unbedingt zur Ansicht gedacht.
von den Endnutzern. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden und
Sie entsprechen dem regulären Ausdruck ^[a-zA-Z0-9_-]+$ . Dieses Produkt
Der Name DÜRFEN sich während der Lebensdauer des Produkts NICHT ändern. |
ODM_SKU | Ein optionaler Wert, der vom Geräte-Implementierer ausgewählt wird und Folgendes enthält:
SKU (Stock Keeping Unit), mit der bestimmte Konfigurationen der
Gerät enthalten, z. B. alle Peripheriegeräte, die beim Verkauf im Lieferumfang des Geräts enthalten waren.
Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden können und mit dem
regulärer Ausdruck ^([0-9A-Za-z.,_-]+)$ |
Seriennummer | MÜSSEN "UNKNOWN" zurückgeben. |
TAGS | Eine durch Kommas getrennte Liste von Tags, die von der Geräteimplementierung ausgewählt wurden und
den Build noch besser unterscheidet. Die Tags MÜSSEN als 7-Bit-ASCII kodierbar sein
und mit dem regulären Ausdruck ^[a-zA-Z0-9._-]+ übereinstimmen und MUSS
haben einen der Werte, die den drei typischen Android-Plattformen
Signaturkonfigurationen: Release-, Entwicklungs- und Testschlüssel. |
UHRZEIT | Ein Wert, der den Zeitstempel für den Build darstellt. |
SCHREIBMASCHINE | Wert, der vom Geräte-Implementierer ausgewählt wird, der die Laufzeit angibt Konfiguration des Builds. Dieses Feld MUSS einen der Werte enthalten. entspricht den drei typischen Android-Laufzeitkonfigurationen: Nutzer, userdebug. |
NUTZER | Name oder User-ID des Nutzers (oder des automatisierten Nutzers), der die Generierung der erstellen. Es gibt keine Anforderungen an das Format dieses Felds. außer dass er NICHT null oder die leere Zeichenfolge ("") sein darf. |
SICHERHEIT_PATCH | Ein Wert, der die Sicherheitspatch-Ebene eines Builds angibt. Es MUSS bedeuten, Der Build ist in keiner Weise anfällig für die beschriebenen Probleme. im öffentlichen Sicherheitsbulletin für Android verfügbar. Sie MUSS in diesem Land sein: das Format [JJJJ-MM-TT] haben und einer definierten Zeichenfolge entsprechen, die im Öffentliche Sicherheit bei Android Bulletin oder im Android-Sicherheitshinweise, z. B. „2015-11-01“. |
BASIS-Betriebssystem | Wert, der den Parameter FINGERprint des Builds darstellt und der die ansonsten mit diesem Build identisch sind, mit Ausnahme der Patches in den Öffentliches Sicherheitsbulletin für Android Er MÜSSEN den richtigen Wert melden und so ein Build nicht existiert, melden Sie einen leeren String (""). |
BOOTLOADER | Ein Wert, der vom Geräte-Implementierer ausgewählt wird, der das spezifische
Auf dem Gerät verwendete interne Bootloader-Version in einem visuell lesbaren Format.
Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden können und mit dem
regulärer Ausdruck ^[a-zA-Z0-9._-]+$ |
getRadioVersion() | MÜSSEN (oder zurückgeben) ein Wert, der von der Geräteimplementierung ausgewählt wurde
die spezifische interne Radio-/Modemversion identifiziert, die auf dem Gerät verwendet wird,
in menschenlesbarem Format. Wenn ein Gerät keine internen
Radio/Modem MUSS NULL zurückgegeben werden. In diesem Feld MUSS der Wert
als 7-Bit-ASCII codiert und entspricht dem regulären Ausdruck
^[a-zA-Z0-9._-,]+$ |
getSerial() |
MUSS eine Hardware-Seriennummer (MÜSSEN verfügbar sein oder zurückgegeben werden)
und auf allen Geräten mit demselben MODELL und MANUFACTURER einzigartig sein. Der Wert von
Dieses Feld MUSS als 7-Bit-ASCII codiert werden und dem regulären Ausdruck entsprechen.
^[a-zA-Z0-9]+$ |
3.2.3 Intent-Kompatibilität
3.2.3.1 Allgemeine Anwendungs-Intents
Android-Intents ermöglichen es Anwendungskomponenten, Funktionen von anderen Android-Komponenten. Das Android-Upstream-Projekt enthält eine Liste Anwendungen, die mehrere Intent-Muster zum Ausführen gängiger Aktionen implementieren.
Geräteimplementierungen:
- [C-SR-1] wird dringend empfohlen, eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filter von den folgenden Anwendungs-Intents definierte Muster, die hier aufgeführt sind zu erfüllen, d.h. die Erwartungen der Entwickler in Bezug auf diese gängigen Anwendungs-Intents, wie im SDK beschrieben.
Informationen zu obligatorischen Anwendungs-Intents finden Sie in Abschnitt 2. für jeden Gerätetyp ein.
3.2.3.2 Intent-Auflösung
[C-0-1] Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen MÜSSEN alle in Abschnitt 3.2.3.1 referenzierten Intent-Muster zulassen, außer den Einstellungen, die von Drittanbieteranwendungen überschrieben werden. Die Dies wird standardmäßig durch die Open-Source-Implementierung von Android ermöglicht.
[C-0-2] Geräteimplementierungen DÜRFEN KEINE Sonderberechtigungen an das System anhängen Anwendungen oder verhindern, dass Drittanbieter-Apps von der Bindung an diese Muster und der Übernahme der Kontrolle über diese Muster. Dieses Verbot insbesondere das Deaktivieren der Funktion Nutzer Oberfläche, in der Nutzer zwischen mehreren Anwendungen wählen können, die alle mit demselben Intent-Muster verarbeitet werden.
[C-0-3] Geräteimplementierungen MÜSSEN eine Benutzeroberfläche bereitstellen, über die Nutzer Standardaktivität für Intents ändern.
Geräteimplementierungen KÖNNEN jedoch Standardaktivitäten für bestimmte URI-Muster (z.B. http://play.google.com), wenn die Standardaktivität ein spezifischeres Attribut für den Daten-URI. Beispiel: Ein Intent-Filtermuster unter Angabe des Daten-URI „http://www.android.com“ spezifischer als die das zentrale Intent-Muster des Browsers für „http://“.
Android umfasst auch einen Mechanismus, mit dem Drittanbieter-Apps eine autoritatives standardmäßiges Verhalten beim Verknüpfen von Apps für bestimmte Arten von Web-URI-Intents. Wenn solche verlässlichen Erklärungen in den Intent-Filtermustern einer App, Geräteimplementierungen:
- [C-0-4] MÜSSEN versuchen, Intent-Filter zu validieren, indem in der Digital Asset Links-Spezifikation definierte Überprüfungsschritte wie vom Paketmanager in der vorgelagerten Open-Source-Version von Android implementiert. Projekt
- [C-0-5] MÜSSEN versucht werden, die Validierung der Intent-Filter während der Installation von der Anwendung und legen Sie alle erfolgreich validierten URI-Intent-Filter als fest. Standard-App-Handler für ihre URIs zu verwenden.
- spezifische URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen, Wenn sie erfolgreich überprüft werden, aber andere mögliche URI-Filter fehlschlagen Überprüfung. Ist dies bei einer Geräteimplementierung der Fall, MÜSSEN sie den Parameter Überschreibungen von nutzerspezifischen Überschreibungen von Pro-URI-Mustern im Einstellungsmenü.
- Nutzer MUSS dem Nutzer in den Einstellungen Einstellungen für App-Links wie folgt zur Verfügung stellen:
folgt:
<ph type="x-smartling-placeholder">
- </ph>
- [C-0-6] Der Nutzer MUSS in der Lage sein, die Standard-App ganzheitlich zu überschreiben. für eine App: immer offen, immer fragen oder nie öffnen, die für alle möglichen URI-Intent-Filter gleichermaßen gelten muss.
- [C-0-7] Der Nutzer MUSS die Liste des möglichen URI-Intents sehen können. Filter.
- Die Geräteimplementierung MÖGLICHERWEISE dem Nutzer die Möglichkeit geben, Bestimmte mögliche URI-Intent-Filter überschreiben, die erfolgreich waren können auf Basis von Intent-Filtern überprüft werden.
- [C-0-8] Die Geräteimplementierung MUSS Nutzern die Möglichkeit geben, Bestimmte mögliche URI-Intent-Filter aufrufen und überschreiben, wenn das Gerät Bei der Implementierung sind einige mögliche URI-Intent-Filter erfolgreich. während andere nicht erfolgreich sein können.
3.2.3.3 Intent-Namespaces
- [C-0-1] Geräteimplementierungen DÜRFEN KEINE Android-Komponente enthalten, die alle neuen Intent- oder Broadcast-Intent-Muster mit einer ACTION-, CATEGORY- oder Anderer Schlüsselstring im Namespace „android.*“ oder „com.android.*“ sein.
- [C-0-2] Geräteimplementierungen DÜRFEN KEINE Android-Komponenten enthalten, die neue Intents oder Broadcast-Intent-Muster mit einer ACTION-, CATEGORY- oder anderer Schlüsselstring in einem Paketbereich, der zu einer anderen Organisation gehört.
- [C-0-3] Nutzer, die auf Geräten implementiert sind, DÜRFEN den Intent NICHT verändern oder erweitern die in Abschnitt 3.2.3.1 aufgeführt sind.
- Geräteimplementierungen KÖNNEN Intent-Muster mit Namespaces enthalten und offensichtlich mit dem Unternehmen in Verbindung gebracht werden. Dieses Verbot ist analog zu den Java-Sprachklassen in Abschnitt 3.6.
3.2.3.4 Übertragungs-Intents
Drittanbieter-Apps nutzen die Plattform, um bestimmte Intents über Änderungen in der Hardware- oder Softwareumgebung zu informieren.
Geräteimplementierungen:
- [C-0-1] MÜSSEN die hier aufgeführten öffentlichen Übertragungs-Intents übertragen. als Reaktion auf entsprechende Systemereignisse, wie in der SDK-Dokumentation beschrieben. Diese Anforderung steht nicht im Widerspruch zu Abschnitt 3.5, da Einschränkungen für Hintergrundanwendungen werden auch im SDK beschrieben. Dokumentation. Bestimmte Broadcast-Intents sind an die Hardware gebunden. -Support. Wenn das Gerät die erforderliche Hardware unterstützt, MUSS er die Intents und stellen die Funktionsweise in der SDK-Dokumentation bereit.
3.2.3.5 Bedingte Anwendungs-Intents
Android bietet Einstellungen, die Nutzern eine einfache Möglichkeit bieten, Standard-Apps, z. B. für den Startbildschirm oder für SMS.
Wo es sinnvoll ist, MÜSSEN bei der Geräteimplementierung ähnliche Einstellungen bereitgestellt werden. und mit dem beschriebenen Intent-Filtermuster und den beschriebenen API-Methoden kompatibel sein. in der SDK-Dokumentation wie unten beschrieben.
Wenn Geräteimplementierungen android.software.home_screen
melden, geschieht Folgendes:
- [C-1-1] MUSS die
android.settings.HOME_SETTINGS
berücksichtigen Standard-App-Einstellungsmenü für den Startbildschirm anzuzeigen.
Wenn Geräteimplementierungen android.hardware.telephony.calling
melden, geschieht Folgendes:
[C-2-1] MÜSSEN ein Einstellungsmenü bereitstellen,
android.provider.Telephony.ACTION_CHANGE_DEFAULT
ein Dialogfeld zum Ändern der Standard-SMS-App anzuzeigen.[C-2-2] MUSS die
android.telecom.action.CHANGE_DEFAULT_DIALER
berücksichtigen Intent, ein Dialogfeld anzuzeigen, über das der Nutzer die Standard-Telefonnummer ändern kann. .- MUSS die Benutzeroberfläche der vom Nutzer ausgewählten Standard-Telefon-App für eingehende mit Ausnahme von Notrufen, bei denen das Telefon App vorinstalliert.
[C-2-3] MÜSSEN die android.telecom.action.CHANGE_PHONE_ACCOUNTS berücksichtigen Nutzer sollen die Möglichkeit haben, die
ConnectionServices
zu konfigurieren. die 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 und android.intent.action.DIAL Intents mit einer vorinstallierten Telefonanwendung, die diese Intents verarbeiten kann, die im SDK beschriebene Auftragsausführung zu ermöglichen.
Wenn Geräteimplementierungen android.hardware.nfc.hce
melden, geschieht Folgendes:
- [C-3-1] MUSS die android.settings.NFC_PAYMENT_SETTINGS berücksichtigen. wird ein Standardmenü für App-Einstellungen für kontaktloses Bezahlen angezeigt.
- [C-3-2] MUSS android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT berücksichtigen eine Aktivität anzuzeigen, die ein Dialogfeld öffnet, in dem der Nutzer aufgefordert wird, Standardkartenemulationsdienst für eine bestimmte Kategorie, wie im SDK beschrieben.
Wenn Geräteimplementierungen android.hardware.nfc
melden, geschieht Folgendes:
- [C-4-1] MÜSSEN diese Intents android.nfc.action.NDEF_DISCOVERED berücksichtigen, android.nfc.action.TAG_DISCOVERED und android.nfc.action.TECH_DISCOVERED, eine Aktivität zu zeigen, die die Erwartungen der Entwickler an diese Intents erfüllt, wie im SDK beschrieben.
Wenn Geräteimplementierungen android.hardware.bluetooth
melden, geschieht Folgendes:
- [C-5-1] MUSS die Richtlinie 'android.bluetooth.adapter.action.REQUEST_ENABLE' berücksichtigen und eine Systemaktivität anzeigen, damit der Nutzer Bluetooth aktivieren kann.
- [C-5-2] MÜSSEN die „android.bluetooth.adapter.action.REQUEST_DISCOVERABLE“ und zeigen eine Systemaktivität an, die den Erkennbarkeitsmodus anfordert.
Wenn Geräteimplementierungen die Funktion „Nicht stören“ unterstützen, gilt Folgendes:
- [C-6-1] MÜSSEN eine Aktivität implementieren, die auf den Intent
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
, Bei Implementierungen mit UI_MODE_TYPE_NORMAL MUSS dies eine Aktivität sein, bei der Der Nutzer kann der App Zugriff auf die nicht störenden Richtlinienkonfigurationen gewähren oder verweigern.
Wenn die Geräteimplementierung den Nutzern die Verwendung von Drittanbieter-Eingabemethoden auf der Gerät:
- [C-7-1] MÜSSEN einen für den Nutzer zugänglichen Mechanismus zum Hinzufügen und Konfigurieren bereitstellen.
Eingabemethoden von Drittanbietern als Reaktion auf
android.settings.INPUT_METHOD_SETTINGS
die Nutzerabsicht verstehen.
Wenn Geräteimplementierungen Bedienungshilfen von Drittanbietern unterstützen, gilt Folgendes:
- [C-8-1] MUSS die
android.settings.ACCESSIBILITY_SETTINGS
berücksichtigen einen für den Nutzer zugänglichen Mechanismus zum Aktivieren und Deaktivieren Bedienungshilfen von Drittanbietern neben den vorinstallierten .
Wenn Geräteimplementierungen Wi-Fi Easy Connect unterstützen und den Drittanbieter-Apps funktionieren, müssen sie:
- [C-9-1] MUSS die Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI implementieren Intent-APIs wie in der SDK-Dokumentation beschrieben.
Wenn Geräteimplementierungen den Datensparmodus unterstützen, ist Folgendes möglich:
- [C-10-1] MÜSSEN in den Einstellungen eine Benutzeroberfläche bereitstellen,
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
damit Nutzer Anwendungen hinzufügen oder entfernen können. auf der Zulassungsliste steht.
Wenn Geräteimplementierungen den Datensparmodus nicht unterstützen, kann das folgende Gründe haben:
- [C-11-1] MÜSSEN über eine Aktivität verfügen,
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
aber KANN als No-Op implementiert werden.
Wenn Geräteimplementierungen die Unterstützung der Kamera per
android.hardware.camera.any
, sie/er:
- [C-12-3] MÜSSEN und nur vorinstallierte Android-Apps zulassen
zur Verarbeitung der folgenden Intents
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, 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 das System nicht verarbeiten oder es ablehnen kann.[C-13-2] MÜSSEN die Intents respektieren android.app.action.PROVISION_MANAGED_PROFILE android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD und android.app.action.START_ENCRYPTION und eine Aktivität haben, die die Auftragsausführung für diese Intents ermöglicht, wie beschrieben hier im SDK.
Wenn in Geräteimplementierungen die android.software.autofill
deklariert ist
Funktions-Flag:
- [C-14-1] MUSS die
AutofillService
vollständig implementieren 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.
Wenn Geräteimplementierungen das VoiceInteractionService
unterstützen und mehr
als bei einer Anwendung, die diese API verwendet, gleichzeitig Folgendes tun:
- [C-18-1] MUSS die
android.settings.ACTION_VOICE_INPUT_SETTINGS
respektieren Standard-App-Einstellungsmenü für Spracheingabe und Unterstützung anzeigen.
Wenn Geräteimplementierungen die Funktion android.hardware.audio.output
melden,
Sie:
- [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA und Für android.speech.tts.engine.GET_SAMPLE_TEXT-Intents muss eine Aktivität bereitgestellt werden Auftragsausführung für diese Intents, wie hier im SDK beschrieben.
Android bietet Unterstützung für interaktive Bildschirmschoner, die zuvor als als Träume. Mithilfe der Bildschirmschoner können Nutzer mit Apps interagieren, an eine Stromquelle angeschlossen ist, inaktiv oder in einem Dock angedockt ist. Geräteimplementierungen:
- SOLLTEN Bildschirmschoner unterstützen und eine Einstellungsoption für
die Konfiguration von Bildschirmschonern als Reaktion auf den
android.settings.DREAM_SETTINGS
Intent.
Wenn Geräteimplementierungen android.hardware.nfc.uicc
oder android.hardware.nfc.ese
melden,
Sie:
- [C-19-1] MUSS die Funktion NfcAdapter.ACTION_TRANSACTION_DETECTED implementieren. Intent API (als „EVT_TRANSACTION“ gemäß der technischen Spezifikation der GSM Association TS.26 – Anforderungen an NFC-Mobilgeräte)
3.2.4 Aktivitäten auf sekundären/mehreren Displays
Wenn die Geräteimplementierung das Starten normaler Android-Aktivitäten auf mehr als auf einem Display:
- [C-1-1] MUSS die
android.software.activities_on_secondary_displays
festlegen Funktions-Flag. - [C-1-2] MUSS die API-Kompatibilität ähnlich einer Aktivität garantieren, die auf das primäre Display.
- [C-1-3] Die neue Aktivität muss auf dem gleichen Display angezeigt werden wie die Aktivität,
Er wurde gestartet, wenn die neue Aktivität ohne Angabe eines Ziels gestartet wird.
Anzeige über das
ActivityOptions.setLaunchDisplayId()
der API erstellen. - [C-1-4] MUSS alle Aktivitäten vernichten, wenn eine Anzeige mit dem
Display.FLAG_PRIVATE
entfernt. - [C-1-5] MÜSSEN Inhalte auf allen Bildschirmen sicher verstecken, wenn das Gerät gesperrt ist
mit einem sicheren Sperrbildschirm, es sei denn, die App lässt die Anzeige über dem Schloss zu
Bildschirm mit
Activity#setShowWhenLocked()
der API erstellen. - SOLLTEN
android.content.res.Configuration
haben die dieser Anzeige entspricht, damit sie angezeigt werden kann, und die Kompatibilität aufrechterhalten, wenn eine Aktivität am sekundäre Displayanzeige.
Wenn die Geräteimplementierung das Starten normaler Android-Aktivitäten auf sekundären Websites ermöglicht und ein sekundäres Display mit android.view.Display.FLAG_PRIVATE Flag:
- [C-3-1] Nur der Eigentümer dieses Displays, Systems und Aktivitäten, die die bereits auf diesem Display angezeigt werden, MUSS in der Lage sein, sie aufzurufen. Jeder kann ein Display mit android.view.Display.FLAG_PUBLIC melden.
3.3 Native API-Kompatibilität
Die Kompatibilität mit nativem Code ist schwierig. Aus diesem Grund Implementierung von Geräten:
- [C-SR-1] EMPFOHLEN, Implementierungen der Bibliotheken zu verwenden aus dem vorgelagerten Android Open Source-Projekt stammen.
3.3.1 Binäre Anwendungsschnittstellen
Mit verwaltetem Dalvik-Bytecode kann nativen Code aufgerufen werden, der in der Anwendung bereitgestellt wird.
.apk
-Datei als ELF-.so
-Datei, die für die entsprechende Gerätehardware kompiliert wurde
Architektur. Da nativer Code stark vom zugrunde liegenden Prozessor abhängt
definiert, definiert Android eine Reihe von Binärschnittstellen (Application Binary Interfaces, ABIs) in
das Android NDK.
Geräteimplementierungen:
- [C-0-1] MÜSSEN mit einem oder mehreren definierten Android-NDK-ABIs kompatibel sein.
- [C-0-2] MÜSSEN Support für Code bereitstellen, der in der verwalteten Umgebung ausgeführt wird, um -Aufruf in nativen Code mithilfe des standardmäßigen Java Native Interface (JNI) Semantik.
- [C-0-3] MÜSSEN quellkompatibel (d.h. header-kompatibel) sein und binär kompatibel (für die ABI) mit jeder erforderlichen Bibliothek in der Liste unten.
- [C-0-5] MÜSSEN die native binäre Binärschnittstelle korrekt melden
(ABI), die vom Gerät unterstützt werden, über
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
undandroid.os.Build.SUPPORTED_64_BIT_ABIS
Parameter, jeweils durch Kommas getrennt Liste der ABIs, sortiert vom größten bis zum am wenigsten bevorzugten.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-0-6] MÜSSEN mithilfe der oben genannten Parameter eine Teilmenge der
und DÜRFEN KEINE ABIs melden, die nicht auf der Liste stehen.
armeabi
(wird vom NDK nicht mehr als Ziel unterstützt)armeabi-v7a
arm64-v8a
x86
x86-64
riscv64
Neue Anforderungen beenden
[C-0-7] MÜSSEN alle folgenden Bibliotheken, die native APIs bereitstellen, für Apps mit nativem Code verfügbar:
- libaaudio.so (Unterstützung für natives AAudio-Audio)
- libamidi.so (native MIDI-Unterstützung, wenn Funktion
android.software.midi
) wie in Abschnitt 5.9 beschrieben beansprucht) - libandroid.so (native Unterstützung für Android-Aktivitäten)
- libc (C-Bibliothek)
- libcamera2ndk.so
- libdl (dynamische Verknüpfung)
- libEGL.so (natives OpenGL-Oberflächenmanagement)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- Liblog (Android-Protokollierung)
- libmediandk.so (Unterstützung für native Media APIs)
- libm (Mathematikbibliothek)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (Unterstützung von OpenMAX AL 1.0.1)
- libOpenSLES.so (Audiounterstützung von OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (Minimale Unterstützung für C++)
- libvulkan.so (Vulkan)
- libz (Zlib-Komprimierung)
- JNI-Schnittstelle
[C-0-8] Dürfen die öffentlichen Funktionen für die nativen Bibliotheken NICHT hinzufügen oder entfernen oben aufgeführt.
[C-0-9] MÜSSEN zusätzliche Nicht-AOSP-Bibliotheken auflisten, die direkt Drittanbieter-Apps in
/vendor/etc/public.libraries.txt
.[C-0-10] DÜRFEN KEINE anderen nativen Bibliotheken, implementiert und in AOSP als Systembibliotheken für Drittanbieter-Apps für Targeting API ab Level 24, da diese reserviert sind.
[C-0-11] MÜSSEN alle OpenGL ES 3.1-Dateien und das gesamte Android-Erweiterungspaket exportieren. wie im NDK über die Bibliothek
libGLESv3.so
definiert. Alle Symbole MÜSSEN zwar vorhanden sein, in Abschnitt 7.1.4.1 wird jedoch beschrieben, die Anforderungen an die vollständige Implementierung der einzelnen Funktionen erwartet werden.[C-0-12] MÜSSEN Funktionssymbole für den Kern exportieren Vulkan 1.1-Funktion sowie den
VK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
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 die Anforderungen an den Zeitpunkt, an dem die vollständigen dass die Implementierung der jeweiligen Funktionen erwartet wird.SOLLTE mit dem Quellcode und den Header-Dateien erstellt werden, die im Open-Source-Projekt von Android.
Beachten Sie, dass in zukünftigen Android-Versionen möglicherweise weitere ABIs.
3.3.2 Kompatibilität mit nativem 32-Bit-ARM-Code
Wenn Geräteimplementierungen die Unterstützung des ABI für armeabi
melden, geschieht Folgendes:
- [C-3-1] MÜSSEN auch
armeabi-v7a
unterstützen und dies melden 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
15 Branch für die Implementierung der
android.webkit.WebView
der API erstellen. [C-1-3] Der von WebView gemeldete User-Agent-String MUSS folgendes Format haben:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, wie Gecko) Version/4.0 $(CHROMIUM_VER) Mobil Safari/537.36
- Der Wert des Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE.
- Der String $(MODEL) KANN leer sein, aber wenn er nicht leer ist, MUSS er denselben Wert wie android.os.Build.MODEL.
- „Build/$(BUILD)“ KANN weggelassen werden, aber wenn es vorhanden ist, ist $(BUILD) erforderlich. String MUSS mit dem Wert für android.os.Build.ID identisch sein.
- Der Wert des Strings $(CHROMIUM_VER) MUSS die Version von Chromium sein im vorgelagerten Android Open Source-Projekt.
- Bei Geräteimplementierungen KANN „Mobile“ im User-Agent-String weggelassen werden.
Die WebView-Komponente SOLLTE Unterstützung für so viele HTML5-Funktionen wie möglich und wenn die Funktion unterstützt wird, SOLLTEN Sie den HTML5-Spezifikation
[C-1-4] MÜSSEN die bereitgestellten Inhalte oder Remote-URL-Inhalte in einem Prozess gerendert werden. die sich von der Anwendung unterscheidet, die die WebView instanziiert. Insbesondere Der separate Renderer-Prozess MUSS geringere Berechtigungen haben, ausführen als separate Nutzer-ID haben, keinen Zugriff auf das Datenverzeichnis der Anwendung, keinen direkten Netzwerkzugriff haben und nur auf das Minimum Systemdienste über Binder. Die AOSP-Implementierung von WebView erfüllt diese Anforderung erfüllen.
Hinweis: Bei 32-Bit-Implementierungen von Geräten oder zum Deklarieren des Funktions-Flags
android.hardware.ram.low
sind sie von C-1-3 ausgenommen.
3.4.2 Browserkompatibilität
Wenn Geräteimplementierungen eine eigenständige Browseranwendung für allgemeine wenn sie im Web surfen,
- [C-1-1] MUSS alle der folgenden APIs unterstützen, die mit HTML5: <ph type="x-smartling-placeholder">
- [C-1-2] MUSS HTML5/W3C unterstützen Webstorage API verwenden und HTML5/W3C unterstützen IndexedDB API Beachten Sie, dass als Web- stellen Stellen mit Entwicklungsstandards zur Bevorzugung von IndexedDB gegenüber wird IndexedDB zu einer erforderlichen Komponente zukünftige Android-Version.
- KANN einen benutzerdefinierten User-Agent-String in der eigenständigen Browseranwendung versenden.
- SOLLTE Support möglichst viel von HTML5 wie möglich auf der eigenständigen Version Browser-Anwendung (ob auf dem vorgeschalteten WebKit-Browser basiert) oder eine Ersatzanwendung durch einen Drittanbieter).
Wenn Geräteimplementierungen jedoch keinen eigenständigen Browser umfassen, Anwendung finden, gilt Folgendes:
- [C-2-1] MÜSSEN weiterhin die Muster für öffentliche Absichten unterstützen, wie in Abschnitt 3.2.3.1.
3.5 API-Verhaltenskompatibilität
Geräteimplementierungen:
- [C-0-9] MÜSSEN sicherstellen, dass die API-Verhaltenskompatibilität auf alle angewendet wird, installierten Apps, es sei denn, sie sind wie unter Abschnitt 3.5.1:
- [C-0-10] DÜRFEN NICHT die Zulassungsliste implementieren, mit der sichergestellt wird, Verhaltenskompatibilität nur für Apps, die nach Gerät ausgewählt sind und Implementierungsteams.
Das Verhalten der einzelnen API-Typen (verwaltet, weich, nativ und Web) muss mit der bevorzugten Implementierung der vorgelagerten Open-Source-Projekt für Android Bestimmte Gebiete Kompatibilität sind:
- [C-0-1] Geräte DÜRFEN NICHT das Verhalten oder die Semantik eines Geräts ändern. Standard-Intent.
- [C-0-2] Geräte DÜRFEN den Lebenszyklus oder die Lebenszyklussemantik von eine bestimmte Art von Systemkomponente (wie Dienst, Aktivität, ContentProvider usw.).
- [C-0-3] Geräte DÜRFEN die Semantik einer Standardberechtigung NICHT ändern.
- Auf den Geräten DÜRFEN die Beschränkungen für Hintergrund-Apps NICHT geändert werden.
Genauer gesagt für Hintergrund-Apps:
<ph type="x-smartling-placeholder">
- </ph>
- [C-0-4] Sie MÜSSEN die Ausführung von Callbacks beenden, die vom
App, um Ausgaben vom
GnssMeasurement
zu empfangen undGnssNavigationMessage
. - [C-0-5] MÜSSEN die Häufigkeit von Updates, die
die der App über die
LocationManager
API-Klasse oder derWifiManager.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
oder sich im Ausnahmeliste. - [C-0-7] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MUSS die App beendet werden.
die Hintergrunddienste der App, als ob sie die
Dienste
stopSelf()
aus, es sei denn, die App wird auf eine temporäre Zulassungsliste gesetzt, die für die Nutzenden sichtbar ist. - [C-0-8] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN sie MÜSSEN lassen Sie die Wakelocks in der App los.
- [C-0-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 der
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. 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 Implementierer, MÜSSEN jedoch mit den Auswirkungen der App auf den Systemzustand in Verbindung stehen. Sonstiges Kriterien, die sich nicht nur auf den Systemzustand beziehen, z. B. geringe Beliebtheit auf dem Markt, DARF NICHT als Kriterien verwendet werden.
[C-1-4] DARF diese proprietären Einschränkungen nicht automatisch auf Apps anwenden. Ein Nutzer hat App-Einschränkungen manuell deaktiviert und KANN dem Nutzer vorschlagen, um diese proprietären Einschränkungen anzuwenden.
[C-1-5] MÜSSEN Nutzer informieren, wenn diese proprietären Einschränkungen für automatisch eine App. Solche Informationen MÜSSEN innerhalb von 24 Stunden zur Verfügung gestellt werden. vor der Anwendung dieser proprietären Einschränkungen.
[C-1-6] MUSS für ActivityManager.isBackgroundRestricted() "true" zurückgeben für API-Aufrufe aus einer App.
[C-1-7] DÜRFEN NICHT die im Vordergrund verwendete App einschränken, die explizit von Nutzenden.
[C-1-8] MÜSSEN diese proprietären Einschränkungen für eine App aussetzen, wenn ein Der Nutzer beginnt, die App explizit zu verwenden, wodurch sie im Vordergrund angezeigt wird. .
[C-1-10] MÜSSEN ein öffentliches und klares Dokument oder eine Website zur Verfügung gestellt werden, wie proprietäre Einschränkungen angewendet werden. Dieses Dokument oder diese Website MUSS aus den Android SDK-Dokumenten verknüpfbar und MÜSSEN Folgendes enthalten:
- Bedingungen für proprietäre Einschränkungen auslösen
- Welche Einschränkungen für Apps gelten und wie sie eingeschränkt werden können
- Wie eine App von solchen Einschränkungen ausgenommen werden kann
- Wie eine App eine Ausnahme von proprietären Einschränkungen beantragen kann, eine solche Ausnahme für Apps, die der Nutzer installieren kann.
Wenn eine App auf dem Gerät vorinstalliert ist und noch nie von einem mehr als 30 Tage lang genutzt werden, sind [C-1-3] [C-1-5] ausgenommen.
Wenn Geräteimplementierungen die implementierten App-Einschränkungen erweitern bei AOSP:
- [C-2-1]MÜSSEN der in diesem Dokument beschriebenen Implementierung folgen.
3.5.2 Ruhezustand von Anwendungen
Wenn Geräteimplementierungen den App-Ruhemodus beinhalten, der in AOSP enthalten ist, oder die in AOSP enthaltene Funktion erweitern, dann:
- [C-1-1] MUSS alle Anforderungen in Abschnitt 3.5.1 erfüllen, mit Ausnahme von [C-1-6] und [C-1-3].
- [C-1-2] MUSS die Einschränkung für die App nur auf einen Nutzer anwenden, wenn den Nachweis, dass der Nutzer die App über einen längeren Zeitraum nicht verwendet hat. Dieses Dauer wird UNBEDINGT zu einem Monat oder länger empfohlen. Nutzung MÜSSEN sein durch explizite Nutzerinteraktion über die UsageStats#getLastTimeVisible() über eine API oder ein anderes Element, das dazu führen würde, dass eine App einschließlich Dienstbindungen, Contentanbieterbindungen, expliziten Broadcasts usw., die von einer neuen API UsageStats#getLastTimeAnyComponentUsed() nachverfolgt werden.
- [C-1-3] MUSS nur Einschränkungen anwenden, die alle Gerätenutzer betreffen, ist der Beweis dafür, dass das Paket über einen bestimmten Zeitraum . Diese Dauer wird UNBEDINGT zu einem Monat oder länger empfohlen.
- [C-1-4] DÜRFEN die App nicht in der Lage machen, auf Aktivitäts-Intents zu reagieren, z. B. Dienstbindungen, Contentanbieteranfragen oder explizite Übertragungen.
Der App-Ruhezustand in AOSP erfüllt die oben genannten Anforderungen.
3.6. API-Namespaces
Android folgt den Konventionen für Paket- und Klassen-Namespaces, die von der Java- Programmiersprache. Um die Kompatibilität mit Anwendungen von Drittanbietern sicherzustellen, Geräte-Implementierungen DÜRFEN KEINE verbotenen Änderungen (siehe unten) an diese Paket-Namespaces:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
Das heißt:
- [C-0-1] DÜRFEN die auf der Android-Plattform öffentlich zugänglichen APIs NICHT verändern. durch Ändern beliebiger Methoden oder Klassensignaturen oder Entfernen von Klassen oder Klassen .
- [C-0-2] DÜRFEN KEINE öffentlich zugänglichen Elemente wie Klassen oder Schnittstellen oder Felder oder Methoden auf vorhandene Klassen oder Schnittstellen) oder Test oder System-APIs zu den APIs in den oben genannten Namespaces hinzu. Ein „öffentlich exponiertes Element“ ist ein Konstrukt, das nicht mit „@hide“ dekoriert ist Markierung als die im vorgelagerten Android-Quellcode verwendet werden.
Geräte-Implementierer KÖNNEN die zugrunde liegende Implementierung der APIs ändern, aber Änderungen vornehmen:
- [C-0-3] DÜRFEN NICHT das angegebene Verhalten und die Java-Sprachsignatur von öffentlich zugänglichen APIs.
- [C-0-4] DÜRFEN NICHT beworben und nicht auf andere Weise Entwicklern zugänglich gemacht werden.
Geräte-Implementierer KÖNNEN jedoch benutzerdefinierte APIs außerhalb des standardmäßigen Android- Namespace, aber die benutzerdefinierten APIs:
- [C-0-5] Dürfen sich NICHT in einem Namespace befinden, der einem anderen Namespace gehört oder auf diesen verweist
Unternehmen. Beispielsweise DÜRFEN Personen, die Geräte implementieren,
com.google.*
oder ähnlicher Namespace: Nur Google kann dies tun. In ähnlicher Weise Google DARF KEINE APIs zu den APIs anderer Unternehmen hinzufügen. Namespaces. - [C-0-6] MÜSSEN in einer gemeinsam genutzten Bibliothek von Android gepackt sein, damit nur Apps die sie explizit (über den Mechanismus <uses-library>) verwenden, sind die von der erhöhten Arbeitsspeichernutzung dieser APIs betroffen sind.
Geräte-Implementierer KÖNNEN benutzerdefinierte APIs in Muttersprachen außerhalb des NDK hinzufügen. APIs, aber die benutzerdefinierten APIs:
- [C-1-1] Darf sich NICHT in einer NDK-Bibliothek oder einer Bibliothek eines anderen Nutzers befinden des Unternehmens wie beschrieben hier.
Wenn ein Geräte-Implementierer vorschlägt, einen der oben genannten Paket-Namespaces zu verbessern z. B. durch Hinzufügen nützlicher neuer Funktionen zu einer vorhandenen API oder Hinzufügen einer neuen API) verwendet, SOLLTE der Implementierer source.android.com aufrufen. und beginnen damit, Änderungen beizutragen, gemäß den Informationen auf der Website.
Beachten Sie, dass die oben genannten Einschränkungen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java soll dies lediglich darauf abzielen, und binden sie durch Einbeziehung in diese Kompatibilitäts- Definition:
3.7 Laufzeitkompatibilität
Geräteimplementierungen:
[C-0-1] MUSS das vollständige Dalvik Executable (DEX)-Format unterstützen und Dalvik-Bytecode-Spezifikation und -Semantik.
[C-0-2] MÜSSEN Dalvik-Laufzeiten konfigurieren, um Arbeitsspeicher zuzuweisen in entsprechend der vorgelagerten Android-Plattform und in der folgenden Tabelle. (Siehe Abschnitt 7.1.1 für Definitionen für Bildschirmgröße und Bildschirmdichte.)
SOLLTEN Android RunTime (ART), die Upstream-Referenz, verwenden Implementierung des Dalvik Executable Formats und die Referenz im Paketverwaltungssystem der Implementierung.
SOLLTEN Sie Fuzz-Tests in verschiedenen Ausführungsmodi durchführen und Zielarchitekturen, um die Stabilität der Laufzeit zu gewährleisten. Weitere Informationen finden Sie unter JFuzz und DexFuzz auf der Website des Android Open Source Project.
Die unten angegebenen Speicherwerte gelten als Mindestwerte und Geräteimplementierungen KÖNNEN mehr Speicher pro Anwendung zuweisen.
Bildschirmlayout | Bildschirmdichte | Mindestanforderungen an den Anwendungsarbeitsspeicher |
---|---|---|
Android-Uhr | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
klein/normal | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
groß | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512MB | |
xlarge | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3.8 Kompatibilität der Benutzeroberfläche
3.8.1 Launcher (Startbildschirm)
Android umfasst eine Launcher-App (Startbildschirm) und Unterstützung für Drittanbieter-Apps als Ersatz für den Geräte-Launcher (Startbildschirm) aus.
Wenn die Geräteimplementierung das Gerät durch Drittanbieter-Apps ersetzen kann Startbildschirm eingeblendet wird, geschieht Folgendes:
- [C-1-1] MÜSSEN die Plattformfunktion
android.software.home_screen
deklarieren. - [C-1-2] MUSS den
AdaptiveIconDrawable
zurückgeben. Objekt, wenn die Drittanbieter-App das Tag<adaptive-icon>
verwendet, das eigene Symbol und 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 Angebote der Benutzeroberfläche zum Hinzufügen, Konfigurieren, Anzeigen und Entfernen von AppWidgets
- [C-1-3] MÜSSEN Widgets mit dem Format 4 x 4 rendern können. in der Standardrastergröße. Weitere Informationen finden Sie in den Designrichtlinien für App-Widgets. finden Sie in der Android SDK-Dokumentation.
- KANN App-Widgets auf dem Sperrbildschirm unterstützen.
Ob Geräteimplementierungen App-Widgets und In-App-Apps von Drittanbietern unterstützen das Anpinnen von Tastenkombinationen:
- [C-2-1] MÜSSEN
true
melden fü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. Wenn eine Geräteimplementierung beispielsweise einen Vibrationsalarm beinhaltet, MÜSSEN sie MÜSSEN die Vibrations-APIs korrekt implementiert. Wenn die Implementierung eines Geräts Hardware verwenden, MÜSSEN die entsprechenden APIs als managementfrei implementiert werden. Dieses Verhalten ist wird in Abschnitt 7 genauer beschrieben.
- [C-1-2] MUSS alle resources korrekt rendern (Symbole, Animationsdateien usw.), die in den APIs oder in den Styleguide für Status-/Systemleistensymbole, obwohl sie eine alternative Nutzererfahrung für Benachrichtigungen bieten KÖNNEN als durch die Open-Source-Referenzimplementierung für Android bereitgestellt.
- [C-1-3] MÜSSEN die für APIs Benachrichtigungen zu aktualisieren, zu entfernen und zu gruppieren.
- [C-1-4] MUSS das vollständige Verhalten von NotificationChannel bereitstellen API, die im SDK dokumentiert ist.
- [C-1-5] MÜSSEN eine Nutzeroption zum Blockieren und Ändern einer bestimmten Benachrichtigung der Drittanbieter-App für jede Kanal- und App-Paketebene.
- [C-1-6] MÜSSEN auch Angebote zum Anzeigen gelöschter Benachrichtigungen enthalten. Kanäle.
[C-1-7] MÜSSEN alle Ressourcen (Bilder, Sticker, Symbole usw.) korrekt rendern. über Notification.MessagingStyle bereitgestellt neben dem Benachrichtigungstext ohne zusätzliche Nutzerinteraktion. Für MÜSSEN beispielsweise alle Ressourcen angezeigt werden, auch die Symbole, die über android.app.Person in einer Gruppenunterhaltung, die durch setGroupConversation:
[C-SR-1] EMPFOHLEN, Nutzern ein Angebot zu bieten, festlegen, welche Benachrichtigungen Apps angezeigt werden, denen die Berechtigung für Mitteilungs-Listener. Der Detaillierungsgrad MUSS so sein, dass die Nutzenden Steuerelement für jeden solchen Benachrichtigungs-Listener, welche Benachrichtigungstypen mit diesem Listener verbunden. Die Typen MÜSSEN „Unterhaltungen“, „Benachrichtigungen“, „Lautlos“ und „Wichtige fortlaufende Inhalte“ Benachrichtigungen.
[C-SR-2] EMPFOHLEN, dürfte Nutzern ein Angebot bieten Apps, bei denen ein bestimmter Benachrichtigungs-Listener nicht benachrichtigt werden soll.
[C-SR-3] WIRD UNBEDINGT EMPFOHLEN, ein Nutzerangebot automatisch anzeigen zu lassen Um die Benachrichtigung einer bestimmten Drittanbieter-App für jeden Kanal und jede App zu blockieren nachdem der Nutzer die Benachrichtigung mehrmals geschlossen hat.
SOLLTEN erweiterte Benachrichtigungen unterstützen.
SOLLTEN Benachrichtigungen mit höherer Priorität als Vorabbenachrichtigungen präsentiert werden.
SOLLTEN die Nutzer die Möglichkeit haben, Benachrichtigungen zurückzustellen.
KANN nur die Sichtbarkeit und den Zeitpunkt festlegen, zu dem Drittanbieter-Apps benachrichtigt werden können von wichtigen Ereignissen, um Sicherheitsprobleme wie die Ablenkung des Fahrers zu mindern.
Mit Android 11 werden Unterhaltungsbenachrichtigungen unterstützt: Benachrichtigungen mit MessagingStyle und gibt eine veröffentlichte Kurzbefehl-ID für Personen an.
Geräteimplementierungen:
- [C-SR-4] EMPFOHLENE Gruppierung und Kennzeichnung
conversation notifications
vor Benachrichtigungen, die keine Unterhaltung sind, mit Ausnahme von laufende Benachrichtigungen zu Diensten im Vordergrund undimportance:high
Benachrichtigungen.
Wenn Geräteimplementierungen conversation notifications
unterstützen
und die App stellt die erforderlichen Daten bereit,
bubbles
:
- [C-SR-5] Wir empfehlen dringend, diese Unterhaltung als Bubble anzuzeigen. Die AOSP-Implementierung erfüllt diese Anforderungen mit der standardmäßigen System-UI, Einstellungen und Launcher.
Wenn Geräteimplementierungen umfassende Benachrichtigungen unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN die exakten Ressourcen wie
über die
Notification.Style
bereitgestellt API-Klasse und ihre abgeleiteten Klassen für die dargestellten Ressourcenelemente. - SOLLTEN Sie jedes einzelne Ressourcenelement (z.B.
Symbol, Titel und Zusammenfassungstext) definiert in
Notification.Style
API-Klasse und ihre abgeleiteten Klassen.
Vorwarnungen sind Benachrichtigungen, die dem Nutzer unabhängig von der Oberfläche präsentiert werden, aktiviert. Wenn Geräteimplementierungen eine Warnmeldung unterstützen Benachrichtigungen erhalten, geschieht Folgendes:
- [C-3-1] MUSS die Ansicht mit Vorabbenachrichtigungen und die Ressourcen verwenden
wie in
Notification.Builder
beschrieben API-Klasse, wenn Vorabbenachrichtigungen angezeigt werden. - [C-3-2] MÜSSEN die in
Notification.Builder.addAction()
ohne zusätzliche Nutzerinteraktion gemeinsam mit dem Inhalt der Benachrichtigung wie im SDK beschrieben.
3.8.3.2 Mitteilungs-Listener-Dienst
Android umfasst die NotificationListenerService
APIs, die es Apps (sobald der Nutzer explizit aktiviert hat) erlauben, eine Kopie von
alle Benachrichtigungen, sobald sie gepostet oder aktualisiert werden.
Geräteimplementierungen:
- [C-0-1] MÜSSEN die Benachrichtigungen korrekt und umgehend vollständig aktualisieren. an alle derartigen installierten und nutzeraktivierten Hörerdienste, einschließlich aller und Alle Metadaten, die an das Benachrichtigungsobjekt angehängt sind.
- [C-0-2] MÜSSEN die
snoozeNotification()
respektieren API-Aufruf aufrufen, die Benachrichtigung schließen und nach der Schlummerfunktion einen Rückruf starten Dauer, die im API-Aufruf festgelegt wird.
Wenn Geräteimplementierungen Nutzern die Möglichkeit bieten, Benachrichtigungen zurückzustellen, geschieht Folgendes:
- [C-1-1] MÜSSEN den Status der zurückgestellten Benachrichtigungen richtig wiedergeben.
Standard-APIs wie
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] MÜSSEN diesem Nutzer die Möglichkeit geben, Benachrichtigungen zu deaktivieren. aus jeder installierten Drittanbieter-App, es sei denn, sie stammen von dauerhafte Dienste im Vordergrund.
3.8.3.3 Nicht stören/Prioritätsmodus
Wenn Geräteimplementierungen die Funktion „Nicht stören“ unterstützen (auch Prioritätsmodus genannt), haben sie folgende Möglichkeiten:
- [C-1-1] MÜSSEN, wenn die Geräteimplementierung dem Nutzer die Möglichkeit bietet, Drittanbieter-Apps Zugriff auf die Konfiguration der „Nicht stören“-Richtlinie zu gewähren oder zu verweigern, Automatische DND-Regeln anzeigen die von Anwendungen zusammen mit den vom Nutzer erstellten und vordefinierten Regeln erstellt werden.
- [C-1-3] MUSS die
suppressedVisualEffects
berücksichtigen Werte, die ü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.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
3.8.3.4 Schutz sensibler Benachrichtigungen
Zu vertraulichen Benachrichtigungsdaten gehören Inhalte wie Einmalpasswörter, einmalige Bestätigungscodes und ähnliche Authentifizierungs- oder Zurücksetzen-Codes, können in Benachrichtigungen für Nutzende zu machen.
Ob Drittanbieter-Apps bei der Geräteimplementierung Nutzer über wichtige Ereignisse zu benachrichtigen, Sie:
[C-1-1] MÜSSEN vertrauliche Benachrichtigungsinformationen aus der Weitergabe an Benachrichtigungs-Listener, es sei denn, der Listener-Dienst ist einer der folgenden:
- Vom System signierte Apps mit einem
uid
< 10.000 - System-UI
- Muschel
- Ausgewählte Companion-Geräte-App (definiert durch
CompanionDeviceManager
) - Rolle „
SYSTEM_AUTOMOTIVE_PROJECTION
“ - Rolle „
SYSTEM_NOTIFICATION_INTELLIGENCE
“ - HOME-Rolle
- Vom System signierte Apps mit einem
Die AOSP-Implementierung von
NotificationAssistantServices
diese Anforderungen beispielhaft darstellt und erfüllt. Weitere Informationen finden Sie unter
android.ext.services.notification
finden Sie ein Beispiel.
Neue Anforderungen beenden
3.8.4. Assist-APIs
Android enthält die Assist APIs. damit Anwendungen auswählen können, wie viele Informationen des aktuellen Kontextes die für den Assistant auf dem Gerät freigegeben sind.
Wenn Geräteimplementierungen die Aktion „Assist“ unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN Endnutzer deutlich darauf hinweisen, wenn der Kontext bereitgestellt wird, indem
Entweder:
<ph type="x-smartling-placeholder">
- </ph>
- Jedes Mal, wenn die Assistent-App auf den Kontext zugreift, wird ein weißes Symbol an den Rändern des Bildschirms an, die die Dauer der Open-Source-Projekt-Implementierung von Android.
- Die vorinstallierte Assistent-App bietet den Nutzern weniger Geld. als zwei Navigationen von der Standardeinstellungen für Spracheingabe und in der Assistant App, und nur dann den Kontext teilen, wenn die Assistent-App explizit durch über die Eingabe eines Hotwords oder einer unterstützenden Navigationstaste.
- [C-2-2] Die vorgesehene Interaktion zum Starten der Assist-App, wie beschrieben.
in Abschnitt 7.2.3 MÜSSEN die vom Nutzer ausgewählte
Assistent-App, d. h. die App, die
VoiceInteractionService
implementiert, oder eine Aktivität, die den 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
TYPE_APPLICATION_OVERLAY
verwenden. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente in der Benachrichtigungsleiste.[C-1-2] MÜSSEN die Toast API berücksichtigen und Endnutzern in einigen sichtbar sind.
3.8.6. Designs
Android bietet „Designs“ als Mechanismus verwendet, mit dem Stile einer gesamten Aktivität oder einer App geöffnet.
Android enthält ein "Holo" und „Material“ Designfamilie als eine Reihe definierter Stile für Anwendungsentwickler:innen, die den Holo-Design wie vom Android SDK definiert.
Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:
- [C-1-1] DÜRFEN KEINE der Holo-Designattribute verändern, die Anwendungen.
- [C-1-2] MUSS das Attribut „Material“ unterstützen Theme-Themenfamilie und DÜRFEN KEINE der folgenden Attribute des Materialdesigns oder deren Assets für Anwendungen zugänglich sind.
[C-1-3] MUSS entweder "sans-serif" Schriftfamilie zu Roboto Version 2.x für die Sprachen die Roboto unterstützt, oder bieten Nutzern die Möglichkeit, die verwendete Schriftart für „sans-serif“ Schriftfamilie auf Roboto Version 2.x für die Sprachen, die von Roboto unterstützt werden.
[C-1-4] MÜSSEN dynamische Farbtonpaletten gemäß AOSP generieren. Dokumentation von
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(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
undMONOCHROMATIC
.„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 „Gerätestandard“- Designfamilie als eine Reihe definierter Stile für Anwendungsentwickler, die das Design an das Design Gerätedesign entsprechend der Definition der Geräteimplementierung.
- Bei Geräteimplementierungen können die Attribute des Gerätestandard-Designs, die Anwendungen.
Android unterstützt ein Variantendesign mit durchscheinenden Systemleisten, Anwendungsentwicklern den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten. Damit Entwickler in dieser Phase Konfiguration ist es wichtig, dass der Stil der Statusleistensymbole unterschiedliche Geräteimplementierungen.
Wenn Geräteimplementierungen eine Systemstatusleiste enthalten, gilt Folgendes:
- [C-2-1] MUSS Weiß für Systemstatussymbole (wie Signalstärke und Akkuladestand) und vom System ausgegebene Benachrichtigungen, es sei denn, das Symbol weist auf einen problematischen Status hin oder eine App fordert eine helle Statusleiste mithilfe von WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS melden.
- [C-2-2] Bei Android-Geräten MÜSSEN die Systemfarbe geändert werden werden Statussymbole schwarz dargestellt (weitere Informationen finden Sie unter R.style), wenn eine App fordert eine LED-Statusleiste an.
3.8.7 Live-Hintergründe
Android definiert einen Komponententyp sowie eine entsprechende API und einen entsprechenden Lebenszyklus, Anwendungen, um eine oder mehrere „Live-Hintergründe“ für die Endanwendenden. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabemöglichkeiten, die als Hintergrund, hinter anderen Anwendungen.
Hardware wird als in der Lage angesehen, Live-Hintergründe zuverlässig auszuführen, wenn sie alle Live-Hintergründe ohne Einschränkung der Funktionalität in einem angemessenen Frame ohne negative Auswirkungen auf andere Anwendungen. Wenn Einschränkungen in der Hardware verursachen, die Hintergründe und/oder Anwendungen abstürzen, nicht ordnungsgemäß funktionieren, zu viel CPU- oder Akkuleistung oder mit inakzeptablen niedrigen Frame-Rates läuft, wird davon ausgegangen, dass auf Hardware keine Live-Hintergründe ausgeführt werden können. Zum Beispiel haben einige Live-Hintergründe können zur Darstellung ihrer Inhalte einen OpenGL 2.0- oder 3.x-Kontext verwenden. Live-Hintergrund funktioniert nicht zuverlässig auf Hardware, die nicht mehrere OpenGL-Kontexte, da die Verwendung eines OpenGL-Kontextes bei der Live-Hintergrundnutzung zu Konflikten führen kann mit anderen Anwendungen, die ebenfalls einen OpenGL-Kontext nutzen.
- Geräteimplementierungen, die Live-Hintergründe zuverlässig ausführen können (siehe Beschreibung) SOLLTEN Live-Hintergründe implementieren.
Wenn Live-Hintergründe auf Geräten implementiert sind, gilt Folgendes:
- [C-1-1] MÜSSEN das Funktions-Flag „android.software.live_wallpaper“ der Plattform melden.
3.8.8. Wechseln zwischen Aktivitäten
Der vorgelagerte Android-Quellcode enthält die Übersichtsbildschirm angezeigt, ein Benutzeroberfläche auf Systemebene zum Wechseln zwischen Aufgaben und Anzeigen der zuletzt aufgerufenen Aktivitäten und Aufgaben mithilfe einer Miniaturansicht der grafischen zu dem Zeitpunkt, zu dem der Nutzer die App das letzte Mal verlassen hat.
Geräteimplementierungen einschließlich der Navigationstaste für die Funktion „Recents“, wie in den Abschnitt 7.2.3 KÖNNEN die Schnittstelle verändern.
Bei Geräteimplementierungen mit der Navigationstaste für die Funktion „Recents“ wie in den Abschnitt 7.2.3 ändert die Benutzeroberfläche, sie:
- [C-1-1] MUSS mindestens bis zu sieben angezeigte Aktivitäten unterstützen.
- SOLLTE mindestens den Titel von vier Aktivitäten gleichzeitig anzeigen.
- SOLLTEN unter „Letzte“ die Farbe, das Symbol und den Bildschirmtitel hervorheben.
- SOLLTE ein abschließendes Angebot („x“) angezeigt werden, aber KANN die Anzeige verzögern, bis der Nutzer mit den Bildschirmen interagiert.
- SOLLTEN Sie eine Verknüpfung implementieren, um einfach zur vorherigen Aktivität zu wechseln.
- SOLLTE ein schneller Wechsel zwischen den beiden zuletzt verwendeten Apps, wenn zweimal auf die Funktionstaste „Letzte Apps“ getippt wird.
- SOLLTE den Splitscreen-Mehrfenstermodus auslösen, sofern unterstützt, wenn das langes Drücken der letzten Funktionstaste
- KANN verbundene zuletzt verwendete Elemente als Gruppe angezeigt werden, die zusammen verschoben wird.
- [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die vorgelagerten Android-Nutzer zu verwenden (oder eine ähnliche Miniaturansicht-basierte Oberfläche) für den Übersichtsbildschirm.
3.8.9. Eingabeverwaltung
Android unterstützt Eingabeverwaltung und Unterstützung für Eingabemethoden-Editoren von Drittanbietern.
Wenn die Geräteimplementierung den Nutzern die Verwendung von Drittanbieter-Eingabemethoden auf der Gerät:
- [C-1-1] MÜSSEN die Plattformfunktion android.software.input_methods und unterstützen IME APIs wie in der Android SDK-Dokumentation definiert.
3.8.10 Mediensteuerung auf dem Sperrbildschirm
Die Remote Control Client API wird von Android 5.0 zugunsten der Medienbenachrichtigungsvorlage mit der Medien-Apps in die Wiedergabesteuerung integriert werden können, auf dem Sperrbildschirm angezeigt.
3.8.11 Bildschirmschoner (früher „Dreams“)
Einstellungen finden Sie in Abschnitt 3.2.3.5. Bildschirmschoner konfigurieren.
3.8.12. Standort
Wenn die Geräteimplementierung einen kompatiblen Hardwaresensor (z.B. GPS) umfasst Standortkoordinaten angegeben werden,
- [C-1-2] MÜSSEN den aktuellen Status des Standorts anzeigen. im Menü „Standort“ in den Einstellungen.
- [C-1-3] DÜRFEN KEINE Standortmodi anzeigen im Menü „Standort“ in den Einstellungen.
3.8.13. Unicode und Schriftart
Android unterstützt die Emoji-Zeichen in den Unicode 10.0.
Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:
- [C-1-1] MUSS diese Emoji-Zeichen in Farbglyphen rendern können.
- [C-1-2] MÜSSEN folgende unterstützen:
<ph type="x-smartling-placeholder">
- </ph>
- Roboto 2-Schriftart mit unterschiedlichen Schriftstärken: sans-serif-thin, sans-serif-light, serif-medium, sans-serif-black, sans-serif-kondensed, Sans Serif-Condensed-light für die auf dem Gerät verfügbaren Sprachen.
- Vollständige Unicode 7.0-Abdeckung für Latein, Griechisch und Kyrillisch, einschließlich der Erweiterte A-, B-, C- und D-Bereiche des lateinischen Alphabets sowie alle Glyphen in der Währung Unicode 7.0-Symbolblock.
- [C-1-3] DARF KEINE NotoColorEmoji.tff aus dem System-Image entfernen oder verändern. (Es ist zulässig, eine neue Emoji-Schriftart hinzuzufügen, um Emojis in NotoColorEmoji.tff)
- SOLLTEN den Hautton und die verschiedenen Familien-Emojis gemäß den Angaben in den Unicode Technical Report Nr. 51
Wenn Geräteimplementierungen einen IME enthalten, gilt Folgendes:
- SOLLTE dem Nutzer eine Eingabemethode für diese Emoji-Zeichen zur Verfügung stellen.
Android unterstützt das Rendern von myanmarischen Schriftarten. Myanmar hat mehrere nicht-Unicode-kompatible Schriftarten, bekannt als Zawgyi, verwenden, für das Rendern von Myanmar Sprachen.
Wenn Geräteimplementierungen Burmesisch unterstützen, gilt Folgendes:
- [C-2-1] Text muss standardmäßig mit Unicode-konformer Schriftart dargestellt werden. Nicht-Unicode-konforme Schriftart DARF NICHT als Standardschriftart festgelegt werden, es sei denn, der Nutzer in der Sprachauswahl aus.
- [C-2-2] MUSS eine Unicode-Schriftart und eine nicht-Unicode-konforme Schriftart unterstützen, wenn ein Nicht-Unicode-konforme Schriftart wird auf dem Gerät unterstützt. Nicht-Unicode konforme Schriftart darf die Unicode-Schriftart NICHT entfernen oder überschreiben.
- [C-2-3] Text in nicht Unicode-konformer Schriftart NUR WENN a Sprachcode mit Skriptcode Qaag angegeben ist (z.B. my-Qaag). Keine anderen ISO-Sprach- oder Regionscodes (ob „zugewiesen“, „nicht zugewiesen“ oder „reserviert“) können für Nicht-Unicode-Zeichen verwendet werden. Schriftart für Myanmar. App-Entwickler und Webseiten-Autoren können Geben Sie my-Qaag genau wie bei jedem anderen Anbieter als Sprachcode an. in einer anderen Sprache.
3.8.14. Mehrere Fenster
Wenn Geräteimplementierungen die Möglichkeit haben, mehrere Aktivitäten auf gleichzeitig geschieht Folgendes:
- [C-1-1] MÜSSEN derartige Mehrfenstermodi gemäß den Anwendungsverhalten und APIs, die im Android SDK beschrieben sind Dokumentation zum Mehrfenstermodus und erfüllen die folgenden Anforderungen erfüllen:
- [C-1-2] MUSS
android:resizeableActivity
anerkennen der von einer App in der 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 Mehrfenstermodus als „Bild im Bild“ verwenden.
- Geräteimplementierungen mit einer Bildschirmgröße von
xlarge
SOLLTEN freies Format unterstützen .
Ob Geräteimplementierungen den Mehrfenstermodus unterstützen und der Splitscreen-Modus haben sie folgende Möglichkeiten:
- [C-2-2] MUSS die angedockte Aktivität bei einem Mehrfenstermodus mit geteiltem Bildschirm zuschneiden, aber SOLLTE einige Inhalte davon zu sehen sein, wenn die Launcher-App das Fenster im Fokus ist.
- [C-2-3] MUSS die deklarierten
AndroidManifestLayout_minWidth
einhalten 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 die Funktion „Bild im Bild“ unterstützen Mehrfenstermodus aktivieren, werden sie:
- [C-3-1] MÜSSEN Aktivitäten im Bild-im-Bild-Mehrfenstermodus gestartet werden
wenn die App:
* Ausrichtung auf API-Level 26 oder höher und deklariert
android:supportsPictureInPicture
* Ausrichtung auf API-Level 25 oder niedriger und 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
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Geräteimplementierungen mehr als eine Android-kompatible Flächen anzeigen und diese für Apps zur Verfügung stellen, geschieht Folgendes:
- [C-4-1] MUSS den Mehrfenstermodus unterstützen.
Wenn Geräteimplementierungen den Mehrfenstermodus unterstützen, gilt Folgendes:
- [C-5-1] MÜSSEN die richtige Version der Fenstermanager-Erweiterungen implementieren.
API-Ebene beschrieben in
WindowManager
Erweiterungen.
Neue Anforderungen beenden
3.8.15. Display-Aussparung
Android unterstützt eine Display-Aussparung, wie beschrieben
im SDK-Dokument. Mit der DisplayCutout
API wird
Einen Bereich am Rand des Displays, der möglicherweise nicht für eine App geeignet ist
Display-Aussparung oder gewölbtes Display an den Rändern.
Wenn Geräteimplementierungen Display-Aussparungen enthalten, gilt Folgendes:
- [C-1-5] DÜRFEN KEINE Aussparungen haben, wenn das Seitenverhältnis des Geräts 1,0 (1:1) beträgt.
- [C-1-2] DÜRFEN NICHT mehr als eine Aussparung pro Rand haben.
- [C-1-3] MÜSSEN die in der App festgelegten Flags für Display-Aussparungen
WindowManager.LayoutParams
API wie im SDK beschrieben. - [C-1-4] MÜSSEN korrekte Werte für alle in der
DisplayCutout
API
3.8.16. Gerätesteuerung
Android enthält ControlsProviderService
und Control
APIs, mit denen Drittanbieter-Apps Gerätesteuerungen schnell veröffentlichen können
und Aktionen für Nutzende.
Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2_2_3.
3.8.17. Zwischenablage
Geräteimplementierungen:
- [C-0-1] DÜRFEN KEINE Daten aus der Zwischenablage an eine Komponente, eine Aktivität, einen Dienst oder ohne explizite Nutzeraktion (z.B. das Drücken einer Schaltfläche im Overlay), mit Ausnahme der Dienste, die in den 9.8.6 Erfassung von Inhalten und App-Suche.
Wenn Geräteimplementierungen eine für den Nutzer sichtbare Vorschau beim Kopieren von Inhalten generieren
in die Zwischenablage für jedes ClipData
-Element, bei dem
ClipData.getDescription().getExtras()
enthält
android.content.extra.IS_SENSITIVE
, sie:
- [C-1-1] MUSS die sichtbare Vorschau des Nutzers entfernen.
Die AOSP-Referenzimplementierung erfüllt diese Anforderungen für die Zwischenablage.
3.9. Geräteverwaltung
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Android umfasst Funktionen, die sicherheitsbewusste
Apps aktivieren
Device Policy Controller-Anwendungen,
Geräteverwaltungsfunktionen auf Systemebene, z. B. das Erzwingen von Passwörtern
oder eine Remote-Löschung durchführen,
Android Device Administration API
Device Policy Manager APIs
- [C-1-1] MUSS
android.software.device_admin
deklarieren. - [C-1-2] MÜSSEN die Bereitstellung von Geräteinhabern unterstützen, wie in den Abschnitt 3.9.1 und Abschnitt 3.9.1.1.
Neue Anforderungen beenden
3.9.1 Gerätebereitstellung
3.9.1.1 Nutzerverwaltung für Geräteinhaber
Wenn in Geräteimplementierungen android.software.device_admin
deklariert wird, gilt Folgendes:
- [C-1-1] MUSS die Registrierung eines Device Policy-Clients (DPC) als
App „Geräteinhaber“
wie unten beschrieben:
<ph type="x-smartling-placeholder">
- </ph>
- Wenn bei der Geräteimplementierung
weder Nutzer noch
konfiguriert sind, geschieht Folgendes:
<ph type="x-smartling-placeholder">
- </ph>
- [C-1-5] MÜSSEN die DPC-Anwendung als Geräteinhaber-App registrieren
oder aktivieren Sie die DPC-App, um
Geräteinhaber oder Profilinhaber werden,
wenn das Gerät NFC-Unterstützung (Nahfeldkommunikation) über
das Funktions-Flag
android.hardware.nfc
und empfängt eine NFC-Nachricht. Enthält einen Datensatz mit einem MIME-TypMIME_TYPE_PROVISIONING_NFC
- [C-1-8] MUSS die ACTION_GET_PROVISIONING_MODE senden
Intent nach der Auslösung der Bereitstellung des Geräteeigentümers,
Die DPC-App kann auswählen, ob sie Geräteinhaber oder Profil werden soll
Inhaber, abhängig von den Werten
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, es sei denn, es lässt sich anhand dass es nur eine gültige Option gibt. - [C-1-9] MÜSSEN die ACTION_ADMIN_POLICY_COMPLIANCE Intent an die App „Geräteinhaber“, wenn ein Geräteinhaber eingerichtet wird während der Bereitstellung, unabhängig von der verwendeten Bereitstellungsmethode. Die Nutzer darf den Einrichtungsassistenten erst verwenden, Die App „Geräteinhaber“ ist fertig.
- [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:
<ph type="x-smartling-placeholder">
- </ph>
- [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:
<ph type="x-smartling-placeholder">
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
[C-1-2] MUSS einen entsprechenden Offenlegungshinweis anzeigen (wie in AOSP angegeben) und vor der Veröffentlichung der App die Einwilligung des Endnutzers einholen. als Geräteinhaber festgelegt, es sei denn, das Gerät wurde programmatisch konfiguriert für den Demomodus für den Einzelhandel vor der Endnutzerinteraktion auf dem Bildschirm. Wenn in der Geräteimplementierung
android.software.device_admin
deklariert ist, aber auch gehören eine proprietäre und bieten einen Mechanismus, eine in der Lösung konfigurierte Anwendung als „Geräteinhaber“ hochstufen Äquivalent“ den standardmäßigen „Geräteinhaber“ wie sie vom standardmäßigen Android- DevicePolicyManager APIs:[C-2-1] MÜSSEN über einen Prozess verfügen, mit dem geprüft wird, ob die betreffende App der beworben wird, gehört zu einer legitimen Unternehmensgeräteverwaltung. -Lösung und wurde in der proprietären Lösung konfiguriert. um die entsprechenden Rechte als Geräteinhaber zu haben.
[C-2-2] MUSS dieselbe Offenlegung zur Einwilligung des AOSP-Geräteinhabers anzeigen wie in Vorgang initiiert von
android.app.action.PROVISION_MANAGED_DEVICE
bevor Sie die DPC-Anwendung als "Geräteinhaber" registrieren.[C-2-3] DÜRFEN die Einwilligung NICHT hartcodieren oder verhindern, die Nutzung anderer Apps von Geräteeigentümern.
Neue Anforderungen beenden
3.9.1.2 Bereitstellung verwalteter Profile
Wenn in Geräteimplementierungen android.software.managed_users
deklariert wird, gilt Folgendes:
- [C-1-1] MÜSSEN die APIs implementieren. sodass eine DPC-Anwendung (Device Policy Controller) zur Inhaber eines neuen verwalteten Profils
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-2] Der Bereitstellungsprozess für verwaltete Profile, also der vom DPC mithilfe der android.app.action.PROVISION_MANAGED_PROFILE) oder der Plattform), der Zustimmungsbildschirm und die Nutzererfahrung MÜSSEN mit den der AOSP-Implementierung.
Neue Anforderungen beenden
[C-1-3] MÜSSEN die folgenden Nutzereigenschaften in den Einstellungen dem Nutzer anzeigen, wenn eine bestimmte Systemfunktion durch Device Policy Controller (DPC):
- Ein einheitliches Symbol oder ein anderes Angebot für Nutzer (zum Beispiel das vorgelagerte Angebot) AOSP-Infosymbol), um anzuzeigen, dass eine bestimmte Einstellung durch ein Device Admin.
- Eine kurze Erklärung, die vom Device Admin über die
setShortSupportMessage
- Das Symbol der DPC-Anwendung.
[C-1-4] MÜSSEN den Handler für ACTION_PROVISIONING_SUCCESSFUL starten. im Arbeitsprofil, wenn ein Profilinhaber festgelegt wird, Die Bereitstellung wird durch android.app.action.PROVISION_MANAGED_PROFILE eingeleitet und der DPC hat den Handler implementiert.
[C-1-5] MUSS ACTION_PROFILE_PROVISIONING_COMPLETE gesendet werden an den DPC des Arbeitsprofils übertragen, wenn die Bereitstellung vom android.app.action.PROVISION_MANAGED_PROFILE die Nutzerabsicht verstehen.
[C-1-6] MÜSSEN die ACTION_GET_PROVISIONING_MODE senden Intent nach Auslösung der DPC-App-Bereitstellung des Profilinhabers. können festlegen, ob sie Geräteinhaber oder Profilinhaber werden möchten, es sei denn, Die Bereitstellung wird durch den Intent android.app.action.PROVISION_MANAGED_PROFILE ausgelöst.
[C-1-7] MUSS die ACTION_ADMIN_POLICY_COMPLIANCE senden Intent für das Arbeitsprofil, wenn während unabhängig von der verwendeten Bereitstellungsmethode, ausgenommen wenn die Bereitstellung durch den Intent android.app.action.PROVISION_MANAGED_PROFILE ausgelöst wird. Der Nutzer darf den Einrichtungsassistenten erst verwenden, wenn das Profil Inhaber-App beendet.
[C-1-8] MUSS ACTION_MANAGED_PROFILE_PROVISIONED senden an den privaten Profil-DPC übertragen, wenn ein Profilinhaber eingerichtet wird, unabhängig von der verwendeten Bereitstellungsmethode.
3.9.2 Unterstützung für verwaltete Profile
Wenn in Geräteimplementierungen android.software.managed_users
deklariert wird, gilt Folgendes:
- [C-1-1] MUSS verwaltete Profile über die
android.app.admin.DevicePolicyManager
unterstützen APIs - [C-1-2] MUSS die Erstellung nur eines einzigen verwalteten Profils zulassen.
- [C-1-3] MUSS ein Symbol (ähnlich dem AOSP-Upstream-Arbeitsabzeichen) verwenden, um die verwalteten Anwendungen und Widgets und andere gekennzeichnete UI-Elemente darstellen, wie Recents und Benachrichtigungen.
- [C-1-4] MÜSSEN ein Benachrichtigungssymbol anzeigen (ähnlich der AOSP-Upstream-Arbeit). ) angezeigt, wenn sich der Nutzer in einer Anwendung mit einem verwalteten Profil befindet.
- [C-1-5] MÜSSEN ein Toast anzeigen, der darauf hinweist, dass sich der Nutzer im verwalteten Konto befindet. wenn das Gerät aktiviert wird (ACTION_USER_PRESENT) und die Die Anwendung im Vordergrund befindet sich im verwalteten Profil.
- [C-1-6] Wenn ein verwaltetes Profil vorhanden ist, MUSS im Intent-Auswahl damit der Nutzer den Intent aus dem verwalteten Bereich an den Hauptnutzer oder umgekehrt, wenn diese Funktion über die Device Policy aktiviert wurde. Controller.
- [C-1-7] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN die folgenden Nutzer angezeigt werden
Angebote für den Hauptnutzer und das verwaltete Profil:
<ph type="x-smartling-placeholder">
- </ph>
- Separate Berechnung von Akku-, Standort-, mobiler Daten- und Speichernutzung für den Hauptnutzer und das verwaltete Profil.
- Unabhängige Verwaltung von VPN-Anwendungen, die in der primären Instanz installiert sind Nutzer- oder verwalteten Profils.
- Unabhängige Verwaltung von Anwendungen, die innerhalb des Hauptnutzers installiert sind oder einem verwalteten Profil.
- Unabhängige Verwaltung von Konten innerhalb des primären Nutzers oder verwalteten Konten zu erstellen.
- [C-1-8] MÜSSEN sicherstellen, dass Telefon, Kontakte und Messaging vorinstalliert sind. können Anruferinformationen in den verwalteten Apps (sofern vorhanden) zusätzlich zum primären Profil, wenn das Device Policy Controller lässt dies zu.
- [C-1-9] MÜSSEN sicherstellen, dass alle Sicherheitsanforderungen erfüllt werden. gilt für ein Gerät mit mehreren aktivierten Nutzern (siehe Abschnitt 9.5), auch wenn das verwaltete Profil wird nicht zusätzlich zum primären Nutzer als weiterer Nutzer gezählt.
- [C-1-10] MÜSSEN sicherstellen, dass die Screenshot-Daten im Arbeitsprofil gespeichert sind.
wenn ein Screenshot mit einem
topActivity
Fenster mit Fokus (der der Nutzer zuletzt unter allen Aktivitäten interagiert hat) und zu dem er gehört eine Arbeitsprofil-App. - [C-1-11] DÜRFEN KEINE anderen Bildschirminhalte (Systemleiste, Benachrichtigungen oder Inhalte im privaten Profil), mit Ausnahme des Arbeitsprofils Fenster/Fenster der Anwendung wenn Sie einen Screenshot im Arbeitsprofil speichern. Profildaten nicht im Arbeitsprofil gespeichert werden.
Wenn in der Geräteimplementierung android.software.managed_users
und
android.software.secure_lock_screen
:
- [C-2-1] MUSS die Möglichkeit unterstützen, eine separate Besprechung auf dem Sperrbildschirm anzugeben.
die folgenden Anforderungen, um Zugriff auf Apps zu gewähren, die in einer verwalteten
- Geräteimplementierungen MÜSSEN die
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
Intent angezeigt und eine Benutzeroberfläche zum Konfigurieren eines separaten Sperrbildschirms angezeigt werden. Anmeldedaten für das verwaltete Profil. - Die Anmeldedaten für den Sperrbildschirm des verwalteten Profils MÜSSEN dieselben die Mechanismen zum Speichern und Verwalten von Anmeldedaten als übergeordnetes Profil. wie auf der Website des Open-Source-Projekts von Android.
- DPC-Passwortrichtlinien
MUSS sich nur auf die Anmeldedaten für den Sperrbildschirm des verwalteten Profils beziehen, es sei denn,
für die
DevicePolicyManager
-Instanz aufgerufen, die vongetParentProfileInstance
- 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. Rollenanforderungen für die Device Policy Management-Rolle
Wenn Geräteimplementierungen android.software.device_admin
oder
android.software.managed_users
:
- [C-1-1] MUSS die Rolle zur Verwaltung von Geräterichtlinien gemäß der Definition in
Abschnitt 9.1. Die Anwendung, die die Rolle zur Verwaltung von Geräterichtlinien hat
KANN definiert werden, indem
config_devicePolicyManagement
auf den Paketnamen festgelegt wird. Auf den Paketnamen MÜSSEN:
und das Signaturzertifikat folgen, es sei denn, die Anwendung ist vorab geladen.
Wenn für config_devicePolicyManagement
kein Paketname als
wie oben beschrieben:
- [C-2-1] Geräteimplementierungen MÜSSEN die Bereitstellung ohne Gerät unterstützen Richtlinienmanagement-Bewerbung für Rolleninhaber AOSP bietet eine Referenzimplementierung.
Wenn ein Paketname für config_devicePolicyManagement
wie beschrieben definiert ist
oben:
- [C-3-1] Die App MUSS auf allen Geräten installiert werden, Profile für einen Nutzer.
- [C-3-2] Geräteimplementierungen KÖNNEN eine Anwendung definieren, die die
Rolleninhaber für die Verwaltung von Geräterichtlinien vor der Bereitstellung durch Einstellung
config_devicePolicyManagementUpdater
Wenn für config_devicePolicyManagementUpdater
ein Paketname definiert ist als
wie oben beschrieben:
- [C-4-1] Die App MUSS auf dem Gerät vorinstalliert sein.
- [C-4-2] Die Anwendung MÜSSEN einen Intent-Filter implementieren, der
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
3.9.5 Framework zur Auflösung von Geräterichtlinien
Wenn Geräteimplementierungen android.software.device_admin
oder
android.software.managed_users
:
- [C-1-1] MÜSSEN Konflikte mit Geräterichtlinien gemäß der Dokumentation Device Policy Resolution Framework
3:10. Bedienungshilfen
Android bietet eine Ebene der Bedienungshilfen, über die Nutzer mit Beeinträchtigungen einfacher zu bedienen. Außerdem bietet Android Plattform-APIs die es Bedienungshilfen ermöglichen, Callbacks für Nutzer zu empfangen. und Systemereignisse zu identifizieren und alternative Feedbackmechanismen zu generieren, z. B. Sprachausgabe, haptisches Feedback und Navigation per Trackball oder Steuerkreuz
Wenn Geräteimplementierungen Bedienungshilfen von Drittanbietern unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN eine Implementierung der Android-Bedienungshilfen wie in den Bedienungshilfen-APIs SDK-Dokumentation
- [C-1-2] MÜSSEN Bedienungshilfen-Ereignisse generieren und die
AccessibilityEvent
an alle 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.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
3:12. TV-Eingabe-Framework
Das Android Television Input Framework (TIF) vereinfacht die Bereitstellung von Live-Inhalten an Android-Fernsehgeräte TIF stellt eine Standard- API zum Erstellen von Eingabemodulen, die Android TV-Geräte steuern
Wenn Geräteimplementierungen TIF unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die Plattformfunktion
android.software.live_tv
deklarieren. - [C-1-2] MUSS alle TIF APIs unterstützen, sodass eine Anwendung, die diesen APIs und den TIF-basierten Eingaben von Drittanbietern auf dem Gerät installiert und verwendet werden kann.
Neue Anforderungen beenden
3:13. Schnelleinstellungen
Android bietet eine UI-Komponente für die Schnelleinstellungen, mit der Sie schnell auf häufig genutzte oder dringend benötigte Maßnahmen.
Wenn Geräteimplementierungen eine UI-Komponente für Schnelleinstellungen enthalten und einen Drittanbieter unterstützen Über die Schnelleinstellungen können Sie Folgendes tun:
- [C-1-1] MÜSSEN Nutzer die über die
quicksettings
APIs einer Drittanbieter-App - [C-1-2] DÜRFEN KEINE Kacheln direkt direkt aus einer Drittanbieter-App hinzufügen zu den Schnelleinstellungen.
- [C-1-3] MÜSSEN alle vom Nutzer hinzugefügten Kacheln aus Drittanbieter-Apps angezeigt werden neben den vom System bereitgestellten Kacheln für die Schnelleinstellungen.
3:14. Medien-UI
Wenn Geräteimplementierungen Apps umfassen, die nicht sprachgesteuert sind (die Apps), die mit
Drittanbieter-Apps über MediaBrowser
oder MediaSession
,
der Apps:
[C-1-2] MÜSSEN die über
getIconBitmap()
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:
<ph type="x-smartling-placeholder">
- </ph>
- Der Intent-Musterfilter der Komponente ist verfügbar und enthält CATEGORY_BROWSABLE
- Es handelt sich um eine der folgenden Aktionen: ACTION_SEND, ACTION_SENDTO oder ACTION_SEND_MULTIPLE
- Das Ziel wird explizit mit android:visibleToInstantApps bereitgestellt.
- [C-1-3] Instant Apps DÜRFEN NICHT explizit mit installierten Apps interagieren, es sei denn, Komponente wird über android:visibleToInstantApps bereitgestellt.
- [C-1-4] Installierte Apps DÜRFEN KEINE Details zu Instant Apps auf der Gerät, es sei denn, die Instant App stellt explizit eine Verbindung installierte Anwendung.
Geräteimplementierungen MÜSSEN die folgenden Nutzerangebote für mit Instant Apps interagieren. Der AOSP erfüllt die Anforderungen mit der Standard-System-UI, Einstellungen und Launcher. Geräteimplementierungen:
- [C-1-5] MÜSSEN Nutzern die Möglichkeit bieten, Instant Apps aufzurufen und zu löschen. für jedes einzelne App-Paket im lokalen Cache gespeichert.
- [C-1-6] MÜSSEN eine dauerhafte Nutzerbenachrichtigung bereitstellen, die
minimiert werden, während eine Instant-App im Vordergrund ausgeführt wird. Dieser Nutzer
Benachrichtigung MUSS enthalten, dass Instant Apps keine Installation erfordern
und ihnen Angebote bieten, die sie zur App weiterleiten.
Infobildschirm in den Einstellungen. Bei Instant Apps, die über Web Intents gestartet werden, wie
definiert durch einen Intent, dessen Aktion auf
Intent.ACTION_VIEW
festgelegt ist, und mit dem Schema "http" oder „https“, eine zusätzliche Angebotsmöglichkeit für Nutzer, SOLLTE dem Nutzer erlauben, die Instant App nicht zu starten und startet den zugehörigen Link mit dem konfigurierten Webbrowser, falls ein Browser auf dem Gerät verfügbar ist. - [C-1-7] MÜSSEN den Zugriff auf ausgeführte Instant Apps über die App „Letzte“ erlauben , wenn die Funktion „Zuletzt verwendet“ auf dem Gerät verfügbar ist.
[C-1-8] MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten vorab laden. mit einem Intent-Handler für die Intents, die hier im SDK aufgeführt sind und die Intents für Instant Apps sichtbar machen.
3:16. Begleitgerät koppeln
Android unterstützt die Kopplung von Begleitgeräten für eine effektivere Verwaltung.
Verknüpfung mit Companion-Geräten und bietet die CompanionDeviceManager
API für Apps, die auf diese Funktion zugreifen können.
Wenn Geräteimplementierungen die Kopplungsfunktion von Begleitgeräten unterstützen, gilt Folgendes:
- [C-1-1] MUSS das Funktions-Flag
FEATURE_COMPANION_DEVICE_SETUP
deklarieren. . - [C-1-2] MÜSSEN sicherstellen, dass die APIs in der
android.companion
-Paket vollständig implementiert ist.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-3] MÜSSEN Nutzern Angebote zur Auswahl/Bestätigung bereitgestellt werden. Begleitgerät vorhanden und betriebsbereit ist, die dieselbe Nachricht wie in AOSP implementiert ohne Addition oder Änderung.
Neue Anforderungen beenden
3:17. Komplexe Apps
Wenn in Geräteimplementierungen die Funktion FEATURE_CANT_SAVE_STATE
deklariert ist,
dann:
- [C-1-1] DÜRFEN nur eine App installiert haben, die folgende Anforderungen erfüllt:
cantSaveState
gleichzeitig im System ausgeführt werden. Wenn der Nutzer verlässt eine solche App, ohne sie explizit zu beenden (z. B. durch Drücken von wenn das System eine aktive Aktivität verlässt, anstatt ohne verbleibende aktive Aktivitäten im System), dann Geräteimplementierungen MÜSSEN diese App wie bei anderen Apps im RAM priorisieren. Dinge, die weiterhin ausgeführt werden sollen, z. B. Dienste im Vordergrund. Auch wenn eine solche App im Hintergrund läuft, kann das System trotzdem Strom liefern. z. B. die Begrenzung des CPU- und Netzwerkzugriffs. - [C-1-2] MÜSSEN eine UI-Option bereitstellen, mit der die App ausgewählt werden kann, die nicht
den normalen Speicher-/Wiederherstellungsmechanismus nutzen,
startet eine zweite App, die mit
cantSaveState
deklariert wurde . - [C-1-3] DÜRFEN KEINE anderen Richtlinienänderungen auf Apps anwenden, für die Folgendes angegeben ist:
cantSaveState
, z. B. die CPU-Leistung oder die Planungspriorisierung ändern.
Wenn die Funktion in der Geräteimplementierung nicht deklariert wird
FEATURE_CANT_SAVE_STATE
,
dann:
- [C-1-1] MUSS
cantSaveState
ignorieren. von Apps festgelegt wurde und DÜRFEN das App-Verhalten NICHT basierend auf diesem Attribut ändern. .
3:18. Kontakte
Android umfasst
Contacts Provider
APIs, mit denen Anwendungen die auf dem Gerät gespeicherten Kontaktdaten verwalten können
Direkt in das Gerät eingegebene Kontaktdaten werden in der Regel synchronisiert.
mit einem Webdienst verknüpft sein, aber die Daten KÖNNEN auch nur lokal auf dem Gerät gespeichert sein.
Kontakte, die nur auf dem Gerät gespeichert sind, werden als lokale
Kontakte.
Rohkontakte
„verknüpft mit“ oder „gespeichert in“ eine
Konto
wenn das Ereignis
ACCOUNT_NAME
,
und
ACCOUNT_TYPE
Spalten für die unverarbeiteten Kontakte mit den entsprechenden
Konto.name
und
Kontotyp
des Kontos.
Lokales Standardkonto: ein Konto für unformatierte Kontakte, die nur in
und nicht mit einem Konto im
AccountManager,
die mit null-Werten für die
ACCOUNT_NAME
,
und
ACCOUNT_TYPE
Spalten.
Benutzerdefiniertes lokales Konto: ein Konto für unformatierte Kontakte, die nur auf dem
Gerät und nicht mit einem Konto im AccountManager verknüpft ist. Diese können
erstellt mit mindestens einem Nicht-Null-Wert für die
ACCOUNT_NAME
,
und
ACCOUNT_TYPE
Spalten.
Geräteimplementierungen:
- [C-SR-1] Es wird dringend empfohlen, keine benutzerdefinierten lokalen Konten zu erstellen.
Wenn für Geräteimplementierungen ein benutzerdefiniertes lokales Konto verwendet wird:
- [C-1-1] Die
ACCOUNT_NAME
, des benutzerdefinierten lokalen Kontos MÜSSEN 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.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
3:19. Spracheinstellungen
Geräteimplementierungen:
- [C-0-1] DÜRFEN KEINE Nutzerangebote zur Auswahl geschlechtsspezifischer Angebote machen. Behandlung von Sprachen, die keine geschlechtsspezifischen Informationen unterstützen Übersetzungen. Grammatikalische Ressourcen .
Neue Anforderungen beenden
4. Kompatibilität der App-Paketerstellung
Implementierungen auf Geräten:
[C-0-1] MUSS Android ".apk" installieren und ausführen können Dateien unter generiert von „aapt“ im offiziellen Android SDK.
- Da die obige Anforderung eine Herausforderung sein kann, werden Geräteimplementierungen EMPFOHLEN, die Paketverwaltung der AOSP-Referenzimplementierung zu verwenden System.
[C-0-2] MUSS die Überprüfung von ".apk" unterstützen Dateien mithilfe der APK-Signaturschema v3.1, APK Signature Scheme v3 APK-Signaturschema v2 und JAR-Signatur.
[C-0-3] DÜRFEN NICHT die .apk Android-Manifest, Dalvik-Bytecode oder RenderScript-Bytecodeformate so, dass diese Dateien nicht auf anderen kompatiblen Geräten installiert werden kann.
[C-0-4] DÜRFEN KEINE anderen Apps als die aktuellen zulassen. „Installer of Record“ damit das Paket die App unbemerkt und ohne Nutzerbestätigung, wie im SDK für den
DELETE_PACKAGE
Berechtigung. Die einzige Ausnahme ist die App, die die Systempaketprüfung verarbeitet, PAKET_ERFORDERLICH_BESTÄTIGUNG der Intent- und Speichermanager-App, ACTION_MANAGE_STORAGE die Nutzerabsicht verstehen.[C-0-5] MÜSSEN über eine Aktivität verfügen,
android.settings.MANAGE_UNKNOWN_APP_SOURCES
die Nutzerabsicht verstehen.[C-0-6] DÜRFEN KEINE Anwendungspakete von unbekannten Quellen, es sei denn, die App, die die Installation anfordert alle folgenden Anforderungen erfüllt:
- Es MÜSSEN die
REQUEST_INSTALL_PACKAGES
deklariert werden. 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()
, Wenn die Geräteimplementierung den Nutzern diese Auswahl nicht ermöglichen soll. Aber selbst in solchen Fällen SOLLTEN sie dem Nutzer mitteilen, warum eine solche Auswahl.[C-0-7] MÜSSEN ein Warndialogfeld mit der Zeichenfolge für die Warnung über die System-API
PackageManager.setHarmfulAppWarning
bevor eine Aktivität in einer Anwendung gestartet wird, die als System-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,
<ph type="x-smartling-placeholder">
- </ph>
- SOLLTEN KEINE Eingabepuffer verbrauchen und speichern und nur Eingabepuffer zurückgeben. nach der Verarbeitung.
- Decodierte Puffer sollten NICHT länger aufbewahrt werden, als in den Standard (z.B. SPS).
- Sie sollten codierte Puffer NICHT länger aufbewahren, als von der GoP gefordert. Struktur.
Alle im folgenden Abschnitt aufgeführten Codecs werden als Softwareprogramme bereitgestellt. Implementierungen in der bevorzugten Android-Implementierung aus dem Quellprojekt.
Bitte beachten Sie, dass weder Google noch die Open Handset Alliance Erklärung, dass diese Codecs frei von Patenten Dritter sind. Diese wird empfohlen, diesen Quellcode in Hardware- oder Softwareprodukten zu verwenden. dass Implementierungen dieses Codes, auch in Open-Source-Software oder Shareware erfordern möglicherweise Patentlizenzen von den entsprechenden Patentinhabern.
5.1. Medien-Codecs
5.1.1 Audiocodierung
Weitere Informationen finden Sie unter 5.1.3. Details zu Audio-Codecs.
Wenn in der Geräteimplementierung android.hardware.microphone
deklariert ist,
Sie MÜSSEN die Codierung der folgenden Audioformate unterstützen und bereitstellen.
Drittanbieter-Apps:
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
Alle Audioencoder MÜSSEN unterstützen:
- [C-3-1] 16-Bit-Audioframes für native PCM-Bytereihenfolge in PCM über den
android.media.MediaCodec
der API erstellen.
5.1.2 Audiodecodierung
Weitere Informationen finden Sie unter 5.1.3. Details zu Audio-Codecs.
Wenn in den Geräteimplementierungen die
android.hardware.audio.output
-Funktion verwenden, müssen sie die Decodierung unterstützen,
folgenden Audioformaten verwenden:
- [C-1-1] MPEG-4 AAC Profile (AAC LC)
- [C-1-2] MPEG-4 HE AAC-Profil (AAC+)
- [C-1-3] MPEG-4 HE AACv2 Profile (erweitertes AAC+)
- [C-1-4] AAC ELD (Optimierte AAC mit niedriger Verzögerung)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, einschließlich USAC Baseline Profile und ISO/IEC 23003-4 Dynamic Range Einstellungsprofil)
- [C-1-5] FLAC
- [C-1-6] MP3-Datei
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE einschließlich hochauflösendem Audio Formate mit bis zu 24 Bit, Abtastrate von 192 kHz und 8 Kanälen. Beachten Sie, dass diese Anforderung nur für die Decodierung gilt und dass ein Gerät während der Wiedergabe ein Downsampling oder Downmix zulassen.
- [C-1-10] Opus
Wenn Geräteimplementierungen die Decodierung von AAC-Eingabepuffern von
Multi-Channel-Streams (d.h. mehr als zwei Kanäle) über die Standardeinstellung zu PCM
AAC-Audiodecoder in der android.media.MediaCodec
API. Folgendes MÜSSEN sein:
unterstützt:
- [C-2-1] Decodierung MUSS ohne Downmixing durchgeführt werden (z.B. eine 5,0-AAC-Datei). Der Stream muss in fünf PCM-Kanäle decodiert werden, ein 5.1-AAC-Stream muss decodiert werden bis zu sechs Kanäle für PCM).
- [C-2-2] Die Metadaten für den dynamischen Bereich MÜSSEN der Definition in "Dynamic Range Control" entsprechen.
Demokratische Republik Kongo" in ISO/IEC 14496-3 und die
android.media.MediaFormat
DRC-Schlüssel zur Dynamikumfang-bezogenes Verhalten des Audiodecoders konfigurieren Die AAC DRC-Schlüssel wurden in API 21 eingeführt und sind:KEY_AAC_DRC_ATTENUATION_FACTOR
,KEY_AAC_DRC_BOOST_FACTOR
,KEY_AAC_DRC_HEAVY_COMPRESSION
,KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
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 <ph type="x-smartling-placeholder"></ph> AMR-WB, adaptive Multi-Rate – Wideband Speech Codec | 3GPP (3GP) |
FLAC | Sowohl für Encoder als auch Decoder: MÜSSEN mindestens die Mono- und Stereomodi verwendet werden. unterstützt. Abtastraten von bis zu 192 kHz MÜSSEN unterstützt werden. 16-Bit und 24-Bit Auflösung MUSS unterstützt werden. Die Verarbeitung von FLAC-24-Bit-Audiodaten MÜSSEN Gleitkomma-Audio-Konfiguration verfügbar. |
|
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
- [C-0-4] AVIF
<ph type="x-smartling-placeholder">
- </ph>
- Geräte müssen
BITRATE_MODE_CQ
und Baseline-Profil unterstützen.
- Geräte müssen
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
BitratenkontrollmodusHEVCProfileMainStill
und eine Frame-Größe von 512 x 512 Pixeln.
5.1.5 Bilddecodierung
Weitere Informationen finden Sie unter 5.1.6. Details zu Image-Codecs.
Geräteimplementierungen MÜSSEN die Decodierung der folgenden Bildcodierung unterstützen:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Roh
- [C-0-7] AVIF (Baseline-Profil)
Wenn Geräteimplementierungen die HEVC-Videodecodierung unterstützen, gilt Folgendes:
- [C-1-1] MUSS die HEIF-Bilddecodierung (HEIC) unterstützen.
Bilddecoder, die ein Format mit hoher Bittiefe unterstützen (mehr als 9 Bit pro Kanal):
- [C-2-1] MUSS die Ausgabe eines entsprechenden 8-Bit-Formats unterstützen, wenn dies von
Die Anwendung, z. B. über
ARGB_8888
Konfiguration vonandroid.graphics.Bitmap
.
5.1.6. Details zu Image-Codecs
Format/Codec | Details | Unterstützte Dateitypen/Containerformate |
---|---|---|
JPEG | Base+progressiv | JPEG (JPG) |
GIF | GIF (.gif) | |
PNG | PNG (PNG) | |
BMP | BMP (BMP) | |
WebP | WebP (WebP) | |
Raw | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIF | Bild, Bildersammlung, Bildsequenz | HEIF (.heif), HEIC (.heic) |
AVIF (Baseline-Profil) | Bild, Bilderfassung, Bildsequenz-Baseline-Profil | HEIF-Container (AVIF) |
Bild-Encoder und -Decodierer, die über die MediaCodec API verfügbar gemacht werden
[C-1-1] MUSS 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 ein VP8-Hardware-Codec verwendet werden, der den Anforderungen erfüllen.
Wenn Geräteimplementierungen einen Videodecoder oder Encoder umfassen:
[C-1-1] Video-Codecs MÜSSEN Ausgabe- und Eingabe-Bytebuffer-Größen unterstützen, die den größtmöglichen komprimierten und unkomprimierten Frame entsprechend den Vorgaben und der Konfiguration, aber auch nicht zu viel.
[C-1-2] Video-Encoder und -Decodierer MÜSSEN die flexible Farbe YUV420 im Format 8:8:8 unterstützen. (
COLOR_FormatYUV420Flexible
) 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. |
|
AV1 | Weitere Informationen finden Sie in Abschnitt 5.2 und Abschnitt 5.3. |
|
5.1.9. Medien-Codec-Sicherheit
Geräteimplementierungen MÜSSEN die Einhaltung der Sicherheitsfunktionen für Medien-Codec sicherstellen wie unten beschrieben.
Android unterstützt OMX, eine plattformübergreifende Multimedia Acceleration API, sowie Codec 2.0, eine Low-Overhead-Multimedia-Beschleunigungs-API.
Wenn Geräteimplementierungen Multimedia unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN Support für Medien-Codecs entweder über OMX oder Codec 2.0 bereitstellen. APIs (oder beides) wie im Android Open Source-Projekt und nicht deaktiviert oder um die Sicherheitsvorkehrungen zu umgehen. Das bedeutet insbesondere nicht, dass jede Codec MUSS entweder die OMX- oder die Codec 2.0 API verwenden. Nur die Unterstützung für mindestens Eine dieser APIs MUSS verfügbar sein und der Support für die verfügbaren APIs MÜSSEN MÜSSEN die vorhandenen Sicherheitsvorkehrungen.
- [C-SR-1] wird dringend empfohlen, Support für die Codec 2.0 API aufzunehmen.
Wenn Geräteimplementierungen die Codec 2.0 API nicht unterstützen, geschieht Folgendes:
- [C-2-1] MÜSSEN den entsprechenden OMX-Software-Codec aus dem Open-Source-Projekt (sofern verfügbar) für jedes Medienformat und jeden Medientyp (Encoder oder Decoder), der vom Gerät unterstützt wird.
- [C-2-2] Codecs, deren Namen mit „OMX.google“ beginnen. MÜSSEN aufgestellt sein. im Quellcode ihres Android Open Source Project.
- [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, dass die OMX-Software-Codecs in einem Codec ausgeführt werden Prozess, der keinen Zugriff auf andere Hardwaretreiber als Speicher-Mapper hat.
Wenn Geräteimplementierungen die Codec 2.0 API unterstützen, gilt Folgendes:
- [C-3-1] MÜSSEN den entsprechenden Codec 2.0-Software-Codec aus dem Open-Source-Projekt von Android (sofern verfügbar) für jedes Medienformat und jeden Medientyp (Encoder oder Decoder), der vom Gerät unterstützt wird.
- [C-3-2] MÜSSEN die Codec 2.0-Software-Codecs im Software-Codec enthalten. wie im Android Open Source Project beschrieben, um enger Zugriff auf Software-Codecs zu gewähren.
- [C-3-3] Codecs, deren Namen mit „c2.android“ beginnen. MÜSSEN aufgestellt sein. im Quellcode ihres Android Open Source Project.
5.1.10. Charakterisierung von Medien-Codec
Wenn Geräteimplementierungen Medien-Codecs unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN korrekte Werte für die Media-Codec-Charakterisierung über die
MediaCodecInfo
der API erstellen.
Insbesondere
- [C-1-2] Codecs, deren Namen mit „OMX“ beginnen. MÜSSEN die OMX-APIs verwenden. und deren Namen den Benennungsrichtlinien von OMX IL entsprechen.
- [C-1-3] Codecs mit Namen, die mit „c2“ beginnen. MÜSSEN die Codec 2.0 API und deren Namen den Codec 2.0-Benennungsrichtlinien für Android entsprechen.
- [C-1-4] Codecs, deren Namen mit „OMX.google“ beginnen. oder „c2.android“. MUSS Sie dürfen NICHT als Anbieter oder hardwarebeschleunigt bezeichnet werden.
- [C-1-5] Codecs, die in einem Codec-Prozess (Anbieter oder System) ausgeführt werden, Der Zugriff auf andere Hardwaretreiber als Speicherzuordnungen und Mapper DÜRFEN NICHT sind reine Softwareprodukte.
- [C-1-6] Codecs, die nicht im Android Open Source Project vorhanden sind oder nicht basieren im Quellcode in diesem Projekt MUSS als Anbieter gekennzeichnet werden.
- [C-1-7] Codecs, die die Hardwarebeschleunigung nutzen, MÜSSEN gekennzeichnet werden, als hardwarebeschleunigt wurde.
- [C-1-8] Codec-Namen DÜRFEN NICHT irreführend sein. Beispiele für Codecs mit der Bezeichnung "Decoder" MÜSSEN die Decodierung und solche mit der Bezeichnung „Encoder“ unterstützen MÜSSEN unterstützen Codierung. Codecs mit Namen, die Medienformate enthalten, MÜSSEN diese unterstützen. Formaten.
Wenn Geräteimplementierungen Video-Codecs unterstützen:
- [C-2-1] Alle Video-Codecs MÜSSEN erreichbare Frame-Rate-Daten für die folgenden Größen, wenn der Codec unterstützt wird:
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Videoauflösung |
|
|
|
1920 x 1080 Pixel (außer MPEG4, AV1) | 3840 x 2160 Pixel (HEVC, VP9, AV1) |
- [C-2-2] Video-Codecs, die als hardwarebeschleunigt gekennzeichnet sind, MÜSSEN MÜSSEN
Informationen zu Leistungspunkten veröffentlichen. Sie MÜSSEN jeweils alle unterstützten
Punkte der standardmäßigen Leistung (aufgeführt in
PerformancePoint
) API), sofern sie nicht von einem anderen unterstützten Standard-Leistungspunkt abgedeckt sind. - Außerdem SOLLTEN sie erweiterte Leistungspunkte veröffentlichen, die anhaltende Videoleistung aufweisen, außer einer der oben aufgeführten.
5.2. Videocodierung
Wenn Geräteimplementierungen Video-Encoder unterstützen und für alle
Drittanbieter-Apps und legen Sie die
Von MediaFormat.KEY_BITRATE_MODE
an
BITRATE_MODE_VBR
sodass der Encoder im Modus mit variabler Bitrate arbeitet,
Solange sie sich nicht auf die Mindestqualitätsstufe auswirken,
die codierte Bitrate :
- SOLLTE NICHT sein, mehr als eins gleitendes Fenster, mehr als 15% über der Bitrate zwischen Intraframe (I-Frame) Intervalle.
- SOLLTE NICHT mehr sein als 100% über der Bitrate über ein gleitendes Fenster von 1 Sekunde.
Wenn Geräteimplementierungen Video-Encoder unterstützen und für alle
Drittanbieter-Apps und legen Sie
MediaFormat.KEY_BITRATE_MODE
bis
BITRATE_MODE_CBR
sodass der Encoder im Modus mit konstanter Bitrate arbeitet, wird die codierte Bitrate verwendet:
- [C-SR-2] wird dringend empfohlen, NICHT mehr als 15% über der Zielbitrate bei einem gleitenden Fenster von 1 Sekunde liegen
Wenn Geräteimplementierungen ein eingebettetes Display mit der
mindestens 2,5 Zoll diagonal sein oder einen Videoausgangsanschluss oder
die Unterstützung einer Kamera über die android.hardware.camera.any
erklären
Funktions-Flag:
- [C-1-1] MÜSSEN die Unterstützung mindestens eines VP8- oder H.264-Videos beinhalten. und für Drittanbieteranwendungen zur Verfügung stellen.
- SOLLTEN sowohl VP8- als auch H.264-Videoencoder unterstützen und für Drittanbieter-Anwendungen.
Wenn Geräteimplementierungen H.264-, VP8-, VP9- oder HEVC-Videos unterstützen und sie für Anwendungen von Drittanbietern verfügbar machen, müssen sie:
- [C-2-1] MUSS dynamisch konfigurierbare Bitraten unterstützen.
- SOLLTE variable Frame-Rates unterstützen, wobei der Video-Encoder bestimmen sollte, sofortige Frame-Dauer basierend auf den Zeitstempeln der Eingabepuffer und Ordnen Sie seinen Bit-Bucket basierend auf dieser Frame-Dauer zu.
Wenn Geräteimplementierungen den Video-Encoder MPEG-4 SP unterstützen, Drittanbieter-Apps zur Verfügung, gilt Folgendes:
- SOLLTEN für den unterstützten Encoder dynamisch konfigurierbare Bitraten unterstützen.
Wenn Geräteimplementierungen hardwarebeschleunigte Video- oder Bild-Encoder bieten,
und eine oder mehrere angeschlossene oder steckbare Hardwarekameras unterstützen, die durch
den android.camera
-APIs:
- [C-4-1] Alle hardwarebeschleunigten Video- und Bild-Encoder MÜSSEN unterstützen. das Codieren von Frames der Hardwarekamera(s).
- SOLLTEN die Codierung von Frames der Hardwarekamera(s) in allen Videos unterstützen. oder Bildencoder nutzen.
Wenn Geräteimplementierungen eine HDR-Codierung ermöglichen, geschieht Folgendes:
- [C-SR-1] wird dringend empfohlen, ein Plug-in für die nahtlose Transcodierungs-API zur Konvertierung vom HDR- in das SDR-Format.
5.2.1 H.263
Wenn Geräteimplementierungen H.263-Encoder unterstützen und verfügbar machen Drittanbieter-Apps:
- [C-1-1] MUSS die QCIF-Auflösung unterstützen (176 x 144) mit Baseline-Profillevel 45. Die SQCIF-Auflösung ist optional.
5.2.2 H.264
Wenn Geräteimplementierungen den H.264-Codec unterstützen, gilt Folgendes:
- [C-1-1] MUSS Baseline-Profilebene 3 unterstützen. Die Unterstützung für ASO (Arbitrary Slice Ordering), FMO (Flexible Funktion) Macroblock Ordering) und RS (Redundante Slices) sind OPTIONAL. Außerdem können Sie mit anderen Android-Geräten kompatibel zu sein, wird EMPFOHLEN, Encoder verwenden keine ASO, FMO und RS für das Baseline-Profil.
- [C-1-2] MÜSSEN die SD-Videocodierungsprofile (Standard Definition) unterstützen in der folgenden Tabelle.
- SOLLTEN die Hauptprofilebene 4 unterstützen.
- SOLLTEN die Codierungsprofile für HD-Videos (High Definition) wie folgt unterstützen: wie in der folgenden Tabelle angegeben.
Wenn Geräteimplementierungen die Unterstützung der H.264-Codierung für 720p oder 1080p melden Medien-APIs die Auflösung von Videos zu verwenden,
- [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | |
---|---|---|---|---|
Videoauflösung | 320 x 240 px | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px |
Video-Framerate | 20 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps |
Video-Bitrate | 384 kbit/s | 2 Mbit/s | 4 Mbit/s | 10 Mbit/s |
5.2.3 VP8
Wenn Geräteimplementierungen den VP8-Codec unterstützen, gilt Folgendes:
- [C-1-1] MUSS die SD-Video-Codierungsprofile unterstützen.
- SOLLTEN die folgenden HD-Videocodierungsprofile (High Definition) unterstützen.
- [C-1-2] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
- SOLLTEN SIE einen Hardware-VP8-Codec bereitstellen, der die Codierungsanforderungen für RTC-Hardware von WebM-Projekten, um sicherzustellen, akzeptable Qualität der Dienste für Webvideostreaming und Videokonferenzen
Wenn Geräteimplementierungen die Unterstützung der VP8-Codierung für 720p oder 1080p melden Medien-APIs die Auflösung von Videos zu verwenden,
- [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | |
---|---|---|---|---|
Videoauflösung | 320 x 180 Pixel | 640 x 360 Pixel | 1280 x 720 px | 1920 x 1080 px |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps |
Video-Bitrate | 800 kbit/s | 2 Mbit/s | 4 Mbit/s | 10 Mbit/s |
5.2.4 VP9
Wenn Geräteimplementierungen den VP9-Codec unterstützen, gilt Folgendes:
- [C-1-2] MUSS Profil 0 Level 3 unterstützen.
- [C-1-1] MUSS das Schreiben von Matroska WebM-Dateien unterstützen.
- [C-1-3] MÜSSEN CodecPrivate-Daten generieren.
- SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
- [C-SR-1] wird dringend empfohlen, HD-Decodierungsprofile als in der folgenden Tabelle, wenn es einen Hardware-Encoder gibt.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Videoauflösung | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps |
Video-Bitrate | 1,6 Mbit/s | 4 Mbit/s | 5 Mbit/s | 20 Mbit/s |
Wenn Geräteimplementierungen Profil 2 oder Profil 3 über die Medien-APIs:
- Unterstützung für das 12-Bit-Format ist optional.
5.2.5 H.265
Wenn Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:
- [C-1-1] MUSS Hauptprofilebene 3 bis zu Auflösung: 512 x 512
- [C-SR-1] wird dringend empfohlen, 720 x 480-SD-Profil und das HD-Codierungsprofile wie in der folgenden Tabelle angegeben, wenn ein Hardware-Encoder.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Videoauflösung | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps |
Video-Bitrate | 1,6 Mbit/s | 4 Mbit/s | 5 Mbit/s | 20 Mbit/s |
5.2.6. AV1
Wenn Geräteimplementierungen den AV1-Codec unterstützen, geschieht Folgendes:
- [C-1-1] MUSS das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalte unterstützen.
[C-1-2] MÜSSEN Leistungsdaten veröffentlichen, d.h., die Leistungsdaten über das
getSupportedFrameRatesFor()
odergetSupportedPerformancePoints()
APIs für unterstützte Auflösungen finden Sie in der Tabelle unten.[C-1-3] MUSS HDR-Metadaten akzeptieren und im Bitstream ausgeben
Wenn der AV1-Encoder hardwarebeschleunigt ist, geschieht Folgendes:
- [C-2-1] MUSS bis einschließlich HD1080p-Codierungsprofil aus dem Tabelle unten:
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Videoauflösung | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps |
Video-Bitrate | 5 Mbit/s | 8 Mbit/s | 16 Mbit/s | 50 Mbit/s |
5.3. Videodecodierung
Wenn Geräteimplementierungen die Codecs VP8, VP9, H.264 oder H.265 unterstützen, gilt Folgendes:
- [C-1-1] MUSS die dynamische Videoauflösung und den Wechsel der Framerate unterstützen über die standardmäßigen Android-APIs im selben Stream für alle VP8-, VP9-, H.264- und H.265-Codecs in Echtzeit und bis zur maximal unterstützten Auflösung von jedem Codec auf dem Gerät.
5.3.1 MPEG-2
Wenn Geräteimplementierungen MPEG-2-Decodierer unterstützen, gilt Folgendes:
- [C-1-1] MUSS die allgemeine Ebene "Hauptprofil" unterstützen.
5.3.2 H.263
Wenn Geräteimplementierungen H.263-Decoder unterstützen, gilt Folgendes:
- [C-1-1] MUSS Baseline-Profilebene 30 unterstützen (CIF-, QCIF- und SQCIF-Auflösungen bei 30 fps, 384 kbit/s) und Level 45 (QCIF und SQCIF-Auflösungen bei 30 fps und 128 kbit/s).
5.3.3 MPEG-4
Bei Geräteimplementierungen mit MPEG-4-Decodierern gilt Folgendes:
- [C-1-1] MÜSSEN die einfache Profilebene 3 unterstützen.
5.3.4. H.264
Wenn Geräteimplementierungen H.264-Decoder unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die Hauptprofilebene 3.1 und das Basisprofil unterstützen. Support für ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (redundante Segmente) ist OPTIONAL.
- [C-1-2] MUSS Videos mit SD (Standardauflösung) decodieren können Profile, die in der folgenden Tabelle aufgeführt und mit dem Baseline-Profil codiert sind und Hauptprofilebene 3.1 (einschließlich 720p30).
- SOLLTEN in der Lage sein, Videos mit HD-Profilen (High Definition) zu decodieren. wie in der folgenden Tabelle angegeben.
Wenn die von der Methode Display.getSupportedModes()
gemeldete Höhe so lautet
gleich oder größer als die Videoauflösung ist, implementierten Geräte:
- [C-2-1] MUSS die HD-Videodecodierungsprofile mit 720p in den folgenden .
- [C-2-2] MÜSSEN die HD-1080p-Video-Decodierungsprofile in den folgenden .
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | |
---|---|---|---|---|
Videoauflösung | 320 x 240 px | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | 60 fps | 30 fps (60 fpsFernsehen) |
Video-Bitrate | 800 kbit/s | 2 Mbit/s | 8 Mbit/s | 20 Mbit/s |
5.3.5. H.265 (HEVC)
Wenn Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:
- [C-1-1] MUSS die Hauptstufe 3 des Hauptprofils und das SD-Video unterstützen. Decodierung von Profilen, wie in der folgenden Tabelle angegeben.
- SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
- [C-1-2] MUSS die HD-Decodierungsprofile wie unten angegeben unterstützen wenn es einen Hardwaredecoder gibt.
Wenn die von der Methode Display.getSupportedModes()
gemeldete Höhe so lautet
gleich oder größer als die Videoauflösung ist, dann:
- [C-2-1] Geräteimplementierungen MÜSSEN mindestens H.265 oder VP9 unterstützen. Decodierung von 720-, 1080- und UHD-Profilen.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Videoauflösung | 352 x 288 px | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | 30/60 fps (60 fpsFernsehen mit H.265-Hardware-Decodierung) | 60 fps |
Video-Bitrate | 600 Kbit/s | 1,6 Mbit/s | 4 Mbit/s | 5 Mbit/s | 20 Mbit/s |
Wenn Geräteimplementierungen angeblich ein HDR-Profil über die Medien unterstützen APIs:
- [C-3-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR-Metadaten von sowie das Extrahieren und Ausgeben der erforderlichen HDR-Inhalte Metadaten aus dem Bitstream und/oder Container.
- [C-3-2] Geräteimplementierungen MÜSSEN HDR-Inhalte auf der Gerätebildschirm oder an einem Standard-Videoausgabeanschluss (z.B. HDMI).
5.3.6. VP8
Wenn Geräteimplementierungen den VP8-Codec unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die SD-Decodierungsprofile in der folgenden Tabelle unterstützen.
- SOLLTEN SIE einen Hardware-VP8-Codec verwenden, der die Anforderungen erfüllen.
- SOLLTEN die HD-Decodierungsprofile in der folgenden Tabelle unterstützen.
Wenn die von der Display.getSupportedModes()
-Methode gemeldete Höhe gleich
oder größer als die Videoauflösung ist, dann:
- [C-2-1] Geräteimplementierungen MÜSSEN 720p-Profile im folgenden Tabelle.
- [C-2-2] Geräteimplementierungen MÜSSEN 1080p-Profile im folgenden Tabelle.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | |
---|---|---|---|---|
Videoauflösung | 320 x 180 Pixel | 640 x 360 Pixel | 1280 x 720 px | 1920 x 1080 px |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | 30 fps (60 fpsFernsehen) | 30 (60 fpsFernsehen) |
Video-Bitrate | 800 kbit/s | 2 Mbit/s | 8 Mbit/s | 20 Mbit/s |
5.3.7. VP9
Wenn Geräteimplementierungen den VP9-Codec unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN die SD-Video-Decodierungsprofile unterstützen, wie in den folgenden Tabelle.
- SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
Wenn Geräteimplementierungen den VP9-Codec und einen Hardwaredecoder unterstützen:
- [C-2-1] MUSS die HD-Decodierungsprofile wie unten angegeben unterstützen. .
Wenn die von der Methode Display.getSupportedModes()
gemeldete Höhe so lautet
gleich oder größer als die Videoauflösung ist, dann:
- [C-3-1] Geräteimplementierungen MÜSSEN mindestens entweder VP9 oder H.265 unterstützen. Decodierung der 720-, 1080- und UHD-Profile.
SD (niedrige Qualität) | SD (hohe Qualität) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Videoauflösung | 320 x 180 Pixel | 640 x 360 Pixel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | 30 fps (60 fpsFernsehen mit VP9-Hardware-Decodierung) | 60 fps |
Video-Bitrate | 600 Kbit/s | 1,6 Mbit/s | 4 Mbit/s | 5 Mbit/s | 20 Mbit/s |
Wenn Geräteimplementierungen VP9Profile2
oder VP9Profile3
unterstützen
über 'CodecProfileLevel'
Medien-APIs:
- Unterstützung für das 12-Bit-Format ist optional.
Wenn Geräteimplementierungen angeblich ein HDR-Profil unterstützen (VP9Profile2HDR
,
VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) über die
Medien-APIs:
- [C-4-1] Geräteimplementierungen MÜSSEN die erforderlichen HDR-Metadaten akzeptieren
KEY_HDR_STATIC_INFO
für alle HDR-Profile sowie 'KEY_HDR10_PLUS_INFO' für HDR10Plus-Profile) aus der Anwendung. Sie MÜSSEN auch unterstützen, das die erforderlichen HDR-Metadaten aus dem Bitstream und/oder dem Container. - [C-4-2] Geräteimplementierungen MÜSSEN HDR-Inhalte auf der Gerätebildschirm oder an einem Standard-Videoausgabeanschluss (z.B. HDMI).
5.3.8. Dolby Vision
Wenn Geräteimplementierungen die Unterstützung des Dolby Vision-Decoders durch
HDR_TYPE_DOLBY_VISION
,
Sie:
- [C-1-1] MÜSSEN einen Dolby Vision-fähigen Extraktor bereitstellen.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-2] MÜSSEN Dolby Vision-Inhalte korrekt angezeigt werden entweder auf dem Gerät auf einem externen Display über einen Standard-Videoausgabeport (z.B. HDMI).
Neue Anforderungen beenden
- [C-1-3] MUSS die Titel-ID festlegen. der abwärtskompatiblen Basisebenen (falls vorhanden) müssen mit der der Track-ID der Dolby Vision-Ebene kombiniert.
5.3.9. AV1
Wenn Geräteimplementierungen den AV1-Codec unterstützen und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:
- [C-1-1] MUSS das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalte unterstützen.
Wenn Geräteimplementierungen Unterstützung für den AV1-Codec mit einer Hardware bieten beschleunigt werden, geschieht Folgendes:
- [C-2-1] MÜSSEN in der Lage sein, mindestens HD-Videodecodierungsprofile mit 720p von
der Tabelle unten, wenn die von
Display.getSupportedModes()
gemeldete Höhe gleich oder größer als 720p ist. - [C-2-2] MÜSSEN in der Lage sein, mindestens HD-Videodecodierungsprofile mit 1080p zu decodieren
aus der Tabelle unten, wenn die von
Display.getSupportedModes()
gemeldete Höhe gleich oder größer als 1080p ist.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Videoauflösung | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 Pixel |
Video-Framerate | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps | Frame-Rate: 30 fps |
Video-Bitrate | 5 Mbit/s | 8 Mbit/s | 16 Mbit/s | 50 Mbit/s |
Wenn Geräteimplementierungen HDR-Profile über die Media APIs unterstützen, dann Sie:
- [C-3-1] MUSS die Extraktion und Ausgabe von HDR-Metadaten aus dem Bitstream und/oder Container.
- [C-3-2] HDR-Inhalte MUSS richtig auf dem Gerätebildschirm oder auf einem Standard-Videoausgangsport (z. B. HDMI)
5.4. Audioaufnahmen
Während einige der in diesem Abschnitt beschriebenen Anforderungen aufgelistet werden sollten, SOLLTEN Sie eine Kompatibilitätsdefinition für zukünftige Versionen um sie in MUSS zu ändern. Bestehende und neue Android-Geräte sind UNBEDINGT EMPFOHLEN, diese Anforderungen zu erfüllen, die als SOLLTEN aufgeführt sind, oder wird bei einem Upgrade auf die Zukunft nicht mehr mit Android kompatibel sein. Version.
5.4.1 Aufzeichnung von Rohdaten und Mikrofon
Wenn in Geräteimplementierungen android.hardware.microphone
deklariert wird, gilt Folgendes:
[C-1-1] MUSS die Aufnahme von Audio-Rohinhalten für beliebiger
AudioRecord
- 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 Aufnahme von Audiorohdaten in AM-Radio- und DVD-Qualität ermöglicht Inhalte:[C-2-1] MÜSSEN ohne Upsampling mit einem Verhältnis erfasst werden, das höher ist als 16000:22050 oder 44100:48000.
[C-2-2] MÜSSEN für Upsampling einen geeigneten Anti-Aliasing-Filter verwenden. oder Downsampling.
5.4.2 Für Spracherkennung aufnehmen
Wenn in Geräteimplementierungen android.hardware.microphone
deklariert wird, gilt Folgendes:
- [C-1-1] MÜSSEN erfassen
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
Audioquelle bei einer der Stichprobenraten 44.100 und 48.000. - [C-1-2] MÜSSEN standardmäßig die Audioverarbeitung zur Rauschunterdrückung deaktivieren, wenn
Sie nehmen einen Audiostream aus dem Audioteil „
AudioSource.VOICE_RECOGNITION
“ auf Quelle. [C-1-3] MÜSSEN standardmäßig die automatische Verstärkungsregelung bei der Aufnahme deaktivieren. Ein Audiostream von der Audioquelle „
AudioSource.VOICE_RECOGNITION
“.SOLLTE etwa flache Amplitude-gegen-Frequenz-Eigenschaften aufweisen. im mittleren Frequenzbereich: jeweils ±3 dB von 100 Hz bis 4.000 Hz sowie jedes Mikrofon, das für die Aufzeichnung der Spracherkennungs-Audioquelle verwendet wird.
Für [C-SR-1] wird dringend empfohlen, Amplitudenwerte im unteren Bereich Frequenzbereich: von ±20 dB von 30 Hz bis 100 Hz im Vergleich zu mittlerer Frequenzbereich für jedes einzelne Mikrofon, mit dem die Stimme aufgezeichnet wird Audioquelle mit Erkennungsfunktion.
Für [C-SR-2] wird dringend empfohlen, Amplitudenwerte im hohen Frequenzbereich: von ±30 dB von 4.000 Hz bis 22 kHz im Vergleich zu den mittleren Frequenzbereich für jedes einzelne Mikrofon, mit dem die Stimme aufgezeichnet wird Audioquelle mit Erkennungsfunktion.
SOLLTEN SIE die Empfindlichkeit der Audioeingabe so einstellen, dass eine sinusoidale Tonquelle von 1.000 Hz eingestellt wird. Wiedergabe bei 90 dB Schalldruckpegel (neben dem Mikrofon gemessen) eine ideale Reaktion von 2500 RMS im Bereich von 1770 bis 3530 für 16 Bit-Samples (oder -22,35 db ±3 dB Full Scale für Gleitkomma/doppelte Genauigkeit) Samples) für jedes Mikrofon, das für die Aufzeichnung der Spracherkennung verwendet wird, Audioquelle.
SOLLTEN den Audiostream der Spracherkennung so aufzeichnen, dass die PCM-Amplitude Pegel verfolgen Änderungen des Eingangs-SPL linear über mindestens einen 30-dB-Bereich von -18 dB bis +12 dB, 90 dB Schalldruckpegel am Mikrofon.
SOLLTEN den Audiostream der Spracherkennung mit dem gesamten Oberton aufzeichnen. Verzerrung (THD) von weniger als 1% für 1 kHz bei 90 dB SPL am Eingang Mikrofon.
Wenn in der Geräteimplementierung android.hardware.microphone
und Rauschen deklariert sind
zur Unterdrückung (Reduzierung) von Technologien, die auf Spracherkennung ausgelegt sind:
- [C-2-1] MUSS erlauben, dass dieser Audioeffekt mit der Funktion
android.media.audiofx.NoiseSuppressor
-API. - [C-2-2] MÜSSEN jede Technologie zur Rauschunterdrückung eindeutig identifizieren.
über das Feld
AudioEffect.Descriptor.uuid
implementieren.
5.4.3 Aufnahme für Umleitung der Wiedergabe
Die Klasse android.media.MediaRecorder.AudioSource
enthält das REMOTE_SUBMIX
Audioquelle.
Wenn in Geräteimplementierungen sowohl android.hardware.audio.output
als auch
android.hardware.microphone
:
[C-1-1] MÜSSEN die Audioquelle
REMOTE_SUBMIX
ordnungsgemäß implementieren, sodass wenn eine Anwendung 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 erklären. API-Methode AcousticEchoCanceler.isAvailable()
- [C-SR-2] sind STRONGLY_RECOMMENDED, damit dieser Audioeffekt verwendet werden kann steuerbar mit AcousticEchoCanceler der API erstellen.
- [C-SR-3] dienen zur eindeutigen Identifizierung jeder AEC-Technologie STRONGLY_RECOMMENDED. Implementierung über die Methode AudioEffect.Descriptor.uuid ein.
5.4.5. Gleichzeitige Aufnahme
Wenn in der Geräteimplementierung „android.hardware.microphone
“ deklariert ist,MÜSSEN sie MÜSSEN
die gleichzeitige Erfassung implementieren, wie in diesem Dokument beschrieben. Im Detail:
- [C-1-1] MUSS gleichzeitigen Zugriff auf das Mikrofon durch Bedienungshilfen erlauben.
Diensterfassung mit
AudioSource.VOICE_RECOGNITION
und mindestens einem Anwendungserfassung mitAudioSource
. - [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, Audio empfängt.
5.5. Audiowiedergabe
Unter Android können Apps auch Audio über Audio wiedergeben. Peripheriegerät gemäß Definition in Abschnitt 7.8.2.
5.5.1 Raw-Audiowiedergabe
Wenn in Geräteimplementierungen android.hardware.audio.output
deklariert wird, gilt Folgendes:
[C-1-1] MUSS die Wiedergabe von unbearbeiteten Audioinhalten mit den folgenden Eigenschaften:
- Quellformate: Lineare PCM, 16-Bit, 8-Bit, Gleitkommazahl
- Kanäle: Mono, Stereo, gültige Mehrkanalkonfigurationen mit bis zu 8 Kanälen
- Abtastraten (in Hz):
<ph type="x-smartling-placeholder">
- </ph>
- 8000, 11025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 auf dem Kanal oben aufgeführte Konfigurationen
- 96.000 in Mono und Stereo
5.5.2 Audioeffekte
Android bietet eine API für Audioeffekte. für Geräteimplementierungen.
Wenn in Geräteimplementierungen die Funktion android.hardware.audio.output
deklariert ist,
Sie:
- [C-1-1] MUSS die
EFFECT_TYPE_EQUALIZER
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.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-4] MUSS Audioeffekte unterstützen mit Gleitkomma-Eingabe und -Ausgabe, wenn der Effekt werden die Ergebnisse an die Framework-Audiopipeline zurückgegeben. Dies bezieht sich auf typische -Insert- oder AUX-Effekte wie dem Equalizer. Gleichwertiges Verhalten ist stark empfohlen, wenn die Effektergebnisse vom Framework-Audio nicht sichtbar sind (z. B. Nachbearbeitung oder ausgelagerte Effekte).
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-5] MÜSSEN sicherstellen, dass Audioeffekte mehrere Kanäle bis zu die Anzahl der Mixerkanäle, auch bekannt als FCC_LIMIT, wenn die Effektergebnisse an die Framework-Audiopipeline zurückgegeben werden. Dieses bezieht sich auf typische Insert- oder Aux-Effekte, schließt Spezialeffekte wie als Downmix-, Upmix- oder Verräumungseffekte, die die Kanalzahl verändern. Ein gleichwertiges Verhalten wird empfohlen, wenn die Auswirkungen nicht sichtbar sind. Framework-Audio-Pipeline (z. B. Nachverarbeitung oder Auslagerung Effekte).
Neue Anforderungen beenden
- SOLLTEN die
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
, Implementierungen 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
nach AudioAttributes
und die Nutzung von Auto-Audio, wie in
android.car.CarAudioManager
öffentlich definiert.
5.5.4 Audio-Offload
Wenn Geräteimplementierungen die Wiedergabe von Audioauslagerungen unterstützen, geschieht Folgendes:
- [C-SR-1] WIRD DRINGEND empfohlen, die Wiedergabe von Audioinhalten ohne Unterbrechung zu kürzen zwischen zwei Clips mit demselben Format, wenn dies durch den lückenlose AudioTrack API und den Media-Container für MediaPlayer.
5.6. Audiolatenz
Die Audiolatenz ist die Zeitverzögerung, wenn ein Audiosignal ein System durchläuft. Viele Klassen von Anwendungen nutzen kurze Latenzen, um Soundeffekte.
Verwenden Sie für die Zwecke dieses Abschnitts die folgenden Definitionen:
- Ausgabelatenz. Das Intervall zwischen dem Schreiben eines Frames durch eine Anwendung von PCM-codierten Daten und wenn der entsprechende Ton dem Umgebung an einem Transducer auf dem Gerät oder das Signal verlässt das Gerät über Port und können extern beobachtet werden.
- Latenz der kalten Ausgabe. Die Zeit zwischen dem Start eines Ausgabestreams und dem des ersten Frames basierend auf Zeitstempeln, wenn die Audioausgabe das System vor der Anfrage inaktiv war und heruntergefahren wurde.
- Kontinuierliche Ausgabelatenz: Die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät Audio wiedergibt.
- Eingabelatenz Das Intervall zwischen der Wiedergabe eines Tons die Umgebung zum Gerät über einen geräteinternen Transducer oder ein Signal und wenn eine Anwendung den entsprechenden Frame von PCM-codierten Daten liest.
- keine Eingabe mehr. Der erste Teil eines Eingabesignals, der nicht nutzbar oder nicht verfügbar.
- Kalteingabelatenz Die Zeit zwischen dem Start des Streams und dem Zeitpunkt, zu dem der wenn das Audioeingabesystem inaktiv war und der erste gültige Frame empfangen wird. vor der Anfrage heruntergefahren wurden.
- Kontinuierliche Eingabelatenz. Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufzeichnet.
- Kontinuierliche Umlauflatenz. Die Summe der kontinuierlichen Eingabelatenz plus die kontinuierliche Ausgabelatenz plus einen Pufferzeitraum. Der Pufferzeitraum ermöglicht es, Zeit, die die App zum Verarbeiten des Signals benötigt, und die Zeit, die die App zur Entschärfung benötigt. zwischen Eingabe- und Ausgabestreams.
- OpenSL ES PCM Buffer Queue API Die Gruppe der PCM-bezogenen OpenSL Spanien APIs in Android NDK
- Native Audio API von Audio. Die Gruppe der AAudio-APIs im Android NDK.
- Zeitstempel. Ein Paar, das aus einer relativen Frame-Position innerhalb eines -Stream und die geschätzte Zeit, zu der dieser Frame den Audioverarbeitungspipeline auf dem zugehörigen Endpunkt. Siehe auch AudioTimestamp:
- Fehler. Eine vorübergehende Unterbrechung oder ein falscher Samplewert im Audiosignal ist in der Regel auf buffer underrun für die Ausgabe, Pufferüberlauf für die Eingabe oder eine andere Quelle von digitalem oder analogem Rauschen.
- mittlere absolute Abweichung (MAD). Durchschnitt des absoluten Werts der Abweichungen vom Mittelwert für eine Reihe von Werten.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Die Tap-to-Tone-Latenz (TTL) wird von CTS Verifier gemessen und ist die Zeit, zwischen dem Antippen des Bildschirms und dem generierten Ton auf dem Lautsprecher zu hören ist. Dieser Wert wird über 5 Messungen gemittelt, wobei das AAudio native Audio API für die Ausgabe
Die Round-Trip-Latenz (RTL) ist der durchschnittliche Kontinuierliche Latenz über 5 Messungen, gemessen über einen Loopback-Pfad, der Feeds mithilfe der AAudio Native Audio API zurückgeben. Es gibt folgende Loopback-Pfade:
- Lautsprecher/Mikrofon: Integrierter Lautsprecher und integriertes Mikrofon.
- Analog: Analoger 3,5-mm-Anschluss und Loopback-Adapter.
- USB: USB-auf-3,5-mm-Adapter und Loopback-Adapter oder USB-Audioadapter Schnittstellen- und Loopback-Kabel verwenden.
FEATURE_AUDIO_PRO Die Funktion „
android.hardware.audio.pro
“ ist .MPC Media Performance-Klasse
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- Head-Tracking-Latenz. Die Zeit, zu der es bezieht sich auf die Kopfbewegung, die von der Trägheitsmaßeinheit (IMU) erfasst wurde zu den Kopfhöreraufnehmern der Geräuschänderung aufgrund von Bewegung.
Neue Anforderungen beenden
Wenn in der Geräteimplementierung android.hardware.audio.output
deklariert ist, wird
MÜSSEN die folgenden Anforderungen erfüllen oder übertreffen:
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-1] Der von
AudioTrack.getTimestamp
und
AAudioStream_getTimestamp
auf +/- 2 ms genau ist.
Neue Anforderungen beenden
[C-1-2] Kalte Ausgabelatenz von 500 Millisekunden oder weniger.
[C-1-3] Öffnen eines Ausgabestreams mit
AAudioStreamBuilder_openStream()
MÜSSEN weniger als 1.000 Millisekunden.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-4] Die berechneten Umlauflatenzen basierend auf Ein- und Ausgabe
Von
AAudioStream_getTimestamp
zurückgegebene Zeitstempel MÜSSEN innerhalb von 200 ms nach dem die gemessene Umlauflatenz fürAAUDIO_PERFORMANCE_MODE_NONE
undAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
für Lautsprecher, kabelgebunden und kabellos Headsets.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn in Geräteimplementierungen android.hardware.audio.output
deklariert wird, sind sie
EMPFOHLEN, die folgenden Anforderungen zu erfüllen oder zu übertreffen:
[C-SR-1] Kalte Ausgabelatenz von maximal 100 Millisekunden über den Lautsprecher Datenpfad.
[C-SR-2] Die Tonwahl-Latenz beträgt maximal 80 Millisekunden.
[C-SR-4] Die berechneten Umlauflatenzen auf der Grundlage von Ein- und Ausgabe Die von
AAudioStream_getTimestamp
zurückgegebenen Zeitstempel werden UNBEDINGT EMPFOHLEN maximal 30 Millisekunden von der gemessenen Umlauflatenz fürAAUDIO_PERFORMANCE_MODE_NONE
undAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
für Lautsprecher sowie kabelgebundene und kabellose Headsets.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Geräteimplementierungen die oben genannten Anforderungen erfüllen, können Sie Kalibrierung bei Verwendung der AAudio Native Audio API für eine kontinuierliche Ausgabe Latenz und Kaltausgabelatenz für mindestens ein unterstütztes Audio Ausgabegerät, sind sie:
- [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
.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Geräteimplementierungen die Anforderungen an Audio mit niedriger Latenz nicht erfüllen über die AAudio Native Audio API:
- [C-2-1] DÜRFEN KEINE Unterstützung für Audio mit niedriger Latenz melden.
Neue Anforderungen beenden
Wenn Geräteimplementierungen android.hardware.microphone
enthalten,
MÜSSEN die folgenden Anforderungen für die Audioeingabe erfüllen:
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-3-1] Begrenzen Sie den Fehler in Eingabezeitstempeln, wie von
AudioRecord.getTimestamp
oder
AAudioStream_getTimestamp
auf +/- 2 ms. „Fehler“ bedeutet hier die Abweichung vom richtigen Wert.
Neue Anforderungen beenden
- [C-3-2] Kalte Eingabe-Latenz von 500 Millisekunden oder weniger.
- [C-3-3] Ein Eingabestream mit
AAudioStreamBuilder_openStream()
öffnen MÜSSEN weniger als 1.000 Millisekunden.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Geräteimplementierungen android.hardware.microphone
enthalten, sind sie
EMPFOHLEN, die folgenden Anforderungen für die Audioeingabe zu erfüllen:
- [C-SR-8] Kalteingabelatenz von maximal 100 Millisekunden über dem Mikrofon Datenpfad.
- [C-SR-11] Begrenzen Sie den Fehler in Eingabezeitstempeln, wie von
AudioRecord.getTimestamp
oder
AAudioStream_getTimestamp
in +/- 1 ms.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn in der Geräteimplementierung android.hardware.audio.output
und
android.hardware.microphone
:
- [C-SR-12] WIRD UNBEDINGT EMPFOHLEN, eine durchschnittliche Umlauflatenz zu haben 50 Millisekunden oder weniger über 5 Messungen mit einer mittleren absoluten Abweichung weniger als 10 Millisekunden über mindestens einen unterstützten Pfad
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
In der folgenden Tabelle sind die Anforderungen für RTL-Dateien für Handheld-Geräte definiert.
Implementierungen gemäß 2.2.1, die
android.hardware.audio.output
und android.hardware.microphone
.
Gerät und Erklärungen | Linksläufig (ms) | MAD (ms) | Loopback-Pfade |
---|---|---|---|
Handkamera | 250 | 30 | Lautsprecher/Mikrofon, 3,5 mm analog (falls unterstützt), USB (falls unterstützt) |
>= MPC_T (14) | 80 | 15 | mindestens einen Pfad |
FUNKTION_AUDIO_NIEDRIGE_LATENZ | 50 | 10 | mindestens einen Pfad |
Audiopro-Funktion | 25 | 5 | mindestens einen Pfad |
Audiopro-Funktion | 20 | 5 | analog (falls unterstützt) |
Audiopro-Funktion | 25 | 5 | USB (wenn analoges Gerät nicht unterstützt wird) |
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
In der folgenden Tabelle sind die Anforderungen für die TTL auf einem Handheld-Gerät definiert.
Implementierungen gemäß 2.2.1, die
android.hardware.audio.output
und android.hardware.microphone
.
Gerät und Erklärungen | TTL (ms) |
---|---|
Handkamera | 250 |
>= MPC_T (14) | 80 |
MPC_S (13) | 100 |
Audiopro-Funktion | 80 |
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Geräteimplementierungen Unterstützung für
spatial audio
mit Erfassung von Kopfbewegungen
und deklarieren Sie PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY
melden sie:
- [C-4-1] MÜSSEN eine maximale Latenz von Head-Tracking zu Audio-Updates von 300 ms aufweisen.
Neue Anforderungen beenden
5.7. Netzwerkprotokolle
Geräteimplementierungen MÜSSEN unterstützen: Mediennetzwerkprotokolle für die Audio- und Videowiedergabe, wie in der Android SDK-Dokumentation angegeben.
Für jeden Codec und jedes Containerformat, für das eine Geräteimplementierung erforderlich ist, Support, die Geräteimplementierung:
[C-1-1] MUSS diesen Codec oder Container über HTTP und HTTPS unterstützen.
[C-1-2] MÜSSEN die entsprechenden Mediensegmentformate unterstützen, wie in der Tabelle „Mediensegmentformate“ Entwurfsprotokoll für HTTP-Livestreaming, Version 7
[C-1-3] MUSS die entsprechenden RTSP-Nutzlastformate unterstützen, wie in der RTSP-Tabelle unten. Ausnahmen finden Sie in den Fußnoten der Tabelle Abschnitt 5.1.
Formate für Mediensegmente
Segmentformate | Referenz(en) | Codec-Unterstützung erforderlich |
---|---|---|
MPEG-2-Transportstrom | ISO 13818 |
Video-Codecs:
<ph type="x-smartling-placeholder">
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
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-2] MÜSSEN
den durchgehenden Round-Trip-Ton haben. die Latenz, die Latenz Anforderungen fürFEATURE_AUDIO_PRO
gemäß Definition in Abschnitt 5.6 Audiolatenzvon 25 Millisekunden oder weniger über mindestens einem unterstützten Typ Pfad.
Neue Anforderungen beenden
- [C-1-3] MUSS einen oder mehrere USB-Ports haben, die den USB-Hostmodus und USB unterstützen. Peripheriemodus.
- [C-1-4] MÜSSEN die Unterstützung für Funktion
android.software.midi
melden.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-5] MUSS die Anforderungen erfüllen
Latenzen undUSB-Audio Anforderungen an die Latenz mithilfe der Natives Audio-Audio API undAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
.
Neue Anforderungen beenden
- [C-1-6] MUSS eine Latenz für die kalte Ausgabe von 200 Millisekunden oder weniger haben.
- [C-1-7] MÜSSEN eine Kalteingabelatenz von maximal 200 Millisekunden haben.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-8] MUSS eine durchschnittliche Tap-to-Ton-Latenz von 80 Millisekunden oder weniger haben über mindestens 5 Messungen über den Datenpfad zwischen Lautsprecher und Mikrofon.
- [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die im Abschnitt definierten Latenzen zu erfüllen 5.6 Audiolatenz von 20 Millisekunden oder weniger, über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden über den Weg vom Lautsprecher zum Mikrofon.
- [C-SR-2] wird dringend empfohlen, die Pro Audio-Anforderungen für Kontinuierliche Umlauf-Audiolatenz, Cold-Input-Latenz und Cold-Ausgabe Latenz- und USB-Audioanforderungen bei Verwendung der AAudio Native Audio API über den MMAP-Pfad.
[C-SR-3] WIRD UNBEDINGT EMPFOHLEN, ein konsistentes CPU-Level bereitzustellen bei aktivem Audio und schwankender CPU-Auslastung. Dies sollte getestet werden, mit der Android-App SynthMark. SynthMark nutzt einen Software-Synthesizer, der auf einem simulierten Audio-Framework ausgeführt wird. die die Systemleistung misst. Weitere Informationen finden Sie in der SynthMark-Dokumentation finden Sie eine Erläuterung der Benchmarks. SynthMark ausgeführt werden muss, „Automatisierter Test“ und folgende Ergebnisse erzielen:
- Stimmmarke.90 >= 32 Stimmen
- Latenzmark.Fixed.little <= 15 ms
- Latenzmark.dynamic.little <= 50 ms
SOLLTEN die Ungenauigkeit der Audiouhr und die Abweichung gegenüber der Standardzeit minimieren.
SOLLTEN die Abweichung des Audiotakts relativ zur CPU minimieren:
CLOCK_MONOTONIC
wenn beide aktiv sind.SOLLTEN die Audiolatenz über geräteinterne Transducer minimieren.
SOLLTEN die Audiolatenz im Vergleich zu digitalen USB-Audioquellen minimieren.
SOLLTEN die Messungen der Audiolatenz für alle Pfade dokumentieren.
SOLLTEN Sie den Jitter bei den Callback-Eingabezeiten für die Beendigung des Audiopuffers minimieren, da wirkt sich auf den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback aus.
SOLLTEN bei normaler Nutzung mit der gemeldeten Latenz keine Audiostörungen auftreten.
SOLLTEN keinen Unterschied bei der kanalübergreifenden Latenz haben.
SOLLTEN die durchschnittliche MIDI-Latenz für alle Transporte minimieren.
SOLLTEN die MIDI-Latenzvariabilität unter Last (Jitter) bei allen Transporten minimieren.
SOLLTEN für alle Transporte genaue MIDI-Zeitstempel angeben.
SOLLTEN Störungen des Audiosignals über geräteinterne Wandler, einschließlich der Periode direkt nach dem Kaltstart.
SOLLTE 0 Audiotaktdifferenz zwischen den Ein- und Ausgabeseiten des wenn beide aktiv sind. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher des Geräts oder der Audioanschluss und Ausgabe.
SOLLTE Callbacks für die Beendigung des Audiopuffers auf der Ein- und Ausgabeseite verarbeiten. der entsprechenden Endpunkte im selben Thread, wenn beide aktiv sind, und direkt nach der Rückgabe des Eingabe-Callbacks den Ausgabe-Callback. Oder Wenn die Callbacks nicht im selben Thread verarbeitet werden können, geben Sie den Parameter kurz nach der Eingabe des Eingabe-Callbacks übergeben, um den um ein einheitliches Timing der Ein- und Ausgabeseite zu gewährleisten.
SOLLTEN den Phasenunterschied zwischen der HAL-Audiozwischenspeicherung für die Eingabe minimieren. und Ausgabeseiten der entsprechenden Endpunkte.
SOLLTEN die Berührungslatenz minimieren.
SOLLTEN Sie die Schwankungen der Berührungslatenz unter Last (Jitter) minimieren.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Geräteimplementierungen alle oben genannten Anforderungen erfüllen, gilt Folgendes:
- [C-SR-4] WIRD DRINGEND empfohlen, die Unterstützung dieser Funktion zu melden
android.hardware.audio.pro
über dieandroid.content.pm.PackageManager
.
Neue Anforderungen beenden
Wenn Geräte eine 3,5-mm-Audiobuchse mit 4 Kabeln enthalten, ist Folgendes zu beachten:
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-2-1] MUSS eine durchschnittliche Continuous Round-Trip-Audiolatenz haben, wie in Abschnitt 5.6 Audiolatenz von 20 Millisekunden oder weniger, über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 5 Millisekunden im den Pfad der Audiobuchse mithilfe eines Audio-Loopback-Dongle.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-2-2]
[C-SR-5]Dringend empfohlenMÜSSEN Abschnitt entsprechen Technische Daten für das Mobilgerät (Anschluss) der Spezifikation für Kabel-Audio-Headsets (Version 1.1).
Neue Anforderungen beenden
Wenn Geräte keine 3,5-mm-Audiobuchse mit 4 Kabeln und keine verfügen über einen oder mehrere USB-Ports, die den USB-Hostmodus unterstützen. Sie:
- [C-3-1] MÜSSEN die USB-Audioklasse implementieren.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-3-2] MUSS eine durchschnittliche Continuous Round-Trip-Audiolatenz von 25 Millisekunden oder weniger, über 5 Messungen mit einer mittleren absoluten Abweichung weniger als 5 Millisekunden über den USB-Hostmodus-Port bei Verwendung der USB-Audioklasse (Dies kann mit einem USB-3,5-mm-Adapter und einem Audio-Loopback gemessen werden. oder eine USB-Audioschnittstelle mit Patchkabeln verwenden, Ein- und Ausgaben).
- [C-SR-6] WIRDEN DRINGEND empfohlen, die gleichzeitige E/A für bis zu 8 Kanäle zu unterstützen in jede Richtung, eine Abtastrate von 96 kHz und eine Tiefe von 24 Bit oder 32 Bit, wenn verwendet mit USB-Audio-Peripheriegeräten, die diese Anforderungen ebenfalls erfüllen.
- [C-SR-7] EMPFOHLEN, diese Gruppe von Anforderungen zu erfüllen, das native AAudio-Audio-API über den MMAP-Pfad.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Geräteimplementierungen einen HDMI-Port enthalten, ist Folgendes erforderlich:
- SOLLTEN die Ausgabe in Stereo und acht Kanäle mit 20-Bit oder 24-Bit-Tiefe und 192 kHz ohne Bittiefenverlust oder -resampling, in mindestens einer Konfiguration.
Neue Anforderungen beenden
5:11. Für unverarbeitet erfassen
Android bietet Unterstützung für die Aufzeichnung von unverarbeiteten Audioinhalten über die
android.media.MediaRecorder.AudioSource.UNPROCESSED
Audioquelle. In
OpenSL ES, kann über die Aufnahmevoreinstellung
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
Wenn die Geräteimplementierung eine unverarbeitete Audioquelle unterstützen soll, Drittanbieter-Apps zur Verfügung stehen,
[C-1-1] MÜSSEN den Support über
android.media.AudioManager
melden. Property PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] MÜSSEN annähernd flache Amplitude-gegen-Frequenz aufweisen. im mittleren Frequenzbereich, genauer gesagt ±10 dB von 100 Hz bis 7.000 Hz für jedes Mikrofon, das für die Aufzeichnung der unverarbeiteten Audioquelle.
[C-1-3] MUSS die Amplitudenwerte in der niedrigen Frequenz von ±20 dB von 5 z bis 100 Hz im Vergleich zu für jedes Mikrofon, das für die Aufnahme verwendet wird, unverarbeitete Audioquelle.
[C-1-4] MUSS Amplitudenpegel bei hoher Frequenz von ±30 dB von 7.000 Hz bis 22 kHz im Vergleich zum für jedes Mikrofon, das für die Aufnahme verwendet wird, unverarbeitete Audioquelle.
[C-1-5] MÜSSEN die Empfindlichkeit der Audioeingabe auf eine sinusoidale 1.000-Hz-Angabe einstellen. Tonquelle, die bei 94 dB Schalldruckpegel (SPL) wiedergegeben wird, ergibt eine Antwort mit RMS von 520 für 16-Bit-Samples (oder -36 dB Full Scale für Gleitkomma/Doppel) Precision-Samples) für jedes Mikrofon, das für die Aufzeichnung der nicht verarbeiteten Audioquelle.
[C-1-6] MUSS für jedes einzelne Mikrofon, das zur Aufzeichnung der unverarbeiteten Audioquelle verwendet wird. (der SNR-Wert wird als Differenz zwischen 94 dB Schalldruckpegel und Äquivalent gemessen. SPL des Selbstrauschens, A-gewichtet).
[C-1-7] MUSS eine insgesamte harmonische Verzerrung (THD) haben, die kleiner als sein darf als 1% für 1 kHz bei 90 dB Schalldruckpegel bei jedem Mikrofon, das für Folgendes verwendet wird: Aufzeichnung der unverarbeiteten Audioquelle.
[C-1-8] DÜRFEN keine andere Signalverarbeitung haben (z. B. Automatische Verstärkung). Steuerung, High-Pass-Filter oder Echo-Unterdrückung) im Pfad außer einem um das Level auf den gewünschten Bereich zu bringen. Mit anderen Worten:
- [C-1-9] Wenn in der Architektur eine Signalverarbeitung für deaktiviert werden und eine Verzögerung von null oder zusätzliche Latenz zum Signalpfad.
- [C-1-10] Der Levelmultiplikator darf zwar im Pfad enthalten sein, DARF aber NICHT oder Latenz im Signalpfad verursachen.
Alle Schallpegelmessungen erfolgen direkt neben dem zu testenden Mikrofon. Bei mehreren Mikrofonkonfigurationen gelten diese Anforderungen für Mikrofons verwenden.
Wenn in der Geräteimplementierung android.hardware.microphone
deklariert wird, aber nicht
unterstützen unverarbeitete Audioquellen:
- [C-2-1] MUSS
null
fü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 die Tonzuordnung für HDR zu SDR standardmäßig unterstützen hardwarebeschleunigter Decoder für das erfasste Profil. Mit anderen Worten: Wenn ein Gerät HDR10+ HEVC aufnehmen kann, MUSS der Standard-HEVC-Decoder in der Lage sein, um den aufgezeichneten Stream in SDR zu decodieren.
Anforderungen für die HDR-Bearbeitung
Wenn auf Geräten Videoencoder eingesetzt werden, die die HDR-Bearbeitung unterstützen, Sie:
- zum Generieren der HDR-Metadaten sollte die Latenz minimal sein, und SOLLTEN anmutig mit Situationen umgehen, in denen Metadaten für einige und nicht für andere. Diese Metadaten SOLLTEN präzise sein (z. B. stellen die tatsächliche Leuchtdichte von Spitzenwerten und das Histogramm des Frames dar.
Wenn die Geräteimplementierung Codecs umfasst, die FEATURE_HdrEditing
unterstützen, dann:
diese Codecs:
[C-7-1] MUSS mindestens ein HDR-Profil unterstützen.
[C-7-2] MUSS
FEATURE_HdrEditing
für alle HDR-Profile unterstützen, die von Codec angelangt. Mit anderen Worten, sie MÜSSEN die Erstellung von HDR-Metadaten unterstützen, wenn nicht für alle unterstützten HDR-Profile vorhanden, die HDR-Metadaten verwenden.[C-7-3] MUSS die folgenden Video-Encoder-Eingabeformate unterstützen, die das decodierte HDR-Signal beibehalten:
- RGBA_1010102 (bereits in der Zieltransferkurve) für beide Eingaben und ByteBuffer und MUSS die Unterstützung für COLOR_Format32BitABGR2101010.
Wenn die Geräteimplementierung Codecs enthält, die FEATURE_HdrEditing unterstützen, dann gilt: das Gerät:
- [C-7-4] MÜSSEN die Unterstützung für die Erweiterung EXT_YUV_target OpenGL anbieten.
6. Kompatibilität von Entwicklertools und -optionen
6.1 Entwicklertools
Geräteimplementierungen:
- [C-0-1] MUSS die Android-Entwicklertools unterstützen, die im SDK.
- Android Debug Bridge (ADB)
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-0-2] MÜSSEN ADB gemäß der Dokumentation im Android SDK und in der Shell unterstützen.
die im AOSP bereitgestellt werden und
die von App-Entwicklern verwendet werden können,
einschließlich
dumpsys
,cmd stats
und Simpleperf
Neue Anforderungen beenden
- [C-0-11] MUSS den Shell-Befehl
cmd testharness
unterstützen. Upgrade wird durchgeführt früheren Android-Versionen ohne eine persistente Datensperre KANN von C-0-11 ausgenommen werden. - [C-0-3] Dürfen das Format oder den Inhalt des Gerätesystems NICHT verändern -Ereignisse (batterystats, diskstats, fingerabdruck, grafikstats, netstats, Notification, procstats), die über den Befehl dumpsys protokolliert wurden.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-0-10] MÜSSEN die folgenden Ereignisse ohne Auslassung aufnehmen und durchführen.
und für den Shell-Befehl
cmd stats
und den System-API-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
- InputDeviceUsageReported
- JobStateChanged (Jobstatus geändert)
- Mit der Tastatur konfiguriert
- KeyboardSystemsEventReported
- PluggedStateChanged
- ScheduledJobStateGeändert
- Bildschirmstatus geändert
- Synchronisierungsstatus geändert
- SystemElapsedRealtime
- Touchpad-Nutzung
- UidProcessStateGeändert
- WakelockStateGeändert
- Wakeup-Alarm aufgetreten
- WifiLockStateGeändert
- WifiMulticastLockStateGeändert
- WifiScanStateGeändert
Neue Anforderungen beenden
- [C-0-4] MÜSSEN der geräteseitige ADB-Daemon standardmäßig inaktiv sein und Es muss einen für den Nutzer zugänglichen Mechanismus zum Aktivieren von Android Debug Brücke.
- [C-0-5] MUSS sicheres ADB unterstützen. Android unterstützt sichere ADB. „Secure adb“ aktiviert ADB auf bekannten authentifizierten Hosts.
- [C-0-6] MÜSSEN einen Mechanismus bereitstellen, der die Verbindung von adb über eine Hostcomputer. Im Detail:
Wenn Geräteimplementierungen ohne USB-Port den Peripheriemodus unterstützen, gilt Folgendes:
- [C-3-1] MÜSSEN ADB über ein lokales Netzwerk (z. B. Ethernet) implementieren. oder WLAN).
- [C-3-2] MÜSSEN Treiber für Windows 7, 8 und 10 bereitstellen, Entwicklern über das ADB-Protokoll eine Verbindung zum Gerät herzustellen.
Wenn Geräteimplementierungen ADB-Verbindungen zu einem Hostcomputer über WLAN oder Ethernet, verwenden sie Folgendes:
- [C-4-1] MUSS die Methode
AdbManager#isAdbWifiSupported()
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.
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 vompower/gpu_work_period
-Kernel 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 MUSS die API wie in der Android SDK-Dokumentation beschrieben.
Wenn eine API im SDK mit einer Hardwarekomponente interagiert, die als optional angegeben wird, und bei der Implementierung auf dem Gerät diese Komponente nicht vorhanden ist:
- [C-0-2] Vollständige Klassendefinitionen (wie im SDK dokumentiert) für die Komponente APIs MÜSSEN weiterhin angezeigt werden.
- [C-0-3] Das Verhalten der API MÜSSEN in angemessenen Mode.
- [C-0-4] API-Methoden MÜSSEN NULL-Werte zurückgeben, wenn dies laut SDK zulässig ist. Dokumentation.
- [C-0-5] API-Methoden MÜSSEN No-Op-Implementierungen von Klassen zurückgeben, bei denen Nullwerte vorliegen. sind laut SDK-Dokumentation nicht zulässig.
- [C-0-6] API-Methoden DÜRFEN KEINE Ausnahmen auslösen, die nicht im SDK dokumentiert sind Dokumentation.
- [C-0-7] Geräteimplementierungen MÜSSEN immer die korrekte Hardware melden
Konfigurationsinformationen über die
getSystemAvailableFeatures()
- 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 laufen gut auf einer Vielzahl von Hardware-Displays und -Konfigurationen. Eine Die Android-kompatible Anzeige ist ein Bildschirm, auf dem alle Android-Entwickler: Bildschirmkompatibilität Übersicht angezeigt wird, Abschnitt (7.1) und die zugehörigen Unterabschnitte sowie alle weiteren Gerätetypen, spezifischen Verhaltensweisen, die in Abschnitt 2 dieser CDD
Geräteimplementierungen:
- [C-0-1] MÜSSEN Anwendungen von Drittanbietern standardmäßig nur auf Mit Android kompatible Displays.
Die Einheiten, auf die in den Anforderungen in diesem Abschnitt verwiesen wird, sind wie folgt definiert:
- physische diagonale Größe. Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Teils des Displays.
- density definieren. Die Anzahl der von einer linearen Linie eingeschlossenen Pixel Horizontale oder vertikale Spanne von 1", ausgedrückt als Pixel pro Zoll (ppi oder dpi) Wenn ppi- und dpi-Werte aufgeführt sind, Die DPI sowohl horizontal als auch vertikal müssen im angegebenen Bereich liegen.
- Seitenverhältnis. Das Verhältnis der Pixel der längeren Seite zur kürzere Dimension des Bildschirms. Ein Display mit 480 x 854 Pixeln 854/480 = 1, 779 oder ungefähr "16:9".
- dichteunabhängige Pixel (dp): Eine virtuelle Pixeleinheit, normalisiert auf eine Bildschirmdichte von 160 Für eine gewisse Dichte d und die Anzahl der Pixel p, die Anzahl der dichteunabhängigen Pixel dp, Berechnung: dp = (160 ÷ d) × p.
7.1.1 Bildschirmkonfiguration
7.1.1.1 Displaygröße und -form
Das Android-UI-Framework unterstützt eine Vielzahl verschiedener logischer Bildschirmlayouts
Größen und ermöglicht Anwendungen, den Bildschirm der aktuellen Konfiguration abzufragen
Layoutgröße über Configuration.screenLayout
mit dem SCREENLAYOUT_SIZE_MASK
und Configuration.smallestScreenWidthDp
.
Geräteimplementierungen:
[C-0-1] MÜSSEN die richtige Layoutgröße für die
Configuration.screenLayout
gemäß der Definition in der Android SDK-Dokumentation. Insbesondere müssen Geräteimplementierungen die korrekten logischen Dichte-unabhängige Pixel-Bildschirmabmessungen (dp):- Geräte, bei denen
Configuration.uiMode
auf einen anderen Wert als UI_MODE_TYPE_WATCH abruft und 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 Bildschirme unterstützen, die
UI_MODE_TYPE_NORMAL
-Größenkonfiguration
und verwenden Sie physische Bildschirme
mit abgerundeten Ecken zum Rendern dieser Bildschirme,
Sie:
[C-1-1] MÜSSEN sicherstellen, dass mindestens eine der folgenden Anforderungen für jede Anzeige erfüllt ist:
- Der Radius der abgerundeten Ecken ist kleiner oder gleich 38 dp.
- Wenn ein Feld mit 18 dp mal 18 dp an jeder Ecke des logischen angezeigt wird, ist mindestens ein Pixel jedes Feldes auf dem Bildschirm sichtbar.
SOLLTEN Sie die Nutzerfreundlichkeit einbeziehen, um mit der von rechteckigen Ecken.
Wenn in Geräteimplementierungen nur die NO_KEYS
-Tastaturkonfiguration unterstützt wird,
und möchten die Unterstützung für den UI-Modus „UI_MODE_TYPE_NORMAL
“ melden
Konfiguration:
- [C-4-1] MUSS ein Layout von mindestens Mindestens 596 dp x 384 dp
Weitere Informationen zur korrekten Implementierung der Sidecar- oder Erweiterungs-APIs finden Sie unter der öffentlichen Dokumentation von Window Manager Jetpack.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Ob Geräteimplementierungen einen oder mehrere Android-kompatible Anzeigebereiche enthalten die faltbar sind oder ein faltbares Scharnier zwischen mehreren Android-kompatible Anzeigebereiche und stellen diese Anwendungen:
- [C-4-1] MÜSSEN die richtige Version der Fenstermanager-Erweiterungen implementieren. API-Ebene, wie unter WindowManager-Erweiterungen beschrieben.
Neue Anforderungen beenden
7.1.1.2 Bildschirmseitenverhältnis
Dieser Abschnitt wurde in Android 14 gelöscht.
7.1.1.3 Bildschirmdichte
Das Android-UI-Framework definiert eine Reihe von logischen Standarddichten, um Anwendungsentwickler zielen auf Anwendungsressourcen ab.
Geräteimplementierungen:
[C-0-1] MÜSSEN eine der aufgeführten Android-Framework-Dichten melden. am
DisplayMetrics
über dieDENSITY_DEVICE_STABLE
API Dieser Wert muss für jedes physische Display ein statischer Wert sein. Das Gerät KANN jedoch AnderesDisplayMetrics.density
melden entsprechend den vom Nutzer vorgenommenen Änderungen an der Anzeigekonfiguration (für (z. B. Anzeigegröße), die nach dem ersten Start festgelegt wird.SOLLTE die numerisch Standard-Android-Framework-Dichte definieren der physischen Dichte des Bildschirms am nächsten ist, oder einen Wert, der der Äquivalente des Sichtfelds von Handheld-Geräten.
Wenn Geräteimplementierungen die Anzeigegröße des Geräts ändern,
- [C-1-1] DÜRFEN den Bildschirm NICHT auf mehr als 1,5-fach skalieren
DENSITY_DEVICE_STABLE
oder eine Bildschirmgröße von unter 320 dp (entspricht an den Ressourcenqualifizierer sw320dp übergeben, je nachdem, was zuerst eintritt. - [C-1-2] DARF NICHT das Display skalieren
kleiner als das 0,85-Fache des
DENSITY_DEVICE_STABLE
ist. - Um eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen zu gewährleisten, wird EMPFOHLEN,
die folgende Skalierung der nativen Displayoptionen zur Verfügung steht (unter Einhaltung der Beschränkungen)
oben angegeben)
<ph type="x-smartling-placeholder">
- </ph>
- Klein: 0,85x
- Standardeinstellung: 1x (Skalierung für native Displayanzeige)
- Groß: 1,15x
- Größer: 1,3x
- Größte 1,45x
7.1.2 Messwerte anzeigen
Wenn Geräte die Android-kompatiblen Bildschirme oder auf die mit Android kompatiblen Bildschirmen übertragen:
- [C-1-1] MÜSSEN korrekte Werte für alle mit Android kompatiblen Displays gemeldet werden
die in den
android.util.DisplayMetrics
API
Wenn Geräteimplementierungen keinen eingebetteten Bildschirm oder keine Videoausgabe enthalten, Sie:
- [C-2-1] MÜSSEN die richtigen Werte des Android-kompatiblen Bildschirms melden
wie in der
android.util.DisplayMetrics
API definiert für den emulierten 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 Anwendungsanforderung für einen bestimmten Bildschirm respektieren. Ausrichtung.
- [C-1-2] DÜRFEN die gemeldete Bildschirmgröße oder -dichte beim Ändern der Ausrichtung NICHT ändern.
- Sie können als Standardeinstellung das Hoch- oder Querformat auswählen.
7.1.4 2D- und 3D-Grafikbeschleunigung
7.1.4.1 OpenGL ES
Geräteimplementierungen:
- [C-0-1] MÜSSEN die unterstützten OpenGL ES-Versionen (1.1, 2.0,
3.0, 3.1, 3.2) über die verwalteten APIs (z. B. über die
GLES10.getString()
) und die nativen APIs verwenden. - [C-0-2] MÜSSEN die Unterstützung für alle entsprechenden verwalteten APIs und native APIs für jede OpenGL ES-Version, die sie unterstützen möchten.
Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-1] MUSS
beideunterstützen OpenGL ES 1.1sowie2.0, 3.0 und 3.1, wie gesprochen und detailliert in der Android SDK-Dokumentation.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-SR-1] Wir empfehlen dringend, OpenGL ES 3.1 zu unterstützen.
Neue Anforderungen beenden
- SOLLTEN OpenGL ES 3.2 unterstützen.
Die OpenGL ES-dEQP-Tests sind in eine Reihe von Testlisten aufgeteilt, die jeweils eine
eine zugehörige Datums-/Versionsnummer. Diese befinden sich in der Android-Quellstruktur unter
external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt
Ein Gerät, das
OpenGL ES auf einem selbst angegebenen Level unterstützt, bedeutet, dass es den dEQP-Wert bestehen kann.
Tests in allen Testlisten dieser und früheren Stufen.
Wenn Geräteimplementierungen eine der OpenGL ES-Versionen unterstützen, gilt Folgendes:
- [C-2-1] MÜSSEN über die von OpenGL ES verwalteten APIs und nativen APIs andere von ihnen implementierte OpenGL ES-Erweiterungen, und MÜSSEN umgekehrt MÜSSEN, KEINE Erweiterungsstrings melden, die sie nicht unterstützen.
- [C-2-2] MUSS
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
EGL_ANDROID_recordable
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, eine plattformübergreifende API mit geringem Aufwand für leistungsstarke 3D-Grafiken.
Wenn Geräteimplementierungen OpenGL ES 3.1 unterstützen, gilt Folgendes:
- [C-SR-1] wird dringend empfohlen, Support für Vulkan 1.3.
- [C-4-1] DARF KEINE Vulkan-Variante (d.h. die Variante) unterstützen Teil der Vulkan-Kernversion MUSS Null sein).
Wenn Geräteimplementierungen eine Bildschirm- oder Videoausgabe beinhalten, gilt Folgendes:
- [C-SR-2] wird dringend empfohlen, Support für Vulkan 1.3.
Die Vulkan-dEQP-Tests sind in mehrere Testlisten aufgeteilt, die jeweils einen
das zugehörige Datum bzw. die zugehörige Version. Diese befinden sich in der Android-Quellstruktur unter
external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt
Ein Gerät, das
unterstützt Vulkan auf einer selbst angegebenen Ebene. Dies bedeutet, dass er den dEQP-Wert erreichen kann.
Tests in allen Testlisten dieser und früheren Stufen.
Wenn Geräteimplementierungen Vulkan-Unterstützung beinhalten, gilt Folgendes:
- [C-1-1] MÜSSEN den richtigen Ganzzahlwert mit dem
android.hardware.vulkan.level
undandroid.hardware.vulkan.version
Funktions-Flags. - [C-1-2] MUSS angeben, mindestens ein
VkPhysicalDevice
für den Vulkan die native APIvkEnumeratePhysicalDevices()
. - [C-1-3] MÜSSEN die Vulkan 1.1-APIs für jede der aufgeführten APIs vollständig implementieren.
VkPhysicalDevice
- [C-1-4] MÜSSEN Ebenen aufzählen, die in nativen Bibliotheken mit dem Namen
libVkLayer*.so
im nativen Bibliotheksverzeichnis des Anwendungspakets. über die nativen Vulkan-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
alstrue
oder die Metadatencom.android.graphics.injectLayers.enable
festgelegt auftrue
festgelegt. - [C-1-6] MÜSSEN alle Erweiterungs-Strings, die von ihnen unterstützt werden, über die Native Vulkan-APIs und umgekehrt DÜRFEN KEINE Erweiterungsstrings melden. die sie nicht richtig unterstützen.
- [C-1-7] MUSS VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, und VK_KHR_incremental_present.
- [C-1-8] MÜSSEN die Höchstversion der Vulkan dEQP-Tests melden
wird über das Funktions-Flag
android.software.vulkan.deqp.level
unterstützt. - [C-1-9] MUSS mindestens Version
132317953
(vom 1. März 2019) unterstützen als im Funktions-Flag „android.software.vulkan.deqp.level
“ aufgeführt. - [C-1-10] MÜSSEN alle Vulkan-dEQP-Tests in den Testlisten zwischen
Version
132317953
und die Version, die im Funktions-Flagandroid.software.vulkan.deqp.level
. - [C-1-11] DARF NICHT die Unterstützung für die VK_KHR_video_queue, die Erweiterungen VK_KHR_video_decode_queue oder VK_KHR_video_encode_queue.
- [C-SR-3] WIRD UNBEDINGT EMPFOHLEN,
VK_KHR_driver_properties
zu unterstützen undVK_GOOGLE_display_timing
Erweiterungen. - [C-1-12] DARF NICHT die Unterstützung für die Erweiterung „VK_KHR_performance_query“ aufzählen.
- [C-SR-4] EMPFOHLEN, die folgenden Anforderungen zu erfüllen, das Profil Android Baseline 2022.
- [C-SR-5] WIRD UNBEDINGT EMPFOHLEN,
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
zu unterstützen undVK_EXT_global_priority
. - [C-SR-6] wird dringend empfohlen,
SkiaVk
mit HWUI zu verwenden.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
Wenn Geräteimplementierungen Vulkan-Unterstützung beinhalten, gilt Folgendes:
- [C-SR-8] wird dringend empfohlen, den Vulkan-Loader nicht zu verändern.
- [C-1-14] DÜRFEN KEINE Vulkan-Geräteerweiterungen vom Typ „KHR“,
„GOOGLE“ oder „ANDROID“ es sei denn, diese Erweiterungen sind im
Funktions-Flag „
android.software.vulkan.deqp.level
“.
Neue Anforderungen beenden
Wenn Geräteimplementierungen Vulkan 1.0 nicht unterstützen, passiert Folgendes:
- [C-2-1] DÜRFEN KEINE Hinweise auf Vulkan-Features (z.B.
android.hardware.vulkan.level
,android.hardware.vulkan.version
). - [C-2-2] DARF KEINE
VkPhysicalDevice
für die native Vulkan-API aufzählenvkEnumeratePhysicalDevices()
.
Wenn Geräteimplementierungen Unterstützung für Vulkan 1.1 beinhalten und eines der Hier werden die hier beschriebenen Vulkan-Funktions-Flags beschrieben. Sie:
[C-3-1] MÜSSEN die Unterstützung für die externe Semaphore und den Handle
SYNC_FD
anzeigen und die ErweiterungVK_ANDROID_external_memory_android_hardware_buffer
.[C-SR-7] wird dringend empfohlen, die
VK_KHR_external_fence_fd
Erweiterung für Drittanbieter-Anwendungen und aktivieren die Anwendung um Zaunnutzlasten in eine POSIX-Datei zu exportieren und diese zu importieren Beschreibungen wie beschrieben finden Sie hier.
7.1.4.3 RenderScript
Geräteimplementierungen:
- [C-0-1] MUSS Android RenderScript unterstützen. wie in der Android SDK-Dokumentation beschrieben.
7.1.4.4 2D-Grafikbeschleunigung
Android bietet einen Mechanismus, mit dem Apps angeben können, dass sie die Hardwarebeschleunigung für 2D-Grafiken unter Fenster- oder Datenansichtsebene durch Verwendung eines Manifest-Tags android:hardwareAccelerated oder direkte API-Aufrufe.
Geräteimplementierungen:
- [C-0-1] MÜSSEN die Hardwarebeschleunigung standardmäßig aktivieren und Deaktivieren Sie die Hardwarebeschleunigung, wenn der Entwickler dies anfordert, indem Sie android:hardwareAccelerated="false" oder Deaktivieren der Hardwarebeschleunigung direkt über die Android View APIs.
- [C-0-2] MÜSSEN ein Verhalten zeigen, das mit dem Android SDK-Dokumentation zur Hardwarebeschleunigung
Android enthält ein TextureView-Objekt, mit dem Entwickler hardwarebeschleunigte OpenGL ES-Texturen als Renderingziele in einer UI-Hierarchie.
Geräteimplementierungen:
- [C-0-3] MÜSSEN die TextureView API unterstützen und angeben, einheitliches Verhalten bei der vorgelagerten Android-Implementierung.
7.1.4.5 Wide-Gamut-Displays
Wenn Geräteimplementierungen Unterstützung für Weitwinkel-Displays durch
Configuration.isScreenWideColorGamut()
, sie:
- [C-1-1] MUSS ein farbkalibriertes Display haben.
- [C-1-2] MÜSSEN über ein Display verfügen, dessen Farbumfang die sRGB-Farbgamut abdeckt. vollständig im CIE-1931-xyY-Bereich.
- [C-1-3] MÜSSEN über ein Display verfügen, dessen Umfang einen Bereich von mindestens 90% des DCI-P3 im CIE 1931-xyY-Bereich.
- [C-1-4] MUSS OpenGL ES 3.1 oder 3.2 unterstützen und ordnungsgemäß melden.
- [C-1-5] MÜSSEN Support für
EGL_KHR_no_config_context
bewerben,EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
,EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
EGL_EXT_gl_colorspace_display_p3
,EGL_EXT_gl_colorspace_display_p3_linear
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 bei dem das Framework in einem 'normal' [normal] Bildschirmgröße entspricht (320 dp Breite) zugunsten der alten Apps, die nicht für ältere Versionen von Android entwickelt wurden, unabhängig von Bildschirmgröße.
7.1.6 Bildschirmtechnologie
Die Android-Plattform umfasst APIs, mit denen komplexe Anwendungen auf ein Android-kompatibles Display übertragen. Geräte MÜSSEN alle diese Funktionen unterstützen APIs gemäß der Definition im Android SDK, sofern in diesem Dokument nicht ausdrücklich zulässig.
Alle mit Android kompatiblen Displays einer Geräteimplementierung:
- [C-0-1] MUSS 16-Bit-Farbgrafiken unterstützen können.
- SOLLTEN Bildschirme unterstützt werden, die 24-Bit-Farbgrafiken unterstützen.
- [C-0-2] MUSS Animationen rendern können.
- [C-0-3] MUSS ein Pixel-Seitenverhältnis (PAR) haben zwischen 0,9 und 1,15 liegt. Das Pixel-Seitenverhältnis MUSS also nahe quadratisch sein. (1,0) mit einer Toleranz von 10 bis 15 %.
7.1.7 Sekundäre Displays
Android unterstützt sekundäre, mit Android kompatible Displays, Funktionen zum Teilen von Medien und Entwickler-APIs für den Zugriff auf externe Bildschirme
Wenn Geräteimplementierungen einen externen Bildschirm unterstützen, entweder über ein kabelgebundenes oder drahtlos oder über eine eingebettete zusätzliche Displayverbindung verfügen, geschieht Folgendes:
- [C-1-1] MÜSSEN die
DisplayManager
Systemdienst und API, wie in der Android SDK-Dokumentation beschrieben.
7.2. Eingabegeräte
Geräteimplementierungen:
- [C-0-1] MUSS einen Eingabemechanismus wie eine Touchscreen oder Navigation ohne Touchscreen, um zwischen den UI-Elementen zu navigieren.
7.2.1 Tastatur
Wenn Geräteimplementierungen Drittanbieter-Unterstützung beinhalten IME-Anwendungen (Eingabemethoden-Editoren) müssen folgende Voraussetzungen erfüllen:
- [C-1-1] MUSS die
android.software.input_methods
deklarieren Funktions-Flag. - [C-1-2] MUSS
Input Management Framework
vollständig implementieren - [C-1-3] MUSS eine vorinstallierte Softwaretastatur haben.
Geräteimplementierungen:
- [C-0-1] DÜRFEN KEINE Hardwaretastatur enthalten, die nicht mit einer der Formate angegeben in android.content.res.Configuration.keyboard (QWERTY oder 12-Tasten).
- SOLLTEN zusätzliche Implementierungen von Softtastaturen beinhalten.
- KANN eine Hardware-Tastatur enthalten.
7.2.2 Berührungslose Navigation
Android unterstützt das Steuerkreuz, den Trackball und das Rad, berührungslose Navigation.
Geräteimplementierungen:
- [C-0-1] MÜSSEN den richtigen Wert für android.content.res.Configuration.navigation.
Wenn Geräteimplementierungen keine berührungslose Navigation haben, kann das folgende Gründe haben:
- [C-1-1] MÜSSEN eine vernünftige alternative Benutzeroberfläche für die Auswahl und Bearbeitung von Text, kompatibel mit Input Management Engines. Die vorgelagerte Open-Source-Implementierung von Android beinhaltet einen Auswahlmechanismus Geeignet für Geräte ohne berührungsempfindliche Navigationseingaben.
7.2.3 Navigationstasten
Die Startseite, Letzte und Zurück Funktionen, die in der Regel über eine Interaktion mit einer dedizierten physischen Taste bereitgestellt werden oder einen bestimmten Teil des Touchscreens für die Android-App Navigationsparadigma und damit auch Geräteimplementierungen:
- [C-0-1] MÜSSEN eine Nutzeroption zum Starten installierter Apps anbieten.
für die eine Aktivität mit dem
<intent-filter>
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 Apps verfügbar machen, wenn
targetSdkVersion
ist kleiner als 10, entweder durch eine physische Taste, einen Softwareschlüssel oder Gesten. Diese Menüfunktion sollte zugänglich sein, sofern sie nicht zusammen mit andere Navigationsfunktionen nutzen.
Wenn Geräte die Unterstützungsfunktion bieten, Sie:
- [C-4-1] MÜSSEN die Unterstützungsfunktion mit einer einzigen Aktion zugänglich machen. (z.B. Tippen, Doppelklick oder Touch-Geste), wenn andere Navigationstasten verfügbar sind.
- [C-SR-3] WIRD UNBEDINGT EMPFOHLEN, die Startbildschirm-Funktion lange zu drücken, da Interaktion.
Wenn Geräteimplementierungen einen bestimmten Teil des Bildschirms nutzen, um die Navigationstasten verwenden:
- [C-5-1] Die Navigationstasten MÜSSEN einen deutlichen Teil des Bildschirms einnehmen, für Anwendungen zur Verfügung stehen und DÜRFEN NICHT verdeckt oder auf sonstige Weise gestört werden Teil des Bildschirms, der Anwendungen zur Verfügung steht.
- [C-5-2] MÜSSEN einen Teil des Bildschirms für Anwendungen verfügbar machen, die die in Abschnitt 7.1.1 definierten Anforderungen erfüllt.
- [C-5-3] MÜSSEN die von der App über die
View.setSystemUiVisibility()
festgelegten Flags berücksichtigen sodass dieser bestimmte Teil des Bildschirms (auch bekannt als Navigationsleiste) ordnungsgemäß versteckt ist, wie in den des SDK.
Wenn die Navigationsfunktion als bewegungsbasierte Aktion auf dem Bildschirm bereitgestellt wird:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
MUSS nur verwendet werden, um den Bereich zur Gestenerkennung für das Zuhause zu melden. - [C-6-2] Gesten, die innerhalb eines Ausschlussrechtecks beginnen, wie vom
Anwendung im Vordergrund über
View#setSystemGestureExclusionRects()
, aber außerhalb 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 der Funktion „Letzte Apps“ als Wischen nach oben und Halten vor dem Loslassen dienen. wie bei der Touch-Geste für den Startbildschirm.
- Gesten, die innerhalb
WindowInsets#getMandatorySystemGestureInsets()
SOLLTEN NICHT von den vom Vordergrund bereitgestellten Ausschlusskriterien betroffen sein. Bewerbung ü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 als Wischen Sie vom linken und rechten Rand der aktuellen Ausrichtung des Bildschirm.
- [C-7-2] Wenn auf der linken oder linken Seite rechten Kanten, MÜSSEN sie im oberen Drittel des Bildschirms und mit ein klarer, dauerhafter visueller Hinweis, dass durch Ziehen bereits erwähnten Panels und folglich nicht „Zurück“. Ein Steuerfeld KÖNNEN wurde vom Nutzer so konfiguriert, dass er unter dem oberen Drittel des Bildschirms erscheint. Kanten, aber das Steuerfeld DÜRFEN NICHT länger als ein Drittel der Kanten verwenden.
- [C-7-3] Wenn die Vordergrund-App entweder View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT oder WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE Flags gesetzt, Wischen von den Rändern MUSS wie bei AOSP implementiert werden, die im SDK dokumentiert sind.
- [C-7-4] Wenn die Vordergrund-App entweder View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT oder WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE Flags gesetzt, Benutzerdefinierte wischbare Systembereiche MÜSSEN ausgeblendet werden, bis der Nutzer sie einbringt oder hebt die Helligkeit der Systemleisten (auch Navigations- und Statusleiste) auf, wie sie implementiert wurde. bei AOSP.
Wenn die Zurück-Navigationsfunktion verfügbar ist und die Nutzenden die Schaltfläche „Zurück“ und dann:
- [C-8-1]
OnBackInvokedCallback.onBackCancelled()
MUSS aufgerufen werden. - [C-8-2]
OnBackInvokedCallback.onBackInvoked()
DARF NICHT aufgerufen werden. - [C-8-3] Das KEYCODE_BACK-Ereignis DARF NICHT gesendet werden.
Wenn die Zurück-Navigationsfunktion vorhanden ist, die App im Vordergrund jedoch
KEINE OnBackInvokedCallback
registriert haben, dann:
- Das System SOLLTE eine Animation für die Anwendung im Vordergrund bereitstellen, die schlägt vor, dass der Nutzer wie in AOSP angegeben zurückkehrt.
Wenn Geräteimplementierungen die System-API setNavBarMode
unterstützen,
System-Apps mit der Berechtigung android.permission.STATUS_BAR
erlauben, die Einstellung
Navigationsleistenmodus aktiviert, geschieht Folgendes:
- [C-9-1] MÜSSEN Support für kinderfreundliche Symbole oder wie im AOSP-Code angegeben.
7.2.4 Touchscreeneingabe
Android unterstützt eine Vielzahl von Zeiger-Eingabesystemen, darunter Touchscreens, Touchpads und gefälschte Berührungseingabegeräte. Geräte mit Touchscreen implementieren die mit einer Anzeige verknüpft sind, sodass der Nutzer direkt den Eindruck Elemente auf dem Bildschirm zu manipulieren. Da die Nutzenden den Bildschirm direkt berühren, benötigt das System keine zusätzlichen Angebote, um die Objekte manipuliert werden.
Geräteimplementierungen:
- SOLLTEN ein Zeigereingabesystem haben (z. B. Maus- oder Touchbedienung).
- SOLLTEN vollständig unabhängig nachverfolgte Zeiger unterstützen.
Wenn Geräte einen Touchscreen (Single Touch oder besser) auf einem primären Android-kompatiblen Displays:
- [C-1-1] MÜSSEN
TOUCHSCREEN_FINGER
fü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 durch einmaliges Tippen auf einem primären mit Android kompatiblen Bildschirm:
- [C-2-1] MÜSSEN die entsprechenden Funktions-Flags
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
je nach Art des Touchscreens des Geräts.
Wenn Geräteimplementierungen auf ein externes Eingabegerät wie Maus oder Trackball (d.h. ohne direktes Berühren des Bildschirms) für die Eingabe auf einem primären Android-kompatiblen Bildschirm und erfüllen die gefälschten Anforderungen in Bezug auf die Touchbedienung in Abschnitt 7.2.5, sie:
- [C-3-1] DÜRFEN KEINE Funktions-Flags melden, die mit
android.hardware.touchscreen
- [C-3-2] MÜSSEN nur
android.hardware.faketouch
melden. - [C-3-3] MÜSSEN
TOUCHSCREEN_NOTOUCH
für 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 Statusänderung auf dem Zeiger nach unten oder oben auf dem Bildschirm.
- [C-1-3] MUSS den Zeiger nach unten und oben auf einem Objekt auf dem Bildschirm unterstützen, was ermöglicht Nutzern, das Tippen auf ein Objekt auf dem Bildschirm zu emulieren.
- [C-1-4] MÜSSEN Zeiger nach unten, nach oben, nach unten und dann nach oben unterstützen innerhalb einer Zeitgrenze an derselben Stelle auf einem Bildschirmelement platzieren, ermöglicht Nutzern, Doppeltippen zu emulieren auf ein Objekt auf dem Bildschirm.
- [C-1-5] MUSS den Mauszeiger auf einen beliebigen Punkt auf dem Bildschirm nach unten unterstützen, bewegen sich den Zeiger zu einer beliebigen anderen Stelle auf dem Bildschirm, gefolgt von einem Zeiger. nach oben, sodass Nutzende einen Touch-Ziehvorgang emulieren können.
- [C-1-6] MUSS den Zeiger nach unten unterstützen, damit Nutzer das Gerät schnell bewegen können. Objekt an eine andere Position auf dem Bildschirm verschieben und dann mit dem Mauszeiger nach oben zeigen, mit der Nutzende ein Objekt auf den Bildschirm werfen können.
Wenn Geräteimplementierungen Unterstützung für
android.hardware.faketouch.multitouch.distinct
, sie/er:
- [C-2-1] MÜSSEN die Unterstützung für
android.hardware.faketouch
erklären. - [C-2-2] MUSS das eindeutige Tracking von zwei oder mehr unabhängigen Zeigern unterstützen Eingaben.
Wenn Geräteimplementierungen Unterstützung für
android.hardware.faketouch.multitouch.jazzhand
, sie/er:
- [C-3-1] MÜSSEN die Unterstützung für
android.hardware.faketouch
erklären. - [C-3-2] MUSS eindeutiges Tracking von 5 (Zeichnen einer Hand mit Fingern) unterstützen oder mehr Zeigereingaben ganz unabhängig voneinander ausführen.
7.2.6 Unterstützung für Gamecontroller
7.2.6.1 Schaltflächenzuordnungen
Geräteimplementierungen:
- [C-1-1] MUSS HID-Ereignisse den entsprechenden
InputEvent
-Konstanten zuordnen können, wie in den folgenden Tabellen aufgeführt. Die vorgelagerte Android-Implementierung erfüllt diese Anforderung.
Wenn bei der Geräteimplementierung ein Controller eingebettet ist oder ein separater Controller beigefügt wird, damit alle in den folgenden Tabellen aufgeführten Ereignisse eingegeben werden können, gilt Folgendes:
- [C-2-1] MÜSSEN das Funktions-Flag
android.hardware.gamepad
deklarieren.
Schaltfläche | HID-Nutzung2 | Android-Taste |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_SCHALTFLÄCHE (96) |
B1 | 0x09 0x0002 | KEYCODE_SCHALTFLÄCHE (97) |
X1 | 0x09 0x0004 | KEYCODE_button_X (99) |
J1 | 0x09 0x0005 | KEYCODE_SCHALTFLÄCHE (100) |
Steuerkreuz oben1 Steuerkreuz unten1 |
0x01 0x00393 | AXIS_HAT_Y4 |
Steuerkreuz links1 Steuerkreuz rechts1 |
0x01 0x00393 | AXIS_HAT_X4 |
Taste auf der linken Schulter1 | 0x09 0x0007 | KEYCODE_button_L1 (102) |
Rechte Schultertaste1 | 0x09 0x0008 | KEYCODE_button_R1 (103) |
Mit linker Maustaste klicken1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
Mit der rechten Maustaste klicken1 | 0x09 0x000F | KEYCODE_button_THUMBR (107) |
Zurück1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
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 | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
7.2.7 Fernbedienung
Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.3.1.
7.3. Sensoren
Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer 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 ihrer Der Stromverbrauch MUSS immer unter 4 mW liegen.
- SOLLTEN jeweils unter 2 mW bzw.0,5 mW liegen, wenn das Gerät in einem dynamischen oder statische Bedingung verwendet wird.
Wenn die Geräte einen 3-Achsen-Beschleunigungsmesser und einen 3-Achsen-Gyroskopsensor umfassen, Sie:
- [C-5-1] MUSS
TYPE_GRAVITY
undTYPE_LINEAR_ACCELERATION
implementieren zusammengesetzten Sensoren. - [C-SR-7] wird dringend empfohlen,
TYPE_GAME_ROTATION_VECTOR
-Komposit-Sensor.
Wenn die Geräte einen 3-Achsen-Beschleunigungsmesser, einen 3-Achsen-Gyroskopsensor, und einem Magnetometer-Sensor:
- [C-6-1] MÜSSEN einen
TYPE_ROTATION_VECTOR
-Sensoren implementieren.
7.3.2 Magnetometer
Geräteimplementierungen:
- [C-SR-1] Wir empfehlen dringend, einen dreiachsigen Magnetometer (Kompass) mitzunehmen.
Wenn Geräteimplementierungen ein 3-Achsen-Magnetometer umfassen, gilt Folgendes:
- [C-1-1] MÜSSEN den
TYPE_MAGNETIC_FIELD
-Sensor implementieren. - [C-1-2] MÜSSEN in der Lage sein, Ereignisse bis zu einer Frequenz von mindestens 10 Hz zu melden. und SOLLTEN Ereignisse mit bis zu 50 Hz melden.
- [C-1-3] MUSS den Anforderungen des Android-Sensorkoordinatensystems entsprechen wie in den Android-APIs
- [C-1-4] MUSS jeweils zwischen -900 μT und +900 μT messen können vor der Sättigung.
- [C-1-5] MUSS einen Offset-Wert des harten Eisens unter 700 μT haben und eine einen Wert unter 200 μT, indem Sie das Magnetometer in großer Entfernung dynamische (strominduzierte) und statische (magnetinduzierte) Magnetfelder.
- [C-1-6] MUSS eine Auflösung von mindestens 0,6 μT haben.
- [C-1-7] MUSS die Online-Kalibrierung und -Kompensation des harten Eisens unterstützen. und die Kompensationsparameter zwischen Geräteneustarts beizubehalten.
- [C-1-8] MUSS die Kompensation für weiches Eisen angewendet werden – die Kalibrierung kann während der Verwendung oder während der Produktion des Geräts durchgeführt wird.
- [C-1-9] MUSS eine Standardabweichung haben, berechnet pro Achse von Stichproben, die bei der schnellsten Stichprobenerhebung in einem Zeitraum von mindestens 3 Sekunden erfasst wurden Rate, nicht größer als 1,5 μT; SOLLTE eine Standardabweichung von maximal 0,5 μT.
- [C-1-10] MÜSSEN die
TYPE_MAGNETIC_FIELD_UNCALIBRATED
Sensor.
Wenn die Geräte ein 3-Achsen-Magnetometer oder einen Beschleunigungsmesser umfassen und einem 3-Achsen-Gyroskopsensor:
- [C-2-1] MÜSSEN einen
TYPE_ROTATION_VECTOR
-Sensoren implementieren.
Wenn Geräteimplementierungen ein dreiachsiges Magnetometer oder einen Beschleunigungsmesser enthalten, ist Folgendes zu beachten:
- KANN den
TYPE_GEOMAGNETIC_ROTATION_VECTOR
-Sensor implementieren.
Wenn Geräte ein 3-Achsen-Magnetometer, einen Beschleunigungsmesser und
TYPE_GEOMAGNETIC_ROTATION_VECTOR
-Sensor wird Folgendes ausgeführt:
- [C-3-1] MUSS weniger als 10 mW verbrauchen.
- SOLLTE weniger als 3 mW verbrauchen, wenn der Sensor für den Batchmodus registriert ist bei 10 Hz.
7.3.3 GPS
Geräteimplementierungen:
- [C-SR-1] wird dringend empfohlen, einen GPS-/GNSS-Empfänger mitzunehmen.
Wenn Geräte einen GPS-/GNSS-Empfänger umfassen und die Funktion melden
über das Funktions-Flag android.hardware.location.gps
an Anwendungen übergeben, geschieht Folgendes:
- [C-1-1] MUSS die Standortausgaben mit einer Frequenz von mindestens 1 Hz unterstützen, wenn
über
LocationManager#requestLocationUpdate
angefordert. - [C-1-2] MÜSSEN in der Lage sein, den Ort unter freiem Himmel zu bestimmen.
(starke Signale, vernachlässigbarer Multipath, HDOP < 2) innerhalb von 10 Sekunden (schnell
Zeit bis zur ersten Fehlerbehebung), bei einer Geschwindigkeit von mindestens 0,5 Mbit/s
eine Internetverbindung. Diese Anforderung wird in der Regel durch die Verwendung einiger
Form der unterstützten oder vorhergesagten GPS-/GNSS-Technik
um die GPS-/GNSS-Verriegelungszeit zu minimieren (Unterstützungsdaten umfassen Referenzzeit,
Referenzstandort und Satelliten-Ephemeris/Uhr).
- [C-1-6] Nach der Berechnung des Standorts wird das Gerät Implementierungen MÜSSEN seinen Standort unter freiem Himmel innerhalb 5 Sekunden, wenn Standortanfragen neu gestartet werden, bis zu eine Stunde danach Berechnung des Standorts, auch wenn die nachfolgende Anfrage ohne Datenverbindung und/oder nach dem Ein- und Ausschalten.
Bei freiem Himmel, nachdem der Standort ermittelt wurde, bei stehendem oder bei Bewegung mit weniger als 1 Meter pro Sekunde zum Quadrat der Beschleunigung:
- [C-1-3] MÜSSEN den Standort innerhalb von 20 Metern und die Geschwindigkeit ermitteln können. mit einer Geschwindigkeit von mindestens 0, 5 Metern pro Sekunde.
- [C-1-4] MÜSSEN gleichzeitig über
GnssStatus.Callback
mindestens 8 Satelliten aus einer Konstellation. - SOLLTEN in der Lage sein, gleichzeitig mindestens 24 Satelliten von mehrere Sternbilder (z.B. GPS und mindestens eines der Sternbilder Glonass, Beidou, Galileo.
[C-SR-2] WIRD UNBEDINGT EMPFOHLEN, weiterhin normales GPS/GNSS bereitzustellen Standortausgaben über GNSS Location Provider APIs während eines Notrufs aufrufen.
[C-SR-3] Es wird dringend empfohlen, GNSS-Messungen von allen Nutzern zu melden. Erfasste Panoramengruppen (wie in GnssStatus-Nachrichten angegeben), mit Ausnahme von SBAS.
[C-SR-4] DRINGEND empfohlen, AGC und die Häufigkeit von GNSS zu melden zu messen.
[C-SR-5] Es wird dringend empfohlen, alle Genauigkeitsschätzungen anzugeben. (einschließlich Peilung, Geschwindigkeit und vertikaler Ausrichtung) als Teil jedes GPS-/GNSS-Standorts angegeben werden.
[C-SR-6] GNSS-Messungen werden dringend empfohlen, sobald gefunden werden, auch wenn ein über GPS/GNSS berechneter Standort noch nicht gemeldet.
[C-SR-7] wird dringend empfohlen, GNSS-Pseudobereiche und Pseudorangeraten, die bei freiem Himmel nach der Bestimmung des Standorts sich nicht bewegen, mit weniger als 0,2 Metern pro Sekunde zum Quadrat beschleunigen, reichen aus, um die Position innerhalb von 20 Metern zu berechnen, und die Geschwindigkeit. in mindestens 95% der Fälle mit einer Geschwindigkeit von 0, 2 Metern pro Sekunde.
7.3.4 Gyroskop
Geräteimplementierungen:
- [C-SR-1] wird dringend empfohlen, einen Gyroskopsensor zu verwenden.
Wenn Geräteimplementierungen ein Gyroskop umfassen, gilt Folgendes:
- [C-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 50 Hz melden können.
- [C-1-4] MUSS eine Auflösung von mindestens 12 Bit haben.
- [C-1-5] MUSS temperaturkompensiert werden.
- [C-1-6] MÜSSEN bei der Verwendung kalibriert und kompensiert werden und den zwischen Geräteneustarts kompensieren.
- [C-1-7] MUSS eine Varianz von nicht größer als 1e–7 rad^2 / s^2 pro Hz haben (Abweichung pro Hz oder Rad^2 / s). Die Varianz darf mit dem Stichprobenrate, MUSS aber durch diesen Wert eingeschränkt werden. Mit anderen Worten, wenn Sie Die Varianz des Gyroskops mit einer Abtastrate von 1 Hz messen. Sie SOLLTE nicht höher sein. als 1e–7 rad^2/s^2.
- [C-SR-2] Ein Kalibrierungsfehler unter 0,01 rad/s wird dringend empfohlen wenn das Gerät bei Raumtemperatur steht.
- [C-SR-3] Eine Auflösung von mindestens 16 Bit wird dringend empfohlen.
- SOLLTE Ereignisse mit bis zu 200 Hz melden.
Wenn Geräteimplementierungen ein 3-Achsen-Gyroskop umfassen, ist Folgendes erforderlich:
- [C-2-1] MÜSSEN den
TYPE_GYROSCOPE
-Sensor implementieren. - [C-SR-4] Wir empfehlen dringend,
TYPE_GYROSCOPE_UNCALIBRATED
zu implementieren Sensor.
Wenn Geräteimplementierungen ein Gyroskop mit weniger als 3 Achsen enthalten, ist Folgendes zu beachten:
- [C-3-1] MÜSSEN den
TYPE_GYROSCOPE_LIMITED_AXES
-Sensor implementieren und melden. - [C-SR-5] Implementierung und Berichterstattung STRONGLY_RECOMMENDED
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
-Sensor.
Wenn die Geräte ein 3-Achsen-Gyroskop, einen Beschleunigungsmessersensor enthalten und einem Magnetometer-Sensor:
- [C-4-1] MÜSSEN einen
TYPE_ROTATION_VECTOR
-Sensoren implementieren.
Wenn die Geräte einen 3-Achsen-Beschleunigungsmesser und ein 3-Achsen-Gyroskop umfassen Sensor verwenden sie:
- [C-5-1] MUSS
TYPE_GRAVITY
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ärprogramm "in der Nähe" oder "weit" lesen:
- [C-1-1] MÜSSEN die Nähe eines Objekts in derselben Richtung wie die des Bildschirm. Das heißt, der Näherungssensor MUSS darauf ausgerichtet sein, Objekte zu erkennen. Bildschirm zu platzieren, da dieser Sensortyp ein Telefon erkennen, das der Nutzer verwendet. Wenn Geräteimplementierungen ein Näherungssensors mit einer anderen Ausrichtung verwenden, DARF ER NICHT zugänglich sein. über diese API.
- [C-1-2] MUSS mindestens eine Genauigkeit von 1 Bit haben.
- [C-1-3] MÜSSEN 0 Zentimeter als Näherungswert und 5 Zentimeter als der weiterlesen.
- [C-1-4] MÜSSEN einen Höchstwert und eine Auflösung von 5 angeben.
7.3.9 Hochwertige Sensoren
Wenn Geräteimplementierungen eine Reihe hochwertigerer Sensoren umfassen, wie definiert, und für Drittanbieter-Apps zur Verfügung stellen, geschieht Folgendes:
- [C-1-1] MUSS die Fähigkeit über das
Funktions-Flag „
android.hardware.sensor.hifi_sensors
“.
Wenn in der Geräteimplementierung android.hardware.sensor.hifi_sensors
deklariert ist,
Sie:
[C-2-1] MUSS einen
TYPE_ACCELEROMETER
-Sensor haben, der:- MUSS einen Messbereich zwischen -8 g und +8 g haben und EMPFOHLENE Messbereiche von mindestens -16 g und +16 g.
- MÜSSEN eine Auflösung von mindestens 2.048 LSB/g haben.
- MUSS eine Mindest-Messfrequenz von 12,5 Hz oder weniger haben.
- MUSS eine maximale Messfrequenz von 400 Hz oder höher haben. SOLLTEN
SensorDirectChannel
RATE_VERY_FAST
unterstützt. - MUSS ein Messrauschen nicht über 400 μg/√Hz haben.
- MÜSSEN bei diesem Sensor eine Nicht-Aktivierungsform mit Pufferung implementiert werden. mindestens 3.000 Sensorereignisse.
- MUSS einen Batch-Stromverbrauch haben, der nicht unter 3 mW liegt.
- [C-SR-1] Es wird dringend empfohlen, eine 3-dB-Messbandbreite von bei mindestens 80% der Nyquist-Frequenz und Bandbreite.
- SOLLTEN bei zufälliger Beschleunigung von weniger als 30 μg √Hz bei die Raumtemperatur haben.
- SOLLTE eine Verzerrungsänderung gegenüber der Temperatur von ≤ +/- 1 mg/°C auftreten.
- SOLLTEN eine optimale Linien-Nichtlinearität von ≤ 0,5 % und Empfindlichkeitsänderung gegenüber Temperatur ≤ 0,03%/C°.
- SOLLTEN die Querachsenempfindlichkeit < 2,5 % und Variation von Querachsenempfindlichkeit < 0,2% im Betriebstemperaturbereich des Geräts.
[C-2-2] MUSS eine
TYPE_ACCELEROMETER_UNCALIBRATED
mit demselben Qualitätsanforderungen 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 mehr als 0,5 mW haben, wenn das Gerät statisch und 1,5 mW in Bewegung.
[C-2-10] MUSS einen
TYPE_STEP_DETECTOR
-Sensor haben, der:- MÜSSEN bei diesem Sensor eine Nicht-Aktivierungsform mit Pufferung implementiert werden. mindestens 100 Sensorereignisse.
- MUSS einen Stromverbrauch von nicht mehr als 0,5 mW haben, wenn das Gerät statisch und 1,5 mW in Bewegung.
- MUSS einen Batch-Stromverbrauch haben, der nicht unter 4 mW liegt.
[C-2-11] MUSS einen
TYPE_STEP_COUNTER
-Sensor haben, der:- MUSS einen Stromverbrauch von nicht mehr als 0,5 mW haben, wenn das Gerät statisch und 1,5 mW in Bewegung.
[C-2-12] MUSS einen
TILT_DETECTOR
-Sensor haben, der:- MUSS einen Stromverbrauch von nicht mehr als 0,5 mW haben, wenn das Gerät statisch und 1,5 mW in Bewegung.
[C-2-13] Der Ereigniszeitstempel desselben physischen Ereignisses, der vom Beschleunigungsmesser, Gyroskop und Magnetometer MÜSSEN innerhalb von 2, 5 Millisekunden liegen. voneinander zu lernen. Ereigniszeitstempel desselben physischen Ereignisses, gemeldet von Beschleunigungsmesser und Gyroskop sollten in einem Umkreis von 0,25 Millisekunden Sonstiges.
[C-2-14] MUSS die Ereigniszeitstempel des Gyroskopsensors gleichzeitig verwenden. als Kamera-Subsystem und innerhalb von 1 Millisekunde Fehler.
[C-2-15] MÜSSEN Muster innerhalb von 5 Millisekunden nach Die Zeit, zu der die Daten über einen der oben genannten physischen Sensoren verfügbar sind an die Anwendung gesendet.
[C-2-16] DÜRFEN KEINEN Stromverbrauch über 0,5 mW haben. bei statischem Gerät und 2,0 mW in Bewegung wenn eine Kombination der folgenden Sensoren aktiviert ist:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] KANN einen
TYPE_PROXIMITY
-Sensor haben, aber wenn vorhanden MUSS eine Mindestpufferkapazität von 100 Sensorereignissen.
Beachten Sie, dass bei den Anforderungen an den Stromverbrauch in diesem Abschnitt nicht die Stromverbrauch des Anwendungsprozessors. Es beinhaltet auch die Macht, Sensorkette, d. h. alle unterstützenden Schaltkreise, spezielles Sensorverarbeitungssystem usw.
Wenn Geräte eine direkte Sensorunterstützung bieten, gilt Folgendes:
- [C-3-1] MÜSSEN die Unterstützung von direkten und direkten Kanaltypen korrekt deklariert werden.
Preisebene über die
isDirectChannelTypeSupported
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:
<ph type="x-smartling-placeholder">
- </ph>
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10 Biometrische Sensoren
Weitere Informationen zum Messen der Sicherheit biometrischer Entsperrung finden Sie unter Dokumentation zum Messen der biometrischen Sicherheit
Wenn Geräteimplementierungen einen sicheren Sperrbildschirm beinhalten, gilt Folgendes:
- SOLLTE einen biometrischen Sensor enthalten
Biometrische Sensoren können der Klasse 3 (früher Stark) zugeordnet werden, Klasse 2 (früher Weak) oder Klasse 1 (früher Convenience) der Akzeptanzraten von Parodien und Irrtümern sowie der Sicherheit der biometrische Pipeline. Diese Klassifizierung bestimmt die Funktionen, Der biometrische Sensor muss mit der Plattform und dem Drittanbieter verbunden sein. Anwendungen. Die Sensoren müssen die unten aufgeführten zusätzlichen Anforderungen erfüllen, wenn möchten, dass sie in Klasse 1, Klasse 2 oder Klasse 3 klassifiziert werden. Sowohl die Klasse 2 als auch die Klasse 3 haben zusätzliche Funktionen, (siehe unten).
Wenn Geräteimplementierungen einen biometrischen Sensor für Drittanbieter zur Verfügung stellen android.hardware.biometrics.BiometricManager android.hardware.biometrics.BiometricPrompt und android.provider.Settings.ACTION_BIOMETRIC_ENROLL, Sie:
- [C-4-1] MUSS die Anforderungen für biometrische Daten der Klasse 3 oder Klasse 2 erfüllen wie in diesem Dokument definiert.
- [C-4-2] MÜSSEN jeden als Konstanten definierten Parameternamen erkennen und berücksichtigen im Abschnitt Authenticators und allen Kombinationen daraus. Umgekehrt DÜRFEN KEINE Ganzzahlkonstanten, die an die canAuthenticate(int): und setAllowedAuthenticators(int) als öffentliche Konstanten dokumentiert sind, Authenticator und jegliche Kombinationen daraus.
- [C-4-3] MÜSSEN die ACTION_BIOMETRIC_ENROLL implementieren Aktion auf Geräten mit biometrischen Verfahren der Klasse 3 oder Klasse 2. Diese Aktion DARF nur die Einstiegspunkte zur Anmeldung für Klasse 3 anzeigen oder Kurs 2.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-4-4] MÜSSEN Anwendungen erlauben, benutzerdefinierte Inhalte zu
BiometricPrompt
hinzuzufügen mit denPromptContentView
-Formaten für die Inhaltsanzeige. Der Inhalt wird angezeigt Formate DÜRFEN NICHT erweitert werden, um Bilder, Links, interaktive Inhalte, oder andere Arten von Medien, die noch nicht Teil desBiometricPrompt
sind der API erstellen. Stilistische Anpassungen, die den Text nicht verändern, verdecken oder kürzen Elemente festgelegt werden können (z. B. Position, Abstand, Ränder und Typografie).
Neue Anforderungen beenden
Wenn Geräteimplementierungen passives biometrisches Verfahren unterstützen, gilt Folgendes:
- [C-5-1] MUSS standardmäßig einen zusätzlichen Bestätigungsschritt erfordern (z.B. Drücken einer Taste).
- [C-SR-1] Wir empfehlen dringend, eine Einstellung zu haben, mit der Nutzer Folgendes tun können: Anwendungseinstellung überschreiben und immer eine begleitende Bestätigungsschritts.
- [C-SR-2] WIRD UNBEDINGT EMPFOHLEN, die Bestätigungsaktion zu sichern sodass ein Betriebssystem- oder Kernel-Manipulation das Spoofing nicht verhindern kann. Das bedeutet zum Beispiel, dass die Bestätigung über eine physische Taste wird über einen GPIO-Pin (Input-Only General-purpose Input/Output) weitergeleitet ein Secure Element (SE), das ausschließlich durch ein Tastendruck.
- [C-5-2] MÜSSEN zusätzlich einen impliziten Authentifizierungsvorgang implementieren. (ohne Bestätigungsschritt) entspricht setConfirmationRequired(boolean) welche Anwendungen für Anmeldeabläufe genutzt werden können.
Geräteimplementierungen mit mehreren biometrischen Sensoren:
[C-7-1] MÜSSEN, wenn ein biometrisches Verfahren gesperrt ist, d.h. das biometrische Verfahren bis der Nutzer das Gerät mit der primären Authentifizierung entsperrt) oder eine zeitgebundene Sperrung (d. h. das biometrische Verfahren ist vorübergehend deaktiviert, bis der Nutzer eine Weile wartet. Intervall) aufgrund zu vieler fehlgeschlagener Versuche, sperren Sie auch alle anderen biometrischen Verfahren einer niedrigeren biometrischen Klasse. Bei einer zeitgebundenen Sperrung Die Backoff-Zeit für die biometrische Überprüfung MUSS der maximalen Backoff-Zeit entsprechen aller biometrischen Daten unter zeitgebundener Lockout-Regelung.
[C-SR-12] werden dringend empfohlen, wenn ein biometrisches Verfahren gesperrt ist (d.h. ist deaktiviert, bis der Nutzer das Gerät mit der primären Authentifizierung entsperrt. zeitgebundene Sperrung (d.h. das biometrische Verfahren wird bis zum Wartezeit des Nutzers) aufgrund zu vieler fehlgeschlagener Versuche, um auch alle anderen biometrischen Verfahren derselben biometrischen Klasse sperren. Im Fall von zeitgebundene Sperrung, ist die Backoff-Zeit für die biometrische Überprüfung UNBEDINGT EMPFOHLEN, die maximale Backoff-Zeit aller biometrischen Daten in terminierter
[C-7-2] MUSS den Nutzer zur empfohlenen primären Authentifizierung auffordern (z. B. PIN, Muster, Passwort), um den Sperrzähler für ein biometrisches Verfahren ausgesperrt zu sein. Klasse 3: Die Sperrfunktion für biometrische Verfahren KANN zurückgesetzt werden. für ein gesperrtes biometrisches Verfahren derselben oder einer niedrigeren Klasse. Kurs 2 oder Klasse 1 – biometrische Verfahren DÜRFEN NICHT die Sperre für das Zurücksetzen auf die Werkseinstellungen durchführen für jedes biometrische Verfahren.
[C-SR-3] Es wird dringend empfohlen, nur eine biometrische Methode zu bestätigen pro Authentifizierung (z.B. wenn sowohl Fingerabdruck- als auch Gesichtserkennung verfügbar sind) auf dem Gerät, onAuthenticationSucceeded. sollte gesendet werden, nachdem einer davon bestätigt wurde.
Damit Geräteimplementierungen den Zugriff auf Schlüsselspeicherschlüssel ermöglichen, Anwendungen von Drittanbietern:
- [C-6-1] MÜSSEN die hier definierten Anforderungen für Klasse 3 erfüllen. weiter unten.
- [C-6-2] MUSS bei der Authentifizierung nur biometrische Daten der Klasse 3 anzeigen erfordert BIOMETRIC_STRONG, oder die Authentifizierung wird mit einem CryptoObject aufgerufen.
Wenn ein biometrischer Sensor in Geräteimplementierungen als Klasse 1 behandelt werden soll (früher Convenience) verwenden, gilt Folgendes:
- [C-1-1] MUSS eine falsche Annahmequote unter 0,002 % haben.
- [C-1-2] MÜSSEN offenlegen, dass dieser Modus möglicherweise weniger sicher ist als eine starke PIN, oder Passwort haben und die Risiken einer Aktivierung klar aufführen, falls der Die Akzeptanzrate von Spoofing und Hochstapler-Syndrom liegt über 7 %, Biometrische Testprotokolle von Android.
- [C-1-9] MUSS den Nutzer zur empfohlenen primären Authentifizierung auffordern (z.B. PIN, Muster, Passwort), nach maximal 20 falschen Versuchen Backoff-Zeit von weniger als 90 Sekunden für die biometrische Überprüfung, Falsche Aufnahme hat eine angemessene Aufnahmequalität. (BIOMETRIC_ACQUIRED_GOOD), der nicht mit einem registrierten biometrischen Verfahren übereinstimmt.
- [C-SR-4] WIRD UNBEDINGT EMPFOHLEN, die Gesamtzahl der falschen Versuche zu verringern für die biometrische Überprüfung gemäß [C-1-9], wenn die Parodien und Betrüger Akzeptanzraten sind höher als 7 %, wie von Android Biometrics ermittelt Testprotokolle.
- [C-1-3] MUSS die Anzahl der Versuche für die biometrische Überprüfung begrenzen, wenn
Falsche Aufnahme hat eine angemessene Aufnahmequalität.
(
BIOMETRIC_ACQUIRED_GOOD
) die nicht mit einem registrierten biometrischen Verfahren übereinstimmen. - [C-SR-5] Dringend empfohlen, Ratenbegrenzungen für mindestens 30 Sekunden nach fünf Fehlversuchen zur biometrischen Überprüfung der maximale Anzahl falscher Versuche pro [C-1-9], wobei ein falscher Test eins mit eine angemessene Aufnahmequalität (BIOMETRIC_ACQUIRED_GOOD), die nicht mit biometrischen Verfahren ein.
- [C-SR-6] Es wird dringend empfohlen, die gesamte Ratenbegrenzungslogik in TEE zu verwenden.
- [C-1-10] MÜSSEN das biometrische Verfahren deaktivieren, sobald der Backoff für die primäre Authentifizierung wie in [C-0-2] in Abschnitt 9.11 beschrieben ausgelöst.
- [C-1-11] MUSS eine Akzeptanzrate von Spoofing und Identitätsdiebstahl aufweisen, die nicht über 30 % liegt. mit (1) einer Akzeptanzrate von Parodien und Irrtümern für die Präsentation der Stufe A Angriffsinstrumentenarten, die nicht mehr als 30 % ausmachen, und (2) eine Parodien und Hochstapler-Akzeptanzrate von Level-B-PAI-Spezies nicht höher als 40%, da gemäß den Android Biometrics Test Protocols gemessen werden.
- [C-1-4] MUSS das Hinzufügen neuer biometrischer Daten MUSS verhindern, ohne zuvor ein Vertrauenskette, indem Nutzer das vorhandene Gerät bestätigen oder ein neues hinzufügen Von TEE gesicherte Anmeldedaten (PIN/Muster/Passwort) die Android Open Die Quellprojektimplementierung stellt den zu tunden Mechanismus im Framework bereit also.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-5] MÜSSEN alle identifizierbaren biometrischen Daten eines Nutzers vollständig entfernen Das Nutzerkonto wird entfernt (z. B. durch das Zurücksetzen auf die Werkseinstellungen). oder wenn die empfohlene primäre Authentifizierung (z.B. PIN, Muster, Passwort) entfernt werden.
Neue Anforderungen beenden
- [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
.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-7] MUSS den Nutzer zur empfohlenen primären Authentifizierung auffordern
(z. B. PIN, Muster, Passwort) mindestens einmal alle 24 Stunden.
Hinweis: Das Upgrade von Geräten, die mit Android 9 oder niedriger gestartet wurden, MÜSSEN MÜSSEN den Nutzer nach der empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) und höchstens alle 72 Stunden.
Neue Anforderungen beenden
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-8] MÜSSEN den Nutzer zur Empfehlung für Hauptkonten auffordern
Authentifizierung (z. B. PIN, Muster, Passwort) oder biometrisches Verfahren der Klasse 3 (STRONG)
nach einer der folgenden Aktionen:
<ph type="x-smartling-placeholder">
- </ph>
- ein Zeitlimit von 4 Stunden bei Inaktivität ODER
- 3 fehlgeschlagene biometrische Authentifizierungsversuche.
- Das Zeitlimit bei Inaktivität und die Anzahl der fehlgeschlagenen Authentifizierungen werden zurückgesetzt.
nach erfolgreicher Bestätigung der Geräteanmeldedaten.
Hinweis: Aktualisieren von Geräten, die mit Android Version 9 gestartet wurden oder früher KANN von C-1-8 ausgenommen werden.
Neue Anforderungen beenden
- [C-SR-7] wird dringend empfohlen, die Logik des bereitgestellten Frameworks zu verwenden. des Android Open Source-Projekts, um die in den [C-1-7] und [C-1-8] für neue Geräte.
- [C-SR-8] WIRD UNBEDINGT EMPFOHLEN, eine Rate falscher Ablehnungen zu verwenden von weniger als 10 % gemessen.
- [C-SR-9] Wir empfehlen dringend, eine Latenz von unter 1 Sekunde (gemessen) zu haben. ab dem Zeitpunkt, an dem das biometrische Verfahren erkannt wird, bis zum Entsperren des Bildschirms. biometrischen Verfahren ein.
- [C-1-12] DÜRFEN eine Akzeptanzrate von Parodien und Betrügern von maximal 40 % aufweisen. pro Art des Präsentationsangriffs (PAI), gemessen von der Biometrische Testprotokolle von Android.
- [C-SR-13] Parodien und Die Akzeptanzrate für Hacker nicht höher als 30% pro Art des Präsentationsangriffs (PAI), gemessen von der Biometrische Testprotokolle von Android.
- [C-SR-8] WIRD UNBEDINGT EMPFOHLEN, eine Rate falscher Ablehnungen zu verwenden von weniger als 10 % gemessen.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-15] MÜSSEN Nutzern die Entfernung eines oder mehrerer biometrischer Daten erlauben. Registrierungen.
Neue Anforderungen beenden
[C-SR-14] WIRD UNBEDINGT EMPFOHLEN, die biometrische Klasse des biometrischen Sensor und die damit verbundenen Risiken ihrer Aktivierung.
[C-SR-17] WIRD DRINGEND empfohlen, die neuen AIDL-Schnittstellen zu implementieren (z. B.
IFace.aidl
undIFingerprint.aidl
).
Wenn ein biometrischer Sensor in Geräteimplementierungen als Klasse 2 behandelt werden soll (früher Weak) werden sie:
- [C-2-1] MÜSSEN alle Anforderungen für Klasse 1 oben erfüllen.
- [C-2-2] MUSS eine Akzeptanzrate von Spoofing und Nichtbetrügern von maximal 20 % aufweisen. mit (1) einer Akzeptanzrate von Spoofing und PAI-Spezies, Level A, die nicht höher als 20 % sind und (2) eine Akzeptanzrate von Parodien und Hochstapler-Spezies von PAI-Arten der Stufe B, die nicht über 30%, gemessen am Biometrische Testprotokolle von Android.
- [C-SR-15] Parodien und Betrüger raten dringend davon ab. Akzeptanzrate nicht höher als 20% pro Art des Präsentationsangriffs (PAI), gemessen von der Biometrische Testprotokolle von Android.
- [C-2-3] MUSS die biometrischer Abgleich in einer isolierten Ausführungsumgebung außerhalb von Android Nutzer- oder Kernel-Bereich wie die vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) auf einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder auf einer geschützten virtuellen Maschine, die die Anforderungen in Abschnitt 9.17 erfüllt.
- [C-2-4] MÜSSEN alle identifizierbaren Daten verschlüsselt und kryptografisch verschlüsselt werden. so authentifiziert, dass sie außerhalb des die isolierte Ausführungsumgebung, oder einen Chip mit einem sicheren Kanal, isolierten Ausführungsumgebung, wie in der Implementierungsumgebung Richtlinien auf der Website des Open-Source-Projekts von Android oder einer geschützten virtuellen Maschine vom Hypervisor gesteuert, der die Anforderungen in Abschnitt 9.17 erfüllt.
- [C-2-5] Für kamerabasierte biometrische Verfahren und biometrische Authentifizierung
oder eine Registrierung stattfindet:
<ph type="x-smartling-placeholder">
- </ph>
- MÜSSEN die Kamera in einem Modus betrieben werden, der verhindert, dass die Kamerarahmen außerhalb der isolierten Ausführungsumgebung oder eines Chips gelesen oder geändert werden. mit einem sicheren Kanal in die isolierte Ausführungsumgebung oder Virtuelle Maschine, die vom Hypervisor gesteuert wird und die Anforderungen in Abschnitt erfüllt 9:17.
- Bei RGB-Lösungen mit einer Kamera können die Kamerarahmen Außerhalb der isolierten Ausführungsumgebung lesbar, um Vorgänge zu unterstützen wie die Vorschau für die Anmeldung, DARF aber trotzdem NICHT geändert werden.
- [C-2-6] DÜRFEN Anwendungen von Drittanbietern NICHT ermöglichen, zwischen biometrische Anmeldungen.
- [C-2-7] DÜRFEN KEINEN unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder alle daraus abgeleiteten Daten (z. B. Einbettungen) an den Anwendungsprozessor außerhalb des Kontexts des TEE oder der geschützten virtuellen Maschine der die Anforderungen in Paragraf 9.17 erfüllt. Upgrades von Geräten, die mit Android 9 oder niedriger gestartet wurden, sind nicht ausgenommen C-2-7.
[C-2-8] MÜSSEN über eine sichere Verarbeitungspipeline verfügen, eine Manipulation des Systems oder Kernels nicht zulassen, dass Daten direkt in sich fälschlicherweise als Nutzer authentifizieren. Hinweis: Wenn Geräteimplementierungen bereits unter Android 9 veröffentlicht werden oder früher und kann die Anforderung C-2-8 nicht über eine Systemsoftware erfüllen. aktualisiert wurde, sind sie von der Anforderung ausgenommen.
[C-SR-10] Wir empfehlen dringend, die Aktivitätserkennung für alle biometrische Modalitäten und Aufmerksamkeitserkennung für biometrische Verfahren.
[C-2-9] MUSS den biometrischen Sensor Drittanbietern zur Verfügung stellen Anwendungen.
Wenn ein biometrischer Sensor in Geräteimplementierungen als Klasse 3 behandelt werden soll (früher Strong) gilt Folgendes:
- [C-3-1] MÜSSEN alle Anforderungen der obigen Klasse 2 erfüllen, mit Ausnahme von [C-1-7] und [C-1-8].
- [C-3-2] MÜSSEN eine hardwaregestützte Schlüsselspeicherimplementierung haben.
- [C-3-3] MUSS eine Akzeptanzrate von Parodien und Betrügern von maximal 7 % aufweisen. mit (1) einer Akzeptanzrate von Spoofing und PAI-Spezies, Level A, die nicht über 7 % liegen und (2) die Akzeptanzrate von Parodien und Hochstapler-Spezies von PAI-Arten der Stufe B nicht höher als 20%, gemessen am Biometrische Testprotokolle von Android.
- [C-3-4] MÜSSEN den Nutzer zur empfohlenen primären IP-Adresse herausfordern. Authentifizierung (z. B. PIN, Muster oder Passwort) einmal alle 72 Stunden oder weniger.
- [C-3-5] MÜSSEN die Authenticator-ID neu generieren. für alle biometrischen Verfahren der Klasse 3, die auf dem Gerät unterstützt werden, sofern eines davon erneut angemeldet wurden.
- [C-3-6] Biometrische gesicherte Schlüsselspeicherschlüssel müssen für Drittanbieter aktiviert werden. Anwendungen.
[C-SR-16] Parodien und Betrüger raten dringend davon ab. Akzeptanzrate nicht höher als 7% pro Art des Präsentationsangriffs, gemessen von der Biometrische Testprotokolle von Android. Wenn Geräteimplementierungen einen Fingerabdrucksensor unter dem Display enthalten, Sie:
[C-SR-11] WIRD UNBEDINGT EMPFOHLEN, den antippbaren Bereich des Fingerabdrucksensors unter dem Display zu verhindern die die Bedienung über 3 Schaltflächen beeinträchtigen können( was einige Nutzer und Barrierefreiheit).
7.3.11 Positionssensor
Geräteimplementierungen:
- KANN Positionssensor mit 6 Freiheitsgraden unterstützen.
Wenn Geräteimplementierungen einen Positionssensor mit 6 Freiheitsgraden unterstützen, ist Folgendes möglich:
- [C-1-1] MÜSSEN
TYPE_POSE_6DOF
implementieren und melden. Sensor. - [C-1-2] MUSS genauer sein als der Rotationsvektor allein.
7.3.12 Scharnierwinkelsensor
Wenn Geräteimplementierungen einen Scharnierwinkelsensor unterstützen, ist Folgendes zu beachten:
- [C-1-1] MÜSSEN
TYPE_HINGLE_ANGLE
implementieren und melden. - [C-1-2] MUSS mindestens zwei Messwerte zwischen 0 und 360 Grad unterstützen (einschließlich 0 und 360 Grad).
- [C-1-3] MUSS einen Wakeup zurückgeben.
Sensor für
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13 IEEE 802.1.15.4 (UWB)
Wenn Geräteimplementierungen 802.1.15.4 unterstützen und den Funktionalität in Anwendungen von Drittanbietern zur Verfügung stellen, gilt Folgendes:
- [C-1-2] MÜSSEN das Hardwarefunktions-Flag
android.hardware.uwb
melden. - [C-1-3] MUSS alle folgenden Konfigurationssätze (vordefiniert) unterstützen
Kombinationen der Parameter FIRA UCI
die in der AOSP-Implementierung definiert sind.
CONFIG_ID_1
: FiRa-definiertes Unicast-STATIC STS DS-TWR
-Bereich, verzögerten Modus mit einem Bereichsintervall von 240 ms.CONFIG_ID_2
: Von FiRa definierter 1:n-STATIC STS DS-TWR
-Bereich, verzögerten Modus mit einem Bereichsintervall von 200 ms. Typischer Anwendungsfall: Smartphone mit vielen Smart-Home-Geräten interagieren.CONFIG_ID_3
: EntsprichtCONFIG_ID_1
mit Ausnahme des Ankunftswinkels (AoA) werden keine Daten gemeldet.CONFIG_ID_4
: EntsprichtCONFIG_ID_1
, mit dem Unterschied, dass der P-STS-Sicherheitsmodus ist aktiviert.CONFIG_ID_5
: EntsprichtCONFIG_ID_2
, mit dem Unterschied, dass der P-STS-Sicherheitsmodus ist aktiviert.CONFIG_ID_6
: EntsprichtCONFIG_ID_3
, mit dem Unterschied, dass der P-STS-Sicherheitsmodus ist aktiviert.CONFIG_ID_7
: EntsprichtCONFIG_ID_2
, mit Ausnahme von P-STS-Steuerelementen für einzelne Nutzer Schlüsselmodus aktiviert ist.
- [C-1-4] MÜSSEN eine Funktion anbieten, mit der Nutzer das UWB aktivieren und deaktivieren können. aktiviert/deaktiviert.
- [C-1-5] MÜSSEN erzwingen, dass Apps, die UWB-Funkschnittstellen verwenden, das
UWB_RANGING
Berechtigung (unter der BerechtigungsgruppeNEARBY_DEVICES
).
Das Bestehen der relevanten Konformitäts- und Zertifizierungstests gemäß der Norm einschließlich FIRA, CC und CSA sorgt dafür, dass 802.1.15.4 ordnungsgemäß funktioniert.
7.4 Datenverbindung
7.4.1 Telefonie
„Telefonie“ die von den Android-APIs verwendet werden. Dieses Dokument bezieht sich auf Hardware zum Tätigen von Sprachanrufen und Senden von SMS-Nachrichten oder Einrichten von mobilen Daten über ein Mobilfunknetz (z.B. GSM, CDMA, LTE, NR),GSM oder CDMA Netzwerk. Ein Gerät, das „Telefonie“ unterstützt einige oder alle Anruf-, Messaging- und Datendienste entsprechend dem Produkt.
- Android KANN auf Geräten ohne Telefonie-Hardware verwendet werden. Das Android ist mit Geräten kompatibel, bei denen es sich nicht um Smartphones handelt.
Wenn Geräteimplementierungen GSM- oder CDMA-Telefonie umfassen, gilt Folgendes:
- [C-1-1] MÜSSEN das Funktions-Flag
android.hardware.telephony
und anderen Unterelementen-Flags entsprechend der Technologie. - [C-1-2] MÜSSEN für diese Technologie den vollen Support für die API implementieren.
- SOLLTEN alle verfügbaren Mobilfunkdienste zulassen (2G, 3G, 4G, 5G usw.).
bei Notrufen (unabhängig von den Netzwerktypen,
SetAllowedNetworkTypeBitmap()
.
Wenn Geräteimplementierungen keine Telefoniehardware enthalten, gilt Folgendes:
- [C-2-1] MÜSSEN die vollständigen APIs als managementfrei implementieren.
Wenn Geräteimplementierungen eUICCs oder eSIMs/eingebettete SIMs unterstützen und einen proprietären Mechanismus, um die eSIM-Funktion für Drittanbieter verfügbar zu machen Entwickler:innen:
- [C-3-1] MÜSSEN die
android.hardware.telephony.euicc
Funktions-Flag.
Wenn die Systemeigenschaft ro.telephony.iwlan\_operation\_mode
bei Geräteimplementierungen nicht auf „Legacy“ gesetzt wird, geschieht Folgendes:
- [C-4-1] DARF NICHT 'NETWORK_TYPE_IWLAN' melden über NetworkRegistrationInfo#getAccessNetworkTechnology() wenn NetworkRegistrationInfo#getTransportType() wird als TRANSPORT_TYPE_WWAN gemeldet für dieselbe NetworkRegistrationInfo-Instanz an.
Wenn Geräteimplementierungen ein einzelnes IP Multimedia Subsystem (IMS) unterstützen für den Multimedia-Telefoniedienst (MMTEL) und Rich Communication Service (RCS) profitieren und mit den Anforderungen des Mobilfunkanbieters bezüglich der Verwendung eines einzigen IMS-Registrierung für den gesamten IMS-Signalisierungs-Traffic:
- [C-5-1] MUSS die
android.hardware.telephony.ims
deklarieren und eine vollständige Implementierung der ImsService API für MMTEL und RCS User Capability Exchange API. - [C-5-2] MUSS die
android.hardware.telephony.ims.singlereg
deklarieren Funktions-Flag und bieten eine vollständige Implementierung der SipTransport API, die GbaService API dedizierten Inhaber über IRadio 1.6 HAL und die Bereitstellung über den Auto Configuration Server (ACS) oder eine andere proprietäre Bereitstellung mithilfe der IMS-Konfigurations-API.
Wenn Geräteimplementierungen die Funktion android.hardware.telephony
melden, dann:
- [C-6-1] Die
SmsManager#sendTextMessage
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: <ph type="x-smartling-placeholder">- </ph>
- Netzwerkzugriff widerrufen oder einschränken
- Berechtigungen widerrufen
- Die Ausführung von Apps im Hintergrund oder im Vordergrund über die vorhandenen Energieverwaltungsfunktionen von AOSP hinaus einschränken
- App deaktivieren oder deinstallieren
Wenn Geräteimplementierungen die Funktion android.hardware.telephony
melden und
alle aktiven,
nicht opportunistische Abos
Gruppen-UUIDs deaktiviert sind.
vom Gerät entfernt oder als opportunistisch gekennzeichnet wurde, geschieht Folgendes:
- [C-8-1] MÜSSEN automatisch alle verbleibenden aktiven opportunistisch Abos in derselben Gruppe.
Wenn Geräteimplementierungen GSM-Telefonie, aber keine CDMA-Telefonie umfassen, gilt Folgendes:
- [C-9-1] DARF NICHT
PackageManager#FEATURE_TELEPHONY_CDMA
deklarieren. - [C-9-2] MÜSSEN bei Versuchen, einen Wert festzulegen, den Fehler
IllegalArgumentException
auslösen. 3GPP2-Netzwerktypen in bevorzugten oder zulässigen Bitmasken des Netzwerktyps. - [C-9-3] MUSS eine leere Zeichenfolge aus
TelephonyManager#getMeid
Wenn die Geräteimplementierungen eUICCs mit mehreren Ports und Profilen unterstützen, gilt Folgendes:
- [C-10-1] MÜSSEN die
android.hardware.telephony.euicc.mep
Funktions-Flag.
7.4.1.1 Kompatibilität mit Nummernblockierungen
Wenn Geräteimplementierungen die Funktion android.hardware.telephony.calling
melden, geschieht Folgendes:
- [C-1-1] MUSS die Unterstützung für das Blockieren von Nummern enthalten.
- [C-1-2] MUSS
BlockedNumberContract
vollständig implementieren und die entsprechende API, wie in der SDK-Dokumentation beschrieben. [C-1-3] MÜSSEN alle Anrufe und Nachrichten von einer Telefonnummer in „BlockingNumberProvider“ ohne Interaktion mit Apps. Die einzige Ausnahme wenn die Blockierung von Nummern wie im SDK beschrieben vorübergehend aufgehoben wird Dokumentation.
[C-1-4] MUSS in den Plattformanbieter für Anruflisten schreiben für einen blockierten Anruf und MÜSSEN Anrufe mit
BLOCKED_TYPE
von Standardansicht in der Anrufliste in der vorinstallierten Telefon-App[C-1-5] DARF NICHT an den Telefonieanbieter schreiben für eine blockierte Nachricht.
[C-1-6] MÜSSEN eine UI für die Verwaltung blockierter Nummern implementieren, die geöffnet wird. mit dem von
TelecomManager.createManageBlockedNumbersIntent()
zurückgegebenen Intent .[C-1-7] DÜRFEN sekundäre Nutzer NICHT erlauben, die blockierten Nummern anzusehen oder zu bearbeiten da die Android-Plattform davon ausgeht, dass der Hauptnutzer Kontrolle über die Telefoniedienste in einer einzigen Instanz auf dem Gerät. Alle Benutzeroberfläche zum Blockieren von Nutzern MUSS für sekundäre Nutzer ausgeblendet sein und die Liste der blockierten Nutzer MÜSSEN MÜSSEN respektiert werden.
SOLLTEN Sie die blockierten Nummern zum Anbieter migrieren, wenn ein Gerät aktualisiert wird Android 7.0.
SOLLTEN Sie die blockierten Anrufe in der vorinstallierten App Telefon App
7.4.1.2 Telekommunikations-API
Wenn Geräteimplementierungen android.hardware.telephony.calling
melden, geschieht Folgendes:
- [C-1-1] MUSS die im SDK beschriebenen
ConnectionService
APIs unterstützen. - [C-1-2] MÜSSEN einen neuen eingehenden Anruf anzeigen und dem Nutzer
Eingehenden Anruf annehmen oder ablehnen, während der Nutzer in einem aktiven Anruf ist
die von einer Drittanbieter-App stammen, die die Hold-Funktion nicht unterstützt
angegeben über
CAPABILITY_SUPPORT_HOLD
- [C-1-3] MUSS eine Anwendung haben, die InCallService übergeben.
[C-SR-1] Es wird dringend empfohlen, den Nutzer über die eingehender Anruf wird ein laufender Anruf beendet.
Die AOSP-Implementierung erfüllt diese Anforderungen mit einer Vorabbenachrichtigung was dem Nutzer signalisiert, dass das Annehmen eines eingehenden Anrufs ein anderer zu löschender Anruf.
[C-SR-2] EMPFOHLEN, die Standard-Telefon-App vorab zu laden, einen Eintrag aus der Anrufliste und den Namen einer Drittanbieter-App in der Anrufliste zeigt wenn die Drittanbieter-App
EXTRA_LOG_SELF_MANAGED_CALLS
Extras-Schlüssel 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.
Neue Anforderungen für 15 Nutzer (AOSP experimentell)
- [C-1-4] MÜSSEN Multicast-DNS (mDNS) unterstützen und mDNS-Pakete NICHT filtern (224.0.0.251 oder ff02::fb) auch dann, wenn das Display nicht aktiv ist, es sei denn, das Verwerfen oder Filtern dieser Pakete ist erforderlich, um innerhalb der gesetzlich vorgeschriebenen Bereiche des Stromverbrauchs zu bleiben die für den Zielmarkt gelten.
- [C-1-4] MUSS mDNS unterstützen und DÜRFEN KEINE mDNS-Pakete filtern (224.0.0.251 oder ff02::fb) zur Verfügung, auch wenn der der Bildschirm nicht aktiv ist, es sei denn, die Multicast-Sperre ist aktiviert und werden die Pakete vom APF gefiltert. Die Pakete sind nicht erforderlich, um mDNS-Vorgänge, die derzeit von Anwendungen über den NsdManager angefordert werden APIs Das Gerät KANN jedoch mDNS-Pakete filtern, wenn dies erforderlich ist. um den Stromverbrauchsbereichen einzuhalten, die gesetzlich vorgeschrieben sind die für den Zielmarkt relevant sind.
Neue Anforderungen beenden
- [C-1-5] DARF NICHT den
WifiManager.enableNetwork()
behandeln API-Methodenaufruf als ausreichender Hinweis zum Wechseln der derzeit 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) Adresse nach der Hälfte des Scans).
- [C-1-9] MÜSSEN die Sequenznummer der Prüfungsanfrage wie gewohnt (sequentiell) iterieren. zwischen den Prüfungsanfragen in einem Scan.
- [C-1-10] MÜSSEN die Sequenznummer der Prüfungsanforderung zwischen der letzten Prüfung zufällig anordnen. und die erste Prüfungsanfrage des nächsten Scans.
- [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die MAC-Quelladresse für
die gesamte STA-Kommunikation mit einem Zugangspunkt (Zugangspunkt) zu verbinden, während
verknüpft sind.
- Das Gerät muss für jede SSID eine andere zufällige MAC-Adresse verwenden. (FQDN für Passpoint), mit dem er kommuniziert.
- Das Gerät MUSS dem Nutzer eine Option zum Steuern des Randomisierung pro SSID (FQDN für Passpoint) mit nicht zufälligen und Zufällig ausgewählte Optionen und MÜSSEN den Standardmodus für das neue WLAN festlegen. Konfigurationen ausgewählt werden.
- [C-SR-2] Es wird dringend empfohlen, für jeden Zugangspunkt eine zufällige BSSID zu verwenden,
erstellen.
- Die MAC-Adresse MUSS für jede vom ZP.
- Über das GERÄT KANN der Nutzer diese Funktion deaktivieren. Wenn eine solche Option angegeben wird, MUSS die Zufallsauswahl standardmäßig aktiviert sein.
Wenn Geräteimplementierungen wie definiert den WLAN-Energiesparmodus unterstützen gemäß IEEE 802.11-Standard:
- SOLLTEN Sie den WLAN-Energiesparmodus ausschalten, wenn eine App
WIFI_MODE_FULL_HIGH_PERF
-Sperre 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. generische Anzeige Service (GAS) und Access Network Query Protocol (ANQP).
- [C-1-4] MÜSSEN das Funktions-Flag „
android.hardware.wifi.passpoint
“ deklarieren. - [C-1-5] MUSS der AOSP-Implementierung folgen, um zu erkennen, abzugleichen und zu verknüpfen mit Passpoint-Netzwerken.
- [C-1-6] MUSS mindestens die folgende Teilmenge der Gerätebereitstellung unterstützen Protokolle entsprechend der Definition im Wi-Fi Alliance Passpoint R2: EAP-TTLS -Authentifizierung und SOAP-XML.
- [C-1-7] MÜSSEN das AAA-Serverzertifikat wie in Hotspot 2.0 R3-Spezifikation.
- [C-1-8] MÜSSEN die Nutzersteuerung der Bereitstellung über die WLAN-Auswahl unterstützen.
- [C-1-9] MÜSSEN Passpoint-Konfigurationen auch nach einem Neustart beibehalten werden.
- [C-SR-1] WIRD UNBEDINGT EMPFOHLEN, die Nutzungsbedingungen zu unterstützen Akzeptanzfunktion zu finden.
- [C-SR-2] wird dringend empfohlen, die Funktion „Informationen zu Veranstaltungsorten“ zu unterstützen.
Wenn ein globaler Nutzersteuerungsschalter mit Passpoint-Deaktivierung verfügbar ist, werden folgende Implementierungen angewendet:
- [C-3-1] MÜSSEN Passpoint standardmäßig aktivieren.
7.4.2.5 WLAN-Standort (WLAN-Umlaufzeit – RTT)
Geräteimplementierungen:
- SOLLTE Unterstützung für WLAN-Standort beinhalten.
Wenn die Geräteimplementierung die WLAN-Funktion unterstützt und die Drittanbieter-Apps zur Verfügung stehen, geschieht Folgendes:
- [C-1-1] MÜSSEN die
WifiRttManager
APIs wie in den SDK-Dokumentation. - [C-1-2] MÜSSEN das Funktions-Flag
android.hardware.wifi.rtt
deklarieren. - [C-1-3] MÜSSEN die Quell-MAC-Adresse für jeden RTT-Burst zufällig anordnen. der ausgeführt wird, während die WLAN-Schnittstelle, auf der die RTT läuft, ausgeführt wird. ausgeführt wird, ist keinem Zugangspunkt zugeordnet.
- [C-1-4] MÜSSEN am 68. und bei einer Bandbreite von 80 MHz auf einen Bereich von 2 Metern genau sein Perzentil (wie mit der kumulativen Verteilungsfunktion berechnet).
- [C-SR-1] Es wird dringend empfohlen, Daten in einem Umkreis von 1,5 Metern zu melden. bei einer Bandbreite von 80 MHz beim 68. Perzentil (wie mit der Kumulative Verteilungsfunktion).
7.4.2.6 Wi-Fi Keepalive Offload
Geräteimplementierungen:
- SOLLTEN die Unterstützung für Wi-Fi-Keepalive-Auslagerung umfassen.
Wenn Geräteimplementierungen Unterstützung für die Wi-Fi-Keepalive-Auslagerung beinhalten und die Funktionalität für Drittanbieter-Apps verfügbar ist, gilt Folgendes:
- [C-1-1] MUSS die SocketKeepAlive API unterstützen.
- [C-1-2] MUSS mindestens drei gleichzeitige Keepalive-Slots über WLAN unterstützen
Wenn Geräteimplementierungen die Wi-Fi-Keepalive-Auslagerung nicht unterstützen, Sie:
- [C-2-1] MUSS
ERROR_UNSUPPORTED
zurückgeben.
7.4.2.7 Wi-Fi Easy Connect (Protokoll für die Gerätebereitstellung)
Geräteimplementierungen:
- SOLLTEN Wi-Fi Easy Connect (DPP) unterstützen.
Wenn Geräteimplementierungen Wi-Fi Easy Connect unterstützen und den Drittanbieter-Apps funktionieren, müssen sie:
- [C-1-1] MUSS die Funktion WifiManager#isEasyConnectSupported()
gibt
true
zurück.
7.4.2.8 Validierung des Unternehmens-WLAN-Serverzertifikats
Wenn das WLAN-Serverzertifikat nicht bestätigt wurde oder der WLAN-Server Domainname nicht festgelegt, Geräteimplementierungen:
- [C-SR-1] Es wird dringend empfohlen, dem Nutzer keine Option zu bieten, Unternehmens-WLAN manuell hinzufügen in der App „Einstellungen“.
7.4.2.9 Vertrauen bei der ersten Verwendung
Wenn Geräteimplementierungen Trust on first use (TOFU) unterstützen und Erlaubt es dem Nutzer, WPA-/WPA2-/WPA3-Enterprise-Konfigurationen zu definieren, dann:
- [C-4-1] MÜSSEN dem Nutzer die Möglichkeit geben, TOFU zu verwenden.
7.4.3 Bluetooth
Wenn Geräteimplementierungen das Bluetooth Audio-Profil unterstützen, gilt Folgendes:
- SOLLTEN erweiterte Audio-Codecs und Bluetooth-Audio-Codecs unterstützen. (z.B. LDAC)
Wenn Geräteimplementierungen HFP, A2DP und AVRCP unterstützen, gilt Folgendes:
- SOLLTEN mindestens 5 verbundene Geräte unterstützen.
Wenn in der Geräteimplementierung android.hardware.vr.high_performance
deklariert wird
Funktion:
- [C-1-1] MÜSSEN Bluetooth 4.2 und Bluetooth LE-Datenlängenerweiterung unterstützen.
Android unterstützt Bluetooth und Bluetooth Low Energy.
Ob die Geräteimplementierung Bluetooth und Bluetooth unterstützt Energiesparend können sie:
- [C-2-1] MÜSSEN die relevanten Plattformfunktionen deklariert werden.
(
android.hardware.bluetooth
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 Voraussetzungen für die Anwesenheitskalibrierung
7.4.4 Nahfeldkommunikation
Geräteimplementierungen:
- SOLLTEN einen Transceiver und die zugehörige Hardware für den Nahfeldbereich enthalten. Kommunikation (NFC).
- [C-0-1] MÜSSEN
android.nfc.NdefMessage
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:
<ph type="x-smartling-placeholder">
- </ph>
- NfcA (ISO14443-3A)
- NFCB (ISO 14443-3B)
- NFCF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- NFC-Forum Tag-Typen 1, 2, 3, 4, 5 (definiert vom NFC-Forum)
[C-SR-1] WIRD UNBEDINGT EMPFOHLEN, NDEF zu lesen und zu schreiben Nachrichten sowie Rohdaten über die folgenden NFC-Standards. Beachten Sie, dass NFC-Standards sind zwar als AUSSCHLIEẞLICH EMPFOHLEN, Die Kompatibilitätsdefinition für eine zukünftige Version wird diese an MUSS. Diese Standards sind in dieser Version optional, erforderlich in zukünftigen Versionen. Vorhandene und neue Geräte, auf denen diese Version von ausgeführt wird Android wird dringend geraten, diese Anforderungen jetzt zu erfüllen, können sie ein Upgrade auf die zukünftigen Plattform-Releases durchführen.
[C-1-13] MÜSSEN während der NFC-Erkennung alle unterstützten Technologien abrufen. .
SOLLTEN Sie sich im NFC-Erkennungsmodus befinden, während das Gerät aktiv ist und das Gerät Bildschirm aktiv und der Sperrbildschirm entsperrt.
SOLLTEN Barcode und URL (falls codiert) von NFC-Barcode von Thinfilm zu verbessern.
Beachten Sie, dass öffentlich verfügbare Links für JIS, ISO und NFC nicht verfügbar sind. oben zitierte Forenspezifikationen.
Android unterstützt den NFC-Modus "Host Card Emulation" (HCE).
Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz enthalten (für NfcA und/oder NfcB und unterstützen das Routing von Anwendungs-IDs (AID) wie folgt:
- [C-2-1] MÜSSEN die
android.hardware.nfc.hce
-Funktionskonstante melden. - [C-2-2] MÜSSEN NFC HCE APIs als die im Android SDK definiert sind.
Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz enthalten für NfcF und zur Implementierung der Funktion für Anwendungen von Drittanbietern:
- [C-3-1] MÜSSEN die
android.hardware.nfc.hcef
-Funktionskonstante melden. - [C-3-2] MÜSSEN die NfcF Card Emulation APIs implementieren wie im Android SDK definiert.
Wenn Geräteimplementierungen allgemeinen NFC-Support wie in diesem MIFARE-Technologien (MIFARE Classic, MIFARE Ultralight, NDEF auf MIFARE Classic) in der Rolle „Leser/Autor“:
- [C-4-1] MÜSSEN die entsprechenden Android-APIs gemäß den das Android SDK.
- [C-4-2] MÜSSEN die Funktion
com.nxp.mifare
aus 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:
<ph type="x-smartling-placeholder">
- </ph>
- [C-0-4] MÜSSEN die IPv6-Verbindungen im Stromsparmodus aufrechterhalten.
- [C-0-5] Ratenbegrenzung DARF NICHT zum Verlust von IPv6 auf dem Gerät führen. mit einem IPv6-kompatiblen Netzwerk, das RA-Lebensdauer mindestens 180 Sekunden lang.
- MÜSSEN sicherstellen, dass die IPv6-Kommunikation so zuverlässig ist wie IPv4, zum Beispiel:
<ph type="x-smartling-placeholder">
- [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 wieconnect()
) 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 Support beinhalten für 802.1.15.4 und stellen die Funktionalität einer Drittanbieteranwendung zur Verfügung. dann:
- [C-1-1] MÜSSEN die entsprechende Android API in android.uwb implementieren.
- [C-1-2] MÜSSEN das Hardwarefunktions-Flag „android.hardware.uwb“ melden.
- [C-1-3] MUSS alle relevanten UWB-Profile unterstützen, die in Android definiert sind Implementierung.
- [C-1-4] MÜSSEN eine Funktion anbieten, mit der Nutzer das UWB aktivieren und deaktivieren können. aktiviert/deaktiviert.
- [C-1-5] MÜSSEN erzwingen, dass Apps, die die UWB-Funkschnittstelle verwenden, die Berechtigung UWB_RANGING verwenden (unter der Berechtigungsgruppe NEARBY_GERÄTE).
- [C-SR-1] EMPFOHLEN, die relevanten Konformitäts- und Zertifizierungstests, die von Standardorganisationen definiert wurden, darunter: FIRA und CC und CSA.
- [C-1-6] MÜSSEN darauf achten, dass die Entfernungsmessungen bei 95 % zwischen +/-15 cm liegen der Messungen in der Sichtweite bei 1 m Entfernung in einem nicht reflektierende Kammer.
- [C-1-7] MÜSSEN darauf achten, dass der Medianwert der Entfernungsmessungen bei 1 m liegt. vom Referenzgerät entfernt liegt [0,75 m bis 1,25 m], wo Ground-Truth-Wert Der Abstand wird vom oberen Rand des DUTs gemessen.
- [C-SR-2] Wir empfehlen dringend, die Schritte zur Einrichtung der Analyse zu befolgen angegeben in Voraussetzungen für die Anwesenheitskalibrierung
7.5 Kameras
Wenn eine Geräteimplementierung mindestens eine Kamera umfasst, gilt Folgendes:
- [C-1-1] MUSS das Funktions-Flag
android.hardware.camera.any
deklarieren. - [C-1-2] MÜSSEN möglich sein, damit eine Anwendung gleichzeitig 3 RGBA_8888-Bitmaps, die der Größe der Bilder entsprechen, Kamerasensor mit der größten Auflösung des Geräts, während die Kamera für die und trotzdem erfassen.
- [C-1-3] MÜSSEN sicherstellen, dass die vorinstallierte Kamera-App
Umgang mit Intents
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, 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 nach außen gerichtete Kamera, die Szenen von der äußeren Seite wie bei einer herkömmlichen Kamera; auf Handheld-Geräten, d. h. eine Kamera an der Seite des Geräts gegenüber dem Display.
Geräteimplementierungen:
- SOLLTE eine Rückkamera enthalten.
Wenn Geräteimplementierungen mindestens eine Kamera auf der Rückseite enthalten, ist Folgendes zu beachten:
- [C-1-1] MÜSSEN die Funktions-Flags
android.hardware.camera
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 für den Nutzer in der Regel zum Aufnehmen von Fotos z. B. für Videokonferenzen und ähnliche Anwendungen; auf Handheld Geräte, also eine Kamera, die sich an der Seite des Geräts wie das Display befindet.
Geräteimplementierungen:
- KANN eine Frontkamera enthalten.
Wenn Geräteimplementierungen mindestens eine Frontkamera umfassen, ist Folgendes zu beachten:
- [C-1-1] MÜSSEN die Funktions-Flags
android.hardware.camera.any
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
Eine externe Kamera ist eine Kamera, die an ihr angeschlossen oder von ihr getrennt werden kann. Geräteimplementierung und kann in jede Richtung ausgerichtet werden; wie USB Kameras.
Geräteimplementierungen:
- KÖNNEN auch Support für eine externe Kamera anbieten, die nicht unbedingt immer verbunden.
Wenn Geräteimplementierungen eine externe Kamera unterstützen, gilt Folgendes:
- [C-1-1] MÜSSEN das Funktions-Flag für die Plattform angeben.
android.hardware.camera.external
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 ist, die Daten im 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 steht, müssen die API-Callbacks dennoch "gefälscht" sein. wie beschrieben. - [C-0-6] MÜSSEN alle Parameternamen erkennen und berücksichtigen.
als Konstante in der
android.hardware.Camera.Parameters
und die 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] Für Geräte mit mehreren RGB-Kameras in
in die gleiche Richtung zeigen,
Es wird dringend empfohlen, ein logisches Kameragerät zu verwenden, das
Capability
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, bestehend aus allen RGB-Kameras, die als physische Untergeräte in diese Richtung weisen.
Wenn die Geräteimplementierungen eine proprietäre Kamera-API für Drittanbieter-Apps bereitstellen, Sie:
- [C-1-1] MÜSSEN eine solche Kamera-API mit
android.hardware.camera2
implementieren. der API erstellen. - KANN für
android.hardware.camera2
Anbieter-Tags und/oder Erweiterungen bereitgestellt werden. der API erstellen.
7.5.5 Kameraausrichtung
Wenn Geräte eine Front- oder Rückkamera haben, z. B. eine oder mehrere Kameras:
- [C-1-1] MÜSSEN so ausgerichtet werden, dass die lange Seite der Kamera die lange Dimension des Bildschirms. Das heißt, wenn das Gerät im Querformat gehalten wird MÜSSEN Kameras Bilder im Querformat erfassen. Dieses wird unabhängig von der natürlichen Ausrichtung des Geräts angewendet; d. h., sie gilt für primär Geräte im Querformat und primäre Geräte im Hochformat.
Geräte, die alle der folgenden Kriterien erfüllen, sind von der oben genannten Anforderung ausgenommen:
- Das Gerät verfügt über Displays mit variabler Geometrie, wie z. B. faltbare oder klappbare Displays. angezeigt wird.
- Wenn sich das zuklappen oder Scharnier des Geräts ändert, wechselt das Gerät zwischen Hochformat und primären zum Querformat und umgekehrt.
- Geräteimplementierungen, die nicht vom Nutzer rotiert werden können, z. B. wie Automobilgeräte.
7.6 Arbeitsspeicher und Datenspeicher
7.6.1 Mindestanforderungen an Arbeitsspeicher und Speicherplatz
Geräteimplementierungen:
- [C-0-1] MUSS mit einem Download-Manager die Anwendungen zum Herunterladen von Datendateien verwenden MÖCHTEN, und MÜSSEN in der Lage sein, Herunterladen einzelner Dateien von mindestens 100 MB „Cache“ Standort.
7.6.2 Freigegebener Anwendungsspeicher
Geräteimplementierungen:
- [C-0-1] MÜSSEN Speicherplatz anbieten, der von Anwendungen gemeinsam genutzt werden kann, auch häufig verwiesene als „freigegebener externer Speicher“, „freigegebener Anwendungsspeicher“ oder von der Linux- Pfad „/sdcard“ auf dem es bereitgestellt ist.
- [C-0-2] MÜSSEN so konfiguriert sein, dass standardmäßig freigegebener Speicher in anderen sofort einsatzbereit ist, unabhängig davon, ob die Speicherkapazität eine interne Speicherkomponente oder ein austauschbares Speichermedium (z.B. Secure Steckplatz für digitale Karte).
- [C-0-3] MÜSSEN den freigegebenen Speicher der Anwendung direkt unter dem Linux-Pfad bereitstellen.
sdcard
oder symbolischen Linux-Link 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:
<ph type="x-smartling-placeholder">
- </ph>
- 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:
<ph type="x-smartling-placeholder">
- </ph>
- Einen Typ-C-Anschluss auf dem Gerät haben oder mit einem oder mehreren Kabeln für das entsprechende Gerät versenden proprietären Port mit einem Standard-USB-Typ-C-Port (USB-Typ-C-Gerät) verbinden.
- ein Gerät Typ A auf dem Gerät haben oder mit einem oder mehreren Kabeln ausgeliefert werden, die das Gerät anpassen Anschluss an einen Standard-USB-Typ-A-Port.
- über einen Micro-AB-Port auf dem Gerät verfügen, der mit einem Kabeladapter geliefert werden sollte Standard-A-Port anzuschließen.
- [C-1-3] DÜRFEN NICHT mit einem Adapter geliefert werden, der von USB Typ A oder micro-AB-Ports mit einem Typ-C-Port (Buchse).
- [C-SR-1] wird dringend empfohlen, die USB-Audiokurs wie in der Android SDK-Dokumentation beschrieben.
- SOLLTEN das Laden des verbundenen USB-Peripheriegeräts unterstützen, während es auf dem Host ist mode; mit einer Stromquelle von mindestens 1,5 A gemäß den Abschnitt "Kündigungsparameter" der USB Typ-C-Kabel und -Anschlussspezifikation, Version 1.2 für USB Typ-C Anschlussstecker oder verwenden Sie den CDP-Ausgangsstrombereich des Ladekabels als in den Spezifikationen zum Laden des USB-Akkus, Version 1.2 für Micro-AB-Connectors.
- SOLLTEN USB-Typ-C-Standards implementieren und unterstützen.
Wenn die Geräteimplementierung einen USB-Anschluss umfasst, der den Hostmodus unterstützt, und das USB-Kabel Audioklasse:
- [C-2-1] MUSS die USB HID-Klasse unterstützen.
- [C-2-2] MUSS die Erkennung und Zuordnung der folgenden HID-Daten unterstützen
Felder, die in den USB HID-Nutzungstabellen angegeben sind
und die Anfrage zur Nutzung von Voice Command
für
KeyEvent
wie unten dargestellt:- Nutzungsseite (0xC) Nutzungs-ID (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- Nutzungsseite (0xC) Nutzungs-ID (0x0E9):
KEYCODE_VOLUME_UP
- Nutzungsseite (0xC) Nutzungs-ID (0x0EA):
KEYCODE_VOLUME_DOWN
- Nutzungsseite (0xC) Nutzungs-ID (0x0CF):
KEYCODE_VOICE_ASSIST
- 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, Bei WLAN oder Mobilfunknetzen ist kein „Ausgabeport“ enthalten.
7.8.2.1 Analoge Audioanschlüsse
Um mit den Headsets und anderes Audiozubehör über den 3,5-mm-Audiostecker aus dem Android-Ökosystem, Implementierungen umfassen einen oder mehrere analoge Audioports. Sie:
- [C-SR-1] Es wird dringend empfohlen, mindestens eines der Audioport(s) als 3,5-mm-Audioanschluss mit 4 Kabeln.
Geräteimplementierungen mit einem 3, 5-mm-Audioanschluss mit 4 Kabeln:
- [C-1-1] MÜSSEN die Audiowiedergabe über Stereo-Kopfhörer und -Headsets unterstützen. mit einem Mikrofon.
- [C-1-2] MUSS TRRS-Audiostecker mit CTIA-Pin-out-Reihenfolge unterstützen.
- [C-1-3] MUSS die Erkennung und Zuordnung zu den Keycodes für die
der dreifachen äquivalenten Impedanz zwischen Mikrofon und Erde
Kabeln am Audiostecker:
<ph type="x-smartling-placeholder">
- </ph>
- Max. 70 Ohm:
KEYCODE_HEADSETHOOK
- 210–290 Ohm:
KEYCODE_VOLUME_UP
- 360–680 Ohm:
KEYCODE_VOLUME_DOWN
- Max. 70 Ohm:
- [C-1-4] MUSS
ACTION_HEADSET_PLUG
bei Steckereinsatz auslösen, aber Erst nachdem alle Kontakte der Steckdose die relevanten Segmente berührt haben am Anschluss. - [C-1-5] MUSS mindestens 150 mV ± 10% der Ausgangsspannung eine Lautsprecherimpedanz von 32 Ohm.
- [C-1-6] MÜSSEN über eine Mikrofonspannung zwischen 1,8 und 2,9 V verfügen.
- [C-1-7] MUSS den Schlüsselcode für Folgendes erkennen und zuordnen
Bereich der äquivalenten Impedanz zwischen Mikrofon und Erdleitern
am Audiostecker:
<ph type="x-smartling-placeholder">
- </ph>
- 110–180 Ohm:
KEYCODE_VOICE_ASSIST
- 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 Nah-Ultraschall-Audiofunktion über die AudioManager.getProperty API so:
Wenn PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
„true“ ist, MÜSSEN die folgenden Anforderungen vom
Audioquellen VOICE_RECOGNITION
und UNPROCESSED
:
- [C-1-1] Der durchschnittliche Stromeingang des Mikrofons im Band von 18,5 kHz bis 20 kHz DÜRFEN nicht mehr als 15 dB unter dem Antwortwert bei 2 kHz liegen.
- [C-1-2] Ungewichtetes Signal-Rausch-Verhältnis des Mikrofons über 18,5 kHz bis 20 kHz für einen 19-kHz-Ton bei -26 dBFS MUSS nicht niedriger als 50 dB sein.
Wenn PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
ist „true“:
- [C-2-1] Der Mittelwert des Lautsprechers in einem Bereich von 18,5 kHz bis 20 kHz DARF nicht unter 40 dB unter dem Wert bei 2 kHz liegen.
7.8.4 Signalintegrität
Geräteimplementierungen:
- SOLLTEN Sie für beide Eingänge einen störungsfreien Audiosignalpfad bereitstellen. und Ausgabestreams auf Handheld-Geräten. während eines Tests von einer Minute pro Pfad gemessen. Mit OboeTester testen „Automatisierter Glitch-Test“.
Für den Test ist ein Audio-Loopback-Dongle erforderlich. wird direkt in einer 3,5-mm-Buchse und/oder in Kombination mit einem USB-C-zu-3,5-mm-Adapter verwendet. Alle Audioausgangsports SOLLTEN getestet werden.
OboeTester unterstützt derzeit AAudio-Pfade, sodass der folgende Kombinationen SOLLTEN mit AAudio auf Fehler getestet werden:
Performance-Modus | Inhalte teilen | Aus Stichprobenrate | In Chans | Out Chans |
---|---|---|---|---|
NIEDRIGE_LATENZ | EXKLUSIV | KEINE ANGABE | 1 | 2 |
NIEDRIGE_LATENZ | EXKLUSIV | KEINE ANGABE | 2 | 1 |
NIEDRIGE_LATENZ | Weiterempfohlen | KEINE ANGABE | 1 | 2 |
NIEDRIGE_LATENZ | Weiterempfohlen | KEINE ANGABE | 2 | 1 |
KEINE | Weiterempfohlen | 48000 | 1 | 2 |
KEINE | Weiterempfohlen | 48000 | 2 | 1 |
KEINE | Weiterempfohlen | 44100 | 1 | 2 |
KEINE | Weiterempfohlen | 44100 | 2 | 1 |
KEINE | Weiterempfohlen | 16000 | 1 | 2 |
KEINE | Weiterempfohlen | 16000 | 2 | 1 |
Ein zuverlässiger Stream sollte die folgenden Kriterien für Signal-Rauschen erfüllen Verhältnis (SNR) und Total Harmonic Distortion (THD) für einen Sinus von 2.000 Hz.
Wandler | THD | SNR-Fehler |
---|---|---|
primärer eingebauter Lautsprecher, gemessen mit einem externen Referenzmikrofon | < 3,0% | >= 50 dB |
primäres integriertes Mikrofon, gemessen mit einem externen Referenzlautsprecher | < 3,0% | >= 50 dB |
Integrierte analoge 3,5-mm-Anschlüsse, getestet mit dem Loopback-Adapter | < 1 % | >= 60 dB |
Mit dem Smartphone gelieferte USB-Adapter, die mit dem Loopback-Adapter getestet wurden | < 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:
<ph type="x-smartling-placeholder">
- </ph>
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] WIRDEN DRINGEND empfohlen,
TYPE_HARDWARE_BUFFER
Direktkanaltyp für alle oben aufgeführten Arten von direkten Kanälen. - [C-1-21] MUSS die Anforderungen des Gyroskops, des Beschleunigungsmessers und des Magnetometers erfüllen.
Anforderungen für
android.hardware.hifi_sensors
, wie angegeben in Abschnitt 7.3.9. - [C-SR-8] WIRDEN DRINGEND empfohlen,
Funktion „
android.hardware.sensor.hifi_sensors
“. - [C-1-22] MUSS eine End-to-End-Latenz von Bewegung zu Photon aufweisen, die nicht höher ist als 28 Millisekunden.
- [C-SR-9] WIRD UNBEDINGT EMPFOHLEN, eine End-to-End-Latenz von Bewegung zu Photon zu haben höchstens 20 Millisekunden.
- [C-1-23] MÜSSEN das Verhältnis für den ersten Frame haben. Dies ist das Verhältnis zwischen Helligkeit der Pixel im ersten Frame nach einem Übergang von Schwarz zu Weiß und die Helligkeit weißer Pixel im stabilen Zustand von mindestens 85%.
- [C-SR-10] Es wird dringend empfohlen, ein Verhältnis für den ersten Frame von mindestens 90 % zu haben.
- KANN einen exklusiven Kern für den Vordergrund bereitstellen.
Anwendung und KÖNNEN die
Process.getExclusiveCores
API unterstützen, um die Anzahl der CPU-Kerne, die ausschließlich im oberen Vordergrund vorhanden sind .
Wenn der exklusive Kern unterstützt wird, gilt für den Kern Folgendes:
- [C-2-1] DÜRFEN die Ausführung anderer Userspace-Prozesse auf dem Tab zulassen (außer Gerätetreiber, die von der Anwendung verwendet werden), aber einige Kernel zulassen KÖNNEN Prozesse nach Bedarf auszuführen.
7:10. Haptik
Geräte, die in der Hand gehalten oder getragen werden, können eine allgemeine Haptik enthalten Bedienelement, das für Anwendungen wie das Erzeugen von Aufmerksamkeit verfügbar ist durch Klingeltöne, Alarme, Benachrichtigungen und allgemeines Touch-Feedback.
Wenn Geräteimplementierungen KEINEN derartigen haptischen Bedienelements für allgemeine Zwecke enthalten, Sie:
- [7.10/C] MUSS für
Vibrator.hasVibrator()
"false" zurückgeben.
Wenn Geräteimplementierungen mindestens eine solche Universalhaptik enthalten Bedienelement:
- [C-1-1] MUSS für
Vibrator.hasVibrator()
"true" zurückgeben. - DU DARF KEINEN haptischen Bedienungselement mit exzentrischer rotierender Masse (ERM) verwendet werden.
- SOLLTEN alle öffentlichen Konstanten für eine eindeutige Haptik implementieren
in
android.view.HapticFeedbackConstants
nämlich (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
undGESTURE_END
). - SOLLTEN alle öffentlichen Konstanten für eine eindeutige Haptik implementieren
in
android.os.VibrationEffect
nämlich (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
undEFFECT_DOUBLE_CLICK
) und alle zulässigen öffentlichenPRIMITIVE_*
-Konstanten für Hohe Haptik inandroid.os.VibrationEffect.Composition
(CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
undTHUD
). Einige dieser Primitive, z. B.LOW_TICK
undSPIN
sind möglicherweise nur realisierbar, wenn die Vibration relativ niedrige Frequenzen. - SOLLTEN Sie den Richtlinien für die Kartierung öffentlicher Konstanten folgen.
in
android.view.HapticFeedbackConstants
den empfohlenenandroid.os.VibrationEffect
mit den entsprechenden Amplitudenbeziehungen. - SOLLTE diese verknüpften Zuordnungen der haptischen Konstanten verwenden.
- SOLLTEN Sie die Qualitätsprüfung durchlaufen
für
createOneShot()
undcreateWaveform()
APIs - SOLLTEN bestätigt werden, dass das Ergebnis der öffentlichen
android.os.Vibrator.hasAmplitudeControl()
API die Vibrationsfähigkeiten des Nutzers korrekt widerspiegelt. - SOLLTEN die Funktionen für die Amplituden-Skalierbarkeit durch Ausführung von
android.os.Vibrator.hasAmplitudeControl()
prüfen.
Wenn Geräteimplementierungen der Zuordnung der haptischen Konstanten folgen, gilt Folgendes:
- SOLLTEN Sie den Implementierungsstatus überprüfen, indem Sie
android.os.Vibrator.areAllEffectsSupported()
ausführen. undandroid.os.Vibrator.arePrimitivesSupported()
APIs - SOLLTE eine Qualitätsprüfung durchführen für haptische Konstanten.
- SOLLTEN Sie die Fallback-Konfiguration für nicht unterstützte Primitive wie im Implementierungsleitfaden beschrieben nach Konstanten.
- SOLLTE Fallback-Unterstützung bereitgestellt werden, um das Fehlerrisiko wie beschrieben zu minimieren. hier.
7:11. Media Performance-Klasse
Die Medienleistungsklasse der Geräteimplementierung finden Sie hier:
die android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
API. Anforderungen
für Medienleistungsklasse sind für jede Android-Version definiert, beginnend mit
R (Version 30). Der spezielle Wert 0 bedeutet, dass das Gerät kein
der Medienleistung.
Wenn Geräteimplementierungen einen Wert ungleich null zurückgeben für
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, sie/er:
[C-1-1] MUSS mindestens den Wert
android.os.Build.VERSION_CODES.R
zurückgeben.[C-1-2] MUSS die Implementierung eines Handheld-Geräts sein.
[C-1-3] MÜSSEN alle Anforderungen für die Medienleistungsklasse erfüllen. beschrieben in Abschnitt 2.2.7.
Mit anderen Worten: Die Medienleistungsklasse in Android T ist nur für der Version T, S oder R.
Siehe Abschnitt 2.2.7 für gerätespezifische Anforderungen.
8. Leistung und Leistung
Einige Mindestanforderungen an Leistung und Leistung sind entscheidend für die User Experience und wirken sich auf die grundlegenden Annahmen aus, von denen Entwickelnde bei der Entwicklung
8.1. Konsistente Nutzererfahrung
Eine reibungslose Benutzeroberfläche kann für Endanwendende bereitgestellt werden, wenn bestimmte Mindestanforderungen, um eine konsistente Framerate und konsistente Antwortzeiten für Apps und Spiele. Geräteimplementierungen je nach Gerätetyp KÖNNEN messbare Anforderungen an die Latenz der Benutzeroberfläche und die Aufgabe wie in Abschnitt 2 beschrieben.
8.2. Leistung des Datei-E/A-Zugriffs
Bereitstellung einer gemeinsamen Basis für eine konsistente Leistung beim Dateizugriff auf der
Der private Datenspeicher einer Anwendung (/data
Partition) ermöglicht App-Entwicklern
eine angemessene Erwartung festzulegen,
die ihrem Softwaredesign helfen würde. Gerät
für Implementierungen, KANN je nach Gerätetyp bestimmte Anforderungen erfüllen
wie in Abschnitt 2 beschrieben
und Schreibvorgänge:
- Leistung sequentieller Schreibvorgänge: Gemessen durch Schreiben einer 256 MB-Datei mit 10 MB Zwischenspeicher
- Zufällige Schreibleistung: Gemessen durch Schreiben einer 256 MB großen Datei mit 4 KB Schreibpuffer.
- Leistung sequentieller Lesevorgänge: Gemessen durch Lesen einer 256 MB-Datei mit 10 MB Zwischenspeicher
- Zufällige Leseleistung: Gemessen durch Lesen einer 256 MB großen Datei mit 4 KB Schreibpuffer.
8.3. Energiesparmodi
Wenn Geräteimplementierungen Funktionen zur Verbesserung der Energieverwaltung von Geräten enthalten die in AOSP enthalten sind (z.B. App Standby-Bucket, Stromsparmodus) oder die Funktionen erweitern um stärkere Einschränkungen als den EINGESCHRÄNKTEN App-Standby-Bucket anzuwenden, gilt Folgendes:
- [C-1-1] DARF NICHT von der AOSP-Implementierung für das Auslösen abweichen, Wartung, Wakeup-Algorithmen und der Verwendung globaler Systemeinstellungen Gerätekonfiguration des App-Standbys und des Stromsparmodus.
- [C-1-2] DÜRFEN NICHT von der AOSP-Implementierung abweichen, wenn Sie globale oder DeviceConfig nutzen, um die Drosselung von Jobs, Alarmen und Netzwerk für Anwendungen in jedem Bucket für Anwendungs-Standby-Modus.
- [C-1-3] DÜRFEN NICHT von der AOSP-Implementierung bezüglich der Anzahl der App-Standby-Buckets die für App-Standby verwendet werden.
- [C-1-4] MÜSSEN App-Standby-Buckets implementieren. und Stromsparmodus, wie unter Energiesparmodus beschrieben.
- [C-1-5] MUSS
true
zurückgeben fürPowerManager.isPowerSaveMode()
wenn sich das Gerät im Energiesparmodus befindet. - [C-1-6] MÜSSEN Nutzern Angebote zur Anzeige aller ausgenommenen Apps anbieten. aus den Energiesparmodi „App Standby“ und „Stromsparmodus“ oder und MÜSSEN die ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS implementieren. Absicht, den Nutzer aufzufordern, einer App das Ignorieren des Akkus zu erlauben Optimierungen vor.
- [C-SR-1] EMPFOHLEN, Nutzern ein solches Angebot zu bieten, um den Energiesparmodus zu deaktivieren.
- [C-SR-2] EMPFOHLEN, Nutzern alle Inhalte anzuzeigen Apps, die vom App-Standby- und Stromsparmodus ausgenommen sind
Wenn bei der Implementierung von Geräten die enthaltenen Energieverwaltungsfunktionen erweitert werden in AOSP ist und diese Erweiterung strengere Einschränkungen anwendet den Seltenen App-Standby-Bucket, siehe Abschnitt 3.5.1.
Zusätzlich zu den Energiesparmodi können Implementierungen auf Android-Geräten einen oder alle der vier Schlaf-Leistungsstatus gemäß Definition in der Configuration and Power Interface (ACPI)
Wenn Geräteimplementierungen den S4-Leistungsstatus gemäß Definition durch den ACPI führen sie
- [C-1-1] MÜSSEN diesen Status erst erhalten, nachdem der Nutzer eine explizite Aktion ausgeführt hat. das Gerät in den inaktiven Zustand zu versetzen, etwa durch Schließen eines Teil des Geräts oder zum Abschalten eines Fahrzeugs oder Fernsehers) und bevor die Nutzer aktiviert das Gerät wieder, z.B. durch Öffnen des Deckels oder Drehen des Fahrzeugs oder den Fernseher wieder einschalten).
Wenn Geräteimplementierungen den S3-Stromzustand gemäß Definition durch den ACPI führen sie
[C-2-1] MÜSSEN die obigen C-1-1-Anforderungen erfüllen oder nur in den S3-Status wechseln, wenn Drittanbieter Anwendungen benötigen keine Systemressourcen (z.B. Bildschirm, CPU).
Umgekehrt MÜSSEN den S3-Status beendet werden, wenn Drittanbieter-Anwendungen den Systemressourcen, wie in diesem SDK beschrieben.
Beispiel: Während Anwendungen von Drittanbietern anfordern, dass der Bildschirm bis
FLAG_KEEP_SCREEN_ON
weiterlaufen lassen,PARTIAL_WAKE_LOCK
, DARF das Gerät NICHT in den S3-Status wechseln, außer wie beschrieben In C-1-1 hat der Nutzer eine explizite Aktion ausgeführt, um das Gerät in einen inaktiv. Umgekehrt kann eine Aufgabe, die von Drittanbieter-Apps durch JobScheduler implementiert wird oder Firebase Cloud Messaging Drittanbieter-Apps bereitgestellt werden, MUSS das Gerät den S3-Status beenden, es sei denn, Nutzer hat das Gerät in den Status „Inaktiv“ versetzt. Sie sind nicht umfassend Beispiele und AOSP im