Änderungsprotokoll zum Android-Kompatibilitätsdefinitionsdokument

Android 14

20. November 2023

2. Gerätetypen

  • 2.2.1. Hardware :

    Siehe Überarbeitung

    Wenn Handheld-Geräteimplementierungen die Unterstützung eines 64-Bit-ABI (mit oder ohne 32-Bit-ABI) erklären:

  • 2.2.7.2. Kamera :

    Siehe Überarbeitung

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

  • 2.3.2. Multimedia :

    Siehe Überarbeitung

    • [ 5.8 /T-0-1] MUSS den HDMI-Ausgabemodus auf die höchste Auflösung für das gewählte SDR- oder HDR-Format einstellen, das mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz für das externe Display funktioniert.

      Der HDMI-Ausgabemodus MUSS so eingestellt werden, dass die maximale Auflösung ausgewählt wird, die mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz unterstützt werden kann.

  • 2.4.5. Sicherheitsmodell :

    Siehe Überarbeitung

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

6. Kompatibilität von Entwicklertools und -optionen

  • 6.1. Entwicklerwerkzeuge :

    Siehe Überarbeitung

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

    Siehe Überarbeitung

    • [C-0-13] MUSS den Shell-Befehl dumpsys gpu --gpuwork zur Anzeige implementieren

9. Kompatibilität des Sicherheitsmodells

  • 9.7. Sicherheitsfunktionen :

    Siehe Überarbeitung

    Wenn Geräteimplementierungen einen Linux-Kernel verwenden, der SELinux unterstützen kann, gilt Folgendes:

    Siehe Überarbeitung

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

4. Oktober 2023

