Änderungsprotokoll des Android-Kompatibilitätsdefinitionsdokuments

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Android 13

19. Oktober 2022

2. Gerätetypen

  • 2.2.3 Software

    Siehe Überarbeitung

    Wenn Handheld-Geräteimplementierungen nicht im Lock-Task-Modus ausgeführt werden, gilt Folgendes, wenn Inhalte in die Zwischenablage kopiert werden:

    • [3.8.17/H-1-1] MUSS dem Benutzer eine Bestätigung präsentieren, dass Daten in die Zwischenablage kopiert wurden (z. B. ein Miniaturbild oder eine Warnung „Inhalt kopiert“). Geben Sie hier außerdem an, ob Daten aus der Zwischenablage geräteübergreifend synchronisiert werden.

3. Software

  • 3.2.3.5. Bedingte Anwendungsabsichten

    Siehe Überarbeitung

    Wenn die Anwendung „Einstellungen“ der Geräteimplementierung eine geteilte Funktionalität implementiert, die Aktivitätseinbettung verwendet, dann:

    Wenn Geräteimplementierungen den VoiceInteractionService unterstützen und mehr als eine Anwendung, die diese API verwendet, gleichzeitig installiert sind, gilt Folgendes:

  • 3.4.1 Webview-Kompatibilität

    Siehe Überarbeitung

    • [C-1-4] MUSS den bereitgestellten Inhalt oder Remote-URL-Inhalt in einem Prozess rendern, der sich von der Anwendung unterscheidet, die die WebView instanziiert. Insbesondere der separate Renderer-Prozess MUSS über niedrigere Berechtigungen verfügen, als separate Benutzer-ID ausgeführt werden, keinen Zugriff auf das Datenverzeichnis der App haben, keinen direkten Netzwerkzugriff haben und nur Zugriff auf die mindestens erforderlichen Systemdienste über Binder haben. Die AOSP-Implementierung von WebView erfüllt diese Anforderung.

7. Hardwarekompatibilität

  • 7.4.2 IEEE 802.11 (WLAN)

    Siehe Überarbeitung

    Wenn Geräteimplementierungen Unterstützung für den Wi-Fi-Energiesparmodus enthalten, wie im IEEE 802.11-Standard definiert, sie:

  • 7.4.3 Bluetooth

    Siehe Überarbeitung

    Wenn Geräteimplementierungen Unterstützung für Bluetooth Low Energy (BLE) beinhalten, dann:

    • [C-3-5] MUSS ein Timeout für auflösbare Privatadressen (RPA) von nicht mehr als 15 Minuten implementieren und die Adresse beim Timeout rotieren, um die Privatsphäre der Benutzer zu schützen , wenn das Gerät BLE aktiv zum Scannen oder für Werbung verwendet. Um Timing-Angriffe zu verhindern, MÜSSEN auch Timeout-Intervalle zufällig zwischen 5 und 15 Minuten gewählt werden.

  • 7.5.5 Kameraausrichtung

    Siehe Überarbeitung

    Wenn Geräteimplementierungen über eine nach vorne oder hinten gerichtete Kamera verfügen, gilt für diese Kamera(s):

    • [C-1-1] MUSS so ausgerichtet sein, dass die Längsabmessung der Kamera mit der Längsabmessung des Bildschirms übereinstimmt. Das heißt, wenn das Gerät im Querformat gehalten wird, MÜSSEN Kameras Bilder im Querformat aufnehmen. Dies gilt unabhängig von der natürlichen Ausrichtung des Geräts; das heißt, es gilt sowohl für primäre Geräte im Querformat als auch für primäre Geräte im Hochformat.

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

    • Das Gerät implementiert Bildschirme mit variabler Geometrie, wie z. B. faltbare oder klappbare Displays.
    • Wenn sich der Klapp- oder Scharnierzustand des Geräts ändert, wechselt das Gerät zwischen der primären Hochformat- und der primären Querformatausrichtung (oder umgekehrt).

9. Kompatibilität des Sicherheitsmodells

  • 9.11 Schlüssel und Anmeldedaten

    Siehe Überarbeitung

    Wenn die Geräteimplementierung einen sicheren Sperrbildschirm unterstützt, geschieht Folgendes:

    • [C-1-6] MUSS IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice Version 1 oder IKeyMintDevice Version 2 unterstützen.

  • 9.17 Android-Virtualisierungsframework

    Siehe Überarbeitung

    Wenn das Gerät Unterstützung für die APIs des Android Virtualization Framework ( android.system.virtualmachine.* ) implementiert, führt der Android-Host Folgendes aus:

    • [C-1-3] DÜRFEN die Neverallow-Regeln in der System-/Se-Richtlinie, die im Upstream-Android Open Source Project (AOSP) bereitgestellt wird, NICHT ändern, weglassen oder ersetzen, und die Richtlinie MUSS mit allen vorhandenen Neverallow-Regeln kompiliert werden.

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

    • [C-2-4] DÜRFEN die Neverallow-Regeln in System/Sepolicy/Microdroid, die im Upstream-Android-Open-Source-Projekt (AOSP) bereitgestellt werden, NICHT ändern, auslassen oder ersetzen.

    Wenn das Gerät Unterstützung für die APIs des Android Virtualization Framework implementiert, dann für die Schlüsselverwaltung:

    • [C-6-2] MUSS WÜRFEL korrekt ausführen, dh die korrekten Werte liefern. Aber es muss vielleicht nicht so detailliert sein.

15. August 2022

