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 verfügen ü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.
Starten Sie neue Anforderungen
- Verfügen Sie über eine Touchscreen-Eingabeschnittstelle.
- Sie verfügen ü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 an der kurzen Kante mindestens 2,2 Zoll und an der langen Kante mindestens 3,4 Zoll groß ist.[ 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 _ENDE).
- [ 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, auch wenn diese Anforderung 4K erfordert.
- [5.1/H-1-7] MUSS eine Codec-Initialisierungslatenz von 40 ms oder weniger für eine 1080p- oder kleinere Videokodierungssitzung für alle Hardware-Videokodierer unter Last haben. Unter „Laden“ versteht man eine gleichzeitige reine Videotranskodierungssitzung von 1080p in 720p unter Verwendung von Hardware-Videocodecs zusammen mit der Initialisierung der 1080p-Audio-Video-Aufzeichnung. Für den Dolby Vision-Codec MUSS die Codec-Initialisierungslatenz 50 ms oder weniger betragen.
- [5.1/H-1-8] MUSS eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiocodierungssitzung mit einer Bitrate von 128 kbps oder niedriger für alle Audio-Encoder unter Last haben. Unter „Laden“ versteht man eine gleichzeitige reine Videotranskodierungssitzung von 1080p in 720p unter Verwendung von Hardware-Videocodecs zusammen mit der Initialisierung der 1080p-Audio-Video-Aufzeichnung.
- [5.1/H-1-9] MÜSSEN 2 Instanzen sicherer Hardware-Video-Decoder-Sitzungen (AVC, HEVC, VP9, AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit 4K-Auflösung bei 30 fps (außer AV1) für beide 8- Bit (SDR) und 10-Bit HDR-Inhalte. AV1-Codec-Sitzungen müssen nur die Auflösung 1080p unterstützen, selbst wenn diese Anforderung 4K erfordert.
- [5.1/H-1-10] MÜSSEN 3 Instanzen nicht sicherer Hardware-Video-Decoder-Sitzungen zusammen mit 1 Instanz sicherer Hardware-Video-Decoder-Sitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, AV1 oder höher) in jedem Codec unterstützen Kombination, die gleichzeitig mit 3 Sitzungen bei 4K-Auflösung bei 30 fps (außer AV1) läuft, die eine sichere Decoder-Sitzung und 1 nn-sichere Sitzung bei 1080p-Auflösung bei 30 fps umfasst, wobei höchstens 2 Sitzungen in 10-Bit-HDR stattfinden können. AV1-Codec-Sitzungen müssen nur die Auflösung 1080p unterstützen, selbst wenn diese Anforderung 4K erfordert.
- [5.1/H-1-11] MUSS einen sicheren Decoder für jeden Hardware-AVC-, HEVC-, VP9- oder AV1-Decoder auf dem Gerät unterstützen.
- [5.1/H-1-12] MUSS eine Codec-Initialisierungslatenz von 40 ms oder weniger für eine 1080p- oder kleinere Videodekodierungssitzung für alle Hardware-Videodecoder unter Last haben. Unter „Laden“ versteht man eine gleichzeitige reine Videotranskodierungssitzung von 1080p in 720p unter Verwendung von Hardware-Videocodecs zusammen mit der Initialisierung der 1080p-Audio-Video-Wiedergabe. Für den Dolby Vision-Codec MUSS die Codec-Initialisierungslatenz 50 ms oder weniger betragen.
- [5.1/H-1-13] MUSS eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiodekodierungssitzung mit einer Bitrate von 128 kbps oder niedriger für alle Audiodecoder unter Last haben. Unter „Laden“ versteht man eine gleichzeitige reine Videotranskodierungssitzung von 1080p in 720p unter Verwendung von Hardware-Videocodecs zusammen mit der Initialisierung der 1080p-Audio-Video-Wiedergabe.
- [5.1/H-1-14] MUSS den AV1-Hardware-Decoder Main 10, Level 4.1 und Filmkörnung unterstützen.
- [5.1/H-1-15] MUSS über mindestens 1 Hardware-Videodecoder verfügen, der 4K60 unterstützt.
- [5.1/H-1-16] MUSS über mindestens einen Hardware-Video-Encoder verfügen, der 4K60 unterstützt.
- [5.3/H-1-1] Bei einer 4K-Videositzung mit 60 fps unter Last DARF NICHT mehr als 1 Frame in 10 Sekunden verloren gehen (d. h. weniger als 0,167 Prozent Frame Drop).
- [5.3/H-1-2] Während einer Änderung der Videoauflösung in einer 60-fps-Videositzung unter Last für eine 4K-Sitzung DARF NICHT mehr als 1 Bild in 10 Sekunden verloren gehen.
- [5.6/H-1-1] MUSS eine Tap-to-Tone-Latenz von 80 Millisekunden oder weniger haben, wenn der CTS Verifier Tap-to-Tone-Test verwendet wird.
- [5.6/H-1-2] MUSS über mindestens einen unterstützten Datenpfad eine Audio-Round-Trip-Latenz von 80 Millisekunden oder weniger haben.
- [5.6/H-1-3] MUSS >=24-Bit-Audio für die Stereoausgabe über 3,5-mm-Audiobuchsen (falls vorhanden) und über USB-Audio unterstützen, wenn dies über den gesamten Datenpfad für Konfigurationen mit geringer Latenz und Streaming unterstützt wird. Für die Konfiguration mit geringer Latenz sollte AAudio von der App im Rückrufmodus mit geringer Latenz verwendet werden. Für die Streaming-Konfiguration sollte ein Java AudioTrack von der App verwendet werden. Sowohl in der Konfiguration mit geringer Latenz als auch in der Streaming-Konfiguration sollte die HAL-Ausgabesenke entweder
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
oderAUDIO_FORMAT_PCM_FLOAT
als Zielausgabeformat akzeptieren. - [5.6/H-1-4] MUSS >=4-Kanal-USB-Audiogeräte unterstützen (Dies wird von DJ-Controllern für die Vorschau von Songs verwendet.)
- [5.6/H-1-5] MUSS klassenkompatible MIDI-Geräte unterstützen und das MIDI-Feature-Flag deklarieren.
- [5.6/H-1-9] MUSS mindestens 12-Kanal-Mischung unterstützen. Dies impliziert die Möglichkeit, einen AudioTrack mit 7.1.4-Kanalmaske zu öffnen und alle Kanäle ordnungsgemäß zu verräumlichen oder auf Stereo herunterzumischen.
- [5.6/H-SR] Es wird DRINGEND EMPFOHLEN, 24-Kanal-Mischung mit mindestens Unterstützung für 9.1.6- und 22.2-Kanal-Masken zu unterstützen.
- [5.7/H-1-2] MUSS
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
mit den folgenden Inhaltsentschlüsselungsfunktionen unterstützen.
Mindestprobengröße | 4 MiB |
Mindestanzahl an Teilproben – H264 oder HEVC | 32 |
Mindestanzahl an Teilproben – VP9 | 9 |
Mindestanzahl an Teilproben – AV1 | 288 |
Mindestgröße des Teilprobenpuffers | 1 MiB |
Mindestgröße des generischen Kryptopuffers | 500 KiB |
Mindestanzahl gleichzeitiger Sitzungen | 30 |
Mindestanzahl von Schlüsseln pro Sitzung | 20 |
Mindestgesamtzahl der Schlüssel (alle Sitzungen) | 80 |
Mindestgesamtzahl der DRM-Schlüssel (alle Sitzungen) | 6 |
Nachrichtengröße | 16 KiB |
Entschlüsselte Frames pro Sekunde | 60 fps |
- [5.1/H-1-17] MUSS über mindestens einen Hardware-Bilddecoder verfügen, der das AVIF Baseline Profile unterstützt.
- [5.1/H-1-18] MUSS den AV1-Encoder unterstützen, der eine Auflösung von bis zu 480p bei 30 Bildern pro Sekunde und 1 Mbit/s kodieren kann.
-
[5.12/H-1-1] MUSS[5.12/H-SR] dringend empfohlen werden, um die FunktionFeature_HdrEditing
für alle auf dem Gerät vorhandenen Hardware-AV1- und HEVC-Encoder zu unterstützen. - [5.12/H-1-2] MUSS das Farbformat RGBA_1010102 für alle auf dem Gerät vorhandenen Hardware-AV1- und HEVC-Encoder unterstützen.
- [5.12/H-1-3] MUSS Unterstützung für die Erweiterung EXT_YUV_target ankündigen, um YUV-Texturen in 8 und 10 Bit abzutasten.
- [7.1.4/H-1-1] MÜSSEN mindestens 6 Hardware-Overlays im Hardware Composer (HWC) der Datenverarbeitungseinheit (DPU) haben, von denen mindestens 2 10-Bit-Videoinhalte anzeigen können.
Wenn Handheld-Geräteimplementierungen android.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben und Unterstützung für einen Hardware-AVC- oder HEVC-Encoder enthalten, dann gilt Folgendes:
- [5.2/H-2-1] MUSS das Mindestqualitätsziel erfüllen, das durch die Video-Encoder-Raten-Verzerrungskurven für Hardware-AVC- und HEVC-Codecs definiert wird, wie in der kommenden Dokumentation definiert.
Siehe Überarbeitung
android.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, dann:- [ 7.5 /H-1-1] MUSS über eine primäre nach hinten gerichtete Kamera mit einer Auflösung von mindestens 12 Megapixeln verfügen, die Videoaufnahme mit 4K bei 30 Bildern pro Sekunde unterstützt. Die primäre nach hinten gerichtete Kamera ist die nach hinten gerichtete Kamera mit der niedrigsten Kamera-ID.
- [ 7.5 /H-1-2] MUSS über eine primäre Frontkamera mit einer Auflösung von mindestens 6 Megapixeln verfügen und die Videoaufnahme mit 1080p bei 30 Bildern pro Sekunde unterstützen. Die primäre Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
- [ 7.5 /H-1-3] MUSS die Eigenschaft
android.info.supportedHardwareLevel
als FULL oder besser für beide Primärkameras unterstützen. - [ 7.5 /H-1-4] MUSS
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
für beide Primärkameras unterstützen. - [ 7.5 /H-1-5] MUSS eine JPEG-Aufnahmelatenz von Kamera2 < 1000
900ms für eine Auflösung von 1080p haben, gemessen durch den CTS-Kamera-PerformanceTest unter ITS-Lichtbedingungen (3000 K) für beide Primärkameras. - [ 7.5 /H-1-6] MUSS eine Startlatenz von Kamera2 (geöffnete Kamera bis zum ersten Vorschaubild) von < 500 ms haben, gemessen durch den CTS-Kamera-PerformanceTest unter ITS-Lichtbedingungen (3000 K) für beide Primärkameras.
- [ 7.5 /H-1-8] MUSS
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
undandroid.graphics.ImageFormat.RAW_SENSOR
für die primäre Rückkamera unterstützen. - [ 7.5 /H-1-9] MUSS über eine nach hinten gerichtete Hauptkamera verfügen, die 720p oder 1080p bei 240fps unterstützt.
- [ 7.5 /H-1-10] MUSS ein minimales ZOOM_RATIO < 1,0 für die Primärkameras haben, wenn eine Ultrawide-RGB-Kamera in die gleiche Richtung zeigt.
- [ 7.5 /H-1-11] MUSS gleichzeitiges Front-Back-Streaming auf Primärkameras implementieren.
- [ 7.5 /H-1-12] MUSS
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
sowohl für die primäre vordere als auch die primäre hintere Kamera unterstützen. - [ 7.5 /H-1-13] MUSS
LOGICAL_MULTI_CAMERA
Funktion für die Primärkameras unterstützen, wenn mehr als eine RGB-Kamera in die gleiche Richtung zeigt. - [ 7.5 /H-1-14] MUSS
STREAM_USE_CASE
Funktion sowohl für die primäre vordere als auch die primäre hintere Kamera unterstützen. - [ 7.5 /H-1-15] MUSS
Bokeh- undNachtmodus-Erweiterungen über die CameraX- und Camera2-Erweiterungen für Primärkameras unterstützen. - [ 7.5 /H-1-16] MUSS die DYNAMIC_RANGE_TEN_BIT-Fähigkeit für die primären Kameras unterstützen.
- [ 7.5 /H-1-17] MUSS CONTROL_SCENE_MODE_FACE_PRIORITY und Gesichtserkennung ( STATISTICS_FACE_DETECT_MODE_SIMPLE oder STATISTICS_FACE_DETECT_MODE_FULL ) für die primären Kameras unterstützen.
Siehe Überarbeitung
android.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, dann:- [7.1.1.1/H-2-1] MUSS eine Bildschirmauflösung von mindestens 1080p haben.
- [7.1.1.3/H-2-1] MUSS eine Bildschirmdichte von mindestens 400 dpi haben.
- [7.1.1.3/H-3-1] MUSS über ein HDR-Display verfügen, das mindestens 1000 Nits durchschnittlich unterstützt.
- [7.6.1/H-2-1] MUSS über mindestens 8 GB physischen Speicher verfügen.
Siehe Überarbeitung
android.os.Build.VERSION_CODES.U
für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
zurückgeben, dann:- [8.2/H-1-1] MUSS eine sequentielle Schreibleistung von mindestens 150 MB/s gewährleisten.
- [8.2/H-1-2] MUSS eine zufällige Schreibleistung von mindestens 10 MB/s gewährleisten.
- [8.2/H-1-3] MUSS eine sequentielle Leseleistung von mindestens 250 MB/s gewährleisten.
- [8.2/H-1-4] MUSS eine zufällige Leseleistung von mindestens 100 MB/s gewährleisten.
- [8.2/H-1-5] MUSS eine parallele sequentielle Lese- und Schreibleistung mit 2x Lese- und 1x Schreibleistung von mindestens 50 MB/s gewährleisten.
Siehe Überarbeitung
Implementierungen von Fernsehgeräten MÜSSEN die folgenden Videokodierungsformate unterstützen und sie für Anwendungen von Drittanbietern verfügbar machen:
- [ 5.2 /T-0-3] AV1
Implementierungen von Fernsehgeräten MÜSSEN die folgenden Videodekodierungsformate unterstützen und sie für Anwendungen von Drittanbietern verfügbar machen:
- [ 5.3.2 /T-0-7] AV1
Siehe Überarbeitung
Wenn Geräteimplementierungen über einen sicheren Sperrbildschirm verfügen und einen oder mehrere Trust Agents enthalten, die die TrustAgentService
System-API implementieren, gilt Folgendes:
- [ 9.11.1 /W-1-1] MUSS den Benutzer häufiger als einmal alle 72 Stunden nach einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) fragen.
Siehe Überarbeitung
Wenn Geräteimplementierungen Unterstützung für AM/FM-Rundfunk beinhalten und die Funktionalität für jede Anwendung verfügbar machen, gilt Folgendes:
- [ 7.4
.10/A-0-1] MUSS Unterstützung fürFEATURE_BROADCAST_RADIO
deklarieren.
Eine Außenkamera ist eine Kamera, die Szenen außerhalb der Geräteimplementierung aufnimmt, wie die Rückfahrkamera.
Implementierungen von Automobilgeräten:
- SOLLTE eine oder mehrere Außenkameras enthalten.
Wenn Automotive-Geräteimplementierungen eine Außenansichtskamera umfassen, gilt für eine solche Kamera Folgendes:
- [ 7.5 /A-1-1] DÜRFEN KEINE Außenkameras haben, auf die über die Android-Kamera-APIs zugegriffen werden kann, es sei denn, sie erfüllen die Kernanforderungen der Kamera.
- [ 7.5 /A-SR-1] Es wird DRINGEND EMPFOHLEN, die Kameravorschau nicht zu drehen oder horizontal zu spiegeln.
- [ 7.5 /A-SR-2] Es wird DRINGEND EMPFOHLEN, dass die Auflösung mindestens 1,3 Megapixel beträgt.
- SOLLTE entweder über Hardware mit festem Fokus oder EDOF (erweiterte Tiefenschärfe) verfügen.
- Möglicherweise ist im Kameratreiber entweder Hardware-Autofokus oder Software-Autofokus implementiert.
Wenn die Implementierung von Automobilgeräten eine oder mehrere Außenkameras umfasst und den Dienst „Exterieur View System“ (EVS) lädt, 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 API von NFCAdapter.Action_Transaction_deted Intent implementieren (als "evt_transaction" definiert durch die technische Spezifikation der GSM-Vereinigung Ts.26-NFC-Mobilteilanforderungen) .
3.3.1. Anwendung Binäre Schnittstellen :
Siehe Revision
Geräteimplementierungen:
- [C-0-12] MUST export function symbols for the core
Vulkan 1.0Vulkan 1.1 function symbols, as well as theVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
, andVK_KHR_get_physical_device_properties2
extensions through thelibvulkan.so
library. Beachten Sie, dass zwar alle Symbole vorhanden sein müssen, in Abschnitt 7.1.4.2 detaillierter die Anforderungen für die vollständige Implementierung jeder entsprechenden Funktionen erwartet werden.
- [C-0-12] MUST export function symbols for the core
Siehe Revision
Wenn Geräteimplementierungen einen Bildschirm oder eine Videoausgabe enthalten, sind sie:
-
MONOCHROMATIC
C-1-5SPRITZ
Muss dynamische Farbtonalpaletten unterFRUIT_SALAD
EXPRESSIVE
android.theme.customization.theme_styles
erzeugen,RAINBOW
in denSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
aufgezähltTONAL_SPOT
VIBRANT
.
-
3.8.8. Aktivitätsumschaltung :
Siehe Revision
Wenn Geräteimplementierungen einschließlich des in Abschnitt 7.2.3 beschriebenen Navigationsschlüssels der Recents -Funktion die Schnittstelle verändern, dann:
- [C-1-2] muss das Bildschirm-Pining-Verhalten implementieren und dem Benutzer ein Einstellungsmenü zur Verfügung stellen, um die Funktion umzuschalten.
3.9.2 Managed Profile Support :
Siehe Revision
Wenn Geräteimplementierungen
android.software.managed_users
deklarieren, sind sie:- [C-1-10] muss sicherstellen, dass die Screenshot-Daten im Speicher des Arbeitsprofils gespeichert werden, wenn ein Screenshot mit einem
topActivity
Fenster erfasst wird, das sich konzentriert (der Benutzer, mit dem der Benutzer unter allen Aktivitäten interagiert) und gehört zu einem Arbeitsprofil an App . - [C-1-11] dürfen keinen anderen Bildschirminhalt (Systemleiste, Benachrichtigungen oder persönliche Profilinhalte) erfassen, außer für das Fenster/Fenster des Arbeitsprofils beim Speichern eines Screenshots für das Arbeitsprofil (um sicherzustellen, dass persönliche Profildaten sind nicht im Arbeitsprofil gespeichert).
- [C-1-10] muss sicherstellen, dass die Screenshot-Daten im Speicher des Arbeitsprofils gespeichert werden, wenn ein Screenshot mit einem
3.9.5 Richtlinienrahmen für Geräterichtlinien : neuer Abschnitt
Siehe Revision
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 Revision
Geräteimplementierungen müssen die Codierung der folgenden Bildcodierung unterstützen:
- [C-0-4] AVIF
- Geräte müssen
BITRATE_MODE_CQ
und Basisprofil unterstützen.
- Geräte müssen
- [C-0-4] AVIF
Siehe Revision
Geräteimplementierungen müssen die Dekodierung der folgenden Bildcodierung unterstützen:
[C-0-7] AVIF (Basisprofil)
Siehe Revision
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, Bildsammlung, Bildsequenz Heif (.heif), heic (.heic) AVIF (Basisprofil) Bild, Bildsammlung, Bildsequenz -Basisprofil Heif Container (.avif) Siehe Revision
Format/Codec Einzelheiten Dateitypen/Containerformate, die unterstützt werden sollen H.263 - 3GPP (.3gp)
- MPEG-4 (.MP4)
- Matroska (.mkv, nur dekodieren)
H.264 AVC Weitere Informationen finden Sie in Abschnitt 5.2 und 5.3 - 3GPP (.3gp)
- MPEG-4 (.MP4)
- Mpeg-2 ts (.ts, nicht suchbar)
- Matroska (.mkv, nur 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 suchbar)
- Mpeg-4 (.mp4, nur decodieren)
- Matroska (.mkv, nur dekodieren)
MPEG-4 sp - 3GPP (.3gp)
- MPEG-4 (.MP4)
- Matroska (.mkv, nur dekodieren)
VP8 Weitere Informationen finden Sie in Abschnitt 5.2 und 5.3 - Webm (.webm)
- Matroska (.mkv)
VP9 Weitere Informationen finden Sie in Abschnitt 5.3 - Webm (.webm)
- Matroska (.mkv)
AV1 Weitere Informationen finden Sie in Abschnitt 5.2 und Abschnitt 5.3 - MPEG-4 (.MP4)
- Matroska (.mkv, nur dekodieren)
5.1.10. Medien -Codec -Charakterisierung :
Siehe Revision
Wenn Geräteimplementierungen Video -Codecs unterstützen:
- [C-2-1] Alle Video-Codecs müssen erreichbare Bildrate-Daten für die folgenden Größen veröffentlichen, wenn sie vom Codec unterstützt werden:
SD (geringer Qualität) SD (hohe Qualität) HD 720p HD 1080p UHD Video Auflösung - 176 x 144 PX (H263, MPEG2, MPEG4)
- 352 x 288 PX (MPEG4 -Encoder, H263, MPEG2)
- 320 x 180 PX (VP8, VP8)
- 320 x 240 px (andere)
- 704 x 576 PX (H263)
- 640 x 360 PX (VP8, VP9)
- 640 x 480 PX (MPEG4 -Encoder)
- 720 x 480 px (andere, AV1 )
- 1408 x 1152 PX (H263)
- 1280 x 720 PX (andere, AV1 )
1920 x 1080 PX (außer MPEG4, AV1 ) 3840 x 2160 PX (HEVC, VP9, AV1 ) Siehe Revision
Wenn Geräteimplementierungen einen Video-Encoder unterstützen und Apps von Drittanbietern zur Verfügung stellen, dann:- Sollte nicht über zwei Schiebefenster sein, mehr als 15% über der Bitrate zwischen Intraframe (I-Frame) Intervallen.
- Sollte nicht mehr als 100% über dem Bitrate über einem Gleitfenster von 1 Sekunde sein.
Wenn Geräteimplementierungen einen Video-Encoder unterstützen und Apps von Drittanbietern zur Verfügung stellen und die festlegen
MediaFormat.KEY_BITRATE_MODE
anBITRATE_MODE_VBR
so, dass der Encoder im variablen Bitrate -Modus arbeitet, so lange, wie es sich nicht auf den minimalen Qualitätsboden auswirkt, ist das codierte Bitrate:-
[C-5-1] solltenicht über ein Gleitfenster sein, mehr als 15% über der Bitrate zwischen Intraframe (I-Frame) Intervallen. -
[C-5-2] dürfenüber einem Gleitfenster von 1 Sekunde nicht mehr als 100% über dem Bitrate sein.
Wenn Geräteimplementierungen einen Video-Encoder unterstützen und Apps von Drittanbietern zur Verfügung stellen und die
MediaFormat.KEY_BITRATE_MODE
aufBITRATE_MODE_CBR
einstellen, sodass der Encoder im konstanten Bitrate-Modus arbeitet, dann der codierte Bitrate:-
[C-6-1] muss[C-SR-2] dringend empfohlen werden, nicht mehr als 15% gegenüber dem Zielbitrate über einem Schiebungsfenster von 1 Sekunde zu sein.
Siehe Revision
Wenn Geräteimplementierungen H.263-Encoder unterstützen und es für Apps von Drittanbietern zur Verfügung stellen, dann:
- [C-1-1] muss die QCIF-Auflösung (176 x 144) unter Verwendung der Basisprofilebene 45 unterstützen . Die SQCIF-Auflösung ist optional.
-
Sollte dynamisch konfigurierbare Bitrate für den unterstützten Encoder unterstützen.
Siehe Revision
Wenn Geräteimplementierungen H.265 Codec unterstützen, sind sie:
- [C-1-1] muss die Hauptprofilstufe 3 bis zu 512 x 512 Auflösung unterstützen.
-
Sollte die HD -Codierungsprofile unterstützen, wie in der folgenden Tabelle angegeben. - [C-SR-1] werden dringend empfohlen, um das 720 x 480 SD-Profil und die HD-Codierungsprofile zu unterstützen, wie in der folgenden Tabelle angegeben, wenn ein Hardware-Encoder vorliegt.
5.2.6. AV1 : neuer Abschnitt
Siehe Revision
Wenn Geräteimplementierungen AV1 Codec unterstützen, dann:
- [C-1-1] muss das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalten unterstützen.
[C-1-2] Muss Leistungsdaten veröffentlichen, dh die Leistungsdaten über die
getSupportedFrameRatesFor()
odergetSupportedPerformancePoints()
-APIs für unterstützte Auflösungen in der folgenden Tabelle veröffentlichen.[C-1-3] muss HDR-Metadaten akzeptieren und an den Bitstream ausgeben
Wenn AV1 -Encoder hardware beschleunigt ist, dann: dann:
- [C-2-1] muss bis hin zu HD1080P-Codierungsprofilen aus der folgenden Tabelle unterstützen:
SD HD 720p HD 1080p UHD Video Auflösung 720 x 480 px 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 Revision
Wenn Geräteimplementierungen H.263 -Decoder unterstützen, dann:
- [C-1-1] muss die Baseline-Profilstufe 30 (CIF-, QCIF- und SQCIF-Auflösungen @ 30fps 384Kbit / s) und Stufe 45 (QCIF- und SQCIF-Auflösungen @ 30fps 128Kbit / s) unterstützen.
Siehe Revision
Wenn Geräteimplementierungen AV1 -Codec unterstützen, sind sie:- [C-1-1] muss Profil 0 einschließlich 10-Bit-Inhalten unterstützen.
Wenn Geräteimplementierungen AV1-Codec unterstützen und sie für Anwendungen von Drittanbietern zur Verfügung stellen, dann:
- [C-1-1] muss das Hauptprofil einschließlich 8-Bit- und 10-Bit-Inhalten unterstützen.
Wenn Geräteimplementierungen AV1 Codec mit einem beschleunigten Hardware -Decoder unterstützen, dann:
- [C-2-1] muss in der Lage sein, mindestens HD 720p-Video-Dekodierungsprofile aus der folgenden Tabelle zu dekodieren, wenn die von Anzeige gemeldete
Display.getSupportedModes()
-Methode gleich oder größer als 720p ist. - [C-2-2] muss in der Lage sein, mindestens HD 1080p-Video-Dekodierungsprofile aus der folgenden Tabelle zu dekodieren, wenn die durch Anzeige gemeldete
Display.getSupportedModes()
-Methode gleich oder größer als 1080p ist.
SD HD 720p HD 1080p UHD Video Auflösung 720 x 480 px 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 das HDR -Profil über die Medien -APIs unterstützen, dann: dann:
- [C-3-1] muss das Extrahieren und Ausgang von HDR-Metadaten aus Bitstream und/oder Behälter unterstützen.
- [C-3-2] muss den HDR-Inhalt auf dem Gerätebildschirm oder auf einem Standard-Videoausgangsport (z. B. HDMI) ordnungsgemäß anzeigen.
5.4.2. Erfassung für die Spracherkennung :
Siehe Revision
Wenn Geräteimplementierungen
android.hardware.microphone
deklarieren, sind sie:- Sollte die Empfindlichkeit der Audioeingangsempfindlichkeit so einstellen, dass eine 1000
-Hz3530 für 16 -Bit -Samples (oder -22,35 dB ± 3 dB Full Skala für schwimmende Punkt-/Doppel -Präzisions -Proben) für jedes Mikrofon, mit dem die Audioquelle der Spracherkennung aufgezeichnet wird.
- Sollte die Empfindlichkeit der Audioeingangsempfindlichkeit so einstellen, dass eine 1000
Siehe Revision
Wenn Geräteimplementierungen die Funktion
android.hardware.audio.output
deklarieren, sind sie:- [C-1-4] muss Audioeffekte mit Floating-Punkt-Eingang und -ausgang 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.Neue Anforderungen starten
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.
Neue Anforderungen starten
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.
Neue Anforderungen starten
- 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.
[
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-SR-17] werden dringend empfohlen, die neuen AIDL-Schnittstellen
IFingerprint.aidl
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-2] werden dringend empfohlen, den RX-Offset zu messen und auszugleichen, um
ADVERTISE_TX_POWER_HIGH
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-2] werden dringend empfohlen, den RX-Offset zu messen und auszugleichen, um
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 in der gleichen Richtung wird dringend empfohlen, ein logisches Kamera-Gerät zu unterstützen, das die
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
auflistet. Als physische Unterverfassungen.
- [C-SR-1] Für Geräte mit mehreren RGB-Kameras in unmittelbarer Nähe und in der gleichen Richtung wird dringend empfohlen, ein logisches Kamera-Gerät zu unterstützen, das die
Siehe Revision
Geräte, die alle folgenden Kriterien erfüllen, sind von der obigen Anforderung ausgenommen:
- Geräteimplementierungen, die nicht vom Benutzer gedreht werden können, z. B. Automobilgeräte.
Siehe Revision
Geräte, die als Handheld oder abgenutzt sind, können einen allgemeinen haptischen Aktuator für den haptischen Aktuator umfassen, der Anwendungen für Zwecke zur Verfügung steht, einschließlich Klingeltöne, Alarme, Benachrichtigungen sowie allgemeines Berührungsfeedback.
Wenn Geräteimplementierungen keinen solchen allgemeinen haptischen Aktuator enthalten, sind sie:
- [7.10/c] muss für
Vibrator.hasVibrator()
.
Wenn Geräteimplementierungen mindestens einen solchen allgemeinen haptischen Aktuator enthalten, sind sie:
- [C-1-1] muss für
Vibrator.hasVibrator()
true zurückkehren. - Sollte keine exzentrische rotierende Masse (ERM) Haptic Actuator (Vibrator) verwenden.
- Sollte alle öffentlichen Konstanten für klare Haptik in
android.view.HapticFeedbackConstants
implementieren (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
GESTURE_END
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 Primitiven wieLOW_TICK
undSPIN
können nur machbar sein, 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. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionService
they:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATION
as the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
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] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagMode
manifest option:- heap buffer overflow
- use after free
- double free
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported
.
If device implementations set the system property
ro.arm64.memtag.bootctl_supported
to true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctl
to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag
: a Memory Safety technology as defined above is enabled -
memtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off
: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl
.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl
.[C-3-4] MUST set
arm64.memtag.bootctl
to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag
.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()
with theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillService
to the system. - Any screen or other data accessible via
Content Capture
API. - Any screen or other data accessible via
FieldClassificationService
API - Any application data passed to the system via the
AppSearchManager
API and accessible viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
API a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()
by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord
,SoundTrigger
or other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . 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 asRAPPOR
).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is shared. Unless such functionality is built as an Android SDK API (AmbientContext
,HotwordDetectionService
).[C-1-6] MUST provide user affordance to erase such data that the
implementation or the proprietary means collectsContentCaptureService
ifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()
provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephony
feature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONY
MUST contain at least the following information:-
SubscriptionManagerService
dump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. 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 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 . Device implementations:
- [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
Device implementations:
- [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.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentService
System API, they:[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