Änderungsprotokoll für das Dokument zur Android-Kompatibilitätsdefinition

Android 14

26. Juni 2024

2. Gerätetypen

  • 2.2.1 Hardware:

    Überarbeitung ansehen

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

    Überarbeitung ansehen

    Neue Anforderungen erstellen

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

  • 2.4.1 Hardware:

    Überarbeitung ansehen

    Neue Anforderungen erstellen

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

  • 2.5.1 Hardware:

    Überarbeitung ansehen

    Neue Anforderungen erstellen

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

3. Software

  • 3.2.2 Build-Parameter:

    Für den Parameter „ODM_SKU“:

    Überarbeitung ansehen

    Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck ^([0-9A-Za-z.,_-]+)$ entsprechen.

5. Multimedia-Kompatibilität

  • 5.1.3 Details zu Audio-Codecs:

    Es wurden Details für das Vorbis-Format/Codec hinzugefügt:

    Überarbeitung ansehen

    Decodierung: Unterstützung für Mono-, Stereo-, 5.0- und 5.1-Inhalte mit Abtastraten von 8.000, 12.000, 16.000, 24.000 und 48.000 Hz.
    Codierung: Unterstützung für Mono- und Stereoinhalte mit Abtastraten von 8.000, 080, 120, 120, 120 Hz und 120 Hz

7. Hardwarekompatibilität

  • 7.1.4.2 Vulkan:

    Überarbeitung ansehen

  • 7.7.1 USB-Peripheriemodus:

    Entfernung von:

    Überarbeitung ansehen

    • SOLLTEN NICHT das in der Android Open Accessory Protocol 2.0-Dokumentation dokumentierte AOAv2-Audio implementiert werden. AOAv2 Audio wird ab Android-Version 8.0 (API-Level 26) eingestellt.

9. Kompatibilität des Sicherheitsmodells

  • 9.7 Sicherheitsfunktion:

    [C-SR-1] wurde zum Entfernen duplizierter Inhalte in [C-SR-7] umbenannt und [C-SR-8] entfernt:

    Überarbeitung ansehen

    • [C-SR-1] EMPFOHLEN, Kerneldaten, die nur während der Initialisierung geschrieben werden, nach der Initialisierung als schreibgeschützt markiert zu behalten (z.B. __ro_after_init).

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

    • [C-SR-3] wird dringend empfohlen, die Kontrollflussintegrität (Control Flow Integrity, CFI) im Kernel zu aktivieren, um zusätzlichen Schutz vor Code-Wiederverwendungsangriffen (z.B. CONFIG_CFI_CLANG und CONFIG_SHADOW_CALL_STACK) zu bieten.

    • [C-SR-4] Es wird DRINGEND empfohlen, die Kontrollflussintegrität (Control-Flow Integrity, CFI), den Shadow Call Stack (SCS) oder die Integer Overflow-Bereinigung (IntSan) für Komponenten, für die sie aktiviert ist, nicht zu deaktivieren.

    • [C-SR-5] wird dringend empfohlen, CFI, SCS und IntSan für alle zusätzlichen sicherheitsrelevanten Userspace-Komponenten zu aktivieren, wie unter CFI und IntSan erläutert.

    • [C-SR-6] wird dringend empfohlen, die Stack-Initialisierung im Kernel zu aktivieren, um die Verwendung nicht initialisierter lokaler Variablen (CONFIG_INIT_STACK_ALL oder CONFIG_INIT_STACK_ALL_ZERO) zu verhindern. Außerdem sollten Geräteimplementierungen NICHT den Wert annehmen, der vom Compiler zur Initialisierung der lokalen Variablen verwendet wird.

    • [C-SR-7] wird dringend empfohlen, die Heap-Initialisierung im Kernel zu aktivieren, um die Verwendung nicht initialisierter Heap-Zuweisungen (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) zu verhindern, und SOLLTE NICHT von dem Wert ausgehen, der vom Kernel zum Initialisieren dieser Zuweisungen verwendet wird.

  • 9.11 Schlüssel und Anmeldedaten:

    Überarbeitung ansehen

    • [C-1-6] MUSS eine der folgenden Funktionen unterstützen:
      • IKeymasterDevice 3.0
      • IKeymasterDevice 4.0
      • IKeymasterDevice 4.1
      • IKeyMintDevice Version 1 oder
      • IKeyMintDevice Version 2.

  • 9.11.1 Sicherer Sperrbildschirm, Authentifizierung und virtuelle Geräte:

    Überarbeitung ansehen

    • [C-8-3] Sie DÜRFEN KEINE API zur Verwendung durch Drittanbieter-Apps zur Verfügung stellen, um den Sperrstatus zu ändern.

    Überarbeitung ansehen

    • [C-12-4] MUSS TrustManagerService.revokeTrust() aufrufen.
      • Nach spätestens 24 Stunden nach Erteilung der Vertrauensstellung oder
      • Nach acht Stunden Inaktivität oder
      • Wenn die Implementierungen keine kryptografisch sichere und präzise Bereichserkennung wie in [C-12-5] definiert verwenden, wenn die zugrunde liegende Verbindung zum nahe gelegenen physischen Gerät unterbrochen wird.
    • [C-12-5] Implementierungen, die sich auf eine sichere und genaue Bereichserkennung stützen, um die Anforderungen von [C-12-4] zu erfüllen, MÜSSEN eine der folgenden Lösungen verwenden:
      • Implementierungen mit UWB:
        • MÜSSEN die in 7.4.9 beschriebenen Konformitäts-, Zertifizierungs-, Genauigkeits- und Kalibrierungsanforderungen für UWB erfüllen.
        • MÜSSEN einen der unter 7.4.9 aufgeführten P-STS-Sicherheitsmodi verwenden.
      • Implementierungen unter Verwendung von Wi-Fi Neighborhood Awareness Networking (NAN):
        • MÜSSEN die Anforderungen an die Genauigkeit in 2.2.1 [7.4.2.5/H-SR-1] erfüllen, die Bandbreite von 160 MHz (oder höher) verwenden und die unter Anwesenheitskalibrierung beschriebenen Schritte zur Einrichtung der Messung ausführen.
        • MÜSSEN Secure LTF gemäß IEEE 802.11az verwenden.

8. April 2024

2. Gerätetypen

  • 2.2.1 Hardware:

    Überarbeitung ansehen

    Neue Anforderungen erstellen

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

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

  • 2.2.5 Sicherheitsmodell:

    Überarbeitung ansehen

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

    • [9.8/H-1-6] DARF NICHT zulassen, dass bei jedem erfolgreichen Hotword-Ergebnis mehr als 100 Byte Daten aus dem Hotword-Erkennungsdienst übertragen werden, mit Ausnahme von Audiodaten, die über HotwordAudioStream weitergeleitet werden.

    Überarbeitung ansehen

    Ändern Sie [9.8/H-1-13] in:

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

    Überarbeitung ansehen

    Anforderungen entfernt [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].

  • 2.2.7.2 Kamera:

    Überarbeitung ansehen

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

    • [7.5/H-1-3] MUSS die Eigenschaft android.info.supportedHardwareLevel als FULL oder besser für die rückwärtige primäre Kamera und LIMITED oder besser für die primäre Frontkamera unterstützen.

  • 2.3.2 Multimedia:

    Überarbeitung ansehen

    Wenn Fernsehgeräte nicht über einen integrierten Bildschirm verfügen, sondern stattdessen einen über HDMI angeschlossenen externen Bildschirm unterstützen, gilt Folgendes:

    • [5.8/T-0-1] MÜSSEN für den HDMI-Ausgabemodus die höchste Auflösung für das ausgewählte Pixelformat eingestellt werden, die mit einer Aktualisierungsrate von 50 Hz oder 60 Hz für den externen Bildschirm funktioniert. Dies hängt von der Videoaktualisierungsrate in der Region ab, in der das Gerät verkauft wird. MÜSSEN im HDMI-Ausgabemodus die maximale Auflösung ausgewählt werden, die mit einer Aktualisierungsrate von 50 Hz oder 60 Hz unterstützt wird.

3. Software

5. Multimedia-Kompatibilität

  • 5.3.8 Dolby Vision:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen die Unterstützung für den Dolby Vision-Decoder über HDR_TYPE_DOLBY_VISION deklarieren, geschieht Folgendes:

    • [C-1-3] MÜSSEN die Track-ID der abwärtskompatiblen Basisebenen (falls vorhanden) mit der Track-ID der kombinierten Dolby Vision-Ebene übereinstimmen.

7. Hardwarekompatibilität

  • 7.1.1.1 Bildschirmgröße und ‐form:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen Bildschirme unterstützen, die für die Größenkonfiguration UI_MODE_TYPE_NORMAL geeignet sind und physische Displays mit abgerundeten Ecken zum Rendern dieser Bildschirme verwendet werden, gilt Folgendes:

    • [C-1-1] MÜSSEN sicherstellen, dass für jedes dieser Displays mindestens eine der folgenden Anforderungen erfüllt ist:
      • Wenn in jeder Ecke der logischen Anzeige ein Feld mit 15 und 18 dp × 1518 dp verankert ist, ist mindestens ein Pixel jedes Felds auf dem Bildschirm sichtbar.

  • 7.4.3 Bluetooth:

    Überarbeitung ansehen

    Die folgenden Anforderungen wurden reaktiviert:

    Wenn in Geräteimplementierungen FEATURE_BLUETOOTH_LE deklariert wird, gilt Folgendes:

    • [C-SR-2] Es wird dringend empfohlen, den Rx-Versatz zu messen und zu kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei 1 m Abstand zu einem Referenzgerät, das die Übertragung an ADVERTISE_TX_POWER_HIGH sendet, bei -60 dBm +/-10 dB liegt. Die Geräte sind so ausgerichtet, dass sie auf „parallelen Ebenen“ mit Bildschirmen in die gleiche Richtung ausgerichtet sind.

    • [C-SR-3] Es wird dringend empfohlen, den Tx-Offset zu messen und zu kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -60 dBm +/-10 dB liegt, wenn das Scannen von einem Referenzgerät, das in 1 m Entfernung positioniert ist, und die Übertragung unter ADVERTISE_TX_POWER_HIGH erfolgt, wobei die Geräte so ausgerichtet sind, dass sie sich auf parallelen Ebenen befinden und Bildschirme in die gleiche Richtung zeigen.

    Überarbeitung ansehen

    Die Anforderungen [C-10-3] und [C-10-4] wurden in 2.2.1. Hardware.

    • [C-10-3] MÜSSEN den Rx-Offset messen und kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -55 dBm +/-10 dB in 1 m Entfernung von einem Referenzgerät liegt, das bei ADVERTISE_TX_POWER_HIGH sendet.
    • [C-10-4] MÜSSEN den Tx-Offset messen und kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -55 dBm +/-10 dB liegt, wenn beim Scannen von einem Referenzgerät, das in einer Entfernung von 1 m positioniert ist, und bei der Übertragung bei ADVERTISE_TX_POWER_HIGH liegt.

20. November 2023

2. Gerätetypen

  • 2.2.1 Hardware:

    Überarbeitung ansehen

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

  • 2.2.7.2 Kamera:

    Überarbeitung ansehen

    • [7.5/H-1-13] MUSS die LOGICAL_MULTI_CAMERA-Funktion für die primäre rückseitige Kamera unterstützen, wenn mehr als eine RGB-Rückkamera vorhanden ist.

  • 2.3.2 Multimedia:

    Überarbeitung ansehen

    • [5.8/T-0-1] MÜSSEN den HDMI-Ausgabemodus auf die höchste Auflösung für das ausgewählte SDR- oder HDR-Format einstellen, die mit einer Aktualisierungsrate von 50 Hz oder 60 Hz für den externen Bildschirm funktioniert.

      MÜSSEN im HDMI-Ausgabemodus die maximale Auflösung ausgewählt werden, die mit einer Aktualisierungsrate von 50 Hz oder 60 Hz unterstützt wird.

  • 2.4.5 Sicherheitsmodell:

    Überarbeitung ansehen

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

6. Kompatibilität von Entwicklertools und -optionen

  • 6.1 Entwicklertools:

    Überarbeitung ansehen

    • [C-0-12] MUSS ein LMK_KILL_OCCURRED_FIELD_NUMBER-Atom in die

    Überarbeitung ansehen

    • [C-0-13] MÜSSEN den Shell-Befehl dumpsys gpu --gpuwork implementieren, um

9. Kompatibilität des Sicherheitsmodells

  • 9.7 Sicherheitsfunktionen:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen einen Linux-Kernel verwenden, der SELinux unterstützt, geschieht Folgendes:

    Überarbeitung ansehen

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

4. Oktober 2023