2. Gerätetypen

  • 2.2.1 Hardware : Änderungen an den Hardwareanforderungen wie folgt.

    • Eingabegeräte:

      Siehe Überarbeitung

      Implementierungen von Handheld-Geräten:

      • [ 7.2.3 /H-0-5] MUSS OnBackInvokedCallback.onBackStarted() für das aktuell fokussierte Fenster aufrufen, wenn die Zurück-Geste beginnt oder die Zurück-Schaltfläche ( KEYCODE_BACK ) NACH UNTEN gedrückt wird.
      • [ 7.2.3 /H-0-6] MUSS OnBackInvokedCallback.onBackInvoked() aufrufen, wenn die Zurück-Geste festgeschrieben oder die Zurück-Schaltfläche losgelassen wird (UP).
      • [ 7.2.3 /H-0-7] MUSS OnBackInvokedCallback.onBackCancelled() aufrufen, wenn die Zurück-Geste nicht festgeschrieben oder das KEYCODE_BACK Ereignis abgebrochen wird.

      Wenn Geräte das WiFi Neighbor Awareness Networking (NAN)-Protokoll durch Deklaration von PackageManager.FEATURE_WIFI_AWARE und Wi-Fi Location (Wi-Fi Round Trip Time – RTT) durch Deklaration von PackageManager.FEATURE_WIFI_RTT unterstützen, dann:

      • [ 7.4.2.5/H-1-1 ] MUSS die Reichweite innerhalb von +/-1 Meter bei 160 MHz Bandbreite beim 68. Perzentil (wie mit der kumulativen Verteilungsfunktion berechnet) genau melden, +/-2 Meter bei 80 MHz Bandbreite beim 68. Perzentil, +/-4 Meter bei 40 MHz Bandbreite beim 68. Perzentil und +/-8 Meter bei 20 MHz Bandbreite beim 68. Perzentil bei Abständen von 10 cm, 1 m, 3 m und 5 m, wie beobachtet über die WifiRttManager#startRanging Android API .

      • [ 7.4.2.5/H-SR ] wird DRINGEND EMPFOHLEN, die Reichweite auf +/-1 Meter bei 160 MHz Bandbreite beim 90. Perzentil (wie mit der kumulativen Verteilungsfunktion berechnet) genau zu melden, +/-2 Meter bei 80 MHz Bandbreite beim 90. Perzentil, +/-4 Meter bei 40 MHz Bandbreite beim 90. Perzentil und +/-8 Meter bei 20 MHz Bandbreite beim 90. Perzentil bei Entfernungen von 10 cm, wie über die WifiRttManager#startRanging Android API beobachtet.

      Es wird DRINGEND EMPFOHLEN, die Schritte zur Einrichtung der Messung zu befolgen, die in Voraussetzungen für die Anwesenheitskalibrierung angegeben sind.

    • Audiolatenz:

      Siehe Überarbeitung

      Wenn Handheld-Geräteimplementierungen android.hardware.audio.output und android.hardware.microphone deklarieren, dann:

      • [ 5.6 /H-1-1] MUSS eine mittlere kontinuierliche Round-Trip-Latenz von 500 haben 800 Millisekunden oder weniger über 5 Messungen mit einer mittleren absoluten Abweichung von weniger als 50 100 ms über folgende Datenpfade: „Lautsprecher zu Mikrofon“, 3,5-mm-Loopback-Adapter (falls unterstützt), USB-Loopback (falls unterstützt). mindestens ein unterstützter Pfad.

      • [ 5.6 /H-1-1] MUSS eine durchschnittliche Tap-to-Tone-Latenz von 500 Millisekunden oder weniger über mindestens 5 Messungen über den Datenpfad vom Lautsprecher zum Mikrofon aufweisen.

    • Haptische Eingaben:

      Siehe Überarbeitung

      Wenn Implementierungen von Handgeräten mindestens einen haptischen Aktuator umfassen, dann:

      • [ 7.10 /H]* SOLLTE KEINEN haptischen Aktuator (Vibrator) mit exzentrischer rotierender Masse (ERM) verwenden.
      • [ 7.10 /H]* SOLLTE den Betätiger 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]* SOLLTEN alle öffentlichen Konstanten für klare Haptik in android.view implementieren. HapticFeedbackConstants nämlich (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START und GESTURE_END).
      • [ 7.10 /H]* SOLLTE nämlich alle öffentlichen Konstanten für klare Haptik in android.os.VibrationEffect implementieren (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK und EFFECT_DOUBLE_CLICK) und alle möglichen öffentlichen PRIMITIVE_* Konstanten für reichhaltige Haptik in android.os.VibrationEffect.Composition nämlich (PRIMITIVE_CLICK und PRIMITIVE_TICK) (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, DREHEN, THUD). Einige dieser Primitive, wie etwa LOW_TICK und SPIN, sind möglicherweise nur durchführbar, wenn der Vibrator relativ niedrige Frequenzen unterstützen kann.

      Wenn Implementierungen von Handgeräten mindestens einen linearen Resonanzaktuator enthalten, dann:

      • [ 7.10 /H]* SOLLTE den haptischen Aktuator in der X-Achse (links-rechts) der Hochformatausrichtung bewegen.

      • [ 7.10 /H]* SOLLTE die Fallback-Konfiguration für nicht unterstützte Primitive überprüfen und bei Bedarf aktualisieren, wie in der Implementierungsanleitung für Konstanten beschrieben.

      • [7.10/H]* SOLLTE Fallback-Unterstützung bieten, um das Ausfallrisiko wie hier beschrieben zu mindern.

  • 2.2.3 Software :

    • Auth Trivial Device Controls:

      Siehe Überarbeitung

      • [ 3.8 .16/H-1-5] MUSS dem Benutzer die Möglichkeit geben, sich von den als auth-trivial bezeichneten Steuerelementen für authtriviale Geräte von den Steuerelementen abzumelden, die von den Drittanbieteranwendungen über den ControlsProviderService und die Control Control.isAuthRequired -API registriert wurden.

    • MediaStyle-Benachrichtigungen:

      Siehe Überarbeitung

      Wenn Handheld-Geräteimplementierungen MediaStyle-Benachrichtigungen unterstützen, dann:

      • [3.8.3.1/H-1-SR] Es wird DRINGEND EMPFOHLEN, ein Benutzerangebot (z. B. „Ausgangsumschalter“) bereitzustellen, auf das über die System-UI zugegriffen wird, das es Benutzern ermöglicht, zwischen geeigneten verfügbaren Medienrouten zu wechseln (z. B. Bluetooth-Geräte und Routen, die MediaRouter2Manager bereitgestellt werden). wenn eine App eine MediaStyle-Benachrichtigung mit einem MediaSession-Token sendet.

  • 2.2.4 Leistung und Leistung : Neue Anforderung für Apps, die Vordergrunddienste ausführen.

    Siehe Überarbeitung

    Implementierungen von Handheld-Geräten:

    • [ 8.5 /H-0-1] MUSS einem Benutzer im Einstellungsmenü die Möglichkeit bieten, eine App zu stoppen, die einen Vordergrunddienst ausführt, und alle Apps mit aktiven Vordergrunddiensten sowie die Dauer jedes dieser Dienste seither anzuzeigen wie im SDK-Dokument beschrieben gestartet.
      • Einige Apps KÖNNEN davon ausgenommen sein, angehalten oder in einem solchen Benutzerangebot aufgeführt zu werden, wie im SDK-Dokument beschrieben.

  • 2.2.7.1 Medien : Aktualisierungen des Abschnitts Medienanforderungen für Handhelds wie folgt:

    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:

    • [5.1/H-1-1] MUSS über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() die maximale Anzahl von Hardware-Videodecoder-Sitzungen ankündigen, die gleichzeitig in einer beliebigen Codec-Kombination ausgeführt werden können.
    • [5.1/H-1-2] MUSS 6 Instanzen von Hardware-Videodecodersitzungen (AVC, HEVC, VP9, ​​AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt werden.
    • [5.1/H-1-3] MUSS die maximale Anzahl von Hardware-Video-Encoder-Sitzungen ankündigen, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() ausgeführt werden können.
    • [5.1/H-1-4] MUSS 6 Instanzen von Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, ​​AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt werden.
    • [5.1/H-1-5] MUSS die maximale Anzahl von Hardware-Video-Encoder- und -Decoder-Sitzungen ankündigen, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() ausgeführt werden können.
    • [5.1/H-1-6] MUSS 6 Instanzen von Sitzungen mit Hardware-Videodecoder und Hardware-Videoencoder (AVC, HEVC, VP9, ​​AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt werden.
    • [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. Das Laden ist hier definiert als eine gleichzeitige 1080p-zu-720p-Nur-Video-Transcodierungssitzung unter Verwendung von Hardware-Video-Codecs zusammen mit der 1080p-Audio-Video-Aufzeichnungsinitialisierung.
    • [5.1/H-1-8] MUSS eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiokodierungssitzung mit 128 kbps oder niedrigerer Bitrate für alle Audiokodierer unter Last haben. Das Laden ist hier definiert als eine gleichzeitige 1080p-zu-720p-Nur-Video-Transcodierungssitzung unter Verwendung von Hardware-Video-Codecs zusammen mit der 1080p-Audio-Video-Aufzeichnungsinitialisierung.
    • [5.1/H-1-9] MUSS 2 Instanzen sicherer Hardware-Videodecodersitzungen (AVC, HEVC, VP9, ​​AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt werden.
    • [5.1/H-1-10] MUSS 3 Instanzen nicht sicherer Hardware-Videodecodersitzungen zusammen mit 1 Instanz sicherer Hardware-Videodecodersitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, ​​AV1 oder höher) in einem beliebigen Codec unterstützen Kombination, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt wird.
    • [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 Videodecoder-Initialisierungslatenz von 40 ms oder weniger haben.
    • [5.1/H-1-13] MUSS eine Audiodecoder-Initialisierungslatenz von 30 ms oder weniger haben.
    • [5.1/H-1-14] MUSS AV1-Hardwaredecoder Main 10, Level 4.1 unterstützen.
    • [5.1/H-SR] werden dringend empfohlen, um Film Grain für AV1-Hardware-Decoder zu unterstützen.
    • [5.1/H-1-15] MUSS mindestens 1 Hardware-Videodecoder haben, der 4K60 unterstützt.
    • [5.1/H-1-16] MUSS mindestens 1 Hardware-Videoencoder haben, der 4K60 unterstützt.
    • [5.3/H-1-1] DARF NICHT mehr als 1 Frame in 10 Sekunden (dh weniger als 0,167 Prozent Frame-Drop) für eine 1080p-60-fps-Videositzung unter Last verlieren. Laden ist definiert als eine gleichzeitige 1080p- bis 720p-Nur-Video-Transcodierungssitzung mit Hardware-Video-Codecs sowie eine 128-kbps-AAC-Audiowiedergabe.
    • [5.3/H-1-2] DÜRFEN NICHT mehr als 1 Frame in 10 Sekunden während einer Änderung der Videoauflösung in einer 60-fps-Videositzung unter Last verlieren. Laden ist definiert als eine gleichzeitige 1080p- bis 720p-Nur-Video-Transcodierungssitzung mit Hardware-Video-Codecs sowie eine 128-kbps-AAC-Audiowiedergabe.
    • [5.6/H-1-1] MUSS eine Tap-to-Tone-Latenz von 80 Millisekunden oder weniger haben, wenn der OboeTester-Tap-to-Tone-Test oder der CTS-Verifier-Tap-to-Tone-Test verwendet wird.
    • [5.6/H-1-2] MUSS eine Round-Trip-Audiolatenz von 80 Millisekunden oder weniger über mindestens einen unterstützten Datenpfad 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 niedrige Latenz- und Streaming-Konfigurationen unterstützt wird. Für die Konfiguration mit niedriger Latenz sollte AAudio von der App im Rückrufmodus mit niedriger Latenz verwendet werden. Für die Streaming-Konfiguration sollte ein Java AudioTrack von der App verwendet werden. Sowohl in den Konfigurationen mit niedriger Latenz als auch in den Streaming-Konfigurationen sollte die HAL-Ausgabesenke entweder AUDIO_FORMAT_PCM_24_BIT , AUDIO_FORMAT_PCM_24_BIT_PACKED , AUDIO_FORMAT_PCM_32_BIT oder AUDIO_FORMAT_PCM_FLOAT als Zielausgabeformat akzeptieren.
    • [5.6/H-1-4] 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 klassenkonforme MIDI-Geräte unterstützen und das MIDI-Feature-Flag deklarieren.
    • [5.7/H-1-2] MUSS MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL mit den unten aufgeführten Fähigkeiten zur Inhaltsentschlüsselung unterstützen.
    Minimale Stichprobengröße 4 MiB
    Mindestanzahl an Teilproben – H264 oder HEVC 32
    Minimale Anzahl von Subsamples - VP9 9
    Minimale Anzahl von Subsamples - AV1 288
    Minimale Subsample-Puffergröße 1 MiB
    Minimale generische Krypto-Puffergröße 500 KB
    Mindestanzahl gleichzeitiger Sitzungen 30
    Mindestanzahl von Schlüsseln pro Sitzung 20
    Minimale Gesamtanzahl an Schlüsseln (alle Sitzungen) 80
    Minimale Gesamtzahl von DRM-Schlüsseln (alle Sitzungen) 6
    Nachrichtengröße 16 KiB
    Entschlüsselte Frames pro Sekunde 60 fps

  • 2.2.7.2 Kamera : Aktualisierungen der Kameraanforderungen der Media Performance Class.

    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:

    • [7.5/H-1-1] MUSS eine primäre nach hinten gerichtete Kamera mit einer Auflösung von mindestens 12 Megapixeln haben, die Videoaufnahmen mit 4k@30fps 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 eine primäre Frontkamera mit einer Auflösung von mindestens 5 Megapixeln haben und Videoaufnahmen mit 1080p@30fps unterstützen. Die primäre Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
    • [7.5/H-1-3] MUSS die Eigenschaft android.info.supportedHardwareLevel für beide primären Kameras als FULL oder besser unterstützen.
    • [7.5/H-1-4] MUSS CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME für beide primären Kameras unterstützen.
    • [7.5/H-1-5] MUSS eine JPEG-Erfassungslatenz von Kamera2 < 1000 ms für eine Auflösung von 1080p haben, gemessen durch den CTS-Kameraleistungstest unter ITS-Beleuchtungsbedingungen (3000K) für beide Hauptkameras.
    • [7.5/H-1-6] MUSS Kamera2-Startlatenz (Öffnen der Kamera bis zum ersten Vorschaubild) < 500 ms haben, gemessen durch den CTS-Kameraleistungstest unter ITS-Beleuchtungsbedingungen (3000 K) für beide Primärkameras.
    • [7.5/H-1-8] MUSS CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW und android.graphics.ImageFormat.RAW_SENSOR für die primäre Rückkamera unterstützen.
    • [7.5/H-1-9] MUSS eine nach hinten gerichtete Primärkamera haben, die 720p oder 1080p bei 240fps unterstützt.
    • [7.5/H-1-10] MUSS min. ZOOM_RATIO < 1.0 für die primären Kameras 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 Front- als auch für die primäre Rückkamera unterstützen.
    • [7.5/H-1-13] MUSS LOGICAL_MULTI_CAMERA Fähigkeit für die Primärkameras unterstützen, wenn mehr als 1 RGB-Kameras in die gleiche Richtung zeigen.
    • [7.5/H-1-14] MUSS STREAM_USE_CASE Fähigkeit sowohl für die primäre Front- als auch für die primäre Rückkamera unterstützen.

  • 2.2.7.3 Hardware : Aktualisierungen der Medienleistungsklassen-Anforderungen für Hardware.

    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:

    • [7.1.1.1/H-2-1] MUSS eine Bildschirmauflösung von mindestens 1080p haben.
    • [7.1.1.3/H-2-1] MUSS eine Rasterdichte von mindestens 400 dpi haben.
    • [7.6.1/H-2-1] MUSS über mindestens 8 GB physischen Speicher verfügen.

  • 2.2.7.4 Leistung : Aktualisierungen der Medienleistungsklasse für Leistung.

    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:

    • [8.2/H-1-1] MUSS eine sequentielle Schreibleistung von mindestens 125 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 40 MB/s sicherstellen.

  • 2.5.1 Hardware : Aktualisierungen der Anforderungen an den 3-Achsen-Beschleunigungsmesser und das 3-Achsen-Gyroskop sowie die Anforderungen an die Außensichtkamera.

    Siehe Überarbeitung

    Implementierungen von Automobilgeräten:

    • [ 7.3.1 /A-0-4] MUSS dem Android- Autosensor-Koordinatensystem entsprechen.
    • [ 7.3 /A-SR] Es wird DRINGEND_EMPFOHLEN, einen 3-Achsen-Beschleunigungsmesser und ein 3-Achsen-Gyroskop einzuschließen.
    • [ 7.3 /A-SR] Es wird DRINGEND_EMPFOHLEN, den Sensor TYPE_HEADING zu implementieren und zu melden.

    Wenn Implementierungen von Automotive-Geräten einen Beschleunigungsmesser beinhalten, dann:

    • [ 7.3 .1/A-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 100 Hz melden können.

    Wenn Geräteimplementierungen einen 3-Achsen-Beschleunigungsmesser enthalten, haben sie:

    • [ 7.3.1 /A-SR] Es wird DRINGEND EMPFOHLEN, den zusammengesetzten Sensor für Beschleunigungsmesser mit begrenzten Achsen zu implementieren.

    Wenn Implementierungen von Automotive-Geräten einen Beschleunigungsmesser mit weniger als 3 Achsen beinhalten, dann:

    • [ 7.3.1 /A-1-3] MUSS den Sensor TYPE_ACCELEROMETER_LIMITED_AXES implementieren und melden.
    • [ 7.3.1 /A-1-4] MUSS den Sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED implementieren und melden.

    Wenn Implementierungen von Automotive-Geräten ein Gyroskop enthalten, dann:

    • [ 7.3 .4/A-2-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 100 Hz melden können.
    • [ 7.3.4 /A-2-3] MUSS in der Lage sein, Orientierungsänderungen bis zu 250 Grad pro Sekunde zu messen.
    • [ 7.3.4 /A-SR] Es wird DRINGEND EMPFOHLEN, den Messbereich des Gyroskops auf +/-250 dps zu konfigurieren, um die mögliche Auflösung zu maximieren.

    Wenn Implementierungen von Automotive-Geräten ein 3-Achsen-Gyroskop enthalten, dann:

    • [ 7.3.4 /A-SR] Es wird DRINGEND EMPFOHLEN, den Verbundsensor für Gyroskope mit begrenzten Achsen zu implementieren.

    Wenn Implementierungen von Automotive-Geräten ein Gyroskop mit weniger als 3 Achsen beinhalten, dann:

    • [ 7.3.4 /A-4-1] MUSS den Sensor TYPE_GYROSCOPE_LIMITED_AXES implementieren und melden.
    • [ 7.3.4 /A-4-2] MUSS den Sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED implementieren und melden.

    Wenn Implementierungen von Automobilgeräten einen TYPE_HEADING Sensor enthalten, haben sie:

    • [ 7.3.4 /A-4-3] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 1 Hz melden können.
    • [ 7.3.4 /A-SR] DRINGEND_EMPFOHLEN, Ereignisse bis zu einer Frequenz von mindestens 10 Hz zu melden.
    • SOLLTE sich auf den wahren Norden beziehen.
    • MUSS auch bei stehendem Fahrzeug verfügbar sein.
    • SOLLTE eine Auflösung von mindestens 1 Grad haben.

    Eine Außensichtkamera ist eine Kamera, die Szenen außerhalb der Geräteimplementierung abbildet, wie die Rückfahrkamera eine Dashcam .

    Wenn Implementierungen von Kraftfahrzeuggeräten eine Außensichtkamera enthalten, gilt für eine solche Kamera Folgendes:

    • [ 7.5.5 /A-SR] Es wird DRINGEND EMPFOHLEN, so ausgerichtet zu werden, dass die lange Abmessung der Kamera mit dem Horizont übereinstimmt.

    • SOLLTE das Android-Synchronisations-Framework unterstützen.

    • MÖGLICHERWEISE ist entweder ein Hardware-Autofokus oder ein Software-Autofokus im Kameratreiber implementiert.

    Wenn Implementierungen von Kraftfahrzeuggeräten eine oder mehrere Außensichtkameras enthalten und den Dienst Exterior View System (EVS) laden, dann gilt für eine solche Kamera Folgendes:

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

    Implementierungen von Automobilgeräten:

    • KÖNNEN eine oder mehrere Kameras enthalten, die Anwendungen von Drittanbietern zur Verfügung stehen.

    Wenn Implementierungen von Automobilgeräten mindestens eine Kamera enthalten und diese Anwendungen von Drittanbietern zur Verfügung stellen, dann:

    • [ 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 deklarieren .
    • KANN externe Kameras unterstützen, die in Abschnitt 7.5.3 beschrieben sind.
    • KÖNNEN Funktionen (wie Autofokus usw.) enthalten, die für nach hinten gerichtete Kameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.

  • 2.5.5 Sicherheitsmodell : Neue Anforderungen für Kameraberechtigungen für Fahrzeuggeräte.

    Siehe Überarbeitung

    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 mit CDD genannten Rollen innehaben Kennung [C-3-X].

    • [ 9.8.2 /A-2-2] DARF die Kameraanzeige für System-Apps mit sichtbaren Benutzeroberflächen oder direkter Benutzerinteraktion nicht verbergen.

  • 2.6.1 Tablet-Anforderungen – Hardware : Aktualisierung der Anforderungen an die Bildschirmgröße des Tablets.

    Siehe Überarbeitung

    Ein Android-Tablet-Gerät bezieht sich auf eine Android-Geräteimplementierung, die normalerweise alle folgenden Kriterien erfüllt:

    • Hat eine Bildschirmgröße von mehr als 7 Zoll und weniger als 18 Zoll, diagonal gemessen.

    Bildschirmgröße

    • [ 7.1.1.1/Tab-0-1 ] MUSS einen Bildschirm im Bereich von 7 bis 18 Zoll haben.

3. Software

  • 3.2.2 Build-Parameter : Aktualisierte ASCII-Zeichen in getSerial() .

    Siehe Überarbeitung

    • [C-0-1] Um konsistente, aussagekräftige Werte über Geräteimplementierungen hinweg bereitzustellen, enthält die folgende Tabelle zusätzliche Einschränkungen für die Formate dieser Werte, denen Geräteimplementierungen entsprechen MÜSSEN.
    Parameter Einzelheiten
    getSerial() MUSS eine Hardware-Seriennummer sein oder zurückgeben, die für Geräte mit demselben MODELL und HERSTELLER verfügbar und eindeutig sein MUSS. Der Wert dieses Felds MUSS als 7-Bit-ASCII kodierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9]+$“ entsprechen.

  • 3.2.3.5 Bedingte Anwendungsabsichten : Aktualisierung der Anforderungen für bedingte Anwendungsabsichten.

    Siehe Überarbeitung

    Wenn Geräteimplementierungen ein großes Display enthalten (im Allgemeinen mit einer Displaybreite und -höhe von 600 dp+) und Split-Funktionalität unterstützen, dann:

  • 3.5.1 Anwendungsbeschränkung : Aktualisierungen der Anwendungsbeschränkungen.

    Siehe Überarbeitung

    Wenn Geräteimplementierungen einen proprietären Mechanismus implementieren, um Apps einzuschränken (z. B. das Ändern oder Einschränken von API-Verhalten, das im SDK beschrieben ist) und dieser Mechanismus restriktiver ist als der Restricted App Standby Bucket , dann:

    • [C-1-1] MUSS dem Benutzer erlauben, die Liste der eingeschränkten Apps zu sehen.
    • [C-1-2] MUSS dem Benutzer die Möglichkeit bieten, alle diese proprietären Beschränkungen für jede App ein-/auszuschalten.
    • [C-1-3] DÜRFEN diese proprietären Beschränkungen nicht automatisch ohne Nachweis eines schlechten Systemzustandsverhaltens anwenden, aber KANN die Beschränkungen auf Apps anwenden, wenn ein schlechtes Systemzustandsverhalten wie hängende Wakelocks, lange laufende Dienste und andere Kriterien erkannt wird. Die Kriterien KÖNNEN von Geräteimplementierern festgelegt werden, MÜSSEN sich jedoch auf die Auswirkungen der App auf den Systemzustand beziehen. Andere Kriterien, die sich nicht ausschließlich auf den Systemzustand beziehen, wie z. B. die mangelnde Popularität der App auf dem Markt, DÜRFEN NICHT als Kriterien verwendet werden.
    • [C-1-4] MUSS diese proprietären Beschränkungen nicht automatisch auf Apps anwenden, wenn ein Benutzer App-Beschränkungen manuell deaktiviert hat, und KANN dem Benutzer vorschlagen, diese proprietären Beschränkungen anzuwenden.

    • [C-1-5] MUSS Benutzer informieren, wenn diese Eigentumsbeschränkungen automatisch auf eine App angewendet werden. Diese Informationen MÜSSEN innerhalb von 24 Stunden vor der Anwendung dieser Eigentumsbeschränkungen bereitgestellt werden.

    • [C-1-6] MUSS für die ActivityManager.isBackgroundRestricted()- Methode für alle API-Aufrufe von einer App „true“ zurückgeben.

    • [C-1-7] DARF NICHT die oberste Vordergrund-App einschränken, die ausdrücklich vom Benutzer verwendet wird.

    • [C-1-8] MUSS diese proprietären Einschränkungen für eine App aufheben, wenn ein Benutzer beginnt, die App explizit zu verwenden, wodurch sie zur obersten Vordergrundanwendung wird.

    • [C-1-9] MUSS alle diese proprietären Beschränkungsereignisse über UsageStats melden.

    • [C-1-10] MUSS ein öffentliches und klares Dokument oder eine Website bereitstellen, die beschreibt, wie Eigentumsbeschränkungen angewendet werden. Dieses Dokument oder diese Website MUSS mit den Android SDK-Dokumenten verknüpft werden können und MUSS Folgendes enthalten:

      • Auslösebedingungen für Eigentumsbeschränkungen.
      • Was und wie eine App eingeschränkt werden kann.
      • Wie eine App von solchen Beschränkungen ausgenommen werden kann.
      • Wie eine App eine Ausnahme von Eigentumsbeschränkungen beantragen kann, wenn sie eine solche Ausnahme für Apps unterstützt, die der Benutzer installieren kann.

    Wenn eine App auf dem Gerät vorinstalliert ist und länger als 30 Tage nie ausdrücklich von einem Benutzer verwendet wurde, sind [C-1-3] [C-1-5] ausgenommen.

  • 3.8.1 Launcher (Startbildschirm) : Aktualisierungen zur Unterstützung von monochrome/adaptive-icon .

    Siehe Überarbeitung

    Wenn Geräteimplementierungen monochrome Symbole unterstützen, sind diese Symbole:

    • [C-6-1] DÜRFEN nur verwendet werden, wenn ein Benutzer sie explizit aktiviert (z. B. über die Einstellungen oder das Hintergrundbildauswahlmenü).

  • 3.8.2 Widgets : Aktualisieren Sie die Präsenz von Drittanbieter-App-Widgets im Launcher.

    Siehe Überarbeitung

    Wenn Geräteimplementierungen App-Widgets von Drittanbietern unterstützen, tun sie Folgendes:

    • [C-1-2] MUSS integrierte Unterstützung für AppWidgets enthalten und Benutzeroberflächenangebote zum Hinzufügen, Konfigurieren, Anzeigen und Entfernen von AppWidgets bereitstellen direkt im Launcher.

  • 3.8.3.1 Präsentation von Benachrichtigungen : Klärung der Definition von Heads-up-Benachrichtigungen.

    Siehe Überarbeitung

    Heads-up-Benachrichtigungen sind Benachrichtigungen, die dem Benutzer angezeigt werden, sobald sie eingehen, unabhängig von der Oberfläche, auf der sich der Benutzer befindet.

  • 3.8.3.3 DND (Bitte nicht stören)/Prioritätsmodus : Update zur Einbeziehung des Prioritätsmodus in die DND-Anforderungen (Bitte nicht stören).

    Siehe Überarbeitung

    3.8.3.3. DND (Bitte nicht stören) / Prioritätsmodus

    Wenn Geräteimplementierungen die DND-Funktion (auch Prioritätsmodus genannt) unterstützen, tun sie Folgendes:

  • 3.8.6 Themen : Neue Anforderungen für dynamische Farbtonpaletten.

    Siehe Überarbeitung

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

    • [C-1-4] MUSS dynamische Farbtonpaletten generieren, wie in der AOSP-Dokumentation von Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES angegeben (siehe android.theme.customization.system_palette und android.theme.customization.theme_style ).

    • [C-1-5] MUSS dynamische Farbpaletten mit Farbdesigns erzeugen, die in der Dokumentation Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (siehe android.theme.customization.theme_styles ) aufgeführt sind, nämlich TONAL_SPOT , VIBRANT , EXPRESSIVE , SPRITZ , RAINBOW , FRUIT_SALAD .

      „Quellfarbe“ wird verwendet, um dynamische Farbtonpaletten zu generieren, wenn sie mit android.theme.customization.system_palette gesendet werden (wie in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES dokumentiert).

    • [C-1-6] MUSS einen CAM16 Chromawert von 5 oder höher haben.

      • SOLLTE vom Hintergrundbild über com.android.systemui.monet.ColorScheme#getSeedColors abgeleitet werden, das mehrere gültige Quellfarben bereitstellt, aus denen eine ausgewählt werden kann.

      • SOLLTE den Wert 0xFF1B6EF3 verwenden, wenn keine der bereitgestellten Farben die oben genannten Anforderungen an die Quellfarbe erfüllt.

  • 3.8.17 Zwischenablage : Neuer Anforderungsabschnitt für Inhalte in der Zwischenablage hinzugefügt.

    Siehe Überarbeitung

    3.8.17. Zwischenablage

    Geräteimplementierungen:

    • [C-0-1] DARF KEINE Zwischenablagedaten an Komponenten, Aktivitäten, Dienste oder über eine Netzwerkverbindung ohne explizite Benutzeraktion (z. B. Drücken einer Schaltfläche auf dem Overlay) senden, mit Ausnahme der in 9.8.6 Inhalt erwähnten Dienste Erfassung und App-Suche .

    Wenn Geräteimplementierungen eine für den Benutzer sichtbare Vorschau generieren, wenn Inhalte für ein beliebiges ClipData Element in die Zwischenablage kopiert werden, bei dem ClipData.getDescription().getExtras() android.content.extra.IS_SENSITIVE enthält, dann:

    • [C-1-1] MUSS die für den Benutzer sichtbare Vorschau redigieren

    Die AOSP-Referenzimplementierung erfüllt diese Zwischenablageanforderungen.

  • 3.9.1.1 Gerätebesitzer-Bereitstellung : Aktualisierungen der Gerätebesitzer-Bereitstellungsanforderungen.

    Siehe Überarbeitung

    Wenn Geräteimplementierungen android.software.device_admin deklarieren, haben sie:

    • [C-1-1] MUSS die Registrierung eines Device Policy Client (DPC) als Gerätebesitzer-App wie unten beschrieben unterstützen:
      • Wenn für die Geräteimplementierung weder Benutzer noch Benutzerdaten konfiguriert sind, gilt Folgendes:
        • [C-1-5] MUSS die DPC-Anwendung als Geräteeigentümer-App registrieren oder der DPC-App ermöglichen, auszuwählen, ob sie Geräteeigentümer oder Profileigentümer werden möchte, wenn das Gerät Near-Field Communications (NFC)-Unterstützung über die Funktion erklärt Flag android.hardware.nfc und erhält eine NFC-Nachricht, die einen Datensatz mit dem MIME-Typ MIME_TYPE_PROVISIONING_NFC enthält.
        • [C-1-8] MUSS die Absicht ACTION_GET_PROVISIONING_MODE senden, nachdem die Bereitstellung des Gerätebesitzers ausgelöst wurde, damit die DPC-App abhängig von den Werten von android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES wählen kann, ob sie ein Gerätebesitzer oder ein Profilbesitzer werden möchte, es sei denn es kann aus dem Kontext bestimmt werden, dass es nur eine gültige Option gibt. (z. B. für die NFC-basierte Bereitstellung, bei der die Profilbesitzer-Bereitstellung nicht unterstützt wird).
        • [C-1-9] MUSS die Absicht ACTION_ADMIN_POLICY_COMPLIANCE an die Gerätebesitzer-App senden, wenn ein Gerätebesitzer während der Bereitstellung eingerichtet wird, unabhängig von der verwendeten Bereitstellungsmethode. Der Benutzer darf nicht in der Lage sein, im Einrichtungsassistenten fortzufahren, bis die Gerätebesitzer-App beendet ist.
      • Wenn die Geräteimplementierung Benutzer oder Benutzerdaten enthält, gilt Folgendes:
        • [C-1-7] DÜRFEN keine DPC-Anwendung mehr als Gerätebesitzer-App registrieren.
    • [C-1-2] MUSS einen entsprechenden Offenlegungshinweis (z. B. auf den in AOSP verwiesen wird ) anzeigen und die Zustimmung des Endbenutzers einholen, bevor eine App als Geräteeigentümer festgelegt wird, es sei denn, das Gerät wurde zuvor programmgesteuert für den Einzelhandelsdemomodus konfiguriert Bildschirm, Endbenutzerinteraktion. einige positive Maßnahmen vor oder während des Bereitstellungsprozesses erfordern, um einer App zuzustimmen, die als Geräteeigentümer festgelegt wird. Die Zustimmung kann durch eine Benutzeraktion oder durch einige programmatische Mittel erfolgen, aber ein entsprechender Offenlegungshinweis (wie in AOSP referenziert) MUSS angezeigt werden, bevor die Bereitstellung des Gerätebesitzers eingeleitet wird. Außerdem darf der (von Unternehmen) für die Gerätebesitzer-Bereitstellung verwendete programmatische Zustimmungsmechanismus für Gerätebesitzer NICHT die Out-of-Box-Erfahrung für die Verwendung außerhalb des Unternehmens beeinträchtigen.
    • [C-1-3] DÜRFEN die Einwilligung NICHT fest codieren oder die Nutzung anderer Gerätebesitzer-Apps verhindern.

    Wenn Geräteimplementierungen android.software.device_admin deklarieren, aber auch eine proprietäre Gerätebesitzer Geräteverwaltungslösung und stellen einen Mechanismus bereit, um eine in ihrer Lösung konfigurierte Anwendung als „Gerätebesitzer-Äquivalent“ zum standardmäßigen „Gerätebesitzer“ hochzustufen, wie von den standardmäßigen Android DevicePolicyManager- APIs erkannt, sie:

    • [C-2-1] MUSS über einen Prozess verfügen, um zu verifizieren, dass die beworbene App zu einer legitimen Geräteverwaltungslösung für Unternehmen gehört und in der proprietären Lösung so konfiguriert wurde, dass sie über die Rechte eines „Gerätebesitzers“ verfügt.
    • [C-2-2] MUSS dieselbe Offenlegung der Zustimmung des AOSP-Gerätebesitzers zeigen wie der von android.app.action.PROVISION_MANAGED_DEVICE initiierte Ablauf, bevor die DPC-Anwendung als „Gerätebesitzer“ registriert wird.
    • [C-2-3] DÜRFEN die Zustimmung NICHT fest codieren oder die Nutzung anderer Gerätebesitzer-Apps verhindern.
    • KÖNNEN Benutzerdaten auf dem Gerät haben, bevor die DPC-Anwendung als „Geräteeigentümer“ registriert wird.

  • 3.9.4 Rollenanforderungen für die Geräteverwaltung : Es wurde ein Abschnitt für die Rollenanforderungen für die Geräteverwaltung hinzugefügt.

    Siehe Überarbeitung

    3.9.4 Rollenanforderungen für die Geräterichtlinienverwaltung

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

    • [C-1-1] MUSS die Geräterichtlinienverwaltungsrolle wie in Abschnitt 9.1 definiert unterstützen. Die Anwendung, die die Geräterichtlinienverwaltungsrolle innehat, KANN definiert werden, indem config_devicePolicyManagement auf den Paketnamen gesetzt wird. Auf den Paketnamen MUSS : und das Signaturzertifikat folgen, es sei denn, die Anwendung ist vorab geladen.

    Wenn für config_devicePolicyManagement kein Paketname definiert ist, wie oben beschrieben:

    Wenn für config_devicePolicyManagement wie oben beschrieben ein Paketname definiert ist:

    • [C-3-1] Die Anwendung MUSS auf allen Profilen eines Benutzers installiert werden .
    • [C-3-2] Geräteimplementierungen KÖNNEN eine Anwendung definieren, die den Inhaber der Geräterichtlinienverwaltungsrolle vor der Bereitstellung aktualisiert, indem config_devicePolicyManagementUpdater festgelegt wird.

    Wenn für config_devicePolicyManagementUpdater wie oben beschrieben ein Paketname definiert ist:

    • [C-4-1] Die Anwendung MUSS auf dem Gerät vorinstalliert sein.
    • [C-4-2] Die Anwendung MUSS einen Absichtsfilter implementieren, der android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER auflöst.

  • 3.18 Kontakte : Hinzufügen von Informationen für neue Kontakte.

    Siehe Überarbeitung

    Standardkonto für neue Kontakte: Contacts Provider stellt APIs bereit, um die Einstellung des Standardkontos beim Erstellen eines neuen Kontakts zu verwalten.

    Wenn Geräteimplementierungen eine Kontakte-App vorab laden, dann gilt für die vorab geladene Kontakte-App:

    • [C-2-1] MUSS die Absicht ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT verarbeiten, um eine Benutzeroberfläche für die Kontoauswahl zu starten und die Einstellung im Kontaktanbieter zu speichern, wenn ein Konto ausgewählt wird.

    • [C-2-2] MUSS die Standardkontoeinstellung berücksichtigen, wenn Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT für ContactsContracts.Contacts.CONTENT_TYPE und ContactsContract.RawContacts.CONTENT_TYPE verarbeitet werden, indem zunächst das Konto ausgewählt wird.

4. Kompatibilität der Anwendungsverpackung

5. Multimedia-Kompatibilität

  • 5.1.2 Audio-Decodierung : Neue Anforderungen für Decoder hinzugefügt, die Mehrkanal-Audio ausgeben können.

    Siehe Überarbeitung

    Wenn Geräteimplementierungen die Dekodierung von AAC-Eingangspuffern von Mehrkanal-Streams (d. h. mehr als zwei Kanälen) zu PCM über den Standard-AAC-Audiodecoder in der android.media.MediaCodec API unterstützen, MUSS Folgendes unterstützt werden:

    • [C-7-1] MUSS von der Anwendung über die Decodierung mit dem Schlüssel KEY_MAX_OUTPUT_CHANNEL_COUNT konfiguriert werden können, um zu steuern, ob der Inhalt auf Stereo heruntergemischt wird (bei Verwendung eines Werts von 2) oder mit der nativen Anzahl von Kanälen ausgegeben wird ( wenn Sie einen Wert verwenden, der gleich oder größer dieser Zahl ist). Beispielsweise würde ein Wert von 6 oder höher einen Decoder so konfigurieren, dass er 6 Kanäle ausgibt, wenn 5.1-Inhalte eingespeist werden.
    • [C-7-2] Beim Decodieren MUSS der Decoder die im Ausgabeformat verwendete Kanalmaske mit dem Schlüssel KEY_CHANNEL_MASK unter Verwendung der android.media.AudioFormat Konstanten bekannt geben (Beispiel: CHANNEL_OUT_5POINT1 ).

    Wenn Geräteimplementierungen andere Audiodecoder als den Standard-AAC-Audiodecoder unterstützen und in der Lage sind, Mehrkanal-Audio (d. h. mehr als 2 Kanäle) auszugeben, wenn komprimierter Mehrkanal-Inhalt eingespeist wird, dann:

    • [C-SR] Es wird DRINGEND EMPFOHLEN, dass der Decoder von der Anwendung konfiguriert werden kann, indem er die Dekodierung mit dem Schlüssel KEY_MAX_OUTPUT_CHANNEL_COUNT verwendet, um zu steuern, ob der Inhalt auf Stereo heruntergemischt wird (bei Verwendung eines Werts von 2) oder mit der nativen Nummer ausgegeben wird der Kanäle (bei Verwendung eines Werts, der gleich oder größer dieser Zahl ist). Beispielsweise würde ein Wert von 6 oder höher einen Decoder so konfigurieren, dass er 6 Kanäle ausgibt, wenn 5.1-Inhalte eingespeist werden.
    • [C-SR] Beim Decodieren wird dem Decoder DRINGEND EMPFOHLEN, die im Ausgabeformat verwendete Kanalmaske mit dem Schlüssel KEY_CHANNEL_MASK unter Verwendung der android.media.AudioFormat-Konstanten anzukündigen (Beispiel: CHANNEL_OUT_5POINT1 ).

  • 5.4.1 Raw Audio Capture und Mikrofoninformationen : Aktualisierungen für unterstützte Audioquellen für Audioeingangsstreams.

    Siehe Überarbeitung

    Wenn Geräteimplementierungen android.hardware.microphone deklarieren, tun sie Folgendes:

    • [C-1-1] MUSS die Erfassung von Audio-Rohinhalten mit den folgenden Merkmalen für jeden erfolgreich geöffneten AudioRecord oder AAudio INPUT-Stream zulassen. Folgende Merkmale MÜSSEN mindestens unterstützt werden :

  • 5.4.2 Aufnahme für die Spracherkennung : Aktualisierte Anforderungen für den Spracherkennungs-Audiostream und zusätzliche Anforderungen für Mikrofonverstärkungspegel.

    Siehe Überarbeitung

    Wenn Geräteimplementierungen android.hardware.microphone deklarieren, tun sie Folgendes:

    • SOLLTE den Spracherkennungs-Audiostream mit ungefähr flachen Amplituden-Frequenz-Eigenschaften aufzeichnen: insbesondere ±3 dB von 100 Hz bis 4000 Hz.
    • SOLLTE den Spracherkennungs-Audiostream mit einer so eingestellten Eingangsempfindlichkeit aufzeichnen, dass eine Quelle mit 90 dB Schallleistungspegel (SPL) bei 1000 Hz RMS von 2500 für 16-Bit-Samples ergibt.

    • SOLLTE im mittleren Frequenzbereich ungefähr flache Amplituden-Frequenz-Charakteristiken aufweisen: insbesondere ±3 dB von 100 Hz bis 4000 Hz für jedes einzelne Mikrofon, das zur Aufzeichnung der Audioquelle der Spracherkennung verwendet wird.
    • [C-SR] wird DRINGEND EMPFOHLEN, Amplitudenpegel im Niederfrequenzbereich aufzuweisen: insbesondere von ±20 dB von 30 Hz bis 100 Hz im Vergleich zum Mittelfrequenzbereich für jedes einzelne Mikrofon, das zum Aufzeichnen der Spracherkennungs-Audioquelle verwendet wird.
    • [C-SR] wird DRINGEND EMPFOHLEN, Amplitudenpegel im Hochfrequenzbereich aufzuweisen: insbesondere von ±30 dB von 4000 Hz bis 22 KHz im Vergleich zum Mittelfrequenzbereich für jedes einzelne Mikrofon, das zum Aufzeichnen der Spracherkennungs-Audioquelle verwendet wird.
    • SOLLTE die Audioeingangsempfindlichkeit so einstellen, dass eine sinusförmige 1000-Hz-Tonquelle mit 90 dB Schalldruckpegel (SPL) (gemessen neben dem Mikrofon) eine ideale Antwort von RMS 2500 innerhalb eines Bereichs von 1770 und 3530 für 16-Bit-Samples liefert ( oder -22,35 db ±3 dB Full Scale für Fließkomma-/Doppelpräzisions-Samples) für jedes einzelne Mikrofon, das zum Aufzeichnen der Spracherkennungs-Audioquelle verwendet wird.

  • 5.4.6 Mikrofonverstärkungspegel : Anforderungen für Mikrofonverstärkungspegel in Abschnitt 5.4.2 verschoben.

    Siehe Überarbeitung

    5.4.6. Mikrofonverstärkungspegel [Nach 5.4.2 verschoben]

    Wenn Geräteimplementierungen android.hardware.microphone deklarieren, tun sie Folgendes:

    • SOLLTE im mittleren Frequenzbereich ungefähr flache Amplituden-Frequenz-Charakteristiken aufweisen: insbesondere ±3 dB von 100 Hz bis 4000 Hz für jedes einzelne Mikrofon, das zur Aufzeichnung der Audioquelle der Spracherkennung verwendet wird.
    • [C-SR] wird DRINGEND EMPFOHLEN, Amplitudenpegel im Niederfrequenzbereich aufzuweisen: insbesondere von ±20 dB von 5 Hz bis 100 Hz im Vergleich zum Mittelfrequenzbereich für jedes einzelne Mikrofon, das zum Aufzeichnen der Spracherkennungs-Audioquelle verwendet wird.
    • [C-SR] wird DRINGEND EMPFOHLEN, Amplitudenpegel im Hochfrequenzbereich aufzuweisen: insbesondere von ±30 dB von 4000 Hz bis 22 KHz im Vergleich zum Mittelfrequenzbereich für jedes einzelne Mikrofon, das zum Aufzeichnen der Spracherkennungs-Audioquelle verwendet wird.
    • SOLLTE die Audioeingangsempfindlichkeit so einstellen, dass eine sinusförmige 1000-Hz-Tonquelle, die mit 90 dB Schalldruckpegel (SPL) abgespielt wird, eine Antwort mit RMS von 2500 für 16-Bit-Samples (oder -22,35 dB Full Scale für Gleitkomma-/Doppelpräzisions-Samples) liefert. für jedes einzelne Mikrofon, das zum Aufzeichnen der Spracherkennungs-Audioquelle verwendet wird.

  • 5.5.4 Audio-Offload : Aktualisierungen der Audio-Offload-Wiedergabeanforderungen.

    Siehe Überarbeitung

    Wenn Geräteimplementierungen die Audio-Offload-Wiedergabe unterstützen, tun sie Folgendes:

    • [C-SR] wird DRINGEND EMPFOHLEN, den wiedergegebenen lückenlosen Audioinhalt zwischen zwei Clips mit demselben Format zu trimmen, wenn dies von der AudioTrack Gapless API und dem Mediencontainer für MediaPlayer angegeben wird.

  • 5.6 Audiolatenz : Aktualisierungen der Audiolatenzanforderungen.

    Siehe Überarbeitung

    Verwenden Sie für die Zwecke dieses Abschnitts die folgenden Definitionen:

    • kalter Ausgangsjitter . Die Variabilität zwischen getrennten Messungen von Kaltausgabelatenzwerten.
    • kalter Eingangsjitter . Die Variabilität zwischen getrennten Messungen von Cold-Input-Latenzwerten.

    Wenn Geräteimplementierungen android.hardware.audio.output deklarieren, MÜSSEN sie die folgenden Anforderungen erfüllen oder übertreffen:

    • [C-1-2] Kaltausgabelatenz von 500 Millisekunden oder weniger.
    • [C-1-3] Das Öffnen eines Ausgabestreams mit AAudioStreamBuilder_openStream() MUSS weniger als 1000 Millisekunden dauern.

    Wenn Geräteimplementierungen android.hardware.audio.output deklarieren, wird DRINGEND EMPFOHLEN, dass sie die folgenden Anforderungen erfüllen oder übertreffen:

    • [C-SR] Kaltausgangslatenz von 100 Millisekunden oder weniger über den Lautsprecherdatenpfad. Vorhandene und neue Geräte, auf denen diese Version von Android ausgeführt wird, werden SEHR DRINGEND EMPFOHLEN, um diese Anforderungen jetzt zu erfüllen. In einer zukünftigen Plattformversion werden wir eine Kaltausgabelatenz von 200 ms oder weniger als MUSS fordern.
    • [C-SR] Minimiert den Kaltausgabe-Jitter.

    Wenn Geräteimplementierungen android.hardware.microphone enthalten, MÜSSEN sie diese Eingangsaudioanforderungen erfüllen:

    • [C-3-2] Kalteingangslatenz von 500 Millisekunden oder weniger.
    • [C-3-3] Das Öffnen eines Eingabestreams mit AAudioStreamBuilder_openStream() MUSS weniger als 1000 Millisekunden dauern.

    Wenn Geräteimplementierungen android.hardware.microphone enthalten, werden sie DRINGEND EMPFOHLEN, um diese Eingangsaudioanforderungen zu erfüllen:

    • [C-SR] Kalteingangslatenz von 100 Millisekunden oder weniger über den Mikrofondatenpfad. Vorhandene und neue Geräte, auf denen diese Version von Android ausgeführt wird, werden SEHR DRINGEND EMPFOHLEN, um diese Anforderungen jetzt zu erfüllen. In einer zukünftigen Plattformversion werden wir eine Kalteingangslatenz von 200 ms oder weniger als MUSS fordern.

    • [C-SR] Kontinuierliche Eingangslatenz von 30 Millisekunden oder weniger.
    • [C-SR] Minimize the cold input jitter.

  • 5.10 Professional Audio : Updates to audio latency requirements for professional audio support.

    See revision

    If device implementations report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class, they:

    • [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less and SHOULD be 10 milliseconds or less over at least one supported path.
    • [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY .
    • [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
    • [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
    • SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.

    If device implementations include a 4 conductor 3.5mm audio jack, they:

    • [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency , of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an audio loopback dongle .

  • 5.12 HDR Video : Added a new section for HDR Video requirements.

6. Developer Tools and Options Compatibility

  • 6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.

    See revision

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:

    • [C-4-1] MUST have the AdbManager#isAdbWifiSupported() method return true .

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:

    • [C-5-1] MUST have the AdbManager#isAdbWifiQrSupported() method return true .

    • GPU work information

      Device implementations:

      • [C-6-1] MUST implement the shell command dumpsys gpu --gpuwork to display the aggregated GPU work data returned by the power/gpu_work_period kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation is frameworks/native/services/gpuservice/gpuwork/ .

7. Hardware Compatibility

  • 7.1.4.1 OpenGL ES : Update to recommended extensions.

    See revision

    If device implementations support any of the OpenGL ES versions, they:

    • SHOULD support the EGL_IMG_context_priority and EGL_EXT_protected_content extensions.

  • 7.1.4.2 Vulkan : Updates to version supported for Vulkan.

    See revision

    If device implementations support OpenGL ES 3.1, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1
    • MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).

    If device implementations include a screen or video output, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1

    If device implementations include support for Vulkan 1.0 or higher, they:

    • SHOULD support VkPhysicalDeviceProtectedMemoryFeatures and VK_EXT_global_priority .
    • [C-1-12] MUST NOT enumerate support for the VK_KHR_performance_query extension.
    • [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.

  • 7.2.3 Navigation Keys :

    See revision

    Device implementations:

    • [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.

    If the back navigation function is provided and the user cancels the Back gesture, then:

    • [C-8-1] OnBackInvokedCallback.onBackCancelled() MUST be called.
    • [C-8-2] OnBackInvokedCallback.onBackInvoked() MUST NOT be called.
    • [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.

    If the back navigation function is provided but the foreground application does NOT have an OnBackInvokedCallback registered, then:

    • The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.

    If device implementations provide support for the system API setNavBarMode to allow any system app with android.permission.STATUS_BAR permission to set the navigation bar mode, then they:

    • [C-9-1] MUST provide support for kid-friendly icons or button-based navigation as provided in the AOSP code.

  • 7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.

    See revision

    If device implementations include an accelerometer, a 3-axis accelerometer, they:

    • [C-1-2] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [SR] are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [SR] are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    Wenn Geräteimplementierungen einen 3-Achsen-Beschleunigungsmesser enthalten, haben sie:

    • [C-2-1] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    If device implementations include an accelerometer with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_ACCELEROMETER_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis accelerometer and any of the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors are implemented:

    • [C-4-1] The sum of their power consumption MUST always be less than 4 mW.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

    If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:

    • [C-6-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

  • 7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.

    See revision

    If device implementations include a gyroscope, they:

    • [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
    • [C-1-4] MUST have a resolution of 12-bits or more.
    • [C-1-5] MUST be temperature compensated.
    • [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
    • [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
    • [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
    • [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
    • SHOULD report events up to at least 200 Hz.

    If device implementations include a 3-axis gyroscope, they:

    • [C-2-1] MUST implement the TYPE_GYROSCOPE sensor.

    If device implementations include a gyroscope with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_GYROSCOPE_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:

    • [C-4-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

  • 7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.

    See revision

    Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 . Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.

    If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience ), they:

    • [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.

    If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak ), they:

    • [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .

    If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong ), they:

    • [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .

  • 7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.

    See revision

    7.3.13. IEEE 802.1.15.4 (UWB)

    If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:

    • [C-1-1] MUST implement the corresponding Android API in android.uwb.
    • [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
    • [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
    • [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
    • [C-1-5] MUST enforce that apps using UWB radio hold UWB_RANGING permission (under NEARBY_DEVICES permission group).
    • [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .

  • 7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.

    See revision

    If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:

    If device implementations include GSM or CDMA telephony, then:

    If the device device implementations include GSM or CDMA telephony and provide a system status bar, then:

    • [C-6-7] MUST select a representative active subscription for a given group UUID to display to the user in any affordances that provide SIM status information. Examples of such affordances include the status bar cellular signal icon or quick settings tile.
    • [C-SR] It is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.

    If device implementations include GSM or CDMA telephony, then:

    • [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
    • [C-6-10] MUST NOT apply any of the following behaviors to active carrier apps (as designated by TelephonyManager#getCarrierServicePackageName ) automatically or without explicit user confirmation:
      • Revoke or limit network access
      • Revoke permissions
      • Restrict background or foreground app execution beyond the existing power management features included in AOSP
      • Disable or uninstall the app

    If device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:

    • [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.

    If device implementations include GSM telephony but not CDMA telephony, they:

    If the device implementations support eUICCs with multiple ports and profiles, they:

  • 7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.

    See revision

    If device implementations report the android.hardware.telephony feature , they:

    • [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with BLOCKED_TYPE out of the default call log view in the pre-installed dialer app.
    • SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.

  • 7.4.1.3 Cellular NAT-T Keepalive Offload : New section for Cellular NAT-T Keepalive Offload.

    See revision

    7.4.1.3. Cellular NAT-T Keepalive Offload

    Device implementations:

    • SHOULD include support for Cellular keepalive offload.

    If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least one concurrent keepalive slot over cellular.
    • [C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio HAL.
    • [C-SR] Are STRONGLY RECOMMENDED to support at least three cellular keepalive slots per radio instance.

    If device implementations do not include support for cellular keepalive offload, they:

    • [C-2-1] MUST return ERROR_UNSUPPORTED.

  • 7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.

    See revision

    If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:

    • [C-1-4] MUST be accurate to within 2 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
    • [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).

  • 7.4.2.6 Wi-Fi Keepalive Offload : Updated to add cellular keepalive offload requirements.

    See revision

    Device implementations:

    • SHOULD include support for Wi-Fi keepalive offload.

    If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi
      and at least one keepalive slot over cellular.

    If device implementations do not include support for Wi-Fi keepalive offload, they:

  • 7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.

    See revision

    7.4.2.9 Trust On First Use (TOFU)

    If device implementations support Trust on first usage (TOFU) and allow the user to define WPA/WPA2/WPA3-Enterprise configurations, then they:

    • [C-4-1] MUST provide the user an option to select to use TOFU.

  • 7.4.3 Bluetooth : Update to Bluetooth requirements.

    See revision

    If device implementations support Bluetooth Audio profile, they:

    • SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.

    If device implementations return true for the BluetoothAdapter.isLeAudioSupported() API, then they:

    • [C-7-1] MUST support unicast client.
    • [C-7-2] MUST support 2M PHY.
    • [C-7-3] MUST support LE Extended advertising.
    • [C-7-4] MUST support at least 2 CIS connections in a CIG.
    • [C-7-5] MUST enable BAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.
    • [C-SR] Are STRONGLY RECOMMENDED to enable HAP unicast client.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, then they:

    • [C-8-1] MUST support at least 2 BIS links in a BIG.
    • [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
    • [C-8-3] MUST support LE Periodic advertising.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, then they:

    • [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
    • [C-9-2] MUST support LE Periodic advertising.

    If device implementations declare FEATURE_BLUETOOTH_LE , they:

    • [C-10-1] MUST have RSSI measurements be within +/-9dB for 95% of the measurements at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH in line of sight environment.
    • [C-10-2] MUST include Rx/Tx corrections to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +/-3dB of one another for 95% of the measurements.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.

    Es wird DRINGEND EMPFOHLEN, die Schritte zur Einrichtung der Messung zu befolgen, die in Voraussetzungen für die Anwesenheitskalibrierung angegeben sind.

    If device implementations support Bluetooth version 5.0, then they:

    • [C-SR] Are STRONGLY RECOMMENDED to provide support for:
      • LE 2M PHY
      • LE Codec PHY
      • LE Advertising Extension
      • Periodic advertising
      • At least 10 advertisement sets
      • At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
      • LE Link Layer Privacy
      • A "resolving list" size of at least 8 entries

  • 7.4.9 UWB : Added a requirements section for UWB hardware.

    See revision

    7.4.9. UWB

    If device implementations report support for feature android.hardware.uwb via the android.content.pm.PackageManager class, then they:

    • [C-1-1] MUST ensure the distance measurements are within +/-15 cm for 95% of the measurements in the line of sight environment at 1m distance in a non-reflective chamber.
    • [C-1-2] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT held face up and tilted 45 degrees.

    Es wird DRINGEND EMPFOHLEN, die Schritte zur Einrichtung der Messung zu befolgen, die in Voraussetzungen für die Anwesenheitskalibrierung angegeben sind.

  • 7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.

    See revision

    If device implementations support HDR 10-bit output capability, then they:

    • [C-2-1] MUST support at least the HLG HDR profile for every camera device that supports 10-bit output.
    • [C-2-2] MUST support 10-bit output for either the primary rear-facing or the primary front-facing camera.
    • [C-SR] Are STRONGLY RECOMMENDED to support 10-bit output for both primary cameras.
    • [C-2-3] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.

    For Logical camera devices which support 10-bit HDR that implement the android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, they:

    • [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the CONTROL_ZOOM_RATIO control on the logical camera.

  • 7.7.2 USB Host Mode : Revisions for dual role ports.

    See revision

    If device implementations include a USB port supporting host mode and USB Type-C, they:

    • [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.

  • 7.11 Media Performance Class : Updated to include Android T.

    See revision

    If device implementations return non-zero value for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , they:

    • [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .

    In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.

    See section 2.2.7 for device-specific requirements.

9. Security Model Compatibility

  • 9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.

    See revision

    • [C-0-2] Permissions with a protectionLevel of PROTECTION_FLAG_PRIVILEGED MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in the etc/permissions/ path and using the system/priv-app path as the privileged path.

  • 9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.

    See revision

    Kernel integrity and self-protection features are integral to Android security. Device implementations:

    • [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables ( CONFIG_INIT_STACK_ALL or CONFIG_INIT_STACK_ALL_ZERO ). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.

  • 9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.

    See revision

    Device implementations:

    • [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the ClipboardManager API) unless the 3rd-party app is the default IME or is the app that currently has focus.
    • [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.

  • 9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms.

    See revision

    When the device implementation supports a secure lock screen, it:

    • [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH (if IKeyMintDevice is supported), 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. Sichere Isolation MUSS alle potenziellen Mechanismen blockieren, durch die Kernel- oder Userspace-Code auf den internen Zustand der isolierten Umgebung zugreifen könnte, einschließlich DMA. Das Upstream-Android-Open-Source-Projekt (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty- Implementierung, aber eine andere ARM-TrustZone-basierte Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer ordnungsgemäßen Hypervisor-basierten Isolierung sind alternative Optionen.

  • 9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.

    See revision

    If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:

    • [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.

    If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via VirtualDeviceManager , they:

    • [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.

    If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager , they:

    • [C-10-1] MUST support separate lock states per virtual device
    • [C-10-2] MUST disconnect all virtual devices upon idle timeout
    • [C-10-3] MUST have an idle timeout
    • [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
    • [C-10-5] MUST have separate virtual device instances per user
    • [C-10-6] MUST disable the creation of associated input events via VirtualDeviceManager when indicated by DevicePolicyManager.setNearbyAppStreamingPolicy
    • [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
    • [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
    • [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
    • [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See KeyGenParameterSpec.Builder.setUserAuthentication* .

    When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:

    • [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in the Google Cloud Key Vault Service security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
    • [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
    • [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.

    If device implementations have a secure lock screen and include one or more trust agents, which call the TrustAgentService.grantTrust() System API with the FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE flag they:

    • [C-12-1] MUST only call grantTrust() with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement.
    • [C-12-2] MUST put the device implementation into the TrustState.TRUSTABLE state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement.
    • [C-12-3] MUST only move the device from TrustState.TRUSTABLE to the TrustState.TRUSTED state if the TrustAgent is still granting trust based on the requirements in C-12-1.
    • [C-12-4] MUST call TrustManagerService.revokeTrust() after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.

    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-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to false from being started on the virtualdevice.
    • [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.
    • [C-13-10] MUST disable installation of apps initiated from virtual devices.

  • 9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.

    See revision

    To validate compliance with [C-1-3] through [C-1-9], device implementations:

    • [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will become a MUST requirement in Android 14 (AOSP experimental).

  • 9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.

    See revision

    The Identity Credential System is defined and achieved by implementing all APIs in the android.security.identity.* package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:

    The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.

  • 9.11.4 ID Attestation : Added a section for ID attestation requirement.

    See revision

    9.11.4. ID Attestation

    Device implementations MUST support ID attestation .

  • 9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.

    See revision

    9.17. Android Virtualization Framework

    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.
    • [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 NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
    • [C-1-5] MUST NOT allow a Protected Virtual Machine 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.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then any Protected Virtual Machine instance:

    • [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
    • [C-2-2] MUST NOT allow a Protected Virtual Machine 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 Machine 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 Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
    • [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
    • [C-2-7] MUST ensure that the pVM firmware refuses to 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 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 VM and before it is returned to the host (eg the pVM is destroyed).
    • [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
    • [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.

    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 support Isolated Compilation 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-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.

Back to top

,

Android 13

October 19, 2022

2. Device Types

  • 2.2.3 Software

    See revision

    Wenn Handheld-Geräteimplementierungen nicht im Lock-Task-Modus ausgeführt werden, gilt Folgendes, wenn Inhalte in die Zwischenablage kopiert werden:

    • [3.8.17/H-1-1] MUST present a confirmation to the user that data has been copied to the clipboard (eg, a thumbnail or alert of “Content copied.”). Additionally, include here an indication if clipboard data will be synced across devices.

3. Software

  • 3.2.3.5. Conditional Application Intents

    See revision

    If device implementation's Settings application implements a split functionality , using activity embedding, then they:

    If device implementations support the VoiceInteractionService and have more than one application using this API installed at a time, they:

  • 3.4.1 Webview Compatibility

    See revision

    • [C-1-4] MUST render the' provided content or remote URL content in a process that is distinct from the application that instantiates the WebView. Specifically the separate renderer process MUST hold lower privilege, run as a separate user ID, have no access to the app's data directory, have no direct network access, and only have access to the minimum-required system services over Binder. The AOSP implementation of WebView meets this requirement.

7. Hardware Compatibility

  • 7.4.2 IEEE 802.11 (Wi-Fi)

    See revision

    If device implementations include support for Wi-Fi power save mode as defined in IEEE 802.11 standard, they:

  • 7.4.3 Bluetooth

    See revision

    If device implementations include support for Bluetooth Low Energy (BLE), they:

    • [C-3-5] MUST implement a Resolvable Private Address (RPA) timeout no longer than 15 minutes and rotate the address at timeout to protect user privacy when device is actively using BLE for scanning or advertising. To prevent timing attacks, timeout intervals MUST also be randomized between 5 and 15 minutes.

  • 7.5.5 Camera Orientation

    See revision

    If device implementations have a front- or a rear-facing camera, such camera(s):

    • [C-1-1] MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

    Devices that fulfill all of the following criteria are exempt from the requirement above:

    • The device implements variable-geometry screens, such as foldable or hinged displays.
    • When the device's fold or hinge state changes, the device switches between portrait-primary to landscape-primary (or vice-versa) orientations.

9. Security Model Compatibility

  • 9.11 Keys and Credentials

    See revision

    When the device implementation supports a secure lock screen, it:

    • [C-1-6] MUST support IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice version 1 or IKeyMintDevice version 2.

  • 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-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.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then any Protected Virtual Machine instance:

    • [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).

    If the device implements support for the Android Virtualization Framework APIs, then for Key Management:

    • [C-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.

August 15, 2022

2. Device Types

  • 2.2.1 Hardware : Changes to hardware requirements as follows.

    • Input devices:

      See revision

      Implementierungen von Handheld-Geräten:

      • [ 7.2 .3/H-0-5] MUST call OnBackInvokedCallback.onBackStarted() on the current focused window when the back gesture starts or the back button ( KEYCODE_BACK ) is pressed DOWN.
      • [ 7.2.3 /H-0-6] MUSS OnBackInvokedCallback.onBackInvoked() aufrufen, wenn die Zurück-Geste festgeschrieben oder die Zurück-Schaltfläche losgelassen wird (UP).
      • [ 7.2 .3/H-0-7] MUST call OnBackInvokedCallback.onBackCancelled() when the back gesture is not committed or the KEYCODE_BACK event is canceled.

      Wenn Geräte das WiFi Neighbor Awareness Networking (NAN)-Protokoll durch Deklaration von PackageManager.FEATURE_WIFI_AWARE und Wi-Fi Location (Wi-Fi Round Trip Time – RTT) durch Deklaration von PackageManager.FEATURE_WIFI_RTT unterstützen, dann:

      • [ 7.4.2.5/H-1-1 ] MUSS die Reichweite innerhalb von +/-1 Meter bei 160 MHz Bandbreite beim 68. Perzentil (wie mit der kumulativen Verteilungsfunktion berechnet) genau melden, +/-2 Meter bei 80 MHz Bandbreite beim 68. Perzentil, +/-4 Meter bei 40 MHz Bandbreite beim 68. Perzentil und +/-8 Meter bei 20 MHz Bandbreite beim 68. Perzentil bei Abständen von 10 cm, 1 m, 3 m und 5 m, wie beobachtet über die WifiRttManager#startRanging Android API .

      • [ 7.4 .2.5/H-SR] Are STRONGLY RECOMMENDED to report the range accurately to within +/-1 meter at 160 MHz bandwidth at the 90th percentile (as calculated with the Cumulative Distribution Function), +/-2 meters at 80 MHz bandwidth at the 90th percentile, +/-4 meters at 40 MHz bandwidth at the 90th percentile, and +/-8 meters at 20 MHz bandwidth at the 90th percentile at distances of 10 cm, as observed via the WifiRttManager#startRanging Android API .

      Es wird DRINGEND EMPFOHLEN, die Schritte zur Einrichtung der Messung zu befolgen, die in Voraussetzungen für die Anwesenheitskalibrierung angegeben sind.

    • Audio latency:

      See revision

      Wenn Handheld-Geräteimplementierungen android.hardware.audio.output und android.hardware.microphone deklarieren, dann:

      • [ 5.6 /H-1-1] MUST have a Mean Continuous Round-Trip latency of 500 800 milliseconds or less over 5 measurements, with a Mean Absolute Deviation less than 50 100 ms, over the following data paths: "speaker to microphone", 3.5 mm loopback adapter (if supported), USB loopback (if supported). at least one supported path.

      • [ 5.6 /H-1-1] MUST have an average Tap-to-tone latency of 500 milliseconds or less over at least 5 measurements over the speaker to microphone data path.

    • Haptic inputs:

      See revision

      Wenn Implementierungen von Handgeräten mindestens einen haptischen Aktuator umfassen, dann:

      • [ 7.10 /H]* SOLLTE KEINEN haptischen Aktuator (Vibrator) mit exzentrischer rotierender Masse (ERM) verwenden.
      • [ 7.10 /H]* SOLLTE den Betätiger 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]* SOLLTEN alle öffentlichen Konstanten für klare Haptik in android.view implementieren. HapticFeedbackConstants nämlich (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START und GESTURE_END).
      • [ 7.10 /H]* SHOULD implement all public constants for clear haptics in android.os.VibrationEffect namely (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK and EFFECT_DOUBLE_CLICK) and all feasible public PRIMITIVE_* constants for rich haptics in android.os.VibrationEffect.Composition namely (PRIMITIVE_CLICK and PRIMITIVE_TICK) (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Some of these primitives, such as LOW_TICK and SPIN may only be feasible if the vibrator can support relatively low frequencies.

      • [ 7.10 /H]* SHOULD use these linked haptic constants mappings .

      Wenn Implementierungen von Handgeräten mindestens einen linearen Resonanzaktuator enthalten, dann:

      • [ 7.10 /H]* SHOULD move the haptic actuator in the X-axis (left-right) of portrait orientation.

      • [ 7.10 /H]* SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.

      • [7.10/H]* SHOULD provide fallback support to mitigate the risk of failure as described here .

  • 2.2.3 Software :

    • Auth Trivial Device Cotntrols:

      See revision

      • [ 3.8 .16/H-1-5] MUST provide a user affordance to opt out of app designated auth-trivial device controls from the controls registered by the third-party applications through the ControlsProviderService and the Control Control.isAuthRequired API.

    • MediaStyle Notifications:

      See revision

      Wenn Handheld-Geräteimplementierungen MediaStyle-Benachrichtigungen unterstützen, dann:

      • [3.8.3.1/H-1-SR] Are STRONGLY RECOMMENDED to provide a user affordance(eg “output switcher”) accessed from system UI that allows users to switch among appropriate available media routes(eg bluetooth devices and routes provided to MediaRouter2Manager ) when an app posts a MediaStyle notification with a MediaSession token .

  • 2.2.4 Performance and Power : New requirement for apps that run foreground services.

    See revision

    Implementierungen von Handheld-Geräten:

    • [ 8.5 /H-0-1] MUSS einem Benutzer im Einstellungsmenü die Möglichkeit bieten, eine App zu stoppen, die einen Vordergrunddienst ausführt, und alle Apps mit aktiven Vordergrunddiensten sowie die Dauer jedes dieser Dienste seither anzuzeigen wie im SDK-Dokument beschrieben gestartet.
      • Einige Apps KÖNNEN davon ausgenommen sein, angehalten oder in einem solchen Benutzerangebot aufgeführt zu werden, wie im SDK-Dokument beschrieben.

  • 2.2.7.1 Media : Updates to the Handheld Requirements Media section as follows:

    See revision

    Wenn Handheld-Geräteimplementierungen android.os.Build.VERSION_CODES.T für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, dann:

    • [5.1/H-1-1] MUSS über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() die maximale Anzahl von Hardware-Videodecoder-Sitzungen ankündigen, die gleichzeitig in einer beliebigen Codec-Kombination ausgeführt werden können.
    • [5.1/H-1-2] MUSS 6 Instanzen von Hardware-Videodecodersitzungen (AVC, HEVC, VP9, ​​AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt werden.
    • [5.1/H-1-3] MUSS die maximale Anzahl von Hardware-Video-Encoder-Sitzungen ankündigen, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() ausgeführt werden können.
    • [5.1/H-1-4] MUSS 6 Instanzen von Hardware-Video-Encoder-Sitzungen (AVC, HEVC, VP9, ​​AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt werden.
    • [5.1/H-1-5] MUSS die maximale Anzahl von Hardware-Video-Encoder- und -Decoder-Sitzungen ankündigen, die gleichzeitig in einer beliebigen Codec-Kombination über die Methoden CodecCapabilities.getMaxSupportedInstances() und VideoCapabilities.getSupportedPerformancePoints() ausgeführt werden können.
    • [5.1/H-1-6] MUSS 6 Instanzen von Sitzungen mit Hardware-Videodecoder und Hardware-Videoencoder (AVC, HEVC, VP9, ​​AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt werden.
    • [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. Das Laden ist hier definiert als eine gleichzeitige 1080p-zu-720p-Nur-Video-Transcodierungssitzung unter Verwendung von Hardware-Video-Codecs zusammen mit der 1080p-Audio-Video-Aufzeichnungsinitialisierung.
    • [5.1/H-1-8] MUSS eine Codec-Initialisierungslatenz von 30 ms oder weniger für eine Audiokodierungssitzung mit 128 kbps oder niedrigerer Bitrate für alle Audiokodierer unter Last haben. Das Laden ist hier definiert als eine gleichzeitige 1080p-zu-720p-Nur-Video-Transcodierungssitzung unter Verwendung von Hardware-Video-Codecs zusammen mit der 1080p-Audio-Video-Aufzeichnungsinitialisierung.
    • [5.1/H-1-9] MUSS 2 Instanzen sicherer Hardware-Videodecodersitzungen (AVC, HEVC, VP9, ​​AV1 oder höher) in einer beliebigen Codec-Kombination unterstützen, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt werden.
    • [5.1/H-1-10] MUSS 3 Instanzen nicht sicherer Hardware-Videodecodersitzungen zusammen mit 1 Instanz sicherer Hardware-Videodecodersitzung (insgesamt 4 Instanzen) (AVC, HEVC, VP9, ​​AV1 oder höher) in einem beliebigen Codec unterstützen Kombination, die gleichzeitig mit einer Auflösung von 1080p bei 30 fps ausgeführt wird.
    • [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 Videodecoder-Initialisierungslatenz von 40 ms oder weniger haben.
    • [5.1/H-1-13] MUSS eine Audiodecoder-Initialisierungslatenz von 30 ms oder weniger haben.
    • [5.1/H-1-14] MUSS AV1-Hardwaredecoder Main 10, Level 4.1 unterstützen.
    • [5.1/H-SR] Are Strongly Recommended to support Film Grain for AV1 hardware decoder.
    • [5.1/H-1-15] MUSS mindestens 1 Hardware-Videodecoder haben, der 4K60 unterstützt.
    • [5.1/H-1-16] MUSS mindestens 1 Hardware-Videoencoder haben, der 4K60 unterstützt.
    • [5.3/H-1-1] DARF NICHT mehr als 1 Frame in 10 Sekunden (dh weniger als 0,167 Prozent Frame-Drop) für eine 1080p-60-fps-Videositzung unter Last verlieren. Laden ist definiert als eine gleichzeitige 1080p- bis 720p-Nur-Video-Transcodierungssitzung mit Hardware-Video-Codecs sowie eine 128-kbps-AAC-Audiowiedergabe.
    • [5.3/H-1-2] DÜRFEN NICHT mehr als 1 Frame in 10 Sekunden während einer Änderung der Videoauflösung in einer 60-fps-Videositzung unter Last verlieren. Laden ist definiert als eine gleichzeitige 1080p- bis 720p-Nur-Video-Transcodierungssitzung mit Hardware-Video-Codecs sowie eine 128-kbps-AAC-Audiowiedergabe.
    • [5.6/H-1-1] MUSS eine Tap-to-Tone-Latenz von 80 Millisekunden oder weniger haben, wenn der OboeTester-Tap-to-Tone-Test oder der CTS-Verifier-Tap-to-Tone-Test verwendet wird.
    • [5.6/H-1-2] MUSS eine Round-Trip-Audiolatenz von 80 Millisekunden oder weniger über mindestens einen unterstützten Datenpfad 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 niedrige Latenz- und Streaming-Konfigurationen unterstützt wird. Für die Konfiguration mit niedriger Latenz sollte AAudio von der App im Rückrufmodus mit niedriger Latenz verwendet werden. Für die Streaming-Konfiguration sollte ein Java AudioTrack von der App verwendet werden. Sowohl in den Konfigurationen mit niedriger Latenz als auch in den Streaming-Konfigurationen sollte die HAL-Ausgabesenke entweder AUDIO_FORMAT_PCM_24_BIT , AUDIO_FORMAT_PCM_24_BIT_PACKED , AUDIO_FORMAT_PCM_32_BIT oder AUDIO_FORMAT_PCM_FLOAT als Zielausgabeformat akzeptieren.
    • [5.6/H-1-4] 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 klassenkonforme MIDI-Geräte unterstützen und das MIDI-Feature-Flag deklarieren.
    • [5.7/H-1-2] MUSS MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL mit den unten aufgeführten Fähigkeiten zur Inhaltsentschlüsselung unterstützen.
    Minimale Stichprobengröße 4 MiB
    Mindestanzahl an Teilproben – H264 oder HEVC 32
    Minimale Anzahl von Subsamples - VP9 9
    Minimale Anzahl von Subsamples - AV1 288
    Minimale Subsample-Puffergröße 1 MiB
    Minimale generische Krypto-Puffergröße 500 KB
    Mindestanzahl gleichzeitiger Sitzungen 30
    Mindestanzahl von Schlüsseln pro Sitzung 20
    Minimale Gesamtanzahl an Schlüsseln (alle Sitzungen) 80
    Minimale Gesamtzahl von DRM-Schlüsseln (alle Sitzungen) 6
    Nachrichtengröße 16 KiB
    Entschlüsselte Frames pro Sekunde 60 fps

  • 2.2.7.2 Camera : Updates to the Media Performance Class Camera requirements.

    See revision

    Wenn Handheld-Geräteimplementierungen android.os.Build.VERSION_CODES.T für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, dann:

    • [7.5/H-1-1] MUSS eine primäre nach hinten gerichtete Kamera mit einer Auflösung von mindestens 12 Megapixeln haben, die Videoaufnahmen mit 4k@30fps 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 eine primäre Frontkamera mit einer Auflösung von mindestens 5 Megapixeln haben und Videoaufnahmen mit 1080p@30fps unterstützen. Die primäre Frontkamera ist die Frontkamera mit der niedrigsten Kamera-ID.
    • [7.5/H-1-3] MUSS die Eigenschaft android.info.supportedHardwareLevel für beide primären Kameras als FULL oder besser unterstützen.
    • [7.5/H-1-4] MUSS CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME für beide primären Kameras unterstützen.
    • [7.5/H-1-5] MUSS eine JPEG-Erfassungslatenz von Kamera2 < 1000 ms für eine Auflösung von 1080p haben, gemessen durch den CTS-Kameraleistungstest unter ITS-Beleuchtungsbedingungen (3000K) für beide Hauptkameras.
    • [7.5/H-1-6] MUSS Kamera2-Startlatenz (Öffnen der Kamera bis zum ersten Vorschaubild) < 500 ms haben, gemessen durch den CTS-Kameraleistungstest unter ITS-Beleuchtungsbedingungen (3000 K) für beide Primärkameras.
    • [7.5/H-1-8] MUSS CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW und android.graphics.ImageFormat.RAW_SENSOR für die primäre Rückkamera unterstützen.
    • [7.5/H-1-9] MUSS eine nach hinten gerichtete Primärkamera haben, die 720p oder 1080p bei 240fps unterstützt.
    • [7.5/H-1-10] MUSS min. ZOOM_RATIO < 1.0 für die primären Kameras 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 Front- als auch für die primäre Rückkamera unterstützen.
    • [7.5/H-1-13] MUSS LOGICAL_MULTI_CAMERA Fähigkeit für die Primärkameras unterstützen, wenn mehr als 1 RGB-Kameras in die gleiche Richtung zeigen.
    • [7.5/H-1-14] MUSS STREAM_USE_CASE Fähigkeit sowohl für die primäre Front- als auch für die primäre Rückkamera unterstützen.

  • 2.2.7.3 Hardware : Updates to the Media Performance Class requirements for Hardware.

    See revision

    Wenn Handheld-Geräteimplementierungen android.os.Build.VERSION_CODES.T 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 Rasterdichte von mindestens 400 dpi haben.
    • [7.6.1/H-2-1] MUSS über mindestens 8 GB physischen Speicher verfügen.

  • 2.2.7.4 Performance : Updates to the Media Performance Class for Performance.

    See revision

    Wenn Handheld-Geräteimplementierungen android.os.Build.VERSION_CODES.T für android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS zurückgeben, dann:

    • [8.2/H-1-1] MUSS eine sequentielle Schreibleistung von mindestens 125 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 40 MB/s sicherstellen.

  • 2.5.1 Hardware : Updates to the 3-axis accelerometer and 3-axis gyroscope requirements, as well as the exterior-view camera requirements.

    See revision

    Implementierungen von Automobilgeräten:

    • [ 7.3.1 /A-0-4] MUSS dem Android- Autosensor-Koordinatensystem entsprechen.
    • [ 7.3 /A-SR] Are STRONGLY_RECOMMENDED to include a 3-axis accelerometer and 3-axis gyroscope.
    • [ 7.3 /A-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_HEADING sensor.

    Wenn Implementierungen von Automotive-Geräten einen Beschleunigungsmesser beinhalten, dann:

    • [ 7.3 .1/A-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 100 Hz melden können.

    Wenn Geräteimplementierungen einen 3-Achsen-Beschleunigungsmesser enthalten, haben sie:

    • [ 7.3 .1/A-SR] Are STRONGLY RECOMMENDED to implement the composite sensor for limited axes accelerometer.

    Wenn Implementierungen von Automotive-Geräten einen Beschleunigungsmesser mit weniger als 3 Achsen beinhalten, dann:

    • [ 7.3.1 /A-1-3] MUSS den Sensor TYPE_ACCELEROMETER_LIMITED_AXES implementieren und melden.
    • [ 7.3.1 /A-1-4] MUSS den Sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED implementieren und melden.

    Wenn Implementierungen von Automotive-Geräten ein Gyroskop enthalten, dann:

    • [ 7.3 .4/A-2-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 100 Hz melden können.
    • [ 7.3.4 /A-2-3] MUSS in der Lage sein, Orientierungsänderungen bis zu 250 Grad pro Sekunde zu messen.
    • [ 7.3 .4/A-SR] Are STRONGLY RECOMMENDED to configure the gyroscope's measurement range to +/-250dps in order to maximize the resolution possible.

    Wenn Implementierungen von Automotive-Geräten ein 3-Achsen-Gyroskop enthalten, dann:

    • [ 7.3 .4/A-SR] Are STRONGLY RECOMMENDED to implement the composite sensor for limited axes gyroscope.

    Wenn Implementierungen von Automotive-Geräten ein Gyroskop mit weniger als 3 Achsen beinhalten, dann:

    • [ 7.3.4 /A-4-1] MUSS den Sensor TYPE_GYROSCOPE_LIMITED_AXES implementieren und melden.
    • [ 7.3.4 /A-4-2] MUSS den Sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED implementieren und melden.

    Wenn Implementierungen von Automobilgeräten einen TYPE_HEADING Sensor enthalten, haben sie:

    • [ 7.3.4 /A-4-3] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 1 Hz melden können.
    • [ 7.3 .4/A-SR] STRONGLY_RECOMMENDED to report events up to a frequency of at least 10 Hz.
    • SOLLTE sich auf den wahren Norden beziehen.
    • MUSS auch bei stehendem Fahrzeug verfügbar sein.
    • SOLLTE eine Auflösung von mindestens 1 Grad haben.

    An exterior view camera is a camera that images scenes outside of the device implementation, like the rearview camera a dashcam .

    Wenn Implementierungen von Kraftfahrzeuggeräten eine Außensichtkamera enthalten, gilt für eine solche Kamera Folgendes:

    • [ 7.5 .5/A-SR] Are STRONGLY RECOMMENDED to be oriented so that the long dimension of the camera aligns with the horizon.

    • SHOULD support Android synchronization framework .

    • MÖGLICHERWEISE ist entweder ein Hardware-Autofokus oder ein Software-Autofokus im Kameratreiber implementiert.

    Wenn Implementierungen von Kraftfahrzeuggeräten eine oder mehrere Außensichtkameras enthalten und den Dienst Exterior View System (EVS) laden, dann gilt für eine solche Kamera Folgendes:

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

    Implementierungen von Automobilgeräten:

    • KÖNNEN eine oder mehrere Kameras enthalten, die Anwendungen von Drittanbietern zur Verfügung stehen.

    Wenn Implementierungen von Automobilgeräten mindestens eine Kamera enthalten und diese Anwendungen von Drittanbietern zur Verfügung stellen, dann:

    • [ 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 deklarieren .
    • KANN externe Kameras unterstützen, die in Abschnitt 7.5.3 beschrieben sind.
    • KÖNNEN Funktionen (wie Autofokus usw.) enthalten, die für nach hinten gerichtete Kameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.

  • 2.5.5 Security Model : New requirements for camera permissions for automotive devices.

    See revision

    If Automotive device implementations declare android.hardware.camera.any , then they:

    • [ 9.8.2 /A-2-1] MUST display the camera indicator when an app is accessing live camera data, but not when the camera is only being accessed by app(s) holding the roles called out in Section 9.1 Permissions with CDD identifier [C-3-X].

    • [ 9.8.2 /A-2-2] MUST not hide the camera indicator for system apps that have visible user interfaces or direct user interaction.

  • 2.6.1 Tablet Requirements — Hardware : Update to tablet screen size requirements.

    See revision

    Ein Android-Tablet-Gerät bezieht sich auf eine Android-Geräteimplementierung, die normalerweise alle folgenden Kriterien erfüllt:

    • Has a screen display size greater than 7” and less than 18", measured diagonally.

    Screen Size

    • [ 7.1 .1.1/Tab-0-1] MUST have a screen in the range of 7 to 18 inches.

3. Software

  • 3.2.2 Build Parameters : Updated ASCII characters in getSerial() .

    See revision

    • [C-0-1] To provide consistent, meaningful values across device implementations, the table below includes additional restrictions on the formats of these values to which device implementations MUST conform.
    Parameter Details
    getSerial() MUST (be or return) a hardware serial number, which MUST be available and unique across devices with the same MODEL and MANUFACTURER. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9]+$” .

  • 3.2.3.5 Conditional Application Intents : Update to requirements for conditional application intents.

    See revision

    If device implementations include a large display (generally having display width and height of 600dp+) and supports split functionality , then they:

  • 3.5.1 Application Restriction : Updates to application restrictions.

    See revision

    If device implementations implement a proprietary mechanism to restrict apps (eg changing or restricting API behaviors that are described in the SDK) and that mechanism is more restrictive than the Restricted App Standby Bucket , they:

    • [C-1-1] MUST allow the user to see the list of restricted apps.
    • [C-1-2] MUST provide user affordance to turn on / off all of these proprietary restrictions on each app.
    • [C-1-3] MUST not automatically apply these proprietary restrictions without evidence of poor system health behavior, but MAY apply the restrictions on apps upon detection of poor system health behavior like stuck wakelocks, long running services, and other criteria. The criteria MAY be determined by device implementers but MUST be related to the app's impact on the system health. Other criteria that are not purely related to the system health, such as the app's lack of popularity in the market, MUST NOT be used as criteria.
    • [C-1-4] MUST not automatically apply these proprietary restrictions for apps when a user has turned off app restrictions manually, and MAY suggest the user to apply these proprietary restrictions.

    • [C-1-5] MUST inform users if these proprietary restrictions are applied to an app automatically. Such information MUST be provided in the 24-hour period preceding the application of these proprietary restrictions.

    • [C-1-6] MUST return true for the ActivityManager.isBackgroundRestricted() method for any API calls from an app.

    • [C-1-7] MUST NOT restrict the top foreground app that is explicitly used by the user.

    • [C-1-8] MUST suspend these proprietary restrictions on an app whenever a user starts to explicitly use the app, making it the top foreground application.

    • [C-1-9] MUST report all these proprietary restrictions events via UsageStats.

    • [C-1-10] MUST provide a public and clear document or website that describes how proprietary restrictions are applied. This document or website MUST be linkable from the Android SDK documents and MUST include:

      • Triggering conditions for proprietary restrictions.
      • What and how an app can be restricted.
      • How an app can be exempted from such restrictions.
      • How an app can request an exemption from proprietary restrictions, if they support such an exemption for apps the user can install.

    If an app is pre-installed on the device and has never been explicitly used by a user for more than 30 days, [C-1-3] [C-1-5] are exempted.

  • 3.8.1 Launcher (Home Screen) : Updates to support for monochrome/adaptive-icon .

    See revision

    If device implementations support monochrome icons, these icons:

    • [C-6-1] MUST be used only when a user explicitly enables them (eg via Settings or wallpaper picker menu).

  • 3.8.2 Widgets : Update to third-party app widget presence in the Launcher.

    See revision

    If device implementations support third-party app widgets, they:

    • [C-1-2] MUST include built-in support for AppWidgets and expose user interface affordances to add, configure, view, and remove AppWidgets directly within the Launcher.

  • 3.8.3.1 Presentation of Notifications : Clarifying the definition of heads-up notifications.

    See revision

    Heads up notifications are notifications that are presented to the user as they come in independently of the surface the user is on.

  • 3.8.3.3 DND (Do not Disturb) / Priority Mode : Update to include Priority Mode in DND (Do Not Disturb) requirements.

    See revision

    3.8.3.3. DND (Do not Disturb) / Priority Mode

    If device implementations support the DND feature (also called Priority Mode), they:

  • 3.8.6 Themes : New requirements for dynamic color tonal palettes.

    See revision

    If device implementations include a screen or video output, they:

    • [C-1-4] MUST generate dynamic color tonal palettes as specified in the AOSP documentation of Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (see android.theme.customization.system_palette and android.theme.customization.theme_style ).

    • [C-1-5] MUST generate dynamic color tonal palettes using color theme styles enumerated in the Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES documentation (see android.theme.customization.theme_styles ), namely TONAL_SPOT , VIBRANT , EXPRESSIVE , SPRITZ , RAINBOW , FRUIT_SALAD .

      "Source color" used to generate dynamic color tonal palettes when sent with android.theme.customization.system_palette (as documented in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES ).

    • [C-1-6] MUST have a CAM16 chroma value of 5 or larger.

      • SHOULD be derived from the wallpaper via com.android.systemui.monet.ColorScheme#getSeedColors , which provides multiple valid source colors to pick one from.

      • SHOULD use the value 0xFF1B6EF3 , if none of the provided colors meet the above source color requirement.

  • 3.8.17 Clipboard : Added new requirements section for content on the clipboard.

    See revision

    3.8.17. Clipboard

    Device implementations:

    • [C-0-1] MUST NOT send clipboard data to any component, activity, service, or across any network connection, without explicit user action (eg, pressing a button on the overlay), except for services mentioned in 9.8.6 Content Capture and App Search .

    If device implementations generate a user-visible preview when content is copied to the clipboard for any ClipData item where ClipData.getDescription().getExtras() contains android.content.extra.IS_SENSITIVE , they:

    • [C-1-1] MUST redact the user visible preview

    The AOSP reference implementation satisfies these clipboard requirements.

  • 3.9.1.1 Device Owner Provisioning : Updates to device owner provisioning requirements.

    See revision

    If device implementations declare android.software.device_admin , they:

    • [C-1-1] MUST support enrolling a Device Policy Client (DPC) as a Device Owner app as described below:
      • When the device implementation has neither users nor user data configured, it:
        • [C-1-5] MUST enroll the DPC application as the Device Owner app or enable the DPC app to choose whether to become a Device Owner or a Profile Owner, if the device declares Near-Field Communications (NFC) support via the feature flag android.hardware.nfc and receives an NFC message containing a record with MIME type MIME_TYPE_PROVISIONING_NFC .
        • [C-1-8] MUST send the ACTION_GET_PROVISIONING_MODE intent after device owner provisioning is triggered so that the DPC app can choose whether to become a Device Owner or a Profile Owner, depending on the values of android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES , unless it can be determined from context that there is only one valid option. (such as for NFC based provisioning where Profile Owner provisioning is not supported).
        • [C-1-9] MUST send the ACTION_ADMIN_POLICY_COMPLIANCE intent to the Device Owner app if a Device Owner is established during provisioning regardless of the provisioning method used. The user must not be able to proceed in the Setup Wizard until the Device Owner app finishes.
      • When the device implementation has users or user data, it:
        • [C-1-7] MUST not enroll any DPC application as the Device Owner App any more.
    • [C-1-2] MUST show an appropriate disclosure notice (such as referenced in AOSP ) and obtain affirmative consent from the end user prior to an app being set as Device Owner, unless the device is programmatically configured for retail demo mode prior to on-screen, end-user interaction. require some affirmative action before or during the provisioning process to consent to an app being set as Device Owner. Consent can be via user action or by some programmatic means but appropriate disclosure notice (as referenced in AOSP) MUST be shown before device owner provisioning is initiated. Also, the programmatic device owner consent mechanism used (by enterprises) for device owner provisioning MUST NOT interfere with the Out-Of-Box Experience for non-enterprise use.
    • [C-1-3] MUST NOT hard code the consent or prevent the use of other device owner apps.

    If device implementations declare android.software.device_admin , but also include a proprietary Device Owner device management solution and provide a mechanism to promote an application configured in their solution as a "Device Owner equivalent" to the standard "Device Owner" as recognized by the standard Android DevicePolicyManager APIs, they:

    • [C-2-1] MUST have a process in place to verify that the specific app being promoted belongs to a legitimate enterprise device management solution and has been configured in the proprietary solution to have the rights equivalent as a "Device Owner".
    • [C-2-2] MUST show the same AOSP Device Owner consent disclosure as the flow initiated by android.app.action.PROVISION_MANAGED_DEVICE prior to enrolling the DPC application as "Device Owner".
    • [C-2-3] MUST NOT hard code the consent or prevent the use of other device owner apps.
    • MAY have user data on the device prior to enrolling the DPC application as "Device Owner".

  • 3.9.4 Device Management Role Requirements : Added a section for Device Management Role Requirements.

    See revision

    3.9.4 Device Policy Management Role Requirements

    If device implementations report android.software.device_admin or android.software.managed_users , then they:

    • [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting config_devicePolicyManagement to the package name. The package name MUST be followed by : and the signing certificate unless the application is preloaded.

    If a package name is not defined for config_devicePolicyManagement as described above:

    If a package name is defined for config_devicePolicyManagement as described above:

    • [C-3-1] The application MUST be installed on all profiles for a user .
    • [C-3-2] Device implementations MAY define an application that updates the device policy management role holder before provisioning by setting config_devicePolicyManagementUpdater .

    If a package name is defined for config_devicePolicyManagementUpdater as described above:

    • [C-4-1] The application MUST be preinstalled on the device.
    • [C-4-2] The application MUST implement an intent filter which resolves android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER .

  • 3.18 Contacts : Adding information for new contacts.

    See revision

    Default account for new contacts: Contacts Provider provides APIs to manage the setting of the default account when creating a new contact.

    If device implementations preload a contacts app, then the pre-loaded contacts app:

    • [C-2-1] MUST handle the intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT to launch a UI for account selection and save the setting to Contacts Provider when an account is selected.

    • [C-2-2] MUST honor the default account setting when handling Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT for the ContactsContracts.Contacts.CONTENT_TYPE and ContactsContract.RawContacts.CONTENT_TYPE by initially selecting the account.

4. Application Packaging Compatibility

5. Multimedia Compatibility

  • 5.1.2 Audio Decoding : Added new requirements for decoders capable of outputting mutli-channel audio.

    See revision

    If device implementations support the decoding of AAC input buffers of multichannel streams (ie more than two channels) to PCM through the default AAC audio decoder in the android.media.MediaCodec API, then the following MUST be supported:

    • [C-7-1] MUST be able to be configured by the application using the decoding with the key KEY_MAX_OUTPUT_CHANNEL_COUNT to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content.
    • [C-7-2] When decoding, the decoder MUST advertise the channel mask being used on the output format with the KEY_CHANNEL_MASK key, using the android.media.AudioFormat constants (example: CHANNEL_OUT_5POINT1 ).

    If device implementations support audio decoders other than the default AAC audio decoder and are capable of outputting multi-channel audio (ie more than 2 channels) when fed compressed multi-channel content, then:

    • [C-SR] The decoder is STRONGLY RECOMMENDED to be able to be configured by the application using the decoding with the key KEY_MAX_OUTPUT_CHANNEL_COUNT to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content.
    • [C-SR] When decoding, the decoder is STRONGLY RECOMMENDED to advertise the channel mask being used on the output format with the KEY_CHANNEL_MASK key, using the android.media.AudioFormat constants (example: CHANNEL_OUT_5POINT1 ).

  • 5.4.1 Raw Audio Capture and Microphone Information : Updates to supported audio sources for audio input streams.

    See revision

    If device implementations declare android.hardware.microphone , they:

  • 5.4.2 Capture for Voice Recognition : Updated requirements for voice recognition audio stream and added requirements for microphone gain levels.

    See revision

    If device implementations declare android.hardware.microphone , they:

    • SHOULD record the voice recognition audio stream with approximately flat amplitude versus frequency characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
    • SHOULD record the voice recognition audio stream with input sensitivity set such that a 90 dB sound power level (SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.

    • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 30 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

  • 5.4.6 Microphone Gain Levels : Moved requirements for Microphone Gain Levels to section 5.4.2.

    See revision

    5.4.6. Microphone Gain Levels [Moved to 5.4.2]

    If device implementations declare android.hardware.microphone , they:

    • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) yields a response with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

  • 5.5.4 Audio Offload : Updates to the audio offload playback requirements.

    See revision

    If device implementations support audio offload playback , they:

    • [C-SR] Are STRONGLY RECOMMENDED to trim the played gapless audio content between two clips with the same format when specified by the AudioTrack gapless API and the media container for MediaPlayer.

  • 5.6 Audio Latency : Updates to the audio latency requirements.

    See revision

    For the purposes of this section, use the following definitions:

    • cold output jitter . The variability among separate measurements of cold output latency values.
    • cold input jitter . The variability among separate measurements of cold input latency values.

    If device implementations declare android.hardware.audio.output , they MUST meet or exceed the following requirements:

    • [C-1-2] Cold output latency of 500 milliseconds or less.
    • [C-1-3] Opening an output stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations declare android.hardware.audio.output they are STRONGLY RECOMMENDED to meet or exceed the following requirements:

    • [C-SR] Cold output latency of 100 milliseconds or less over the speaker data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release, we will require Cold output latency of 200 ms or less as a MUST.
    • [C-SR] Minimize the cold output jitter.

    If device implementations include android.hardware.microphone , they MUST meet these input audio requirements:

    • [C-3-2] Cold input latency of 500 milliseconds or less.
    • [C-3-3] Opening an input stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations include android.hardware.microphone , they are STRONGLY RECOMMENDED to meet these input audio requirements:

    • [C-SR] Cold input latency of 100 milliseconds or less over the microphone data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release we will require Cold input latency of 200 ms or less as a MUST.

    • [C-SR] Continuous input latency of 30 milliseconds or less.
    • [C-SR] Minimize the cold input jitter.

  • 5.10 Professional Audio : Updates to audio latency requirements for professional audio support.

    See revision

    If device implementations report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class, they:

    • [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less and SHOULD be 10 milliseconds or less over at least one supported path.
    • [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY .
    • [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
    • [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
    • SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.

    If device implementations include a 4 conductor 3.5mm audio jack, they:

    • [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency , of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an audio loopback dongle .

  • 5.12 HDR Video : Added a new section for HDR Video requirements.

6. Developer Tools and Options Compatibility

  • 6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.

    See revision

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:

    • [C-4-1] MUST have the AdbManager#isAdbWifiSupported() method return true .

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:

    • [C-5-1] MUST have the AdbManager#isAdbWifiQrSupported() method return true .

    • GPU work information

      Device implementations:

      • [C-6-1] MUST implement the shell command dumpsys gpu --gpuwork to display the aggregated GPU work data returned by the power/gpu_work_period kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation is frameworks/native/services/gpuservice/gpuwork/ .

7. Hardware Compatibility

  • 7.1.4.1 OpenGL ES : Update to recommended extensions.

    See revision

    If device implementations support any of the OpenGL ES versions, they:

    • SHOULD support the EGL_IMG_context_priority and EGL_EXT_protected_content extensions.

  • 7.1.4.2 Vulkan : Updates to version supported for Vulkan.

    See revision

    If device implementations support OpenGL ES 3.1, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1
    • MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).

    If device implementations include a screen or video output, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1

    If device implementations include support for Vulkan 1.0 or higher, they:

    • SHOULD support VkPhysicalDeviceProtectedMemoryFeatures and VK_EXT_global_priority .
    • [C-1-12] MUST NOT enumerate support for the VK_KHR_performance_query extension.
    • [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.

  • 7.2.3 Navigation Keys :

    See revision

    Device implementations:

    • [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.

    If the back navigation function is provided and the user cancels the Back gesture, then:

    • [C-8-1] OnBackInvokedCallback.onBackCancelled() MUST be called.
    • [C-8-2] OnBackInvokedCallback.onBackInvoked() MUST NOT be called.
    • [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.

    If the back navigation function is provided but the foreground application does NOT have an OnBackInvokedCallback registered, then:

    • The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.

    If device implementations provide support for the system API setNavBarMode to allow any system app with android.permission.STATUS_BAR permission to set the navigation bar mode, then they:

    • [C-9-1] MUST provide support for kid-friendly icons or button-based navigation as provided in the AOSP code.

  • 7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.

    See revision

    If device implementations include an accelerometer, a 3-axis accelerometer, they:

    • [C-1-2] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [SR] are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [SR] are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    Wenn Geräteimplementierungen einen 3-Achsen-Beschleunigungsmesser enthalten, haben sie:

    • [C-2-1] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    If device implementations include an accelerometer with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_ACCELEROMETER_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis accelerometer and any of the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors are implemented:

    • [C-4-1] The sum of their power consumption MUST always be less than 4 mW.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

    If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:

    • [C-6-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

  • 7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.

    See revision

    If device implementations include a gyroscope, they:

    • [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
    • [C-1-4] MUST have a resolution of 12-bits or more.
    • [C-1-5] MUST be temperature compensated.
    • [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
    • [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
    • [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
    • [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
    • SHOULD report events up to at least 200 Hz.

    If device implementations include a 3-axis gyroscope, they:

    • [C-2-1] MUST implement the TYPE_GYROSCOPE sensor.

    If device implementations include a gyroscope with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_GYROSCOPE_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:

    • [C-4-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

  • 7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.

    See revision

    Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 . Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.

    If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience ), they:

    • [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.

    If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak ), they:

    • [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .

    If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong ), they:

    • [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .

  • 7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.

    See revision

    7.3.13. IEEE 802.1.15.4 (UWB)

    If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:

    • [C-1-1] MUST implement the corresponding Android API in android.uwb.
    • [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
    • [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
    • [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
    • [C-1-5] MUST enforce that apps using UWB radio hold UWB_RANGING permission (under NEARBY_DEVICES permission group).
    • [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .

  • 7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.

    See revision

    If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:

    If device implementations include GSM or CDMA telephony, then:

    If the device device implementations include GSM or CDMA telephony and provide a system status bar, then:

    • [C-6-7] MUST select a representative active subscription for a given group UUID to display to the user in any affordances that provide SIM status information. Examples of such affordances include the status bar cellular signal icon or quick settings tile.
    • [C-SR] It is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.

    If device implementations include GSM or CDMA telephony, then:

    • [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
    • [C-6-10] MUST NOT apply any of the following behaviors to active carrier apps (as designated by TelephonyManager#getCarrierServicePackageName ) automatically or without explicit user confirmation:
      • Revoke or limit network access
      • Revoke permissions
      • Restrict background or foreground app execution beyond the existing power management features included in AOSP
      • Disable or uninstall the app

    If device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:

    • [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.

    If device implementations include GSM telephony but not CDMA telephony, they:

    If the device implementations support eUICCs with multiple ports and profiles, they:

  • 7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.

    See revision

    If device implementations report the android.hardware.telephony feature , they:

    • [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with BLOCKED_TYPE out of the default call log view in the pre-installed dialer app.
    • SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.

  • 7.4.1.3 Cellular NAT-T Keepalive Offload : New section for Cellular NAT-T Keepalive Offload.

    See revision

    7.4.1.3. Cellular NAT-T Keepalive Offload

    Device implementations:

    • SHOULD include support for Cellular keepalive offload.

    If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least one concurrent keepalive slot over cellular.
    • [C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio HAL.
    • [C-SR] Are STRONGLY RECOMMENDED to support at least three cellular keepalive slots per radio instance.

    If device implementations do not include support for cellular keepalive offload, they:

    • [C-2-1] MUST return ERROR_UNSUPPORTED.

  • 7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.

    See revision

    If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:

    • [C-1-4] MUST be accurate to within 2 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
    • [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).

  • 7.4.2.6 Wi-Fi Keepalive Offload : Updated to add cellular keepalive offload requirements.

    See revision

    Device implementations:

    • SHOULD include support for Wi-Fi keepalive offload.

    If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi
      and at least one keepalive slot over cellular.

    If device implementations do not include support for Wi-Fi keepalive offload, they:

  • 7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.

    See revision

    7.4.2.9 Trust On First Use (TOFU)

    If device implementations support Trust on first usage (TOFU) and allow the user to define WPA/WPA2/WPA3-Enterprise configurations, then they:

    • [C-4-1] MUST provide the user an option to select to use TOFU.

  • 7.4.3 Bluetooth : Update to Bluetooth requirements.

    See revision

    If device implementations support Bluetooth Audio profile, they:

    • SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.

    If device implementations return true for the BluetoothAdapter.isLeAudioSupported() API, then they:

    • [C-7-1] MUST support unicast client.
    • [C-7-2] MUST support 2M PHY.
    • [C-7-3] MUST support LE Extended advertising.
    • [C-7-4] MUST support at least 2 CIS connections in a CIG.
    • [C-7-5] MUST enable BAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.
    • [C-SR] Are STRONGLY RECOMMENDED to enable HAP unicast client.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, then they:

    • [C-8-1] MUST support at least 2 BIS links in a BIG.
    • [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
    • [C-8-3] MUST support LE Periodic advertising.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, then they:

    • [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
    • [C-9-2] MUST support LE Periodic advertising.

    If device implementations declare FEATURE_BLUETOOTH_LE , they:

    • [C-10-1] MUST have RSSI measurements be within +/-9dB for 95% of the measurements at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH in line of sight environment.
    • [C-10-2] MUST include Rx/Tx corrections to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +/-3dB of one another for 95% of the measurements.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.

    Es wird DRINGEND EMPFOHLEN, die Schritte zur Einrichtung der Messung zu befolgen, die in Voraussetzungen für die Anwesenheitskalibrierung angegeben sind.

    If device implementations support Bluetooth version 5.0, then they:

    • [C-SR] Are STRONGLY RECOMMENDED to provide support for:
      • LE 2M PHY
      • LE Codec PHY
      • LE Advertising Extension
      • Periodic advertising
      • At least 10 advertisement sets
      • At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
      • LE Link Layer Privacy
      • A "resolving list" size of at least 8 entries

  • 7.4.9 UWB : Added a requirements section for UWB hardware.

    See revision

    7.4.9. UWB

    If device implementations report support for feature android.hardware.uwb via the android.content.pm.PackageManager class, then they:

    • [C-1-1] MUST ensure the distance measurements are within +/-15 cm for 95% of the measurements in the line of sight environment at 1m distance in a non-reflective chamber.
    • [C-1-2] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT held face up and tilted 45 degrees.

    Es wird DRINGEND EMPFOHLEN, die Schritte zur Einrichtung der Messung zu befolgen, die in Voraussetzungen für die Anwesenheitskalibrierung angegeben sind.

  • 7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.

    See revision

    If device implementations support HDR 10-bit output capability, then they:

    • [C-2-1] MUST support at least the HLG HDR profile for every camera device that supports 10-bit output.
    • [C-2-2] MUST support 10-bit output for either the primary rear-facing or the primary front-facing camera.
    • [C-SR] Are STRONGLY RECOMMENDED to support 10-bit output for both primary cameras.
    • [C-2-3] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.

    For Logical camera devices which support 10-bit HDR that implement the android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, they:

    • [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the CONTROL_ZOOM_RATIO control on the logical camera.

  • 7.7.2 USB Host Mode : Revisions for dual role ports.

    See revision

    If device implementations include a USB port supporting host mode and USB Type-C, they:

    • [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.

  • 7.11 Media Performance Class : Updated to include Android T.

    See revision

    If device implementations return non-zero value for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , they:

    • [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .

    In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.

    See section 2.2.7 for device-specific requirements.

9. Security Model Compatibility

  • 9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.

    See revision

    • [C-0-2] Permissions with a protectionLevel of PROTECTION_FLAG_PRIVILEGED MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in the etc/permissions/ path and using the system/priv-app path as the privileged path.

  • 9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.

    See revision

    Kernel integrity and self-protection features are integral to Android security. Device implementations:

    • [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables ( CONFIG_INIT_STACK_ALL or CONFIG_INIT_STACK_ALL_ZERO ). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.

  • 9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.

    See revision

    Device implementations:

    • [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the ClipboardManager API) unless the 3rd-party app is the default IME or is the app that currently has focus.
    • [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.

  • 9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms.

    See revision

    When the device implementation supports a secure lock screen, it:

    • [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH (if IKeyMintDevice is supported), 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. Sichere Isolation MUSS alle potenziellen Mechanismen blockieren, durch die Kernel- oder Userspace-Code auf den internen Zustand der isolierten Umgebung zugreifen könnte, einschließlich DMA. Das Upstream-Android-Open-Source-Projekt (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty- Implementierung, aber eine andere ARM-TrustZone-basierte Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer ordnungsgemäßen Hypervisor-basierten Isolierung sind alternative Optionen.

  • 9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.

    See revision

    If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:

    • [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.

    If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via VirtualDeviceManager , they:

    • [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.

    If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager , they:

    • [C-10-1] MUST support separate lock states per virtual device
    • [C-10-2] MUST disconnect all virtual devices upon idle timeout
    • [C-10-3] MUST have an idle timeout
    • [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
    • [C-10-5] MUST have separate virtual device instances per user
    • [C-10-6] MUST disable the creation of associated input events via VirtualDeviceManager when indicated by DevicePolicyManager.setNearbyAppStreamingPolicy
    • [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
    • [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
    • [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
    • [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See KeyGenParameterSpec.Builder.setUserAuthentication* .

    When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:

    • [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in the Google Cloud Key Vault Service security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
    • [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
    • [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.

    If device implementations have a secure lock screen and include one or more trust agents, which call the TrustAgentService.grantTrust() System API with the FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE flag they:

    • [C-12-1] MUST only call grantTrust() with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement.
    • [C-12-2] MUST put the device implementation into the TrustState.TRUSTABLE state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement.
    • [C-12-3] MUST only move the device from TrustState.TRUSTABLE to the TrustState.TRUSTED state if the TrustAgent is still granting trust based on the requirements in C-12-1.
    • [C-12-4] MUST call TrustManagerService.revokeTrust() after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.

    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-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to false from being started on the virtualdevice.
    • [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.
    • [C-13-10] MUST disable installation of apps initiated from virtual devices.

  • 9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.

    See revision

    To validate compliance with [C-1-3] through [C-1-9], device implementations:

    • [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will become a MUST requirement in Android 14 (AOSP experimental).

  • 9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.

    See revision

    The Identity Credential System is defined and achieved by implementing all APIs in the android.security.identity.* package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:

    The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.

  • 9.11.4 ID Attestation : Added a section for ID attestation requirement.

    See revision

    9.11.4. ID Attestation

    Device implementations MUST support ID attestation .

  • 9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.

    See revision

    9.17. Android Virtualization Framework

    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.
    • [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 NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
    • [C-1-5] MUST NOT allow a Protected Virtual Machine 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.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then any Protected Virtual Machine instance:

    • [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
    • [C-2-2] MUST NOT allow a Protected Virtual Machine 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 Machine 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 Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
    • [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
    • [C-2-7] MUST ensure that the pVM firmware refuses to 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 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 VM and before it is returned to the host (eg the pVM is destroyed).
    • [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
    • [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.

    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 support Isolated Compilation 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-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.

Back to top