Android 14
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 die
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 die
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 eine klare Haptik in android.view.HapticFeedbackConstants implementieren, nämlich (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START und GESTURE_END).
- [ 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 Audio-Decodierungssitzung mit einer Bitrate von 128 kbps oder niedriger für alle Audio-Decoder 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.
Unter einer nach vorne gerichteten Kamera versteht man eine dem Benutzer zugewandte Kamera, die sich an einer beliebigen Stelle des Fahrzeugs befinden kann und in den Innenraum des Fahrzeugs 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ären Benutzern, 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 definierten Rollen
innehabenmit 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 Einzelheiten 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, d. h. 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-Kanalzahl unterstützen, die auch als fcc_limit bezeichnet wird.
Siehe Revision
Wenn Geräteimplementierungen
android.hardware.audio.output
deklarieren, wird nachdrücklich empfohlen, die folgenden Anforderungen zu erfüllen oder zu übertreffen:- [C-SR-4] Der von audiotrack.gettimestamp und
AAudioStream_getTimestamp
zurückgegebene Ausgangszeitstempel ist auf +/- 1 ms genau.
- [C-SR-4] Die berechneten Roundtrip-Latenzen, die auf Eingabe- und Ausgabezeitstempeln basieren, die von
AAudioStream_getTimestamp
zurückgegeben werden, wird dringend empfohlen, innerhalb von 30 ms der gemessenen Round-Trip-Latenz fürAAUDIO_PERFORMANCE_MODE_NONE
undAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
und Sprecher, verwirrte und dröhnte Lacecents, verwirrte und dröhnte Laken, verwirrte und dröhnte Headsets zu liegen.
- [C-SR-4] Der von audiotrack.gettimestamp und
7. Hardwarekompatibilität
Siehe Revision
Android umfasst Einrichtungen, die die Anwendungsvermögen und UI-Layouts automatisch für das Gerät angemessen anpassen, um sicherzustellen, dass Drittanbieter-Anwendungen auf einer
Vielzahl von Hardwarekonfigurationen gut ausgeführt werden.Vielzahl von Hardware -Displays und Konfigurationen. Eine Android-kompatible Anzeige ist ein Display-Bildschirm, das alle in Android-Entwicklern beschriebenen Verhaltensweisen und APIs implementiert- Überblick Diese CDD.Auf den Android-kompatiblen Displays (en), in 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] müssen standardmäßig Anwendungen von Drittanbietern nur auf Android-kompatible Displays übertragen.
Die Einheiten, auf die sich die Anforderungen in diesem Abschnitt beziehen, sind wie folgt definiert:
- Physikalische diagonale Größe . Die Entfernung in Zentimeter zwischen zwei gegensätzlichen Ecken des beleuchteten Teils des Displays.
-
Punkte pro Zoll (DPI)Dichte . Die Anzahl der Pixel, die durch eine lineare horizontale oder vertikale Spannweite von 1 Zoll umfassen , ausgedrückt als Pixel pro Zoll (PPI oder DPI) . WennDPI-PPI- und DPI -Werte aufgeführt sind, müssen sowohl horizontale als auch vertikale DPI in den aufgelisteten Bereich fallen. - Seitenverhältnis . Das Verhältnis der Pixel der längeren Dimension zur kürzeren Dimension des Bildschirms. Beispielsweise wäre eine Anzeige von 480 x 854 Pixel 854/480 = 1,779 oder ungefähr „16: 9“.
- Dichteunabhängige Pixel (DP) .
DieA- virtuelle Pixeleinheit, die auf eine160-dpi-Bildschirm-Bildschirmdichte von 160normalisiertwurde dp = (160 / d) * p .
7.1.1.1. Bildschirmgröße und -form :
Siehe Revision
Wenn Geräteimplementierungen Bildschirme unterstützen, die zur Konfiguration der
UI_MODE_TYPE_NORMAL
SRIBY in der Lage sind, und die physischen Anzeigenvon Android-kompatiblen Verwendung mit abgerundeten Ecken enthalten,um diese Bildschirme zu rendern , sind sie:- [C-1-1] muss sicherstellen, dass für jede solche Anzeige mindestens eine der folgenden Anforderungen erfüllt wird:
- Der Radius der abgerundeten Ecken beträgt weniger als oder gleich 38 dp.
Wenn an jeder Ecke des logischen Displays ein 15 dp x 15 dp veranker ist, ist auf dem Bildschirm mindestens ein Pixel jeder Box sichtbar.
Sollte die Benutzerbilanz einbeziehen, um mit den rechteckigen Ecken in den Anzeigemodus umzusteigen.
Starten Sie neue Anforderungen
Wenn Geräteimplementierungen nur mit der Tastaturkonfiguration
NO_KEYS
in der Lage sind und die Unterstützung für die KonfigurationUI_MODE_TYPE_NORMAL
UI -Modus melden möchten, sind Sie:- [C-4-1] muss eine Layoutgröße ohne Anzeigeausschnitte von mindestens 596 dp x 384 dp oder mehr haben.
Wenn Geräteimplementierungen eine faltbare Android-kompatible Anzeige enthalten oder ein faltungsvolles Scharnier zwischen mehreren Anzeigetafeln enthalten und solche Displays zur Verfügung stellen, um Apps von Drittanbietern zu rendern, sind sie:
- [C-2-1] muss die neueste verfügbare stabile Version der Extensions-API oder die stabile Version der SIDECAR-API von der Window Manager-Jetpack- Bibliothek verwendet werden.
Wenn Geräteimplementierungen eine faltbare Android-kompatible Anzeige enthalten oder ein Faltungsscharnier zwischen mehreren Anzeigetafeln enthalten und wenn das Scharnier oder die Falte ein Vollbild-Anwendungsfenster überquert, sind sie:
- [C-3-1] MÜSSEN die Position, die Grenzen und den Zustand des Scharniers oder die Falten durch Erweiterungen oder Sidecar-APIs für die Anwendung melden.
Wenn Geräteimplementierungen ein oder mehrere Android-kompatible Anzeigebereiche enthalten, die faltbar sind, oder ein Faltscharschen zwischen mehreren Android-kompatiblen Anzeigebereichen und Bereichen der Anzeige für Anwendungen zur Verfügung gestellt werden:
- [C-4-1] muss die richtige Version der API-Ebene der Fensterverlängerung implementieren, wie in den bevorstehenden Dokumentation beschrieben.
7.1.1.2. Bildschirm Seitenverhältnis : entfernt
Siehe Revision
Geräteimplementierungen:
- [C-0-1]
Standardmäßig dürfen Geräteimplementierungennureine der Android-Framework-Dichten melden, die über die APIDENSITY_DEVICE_STABLE
DisplayMetrics
sind. Dieser Wert muss für jede physische Anzeigezu keinem Zeitpunkt geändert werden.Das Gerät kannjedochjedoch eine anderebeliebige DichteDisplayMetrics.density
melden. Densität gemäß den vom Benutzer (z. B. Anzeigegröße angegebenen Anzeigegröße) nach dem Erststart vorgenommene Konfigurationsänderungen.
- Geräteimplementierungen sollten die Standard -Android -Framework -Dichte definieren, die der physikalischen Dichte des Bildschirms numerisch am nächsten ist, es sei denn, diese logische Dichte drückt die gemeldete Bildschirmgröße unter den unterstützten Minimum. Wenn die Standard -Android -Framework -Dichte, die der physikalischen Dichte numerisch am nächsten ist, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 DP -Breite) ist, sollten die Geräteimplementierungen die nächstniedrigste Android -Framework -Dichte der Android -Framework angeben.
Starten Sie neue Anforderungen
- Sollte die Standard-Android-Framework-Dichte definieren, die der physikalischen Dichte des Bildschirms numerisch am nächsten ist, oder einen Wert, der demselben äquivalenten Winkelfeldmessungen eines Handheld-Geräts zugeordnet ist.
Wenn Geräteimplementierungen eine Gewährleistung für die Änderung der Anzeigegröße des Geräts
vorhanden sind, dann :- [C-1-1]
Die Anzeigegröße darf nicht skaliert werden,darf die Anzeige nicht mehr als das 1,5-facheDENSITY_DEVICE_STABLE
native Dichteskalieren oder eine effektive minimale Bildschirmdimension von kleiner als 320DP erzeugen (entsprechend der Ressourcenqualifiziererin SW320DP), je nachdem, was zuerst kommt. - [C-1-2]
Die Anzeigegröße darf nicht skaliert werden,darf die Anzeige kleiner als das 0,85-fache dernativen DichteDENSITY_DEVICE_STABLE
nicht skalieren.
- [C-0-1]
Siehe Revision
Wenn die Geräteimplementierungen die Unterstützung von Vulkan
1.0 oder höherenthalten, sind sie:[C-1-3] muss die
Vulkan 1.0Vulkan 1.1- APIs für jeden aufzähligenVkPhysicalDevice
vollständig implementieren.[C-1-5] darf keine von Bibliotheken außerhalb des Anwendungspakets bereitgestellten Ebenen aufzählen oder andere Möglichkeiten zur
true
odercom.android.graphics.injectLayers.enable
derandroid:debuggable
-API bereitstellen, es sei denncom.android.graphics.injectLayers.enable
Set auftrue
.
- Sollte
VkPhysicalDeviceProtectedMemoryFeatures
undVK_EXT_global_priority
unterstützen.
- [C-1-13] müssen die vom Android Baseline 2021-Profil angegebenen Anforderungen erfüllen.
[C
VK_EXT_global_priority
SR-5] werden dringend empfohlen, umVkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
zu unterstützen.[C-SR-6] werden dringend empfohlen,
SkiaVk
mit HWUI zu verwenden.
Wenn die Geräteimplementierungen die Unterstützung von Vulkan 1.1 enthalten und die hier beschriebenen Vulkan -Feature -Flaggen deklarieren, sind sie:
- [C-SR - 7] werden dringend empfohlen, um die Erweiterung
VK_KHR_external_fence_fd
für Anwendungen von Drittanbietern verfügbar zu machen und die Anwendung zu ermöglichen, die Nutzlast der Zaun in POSIX-Dateideskriptoren zu exportieren und Zaunnutzlast zu importieren.
7.3.10. Biometrische Sensoren :
Siehe Revision
Wenn Geräteimplementierungen mehrere biometrische Sensoren haben, sind sie:
[C-7-1] muss, wenn sich eine Biometrie in der Sperrung befindet (dh der Biometrie ist deaktiviert, bis der Benutzer mit primärer Authentifizierung freigeschaltet wird) oder eine zeitgebundene Aussperrung (dh der Biometrie ist vorübergehend deaktiviert, bis der Benutzer auf ein Zeitintervall wartet) Aufgrund zu vieler fehlgeschlagener Versuche sperren auch alle anderen Biometrie einer niedrigeren biometrischen Klasse. Bei zeitgebundener Aussperrung muss die Backoff-Zeit für die biometrische Überprüfung die maximale Backoff-Zeit aller Biometrie in zeitgebundenem Sperrung sein.
[C-SR-12] werden dringend empfohlen, wenn sich eine Biometrie in der Sperrung befindet (dh der Biometrie ist deaktiviert, bis der Benutzer mit primärer Authentifizierung freigeschaltet wird) oder eine zeitgebundene Aussperrung (dh der Biometrie ist vorübergehend deaktiviert, bis der Benutzer eine Zeit wartet Intervall) aufgrund zu vieler fehlgeschlagener Versuche, um auch alle anderen Biometrie derselben biometrischen Klasse auszuschließen. Im Falle einer zeitgebundenen Sperrung wird die Backoff-Zeit für die biometrische Überprüfung dringend empfohlen, die maximale Backoff-Zeit aller Biometrie in zeitgebundener Sperrung zu sein.
[C-7-2] muss den Benutzer um die empfohlene primäre Authentifizierung (z. B. PIN, Muster, Kennwort) herausfordern, den Sperrschalter für eine ausgeschlossene Biometrie zurückzusetzen. Die Biometrie der Klasse 3 kann den Sperrschalter für eine verschlossene Biometrie derselben oder unteren Klasse zurücksetzen. Die Biometrie der Klasse 2 oder der Klasse 1 darf keinen Reset -Sperrvorgang für Biometrie abschließen.
Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 1 (ehemals Bequemlichkeit ) behandeln möchten, dann:
[C-1-12] muss eine Parodie- und Betrüger-Akzeptanzrate von nicht mehr als 40% pro Präsentationsinstrumentinstrument (PAI) haben, gemessen anhand der Android-Biometrics-Testprotokolle .
[C-SR-13] wird dringend empfohlen, eine Parodie- und Betrüger-Akzeptanzrate von nicht mehr als 30% pro Präsentationsinstrumentinstrument (PAI) zu haben, gemessen anhand der Android-Biometrics-Testprotokolle .
[C-SR-14] werden dringend empfohlen, die biometrische Klasse des biometrischen Sensors und die entsprechenden Risiken des Aktivierens offenzulegen.
[C
IFingerprint.aidl
SR-17] werden dringend empfohlen, die neuen AIDL-Schnittstellen (IFace.aidl
.
Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 2 (ehemals schwach ) behandeln möchten, sind sie:
- [C-SR-15] wird dringend empfohlen, eine Parodie- und Betrüger-Akzeptanzrate von nicht mehr als 20% pro Präsentationsinstrumentinstrument (PAI) zu haben, gemessen anhand der Android-Biometrics-Testprotokolle .
- [C-2-3] muss die biometrische Übereinstimmung in einer isolierten Ausführungsumgebung außerhalb des Android-Benutzer- oder Kernelraums
wieder vertrauenswürdigen Ausführungsumgebung (TE- Virtuelle Maschine, die die Anforderungen in Abschnitt 9.17 erfüllt . - [C-2-4] muss über alle identifizierbaren Daten verschlüsselt und kryptografisch authentifiziert werden, so dass sie außerhalb der isolierten Ausführungsumgebung oder einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung nicht erfasst, gelesen oder verändert werden können, wie in den Implementierungsrichtlinien dokumentiert werden Auf der Android Open Source -Projektstelle oder einer von Hypervisor gesteuerten virtuellen Maschine, die die Anforderungen in Abschnitt 9.17 erfüllt .
- [C-2-5] für eine biometrische Basis von Kameras, während eine biometrische Authentifizierung oder Registrierung stattfindet:
- Muss die Kamera in einem Modus bedienen, in dem die Kamerarahmen außerhalb der isolierten Ausführungsumgebung oder einem Chip mit einem sicheren Kanal zur isolierten Ausführungsumgebung oder einem von Hypervisor gesteuerten geschützten virtuellen Maschine, der die Anforderungen in Abschnitt 9.17 entspricht, außerhalb der isolierten Ausführungsumgebung betreiben oder verändert wird.
- Bei RGB-Einzelkamera-Lösungen können die Kamera-Frames außerhalb der isolierten Ausführungsumgebung lesbar sein, um Operationen wie die Vorschau für die Registrierung zu unterstützen, müssen jedoch dennoch nicht verändert werden.
- [C-2-7] dürfen den unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder von daraus abgeleiteten Daten (z. B. Einbetten) auf den Anwendungsprozessor außerhalb des Kontextes des TEE oder des von Hypervisor gesteuerten Virtualmaschinens, der den Anforderungen im Abschnitt erfüllt, nicht zulassen 9.17 . Upgrade-Geräte, die auf Android Version 9 oder früher gestartet wurden, sind nicht von C-2-7 ausgenommen.
Wenn Geräteimplementierungen einen biometrischen Sensor als Klasse 3 (früher stark ) behandeln möchten, dann:
- [C-SR-16] wird dringend empfohlen, eine Parodie- und Betrüger-Akzeptanzrate von nicht mehr als 7% pro Präsentationsinstrumentinstrument (PAI) zu haben, gemessen anhand der Android-Biometrics-Testprotokolle .
7.3.13. IEEE 802.1.15.4 (UWB) :
Siehe Revision
Wenn die Geräteimplementierungen die Unterstützung für 802.1.15.4 enthalten und die Funktionalität einer Anwendung von Drittanbietern aussetzen, sind sie:
- [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, aufgeschobener Modus, Ranging-Intervall 240 ms. -
CONFIG_ID_2
: FIRA-definierte Eins-zu-VieleSTATIC STS DS-TWR
, aufgeschobener Modus, Ranging-Intervall 200 ms. Typischer Anwendungsfall: Smartphone interagiert mit vielen intelligenten Geräten. -
CONFIG_ID_3
: WieCONFIG_ID_1
, mit Ausnahme der Daten des AOA-Angle-Of-ARA werden nicht gemeldet. -
CONFIG_ID_4
: gilt wieCONFIG_ID_1
, außer dass der Sicherheitsmodus von P-Sts aktiviert ist. -
CONFIG_ID_5
: WieCONFIG_ID_2
, außer dass der Sicherheitsmodus von P-Sts aktiviert ist. -
CONFIG_ID_6
: WieCONFIG_ID_3
, außer dass der Sicherheitsmodus von P-Sts aktiviert ist. -
CONFIG_ID_7
: WieCONFIG_ID_2
, außer dass der einzelnen Steuerungsmodus des einzelnen Steuerelements aktiviert ist.
-
- [C-1-4] muss eine Benutzergeistigkeit bieten, damit der Benutzer das UWB-Radio ein-/aus-Status umschalten kann.
- [C-1-5] muss durchsetzen, dass Apps, die UWB-Radio verwenden, die Berechtigungsberechtigung
UWB_RANGING
(unter der GenehmigungsgruppeNEARBY_DEVICES
) halten.
Durch die relevanten Konformitäts- und Zertifizierungstests, die von Standardorganisationen, einschließlich Fira , CCC und CSA , definiert wurden, wird sichergestellt, dass 802.1.15.4 Funktionen korrekt sind.
- [C-1-2] muss das Hardware-Feature-Flag
Siehe Revision
"Telefonie", wie sie von den Android -APIs und in diesem Dokument verwendet werden, bezieht sich speziell auf Hardware, die sich auf das Platzieren von Sprachanrufen und das Senden von SMS -Nachrichten oder das Erstellen von mobilen Daten über ein mobiles GSM- oder CDMA -Netzwerk beziehen. Ein Gerät, das „Telefonie“ unterstützt, kann einige oder alle Anrufe, Nachrichten- und Datendienste als Produkt anbieten.
über ein GSM- oder CDMA -Netzwerk. Diese Sprachanrufe können zwar paketanschlitzt werden oder auch nicht, aber sie stehen für die Zwecke von Android als unabhängig von einer Datenkonnektivität, die möglicherweise mit demselben Netzwerk implementiert werden kann. Mit anderen Worten, die Android -Funktionalität und APIs beziehen sich speziell auf Sprachanrufe und SMS. Beispielsweise werden Geräteimplementierungen, bei denen keine Anrufe getätigt werden oder SMS -Nachrichten gesendet/empfangen werden können, nicht als Telefonie -Gerät angesehen, unabhängig davon, ob sie ein Mobilfunknetz für die Datenkonnektivität verwenden.Siehe Revision
Wenn die Geräteimplementierungen die Unterstützung für 802.11 enthalten und die Funktionalität einer Anwendung von Drittanbietern aussetzen, sind sie:
- [C-1-4] muss Multicast-DNS ( MDNs ) unterstützen und dürfen keine MDNS Die Filterung dieser Pakete ist erforderlich, um in Stromverbrauchsbereichen zu bleiben, die durch die auf den Zielmarkt geltenden regulatorischen Anforderungen erforderlich sind.
Für Android -Fernsehgerät -Implementierungen, auch in Standby -Leistungsstaaten.
- [C-1-4] muss Multicast-DNS ( MDNs ) unterstützen und dürfen keine MDNS Die Filterung dieser Pakete ist erforderlich, um in Stromverbrauchsbereichen zu bleiben, die durch die auf den Zielmarkt geltenden regulatorischen Anforderungen erforderlich sind.
Siehe Revision
Wenn Geräteimplementierungen feature_bluetooth_le deklarieren, dann: sie:
- [C-SR
ADVERTISE_TX_POWER_HIGH
2] werden dringend empfohlen, den RX-Offset zu messen und auszugleichen, um sicherzustellen auf 'parallelen Ebenen' mit Bildschirmen mit der gleichen Richtung. - [C-SR-3] werden dringend empfohlen, den TX-Offset zu messen und auszugleichen, um
ADVERTISE_TX_POWER_HIGH
so dass sie in "parallelen Ebenen" mit Bildschirmen mit der gleichen Richtung sind.
- [C-10-3] muss den RX-Offset messen und kompensieren, um sicherzustellen, dass die mediane RSSI -55 dBm +/- 10 dB bei 1 m Abstand von einem Referenzgerät, das unter
ADVERTISE_TX_POWER_HIGH
überträgt, beträgt. - [C-10-4] muss den TX-Offset messen und kompensieren, um sicherzustellen, dass die mediane RSSI -55 dBm +/- 10 dB bei einem Referenzgerät bei 1 m-Entfernung und Übertragung bei
ADVERTISE_TX_POWER_HIGH
beträgt.
Wenn Geräteimplementierungen Bluetooth Version 5.0 unterstützen, dann: dann:
- [C-SR-4] werden dringend empfohlen, um zu unterstützen:
- Le 2m Phy
- Le Codec Phy
- Le Advertising -Erweiterung
- Regelmäßige Werbung
- Mindestens 10 Werbesätze
- Mindestens 8 LE -Verknüpfungen. Jede Verbindung kann in beiden Verbindungs -Topologie -Rollen stehen.
- LE Link Layer Privatsphäre
- Eine Größe von mindestens 8 Einträgen "Auflösungsliste"
- [C-SR
Siehe Revision
- [C-1-7] muss sicherstellen, dass der Median der Entfernungsmessungen bei 1 m von der Referenzvorrichtung innerhalb von [0,75 m, 1,25 m] liegt, wo der Grundwahrheitsabstand vom oberen Rand des Duts gemessen wird.
Gesicht nach oben und 45 Grad geneigt.
- [C-1-7] muss sicherstellen, dass der Median der Entfernungsmessungen bei 1 m von der Referenzvorrichtung innerhalb von [0,75 m, 1,25 m] liegt, wo der Grundwahrheitsabstand vom oberen Rand des Duts gemessen wird.
7.5.1. Nach hinten gerichtete Kamera :
Siehe Revision
Eine nach hinten gerichtete Kamera ist eine Kamera an der Seite des Geräts gegenüber dem Display. Das heißt, es bildet wie eine herkömmliche Kamera Szenen auf der anderen Seite des Geräts.
Eine nach hinten gerichtete Kamera ist eine weltweite Kamera, die wie eine herkömmliche Kamera auf der anderen Seite des Geräts szenen. Auf Handheld -Geräten befindet sich eine Kamera an der Seite des Geräts gegenüber dem Display.
Siehe Revision
Eine vorne gerichtete Kamera ist eine Kamera auf derselben Seite des Geräts wie das Display. Das heißt, eine Kamera, die normalerweise verwendet wird, um den Benutzer vorzustellen, z. B. für Videokonferenzen und ähnliche Anwendungen.
Eine vorne gerichtete Kamera ist eine benutzergerichtete Kamera, die normalerweise zum Bild des Benutzers verwendet wird, z. B. für Videokonferenzen und ähnliche Anwendungen. Auf Handheld -Geräten befindet sich eine Kamera auf derselben Seite des Geräts wie das Display.
Siehe Revision
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
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
der gleichen Richtung wird dringend empfohlen, ein logisches Kamera-Gerät zu unterstützen, das die Fähigkeitsfunktionskamerametadaten auflistet. Als physische Unterverfassungen.
- [C-SR-1] Für Geräte mit mehreren RGB-Kameras in unmittelbarer Nähe und
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
GESTURE_END
TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,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.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
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:- 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 können,
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
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 dasGerä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
BUGREPORT_MODE_TELEPHONY
generiert wurden, müssen mindestens die folgenden Informationen enthalten:-
SubscriptionManagerService
Dump
-
- [C-1-4] Berichte, die mithilfe
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] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Erlaubnis .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager
, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANT
role. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionService
and/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::query
API provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATS
permission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Geräteimplementierungen:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Geräteimplementierungen:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
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] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of Sorge.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the