Android 14
8. April 2024
2. Gerätetypen
Siehe Überarbeitung
Starten Sie neue Anforderungen
Wenn Handheld-Geräteimplementierungen
FEATURE_BLUETOOTH_LE
deklarieren, gilt Folgendes:- [ 7.4 .3/H-1-3] MUSS den Rx-Offset messen und kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -50 dBm +/-15 dB in 1 m Entfernung von einem Referenzgerät beträgt, das mit
ADVERTISE_TX_POWER_HIGH
sendet. - [ 7.4 .3/H-1-4] MUSS den Tx-Offset messen und kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -50 dBm +/-15 dB beträgt, wenn von einem Referenzgerät gescannt wird, das sich in 1 m Entfernung befindet und mit
ADVERTISE_TX_POWER_HIGH
sendet.
- [ 7.4 .3/H-1-3] MUSS den Rx-Offset messen und kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -50 dBm +/-15 dB in 1 m Entfernung von einem Referenzgerät beträgt, das mit
Siehe Überarbeitung
Wenn Handheld-Geräteimplementierungen den System API
HotwordDetectionService
oder einen anderen Mechanismus zur Hotword-Erkennung ohne Mikrofonzugriffsanzeige 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 übergeben werden .
Siehe Überarbeitung
Ändern Sie [9.8/H-1-13] in:
- [9.8/H-SR-3] Es wird DRINGEND EMPFOHLEN, den Prozess, der den Hotword-Erkennungsdienst hostet, mindestens einmal pro Stunde oder alle 30 Hardware-Trigger-Ereignisse neu zu starten, je nachdem, was zuerst eintritt.
Siehe Überarbeitung
Anforderungen [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3] entfernt.
Siehe Überarbeitung
Wenn Handheld-Geräteimplementierungen
android.os.Build.VERSION_CODES.U
fürandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, dann:- [ 7.5 /H-1-3] MUSS die Eigenschaft
android.info.supportedHardwareLevel
alsFULL
oder besser für die hintere Primärkamera undLIMITED
oder besser für die vordere Primärkamera unterstützen.
- [ 7.5 /H-1-3] MUSS die Eigenschaft
Siehe Überarbeitung
Wenn Implementierungen von Fernsehgeräten nicht über ein integriertes Display verfügen, sondern stattdessen ein über HDMI angeschlossenes externes Display unterstützen, gilt Folgendes:
- [ 5.8 /T-0-1] MUSS den HDMI-Ausgabemodus auf die höchste Auflösung für das gewählte Pixelformat einstellen, das mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz für das externe Display funktioniert, abhängig von der Bildwiederholfrequenz für die Region, in der das Gerät verkauft wird in.
Der HDMI-Ausgabemodus MUSS so eingestellt werden, dass die maximale Auflösung ausgewählt wird, die mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz unterstützt werden kann.
- [ 5.8 /T-0-1] MUSS den HDMI-Ausgabemodus auf die höchste Auflösung für das gewählte Pixelformat einstellen, das mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz für das externe Display funktioniert, abhängig von der Bildwiederholfrequenz für die Region, in der das Gerät verkauft wird in.
3. Software
3.5.1. Anwendungsbeschränkung :
Siehe Überarbeitung
- Anforderung [C-1-9] entfernt
5. Multimedia-Kompatibilität
Siehe Überarbeitung
Wenn Geräteimplementierungen über
HDR_TYPE_DOLBY_VISION
die Unterstützung für den Dolby Vision-Decoder erklären, gilt Folgendes:- [C-1-3] MUSS die Spur-ID der abwärtskompatiblen Basisschicht(en) (sofern vorhanden) so einstellen, dass sie mit der Spur-ID der kombinierten Dolby Vision-Schicht übereinstimmt.
7. Hardwarekompatibilität
7.1.1.1. Bildschirmgröße und -form :
Siehe Überarbeitung
Wenn Geräteimplementierungen Bildschirme unterstützen, die die Größenkonfiguration
UI_MODE_TYPE_NORMAL
unterstützen und zum Rendern dieser Bildschirme physische Displays mit abgerundeten Ecken verwenden, gilt Folgendes:- [C-1-1] MUSS sicherstellen, dass für jede dieser Anzeigen mindestens eine der folgenden Anforderungen erfüllt ist:
- Wenn an jeder Ecke der logischen Anzeige
ein Feld mit 15und 18 dp x1518 dp verankert ist, ist mindestens ein Pixel jedes Felds auf dem Bildschirm sichtbar.
- Wenn an jeder Ecke der logischen Anzeige
- [C-1-1] MUSS sicherstellen, dass für jede dieser Anzeigen mindestens eine der folgenden Anforderungen erfüllt ist:
Siehe Überarbeitung
Folgende Anforderungen wurden wieder eingeführt:
Wenn Geräteimplementierungen
FEATURE_BLUETOOTH_LE
deklarieren, gilt Folgendes:[C-SR-2] Es wird DRINGEND EMPFOHLEN, den Rx-Offset zu messen und zu kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -60 dBm +/-10 dB in 1 m Entfernung von einem Referenzgerät beträgt, das bei
ADVERTISE_TX_POWER_HIGH
sendet, wobei die Geräte so ausgerichtet sind, dass sie es sind auf „parallelen Ebenen“ mit Bildschirmen, die in die gleiche Richtung zeigen.[C-SR-3] Werden DRINGEND EMPFOHLEN, den Tx-Offset zu messen und zu kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -60 dBm +/-10 dB beträgt, wenn von einem Referenzgerät gescannt wird, das sich in 1 m Entfernung befindet und bei
ADVERTISE_TX_POWER_HIGH
sendet, wo die Geräte ausgerichtet sind so dass sie sich auf „parallelen Ebenen“ befinden und die Bildschirme in die gleiche Richtung zeigen.
Siehe Überarbeitung
Anforderungen [C-10-3] und [C-10-4] nach 2.2.1 verschoben. Hardware .
- [C-10-3] MUSS den Rx-Offset messen und kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -55 dBm +/-10 dB in 1 m Entfernung von einem Referenzgerät beträgt, das mit
ADVERTISE_TX_POWER_HIGH
sendet. - [C-10-4] MUSS den Tx-Offset messen und kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -55 dBm +/-10 dB beträgt, wenn von einem Referenzgerät gescannt wird, das sich in 1 m Entfernung befindet und mit
ADVERTISE_TX_POWER_HIGH
sendet.
20. November 2023
2. Gerätetypen
Siehe Überarbeitung
Wenn Handheld-Geräteimplementierungen die Unterstützung eines 64-Bit-ABI (mit oder ohne 32-Bit-ABI) erklären:
Siehe Überarbeitung
- [ 7.5 /H-1-13] MUSS
LOGICAL_MULTI_CAMERA
Funktion für die primäre Rückkamera unterstützen, wenn mehr als eine RGB-Rückkamera vorhanden ist.
- [ 7.5 /H-1-13] MUSS
Siehe Überarbeitung
[ 5.8 /T-0-1] MUSS den HDMI-Ausgabemodus auf die höchste Auflösung für das gewählte SDR- oder HDR-Format einstellen, das mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz für das externe Display funktioniert.
Der HDMI-Ausgabemodus MUSS so eingestellt werden, dass die maximale Auflösung ausgewählt wird, die mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz unterstützt werden kann.
Siehe Überarbeitung
- [9/W-0-1] MUSS die
android.hardware.security.model.compatible feature
deklarieren.
- [9/W-0-1] MUSS die
6. Kompatibilität von Entwicklertools und -optionen
Siehe Überarbeitung
- [C-0-12] MUSS ein
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom in das schreiben
Siehe Überarbeitung
- [C-0-13] MUSS den Shell-Befehl
dumpsys gpu --gpuwork
zur Anzeige implementieren
- [C-0-12] MUSS ein
9. Kompatibilität des Sicherheitsmodells
Siehe Überarbeitung
Wenn Geräteimplementierungen einen Linux-Kernel verwenden, der SELinux unterstützen kann, gilt Folgendes:
Siehe Überarbeitung
Wenn Geräteimplementierungen einen anderen Kernel als Linux oder Linux ohne SELinux verwenden, gilt Folgendes:
4. Oktober 2023
2. Gerätetypen
Siehe Überarbeitung
Android-Geräteimplementierungen werden als Handheld klassifiziert, wenn sie alle folgenden Kriterien erfüllen:
- Sie müssen über eine physische Bildschirmdiagonale im Bereich von 4 Zoll
3,3 Zoll (oder 2,5 Zoll für Geräteimplementierungen, die auf API-Ebene 29 oder früher ausgeliefert wurden)bis 8 Zoll verfügen.
Starten Sie neue Anforderungen
- Verfügen Sie über eine Touchscreen-Eingabeschnittstelle.
- Sie müssen über eine physische Bildschirmdiagonale im Bereich von 4 Zoll
Siehe Überarbeitung
Implementierungen von Handheld-Geräten:
- [ 7.1 .1.1/H-0-1] MUSS über mindestens ein
Android-kompatibles Display verfügen, das alle in diesem Dokument beschriebenen Anforderungen erfüllt.Display, das an der kurzen Kante mindestens 2,2 Zoll und an der langen Kante mindestens 3,4 Zoll misst.
Wenn Handheld-Geräteimplementierungen die Software-Bildschirmdrehung unterstützen, gilt Folgendes:
- [ 7.1 .1.1/H-1-1]* MUSS dafür sorgen, dass der logische Bildschirm, der für Drittanwendungen zur Verfügung gestellt wird, mindestens 2 Zoll an der/den kurzen Kante(n) und 2,7 Zoll an der/den langen Kante(n) beträgt. Geräte, die mit Android API Level 29 oder früher ausgeliefert wurden, sind möglicherweise von dieser Anforderung ausgenommen.
Wenn Handheld-Geräteimplementierungen keine Software-Bildschirmdrehung unterstützen, gilt Folgendes:
- [ 7.1 .1.1/H-2-1]* MUSS dafür sorgen, dass der logische Bildschirm, der für Drittanwendungen zur Verfügung gestellt wird, an der/den kurzen Kante(n) mindestens 2,7 Zoll groß ist. Geräte, die mit Android API Level 29 oder früher ausgeliefert wurden, sind möglicherweise von dieser Anforderung ausgenommen.
Starten Sie neue Anforderungen
[ 7.1 .1.1/H-0-3]* MUSS jede
UI_MODE_NORMAL
-Anzeige, die für Drittanwendungen zur Verfügung gestellt wird, auf einen freien physischen Anzeigebereich abbilden, der mindestens 2,2 Zoll an der kurzen Kante und 3,4 Zoll an der langen Kante beträgt.[ 7.1 .1.3/H-0-1]* MUSS den Wert von
DENSITY_DEVICE_STABLE
auf 92 % oder mehr als die tatsächliche physikalische Dichte der entsprechenden Anzeige einstellen.
Wenn Handheld-Geräteimplementierungen
android.hardware.audio.output
undandroid.hardware.microphone
deklarieren, gilt Folgendes:[ 5.6 /H-1-1] MUSS eine mittlere kontinuierliche Round-Trip-Latenz von 300 Millisekunden oder weniger über 5 Messungen haben, mit einer mittleren absoluten Abweichung von weniger als 30 ms , über die folgenden Datenpfade: „Lautsprecher zu Mikrofon“, 3,5 mm Loopback-Adapter (falls unterstützt), USB-Loopback (falls unterstützt).
[ 5.6 /H-1-2] MUSS eine durchschnittliche Tap-to-Tone-Latenz von 300 Millisekunden oder weniger über mindestens 5 Messungen über den Datenpfad vom Lautsprecher zum Mikrofon aufweisen.
Wenn Handheld-Geräteimplementierungen mindestens einen haptischen Aktuator umfassen, gilt Folgendes:
- [ 7.10 /H]* SOLLTE KEINEN haptischen Aktuator (Vibrator) mit exzentrischer rotierender Masse (ERM) verwenden.
- [ 7.10 /h]* Sollte alle öffentlichen Konstanten für klare Haptik in Android.view.hapticfeedbackConstants implementieren (clock_tick, context_click, keyboard_press, keyboard_release, keyboard_tap, long_press, text_handle_move, virtual_key, virtual_key_relase, räume, release, release, gesture_relase, release, release, release, release, release, release, release, release, release, release, release, release, release, release, release, release, release, release, release, release.
- [ 7.10 /H]* SOLLTE alle öffentlichen Konstanten für klare Haptiken in android.os.VibrationEffect implementieren, nämlich (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK und EFFECT_DOUBLE_CLICK) und alle möglichen öffentlichen
PRIMITIVE_*
Konstanten für reichhaltige Haptiken in android.os.VibrationEffect.Composition , nämlich ( CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Einige dieser Grundelemente, wie z. B. LOW_TICK und SPIN, sind möglicherweise nur möglich, wenn der Vibrator relativ niedrige Frequenzen unterstützen kann. - [7.10/H]* SOLLTE der Anleitung zum Zuordnen öffentlicher Konstanten in android.view.HapticFeedbackConstants zu den empfohlenen android.os.VibrationEffect -Konstanten mit den entsprechenden Amplitudenbeziehungen folgen.
- [ 7.10 /H]* SOLLTE einer Qualitätsbewertung für die APIs createOneShot() und createWaveform() folgen.
- [ 7.10 /H]* SOLLTE überprüfen, ob das Ergebnis der öffentlichen android.os.Vibrator.hasAmplitudeControl() API die Fähigkeiten ihres Vibrators korrekt widerspiegelt.
- [ 7.10 /H]* SOLLTE den Aktuator in der Nähe der Stelle platzieren, an der das Gerät normalerweise mit den Händen gehalten oder berührt wird.
Wenn die Implementierung von Handgeräten mindestens einen Allzweck -7.10- Linearresonanzaktuator umfasst, gilt Folgendes:
- [ 7.10 /H] SOLLTE den Aktuator in der Nähe der Stelle platzieren, an der das Gerät normalerweise mit den Händen gehalten oder berührt wird.
- [ 7.10 /H] SOLLTE den haptischen Aktuator in der X-Achse (links-rechts) der natürlichen
Hochformatausrichtungdes Geräts bewegen.
Wenn Handheld-Geräteimplementierungen über einen universellen haptischen Aktuator verfügen, bei dem es sich um einen X-Achsen-Linearresonanzaktor (LRA) handelt, gilt Folgendes:
- [ 7.10 /H] SOLLTE die Resonanzfrequenz des X-Achsen-LRA unter 200 Hz liegen.
- [ 7.1 .1.1/H-0-1] MUSS über mindestens ein
Siehe Überarbeitung
Implementierungen von Handheld-Geräten MÜSSEN die folgenden Videokodierungsformate unterstützen und sie für Anwendungen von Drittanbietern verfügbar machen:
- [ 5.2 /H-0-3] AV1
Implementierungen von Handheld-Geräten MÜSSEN die folgenden Videodekodierungsformate unterstützen und sie für Anwendungen von Drittanbietern verfügbar machen:
- [ 5.3 /H-0-6] AV1
Siehe Überarbeitung
Wenn Geräteimplementierungen, einschließlich der Navigationstaste für die Funktion „Letzte“, wie in Abschnitt 7.2.3 beschrieben, die Schnittstelle ändern, geschieht Folgendes:
- [ 3.8 .3/H-1-1] MUSS das Verhalten beim Anheften des Bildschirms implementieren und dem Benutzer ein Einstellungsmenü zum Umschalten der Funktion bereitstellen.
Wenn Handheld-Geräteimplementierungen Unterstützung für
ControlsProviderService
undControl
APIs umfassen und Drittanbieteranwendungen die Veröffentlichung von Gerätesteuerelementen ermöglichen, dann gilt Folgendes:- [ 3.8 .16/H-1-6] Geräteimplementierungen MÜSSEN das Benutzerangebot wie folgt genau wiedergeben:
- Wenn das Gerät
config_supportsMultiWindow=true
festgelegt hat und die App die MetadatenMETA_DATA_PANEL_ACTIVITY
in derControlsProviderService
Deklaration deklariert, einschließlich des Komponentennamens einer gültigen Aktivität (wie durch die API definiert), dann MUSS die App diese Aktivität in dieses Benutzerangebot einbetten. - Wenn die App keine Metadaten
META_DATA_PANEL_ACTIVITY
deklariert, MUSS sie die angegebenen Felder so rendern, wie sie von derControlsProviderService
API bereitgestellt werden, sowie alle angegebenen Felder, die von den Control- APIs bereitgestellt werden.
- Wenn das Gerät
- [ 3.8 .16/H-1-7] Wenn die App die Metadaten
META_DATA_PANEL_ACTIVITY
deklariert, MUSS sie beim Starten der eingebetteten Aktivität den Wert der in [3.8.16/H-1-5] definierten Einstellung mitEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
übergeben.
Wenn Geräteimplementierungen es Benutzern ermöglichen, Anrufe jeglicher Art zu tätigen, können sie
- [ 7.4.1.2 /H-0-1] MUSS das Feature-Flag
android.software.telecom
deklarieren. - [ 7.4.1.2 /H-0-2] MUSS das Telekommunikations-Framework implementieren.
2.2.4. Leistung und Leistung :
Siehe Überarbeitung
Implementierungen von Handheld-Geräten:
- [ 8.5 /H-0-1] MUSS ein Benutzerangebot
im Menü „Einstellungen“bereitstellen , um alle Apps mit aktiven Vordergrunddiensten oder vom Benutzer initiierten Jobs anzuzeigen, einschließlich der Dauer jedes dieser Dienste seit seinem Start, wie im SDK-Dokument beschrieben .und die Möglichkeit, eine App zu stoppen, die einen Vordergrunddienst oder einen vom Benutzer initiierten Job ausführt.mit der Möglichkeit, eine App zu stoppen, die einen Vordergrunddienst ausführt, und alle Apps anzuzeigen, die über aktive Vordergrunddienste verfügen, sowie die Dauer jedes dieser Dienste seit dem Start, wie im SDK-Dokument beschrieben.- Einige Apps können möglicherweise vom Stoppen oder der Auflistung in einem solchen Benutzerangebot ausgenommen werden, wie im SDK-Dokument beschrieben.
- [ 8.5 /H-0-1] MUSS ein Benutzerangebot
- [ 8.5 /H-0-2]MUSS dem Benutzer die Möglichkeit bieten, eine App zu stoppen, die einen Vordergrunddienst oder einen vom Benutzer initiierten Job ausführt.
Siehe Überarbeitung
Wenn Geräteimplementierungen die Unterstützung für android.hardware.telephony
erklären, gilt Folgendes:
- [ 9.5 /H-1-1] DARF
UserManager.isHeadlessSystemUserMode
NICHT auftrue
gesetzt werden.
Wenn Geräteimplementierungen über einen sicheren Sperrbildschirm verfügen und einen oder mehrere Trust Agents enthalten, die die TrustAgentService
-System-API implementieren, gilt Folgendes:
- [ 9.11.1 /H-1-1] MUSS den Benutzer häufiger als einmal alle 72 Stunden nach einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) fragen.
Wenn Handheld-Geräteimplementierungen UserManager.isHeadlessSystemUserMode
auf true
setzen, werden sie
Wenn Handheld-Geräteimplementierungen den System API HotwordDetectionService
oder einen anderen Mechanismus zur Hotword-Erkennung ohne Mikrofonzugriffsanzeige unterstützen, gilt Folgendes:
- [9.8/H-1-1] MUSS sicherstellen, dass der Hotword-Erkennungsdienst nur Daten an das System,
ContentCaptureService
oder den Spracherkennungsdienst auf dem Gerät übertragen kann, der vonSpeechRecognizer#createOnDeviceSpeechRecognizer()
erstellt wurde. - [9.8/H-1-6] DARF NICHT zulassen, dass bei jedem erfolgreichen Hotword-Ergebnis mehr als 100 Byte Daten (ausgenommen Audiostreams) aus dem Hotword-Erkennungsdienst übertragen werden.
- [9.8/H-1-15] MUSS sicherstellen, dass Audiostreams, die bei erfolgreichen Hotword-Ergebnissen bereitgestellt werden, in einer Richtung vom Hotword-Erkennungsdienst zum Sprachinteraktionsdienst übertragen werden.
Wenn Geräteimplementierungen eine Anwendung umfassen, die die System-API HotwordDetectionService
oder einen ähnlichen Mechanismus zur Hotword-Erkennung ohne Angabe der Mikrofonnutzung verwendet, gilt für die Anwendung Folgendes:
- [9.8/H-2-3] DÜRFEN vom Hotword-Erkennungsdienst KEINE Audiodaten, Daten, die zur (ganz oder teilweise) Rekonstruktion des Audios verwendet werden können, oder Audioinhalte übertragen, die nichts mit dem Hotword selbst zu tun haben, außer an den
ContentCaptureService
oder Spracherkennungsdienst auf dem Gerät.
Wenn Handheld-Geräteimplementierungen die System-API VisualQueryDetectionService
oder einen anderen Mechanismus zur Abfrageerkennung ohne Mikrofon- und/oder Kamerazugriffsanzeige unterstützen, gilt Folgendes:
- [9.8/H-3-1] MUSS sicherstellen, dass der Abfrageerkennungsdienst Daten nur an das System oder
ContentCaptureService
oder den Spracherkennungsdienst auf dem Gerät (erstellt vonSpeechRecognizer#createOnDeviceSpeechRecognizer()
) übertragen kann. - [9.8/H-3-2] DARF NICHT zulassen, dass Audio- oder Videoinformationen aus dem
VisualQueryDetectionService
übertragen werden, außer anContentCaptureService
oder den Spracherkennungsdienst auf dem Gerät. - [9.8/H-3-3] MUSS einen Benutzerhinweis in der Benutzeroberfläche des Systems anzeigen, wenn das Gerät die Absicht des Benutzers erkennt, mit der Digital Assistant-Anwendung zu interagieren (z. B. durch Erkennen der Benutzeranwesenheit über die Kamera).
- [9.8/H-3-4] MUSS eine Mikrofonanzeige anzeigen und die erkannte Benutzeranfrage direkt nach der Erkennung der Benutzeranfrage in der Benutzeroberfläche anzeigen.
- [9.8/H-3-5] DARF NICHT zulassen, dass eine vom Benutzer installierbare Anwendung den visuellen Abfrageerkennungsdienst bereitstellt.
Siehe Überarbeitung
Wenn Handheld-Geräteimplementierungen android.os.Build.VERSION_CODES.T
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, dann:
- MÜSSEN die in Android 13 CDD Abschnitt 2.2.7.1 aufgeführten Medienanforderungen erfüllen.
Starten Sie neue Anforderungen
Wenn Handheld-Geräteimplementierungenandroid.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, dann:- [5.1/H-1-1] MUSS über die Methoden
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
die maximale Anzahl von Hardware-Video-Decoder-Sitzungen bekannt geben, die gleichzeitig in einer beliebigen Codec-Kombination ausgeführt werden können. - [5.1/H-1-2] MUSS 6 Instanzen von 8-Bit (SDR)-Hardware-Video-Decoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen bei 1080p-Auflösung bei 30 fps ausgeführt werden und 3 Sitzungen mit 4K-Auflösung bei 30 Bildern pro Sekunde, sofern nicht AV1. AV1-Codecs sind nur zur Unterstützung der 1080p-Auflösung erforderlich, müssen aber weiterhin 6 Instanzen mit 1080p30fps unterstützen.
- [5.1/H-1-3] MUSS über die Methoden
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
die maximale Anzahl von Hardware-Video-Encoder-Sitzungen bekannt geben, die gleichzeitig in einer beliebigen Codec-Kombination ausgeführt werden können. - [5.1/H-1-4] MÜSSEN 6 Instanzen von 8-Bit (SDR)-Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit 4 Sitzungen bei 1080p-Auflösung bei 30 fps ausgeführt werden und 2 Sitzungen mit 4K-Auflösung bei 30 Bildern pro Sekunde, sofern nicht AV1. AV1-Codecs sind nur zur Unterstützung der 1080p-Auflösung erforderlich, müssen aber weiterhin 6 Instanzen mit 1080p30fps unterstützen.
- [5.1/H-1-5] MUSS die maximale Anzahl von Hardware-Video-Encoder- und Decoder-Sitzungen bekannt geben, die gleichzeitig in jeder Codec-Kombination über die Methoden
CodecCapabilities.getMaxSupportedInstances()
undVideoCapabilities.getSupportedPerformancePoints()
ausgeführt werden können. - [5.1/H-1-6] MÜSSEN 6 Instanzen von 8-Bit (SDR)-Hardware-Video-Decoder- und Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in jeder Codec-Kombination unterstützen, die gleichzeitig mit 3 Sitzungen bei 4K ausgeführt werden @30fps-Auflösung (außer AV1), davon höchstens 2 Encoder-Sitzungen und 3 Sitzungen mit 1080p-Auflösung. AV1-Codecs sind nur zur Unterstützung der 1080p-Auflösung erforderlich, müssen aber weiterhin 6 Instanzen mit 1080p30fps unterstützen.
- [5.1/H-1-19] MÜSSEN 3 Instanzen von 10-Bit (HDR)-Hardware-Video-Decoder- 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 Bildern pro Sekunde ausgeführt werden (außer AV1), von denen höchstens 1 eine Encodersitzung ist, die im RGBA_1010102-Eingabeformat über eine GL-Oberfläche konfiguriert werden könnte. Bei der Kodierung über die GL-Oberfläche ist die Generierung von HDR-Metadaten durch den Encoder nicht erforderlich. AV1-Codec-Sitzungen müssen nur die Auflösung 1080p unterstützen, selbst wenn diese Anforderung 4K erfordert.
- [5.1/H-1-7] MUSS eine Codec-Initialisierungslatenz von 40 ms oder weniger für eine 1080p- oder kleinere Videokodierungssitzung für alle Hardware-Videokodierer unter Last haben. Unter „Laden“ versteht man eine gleichzeitige reine Videotranskodierungssitzung von 1080p in 720p unter Verwendung von Hardware-Videocodecs zusammen mit der Initialisierung der 1080p-Audio-Video-Aufzeichnung. Für den Dolby Vision-Codec MUSS die Codec-Initialisierungslatenz 50 ms oder weniger betragen.
- [5.1/H-1-8] MUSS eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiocodierungssitzung mit einer Bitrate von 128 kbps oder niedriger für alle Audio-Encoder unter Last haben. Unter „Laden“ versteht man eine gleichzeitige reine Videotranskodierungssitzung von 1080p in 720p unter Verwendung von Hardware-Videocodecs zusammen mit der Initialisierung der 1080p-Audio-Video-Aufzeichnung.
- [5.1/H-1-9] MÜSSEN 2 Instanzen sicherer Hardware-Video-Decoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit 4K-Auflösung bei 30 fps (außer AV1) für beide 8- Bit (SDR) und 10-Bit HDR-Inhalte. AV1-Codec-Sitzungen müssen nur die Auflösung 1080p unterstützen, selbst wenn diese Anforderung 4K erfordert.
- [5.1/H-1-10] MÜSSEN 3 Instanzen nicht sicherer Hardware-Video-Decoder-Sitzungen zusammen mit 1 Instanz sicherer Hardware-Video-Decoder-Sitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, AV1 oder höher) in jedem Codec unterstützen Kombination, die gleichzeitig mit 3 Sitzungen bei 4K-Auflösung bei 30 fps (außer AV1) läuft, die eine sichere Decoder-Sitzung und 1 nn-sichere Sitzung bei 1080p-Auflösung bei 30 fps umfasst, wobei höchstens 2 Sitzungen in 10-Bit-HDR stattfinden können. AV1-Codec-Sitzungen müssen nur die Auflösung 1080p unterstützen, selbst wenn diese Anforderung 4K erfordert.
- [5.1/H-1-11] MUSS einen sicheren Decoder für jeden Hardware-AVC-, HEVC-, VP9- oder AV1-Decoder auf dem Gerät unterstützen.
- [5.1/H-1-12] MUSS eine Codec-Initialisierungslatenz von 40 ms oder weniger für eine 1080p- oder kleinere Videodekodierungssitzung für alle Hardware-Videodecoder unter Last haben. Unter „Laden“ versteht man eine gleichzeitige reine Videotranskodierungssitzung von 1080p in 720p unter Verwendung von Hardware-Videocodecs zusammen mit der Initialisierung der 1080p-Audio-Video-Wiedergabe. Für den Dolby Vision-Codec MUSS die Codec-Initialisierungslatenz 50 ms oder weniger betragen.
- [5.1/H-1-13] MUSS eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiodekodierungssitzung mit einer Bitrate von 128 kbps oder niedriger für alle Audiodecoder unter Last haben. Unter „Laden“ versteht man eine gleichzeitige reine Videotranskodierungssitzung von 1080p in 720p unter Verwendung von Hardware-Videocodecs zusammen mit der Initialisierung der 1080p-Audio-Video-Wiedergabe.
- [5.1/H-1-14] MUSS den AV1-Hardware-Decoder Main 10, Level 4.1 und Filmkörnung unterstützen.
- [5.1/H-1-15] MUSS über mindestens 1 Hardware-Videodecoder verfügen, der 4K60 unterstützt.
- [5.1/H-1-16] MUSS über mindestens einen Hardware-Video-Encoder verfügen, der 4K60 unterstützt.
- [5.3/H-1-1] Bei einer 4K-Videositzung mit 60 fps unter Last DARF NICHT mehr als 1 Frame in 10 Sekunden verloren gehen (d. h. weniger als 0,167 Prozent Frame Drop).
- [5.3/H-1-2] Während einer Änderung der Videoauflösung in einer 60-fps-Videositzung unter Last für eine 4K-Sitzung DARF NICHT mehr als 1 Bild in 10 Sekunden verloren gehen.
- [5.6/H-1-1] MUSS eine Tap-to-Tone-Latenz von 80 Millisekunden oder weniger haben, wenn der CTS Verifier Tap-to-Tone-Test verwendet wird.
- [5.6/H-1-2] MUSS über mindestens einen unterstützten Datenpfad eine Audio-Round-Trip-Latenz von 80 Millisekunden oder weniger haben.
- [5.6/H-1-3] MUSS >=24-Bit-Audio für die Stereoausgabe über 3,5-mm-Audiobuchsen (falls vorhanden) und über USB-Audio unterstützen, wenn dies über den gesamten Datenpfad für Konfigurationen mit geringer Latenz und Streaming unterstützt wird. Für die Konfiguration mit geringer Latenz sollte AAudio von der App im Rückrufmodus mit geringer Latenz verwendet werden. Für die Streaming-Konfiguration sollte ein Java AudioTrack von der App verwendet werden. Sowohl in der Konfiguration mit geringer Latenz als auch in der Streaming-Konfiguration sollte die HAL-Ausgabesenke entweder
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
oderAUDIO_FORMAT_PCM_FLOAT
als Zielausgabeformat akzeptieren. - [5.6/H-1-4] MUSS >=4-Kanal-USB-Audiogeräte unterstützen (Dies wird von DJ-Controllern für die Vorschau von Songs verwendet.)
- [5.6/H-1-5] MUSS klassenkompatible MIDI-Geräte unterstützen und das MIDI-Feature-Flag deklarieren.
- [5.6/H-1-9] MUSS mindestens 12-Kanal-Mischung unterstützen. Dies impliziert die Möglichkeit, einen AudioTrack mit 7.1.4-Kanalmaske zu öffnen und alle Kanäle ordnungsgemäß zu verräumlichen oder auf Stereo herunterzumischen.
- [5.6/H-SR] Es wird DRINGEND EMPFOHLEN, 24-Kanal-Mischung mit mindestens Unterstützung für 9.1.6- und 22.2-Kanal-Masken zu unterstützen.
- [5.7/H-1-2] MUSS
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
mit den folgenden Inhaltsentschlüsselungsfunktionen unterstützen.
Mindestprobengröße | 4 MiB |
Mindestanzahl an Teilproben – H264 oder HEVC | 32 |
Mindestanzahl an Teilproben – VP9 | 9 |
Mindestanzahl an Teilproben – AV1 | 288 |
Mindestgröße des Teilprobenpuffers | 1 MiB |
Mindestgröße des generischen Kryptopuffers | 500 KiB |
Mindestanzahl gleichzeitiger Sitzungen | 30 |
Mindestanzahl von Schlüsseln pro Sitzung | 20 |
Mindestgesamtzahl der Schlüssel (alle Sitzungen) | 80 |
Mindestgesamtzahl der DRM-Schlüssel (alle Sitzungen) | 6 |
Nachrichtengröße | 16 KiB |
Entschlüsselte Frames pro Sekunde | 60 fps |
- [5.1/H-1-17] MUSS über mindestens einen Hardware-Bilddecoder verfügen, der das AVIF Baseline Profile unterstützt.
- [5.1/H-1-18] MUSS den AV1-Encoder unterstützen, der eine Auflösung von bis zu 480p bei 30 Bildern pro Sekunde und 1 Mbit/s kodieren kann.
-
[5.12/H-1-1] MUSS[5.12/H-SR] dringend empfohlen werden, um die FunktionFeature_HdrEditing
für alle auf dem Gerät vorhandenen Hardware-AV1- und HEVC-Encoder zu unterstützen. - [5.12/H-1-2] MUSS das Farbformat RGBA_1010102 für alle auf dem Gerät vorhandenen Hardware-AV1- und HEVC-Encoder unterstützen.
- [5.12/H-1-3] MUSS Unterstützung für die Erweiterung EXT_YUV_target ankündigen, um YUV-Texturen in 8 und 10 Bit abzutasten.
- [7.1.4/H-1-1] MÜSSEN mindestens 6 Hardware-Overlays im Hardware Composer (HWC) der Datenverarbeitungseinheit (DPU) haben, von denen mindestens 2 10-Bit-Videoinhalte anzeigen können.
Wenn Handheld-Geräteimplementierungen android.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben und Unterstützung für einen Hardware-AVC- oder HEVC-Encoder enthalten, dann gilt Folgendes:
- [5.2/H-2-1] MUSS das Mindestqualitätsziel erfüllen, das durch die Video-Encoder-Raten-Verzerrungskurven für Hardware-AVC- und HEVC-Codecs definiert wird, wie in der kommenden Dokumentation definiert.
Siehe Überarbeitung
android.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, dann:- [ 7.5 /H-1-1] MUSS über eine primäre nach hinten gerichtete Kamera mit einer Auflösung von mindestens 12 Megapixeln verfügen, die Videoaufnahme mit 4K bei 30 Bildern pro Sekunde unterstützt. Die primäre nach hinten gerichtete Kamera ist die nach hinten gerichtete Kamera mit der niedrigsten Kamera-ID.
- [ 7.5 /H-1-2] MUSS über eine primäre Frontkamera mit einer Auflösung von mindestens 6 Megapixeln verfügen und die Videoaufnahme mit 1080p bei 30 Bildern pro Sekunde 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
als FULL oder besser für beide Primärkameras unterstützen. - [ 7.5 /H-1-4] MUSS
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
für beide Primärkameras unterstützen. - [ 7.5 /H-1-5] MUSS eine JPEG-Aufnahmelatenz von Kamera2 < 1000
900ms für eine Auflösung von 1080p haben, gemessen durch den CTS-Kamera-PerformanceTest unter ITS-Lichtbedingungen (3000 K) für beide Primärkameras. - [ 7.5 /H-1-6] MUSS eine Startlatenz von Kamera2 (geöffnete Kamera bis zum ersten Vorschaubild) von < 500 ms haben, gemessen durch den CTS-Kamera-PerformanceTest unter ITS-Lichtbedingungen (3000 K) für beide Primärkameras.
- [ 7.5 /H-1-8] MUSS
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
undandroid.graphics.ImageFormat.RAW_SENSOR
für die primäre Rückkamera unterstützen. - [ 7.5 /H-1-9] MUSS über eine nach hinten gerichtete Hauptkamera verfügen, die 720p oder 1080p bei 240fps unterstützt.
- [ 7.5 /H-1-10] MUSS ein minimales ZOOM_RATIO < 1,0 für die Primärkameras haben, wenn eine Ultrawide-RGB-Kamera in die gleiche Richtung zeigt.
- [ 7.5 /H-1-11] MUSS gleichzeitiges Front-Back-Streaming auf Primärkameras implementieren.
- [ 7.5 /H-1-12] MUSS
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
sowohl für die primäre vordere als auch die primäre hintere Kamera unterstützen. - [ 7.5 /H-1-13] MUSS
LOGICAL_MULTI_CAMERA
Funktion für die Primärkameras unterstützen, wenn mehr als eine RGB-Kamera in die gleiche Richtung zeigt. - [ 7.5 /H-1-14] MUSS
STREAM_USE_CASE
Funktion sowohl für die primäre vordere als auch die primäre hintere Kamera unterstützen. - [ 7.5 /H-1-15] MUSS
Bokeh- undNachtmodus-Erweiterungen über die CameraX- und Camera2-Erweiterungen für Primärkameras unterstützen. - [ 7.5 /H-1-16] MUSS die DYNAMIC_RANGE_TEN_BIT-Fähigkeit 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.
Siehe Überarbeitung
android.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, dann:- [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 über ein HDR-Display verfügen, das mindestens 1000 Nits durchschnittlich unterstützt.
- [7.6.1/H-2-1] MUSS über mindestens 8 GB physischen Speicher verfügen.
Siehe Überarbeitung
android.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, dann:- [8.2/H-1-1] MUSS eine sequentielle Schreibleistung von mindestens 150 MB/s gewährleisten.
- [8.2/H-1-2] MUSS eine zufällige Schreibleistung von mindestens 10 MB/s gewährleisten.
- [8.2/H-1-3] MUSS eine sequentielle Leseleistung von mindestens 250 MB/s gewährleisten.
- [8.2/H-1-4] MUSS eine zufällige Leseleistung von mindestens 100 MB/s gewährleisten.
- [8.2/H-1-5] MUSS eine parallele sequentielle Lese- und Schreibleistung mit 2x Lese- und 1x Schreibleistung von mindestens 50 MB/s gewährleisten.
Siehe Überarbeitung
Implementierungen von Fernsehgeräten MÜSSEN die folgenden Videokodierungsformate unterstützen und sie für Anwendungen von Drittanbietern verfügbar machen:
- [ 5.2 /T-0-3] AV1
Implementierungen von Fernsehgeräten MÜSSEN die folgenden Videodekodierungsformate unterstützen und sie für Anwendungen von Drittanbietern verfügbar machen:
- [ 5.3.2 /T-0-7] AV1
Siehe Überarbeitung
Wenn Geräteimplementierungen über einen sicheren Sperrbildschirm verfügen und einen oder mehrere Trust Agents enthalten, die die TrustAgentService
-System-API implementieren, gilt Folgendes:
- [ 9.11.1 /W-1-1] MUSS den Benutzer häufiger als einmal alle 72 Stunden nach einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) fragen.
Siehe Überarbeitung
Wenn Geräteimplementierungen Unterstützung für AM/FM-Rundfunk beinhalten und die Funktionalität für jede Anwendung verfügbar machen, gilt Folgendes:
- [ 7.4
.10/A-0-1] MUSS Unterstützung fürFEATURE_BROADCAST_RADIO
deklarieren.
Eine Außenkamera ist eine Kamera, die Szenen außerhalb der Geräteimplementierung aufnimmt, wie die Rückfahrkamera.
Implementierungen von Automobilgeräten:
- SOLLTE eine oder mehrere Außenkameras enthalten.
Wenn Automotive-Geräteimplementierungen eine Außenansichtskamera umfassen, gilt für eine solche Kamera Folgendes:
- [ 7.5 /A-1-1] DÜRFEN KEINE Außenkameras haben, auf die über die Android-Kamera-APIs zugegriffen werden kann, es sei denn, sie erfüllen die Kernanforderungen der Kamera.
- [ 7.5 /A-SR-1] Es wird DRINGEND EMPFOHLEN, die Kameravorschau nicht zu drehen oder horizontal zu spiegeln.
- [ 7.5 /A-SR-2] Es wird DRINGEND EMPFOHLEN, dass die Auflösung mindestens 1,3 Megapixel beträgt.
- SOLLTE entweder über Hardware mit festem Fokus oder EDOF (erweiterte Tiefenschärfe) verfügen.
- Möglicherweise ist im Kameratreiber entweder Hardware-Autofokus oder Software-Autofokus implementiert.
Wenn Implementierungen von Automobilgeräten eine oder mehrere Außenkameras umfassen und den Dienst „Exterieur View System“ (EVS) laden, dann gilt für eine solche Kamera Folgendes:
- [ 7.5 /A-2-1] DARF die Kameravorschau NICHT gedreht oder horizontal gespiegelt werden.
Implementierungen von Automobilgeräten:
- KANN eine oder mehrere Kameras enthalten, die für Anwendungen von Drittanbietern verfügbar sind.
Wenn Implementierungen von Automobilgeräten mindestens eine Kamera umfassen und diese für Anwendungen von Drittanbietern verfügbar machen, dann gilt Folgendes:
- [ 7.5 /A-3-1] MUSS das Feature-Flag
android.hardware.camera.any
melden. - [ 7.5 /A-3-2] DARF die Kamera nicht als Systemkamera deklariert werden.
- Unterstützt möglicherweise die in Abschnitt 7.5.3 beschriebenen externen Kameras.
- KANN Funktionen (wie Autofokus usw.) umfassen, die für nach hinten gerichtete Kameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.
Eine nach hinten gerichtete Kamera bezeichnet eine nach außen gerichtete Kamera, die an einer beliebigen Stelle des Fahrzeugs angebracht werden kann und auf die Außenseite der Fahrzeugkabine gerichtet ist; Das heißt, es nimmt Szenen auf der anderen Seite der Fahrzeugkarosserie auf, wie die Rückfahrkamera.
Eine nach vorne gerichtete Kamera bezeichnet eine dem Benutzer zugewandte Kamera, die sich an einer beliebigen Stelle des Fahrzeugs befinden kann und in die Fahrzeugkabine zeigt. Das heißt, es stellt Bilder des Benutzers dar, beispielsweise für Videokonferenzen und ähnliche Anwendungen.
Implementierungen von Automobilgeräten:
- [7.5/A-SR-1] Es wird DRINGEND EMPFOHLEN, eine oder mehrere nach außen gerichtete Kameras einzubinden.
- KANN eine oder mehrere dem Benutzer zugewandte Kameras umfassen.
- [7.5/A-SR-2] Werden DRINGEND EMPFOHLEN, um das gleichzeitige Streaming mehrerer Kameras zu unterstützen.
Wenn Implementierungen von Automobilgeräten mindestens eine nach außen gerichtete Kamera umfassen, gilt für eine solche Kamera Folgendes:
- [7.5/A-1-1] MUSS so ausgerichtet sein, dass die lange Dimension der Kamera mit der XY-Ebene der Android-Automobilsensorachsen übereinstimmt.
- [7.5/A-SR-3] Es wird DRINGEND EMPFOHLEN, entweder über Hardware mit festem Fokus oder EDOF (Extended Depth of Field) zu verfügen.
- [7.5/A-1-2] MUSS die primäre zur Welt gerichtete Kamera als die zur Welt gerichtete Kamera mit der niedrigsten Kamera-ID haben.
Wenn Automotive-Geräteimplementierungen mindestens eine dem Benutzer zugewandte Kamera umfassen, gilt für eine solche Kamera Folgendes:
- [7.5/A-2-1] Die primäre dem Benutzer zugewandte Kamera MUSS die dem Benutzer zugewandte Kamera mit der niedrigsten Kamera-ID sein.
- Kann so ausgerichtet werden, dass die lange Dimension der Kamera mit der XY-Ebene der Android-Automobilsensorachsen übereinstimmt.
Wenn Automotive-Geräteimplementierungen eine Kamera umfassen, auf die entweder über die API android.hardware.Camera
oder android.hardware.camera2
zugegriffen werden kann, gilt Folgendes:
- [7.5/A-3-1] MUSS den grundlegenden Kameraanforderungen in Abschnitt 7.5 entsprechen.
Wenn Automotive-Geräteimplementierungen eine Kamera enthalten, auf die weder über die API android.hardware.Camera
noch über die API android.hardware.camera2
zugegriffen werden kann, gilt Folgendes:
- [7.5/A-4-1] MUSS über den Extended View System-Dienst zugänglich sein.
Wenn Automotive-Geräteimplementierungen eine oder mehrere Kameras umfassen, auf die über den Extended View System Service zugegriffen werden kann, gilt für eine solche Kamera Folgendes:
- [7.5/A-5-1] DARF die Kameravorschau NICHT gedreht oder horizontal gespiegelt werden.
- [7.5/A-SR-4] Es wird DRINGEND EMPFOHLEN, dass die Auflösung mindestens 1,3 Megapixel beträgt.
Wenn Implementierungen von Automobilgeräten eine oder mehrere Kameras umfassen, auf die sowohl über den Extended View System Service als auch über die API android.hardware.Camera
oder android.hardware.Camera2
zugegriffen werden kann, gilt für eine solche Kamera Folgendes:
- [7.5/A-6-1] MUSS dieselbe Kamera-ID melden.
Wenn Implementierungen von Automobilgeräten eine proprietäre Kamera-API bereitstellen, gilt Folgendes:
- [7.5/A-7-1] MUSS eine solche Kamera-API mithilfe
android.hardware.camera2
-API oder der Extended View System-API implementieren.
Siehe Überarbeitung
Implementierungen von Automobilgeräten:
- [ 3.8 /A-0-1] Vollständigen Sekundärbenutzern, die nicht der aktuelle Vordergrundbenutzer sind, DARF NICHT gestattet werden, Aktivitäten zu starten und auf allen Displays Zugriff auf die Benutzeroberfläche zu haben.
Siehe Überarbeitung
Wenn Automotive-Geräteimplementierungen android.hardware.microphone
deklarieren, gilt Folgendes:
- [ 9.8.2 /A-1-1] MUSS die Mikrofonanzeige anzeigen, wenn eine App auf Audiodaten vom Mikrofon zugreift, aber nicht, wenn auf das Mikrofon nur von
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
oder Apps mit den im Abschnitt genannten Rollen zugegriffen wird 9.1 mit CDD-Kennung [C-4-X]. - [ 9.8.2 /A-1-2] DARF die Mikrofonanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Benutzerinteraktion nicht ausgeblendet werden.
- [ 9.8.2 /A-1-3] MUSS dem Benutzer die Möglichkeit bieten, das Mikrofon in der Einstellungen-App umzuschalten.
Wenn Automotive-Geräteimplementierungen android.hardware.camera.any
deklarieren, dann:
- [ 9.8.2 /A-2-1] MUSS die Kameraanzeige anzeigen, wenn eine App auf Live-Kameradaten zugreift, aber nicht, wenn auf die Kamera nur von Apps zugegriffen wird, die die in Abschnitt 9.1 Berechtigungen
definiertenRollen innehaben mit CDD-Kennung [C-4-X][C-3-X].
- [ 9.8.2 /A-2-3] MUSS dem Benutzer die Möglichkeit bieten, die Kamera in der Einstellungen-App umzuschalten.
- [ 9.8.2 /A-2-4] MÜSSEN aktuelle und aktive Apps mit Kamera anzeigen, wie sie von
PermissionManager.getIndicatorAppOpUsageData()
zurückgegeben werden, zusammen mit allen damit verbundenen Zuordnungsmeldungen.
Wenn Geräteimplementierungen über einen sicheren Sperrbildschirm verfügen und einen oder mehrere Trust Agents enthalten, die die TrustAgentService
-System-API implementieren, gilt Folgendes:
- [ 9.11.1 /A-1-1] MUSS den Benutzer häufiger als einmal alle 336 Stunden nach einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) fragen.
3. Software
3.1. Verwaltete API-Kompatibilität :
Siehe Überarbeitung
Geräteimplementierungen:
- [C-0-8] DARF NICHT die Installation von Anwendungen unterstützen, die auf eine API-Ebene unter 23 abzielen.
3.2.3.5. Bedingte Anwendungsabsichten :
Siehe Überarbeitung
Wenn Geräteimplementierungen
android.hardware.nfc.uicc
oderandroid.hardware.nfc.ese
melden, gilt Folgendes:- [C-19-1] MUSS die Intent-API NfcAdapter.ACTION_TRANSACTION_DETECTED implementieren (als „EVT_TRANSACTION“, definiert durch die technische Spezifikation TS.26 der GSM Association – NFC-Handset-Anforderungen) .
3.3.1. Binäre Anwendungsschnittstellen :
Siehe Überarbeitung
Geräteimplementierungen:
- [C-0-12] MÜSSEN Funktionssymbole für die Kernfunktionssymbole
von Vulkan 1.0 undVulkan 1.1 sowie die ErweiterungenVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
undVK_KHR_get_physical_device_properties2
über die Bibliotheklibvulkan.so
exportieren. Beachten Sie, dass zwar alle Symbole vorhanden sein MÜSSEN, Abschnitt 7.1.4.2 jedoch ausführlicher die Anforderungen beschreibt, wann die vollständige Implementierung der jeweiligen Funktionen erwartet wird.
- [C-0-12] MÜSSEN Funktionssymbole für die Kernfunktionssymbole
Siehe Überarbeitung
Wenn Geräteimplementierungen einen Bildschirm- oder Videoausgang umfassen, gilt Folgendes:
- [C-1-5] MÜSSEN dynamische Farbtonpaletten mit Farbthemenstilen generieren, die in der Dokumentation
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(sieheandroid.theme.customization.theme_styles
) aufgeführt sind, nämlichTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
undMONOCHROMATIC
.
- [C-1-5] MÜSSEN dynamische Farbtonpaletten mit Farbthemenstilen generieren, die in der Dokumentation
Siehe Überarbeitung
Wenn Geräteimplementierungen, einschließlich der Navigationstaste für die Funktion „Letzte“, wie in Abschnitt 7.2.3 beschrieben, die Schnittstelle ändern, geschieht Folgendes:
- [C-1-2] MUSS das Verhalten beim Anheften des Bildschirms implementieren und dem Benutzer ein Einstellungsmenü zum Umschalten der Funktion bereitstellen.
3.9.2 Unterstützung verwalteter Profile :
Siehe Überarbeitung
Wenn Geräteimplementierungen
android.software.managed_users
deklarieren, gilt Folgendes:- [C-1-10] MUSS sicherstellen, dass die Screenshot-Daten im Arbeitsprofilspeicher gespeichert werden, wenn ein Screenshot mit einem
topActivity
Fenster erfasst wird, das den Fokus hat (dasjenige, mit dem der Benutzer zuletzt unter allen Aktivitäten interagiert hat) und zu einem Arbeitsprofil gehört App . - [C-1-11] Beim Speichern eines Screenshots im Arbeitsprofil DÜRFEN KEINE anderen Bildschirminhalte (Systemleiste, Benachrichtigungen oder persönliche Profilinhalte) erfasst werden, mit Ausnahme des /der Arbeitsprofil-Anwendungsfenster(s ), um sicherzustellen, dass persönliche Profildaten vorhanden sind nicht im Arbeitsprofil gespeichert).
- [C-1-10] MUSS sicherstellen, dass die Screenshot-Daten im Arbeitsprofilspeicher gespeichert werden, wenn ein Screenshot mit einem
3.9.5 Device Policy Resolution Framework : Neuer Abschnitt
Siehe Überarbeitung
Wenn Geräteimplementierungen
android.software.device_admin
oderandroid.software.managed_users
melden, dann:- [C-1-1] MUSS Geräterichtlinienkonflikte lösen, wie in der AOSP-Dokumentation dokumentiert.
5. Multimedia-Kompatibilität
Siehe Überarbeitung
Geräteimplementierungen MÜSSEN die Kodierung der folgenden Bildkodierung unterstützen:
- [C-0-4] AVIF
- Geräte müssen
BITRATE_MODE_CQ
und Baseline Profile unterstützen.
- Geräte müssen
- [C-0-4] AVIF
Siehe Überarbeitung
Geräteimplementierungen MÜSSEN die Dekodierung der folgenden Bildkodierung unterstützen:
[C-0-7] AVIF (Basisprofil)
5.1.6. Details zu den Bildcodecs :
Siehe Überarbeitung
Format/Codec Einzelheiten Unterstützte Dateitypen/Containerformate JPEG Basis+progressiv JPEG (.jpg) GIF GIF (.gif) PNG PNG (.png) BMP BMP (.bmp) WebP WebP (.webp) Roh 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 (Basisprofil) Bild, Bildsammlung, Bildsequenz Basislinienprofil HEIF-Container (.avif) 5.1.8. Liste der Video-Codecs :
Siehe Überarbeitung
Format/Codec Einzelheiten Zu unterstützende Dateitypen/Containerformate H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, nur dekodieren)
H.264 AVC Weitere Informationen finden Sie in den Abschnitten 5.2 und 5.3 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS (.ts, nicht durchsuchbar)
- Matroska (.mkv, nur dekodieren)
H.265 HEVC Weitere Informationen finden Sie in Abschnitt 5.3 - MPEG-4 (.mp4)
- Matroska (.mkv, nur dekodieren)
MPEG-2 Hauptprofil - MPEG2-TS (.ts, nicht durchsuchbar)
- MPEG-4 (.mp4, nur dekodieren)
- Matroska (.mkv, nur dekodieren)
MPEG-4 SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, nur dekodieren)
VP8 Weitere Informationen finden Sie in den Abschnitten 5.2 und 5.3 - WebM (.webm)
- Matroska (.mkv)
VP9 Weitere Informationen finden Sie in Abschnitt 5.3 - WebM (.webm)
- Matroska (.mkv)
AV1 Einzelheiten finden Sie in Abschnitt 5.2 und Abschnitt 5.3 - MPEG-4 (.mp4)
- Matroska (.mkv, nur dekodieren)
5.1.10. Charakterisierung des Mediencodecs :
Siehe Überarbeitung
Wenn Geräteimplementierungen Videocodecs unterstützen:
- [C-2-1] Alle Video-Codecs MÜSSEN erreichbare Bildratendaten für die folgenden Größen veröffentlichen, sofern sie vom Codec unterstützt werden:
SD (geringe Qualität) SD (hohe Qualität) HD 720p HD 1080p UHD Video Auflö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 (andere)
- 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 ) Siehe Überarbeitung
Wenn Geräteimplementierungen einen beliebigen Video-Encoder unterstützen und ihn für Apps von Drittanbietern verfügbar machen, gilt Folgendes:- SOLLTE über zwei Schiebefenster NICHT mehr als 15 % über der Bitrate zwischen Intraframe-Intervallen (I-Frame) liegen.
- SOLLTE innerhalb eines Schiebefensters von 1 Sekunde NICHT mehr als 100 % über der Bitrate liegen.
Wenn Geräteimplementierungen einen beliebigen Video-Encoder unterstützen und ihn für Apps von Drittanbietern verfügbar machen, legen Sie fest
MediaFormat.KEY_BITRATE_MODE
aufBITRATE_MODE_VBR
, sodass der Encoder im Modus mit variabler Bitrate arbeitet. Solange dies keinen Einfluss auf die Mindestqualitätsuntergrenze hat, ist die codierte Bitrate:-
[C-5-1] DARFinnerhalb eines Schiebefensters NICHT mehr als 15 % über der Bitrate zwischen Intraframe-Intervallen (I-Frame) liegen. -
[C-5-2] DARFinnerhalb eines Schiebefensters von 1 Sekunde NICHT mehr als 100 % über der Bitrate liegen.
Wenn Geräteimplementierungen einen beliebigen Videoencoder unterstützen und ihn für Apps von Drittanbietern verfügbar machen und
MediaFormat.KEY_BITRATE_MODE
aufBITRATE_MODE_CBR
setzen, damit der Encoder im Modus mit konstanter Bitrate arbeitet, dann ist die codierte Bitrate:-
[C-6-1] DARF[C-SR-2] DRINGEND EMPFOHLEN werden, dass die Bitrate in einem gleitenden Fenster von 1 Sekunde NICHT mehr als 15 % über der Zielbitrate liegt.
Siehe Überarbeitung
Wenn Geräteimplementierungen H.263-Encoder unterstützen und diese für Apps von Drittanbietern verfügbar machen, gilt Folgendes:
- [C-1-1] MUSS die QCIF-Auflösung (176 x 144) mit Baseline Profile Level 45 unterstützen. Die SQCIF-Auflösung ist optional.
-
SOLLTE dynamisch konfigurierbare Bitraten für den unterstützten Encoder unterstützen.
Siehe Überarbeitung
Wenn Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:
- [C-1-1] MUSS Main Profile Level 3 mit einer Auflösung von bis zu 512 x 512 unterstützen.
-
SOLLTE die HD-Kodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben. - [C-SR-1] wird DRINGEND EMPFOHLEN, das 720 x 480 SD-Profil und die HD-Kodierungsprofile zu unterstützen, wie in der folgenden Tabelle angegeben, wenn ein Hardware-Encoder vorhanden ist.
5.2.6. AV1 : neuer Abschnitt
Siehe Überarbeitung
Wenn Geräteimplementierungen den AV1-Codec unterstützen, gilt Folgendes:
- [C-1-1] MUSS das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalten unterstützen.
[C-1-2] MÜSSEN Leistungsdaten veröffentlichen, dh Leistungsdaten über die APIs
getSupportedFrameRatesFor()
odergetSupportedPerformancePoints()
für unterstützte Auflösungen in der folgenden Tabelle melden.[C-1-3] MUSS HDR-Metadaten akzeptieren und an den Bitstream ausgeben
Wenn der AV1-Encoder hardwarebeschleunigt ist, dann:
- [C-2-1] MUSS bis einschließlich HD1080p-Codierungsprofil aus der folgenden Tabelle unterstützen:
SD HD 720p HD 1080p UHD Video Auflösung 720 x 480 Pixel 1280 x 720 Pixel 1920 x 1080 Pixel 3840 x 2160 Pixel Video-Bildrate 30 fps 30 fps 30 fps 30 fps Video-Bitrate 5 Mbit/s 8 Mbit/s 16 Mbit/s 50 Mbit/s Siehe Überarbeitung
Wenn Geräteimplementierungen H.263-Decoder unterstützen, gilt Folgendes:
- [C-1-1] MUSS Baseline Profile Level 30 (CIF-, QCIF- und SQCIF-Auflösungen bei 30 fps 384 kbps) und Level 45 (QCIF- und SQCIF-Auflösungen bei 30 fps 128 kbps) unterstützen.
Siehe Überarbeitung
Wenn Geräteimplementierungen den AV1-Codec unterstützen, gilt Folgendes:- [C-1-1] MUSS Profil 0 einschließlich 10-Bit-Inhalt unterstützen.
Wenn Geräteimplementierungen den AV1-Codec unterstützen und ihn für Anwendungen von Drittanbietern verfügbar machen, gilt Folgendes:
- [C-1-1] MUSS das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalten unterstützen.
Wenn Geräteimplementierungen den AV1-Codec mit einem hardwarebeschleunigten Decoder unterstützen, dann gilt Folgendes:
- [C-2-1] MUSS in der Lage sein, mindestens HD 720p-Videodekodierungsprofile aus der folgenden Tabelle zu dekodieren, wenn die von
Display.getSupportedModes()
Methode gemeldete Höhe gleich oder größer als 720p ist. - [C-2-2] MUSS in der Lage sein, mindestens HD 1080p-Videodekodierungsprofile aus der Tabelle unten zu dekodieren, wenn die von der Methode
Display.getSupportedModes()
gemeldete Höhe gleich oder größer als 1080p ist.
SD HD 720p HD 1080p UHD Video Auflösung 720 x 480 Pixel 1280 x 720 Pixel 1920 x 1080 Pixel 3840 x 2160 Pixel Video-Bildrate 30 fps 30 fps 30 fps 30 fps Video-Bitrate 5 Mbit/s 8 Mbit/s 16 Mbit/s 50 Mbit/s Wenn Geräteimplementierungen HDR Profile über die Medien-APIs unterstützen, dann:
- [C-3-1] MUSS das Extrahieren und Ausgeben von HDR-Metadaten aus dem Bitstream und/oder Container unterstützen.
- [C-3-2] HDR-Inhalte MÜSSEN ordnungsgemäß auf dem Gerätebildschirm oder an einem Standard-Videoausgangsanschluss (z. B. HDMI) angezeigt werden.
5.4.2. Aufnahme zur Spracherkennung :
Siehe Überarbeitung
Wenn Geräteimplementierungen
android.hardware.microphone
deklarieren, gilt Folgendes:- Die Audioeingangsempfindlichkeit sollte so eingestellt werden, dass eine sinusförmige 1000-Hz-Tonquelle mit einem Schalldruckpegel (SPL) von 90 dB (gemessen
in einem Abstand von 30 cm nebendem Mikrofon) eine ideale Reaktion von RMS 2500 innerhalb eines Bereichs von 1770 und ergibt 3530 für 16-Bit-Samples (oder -22,35 dB ±3 dB Full Scale für Gleitkomma-/Double-Precision-Samples) für jedes einzelne Mikrofon, das zur Aufzeichnung der Spracherkennungs-Audioquelle verwendet wird.
- Die Audioeingangsempfindlichkeit sollte so eingestellt werden, dass eine sinusförmige 1000-Hz-Tonquelle mit einem Schalldruckpegel (SPL) von 90 dB (gemessen
Siehe Überarbeitung
Wenn Geräteimplementierungen die Funktion
android.hardware.audio.output
deklarieren, gilt Folgendes:- [C-1-4] MUSS Audioeffekte mit Gleitkomma-Eingabe und -Ausgabe unterstützen.
- [C-1-5] MUSS sicherstellen, dass Audioeffekte mehrere Kanäle bis zur Mixer-Kanalanzahl, auch bekannt als FCC_LIMIT, unterstützen.
Siehe Überarbeitung
Wenn Geräteimplementierungen
android.hardware.audio.output
deklarieren, wird ihnen 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] Es wird DRINGEND EMPFOHLEN, dass die berechneten Roundtrip-Latenzen auf der Grundlage der von
AAudioStream_getTimestamp
zurückgegebenen Eingabe- und Ausgabezeitstempel innerhalb von 30 ms der gemessenen Roundtrip-Latenz fürAAUDIO_PERFORMANCE_MODE_NONE
undAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
für Lautsprecher, kabelgebundene und kabellose Headsets liegen.
- [C-SR-4] Der von AudioTrack.getTimestamp und
7. Hardwarekompatibilität
Siehe Überarbeitung
Android verfügt über Funktionen, die Anwendungsressourcen und UI-Layouts automatisch entsprechend dem Gerät anpassen, um sicherzustellen, dass Anwendungen von Drittanbietern auf einer
Vielzahl von Hardwarekonfigurationen gut laufen.Vielzahl von Hardware-Anzeigen und -Konfigurationen. Ein Android-kompatibles Display ist ein Anzeigebildschirm, der alle Verhaltensweisen und APIs implementiert, die in Android-Entwicklern – Übersicht über die Bildschirmkompatibilität , diesem Abschnitt (7.1) und seinen Unterabschnitten beschrieben werden, sowie alle zusätzlichen gerätetypspezifischen Verhaltensweisen, die in Abschnitt 2 von dokumentiert sind diese CDD.Auf den Android-kompatiblen Displays, auf denen alle Android-kompatiblen Anwendungen von Drittanbietern ausgeführt werden können, MÜSSEN Geräteimplementierungen diese APIs und Verhaltensweisen ordnungsgemäß implementieren, wie in diesem Abschnitt beschrieben.Starten Sie neue Anforderungen
Geräteimplementierungen:
- [C-0-1] DÜRFEN Anwendungen von Drittanbietern standardmäßig nur auf Android-kompatiblen Displays rendern.
Die Einheiten, auf die sich die Anforderungen in diesem Abschnitt beziehen, sind wie folgt definiert:
- physikalische Diagonalgröße . Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Teils des Displays.
- Dichte
von Punkten pro Zoll (dpi). Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1 Zoll umfasst werden , ausgedrückt in Pixel pro Zoll (ppi oder dpi) . Wenndpippi- und dpi- Werte aufgeführt sind, müssen sowohl die horizontale als auch die vertikale dpi innerhalb des aufgeführten Bereichs liegen. - Seitenverhältnis . Das Verhältnis der Pixel der längeren Dimension zur kürzeren Dimension des Bildschirms. Beispielsweise wäre eine Anzeige mit 480 x 854 Pixeln 854/480 = 1,779, also ungefähr „16:9“.
- dichteunabhängiges Pixel (dp) .
Einevirtuelle Pixeleinheit normalisiert sich auf einen160-dpi-Bildschirm miteiner Bildschirmdichte von 160. Für eine bestimmte Dichte d und eine Anzahl von Pixeln p, die Anzahl der dichteunabhängigen Pixel dp, wird wie folgt berechnet:Pixel = dps * (Dichte/160)dp = (160 / d) * p .
7.1.1.1. Bildschirmgröße und -form :
Siehe Überarbeitung
Wenn Geräteimplementierungen Bildschirme unterstützen, die die Größenkonfiguration
UI_MODE_TYPE_NORMAL
unterstützen undAndroid-kompatibel sind,verwenden Sie zum Rendern dieser Bildschirme physische Displays mit abgerundeten Ecken:- [C-1-1] MUSS sicherstellen, dass für jede dieser Anzeigen mindestens eine der folgenden Anforderungen erfüllt ist:
- Der Radius der abgerundeten Ecken beträgt höchstens 38 dp.
Wenn an jeder Ecke der logischen Anzeige ein 15 dp x 15 dp großes Feld verankert ist, ist mindestens ein Pixel jedes Felds auf dem Bildschirm sichtbar.
SOLLTE dem Benutzer die Möglichkeit bieten, in den Anzeigemodus mit den rechteckigen Ecken zu wechseln.
Starten Sie neue Anforderungen
Wenn Geräteimplementierungen nur die
NO_KEYS
Tastaturkonfiguration unterstützen und beabsichtigen, Unterstützung für die UI-ModuskonfigurationUI_MODE_TYPE_NORMAL
zu melden, gehen sie wie folgt vor:- [C-4-1] MUSS eine Layoutgröße (ohne Displayausschnitte) von mindestens 596 dp x 384 dp oder mehr haben.
Wenn Geräteimplementierungen ein oder mehrere Android-kompatible Displays umfassen, die faltbar sind, oder über ein Klappscharnier zwischen mehreren Displaypanels verfügen und diese Displays für die Darstellung von Drittanbieter-Apps verfügbar machen, gilt Folgendes:
- [C-2-1] MUSS die neueste verfügbare stabile Version der Erweiterungs-API oder die stabile Version der Sidecar-API implementieren, die von der Window Manager Jetpack- Bibliothek verwendet werden soll.
Wenn Geräteimplementierungen ein oder mehrere Android-kompatible Displays umfassen, die faltbar sind, oder ein Klappscharnier zwischen mehreren Anzeigefeldern umfassen und wenn das Scharnier oder die Falte ein Vollbild-Anwendungsfenster kreuzt, gilt Folgendes:
- [C-3-1] MUSS die Position, Grenzen und den Zustand des Scharniers oder der Falte über Erweiterungen oder Sidecar-APIs an die Anwendung melden.
Wenn Geräteimplementierungen einen oder mehrere Android-kompatible Anzeigebereiche umfassen, die faltbar sind, oder ein Klappscharnier zwischen mehreren Android-kompatiblen Anzeigebereichsbereichen umfassen und diese Anzeigebereiche für Anwendungen verfügbar machen, gilt Folgendes:
- [C-4-1] MUSS die richtige Version der API-Ebene der Window Manager-Erweiterungen implementieren, wie in der kommenden Dokumentation beschrieben.
7.1.1.2. Bildschirmseitenverhältnis : entfernt
Siehe Überarbeitung
Geräteimplementierungen:
- [C-0-1]
Standardmäßig MÜSSEN Geräteimplementierungennureine der Android-Framework-Dichten melden, die aufDisplayMetrics
über dieDENSITY_DEVICE_STABLE
-API aufgeführt sind, und dieser Wert muss ein statischer Wert für jede physische Anzeige sein.DARF sich zu keinem Zeitpunkt ändern; Allerdingsmeldet das Gerät möglicherweise eine anderewillkürliche DichteDisplayMetrics.density
entsprechend den vom Benutzer vorgenommenen Änderungen der Anzeigekonfiguration (z. B. Anzeigegröße), die nach dem ersten Start festgelegt wurden.
- Geräteimplementierungen SOLLTEN die standardmäßige Android-Framework-Dichte definieren, die numerisch der physischen Dichte des Bildschirms am nächsten kommt, es sei denn, diese logische Dichte drückt die gemeldete Bildschirmgröße unter das unterstützte Minimum. Wenn die Standard-Android-Framework-Dichte, die der physischen Dichte numerisch am nächsten kommt, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 dp Breite) ist, SOLLTEN Geräteimplementierungen die nächstniedrigere Standard-Android-Framework-Dichte melden.
Starten Sie neue Anforderungen
- SOLLTE die standardmäßige Android-Framework-Dichte definieren, die numerisch der physischen Dichte des Bildschirms am nächsten kommt, oder einen Wert, der den gleichen äquivalenten Winkelmessungen des Sichtfelds eines Handheld-Geräts entspricht.
Wenn Geräteimplementierungen eine Möglichkeit bieten
,die Anzeigegröße des Geräts zu ändern , gehen sie wie folgt vor:- [C-1-1]
Die Anzeigegröße DARF NICHT skaliert werden.Die Anzeige darf NICHT größer als das 1,5-fache der nativenDENSITY_DEVICE_STABLE
Dichteskaliert werden oder eine effektive minimale Bildschirmdimension kleiner als 320 dp erzeugen (entspricht dem Ressourcenqualifikator sw320dp), je nachdem, was zuerst eintritt. - [C-1-2]
Die Anzeigegröße DARF NICHT skaliert werden.Die Anzeige darf NICHT kleiner als das 0,85-fache dernativen DichtevonDENSITY_DEVICE_STABLE
skaliert werden.
- [C-0-1]
Siehe Überarbeitung
Wenn Geräteimplementierungen Unterstützung für Vulkan
1.0 oder höherbeinhalten, gilt Folgendes:[C-1-3] MUSS die
Vulkan 1.0Vulkan 1.1- APIs für jedes aufgelisteteVkPhysicalDevice
vollständig implementieren.[C-1-5] DARF KEINE Ebenen aufzählen, die von Bibliotheken außerhalb des Anwendungspakets bereitgestellt werden, oder andere Möglichkeiten zum Verfolgen oder Abfangen der Vulkan-API bereitstellen, es sei denn, für die Anwendung ist das Attribut
android:debuggable
auf „true
oder die Metadatencom.android.graphics.injectLayers.enable
festgelegtcom.android.graphics.injectLayers.enable
auftrue
gesetzt .
- SOLLTE
VkPhysicalDeviceProtectedMemoryFeatures
undVK_EXT_global_priority
unterstützen.
- [C-1-13] MUSS die im Android Baseline 2021-Profil festgelegten Anforderungen erfüllen.
[C-SR-5] Es wird DRINGEND EMPFOHLEN,
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
undVK_EXT_global_priority
zu unterstützen.[C-SR-6] Es wird dringend empfohlen,
SkiaVk
mit HWUI zu verwenden.
Wenn Geräteimplementierungen Unterstützung für Vulkan 1.1 beinhalten und eines der hier beschriebenen Vulkan-Feature-Flags deklarieren, gilt Folgendes:
- [C-SR-7] Es wird DRINGEND EMPFOHLEN, die Erweiterung
VK_KHR_external_fence_fd
für Drittanwendungen verfügbar zu machen und der Anwendung den Export von Fence-Nutzdaten in POSIX-Dateideskriptoren und den Import von Fence-Nutzdaten aus POSIX-Dateideskriptoren zu ermöglichen, wie hier beschrieben.
7.3.10. Biometrische Sensoren :
Siehe Überarbeitung
Wenn Geräteimplementierungen über mehrere biometrische Sensoren verfügen, gilt Folgendes:
[C-7-1] MUSS, wenn eine Biometrik gesperrt ist (d. h. die Biometrik ist deaktiviert, bis der Benutzer sie mit primärer Authentifizierung entsperrt) oder zeitgebunden gesperrt ist (d. h. die Biometrik ist vorübergehend deaktiviert, bis der Benutzer eine Zeitspanne abwartet). aufgrund zu vieler Fehlversuche auch alle anderen biometrischen Daten einer niedrigeren biometrischen Klasse sperren. Im Falle einer zeitgebundenen Sperrung MUSS die Backoff-Zeit für die biometrische Überprüfung der maximalen Backoff-Zeit aller biometrischen Daten bei zeitgebundener Sperrung entsprechen.
[C-SR-12] Werden DRINGEND EMPFOHLEN, wenn eine Biometrik gesperrt ist (d. h. die Biometrik ist deaktiviert, bis der Benutzer sie mit primärer Authentifizierung entsperrt) oder zeitgebunden gesperrt ist (d. h. die Biometrik ist vorübergehend deaktiviert, bis der Benutzer eine Zeit lang wartet). (Intervall) aufgrund zu vieler Fehlversuche, um auch alle anderen biometrischen Daten derselben biometrischen Klasse zu sperren. Im Falle einer zeitgebundenen Sperrung wird DRINGEND EMPFOHLEN, dass die Backoff-Zeit für die biometrische Verifizierung die maximale Backoff-Zeit aller biometrischen Daten bei zeitgebundener Sperrung ist.
[C-7-2] MUSS den Benutzer zur Eingabe der empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) auffordern, um den Sperrzähler für eine gesperrte biometrische Kennzahl zurückzusetzen. Biometriedaten der Klasse 3 KÖNNEN zugelassen werden, um den Sperrzähler für eine gesperrte Biometriedaten derselben oder einer niedrigeren Klasse zurückzusetzen. Es darf NICHT zugelassen werden, dass biometrische Daten der Klasse 2 oder 1 einen Reset-Sperrvorgang für biometrische Daten durchführen.
Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 1 (früher Komfort ) behandeln möchten, gehen sie wie folgt vor:
[C-1-12] Die Spoof- und Imposter-Akzeptanzrate darf nicht höher als 40 % pro PAI-Art (Presentation Attack Instrument) sein, gemessen anhand der Android Biometrics Test Protocols .
[C-SR-13] Es wird DRINGEND EMPFOHLEN, dass die Spoof- und Imposter-Akzeptanzrate nicht höher als 30 % pro PAI-Art (Presentation Attack Instrument) ist, gemessen anhand der Android Biometrics Test Protocols .
[C-SR-14] Es wird DRINGEND EMPFOHLEN, die biometrische Klasse des biometrischen Sensors und die entsprechenden Risiken seiner Aktivierung offenzulegen.
[C-SR-17] Werden DRINGEND EMPFOHLEN, die neuen AIDL-Schnittstellen (z. B.
IFace.aidl
undIFingerprint.aidl
) zu implementieren.
Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 2 (früher Schwach ) behandeln möchten, gehen sie wie folgt vor:
- [C-SR-15] Es wird DRINGEND EMPFOHLEN, dass die Spoof- und Imposter-Akzeptanzrate nicht höher als 20 % pro PAI-Art (Presentation Attack Instrument) ist, gemessen anhand der Android Biometrics Test Protocols .
- [C-2-3] MUSS den biometrischen Abgleich in einer isolierten Ausführungsumgebung außerhalb des Android-Benutzer- oder Kernel-Bereichs durchführen, wie etwa der Trusted Execution Environment (TEE),
oderauf einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder auf Protected Virtuelle Maschine, die die Anforderungen in Abschnitt 9.17 erfüllt . - [C-2-4] Alle identifizierbaren Daten MÜSSEN verschlüsselt und kryptografisch authentifiziert sein, sodass sie nicht außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal zur isolierten Ausführungsumgebung erfasst, gelesen oder verändert werden können, wie in den Implementierungsrichtlinien dokumentiert auf der Website des Android Open Source Project oder einer geschützten virtuellen Maschine, die von einem Hypervisor gesteuert wird und die Anforderungen in Abschnitt 9.17 erfüllt .
- [C-2-5] Für kamerabasierte Biometrie, während eine biometrische Authentifizierung oder Registrierung stattfindet:
- MUSS die Kamera in einem Modus betreiben, der verhindert, dass Kamerabilder außerhalb der isolierten Ausführungsumgebung oder eines Chips mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder einer geschützten virtuellen Maschine, die vom Hypervisor gesteuert wird und die Anforderungen in Abschnitt 9.17 erfüllt, gelesen oder geändert werden.
- Bei RGB-Einzelkameralösungen KÖNNEN die Kamerabilder außerhalb der isolierten Ausführungsumgebung lesbar sein, um Vorgänge wie die Vorschau zur Registrierung zu unterstützen, DÜRFEN aber dennoch NICHT änderbar sein.
- [C-2-7] DARF KEINEN 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 geschützten virtuellen Maschine erlauben, die von einem Hypervisor gesteuert wird, der die Anforderungen in Abschnitt erfüllt 9.17 . Das Aktualisieren von Geräten, die mit Android Version 9 oder früher gestartet wurden, ist nicht von C-2-7 ausgenommen.
Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 3 (früher Strong ) behandeln möchten, gehen sie wie folgt vor:
- [C-SR-16] Es wird DRINGEND EMPFOHLEN, dass die Spoof- und Imposter-Akzeptanzrate nicht höher als 7 % pro PAI-Art (Presentation Attack Instrument) ist , gemessen anhand der Android Biometrics Test Protocols .
7.3.13. IEEE 802.1.15.4 (UWB) :
Siehe Überarbeitung
Wenn Geräteimplementierungen Unterstützung für 802.1.15.4 umfassen und die Funktionalität einer Drittanbieteranwendung zugänglich machen, gilt Folgendes:
- [C-1-2] MUSS das Hardware-Feature-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 UnicastSTATIC STS DS-TWR
-Ranging, verzögerter Modus, Ranging-Intervall 240 ms. -
CONFIG_ID_2
: FiRa-definierte Eins-zu-VieleSTATIC STS DS-TWR
-Ranging, verzögerter Modus, Ranging-Intervall 200 ms. Typischer Anwendungsfall: Smartphone interagiert mit vielen Smart-Geräten. -
CONFIG_ID_3
: Identisch mitCONFIG_ID_1
, außer dass Daten zum Einfallswinkel (AoA) nicht gemeldet werden. -
CONFIG_ID_4
: Identisch mitCONFIG_ID_1
, außer dass der P-STS-Sicherheitsmodus aktiviert ist. -
CONFIG_ID_5
: WieCONFIG_ID_2
, außer dass der P-STS-Sicherheitsmodus aktiviert ist. -
CONFIG_ID_6
: WieCONFIG_ID_3
, außer dass der P-STS-Sicherheitsmodus aktiviert ist. -
CONFIG_ID_7
: WieCONFIG_ID_2
, außer dass der P-STS-Einzelkontrollschlüsselmodus aktiviert ist.
-
- [C-1-4] MUSS eine Möglichkeit für den Benutzer bieten, den UWB-Funk ein-/auszuschalten.
- [C-1-5] MUSS erzwingen, dass Apps, die UWB-Radio verwenden, die
UWB_RANGING
Berechtigung besitzen (unter derNEARBY_DEVICES
Berechtigungsgruppe).
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.
- [C-1-2] MUSS das Hardware-Feature-Flag
Siehe Überarbeitung
„Telefonie“, wie sie von den Android-APIs und diesem Dokument verwendet wird, bezieht sich speziell auf Hardware im Zusammenhang mit dem Tätigen von Sprachanrufen und dem Senden von SMS-Nachrichten oder dem Einrichten mobiler Daten über ein mobiles GSM- oder CDMA-Netzwerk (z. B. GSM, CDMA, LTE, NR). Ein Gerät, das „Telefonie“ unterstützt, kann je nach Produkt einige oder alle Anruf-, Nachrichten- und Datendienste anbieten.
über ein GSM- oder CDMA-Netz. Auch wenn diese Sprachanrufe paketvermittelt sein können oder nicht, gelten sie für die Zwecke von Android als unabhängig von Datenkonnektivität, die über dasselbe Netzwerk implementiert werden kann. Mit anderen Worten: Die „Telefonie“-Funktionalität und APIs von Android beziehen sich speziell auf Sprachanrufe und SMS. Beispielsweise gelten Geräteimplementierungen, die keine Anrufe tätigen oder SMS-Nachrichten senden/empfangen können, nicht als Telefoniegerät, unabhängig davon, ob sie ein Mobilfunknetz für die Datenverbindung verwenden.Siehe Überarbeitung
Wenn Geräteimplementierungen Unterstützung für 802.11 umfassen und die Funktionalität einer Drittanbieteranwendung zugänglich machen, gilt Folgendes:
- [C-1-4] MUSS Multicast-DNS (mDNS) unterstützen und darf zu keinem Zeitpunkt des Betriebs mDNS-Pakete (224.0.0.251 oder ff02::fb ) filtern, auch wenn sich der Bildschirm nicht in einem aktiven Zustand befindet, es sei denn, sie werden gelöscht oder Das Filtern dieser Pakete ist erforderlich, um innerhalb der Stromverbrauchsbereiche zu bleiben, die durch die für den Zielmarkt geltenden gesetzlichen Anforderungen erforderlich sind.
Für Implementierungen von Android-Fernsehgeräten, auch im Standby-Modus.
- [C-1-4] MUSS Multicast-DNS (mDNS) unterstützen und darf zu keinem Zeitpunkt des Betriebs mDNS-Pakete (224.0.0.251 oder ff02::fb ) filtern, auch wenn sich der Bildschirm nicht in einem aktiven Zustand befindet, es sei denn, sie werden gelöscht oder Das Filtern dieser Pakete ist erforderlich, um innerhalb der Stromverbrauchsbereiche zu bleiben, die durch die für den Zielmarkt geltenden gesetzlichen Anforderungen erforderlich sind.
Siehe Überarbeitung
Wenn Geräteimplementierungen FEATURE_BLUETOOTH_LE deklarieren, gilt Folgendes:
- [C-SR-2] Es wird DRINGEND EMPFOHLEN, den Rx-Offset zu messen und zu kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -60 dBm +/-10 dB in 1 m Entfernung von einem Referenzgerät beträgt, das bei
ADVERTISE_TX_POWER_HIGH
sendet, wobei die Geräte so ausgerichtet sind, dass sie es sind auf „parallelen Ebenen“ mit Bildschirmen, die in die gleiche Richtung zeigen. - [C-SR-3] Werden DRINGEND EMPFOHLEN, den Tx-Offset zu messen und zu kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -60 dBm +/-10 dB beträgt, wenn von einem Referenzgerät gescannt wird, das sich in 1 m Entfernung befindet und bei
ADVERTISE_TX_POWER_HIGH
sendet, wo die Geräte ausgerichtet sind so dass sie sich auf „parallelen Ebenen“ befinden und die Bildschirme in die gleiche Richtung zeigen.
- [C-10-3] MUSS den Rx-Offset messen und kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -55 dBm +/-10 dB in 1 m Entfernung von einem Referenzgerät beträgt, das mit
ADVERTISE_TX_POWER_HIGH
sendet. - [C-10-4] MUSS den Tx-Offset messen und kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -55 dBm +/-10 dB beträgt, wenn von einem Referenzgerät gescannt wird, das sich in 1 m Entfernung befindet und mit
ADVERTISE_TX_POWER_HIGH
sendet.
Wenn Geräteimplementierungen Bluetooth Version 5.0 unterstützen, dann:
- [C-SR-4] Werden DRINGEND EMPFOHLEN, um Folgendes zu unterstützen:
- LE 2M PHY
- LE-Codec PHY
- LE-Werbeerweiterung
- Regelmäßige Werbung
- Mindestens 10 Werbesets
- Mindestens 8 LE gleichzeitige Verbindungen. Jede Verbindung kann eine der beiden Verbindungstopologierollen haben.
- LE-Link-Layer-Datenschutz
- Eine „Auflösungsliste“ mit einer Größe von mindestens 8 Einträgen
- [C-SR-2] Es wird DRINGEND EMPFOHLEN, den Rx-Offset zu messen und zu kompensieren, um sicherzustellen, dass der mittlere BLE-RSSI -60 dBm +/-10 dB in 1 m Entfernung von einem Referenzgerät beträgt, das bei
Siehe Überarbeitung
- [C-1-7] MUSS sicherstellen, dass der Median der Entfernungsmessungen in 1 m Entfernung vom Referenzgerät innerhalb von [0,75 m, 1,25 m] liegt, wobei die Ground-Truth-Entfernung von der Oberkante des Prüflings gemessen wird.
mit der Vorderseite nach oben gehalten und um 45 Grad geneigt.
- [C-1-7] MUSS sicherstellen, dass der Median der Entfernungsmessungen in 1 m Entfernung vom Referenzgerät innerhalb von [0,75 m, 1,25 m] liegt, wobei die Ground-Truth-Entfernung von der Oberkante des Prüflings gemessen wird.
7.5.1. Nach hinten gerichtete Kamera :
Siehe Überarbeitung
Eine nach hinten gerichtete Kamera ist eine Kamera, die sich auf der dem Display gegenüberliegenden Seite des Geräts befindet; Das heißt, es nimmt Szenen auf der anderen Seite des Geräts auf, wie bei einer herkömmlichen Kamera.
Eine nach hinten gerichtete Kamera ist eine nach außen gerichtete Kamera, die wie eine herkömmliche Kamera Szenen auf der anderen Seite des Geräts aufnimmt. Bei Handheld-Geräten handelt es sich um eine Kamera, die sich auf der dem Display gegenüberliegenden Seite des Geräts befindet.
Siehe Überarbeitung
Eine nach vorne gerichtete Kamera ist eine Kamera, die sich auf derselben Seite des Geräts befindet wie das Display. Dabei handelt es sich um eine Kamera, die typischerweise zur Bildaufnahme des Benutzers verwendet wird, beispielsweise für Videokonferenzen und ähnliche Anwendungen.
Eine nach vorne gerichtete Kamera ist eine dem Benutzer zugewandte Kamera, die normalerweise zur Bildaufnahme des Benutzers verwendet wird, beispielsweise für Videokonferenzen und ähnliche Anwendungen. Bei Handheld-Geräten handelt es sich um eine Kamera, die sich auf derselben Seite des Geräts befindet wie das Display.
Siehe Überarbeitung
Eine externe Kamera ist eine Kamera, die jederzeit physikalisch von der Geräteimplementierung angehängt oder abgelöst werden kann. wie USB -Kameras.
7.5.4. Kamera -API -Verhalten :
Siehe Revision
Geräteimplementierungen müssen das folgende Verhalten für die Kamera-APIs für alle verfügbaren Kameras implementieren. Geräteimplementierungen:
- [C-SR-1] Für Geräte mit mehreren RGB-Kameras in unmittelbarer Nähe und in der gleichen Richtung wird dringend empfohlen, ein logisches Kamera-Gerät zu unterstützen, das die
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
auflistet. Als physische Unterverfassungen.
- [C-SR-1] Für Geräte mit mehreren RGB-Kameras in unmittelbarer Nähe und in der gleichen Richtung wird dringend empfohlen, ein logisches Kamera-Gerät zu unterstützen, das die
Siehe Revision
Geräte, die alle folgenden Kriterien erfüllen, sind von der obigen Anforderung ausgenommen:
- Geräteimplementierungen, die nicht vom Benutzer gedreht werden können, z. B. Automobilgeräte.
Siehe Revision
Geräte, die als Handheld oder abgenutzt sind, können einen allgemeinen haptischen Aktuator für den haptischen Aktuator umfassen, der Anwendungen für Zwecke zur Verfügung steht, einschließlich Klingeltöne, Alarme, Benachrichtigungen sowie allgemeines Berührungsfeedback.
Wenn Geräteimplementierungen keinen solchen allgemeinen haptischen Aktuator enthalten, sind sie:
- [7.10/c] muss für
Vibrator.hasVibrator()
.
Wenn Geräteimplementierungen mindestens einen solchen allgemeinen haptischen Aktuator enthalten, sind sie:
- [C-1-1] muss für
Vibrator.hasVibrator()
true zurückkehren. - Sollte keine exzentrische rotierende Masse (ERM) Haptic Actuator (Vibrator) verwenden.
- Sollte alle öffentlichen Konstanten für klare Haptik in
android.view.HapticFeedbackConstants
implementieren (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
GESTURE_END
VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
undGESTURE_START
). - SHOULD implement all public constants for clear haptics in
android.os.VibrationEffect
namely (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
andEFFECT_DOUBLE_CLICK
) and all feasible publicPRIMITIVE_*
constants for rich haptics inandroid.os.VibrationEffect.Composition
namely (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Einige dieser Grundelemente, wie z. B.LOW_TICK
undSPIN
sind möglicherweise nur möglich, wenn der Vibrator relativ niedrige Frequenzen unterstützen kann. - Sollte den Anleitungen zur Kartierung öffentlicher Konstanten in
android.view.HapticFeedbackConstants
auf die empfohlenenandroid.os.VibrationEffect
-Konstanten mit den entsprechenden Amplitudenbeziehungen folgen. - Sollten diese verknüpften haptischen Konstanten Mappings verwenden.
- Sollte eine qualitativ hochwertige Bewertung für
createOneShot()
undcreateWaveform()
APIs folgen. - Sollte überprüfen, ob das Ergebnis der öffentlichen
android.os.Vibrator.hasAmplitudeControl()
API die Fähigkeiten ihres Vibrators korrekt widerspiegelt. - Sollte die Fähigkeiten für die Skalierbarkeit von Amplituden durch Ausführen
android.os.Vibrator.hasAmplitudeControl()
überprüfen.
Wenn Geräteimplementierungen der maptischen Konstantskartierung folgen, dann:
- Sollte den Implementierungsstatus durch Ausführen von
android.os.Vibrator.areAllEffectsSupported()
undandroid.os.Vibrator.arePrimitivesSupported()
APIs überprüfen. - Sollte eine Qualitätsbewertung für haptische Konstanten durchführen.
- Sollte bei Bedarf die Fallback -Konfiguration für nicht unterstützte Primitive wie in den Implementierungsanleitungen für Konstanten beschrieben überprüfen und aktualisieren.
- Sollte Fallback -Unterstützung bieten, um das hier beschriebene Versagenrisiko zu mildern.
In Abschnitt 2.2.1 finden Sie Gerätespezifische Anforderungen.
- [7.10/c] muss für
9. Sicherheitsmodellkompatibilität
Siehe Revision
Geräteimplementierungen:
- [C-0-4] muss eine und nur eine Implementierung beider Benutzeroberflächen haben.
Wenn Geräteimplementierungen Pakete vorstellen, die eine der Systeme UI-Intelligenz , die Audio-Intelligenz von Systemen , System-Audio-Intelligenz , Systembenachrichtigungsintelligenz , Systemtextinformationen oder Systems visuelle Intelligenz, die Pakete für die visuelle Intelligenz, Systembenachrichtigung haben:
- [C-4-1] Muss alle Anforderungen erfüllen, die für Geräteimplementierungen in Abschnitten
"9.8.6 Inhaltserfassung""9.8.6 OS-Level- und Umgebungsdaten und 9.8.15-API-Implementierungen von Sandboxed" "9.8.6" erfüllen.
- [C-4-2] darf keine Android.Permission.internet-Erlaubnis haben. Dies ist strenger als die in Abschnitt 9.8.6 aufgeführten stark empfohlenen.
- [C-4-3] darf mit Ausnahme der folgenden System-Apps nicht an andere Apps binden: Bluetooth, Kontakte, Medien, Telefonie, Systemui und Komponenten, die Internet-APIs liefern. Dies ist strenger als die in Abschnitt 9.8.6 aufgeführten stark empfohlenen.
Wenn Geräteimplementierungen eine Standardanwendung enthalten, um den
VoiceInteractionService
zu unterstützen, den sie haben:- [C-5-1] darf
ACCESS_FINE_LOCATION
nicht als Standard für diese Anwendung gewähren.
9.5. Support für Multi-Benutzer :
Siehe Revision
Wenn Geräteimplementierungen das oben beschriebene zusätzliche Benutzerprofil erstellen, dann: dann:
- [C-4-5] muss die Dual-Instance-Anwendungssymbole visuell unterscheiden, wenn die Symbole den Benutzern präsentiert werden.
- [C-4-6] muss eine Benutzerkörper bereitstellen, um die gesamten Klonprofildaten zu löschen.
- [C-4-7] muss alle Klon-Apps deinstallieren, die privaten App-Datenverzeichnisse und deren Inhalt löschen und Klonprofildaten löschen, wenn der Benutzer die gesamten Klonprofildaten löscht.
- Sollte der Benutzer zum Löschen von gesamten Klonprofildaten auffordern, wenn die letzte Klon -App gelöscht wird.
- [C-4-8] muss den Benutzer darüber informieren, dass App-Daten gelöscht werden, wenn die Klonanwendung deinstalliert wird, oder den Benutzern die Option zur Aufbewahrung von App-Daten zur Deinstallation des Geräts zur Verfügung stellen.
- [C-4-9] muss die privaten App-Datenverzeichnisse und deren Inhalt löschen, wenn der Benutzer die Daten während der Deinstallation löschen möchte.
[C-4-1] muss zulassen, dass die folgenden Absichten, die aus dem zusätzlichen Profil stammen, durch Anwendungen des primären Benutzers auf dem Gerät behandelt werden:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] Muss alle Benutzerbeschränkungen für Geräterichtlinien und ausgewählte Nichtbenutzerbeschränkungen (unten) erben (unten), die auf den primären Benutzer des Geräts auf dieses zusätzliche Benutzerprofil angewendet werden.
[C-4-3] dürfen nur über die folgenden Absichten das Schreiben von Kontakten aus diesem zusätzlichen Profil zulassen:
[C-4-4] dürfen keine Kontaktsynchronisierung für Anwendungen haben, die in diesem zusätzlichen Benutzerprofil ausgeführt werden.
- [C-4-14] muss für die in diesem zusätzlichen Profil ausgeführten Anwendungen eine separate Berechtigung und Speicherverwaltung haben
- [C-4-5] dürfen nur Anwendungen im zusätzlichen Profil zulassen, die über eine Launcher-Aktivität auf Kontakte zugreifen, auf die bereits für das übergeordnete Benutzerprofil zugegriffen werden kann.
Siehe Revision
Eine Speichersicherheitstechnologie ist eine Technologie, die mindestens die folgenden Fehlerklassen mit einer hohen (> 90%) Wahrscheinlichkeit in Anwendungen, die das
android:memtagMode
Manifest -Option, mindert: Option: MemtagMode Manifest:- Heap -Pufferüberlauf
- benutzen nach frei
- doppelt frei
- wild frei (frei von einem Nicht-Mallloc-Zeiger)
Geräteimplementierungen:
- [C-SR-15] werden dringend empfohlen,
ro.arm64.memtag.bootctl_supported
festzulegen.
Wenn Geräteimplementierungen die Systemeigenschaft
ro.arm64.memtag.bootctl_supported
an true festlegen, sind sie:[C-3-1] muss der Systemeigenschaft
arm64.memtag.bootctl
zulassen, eine von der Kommission getrennte Liste der folgenden Werte zu akzeptieren, wobei der gewünschte Effekt auf den nächsten nachfolgenden Neustart angewendet wird:-
memtag
: Eine oben definierte Speichersicherheitstechnologie ist aktiviert -
memtag-once
: Eine oben definierte Speichersicherheitstechnologie ist vorübergehend aktiviert und beim nächsten Neustart automatisch deaktiviert -
memtag-off
: Eine oben definierte Speichersicherheitstechnologie ist deaktiviert
-
[C-3-2] muss dem Shell-Benutzer ermöglichen,
arm64.memtag.bootctl
festzulegen.[C-3-3] muss zulassen, dass jeder Prozess
arm64.memtag.bootctl
lesen kann.[C-3-4] muss
arm64.memtag.bootctl
auf den aktuell angeforderten Status beim BOOT einstellen. Es muss auch die Eigenschaft aktualisieren, wenn die Geräteimplementierung den Status ändern kann, ohne die Systemeigenschaft zu ändern.[C-SR-16] werden dringend empfohlen, eine Entwicklereinstellung anzuzeigen, die Memtag-Once 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 -Bootloaderprotokoll .
- [C-SR-17] werden dringend empfohlen, eine Einstellung im Menü Sicherheitseinstellungen anzuzeigen, mit der der Benutzer
memtag
aktiviert werden kann.
Siehe Revision
Geräteimplementierungen:
- [C-0-2] muss eine Benutzerwarnung anzeigen und eine explizite Einwilligung des Benutzers einholen , die sensible Informationen ermöglichen, die auf dem Bildschirm des Benutzers erfasst werden
können, die genau dieselbe Nachricht wie AOSP enthält,wennjedes Mal eine Sitzung zum Erfassen der Sitzung das erfasst wird Die Bildschirm-Casting- oder Bildschirmaufzeichnungistaktiviertüber dieMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
oder proprietäre APIs.Darf den Benutzern keine Gewährleistung bieten, um die zukünftige Anzeige der Einwilligung der Benutzer zu deaktivieren.
[C-SR-1] werden dringend empfohlen, eine Benutzerwarnung anzuzeigen, die genau dieselbe Nachricht ist wie in AOPS implementiert, kann jedoch geändert werden, solange die Nachricht den Benutzer eindeutig warnt, dass sensible Informationen auf dem Bildschirm des Benutzers erfasst werden.
[C-0-4] darf den Benutzern keine Gewährleistung bieten, um zukünftige Eingabeaufforderungen der Benutzereinwilligung zum Erfassen des Bildschirms zu deaktivieren, es sei denn, die Sitzung wird von einer System-App gestartet, die der Benutzer mit der
android.app.role.COMPANION_DEVICE_APP_STREAMING
associate()
.android.app.role.COMPANION_DEVICE_APP_STREAMING
oder dieandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
Gerätsprofil.
- [C-0-2] muss eine Benutzerwarnung anzeigen und eine explizite Einwilligung des Benutzers einholen , die sensible Informationen ermöglichen, die auf dem Bildschirm des Benutzers erfasst werden
9.8.6. OS-Level- und Umgebungsdaten : Dieser Abschnitt wurde in der Inhaltserfassung und der App-Suche in OS-Ebene und Umgebungsdaten umbenannt.
Siehe Revision
Android über die System -APIs
unterstützt einen Mechanismus für Geräteimplementierungen, um die folgendenContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
oder andere proprietäre MittelAnwendungsdateninteraktionen zwischen den Anwendungen und den benutzersensiblenDaten zu erfassen:- Jeder Bildschirm oder andere Daten, die über den
AugmentedAutofillService
an das System gesendet werden. - Jeder Bildschirm oder andere Daten, die über die API
Content Capture
erfasst werden können. - Jeder Bildschirm oder andere Daten, die über
FieldClassificationService
-API zugegriffen werden können - Alle Anwendungsdaten über die
AppSearchManager
-API übergeben und überAppSearchGlobalManager.query
zugänglich.
- Alle anderen Ereignisse, die eine Anwendung über die API oder
AppSearchManager
-API vonContent Capture
API für das System zur Verfügung stellt, ist eine ähnlich fähige Android- und proprietäre API.
- Audiodaten, die als Ergebnis der Verwendung von
SpeechRecognizer#onDeviceSpeechRecognizer()
durch die Rede -Erkennungs -Implementierung erhalten wurden. - Audiodaten, die (kontinuierlich) über
AudioRecord
,SoundTrigger
oder andere Audio-APIs erhalten wurden und nicht zu einem benutzerlich sichtbaren Indikator führen - Kameradaten im Hintergrund (kontinuierlich) über Kameramanager oder andere Kamera-APIs und nicht zu einem benutzerfreundlichen Indikator führen
Wenn Geräteimplementierungen eine der obigen Daten erfassen, sind sie:
[C-1-3] darf nur alle diese Daten
und das Gerät mithilfe eines Datenschutzmechanismus anmelden, außer mit der expliziten Einwilligung der Benutzer jedes Mal, wenn die Daten gemeinsam genutzt werden . Der Datenschutzmechanismus ist definiert als „solche, die nur eine Analyse in aggregierter Weise ermöglichen und die Anpassung an protokollierten Ereignissen oder abgeleiteten Ergebnissen an einzelne Benutzer verhindern“, um zu verhindernRAPPOR
).[C-1-5] darf solche Daten nicht mit anderen OS-Komponenten weitergeben, die nicht im aktuellen Abschnitt (9.8.6
Inhaltserfassungs-OS-Level- und Umgebungsdaten ) erfolgen, außer mit einer expliziten Einwilligung der Benutzer jedes Mal, wenn es ist, geteilt. Es sei denn, eine solche Funktionalität wird als Android -SDK -API (AmbientContext
,HotwordDetectionService
) erstellt.[C-1-6] muss dem Benutzer die Gewährleistung bieten, um solche Daten zu löschen, dass die
Implementierung oder die proprietären Mittel sammelt ,ContentCaptureService
wenndie Daten in einem beliebigen Formular auf dem Gerät gespeichert werden. Wenn der Benutzer die Daten löscht, muss alle gesammelten historischen Daten entfernen.
- [C-SR-3] wird dringend empfohlen, mit Android SDK API oder einem ähnlichen Open-Source-Repository im Open-Source-Repository implementiert zu werden. und / oder in einer sandboxen Implementierung durchgeführt werden (siehe 9.8.15 API -Implementierungen von Sandboxed).
Android bietet über
SpeechRecognizer#onDeviceSpeechRecognizer()
die Fähigkeit, die Spracherkennung auf dem Gerät auszuführen, ohne das Netzwerk einzubeziehen. Jede Implementierung des Redekogners für das Gerät muss den in diesem Abschnitt beschriebenen Richtlinien folgen.- Jeder Bildschirm oder andere Daten, die über den
9.8.10. Konnektivitätsfehlerbericht :
Siehe Revision
Wenn Geräteimplementierungen das Feature -Flag
android.hardware.telephony
deklarieren, dann:- [C-1-4] Berichte, die mithilfe von
BUGREPORT_MODE_TELEPHONY
generiert wurden, müssen mindestens die folgenden Informationen enthalten:-
SubscriptionManagerService
Dump
-
- [C-1-4] Berichte, die mithilfe von
9.8.14. Anmeldeinformationsmanager : entfernt
9.8.15. SANDBOOD -API -Implementierungen : neuer Abschnitt
Siehe Revision
Android bietet durch eine Reihe von Delegierten-APIs einen Mechanismus zur Verarbeitung sicherer OS-Ebene und Umgebungsdaten. Eine solche Verarbeitung kann an eine vorinstallierte APK mit privilegiertem Zugriff und reduzierten Kommunikationsfunktionen delegiert werden, die als sandboxte API -Implementierung bezeichnet werden.
Jede sandboxte API -Implementierung:
- [C-0-1] darf die Internet-Erlaubnis nicht anfordern.
- [C-0-2] dürfen nur über strukturierte APIs zugreifen, die durch öffentlich verfügbare Open-Source-Implementierungen unter Verwendung von Mechanismen für Datenschutzbestimmungen oder indirekt über Android-SDK-APIs unterstützt werden. Der Datenschutzmechanismus wird definiert als "solche, die nur eine Analyse in aggregierter Weise ermöglichen und die Anpassung an protokollierten Ereignissen oder abgeleiteten Ergebnissen an einzelne Benutzer verhindern", um zu verhindern Rappor ).
- [C-0-3] müssen die Dienste von anderen Systemkomponenten getrennt halten (z. B. die Bindung des Dienstes oder der Freigabe-Prozess-IDs), mit Ausnahme der folgenden:
- Telefonie, Kontakte, System -Benutzeroberfläche und Medien
- [C-0-4] dürfen Benutzern nicht erlauben, die Dienste durch eine Benutzeranwendung oder einen Dienst zu ersetzen
- [C-0-5] darf die vorinstallierten Dienste nur erlauben, solche Daten zu erfassen. Es sei denn, die Ersatzfähigkeit ist in AOSP integriert (z. B. für digitale Assistenten -Apps).
- [C-0-6] dürfen keine anderen Apps als dem vorinstallierten Dienstemechanismus zulassen, solche Daten zu erfassen. Es sei denn, eine solche Erfassungsfähigkeit wird mit einer Android -SDK -API implementiert.
- [C-0-7] muss dem Benutzer eine Gewährung bieten, um die Dienste zu deaktivieren.
- [C-0-8] darf die Benutzerverdienste nicht unterlassen, um Android-Berechtigungen zu verwalten, die von den Diensten gehalten werden, und das in Abschnitt 9.1 beschriebene Android-Berechtigungsmodell zu befolgen. Erlaubnis .
9.8.16. Kontinuierliche Audio- und Kamerataten : neuer Abschnitt
Siehe Revision
Zusätzlich zu den in 9.8.2 Aufzeichnung beschriebenen Anforderungen, 9.8.6 OS-Level- und Umgebungsdaten sowie 9.8.15 API-Implementierungen von Sandboxen, Implementierungen, die Audiodaten (kontinuierlich) über AudioreCord, Soundtrigger oder andere Audio-APIs verwenden Oder Kameradaten im Hintergrund (kontinuierlich) über Kameramannager oder andere Kamera -APIs:
- [C-0-1] muss einen entsprechenden Indikator (Kamera und/oder Mikrofon gemäß Abschnitt 9.8.2 Aufzeichnung) erzwingen, es sei denn,:
- Dieser Zugriff wird in einer Sandbox -Implementierung durchgeführt (siehe 9.8.15 SANDBOBS -API -Implementierung) über ein Paket, das eine oder mehrere der folgenden Rollen hält: System UI Intelligence , System Umgebungs Audio Intelligence , System Audio Intelligence , Systembenachrichtigungsintelligenz , Systemtextinformation , oder system visuelle Intelligenz .
- Der Zugang wird über eine Sandbox durchgeführt, die über Mechanismen in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
) implementiert und durchgesetzt wird. - Der Audiozugriff wird von der digitalen Assistentenanwendung für assistive Zwecke durchgeführt, wobei
SOURCE_HOTWORD
als Audioquelle versorgt wird. - Der Zugriff wird vom System durchgeführt und mit Open-Source-Code implementiert.
- [C-SR-1] wird dringend empfohlen, die Einwilligung der Benutzer für jede Funktionalität mit solchen Daten zu erfordern und standardmäßig deaktiviert zu werden.
- [C-SR-2] wird dringend empfohlen, dieselbe Behandlung anzuwenden (dh den in 9.8.2 Aufzeichnung beschriebenen Beschränkungen, 9.8.6 OS-Level- und Umgebungsdaten, 9.8.15 API-Implementierungen von Sandboxed API und 9.8.16 Continuous Audio und Kameradaten) an Kamerataten, die von einem Remote -Wearable -Gerät stammen.
Wenn die Kameradaten von einem Remote -Wearable -Gerät geliefert und in einer unverschlüsselten Form außerhalb von Android -Betriebssystemen, der Sandbox -Implementierung oder einer von
WearableSensingManager
erstellten Sandbox -Funktionen zugegriffen werden, dann:- [C-1-1] muss dem Ferngerät angeben, um dort einen zusätzlichen Indikator anzuzeigen.
Wenn Geräte ohne das zugewiesene Schlüsselwort eine digitale Assistentenanwendung in Anspruch nehmen können (entweder mit generischen Benutzernabfragen zu behandeln oder die Benutzerpräsenz über die Kamera zu analysieren):
- [C-2-1] muss sicherstellen, dass eine solche Implementierung durch ein Paket bereitgestellt wird, das die Rolle von
android.app.role.ASSISTANT
. - [C-2-2] muss sicherstellen, dass eine solche Implementierung
HotwordDetectionService
und/oderVisualQueryDetectionService
-Android-APIs verwendet.
- [C-0-1] muss einen entsprechenden Indikator (Kamera und/oder Mikrofon gemäß Abschnitt 9.8.2 Aufzeichnung) erzwingen, es sei denn,:
9.8.17. Telemetrie : neuer Abschnitt
Siehe Revision
Android speichert System- und App -Protokolle mit Statslog -APIs. Diese Protokolle werden über StatsManager -APIs verwaltet, die von privilegierten Systemanwendungen verwendet werden können.
StatsManager bietet außerdem eine Möglichkeit, Daten zu sammeln, die als Datenschutz aus Geräten mit einem Datenschutzmechanismus eingestuft wurden. Insbesondere
StatsManager::query
-API bietet die Möglichkeit, eingeschränkte metrische Kategorien abzufragen, die in StatsLog definiert sind.Jede Implementierung, die eingeschränkte Metriken von StatsManager abfragt und sammelt:
- [C-0-1] muss die einzige Anwendung/Implementierung auf dem Gerät sein und die Berechtigung
READ_RESTRICTED_STATS
halten. - [C-0-2] darf nur Telemetriedaten und das Protokoll des Geräts unter Verwendung eines Datenschutzmechanismus senden. Der Datenschutzmechanismus wird definiert als "solche, die nur eine Analyse in aggregierter Weise ermöglichen und die Anpassung an protokollierten Ereignissen oder abgeleiteten Ergebnissen an einzelne Benutzer verhindern", um zu verhindern Rappor ).
- [C-0-3] darf diese Daten nicht mit einer Benutzeridentität (wie dem Konto ) auf dem Gerät assoziieren.
- [C-0-4] dürfen solche Daten nicht mit anderen Betriebssystemkomponenten weitergeben, die nicht im aktuellen Abschnitt (9.8.17 Datenschutzverschreibungs-Telemetrie) entsprechen.
- [C-0-5] muss eine Benutzergünstigkeit bieten, um die Sammlung, Verwendung und Freigabe von Privatsphäre zu aktivieren/zu deaktivieren.
- [C-0-6] muss dem Benutzer die Gewährleistung bieten, um solche Daten zu löschen, die die Implementierung erfasst, wenn die Daten in einem beliebigen Formular auf dem Gerät gespeichert werden. Wenn der Benutzer die Daten löscht, muss alle auf dem Gerät gespeicherten Daten entfernen.
- [C-0-7] muss in einem Open-Source-Repository zugrunde liegende Datenschutzprotokoll-Implementierung offenlegen.
- [C-0-8] muss in diesem Abschnitt Datenausgangsrichtlinien zur Erfassung von Daten in eingeschränkten metrischen Kategorien durchsetzen, die in Statslog definiert sind.
- [C-0-1] muss die einzige Anwendung/Implementierung auf dem Gerät sein und die Berechtigung
Siehe Revision
GeräteimplementierungenWenn Geräteimplementierungen in der Lage sind, den Dateiinhalt pro Seitenbasis zu überprüfen, dann :
[
C-0-3C-2-1 ] Überprüfen Sie kryptografisch den Inhalt von Dateienmit einem vertrauenswürdigen Schlüssel,ohne die gesamte Datei zu lesen.[
C-0-4C-2-2 ] darf nicht zulassen, dass die Leseanforderungen in einer geschützten Datei erfolgreich sein, wenn der Leseinhaltnicht gegen einen vertrauenswürdigen Schlüssel überprüftwird .
- [C-2-4] muss die Prüfsumme der Datei in O (1) für aktivierte Dateien zurückgeben.
9.11. Schlüssel und Anmeldeinformationen :
Siehe Revision
Mit dem Android Keystore -System können App -Entwickler kryptografische Schlüssel in einem Container speichern und in kryptografischen Operationen über die Keychain -API oder die Keystore -API verwenden. Geräteimplementierungen:
- [C-0-3] muss die Anzahl fehlgeschlagener primärer Authentifizierungsversuche einschränken.
- [C-SR-2] werden dringend empfohlen, eine obere Grenze von 20 fehlgeschlagenen Primärauthentifizierungsversuchen zu implementieren. Wenn Benutzer einverstanden sind und die Funktion anmelden, führen Sie einen "Zurücksetzen der Fabrikdaten" durch, nachdem die Grenze fehlgeschlagener primärer Authentifizierungsversuche überschritten wurde.
Wenn Geräteimplementierungen die Authentifizierungsmethoden hinzufügen oder ändern, um den Sperrbildschirm zu entsperren, wenn sie auf einem bekannten Geheimnis basieren, und eine neue Authentifizierungsmethode zu verwenden, um den Bildschirm zu sperren, dann: dann:
- [C-SR-3] Es wird dringend empfohlen, mindestens 6 Ziffern oder gleichwertig eine 20-Bit-Entropie zu haben.
- [C-2-1] Ein Pin mit einer Länge von weniger als 6 Ziffern darf keinen automatischen Eintrag ohne Benutzerinteraktion zulassen, um die Enthüllung der Pinlänge zu vermeiden.
9.11.1. Sichere Sperrbildschirm, Authentifizierung und virtuelle Geräte :
Siehe Revision
Geräteimplementierungen:
- [C-0-1] muss die Anzahl der fehlgeschlagenen primären Authentifizierungsversuche einschränken.
- [C-SR-5] werden dringend empfohlen, eine obere Grenze von 20 fehlgeschlagenen Primärauthentifizierungsversuchen zu implementieren. Wenn Benutzer die Funktionen einverstanden und die Funktion anmelden, führen Sie einen "Fabrikdatenwechsel" durch, nachdem die Grenze der fehlgeschlagenen primären Authentifizierungsversuche überschritten wurde.
Wenn Geräteimplementierungen einen numerischen Pin als empfohlene primäre Authentifizierungsmethode festlegen, dann:
- [C-SR-6] Es wird dringend empfohlen, mindestens 6 Ziffern oder gleichwertig eine 20-Bit-Entropie zu haben.
- [C-SR-7] Es wird nachdrücklich empfohlen, dass ein Pin mit einer Länge von weniger als 6 Ziffern nicht den automatischen Eintritt ohne Benutzerinteraktion zulässt, um die Enthüllung der Pin-Länge zu vermeiden.
Wenn Geräteimplementierungen über einen sicheren Sperrbildschirm verfügen und einen oder mehrere Trust Agents enthalten, die die
TrustAgentService
-System-API implementieren, gilt Folgendes:[C-7-8] Der Benutzer muss mindestens alle 72 Stunden oder weniger für eine der empfohlenen primären Authentifizierung (z. B. PIN, Muster, Kennwort) in Frage gestellt werden Sorge.Wenn Geräteimplementierungen Anwendungen ermöglichen, sekundäre virtuelle Anzeigen zu erstellen und zugehörige Eingabeereignisse zu unterstützen, wie z .
[C-13-10] muss die Installation von Apps deaktivieren, die von virtuellen Geräten ausgelöst wurden.9.17. Android -Virtualisierungsrahmen :
Siehe Revision
Wenn das Gerät die Unterstützung für die Android -Virtualisierungs -Framework -APIs (
android.system.virtualmachine.*
), Der Android -Host implementiert:- [C-1-1] muss alle APIs unterstützen, die vom
android.system.virtualmachine
-Paket definiert wurden. - [C-1-2] darf das Android-Selinux- und Berechtigungsmodell für die Verwaltung geschützter virtueller Maschinen (PVM) nicht ändern.
- [C-1-3] darf die im System/Sepolicy vorhandenen Never-Regeln im vorgelagerten Android Open-Source-Projekt (AOSP) nicht ändern, weglassen oder ersetzen, und die Richtlinie muss mit allen vorhandenen Nie-Anlagen zusammenstellen.
- [C-1-4] darf nur den Plattform-Signiercode und die privilegierten Apps zulassen,
dürfen keinen nicht vertrauenswürdigen Code (z. B. 3P-Apps)zum Erstellen und Ausführen einesgeschützten virtuellen Maschinen-PVM erstellen und ausführen. Hinweis: Dies könnte sich in zukünftigen Android -Veröffentlichungen ändern.
- [C-1-5] darf a nicht zulassen
Geschützte virtuelle MaschinePVM zum Ausführen von Code, der nicht Teil des Fabrikbildes oder deren Aktualisierungen ist.Alles, was nicht von Android verifiziert wird (z. B. aus dem Internet heruntergeladene Dateien oder ausfällt), darf nicht in einer geschützten virtuellen Maschine ausgeführt werden.
- [C-1-5] dürfen nur einem nicht-debuggierbaren PVM Code aus dem Werksbild oder der Plattform-Updates ausführen, die auch aktuelle Aktualisierungen für privilegierte Apps enthält.
Wenn das Gerät die Unterstützung für die Android -Virtualisierungs -Framework -APIs (
android.system.virtualmachine.*
) Implementiert, dann hat eine pvM -Instanz dergeschützten virtuellen Maschine:- [C-2-1] muss in der Lage sein, alle in der Virtualisierungs-Apex verfügbaren Betriebssysteme in einem
geschützten virtuellen Maschinen-PVM auszuführen. - [C-2-2] dürfen nicht zulassen, dass ein geschützter PVM
virtueller Maschineein Betriebssystem ausführt, das nicht vom Geräteimplementierer oder OS-Anbieter signiert wird. - [C-2-3] dürfen einem
geschütztenPVM von Virtual Machine nicht zulassen, dass Daten als Code ausgeführt werden (z. B. Selinux Neverlow ExecMem).
- [C-2-4] darf die im System/Sepolicy/Microdroid vorhandenen Nie-Allow-Regeln im vorgelagerten Android Open Source Project (AOSP) nicht ändern, weglassen oder ersetzen.
- [C-2-5] muss auch für nicht-mikrodroidische Betriebssysteme
geschützte virtuelle Maschinen-PVM -Abwehrmechanismen (z. B. Selinux für PVMs) implementieren. - [C-2-6] muss sicherstellen, dass die PVM fehlschlägt,
dass die Firmware nichtstarten kann, wennsie die anfänglichenBilder , die der VM ausgeführt hat, nicht überprüfen kann, nicht überprüft werden kann. Die Überprüfung muss innerhalb der VM durchgeführt werden. - [C-2-7] muss sicherstellen, dass die PVM fehlschlägt,
dass die Firmware nichtstarten kann, wenn die Integrität der Instanz gefährdet ist.
Wenn das Gerät die Unterstützung für die Android -Virtualisierungs -Framework -APIs (
android.system.virtualmachine.*
) Implementiert, dann der Hypervisor:- [C-3-1] müssen sicherstellen, dass Speicherseiten ausschließlich einer VM (entweder PVM- oder Host-VM) nur für die virtuelle Maschine selbst oder den Hypervisor zugänglich sind, nicht von anderen virtuellen Maschinen-entweder geschützt oder nicht geschützt.
Darf kein PVM zulassen, Zugriff auf eine Seite zu einer anderen Entität (dh andere PVM oder Hypervisor) zu haben, es sei denn, der Seitenbesitzer wird ausdrücklich geteilt. Dies schließt den Host VM ein. Dies gilt sowohl für CPU- als auch für DMA -Zugriffe. - [C-3-2] muss eine Seite wischen, nachdem sie von einem PVM verwendet wurde und bevor sie an den Host zurückgegeben wird (z. B. wird das PVM zerstört).
- [C-
3-3SR-1 ] wird dringend empfohlen, um sicherzustellen,dass die PVM-Firmware vor jedem Code in einem PVM geladen und ausgeführt wird. - [C-3-4] muss sicherstellen, dass jedes VM ein pro-vm-Geheimnis ableitet, das
{Boot-Zertifikatkette (BCC) und zusammengesetzte Gerätekennung (CDIs), die einer PVM-Instanzbereitgestellt werden Fabrikreset und OTA.
Wenn das Gerät die Unterstützung für die Android -Virtualisierungs -Framework -APIs implementiert, dann in allen Bereichen:
- [C-4-1] darf einem PVM keine Funktionalität liefern, die das Umgehung des Android-Sicherheitsmodells ermöglicht.
Wenn das Gerät die Unterstützung für die Android -Virtualisierungs -Framework -APIs implementiert, dann:
- [C-5-1] muss in der Lage sein, die isolierte Kompilierung zu unterstützen , kann jedoch die isolierte Zusammenstellung auf dem Geräteversand
eines Kunst-Laufzeit-Updatesdeaktivieren.
Wenn das Gerät die Unterstützung für die Android -Virtualisierungs -Framework -APIs implementiert, dann für die Schlüsselverwaltung:
- [C-6-1] muss an einem Punkt, den der Benutzer nicht ändern kann, selbst bei entsperrten Geräten die Würfelskette rooten. (Um sicherzustellen, dass es nicht gefälscht werden kann).
- [C- SR-2
6-2] wird dringend empfohlen, Würfel als Mechanismus pro-vm-Geheimivationsableitung zu verwenden.Muss Würfel richtig machen, dh die richtigen Werte liefern.
- [C-1-1] muss alle APIs unterstützen, die vom