2. Gerätetypen

  • 2.2. Handheld-Anforderungen :

    Siehe Überarbeitung

    Android-Geräteimplementierungen werden als Handheld klassifiziert, wenn sie alle folgenden Kriterien erfüllen:

    • Sie müssen über eine physische Bildschirmdiagonale im Bereich von 4 Zoll 3,3 Zoll (oder 2,5 Zoll für Geräteimplementierungen, die auf API-Ebene 29 oder früher ausgeliefert wurden) bis 8 Zoll verfügen.

    Starten Sie neue Anforderungen

    • Verfügen Sie über eine Touchscreen-Eingabeschnittstelle.

  • 2.2.1. Hardware :

    Siehe Überarbeitung

    Implementierungen von Handheld-Geräten:

    • [ 7.1 .1.1/H-0-1] MUSS über mindestens ein Android-kompatibles Display verfügen, das alle in diesem Dokument beschriebenen Anforderungen erfüllt. Display, das an der kurzen Kante mindestens 2,2 Zoll und an der langen Kante mindestens 3,4 Zoll misst.

    Wenn Handheld-Geräteimplementierungen die Software-Bildschirmdrehung unterstützen, gilt Folgendes:

    • [ 7.1 .1.1/H-1-1]* MUSS dafür sorgen, dass der logische Bildschirm, der für Drittanwendungen zur Verfügung gestellt wird, mindestens 2 Zoll an der/den kurzen Kante(n) und 2,7 Zoll an der/den langen Kante(n) beträgt. Geräte, die mit Android API Level 29 oder früher ausgeliefert wurden, sind möglicherweise von dieser Anforderung ausgenommen.

    Wenn Handheld-Geräteimplementierungen keine Software-Bildschirmdrehung unterstützen, gilt Folgendes:

    • [ 7.1 .1.1/H-2-1]* MUSS dafür sorgen, dass der logische Bildschirm, der für Drittanwendungen zur Verfügung gestellt wird, an der/den kurzen Kante(n) mindestens 2,7 Zoll groß ist. Geräte, die mit Android API Level 29 oder früher ausgeliefert wurden, sind möglicherweise von dieser Anforderung ausgenommen.

    Starten Sie neue Anforderungen

    • [ 7.1 .1.1/H-0-3]* MUSS jede UI_MODE_NORMAL Anzeige, die für Drittanwendungen zur Verfügung gestellt wird, auf einen freien physischen Anzeigebereich abbilden, der mindestens 2,2 Zoll an der kurzen Kante und 3,4 Zoll an der langen Kante beträgt.

    • [ 7.1 .1.3/H-0-1]* MUSS den Wert von DENSITY_DEVICE_STABLE auf 92 % oder mehr als die tatsächliche physikalische Dichte der entsprechenden Anzeige einstellen.

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

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

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

    Wenn Handheld-Geräteimplementierungen mindestens einen haptischen Aktuator umfassen, gilt Folgendes:

    Wenn die Implementierung von Handgeräten mindestens einen Allzweck -7.10- Linearresonanzaktuator umfasst, gilt Folgendes:

    • [ 7.10 /H] SOLLTE den Aktuator in der Nähe der Stelle platzieren, an der das Gerät normalerweise mit den Händen gehalten oder berührt wird.

    • [ 7.10 /H] SOLLTE den haptischen Aktuator in der X-Achse (links-rechts) der natürlichen Hochformatausrichtung des Geräts bewegen.

    Wenn Handheld-Geräteimplementierungen über einen universellen haptischen Aktuator verfügen, bei dem es sich um einen X-Achsen-Linearresonanzaktor (LRA) handelt, gilt Folgendes:

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

  • 2.2.2. Multimedia :

    Siehe Überarbeitung

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

    • [ 5.2 /H-0-3] AV1

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

    • [ 5.3 /H-0-6] AV1

  • 2.2.3. Software :

    Siehe Überarbeitung

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

    • [ 3.8 .3/H-1-1] MUSS das Verhalten beim Anheften des Bildschirms implementieren und dem Benutzer ein Einstellungsmenü zum Umschalten der Funktion bereitstellen.

    Wenn Handheld-Geräteimplementierungen Unterstützung für ControlsProviderService und Control APIs umfassen und Drittanbieteranwendungen die Veröffentlichung von Gerätesteuerelementen ermöglichen, dann gilt Folgendes:

    • [ 3.8 .16/H-1-6] Geräteimplementierungen MÜSSEN das Benutzerangebot wie folgt genau wiedergeben:
      • Wenn das Gerät config_supportsMultiWindow=true festgelegt hat und die App die Metadaten META_DATA_PANEL_ACTIVITY in der ControlsProviderService Deklaration deklariert, einschließlich des Komponentennamens einer gültigen Aktivität (wie durch die API definiert), dann MUSS die App diese Aktivität in dieses Benutzerangebot einbetten.
      • Wenn die App keine Metadaten META_DATA_PANEL_ACTIVITY deklariert, MUSS sie die angegebenen Felder so rendern, wie sie von der ControlsProviderService API bereitgestellt werden, sowie alle angegebenen Felder, die von den Control- APIs bereitgestellt werden.
    • [ 3.8 .16/H-1-7] Wenn die App die Metadaten META_DATA_PANEL_ACTIVITY deklariert, MUSS sie beim Starten der eingebetteten Aktivität den Wert der in [3.8.16/H-1-5] definierten Einstellung mit EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS übergeben.

    Wenn Geräteimplementierungen es Benutzern ermöglichen, Anrufe jeglicher Art zu tätigen, können sie

  • 2.2.4. Leistung und Leistung :

    Siehe Überarbeitung

    Implementierungen von Handheld-Geräten:

    • [ 8.5 /H-0-1] MUSS ein Benutzerangebot im Menü „Einstellungen“ bereitstellen, um alle Apps mit aktiven Vordergrunddiensten oder vom Benutzer initiierten Jobs anzuzeigen, einschließlich der Dauer jedes dieser Dienste seit seinem Start, wie im SDK-Dokument beschrieben . und die Möglichkeit, eine App zu stoppen, die einen Vordergrunddienst oder einen vom Benutzer initiierten Job ausführt. mit der Möglichkeit, eine App zu stoppen, die einen Vordergrunddienst ausführt, und alle Apps anzuzeigen, die über aktive Vordergrunddienste verfügen, sowie die Dauer jedes dieser Dienste seit dem Start, wie im SDK-Dokument beschrieben.
      • Einige Apps können möglicherweise vom Stoppen oder der Auflistung in einem solchen Benutzerangebot ausgenommen werden, wie im SDK-Dokument beschrieben.

  • [ 8.5 /H-0-2]MUSS dem Benutzer die Möglichkeit bieten, eine App zu stoppen, die einen Vordergrunddienst oder einen vom Benutzer initiierten Job ausführt.