2. Gerätetypen

  • 2.2 Anforderungen für Handhelds:

    Überarbeitung ansehen

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

    • Bildschirmgröße der physischen Diagonale zwischen 4 Zoll 3,3 Zoll (oder 2,5 Zoll für Geräteimplementierungen, die mit API-Level 29 oder früher ausgeliefert wurden) bis 8 Zoll.

    Neue Anforderungen erstellen

    • über eine Touchscreen-Eingabeoberfläche verfügen.

  • 2.2.1 Hardware:

    Überarbeitung ansehen

    Implementierungen von Handheld-Geräten:

    • [7.1.1.1/H-0-1] MUSS mindestens ein Android-kompatibles Display haben, das alle in diesem Dokument beschriebenen Anforderungen erfüllt . Das Display hat eine Länge von mindestens 2,2 Zoll an der kurzen und 3,4 Zoll an der langen Seite.

    Wenn Implementierungen von Handheld-Geräten die Bildschirmdrehung durch Software unterstützen, gilt Folgendes:

    • [7.1.1.1/H-1-1]* MÜSSEN der logische Bildschirm, der für Anwendungen von Drittanbietern zur Verfügung gestellt wird, an den kurzen Seiten mindestens 2 Zoll und an den langen Kanten mindestens 2,7 Zoll lang sein. Geräte, die mit Android API-Level 29 oder niedriger ausgeliefert wurden, KÖNNEN von dieser Anforderung ausgenommen.

    Wenn Implementierungen von Handheld-Geräten die Bildschirmdrehung durch Software nicht unterstützen, geschieht Folgendes:

    • [7.1.1.1/H-2-1]* MÜSSEN die kurzen Seiten des logischen Bildschirms, der für Anwendungen von Drittanbietern zur Verfügung gestellt wird, mindestens 2,7 Zoll haben. Geräte, die mit Android API-Level 29 oder niedriger ausgeliefert wurden, KÖNNEN von dieser Anforderung ausgenommen.

    Neue Anforderungen erstellen

    • [7.1.1.1/H-0-3]* MÜSSEN jedes UI_MODE_NORMAL-Display, das für Anwendungen von Drittanbietern zur Verfügung gestellt wird, auf einem freien Bildschirmbereich platzieren, der an der kurzen Seite mindestens 2,2" und an der langen Seite 3,4" Zoll groß ist.

    • [7.1.1.3/H-0-1]* MÜSSEN den Wert von DENSITY_DEVICE_STABLE auf 92% oder größer als die tatsächliche Dichte des entsprechenden Bildschirms setzen.

    Wenn in Implementierungen von Handheld-Geräten android.hardware.audio.output und android.hardware.microphone deklariert sind, gilt Folgendes:

    • [5.6/H-1-1] MUSS über die Datenpfade „Lautsprecher zu Mikrofon“, 3,5 mm Loopback-Adapter (falls unterstützt), USB-Loopback-Adapter (falls unterstützt) eine durchschnittliche Latenz für kontinuierliche Umlaufzeit von 300 Millisekunden oder weniger als 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 30 ms haben.

    • [5.6/H-1-2] MUSS eine durchschnittliche Latenz von Tap-to-Tone von 300 Millisekunden oder weniger über mindestens fünf Messungen über dem Datenpfad zwischen dem Lautsprecher und dem Mikrofon haben.

    Implementierungen von Handheld-Geräten, die mindestens einen haptischen Bedienungselement enthalten:

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

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

    • [7.10/H] SOLLTE den haptischen Auslöser in der X-Achse (links-rechts) im natürlichen Hochformat des Geräts verschieben.

    Wenn Implementierungen von Handheld-Geräten einen haptischen Bedienelement für allgemeine Zwecke haben, bei dem es sich um einen linearen Resonanzaktuator (X-Achsen-LRA) handelt, gilt Folgendes:

    • [7.10/H] SOLLTEN die Resonanzfrequenz der X-Achsen-LRA unter 200 Hz liegen.

  • 2.2.2 Multimedia:

    Überarbeitung ansehen

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

    • [5.2/H-0-3] AV1

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

    • [5.3/H-0-6] AV1

  • 2.2.3 Software:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen, einschließlich der Navigationstaste für die Funktion „Recents“, wie in Abschnitt 7.2.3 beschrieben, die Schnittstelle ändern, passiert Folgendes:

    • [3.8.3/H-1-1] MÜSSEN das Verhalten der Bildschirmfixierung implementieren und dem Nutzer ein Einstellungsmenü zum Ein-/Ausschalten der Funktion zur Verfügung stellen.

    Wenn Implementierungen von Handheld-Geräten die APIs ControlsProviderService und Control unterstützen und Drittanbieter-Apps erlauben, Gerätesteuerung zu veröffentlichen, gilt Folgendes:

    • [3.8.16/H-1-6] Geräteimplementierungen MÜSSEN die Leistung für Nutzer wie folgt korrekt wiedergeben:
      • Wenn auf dem Gerät config_supportsMultiWindow=true festgelegt ist und die App die Metadaten META_DATA_PANEL_ACTIVITY in der ControlsProviderService-Deklaration deklariert, einschließlich des ComponentName einer gültigen Aktivität (wie von der API definiert), MUSS die App diese Aktivität in dieses Nutzerangebot einbetten.
      • Wenn die App die Metadaten META_DATA_PANEL_ACTIVITY nicht deklariert, MÜSSEN die von der ControlsProviderService API bereitgestellten Felder sowie alle von den Control APIs bereitgestellten Felder gerendert werden.
    • [3.8.16/H-1-7] Wenn die App die Metadaten META_DATA_PANEL_ACTIVITY deklariert, MUSS sie beim Starten der eingebetteten Aktivität mithilfe von EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS den Wert der in [3.8.16/H-1-5] definierten Einstellung übergeben.

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

  • 2.2.4 Leistung und Leistung:

    Überarbeitung ansehen

    Implementierungen von Handheld-Geräten:

    • [8.5/H-0-1] MÜSSEN ein Nutzerangebot im Einstellungsmenü zur Verfügung stellen, um alle Apps mit aktiven Diensten oder vom Nutzer initiierten Jobs zu sehen, einschließlich der Dauer der einzelnen Dienste, da sie wie im SDK-Dokument beschrieben gestartet wurden. und die Möglichkeit, eine App zu beenden, in der ein Dienst im Vordergrund ausgeführt wird und die Funktion eines vom Nutzer initiierten Jobs, der im Vordergrund ausgeführt wird, sowie die Möglichkeit, eine App zu beenden, in der ein Dienst im Vordergrund ausgeführt wird, oder ein vom Nutzer initiierter Job zu stoppen.
      • Einige Apps KÖNNEN, wie im SDK-Dokument beschrieben, von der Beendigung oder Auflistung dieser Apps ausgenommen sein.

    • [8.5/H-0-2]MÜSSEN ein Nutzerangebot zum Stoppen einer App bereitstellen, die einen Dienst im Vordergrund ausführt, oder einen vom Nutzer initiierten Job.

  • 2.2.5 Sicherheitsmodell:

    Überarbeitung ansehen

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

    • [9.5/H-1-1] DARF UserManager.isHeadlessSystemUserMode NICHT auf true setzen.

    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 in Implementierungen von Handheld-Geräten UserManager.isHeadlessSystemUserMode auf true gesetzt wird,

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

    Wenn Implementierungen von Handheld-Geräten die System API HotwordDetectionService oder einen anderen Mechanismus für die Hotword-Erkennung ohne Anzeige des Mikrofonzugriffs unterstützen, gilt Folgendes:

    • [9.8/H-1-1] MÜSSEN sicherstellen, dass der Hotword-Erkennungsdienst nur Daten an das System, ContentCaptureService oder den von SpeechRecognizer#createOnDeviceSpeechRecognizer() erstellten On-Device-Spracherkennungsdienst auf dem Gerät übertragen kann.
    • [9.8/H-1-6] DÜRFEN bei jedem erfolgreichen Hotword-Ergebnis NICHT zulassen, dass mehr als 100 Byte Daten (mit Ausnahme von Audiostreams) aus dem Hotword-Erkennungsdienst übertragen werden.

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

    Wenn in der Geräteimplementierung eine Anwendung enthalten ist, die die System API HotwordDetectionService oder einen ähnlichen Mechanismus zur Hotword-Erkennung ohne Hinweis auf die Mikrofonnutzung verwendet, gilt für die Anwendung Folgendes:

    • [9.8/H-2-3] DÜRFEN KEINE Audiodaten, Audiodaten, die zur vollständigen oder teilweisen Rekonstruktion der Audiodaten verwendet werden können, oder Audioinhalte, die in keinem Zusammenhang mit dem Hotword selbst stehen, übertragen, mit Ausnahme von ContentCaptureService oder dem Spracherkennungsdienst auf dem Gerät.

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

    • [9.8/H-3-1] MÜSSEN sicherstellen, dass der Abfrageerkennungsdienst nur Daten an den System-, ContentCaptureService- oder On-Device-Spracherkennungsdienst (erstellt von SpeechRecognizer#createOnDeviceSpeechRecognizer()) übertragen kann.
    • [9.8/H-3-2] DÜRFEN NICHT zulassen, dass Audio- oder Videoinformationen aus VisualQueryDetectionService übertragen werden, mit Ausnahme von ContentCaptureService oder dem Spracherkennungsdienst auf dem Gerät.
    • [9.8/H-3-3] MÜSSEN in der System-UI ein Nutzerhinweis angezeigt werden, wenn das Gerät erkennt, dass ein Nutzer mit der App für digitalen Assistenten interagieren möchte (z. B. durch die Erkennung der Anwesenheit eines Nutzers über die Kamera).
    • [9.8/H-3-4] MÜSSEN eine Mikrofonanzeige und die erkannte Nutzeranfrage direkt nach der Erkennung in der Benutzeroberfläche anzeigen.
    • [9.8/H-3-5] DARF NICHT zulassen, dass eine vom Nutzer installierbare Anwendung den visuellen Abfrageerkennungsdienst bereitstellt.

  • 2.2.7.1 Medien:

    Überarbeitung ansehen

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

    Neue Anforderungen erstellen

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

    • [5.1/H-1-1] MÜSSEN die maximale Anzahl von Hardware-Videodecodersitzungen bekannt geben, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() ausgeführt werden können.
    • [5.1/H-1-2] MUSS 6 Instanzen von 8-Bit-Hardware-Videodecodersitzungen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen bei einer Auflösung von 1080p bei 30 fps und 3 Sitzungen bei 4K-Auflösung bei AV30 fps läuft, außer AVC, AV1-Codecs sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen. Sie sind aber auch für sechs Instanzen mit 1080p30 fps erforderlich.
    • [5.1/H-1-3] MÜSSEN die maximale Anzahl von Hardware-Video-Encoder-Sitzungen bekannt machen, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() ausgeführt werden können.
    • [5.1/H-1-4] MUSS 6 Instanzen von 8-Bit-Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit 4 Sitzungen bei einer Auflösung von 1080p bei 30 fps und 2 Sitzungen bei 4K-Auflösung bei AV30 fps läuft, außer AVC, AV1-Codecs sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen. Sie sind aber auch für sechs Instanzen mit 1080p30 fps erforderlich.
    • [5.1/H-1-5] MÜSSEN die maximale Anzahl von Hardware-Video-Encoder- und -Decoder-Sitzungen bekannt machen, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() ausgeführt werden können.
    • [5.1/H-1-6] MÜSSEN 6 Instanzen von 8-Bit-Hardware-Videodecoder- und Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen mit einer Auflösung von 4K bei 30 fps (außer AV1) und maximal 30 Encoder-Sitzungen mit Auflösung erforderlich ist. AV1-Codecs sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen. Sie sind aber auch für sechs Instanzen mit 1080p30 fps erforderlich.
    • [5.1/H-1-19] MÜSSEN 3 Instanzen von 10-Bit-Hardware-Videodecoder (HDR) und Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 4K bei 30 fps läuft (es sei denn, AV1 kann ein Surface_GL0-Format sein, das in einer Encoder-Sitzung konfiguriert ist). Bei einer Codierung über die GL-Oberfläche ist keine HDR-Metadatengenerierung durch den Encoder erforderlich. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, auch wenn 4K für diese Anforderung erforderlich ist.
    • [5.1/H-1-7] MÜSSEN bei einer Videocodierungssitzung mit 1080p oder weniger bei allen Hardware-Video-Encodern unter Last eine Codec-Initialisierungslatenz von 40 ms oder weniger haben. Der Ladevorgang ist hier als eine gleichzeitige reine Videotranscodierungssitzung von 1080p bis 720p definiert, die Hardware-Video-Codecs und die Initialisierung von 1080p-Audio-Video-Aufzeichnungen verwendet. Bei Dolby Vision-Codec MUSS die Codec-Initialisierungslatenz 50 ms oder weniger betragen.
    • [5.1/H-1-8] MÜSSEN bei einer Audiocodierungssitzung mit 128 kbit/s oder einer niedrigeren Bitrate bei allen Audio-Encodern unter Last eine Codec-Initialisierungslatenz von 30 ms oder weniger auftreten. Der Ladevorgang ist hier als eine gleichzeitige reine Videotranscodierungssitzung von 1080p bis 720p definiert, die Hardware-Video-Codecs und die Initialisierung von 1080p-Audio-Video-Aufzeichnungen verwendet.
    • [5.1/H-1-9] MUSS 2 Instanzen sicherer Hardware-Videodecodersitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 4K bei 30 fps (außer AV1) für 8-Bit- (SDR) und 10-Bit-HDR-Inhalte läuft. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, auch wenn 4K für diese Anforderung erforderlich ist.
    • [5.1/H-1-10] MÜSSEN 3 Instanzen nicht sicherer Hardware-Videodecoder-Sitzungen zusammen mit einer Instanz einer sicheren Hardware-Videodecoder-Sitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen bei 4K-Auflösung bei 30 fps und einer sicheren AV1-Sitzung mit einer Auflösung von 30 fps und einer sicheren AV1-Sitzung mit 4K-Auflösung bei 30 fps ausgeführt wird. AV1-Codec-Sitzungen sind nur erforderlich, um eine Auflösung von 1080p zu unterstützen, auch wenn 4K für diese Anforderung erforderlich ist.
    • [5.1/H-1-11] MÜSSEN für jeden Hardware-AVC-, HEVC-, VP9- oder AV1-Decoder auf dem Gerät einen sicheren Decoder unterstützen.
    • [5.1/H-1-12] MÜSSEN unter Last bei einer Videodecodierungssitzung mit 1080p oder kleiner für alle Hardware-Videodecoder eine Codec-Initialisierungslatenz von maximal 40 ms haben. Das Laden ist definiert als eine gleichzeitige reine Videotranscodierung mit 1080p bis 720p, die Hardware-Video-Codecs und die Initialisierung der Audio-Video-Wiedergabe von 1080p verwendet. Bei Dolby Vision-Codec MUSS die Codec-Initialisierungslatenz 50 ms oder weniger betragen.
    • [5.1/H-1-13] MÜSSEN bei einer Audiodecodierungssitzung mit 128 kbit/s oder einer niedrigeren Bitrate für alle Audiodecoder unter Last eine Codec-Initialisierungslatenz von 30 ms oder weniger haben. Der Ladevorgang ist hier als eine gleichzeitige reine Videotranscodierungssitzung von 1080p bis 720p definiert, die Hardware-Video-Codecs zusammen mit der Initialisierung der Audio-Video-Wiedergabe von 1080p verwendet.
    • [5.1/H-1-14] MÜSSEN den AV1-Hardwaredecoder Main 10, Level 4.1 und Filmkörnung unterstützen.
    • [5.1/H-1-15] MUSS mindestens einen Hardware-Videodecoder haben, der 4K60 unterstützt.
    • [5.1/H-1-16] MUSS mindestens einen Hardware-Video-Encoder haben, der 4K60 unterstützt.
    • [5.3/H-1-1] DARF BEI einer Videositzung mit 4K und 60 fps unter Last NICHT mehr als einen Frame in 10 Sekunden (d.h.weniger als 0,167 % Frame-Abfall) fallen.
    • [5.3/H-1-2] DÜRFEN NICHT mehr als 1 Frame in 10 Sekunden während einer Änderung der Videoauflösung in einer Videositzung mit 60 fps unter Last bei einer 4K-Sitzung fallen.
    • [5.6/H-1-1] MÜSSEN bei Verwendung des Tap-to-Tone-Tests von CTS Verifier eine Antippen-Ton-Latenz von maximal 80 Millisekunden haben.
    • [5.6/H-1-2] MÜSSEN über mindestens einen unterstützten Datenpfad eine Umlauf-Audiolatenz von 80 Millisekunden oder weniger haben.
    • [5.6/H-1-3] MUSS MEHR ALS 24-Bit-Audio für die Stereoausgabe über 3,5-mm-Audiobuchsen unterstützen, sofern vorhanden, und über USB, wenn dies über den gesamten Datenpfad für Konfigurationen mit niedriger Latenz und Streaming-Konfigurationen unterstützt wird. Für die Konfiguration mit niedriger Latenz sollte AAudio von der Anwendung im Callback-Modus mit niedriger Latenz verwendet werden. Für die Streamingkonfiguration sollte von der Anwendung ein Java AudioTrack verwendet werden. Sowohl in den Konfigurationen mit niedriger Latenz als auch bei Streamingkonfigurationen sollte die HAL-Ausgabesenke entweder AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT oder AUDIO_FORMAT_PCM_FLOAT als Zielausgabeformat akzeptieren.
    • [5.6/H-1-4] MÜSSEN USB-Audiogeräte mit mindestens 4 Kanälen unterstützen (wird von DJ-Controllern für die Vorschau von Songs verwendet.)
    • [5.6/H-1-5] MÜSSEN klassenkonforme MIDI-Geräte unterstützen und das MIDI-Funktions-Flag deklarieren.
    • [5.6/H-1-9] MUSS mindestens 12 Kanäle unterstützen. Dies impliziert die Möglichkeit, einen AudioTrack mit 7.1.4-Kanal-Maske zu öffnen und alle Kanäle ordnungsgemäß auf Stereo zu übertragen oder zu verkleinern.
    • [5.6/H-SR] Es wird dringend empfohlen, 24-Kanal-Mischungen mit mindestens den Kanalmasken 9.1.6 und 22.2 zu unterstützen.
    • [5.7/H-1-2] MUSS MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL mit den unten aufgeführten Funktionen zur Inhaltsentschlüsselung unterstützen.
    Mindeststichprobengröße 4 MiB
    Mindestanzahl von Unterstichproben – 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 der DRM-Schlüssel (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 das AVIF-Baseline-Profil unterstützt.
    • [5.1/H-1-18] MUSS AV1-Encoder unterstützen, der eine Auflösung von bis zu 480p bei 30 fps und 1 Mbit/s codieren kann.
    • [5.12/H-1-1] MÜSSEN [5.12/H-SR] dringend empfohlen werden, um die Feature_HdrEditing-Funktion für alle Hardware-AV1- und HEVC-Encoder auf dem Gerät zu unterstützen.
    • [5.12/H-1-2] MÜSSEN das RGBA_1010102-Farbformat für alle Hardware-AV1- und HEVC-Encoder auf dem Gerät unterstützen.
    • [5.12/H-1-3] MÜSSEN die Unterstützung der Erweiterung EXT_YUV_target für Stichproben aus YUV-Texturen sowohl in 8 als auch in 10 Bit anbieten.
    • [7.1.4/H-1-1] MÜSSEN mindestens 6 Hardware-Overlays in der Datenverarbeitungseinheit (DPU) Hardware Composer (HWC) haben, wobei mindestens zwei davon 10-Bit-Videoinhalte wiedergeben können.

    Wenn Implementierungen von Handheld-Geräten android.os.Build.VERSION_CODES.U für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben und einen AVC- oder HEVC-Encoder Hardware unterstützen, gilt Folgendes:

    • [5.2/H-2-1] MÜSSEN das Mindestqualitätsziel erfüllen, das in den Videoencoder-Raten-Verzerrungskurven für Hardware-AVC- und HEVC-Codecs definiert ist, wie in der kommenden Dokumentation definiert.

  • 2.2.7.2 Kamera:

    Überarbeitung ansehen

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

    • [7.5/H-1-1] MUSS eine primäre Rückkamera mit einer Auflösung von mindestens 12 Megapixeln haben, die eine Videoaufnahme mit 4K bei 30 fps unterstützt. Die primäre Kamera auf der Rückseite ist die Kamera auf der Rückseite mit der niedrigsten Kamera-ID.
    • [7.5/H-1-2] MÜSSEN eine primäre Frontkamera mit einer Auflösung von mindestens 6 Megapixeln haben und Videoaufnahmen mit 1080p bei 30 fps unterstützen. Die primäre Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
    • [7.5/H-1-3] MUSS die Eigenschaft android.info.supportedHardwareLevel für beide primären Kameras als FULL oder besser unterstützen.
    • [7.5/H-1-4] MUSS CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME für beide primären Kameras unterstützen.
    • [7.5/H-1-5] MÜSSEN eine JPEG-Aufnahmelatenz der Kamera2 von unter 1.000 900 ms für eine 1080p-Auflösung haben. Der Leistungstest der CTS-Kamera wurde unter ITS-Beleuchtungsbedingungen (3.000 K) für beide primären Kameras gemessen.
    • [7.5/H-1-6] MUSS die Startlatenz von Kamera 2 (Kamera öffnen, um den ersten Vorschauframe öffnen) unter 500 ms liegen, wie von der CTS-Kameraleistungstest unter ITS-Beleuchtungsbedingungen (3.000 K) für beide primären Kameras gemessen.
    • [7.5/H-1-8] MUSS CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW und android.graphics.ImageFormat.RAW_SENSOR für die primäre Rückkamera unterstützen.
    • [7.5/H-1-9] MUSS auf der Rückseite eine primäre Kamera haben, die 720p oder 1080p bei 240 fps unterstützt.
    • [7.5/H-1-10] MÜSSEN mindestens ZOOM_RATIO < 1,0 für die primären Kameras haben, wenn eine Ultraweitwinkel-RGB-Kamera in die gleiche Richtung gerichtet ist.
    • [7.5/H-1-11] MUSS gleichzeitiges Front-Back-Streaming auf primären Kameras implementieren.
    • [7.5/H-1-12] MUSS CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION sowohl für die primäre Front- als auch die primäre Rückkamera unterstützen.
    • [7.5/H-1-13] MUSS die LOGICAL_MULTI_CAMERA-Funktion für die primären Kameras unterstützen, wenn es mehr als eine RGB-Kamera gibt, die in die gleiche Richtung zeigt.
    • [7.5/H-1-14] MUSS die Funktion STREAM_USE_CASE sowohl für die primäre Frontkamera als auch für die primäre Rückkamera unterstützen.
    • [7.5/H-1-15] MÜSSEN Bokeh- und Nachtmoduserweiterungen für primäre Kameras über die Erweiterungen CameraX und Camera2 unterstützen.
    • [7.5/H-1-16] MUSS die Funktion DYNAMIC_RANGE_TEN_BIT für die primären Kameras unterstützen.
    • [7.5/H-1-17] MUSS CONTROL_SCENE_MODE_FACE_PRIORITY und Gesichtserkennung (STATISTICS_FACE_DETECT_MODE_SIMPLE oder STATISTICS_FACE_DETECT_MODE_FULL) für die primären Kameras unterstützen.

  • 2.2.7.3 Hardware:

    Überarbeitung ansehen

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

    • [7.1.1.1/H-2-1] MUSS eine Bildschirmauflösung von mindestens 1080p haben.
    • [7.1.1.3/H-2-1] MUSS eine Bildschirmdichte von mindestens 400 dpi haben.
    • [7.1.1.3/H-3-1] MUSS ein HDR-Display mit mindestens 1.000 cd/m2 im Durchschnitt haben.
    • [7.6.1/H-2-1] MUSS mindestens 8 GB physischen Arbeitsspeicher haben.

  • 2.2.7.4 Leistung:

    Überarbeitung ansehen

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

    • [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 mit einer 2-fachen Lese- und einer 1-fachen Schreibleistung von mindestens 50 MB/s gewährleisten.

  • 2.3.2 Multimedia:

    Überarbeitung ansehen

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

    • [5.2/T-0-3] AV1

    Implementierungen von Fernsehgeräten MÜSSEN die folgenden Videodecodierungsformate unterstützen und für Drittanbieteranwendungen verfügbar machen:

  • 2.4.5 Sicherheitsmodell:

    Überarbeitung ansehen

    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.1 Hardware:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen AM/FM-Radio unterstützen und die Funktion für eine beliebige Anwendung verfügbar machen, gilt Folgendes:

    • [7.4.10/A-0-1] MUSS die Unterstützung für FEATURE_BROADCAST_RADIO deklarieren.

    Eine Außenkamera ist eine Kamera, die Szenen außerhalb der Geräteimplementierung aufnimmt, z. B. die Rückkamera.

    Implementierungen von Automobilgeräten:

    • SOLLTEN eine oder mehrere Außenkameras enthalten.

    Wenn Implementierungen von Automobil-Geräten eine Außenkamera umfassen, gilt Folgendes:

    • [7.5/A-1-1] DÜRFEN KEINE Außenansichtskameras über die Android Camera APIs zugänglich haben, es sei denn, sie erfüllen die Hauptanforderungen der Kamera.
    • [7.5/A-SR-1] wird dringend empfohlen, die Kameravorschau nicht zu drehen oder horizontal zu spiegeln.
    • [7.5/A-SR-2] wird dringend empfohlen, eine Auflösung von mindestens 1,3 Megapixeln zu haben.
    • SOLLTEN entweder über Fixfokus- oder EDOF-Hardware verfügen.
    • KANN im Kameratreiber entweder Hardware-Autofokus oder Software-Autofokus implementiert sein.

    Wenn Implementierungen für Automobilgeräte eine oder mehrere Außenkameras umfassen und den EVS-Dienst (Exterior View System) laden, gilt für eine solche Kamera Folgendes:

    • [7.5/A-2-1] DARF die Kameravorschau NICHT drehen oder horizontal spiegeln.

    Implementierungen von Automobilgeräten:

    • KÖNNEN eine oder mehrere Kameras enthalten, die für Anwendungen von Drittanbietern verfügbar sind.

    Wenn Implementierungen von Automobilgeräten mindestens eine Kamera enthalten und für Anwendungen von Drittanbietern verfügbar gemacht werden, geschieht Folgendes:

    • [7.5/A-3-1] MÜSSEN das Funktions-Flag android.hardware.camera.any melden.
    • [7.5/A-3-2] DARF die Kamera nicht als Systemkamera deklarieren.
    • KANN externe Kameras unterstützen, wie in Abschnitt 7.5.3 beschrieben.
    • KÖNNEN Funktionen (z. B. Autofokus) von Rückkameras enthalten, wie in Abschnitt 7.5.1 beschrieben.

    Eine nach hinten gerichtete Kamera ist eine nach außen gerichtete Kamera, die sich an jedem beliebigen Ort im Fahrzeug anbringen kann und auf die Außenseite des Fahrzeugs zeigt. Das heißt, sie nimmt Szenen von der hinteren Seite der Fahrzeugkarosserie auf, z. B. von der Rückkamera.

    Eine Frontkamera ist eine Kamera, die sich an jedem beliebigen Ort im Fahrzeug befindet und in den Innenraum des Fahrzeugs zeigt. Das heißt, sie erfasst den Nutzer, z. B. bei Videokonferenzen und ähnlichen Anwendungen.

    Implementierungen von Automobilgeräten:

    • [7.5/A-SR-1] wird dringend empfohlen, eine oder mehrere nach außen gerichtete Kameras zu verwenden.
    • KANN eine oder mehrere Kameras für den Nutzer enthalten.
    • [7.5/A-SR-2] WIRD UNBEDINGT EMPFOHLEN, das gleichzeitige Streaming mehrerer Kameras zu unterstützen.

    Wenn Automotive-Geräteimplementierungen mindestens eine Kamera enthalten, die nach der Welt gerichtet ist, gilt für eine solche Kamera Folgendes:

    • [7.5/A-1-1] MUSS so ausgerichtet sein, dass die lange Achse der Kamera mit der x-y-Ebene der Android-Automotive-Sensorachsen übereinstimmt.
    • [7.5/A-SR-3] Wir empfehlen dringend, entweder Fixfokus- oder EDOF-Hardware (Extended Depth of Field) zu verwenden.
    • [7.5/A-1-2] MÜSSEN die primäre nach außen gerichtete Kamera als die nach außen gerichtete Kamera mit der niedrigsten Kamera-ID haben.

    Wenn Implementierungen für Automotive-Geräte mindestens eine Kamera enthalten, die dann für den Nutzer sichtbar ist, gilt für eine solche Kamera Folgendes:

    • [7.5/A-2-1] Die primäre Kamera für den Nutzer MÜSSEN die Kamera mit der niedrigsten Kamera-ID sein.
    • KANN so ausgerichtet werden, dass die lange Dimension der Kamera mit der x-y-Ebene der Android-Automotive-Sensorachsen übereinstimmt.

    Wenn Implementierungen für Automotive-Geräte eine Kamera enthalten, auf die entweder über die android.hardware.Camera API oder die android.hardware.camera2 API zugegriffen werden kann, gilt Folgendes:

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

    Wenn Implementierungen für Automotive-Geräte eine Kamera enthalten, auf die weder über die android.hardware.Camera noch über die android.hardware.camera2 API zugegriffen werden kann, geschieht Folgendes:

    • [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 den Extended View System Service zugänglich sind, gilt für eine solche Kamera Folgendes:

    • [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 Megapixel wird dringend empfohlen.

    Wenn die Implementierungen für Automobilgeräte eine oder mehrere Kameras umfassen, die sowohl über den Extended View System Service als auch über die android.hardware.Camera oder die android.hardware.Camera2 API zugänglich sind, gilt für eine solche Kamera Folgendes:

    • [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 mit der android.hardware.camera2 API oder der Extended View System API implementieren.

  • 2.5.3 Software:

    Überarbeitung ansehen

    Implementierungen von Automobilgeräten:

    • [3.8/A-0-1] DARF 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.

  • 2.5.5 Sicherheitsmodell:

    Überarbeitung ansehen

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

    • [9.8.2/A-1-1] MÜSSEN die Mikrofonanzeige einblenden, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn nur HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService oder Apps mit den in Abschnitt 9.1 genannten Rollen mit der CDD-Kennung [C-4-X] auf das Mikrofon zugreifen.
    • [9.8.2/A-1-2] DARF die Mikrofonanzeige für System-Apps, die sichtbare Benutzeroberflächen oder direkte Nutzerinteraktionen haben, nicht ausblenden.
    • [9.8.2/A-1-3] MUSS dem Nutzer die Möglichkeit bieten, das Mikrofon in der App „Einstellungen“ ein- oder auszuschalten.

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

    • [9.8.2/A-2-1] MÜSSEN die Kameraanzeige einblenden, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn nur Apps mit den in Abschnitt 9.1 angegebenen Rollen mit der CDD-Kennung [C-4-X][C-3-X] auf die Kamera zugreifen.

    • [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 aktuelle und aktive Apps, die die Kamera verwenden, wie von PermissionManager.getIndicatorAppOpUsageData() zurückgegeben, zusammen mit allen damit verbundenen Quellenangaben angezeigt werden.

    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/A-1-1] MUSS den Nutzer häufiger als alle 336 Stunden zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) auffordern.

3. Software

  • 3.1 Kompatibilität mit verwalteten APIs:

    Überarbeitung ansehen

    Geräteimplementierungen:

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

  • 3.2.3.5 Bedingte Anwendungs-Intents:

    Überarbeitung ansehen

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

  • 3.3.1 Binäre Anwendungsschnittstellen:

    Überarbeitung ansehen

    Geräteimplementierungen:

    • [C-0-12] MÜSSEN Funktionssymbole für die Kernfunktionssymbole Vulkan 1.0 des Typs Vulkan 1.1 sowie die Erweiterungen VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 und VK_KHR_get_physical_device_properties2 über die Bibliothek libvulkan.so exportieren. Alle Symbole MÜSSEN zwar vorhanden sein, Abschnitt 7.1.4.2 beschreibt jedoch genauer, wann die vollständige Implementierung der einzelnen Funktionen erwartet wird.

  • 3.8.6 Designs:

    Überarbeitung ansehen

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

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

  • 3.8.8 Wechseln zwischen Aktivitäten:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen, die die Navigationstaste der Funktion „Zuletzt verwendet“ wie in Abschnitt 7.2.3 beschrieben, geändert haben, gilt Folgendes:

  • 3.9.2 Unterstützung für verwaltete Profile:

    Überarbeitung ansehen

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

    • [C-1-10] MÜSSEN darauf achten, dass die Screenshotdaten im Arbeitsprofilspeicher gespeichert werden, wenn ein Screenshot mit einem topActivity-Fenster mit Fokus erstellt wird (das, mit dem der Nutzer zuletzt unter allen Aktivitäten interagiert hat) und zu einer Arbeitsprofil-App gehört.
    • [C-1-11] DÜRFEN KEINE anderen Bildschirminhalte (Systemleiste, Benachrichtigungen oder Inhalte aus privaten Profilen) mit Ausnahme der Fenster/Fenster des Arbeitsprofils erfassen, wenn ein Screenshot im Arbeitsprofil gespeichert wird. So wird sichergestellt, dass keine persönlichen Profildaten im Arbeitsprofil gespeichert werden.

  • 3.9.5 Framework zur Behebung von Geräterichtlinien: Neuer Abschnitt

    Überarbeitung ansehen

    Wenn Geräteimplementierungen android.software.device_admin oder android.software.managed_users melden, gilt Folgendes:

    • [C-1-1] MÜSSEN Konflikte mit Geräterichtlinien wie in der AOSP-Dokumentation beschrieben lösen.

5. Multimedia-Kompatibilität

  • 5.1.4 Bildcodierung:

    Überarbeitung ansehen

    Geräteimplementierungen MÜSSEN die Codierung der folgenden Bildcodierung unterstützen:

    • [C-0-4] AVIF
      • Geräte müssen BITRATE_MODE_CQ und Baseline-Profil unterstützen.

  • 5.1.5 Bilddecodierung:

    Überarbeitung ansehen

    Geräteimplementierungen MÜSSEN die Decodierung der folgenden Bildcodierung unterstützen:

    [C-0-7] AVIF (Baseline-Profil)

  • 5.1.6 Details zu Image-Codecs:

    Überarbeitung ansehen

    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)

  • 5.1.8 Liste der Video-Codecs:

    Überarbeitung ansehen

    Format/Codec Details Zu unterstützende Dateitypen/Containerformate
    H.263
    • 3GPP (3GP)
    • MPEG-4 (MP4)
    • Matroska (.mkv, nur decodieren)
    H.264-AVC Weitere Informationen finden Sie in Abschnitt 5.2 und 5.3.
    • 3GPP (3GP)
    • MPEG-4 (MP4)
    • MPEG-2-TS (Ts, nicht suchbar)
    • Matroska (.mkv, nur decodieren)
    H.265 HEVC Weitere Informationen finden Sie in Abschnitt 5.3.
    • MPEG-4 (MP4)
    • Matroska (.mkv, nur decodieren)
    MPEG-2 Profil "Main"
    • MPEG2-TS (.ts, nicht suchbar)
    • MPEG-4 (.mp4, nur decodieren)
    • Matroska (.mkv, nur decodieren)
    MPEG-4 SP
    • 3GPP (3GP)
    • MPEG-4 (MP4)
    • Matroska (.mkv, nur decodieren)
    VP8 Einzelheiten finden Sie in Abschnitt 5.2 und 5.3.
    VP9 Weitere Informationen finden Sie in Abschnitt 5.3.
    AV1 Weitere Informationen finden Sie in Abschnitt 5.2 und Abschnitt 5.3.
    • MPEG-4 (.mp4)
    • Matroska (.mkv, nur decodieren)

  • 5.1.10 Medien-Codec-Charakterisierung:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen Video-Codecs unterstützen:

    • [C-2-1] Alle Video-Codecs MÜSSEN erreichbare Framerate-Daten für die folgenden Größen veröffentlichen, wenn sie vom Codec unterstützt werden:
    SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p UHD
    Videoauflösung
    • 176 x 144 Pixel (H263, MPEG2, MPEG4)
    • 352 x 288 Pixel (MPEG4-Encoder, H263, MPEG2)
    • 320 x 180 Pixel (VP8, VP8)
    • 320 x 240 px (sonstige)
    • 704 x 576 Pixel (H263)
    • 640 x 360 Pixel (VP8, VP9)
    • 640 x 480 Pixel (MPEG4-Encoder)
    • 720 x 480 Pixel (andere, AV1)
    • 1408 x 1152 Pixel (H263)
    • 1280 x 720 Pixel (andere, AV1)
    		 1920 x 1080 Pixel (außer MPEG4, AV1) 3840 x 2160 Pixel (HEVC, VP9, AV1)

  • 5.2 Videocodierung:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen Video-Encoder unterstützen und für Drittanbieter-Apps verfügbar machen, geschieht Folgendes:

    • Über zwei gleitende Fenster NICHT mehr als 15% über der Bitrate zwischen Intraframe-Intervallen (I-Frame) liegen
    • NICHT mehr als 100% über der Bitrate auf einem gleitenden Fenster von einer Sekunde liegen.

    Wenn Geräteimplementierungen einen Videoencoder unterstützen und für Drittanbieter-Apps zur Verfügung stellen und
    MediaFormat.KEY_BITRATE_MODE auf BITRATE_MODE_VBR setzen, damit der Encoder im Modus mit variabler Bitrate arbeitet, gilt für die codierte Bitrate Folgendes, sofern die Mindestqualität nicht beeinträchtigt wird :

    • [C-5-1] MUSS SOLLTE NICHT über einem gleitenden Fenster mehr als 15% über der Bitrate zwischen Intraframe-Intervallen (I-Frame) liegen.
    • [C-5-2] MUSS SOLL NICHT mehr als 100% über der Bitrate auf einem gleitenden Fenster von 1 Sekunde liegen.

    Wenn Geräteimplementierungen einen Videoencoder unterstützen und für Drittanbieter-Apps verfügbar machen und MediaFormat.KEY_BITRATE_MODE auf BITRATE_MODE_CBR setzen, damit der Encoder im Modus mit konstanter Bitrate arbeitet, gilt für die codierte Bitrate:

    • [C-6-1] MUSS [C-SR-2] wird dringend empfohlen, bei einem gleitenden Fenster von 1 Sekunde NICHT mehr als 15% über der Zielbitrate zu liegen.

  • 5.2.1 H.263:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen H.263-Encoder unterstützen und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

    • [C-1-1] MUSS die QCIF-Auflösung (176 x 144) mit Referenzprofilebene 45 unterstützen. Die SQCIF-Auflösung ist optional.
    • Dynamisch konfigurierbare Bitraten für den unterstützten Encoder unterstützen

  • 5.2.5 H.265:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:

    • [C-1-1] MUSS Hauptprofilebene 3 bis zu einer Auflösung von 512 x 512 unterstützen.
    • SOLLTEN die HD-Codierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
    • [C-SR-1] wird dringend empfohlen, die SD-Profile (720 x 480) und die HD-Codierungsprofile zu unterstützen, wie in der folgenden Tabelle angegeben, wenn ein Hardware-Encoder vorhanden ist.

  • 5.2.6 AV1: neuer Abschnitt

    Überarbeitung ansehen

    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, d.h. Berichte zur Leistung, über die APIs getSupportedFrameRatesFor() oder getSupportedPerformancePoints() veröffentlichen, wenn die Lösungen in der Tabelle unten unterstützt werden.

    • [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 der folgenden Tabelle unterstützen:
    SD HD 720p HD 1080p UHD
    Videoauflösung 720 x 480 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 Frame-Rate: 30 fps
    Video-Bitrate 5 Mbit/s 8 Mbit/s 16 Mbit/s 50 Mbit/s

  • 5.3.2 H.263:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen H.263-Decoder unterstützen, gilt Folgendes:

    • [C-1-1] MUSS Baseline-Profilstufe 30 (CIF-, QCIF- und SQCIF-Auflösungen bei 30 fps, 384 kbit/s) und Stufe 45 (QCIF- und SQCIF-Auflösungen bei 30 fps und 128 kbit/s) unterstützen.

  • 5.3.9 AV1:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen den AV1-Codec unterstützen, gilt Folgendes:

    • [C-1-1] MUSS Profil 0 einschließlich 10-Bit-Inhalten unterstützen.

    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 den AV1-Codec mit einem hardwarebeschleunigten Decoder unterstützen, gilt Folgendes:

    • [C-2-1] MÜSSEN mindestens HD-Videodecodierungsprofile mit 720p aus der folgenden Tabelle decodieren können, wenn die von der Methode Display.getSupportedModes() gemeldete Höhe mindestens 720p beträgt.
    • [C-2-2] MÜSSEN mindestens HD-Videodecodierungsprofile mit 1080p aus der folgenden Tabelle decodieren können, wenn die von der Methode Display.getSupportedModes() gemeldete Höhe mindestens 1080p beträgt.
    SD HD 720p HD 1080p UHD
    Videoauflösung 720 x 480 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 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, gilt Folgendes:

    • [C-3-1] MUSS das Extrahieren und Ausgeben von HDR-Metadaten aus dem Bitstream und/oder dem Container unterstützen.
    • [C-3-2] MÜSSEN HDR-Inhalte richtig auf dem Gerätebildschirm oder an einem Standard-Videoausgangsanschluss (z. B. HDMI) anzeigen.

  • 5.4.2 Aufnahme für Spracherkennung:

    Überarbeitung ansehen

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

    • SOLLTE die Audioeingabeempfindlichkeit so einstellen, dass eine sinusoidale Tonquelle von 1.000 Hz bei 90 dB Schalldruckpegel (gemessen in einem Abstand von 30 cm zum Mikrofon) neben dem Mikrofon eine ideale Antwort von RMS 2.500 und einer Gleitkommazahl von 1.770 mit 1.770 und 1.770 B3-Samples sowie 1.770 cd/m2 für eine Gleitkommazahl-Erkennung und

  • 5.5.2 Audioeffekte:

    Überarbeitung ansehen

    Wenn in Geräteimplementierungen die Funktion android.hardware.audio.output deklariert wird, geschieht Folgendes:

    • [C-1-4] MUSS Audioeffekte mit Gleitkommaeingabe und -ausgabe unterstützen.
    • [C-1-5] MÜSSEN sicherstellen, dass Audioeffekte mehrere Kanäle bis zur Mischkanalanzahl (auch als FCC_LIMIT bezeichnet) unterstützen.

  • 5.6 Audiolatenz:

    Überarbeitung ansehen

    Wenn in Geräteimplementierungen android.hardware.audio.output deklariert wird, wird dringend empfohlen, die folgenden Anforderungen zu erfüllen oder zu übertreffen:

    • [C-SR-4] Der von AudioTrack.getTimestamp und AAudioStream_getTimestamp zurückgegebene Ausgabezeitstempel ist auf +/- 1 ms genau.

    • [C-SR-4] Die berechneten Umlauflatenzen, die auf den von AAudioStream_getTimestamp zurückgegebenen Eingabe- und Ausgabezeitstempeln basieren, werden UNBEDINGT empfohlen, innerhalb von 30 ms der gemessenen Umlauflatenz für AAUDIO_PERFORMANCE_MODE_NONE und AAUDIO_PERFORMANCE_MODE_LOW_LATENCY für Lautsprecher sowie kabelgebundene und kabellose Headsets zu liegen.

7. Hardwarekompatibilität

  • 7.1 Display und Grafik:

    Überarbeitung ansehen

    Android bietet Funktionen, mit denen App-Assets und UI-Layouts automatisch an das Gerät angepasst werden, um sicherzustellen, dass Anwendungen von Drittanbietern auf verschiedenen Hardwarekonfigurationen einwandfrei funktionieren. Ein mit Android kompatibler Bildschirm ist ein Bildschirm, auf dem alle unter Android-Entwickler – Übersicht über die Bildschirmkompatibilität, in diesem Abschnitt (7.1) und den zugehörigen Unterabschnitten beschriebenen Verhaltensweisen und APIs sowie alle weiteren gerätetypspezifischen Verhaltensweisen implementiert werden, die in Abschnitt 2 dieser CDD beschrieben sind. Auf den mit Android kompatiblen Displays, auf denen alle Android-kompatiblen Anwendungen von Drittanbietern ausgeführt werden können, MÜSSEN diese APIs und Verhaltensweisen korrekt implementiert werden, wie in diesem Abschnitt beschrieben.

    Neue Anforderungen erstellen

    Geräteimplementierungen:

    • [C-0-1] MÜSSEN Drittanbieter-Apps standardmäßig nur auf Android-kompatiblen Bildschirmen rendern.

    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.
    • Punkt pro Zoll (dpi): Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1 Zolleingeschlossen werden, ausgedrückt als Pixel pro Zoll (ppi oder dpi). Wenn die ppi- und dpi-Werte für dpi angegeben sind, müssen sowohl die horizontale als auch die vertikale DPI-Werte in den aufgeführten Bereich fallen.
    • Seitenverhältnis. Das Verhältnis der Pixel der längeren Seite zur kürzeren Seite des Bildschirms. Eine Anzeige mit 480 × 854 Pixeln wäre beispielsweise 854/480 = 1, 779, also ungefähr „16:9“.
    • dichteunabhängige Pixel (dp): Die eine virtuelle Pixeleinheit, normalisiert auf eine Bildschirmdichte von 160 dpi eine Bildschirmdichte von 160. Für eine bestimmte Dichte d und eine Anzahl von Pixeln p wird die Anzahl der dichteunabhängigen Pixel dp so berechnet: pixels = dps * (density/160) dp = (160 / d) * p .

  • 7.1.1.1 Bildschirmgröße und ‐form:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen Bildschirme unterstützen, die die Größenkonfiguration UI_MODE_TYPE_NORMAL unterstützen und Android-kompatible Bildschirme mit abgerundeten Ecken verwenden, um diese Bildschirme zu rendern, geschieht Folgendes:

    • [C-1-1] MÜSSEN für jedes dieser Displays mindestens eine der folgenden Anforderungen erfüllen:
    • Der Radius der abgerundeten Ecken ist kleiner oder gleich 38 dp.

    • Wenn eine Box mit 15 dp × 15 dp in jeder Ecke der logischen Anzeige verankert ist, ist mindestens ein Pixel jedes Felds auf dem Bildschirm sichtbar.

    • SOLLTEN die Nutzer die Möglichkeit haben, in den Anzeigemodus mit den rechteckigen Ecken zu wechseln.

    Neue Anforderungen erstellen

    Wenn in Geräteimplementierungen nur die Tastaturkonfiguration NO_KEYS möglich ist und die Unterstützung für die Konfiguration des UI-Modus UI_MODE_TYPE_NORMAL gemeldet werden soll, geschieht Folgendes:

    • [C-4-1] MÜSSEN eine Layoutgröße von mindestens 596 dp x 384 dp ohne Display-Aussparungen haben.

    Wenn in Geräteimplementierungen Android-kompatible Displays enthalten sind, die faltbar sind, oder ein klappbares Scharnier zwischen mehreren Displays enthalten, das bzw. die zum Rendern von Drittanbieter-Apps zur Verfügung stehen, gilt Folgendes:

    Wenn Geräteimplementierungen ein oder mehrere Android-kompatible Bildschirme umfassen, die faltbar sind, oder ein faltbares Scharnier zwischen mehreren Anzeigebereichen haben und sich das Scharnier oder die Faltung durch ein Anwendungsfenster im Vollbildmodus kreuzt, gilt Folgendes:

    • [C-3-1] MÜSSEN die Position, die Grenzen und den Zustand des Scharniers über Erweiterungen oder Sidecar-APIs an die Anwendung melden.

    Wenn Geräteimplementierungen einen oder mehrere mit Android kompatible Bereiche, die faltbar sind, oder ein faltbares Scharnier zwischen mehreren Android-kompatiblen Displaybereichen umfassen und diese Bereiche für Apps verfügbar machen, gilt Folgendes:

    • [C-4-1] MÜSSEN die richtige Version der Window Manager Extensions API-Ebene implementieren, wie in der kommenden Dokumentation beschrieben.

  • 7.1.1.2 Bildschirmseitenverhältnis: entfernt

  • 7.1.1.3 Bildschirmdichte:

    Überarbeitung ansehen

    Geräteimplementierungen:

    • [C-0-1] Standardmäßig wird bei Geräteimplementierungen nur eine der Android-Framework-Dichten gemeldet, die über die DENSITY_DEVICE_STABLE API in DisplayMetrics aufgeführt sind. Dieser Wert muss ein statischer Wert für jedes physische Display sein DARF NICHT zu jeder Zeit geändert werden.Jedoch Eine andere Einstellung Eine andere Dichte des Geräts wird angezeigt.DisplayMetrics.density

    • Bei Geräteimplementierungen MÜSSEN die standardmäßige Android-Framework-Dichte definiert werden, die numerisch der physischen Dichte des Bildschirms am nächsten kommt, es sei denn, diese logische Dichte führt dazu, dass die gemeldete Bildschirmgröße unter das unterstützte Minimum fällt. Wenn die Standard-Android-Framework-Dichte, die numerisch der physischen Dichte am nächsten kommt, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 dp) ist, SOLLTE die Geräteimplementierung die nächstniedrigere Standard-Android-Framework-Dichte angeben.

    Neue Anforderungen erstellen

    • SOLLTE die standardmäßige Android-Framework-Dichte definieren, die numerisch der physischen Dichte des Bildschirms entspricht, oder einen Wert, der den gleichen äquivalenten Winkel-Sichtfeldmessungen eines Handheld-Geräts zuordnen würde.

    Wenn Geräteimplementierungen die Möglichkeit bieten, die Anzeigegröße des Geräts zu ändern, werden sie:

    • [C-1-1] Die Displaygröße DARF NICHT skaliert werden DÜRFEN NICHT die Anzeige auf ein 1,5-Faches der DENSITY_DEVICE_STABLE nativen Dichte skalieren oder eine effektive Mindestgröße von unter 320 dp haben (entspricht dem Ressourcen-Qualifier sw320dp), je nachdem, was zuerst eintritt.
    • [C-1-2] Die Anzeigegröße DARF NICHT skaliert werden Dürfen die Anzeige NICHT auf weniger als das 0,85-Fache der DENSITY_DEVICE_STABLE nativen Dichte skaliert werden.

  • 7.1.4.2 Vulkan:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen Vulkan 1.0 oder höher unterstützen, gilt Folgendes:

    • [C-1-3] MÜSSEN die Vulkan 1.1 APIs von Vulkan 1.0 für jede aufgelistete VkPhysicalDevice vollständig implementieren.

    • [C-1-5] DARF KEINE Layers aufzählen, die von Bibliotheken außerhalb des Anwendungspakets bereitgestellt werden, und keine anderen Möglichkeiten zum Tracing oder Abfangen der Vulkan API bieten, es sei denn, für die Anwendung ist das Attribut android:debuggable auf true oder die Metadaten com.android.graphics.injectLayers.enable auf true gesetzt.

    • SOLLTEN VkPhysicalDeviceProtectedMemoryFeatures und VK_EXT_global_priority unterstützen.

    • [C-SR-5] wird dringend empfohlen, VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory und VK_EXT_global_priority zu unterstützen.

    • [C-SR-6] wird dringend empfohlen, SkiaVk mit HWUI zu verwenden.

    Wenn Geräteimplementierungen Vulkan 1.1 unterstützen und eines der hier beschriebenen Vulkan-Funktions-Flags deklarieren, geschieht Folgendes:

    • [C-SR-7] Es wird dringend empfohlen, die Erweiterung VK_KHR_external_fence_fd für Drittanbieteranwendungen verfügbar zu machen und der Anwendung zu ermöglichen, Fence-Nutzlasten in POSIX-Dateideskriptoren zu exportieren und aus POSIX-Dateideskriptoren zu importieren, wie hier beschrieben.

  • 7.3.10 Biometrische Sensoren:

    Überarbeitung ansehen

    Geräteimplementierungen mit mehreren biometrischen Sensoren:

    • [C-7-1] MÜSSEN, wenn ein biometrisches Verfahren aufgrund zu vieler fehlgeschlagener Versuche vorübergehend gesperrt wird (das biometrische Verfahren wird deaktiviert, bis der Nutzer mit der primären Authentifizierung entsperrt) oder zeitgebunden ist (d. h., es wird vorübergehend deaktiviert, bis der Nutzer auf ein Zeitintervall wartet). Dies gilt auch für alle anderen biometrischen Daten einer niedrigeren biometrischen Klasse. Im Fall einer zeitgebundenen Sperrung MUSS die Backoff-Zeit für die biometrische Überprüfung die maximale Backoff-Zeit aller biometrischen Daten sein.

    • [C-SR-12] Werden dringend empfohlen, wenn ein biometrisches Verfahren aufgrund zu vieler fehlgeschlagener Versuche vorübergehend gesperrt wird (d. h. das biometrische Verfahren wird deaktiviert, bis der Nutzer mit der primären Authentifizierung entsperrt) oder biometrisches Verfahren (das biometrische Verfahren wird vorübergehend deaktiviert, bis der Nutzer ein bestimmtes Zeitintervall wartet). Im Fall einer zeitgebundenen Sperrung wird UNBEDINGT die maximale Backoff-Zeit aller biometrischen Daten in der biometrischen Überprüfung empfohlen.

    • [C-7-2] MÜSSEN den Nutzer zur empfohlenen primären Authentifizierung auffordern (z. B. mit PIN, Muster, Passwort), um den Sperrzähler zurückzusetzen, wenn ein biometrisches Verfahren gesperrt wird. Klasse 3 darf den Sperrzähler für ein gesperrtes biometrisches Verfahren derselben oder einer niedrigeren Klasse zurücksetzen. Biometrische Verfahren der Klasse 2 oder Klasse 1 DÜRFEN KEINEN Sperrvorgang zum Zurücksetzen für biometrische Daten durchführen.

    Wenn in Geräteimplementierungen ein biometrischer Sensor als Klasse 1 (früher Nutzerfreundlichkeit) behandelt werden soll, gilt Folgendes:

    • [C-1-12] MUSS eine Spoofing- und Imposter-Akzeptanzrate von nicht mehr als 40 % pro Art des Präsentationsangriffs (PAI) haben, wie von den Android Biometrics Test Protocols gemessen.

    • [C-SR-13] Es wird dringend empfohlen, eine Spoofing- und Hochstufungsrate von maximal 30% pro Art des Präsentationsangriffs (PAI) gemäß den Android Biometrics Test Protocols zu verwenden.

    • [C-SR-14] wird dringend empfohlen, die biometrische Klasse des biometrischen Sensors und die entsprechenden Risiken der Aktivierung anzugeben.

    • [C-SR-17] wird dringend empfohlen, die neuen AIDL-Schnittstellen (z. B. IFace.aidl und IFingerprint.aidl) zu implementieren.

    Wenn in Geräteimplementierungen ein biometrischer Sensor als Klasse 2 (früher Schwach) behandelt werden soll, gilt Folgendes:

    • [C-SR-15] Es wird dringend empfohlen, die Akzeptanzrate von Spoofing und Hochstapler-Spoofen nicht über 20% pro Präsentationsangriffsart (PAI) zu setzen, wie von den Android Biometrics Test Protocols gemessen.

    • [C-2-3] MÜSSEN den biometrischen Abgleich in einer isolierten Ausführungsumgebung außerhalb des Android-Nutzer- oder Kernelbereichs wie der Trusted Execution Environment (TEE) oder auf einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder auf einer geschützten virtuellen Maschine durchführen, die die Anforderungen in Abschnitt 9.17 erfüllt.
    • [C-2-4] MÜSSEN alle identifizierbaren Daten verschlüsselt und kryptografisch authentifiziert haben, sodass sie außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal nicht außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal für die isolierte Ausführungsumgebung erfasst, gelesen oder geändert werden können, wie in den Implementierungsrichtlinien auf der Website des Android Open Source Project oder einer geschützten virtuellen Maschine, die von Hypervisor gesteuert wird, die die Anforderungen in Abschnitt 9.17 erfüllt, dokumentiert ist.
    • [C-2-5] Für kamerabasierte biometrische Verfahren und biometrische Authentifizierung oder Registrierung:
      • Die Kamera MÜSSEN in einem Modus betrieben werden, der verhindert, dass Kameraframes außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal gelesen oder geändert werden, in die isolierte Ausführungsumgebung oder eine geschützte virtuelle Maschine, die vom Hypervisor gesteuert wird und die Anforderungen in Abschnitt 9.17 erfüllt.
      • Bei RGB-Lösungen mit einer Kamera können die Kamerabilder außerhalb der isolierten Ausführungsumgebung lesbar sein, um Vorgänge wie die Vorschau für die Registrierung zu unterstützen, DÜRFEN aber dennoch NICHT geändert werden.
    • [C-2-7] DÜRFEN NICHT den unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder daraus abgeleitete Daten (z. B. Einbettungen) auf den Anwendungsprozessor außerhalb des Kontexts des TEE oder der vom Hypervisor gesteuerten geschützten virtuellen Maschine, die die Anforderungen in Abschnitt 9.17 erfüllt, zulassen. Geräteupgrades, die unter Android 9 oder niedriger gestartet wurden, sind nicht von C-2-7 ausgenommen.

    Wenn in Geräteimplementierungen ein biometrischer Sensor als Klasse 3 (früher Stark) behandelt werden soll, gilt Folgendes:

    • [C-SR-16] Es wird dringend empfohlen, eine Spoofing- und Hochstufungsrate von maximal 7% pro Art des Präsentationsangriffs (PAI) gemäß den Android Biometrics Test Protocols zu verwenden.

  • 7.3.13 IEEE 802.1.15.4 (UWB):

    Überarbeitung ansehen

    Wenn Geräteimplementierungen 802.1.15.4 unterstützen und die Funktionalität einer Drittanbieter-App 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 (vordefinierte Kombinationen von FIRA UCI-Parametern) unterstützen, die in der AOSP-Implementierung definiert sind.
      • CONFIG_ID_1: FiRa-definierte Unicast-STATIC STS DS-TWR-Bereichsbestimmung, verzögerter Modus, Bereichsintervall 240 ms.
      • CONFIG_ID_2: Von FiRa definierte 1:n-STATIC STS DS-TWR-Bereichsbestimmung, verzögerter Modus, Abstandsintervall 200 ms. Typischer Anwendungsfall: Smartphones interagieren mit vielen Smart-Home-Geräten.
      • CONFIG_ID_3: Entspricht CONFIG_ID_1, mit dem Unterschied, dass keine Daten zum Anlaufwinkel (AoA) gemeldet werden.
      • CONFIG_ID_4: Entspricht CONFIG_ID_1, mit dem Unterschied, dass der P-STS-Sicherheitsmodus aktiviert ist.
      • CONFIG_ID_5: Entspricht CONFIG_ID_2, mit dem Unterschied, dass der P-STS-Sicherheitsmodus aktiviert ist.
      • CONFIG_ID_6: Entspricht CONFIG_ID_3, mit dem Unterschied, dass der P-STS-Sicherheitsmodus aktiviert ist.
      • CONFIG_ID_7: Entspricht CONFIG_ID_2, mit dem Unterschied, dass der P-STS-Schlüsselmodus für einzelne Steuerelemente aktiviert ist.
    • [C-1-4] MÜSSEN eine Funktion anbieten, mit der der Nutzer das UWB-Radio ein- oder ausschalten kann.
    • [C-1-5] MÜSSEN erzwingen, dass Apps, die UWB-Funkschnittstelle verwenden, die Berechtigung UWB_RANGING (unter der Berechtigungsgruppe NEARBY_DEVICES) haben.

    Das Bestehen der relevanten Konformitäts- und Zertifizierungstests, die von Standardorganisationen wie FIRA, CCC und CSA definiert wurden, trägt dazu bei, dass 802.1.15.4 ordnungsgemäß funktioniert.

  • 7.4.1 Telefonie:

    Überarbeitung ansehen

    Der von den Android-APIs verwendete Begriff "Telefonie" bezieht sich in diesem Dokument speziell auf Hardware für das Tätigen von Sprachanrufen und das Senden von SMS-Nachrichten oder das Einrichten mobiler Daten über ein GSM-, CDMA-, LTE-, NR-)GSM- oder CDMA-Netzwerk. Ein Gerät, das „Telefonie“ unterstützt, kann je nach Produkt einige oder alle Anruf-, Messaging- und Datendienste anbieten.

    über ein GSM- oder CDMA-Netzwerk. Auch wenn diese Sprachanrufe paketversetzt werden können oder nicht, gelten sie für Android als unabhängig von anderen Datenverbindungen, die über dasselbe Netzwerk implementiert werden. Mit anderen Worten,die Android-Telefoniefunktion und -APIs beziehen sich speziell auf Sprachanrufe und SMS. Beispielsweise werden Geräteimplementierungen, die keine Anrufe tätigen oder SMS senden/empfangen können, nicht als Telefoniegerät betrachtet, unabhängig davon, ob sie ein Mobilfunknetz für die Datenverbindung verwenden.

  • 7.4.2 IEEE 802.11 (Wi-Fi):

    Überarbeitung ansehen

    Wenn Geräteimplementierungen 802.11 unterstützen und die Funktionalität einer Drittanbieter-App zur Verfügung stellen, geschieht Folgendes:

    • [C-1-4] MUSS Multicast-DNS (mDNS) unterstützen und DARF KEINE mDNS-Pakete (224.0.0.251 oder ff02::fb) zu jedem Zeitpunkt, auch wenn sich der Bildschirm nicht in einem aktiven Zustand befindet, filtern, es sei denn, das Löschen oder Filtern dieser Pakete ist notwendig, um in den für den Zielmarkt erforderlichen Bereichen des Stromverbrauchs zu bleiben. Für Android TV-Geräteimplementierungen, auch im Stand-by-Modus.

  • 7.4.3 Bluetooth:

    Überarbeitung ansehen

    Wenn in Geräteimplementierungen FEATURE_BLUETOOTH_LE deklariert ist, gilt Folgendes:

    • [C-SR-2] Es wird dringend empfohlen, den Rx-Versatz zu messen und zu kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei 1 m Abstand zu einem Referenzgerät, das Daten sendet, bei ADVERTISE_TX_POWER_HIGH beträgt. Die Geräte sind dabei auf parallelen Ebenen mit Bildschirmen ausgerichtet, die in die gleiche Richtung zeigen.
    • [C-SR-3] Es wird dringend empfohlen, den Tx-Versatz zu messen und zu kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -60 dBm +/-10 dB liegt, wenn das Scannen von einem Referenzgerät, das in 1 m Entfernung positioniert ist, und die Übertragung an ADVERTISE_TX_POWER_HIGH erfolgt. Dabei sind die Geräte so ausgerichtet, dass sie sich auf parallelen Ebenen befinden und Bildschirme in die gleiche Richtung zeigen.

    • [C-10-3] MÜSSEN den Rx-Offset messen und kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -55 dBm +/-10 dB in 1 m Entfernung von einem Referenzgerät liegt, das bei ADVERTISE_TX_POWER_HIGH sendet.
    • [C-10-4] MÜSSEN den Tx-Offset messen und kompensieren, um sicherzustellen, dass der Medianwert für BLE RSSI bei -55 dBm +/-10 dB liegt, wenn beim Scannen von einem Referenzgerät, das in einer Entfernung von 1 m positioniert ist, und bei der Übertragung bei ADVERTISE_TX_POWER_HIGH liegt.

    Wenn Geräteimplementierungen die Bluetooth-Version 5.0 unterstützen, gilt Folgendes:

    • [C-SR-4] Wir empfehlen Ihnen dringend, folgende Fragen zu unterstützen:
    • LE 2 Mio. PHY
    • LE-Codec PHY
    • LE-Werbeerweiterung
    • Regelmäßige Werbung
    • Mindestens 10 Anzeigensätze
    • Mindestens 8 gleichzeitige LE-Verbindungen. Jede Verbindung kann einer der Rollen von Verbindungstopologien zugewiesen sein.
    • LE-Link-Layer-Datenschutz
    • Eine Auflöseliste von mindestens 8 Einträgen

  • 7.4.9 UWB:

    Überarbeitung ansehen

    • [C-1-7] MÜSSEN darauf achten, dass der Medianwert der Entfernungsmessungen in 1 m vom Referenzgerät innerhalb von [0,75 m, 1,25 m] liegt, wobei der Ground-Truth-Abstand vom oberen Rand des DUTs gemessen wird. Das Gerät muss mit dem Display nach oben gehalten und um 45 Grad geneigt sein.

  • 7.5.1 Rückkamera:

    Überarbeitung ansehen

    Eine Kamera auf der Rückseite ist eine Kamera, die sich an der Seite des Geräts gegenüber dem Display befindet. Sie nimmt also wie eine herkömmliche Kamera Szenen auf der anderen Seite des Geräts auf.

    Eine Rückkamera ist eine nach außen gerichtete Kamera, die wie bei einer herkömmlichen Kamera Szenen auf der anderen Seite des Geräts erfasst. Bei Handheld-Geräten ist dies eine Kamera, die sich an der Seite des Geräts gegenüber dem Display befindet.

  • 7.5.2 Frontkamera:

    Überarbeitung ansehen

    Eine Frontkamera ist eine Kamera, die sich an der gleichen Seite des Geräts wie das Display befindet. Das ist eine Kamera, die in der Regel zum Abbilden des Nutzers verwendet wird, z. B. für Videokonferenzen und ähnliche Anwendungen.

    Eine Frontkamera ist eine Kamera, die in der Regel zum Abbilden des Nutzers verwendet wird, z. B. für Videokonferenzen und ähnliche Anwendungen. Bei Handheld-Geräten ist dies eine Kamera, die sich auf derselben Seite des Geräts wie der Bildschirm befindet.

  • 7.5.3 Externe Kamera:

    Überarbeitung ansehen

    Eine externe Kamera ist eine Kamera, die jederzeit an der Geräteimplementierung angebracht oder von ihr getrennt werden kann und in alle Richtungen zeigen kann, zum Beispiel USB-Kameras.

  • 7.5.4 Funktionsweise der Camera API:

    Überarbeitung ansehen

    Bei Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs für alle verfügbaren Kameras implementiert werden. Geräteimplementierungen:

    • [C-SR-1] Bei Geräten mit mehreren RGB-Kameras in unmittelbarer Nähe und, die in die gleiche Richtung gerichtet sind, wird dringend empfohlen, ein logisches Kameragerät mit der Funktion CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA zu unterstützen, die aus allen RGB-Kameras besteht, die in diese Richtung gerichtet sind, als physische Untergeräte.

  • 7.5.5 Kameraausrichtung:

    Überarbeitung ansehen

    Geräte, die alle der folgenden Kriterien erfüllen, sind von der oben genannten Anforderung ausgenommen:

    • Geräteimplementierungen, die nicht vom Nutzer gedreht werden können, z. B. Automobilgeräte.

  • 7.10 Haptik:

    Überarbeitung ansehen

    Geräte, die in der Hand gehalten oder getragen werden, können einen haptischen Bedienungselement für allgemeine Zwecke enthalten, das für verschiedene Zwecke zur Verfügung steht, einschließlich zum Erzeugen von Aufmerksamkeit durch Klingeltöne, Alarme, Benachrichtigungen und allgemeines Touch-Feedback.

    Wenn Geräteimplementierungen KEINEN derartigen haptischen Bedienungselement für allgemeine Zwecke enthalten, ist Folgendes zu beachten:

    • [7.10/C] MUSS für Vibrator.hasVibrator() "false" zurückgeben.

    Wenn Geräteimplementierungen mindestens einen solchen haptischen Bedienelement für allgemeine Zwecke enthalten, ist Folgendes möglich:

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

    Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.2.1.

9. Kompatibilität des Sicherheitsmodells

  • 9.1 Berechtigungen:

    Überarbeitung ansehen

    Geräteimplementierungen:

    • [C-0-4] MUSS nur eine Implementierung beider Benutzeroberflächen haben.

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

    • [C-4-1] MÜSSEN alle Anforderungen erfüllen, die in den Abschnitten 9.8.6 Inhalte erfassen und 9.8.6 Betriebssystem- und Umgebungsdaten und 9.8.15 Implementierungen von APIs in einer Sandbox beschrieben werden.

    • [C-4-2] DÜRFEN KEINE Berechtigung „android.permission.INTERNET“ haben. Dies ist strenger als die in Abschnitt 9.8.6 UNBEDINGT EMPFOHLENE EMPFEHLUNG.
    • [C-4-3] DÜRFEN NICHT an andere Apps gebunden werden, mit Ausnahme der folgenden System-Apps: Bluetooth, Kontakte, Medien, Telefonie, SystemUI und Komponenten, die Internet-APIs bereitstellen. Dies ist strenger als in Abschnitt 9.8.6 UNBEDINGT EMPFOHLEN.

    Wenn Geräteimplementierungen eine Standardanwendung zur Unterstützung von VoiceInteractionService enthalten, gilt Folgendes:

    • [C-5-1] DARF ACCESS_FINE_LOCATION NICHT als Standard für diese Anwendung zuweisen.

  • 9.5 Unterstützung für mehrere Nutzer:

    Überarbeitung ansehen

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

    • [C-4-5] MÜSSEN die Symbole der Dual-Instanz-Anwendung visuell abgrenzen, wenn sie den Nutzern angezeigt werden.
    • [C-4-6] MÜSSEN ein Nutzerangebot zum Löschen vollständiger Klonprofildaten angeben.
    • [C-4-7] MÜSSEN alle geklonten Apps deinstalliert, die privaten App-Datenverzeichnisse und deren Inhalte sowie die Klonprofildaten gelöscht werden, wenn sich der Nutzer entscheidet, gesamte geklonte Profildaten zu löschen.
    • SOLLTE den Nutzer auffordern, alle Daten des Klonprofils zu löschen, wenn die letzte Klon-App gelöscht wird.
    • [C-4-8] MÜSSEN den Nutzer darüber informieren, dass die App-Daten gelöscht werden, wenn die geklonte App deinstalliert wird, oder Nutzern die Möglichkeit bieten, die App-Daten zu behalten, wenn die App vom Gerät deinstalliert wird.
    • [C-4-9] MÜSSEN die privaten App-Datenverzeichnisse und deren Inhalte löschen, wenn der Nutzer sich entscheidet, die Daten während der Deinstallation zu löschen.

    • [C-4-14] MUSS für die in diesem zusätzlichen Profil ausgeführten Anwendungen eine separate Berechtigungs- und Speicherverwaltung haben

    • [C-4-5] DARF nur Apps im zusätzlichen Profil mit einer Launcher-Aktivität den Zugriff auf Kontakte erlauben, die für das übergeordnete Nutzerprofil bereits zugänglich sind.

  • 9.7 Sicherheitsfunktionen:

    Überarbeitung ansehen

    Eine Speichersicherheitstechnologie ist eine Technologie, mit der mindestens die folgenden Klassen von Fehlern mit einer hohen Wahrscheinlichkeit (> 90%) in Anwendungen behoben werden, die die Manifestoption android:memtagMode verwenden:

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

    Geräteimplementierungen:

    • [C-SR-15] wird dringend empfohlen, ro.arm64.memtag.bootctl_supported festzulegen.

    Wenn das Systemattribut ro.arm64.memtag.bootctl_supported bei Implementierungen auf Geräten auf „true“ gesetzt wird, geschieht Folgendes:

    • [C-3-1] MÜSSEN der Systemeigenschaft arm64.memtag.bootctl erlauben, eine durch Kommas getrennte Liste der folgenden Werte zu akzeptieren, wobei der gewünschte Effekt beim nächsten nachfolgenden Neustart angewendet wird:

      • memtag: Eine der oben definierten Speichersicherheitstechnologien ist aktiviert.
      • memtag-once: Eine wie oben definierte Speichersicherheitstechnologie ist vorübergehend aktiviert und beim nächsten Neustart automatisch deaktiviert.
      • memtag-off: Eine der oben definierten Speichersicherheitstechnologien ist deaktiviert.

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

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

    • [C-3-4] MÜSSEN arm64.memtag.bootctl beim Booten auf den aktuell angeforderten Status setzen. Wenn die Geräteimplementierung den Status ändern kann, ohne die Systemeigenschaft zu ändern, MUSS auch die Eigenschaft aktualisiert werden.

    • [C-SR-16] wird dringend empfohlen, eine Entwicklereinstellung anzuzeigen, die das Memtag-Ereignis einmalig festlegt und das Gerät neu startet. Mit einem kompatiblen Bootloader erfüllt das Android-Open-Source-Projekt die oben genannten Anforderungen über das MTE-Bootloader-Protokoll.

    • [C-SR-17] Es wird dringend empfohlen, im Menü "Sicherheitseinstellungen" eine Einstellung anzuzeigen, mit der Nutzer memtag aktivieren können.

  • 9.8.2 Aufzeichnung:

    Überarbeitung ansehen

    Geräteimplementierungen:

    • [C-0-2] MÜSSEN eine Nutzerwarnung anzeigen und die ausdrückliche Einwilligung des Nutzers einholen, damit alle vertraulichen Informationen, die auf dem Bildschirm des Nutzers angezeigt werden, erfasst werden können, die genau die gleiche Nachricht wie AOSP enthalten, wenn jeder und wenn eine Sitzung zur Erfassung des Bildschirms, Streamen oder Starten der Bildschirmaufzeichnung} über die APIs, das Streamen oder die Bildschirmaufzeichnung}{/1.1.1{.MediaProjection.createVirtualDisplay()1.VirtualDeviceManager.createVirtualDisplay() DÜRFEN Nutzern NICHT die Möglichkeit geben, die spätere Anzeige der Nutzereinwilligung zu deaktivieren.

    • [C-SR-1] Es wird dringend empfohlen, eine Nutzerwarnung anzuzeigen, die genau der in AOSP implementierten Nachricht entspricht, die jedoch geändert werden kann, solange der Nutzer deutlich darauf hingewiesen wird, dass vertrauliche Informationen auf dem Bildschirm des Nutzers erfasst werden.

    • [C-0-4] DÜRFEN Nutzern die Möglichkeit bieten, zukünftige Aufforderungen der Nutzereinwilligung zur Bildschirmaufnahme zu deaktivieren, es sei denn, die Sitzung wird von einer System-App gestartet, der der Nutzer associate() mit dem android.app.role.COMPANION_DEVICE_APP_STREAMING- oder dem android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING-Geräteprofil gestattet hat.

  • 9.8.6 Daten auf Betriebssystemebene und Umgebungsdaten: Dieser Abschnitt wurde von Content Capture und App-Suche in Betriebssystem- und Umgebungsdaten umbenannt.

    Überarbeitung ansehen

    Android unterstützt über die System-APIs ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query oder mit anderen proprietären Mitteln einen Mechanismus für Geräteimplementierungen, mit dem die folgenden Interaktionen zwischen Anwendungsdaten zwischen den Anwendungen und dem Nutzer für sensible Daten erfasst werden:

    • Alle Bildschirm- oder anderen Daten, die über AugmentedAutofillService an das System gesendet werden.
    • Alle Bildschirme oder andere Daten, auf die über die Content Capture API zugegriffen werden kann.
    • Alle Bildschirme oder andere Daten, auf die über die FieldClassificationService API zugegriffen werden kann
    • Alle Anwendungsdaten, die über die AppSearchManager API an das System übergeben und über AppSearchGlobalManager.query zugänglich sind.

    • Alle anderen Ereignisse, die eine App dem System über die Content Capture API oder die AppSearchManager API, eine ähnlich leistungsfähige Android- und proprietäre API, zur Verfügung stellt.

    • Audiodaten, die durch die Verwendung von SpeechRecognizer#onDeviceSpeechRecognizer() durch die Implementierung der Spracherkennung abgerufen wurden.
    • Audiodaten, die im Hintergrund (fortlaufend) über AudioRecord, SoundTrigger oder andere Audio-APIs abgerufen werden, ohne dass sie für den Nutzer sichtbar sind
    • Kameradaten, die im Hintergrund (fortlaufend) über CameraManager oder andere Kamera-APIs abgerufen werden, ohne dass für den Nutzer ein Indikator angezeigt wird

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

    • [C-1-3] DARF nur alle diese Daten und das Log vom Gerät unter Verwendung eines datenschutzfreundlichen Verfahrens gesendet werden, außer bei jeder Weitergabe der Daten mit ausdrücklicher Zustimmung des Nutzers. Der Datenschutzmechanismus ist definiert als „Mechanismen, die nur Analysen in aggregierter Form ermöglichen und den Abgleich protokollierter Ereignisse oder abgeleiteter Ergebnisse mit einzelnen Nutzern verhindern“, um zu verhindern, dass nutzerspezifische Daten introspektiv sind (z.B. durch Implementierung einer Differential Privacy-Technologie wie RAPPOR).

    • [C-1-5] DÜRFEN solche Daten NICHT an andere Betriebssystemkomponenten weitergeben, die nicht den im aktuellen Abschnitt (9.8.6 Inhaltserfassung) auf Betriebssystemebene und Umgebungsdaten beschriebenen Anforderungen entsprechen. Ausgenommen hiervon sind die ausdrücklichen Einwilligungen des Nutzers, die weitergegeben werden. Sofern diese Funktionen nicht als Android SDK API (AmbientContext, HotwordDetectionService) erstellt werden.

    • [C-1-6] MÜSSEN Nutzern die Möglichkeit bieten, solche Daten zu löschen, die von der ContentCaptureService-Implementierung oder mit den proprietären Mitteln erhoben werden, wenn wann die Daten in irgendeiner Form auf dem Gerät gespeichert werden. Wenn sich der Nutzer dafür entscheidet, die Daten zu löschen, MÜSSEN alle gesammelten Verlaufsdaten entfernt werden.

    • [C-SR-3] EMPFOHLENE Implementierung mit der Android SDK API oder einem ähnlichen Open-Source-Repository eines OEMs und / oder in einer Sandbox-Implementierung (siehe Abschnitt 9.8.15 Sandboxed API-Implementierungen).

    Android bietet über SpeechRecognizer#onDeviceSpeechRecognizer() die Möglichkeit, auf dem Gerät eine Spracherkennung durchzuführen, ohne das Netzwerk einzubeziehen. Jede Implementierung der Spracherkennung auf dem Gerät MUSS den in diesem Abschnitt beschriebenen Richtlinien entsprechen.

  • 9.8.10. Fehlerbericht zur Konnektivität:

    Überarbeitung ansehen

    Wenn Geräteimplementierungen das Funktions-Flag android.hardware.telephony deklarieren, geschieht Folgendes:

    • [C-1-4] Mit BUGREPORT_MODE_TELEPHONY generierte Berichte MÜSSEN mindestens die folgenden Informationen enthalten:
      • SubscriptionManagerService-Dump

  • 9.8.14. Credential Manager: entfernt

  • 9.8.15. Sandboxed API-Implementierungen: Neuer Abschnitt

    Überarbeitung ansehen

    Android bietet über eine Reihe von delegierten APIs einen Mechanismus, um sichere Betriebssystem- und Umgebungsdaten zu verarbeiten. Eine solche Verarbeitung kann an ein vorinstalliertes APK mit privilegiertem Zugriff und eingeschränkten Kommunikationsfunktionen delegiert werden. Dies wird als „Sandboxed API-Implementierung“ bezeichnet.

    Jede Sandboxed API-Implementierung:

    • [C-0-1] DARF NICHT die INTERNET-Berechtigung anfordern.
    • [C-0-2] DARF nur über strukturierte APIs auf das Internet zugreifen, die auf öffentlich verfügbaren Open-Source-Implementierungen basieren, die datenschutzfreundliche Mechanismen verwenden, oder indirekt über Android SDK APIs. Der Datenschutzmechanismus ist definiert als „Mechanismen, die nur die Analyse in aggregierter Form ermöglichen und den Abgleich protokollierter Ereignisse oder abgeleiteter Ergebnisse mit einzelnen Nutzern verhindern“, um zu verhindern, dass nutzerspezifische Daten nehmbar sind (z.B. implementiert mit einer Differential Privacy-Technologie wie RAPPOR).
    • [C-0-3] MÜSSEN die Dienste von anderen Systemkomponenten getrennt halten (z.B. nicht die Dienst- oder Freigabeprozess-IDs binden), mit folgenden Ausnahmen:
      • Telefonie, Kontakte, System-UI und Medien
    • [C-0-4] Nutzern DARF NICHT erlauben, die Dienste durch eine vom Nutzer installierbare Anwendung oder einen Dienst zu ersetzen
    • [C-0-5] MUSS nur den vorinstallierten Diensten erlauben, solche Daten zu erfassen. Es sei denn, die Ersatzfunktion ist in AOSP integriert (z.B. für Apps für digitale Assistenten).
    • [C-0-6] DÜRFEN zulassen, dass außer den Mechanismen der vorinstallierten Dienste nur die Apps der vorinstallierten Dienste solche Daten erfassen. Es sei denn, eine solche Erfassungsfunktion ist mit einer Android SDK API implementiert.
    • [C-0-7] MÜSSEN die Dienste zur Deaktivierung von Nutzerfunktionen anbieten.
    • [C-0-8] DARF NICHT auf die Nutzerangebote verzichten, um Android-Berechtigungen der Dienste zu verwalten und dem Android-Berechtigungsmodell zu folgen, wie in Abschnitt 9.1. Berechtigung:

  • 9.8.16. Kontinuierliche Audio- und Kameradaten: Neuer Abschnitt

    Überarbeitung ansehen

    Zusätzlich zu den in 9.8.2 Aufzeichnung, 9.8.6 Implementierungen auf Betriebssystem- und Umgebungsdaten und 9.8.15 API-Implementierungen in einer Sandbox beschriebenen Anforderungen, Implementierungen, die Audiodaten verwenden, die im Hintergrund (ständig) über AudioRecord, SoundTrigger oder andere Audio-APIs ODER Kamera-Daten im Hintergrund (fortlaufend) über CameraManager oder andere Kamera-APIs abgerufen werden:

    • [C-0-1] MÜSSEN eine entsprechende Anzeige (Kamera und/oder Mikrofon gemäß Abschnitt 9.8.2 Aufzeichnung) erzwingen, es sei denn:
    • [C-SR-1] Es wird dringend empfohlen, für jede Funktion, die solche Daten verwendet, die Einwilligung der Nutzer einzuholen. Diese Funktion sollte standardmäßig deaktiviert sein.
    • [C-SR-2] EMPFOHLEN, Kameradaten von einem tragbaren Remote-Gerät gleich zu behandeln (d.h., die in 9.8.2 Aufzeichnung, 9.8.6 Betriebssystem- und Umgebungsdaten, 9.8.15 Sandboxed API-Implementierungen und 9.8.16 Continuous Audio- und Kameradaten beschriebenen Einschränkungen) auf Kameradaten anzuwenden.

    Wenn die Kameradaten von einem Wearable-Remote-Gerät bereitgestellt werden und außerhalb des Android-Betriebssystems in unverschlüsselter Form außerhalb des Android-Betriebssystems, einer Sandbox-Implementierung oder einer von WearableSensingManager erstellten Sandbox-Funktion zugegriffen wird, gilt Folgendes:

    • [C-1-1] MUSS dem tragbaren Remote-Gerät angeben, dass dort eine zusätzliche Anzeige eingeblendet wird.

    Wenn Geräte die Möglichkeit bieten, ohne das zugewiesene Schlüsselwort mit einer Digital Assistant-Anwendung zu interagieren (entweder zur Verarbeitung allgemeiner Nutzeranfragen oder zur Analyse der Nutzerpräsenz über die Kamera):

    • [C-2-1] MÜSSEN dafür sorgen, dass eine solche Implementierung von einem Paket mit der Rolle android.app.role.ASSISTANT bereitgestellt wird.
    • [C-2-2] MÜSSEN darauf achten, dass bei dieser Implementierung HotwordDetectionService- und/oder VisualQueryDetectionService-Android-APIs verwendet werden.

  • 9.8.17. Telemetrie: Neuer Abschnitt

    Überarbeitung ansehen

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

    StatsManager bietet auch eine Möglichkeit zum Erfassen von Daten, die von Geräten mit einem datenschutzfreundlichen Mechanismus als datenschutzsensibel eingestuft werden. Insbesondere bietet die StatsManager::query API die Möglichkeit, eingeschränkte Messwertkategorien abzufragen, die in StatsLog definiert sind.

    Jede Implementierungsabfrage und das Erfassen eingeschränkter Messwerte von StatsManager:

    • [C-0-1] MUSS die einzige Anwendung/Implementierung auf dem Gerät sein und die Berechtigung READ_RESTRICTED_STATS haben.
    • [C-0-2] DARF nur Telemetriedaten und das Protokoll des Geräts unter Verwendung eines Mechanismus zur Einhaltung des Datenschutzes senden. Der Datenschutzmechanismus ist definiert als „Mechanismen, die nur Analysen in aggregierter Form ermöglichen und den Abgleich protokollierter Ereignisse oder abgeleiteter Ergebnisse mit einzelnen Nutzern verhindern“, um zu verhindern, dass nutzerspezifische Daten introspektiv sind (z.B. Implementierung mit einer Differential Privacy-Technologie wie RAPPOR).
    • [C-0-3] DÜRFEN solche Daten NICHT mit einer Nutzeridentität (z. B. Account) auf dem Gerät verknüpfen.
    • [C-0-4] DÜRFEN derartige Daten NICHT an andere Betriebssystemkomponenten weitergeben, die nicht den im aktuellen Abschnitt (9.8.17 Datenschutzfreundliche Telemetrie) beschriebenen Anforderungen entsprechen.
    • [C-0-5] MÜSSEN eine Funktion zum Aktivieren/Deaktivieren der datenschutzfreundlichen Erfassung, Verwendung und Weitergabe von Telemetriedaten zur Verfügung stellen.
    • [C-0-6] MÜSSEN Nutzern die Möglichkeit bieten, solche Daten zu löschen, die von der Implementierung erhoben werden, wenn diese in irgendeiner Form auf dem Gerät gespeichert werden. Wenn der Nutzer die Daten löschen möchte, MÜSSEN alle aktuell auf dem Gerät gespeicherten Daten entfernt werden.
    • [C-0-7] MÜSSEN die zugrunde liegende datenschutzfreundliche Protokollimplementierung in einem Open-Source-Repository offenlegen.
    • [C-0-8 ]MÜSSEN in diesem Abschnitt Richtlinien für ausgehenden Datentraffic erzwingen, um die Erfassung von Daten in eingeschränkten Messwertkategorien, die in StatsLog definiert sind, zu steuern.

  • 9.10 Geräteintegrität:

    Überarbeitung ansehen

    Geräteimplementierungen

    Wenn Geräteimplementierungen Dateiinhalte auf Seitenbasis prüfen können, gilt Folgendes:

    • [C-0-3 C-2-1] unterstützt die kryptografische Überprüfung von Dateiinhalten mit einem vertrauenswürdigen Schlüssel, ohne die gesamte Datei zu lesen.

    • [C-0-4 C-2-2] DARF NICHT zulassen, dass Leseanfragen für eine geschützte Datei erfolgreich sind, wenn der gelesene Inhalt nicht anhand eines vertrauenswürdigen Schlüssels verifiziert wird und nicht gemäß [C-2-1] oben überprüft wird.

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

  • 9.11 Schlüssel und Anmeldedaten:

    Überarbeitung ansehen

    Mit dem Android-Schlüsselspeichersystem können App-Entwickler kryptografische Schlüssel in einem Container speichern und über die KeyChain API oder die Keystore API für kryptografische Vorgänge verwenden. Geräteimplementierungen:

    • [C-0-3] MÜSSEN die Anzahl der fehlgeschlagenen primären Authentifizierungsversuche begrenzen.
    • [C-SR-2] Es wird dringend empfohlen, eine Obergrenze von 20 fehlgeschlagenen primären Authentifizierungsversuchen zu implementieren. Wenn Nutzer einwilligen und der Funktion zustimmen, sollten Sie nach Überschreiten der maximalen Anzahl fehlgeschlagener primärer Authentifizierungsversuche ein Zurücksetzen auf die Werkseinstellungen durchführen.

    Wenn bei Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden, wenn dies auf einem bekannten Secret basiert, und eine neue Authentifizierungsmethode verwendet wird, die als sichere Methode zum Sperren des Bildschirms behandelt wird, dann:

    • [C-SR-3] Eine PIN sollte mindestens 6 Ziffern oder eine 20-Bit-Entropie haben.
    • [C-2-1] Bei einer PIN mit weniger als 6 Ziffern DARF die automatische Eingabe ohne Nutzerinteraktion NICHT erlaubt werden, damit die PIN-Länge nicht offengelegt wird.

  • 9.11.1 Sicherer Sperrbildschirm, Authentifizierung und virtuelle Geräte:

    Überarbeitung ansehen

    Geräteimplementierungen:

    • [C-0-1] MÜSSEN die Anzahl der fehlgeschlagenen primären Authentifizierungsversuche begrenzen.
    • [C-SR-5] Es wird dringend empfohlen, eine Obergrenze von 20 fehlgeschlagenen primären Authentifizierungsversuchen zu implementieren. Wenn Nutzer der Funktion zustimmen und der Funktion zustimmen, nach Überschreiten des Limits für fehlgeschlagene primäre Authentifizierungsversuche ein Zurücksetzen auf die Werkseinstellungen durchführen.

    Wenn in Geräteimplementierungen eine numerische PIN als empfohlene primäre Authentifizierungsmethode festgelegt ist, gehe so vor:

    • [C-SR-6] Eine PIN sollte mindestens 6 Ziffern oder eine 20-Bit-Entropie haben.
    • [C-SR-7] Bei einer PIN mit weniger als 6 Ziffern wird dringend empfohlen, die automatische Eingabe ohne Nutzerinteraktion NICHT zu erlauben, um zu verhindern, dass die PIN offengelegt wird.

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

    [C-7-8] Der Nutzer MUSS mindestens alle 72 Stunden zu einer der empfohlenen Methoden zur primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden, es sei denn, die Sicherheit des Nutzers (z. B. Ablenkung des Fahrers) ist ein Problem.

    Wenn Geräteimplementierungen Anwendungen das Erstellen sekundärer virtueller Displays ermöglichen und zugehörige Eingabeereignisse unterstützen, z. B. über VirtualDeviceManager und die Bildschirme nicht mit VIRTUAL_DISPLAY_FLAG_SECURE gekennzeichnet sind, gilt Folgendes:

    [C-13-10] MÜSSEN die Installation von Apps deaktivieren, die über virtuelle Geräte initiiert wurden.

  • 9.17 Android Virtualization-Framework:

    Überarbeitung ansehen

    Wenn auf dem Gerät die Unterstützung der Android Virtualization Framework APIs (android.system.virtualmachine.*) implementiert ist, gilt für den Android-Host Folgendes:

    • [C-1-1] MUSS alle im Paket android.system.virtualmachine definierten APIs unterstützen.
    • [C-1-2] DARF NICHT das Android SELinux und das Berechtigungsmodell für die Verwaltung von geschützten virtuellen Maschinen (pVM) ändern.

    • [C-1-3] DARF die Neverallow-Regeln, die im vorgelagerten Android Open Source Project (AOSP) im vorgelagerten Android Open Source Project (AOSP) vorhanden sind, NICHT geändert, weggelassen oder ersetzt werden. Die Richtlinie MÜSSEN mit allen vorhandenen „Neverallow“-Regeln kompiliert werden.

    • [C-1-4] DÜRFEN nur von der Plattform signierten Code und privilegierte Anwendungen zulassenDÜRFEN NICHT zulassen, dass nicht vertrauenswürdiger Code (z.B. Drittanbieter-Apps) eine geschützte virtuelle MaschinepVM erstellt und ausführt. Hinweis: Das kann sich in zukünftigen Android-Versionen ändern.

    • [C-1-5] DARF einer geschützten virtuellen Maschine pVM NICHT erlauben, Code auszuführen, der nicht Teil des Factory-Images oder ihrer Updates ist. Alles, was nicht vom Android Verified Boot abgedeckt wird, z.B. Dateien, die aus dem Internet heruntergeladen oder per Sideload übertragen werden, DÜRFEN NICHT auf einer geschützten virtuellen Maschine ausgeführt werden.

    • [C-1-5] MUSS nur einer nicht Debug-fähigen pVM erlauben, Code vom Factory-Image oder von deren Plattformupdates auszuführen, was auch alle Aktualisierungen privilegierter Anwendungen umfasst.

    Wenn das Gerät die Unterstützung der Android Virtualization Framework APIs (android.system.virtualmachine.*) implementiert, gilt für jede Protected Virtual Machine pVM -Instanz Folgendes:

    • [C-2-1] MÜSSEN alle in der Virtualisierungs-APEX verfügbaren Betriebssysteme in einer geschützten virtuellen Maschine pVM ausführen können.
    • [C-2-2] DARF NICHT zulassen, dass eine geschützte virtuelle Maschine pVM ein Betriebssystem ausführt, das nicht vom Geräteimplementierer oder Betriebssystemanbieter signiert ist.
    • [C-2-3] DARF NICHT zulassen, dass eine geschützte virtuelle Maschine pVM Daten als Code ausführt (z.B. SELinux niemals erlaubt Ausführung von Ausführungen).

    • [C-2-4] DARF die „Neverallow“-Regeln im vorgelagerten Android Open Source Project (AOSP) im System/sepolicy/microdroid NICHT ändern, weglassen oder ersetzen.

    • [C-2-5] MÜSSEN auch für andere Betriebssysteme, die keine Microdroid-Betriebssysteme verwenden, Protected Virtual Machine pVM -Defense-in-Depth-Mechanismen implementieren (z.B. SELinux für pVMs).
    • [C-2-6] MÜSSEN sicherstellen, dass die pVM fehlschlägt die Firmware nicht startet, wenn die anfänglichen Images, die die Ausführung der VM nicht verifizieren können, nicht verifiziert werden kann. Die Überprüfung MUSS innerhalb der VM durchgeführt werden.
    • [C-2-7] MÜSSEN sicherstellen, dass die pVM ausfällt . Die Firmware verweigert den Start, wenn die Integrität von „instance.img“ kompromittiert wird.

    Wenn das Gerät die Unterstützung für die Android Virtualization Framework APIs (android.system.virtualmachine.*) implementiert, gilt für den Hypervisor Folgendes:

    • [C-3-1] MÜSSEN sicherstellen, dass Speicherseiten, die ausschließlich einer VM (entweder pVM oder Host-VM) gehören, nur für die virtuelle Maschine oder den Hypervisor zugänglich sind und nicht über andere virtuelle Maschinen – ob geschützt oder nicht geschützt. DÜRFEN KEINEN pVM Zugriff auf eine Seite gewähren, die zu einer anderen Entität wie einer anderen pVM oder einem Hypervisor gehört, es sei denn, der Seiteninhaber hat dies explizit freigegeben. Dies schließt die Host-VM ein. Dies gilt sowohl für CPU- als auch für DMA-Zugriffe.
    • [C-3-2] MÜSSEN eine Seite auf Werkseinstellungen zurücksetzen, nachdem sie von einer pVM verwendet wurde und bevor sie an den Host zurückgegeben wird (z.B. wenn die pVM gelöscht wird).
    • [C-3-3SR-1] Es wird dringend empfohlen, sicherzustellen, dass die pVM-Firmware vor Code in einer pVM geladen und ausgeführt wird.
    • [C-3-4] MÜSSEN sicherstellen, dass jede VM ein Secret pro VM ableitet, das {der einer pVM-Instanz bereitgestellten Boot Certificate Chain (BCC) und Compound Device Identifier (CDIs) nur von dieser bestimmten VM-Instanz abgeleitet werden kann und sich beim Zurücksetzen auf die Werkseinstellungen und OTA ändert.

    Wenn das Gerät die Unterstützung für die Android Virtualization Framework APIs implementiert, gilt für alle Bereiche:

    • [C-4-1] DARF KEINE Funktionen für eine pVM bereitstellen, die das Umgehen des Android-Sicherheitsmodells ermöglicht.

    Wenn auf dem Gerät die Unterstützung für die Android Virtualization Framework APIs implementiert ist, gilt Folgendes:

    • [C-5-1] MUSS in der Lage sein, die isolierte Kompilierung zu unterstützen, kann aber die Funktion für die isolierte Kompilierung auf der Gerätelieferung eines ART-Laufzeitupdates deaktivieren.

    Wenn auf dem Gerät die Unterstützung für Android Virtualization Framework APIs implementiert ist, gilt für die Schlüsselverwaltung Folgendes:

    • [C-6-1] MÜSSEN die DICE-Kette an einem Punkt starten, den der Nutzer selbst auf entsperrten Geräten nicht ändern kann. (Um sicherzustellen, dass es nicht gefälscht werden kann)

    • [C-SR-26-2] Dringend empfohlen, DICE als Mechanismus zur Secret-Ableitung pro VM zu verwenden. MÜSSEN die DICES richtig ausführen, d.h. die richtigen Werte angeben.

Nach oben