Kompatibilitätsdefinition für Android 8.1

1. Einführung

In diesem Dokument werden die Anforderungen aufgeführt, die erfüllt sein müssen, damit Geräte mit Android 8.1 kompatibel sind.

Die Verwendung von „MUSS“, „MÜSSEN“, „DARF NICHT“, „DÜRFEN NICHT“, „DARF“, „DÜRFEN“, „SOLLTE“, „SOLLTEN“, „SOLLTE NICHT“, „SOLLTEN NICHT“, „EMPFOHLEN“ sowie „KANN“ und „KÖNNEN“ folgt dem IETF-Standard RFC2119.

In diesem Dokument bezeichnet „Geräteimplementierer“ oder „Implementierer“ eine Person oder Organisation, die eine Hardware-/Softwarelösung mit Android 8.1 entwickelt. Eine „Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte Hardware-/Softwarelösung.

Damit Geräteimplementierungen als mit Android 8.1 kompatibel gelten, MÜSSEN sie die in dieser Kompatibilitätsdefinition enthaltenen Anforderungen erfüllen, einschließlich aller Dokumente, die per Verweis einbezogen werden.

Wenn diese Definition oder die in Abschnitt 10 beschriebenen Softwaretests nicht eindeutig, mehrdeutig oder unvollständig sind, liegt es in der Verantwortung des Geräteherstellers, die Kompatibilität mit bestehenden Implementierungen sicherzustellen.

Aus diesem Grund ist das Open-Source-Projekt für Android sowohl die Referenz- als auch die bevorzugte Implementierung von Android. Geräteherstellern wird DRINGEND EMPFOHLEN, ihre Implementierungen so weit wie möglich auf dem „Upstream“-Quellcode zu basieren, der im Android Open Source Project verfügbar ist. Einige Komponenten können theoretisch durch alternative Implementierungen ersetzt werden. Es wird jedoch DRINGEND EMPFOHLEN, dies nicht zu tun, da das Bestehen der Softwaretests dadurch erheblich erschwert wird. Es liegt in der Verantwortung des Implementierers, für vollständige Verhaltenskompatibilität mit der Standard-Android-Implementierung zu sorgen, einschließlich und über die Compatibility Test Suite hinaus. Bestimmte Komponenten dürfen nicht ersetzt oder modifiziert werden.

Viele der in diesem Dokument verlinkten Ressourcen stammen direkt oder indirekt aus dem Android SDK und sind funktional identisch mit den Informationen in der Dokumentation dieses SDKs. In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Compatibility Test Suite von der SDK-Dokumentation abweicht, gilt die SDK-Dokumentation als maßgeblich. Alle technischen Details, die in den verlinkten Ressourcen in diesem Dokument enthalten sind, gelten durch die Einbeziehung als Teil dieser Kompatibilitätsdefinition.

1.1 Dokumentstruktur

1.1.1. Anforderungen nach Gerätetyp

Abschnitt 2 enthält alle MUST- und STRONGLY RECOMMENDED-Anforderungen, die für einen bestimmten Gerätetyp gelten. Jeder Unterabschnitt von Abschnitt 2 ist einem bestimmten Gerätetyp gewidmet.

Alle anderen Anforderungen, die universell für alle Android-Geräteimplementierungen gelten, sind in den Abschnitten nach Abschnitt 2 aufgeführt. In diesem Dokument werden diese Anforderungen als „Kernanforderungen“ bezeichnet.

1.1.2. Anforderungs-ID

Für MUST-Anforderungen wird eine Anforderungs-ID zugewiesen.

• Die ID wird nur für MUST-Anforderungen zugewiesen.
• Anforderungen, die DRINGEND EMPFOHLEN werden, sind mit [SR] gekennzeichnet, aber es wird keine ID zugewiesen.
• Die ID besteht aus : Geräte-ID – Bedingungs-ID – Anforderungs-ID (z.B. C-0-1).

Jede ID wird so definiert:

• Gerätetyp-ID (siehe 2. Gerätetypen
  • C: Core (Anforderungen, die für alle Android-Geräteimplementierungen gelten)
  • H: Android-Mobilgerät
  • T: Android TV-Gerät
  • A: Android Automotive-Implementierung
• Bedingungs-ID
  • Wenn die Anforderung bedingungslos ist, wird diese ID auf 0 gesetzt.
  • Wenn die Anforderung bedingt ist, wird für die erste Bedingung die Zahl 1 zugewiesen. Die Zahl wird innerhalb desselben Abschnitts und desselben Gerätetyps um 1 erhöht.
• Anforderungs-ID
  • Diese ID beginnt mit 1 und wird innerhalb desselben Abschnitts und derselben Bedingung um 1 erhöht.

2. Gerätetypen

Das Android Open Source Project bietet zwar einen Software-Stack, der für eine Vielzahl von Gerätetypen und Formfaktoren verwendet werden kann, aber es gibt einige Gerätetypen, für die ein relativ gut etabliertes Ökosystem für die App-Verteilung besteht.

In diesem Abschnitt werden diese Gerätetypen sowie zusätzliche Anforderungen und Empfehlungen für jeden Gerätetyp beschrieben.

Alle Android-Geräteimplementierungen, die nicht in einen der beschriebenen Gerätetypen passen, MÜSSEN dennoch alle Anforderungen in den anderen Abschnitten dieser Kompatibilitätsdefinition erfüllen.

2.1 Gerätekonfigurationen

Die wichtigsten Unterschiede in der Hardwarekonfiguration nach Gerätetyp finden Sie in den gerätespezifischen Anforderungen in diesem Abschnitt.

2.2. Anforderungen an Handheld-Geräte

Ein Android-Handheld ist ein Android-Gerät, das in der Regel in der Hand gehalten wird, z. B. ein MP3-Player, ein Smartphone oder ein Tablet.

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

• Eine Stromquelle, die Mobilität ermöglicht, z. B. ein Akku.
• Die physische Displaydiagonale muss zwischen 2,5 und 8 Zoll liegen.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Android-Handheld-Geräteimplementierungen.

2.2.1. Hardware

Displaygröße (Abschnitt 7.1.1.1)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS ein Display mit einer physischen Diagonale von mindestens 2,5 Zoll haben.^*

Bildschirmpixeldichte (Abschnitt 7.1.1.3)

Implementierungen für Handheld-Geräte:

• [H-SR] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, die Displaygröße zu ändern.

Kompatibilitätsmodus für Legacy-Apps (Abschnitt 7.1.5)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS die Unterstützung für den Legacy-Anwendungskompatibilitätsmodus enthalten, wie er im Upstream-Android-Open-Source-Code implementiert ist. Das heißt, Geräteimplementierungen DÜRFEN die Trigger oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert wird, NICHT ändern und das Verhalten des Kompatibilitätsmodus selbst NICHT ändern.

Tastatur (Abschnitt 7.2.1)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS Unterstützung für IME-Apps (Input Method Editor) von Drittanbietern enthalten.

Navigationstasten (Abschnitt 7.2.3)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS die Funktionen „Home“, „Letzte“ und „Zurück“ bieten.

• [H-0-2] MUSS sowohl das normale als auch das Ereignis für langes Drücken der Zurück-Funktion (KEYCODE_BACK) an die Vordergrundanwendung senden.

Touchscreen-Eingabe (Abschnitt 7.2.4)

Implementierungen für Handheld-Geräte:

• [H-0-1] MÜSSEN Touchscreen-Eingabe unterstützen.

Beschleunigungsmesser (Abschnitt 7.3.1)

Implementierungen für Handheld-Geräte:

• [H-SR] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser einzubauen.

Wenn Handheld-Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser enthalten,

• [H-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 100 Hz melden können.

Gyroskop (Abschnitt 7.3.4)

Wenn Handheld-Geräteimplementierungen ein Gyroskop enthalten, gilt Folgendes:

• [H-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 100 Hz melden können.

Näherungssensor (Abschnitt 7.3.8)

Implementierungen von Mobilgeräten, mit denen ein Sprachanruf getätigt werden kann und die in getPhoneType einen anderen Wert als PHONE_TYPE_NONE angeben:

• SOLLTEN einen Näherungssensor enthalten.

Sensor für die Körperhaltung (Abschnitt 7.3.12)

Implementierungen für Handheld-Geräte:

• Es wird EMPFOHLEN, den Positionssensor mit 6 Freiheitsgraden zu unterstützen.

Bluetooth (Abschnitt 7.4.3)

Implementierungen für Handheld-Geräte:

• SOLLTEN Bluetooth und Bluetooth LE unterstützen.

Datensparmodus (Abschnitt 7.4.7)

Wenn Handheld-Geräteimplementierungen eine Verbindung mit beschränktem Datenvolumen enthalten, gilt Folgendes:

• [H-1-1] Der Datensparmodus MUSS bereitgestellt werden.

Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)

Wenn in Implementierungen von Handheld-Geräten nur ein 32‑Bit-ABI deklariert wird:

• [H-1-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 416 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu qHD (z.B. FWVGA) verwendet.

• [H-2-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 592 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu HD+ (z.B. HD, WSVGA) verwendet.

• [H-3-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 896 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu FHD (z.B. WSXGA+) verwendet.

• [H-4-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1344 MB betragen, wenn für das Standarddisplay Framebuffer-Auflösungen bis zu QHD (z.B. QWXGA) verwendet werden.

Wenn Implementierungen von Handheld-Geräten die Unterstützung von 32-Bit- und 64-Bit-ABIs deklarieren:

• [H-5-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 816 MB betragen, wenn für das Standarddisplay Framebuffer-Auflösungen bis zu qHD (z.B. FWVGA) verwendet werden.

• [H-6-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 944 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu HD+ (z.B. HD, WSVGA) verwendet.

• [H-7-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.280 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu FHD (z. B. WSXGA+) verwendet.

• [H-8-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.824 MB betragen, wenn das Standarddisplay Framebuffer-Auflösungen bis zu QHD (z. B. QWXGA) verwendet.

Der oben erwähnte „für den Kernel und den Userspace verfügbare Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicher, der zusätzlich zu dem Arbeitsspeicher bereitgestellt wird, der bereits für Hardwarekomponenten wie Funk und Video reserviert ist und der in Geräteimplementierungen nicht unter der Kontrolle des Kernels steht.

Wenn Handheld-Geräteimplementierungen weniger als oder gleich 1 GB Arbeitsspeicher für den Kernel und den Nutzerbereich enthalten, gilt Folgendes:

• [H-9-1] MUSS das Funktions-Flag android.hardware.ram.low deklarieren.
• [H-9-2] MUSS mindestens 1,1 GB nicht flüchtigen Speicher für private Anwendungsdaten (d. h. die Partition „/data“) haben.

Wenn Implementierungen von Handheld-Geräten mehr als 1 GB Arbeitsspeicher für den Kernel und den Userspace umfassen, gilt Folgendes:

• [H-10-1] MUSS mindestens 4 GB nicht flüchtigen Speicher für private Anwendungsdaten (d. h. die Partition „/data“) bieten.
• SOLLTEN das Funktions-Flag android.hardware.ram.normal deklarieren.

Gemeinsamer Speicher für Anwendungen (Abschnitt 7.6.2)

Implementierungen für Handheld-Geräte:

• [H-0-1] DÜRFEN KEINEN gemeinsamen Anwendungsspeicher mit weniger als 1 GiB bereitstellen.

USB-Peripheriemodus (Abschnitt 7.7.1)

Implementierungen für Handheld-Geräte:

• SOLLTE einen USB-Anschluss mit Unterstützung für den Peripheriemodus enthalten.

Wenn Handheld-Geräteimplementierungen einen USB-Anschluss enthalten, der den Peripheriemodus unterstützt, gilt Folgendes:

• [H-1-1] MUSS die Android Open Accessory (AOA) API implementieren.^*

Mikrofon (Abschnitt 7.8.1)

Implementierungen für Handheld-Geräte:

• [H-0-1] MÜSSEN ein Mikrofon enthalten.

Audioausgabe (Abschnitt 7.8.2)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS eine Audioausgabe haben und android.hardware.audio.output deklarieren.

Virtual Reality Mode (Abschnitt 7.9.1)

Wenn Handheld-Geräteimplementierungen Unterstützung für den VR-Modus enthalten, gilt Folgendes:

• [H-1-1] MÜSSEN die android.software.vr.mode-Funktion deklarieren.^*

Wenn Geräteimplementierungen die Funktion android.software.vr.mode deklarieren, gilt Folgendes:

• [H-2-1] MUSS eine Anwendung enthalten, die android.service.vr.VrListenerService implementiert und von VR-Anwendungen über android.app.Activity#setVrModeEnabled aktiviert werden kann.^*

Hohe Leistung bei Virtual Reality (Abschnitt 7.9.2)

Wenn Implementierungen von Handheld-Geräten alle Anforderungen für die Deklaration des Feature-Flags android.hardware.vr.high_performance erfüllen, gilt Folgendes:

• [H-1-1] MÜSSEN das android.hardware.vr.high_performance-Funktions-Flag deklarieren.^*

2.2.2. Multimedia

Audiocodierung (Abschnitt 5.1.1)

Implementierungen für tragbare Geräte MÜSSEN die folgenden Audio-Encodings unterstützen:

• [H-0-1] AMR-NB
• [H-0-2] AMR-WB
• [H-0-3] MPEG-4 AAC-Profil (AAC LC)
• [H-0-4] MPEG-4 HE AAC-Profil (AAC+)
• [H-0-5] AAC ELD (enhanced low delay AAC)

Audiodecodierung (Abschnitt 5.1.2)

Implementierungen für tragbare Geräte MÜSSEN die folgende Audiodecodierung unterstützen:

• [H-0-1] AMR-NB
• [H-0-2] AMR-WB

Videocodierung (Abschnitt 5.2)

Implementierungen für tragbare Geräte MÜSSEN die folgende Videocodierung unterstützen und für Drittanbieteranwendungen verfügbar machen:

• [H-0-1] H.264 AVC
• [H-0-2] VP8

Videodecodierung (Abschnitt 5.3)

Implementierungen für tragbare Geräte MÜSSEN die folgenden Videodecodierungen unterstützen:

• [H-0-1] H.264 AVC.
• [H-0-2] H.265 HEVC.
• [H-0-3] MPEG-4 SP.
• [H-0-4] VP8.
• [H-0-5] VP9.

2.2.3. Software

WebView-Kompatibilität (Abschnitt 3.4.1)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API bereitstellen.

Browserkompatibilität (Abschnitt 3.4.2)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS eine eigenständige Browseranwendung für das allgemeine Surfen im Web durch Nutzer enthalten.

Launcher (Abschnitt 3.8.1)

Implementierungen für Handheld-Geräte:

• [H-SR] Es wird DRINGEND EMPFOHLEN, einen Standard-Launcher zu implementieren, der das Anpinnen von Verknüpfungen und Widgets in der App unterstützt.

• [H-SR] Es wird DRINGEND EMPFOHLEN, einen Standard-Launcher zu implementieren, der über die ShortcutManager API schnellen Zugriff auf die zusätzlichen Verknüpfungen bietet, die von Drittanbieter-Apps bereitgestellt werden.

• [H-SR] Es wird DRINGEND EMPFOHLEN, eine Standard-Launcher-App einzubinden, in der Badges für die App-Symbole angezeigt werden.

Widgets (Abschnitt 3.8.2)

Implementierungen für Handheld-Geräte:

• [H-SR] Es wird DRINGEND EMPFOHLEN, Widgets von Drittanbieter-Apps zu unterstützen.

Benachrichtigungen (Abschnitt 3.8.3)

Implementierungen für Handheld-Geräte:

• [H-0-1] MÜSSEN Drittanbieter-Apps Nutzern die Möglichkeit geben, sie über wichtige Ereignisse über die API-Klassen Notification und NotificationManager zu benachrichtigen.
• [H-0-2] MÜSSEN Rich Notifications unterstützen.
• [H-0-3] MÜSSEN wichtige Benachrichtigungen unterstützen.
• [H-0-4] MUSS eine Benachrichtigungsleiste enthalten, die dem Nutzer die Möglichkeit bietet, Benachrichtigungen direkt zu steuern (z. B. zu antworten, sie zu verschieben, zu schließen oder zu blockieren). Dazu müssen Nutzeraktionen wie Aktionsschaltflächen oder die in AOSP implementierte Steuerleiste möglich sein.

Suche (Abschnitt 3.8.4)

Implementierungen für Handheld-Geräte:

• [H-SR] Es wird DRINGEND EMPFOHLEN, einen Assistenten auf dem Gerät zu implementieren, der die Assist-Aktion verarbeitet.

Mediensteuerung auf dem Sperrbildschirm (Abschnitt 3.8.10)

Wenn Android-Handheld-Geräteimplementierungen einen Sperrbildschirm unterstützen,gilt Folgendes:

• [H-1-1] Sperrbildschirmbenachrichtigungen, einschließlich der Vorlage für Medienbenachrichtigungen, MÜSSEN angezeigt werden.

Geräteverwaltung (Abschnitt 3.9)

Wenn Handheld-Geräte einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:

• [H-1-1] MUSS die gesamte Bandbreite der in der Android SDK-Dokumentation definierten Richtlinien zur Geräteverwaltung implementieren.

Barrierefreiheit (Abschnitt 3.10)

Implementierungen für Handheld-Geräte:

• [H-SR] MUSS Bedienungshilfen von Drittanbietern unterstützen.

• [H-SR] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorzuladen, die mit den Bedienungshilfen „Schalterzugriff“ und „TalkBack“ (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden) vergleichbar sind oder deren Funktionen übertreffen, wie sie im TalkBack-Open-Source-Projekt bereitgestellt werden.

Text-to-Speech (Abschnitt 3.11)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS die Installation von Drittanbieter-Sprachausgabe-Engines unterstützen.

• [H-SR] Es wird DRINGEND EMPFOHLEN, ein TTS-Modul einzubinden, das die auf dem Gerät verfügbaren Sprachen unterstützt.

Schnelleinstellungen (Abschnitt 3.13)

Implementierungen für Handheld-Geräte:

• [H-SR] Es wird DRINGEND EMPFOHLEN, eine UI-Komponente für die Schnelleinstellungen einzubinden.

Companion Device Pairing (Abschnitt 3.15)

Wenn Android-Mobilgeräteimplementierungen die Unterstützung von FEATURE_BLUETOOTH oder FEATURE_WIFI deklarieren, gilt Folgendes:

• [H-1-1] MUSS die Funktion zum Koppeln von Begleitgeräten unterstützen.

2.2.4. Leistung und Energie

Konsistenz der Nutzererfahrung (Abschnitt 8.1)

Für Implementierungen auf Handheld-Geräten:

• [H-0-1] Einheitliche Framelatenz. Inkonsistente Frame-Latenz oder eine Verzögerung beim Rendern von Frames DÜRFEN nicht häufiger als 5 Frames pro Sekunde auftreten und SOLLTEN weniger als 1 Frame pro Sekunde betragen.
• [H-0-2] Latenz der Benutzeroberfläche. Geräteimplementierungen MÜSSEN für eine Nutzererfahrung mit geringer Latenz sorgen, indem sie eine Liste mit 10.000 Listeneinträgen, wie in der Android Compatibility Test Suite (CTS) definiert, in weniger als 36 Sekunden scrollen.
• [H-0-3] Wechseln zwischen Aufgaben Wenn mehrere Anwendungen gestartet wurden, muss das erneute Starten einer bereits laufenden Anwendung weniger als 1 Sekunde dauern.

Leistung beim Zugriff auf Datei-E/A (Abschnitt 8.2)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS eine sequenzielle Schreibleistung von mindestens 5 MB/s gewährleisten.
• [H-0-2] MÜSSEN eine zufällige Schreibleistung von mindestens 0,5 MB/s bieten.
• [H-0-3] MUSS eine sequenzielle Leseleistung von mindestens 15 MB/s gewährleisten.
• [H-0-4] MUSS eine zufällige Leseleistung von mindestens 3,5 MB/s bieten.

Energiesparmodi (Abschnitt 8.3)

Für Implementierungen auf Handheld-Geräten:

• [H-0-1] Alle Apps, die von den Energiesparmodi „App-Standby“ und „Doze“ ausgenommen sind, MÜSSEN für den Endnutzer sichtbar sein.
• [H-0-2] Die Trigger-, Wartungs- und Weckalgorithmen sowie die Verwendung globaler Systemeinstellungen der App-Standby- und Doze-Energiesparmodi DÜRFEN nicht vom Android Open Source Project abweichen.

Abrechnung des Stromverbrauchs (Abschnitt 8.4)

Implementierungen für Handheld-Geräte:

• [H-0-1] MUSS ein Energieprofil pro Komponente bereitstellen, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch durch die Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.
• [H-0-2] MUSS alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angeben.
• [H-0-3] MUSS den CPU-Stromverbrauch für die UID jedes Prozesses melden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• [H-0-4] MUSS diese Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.
• Sollte der Hardwarekomponente selbst zugeschrieben werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.

Wenn Implementierungen von Mobilgeräten einen Bildschirm oder eine Videoausgabe enthalten, gilt Folgendes:

• [H-1-1] MUSS die Intention android.intent.action.POWER_USAGE_SUMMARY berücksichtigen und ein Einstellungsmenü anzeigen, in dem dieser Stromverbrauch zu sehen ist.

2.2.5. Sicherheitsmodell

Berechtigungen (Abschnitt 9.1)

Implementierungen für Handheld-Geräte:

• [H-0-1] Drittanbieter-Apps MÜSSEN über die Berechtigung android.permission.PACKAGE_USAGE_STATS auf die Nutzungsstatistiken zugreifen können. Außerdem MUSS ein für Nutzer zugänglicher Mechanismus vorhanden sein, um den Zugriff auf solche Apps als Reaktion auf die Intention android.settings.ACTION_USAGE_ACCESS_SETTINGS zu gewähren oder zu widerrufen.

2.3. Anforderungen an das Fernsehgerät

Ein Android-TV-Gerät ist eine Android-Geräteimplementierung, die eine Unterhaltungsoberfläche für die Nutzung digitaler Medien, Filme, Spiele, Apps und/oder Live-TV für Nutzer ist, die etwa 3 Meter entfernt sitzen (eine „Leanback“- oder „3-Meter-Benutzeroberfläche“).

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

• Es wurde ein Mechanismus zur Fernsteuerung der gerenderten Benutzeroberfläche auf dem Display bereitgestellt, das sich möglicherweise in drei Metern Entfernung vom Nutzer befindet.
• Das Gerät muss ein eingebettetes Display mit einer Diagonale von mehr als 24 Zoll haben ODER einen Videoausgang wie VGA, HDMI, DisplayPort oder einen drahtlosen Anschluss für die Anzeige.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Android TV-Geräteimplementierungen.

2.3.1. Hardware

Navigation ohne Touch-Funktion (Abschnitt 7.2.2)

Implementierungen für Fernsehgeräte:

• [T-0-1] MÜSSEN das Steuerkreuz unterstützen.

Navigationstasten (Abschnitt 7.2.3)

Implementierungen für Fernsehgeräte:

• [T-0-1] MUSS die Funktionen „Home“ und „Zurück“ bereitstellen.
• [T-0-2] Sowohl das Ereignis für normales Drücken als auch das Ereignis für langes Drücken der Zurück-Funktion (KEYCODE_BACK) MUSS an die Vordergrundanwendung gesendet werden.

Tastenzuordnungen (Abschnitt 7.2.6.1)

Implementierungen für Fernsehgeräte:

• [T-0-1] MUSS Unterstützung für Controller enthalten und das android.hardware.gamepad-Funktions-Flag deklarieren.

Remote-Gerätesteuerung (Abschnitt 7.2.7)

Implementierungen für Fernsehgeräte:

• Es SOLLTE eine Fernbedienung bereitgestellt werden, über die Nutzer auf die Eingaben für die Navigation ohne Touchbedienung und die wichtigsten Navigationstasten zugreifen können.

Gyroskop (Abschnitt 7.3.4)

Wenn Fernsehgeräteimplementierungen ein Gyroskop enthalten, gilt Folgendes:

• [T-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 100 Hz melden können.

Bluetooth (Abschnitt 7.4.3)

Implementierungen für Fernsehgeräte:

• [T-0-1] MÜSSEN Bluetooth und Bluetooth LE unterstützen.

Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)

Implementierungen für Fernsehgeräte:

• [T-0-1] MUSS mindestens 4 GB nicht flüchtigen Speicher für private Anwendungsdaten (d.h.die Partition „/data“) bieten.
• [T-0-2] MUSS für ActivityManager.isLowRamDevice() „true“ zurückgeben, wenn für den Kernel und den Nutzerbereich weniger als 1 GB Arbeitsspeicher verfügbar ist.

Mikrofon (Abschnitt 7.8.1)

Implementierungen für Fernsehgeräte:

• SOLLTE ein Mikrofon enthalten.

Audioausgabe (Abschnitt 7.8.2)

Implementierungen für Fernsehgeräte:

• [T-0-1] MUSS eine Audioausgabe haben und android.hardware.audio.output deklarieren.

2.3.2 Multimedia

Audiocodierung (Abschnitt 5.1)

Implementierungen von Fernsehgeräten MÜSSEN die folgenden Audio-Encodings unterstützen:

• [T-0-1] MPEG-4 AAC-Profil (AAC LC)
• [T-0-2] MPEG-4 HE AAC-Profil (AAC+)
• [T-0-3] AAC ELD (Enhanced Low Delay AAC)

Videocodierung (Abschnitt 5.2)

Implementierungen von Fernsehgeräten MÜSSEN die folgende Videocodierung unterstützen:

• [T-0-1] H.264 AVC
• [T-0-2] VP8

H.264 (Abschnitt 5.2.2)

Implementierungen von Fernsehgeräten:

• [T-SR] Es wird DRINGEND EMPFOHLEN, die H.264-Codierung von Videos mit einer Auflösung von 720p und 1080p zu unterstützen.
• [T-SR] Es wird DRINGEND EMPFOHLEN, die H.264-Codierung von Videos mit einer Auflösung von 1080p bei 30 Bildern pro Sekunde (fps) zu unterstützen.

Videodecodierung (Abschnitt 5.3)

Implementierungen von Fernsehgeräten MÜSSEN die folgende Videodecodierung unterstützen:

• [T-0-1] H.264 AVC
• [T-0-2] H.265 HEVC
• [T-0-3] MPEG-4 SP
• [T-0-4] VP8
• [T-0-5] VP9

Für Implementierungen von Fernsehgeräten wird DRINGEND EMPFOHLEN, die folgende Videodecodierung zu unterstützen:

• [T-SR] MPEG-2

H.264 (Abschnitt 5.3.4)

Wenn Fernsehgeräteimplementierungen H.264-Decoder unterstützen, gilt Folgendes:

• [T-1-1] MUSS das High Profile Level 4.2 und das HD-Decodierungsprofil (1080p bei 60 fps) unterstützen.
• [T-1-2] MUSS Videos mit beiden HD-Profilen, wie in der folgenden Tabelle angegeben, decodieren können, die entweder mit dem Baseline Profile, Main Profile oder High Profile Level 4.2 codiert wurden.

H.265 (HEVC) (Abschnitt 5.3.5)

Wenn Implementierungen von Fernsehgeräten den H.265-Codec und das HD-Decodierungsprofil (1080p) unterstützen, gilt Folgendes:

• [T-1-1] MUSS das Main Profile Level 4.1 Main Tier unterstützen.
• [T-SR] Es wird DRINGEND EMPFOHLEN, eine Videoframerate von 60 fps für HD 1080p zu unterstützen.

Wenn Fernsehgeräteimplementierungen den H.265-Codec und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:

• [T-2-1] Der Codec MUSS das Profil „Main10 Level 5 Main Tier“ unterstützen.

VP8 (Abschnitt 5.3.6)

Wenn Implementierungen von Fernsehgeräten den VP8-Codec unterstützen, gilt Folgendes:

• [T-1-1] MUSS das HD‑Decodierungsprofil 1080p60 unterstützen.

Wenn Fernsehgeräteimplementierungen den VP8-Codec und 720p unterstützen, gilt Folgendes:

• [T-2-1] MUSS das Decodierungsprofil für HD 720p60 unterstützen.

VP9 (Abschnitt 5.3.7)

Wenn Fernsehgeräteimplementierungen den VP9-Codec und die UHD-Videodecodierung unterstützen, gilt Folgendes:

• [T-1-1] MUSS eine Farbtiefe von 8 Bit unterstützen und SOLLTE VP9 Profil 2 (10 Bit) unterstützen.

Wenn Fernsehgeräteimplementierungen den VP9-Codec, das 1080p-Profil und die VP9-Hardware-Decodierung unterstützen,

• [T-2-1] MUSS 60 fps für 1080p unterstützen.

Sichere Medien (Abschnitt 5.8)

Wenn Geräteimplementierungen Android-Fernseher sind und eine 4K-Auflösung unterstützen, gilt Folgendes:

• [T-1-1] MUSS HDCP 2.2 für alle kabelgebundenen externen Displays unterstützen.

Wenn Implementierungen von Fernsehgeräten keine 4K-Auflösung unterstützen, gilt Folgendes:

• [T-2-1] MUSS HDCP 1.4 für alle kabelgebundenen externen Displays unterstützen.

Implementierungen für Fernsehgeräte:

• [T-SR] Es wird DRINGEND EMPFOHLEN, das gleichzeitige Decodieren von sicheren Streams zu unterstützen. Die gleichzeitige Dekodierung von mindestens zwei Streams wird DRINGEND EMPFOHLEN.

Lautstärke der Audioausgabe (Abschnitt 5.5.3)

Implementierungen für Fernsehgeräte:

• [T-0-1] MUSS die Unterstützung für die System-Master-Lautstärke und die Lautstärkeanpassung der digitalen Audioausgabe auf unterstützten Ausgängen enthalten, mit Ausnahme des Compressed Audio Passthrough-Ausgangs (bei dem keine Audiodecodierung auf dem Gerät erfolgt).

2.3.3. Software

Implementierungen für Fernsehgeräte:

• [T-0-1] MÜSSEN die Funktionen android.software.leanback und android.hardware.type.television deklarieren.

WebView-Kompatibilität (Abschnitt 3.4.1)

Implementierungen für Fernsehgeräte:

• [T-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API bereitstellen.

Mediensteuerung auf dem Sperrbildschirm (Abschnitt 3.8.10)

Wenn Android TV-Geräteimplementierungen einen Sperrbildschirm unterstützen,gilt Folgendes:

• [T-1-1] Sperrbildschirmbenachrichtigungen, einschließlich der Vorlage für Medienbenachrichtigungen, MÜSSEN angezeigt werden.

Mehrfenstermodus (Abschnitt 3.8.14)

Implementierungen für Fernsehgeräte:

• [T-SR] Es wird DRINGEND EMPFOHLEN, den Mehrfenstermodus „Bild im Bild“ (BiB) zu unterstützen.

Barrierefreiheit (Abschnitt 3.10)

Implementierungen für Fernsehgeräte:

• [T-SR] MUSS Bedienungshilfen von Drittanbietern unterstützen.

• [T-SR] Bei Android-Fernsehern wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorab zu laden, die mit den Bedienungshilfen „Schalterzugriff“ und „TalkBack“ (für Sprachen, die von der vorab geladenen Sprachausgabe unterstützt werden) vergleichbar sind oder deren Funktionen übertreffen, wie sie im TalkBack-Open-Source-Projekt bereitgestellt werden.

Text-to-Speech (Abschnitt 3.11)

Wenn Geräteimplementierungen die Funktion „android.hardware.audio.output“ melden, gilt Folgendes:

• [T-SR] Es wird DRINGEND EMPFOHLEN, eine TTS-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.

• [T-0-1] MUSS die Installation von Drittanbieter-Sprachausgabe-Engines unterstützen.

TV Input Framework (Abschnitt 3.12)

Implementierungen für Fernsehgeräte:

• [T-0-1] MUSS das TV Input Framework unterstützen.

2.2.4. Leistung und Energie

Konsistenz der Nutzererfahrung (Abschnitt 8.1)

Für Implementierungen von Fernsehgeräten gilt:

• [T-0-1] Konsistente Frame-Latenz. Inkonsistente Frame-Latenz oder eine Verzögerung beim Rendern von Frames DÜRFEN nicht häufiger als 5 Frames pro Sekunde auftreten und SOLLTEN weniger als 1 Frame pro Sekunde betragen.

Leistung beim Zugriff auf Datei-E/A (Abschnitt 8.2)

Implementierungen für Fernsehgeräte:

• [T-0-1] MUSS eine sequenzielle Schreibleistung von mindestens 5 MB/s gewährleisten.
• [T-0-2] MUSS eine zufällige Schreibleistung von mindestens 0,5 MB/s bieten.
• [T-0-3] MUSS eine sequenzielle Leseleistung von mindestens 15 MB/s gewährleisten.
• [T-0-4] MUSS eine zufällige Leseleistung von mindestens 3,5 MB/s gewährleisten.

Energiesparmodi (Abschnitt 8.3)

Für Implementierungen von Fernsehgeräten gilt:

• [T-0-1] Alle Apps, die von den Energiesparmodi „App-Standby“ und „Doze“ ausgenommen sind, MÜSSEN für den Endnutzer sichtbar sein.
• [T-0-2] Die Trigger-, Wartungs- und Weckalgorithmen sowie die Verwendung globaler Systemeinstellungen der Energiesparmodi „App-Standby“ und „Doze“ DÜRFEN NICHT vom Android Open Source Project abweichen.

Abrechnung des Stromverbrauchs (Abschnitt 8.4)

Implementierungen für Fernsehgeräte:

• [T-0-1] Es MUSS ein Energieprofil pro Komponente bereitgestellt werden, das den Wert für den Stromverbrauch für jede Hardwarekomponente und den ungefähren Akkuverbrauch durch die Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.
• [T-0-2] MÜSSEN alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angegeben werden.
• [T-0-3] Die CPU-Leistungsaufnahme MUSS für die UID jedes Prozesses gemeldet werden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• Sollte der Hardwarekomponente selbst zugeschrieben werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.
• [T-0-4] MUSS diese Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.

2.4. Smartwatch-Anforderungen

Ein Android-Smartwatch-Gerät ist eine Android-Geräteimplementierung, die am Körper getragen werden soll, z. B. am Handgelenk.

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

• Der Bildschirm muss eine physische diagonale Länge zwischen 1,1 und 2,5 Zoll haben.
• Es muss einen Mechanismus geben, mit dem das Gerät am Körper getragen werden kann.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Android-Smartwatch-Implementierungen.

2.4.1. Hardware

Displaygröße (Abschnitt 7.1.1.1)

Smartwatch-Geräteimplementierungen:

• [W-0-1] MUSS ein Display mit einer physischen Diagonale zwischen 1,1 und 2,5 Zoll haben.

Navigationstasten (Abschnitt 7.2.3)

Smartwatch-Geräteimplementierungen:

• [W-0-1] Die Home-Funktion MUSS für den Nutzer verfügbar sein und die Zurück-Funktion, außer wenn sie sich in UI_MODE_TYPE_WATCH befindet.

Touchscreen-Eingabe (Abschnitt 7.2.4)

Smartwatch-Geräteimplementierungen:

• [W-0-2] MÜSSEN Touchscreen-Eingabe unterstützen.

Beschleunigungsmesser (Abschnitt 7.3.1)

Smartwatch-Geräteimplementierungen:

• [W-SR] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser einzubauen.

Bluetooth (Abschnitt 7.4.3)

Smartwatch-Geräteimplementierungen:

• [W-0-1] MÜSSEN Bluetooth unterstützen.

Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)

Smartwatch-Geräteimplementierungen:

• [W-0-1] MUSS mindestens 1 GB nicht flüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) bieten.
• [W-0-2] MUSS mindestens 416 MB Arbeitsspeicher für den Kernel und den Nutzerbereich zur Verfügung haben.

Mikrofon (Abschnitt 7.8.1)

Smartwatch-Geräteimplementierungen:

• [W-0-1] MUSS ein Mikrofon enthalten.

Audioausgabe (Abschnitt 7.8.1)

Smartwatch-Geräteimplementierungen:

• MAY but SHOULD NOT have audio output.

2.4.2. Multimedia

Keine zusätzlichen Anforderungen.

2.4.3. Software

Smartwatch-Geräteimplementierungen:

• [W-0-1] MUSS die Funktion „android.hardware.type.watch“ deklarieren.
• [W-0-2] MÜSSEN uiMode = UI_MODE_TYPE_WATCH unterstützen.

Suche (Abschnitt 3.8.4)

Smartwatch-Geräteimplementierungen:

• [W-SR] Es wird DRINGEND EMPFOHLEN, einen Assistenten auf dem Gerät zu implementieren, der die Assist-Aktion verarbeitet.

Barrierefreiheit (Abschnitt 3.10)

Für Smartwatch-Geräteimplementierungen, die das Feature-Flag android.hardware.audio.output deklarieren, gilt Folgendes:

• [W-1-1] MUSS Bedienungshilfen von Drittanbietern unterstützen.

• [W-SR] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorzuladen, die mit den Bedienungshilfen „Schalterzugriff“ und „TalkBack“ (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden) vergleichbar sind oder deren Funktionen übertreffen, wie sie im TalkBack-Open-Source-Projekt bereitgestellt werden.

Text-to-Speech (Abschnitt 3.11)

Wenn Watch-Geräteimplementierungen die Funktion „android.hardware.audio.output“ melden, gilt Folgendes:

• [W-SR] Es wird DRINGEND EMPFOHLEN, eine TTS-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.

• [W-0-1] MUSS die Installation von Drittanbieter-Sprachausgabe-Engines unterstützen.

2.5. Anforderungen für die Automobilbranche

Eine Android Automotive-Implementierung bezieht sich auf ein Infotainmentsystem im Fahrzeug, auf dem Android als Betriebssystem für einen Teil oder das gesamte System und/oder die Infotainmentfunktionen ausgeführt wird.

Android-Geräteimplementierungen werden als Automotive-Geräte klassifiziert, wenn sie das Feature android.hardware.type.automotive deklarieren oder alle folgenden Kriterien erfüllen.

• Sie sind in ein Kraftfahrzeug eingebettet oder können daran angeschlossen werden.
• Sie verwenden einen Bildschirm in der Fahrerreihe als primäres Display.

Die zusätzlichen Anforderungen im Rest dieses Abschnitts gelten speziell für Android Automotive-Geräteimplementierungen.

2.5.1. Hardware

Displaygröße (Abschnitt 7.1.1.1)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS einen Bildschirm mit einer physischen Diagonale von mindestens 6 Zoll haben.
• [A-0-2] MUSS ein Layout mit einer Bildschirmgröße von mindestens 750 × 480 dp haben.

Navigationstasten (Abschnitt 7.2.3)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS die Funktion „Home“ bereitstellen und DARF die Funktionen „Zurück“ und „Zuletzt verwendet“ bereitstellen.
• [A-0-2] Sowohl das normale als auch das lange Drücken der Zurück-Funktion (KEYCODE_BACK) MUSS an die Vordergrundanwendung gesendet werden.

Beschleunigungsmesser (Abschnitt 7.3.1)

Automotive-Geräteimplementierungen:

• [A-SR] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser einzubauen.

Wenn Automotive-Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser enthalten, gilt Folgendes:

• [A-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 100 Hz melden können.
• [A-1-2] MÜSSEN dem Koordinatensystem für Autosensoren von Android entsprechen.

GPS (Abschnitt 7.3.3)

Wenn Automotive-Geräteimplementierungen einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps an Anwendungen melden:

• [A-1-1] Die GNSS-Technologiegeneration MUSS das Jahr „2017“ oder neuer sein.

Gyroskop (Abschnitt 7.3.4)

Wenn Automotive-Geräteimplementierungen ein Gyroskop enthalten, gilt Folgendes:

• [A-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 100 Hz melden können.

Sensoren nur für Android Automotive (Abschnitt 7.3.11) Aktueller Gang (Abschnitt 7.3.11.1)

Automotive-Geräteimplementierungen:

• SOLLTE den aktuellen Gang als SENSOR_TYPE_GEAR angeben.

Tag-/Nachtmodus (Abschnitt 7.3.11.2)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS den Tag-/Nachtmodus unterstützen, der als SENSOR_TYPE_NIGHT definiert ist.
• [A-0-2] Der Wert des Flags SENSOR_TYPE_NIGHT MUSS mit dem Tag-/Nachtmodus des Dashboards übereinstimmen und SOLLTE auf der Eingabe des Umgebungslichtsensors basieren.
• Der zugrunde liegende Umgebungslichtsensor ist MÖGLICHERWEISE derselbe wie beim Photometer.

Fahrstatus (Abschnitt 7.3.11.3)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS den Fahrstatus unterstützen, der als SENSOR_TYPE_DRIVING_STATUS definiert ist, mit dem Standardwert DRIVE_STATUS_UNRESTRICTED, wenn das Fahrzeug vollständig angehalten und geparkt ist. Gerätehersteller sind dafür verantwortlich, SENSOR_TYPE_DRIVING_STATUS in Übereinstimmung mit allen Gesetzen und Verordnungen zu konfigurieren, die für Märkte gelten, in die das Produkt geliefert wird.

Radgeschwindigkeit (Abschnitt 7.3.11.4)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS die Fahrzeuggeschwindigkeit als SENSOR_TYPE_CAR_SPEED angeben.

Bluetooth (Abschnitt 7.4.3)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS Bluetooth unterstützen und SOLLTE Bluetooth LE unterstützen.

• [A-0-2] Android Automotive-Implementierungen MÜSSEN die folgenden Bluetooth-Profile unterstützen:

  • Telefonieren über das Hands-Free Profile (HFP).
  • Medienwiedergabe über das Audio Distribution Profile (A2DP).
  • Steuerung der Medienwiedergabe über das Remote Control Profile (AVRCP)
  • Kontaktfreigabe anhand des Phone Book Access Profile (PBAP)
• SOLLTE das Message Access Profile (MAP) unterstützen.

Mindestanforderungen an die Netzwerkfunktionen (Abschnitt 7.4.5)

Automotive-Geräteimplementierungen:

• Sollte die Unterstützung für die Datenverbindung über das Mobilfunknetz umfassen.

Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS mindestens 4 GB nicht flüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) bieten.

USB-Peripheriemodus (Abschnitt 7.7.1)

Automotive-Geräteimplementierungen:

• SOLLTE einen USB-Anschluss mit Unterstützung für den Peripheriemodus enthalten.

Mikrofon (Abschnitt 7.8.1)

Automotive-Geräteimplementierungen:

• [A-0-1] MÜSSEN ein Mikrofon enthalten.

Audioausgabe (Abschnitt 7.8.2)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS eine Audioausgabe haben und android.hardware.audio.output deklarieren.

2.5.2. Multimedia

Audiocodierung (Abschnitt 5.1)

Automotive-Geräteimplementierungen MÜSSEN die folgende Audio-Codierung unterstützen:

• [A-1-1] MPEG-4 AAC-Profil (AAC LC)
• [A-1-2] MPEG-4 HE AAC-Profil (AAC+)
• [A-1-3] AAC ELD (Enhanced Low Delay AAC)

Videocodierung (Abschnitt 5.2)

Automotive-Geräteimplementierungen MÜSSEN die folgenden Video-Codierungen unterstützen:

• [A-0-1] H.264 AVC
• [A-0-2] VP8

Videodecodierung (Abschnitt 5.3)

Automotive-Geräteimplementierungen MÜSSEN die folgende Videodecodierung unterstützen:

• [A-0-1] H.264 AVC
• [A-0-2] MPEG-4 SP
• [A-0-3] VP8
• [A-0-4] VP9

Für Automotive-Geräteimplementierungen wird DRINGEND empfohlen, die folgende Videodecodierung zu unterstützen:

• [A-SR] H.265 HEVC

2.5.3. Software

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS die Funktion „android.hardware.type.automotive“ deklarieren.
• [A-0-2] MÜSSEN uiMode = UI_MODE_TYPE_CAR unterstützen.
• [A-0-3] Android Automotive-Implementierungen MÜSSEN alle öffentlichen APIs im Namespace android.car.* unterstützen.

WebView-Kompatibilität (Abschnitt 3.4.1)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS eine vollständige Implementierung von android.webkit.Webview API bereitstellen.

Benachrichtigungen (Abschnitt 3.8.3)

Android Automotive-Geräteimplementierungen:

• [A-0-1] MUSS Benachrichtigungen anzeigen, die die Notification.CarExtender API verwenden, wenn sie von Drittanbieteranwendungen angefordert werden.

Suche (Abschnitt 3.8.4)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS einen Assistenten auf dem Gerät implementieren, der die Assist-Aktion verarbeitet.

Benutzeroberfläche für Medien (Abschnitt 3.14)

Automotive-Geräteimplementierungen:

• [A-0-1] MUSS ein UI-Framework enthalten, das Drittanbieter-Apps unterstützt, die die Media APIs verwenden, wie in Abschnitt 3.14 beschrieben.

2.2.4. Leistung und Energie

Energiesparmodi (Abschnitt 8.3)

Für Automotive-Geräteimplementierungen gilt:

• [A-0-1] Alle Apps, die von den Energiesparmodi „App-Standby“ und „Doze“ ausgenommen sind, MÜSSEN für den Endnutzer sichtbar sein.
• [A-0-2] Die Trigger-, Wartungs- und Weckalgorithmen sowie die Verwendung globaler Systemeinstellungen der Energiesparmodi „App-Standby“ und „Doze“ DÜRFEN nicht vom Android Open Source Project abweichen.

Abrechnung des Stromverbrauchs (Abschnitt 8.4)

Automotive-Geräteimplementierungen:

• [A-0-1] Es MUSS ein Energieprofil pro Komponente bereitgestellt werden, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch durch die Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.
• [A-0-2] MUSS alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angeben.
• [A-0-3] MUSS den CPU-Stromverbrauch für die UID jedes Prozesses melden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• Sollte der Hardwarekomponente selbst zugeschrieben werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.
• [A-0-4] Die Stromnutzung MUSS dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung gestellt werden.

2.2.5. Sicherheitsmodell

Unterstützung mehrerer Nutzer (Abschnitt 9.5)

Wenn Automotive-Geräteimplementierungen mehrere Nutzer umfassen, gilt Folgendes:

• [A-1-1] MUSS ein Gastkonto enthalten, das alle Funktionen des Fahrzeugsystems ermöglicht, ohne dass sich ein Nutzer anmelden muss.

Isolierung von Fahrzeugsystemen (Abschnitt 9.14)

Automotive-Geräteimplementierungen:

• [A-0-1] MÜSSEN Nachrichten von Android-Framework-Fahrzeugsubsystemen filtern, z.B. durch Zulassen von Nachrichtenquellen und Nachrichtentypen.
• [A-0-2] MUSS vor Denial-of-Service-Angriffen durch das Android-Framework oder Drittanbieter-Apps schützen. So wird verhindert, dass das Fahrzeugnetzwerk durch schädliche Software mit Traffic überlastet wird, was zu Fehlfunktionen von Fahrzeugsubsystemen führen kann.

2.6. Tablet-Anforderungen

Ein Android-Tablet ist ein Android-Gerät, das normalerweise mit beiden Händen gehalten wird und kein Clamshell-Formfaktor ist.

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

• Eine Stromquelle, die Mobilität ermöglicht, z. B. ein Akku.
• Die physische Displaydiagonale muss zwischen 7 und 18 Zoll liegen.

Für Tablet-Geräteimplementierungen gelten ähnliche Anforderungen wie für Handheld-Geräteimplementierungen. Die Ausnahmen sind in diesem Abschnitt mit einem Sternchen (*) gekennzeichnet und zur Referenz aufgeführt.

2.4.1. Hardware

Displaygröße (Abschnitt 7.1.1.1)

Tablet-Geräteimplementierungen:

• [Ta-0-1] MUSS ein Display mit einer Größe zwischen 7 und 18 Zoll haben.

Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)

Die für kleine/normale Bildschirme in den Anforderungen für Handheld-Geräte aufgeführten Bildschirmdichten gelten nicht für Tablets.

USB-Peripheriemodus (Abschnitt 7.7.1)

Wenn Handheld-Geräteimplementierungen einen USB-Anschluss enthalten, der den Peripheriemodus unterstützt, gilt Folgendes:

• MAY implement the Android Open Accessory (AOA) API.

Virtual Reality Mode (Abschnitt 7.9.1)

Hohe Leistung bei Virtual Reality (Abschnitt 7.9.2)

Virtual-Reality-Anforderungen gelten nicht für Tablets.

3. Software

3.1. Verwaltete API-Kompatibilität

Die verwaltete Dalvik-Bytecode-Ausführungsumgebung ist das primäre Mittel für Android-Anwendungen. Die Android-Anwendungsprogrammierschnittstelle (API) ist die Gruppe von Android-Plattformschnittstellen, die für Anwendungen verfügbar sind, die in der verwalteten Laufzeitumgebung ausgeführt werden.

• [C-0-1] Geräteimplementierungen MÜSSEN vollständige Implementierungen aller dokumentierten APIs bereitstellen, die vom Android SDK oder einer API, die im Upstream-Android-Quellcode mit dem Marker „@SystemApi“ versehen ist, bereitgestellt werden, einschließlich aller dokumentierten Verhaltensweisen.

• [C-0-2] Geräteimplementierungen MÜSSEN alle Klassen, Methoden und zugehörigen Elemente unterstützen/beibehalten, die mit der TestApi-Annotation (@TestApi) gekennzeichnet sind.

• [C-0-3] Geräteimplementierungen DÜRFEN keine verwalteten APIs auslassen, API-Schnittstellen oder ‑Signaturen ändern, vom dokumentierten Verhalten abweichen oder No-Ops enthalten, sofern dies nicht ausdrücklich in dieser Kompatibilitätsdefinition zulässig ist.

• [C-0-4] Geräteimplementierungen MÜSSEN die APIs weiterhin enthalten und sich angemessen verhalten, auch wenn einige Hardwarefunktionen, für die Android APIs enthält, weggelassen werden. Abschnitt 7 enthält spezifische Anforderungen für dieses Szenario.

3.1.1. Android-Erweiterungen

Android unterstützt die Erweiterung der verwalteten APIs bei Beibehaltung derselben API-Level-Version.

• [C-0-1] Auf Android-Geräteimplementierungen MUSS die AOSP-Implementierung der gemeinsam genutzten Bibliothek ExtShared und der Dienste ExtServices mit Versionen vorinstalliert sein, die höher oder gleich den für die einzelnen API-Levels zulässigen Mindestversionen sind. Bei Geräteimplementierungen mit Android 7.0, die API-Level 24 ausführen, MUSS mindestens Version 1 enthalten sein.

3.2 Soft API Compatibility

Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 enthält Android auch eine wichtige „weiche“ API, die nur zur Laufzeit verfügbar ist. Dazu gehören Intents, Berechtigungen und ähnliche Aspekte von Android-Anwendungen, die nicht zur Kompilierzeit der Anwendung erzwungen werden können.

3.2.1. Berechtigungen

• [C-0-1] Geräteimplementierer MÜSSEN alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der Seite mit Berechtigungsreferenzen dokumentiert. Abschnitt 9 enthält zusätzliche Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell.

3.2.2. Parameter erstellen

Die Android-APIs enthalten eine Reihe von Konstanten in der android.os.Build-Klasse, die das aktuelle Gerät beschreiben sollen.

• [C-0-1] Damit geräteübergreifend einheitliche, aussagekräftige Werte bereitgestellt werden, enthält die Tabelle unten zusätzliche Einschränkungen für die Formate dieser Werte, die von Geräteimplementierungen eingehalten werden MÜSSEN.

Parameter	Details
VERSION.RELEASE	Die Version des aktuell ausgeführten Android-Systems in einem für Menschen lesbaren Format. Dieses Feld MUSS einen der in 8.1 definierten Stringwerte enthalten.
VERSION.SDK	Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Drittanbieter-Anwendungscode zugreifen kann. Bei Android 8.1 MUSS dieses Feld den Ganzzahlwert 8.1_INT haben.
VERSION.SDK_INT	Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Drittanbieter-Anwendungscode zugreifen kann. Bei Android 8.1 MUSS dieses Feld den Ganzzahlwert 8.1_INT haben.
VERSION.INCREMENTAL	Ein vom Gerätehersteller ausgewählter Wert, der den spezifischen Build des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format angibt. Dieser Wert DARF NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. Dieses Feld wird in der Regel verwendet, um anzugeben, welche Build-Nummer oder Quellcode-Änderungs-ID zum Generieren des Builds verwendet wurde. Es gibt keine Anforderungen an das spezifische Format dieses Felds, außer dass es NICHT „null“ oder ein leerer String („“) sein darf.
BRETTSPIEL	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Hardware des Geräts in einem für Menschen lesbaren Format angibt. Ein möglicher Anwendungsfall für dieses Feld ist die Angabe der spezifischen Revision der Platine, die das Gerät mit Strom versorgt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
MARKE	Ein Wert, der den Markennamen des Geräts widerspiegelt, wie er den Endnutzern bekannt ist. MUSS in einem für Menschen lesbaren Format vorliegen und SOLLTE den Hersteller des Geräts oder die Unternehmensmarke angeben, unter der das Gerät vermarktet wird. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
SUPPORTED_ABIS	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität.
SUPPORTED_32_BIT_ABIS	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität.
SUPPORTED_64_BIT_ABIS	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität.
CPU_ABI	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität.
CPU_ABI2	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Weitere Informationen finden Sie in Abschnitt 3.3. Native API-Kompatibilität.
GERÄT	Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen enthält, der die Konfiguration der Hardwarefunktionen und des Industriedesigns des Geräts angibt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen. Dieser Gerätename DARF sich während der Lebensdauer des Produkts NICHT ändern.
FINGERPRINT	Ein String, der diesen Build eindeutig identifiziert. Sie SOLLTE einigermaßen für Menschen lesbar sein. Es MUSS dieser Vorlage entsprechen: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Beispiel: acme/myproduct/     mydevice:8.1/LMYXX/3359:userdebug/test-keys Der Fingerabdruck darf keine Leerzeichen enthalten. Wenn andere Felder in der Vorlage oben Leerzeichen enthalten, MÜSSEN diese im Build-Fingerabdruck durch ein anderes Zeichen ersetzt werden, z. B. durch den Unterstrich („_“). Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können.
HARDWARE	Der Name der Hardware (aus der Kernel-Befehlszeile oder /proc). Sie SOLLTE einigermaßen für Menschen lesbar sein. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
VORTRAGENDER	Ein String, der den Host, auf dem der Build erstellt wurde, in einem für Menschen lesbaren Format eindeutig identifiziert. Es gibt keine Anforderungen an das spezifische Format dieses Felds, außer dass es NICHT „null“ oder ein leerer String („“) sein darf.
ID	Eine vom Geräteimplementierer gewählte Kennung, die sich auf eine bestimmte Version bezieht, in einem für Menschen lesbaren Format. Dieses Feld kann mit android.os.Build.VERSION.INCREMENTAL identisch sein, SOLLTE aber einen Wert enthalten, der für Endnutzer aussagekräftig genug ist, um zwischen Software-Builds zu unterscheiden. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen.
HERSTELLER	Der Markenname des Erstausrüsters (OEM) des Produkts. Für das Format dieses Felds gelten keine besonderen Anforderungen, es darf jedoch nicht „null“ oder ein leerer String („“) sein. Dieses Feld darf sich während der Lebensdauer des Produkts nicht ändern.
MODELL	Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endnutzer bekannt ist. Das SOLLTE derselbe Name sein, unter dem das Gerät an Endnutzer vermarktet und verkauft wird. Für das Format dieses Felds gelten keine besonderen Anforderungen, es darf jedoch nicht „null“ oder ein leerer String („“) sein. Dieses Feld darf sich während der Lebensdauer des Produkts nicht ändern.
PRODUKT/FUNKTION	Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des jeweiligen Produkts (Artikelnummer) enthält. Dieser muss innerhalb derselben Marke eindeutig sein. MUSS menschenlesbar sein, ist aber nicht unbedingt für Endnutzer gedacht. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen. Dieser Produktname DARF sich während der Lebensdauer des Produkts NICHT ändern.
SERIAL	Eine Hardware-Seriennummer, 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 codiert werden können und dem regulären Ausdruck „^([a-zA-Z0-9]{6,20})$“ entsprechen.
TAGS	Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt wurden und den Build weiter unterscheiden. Dieses Feld MUSS einen der Werte haben, die den drei typischen Signaturkonfigurationen der Android-Plattform entsprechen: release-keys, dev-keys, test-keys.
UHRZEIT	Ein Wert, der den Zeitstempel des Builds darstellt.
SCHREIBMASCHINE	Ein vom Geräteimplementierer ausgewählter Wert, der die Laufzeitkonfiguration des Builds angibt. Dieses Feld MUSS einen der Werte haben, die den drei typischen Android-Laufzeitkonfigurationen entsprechen: „user“, „userdebug“ oder „eng“.
NUTZER	Ein Name oder eine Nutzer-ID des Nutzers (oder automatisierten Nutzers), der den Build generiert hat. Es gibt keine Anforderungen an das spezifische Format dieses Felds, außer dass es NICHT „null“ oder ein leerer String („“) sein darf.
SECURITY_PATCH	Ein Wert, der das Sicherheitspatch-Level eines Builds angibt. Es MUSS darauf hinweisen, dass der Build in keiner Weise anfällig für die Probleme ist, die bis zum angegebenen öffentlichen Sicherheitsbulletin für Android beschrieben werden. Es MUSS im Format [JJJJ-MM-TT] vorliegen und mit einem definierten String übereinstimmen, der im öffentlichen Sicherheitsbulletin für Android oder im Android Security Advisory dokumentiert ist, z. B. „2015-11-01“.
BASE_OS	Ein Wert, der den FINGERPRINT-Parameter des Builds darstellt, der ansonsten mit diesem Build identisch ist, mit Ausnahme der im Android Public Security Bulletin bereitgestellten Patches. Es MUSS den richtigen Wert zurückgeben. Wenn ein solcher Build nicht vorhanden ist, MUSS ein leerer String ("") zurückgegeben werden.
BOOTLOADER	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Bootloader-Version des Geräts in einem für Menschen lesbaren Format angibt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen.
getRadioVersion()	MUSS ein vom Gerätehersteller ausgewählter Wert sein oder zurückgeben, der die spezifische interne Funk-/Modemversion identifiziert, die im Gerät verwendet wird, in einem für Menschen lesbaren Format. Wenn ein Gerät kein internes Funkgerät/Modem hat, MUSS NULL zurückgegeben werden. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-,]+$“ entsprechen.

3.2.3. Intent-Kompatibilität

3.2.3.1. Wichtige App-Intents

Mit Android-Intents können Anwendungskomponenten Funktionen von anderen Android-Komponenten anfordern. Das Android-Upstream-Projekt enthält eine Liste von Anwendungen, die als Android-Kernanwendungen gelten. Diese implementieren mehrere Intent-Muster, um häufige Aktionen auszuführen.

• [C-0-1] Geräteimplementierungen MÜSSEN eine oder mehrere Anwendungen oder Dienstkomponenten mit einem Intent-Handler für alle öffentlichen Intent-Filtermuster vorab laden, die von den folgenden Android-Kernanwendungen in AOSP definiert werden:

  • Tischuhr
  • Browser
  • Kalender
  • Kontakte
  • Galerie
  • GlobalSearch
  • Launcher
  • Musik
  • Einstellungen

3.2.3.2. Intent-Auflösung

• [C-0-1] Da Android eine erweiterbare Plattform ist, MUSS in Geräteimplementierungen zugelassen werden, dass jedes in Abschnitt 3.2.3.1 referenzierte Intent-Muster von Drittanbieteranwendungen überschrieben wird. Die Upstream-Implementierung von Android Open Source ermöglicht dies standardmäßig.

• [C-0-2] Geräteimplementierer DÜRFEN der Verwendung dieser Intent-Muster durch Systemanwendungen KEINE besonderen Berechtigungen zuweisen und DÜRFEN nicht verhindern, dass Drittanbieteranwendungen an diese Muster gebunden werden und die Kontrolle über sie übernehmen. Dieses Verbot umfasst insbesondere, aber nicht ausschließlich, das Deaktivieren der Benutzeroberfläche „Chooser“, über die Nutzer zwischen mehreren Anwendungen auswählen können, die alle dasselbe Intent-Muster verarbeiten.

• [C-0-3] Geräteimplementierungen MÜSSEN eine Benutzeroberfläche bieten, über die Nutzer die Standardaktivität für Intents ändern können.

• Geräteimplementierungen KÖNNEN jedoch Standardaktivitäten für bestimmte URI-Muster (z.B. http://play.google.com) bereitstellen, wenn die Standardaktivität ein spezifischeres Attribut für den Daten-URI bietet. Ein Intent-Filtermuster, das den Daten-URI „http://www.android.com“ angibt, ist beispielsweise spezifischer als das Core-Intent-Muster des Browsers für „http://“.

Android bietet auch einen Mechanismus für Drittanbieter-Apps, um ein autoritatives Standardverhalten für App-Links für bestimmte Arten von Web-URI-Intents zu deklarieren. Wenn solche autoritativen Deklarationen in den Intent-Filtermustern einer App definiert sind, gilt für Geräteimplementierungen Folgendes:

• [C-0-4] MUSS versuchen, alle Intent-Filter zu validieren, indem die in der Digital Asset Links-Spezifikation definierten Validierungsschritte ausgeführt werden, wie sie vom Paketmanager im Upstream-Android Open Source Project implementiert sind.
• [C-0-5] Die Validierung der Intent-Filter MUSS während der Installation der Anwendung versucht werden und alle erfolgreich validierten UIR-Intent-Filter MÜSSEN als Standard-App-Handler für ihre UIRs festgelegt werden.
• Sie KÖNNEN bestimmte URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen, wenn sie erfolgreich überprüft wurden, aber andere infrage kommende URI-Filter die Überprüfung nicht bestehen. Wenn ein Gerät dies tut, MUSS es dem Nutzer im Einstellungsmenü geeignete Überschreibungen pro URI-Muster zur Verfügung stellen.
• Nutzer MÜSSEN in den Einstellungen die Möglichkeit haben, App-Links für jede App einzeln zu verwalten. Das muss so aussehen:
  • [C-0-6] Der Nutzer MUSS das Standardverhalten von App-Links für eine App als Ganzes überschreiben können, sodass die App immer geöffnet wird, immer gefragt wird oder nie geöffnet wird. Dies muss für alle infrage kommenden URI-Intent-Filter gleichermaßen gelten.
  • [C-0-7] Der Nutzer MUSS eine Liste der infrage kommenden URI-Intent-Filter sehen können.
  • Die Geräteimplementierung KANN dem Nutzer die Möglichkeit geben, bestimmte Kandidaten-URI-Intent-Filter, die erfolgreich überprüft wurden, pro Intent-Filter zu überschreiben.
  • [C-0-8] Die Geräteimplementierung MUSS Nutzern die Möglichkeit bieten, bestimmte Kandidaten-URI-Intent-Filter anzusehen und zu überschreiben, wenn bei der Geräteimplementierung einige Kandidaten-URI-Intent-Filter die Überprüfung bestehen, andere jedoch nicht.

3.2.3.3. Intent-Namespaces

• [C-0-1] Geräteimplementierungen DÜRFEN keine Android-Komponente enthalten, die neue Intent- oder Broadcast-Intent-Muster mit einem ACTION-, CATEGORY- oder anderen Schlüsselstring im Namespace „android. “ oder „com.android.“ berücksichtigt.
• [C-0-2] Geräteimplementierer DÜRFEN keine Android-Komponenten einbinden, die neue Intent- oder Broadcast-Intent-Muster mit einem ACTION-, CATEGORY- oder anderen Schlüsselstring in einem Paketbereich einer anderen Organisation berücksichtigen.
• [C-0-3] Gerätehersteller DÜRFEN KEINE der Intent-Muster ändern oder erweitern, die von den in Abschnitt 3.2.3.1 aufgeführten Kern-Apps verwendet werden.
• Geräteimplementierungen DÜRFEN Intent-Muster mit Namespaces enthalten, die eindeutig und offensichtlich mit der eigenen Organisation verknüpft sind. Dieses Verbot entspricht dem für Java-Sprachklassen in Abschnitt 3.6.

3.2.3.4. Broadcast-Intents

Drittanbieteranwendungen sind darauf angewiesen, dass die Plattform bestimmte Intents überträgt, um sie über Änderungen in der Hardware- oder Softwareumgebung zu informieren.

Geräteimplementierungen:

• [C-0-1] MUSS die öffentlichen Broadcast-Intents als Reaktion auf entsprechende Systemereignisse übertragen, wie in der SDK-Dokumentation beschrieben. Diese Anforderung steht nicht im Widerspruch zu Abschnitt 3.5, da die Einschränkung für Hintergrundanwendungen auch in der SDK-Dokumentation beschrieben wird.

3.2.3.5. Standard-App-Einstellungen

Android bietet Einstellungen, mit denen Nutzer auf einfache Weise ihre Standardanwendungen auswählen können, z. B. für den Startbildschirm oder SMS.

Sofern sinnvoll, MUSS in Geräteimplementierungen ein ähnliches Einstellungsmenü bereitgestellt werden, das mit dem Intent-Filtermuster und den API-Methoden kompatibel ist, die in der SDK-Dokumentation unten beschrieben werden.

Wenn Geräteimplementierungen android.software.home_screen melden, gilt Folgendes:

• [C-1-1] Der android.settings.HOME_SETTINGS-Intent muss berücksichtigt werden, um ein Standardmenü für die App-Einstellungen für den Startbildschirm anzuzeigen.

Wenn Geräteimplementierungen android.hardware.telephony melden, gilt Folgendes:

• [C-2-1] Es MUSS ein Einstellungsmenü vorhanden sein, in dem der Intent android.provider.Telephony.ACTION_CHANGE_DEFAULT aufgerufen wird, um ein Dialogfeld zum Ändern der Standard-SMS-App anzuzeigen.

• [C-2-2] MUSS die Intention android.telecom.action.CHANGE_DEFAULT_DIALER berücksichtigen, um ein Dialogfeld anzuzeigen, in dem der Nutzer die Standard-Telefonie-App ändern kann.

• [C-2-3] MUSS den Intent android.telecom.action.CHANGE_PHONE_ACCOUNTS berücksichtigen, um dem Nutzer die Möglichkeit zu geben, das ConnectionServices zu konfigurieren, das mit dem PhoneAccounts verknüpft ist, sowie ein Standard-PhoneAccount, das der Telekommunikationsanbieter für ausgehende Anrufe verwendet. Die AOSP-Implementierung erfüllt diese Anforderung, indem sie im Menü „Einstellungen“ unter „Anrufe“ das Menü „Anrufkonten“ enthält.

Wenn Geräteimplementierungen android.hardware.nfc.hce melden, gilt Folgendes:

• [C-3-1] MUSS den Intent android.settings.NFC_PAYMENT_SETTINGS unterstützen, um ein Standardmenü für App-Einstellungen für das kontaktlose Bezahlen anzuzeigen.

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

• [C-4-1] Der android.settings.ACTION_VOICE_INPUT_SETTINGS-Intent MUSS berücksichtigt werden, um ein Standardmenü für App-Einstellungen für die Spracheingabe und den Assistenten anzuzeigen.

3.2.4. Aktivitäten auf sekundären Displays

Wenn Geräteimplementierungen das Starten normaler Android-Aktivitäten auf sekundären Displays zulassen, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag android.software.activities_on_secondary_displays gesetzt werden.
• [C-1-2] MUSS API-Kompatibilität ähnlich einer Aktivität auf dem primären Display garantieren.
• [C-1-3] Die neue Aktivität MUSS auf demselben Display wie die Aktivität, die sie gestartet hat, angezeigt werden, wenn die neue Aktivität ohne Angabe eines Zieldisplays über die ActivityOptions.setLaunchDisplayId() API gestartet wird.
• [C-1-4] ALLE Aktivitäten MÜSSEN beendet werden, wenn ein Display mit dem Flag Display.FLAG_PRIVATE entfernt wird.
• [C-1-5] ALLE Aktivitäten auf einem VirtualDisplay MÜSSEN entsprechend skaliert werden, wenn die Anzeige selbst skaliert wird.
• Kann eine IME (Input Method Editor, ein Steuerelement, mit dem Nutzer Text eingeben können) auf dem primären Display anzeigen, wenn ein Texteingabefeld auf einem sekundären Display fokussiert wird.
• Der Eingabefokus sollte auf dem sekundären Display unabhängig vom primären Display implementiert werden, wenn Touch- oder Tasteneingaben unterstützt werden.
• MUSS android.content.res.Configuration haben, das dem Display entspricht, damit es angezeigt wird, korrekt funktioniert und die Kompatibilität beibehalten wird, wenn eine Aktivität auf dem sekundären Display gestartet wird.

Wenn Geräteimplementierungen das Starten normaler Android-Aktivitäten auf sekundären Displays zulassen und primäre und sekundäre Displays unterschiedliche android.util.DisplayMetrics haben:

• [C-2-1] Aktivitäten, die nicht in der Größe angepasst werden können (mit resizeableActivity=false in AndroidManifest.xml), und Apps, die auf API-Level 23 oder niedriger ausgerichtet sind, DÜRFEN NICHT auf sekundären Displays zugelassen werden.

Wenn Geräteimplementierungen das Starten normaler Android-Aktivitäten auf sekundären Displays zulassen und ein sekundäres Display das Flag android.view.Display.FLAG_PRIVATE hat:

• [C-3-1] Nur der Inhaber des Displays, des Systems und der Aktivitäten, die bereits auf dem Display angezeigt werden, darf die Inhalte auf dem Display starten. Alle Nutzer können auf einem Display mit dem Flag android.view.Display.FLAG_PUBLIC starten.

3.3 Kompatibilität mit nativer API

Gerätehersteller sind:

Die Kompatibilität mit nativem Code ist schwierig. Aus diesem Grund sind Gerätehersteller:

• [SR] Es wird DRINGEND EMPFOHLEN, die Implementierungen der unten aufgeführten Bibliotheken aus dem Upstream-Android Open Source Project zu verwenden.

3.3.1. Binärschnittstellen

Verwalteter Dalvik-Bytecode kann nativen Code aufrufen, der in der .apk-Datei der Anwendung als ELF-Datei .so bereitgestellt wird, die für die entsprechende Gerätehardwarearchitektur kompiliert wurde. Da nativer Code stark von der zugrunde liegenden Prozessortechnologie abhängt, definiert Android im Android NDK eine Reihe von Application Binary Interfaces (ABIs).

Geräteimplementierungen:

• [C-0-1] MUSS mit mindestens einem definierten ABI kompatibel sein und die Kompatibilität mit dem Android NDK implementieren.
• [C-0-2] MUSS Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code aufzurufen, wobei die standardmäßige Java Native Interface-Semantik (JNI) verwendet wird.
• [C-0-3] MUSS mit jeder erforderlichen Bibliothek in der Liste unten quellcodekompatibel (d.h. headerkompatibel) und binärkompatibel (für die ABI) sein.
• [C-0-4] MUSS das entsprechende 32‑Bit-ABI unterstützen, wenn ein 64‑Bit-ABI unterstützt wird.
• [C-0-5] MUSS die vom Gerät unterstützte native Application Binary Interface (ABI) über die Parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS und android.os.Build.SUPPORTED_64_BIT_ABIS genau angeben. Jeder Parameter ist eine durch Kommas getrennte Liste von ABIs, die vom bevorzugtesten zum am wenigsten bevorzugten ABI sortiert sind.
• [C-0-6] MÜSSEN über die oben genannten Parameter nur die ABIs gemeldet werden, die in der aktuellen Version der Android NDK ABI Management-Dokumentation dokumentiert und beschrieben sind, und MÜSSEN die Unterstützung für die Advanced SIMD-Erweiterung (auch bekannt als NEON) enthalten.

• [C-0-7] MÜSSEN alle folgenden Bibliotheken, die native APIs bereitstellen, für Apps mit nativem Code verfügbar sein:

  • libaaudio.so (native AAudio-Audiounterstützung)
  • libandroid.so (Unterstützung nativer Android-Aktivitäten)
  • libc (C-Bibliothek)
  • libcamera2ndk.so
  • libdl (dynamischer Linker)
  • libEGL.so (native OpenGL-Oberflächenverwaltung)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (Android-Protokollierung)
  • libmediandk.so (Unterstützung für native Media-APIs)
  • libm (Mathematikbibliothek)
  • libOpenMAXAL.so (Unterstützung für OpenMAX AL 1.0.1)
  • libOpenSLES.so (OpenSL ES 1.0.1-Audio-Unterstützung)
  • libRS.so
  • libstdc++ (minimale Unterstützung für C++)
  • libvulkan.so (Vulkan)
  • libz (Zlib-Komprimierung)
  • JNI-Schnittstelle

• [C-0-8] Öffentliche Funktionen für die oben aufgeführten nativen Bibliotheken dürfen NICHT hinzugefügt oder entfernt werden.

• [C-0-9] Zusätzliche Nicht-AOSP-Bibliotheken, die Drittanbieter-Apps direkt zur Verfügung gestellt werden, MÜSSEN in /vendor/etc/public.libraries.txt aufgeführt werden.
• [C-0-10] DÜRFEN keine anderen nativen Bibliotheken, die in AOSP als Systembibliotheken implementiert und bereitgestellt werden, für Drittanbieter-Apps mit API-Level 24 oder höher verfügbar machen, da diese reserviert sind.
• [C-0-11] MÜSSEN alle Funktionssymbole von OpenGL ES 3.1 und dem Android Extension Pack, wie im NDK definiert, über die libGLESv3.so-Bibliothek exportiert werden. Alle Symbole MÜSSEN vorhanden sein. In Abschnitt 7.1.4.1 werden die Anforderungen für die vollständige Implementierung der einzelnen entsprechenden Funktionen genauer beschrieben.
• [C-0-12] MÜSSEN Funktionssymbole für die Kernfunktionssymbole von Vulkan 1.0 sowie die Erweiterungen VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 und VK_KHR_get_physical_device_properties2 über die libvulkan.so-Bibliothek exportieren. Alle Symbole MÜSSEN vorhanden sein. In Abschnitt 7.1.4.2 werden die Anforderungen für die vollständige Implementierung der einzelnen entsprechenden Funktionen genauer beschrieben.
• Sollte mit dem Quellcode und den Headerdateien erstellt werden, die im Upstream-Android Open Source Project verfügbar sind

In zukünftigen Versionen des Android NDK werden möglicherweise zusätzliche ABIs unterstützt.

3.3.2 Kompatibilität mit nativem 32-Bit-ARM-Code

Wenn es sich bei Geräteimplementierungen um 64‑Bit-ARM-Geräte handelt, gilt Folgendes:

• [C-1-1] Obwohl bei der ARMv8-Architektur mehrere CPU-Operationen eingestellt werden, darunter einige, die in vorhandenem nativen Code verwendet werden, MÜSSEN die folgenden eingestellten Operationen für nativen 32-Bit-ARM-Code weiterhin verfügbar sein, entweder durch native CPU-Unterstützung oder durch Software-Emulation:

  • Anleitung für SWP und SWPB
  • SETEND-Anweisung
  • CP15ISB-, CP15DSB- und CP15DMB-Barrierevorgänge

Wenn Geräteimplementierungen eine 32-Bit-ARM-ABI enthalten, gilt Folgendes:

• [C-2-1] MUSS die folgenden Zeilen in /proc/cpuinfo enthalten, wenn sie von 32-Bit-ARM-Anwendungen gelesen wird, um die Kompatibilität mit Anwendungen zu gewährleisten, die mit älteren Versionen des Android NDK erstellt wurden.

  • Features:, gefolgt von einer Liste aller optionalen ARMv7-CPU-Funktionen, die vom Gerät unterstützt werden.
  • CPU architecture:, gefolgt von einer Ganzzahl, die die höchste unterstützte ARM-Architektur des Geräts beschreibt (z.B. „8“ für ARMv8-Geräte).

• /proc/cpuinfo sollte nicht geändert werden, wenn es von 64-Bit-ARM- oder Nicht-ARM-Anwendungen gelesen wird.

3.4. Webkompatibilität

3.4.1. WebView-Kompatibilität

Wenn Geräteimplementierungen eine vollständige Implementierung der android.webkit.Webview API bieten, gilt Folgendes:

• [C-1-1] MÜSSEN android.software.webview melden.
• [C-1-2] MUSS für die Implementierung der android.webkit.WebView API den Chromium-Projekt-Build aus dem Upstream-Android-Open-Source-Projekt im Android 8.1-Branch verwenden.

• [C-1-3] Der vom WebView gemeldete User-Agent-String MUSS dieses Format haben:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • Der Wert des Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE übereinstimmen.
  • Der Wert des Strings „$(MODEL)“ MUSS mit dem Wert für „android.os.Build.MODEL“ übereinstimmen.
  • Der Wert des $(BUILD)-Strings MUSS mit dem Wert für android.os.Build.ID übereinstimmen.
  • Der Wert des Strings $(CHROMIUM_VER) MUSS die Version von Chromium im Upstream-Android Open Source Project sein.
  • Bei Geräteimplementierungen KANN „Mobile“ im User-Agent-String weggelassen werden.

• Die WebView-Komponente SOLLTE so viele HTML5-Funktionen wie möglich unterstützen und, falls sie die Funktion unterstützt, der HTML5-Spezifikation entsprechen.

3.4.2. Browserkompatibilität

Wenn Geräteimplementierungen eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten, müssen sie:

• [C-1-1] MUSS jede dieser APIs unterstützen, die mit HTML5 verknüpft sind:
  • Anwendungscache/Offlinebetrieb
  • <video>-Tag
  • Standortbestimmung
• [C-1-2] MUSS die HTML5/W3C-Web Storage API unterstützen und SOLLTE die HTML5/W3C-IndexedDB API unterstützen. Da die Gremien für Webentwicklungsstandards auf IndexedDB anstelle von Web Storage umstellen, wird erwartet, dass IndexedDB in einer zukünftigen Version von Android eine erforderliche Komponente wird.
• MAY ship a custom user agent string in the standalone Browser application.
• Sollte in der eigenständigen Browseranwendung (unabhängig davon, ob sie auf der Upstream-WebKit-Browseranwendung oder einem Ersatz von Drittanbietern basiert) so viel HTML5 wie möglich unterstützen.

Wenn Geräteimplementierungen jedoch keine eigenständige Browseranwendung enthalten, gilt Folgendes:

• [C-2-1] MUSS weiterhin die öffentlichen Intent-Muster unterstützen, wie in Abschnitt 3.2.3.1 beschrieben.

3.5. Verhaltenskompatibilität der API

Das Verhalten der einzelnen API-Typen (verwaltet, Soft, nativ und Web) muss mit der bevorzugten Implementierung des Upstream-Android Open Source Project übereinstimmen. Hier einige konkrete Beispiele für die Kompatibilität:

• [C-0-1] Geräte DÜRFEN das Verhalten oder die Semantik einer Standard-Intent nicht ändern.
• [C-0-2] Geräte DÜRFEN den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, ContentProvider usw.) NICHT ändern.
• [C-0-3] Geräte DÜRFEN die Semantik einer Standardberechtigung NICHT ändern.
• Geräte DÜRFEN die für Hintergrundanwendungen geltenden Einschränkungen NICHT ändern. Insbesondere für Hintergrund-Apps gilt Folgendes:
  • [C-0-4] MÜSSEN die Ausführung von Callbacks beenden, die von der App registriert wurden, um Ausgaben von GnssMeasurement und GnssNavigationMessage zu empfangen.
  • [C-0-5] Sie MÜSSEN die Häufigkeit der Aktualisierungen, die der App über die API-Klasse LocationManager oder die Methode WifiManager.startScan() bereitgestellt werden, ratenbegrenzen.
  • [C-0-6] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, DÜRFEN im Manifest der App KEINE Broadcast-Empfänger für die impliziten Broadcasts von Standard-Android-Intents registriert werden, es sei denn, für den Broadcast-Intent ist die Berechtigung "signature" oder "signatureOrSystem" protectionLevel erforderlich oder er steht auf der Ausnahmeliste.
  • [C-0-7] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN die Hintergrunddienste der App beendet werden, so als hätte die App die Methode stopSelf() der Dienste aufgerufen, es sei denn, die App wird auf eine temporäre Zulassungsliste gesetzt, um eine für den Nutzer sichtbare Aufgabe auszuführen.
  • [C-0-8] Wenn die App auf API‑Level 25 oder höher ausgerichtet ist, MÜSSEN die von der App gehaltenen Wakelocks freigegeben werden.

Die obige Liste ist nicht vollständig. Die Compatibility Test Suite (CTS) testet wichtige Teile der Plattform auf Verhaltenskompatibilität, aber nicht alle. Es liegt in der Verantwortung des Implementierers, für die Verhaltenskompatibilität mit dem Open-Source-Projekt für Android zu sorgen. Aus diesem Grund SOLLTEN Geräteimplementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt wichtige Teile des Systems neu zu implementieren.

3.6. API-Namespaces

Android folgt den von der Programmiersprache Java definierten Paket- und Klassen-Namespace-Konventionen. Um die Kompatibilität mit Drittanbieteranwendungen zu gewährleisten, DÜRFEN Gerätehersteller keine verbotenen Änderungen (siehe unten) an diesen Paket-Namespaces vornehmen:

• java.*
• javax.*
• sun.*
• android.*
• com.android.*

Das bedeutet, dass sie:

• [C-0-1] Öffentlich zugängliche APIs auf der Android-Plattform DÜRFEN NICHT geändert werden, indem Methoden- oder Klassensignaturen geändert oder Klassen oder Klassenfelder entfernt werden.
• [C-0-2] Es DÜRFEN KEINE öffentlich zugänglichen Elemente (z. B. Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) oder Test- oder System-APIs zu den APIs in den oben genannten Namespaces hinzugefügt werden. Ein „öffentlich bereitgestelltes Element“ ist jedes Konstrukt, das nicht mit dem Marker „@hide“ versehen ist, wie er im Upstream-Android-Quellcode verwendet wird.

Gerätehersteller DÜRFEN die zugrunde liegende Implementierung der APIs ändern, aber solche Änderungen:

• [C-0-3] Das angegebene Verhalten und die Java-Sprachsignatur öffentlich verfügbarer APIs dürfen NICHT beeinträchtigt werden.
• [C-0-4] DÜRFEN NICHT beworben oder Entwicklern auf andere Weise präsentiert werden.

Gerätehersteller DÜRFEN jedoch benutzerdefinierte APIs außerhalb des Standard-Android-Namespace hinzufügen. Die benutzerdefinierten APIs:

• [C-0-5] DARF NICHT in einem Namespace sein, der einer anderen Organisation gehört oder sich auf eine andere Organisation bezieht. Gerätehersteller DÜRFEN beispielsweise KEINE APIs zum Namespace com.google.* oder einem ähnlichen Namespace hinzufügen. Das ist nur Google erlaubt. Ebenso DÜRFEN Google KEINE APIs zu den Namespaces anderer Unternehmen hinzufügen.
• [C-0-6] MUSS in einer gemeinsam genutzten Android-Bibliothek verpackt werden, damit nur Apps, die sie explizit verwenden (über den <uses-library>-Mechanismus), von der erhöhten Speichernutzung solcher APIs betroffen sind.

Wenn ein Gerätehersteller vorschlägt, einen der oben genannten Paket-Namespaces zu verbessern (z. B. durch Hinzufügen nützlicher neuer Funktionen zu einer vorhandenen API oder durch Hinzufügen einer neuen API), SOLLTE der Hersteller source.android.com aufrufen und den Prozess zum Beitragen von Änderungen und Code gemäß den Informationen auf dieser Website starten.

Die oben genannten Einschränkungen entsprechen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java. In diesem Abschnitt werden diese Konventionen lediglich verstärkt und durch die Aufnahme in diese Kompatibilitätsdefinition verbindlich gemacht.

3.7. Laufzeitkompatibilität

Geräteimplementierungen:

• [C-0-1] MÜSSEN das vollständige Dalvik Executable-Format (DEX) und die Dalvik-Bytecode-Spezifikation und -Semantik unterstützen.

• [C-0-2] MUSS Dalvik-Laufzeitumgebungen so konfigurieren, dass Speicher gemäß der Upstream-Android-Plattform und wie in der folgenden Tabelle angegeben zugewiesen wird. Abschnitt 7.1.1 enthält Definitionen für Bildschirmgröße und ‑dichte.

• Sollte Android RunTime (ART), die Referenz-Upstream-Implementierung des Dalvik Executable-Formats, und das Paketverwaltungssystem der Referenzimplementierung verwenden.

• Sollten Fuzz-Tests in verschiedenen Ausführungsmodi und auf verschiedenen Zielarchitekturen ausgeführt werden, um die Stabilität der Laufzeit zu gewährleisten. Weitere Informationen finden Sie auf der Website des Open-Source-Projekts von Android unter JFuzz und DexFuzz.

Die unten angegebenen Arbeitsspeicherwerte sind Mindestwerte. Geräteimplementierungen KÖNNEN mehr Arbeitsspeicher pro Anwendung zuweisen.

Bildschirmlayout	Bildschirmdichte	Mindestspeicher für die App
Android-Uhr	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36 MB
	280 dpi (280dpi)
	320 dpi (xhdpi)	48 MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56 MB
	420 dpi (420dpi)	64 MB
	480 dpi (xxhdpi)	88 MB
	560 dpi (560dpi)	112 MB
	640 dpi (xxxhdpi)	154 MB
Klein/Normal	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48 MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80 MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96 MB
	420 dpi (420dpi)	112 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi (560dpi)	192 MB
	640 dpi (xxxhdpi)	256 MB
Groß	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)	48 MB
	213 dpi (tvdpi)	80 MB
	240 dpi (hdpi)
	280 dpi (280dpi)	96 MB
	320 dpi (xhdpi)	128 MB
	360 dpi (360dpi)	160 MB
	400 dpi (400dpi)	192 MB
	420 dpi (420dpi)	228 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi (560dpi)	384 MB
	640 dpi (xxxhdpi)	512 MB
xlarge	120 dpi (ldpi)	48 MB
	160 dpi (mdpi)	80 MB
	213 dpi (tvdpi)	96 MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144 MB
	320 dpi (xhdpi)	192 MB
	360 dpi (360dpi)	240 MB
	400 dpi (400dpi)	288 MB
	420 dpi (420dpi)	336 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi (560dpi)	576 MB
	640 dpi (xxxhdpi)	768 MB

3.8. Kompatibilität der Benutzeroberfläche

3.8.1. Launcher (Startbildschirm)

Android enthält eine Launcher-Anwendung (Startbildschirm) und unterstützt Drittanbieteranwendungen, die den Geräte-Launcher (Startbildschirm) ersetzen.

Wenn Geräteimplementierungen es Drittanbieteranwendungen ermöglichen, den Startbildschirm des Geräts zu ersetzen, gilt Folgendes:

• [C-1-1] MUSS die Plattformfunktion android.software.home_screen deklarieren.
• [C-1-2] MUSS das AdaptiveIconDrawable-Objekt zurückgeben, wenn die Drittanbieteranwendung das <adaptive-icon>-Tag verwendet, um ihr Symbol bereitzustellen, und die PackageManager-Methoden zum Abrufen von Symbolen aufgerufen werden.

Wenn Geräteimplementierungen einen Standard-Launcher enthalten, der das Anpinnen von Verknüpfungen in der App unterstützt, gilt Folgendes:

• [C-2-1] MÜSSEN true für ShortcutManager.isRequestPinShortcutSupported() melden.
• [C-2-2] MUSS den Nutzer fragen, bevor ein von Apps über die API-Methode ShortcutManager.requestPinShortcut() angeforderter Shortcut hinzugefügt wird.
• [C-2-3] MUSS angepinnte Verknüpfungen sowie dynamische und statische Verknüpfungen unterstützen, wie auf der Seite „App-Verknüpfungen“ beschrieben.

Wenn Geräteimplementierungen das Anpinnen von Verknüpfungen in Apps nicht unterstützen, gilt Folgendes:

• [C-3-1] MÜSSEN false für ShortcutManager.isRequestPinShortcutSupported() melden.

Wenn in Geräteimplementierungen ein Standard-Launcher implementiert ist, der über die ShortcutManager API schnellen Zugriff auf die zusätzlichen Verknüpfungen bietet, die von Drittanbieter-Apps bereitgestellt werden, gilt Folgendes:

• [C-4-1] MUSS alle dokumentierten Funktionen für Verknüpfungen unterstützen (z.B. statische und dynamische Verknüpfungen, Anpinnen von Verknüpfungen) und die APIs der ShortcutManager-API-Klasse vollständig implementieren.

Wenn Geräteimplementierungen eine Standard-Launcher-App enthalten, in der Badges für die App-Symbole angezeigt werden, gilt Folgendes:

• [C-5-1] MUSS die API-Methode NotificationChannel.setShowBadge() respektieren. Das bedeutet, dass eine visuelle Aufforderung im Zusammenhang mit dem App-Symbol angezeigt wird, wenn der Wert auf true festgelegt ist. Wenn für alle Benachrichtigungschannels der App der Wert false festgelegt ist, wird kein App-Symbol-Badging-Schema angezeigt.
• MAY override the app icon badges with their proprietary badging scheme when third-party applications indicate support of the proprietary badging scheme through the use of proprietary APIs, but SHOULD use the resources and values provided through the notification badges APIs described in the SDK, such as the Notification.Builder.setNumber() and the Notification.Builder.setBadgeIconType() API.

3.8.2. Widgets

Android unterstützt App-Widgets von Drittanbietern, indem ein Komponententyp und eine entsprechende API und ein entsprechender Lebenszyklus definiert werden, mit denen Anwendungen dem Endnutzer ein AppWidget zur Verfügung stellen können.

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

• [C-1-1] MUSS die Unterstützung für die Plattformfunktion android.software.app_widgets deklarieren.
• [C-1-2] MUSS eine integrierte Unterstützung für App-Widgets enthalten und Benutzeroberflächen-Funktionen zum Hinzufügen, Konfigurieren, Anzeigen und Entfernen von App-Widgets direkt im Launcher bereitstellen.
• [C-1-3] MUSS Widgets mit einer Größe von 4 × 4 im Standardraster rendern können. Weitere Informationen finden Sie in der Android SDK-Dokumentation unter App Widget DesignGuidelines.
• MAY unterstützt App-Widgets auf dem Sperrbildschirm.

Wenn Geräteimplementierungen App-Widgets von Drittanbietern und das Anpinnen von Verknüpfungen in der App unterstützen, gilt Folgendes:

• [C-2-1] MÜSSEN true für AppWidgetManager.html.isRequestPinAppWidgetSupported() melden.
• [C-2-2] MUSS den Nutzer fragen, bevor ein von Apps über die API-Methode AppWidgetManager.requestPinAppWidget() angeforderter Shortcut hinzugefügt wird.

3.8.3. Benachrichtigungen

Android umfasst die APIs Notification und NotificationManager, mit denen Drittanbieter-App-Entwickler Nutzer über wichtige Ereignisse benachrichtigen und die Aufmerksamkeit der Nutzer mithilfe der Hardwarekomponenten (z.B. Ton, Vibration und Licht) und Softwarefunktionen (z.B. Benachrichtigungsfeld, Systemleiste) des Geräts auf sich ziehen können.

3.8.3.1. Darstellung von Benachrichtigungen

Wenn Geräteimplementierungen es Drittanbieter-Apps ermöglichen, Nutzer über wichtige Ereignisse zu benachrichtigen, gilt Folgendes:

• [C-1-1] MUSS Benachrichtigungen unterstützen, die Hardwarefunktionen verwenden, wie in der SDK-Dokumentation beschrieben und soweit dies mit der Hardware der Geräteimplementierung möglich ist. Wenn eine Geräteimplementierung beispielsweise einen Vibrator enthält, MUSS sie die Vibrations-APIs korrekt implementieren. Wenn in einer Geräteimplementierung Hardware fehlt, MÜSSEN die entsprechenden APIs als No-Ops implementiert werden. Dieses Verhalten wird in Abschnitt 7 genauer beschrieben.
• [C-1-2] Alle in den APIs oder im Symbol-Styleguide für die Status-/Systemleiste bereitgestellten Ressourcen (Symbole, Animationsdateien usw.) MÜSSEN korrekt gerendert werden. Es DARF jedoch eine alternative Nutzererfahrung für Benachrichtigungen als die von der Android Open Source-Referenzimplementierung bereitgestellte angeboten werden.
• [C-1-3] MUSS die für die APIs beschriebenen Verhaltensweisen zum Aktualisieren, Entfernen und Gruppieren von Benachrichtigungen berücksichtigen und ordnungsgemäß implementieren.
• [C-1-4] Das vollständige Verhalten der NotificationChannel API, das im SDK dokumentiert ist, MUSS angegeben werden.
• [C-1-5] Es MUSS eine Möglichkeit für Nutzer geben, Benachrichtigungen einer bestimmten Drittanbieter-App pro Kanal und App-Paketebene zu blockieren und zu ändern.
• [C-1-6] MUSS auch eine Möglichkeit für Nutzer bieten, gelöschte Benachrichtigungskanäle aufzurufen.
• Sollte umfassende Benachrichtigungen unterstützen.
• Sollte einige Benachrichtigungen mit höherer Priorität als Vorabbenachrichtigungen präsentieren.
• Es SOLLTE eine Möglichkeit für Nutzer geben, Benachrichtigungen zurückzustellen.
• MAY kann nur die Sichtbarkeit und den Zeitpunkt verwalten, zu dem Drittanbieter-Apps Nutzer über wichtige Ereignisse benachrichtigen können, um Sicherheitsprobleme wie Ablenkung des Fahrers zu minimieren.

Wenn Geräteimplementierungen Rich Notifications unterstützen, gilt Folgendes:

• [C-2-1] MUSS die genauen Ressourcen verwenden, die über die API-Klasse Notification.Style und ihre Unterklassen für die präsentierten Ressourcenelemente bereitgestellt werden.
• Jedes in der API-Klasse Notification.Style und ihren Unterklassen definierte Ressourcenelement (z.B. Symbol, Titel und Zusammenfassungstext) SOLLTE dargestellt werden.

Wenn Geräteimplementierungen Pop-up-Benachrichtigungen unterstützen, gilt Folgendes:

• [C-3-1] Bei der Darstellung von Kurzbenachrichtigungen MUSS die Ansicht und die Ressourcen für Kurzbenachrichtigungen verwendet werden, die in der API-Klasse Notification.Builder beschrieben sind.

3.8.3.2. Mitteilungs-Listener-Dienst

Android enthält die NotificationListenerService-APIs, mit denen Apps (sofern sie vom Nutzer explizit aktiviert wurden) eine Kopie aller Benachrichtigungen erhalten können, sobald diese gesendet oder aktualisiert werden.

Wenn Geräteimplementierungen das Feature-Flag android.hardware.ram.normal melden, gilt Folgendes:

• [C-1-1] MÜSSEN Benachrichtigungen vollständig und zeitnah an alle installierten und vom Nutzer aktivierten Listener-Dienste aktualisieren, einschließlich aller Metadaten, die an das Benachrichtigungsobjekt angehängt sind.
• [C-1-2] MUSS den API-Aufruf snoozeNotification() berücksichtigen, die Benachrichtigung schließen und nach der im API-Aufruf festgelegten Schlummerdauer einen Callback ausführen.

Wenn Geräteimplementierungen eine Möglichkeit zum Zurückstellen von Benachrichtigungen bieten, müssen sie:

• [C-2-1] Der Status von pausierten Benachrichtigungen MUSS über die Standard-APIs wie NotificationListenerService.getSnoozedNotifications() korrekt wiedergegeben werden.
• [C-2-2] MUSS diese Nutzerfunktion zum Schlummern von Benachrichtigungen aus jeder installierten Drittanbieter-App zur Verfügung stellen, sofern sie nicht von persistenten/Vordergrunddiensten stammen.

3.8.3.3. Bitte nicht stören

Wenn Geräteimplementierungen die Funktion „Bitte nicht stören“ unterstützen, gilt Folgendes:

• [C-1-1] Es MUSS eine Aktivität implementiert werden, die auf die Intent-Aktion ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS reagiert. Bei Implementierungen mit UI_MODE_TYPE_NORMAL MUSS es sich um eine Aktivität handeln, in der der Nutzer der App den Zugriff auf die Konfigurationen der Funktion „Bitte nicht stören“ gewähren oder verweigern kann.
• [C-1-2] MUSS, wenn die Geräteimplementierung eine Möglichkeit für den Nutzer bietet, Drittanbieter-Apps den Zugriff auf die Konfiguration der Funktion „Bitte nicht stören“ zu gewähren oder zu verweigern, die von Anwendungen erstellten Automatischen Regeln für „Bitte nicht stören“ neben den vom Nutzer erstellten und vordefinierten Regeln anzeigen.
• [C-1-3] Die Werte von suppressedVisualEffects, die über NotificationManager.Policy übergeben werden, MÜSSEN berücksichtigt werden. Wenn in einer App die Flags SUPPRESSED_EFFECT_SCREEN_OFF oder SUPPRESSED_EFFECT_SCREEN_ON festgelegt sind, SOLLTE dem Nutzer im Menü „Bitte nicht stören“-Einstellungen angezeigt werden, dass die visuellen Effekte unterdrückt werden.

3.8.4. Suchen

Android enthält APIs, mit denen Entwickler Suchfunktionen in ihre Anwendungen einbinden und die Daten ihrer Anwendungen in der globalen Systemsuche verfügbar machen können. Im Allgemeinen besteht diese Funktion aus einer einzigen, systemweiten Benutzeroberfläche, über die Nutzer Anfragen eingeben können. Während der Eingabe werden Vorschläge angezeigt und die Ergebnisse werden präsentiert. Mit den Android-APIs können Entwickler diese Oberfläche wiederverwenden, um die Suche in ihren eigenen Apps zu ermöglichen und Ergebnisse für die gemeinsame globale Suchoberfläche bereitzustellen.

• Android-Geräteimplementierungen SOLLTEN eine globale Suche enthalten, eine einzelne, gemeinsame, systemweite Suchbenutzeroberfläche, die in der Lage ist, in Echtzeit Vorschläge als Reaktion auf Nutzereingaben zu machen.

Wenn Geräteimplementierungen die globale Suchoberfläche implementieren, gilt Folgendes:

• [C-1-1] MUSS die APIs implementieren, die es Drittanbieteranwendungen ermöglichen, dem Suchfeld Vorschläge hinzuzufügen, wenn es im globalen Suchmodus ausgeführt wird.

Wenn keine Drittanbieter-Apps installiert sind, die die globale Suche nutzen:

• Standardmäßig SOLLTEN Ergebnisse und Vorschläge der Websuchmaschine angezeigt werden.

Android umfasst auch die Assist APIs, mit denen Anwendungen festlegen können, wie viele Informationen des aktuellen Kontexts mit dem Assistenten auf dem Gerät geteilt werden.

Wenn Geräteimplementierungen die Assist-Aktion unterstützen, gilt Folgendes:

• [C-2-1] MUSS dem Endnutzer klar anzeigen, wann der Kontext geteilt wird, entweder:
  • Jedes Mal, wenn die Assistent-App auf den Kontext zugreift, wird ein weißes Licht am Rand des Displays angezeigt, das die Dauer und Helligkeit der Android Open Source Project-Implementierung erreicht oder überschreitet.
  • Bei der vorinstallierten Assistenten-App muss eine Nutzeraufforderung weniger als zwei Navigationsschritte vom Menü für die Standardeinstellungen für die Spracheingabe und die Assistenten-App entfernt sein. Außerdem darf der Kontext nur dann geteilt werden, wenn die Assistenten-App explizit vom Nutzer über ein Hotword oder eine Eingabe über die Navigationstaste für den Assistenten aufgerufen wird.
• [C-2-2] Die festgelegte Interaktion zum Starten der Assistenz-App gemäß Abschnitt 7.2.3 MUSS die vom Nutzer ausgewählte Assistenz-App starten, d. h. die App, die VoiceInteractionService implementiert, oder eine Aktivität, die den ACTION_ASSIST-Intent verarbeitet.
• [SR] Es wird DRINGEND EMPFOHLEN, die HOME-Taste lange zu drücken, da dies die vorgesehene Interaktion ist.

3.8.5. Benachrichtigungen und Pop-up-Meldungen

Anwendungen können die Toast API verwenden, um dem Endnutzer kurze, nicht modale Strings anzuzeigen, die nach kurzer Zeit wieder verschwinden. Mit der API für den Fenstertyp TYPE_APPLICATION_OVERLAY können Warnfenster als Overlay über anderen Apps angezeigt werden.

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

• [C-1-1] MUSS eine Möglichkeit für Nutzer bieten, zu verhindern, dass eine App Benachrichtigungsfenster mit TYPE_APPLICATION_OVERLAY anzeigt . Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente im Benachrichtigungsfeld.

• [C-1-2] MUSS die Toast API unterstützen und Toasts von Anwendungen für Endnutzer auf gut sichtbare Weise anzeigen.

3.8.6. Designs

Android bietet „Themes“ als Mechanismus, mit dem Anwendungen Stile auf eine gesamte Aktivität oder Anwendung anwenden können.

Android umfasst die Themenfamilien „Holo“ und „Material“ als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Holo-Thema, wie im Android SDK definiert, verwenden möchten.

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

• [C-1-1] DÜRFEN KEINE der für Anwendungen verfügbaren Holo-Designattribute ändern.
• [C-1-2] MUSS die „Material“-Themenfamilie unterstützen und DARF KEINE der Material-Themenattribute oder die für Anwendungen bereitgestellten Assets ändern.

Android enthält auch eine Designfamilie „Gerätestandard“ als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Erscheinungsbild des vom Geräteimplementierer definierten Gerätedesigns übernehmen möchten.

• Bei Geräteimplementierungen KÖNNEN die für Anwendungen verfügbaren Attribute des Standarddesigns des Geräts geändert werden.

Android unterstützt ein Variantendesign mit durchscheinenden Systemleisten, sodass App-Entwickler den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten füllen können. Damit Entwickler in dieser Konfiguration ein einheitliches Erlebnis haben, ist es wichtig, dass der Stil des Statusleistensymbols auf verschiedenen Geräteimplementierungen beibehalten wird.

Wenn Geräteimplementierungen eine Systemstatusleiste enthalten, gilt Folgendes:

• [C-2-1] Für Symbole für den Systemstatus (z. B. Signalstärke und Akkustand) und Benachrichtigungen, die vom System ausgegeben werden, MUSS Weiß verwendet werden, es sei denn, das Symbol weist auf einen problematischen Status hin oder eine App fordert mit dem Flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR eine helle Statusleiste an.
• [C-2-2] Bei Android-Geräteimplementierungen MUSS die Farbe der Systemstatussymbole in Schwarz geändert werden (weitere Informationen finden Sie unter R.style), wenn eine App eine helle Statusleiste anfordert.

3.8.7. Live-Hintergründe

Android definiert einen Komponententyp und eine entsprechende API und einen entsprechenden Lebenszyklus, mit denen Anwendungen dem Endnutzer ein oder mehrere Live-Hintergründe zur Verfügung stellen können. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabefunktionen, die als Hintergrund hinter anderen Anwendungen angezeigt werden.

Hardware gilt als geeignet für die zuverlässige Ausführung von Live-Hintergründen, wenn sie alle Live-Hintergründe ohne Einschränkungen der Funktionalität mit einer angemessenen Bildrate und ohne negative Auswirkungen auf andere Anwendungen ausführen kann. Wenn Einschränkungen in der Hardware dazu führen, dass Hintergrundbilder und/oder Anwendungen abstürzen, nicht richtig funktionieren, übermäßig viel CPU- oder Akkuleistung verbrauchen oder mit inakzeptabel niedrigen Frameraten ausgeführt werden, gilt die Hardware als nicht geeignet für Live-Hintergrundbilder. Einige Live-Hintergründe verwenden beispielsweise einen OpenGL 2.0- oder 3.x-Kontext, um ihre Inhalte zu rendern. Live-Hintergründe laufen auf Hardware, die mehrere OpenGL-Kontexte nicht unterstützt, nicht zuverlässig, da die Verwendung eines OpenGL-Kontexts durch den Live-Hintergrund mit anderen Anwendungen, die ebenfalls einen OpenGL-Kontext verwenden, in Konflikt geraten kann.

• Geräteimplementierungen, die Live-Hintergründe wie oben beschrieben zuverlässig ausführen können, SOLLTEN Live-Hintergründe implementieren.

Wenn Geräteimplementierungen Live-Hintergründe implementieren, gilt Folgendes:

• [C-1-1] MÜSSEN das Plattform-Funktions-Flag android.software.live_wallpaper melden.

3.8.8. Aktivitätswechsel

Der Upstream-Android-Quellcode enthält den Übersichtsbildschirm, eine Benutzeroberfläche auf Systemebene für den Aufgabenwechsel und die Anzeige von zuletzt aufgerufenen Aktivitäten und Aufgaben. Dabei wird ein Miniaturbild des grafischen Zustands der Anwendung zu dem Zeitpunkt verwendet, als der Nutzer die Anwendung zuletzt verlassen hat.

Bei Geräteimplementierungen, die die Navigationsschaltfläche für die Funktion „Zuletzt verwendet“ enthalten, wie in Abschnitt 7.2.3 beschrieben, KANN die Benutzeroberfläche geändert werden.

Wenn Geräteimplementierungen, die den Navigationsschlüssel für die Funktion „Letzte Apps“ enthalten, wie in Abschnitt 7.2.3 beschrieben, die Benutzeroberfläche ändern, gilt Folgendes:

• [C-1-1] Es MÜSSEN mindestens bis zu 7 angezeigte Aktivitäten unterstützt werden.
• Es SOLLTEN mindestens die Titel von 4 Aktivitäten gleichzeitig angezeigt werden.
• [C-1-2] Das Verhalten beim Anpinnen von Bildschirmen MUSS implementiert werden und dem Nutzer muss ein Einstellungsmenü zur Verfügung gestellt werden, in dem er die Funktion aktivieren oder deaktivieren kann.
• Die Markierungsfarbe, das Symbol und der Bildschirmtitel sollten in den letzten Aktionen angezeigt werden.
• Es SOLLTE eine Schließfunktion („x“) angezeigt werden, dies KANN jedoch verzögert werden, bis der Nutzer mit den Bildschirmen interagiert.
• Es SOLLTE einen Kurzbefehl geben, um einfach zur vorherigen Aktivität zu wechseln.
• SOLLTE die Schnellwechselaktion zwischen den beiden zuletzt verwendeten Apps auslösen, wenn zweimal auf die Taste für „Zuletzt verwendet“ getippt wird.
• SOLLTE bei langem Drücken der Taste für die Übersicht den Splitscreen-Multifenstermodus auslösen, sofern dieser unterstützt wird.

• Möglicherweise werden zugehörige kürzlich angesehene Inhalte als Gruppe angezeigt, die sich gemeinsam bewegt.

• [SR] Es wird DRINGEND EMPFOHLEN, die Upstream-Android-Benutzeroberfläche (oder eine ähnliche thumbnailbasierte Benutzeroberfläche) für den Übersichtsbildschirm zu verwenden.

3.8.9. Eingabeverwaltung

Android bietet Unterstützung für die Eingabeverwaltung und für Eingabemethoden-Editoren von Drittanbietern.

Wenn Geräteimplementierungen Nutzern die Verwendung von Eingabemethoden von Drittanbietern auf dem Gerät ermöglichen, gilt Folgendes:

• [C-1-1] MUSS die Plattformfunktion „android.software.input_methods“ deklarieren und IME-APIs gemäß der Android SDK-Dokumentation unterstützen.
• [C-1-2] Es MUSS ein für Nutzer zugänglicher Mechanismus bereitgestellt werden, um Drittanbieter-Eingabemethoden als Reaktion auf den Intent „android.settings.INPUT_METHOD_SETTINGS“ hinzuzufügen und zu konfigurieren.

Wenn Geräteimplementierungen das Feature-Flag android.software.autofill deklarieren, gilt Folgendes:

• [C-2-1] MUSS die APIs AutofillService und AutofillManager vollständig implementieren und die Absicht android.settings.REQUEST_SET_AUTOFILL_SERVICE berücksichtigen, um ein Standardmenü für App-Einstellungen anzuzeigen, in dem der Nutzer die automatische Vervollständigung aktivieren und deaktivieren und den Standarddienst für die automatische Vervollständigung ändern kann.

3.8.10. Mediensteuerung auf dem Sperrbildschirm

Die Remote Control Client API ist ab Android 5.0 zugunsten der Media Notification Template (Vorlage für Medienbenachrichtigungen) veraltet. Diese ermöglicht es Medienanwendungen, Wiedergabesteuerelemente zu integrieren, die auf dem Sperrbildschirm angezeigt werden.

3.8.11. Bildschirmschoner (früher „Dreams“)

Android unterstützt interaktive Bildschirmschoner, die früher als „Dreams“ bezeichnet wurden. Mit Bildschirmschonern können Nutzer mit Anwendungen interagieren, wenn ein an eine Stromquelle angeschlossenes Gerät inaktiv ist oder in einer Dockingstation steht. Auf Android-Smartwatches KÖNNEN Bildschirmschoner implementiert werden. Andere Gerätetypen SOLLTEN Bildschirmschoner unterstützen und Nutzern eine Einstellungsoption zum Konfigurieren von Bildschirmschonern als Reaktion auf die android.settings.DREAM_SETTINGS-Intention bieten.

3.8.12. Standort

Wenn Geräteimplementierungen einen Hardwaresensor (z.B. GPS) enthalten, der die Standortkoordinaten liefern kann:

• [C-1-1] Standortmodi MÜSSEN in den Einstellungen im Menü „Standort“ angezeigt werden.

3.8.13. Unicode und Schriftart

Android unterstützt die in Unicode 10.0 definierten Emoji-Zeichen.

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

• [C-1-1] MUSS diese Emojis als farbige Glyphen darstellen können.
• [C-1-2] MUSS Folgendes unterstützen:
• Roboto 2-Schriftart mit verschiedenen Strichstärken: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light für die auf dem Gerät verfügbaren Sprachen.
• Vollständige Unicode 7.0-Abdeckung von Lateinisch, Griechisch und Kyrillisch, einschließlich der Bereiche „Latin Extended A“, „B“, „C“ und „D“ sowie aller Glyphen im Block „Currency Symbols“ von Unicode 7.0.
• Sollte die im Unicode Technical Report #51 angegebenen Emojis für Hauttöne und diverse Familien unterstützen.

Wenn Geräteimplementierungen eine IME enthalten, müssen sie folgende Anforderungen erfüllen:

• Es SOLLTE eine Eingabemethode für diese Emojis bereitgestellt werden.

3.8.14. Mehrfenstermodus

Wenn Geräteimplementierungen mehrere Aktivitäten gleichzeitig anzeigen können, gilt Folgendes:

• [C-1-1] MUSS solche Mehrfenstermodi gemäß den in der Dokumentation zur Unterstützung des Mehrfenstermodus des Android SDK beschriebenen Anwendungsfunktionen und APIs implementieren und die folgenden Anforderungen erfüllen:
• [C-1-2] Anwendungen können in der AndroidManifest.xml-Datei angeben, ob sie im Mehrfenstermodus ausgeführt werden können. Dies kann entweder explizit durch Festlegen des Attributs android:resizeableActivity auf true oder implizit durch Festlegen von targetSdkVersion > 24 erfolgen. Apps, die dieses Attribut in ihrem Manifest explizit auf false setzen, DÜRFEN NICHT im Mehrfenstermodus gestartet werden. Ältere Apps mit targetSdkVersion < 24, in denen dieses android:resizeableActivity-Attribut nicht festgelegt ist, KÖNNEN im Mehrfenstermodus gestartet werden. Das System MUSS jedoch eine Warnung ausgeben, dass die App im Mehrfenstermodus möglicherweise nicht wie erwartet funktioniert.
• [C-1-3] Der Split-Screen- oder Freiformmodus darf nicht angeboten werden, wenn die Bildschirmhöhe < 440 dp und die Bildschirmbreite < 440 dp ist.
• Geräteimplementierungen mit einer Bildschirmgröße von xlarge SOLLTEN den Freiformmodus unterstützen.

Wenn Geräteimplementierungen den Mehrfenstermodus und den Splitscreen-Modus unterstützen, gilt Folgendes:

• [C-2-1] Es MUSS ein anpassbarer Launcher als Standard vorab geladen werden.
• [C-2-2] Die angedockte Aktivität eines Split-Screen-Multi-Windows MUSS zugeschnitten werden, es SOLLTEN aber einige Inhalte davon angezeigt werden, wenn die Launcher-App das aktive Fenster ist.
• [C-2-3] MUSS die deklarierten AndroidManifestLayout_minWidth- und AndroidManifestLayout_minHeight-Werte der Launcher-App eines Drittanbieters berücksichtigen und diese Werte nicht überschreiben, wenn Inhalte der angedockten Aktivität angezeigt werden.

Wenn Geräteimplementierungen den Mehrfenstermodus und den Bild-im-Bild-Mehrfenstermodus unterstützen, gilt Folgendes:

• [C-3-1] MUSS Aktivitäten im Bild-im-Bild-Multifenstermodus starten, wenn die App * auf API‑Level 26 oder höher ausgerichtet ist und android:supportsPictureInPicture deklariert oder * auf API‑Level 25 oder niedriger ausgerichtet ist und sowohl android:resizeableActivity als auch android:supportsPictureInPicture deklariert.
• [C-3-2] MUSS die Aktionen in der SystemUI gemäß der aktuellen PIP-Aktivität über die setActions() API verfügbar machen.
• [C-3-3] MUSS Seitenverhältnisse von mindestens 1:2,39 und höchstens 2,39:1 unterstützen, wie durch die PIP-Aktivität über die setAspectRatio() API angegeben.
• [C-3-4] KeyEvent.KEYCODE_WINDOW MUSS verwendet werden, um das BiB-Fenster zu steuern. Wenn der BiB-Modus nicht implementiert ist, MUSS der Schlüssel für die Vordergrundaktivität verfügbar sein.
• [C-3-5] Es MUSS eine Möglichkeit für Nutzer geben, die Anzeige einer App im BiB-Modus zu blockieren. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente im Benachrichtigungsfeld.
• [C-3-6] Das BiB-Fenster MUSS eine Mindestbreite und ‑höhe von 108 dp und eine Mindestbreite von 240 dp und ‑höhe von 135 dp haben, wenn Configuration.uiMode als UI_MODE_TYPE_TELEVISION konfiguriert ist.

3.9. Geräteverwaltung

Android bietet Funktionen, mit denen sicherheitsbewusste Anwendungen Geräteverwaltungsfunktionen auf Systemebene ausführen können, z. B. das Erzwingen von Passwortrichtlinien oder das Ausführen von Remote-Löschungen über die Android Device Administration API.

Wenn Geräteimplementierungen die gesamte Bandbreite der in der Android SDK-Dokumentation definierten Richtlinien zur Geräteverwaltung implementieren, gilt Folgendes:

• [C-1-1] MÜSSEN android.software.device_admin deklarieren.
• [C-1-2] MUSS die Bereitstellung des Geräteinhabers gemäß Abschnitt 3.9.1 und Abschnitt 3.9.1.1 unterstützen.
• [C-1-3] Die Unterstützung von verwalteten Profilen MUSS über das Feature-Flag android.software.managed_users deklariert werden, es sei denn, das Gerät ist so konfiguriert, dass es sich selbst als Gerät mit wenig RAM meldet oder dass es internen (nicht entfernbaren) Speicher als gemeinsam genutzten Speicher zuweist.

3.9.1 Gerätebereitstellung

3.9.1.1 Bereitstellung des Geräteeigentümers

Wenn Geräteimplementierungen android.software.device_admin deklarieren, gilt Folgendes:

• [C-1-1] Das Registrieren eines Geräte-Policy-Clients (Device Policy Client, DPC) als App für Geräteinhaber muss wie unten beschrieben unterstützt werden.
  • Wenn in der Geräteimplementierung noch keine Nutzerdaten konfiguriert sind, gilt Folgendes:
    • [C-1-3] MÜSSEN true für DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) melden.
    • [C-1-4] Die DPC-Anwendung MUSS als Geräteinhaber-App als Reaktion auf die Intent-Aktion android.app.action.PROVISION_MANAGED_DEVICE registriert werden.
    • [C-1-5] Die DPC-Anwendung MUSS als Geräteinhaber-App registriert werden, wenn das Gerät die Unterstützung von Near-Field Communication (NFC) über das Feature-Flag android.hardware.nfc deklariert und eine NFC-Nachricht mit einem Datensatz mit dem MIME-Typ MIME_TYPE_PROVISIONING_NFC empfängt.
  • Wenn die Geräteimplementierung Nutzerdaten enthält, gilt Folgendes:
    • [C-1-6] MÜSSEN false für DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) melden.
    • [C-1-7] DPC-Anwendungen dürfen nicht mehr als Geräteinhaber-App registriert werden.
• [C-1-2] Eine Anwendung (einschließlich vorinstallierter Apps) darf NICHT ohne ausdrückliche Einwilligung oder Aktion des Nutzers oder des Administrators des Geräts als Geräteinhaber-App festgelegt werden.

Wenn in Geräteimplementierungen android.software.device_admin deklariert wird, sie aber auch eine proprietäre Lösung zur Verwaltung von Geräteeigentümern enthalten und einen Mechanismus bieten, um eine in ihrer Lösung konfigurierte Anwendung als „Geräteeigentümer-Äquivalent“ für den Standard-„Geräteeigentümer“ zu bewerben, der von den Standard-Android-DevicePolicyManager-APIs erkannt wird, gilt Folgendes:

• [C-2-1] Es MUSS ein Verfahren vorhanden sein, um zu überprüfen, ob die beworbene App zu einer legitimen Lösung für die Geräteverwaltung von Unternehmen gehört und in der proprietären Lösung bereits so konfiguriert wurde, dass sie die Rechte eines Geräteinhabers hat.
• [C-2-2] Es MUSS dieselbe Offenlegung der Einwilligung des AOSP-Geräteinhabers angezeigt werden wie bei dem von android.app.action.PROVISION_MANAGED_DEVICE initiierten Ablauf, bevor die DPC-Anwendung als „Geräteinhaber“ registriert wird.
• Möglicherweise sind Nutzerdaten auf dem Gerät vorhanden, bevor die DPC-Anwendung als „Geräteinhaber“ registriert wird.

3.9.1.2 Bereitstellung verwalteter Profile

Wenn Geräteimplementierungen android.software.managed_users deklarieren, gilt Folgendes:

• [C-1-1] MUSS die APIs implementieren, die es einer DPC-Anwendung (Device Policy Controller) ermöglichen, Inhaber eines neuen verwalteten Profils zu werden.

• [C-1-2] Der Bereitstellungsprozess für verwaltete Profile (der durch android.app.action.PROVISION_MANAGED_PROFILE initiierte Ablauf) muss mit der AOSP-Implementierung übereinstimmen.

• [C-1-3] MUSS in den Einstellungen die folgenden Informationen für den Nutzer bereitstellen, um anzugeben, wann eine bestimmte Systemfunktion vom Geräteinhaber (Device Policy Controller, DPC) deaktiviert wurde:

  • Ein einheitliches Symbol oder eine andere Nutzerhilfe (z. B. das AOSP-Infosymbol) zur Darstellung, wenn eine bestimmte Einstellung durch einen Geräteadministrator eingeschränkt wird.
  • Eine kurze Erläuterung, die vom Geräteadministrator über die setShortSupportMessage bereitgestellt wird.
  • Das Symbol der DPC-Anwendung.

3.9.2 Unterstützung verwalteter Profile

Wenn Geräteimplementierungen android.software.managed_users deklarieren, gilt Folgendes:

• [C-1-1] MUSS verwaltete Profile über die android.app.admin.DevicePolicyManager-APIs unterstützen.
• [C-1-2] Es MUSS möglich sein, genau ein verwaltetes Profil zu erstellen.
• [C-1-3] Für verwaltete Anwendungen, Widgets und andere UI-Elemente mit Badge wie „Zuletzt verwendet“ und „Benachrichtigungen“ MUSS ein Symbol-Badge verwendet werden, das dem AOSP-Upstream-Arbeitsbadge ähnelt.
• [C-1-4] Es MUSS ein Benachrichtigungssymbol (ähnlich dem AOSP-Upstream-Arbeitssymbol) angezeigt werden, um anzugeben, wann sich der Nutzer in einer Anwendung mit verwaltetem Profil befindet.
• [C-1-5] Es MUSS ein Toast angezeigt werden, der darauf hinweist, dass sich der Nutzer im verwalteten Profil befindet, wenn das Gerät aktiviert wird (ACTION_USER_PRESENT) und die Vordergrundanwendung sich im verwalteten Profil befindet.
• [C-1-6] Wenn ein verwaltetes Profil vorhanden ist, MUSS im Intent-Chooser eine visuelle Möglichkeit angezeigt werden, damit der Nutzer den Intent vom verwalteten Profil an den primären Nutzer oder umgekehrt weiterleiten kann, sofern dies vom Geräteinhaber-Controller aktiviert wurde.
• [C-1-7] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN sowohl für den primären Nutzer als auch für das verwaltete Profil die folgenden Nutzerfunktionen verfügbar sein:
  • Separate Abrechnung für Akku, Standort, mobile Daten und Speichernutzung für den primären Nutzer und das verwaltete Profil.
  • Unabhängige Verwaltung von VPN-Anwendungen, die im primären Nutzerprofil oder im verwalteten Profil installiert sind.
  • Unabhängige Verwaltung von Anwendungen, die im Hauptnutzerprofil oder im verwalteten Profil installiert sind.
  • Unabhängige Verwaltung von Konten im Hauptnutzer- oder verwalteten Profil
• [C-1-8] MUSS dafür sorgen, dass in den vorinstallierten Telefon-, Kontakt- und Messaging-Apps neben den Informationen aus dem primären Profil auch Anruferinformationen aus dem verwalteten Profil (falls vorhanden) gesucht und nachgeschlagen werden können, sofern der Device Policy Controller dies zulässt.
• [C-1-9] MUSS dafür sorgen, dass alle Sicherheitsanforderungen für ein Gerät mit mehreren aktivierten Nutzern erfüllt werden (siehe Abschnitt 9.5), auch wenn das verwaltete Profil nicht als zusätzlicher Nutzer neben dem primären Nutzer gezählt wird.
• [C-1-10] Es MUSS möglich sein, einen separaten Sperrbildschirm anzugeben, der die folgenden Anforderungen erfüllt, um Zugriff auf Apps zu gewähren, die in einem verwalteten Profil ausgeführt werden.
  • Geräteimplementierungen MÜSSEN den Intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD berücksichtigen und eine Benutzeroberfläche zum Konfigurieren eines separaten Sperrbildschirm-Anmeldedaten für das verwaltete Profil anzeigen.
  • Die Anmeldedaten für den Sperrbildschirm des verwalteten Profils MÜSSEN dieselben Mechanismen für die Speicherung und Verwaltung von Anmeldedaten wie das übergeordnete Profil verwenden, wie auf der Android Open Source Project-Website dokumentiert.
  • Die Passwortrichtlinien des Geräteinhabers müssen NUR auf die Anmeldedaten für den Sperrbildschirm des verwalteten Profils angewendet werden, es sei denn, sie werden für die DevicePolicyManager-Instanz aufgerufen, die von getParentProfileInstance zurückgegeben wird.
• Wenn Kontakte aus dem verwalteten Profil im vorinstallierten Anruflisten-UI, im In-Call-UI, in Benachrichtigungen über laufende und verpasste Anrufe, in Kontakten und in Messaging-Apps angezeigt werden, SOLLTEN sie mit demselben Symbol gekennzeichnet werden, das für Anwendungen im verwalteten Profil verwendet wird.

3.10. Bedienungshilfen

Android bietet eine Bedienungshilfenschicht, die Nutzern mit Beeinträchtigungen die Bedienung ihrer Geräte erleichtert. Außerdem bietet Android Plattform-APIs, mit denen Implementierungen von Barrierefreiheitsdiensten Callbacks für Nutzer- und Systemereignisse empfangen und alternative Feedbackmechanismen wie Text-to-Speech, haptisches Feedback und Trackball-/D-Pad-Navigation generieren können.

Wenn Geräteimplementierungen Bedienungshilfen von Drittanbietern unterstützen, gilt Folgendes:

• [C-1-1] MUSS eine Implementierung des Android-Frameworks für Barrierefreiheit gemäß der SDK-Dokumentation zu Accessibility APIs bereitstellen.
• [C-1-2] MUSS Barrierefreiheitsereignisse generieren und die entsprechende AccessibilityEvent an alle registrierten AccessibilityService-Implementierungen senden, wie im SDK dokumentiert.
• [C-1-3] MUSS die android.settings.ACCESSIBILITY_SETTINGS-Intention berücksichtigen, um einen für Nutzer zugänglichen Mechanismus zum Aktivieren und Deaktivieren der Bedienungshilfen von Drittanbietern neben den vorinstallierten Bedienungshilfen bereitzustellen.
• [C-1-4] Es MUSS in der Navigationsleiste des Systems eine Schaltfläche hinzugefügt werden, über die der Nutzer den Bedienungshilfendienst steuern kann, wenn die aktivierten Bedienungshilfendienste AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON deklarieren . Bei Geräteimplementierungen ohne Systemnavigationsleiste gilt diese Anforderung nicht. Geräteimplementierungen SOLLTEN jedoch eine Möglichkeit für Nutzer bieten, diese Bedienungshilfen zu steuern.

Wenn Geräteimplementierungen vorinstallierte Dienste für Barrierefreiheit enthalten, gilt Folgendes:

• [C-2-1] Diese vorinstallierten Bedienungshilfen MÜSSEN als Direct Boot-kompatible Apps implementiert werden, wenn der Datenspeicher mit File Based Encryption (FBE) verschlüsselt ist.
• Es SOLLTE im Einrichtungsablauf ein Mechanismus bereitgestellt werden, mit dem Nutzer relevante Bedienungshilfen aktivieren sowie die Schriftgröße, die Anzeigegröße und die Vergrößerungsbewegungen anpassen können.

3.11. Sprachausgabe

Android enthält APIs, mit denen Anwendungen Text-to-Speech-Dienste (TTS) nutzen können, und ermöglicht Dienstanbietern, Implementierungen von TTS-Diensten bereitzustellen.

Wenn Geräteimplementierungen die Funktion „android.hardware.audio.output“ melden, gilt Folgendes:

• [C-1-1] MUSS die APIs des Android TTS-Frameworks unterstützen.

Wenn Geräteimplementierungen die Installation von Drittanbieter-Sprachausgabe-Engines unterstützen, gilt Folgendes:

• [C-2-1] MUSS dem Nutzer die Möglichkeit bieten, eine TTS-Engine für die Verwendung auf Systemebene auszuwählen.

3.12. TV Input Framework

Das Android Television Input Framework (TIF) vereinfacht die Bereitstellung von Liveinhalten auf Android-Fernsehern. TIF bietet eine Standard-API zum Erstellen von Eingabemodulen, mit denen Android-TV-Geräte gesteuert werden können.

Wenn Geräteimplementierungen TIF unterstützen, gilt Folgendes:

• [C-1-1] MUSS die Plattformfunktion android.software.live_tv deklarieren.
• [C-1-2] MUSS eine TV-Anwendung (TV-App) vorinstallieren und alle Anforderungen in Abschnitt 3.12.1 erfüllen.

3.12.1. TV-App

Wenn Geräteimplementierungen TIF unterstützen:

• [C-1-1] Die TV-App MUSS die Möglichkeit bieten, TV-Kanäle zu installieren und zu verwenden, und die folgenden Anforderungen erfüllen:

Die TV-App, die für Android-Geräteimplementierungen erforderlich ist, in denen das Funktions-Flag android.software.live_tv deklariert wird, MUSS die folgenden Anforderungen erfüllen:

• Geräteimplementierungen SOLLTEN die Installation und Verwaltung von TIF-basierten Eingaben von Drittanbietern (Eingaben von Drittanbietern) ermöglichen.
• Geräteimplementierungen KÖNNEN eine visuelle Trennung zwischen vorinstallierten TIF-basierten Eingaben (installierte Eingaben) und Drittanbietereingaben bieten.
• Auf Geräten sollten die Drittanbietereingaben nicht mehr als einen Navigationsvorgang von der TV-App entfernt angezeigt werden (z.B. durch Maximieren einer Liste von Drittanbietereingaben aus der TV-App).

Das Open-Source-Projekt für Android bietet eine Implementierung der TV-App, die die oben genannten Anforderungen erfüllt.

3.12.1.1. Elektronischer Programmführer (EPG)

Wenn Geräteimplementierungen TIF unterstützen, gilt Folgendes:

• [C-1-1] Es MUSS ein informatives und interaktives Overlay angezeigt werden, das ein elektronisches Programmheft (EPG) enthält, das aus den Werten in den Feldern TvContract.Programs generiert wird.
• [C-1-2] Bei einem Kanalwechsel MUSS auf Geräteimplementierungen EPG-Daten für das aktuell wiedergegebene Programm angezeigt werden.
• [SR] Es wird DRINGEND EMPFOHLEN, dass im EPG installierte Eingänge und Drittanbietereingänge gleichwertig angezeigt werden. Das EPG SOLLTE die Drittanbietereingaben nicht mehr als eine Navigationsaktion von den installierten Eingaben im EPG entfernt anzeigen.
• Das EPG SOLLTE Informationen von allen installierten Eingängen und Drittanbietereingängen anzeigen.
• Das EPG kann eine visuelle Trennung zwischen den installierten Eingängen und den Eingängen von Drittanbietern bieten.

3.12.1.2. Navigation

Wenn Geräteimplementierungen TIF unterstützen, gilt Folgendes:

• [C-1-1] Die Navigation für die folgenden Funktionen MUSS über das Steuerkreuz, die Zurück- und die Home-Taste auf den Eingabegeräten des Android-Fernsehgeräts (d.h. Fernbedienung, Fernbedienungs-App oder Controller) möglich sein:

  • Fernsehsender wechseln
  • EPG wird geöffnet
  • Konfiguration und Optimierung für TIF-basierte Eingaben von Drittanbietern (sofern diese Eingaben unterstützt werden)
  • Menü „Einstellungen“ öffnen

• Schlüsselereignisse SOLLTEN über CEC an HDMI-Eingänge weitergeleitet werden.

3.12.1.3. Verknüpfung von TV-Eingangs-Apps

Android-Fernseher sollten die Verknüpfung von TV-Eingabe-Apps unterstützen. Dadurch können alle Eingaben Aktivitätslinks von der aktuellen Aktivität zu einer anderen Aktivität bereitstellen, z. B. einen Link von Live-Programmen zu ähnlichen Inhalten. In der TV-App SOLLTE die Verknüpfung der TV-Eingabe-App angezeigt werden, wenn sie angegeben ist.

3.12.1.4. Zeitverschiebung

Wenn Geräteimplementierungen TIF unterstützen, gilt Folgendes:

• [SR] Es wird DRINGEND EMPFOHLEN, die Zeitversetzung zu unterstützen, damit der Nutzer Liveinhalte pausieren und fortsetzen kann.
• Der Nutzer SOLLTE die Möglichkeit haben, die aktuelle Wiedergabe zu pausieren und fortzusetzen, wenn für das Programm Time-Shifting verfügbar ist.

3.12.1.5. TV-Aufzeichnung

Wenn Geräteimplementierungen TIF unterstützen, gilt Folgendes:

• [SR] Es wird DRINGEND EMPFOHLEN, die TV-Aufzeichnung zu unterstützen.
• Wenn der TV-Eingang die Aufzeichnung unterstützt und die Aufzeichnung eines Programms nicht verboten ist, bietet das EPG MÖGLICHERWEISE eine Möglichkeit, ein Programm aufzuzeichnen.

3.13 Schnelleinstellungen

Android bietet eine UI-Komponente für die Schnelleinstellungen, die schnellen Zugriff auf häufig verwendete oder dringend benötigte Aktionen ermöglicht.

Wenn Geräteimplementierungen eine UI-Komponente für die Schnelleinstellungen enthalten, gilt Folgendes:

• [C-1-1] Der Nutzer MUSS die Möglichkeit haben, die über die quicksettings-APIs bereitgestellten Kacheln über eine Drittanbieter-App hinzuzufügen oder zu entfernen.
• [C-1-2] Eine Kachel aus einer Drittanbieter-App darf nicht automatisch direkt den Schnelleinstellungen hinzugefügt werden.
• [C-1-3] ALLE vom Nutzer hinzugefügten Kacheln von Drittanbieter-Apps MÜSSEN neben den vom System bereitgestellten Kacheln für Schnelleinstellungen angezeigt werden.

3.14. Media-UI

Wenn Geräteimplementierungen das UI-Framework enthalten, das Drittanbieter-Apps unterstützt, die von MediaBrowser und MediaSession abhängen, gilt Folgendes:

• [C-1-1] MediaItem-Symbole und Benachrichtigungssymbole MÜSSEN unverändert angezeigt werden.
• [C-1-2] Diese Elemente MÜSSEN wie in MediaSession beschrieben angezeigt werden, z.B. Metadaten, Symbole und Bilder.
• [C-1-3] Der App-Titel MUSS angezeigt werden.
• [C-1-4] MUSS eine Schublade haben, um die MediaBrowser-Hierarchie zu präsentieren.
• [C-1-5] Das Doppeltippen auf KEYCODE_HEADSETHOOK oder KEYCODE_MEDIA_PLAY_PAUSE MUSS als KEYCODE_MEDIA_NEXT für MediaSession.Callback#onMediaButtonEvent betrachtet werden.

3.15. Android Instant Apps

Geräteimplementierungen MÜSSEN die folgenden Anforderungen erfüllen:

• [C-0-1] Instant-Apps DÜRFEN nur Berechtigungen erhalten, für die android:protectionLevel auf "ephemeral" festgelegt ist.
• [C-0-2] Instant-Apps DÜRFEN NICHT über implizite Intents mit installierten Apps interagieren, es sei denn, eine der folgenden Bedingungen ist erfüllt:
  • Der Intent-Musterfilter der Komponente ist verfügbar und hat CATEGORY_BROWSABLE
  • Die Aktion ist eine von ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE.
  • Das Ziel wird explizit mit android:visibleToInstantApps verfügbar gemacht.
• [C-0-3] Instant-Apps DÜRFEN NICHT explizit mit installierten Apps interagieren, es sei denn, die Komponente wird über „android:visibleToInstantApps“ verfügbar gemacht.
• [C-0-4] Installierte Apps DÜRFEN keine Details zu Instant Apps auf dem Gerät sehen, es sei denn, die Instant App stellt explizit eine Verbindung zur installierten App her.

3.16. Kopplung von Begleitgeräten

Android unterstützt die Kopplung von Begleitgeräten, um die Zuordnung zu Begleitgeräten effektiver zu verwalten. Außerdem wird die CompanionDeviceManager API bereitgestellt, damit Apps auf diese Funktion zugreifen können.

Wenn Geräteimplementierungen die Funktion zum Koppeln von Companion-Geräten unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag FEATURE_COMPANION_DEVICE_SETUP deklarieren .
• [C-1-2] MUSS dafür sorgen, dass die APIs im Paket android.companion vollständig implementiert sind.
• [C-1-3] MUSS dem Nutzer die Möglichkeit bieten, ein Companion-Gerät auszuwählen/zu bestätigen, das vorhanden und betriebsbereit ist.

4. Kompatibilität von Anwendungspaketen

Geräteimplementierungen:

• [C-0-1] MUSS in der Lage sein, Android-„.apk“-Dateien zu installieren und auszuführen, die vom „aapt“-Tool generiert werden, das im offiziellen Android SDK enthalten ist.
• Da die oben genannte Anforderung schwierig zu erfüllen sein kann, wird empfohlen, dass Geräteimplementierungen das Paketverwaltungssystem der AOSP-Referenzimplementierung verwenden.
• [C-0-2] MÜSSEN die Überprüfung von APK-Dateien mit dem APK-Signaturschema v2 und der JAR-Signierung unterstützen.
• [C-0-3] Die Formate .apk, Android-Manifest, Dalvik-Bytecode oder RenderScript-Bytecode dürfen NICHT so erweitert werden, dass die Dateien nicht auf anderen kompatiblen Geräten installiert und ausgeführt werden können.
• [C-0-4] Apps außer dem aktuellen „Installer of Record“ für das Paket DÜRFEN die App NICHT ohne Aufforderung im Hintergrund deinstallieren, wie im SDK für die Berechtigung DELETE_PACKAGE dokumentiert. Die einzigen Ausnahmen sind die System-App zur Paketüberprüfung, die den Intent PACKAGE_NEEDS_VERIFICATION verarbeitet, und die Speichermanager-App, die den Intent ACTION_MANAGE_STORAGE verarbeitet.

Auf Geräteimplementierungen DÜRFEN keine Anwendungspakete aus unbekannten Quellen installiert werden, es sei denn, die App, die die Installation anfordert, erfüllt alle folgenden Anforderungen:

• Es MUSS die Berechtigung REQUEST_INSTALL_PACKAGES deklarieren oder android:targetSdkVersion muss auf 24 oder niedriger festgelegt sein.
• Der Nutzer MUSS die Berechtigung zum Installieren von Apps aus unbekannten Quellen erteilt haben.

Geräteimplementierungen MÜSSEN eine Aktivität haben, die den Intent android.settings.MANAGE_UNKNOWN_APP_SOURCES verarbeitet. Sie SOLLTEN dem Nutzer die Möglichkeit geben, die Berechtigung zum Installieren von Apps aus unbekannten Quellen pro Anwendung zu erteilen/zu widerrufen. Sie KÖNNEN dies jedoch auch als No-Op implementieren und RESULT_CANCELED für startActivityForResult() zurückgeben, wenn die Geräteimplementierung diese Auswahlmöglichkeit für Nutzer nicht zulassen soll. Auch in solchen Fällen SOLLTEN sie dem Nutzer jedoch mitteilen, warum keine solche Auswahl angezeigt wird.

5. Multimedia-Kompatibilität

Geräteimplementierungen:

• [C-0-1] MUSS die in Abschnitt 5.1 definierten Mediaformate, Encoder, Decoder, Dateitypen und Containerformate für jeden von MediaCodecList deklarierten Codec unterstützen.
• [C-0-2] Die Unterstützung der Encoder und Decoder, die Drittanbieteranwendungen über MediaCodecList zur Verfügung stehen, MUSS deklariert und gemeldet werden.
• [C-0-3] MUSS alle Formate, die es codieren kann, decodieren und Drittanbieter-Apps zur Verfügung stellen können. Dazu gehören alle Bitstreams, die von den Encodern generiert werden, und die in der CamcorderProfile gemeldeten Profile.

Geräteimplementierungen:

• SHOULD aim for minimum codec latency, in others words, they
  • Eingabepuffer SOLLTEN NICHT verarbeitet und gespeichert werden. Sie SOLLTEN erst nach der Verarbeitung zurückgegeben werden.
  • Decodierte Puffer sollten nicht länger als im Standard (z.B. SPS) angegeben aufbewahrt werden.
  • Sollte codierte Puffer nicht länger als durch die GOP-Struktur erforderlich aufbewahren.

Alle unten aufgeführten Codecs werden als Softwareimplementierungen in der bevorzugten Android-Implementierung aus dem Android Open Source Project bereitgestellt.

Weder Google noch die Open Handset Alliance geben eine Zusicherung ab, dass diese Codecs frei von Patenten Dritter sind. Personen, die diesen Quellcode in Hardware- oder Softwareprodukten verwenden möchten, wird geraten, sich darüber zu informieren, ob für die Implementierung dieses Codes, auch in Open-Source-Software oder Shareware, Patentlizenzen von den entsprechenden Patentinhabern erforderlich sind.

5.1. Media-Codecs

5.1.1. Audiocodierung

Weitere Informationen finden Sie unter 5.1.3. Details zu Audio-Codecs.

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, MÜSSEN sie die folgende Audio-Codierung unterstützen:

• [C-1-1] PCM/WAVE

5.1.2. Audiodecodierung

Weitere Informationen finden Sie unter 5.1.3. Details zu Audio-Codecs.

Wenn Geräteimplementierungen Unterstützung für die Funktion android.hardware.audio.output deklarieren, gilt Folgendes:

• [C-1-1] MPEG-4 AAC-Profil (AAC LC)
• [C-1-2] MPEG-4 HE AAC-Profil (AAC+)
• [C-1-3] MPEG-4 HE AACv2-Profil (Enhanced AAC+)
• [C-1-4] AAC ELD (Enhanced Low Delay AAC)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE
• [C-1-10] Opus

Wenn Geräteimplementierungen die Decodierung von AAC-Eingabepuffern von Mehrkanal-Streams (d.h. mehr als zwei Kanäle) zu PCM über den standardmäßigen AAC-Audio-Decoder in der android.media.MediaCodec API unterstützen, muss Folgendes unterstützt werden:

• [C-2-1] Die Decodierung MUSS ohne Downmixing erfolgen (z.B. muss ein 5.0-AAC-Stream in fünf PCM-Kanäle decodiert werden, ein 5.1-AAC-Stream in sechs PCM-Kanäle).
• [C-2-2] Metadaten für den Dynamikbereich MÜSSEN gemäß „Dynamic Range Control (DRC)“ in ISO/IEC 14496-3 definiert sein und die android.media.MediaFormat DRC-Schlüssel zum Konfigurieren des Verhaltens des Audio-Decoders in Bezug auf den Dynamikbereich. Die AAC DRC-Schlüssel wurden in API 21 eingeführt und sind: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL und KEY_AAC_ENCODED_TARGET_LEVEL.

5.1.3. Details zu Audio-Codecs

Format/Codec	Details	Unterstützte Dateitypen/Containerformate
MPEG-4 AAC-Profil (AAC LC)	Unterstützung für Mono-/Stereo-/5.0-/5.1-Inhalte mit Standard-Abtastraten von 8 bis 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS-Roh-AAC (.aac, ADIF wird nicht unterstützt) MPEG-TS (.ts, nicht suchbar)
MPEG-4 HE AAC-Profil (AAC+)	Unterstützung für Mono-/Stereo-/5.0-/5.1-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.
MPEG-4 HE AACv2 Profile (enhanced AAC+)	Unterstützung für Mono-/Stereo-/5.0-/5.1-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.
AAC ELD (Enhanced Low Delay AAC)	Unterstützung für Mono-/Stereo-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.
AMR-NB	4,75 bis 12,2 kbit/s bei einer Abtastrate von 8 kHz	3GPP (.3gp)
AMR-WB	9 Raten von 6,60 kbit/s bis 23,85 kbit/s, abgetastet bei 16 kHz
FLAC	Mono/Stereo (kein Mehrkanal). Abtastraten bis zu 48 kHz (auf Geräten mit 44,1 kHz-Ausgabe wird jedoch bis zu 44,1 kHz EMPFOHLEN, da der Downsampler von 48 auf 44,1 kHz keinen Tiefpassfilter enthält). 16 Bit EMPFOHLEN; für 24 Bit wird kein Dithering angewendet.	Nur FLAC (.flac)
MP3	Mono/Stereo, 8–320 kbit/s, konstante (CBR) oder variable Bitrate (VBR)	MP3 (.mp3)
MIDI	MIDI-Typ 0 und 1 DLS-Version 1 und 2 XMF und Mobile XMF Unterstützung für die Klingeltonformate RTTTL/RTX, OTA und iMelody	Typ 0 und 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		Ogg (.ogg) Matroska (.mkv, Android 4.0 oder höher)
PCM/WAVE	Lineare 16-Bit-PCM (Raten bis zum Limit der Hardware). Geräte MÜSSEN Abtastraten für die Aufnahme von rohem PCM bei Frequenzen von 8.000, 11.025, 16.000 und 44.100 Hz unterstützen.	WAVE (.wav)
Opus		Matroska (.mkv), Ogg(.ogg)

5.1.4. Bildcodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Bild-Codecs

Geräteimplementierungen MÜSSEN die Codierung der folgenden Bildcodierung unterstützen:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

5.1.5. Bilddecodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Bild-Codecs

Geräteimplementierungen MÜSSEN die Codierung der folgenden Bilddecodierung unterstützen:

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Roh

5.1.6. Details zu Bild-Codecs

Format/Codec	Details	Unterstützte Dateitypen/Containerformate
JPEG	Grundpreis + progressiv	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Raw		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.7. Video-Codecs

• Für eine akzeptable Qualität von Web-Videostreaming- und Videokonferenzdiensten SOLLTEN Geräteimplementierungen einen Hardware-VP8-Codec verwenden, der die Anforderungen erfüllt.

Wenn Geräteimplementierungen einen Videodecoder oder ‑encoder enthalten:

• [C-1-1] Videocodecs MÜSSEN Ausgabebytebuffer- und Eingabebytebuffergrößen unterstützen, die das größtmögliche komprimierte und unkomprimierte Frame gemäß Standard und Konfiguration aufnehmen können, aber auch nicht überdimensioniert sind.

• [C-1-2] Video-Encoder und ‑Decoder MÜSSEN das flexible YUV420-Farbformat (COLOR_FormatYUV420Flexible) unterstützen.

Wenn Geräteimplementierungen die Unterstützung von HDR-Profilen über Display.HdrCapabilities angeben, gilt Folgendes:

• [C-2-1] MUSS das Parsen und die Verarbeitung statischer HDR-Metadaten unterstützen.

Wenn Geräteimplementierungen die Unterstützung von Intra-Refresh über FEATURE_IntraRefresh in der Klasse MediaCodecInfo.CodecCapabilities ankündigen, gilt Folgendes:

• [C-3-1]MUSS Aktualisierungszeiträume im Bereich von 10 bis 60 Frames unterstützen und innerhalb von 20% des konfigurierten Aktualisierungszeitraums genau arbeiten.

5.1.8. Liste der Video-Codecs

Format/Codec	Details	Unterstützte Dateitypen/ Containerformate
H.263		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	Weitere Informationen finden Sie in Abschnitt 5.2 und 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, nur AAC-Audio, nicht suchbar, Android 3.0 oder höher)
H.265 HEVC	Weitere Informationen finden Sie in Abschnitt 5.3.	MPEG-4 (.mp4)
MPEG-2	Profil "Main"	MPEG2-TS
MPEG-4 SP		3GPP (.3gp)
VP8	Weitere Informationen finden Sie in Abschnitt 5.2 und 5.3.	WebM (.webm) Matroska (.mkv)
VP9	Weitere Informationen finden Sie in Abschnitt 5.3.	WebM (.webm) Matroska (.mkv)

5.2. Videocodierung

Wenn Geräteimplementierungen einen Video-Encoder unterstützen und ihn für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• Sollte über zwei gleitende Fenster nicht mehr als etwa 15% über der Bitrate zwischen Intraframe-Intervallen (I-Frame) liegen.
• Die Bitrate SOLLTE in einem gleitenden Fenster von 1 Sekunde nicht mehr als etwa 100% über der Bitrate liegen.

Wenn Geräteimplementierungen ein eingebettetes Display mit einer Diagonale von mindestens 2,5 Zoll oder einen Videoausgang enthalten oder die Unterstützung einer Kamera über das android.hardware.camera.any-Funktionsflag deklarieren, müssen sie:

• [C-1-1] MUSS mindestens einen der Video-Encoder VP8 oder H.264 unterstützen und für Drittanbieteranwendungen verfügbar machen.
• SOLLTE sowohl VP8- als auch H.264-Video-Encoder unterstützen und für Drittanbieteranwendungen verfügbar machen.

Wenn Geräteimplementierungen einen der Video-Encoder H.264, VP8, VP9 oder HEVC unterstützen und für Drittanbieteranwendungen verfügbar machen, gilt Folgendes:

• [C-2-1] MUSS dynamisch konfigurierbare Bitraten unterstützen.
• Sollte variable Frameraten unterstützen, wobei der Video-Encoder die sofortige Framedauer anhand der Zeitstempel der Eingabepuffer bestimmen und seinen Bit-Bucket basierend auf dieser Framedauer zuweisen SOLLTE.

Wenn Geräteimplementierungen den MPEG-4 SP-Video-Encoder unterstützen und ihn für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• SOLLTE dynamisch konfigurierbare Bitraten für den unterstützten Encoder unterstützen.

5.2.1. H.263

Wenn Geräteimplementierungen H.263-Encoder unterstützen und sie Drittanbieter-Apps zur Verfügung stellen, gilt Folgendes:

• [C-1-1] MUSS das Baseline-Profil Level 45 unterstützen.
• SOLLTE dynamisch konfigurierbare Bitraten für den unterstützten Encoder unterstützen.

5.2.2. H-264

Wenn Geräteimplementierungen den H.264-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Baseline-Profil Level 3 unterstützen. Die Unterstützung von ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist jedoch OPTIONAL. Um die Kompatibilität mit anderen Android-Geräten aufrechtzuerhalten, wird außerdem EMPFOHLEN, dass ASO, FMO und RS nicht für das Baseline-Profil von Encodern verwendet werden.
• [C-1-2] MUSS die SD-Videocodierungsprofile (Standard Definition) in der folgenden Tabelle unterstützen.
• SOLLTE Main Profile Level 4 unterstützen.
• Sollte die in der folgenden Tabelle angegebenen HD-Videocodierungsprofile (High Definition) unterstützen.

Wenn Geräteimplementierungen über die Media-APIs die Unterstützung der H.264-Codierung für Videos mit einer Auflösung von 720p oder 1080p melden, gilt Folgendes:

• [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 240 px	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel
Video-Framerate	20 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	384 kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.3. VP8

Wenn Geräteimplementierungen den VP8-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS die SD-Videocodierungsprofile unterstützen.
• SOLLTE die folgenden HD-Videocodierungsprofile (High Definition) unterstützen.
• Sollte das Schreiben von Matroska-WebM-Dateien unterstützen.
• Es SOLLTE ein Hardware-VP8-Codec verwendet werden, der die Hardware-Codierungsanforderungen des WebM-Projekts für RTC erfüllt, um eine akzeptable Qualität von Webvideostreaming- und Videokonferenzdiensten zu gewährleisten.

Wenn Geräteimplementierungen über die Media APIs die Unterstützung der VP8-Codierung für Videos mit einer Auflösung von 720p oder 1080p melden, gilt Folgendes:

• [C-2-1] MUSS die Codierungsprofile in der folgenden Tabelle unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 180 px	640 × 360 px	1280 × 720 Pixel	1.920 × 1.080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	800 kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.4. VP9

Wenn Geräteimplementierungen den VP9-Codec unterstützen, gilt Folgendes:

• Sollte das Schreiben von Matroska-WebM-Dateien unterstützen.

5.3. Videodecodierung

Wenn Geräteimplementierungen die Codecs VP8, VP9, H.264 oder H.265 unterstützen, gilt Folgendes:

• [C-1-1] MUSS dynamische Videoauflösungs- und Framerate-Wechsel über die standardmäßigen Android-APIs innerhalb desselben Streams für alle VP8-, VP9-, H.264- und H.265-Codecs in Echtzeit und bis zur maximalen Auflösung unterstützen, die von den einzelnen Codecs auf dem Gerät unterstützt wird.

Wenn Geräteimplementierungen die Unterstützung für den Dolby Vision-Decoder über HDR_TYPE_DOLBY_VISION deklarieren , gilt Folgendes:

• [C-2-1] MUSS einen Extraktor mit Dolby Vision-Unterstützung bereitstellen.
• [C-2-2] Dolby Vision-Inhalte MÜSSEN auf dem Gerätebildschirm oder an einem Standard-Videoausgang (z.B. HDMI).
• [C-2-3] Der Track-Index der abwärtskompatiblen Basisebene(n) (falls vorhanden) MUSS mit dem Track-Index der kombinierten Dolby Vision-Ebene übereinstimmen.

5.3.1. MPEG-2

Wenn Geräteimplementierungen MPEG‑2-Decoder unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Main Profile High Level unterstützen.

5.3.2. H.263

Wenn Geräteimplementierungen H.263-Decoder unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Baseline-Profil Level 30 und Level 45 unterstützen.

5.3.3. MPEG-4

Wenn Geräteimplementierungen MPEG-4-Decoder enthalten, gilt Folgendes:

• [C-1-1] MUSS das Simple Profile Level 3 unterstützen.

5.3.4. H.264

Wenn Geräteimplementierungen H.264-Decoder unterstützen, gilt Folgendes:

• [C-1-1] MUSS Main Profile Level 3.1 und Baseline Profile unterstützen. Die Unterstützung von ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist OPTIONAL.
• [C-1-2] MUSS Videos mit den in der folgenden Tabelle aufgeführten SD-Profilen (Standard Definition) decodieren können, die mit dem Baseline-Profil und dem Main-Profil Level 3.1 (einschließlich 720p30) codiert sind.
• Sollte Videos mit den in der folgenden Tabelle angegebenen HD-Profilen (High Definition) decodieren können.

Wenn die Höhe, die von der Display.getSupportedModes()-Methode gemeldet wird, gleich oder größer als die Videoauflösung ist, müssen Geräteimplementierungen:

• [C-2-1] MUSS die HD‑720p-Videocodierungsprofile in der folgenden Tabelle unterstützen.
• [C-2-2] MUSS die HD‑Videocodierungsprofile mit 1080p in der folgenden Tabelle unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 240 px	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	60 fps	30 fps (60 fpsFernsehen)
Video-Bitrate	800 kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.3.5. H.265 (HEVC)

Wenn Geräteimplementierungen den H.265-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Main Profile Level 3 Main Tier und die SD-Videodecodierungsprofile gemäß der folgenden Tabelle unterstützen.
• Sollte die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
• [C-1-2] MUSS die in der folgenden Tabelle angegebenen HD-Decodierungsprofile unterstützen, wenn ein Hardware-Decoder vorhanden ist.

Wenn die Höhe, die von der Methode Display.getSupportedModes() gemeldet wird, gleich oder größer als die Videoauflösung ist, gilt Folgendes:

• [C-2-1] Geräteimplementierungen MÜSSEN mindestens eine der folgenden Decodierungen unterstützen: H.265 oder VP9 für 720-, 1080- und UHD-Profile.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	352 × 288 px	720 × 480 px	1280 × 720 Pixel	1.920 × 1.080 Pixel	3840 × 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30/60 fps (60 fpsFernseher mit H.265-Hardwaredecodierung)	60 fps
Video-Bitrate	600 Kbit/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

5.3.6. VP8

Wenn Geräteimplementierungen den VP8-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS die SD-Decodierungsprofile in der folgenden Tabelle unterstützen.
• Sollte einen Hardware-VP8-Codec verwenden, der die Anforderungen erfüllt.
• Sollte die HD-Decodierungsprofile in der folgenden Tabelle unterstützen.

Wenn die Höhe, die von der Methode Display.getSupportedModes() zurückgegeben wird, gleich oder größer als die Videoauflösung ist, gilt Folgendes:

• [C-2-1] Geräteimplementierungen MÜSSEN die 720p-Profile in der folgenden Tabelle unterstützen.
• [C-2-2] Geräteimplementierungen MÜSSEN die in der folgenden Tabelle aufgeführten 1080p-Profile unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 × 180 px	640 × 360 px	1280 × 720 Pixel	1.920 × 1.080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30 fps (60 fpsFernsehen)	30 (60 fpsFernsehen)
Video-Bitrate	800 kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.3.7. VP9

Wenn Geräteimplementierungen den VP9-Codec unterstützen, gilt Folgendes:

• [C-1-1] MUSS die in der folgenden Tabelle angegebenen SD-Videodecodierungsprofile unterstützen.
• Sollte die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.

Wenn Geräteimplementierungen den VP9-Codec und einen Hardware-Decoder unterstützen, gilt Folgendes:

• [C-2-2] MUSS die HD-Decodierungsprofile gemäß der folgenden Tabelle unterstützen.

Wenn die Höhe, die von der Methode Display.getSupportedModes() gemeldet wird, gleich oder größer als die Videoauflösung ist, gilt Folgendes:

• [C-3-1] Geräteimplementierungen MÜSSEN mindestens die Decodierung von VP9 oder H.265 für die Profile mit 720p, 1080p und UHD unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	320 × 180 px	640 × 360 px	1280 × 720 Pixel	1.920 × 1.080 Pixel	3840 × 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30 fps (60 fpsFernseher mit VP9-Hardware-Decodierung)	60 fps
Video-Bitrate	600 Kbit/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

5.4. Audioaufnahmen

Einige der in diesem Abschnitt beschriebenen Anforderungen sind seit Android 4.3 als SHOULD aufgeführt. In der Kompatibilitätsdefinition für zukünftige Versionen ist jedoch geplant, diese in MUST zu ändern. Es wird DRINGEND EMPFOHLEN, dass vorhandene und neue Android-Geräte diese Anforderungen erfüllen, die als „SHOULD“ aufgeführt sind. Andernfalls können sie bei einem Upgrade auf die zukünftige Version nicht die Android-Kompatibilität erreichen.

5.4.1. RAW-Audioaufnahme

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

• [C-1-1] MUSS die Aufnahme von Audio-Rohinhalten mit den folgenden Eigenschaften ermöglichen:

• Format: Lineare PCM, 16 Bit

• Abtastraten: 8.000, 11.025, 16.000, 44.100 Hz

• Kanäle: Mono

• [C-1-2] MUSS mit den oben genannten Abtastraten ohne Upsampling erfasst werden.

• [C-1-3] Bei der Erfassung der oben genannten Sampleraten mit Downsampling MUSS ein geeigneter Anti-Aliasing-Filter verwendet werden.

• Sollte die Aufnahme von rohen Audioinhalten in AM-Radio- und DVD-Qualität ermöglichen, was die folgenden Merkmale bedeutet:

• Format: Lineare PCM, 16 Bit

• Abtastraten: 22.050, 48.000 Hz
• Kanäle: Stereo

Wenn Geräteimplementierungen AM-Radio und die Aufnahme von Roh-Audioinhalten in DVD-Qualität ermöglichen, gilt Folgendes:

• [C-2-1] MUSS ohne Upsampling bei einem Verhältnis über 16.000:22.050 oder 44.100:48.000 erfasst werden.
• [C-2-2] Bei jedem Upsampling oder Downsampling MUSS ein geeigneter Anti-Aliasing-Filter verwendet werden.

5.4.2. Aufnahme für die Spracherkennung

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

• [C-1-1] MUSS die Audioquelle android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION mit einer der Abtastraten 44.100 und 48.000 aufnehmen.
• [C-1-2] MUSS standardmäßig alle Audioverarbeitungen zur Rauschunterdrückung deaktivieren, wenn ein Audiostream von der Audioquelle AudioSource.VOICE_RECOGNITION aufgezeichnet wird.
• [C-1-3] MUSS standardmäßig die automatische Verstärkungsregelung deaktivieren, wenn ein Audiostream von der Audioquelle AudioSource.VOICE_RECOGNITION aufgezeichnet wird.
• Der Audio-Stream für die Spracherkennung SOLLTE mit einer ungefähr flachen Amplitude im Verhältnis zur Frequenz aufgezeichnet werden, genauer gesagt mit ±3 dB von 100 Hz bis 4.000 Hz.
• Der Audio-Stream für die Spracherkennung SOLLTE mit einer Eingangsempfindlichkeit aufgezeichnet werden, die so eingestellt ist, dass eine Schallleistungspegelquelle (SPL) von 90 dB bei 1.000 Hz einen RMS von 2.500 für 16-Bit-Samples ergibt.
• Der Audio-Stream für die Spracherkennung SOLLTE so aufgezeichnet werden, dass die PCM-Amplitudenpegel Änderungen des Eingabe-SPL über mindestens einen Bereich von 30 dB linear verfolgen, von -18 dB bis +12 dB re 90 dB SPL am Mikrofon.
• SOLLTE den Audio-Stream für die Spracherkennung mit einem THD-Wert (Total Harmonic Distortion) von unter 1% für 1 kHz bei einem Eingangspegel von 90 dB SPL am Mikrofon aufzeichnen.

Wenn Geräteimplementierungen android.hardware.microphone und Technologien zur Rauschunterdrückung (‑reduzierung) deklarieren, die für die Spracherkennung optimiert sind, gilt Folgendes:

• [C-2-1] Dieser Audioeffekt MUSS über die android.media.audiofx.NoiseSuppressor API steuerbar sein.
• [C-2-2] Jede Implementierung der Technologie zur Rauschunterdrückung MUSS über das Feld AudioEffect.Descriptor.uuid eindeutig identifiziert werden.

5.4.3. Erfassung für die Umleitung der Wiedergabe

Die Klasse android.media.MediaRecorder.AudioSource enthält die Audioquelle REMOTE_SUBMIX.

Wenn in Geräteimplementierungen sowohl android.hardware.audio.output als auch android.hardware.microphone deklariert werden, gilt Folgendes:

• [C-1-1] MUSS die Audioquelle REMOTE_SUBMIX korrekt implementieren, sodass bei der Aufnahme über die android.media.AudioRecord API aus dieser Audioquelle ein Mix aller Audio-Streams erfasst wird, mit Ausnahme der folgenden:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.5. Audiowiedergabe

Android unterstützt die Audiowiedergabe über das in Abschnitt 7.8.2 definierte Audioausgabe-Peripheriegerät.

5.5.1. Wiedergabe von Rohaudio

Wenn Geräteimplementierungen android.hardware.audio.output deklarieren, gilt Folgendes:

• [C-1-1] Die Wiedergabe von rohen Audioinhalten mit den folgenden Merkmalen MUSS möglich sein:

  • Format: Lineare PCM, 16 Bit
  • Abtastraten: 8.000, 11.025, 16.000, 22.050, 32.000, 44.100
  • Kanäle: Mono, Stereo

• Die Wiedergabe von Audio-Rohinhalten mit den folgenden Merkmalen SOLLTE möglich sein:

  • Abtastraten: 24.000, 48.000

5.5.2. Audioeffekte

Android bietet eine API für Audioeffekte für Geräteimplementierungen.

Wenn Geräteimplementierungen das Feature android.hardware.audio.output deklarieren, gilt Folgendes:

• [C-1-1] MUSS die Implementierungen von EFFECT_TYPE_EQUALIZER und EFFECT_TYPE_LOUDNESS_ENHANCER unterstützen, die über die AudioEffect-Unterklassen Equalizer und LoudnessEnhancer gesteuert werden können.
• [C-1-2] MUSS die Implementierung der Visualizer API unterstützen, die über die Klasse Visualizer gesteuert werden kann.
• Sollte die Implementierungen EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB und EFFECT_TYPE_VIRTUALIZER unterstützen, die über die AudioEffect-Unterklassen BassBoost, EnvironmentalReverb, PresetReverb und Virtualizer gesteuert werden können.

5.5.3. Audioausgabelautstärke

Automotive-Geräteimplementierungen:

• Die Audiolautstärke SOLLTE für jeden Audiostream separat angepasst werden können. Dazu werden der Inhaltstyp oder die Verwendung gemäß AudioAttributes und die Verwendung von Audio im Auto gemäß android.car.CarAudioManager verwendet.

5.6. Audiolatenz

Die Audiolatenz ist die Zeitverzögerung, die auftritt, wenn ein Audiosignal ein System durchläuft. Viele Arten von Anwendungen sind auf kurze Latenzen angewiesen, um Echtzeit-Soundeffekte zu erzielen.

Im Zusammenhang mit diesem Abschnitt gelten die folgenden Definitionen:

• Ausgabelatenz. Das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung einen Frame mit PCM-codierten Daten schreibt, und dem Zeitpunkt, zu dem der entsprechende Ton über einen On-Device-Wandler an die Umgebung ausgegeben wird oder das Signal das Gerät über einen Port verlässt und extern beobachtet werden kann.
• Kaltstartlatenz. Die Ausgabelatenz für den ersten Frame, wenn das Audioausgabesystem vor der Anfrage im Leerlauf war und heruntergefahren wurde.
• Latenz der kontinuierlichen Ausgabe. Die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät Audio wiedergegeben hat.
• Eingabelatenz. Das Intervall zwischen dem Zeitpunkt, zu dem ein Ton von der Umgebung über einen On-Device-Wandler an das Gerät übertragen wird oder ein Signal über einen Port in das Gerät gelangt, und dem Zeitpunkt, zu dem eine Anwendung den entsprechenden Frame von PCM-codierten Daten liest.
• Verlorene Eingabe Der erste Teil eines Eingangssignals, der nicht verwendet werden kann oder nicht verfügbar ist.
• Kaltstartlatenz. Die Summe aus der verlorenen Eingabezeit und der Eingabelatenz für den ersten Frame, wenn das Audioeingabesystem vor der Anfrage inaktiv und heruntergefahren war.
• Kontinuierliche Eingabelatenz: Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufnimmt.
• Kalter Ausgabeflatter. Die Variabilität zwischen einzelnen Messungen von Kaltstartlatenzwerten.
• Kalter Eingabe-Jitter: Die Variabilität zwischen einzelnen Messungen von Kaltstart-Eingabelatenzwerten.
• kontinuierliche Roundtrip-Latenz. Die Summe aus der Latenz für kontinuierliche Eingaben, der Latenz für kontinuierliche Ausgaben und einem Pufferzeitraum. Der Pufferzeitraum gibt der App Zeit, das Signal zu verarbeiten und die Phasendifferenz zwischen Ein- und Ausgabestreams zu minimieren.
• OpenSL ES PCM-Pufferwarteschlangen-API Die Gruppe der PCM-bezogenen OpenSL ES-APIs im Android NDK.
• AAudio Native Audio API Die Gruppe der AAudio-APIs im Android NDK.

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

• [SR] Kaltstartlatenz von höchstens 100 Millisekunden
• [SR] Kontinuierliche Ausgabelatenz von höchstens 45 Millisekunden
• [SR] Kaltstart-Jitter minimieren

Wenn Geräteimplementierungen die oben genannten Anforderungen nach einer ersten Kalibrierung bei Verwendung der OpenSL ES PCM-Pufferwarteschlangen-API für die kontinuierliche Ausgabelatenz und die Kaltstart-Ausgabelatenz über mindestens ein unterstütztes Audioausgabegerät erfüllen, gilt Folgendes:

• [SR] Es wird DRINGEND EMPFOHLEN, Audio mit niedriger Latenz zu melden, indem das android.hardware.audio.low_latency-Funktions-Flag deklariert wird.
• [SR] Es wird DRINGEND EMPFOHLEN, auch die Anforderungen für Audio mit geringer Latenz über die AAudio API zu erfüllen.

Wenn Geräteimplementierungen die Anforderungen für Audio mit geringer Latenz über die OpenSL ES-PCM-Pufferwarteschlangen-API nicht erfüllen, gilt Folgendes:

• [C-1-1] DÜRFEN die Unterstützung von Audio mit geringer Latenz NICHT melden.

Wenn Geräteimplementierungen android.hardware.microphone enthalten, wird DRINGEND EMPFOHLEN, die folgenden Anforderungen an die Audioeingabe zu erfüllen:

• [SR] Kaltstartlatenz von höchstens 100 Millisekunden
• [SR] Kontinuierliche Eingabelatenz von höchstens 30 Millisekunden
• [SR] Kontinuierliche Umlauflatenz von höchstens 50 Millisekunden
• [SR] Kaltstart-Jitter minimieren

5.7. Netzwerkprotokolle

Geräteimplementierungen MÜSSEN die Media-Netzwerkprotokolle für die Audio- und Videowiedergabe unterstützen, wie in der Android SDK-Dokumentation angegeben.

Wenn Geräteimplementierungen einen Audio- oder Videodecoder enthalten, gilt Folgendes:

• [C-1-1] MUSS alle erforderlichen Codecs und Containerformate in Abschnitt 5.1 über HTTP(S) unterstützen.

• [C-1-2] MUSS die in der Tabelle „Media Segment Formats“ unten gezeigten Media-Segmentformate über das HTTP Live Streaming-Protokollentwurf, Version 7, unterstützen.

• [C-1-3] MUSS das folgende RTP-Audio-/Videoprofil und die zugehörigen Codecs in der RTSP-Tabelle unten unterstützen. Ausnahmen finden Sie in den Tabellenfußnoten in Abschnitt 5.1.

Formate von Media-Segmenten

Segmentformate	Referenz(en)	Erforderliche Codec-Unterstützung
MPEG-2 Transport Stream	ISO 13818	Video-Codecs: H264 AVC MPEG-4 SP MPEG-2 Weitere Informationen zu H264 AVC, MPEG2-4 SP und MPEG-2 finden Sie im Abschnitt 5.1.3. Audio-Codecs: AAC Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1.
AAC mit ADTS-Framing und ID3-Tags	ISO 13818-7	Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1.
WebVTT	WebVTT

RTSP (RTP, SDP)

Profilname	Referenz(en)	Erforderliche Codec-Unterstützung
H264 AVC	RFC 6184	Weitere Informationen zu H264 AVC finden Sie im Abschnitt 5.1.3.
MP4A-LATM	RFC 6416	Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Details zu H263 finden Sie im Abschnitt 5.1.3.
H263-2000	RFC 4629	Details zu H263 finden Sie im Abschnitt 5.1.3.
AMR	RFC 4867	Weitere Informationen zu AMR-NB finden Sie in Abschnitt 5.1.1.
AMR-WB	RFC 4867	Weitere Informationen zu AMR-WB finden Sie in Abschnitt 5.1.1.
MP4V-ES	RFC 6416	Weitere Informationen zu MPEG-4 SP finden Sie im Abschnitt 5.1.3.
mpeg4-generic	RFC 3640	Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1.
MP2T	RFC 2250	Weitere Informationen finden Sie unter MPEG-2 Transport Stream unter HTTP Live Streaming.

5.8. Sichere Medien

Wenn Geräteimplementierungen die sichere Videoausgabe unterstützen und sichere Oberflächen unterstützen können, gilt Folgendes:

• [C-1-1] MÜSSEN die Unterstützung für Display.FLAG_SECURE deklarieren.

Wenn Geräteimplementierungen Unterstützung für Display.FLAG_SECURE und das Wireless Display-Protokoll deklarieren, gilt Folgendes:

• [C-2-1] Die Verbindung MUSS mit einem kryptografisch starken Mechanismus wie HDCP 2.x oder höher für die über drahtlose Protokolle wie Miracast verbundenen Displays gesichert werden.

Wenn Geräteimplementierungen Unterstützung für Display.FLAG_SECURE und kabelgebundene externe Displays deklarieren, gilt Folgendes:

• [C-3-1] MUSS HDCP 1.2 oder höher für alle kabelgebundenen externen Displays unterstützen.

5.9. Musical Instrument Digital Interface (MIDI)

Wenn Geräteimplementierungen die Unterstützung für das Feature android.software.midi über die Klasse android.content.pm.PackageManager melden, gilt Folgendes:

• [C-1-1] MÜSSEN MIDI über alle MIDI-fähigen Hardware-Transports unterstützen, für die sie eine generische Nicht-MIDI-Verbindung bereitstellen, wobei solche Transports Folgendes sind:

  • USB-Hostmodus, Abschnitt 7.7
  • USB-Peripheriemodus, Abschnitt 7.7
  • MIDI über Bluetooth LE in zentraler Rolle, Abschnitt 7.4.3

• [C-1-2] MUSS den Inter-App-MIDI-Softwaretransport (virtuelle MIDI-Geräte) unterstützen

5.10. Professionelles Audio

Wenn Geräteimplementierungen die Unterstützung für das Feature android.hardware.audio.pro über die Klasse android.content.pm.PackageManager melden, gilt Folgendes:

• [C-1-1] MÜSSEN die Unterstützung für die Funktion android.hardware.audio.low_latency melden.
• [C-1-2] Die kontinuierliche Audio-Umlauflatenz, wie in Abschnitt 5.6 „Audio-Latenz“ definiert, MUSS 20 Millisekunden oder weniger betragen und SOLLTE auf mindestens einem unterstützten Pfad 10 Millisekunden oder weniger betragen.
• [C-1-3] MUSS einen oder mehrere USB-Ports enthalten, die den USB-Host-Modus und den USB-Peripheriemodus unterstützen.
• [C-1-4] MÜSSEN die Unterstützung für die Funktion android.software.midi melden.
• [C-1-5] MUSS die Latenz- und USB-Audioanforderungen über die OpenSL ES-PCM-Pufferwarteschlangen-API erfüllen.
• [SR] Es wird DRINGEND EMPFOHLEN, ein gleichbleibendes Maß an CPU-Leistung bereitzustellen, während Audio aktiv ist und die CPU-Last variiert. Dies sollte mit dem SimpleSynth-Commit 1bd6391 getestet werden. Die SimpleSynth-App muss mit den folgenden Parametern ausgeführt werden und nach 10 Minuten darf es keine Underruns geben:
  • Arbeitszyklen: 200.000
  • Variable Last: AN (zwischen 100% und 10% des Werts für Arbeitszyklen wird alle 2 Sekunden gewechselt. Dies dient zum Testen des CPU-Governors.)
  • Stabilisierte Last: AUS
• Sollte die Ungenauigkeit und Abweichung des Audio-Taktgebers im Vergleich zur Standardzeit minimieren.
• Sollte die Audio-Clock-Drift relativ zur CPU CLOCK_MONOTONIC minimieren, wenn beide aktiv sind.
• Sollte die Audiolatenz über geräteinterne Wandler minimieren.
• Sollte die Audiolatenz über USB-Digitalaudio minimieren.
• Die Audiolatenzmessungen sollten für alle Pfade dokumentiert werden.
• Sollte Jitter bei den Eintragszeiten für den Audio-Puffer-Vervollständigungs-Callback minimieren, da dies den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback beeinflusst.
• Sollte bei normaler Verwendung bei der angegebenen Latenz keine Audio-Underruns (Ausgabe) oder Overruns (Eingabe) liefern.
• Sollte keinen Latenzunterschied zwischen den Kanälen aufweisen.
• Die durchschnittliche MIDI-Latenz sollte über alle Transportarten hinweg minimiert werden.
• Die Variabilität der MIDI-Latenz unter Last (Jitter) sollte über alle Transportarten hinweg minimiert werden.
• Sollte über alle Transportarten hinweg genaue MIDI-Zeitstempel liefern.
• Sollte das Rauschen des Audiosignals über On-Device-Wandler minimieren, einschließlich des Zeitraums unmittelbar nach dem Kaltstart.
• Sollte bei aktiven Endpunkten keinen Unterschied zwischen der Audio-Clock auf der Eingabe- und der Ausgabeseite der entsprechenden Endpunkte aufweisen. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher auf dem Gerät oder der Ein- und Ausgang der Audiobuchse.
• Sollte Audio-Puffer-Abschluss-Callbacks für die Ein- und Ausgabeseiten der entsprechenden Endpunkte auf demselben Thread verarbeiten, wenn beide aktiv sind, und den Ausgabecallback unmittelbar nach der Rückgabe vom Eingabecallback aufrufen. Wenn es nicht möglich ist, die Rückrufe im selben Thread zu verarbeiten, rufen Sie den Ausgaberückruf kurz nach dem Eingaberückruf auf, damit die Anwendung ein einheitliches Timing auf der Eingabe- und Ausgabeseite hat.
• Sollte die Phasendifferenz zwischen der HAL-Audio-Pufferung für die Ein- und Ausgabeseiten der entsprechenden Endpunkte minimieren.
• Die Berührungslatenz SOLLTE minimiert werden.
• Die Variabilität der Berührungslatenz unter Last (Jitter) SOLLTE minimiert werden.

Wenn Geräteimplementierungen alle oben genannten Anforderungen erfüllen,

• [SR] Es wird DRINGEND EMPFOHLEN, die Unterstützung für die Funktion android.hardware.audio.pro über die Klasse android.content.pm.PackageManager zu melden.

Wenn Geräteimplementierungen die Anforderungen über die OpenSL ES PCM-Pufferwarteschlangen-API erfüllen, gilt Folgendes:

• [SR] Es wird DRINGEND EMPFOHLEN, die gleichen Anforderungen auch über die AAudio API zu erfüllen.

Wenn Geräteimplementierungen einen 3,5‑mm-Audioanschluss mit 4 Leitern enthalten, gilt Folgendes:

• [C-2-1] Die kontinuierliche Audio-Roundtrip-Latenz muss über den Audiobuchsenpfad 20 Millisekunden oder weniger betragen.
• [SR] Es wird DRINGEND EMPFOHLEN, den Abschnitt Mobile device (jack) specifications der Wired Audio Headset Specification (v1.1) einzuhalten.
• Die kontinuierliche Audio-Umlauflatenz SOLLTE über den Kopfhöreranschluss 10 Millisekunden oder weniger betragen.

Wenn in Geräteimplementierungen eine 3,5‑mm-Audiobuchse mit 4 Leitern fehlt und USB-Ports enthalten sind, die den USB-Hostmodus unterstützen, gilt Folgendes:

• [C-3-1] MÜSSEN die USB-Audio-Klasse implementieren.
• [C-3-2] MUSS im USB-Hostmodus über den USB-Audio-Klassenanschluss eine kontinuierliche Audio-Umlauflatenz von höchstens 20 Millisekunden aufweisen.
• Die kontinuierliche Audio-Umlauflatenz SOLLTE über den USB-Hostmodus-Port mit USB-Audioklasse 10 Millisekunden oder weniger betragen.

Wenn Geräteimplementierungen einen HDMI-Anschluss enthalten, müssen sie:

• [C-4-1] MUSS die Ausgabe in Stereo und acht Kanälen mit einer Bit-Tiefe von 20 Bit oder 24 Bit und 192 kHz ohne Verlust der Bit-Tiefe oder Resampling unterstützen.

5.11. Aufnahme für „Unprocessed“

Android unterstützt die Aufnahme von unbearbeitetem Audio über die Audioquelle android.media.MediaRecorder.AudioSource.UNPROCESSED. In OpenSL ES kann darauf mit dem Aufzeichnungspreset SL_ANDROID_RECORDING_PRESET_UNPROCESSED zugegriffen werden.

Wenn Geräteimplementierungen eine unverarbeitete Audioquelle unterstützen und Drittanbieter-Apps zur Verfügung stellen möchten, müssen sie:

• [C-1-1] MUSS die Unterstützung über die Eigenschaft android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED melden.

• [C-1-2] MUSS im mittleren Frequenzbereich einen annähernd flachen Amplituden-Frequenz-Verlauf aufweisen, d. h. für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird, ±10 dB von 100 Hz bis 7.000 Hz.

• [C-1-3] MUSS Amplitudenpegel im niedrigen Frequenzbereich aufweisen, insbesondere ±20 dB von 5 Hz bis 100 Hz im Vergleich zum mittleren Frequenzbereich für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird.

• [C-1-4] MUSS Amplitudenpegel im Hochfrequenzbereich aufweisen, insbesondere ±30 dB von 7.000 Hz bis 22 kHz im Vergleich zum Mittelfrequenzbereich für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird.

• [C-1-5] Die Empfindlichkeit des Audioeingangs MUSS so eingestellt werden, dass eine bei 94 dB Schalldruckpegel (SPL) abgespielte 1.000 Hz-Sinustonquelle für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird, eine Reaktion mit einem RMS von 520 für 16-Bit-Samples (oder -36 dB Full Scale für Gleitkomma-/Double-Precision-Samples) ergibt.

• [C-1-6] Das Signal-Rausch-Verhältnis (SNR) muss für jedes Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird, mindestens 60 dB betragen. Das SNR wird als Differenz zwischen 94 dB SPL und dem äquivalenten SPL des Eigenrauschens (A-gewichtet) gemessen.

• [C-1-7] MUSS für 1 kHz bei einem Eingangspegel von 90 dB SPL an jedem Mikrofon, das zum Aufzeichnen der unbearbeiteten Audioquelle verwendet wird, einen THD‑Wert (Total Harmonic Distortion) von weniger als 1% aufweisen.

• Es dürfen keine anderen Signalverarbeitungen (z.B. automatische Verstärkungsregelung, Hochpassfilter oder Echounterdrückung) im Pfad vorhanden sein, außer einem Pegelmultiplikator, um den Pegel in den gewünschten Bereich zu bringen. Mit anderen Worten:

• [C-1-8] Wenn in der Architektur aus irgendeinem Grund eine Signalverarbeitung vorhanden ist, MUSS sie deaktiviert werden und darf keine Verzögerung oder zusätzliche Latenz im Signalpfad verursachen.
• [C-1-9] Der Pegelmultiplikator darf sich zwar auf dem Signalweg befinden, darf aber keine Verzögerung oder Latenz auf dem Signalweg verursachen.

Alle SPL-Messungen werden direkt neben dem zu testenden Mikrofon durchgeführt. Bei Konfigurationen mit mehreren Mikrofonen gelten diese Anforderungen für jedes Mikrofon.

Wenn Geräteimplementierungen android.hardware.microphone deklarieren, aber keine Audioquelle ohne Verarbeitung unterstützen, gilt Folgendes:

• [C-2-1] MUSS für die AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)-API-Methode null zurückgeben, um das Fehlen der Unterstützung richtig anzugeben.
• [SR] werden DRINGEND EMPFOHLEN, um so viele Anforderungen wie möglich an den Signalpfad für die unverarbeitete Aufnahmequelle zu erfüllen.

6. Kompatibilität von Entwicklertools und -optionen

6.1. Entwicklertools

Geräteimplementierungen:

• [C-0-1] MÜSSEN die im Android SDK bereitgestellten Android-Entwicklertools unterstützen.

• Android Debug Bridge (ADB)

  • [C-0-2] MUSS alle adb-Funktionen unterstützen, die im Android SDK dokumentiert sind, einschließlich dumpsys.
  • [C-0-3] Das Format oder der Inhalt von Gerätesystemereignissen (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats), die über „dumpsys“ protokolliert werden, DÜRFEN NICHT geändert werden.
  • [C-0-4] Der ADB-Daemon auf dem Gerät MUSS standardmäßig inaktiv sein und es MUSS einen für Nutzer zugänglichen Mechanismus zum Aktivieren der Android Debug Bridge geben.
  • [C-0-5] MÜSSEN sicheres ADB unterstützen. Android unterstützt sicheres adb. „Sicheres adb“ ermöglicht adb auf bekannten authentifizierten Hosts.

  • [C-0-6] Es MUSS einen Mechanismus geben, der es ermöglicht, adb von einem Hostcomputer aus zu verbinden. Beispiel:

    • Bei Geräteimplementierungen ohne USB-Anschluss, der den Peripheriemodus unterstützt, MUSS ADB über ein lokales Netzwerk (z. B. Ethernet oder WLAN) implementiert werden.
    • Es MÜSSEN Treiber für Windows 7, 9 und 10 bereitgestellt werden, damit Entwickler über das ADB-Protokoll eine Verbindung zum Gerät herstellen können.

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] MÜSSEN alle DDMS-Funktionen unterstützen, die im Android SDK dokumentiert sind. Da ddms adb verwendet, SOLLTE die Unterstützung für ddms standardmäßig inaktiv sein, sie MUSS jedoch unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben beschrieben aktiviert hat.
• Monkey
  • [C-0-8] MUSS das Monkey-Framework enthalten und für Anwendungen verfügbar machen.
• SysTrace
  • [C-0-9] MÜSSEN das Systrace-Tool unterstützen, wie im Android SDK dokumentiert. Systrace muss standardmäßig inaktiv sein und es MUSS einen für Nutzer zugänglichen Mechanismus zum Aktivieren von Systrace geben.

6.2. Entwickleroptionen

Android bietet Entwicklern die Möglichkeit, Einstellungen für die App-Entwicklung zu konfigurieren.

Geräteimplementierungen MÜSSEN eine einheitliche Erfahrung für Entwickleroptionen bieten. Sie:

• [C-0-1] MUSS den Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS berücksichtigen, um Einstellungen für die App-Entwicklung anzuzeigen. In der Upstream-Android-Implementierung ist das Menü „Entwickleroptionen“ standardmäßig ausgeblendet. Nutzer können es aufrufen, indem sie siebenmal auf das Menüelement Einstellungen > Über das Gerät > Build-Nummer tippen.
• [C-0-2] Die Entwickleroptionen MÜSSEN standardmäßig ausgeblendet sein und es MUSS einen Mechanismus geben, um die Entwickleroptionen ohne spezielle Zulassungsliste zu aktivieren.
• MAY kann den Zugriff auf das Menü „Entwickleroptionen“ vorübergehend einschränken, indem es das Menü visuell ausblendet oder deaktiviert, um Ablenkungen in Situationen zu vermeiden, in denen die Sicherheit des Nutzers gefährdet ist.

7. Hardwarekompatibilität

Wenn ein Gerät eine bestimmte Hardwarekomponente enthält, für die es eine entsprechende API für Drittentwickler gibt:

• [C-0-1] Die Geräteimplementierung MUSS diese API wie in der Android SDK-Dokumentation beschrieben implementieren.

Wenn eine API im SDK mit einer Hardwarekomponente interagiert, die als optional angegeben ist, und die Geräteimplementierung diese Komponente nicht enthält:

• [C-0-2] Vollständige Klassendefinitionen (wie im SDK dokumentiert) für die Komponenten-APIs MÜSSEN weiterhin angegeben werden.
• [C-0-3] Das Verhalten der API MUSS in angemessener Weise als No-Op implementiert werden.
• [C-0-4] API-Methoden MÜSSEN Nullwerte zurückgeben, sofern dies in der SDK-Dokumentation zulässig ist.
• [C-0-5] API-Methoden MÜSSEN No-op-Implementierungen von Klassen zurückgeben, in denen Nullwerte gemäß SDK-Dokumentation nicht zulässig sind.
• [C-0-6] API-Methoden DÜRFEN KEINE Ausnahmen auslösen, die nicht in der SDK-Dokumentation dokumentiert sind.
• [C-0-7] Geräteimplementierungen MÜSSEN für denselben Build-Fingerabdruck über die Methoden getSystemAvailableFeatures() und hasSystemFeature(String) in der Klasse android.content.pm.PackageManager konsistent genaue Informationen zur Hardwarekonfiguration melden.

Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telefonie-API: Auch auf Geräten, die keine Smartphones sind, müssen diese APIs als sinnvolle No-Ops implementiert werden.

7.1. Display und Grafik

Android bietet Funktionen, mit denen App-Assets und UI-Layouts automatisch an das Gerät angepasst werden, damit Drittanbieter-Apps auf einer Vielzahl von Hardwarekonfigurationen gut ausgeführt werden. Geräte MÜSSEN diese APIs und Verhaltensweisen wie in diesem Abschnitt beschrieben ordnungsgemäß implementieren.

Die Einheiten, auf die in den Anforderungen in diesem Abschnitt verwiesen wird, sind so definiert:

• physische Diagonale. Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Teils des Displays.
• Punkte pro Zoll (DPI). Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1 Zoll abgedeckt werden. Wenn DPI-Werte angegeben sind, müssen sowohl die horizontalen als auch die vertikalen DPI-Werte in den Bereich fallen.
• Seitenverhältnis. Das Verhältnis der Pixel der längeren Seite zur kürzeren Seite des Bildschirms. Ein Display mit 480 × 854 Pixeln hat beispielsweise ein Seitenverhältnis von 854/480 = 1,779 oder ungefähr „16:9“.
• Dichteunabhängige Pixel (dp). Die virtuelle Pixeleinheit, die auf einen Bildschirm mit 160 dpi normalisiert wird, berechnet sich so: Pixel = dps * (density/160).

7.1.1. Bildschirmkonfiguration

7.1.1.1. Displaygröße

Das Android-UI-Framework unterstützt eine Vielzahl von verschiedenen logischen Bildschirm-Layoutgrößen und ermöglicht es Anwendungen, die Bildschirm-Layoutgröße der aktuellen Konfiguration über Configuration.screenLayout mit den SCREENLAYOUT_SIZE_MASK und Configuration.smallestScreenWidthDp abzufragen.

• [C-0-1] Geräteimplementierungen MÜSSEN die korrekte Layoutgröße für Configuration.screenLayout gemäß der Android SDK-Dokumentation melden. Geräteimplementierungen MÜSSEN die korrekten logischen, dichteunabhängigen Pixel (dp) für die Bildschirmabmessungen wie unten angegeben melden:

  • Geräte, bei denen Configuration.uiMode auf einen anderen Wert als UI_MODE_TYPE_WATCH festgelegt ist und die eine small-Größe für Configuration.screenLayout melden, MÜSSEN mindestens 426 dp × 320 dp haben.
  • Geräte, die eine normal-Größe für die Configuration.screenLayout melden, MÜSSEN mindestens 480 dp × 320 dp haben.
  • Geräte, die für die Configuration.screenLayout eine Größe von large melden, MÜSSEN mindestens 640 dp × 480 dp haben.
  • Geräte, die eine Größe von xlarge für die Configuration.screenLayout melden, MÜSSEN mindestens 960 dp × 720 dp haben.

• [C-0-2] Geräteimplementierungen MÜSSEN die von Anwendungen angegebene Unterstützung für Bildschirmgrößen über das Attribut <supports-screens> in der Datei „AndroidManifest.xml“ korrekt berücksichtigen, wie in der Android SDK-Dokumentation beschrieben.

7.1.1.2. Seitenverhältnis des Bildschirms

Es gibt zwar keine Einschränkung für das Bildschirmseitenverhältnis des physischen Displays, aber das Bildschirmseitenverhältnis des logischen Displays, in dem Drittanbieter-Apps gerendert werden, muss den folgenden Anforderungen entsprechen. Es kann aus den Höhe- und Breitenwerten abgeleitet werden, die über die view.Display-APIs und die Configuration API gemeldet werden:

• [C-0-1] Bei Geräteimplementierungen, bei denen Configuration.uiMode auf UI_MODE_TYPE_NORMAL festgelegt ist, MUSS das Seitenverhältnis zwischen 1,3333 (4:3) und 1,86 (ungefähr 16:9) liegen, es sei denn, die App kann als bereit für eine längere Dehnung angesehen werden, weil eine der folgenden Bedingungen erfüllt ist:

  • In der App wurde mit dem Metadatenwert android.max_aspect angegeben, dass sie ein größeres Seitenverhältnis unterstützt.
  • Die App deklariert über das Attribut android:resizeableActivity, dass sie in der Größe veränderbar ist.
  • Die App ist auf API‑Level 26 oder höher ausgerichtet und deklariert kein android:MaxAspectRatio, das das zulässige Seitenverhältnis einschränken würde.

• [C-0-2] Bei Geräteimplementierungen, bei denen Configuration.uiMode auf UI_MODE_TYPE_WATCH festgelegt ist, MUSS der Wert für das Seitenverhältnis auf 1,0 (1:1) festgelegt sein.

7.1.1.3. Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe von logischen Standarddichten, um App-Entwicklern bei der Ausrichtung von App-Ressourcen zu helfen.

• [C-0-1] Standardmäßig MÜSSEN Geräteimplementierungen über die DENSITY_DEVICE_STABLE-API nur eine der folgenden logischen Android-Framework-Dichten melden. Dieser Wert DARF sich zu keinem Zeitpunkt ändern. Das Gerät DARF jedoch eine andere beliebige Dichte melden, die sich aus den vom Nutzer vorgenommenen Änderungen der Displaykonfiguration (z. B. Displaygröße) ergibt, die nach dem ersten Start festgelegt wurden.

  • 120 dpi (ldpi)
  • 160 dpi (mdpi)
  • 213 dpi (tvdpi)
  • 240 dpi (hdpi)
  • 260 dpi (260dpi)
  • 280 dpi (280dpi)
  • 300 dpi (300 dpi)
  • 320 dpi (xhdpi)
  • 340 dpi (340dpi)
  • 360 dpi (360dpi)
  • 400 dpi (400dpi)
  • 420 dpi (420dpi)
  • 480 dpi (xxhdpi)
  • 560 dpi (560dpi)
  • 640 dpi (xxxhdpi)

• Geräteimplementierungen SOLLTEN die Standarddichte des Android-Frameworks definieren, die der physischen Dichte des Bildschirms numerisch am nächsten kommt, es sei denn, diese logische Dichte führt dazu, dass die gemeldete Bildschirmgröße unter die unterstützte Mindestgröße fällt. Wenn die Standarddichte des Android-Frameworks, die der physischen Dichte numerisch am nächsten kommt, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 dp Breite) ist, SOLLTEN Geräteimplementierungen die nächstniedrigere Standarddichte des Android-Frameworks melden.

Wenn es eine Möglichkeit gibt, die Anzeigegröße des Geräts zu ändern:

• [C-1-1] Die Displaygröße darf nicht auf mehr als das 1,5-Fache der nativen Dichte skaliert werden und darf keine effektive Mindestbildschirmdimension von weniger als 320 dp (entspricht dem Ressourcenqualifizierer „sw320dp“) ergeben, je nachdem, was zuerst eintritt.
• [C-1-2] Die Displaygröße DARF NICHT auf weniger als 0,85 Mal die native Dichte skaliert werden.
• Um eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen zu gewährleisten, wird EMPFOHLEN, die folgenden Skalierungen der Optionen für die native Anzeige bereitzustellen (unter Einhaltung der oben genannten Grenzwerte).
• Klein: 0,85x
• Standard: 1x (native Anzeigeskalierung)
• Groß: 1,15‑fach
• Größer: 1,3-fach
• Größte 1,45‑fach

7.1.2. Messwerte für Displayanzeigen

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

• [C-1-1] MUSS korrekte Werte für alle in der android.util.DisplayMetrics API definierten Display-Messwerte zurückgeben.

Wenn Geräteimplementierungen keinen eingebetteten Bildschirm oder keine Videoausgabe enthalten, gilt Folgendes:

• [C-2-1] Es MÜSSEN angemessene Werte für alle in der android.util.DisplayMetrics API definierten Display-Messwerte für die emulierte Standard-view.Display gemeldet werden.

7.1.3. Displayausrichtung

Geräteimplementierungen:

• [C-0-1] MÜSSEN angeben, welche Bildschirmausrichtungen sie unterstützen (android.hardware.screen.portrait und/oder android.hardware.screen.landscape), und MÜSSEN mindestens eine unterstützte Ausrichtung angeben. Ein Gerät mit einem Bildschirm mit fester Ausrichtung im Querformat, z. B. ein Fernseher oder Laptop, SOLLTE nur android.hardware.screen.landscape melden.
• [C-0-2] MUSS den korrekten Wert für die aktuelle Ausrichtung des Geräts zurückgeben, wenn er über die android.content.res.Configuration.orientation-, android.view.Display.getOrientation()- oder andere APIs abgefragt wird.

Wenn Geräteimplementierungen beide Bildschirmausrichtungen unterstützen, gilt Folgendes:

• [C-1-1] MUSS die dynamische Ausrichtung von Anwendungen im Hoch- oder Querformat unterstützen. Das Gerät muss also die Anfrage der Anwendung nach einer bestimmten Bildschirmausrichtung berücksichtigen.
• [C-1-2] Die gemeldete Bildschirmgröße oder ‑dichte darf sich beim Ändern der Ausrichtung NICHT ändern.
• MAY select either portrait or landscape orientation as the default.

7.1.4. 2D- und 3D-Grafikbeschleunigung

7.1.4.1 OpenGL ES

Geräteimplementierungen:

• [C-0-1] MUSS die unterstützten OpenGL ES-Versionen (1.1, 2.0, 3.0, 3.1, 3.2) über die verwalteten APIs (z. B. über die Methode GLES10.getString()) und die nativen APIs korrekt identifizieren.
• [C-0-2] MÜSSEN die Unterstützung für alle entsprechenden verwalteten APIs und nativen APIs für jede OpenGL ES-Version enthalten, die sie unterstützen.

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

• [C-1-1] MÜSSEN sowohl OpenGL ES 1.0 als auch 2.0 unterstützen, wie in der Android SDK-Dokumentation beschrieben.
• [SR] Es wird DRINGEND EMPFOHLEN, OpenGL ES 3.0 zu unterstützen.
• SOLLTE OpenGL ES 3.1 oder 3.2 unterstützen.

Wenn Geräteimplementierungen eine der OpenGL ES-Versionen unterstützen, gilt Folgendes:

• [C-2-1] MÜSSEN alle anderen implementierten OpenGL ES-Erweiterungen über die verwalteten OpenGL ES-APIs und nativen APIs gemeldet werden. Umgekehrt DÜRFEN keine Erweiterungsstrings gemeldet werden, die nicht unterstützt werden.
• [C-2-2] MUSS die Erweiterungen EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage und EGL_ANDROID_recordable unterstützen.
• [SR] Es wird DRINGEND EMPFOHLEN, EGL_KHR_partial_update zu unterstützen.
• Sie SOLLTEN alle von ihnen unterstützten Texturkomprimierungsformate, die in der Regel anbieterspezifisch sind, über die Methode getString() genau melden.

Wenn Geräteimplementierungen Unterstützung für OpenGL ES 3.0, 3.1 oder 3.2 deklarieren, gilt Folgendes:

• [C-3-1] MUSS die entsprechenden Funktionssymbole für diese Version zusätzlich zu den OpenGL ES 2.0-Funktionssymbolen in der Bibliothek „libGLESv2.so“ exportieren.

Wenn Geräteimplementierungen OpenGL ES 3.2 unterstützen, gilt Folgendes:

• [C-4-1] MUSS das OpenGL ES Android Extension Pack vollständig unterstützen.

Wenn Geräteimplementierungen das Android Extension Pack für OpenGL ES vollständig unterstützen, gilt Folgendes:

• [C-5-1] MUSS die Unterstützung über das Funktions-Flag android.hardware.opengles.aep identifizieren.

Wenn Geräteimplementierungen Unterstützung für die Erweiterung EGL_KHR_mutable_render_buffer bieten, gilt Folgendes:

• [C-6-1] MUSS auch die EGL_ANDROID_front_buffer_auto_refresh-Erweiterung unterstützen.

7.1.4.2 Vulkan

Android unterstützt Vulkan, eine plattformübergreifende API mit geringem Aufwand für leistungsstarke 3D-Grafiken.

Wenn Geräteimplementierungen OpenGL ES 3.0 oder 3.1 unterstützen, gilt Folgendes:

• [SR] Es wird DRINGEND EMPFOHLEN, Unterstützung für Vulkan 1.0 einzubauen .

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

• SOLLTEN Unterstützung für Vulkan 1.0 enthalten.

Geräteimplementierungen, die Vulkan 1.0 unterstützen:

• [C-1-1] MÜSSEN den richtigen Ganzzahlwert mit den Funktions-Flags android.hardware.vulkan.level und android.hardware.vulkan.version melden.
• [C-1-2] MÜSSEN mindestens eine VkPhysicalDevice für die native Vulkan API vkEnumeratePhysicalDevices() aufzählen .
• [C-1-3] MÜSSEN die Vulkan 1.0-APIs für jede aufgeführte VkPhysicalDevice vollständig implementieren.
• [C-1-4] MUSS die Ebenen, die in nativen Bibliotheken mit dem Namen libVkLayer*.so im nativen Bibliotheksverzeichnis des Anwendungspakets enthalten sind, über die nativen Vulkan-APIs vkEnumerateInstanceLayerProperties() und vkEnumerateDeviceLayerProperties() auflisten .
• [C-1-5] Es ist NICHT zulässig, Ebenen aufzulisten, die von Bibliotheken außerhalb des Anwendungspakets bereitgestellt werden, oder andere Möglichkeiten zum Tracing oder Abfangen der Vulkan API bereitzustellen, es sei denn, für die Anwendung ist das Attribut android:debuggable auf true festgelegt.
• [C-1-6] MUSS alle Erweiterungs-Strings, die unterstützt werden, über die nativen Vulkan-APIs melden und DÜRFEN umgekehrt KEINE Erweiterungs-Strings melden, die nicht korrekt unterstützt werden.

Geräteimplementierungen, die keine Unterstützung für Vulkan 1.0 enthalten:

• [C-2-1] DÜRFEN KEINE der Vulkan-Feature-Flags deklarieren (z.B. android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] DÜRFEN keine VkPhysicalDevice für die native Vulkan API vkEnumeratePhysicalDevices() aufzählen.

7.1.4.3 RenderScript

• [C-0-1] Geräteimplementierungen MÜSSEN Android RenderScript unterstützen, wie in der Android SDK-Dokumentation beschrieben.

7.1.4.4 2D-Grafikbeschleunigung

Android bietet einen Mechanismus, mit dem Anwendungen deklarieren können, dass sie die Hardwarebeschleunigung für 2D-Grafiken auf Anwendungs-, Aktivitäts-, Fenster- oder Ansichtsebene aktivieren möchten. Dazu wird entweder das Manifest-Tag android:hardwareAccelerated oder direkte API-Aufrufe verwendet.

Geräteimplementierungen:

• [C-0-1] Die Hardwarebeschleunigung MUSS standardmäßig aktiviert sein und MUSS deaktiviert werden, wenn der Entwickler dies durch Festlegen von android:hardwareAccelerated="false” oder durch Deaktivieren der Hardwarebeschleunigung direkt über die Android View APIs anfordert.
• [C-0-2] MUSS ein Verhalten zeigen, das mit der Android SDK-Dokumentation zur Hardwarebeschleunigung übereinstimmt.

Android enthält ein TextureView-Objekt, mit dem Entwickler hardwarebeschleunigte OpenGL ES-Texturen direkt als Rendering-Ziele in eine UI-Hierarchie einbinden können.

• [C-0-3] MÜSSEN die TextureView API unterstützen und sich konsistent mit der Upstream-Android-Implementierung verhalten.

7.1.4.5 Displays mit breitem Farbraum

Wenn Geräteimplementierungen über Display.isWideColorGamut() Unterstützung für Displays mit großem Farbraum beanspruchen , gilt Folgendes:

• [C-1-1] MUSS ein farbkalibriertes Display haben.
• [C-1-2] MUSS ein Display haben, dessen Farbumfang den sRGB-Farbumfang im CIE 1931 xyY-Raum vollständig abdeckt.
• [C-1-3] MUSS ein Display haben, dessen Farbraum im CIE 1931 xyY-Raum eine Fläche von mindestens 90% des NTSC 1953-Farbraums hat.
• [C-1-4] MUSS OpenGL ES 3.0, 3.1 oder 3.2 unterstützen und dies korrekt melden.
• [C-1-5] MUSS die Unterstützung für die Erweiterungen EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_colorspace_scrgb_linear und EGL_GL_colorspace_display_p3 bewerben.
• [SR] Es wird DRINGEND EMPFOHLEN, GL_EXT_sRGB zu unterstützen.

Wenn Geräteimplementierungen keine Displays mit großem Farbraum unterstützen, gilt Folgendes:

• [C-2-1] Sollte 100% oder mehr von sRGB im CIE 1931 xyY-Farbraum abdecken, obwohl der Farbumfang des Displays nicht definiert ist.

7.1.5. Kompatibilitätsmodus für alte Anwendungen

Android bietet einen „Kompatibilitätsmodus“, in dem das Framework in einem Modus mit einer „normalen“ Bildschirmgröße (320 dp Breite) für ältere Anwendungen ausgeführt wird, die nicht für alte Android-Versionen entwickelt wurden, die vor der Unabhängigkeit von der Bildschirmgröße eingeführt wurden.

7.1.6. Displaytechnologie

Die Android-Plattform umfasst APIs, mit denen Anwendungen umfangreiche Grafiken auf dem Display rendern können. Geräte MÜSSEN alle diese APIs unterstützen, wie im Android SDK definiert, sofern in diesem Dokument nicht ausdrücklich etwas anderes erlaubt ist.

Geräteimplementierungen:

• [C-0-1] MÜSSEN Displays unterstützen, die 16‑Bit-Farbgrafiken rendern können.
• Sollte Displays unterstützen, die 24‑Bit-Farbgrafiken darstellen können.
• [C-0-2] MÜSSEN Displays unterstützen, die Animationen rendern können.
• [C-0-3] MUSS die Displaytechnologie mit einem Pixel-Seitenverhältnis (PAR) zwischen 0,9 und 1,15 verwendet werden. Das Pixel-Seitenverhältnis MUSS also nahezu quadratisch (1,0) sein, mit einer Toleranz von 10 bis 15 %.

7.1.7. Sekundäre Displays

Android unterstützt sekundäre Displays, um die Medienfreigabe zu ermöglichen, und bietet Entwickler-APIs für den Zugriff auf externe Displays.

Wenn Geräteimplementierungen ein externes Display über eine kabelgebundene, kabellose oder eingebettete zusätzliche Displayverbindung unterstützen, gilt Folgendes:

• [C-1-1] MUSS den Systemdienst und die API DisplayManager wie in der Android SDK-Dokumentation beschrieben implementieren.

7.2. Eingabegeräte

Geräteimplementierungen:

• [C-0-1] MUSS einen Eingabemechanismus wie einen Touchscreen oder eine Navigation ohne Touchbedienung enthalten, um zwischen den UI-Elementen zu navigieren.

7.2.1. Tastatur

Wenn Geräteimplementierungen Unterstützung für IME-Apps (Input Method Editor) von Drittanbietern enthalten, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag android.software.input_methods deklarieren.
• [C-1-2] MÜSSEN Input Management Framework vollständig implementieren.
• [C-1-3] MUSS eine vorab geladene Softwaretastatur haben.

Geräteimplementierungen: [C-0-1] DÜRFEN keine Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard (QWERTY oder 12-key) angegebenen Formate entspricht. Sollte zusätzliche Implementierungen für die Bildschirmtastatur enthalten. * KANN eine Hardwaretastatur enthalten.

7.2.2. Bedienung ohne Berührung

Android unterstützt das Steuerkreuz, den Trackball und das Rad als Mechanismen für die Navigation ohne Touch.

Geräteimplementierungen:

• [C-0-1] MUSS den richtigen Wert für android.content.res.Configuration.navigation melden.

Wenn Geräteimplementierungen keine Navigation ohne Berührung unterstützen, gilt Folgendes:

• [C-1-1] MUSS einen angemessenen alternativen Benutzeroberflächenmechanismus für die Auswahl und Bearbeitung von Text bereitstellen, der mit Input Management Engines kompatibel ist. Die Upstream-Implementierung von Android Open Source umfasst einen Auswahlmechanismus, der für die Verwendung mit Geräten geeignet ist, die keine Touch-Navigationseingaben haben.

7.2.3. Navigationstasten

Die Funktionen Startbildschirm, Letzte Apps und Zurück, die in der Regel durch eine Interaktion mit einer speziellen physischen Taste oder einem bestimmten Bereich des Touchscreens bereitgestellt werden, sind für das Android-Navigationsparadigma und daher für Geräteimplementierungen unerlässlich:

• [C-0-1] MUSS eine Möglichkeit für Nutzer bieten, installierte Anwendungen zu starten, die eine Aktivität mit dem <intent-filter> haben, das mit ACTION=MAIN und CATEGORY=LAUNCHER oder CATEGORY=LEANBACK_LAUNCHER für die Implementierung auf Fernsehgeräten festgelegt ist. Die Funktion „Zuhause“ SOLLTE der Mechanismus für diese Nutzerfreundlichkeit sein.
• Es SOLLTE Schaltflächen für die Funktionen „Letzte Apps“ und „Zurück“ geben.

Wenn die Funktionen „Home“, „Letzte“ oder „Zurück“ bereitgestellt werden, gilt Folgendes:

• [C-1-1] MUSS mit einer einzigen Aktion (z.B. Tippen, Doppelklicken oder Geste) zugänglich sein, wenn eine der Funktionen zugänglich ist.
• [C-1-2] Es MUSS klar angegeben werden, welche einzelne Aktion die einzelnen Funktionen auslöst. Ein sichtbares Symbol auf der Schaltfläche, ein Softwaresymbol im Navigationsleistenbereich des Displays oder eine Schritt-für-Schritt-Demo während der Einrichtung sind Beispiele für solche Hinweise.

Geräteimplementierungen:

• [SR] Es wird DRINGEND EMPFOHLEN, den Eingabemechanismus für die Menüfunktion nicht bereitzustellen, da sie seit Android 4.0 zugunsten der Aktionsleiste eingestellt wurde.

Wenn Geräteimplementierungen die Menüfunktion bieten, gilt Folgendes:

• [C-2-1] Die Schaltfläche für das Aktionsüberlaufmenü MUSS angezeigt werden, wenn das Pop-up-Menü für das Aktionsüberlaufmenü nicht leer und die Aktionsleiste sichtbar ist.
• [C-2-2] Das Kontextmenü für Aktionen, das durch Auswahl der Überlaufschaltfläche in der Aktionsleiste angezeigt wird, DARF NICHT an einer anderen Position als der Standardposition gerendert werden. Das Kontextmenü für Aktionen, das durch Auswahl der Menüfunktion angezeigt wird, DARF an einer anderen Position als der Standardposition gerendert werden.

Wenn Geräteimplementierungen die Menüfunktion nicht bieten, gilt aus Gründen der Abwärtskompatibilität Folgendes:

• [C-3-1] Die Menüfunktion MUSS für Anwendungen verfügbar sein, wenn targetSdkVersion unter 10 liegt. Dies kann über eine physische Taste, eine Softwaretaste oder Gesten erfolgen. Diese Menüfunktion sollte zugänglich sein, sofern sie nicht zusammen mit anderen Navigationsfunktionen ausgeblendet wird.

Wenn Geräteimplementierungen die Assist-Funktion bereitstellen, gilt Folgendes:

• [C-4-1] Die Assist-Funktion MUSS mit einer einzigen Aktion (z.B. Tippen, Doppelklicken oder Geste) zugänglich sein, wenn andere Navigationstasten zugänglich sind.
• [SR] Es wird DRINGEND EMPFOHLEN, langes Drücken der HOME-Taste als diese vorgesehene Interaktion zu verwenden.

Wenn Geräteimplementierungen einen bestimmten Teil des Bildschirms zum Anzeigen der Navigationstasten verwenden, gilt Folgendes:

• [C-5-1] Die Navigationstasten MÜSSEN einen separaten Bereich des Bildschirms verwenden, der für Anwendungen nicht verfügbar ist, und DÜRFEN den für Anwendungen verfügbaren Bereich des Bildschirms nicht verdecken oder anderweitig beeinträchtigen.
• [C-5-2] MUSS einen Teil des Displays für Anwendungen zur Verfügung stellen, der den in Abschnitt 7.1.1 definierten Anforderungen entspricht.
• [C-5-3] MUSS die von der App über die API-Methode View.setSystemUiVisibility() festgelegten Flags berücksichtigen, damit dieser bestimmte Teil des Bildschirms (auch als Navigationsleiste bezeichnet) wie im SDK dokumentiert ordnungsgemäß ausgeblendet wird.

7.2.4. Touchscreen-Eingabe

Android unterstützt eine Vielzahl von Zeigereingabesystemen wie Touchscreens, Touchpads und Geräte für die Simulation von Berührungseingaben. Touchscreen-basierte Geräteimplementierungen sind mit einem Display verbunden, sodass der Nutzer den Eindruck hat, Elemente auf dem Bildschirm direkt zu bearbeiten. Da der Nutzer den Bildschirm direkt berührt, sind keine zusätzlichen Hinweise erforderlich, um die manipulierten Objekte zu kennzeichnen.

Geräteimplementierungen:

• Sollte ein Zeigereingabesystem haben (entweder mausähnlich oder per Touch).
• Sollte vollständig unabhängig verfolgte Zeiger unterstützen.

Wenn Geräteimplementierungen einen Touchscreen (Single-Touch oder besser) enthalten, gilt Folgendes:

• [C-1-1] MUSS TOUCHSCREEN_FINGER für das API-Feld Configuration.touchscreen melden.
• [C-1-2] MÜSSEN die Funktions-Flags android.hardware.touchscreen und android.hardware.faketouch gemeldet werden.

Wenn Geräteimplementierungen einen Touchscreen enthalten, der mehr als eine Berührung erfassen kann, gilt Folgendes:

• [C-2-1] MUSS die entsprechenden Feature-Flags android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand entsprechend dem Typ des jeweiligen Touchscreens auf dem Gerät melden.

Wenn Geräteimplementierungen keinen Touchscreen enthalten (und nur auf ein Zeigergerät angewiesen sind) und die Anforderungen für gefälschte Berührungen in Abschnitt 7.2.5 erfüllen, gilt Folgendes:

• [C-3-1] DÜRFEN KEIN Funktions-Flag melden, das mit android.hardware.touchscreen beginnt, und MÜSSEN nur android.hardware.faketouch melden.

7.2.5. Gefälschte Eingabe per Berührung

Eine unechte Touch-Oberfläche bietet ein Nutzereingabesystem, das eine Teilmenge der Touchscreen-Funktionen annähert. Eine Maus oder Fernbedienung, mit der ein Cursor auf dem Bildschirm bewegt wird, ähnelt der Touch-Bedienung, erfordert aber, dass der Nutzer zuerst auf ein Element zeigt oder es fokussiert und dann klickt. Zahlreiche Eingabegeräte wie Maus, Trackpad, gyroskopbasierte Air Mouse, Gyro-Pointer, Joystick und Multi-Touch-Trackpad können Fake-Touch-Interaktionen unterstützen. Android enthält die Konstante „android.hardware.faketouch“, die einem Eingabegerät ohne Touch-Funktion (zeigerbasiert) wie einer Maus oder einem Trackpad entspricht, das Touch-basierte Eingaben (einschließlich grundlegender Gestenunterstützung) angemessen emulieren kann. Sie gibt an, dass das Gerät eine emulierte Teilmenge der Touchscreen-Funktionalität unterstützt.

Wenn Geräteimplementierungen keinen Touchscreen, aber ein anderes Zeigereingabesystem enthalten, das sie zur Verfügung stellen möchten, müssen sie:

• SOLLTEN die Unterstützung für das android.hardware.faketouch-Funktions-Flag deklarieren.

Wenn Geräteimplementierungen Unterstützung für android.hardware.faketouch deklarieren, gilt Folgendes:

• [C-1-1] MUSS die absoluten X- und Y-Bildschirmpositionen der Zeigerposition melden und einen visuellen Zeiger auf dem Bildschirm anzeigen.
• [C-1-2] MUSS ein Touch-Ereignis mit dem Aktionscode melden, der die Zustandsänderung angibt, die auftritt, wenn der Zeiger auf dem Bildschirm nach unten oder oben bewegt wird.
• [C-1-3] Das Gerät MUSS das Herunter- und Hochbewegen des Mauszeigers auf einem Objekt auf dem Bildschirm unterstützen, damit Nutzer das Tippen auf ein Objekt auf dem Bildschirm simulieren können.
• [C-1-4] Das Gerät MUSS das Drücken und Loslassen des Zeigers sowie das Drücken und Loslassen des Zeigers an derselben Stelle auf einem Objekt auf dem Bildschirm innerhalb eines Zeitlimits unterstützen, damit Nutzer Doppeltippen auf einem Objekt auf dem Bildschirm simulieren können.
• [C-1-5] MUSS das Herunterdrücken des Zeigers an einem beliebigen Punkt auf dem Bildschirm, das Bewegen des Zeigers zu einem beliebigen anderen Punkt auf dem Bildschirm und das anschließende Loslassen des Zeigers unterstützen, damit Nutzer ein Ziehen per Touchscreen simulieren können.
• [C-1-6] MUSS das Herunterdrücken des Zeigers unterstützen und es Nutzern ermöglichen, das Objekt schnell an eine andere Position auf dem Bildschirm zu verschieben und dann den Zeiger auf dem Bildschirm loszulassen, wodurch das Objekt auf dem Bildschirm geschleudert wird.
• [C-1-7] MUSS TOUCHSCREEN_NOTOUCH für das API-Feld Configuration.touchscreen melden.

Wenn Geräteimplementierungen Unterstützung für android.hardware.faketouch.multitouch.distinct deklarieren, gilt Folgendes:

• [C-2-1] MÜSSEN die Unterstützung für android.hardware.faketouch deklarieren.
• [C-2-2] MUSS die separate Erfassung von mindestens zwei unabhängigen Zeigereingaben unterstützen.

Wenn Geräteimplementierungen Unterstützung für android.hardware.faketouch.multitouch.jazzhand deklarieren, gilt Folgendes:

• [C-3-1] MÜSSEN die Unterstützung für android.hardware.faketouch deklarieren.
• [C-3-2] MUSS die unabhängige Erfassung von mindestens fünf Zeigereingaben (Erfassung einer Hand mit Fingern) unterstützen.

7.2.6. Unterstützung für Gamecontroller

7.2.6.1. Tastenzuordnungen

Wenn Geräteimplementierungen das Feature-Flag android.hardware.gamepad deklarieren, gilt Folgendes:

• [C-1-1] MUSS einen Controller enthalten oder mit einem separaten Controller im Lieferumfang ausgeliefert werden, mit dem alle in den folgenden Tabellen aufgeführten Ereignisse eingegeben werden können.
• [C-1-2] MUSS HID-Ereignisse den zugehörigen Android-view.InputEvent-Konstanten zuordnen können, wie in den folgenden Tabellen aufgeführt. Die Upstream-Android-Implementierung umfasst eine Implementierung für Gamecontroller, die diese Anforderung erfüllt.

Schaltfläche	HID-Nutzung2	Android-Schaltfläche
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Steuerkreuz nach oben1 Steuerkreuz nach unten1	0x01 0x00393	AXIS_HAT_Y4
Steuerkreuz links1 Steuerkreuz rechts1	0x01 0x00393	AXIS_HAT_X4
Linke Schultertaste1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Rechte Schultertaste1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Klick auf den linken Stick1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Rechten Stick drücken1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Startseite1	0x0c 0x0223	KEYCODE_HOME (3)
Zurück1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Die oben genannten HID-Verwendungen müssen in einer Gamepad-CA (0x01 0x0005) deklariert werden.

3 Diese Nutzung muss einen logischen Mindestwert von 0, einen logischen Höchstwert von 7, einen physischen Mindestwert von 0, einen physischen Höchstwert von 315, Einheiten in Grad und eine Berichtsgröße von 4 haben. Der logische Wert wird als Drehung im Uhrzeigersinn von der vertikalen Achse aus definiert. Ein logischer Wert von 0 entspricht beispielsweise keiner Drehung und dem Drücken der Aufwärtstaste, während ein logischer Wert von 1 einer Drehung um 45 Grad und dem Drücken der Aufwärts- und der linken Taste entspricht.

4 MotionEvent

Analoge Steuerung1	HID-Nutzung	Android-Schaltfläche
Linker Trigger	0x02 0x00C5	AXIS_LTRIGGER
Rechter Trigger	0x02 0x00C4	AXIS_RTRIGGER
Linker Joystick	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Rechter Joystick	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Fernbedienung

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.3.1.

7.3. Sensoren

Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, für den es eine entsprechende API für Drittanbieterentwickler gibt, MUSS die Geräteimplementierung diese API wie in der Android SDK-Dokumentation und der Android Open Source-Dokumentation zu Sensoren beschrieben implementieren.

Geräteimplementierungen:

• [C-0-1] MUSS das Vorhandensein oder Fehlen von Sensoren gemäß der Klasse android.content.pm.PackageManager genau melden.
• [C-0-2] MUSS über SensorManager.getSensorList() und ähnliche Methoden eine genaue Liste der unterstützten Sensoren zurückgeben.
• [C-0-3] MUSS sich für alle anderen Sensor-APIs angemessen verhalten (z. B. true oder false zurückgeben, wenn Anwendungen versuchen, Listener zu registrieren, keine Sensor-Listener aufrufen, wenn die entsprechenden Sensoren nicht vorhanden sind usw.).

Wenn Geräteimplementierungen einen bestimmten Sensortyp enthalten, für den es eine entsprechende API für Drittanbieterentwickler gibt, gilt Folgendes:

• [C-1-1] MÜSSEN alle Sensormessungen mit den relevanten Werten des Internationalen Einheitensystems (metrisch) für jeden Sensortyp gemäß der Android SDK-Dokumentation gemeldet werden.
• [C-1-2] MÜSSEN Sensordaten mit einer maximalen Latenz von 100 Millisekunden melden.
• 2 * sample_time für den Fall, dass ein Sensor mit einer Mindestlatenz von 5 ms gestreamt wird + 2 * sample_time, wenn der Anwendungsprozessor aktiv ist. Diese Verzögerung beinhaltet keine Verzögerungen durch Filterung.
• [C-1-3] MUSS die erste Sensorprobe innerhalb von 400 Millisekunden + 2 * sample_time nach Aktivierung des Sensors melden. Für dieses Beispiel ist eine Genauigkeit von 0 zulässig.

• [SR] SHOULD report the event time in nanoseconds as defined in the Android SDK documentation, representing the time the event happened and synchronized with the SystemClock.elapsedRealtimeNano() clock. Es wird DRINGEND EMPFOHLEN, dass vorhandene und neue Android-Geräte diese Anforderungen erfüllen, damit sie auf zukünftige Plattformversionen aktualisiert werden können, in denen dies möglicherweise eine ERFORDERLICHE Komponente ist. Der Synchronisierungsfehler SOLLTE unter 100 Millisekunden liegen.

• [C-1-7] Für jede API, die in der Android SDK-Dokumentation als kontinuierlicher Sensor angegeben ist, MÜSSEN Geräteimplementierungen kontinuierlich periodische Datenproben bereitstellen, die ein Jitter von unter 3 % haben SOLLTEN. Jitter ist definiert als die Standardabweichung der Differenz der gemeldeten Zeitstempelwerte zwischen aufeinanderfolgenden Ereignissen.

• [C-1-8] MUSS dafür sorgen, dass der Sensorereignisstream die Geräte-CPU NICHT daran hindert, in den Ruhezustand zu wechseln oder aus dem Ruhezustand aufzuwachen.

• Wenn mehrere Sensoren aktiviert sind, SOLLTE der Stromverbrauch die Summe des angegebenen Stromverbrauchs der einzelnen Sensoren NICHT überschreiten.

Die obige Liste ist nicht vollständig. Das dokumentierte Verhalten des Android SDK und die Android Open Source-Dokumentation zu Sensoren sind maßgeblich.

Einige Sensortypen sind zusammengesetzt. Das bedeutet, dass sie aus Daten abgeleitet werden können, die von einem oder mehreren anderen Sensoren bereitgestellt werden. Beispiele sind der Orientierungssensor und der Sensor für lineare Beschleunigung.

Geräteimplementierungen:

• SOLLTEN diese Sensortypen implementiert werden, wenn sie die erforderlichen physischen Sensoren enthalten, wie unter Sensortypen beschrieben.

Wenn Geräteimplementierungen einen zusammengesetzten Sensor enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN den Sensor wie in der Android Open Source-Dokumentation zu Verbundsensoren beschrieben implementieren.

7.3.1. Beschleunigungsmesser

• Geräteimplementierungen SOLLTEN einen 3‑Achsen-Beschleunigungsmesser enthalten.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser enthalten, gilt Folgendes:

• [C-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 50 Hz melden können.
• [C-1-2] MÜSSEN den TYPE_ACCELEROMETER-Sensor implementieren und melden.
• [C-1-3] MUSS dem Android-Sensor-Koordinatensystem entsprechen, wie in den Android-APIs beschrieben.
• [C-1-4] MUSS in der Lage sein, auf jeder Achse Messungen vom freien Fall bis zum Vierfachen der Erdbeschleunigung(4g) oder mehr durchzuführen.
• [C-1-5] MUSS eine Auflösung von mindestens 12 Bit haben.
• [C-1-6] MUSS eine Standardabweichung von höchstens 0,05 m/s^ haben.Die Standardabweichung sollte achsenweise anhand von Stichproben berechnet werden, die über einen Zeitraum von mindestens 3 Sekunden bei der schnellsten Samplingrate erfasst wurden.
• [SR] Es wird DRINGEND EMPFOHLEN, den TYPE_SIGNIFICANT_MOTION-Verbundsensor zu implementieren.
• [SR] Das Implementieren des TYPE_ACCELEROMETER_UNCALIBRATED-Sensors wird DRINGEND EMPFOHLEN, wenn die Online-Beschleunigungsmesser-Kalibrierung verfügbar ist.
• Sollte die zusammengesetzten Sensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR und TYPE_STEP_COUNTER wie im Android SDK-Dokument beschrieben implementieren.
• Sollte Ereignisse mit einer Frequenz von mindestens 200 Hz melden.
• SOLLTE eine Auflösung von mindestens 16 Bit haben.
• Sollte während der Verwendung kalibriert werden, wenn sich die Eigenschaften im Laufe des Lebenszyklus ändern, und kompensiert werden. Die Kompensationsparameter sollten zwischen Geräte-Neustarts beibehalten werden.
• Sollte temperaturkompensiert sein.
• Sollten auch den TYPE_ACCELEROMETER_UNCALIBRATED-Sensor implementieren.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser und einen der zusammengesetzten Sensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR oder TYPE_STEP_COUNTER enthalten:

• [C-2-1] Die Summe des Stromverbrauchs MUSS immer unter 4 mW liegen.
• Sollte jeweils unter 2 mW und 0,5 mW liegen, wenn sich das Gerät in einem dynamischen oder statischen Zustand befindet.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser und einen Gyroskopsensor enthalten, gilt Folgendes:

• [C-3-1] MÜSSEN die Verbundsensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren.
• SOLLTEN den TYPE_GAME_ROTATION_VECTOR-Verbundsensor implementieren.
• [SR] Es wird DRINGEND EMPFOHLEN, dass auf bestehenden und neuen Android-Geräten der TYPE_GAME_ROTATION_VECTOR-Sensor implementiert wird.

Wenn Geräteimplementierungen einen 3‑Achsen-Beschleunigungsmesser, einen Gyroskopsensor und einen Magnetometersensor enthalten, gilt Folgendes:

• [C-4-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Verbundsensor implementieren.

7.3.2. Magnetometer

• Geräteimplementierungen SOLLTEN ein 3‑Achsen-Magnetometer (Kompass) enthalten.

Wenn Geräteimplementierungen einen 3‑Achsen-Magnetometer enthalten,

• [C-1-1] MÜSSEN den TYPE_MAGNETIC_FIELD-Sensor implementieren.
• [C-1-2] MUSS Ereignisse mit einer Häufigkeit von mindestens 10 Hz melden können und SOLLTE Ereignisse mit einer Häufigkeit von mindestens 50 Hz melden können.
• [C-1-3] MUSS dem Android-Sensor-Koordinatensystem entsprechen, wie in den Android-APIs beschrieben.
• [C-1-4] MUSS in der Lage sein, auf jeder Achse Werte zwischen -900 µT und +900 µT zu messen, bevor die Sättigung eintritt.
• [C-1-5] MUSS einen Offsetwert für das harte Eisen von weniger als 700 µT haben und SOLLTE einen Wert von unter 200 µT haben. Dazu muss das Magnetometer weit entfernt von dynamischen (strominduzierten) und statischen (magnetinduzierten) Magnetfeldern platziert werden.
• [C-1-6] MUSS eine Auflösung von mindestens 0,6 µT haben.
• [C-1-7] MUSS die Online-Kalibrierung und ‑Kompensation des Hard-Iron-Bias unterstützen und die Kompensationsparameter zwischen Geräte-Neustarts beibehalten.
• [C-1-8] Die Kompensation für weiches Eisen MUSS angewendet werden. Die Kalibrierung kann entweder während der Verwendung oder während der Produktion des Geräts erfolgen.
• [C-1-9] MUSS eine Standardabweichung haben, die achsenweise auf der Grundlage von Stichproben berechnet wird, die über einen Zeitraum von mindestens 3 Sekunden bei der schnellsten Samplingrate erfasst werden und nicht mehr als 1,5 µT beträgt; SOLLTE eine Standardabweichung von höchstens 0,5 µT haben.
• SOLLTEN den TYPE_MAGNETIC_FIELD_UNCALIBRATED-Sensor implementieren.
• [SR] Es wird DRINGEND EMPFOHLEN, dass auf bestehenden und neuen Android-Geräten der TYPE_MAGNETIC_FIELD_UNCALIBRATED-Sensor implementiert wird.

Wenn Geräteimplementierungen einen 3‑Achsen-Magnetometer, einen Beschleunigungsmesser und einen Gyroskopsensor enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Verbundsensor implementieren.

Wenn Geräteimplementierungen ein 3‑Achsen-Magnetometer und einen Beschleunigungsmesser enthalten,

• KANN den TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor implementieren.

Wenn Geräteimplementierungen ein 3‑Achsen-Magnetometer, einen Beschleunigungsmesser und einen TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor enthalten, gilt Folgendes:

• [C-3-1] MUSS weniger als 10 mW verbrauchen.
• Sollte weniger als 3 mW verbrauchen, wenn der Sensor für den Batchmodus bei 10 Hz registriert ist.

7.3.3. GPS

Geräteimplementierungen:

• SOLLTEN einen GPS-/GNSS-Empfänger enthalten.

Wenn Geräteimplementierungen einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps an Anwendungen melden, gilt Folgendes:

• [C-1-1] MUSS Standortausgaben mit einer Rate von mindestens 1 Hz unterstützen, wenn sie über LocationManager#requestLocationUpdate angefordert werden.
• [C-1-2] Die HU MUSS unter störungsfreien Bedingungen (starke Signale, vernachlässigbarer Mehrwegeeffekt, HDOP < 2) innerhalb von 10 Sekunden (Zeit bis zur ersten Standortbestimmung) den Standort bestimmen können, wenn eine Internetverbindung mit einer Datenübertragungsgeschwindigkeit von mindestens 0,5 Mbit/s besteht. Diese Anforderung wird in der Regel durch die Verwendung einer Form von Assisted oder Predicted GPS/GNSS erfüllt, um die GPS/GNSS-Verbindungszeit zu minimieren. Zu den Hilfsdaten gehören Referenzzeit, Referenzstandort und Satellitenephemeriden/-uhr.
  • [SR] Nach einer solchen Standortberechnung wird DRINGEND EMPFOHLEN, dass das Gerät seinen Standort unter störungsfreien Bedingungen innerhalb von 10 Sekunden bestimmen kann, wenn Standortanfragen neu gestartet werden, und zwar bis zu einer Stunde nach der ersten Standortberechnung, auch wenn die nachfolgende Anfrage ohne Datenverbindung und/oder nach einem Neustart erfolgt.

• Unter störungsfreien Bedingungen nach der Standortbestimmung, wenn das Gerät stillsteht oder sich mit einer Beschleunigung von weniger als 1 Meter pro Sekunde im Quadrat bewegt:

  • [C-1-3] Die HU MUSS in mindestens 95% der Fälle den Standort in einem Radius von 20 Metern und die Geschwindigkeit mit einer Genauigkeit von 0,5 Metern pro Sekunde bestimmen können.
  • [C-1-4] Die HU MUSS gleichzeitig mindestens 8 Satelliten aus einer Konstellation verfolgen und über GnssStatus.Callback melden.
  • Die HU SOLLTE mindestens 24 Satelliten aus mehreren Konstellationen gleichzeitig verfolgen können (z.B. GPS und entweder Glonass, Beidou oder Galileo).
  • [C-1-5] MUSS die Generation der GNSS-Technologie über die Test-API „getGnssYearOfHardware“ melden.
  • [SR] Während eines Notrufs weiterhin normale GPS-/GNSS-Standortdaten liefern.
  • [SR] GNSS-Messungen von allen verfolgten Konstellationen (wie in GnssStatus-Nachrichten angegeben) mit Ausnahme von SBAS melden.
  • [SR] AGC und Häufigkeit von GNSS-Messungen melden.
  • [SR] Alle Genauigkeitsschätzungen (einschließlich Toleranz, Geschwindigkeit und Höhe) müssen als Teil jeder GPS-Positionsangabe gemeldet werden.
  • [SR] Es wird DRINGEND EMPFOHLEN, so viele wie möglich der zusätzlichen obligatorischen Anforderungen für Geräte zu erfüllen, die über die Test-API LocationManager.getGnssYearOfHardware() das Jahr „2016“ oder „2017“ melden.

Wenn Geräteimplementierungen einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps an Anwendungen gemeldet wird und die LocationManager.getGnssYearOfHardware() Test API das Jahr „2016“ oder neuer meldet, gilt Folgendes:

• [C-2-1] MÜSSEN GPS-Messungen melden, sobald sie gefunden werden, auch wenn noch kein aus GPS/GNSS berechneter Standort gemeldet wurde.
• [C-2-2] MUSS GPS-Pseudobereiche und Pseudobereichsraten melden, die unter störungsfreien Bedingungen nach der Standortbestimmung im Ruhezustand oder bei einer Beschleunigung von weniger als 0,2 m/s² in mindestens 95% der Fälle ausreichen, um die Position innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0,2 m/s zu berechnen.

Wenn Geräteimplementierungen einen GPS-/GNSS-Empfänger enthalten und die Funktion über das Funktions-Flag android.hardware.location.gps an Anwendungen gemeldet wird und die LocationManager.getGnssYearOfHardware() Test API das Jahr „2017“ oder neuer meldet, gilt Folgendes:

• [C-3-1] MUSS während eines Notrufs weiterhin normale GPS-/GNSS-Standortdaten liefern.
• [C-3-2] MÜSSEN GNSS-Messungen von allen verfolgten Konstellationen (wie in GnssStatus-Nachrichten angegeben) mit Ausnahme von SBAS melden.
• [C-3-3] MUSS die automatische Verstärkungsregelung (AGC) und die Frequenz der GNSS-Messung melden.
• [C-3-4] MÜSSEN alle Genauigkeitsschätzungen (einschließlich Toleranz, Geschwindigkeit und Höhe) als Teil jeder GPS-Positionsangabe melden.

7.3.4. Gyroskop

Geräteimplementierungen:

• SOLLTEN ein Gyroskop (Sensor für Winkeländerungen) enthalten.
• SOLLTEN keinen Gyroskopsensor enthalten, es sei denn, ein 3‑Achsen-Beschleunigungsmesser ist ebenfalls enthalten.

Wenn Geräteimplementierungen ein Gyroskop enthalten, gilt Folgendes:

• [C-1-1] MUSS Ereignisse mit einer Frequenz von mindestens 50 Hz melden können.
• [C-1-2] MÜSSEN den TYPE_GYROSCOPE-Sensor implementieren und SOLLTEN auch den TYPE_GYROSCOPE_UNCALIBRATED-Sensor implementieren.
• [C-1-3] MUSS in der Lage sein,Änderungen der Ausrichtung von bis zu 1.000 Grad pro Sekunde zu messen.
• [C-1-4] MUSS eine Auflösung von mindestens 12 Bit haben und SOLLTE eine Auflösung von mindestens 16 Bit haben.
• [C-1-5] MUSS temperaturkompensiert sein.
• [C-1-6] MUSS während der Verwendung kalibriert und kompensiert werden und die Kompensationsparameter zwischen Geräte-Neustarts beibehalten.
• [C-1-7] MUSS eine Varianz von höchstens 1e-7 rad^2 / s^2 pro Hz (Varianz pro Hz oder rad^2 / s) haben. Die Varianz darf mit der Samplingrate variieren, MUSS aber durch diesen Wert begrenzt werden. Mit anderen Worten: Wenn Sie die Varianz des Gyroskops bei einer Abtastrate von 1 Hz messen, DÜRFTE sie nicht größer als 1e-7 rad²/s² sein.
• [SR] Es wird DRINGEND EMPFOHLEN, dass auf bestehenden und neuen Android-Geräten der SENSOR_TYPE_GYROSCOPE_UNCALIBRATED-Sensor implementiert wird.
• [SR] Es wird DRINGEND EMPFOHLEN, dass der Kalibrierungsfehler weniger als 0,01 rad/s beträgt, wenn sich das Gerät bei Raumtemperatur in Ruhe befindet.
• Sollte Ereignisse mit einer Frequenz von mindestens 200 Hz melden.

Wenn Geräteimplementierungen ein Gyroskop, einen Beschleunigungsmesser und einen Magnetometer-Sensor enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN einen TYPE_ROTATION_VECTOR-Verbundsensor implementieren.

Wenn Geräteimplementierungen ein Gyroskop und einen Beschleunigungsmesser enthalten, gilt Folgendes:

• [C-3-1] MÜSSEN die Verbundsensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren.
• [SR] Es wird DRINGEND EMPFOHLEN, dass auf bestehenden und neuen Android-Geräten der TYPE_GAME_ROTATION_VECTOR-Sensor implementiert wird.
• SOLLTEN den TYPE_GAME_ROTATION_VECTOR-Verbundsensor implementieren.

7.3.5. Barometer

• Geräteimplementierungen SOLLTEN ein Barometer (Sensor für den Umgebungsdruck) enthalten.

Wenn Geräteimplementierungen ein Barometer enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN den TYPE_PRESSURE-Sensor implementieren und melden.
• [C-1-2] MUSS Ereignisse mit mindestens 5 Hz liefern können.
• [C-1-3] MUSS temperaturkompensiert sein.
• [SR] Es wird DRINGEND EMPFOHLEN, Druckmessungen im Bereich von 300 hPa bis 1.100 hPa melden zu können.
• SOLLTE eine absolute Genauigkeit von 1 hPa haben.
• Sollte eine relative Genauigkeit von 0,12 hPa über einen Bereich von 20 hPa haben (entspricht einer Genauigkeit von etwa 1 m über eine Änderung von etwa 200 m auf Meereshöhe).

7.3.6. Thermometer

Geräteimplementierungen: KÖNNEN ein Umgebungsthermometer (Temperatursensor) enthalten. MAY but SHOULD NOT include a CPU temperature sensor.

Wenn Geräteimplementierungen ein Umgebungsthermometer (Temperatursensor) enthalten, gilt Folgendes:

• [C-1-1] MUSS als SENSOR_TYPE_AMBIENT_TEMPERATURE definiert werden und MUSS die Umgebungstemperatur (Raum/Fahrzeugkabine) in Grad Celsius messen, an der der Nutzer mit dem Gerät interagiert.
• [C-1-2] MUSS als SENSOR_TYPE_TEMPERATURE definiert werden.
• [C-1-3] Die Temperatur der Geräte-CPU MUSS gemessen werden.
• [C-1-4] Es darf keine andere Temperatur gemessen werden.

Der Sensortyp SENSOR_TYPE_TEMPERATURE wurde in Android 4.0 eingestellt.

7.3.7. Fotometer

• Geräteimplementierungen KÖNNEN ein Fotometer (Umgebungslicht-Sensor) enthalten.

7.3.8. Näherungssensor

• Geräteimplementierungen KÖNNEN einen Näherungssensor enthalten.

Wenn Geräteimplementierungen einen Näherungssensor enthalten, gilt Folgendes:

• [C-1-1] MUSS die Nähe eines Objekts in derselben Richtung wie das Display messen. Das heißt, der Näherungssensor MUSS so ausgerichtet sein, dass er Objekte in der Nähe des Displays erkennt, da der primäre Zweck dieses Sensortyps darin besteht, zu erkennen, ob ein Nutzer das Smartphone verwendet. Wenn Geräteimplementierungen einen Näherungssensor mit einer anderen Ausrichtung enthalten, DARF er NICHT über diese API zugänglich sein.
• [C-1-2] MUSS mindestens 1 Bit Genauigkeit haben.

7.3.9. Zuverlässige Sensoren

Wenn Geräteimplementierungen eine Reihe von Sensoren mit höherer Qualität enthalten, wie in diesem Abschnitt definiert, und diese für Drittanbieter-Apps verfügbar machen, müssen sie:

• [C-1-1] MUSS die Funktion über das Funktions-Flag android.hardware.sensor.hifi_sensors identifizieren.

Wenn Geräteimplementierungen android.hardware.sensor.hifi_sensors deklarieren, gilt Folgendes:

• [C-2-1] MUSS einen TYPE_ACCELEROMETER-Sensor haben, der:

  • MUSS einen Messbereich von mindestens -8 g bis +8 g haben.
  • MUSS eine Messauflösung von mindestens 1.024 LSB/G haben.
  • MUSS eine Mindestmesshäufigkeit von 12,5 Hz oder weniger haben.
  • MUSS eine maximale Messfrequenz von mindestens 400 Hz haben.
  • Das Messrauschen darf nicht über 400 µG/√Hz liegen.
  • MUSS eine nicht aufweckende Form dieses Sensors mit einer Pufferkapazität von mindestens 3.000 Sensorereignissen implementieren.
  • MUSS einen Batching-Stromverbrauch von höchstens 3 mW haben.
  • Die Bias-Stabilität des stationären Rauschens SOLLTE aus einem statischen 24-Stunden-Datensatz \<15 μg √Hz betragen.
  • Die Bias-Änderung im Vergleich zur Temperatur SOLLTE ≤ +/- 1 mg / °C betragen.
  • Die Nichtlinearität der Best-Fit-Linie SOLLTE ≤ 0,5 % und die Änderung der Empfindlichkeit im Verhältnis zur Temperatur SOLLTE ≤ 0,03%/C° betragen.
  • SOLLTE ein Rauschspektrum mit weißem Rauschen haben, um eine angemessene Qualifizierung der Rauschinhalte des Sensors zu gewährleisten.

• [C-2-2] MUSS ein TYPE_ACCELEROMETER_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_ACCELEROMETER haben.

• [C-2-3] MUSS einen TYPE_GYROSCOPE-Sensor haben, der:

  • MUSS einen Messbereich zwischen mindestens -1.000 und +1.000 dps haben.
  • MUSS eine Messauflösung von mindestens 16 LSB/dps haben.
  • MUSS eine Mindestmesshäufigkeit von 12,5 Hz oder weniger haben.
  • MUSS eine maximale Messfrequenz von mindestens 400 Hz haben.
  • Das Messrauschen DARF nicht über 0,014°/s/√Hz liegen.
  • Die stationäre Bias-Stabilität SOLLTE anhand eines statischen Datensatzes von 24 Stunden < 0,0002 °/s √Hz betragen.
  • Die Bias-Änderung im Vergleich zur Temperatur SOLLTE ≤ +/- 0,05 °/ s / °C betragen.
  • Die Empfindlichkeit sollte sich im Vergleich zur Temperatur um höchstens 0,02% / °C ändern.
  • SOLLTE eine Nichtlinearität der Ausgleichsgeraden von ≤ 0,2 % aufweisen.
  • SOLLTE eine Rauschdichte von ≤ 0,007 °/s/√Hz haben.
  • SOLLTE ein Rauschspektrum mit weißem Rauschen haben, um eine angemessene Qualifizierung der Rauschinhalte des Sensors zu gewährleisten.
  • Der Kalibrierungsfehler SOLLTE im Temperaturbereich von 10 bis 40 °C weniger als 0,002 rad/s betragen, wenn das Gerät nicht bewegt wird.

• [C-2-4] MUSS ein TYPE_GYROSCOPE_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_GYROSCOPE haben.

• [C-2-5] MUSS einen TYPE_GEOMAGNETIC_FIELD-Sensor haben, der:
  • MUSS einen Messbereich von mindestens -900 bis +900 µT haben.
  • MUSS eine Messauflösung von mindestens 5 LSB/uT haben.
  • Die Mindestmesshäufigkeit MUSS 5 Hz oder weniger betragen.
  • MUSS eine maximale Messfrequenz von mindestens 50 Hz haben.
  • MUSS ein Messrauschen von höchstens 0,5 µT aufweisen.
• [C-2-6] MUSS ein TYPE_MAGNETIC_FIELD_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_GEOMAGNETIC_FIELD haben. Außerdem gilt:
  • Es MUSS eine nicht aufweckende Form dieses Sensors mit einer Pufferkapazität von mindestens 600 Sensorereignissen implementiert werden.
  • SOLLTE ein Rauschspektrum mit weißem Rauschen haben, um eine angemessene Qualifizierung der Rauschinhalte des Sensors zu gewährleisten.
• [C-2-7] MÜSSEN einen TYPE_PRESSURE-Sensor haben, der:
  • MUSS einen Messbereich zwischen mindestens 300 und 1.100 hPa haben.
  • MUSS eine Messauflösung von mindestens 80 LSB/hPa haben.
  • Die Mindestmesshäufigkeit MUSS 1 Hz oder weniger betragen.
  • MUSS eine maximale Messfrequenz von mindestens 10 Hz haben.
  • MUSS ein Messrauschen von höchstens 2 Pa/√Hz aufweisen.
  • MUSS eine nicht aufweckende Form dieses Sensors mit einer Pufferkapazität von mindestens 300 Sensorereignissen implementieren.
  • Der Stromverbrauch für das Batching darf nicht höher als 2 mW sein.
• [C-2-8] MUSS einen TYPE_GAME_ROTATION_VECTOR-Sensor haben, der:
  • MUSS eine nicht aufweckende Form dieses Sensors mit einer Pufferkapazität von mindestens 300 Sensorereignissen implementieren.
  • Der Stromverbrauch für das Batching MUSS mindestens 4 mW betragen.
• [C-2-9] MUSS einen TYPE_SIGNIFICANT_MOTION-Sensor haben, der:
  • Der Stromverbrauch darf nicht höher als 0,5 mW sein, wenn das Gerät statisch ist, und nicht höher als 1,5 mW, wenn es sich bewegt.
• [C-2-10] MUSS einen TYPE_STEP_DETECTOR-Sensor haben, der:
  • MUSS eine Nicht-Wake-up-Version dieses Sensors mit einer Pufferkapazität von mindestens 100 Sensorereignissen implementieren.
  • Der Stromverbrauch darf nicht höher als 0,5 mW sein, wenn das Gerät statisch ist, und nicht höher als 1,5 mW, wenn es sich bewegt.
  • Der Stromverbrauch für das Batching MUSS mindestens 4 mW betragen.
• [C-2-11] MUSS einen TYPE_STEP_COUNTER-Sensor haben, der:
  • Der Stromverbrauch darf nicht höher als 0,5 mW sein, wenn das Gerät statisch ist, und nicht höher als 1,5 mW, wenn es sich bewegt.
• [C-2-12] MUSS einen TILT_DETECTOR-Sensor haben, der:
  • Der Stromverbrauch darf nicht höher als 0,5 mW sein, wenn das Gerät statisch ist, und nicht höher als 1,5 mW, wenn es sich bewegt.
• [C-2-13] Der Ereigniszeitstempel desselben physischen Ereignisses, das vom Beschleunigungsmesser, Gyroskop und Magnetometer gemeldet wird, MUSS innerhalb von 2,5 Millisekunden liegen.
• [C-2-14] MUSS Zeitstempel für Gyroskopsensorereignisse auf derselben Zeitbasis wie das Kamerasubsystem und mit einem Fehler von maximal 1 Millisekunde haben.
• [C-2-15] MUSS innerhalb von 5 Millisekunden nach Verfügbarkeit der Daten auf einem der oben genannten physischen Sensoren an die Anwendung geliefert werden.
• [C-2-16] Der Stromverbrauch darf nicht höher als 0,5 mW sein, wenn das Gerät statisch ist, und nicht höher als 2,0 mW, wenn das Gerät sich bewegt, wenn eine beliebige Kombination der folgenden Sensoren aktiviert ist:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] MAY have a TYPE_PROXIMITY sensor, but if present MUST have a minimum buffer capability of 100 sensor events.

Beachten Sie, dass alle Anforderungen an den Stromverbrauch in diesem Abschnitt nicht den Stromverbrauch des Anwendungsprozessors umfassen. Dazu gehört auch die Leistung, die von der gesamten Sensorkette aufgenommen wird, also vom Sensor, von der unterstützenden Schaltung, von einem dedizierten Sensorverarbeitungssystem usw.

Wenn Geräteimplementierungen eine direkte Sensorunterstützung enthalten, gilt Folgendes:

• [C-3-1] MUSS die Unterstützung von direkten Kanaltypen und die Ebene der direkten Berichtsraten über die API isDirectChannelTypeSupported und getHighestDirectReportRateLevel korrekt deklarieren.
• [C-3-2] MUSS mindestens einen der beiden direkten Sensor-Kanaltypen für alle Sensoren unterstützen, die Unterstützung für den direkten Sensor-Kanal deklarieren.
• TYPE_HARDWARE_BUFFER
• TYPE_MEMORY_FILE
• Die Ereignisberichterstellung über den direkten Sensorchannel für den primären Sensor (Nicht-Wakeup-Variante) der folgenden Typen SOLLTE unterstützt werden:
• TYPE_ACCELEROMETER
• TYPE_ACCELEROMETER_UNCALIBRATED
• TYPE_GYROSCOPE
• TYPE_GYROSCOPE_UNCALIBRATED
• TYPE_MAGNETIC_FIELD
• TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Fingerabdrucksensor

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm enthalten, gilt Folgendes:

• SOLLTE einen Fingerabdrucksensor enthalten.

Wenn Geräteimplementierungen einen Fingerabdrucksensor enthalten und den Sensor für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MÜSSEN die Unterstützung für die android.hardware.fingerprint-Funktion deklarieren.
• [C-1-2] MUSS die entsprechende API vollständig implementieren, wie in der Android SDK-Dokumentation beschrieben.
• [C-1-3] MUSS eine Falschakzeptanzrate von höchstens 0,002 % haben.
• [SR] Es wird DRINGEND EMPFOHLEN, dass die Akzeptanzrate für Spoofing und Identitätsdiebstahl nicht höher als 7 % ist.
• [C-1-4] Es MUSS offengelegt werden, dass dieser Modus möglicherweise weniger sicher ist als eine komplexe PIN, ein komplexes Muster oder ein komplexes Passwort. Außerdem MÜSSEN die Risiken der Aktivierung klar aufgeführt werden, wenn die Akzeptanzraten für Spoofing und Identitätsdiebstahl höher als 7 % sind.
• [C-1-5] Nach fünf fehlgeschlagenen Versuchen zur Fingerabdrucküberprüfung MUSS die Anzahl der Versuche für mindestens 30 Sekunden begrenzt werden.
• [C-1-6] MUSS eine hardwarebasierte Keystore-Implementierung haben und den Fingerabdruckabgleich in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) oder auf einem Chip mit einem sicheren Kanal zur TEE durchführen.
• [C-1-7] Alle identifizierbaren Fingerabdruckdaten MÜSSEN verschlüsselt und kryptografisch authentifiziert werden, sodass sie außerhalb der Trusted Execution Environment (TEE) nicht abgerufen, gelesen oder geändert werden können, wie in den Implementierungsrichtlinien auf der Android Open Source Project-Website dokumentiert.
• [C-1-8] Das Hinzufügen eines Fingerabdrucks MUSS verhindert werden, ohne dass zuerst eine Vertrauenskette aufgebaut wird, indem der Nutzer ein vorhandenes oder neues Geräte-Anmeldedatum (PIN/Muster/Passwort) bestätigt, das durch TEE gesichert ist. Die Android Open Source Project-Implementierung bietet den Mechanismus im Framework, um dies zu tun.
• [C-1-9] Drittanbieteranwendungen DÜRFEN NICHT in der Lage sein, zwischen einzelnen Fingerabdrücken zu unterscheiden.
• [C-1-10] MUSS das Flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT berücksichtigen.
• [C-1-11] MUSS bei einem Upgrade von einer Version vor Android 6.0 die Fingerabdruckdaten sicher migrieren, um die oben genannten Anforderungen zu erfüllen, oder entfernen.
• [SR] Es wird DRINGEND EMPFOHLEN, dass die Falsch-Ablehnungsrate auf dem Gerät gemessen weniger als 10 % beträgt.
• [SR] Es wird DRINGEND EMPFOHLEN, dass die Latenz für einen registrierten Finger unter 1 Sekunde liegt. Die Latenz wird gemessen vom Zeitpunkt der Berührung des Fingerabdrucksensors bis zum Entsperren des Displays.
• Sollte das im Android Open Source Project bereitgestellte Android-Fingerabdrucksymbol verwenden.

7.3.11. Sensoren, die nur in Android Automotive verfügbar sind

Fahrzeugspezifische Sensoren sind in der android.car.CarSensorManager API definiert.

7.3.11.1. Aktueller Gang

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.11.2. Tag-/Nachtmodus

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.11.3. Fahrstatus

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.11.4. Raddrehzahlsensor

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.12. Pose Sensor

Geräteimplementierungen:

• Unterstützt möglicherweise den Positionssensor mit 6 Freiheitsgraden.

Wenn Geräteimplementierungen den Lagesensor mit 6 Freiheitsgraden unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN den TYPE_POSE_6DOF-Sensor implementieren und melden.
• [C-1-2] MUSS genauer sein als der Rotationsvektor allein.

7.4. Datenverbindung

7.4.1. Telefonie

„Telefonie“ bezieht sich in den Android-APIs und in diesem Dokument speziell auf Hardware, die zum Tätigen von Sprachanrufen und zum Senden von SMS-Nachrichten über ein GSM- oder CDMA-Netzwerk verwendet wird. Diese Sprachanrufe können paketvermittelt sein oder nicht, werden aber für Android unabhängig von einer Datenverbindung betrachtet, die möglicherweise über dasselbe Netzwerk implementiert wird. Die Android-Telefoniefunktionen und ‑APIs beziehen sich also speziell auf Sprachanrufe und SMS. Geräteimplementierungen, mit denen keine Anrufe getätigt oder SMS gesendet/empfangen werden können, gelten beispielsweise nicht als Telefoniegeräte, unabhängig davon, ob sie ein Mobilfunknetz für die Datenverbindung verwenden.

• Android KANN auf Geräten verwendet werden, die keine Telefonie-Hardware enthalten. Android ist also mit Geräten kompatibel, die keine Smartphones sind.

Wenn Geräteimplementierungen GSM- oder CDMA-Telefonie umfassen, müssen sie:

• [C-1-1] MÜSSEN das android.hardware.telephony-Funktions-Flag und andere Unterfunktions-Flags entsprechend der Technologie deklarieren.
• [C-1-2] MUSS die API für diese Technologie vollständig unterstützen.

Wenn Geräteimplementierungen keine Telefoniehardware enthalten, müssen sie:

• [C-2-1] Die vollständigen APIs MÜSSEN als No-Ops implementiert werden.

7.4.1.1. Kompatibilität der Nummernblockierung

Wenn Geräteimplementierungen android.hardware.telephony feature melden, gilt Folgendes:

• [C-1-1] MUSS die Blockierung von Nummern unterstützen
• [C-1-2] MUSS BlockedNumberContract und die entsprechende API vollständig implementieren, wie in der SDK-Dokumentation beschrieben.
• [C-1-3] ALLE Anrufe und Nachrichten von einer Telefonnummer in „BlockedNumberProvider“ MÜSSEN ohne Interaktion mit Apps blockiert werden. Die einzige Ausnahme ist, wenn die Nummernbereiche vorübergehend aufgehoben werden, wie in der SDK-Dokumentation beschrieben.
• [C-1-4] Die App DARF NICHT in den Plattformanruflistenanbieter für einen blockierten Anruf schreiben.
• [C-1-5] Der Telefonieanbieter darf bei einer blockierten Nachricht NICHT kontaktiert werden.
• [C-1-6] Es MUSS eine Benutzeroberfläche zur Verwaltung blockierter Nummern implementiert werden, die mit dem von der Methode TelecomManager.createManageBlockedNumbersIntent() zurückgegebenen Intent geöffnet wird.
• [C-1-7] Sekundäre Nutzer DÜRFEN die blockierten Nummern auf dem Gerät NICHT ansehen oder bearbeiten können, da die Android-Plattform davon ausgeht, dass der primäre Nutzer die vollständige Kontrolle über die Telefoniedienste auf dem Gerät hat. Die gesamte Benutzeroberfläche für das Blockieren MUSS für sekundäre Nutzer ausgeblendet werden und die Liste der blockierten Nutzer MUSS weiterhin berücksichtigt werden.
• Sollte die blockierten Nummern zum Anbieter migrieren, wenn ein Gerät auf Android 7.0 aktualisiert wird.

7.4.1.2. Telecom API

Wenn Geräteimplementierungen android.hardware.telephony melden, gilt Folgendes:

• [C-SR] Es wird DRINGEND EMPFOHLEN, die KEYCODE_MEDIA_PLAY_PAUSE- und KEYCODE_HEADSETHOOK-Ereignisse des Audio-Headsets für die android.telecom-APIs wie unten beschrieben zu verarbeiten:
  • Rufen Sie Connection.onDisconnect() auf, wenn während eines laufenden Anrufs ein kurzes Drücken des Tastendruckereignisses erkannt wird.
  • Rufen Sie Connection.onAnswer() auf, wenn während eines eingehenden Anrufs ein kurzer Tastendruck erkannt wird.
  • Rufen Sie Connection.onReject() auf, wenn während eines eingehenden Anrufs ein langes Drücken des Tastaturereignisses erkannt wird.
  • Stummschaltung der CallAudioState aktivieren oder deaktivieren

7.4.2. IEEE 802.11 (WLAN)

Geräteimplementierungen:

• Sollte Unterstützung für eine oder mehrere Formen von 802.11 enthalten.

Wenn Geräteimplementierungen Unterstützung für 802.11 enthalten und die Funktionalität für eine Drittanbieteranwendung verfügbar machen,

• [C-1-1] MÜSSEN die entsprechende Android-API implementieren.
• [C-1-2] MUSS das Hardware-Funktions-Flag android.hardware.wifi melden.
• [C-1-3] MUSS die Multicast-API wie in der SDK-Dokumentation beschrieben implementieren.
• [C-1-4] MUSS Multicast-DNS (mDNS) unterstützen und mDNS-Pakete (224.0.0.251) zu keinem Zeitpunkt filtern, einschließlich:
  • Auch wenn der Bildschirm nicht aktiv ist.
  • Bei Android TV-Geräteimplementierungen, auch im Standby-Modus.
• SOLLTEN die MAC‑Quelladresse und Sequenznummer von Frames zur Prüfungsanfrage randomisieren, einmal zu Beginn aller Scans, während STA getrennt ist.
  • Jede Gruppe mit Frames zur Prüfungsanfrage mit einen Scan SOLLTE eine gleichbleibende MAC‑Adresse verwenden (sollte die MAC‑Adresse nicht nach der Hälfte des Scans randomisieren).
  • Die Sequenznummer der Prüfungsanfrage sollte zwischen den Prüfungsanfragen in einem Scan als normal (sequenziell) iteriert werden.
  • Die Sequenznummer der Prüfungsanfrage sollte zwischen der letzten Prüfungsanfrage eines Scans und der ersten Prüfungsanfrage des nächsten Scans randomisiert werden.
• Sollte nur die folgenden Informationselemente in Probe Request-Frames zulassen, während die STA getrennt ist:
  • SSID-Parametersatz (0)
  • DS-Parametersatz (3)

7.4.2.1. Wi-Fi Direct

Geräteimplementierungen:

• SOLLTE Unterstützung für Wi‑Fi Direct (Wi‑Fi Peer-to-Peer) enthalten.

Wenn Geräteimplementierungen Unterstützung für Wi‑Fi Direct enthalten, gilt Folgendes:

• [C-1-1] MUSS die entsprechende Android-API wie in der SDK-Dokumentation beschrieben implementieren.
• [C-1-2] MÜSSEN die Hardwarefunktion android.hardware.wifi.direct melden.
• [C-1-3] MUSS den regulären WLAN-Betrieb unterstützen.
• Sollte Wi‑Fi- und Wi‑Fi Direct-Vorgänge gleichzeitig unterstützen.

7.4.2.2. Einrichtung von Wi-Fi Tunneled Direct Link

Geräteimplementierungen:

• Sollte Unterstützung für Wi-Fi Tunneled Direct Link Setup (TDLS) enthalten, wie in der Android SDK-Dokumentation beschrieben.

Wenn Geräteimplementierungen Unterstützung für TDLS enthalten und TDLS über die WiFiManager API aktiviert wird, gilt Folgendes:

• [C-1-1] MUSS die Unterstützung für TDLS über WifiManager.isTdlsSupported deklarieren.
• TDLS sollte nur verwendet werden, wenn es möglich UND von Vorteil ist.
• Sollte eine Heuristik verwenden und TDLS NICHT verwenden, wenn die Leistung schlechter sein könnte als über den WLAN-Zugangspunkt.

7.4.2.3. Wi‑Fi Aware

Geräteimplementierungen:

• SOLLTE Unterstützung für Wi‑Fi Aware enthalten.

Wenn Geräteimplementierungen Unterstützung für Wi-Fi Aware enthalten und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS die WifiAwareManager-APIs wie in der SDK-Dokumentation beschrieben implementieren.
• [C-1-2] MUSS das Funktions-Flag android.hardware.wifi.aware deklarieren.
• [C-1-3] MUSS WLAN- und Wi-Fi Aware-Vorgänge gleichzeitig unterstützen.
• [C-1-4] Die Adresse der Wi-Fi Aware-Verwaltungsschnittstelle MUSS in Intervallen von höchstens 30 Minuten und immer dann, wenn Wi-Fi Aware aktiviert ist, zufällig generiert werden.

7.4.2.4. WLAN-Passpoint

Geräteimplementierungen:

• Sollte Unterstützung für Wi‑Fi Passpoint enthalten.

Wenn Geräteimplementierungen Unterstützung für Wi‑Fi Passpoint enthalten, gilt Folgendes:

• [C-1-1] MUSS die Passpoint-bezogenen WifiManager-APIs wie in der SDK-Dokumentation beschrieben implementieren.
• [C-1-2] MUSS den IEEE 802.11u-Standard unterstützen, insbesondere in Bezug auf die Netzwerkerkennung und ‑auswahl, z. B. Generic Advertisement Service (GAS) und Access Network Query Protocol (ANQP).

Wenn Geräteimplementierungen keine Unterstützung für Wi‑Fi Passpoint enthalten:

• [C-2-1] Die Implementierung der Passpoint-bezogenen WifiManager-APIs MUSS eine UnsupportedOperationException auslösen.

7.4.3. Bluetooth

Wenn Geräteimplementierungen das Bluetooth-Audioprofil unterstützen, gilt Folgendes:

• SOLLTEN Advanced Audio Codecs und Bluetooth-Audio-Codecs (z.B. LDAC) unterstützen.

Wenn Geräteimplementierungen die Funktion android.hardware.vr.high_performance deklarieren, gilt Folgendes:

• [C-1-1] MÜSSEN Bluetooth 4.2 und die Bluetooth LE Data Length Extension unterstützen.

Android unterstützt Bluetooth und Bluetooth Low Energy.

Wenn Geräteimplementierungen Unterstützung für Bluetooth und Bluetooth Low Energy enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN die relevanten Plattformfunktionen (android.hardware.bluetooth bzw. android.hardware.bluetooth_le) deklarieren und die Plattform-APIs implementieren.
• Es SOLLTEN relevante Bluetooth-Profile wie A2DP, AVCP, OBEX usw. implementiert werden, je nach Gerät.

Wenn Geräteimplementierungen Unterstützung für Bluetooth Low Energy enthalten, gilt Folgendes:

• [C-3-1] MÜSSEN die Hardwarefunktion android.hardware.bluetooth_le deklarieren.
• [C-3-2] MÜSSEN die GATT-basierten (Generic Attribute Profile) Bluetooth-APIs wie in der SDK-Dokumentation und unter android.bluetooth beschrieben aktiviert werden.
• [C-3-3] MUSS den richtigen Wert für BluetoothAdapter.isOffloadedFilteringSupported() melden, um anzugeben, ob die Filterlogik für die ScanFilter-API-Klassen implementiert ist.
• [C-3-4] Der korrekte Wert für BluetoothAdapter.isMultipleAdvertisementSupported() MUSS angegeben werden, um anzugeben, ob Low Energy Advertising unterstützt wird.
• Die Auslagerung der Filterlogik auf den Bluetooth-Chipsatz SOLLTE unterstützt werden, wenn die ScanFilter API implementiert wird.
• Sollte das Auslagern des Batch-Scans an den Bluetooth-Chipsatz unterstützen.

• Es SOLLTE die Anzeige mehrerer Werbebotschaften mit mindestens vier Slots unterstützt werden.

• [SR] Es wird DRINGEND EMPFOHLEN, ein Zeitlimit für die auflösbare private Adresse (Resolvable Private Address, RPA) von höchstens 15 Minuten zu implementieren und die Adresse nach Ablauf des Zeitlimits zu rotieren, um den Datenschutz der Nutzer zu gewährleisten.

7.4.4. Nahfeldkommunikation

Geräteimplementierungen:

• Sollte einen Transceiver und die zugehörige Hardware für die Nahfeldkommunikation (Near Field Communication, NFC) enthalten.
• [C-0-1] Die APIs android.nfc.NdefMessage und android.nfc.NdefRecord MÜSSEN implementiert werden, auch wenn sie keine Unterstützung für NFC enthalten oder die Funktion android.hardware.nfc deklariert wird, da die Klassen ein protokollunabhängiges Datenformat darstellen.

Wenn Geräteimplementierungen NFC-Hardware enthalten und diese für Drittanbieter-Apps verfügbar gemacht werden soll, gilt Folgendes:

• [C-1-1] MÜSSEN die android.hardware.nfc-Funktion über die android.content.pm.PackageManager.hasSystemFeature()-Methode melden.
• MUSS NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können:
• [C-1-2] MUSS über die folgenden NFC-Standards als NFC-Forum-Lesegerät/Schreibgerät (gemäß der technischen Spezifikation des NFC-Forums NFCForum-TS-DigitalProtocol-1.0) fungieren können:
• NfcA (ISO14443-3A)
• NfcB (ISO14443-3B)
• NfcF (JIS X 6319-4)
• IsoDep (ISO 14443-4)
• NFC Forum Tag Types 1, 2, 3, 4, 5 (definiert vom NFC-Forum)

• [SR] Es wird DRINGEND EMPFOHLEN, NDEF-Nachrichten und Rohdaten über die folgenden NFC-Standards lesen und schreiben zu können. Die NFC-Standards werden zwar als STRONGLY RECOMMENDED (DRINGEND EMPFOHLEN) angegeben, aber in der Kompatibilitätsdefinition für eine zukünftige Version sollen sie in MUST (ERFORDERLICH) geändert werden. Diese Standards sind in dieser Version optional, werden aber in zukünftigen Versionen erforderlich sein. Es wird dringend empfohlen, dass vorhandene und neue Geräte, auf denen diese Android-Version ausgeführt wird, diese Anforderungen jetzt erfüllen, damit sie auf zukünftige Plattformversionen aktualisiert werden können.

• [C-1-3] MUSS Daten über die folgenden Peer-to-Peer-Standards und ‑Protokolle übertragen und empfangen können:

• ISO 18092
• LLCP 1.2 (definiert vom NFC-Forum)
• SDP 1.0 (definiert vom NFC-Forum)
• NDEF Push Protocol
• SNEP 1.0 (definiert vom NFC-Forum)
• [C-1-4] MUSS Unterstützung für Android Beam enthalten und SOLLTE Android Beam standardmäßig aktivieren.
• [C-1-5] Das Gerät MUSS Daten über Android Beam senden und empfangen können, wenn Android Beam aktiviert ist oder ein anderer proprietärer NFC-P2P-Modus aktiviert ist.
• [C-1-6] Der SNEP-Standardserver MUSS implementiert werden. Gültige NDEF-Nachrichten, die vom Standard-SNEP-Server empfangen werden, MÜSSEN mithilfe des android.nfc.ACTION_NDEF_DISCOVERED-Intents an Anwendungen gesendet werden. Durch Deaktivieren von Android Beam in den Einstellungen darf das Senden eingehender NDEF-Nachrichten NICHT deaktiviert werden.
• [C-1-7] MUSS den android.settings.NFCSHARING_SETTINGS-Intent berücksichtigen, um die NFC-Freigabeeinstellungen anzuzeigen.
• [C-1-8] MUSS den NPP-Server implementieren. Nachrichten, die vom NPP-Server empfangen werden, MÜSSEN auf dieselbe Weise verarbeitet werden wie vom SNEP-Standardserver.
• [C-1-9] MUSS einen SNEP-Client implementieren und versuchen, ausgehende P2P-NDEF an den Standard-SNEP-Server zu senden, wenn Android Beam aktiviert ist. Wenn kein Standard-SNEP-Server gefunden wird, MUSS der Client versuchen, Daten an einen NPP-Server zu senden.
• [C-1-10] VORDERGRUNDAKTIVITÄTEN MÜSSEN es ermöglichen, die ausgehende P2P-NDEF-Nachricht mit android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback und android.nfc.NfcAdapter.enableForegroundNdefPush festzulegen.
• Es SOLLTE eine Geste oder Bestätigung auf dem Bildschirm, z. B. „Zum Übertragen berühren“, verwendet werden, bevor ausgehende P2P-NDEF-Nachrichten gesendet werden.
• [C-1-11] Das Gerät MUSS die Übergabe der NFC-Verbindung an Bluetooth unterstützen, wenn es das Bluetooth Object Push Profile unterstützt.
• [C-1-12] MUSS die Übergabe der Verbindung an Bluetooth bei Verwendung von android.nfc.NfcAdapter.setBeamPushUris unterstützen, indem die Spezifikationen „Connection Handover Version 1.2“ und „Bluetooth Secure Simple Pairing Using NFC Version 1.0“ des NFC-Forums implementiert werden. Bei einer solchen Implementierung MUSS der LLCP-Übergabedienst mit dem Dienstnamen „urn:nfc:sn:handover“ implementiert werden, um die Übergabeanfrage-/Auswahledatensätze über NFC auszutauschen, und es MUSS das Bluetooth Object Push Profile für die eigentliche Bluetooth-Datenübertragung verwendet werden. Aus Legacy-Gründen (um mit Android 4.1-Geräten kompatibel zu bleiben) SOLLTE die Implementierung weiterhin SNEP GET-Anfragen zum Austausch der Übergabeanfrage-/Auswahl-Einträge über NFC akzeptieren. Eine Implementierung selbst SOLLTE jedoch KEINE SNEP-GET-Anfragen zum Ausführen der Verbindungsübergabe senden.
• [C-1-13] MUSS im NFC-Erkennungsmodus alle unterstützten Technologien abfragen.
• Das Gerät SOLLTE sich im NFC-Erkennungsmodus befinden, wenn es aktiv ist, das Display eingeschaltet und der Sperrbildschirm entsperrt ist.
• Sollte den Barcode und die URL (falls codiert) von Thinfilm NFC Barcode-Produkten lesen können.

Hinweis: Öffentlich verfügbare Links sind für die oben genannten Spezifikationen von JIS, ISO und NFC Forum nicht verfügbar.

Android unterstützt den NFC-HCE-Modus (Host Card Emulation).

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz (für NfcA und/oder NfcB) enthalten und das Routing von Anwendungs-IDs (Application ID, AID) unterstützen, gilt Folgendes:

• [C-2-1] MÜSSEN die android.hardware.nfc.hce-Funktionskonstante melden.
• [C-2-2] MUSS die NFC HCE-APIs unterstützen, wie im Android SDK definiert.

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz für NfcF enthalten und die Funktion für Drittanbieteranwendungen implementieren, gilt Folgendes:

• [C-3-1] MÜSSEN die android.hardware.nfc.hcef-Funktionskonstante melden.
• [C-3-2] MUSS die NfcF Card Emulation APIs (NfcF-Kartenemulations-APIs) wie im Android SDK definiert implementieren.

Wenn Geräteimplementierungen die in diesem Abschnitt beschriebene allgemeine NFC-Unterstützung und die MIFARE-Technologien (MIFARE Classic, MIFARE Ultralight, NDEF on MIFARE Classic) in der Reader/Writer-Rolle unterstützen, gilt Folgendes:

• [C-4-1] MÜSSEN die entsprechenden Android-APIs implementieren, wie im Android-SDK dokumentiert.
• [C-4-2] MÜSSEN die Funktion com.nxp.mifare über die Methode android.content.pm.PackageManager.hasSystemFeature() melden. Hinweis: Dies ist keine Standardfunktion von Android und wird daher nicht als Konstante in der Klasse android.content.pm.PackageManager angezeigt.

7.4.5. Mindestanforderungen an die Netzwerkfähigkeit

Geräteimplementierungen:

• [C-0-1] MUSS Unterstützung für mindestens eine Form der Datenvernetzung enthalten. Geräteimplementierungen MÜSSEN mindestens einen Datenstandard mit einer Geschwindigkeit von mindestens 200 Kbit/s unterstützen. Beispiele für Technologien, die diese Anforderung erfüllen, sind EDGE, HSPA, EV-DO, 802.11g, Ethernet und Bluetooth PAN.
• [C-0-2] MUSS einen IPv6-Netzwerkstack enthalten und die IPv6-Kommunikation über die verwalteten APIs wie java.net.Socket und java.net.URLConnection sowie die nativen APIs wie AF_INET6-Sockets unterstützen.
• [C-0-3] MUSS IPv6 standardmäßig aktivieren.
• MUSS sicherstellen, dass die IPv6-Kommunikation genauso zuverlässig ist wie z. B. IPv4.
• [C-0-4] MÜSSEN die IPv6-Verbindung im Inaktivmodus aufrechterhalten.
• [C-0-5] Durch die Ratenbegrenzung darf das Gerät in keinem IPv6-kompatiblen Netzwerk, das RA-Gültigkeitsdauern von mindestens 180 Sekunden verwendet, die IPv6-Konnektivität verlieren.
• Sollte auch die Unterstützung für mindestens einen gängigen drahtlosen Datenstandard wie 802.11 (WLAN) umfassen, wenn ein physischer Netzwerkstandard wie Ethernet die primäre Datenverbindung ist.
• MAY implement more than one form of data connectivity.

Das erforderliche Maß an IPv6-Unterstützung hängt vom Netzwerktyp ab:

Wenn Geräteimplementierungen WLANs unterstützen, gilt Folgendes:

• [C-1-1] MUSS Dual-Stack- und Nur-IPv6-Betrieb über WLAN unterstützen.

Wenn Geräteimplementierungen Ethernet-Netzwerke unterstützen, gilt Folgendes:

• [C-2-1] MUSS Dual-Stack-Betrieb über Ethernet unterstützen.

Wenn Geräteimplementierungen Mobilfunkdaten unterstützen, gilt Folgendes:

• [C-3-1] MUSS gleichzeitig diese Anforderungen in jedem Netzwerk erfüllen, mit dem es verbunden ist, wenn ein Gerät gleichzeitig mit mehr als einem Netzwerk verbunden ist (z.B. WLAN und mobile Daten).
• Sollte den IPv6-Betrieb (nur IPv6 und möglicherweise Dual-Stack) über mobile Daten unterstützen.

7.4.6. Synchronisierungseinstellungen

Geräteimplementierungen:

• [C-0-1] Die automatische Hauptsynchronisierung MUSS standardmäßig aktiviert sein, damit die Methode getMasterSyncAutomatically() „true“ zurückgibt.

7.4.7. Datensparmodus

Wenn Geräteimplementierungen eine Verbindung mit beschränktem Datenvolumen enthalten, sind sie:

• [SR] Es wird DRINGEND EMPFOHLEN, den Datensparmodus bereitzustellen.

Wenn Geräteimplementierungen den Datensparmodus bieten, gilt Folgendes:

• [C-1-1] MUSS alle APIs in der Klasse ConnectivityManager unterstützen, wie in der SDK-Dokumentation beschrieben.
• [C-1-2] MUSS eine Benutzeroberfläche in den Einstellungen bereitstellen, die den Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS verarbeitet und es Nutzern ermöglicht, Anwendungen zur Zulassungsliste hinzuzufügen oder aus der Zulassungsliste zu entfernen.

Wenn Geräteimplementierungen den Datensparmodus nicht unterstützen, gilt Folgendes:

• [C-2-1] MUSS für ConnectivityManager.getRestrictBackgroundStatus() den Wert RESTRICT_BACKGROUND_STATUS_DISABLED zurückgeben.
• [C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED darf nicht übertragen werden.
• [C-2-3] MUSS eine Aktivität haben, die den Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS-Intent verarbeitet, KANN ihn aber als No-Op implementieren.

7.5. Kameras

Wenn Geräteimplementierungen mindestens eine Kamera enthalten, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag android.hardware.camera.any deklarieren.
• [C-1-2] Eine Anwendung MUSS gleichzeitig drei RGBA_8888-Bitmaps in der Größe der Bilder zuweisen können, die vom Kamerasensor mit der höchsten Auflösung auf dem Gerät erzeugt werden, während die Kamera zum Zweck der grundlegenden Vorschau und Aufnahme geöffnet ist.

7.5.1. Rückkamera

Eine nach hinten gerichtete Kamera befindet sich auf der Seite des Geräts, die dem Display gegenüberliegt. Sie nimmt Bilder von Szenen auf der gegenüberliegenden Seite des Geräts auf, wie eine herkömmliche Kamera.

Geräteimplementierungen:

• MUSS eine nach hinten gerichtete Kamera haben.

Wenn Geräteimplementierungen mindestens eine nach hinten gerichtete Kamera enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN die Funktions-Flags android.hardware.camera und android.hardware.camera.any melden.
• [C-1-2] MUSS eine Auflösung von mindestens 2 Megapixeln haben.
• Sollte entweder Hardware-Autofokus oder Software-Autofokus im Kameratreiber implementiert haben (transparent für Anwendungssoftware).
• MAY have fixed-focus or EDOF (extended depth of field) hardware.
• KANN einen Blitz enthalten.

Wenn die Kamera einen Blitz hat:

• [C-2-1] Die Blitzlampe darf nicht leuchten, wenn eine android.hardware.Camera.PreviewCallback-Instanz auf einer Kamera-Vorschauoberfläche registriert wurde, es sei denn, die Anwendung hat den Blitz explizit durch Aktivieren der Attribute FLASH_MODE_AUTO oder FLASH_MODE_ON eines Camera.Parameters-Objekts aktiviert. Diese Einschränkung gilt nicht für die integrierte Systemkamera-App des Geräts, sondern nur für Drittanbieter-Apps, die Camera.PreviewCallback verwenden.

7.5.2. Frontkamera

Eine Frontkamera befindet sich auf derselben Seite des Geräts wie das Display. Sie wird in der Regel verwendet, um den Nutzer zu filmen, z. B. für Videokonferenzen und ähnliche Anwendungen.

Geräteimplementierungen:

• MAY include a front-facing camera

Wenn Geräteimplementierungen mindestens eine nach vorn gerichtete Kamera enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN die Funktions-Flags android.hardware.camera.any und android.hardware.camera.front melden.
• [C-1-2] MUSS eine Auflösung von mindestens VGA (640 × 480 Pixel) haben.
• [C-1-3] Eine Frontkamera darf NICHT als Standard für die Camera API verwendet werden und die API darf NICHT so konfiguriert werden, dass eine Frontkamera als Standard-Rückkamera behandelt wird, auch wenn sie die einzige Kamera auf dem Gerät ist.
• [C-1-5] Die Kameravorschau MUSS horizontal gespiegelt werden, wenn die aktuelle Anwendung explizit angefordert hat, dass die Kameraanzeige durch einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() gedreht wird. Umgekehrt MUSS die Vorschau entlang der standardmäßigen horizontalen Achse des Geräts gespiegelt werden, wenn die aktuelle Anwendung nicht explizit anfordert, dass die Kameraanzeige durch einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() gedreht wird.
• [C-1-6] Das endgültige aufgenommene Standbild oder die an Anwendungs-Callbacks zurückgegebenen oder im Medienspeicher gespeicherten Videostreams dürfen NICHT gespiegelt werden.
• [C-1-7] MUSS das von der Postview angezeigte Bild auf dieselbe Weise spiegeln wie den Kameravorschaubildstream.
• KANN Funktionen (z. B. Autofokus, Blitz usw.) enthalten, die für nach hinten gerichtete Kameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.

Wenn Geräteimplementierungen vom Nutzer gedreht werden können (z. B. automatisch über einen Beschleunigungsmesser oder manuell über die Eingabe des Nutzers):

• [C-2-1] Die Kameravorschau MUSS horizontal gespiegelt werden, bezogen auf die aktuelle Ausrichtung des Geräts.

7.5.3. Externe Kamera

Geräteimplementierungen:

• MÖGLICHERWEISE wird eine externe Kamera unterstützt, die nicht unbedingt immer verbunden ist.

Wenn Geräteimplementierungen Unterstützung für eine externe Kamera enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN die Plattform-Funktions-Flags android.hardware.camera.external und android.hardware camera.any deklarieren.
• [C-1-2] MUSS USB Video Class (UVC 1.0 oder höher) unterstützen, wenn die externe Kamera über den USB-Anschluss verbunden wird.
• Sollte Videokomprimierungen wie MJPEG unterstützen, um die Übertragung von uncodierten Streams in hoher Qualität (d.h. Roh- oder unabhängig komprimierte Bildstreams) zu ermöglichen.
• MAY unterstützt möglicherweise mehrere Kameras.
• MAY support camera-based video encoding. Falls unterstützt, MUSS ein gleichzeitiger uncodierter / MJPEG-Stream (QVGA oder höhere Auflösung) für die Geräteimplementierung zugänglich sein.

7.5.4. Verhalten der Camera API

Android umfasst zwei API-Pakete für den Zugriff auf die Kamera. Die neuere android.hardware.camera2-API bietet der App eine Kamera-Steuerung auf niedrigerer Ebene, einschließlich effizienter Burst-/Streaming-Abläufe ohne Kopieren und Steuerung von Belichtung, Verstärkung, Weißabgleich, Farbkonvertierung, Rauschunterdrückung und Schärfen pro Frame.

Das ältere API-Paket android.hardware.Camera ist in Android 5.0 als veraltet markiert, sollte aber weiterhin für Apps verfügbar sein. Android-Geräteimplementierungen MÜSSEN die fortlaufende Unterstützung der API gewährleisten, wie in diesem Abschnitt und im Android SDK beschrieben.

Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs für alle verfügbaren Kameras implementieren. Geräteimplementierungen:

• [C-0-1] android.hardware.PixelFormat.YCbCr_420_SP MUSS für Vorschau-Daten verwendet werden, die für Anwendungs-Callbacks bereitgestellt werden, wenn eine Anwendung noch nie android.hardware.Camera.Parameters.setPreviewFormat(int) aufgerufen hat.
• [C-0-2] MUSS außerdem im NV21-Codierungsformat vorliegen, wenn eine Anwendung eine android.hardware.Camera.PreviewCallback-Instanz registriert und das System die Methode onPreviewFrame() aufruft und das Vorschauformat YCbCr_420_SP ist. Die Daten im Byte[] werden an onPreviewFrame() übergeben. NV21 MUSS der Standard sein.
• [C-0-3] MUSS das YV12-Format (angegeben durch die Konstante android.graphics.ImageFormat.YV12) für Kameravorschauen für Front- und Rückkameras für android.hardware.Camera unterstützen. (Der Hardware-Video-Encoder und die Kamera können ein beliebiges natives Pixelformat verwenden, die Geräteimplementierung MUSS jedoch die Konvertierung in YV12 unterstützen.)
• [C-0-4] MÜSSEN die Formate android.hardware.ImageFormat.YUV_420_888 und android.hardware.ImageFormat.JPEG als Ausgaben über die android.media.ImageReader API für android.hardware.camera2-Geräte unterstützen, die die Funktion REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities bewerben.
• [C-0-5] Die vollständige Camera API, die in der Android SDK-Dokumentation enthalten ist, MUSS weiterhin implementiert werden, unabhängig davon, ob das Gerät einen Hardware-Autofokus oder andere Funktionen bietet. Kameras ohne Autofokus MÜSSEN beispielsweise trotzdem alle registrierten android.hardware.Camera.AutoFocusCallback-Instanzen aufrufen, auch wenn dies für eine Kamera ohne Autofokus keine Relevanz hat. Das gilt auch für Frontkameras. Auch wenn die meisten Frontkameras keinen Autofokus unterstützen, müssen die API-Rückrufe wie beschrieben „gefälscht“ werden.
• [C-0-6] MUSS jeden Parameternamen erkennen und berücksichtigen, der als Konstante in der Klasse android.hardware.Camera.Parameters definiert ist. Umgekehrt DÜRFEN Geräteimplementierungen keine Stringkonstanten berücksichtigen oder erkennen, die an die android.hardware.Camera.setParameters()-Methode übergeben werden, mit Ausnahme der Konstanten, die in der android.hardware.Camera.Parameters dokumentiert sind. Das bedeutet, dass Geräteimplementierungen alle Standard-Kameraparameter unterstützen MÜSSEN, sofern die Hardware dies zulässt, und KEINE benutzerdefinierten Kameraparametertypen unterstützen DÜRFEN. Geräteimplementierungen, die die Aufnahme von Bildern mit HDR-Bildgebungstechniken (High Dynamic Range) unterstützen, MÜSSEN beispielsweise den Kameraparameter Camera.SCENE_MODE_HDR unterstützen.
• [C-0-7] MUSS das richtige Unterstützungsniveau mit dem Attribut android.info.supportedHardwareLevel wie im Android SDK beschrieben melden und die entsprechenden Framework-Funktions-Flags melden.
• [C-0-8] MUSS auch die einzelnen Kamerafunktionen von android.hardware.camera2 über die android.request.availableCapabilities-Property deklarieren und die entsprechenden Funktions-Flags deklarieren. Das Funktions-Flag MUSS definiert werden, wenn eines der angehängten Kamerageräte die Funktion unterstützt.
• [C-0-9] MUSS den Intent Camera.ACTION_NEW_PICTURE senden, wenn ein neues Bild mit der Kamera aufgenommen und der Eintrag des Bildes dem Medienspeicher hinzugefügt wurde.
• [C-0-10] MUSS den Intent Camera.ACTION_NEW_VIDEO übertragen, wenn ein neues Video von der Kamera aufgenommen und der Eintrag des Bildes dem Media Store hinzugefügt wurde.

7.5.5. Kameraausrichtung

Wenn Geräteimplementierungen eine Front- oder Rückkamera haben, müssen diese Kameras:

• [C-1-1] MUSS so ausgerichtet sein, dass die lange Seite der Kamera mit der langen Seite des Bildschirms übereinstimmt. Wenn das Gerät im Querformat gehalten wird, MÜSSEN die Kameras Bilder im Querformat aufnehmen. Dies gilt unabhängig von der natürlichen Ausrichtung des Geräts, also sowohl für Geräte, die hauptsächlich im Querformat verwendet werden, als auch für Geräte, die hauptsächlich im Hochformat verwendet werden.

7.6. Arbeitsspeicher und Datenspeicher

7.6.1. Mindestspeicher und ‑arbeitsspeicher

Geräteimplementierungen:

• [C-0-1] MUSS einen Download-Manager enthalten, über den Anwendungen Datendateien herunterladen können. Außerdem MÜSSEN einzelne Dateien mit einer Größe von mindestens 100 MB an den Standard-Cache-Speicherort heruntergeladen werden können.

7.6.2. Shared Storage für Anwendungen

Geräteimplementierungen:

• [C-0-1] MUSS Speicher anbieten, der von Anwendungen gemeinsam genutzt werden kann. Dieser wird auch als „freigegebener externer Speicher“, „von Anwendungen gemeinsam genutzter Speicher“ oder als der Linux-Pfad „/sdcard“ bezeichnet, auf dem er bereitgestellt wird.
• [C-0-2] MUSS standardmäßig mit eingebundenem gemeinsam genutzten Speicher konfiguriert sein, d. h. „out of the box“, unabhängig davon, ob der Speicher auf einer internen Speicherkomponente oder einem Wechseldatenträger (z. B. SD-Kartensteckplatz) implementiert ist.
• [C-0-3] Der freigegebene Speicher der Anwendung MUSS direkt auf dem Linux-Pfad sdcard gemountet werden oder einen symbolischen Linux-Link von sdcard zum tatsächlichen Mount-Punkt enthalten.
• [C-0-4] MUSS die Berechtigung android.permission.WRITE_EXTERNAL_STORAGE für diesen freigegebenen Speicher gemäß der SDK-Dokumentation erzwingen. Der freigegebene Speicherplatz MUSS ansonsten von jeder Anwendung, die diese Berechtigung erhält, beschreibbar sein.

Geräteimplementierungen KÖNNEN die oben genannten Anforderungen erfüllen, indem sie entweder:

• ein vom Nutzer zugänglicher Wechselspeicher, z. B. ein SD-Kartensteckplatz (Secure Digital).
• ein Teil des internen (nicht entfernbaren) Speichers, wie im Open-Source-Projekt für Android (AOSP) implementiert.

Wenn Geräteimplementierungen Wechselspeicher verwenden, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

• [C-1-1] MUSS eine Toast- oder Pop-up-Benutzeroberfläche implementieren, die den Nutzer warnt, wenn kein Speichermedium in den Steckplatz eingesetzt ist.
• [C-1-2] MUSS ein FAT-formatiertes Speichermedium (z.B. eine SD-Karte) enthalten oder auf der Verpackung und anderem zum Zeitpunkt des Kaufs verfügbaren Material muss angegeben sein, dass das Speichermedium separat erworben werden muss.

Wenn Geräteimplementierungen einen Teil des nicht entfernbaren Speichers verwenden, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

• Sollte die AOSP-Implementierung des freigegebenen internen Anwendungsspeichers verwenden.
• MAY share the storage space with the application private data.

Wenn Geräteimplementierungen mehrere Pfade für den gemeinsamen Speicher enthalten (z. B. sowohl einen SD-Kartensteckplatz als auch einen gemeinsamen internen Speicher), gilt Folgendes:

• [C-3-1] Es MUSS nur vorinstallierten und privilegierten Android-Anwendungen mit der Berechtigung WRITE_EXTERNAL_STORAGE erlaubt sein, auf den sekundären externen Speicher zu schreiben, außer wenn in ihre paketbezogenen Verzeichnisse oder in den URI geschrieben wird, der durch das Auslösen des Intents ACTION_OPEN_DOCUMENT_TREE zurückgegeben wird.

Wenn Geräteimplementierungen einen USB-Anschluss mit Unterstützung für den USB-Peripheriemodus haben, gilt Folgendes:

• [C-3-1] MUSS ein Verfahren zum Zugriff auf die Daten im freigegebenen Speicher der Anwendung von einem Hostcomputer aus bereitstellen.
• Sollte Inhalte aus beiden Speicherpfaden transparent über den Media Scanner-Dienst von Android und android.provider.MediaStore verfügbar machen.
• MAY use USB mass storage, but SHOULD use Media Transfer Protocol to satisfy this requirement.

Wenn Geräteimplementierungen einen USB-Anschluss mit USB-Peripheriemodus haben und das Media Transfer Protocol unterstützen, gilt Folgendes:

• Sollte mit dem Referenz-Android-MTP-Host Android File Transfer kompatibel sein.
• Sollte die USB-Geräteklasse 0x00 melden.
• Sollte den USB-Schnittstellennamen „MTP“ melden.

7.6.3. Verwendbarer Speicher

Wenn das Gerät voraussichtlich mobil ist, im Gegensatz zu einem Fernseher, sind die Geräteimplementierungen:

• [SR] Es wird DRINGEND EMPFOHLEN, den adoptable Speicher an einem langfristig stabilen Ort zu implementieren, da ein versehentliches Trennen zu Datenverlust oder ‑beschädigung führen kann.

Wenn sich der Anschluss für das Wechselspeichergerät an einem langfristig stabilen Ort befindet, z. B. im Akkufach oder in einer anderen Schutzabdeckung, sind die Geräteimplementierungen:

• [SR] Es wird DRINGEND EMPFOHLEN, adoptable storage zu implementieren.

7.7. USB

Wenn Geräteimplementierungen einen USB-Anschluss haben, gilt Folgendes:

• SOLLTE den USB-Peripheriemodus und den USB-Hostmodus unterstützen.

7.7.1. USB-Peripheriemodus

Wenn Geräteimplementierungen einen USB-Anschluss enthalten, der den Peripheriemodus unterstützt:

• [C-1-1] Der Port MUSS mit einem USB-Host verbunden werden können, der einen Standard-USB-Port vom Typ A oder Typ C hat.
• [C-1-2] MUSS den korrekten Wert von iSerialNumber im USB-Standardgerätedeskriptor über android.os.Build.SERIAL melden.
• [C-1-3] MUSS Ladegeräte mit 1,5 A und 3,0 A gemäß dem Typ-C-Widerstandsstandard erkennen und MUSS Änderungen in der Ankündigung erkennen, wenn sie Typ-C-USB unterstützen.
• [SR] Der Port SOLLTE den USB-Formfaktor Micro-B, Micro-AB oder Typ C verwenden. Für bestehende und neue Android-Geräte WIRD DRINGEND EMPFOHLEN, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen aktualisiert werden können.
• [SR] Der Anschluss SOLLTE sich unten am Gerät befinden (entsprechend der natürlichen Ausrichtung) oder die Software-Bildschirmdrehung für alle Apps (einschließlich des Startbildschirms) ermöglichen, damit das Display korrekt dargestellt wird, wenn das Gerät mit dem Anschluss unten ausgerichtet ist. Für bestehende und neue Android-Geräte WIRD DRINGEND EMPFOHLEN, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen aktualisiert werden können.
• [SR] Das Gerät SOLLTE die Möglichkeit bieten, während des HS-Chirps und des Datenverkehrs einen Strom von 1,5 A zu ziehen, wie in der USB Battery Charging Specification, Revision 1.2 beschrieben. Für bestehende und neue Android-Geräte WIRD DRINGEND EMPFOHLEN, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen aktualisiert werden können.
• [SR] Es wird DRINGEND EMPFOHLEN, keine proprietären Lademethoden zu unterstützen, bei denen die Vbus-Spannung über die Standardwerte hinaus geändert oder die Sink-/Source-Rollen geändert werden, da dies zu Interoperabilitätsproblemen mit Ladegeräten oder Geräten führen kann, die die standardmäßigen USB Power Delivery-Methoden unterstützen. Auch wenn dies als „DRINGEND EMPFOHLEN“ gekennzeichnet ist, kann es sein, dass wir in zukünftigen Android-Versionen vorschreiben, dass alle Typ‑C-Geräte die vollständige Interoperabilität mit Standard-Typ‑C-Ladegeräten unterstützen müssen.
• [SR] Es wird DRINGEND EMPFOHLEN, Power Delivery für den Rollentausch von Daten und Strom zu unterstützen, wenn sie USB‑Typ‑C und den USB‑Hostmodus unterstützen.
• Sollte Power Delivery für das Laden mit hoher Spannung und alternative Modi wie die Bildschirmausgabe unterstützen.
• Sollte die Android Open Accessory (AOA) API und Spezifikation wie in der Android SDK-Dokumentation beschrieben implementieren.

Wenn Geräteimplementierungen einen USB-Anschluss enthalten und die AOA-Spezifikation implementieren,

• [C-2-1] MÜSSEN die Unterstützung für die Hardwarefunktion android.hardware.usb.accessory deklarieren.
• [C-2-2] Die USB-Massenspeicherklasse MUSS den String „android“ am Ende des Strings iInterface der Schnittstellenbeschreibung des USB-Massenspeichers enthalten.

7.7.2. USB-Hostmodus

Wenn Geräteimplementierungen einen USB-Anschluss enthalten, der den Hostmodus unterstützt, gilt Folgendes:

• [C-1-1] MUSS die Android-USB-Host-API implementieren, wie im Android SDK dokumentiert, und MUSS die Unterstützung für die Hardwarefunktion android.hardware.usb.host deklarieren.
• [C-1-2] MUSS die Unterstützung für den Anschluss von Standard-USB-Peripheriegeräten implementieren, d. h., es MUSS entweder:
  • Ein Typ-C-Anschluss am Gerät oder ein Kabel, das einen proprietären Anschluss am Gerät an einen standardmäßigen USB‑Typ‑C-Anschluss anpasst (USB‑Typ‑C-Gerät).
  • Sie haben einen Typ A-Anschluss oder werden mit einem Kabel geliefert, das einen proprietären Anschluss des Geräts in einen Standard-USB-Typ A-Anschluss umwandelt.
  • Ein Micro-AB-Port auf dem Gerät, der mit einem Kabel geliefert werden SOLLTE, das an einen Standard-Typ-A-Port angepasst ist.
• [C-1-3] Das Gerät darf nicht mit einem Adapter ausgeliefert werden, der USB‑Typ‑A- oder Micro‑AB-Ports in einen Typ‑C-Port (Buchse) umwandelt.
• [SR] Es wird DRINGEND EMPFOHLEN, die USB-Audioklasse zu implementieren, wie in der Android SDK-Dokumentation beschrieben.
• Das angeschlossene USB-Peripheriegerät sollte im Hostmodus aufgeladen werden können.Dazu muss ein Quellstrom von mindestens 1,5 A gemäß dem Abschnitt „Termination Parameters“ der USB Type-C Cable and Connector Specification Revision 1.2 für USB-Typ-C-Anschlüsse beworben werden oder der Ausgangsstrombereich des Charging Downstream Port(CDP) gemäß den USB Battery Charging specifications, revision 1.2 für Micro-AB-Anschlüsse verwendet werden.
• Sollte USB Typ-C-Standards implementieren und unterstützen.

Wenn Geräteimplementierungen einen USB-Anschluss enthalten, der den Hostmodus und die USB-Audioklasse unterstützt, gilt Folgendes:

• [C-2-1] MUSS die USB HID-Klasse unterstützen.
• [C-2-2] MUSS die Erkennung und Zuordnung der folgenden HID-Datenfelder, die in den USB HID Usage Tables und der Voice Command Usage Request angegeben sind, zu den KeyEvent-Konstanten wie unten unterstützen:
  • Verwendungsseite (0xC) – Verwendungs-ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Verwendungsseite (0xC) – Verwendungs-ID (0x0E9): KEYCODE_VOLUME_UP
  • Verwendungsseite (0xC) Verwendungs-ID (0x0EA): KEYCODE_VOLUME_DOWN
  • Usage Page (0xC) Usage ID (0x0CF): KEYCODE_VOICE_ASSIST

Wenn Geräteimplementierungen einen USB-Anschluss enthalten, der den Hostmodus und das Storage Access Framework (SAF) unterstützt, gilt Folgendes:

• [C-3-1] MUSS alle per Remote-Verbindung verbundenen MTP-Geräte (Media Transfer Protocol) erkennen und ihre Inhalte über die Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT und ACTION_CREATE_DOCUMENT zugänglich machen. .

Wenn Geräteimplementierungen einen USB-Port enthalten, der den Hostmodus und USB Typ C unterstützt, gilt Folgendes:

• [C-4-1] MUSS die Dual Role Port-Funktionalität gemäß der USB Typ-C-Spezifikation (Abschnitt 4.5.1.3.3) implementieren.
• [SR] Es wird DRINGEND EMPFOHLEN, DisplayPort zu unterstützen. Es SOLLTEN USB‑SuperSpeed-Datenraten unterstützt werden und es wird DRINGEND EMPFOHLEN, Power Delivery für das Tauschen von Daten- und Stromversorgungsrollen zu unterstützen.
• [SR] Es wird DRINGEND EMPFOHLEN, den Zubehör-Modus für Audioadapter NICHT zu unterstützen, wie in Anhang A der USB Typ‑C-Kabel- und ‑Anschluss-Spezifikation Revision 1.2 beschrieben.
• Es SOLLTE das Try.*-Modell implementiert werden, das am besten für den Geräteformfaktor geeignet ist. Ein tragbares Gerät SOLLTE beispielsweise das Try.SNK-Modell implementieren.

7.8. Audio

7.8.1. Mikrofon

Wenn Geräteimplementierungen ein Mikrofon enthalten, müssen sie folgende Anforderungen erfüllen:

• [C-1-1] MÜSSEN die android.hardware.microphone-Funktionskonstante melden.
• [C-1-2] MUSS den Anforderungen für Audioaufnahmen in Abschnitt 5.4 entsprechen.
• [C-1-3] MUSS die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
• [SR] Es wird DRINGEND EMPFOHLEN, die Aufzeichnung von Nah-Ultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen.

Wenn in Geräteimplementierungen kein Mikrofon vorhanden ist, gilt Folgendes:

• [C-2-1] DÜRFEN die android.hardware.microphone-Funktionskonstante NICHT melden.
• [C-2-2] MUSS die Audioaufzeichnungs-API mindestens als No-Op-Vorgänge gemäß Abschnitt 7 implementieren.

7.8.2. Audioausgabe

Wenn Geräteimplementierungen einen Lautsprecher oder einen Audio-/Multimedia-Ausgangsanschluss für ein Audioausgabe-Peripheriegerät wie eine 3,5-mm-Audiobuchse mit 4 Leitern oder einen USB-Hostmodus-Anschluss mit USB-Audioklasse enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN die android.hardware.audio.output-Funktionskonstante melden.
• [C-1-2] MUSS die Anforderungen an die Audiowiedergabe in Abschnitt 5.5 erfüllen.
• [C-1-3] MUSS die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
• [SR] Es wird DRINGEND EMPFOHLEN, die Wiedergabe von Nah-Ultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen.

Wenn Geräteimplementierungen keinen Lautsprecher oder Audioausgangsport enthalten, gilt Folgendes:

• [C-2-1] DÜRFEN die android.hardware.audio.output-Funktion NICHT melden.
• [C-2-2] Die APIs für die Audioausgabe MÜSSEN zumindest als No-Ops implementiert werden.

Im Sinne dieses Abschnitts ist ein „Ausgangsport“ eine physische Schnittstelle wie ein 3,5‑mm-Audioanschluss, HDMI oder ein USB-Hostmodus-Port mit USB-Audioklasse. Die Unterstützung der Audioausgabe über funkbasierte Protokolle wie Bluetooth, WLAN oder Mobilfunknetz gilt nicht als „Ausgangsanschluss“.

7.8.2.1. Analoge Audioanschlüsse

Damit ein Gerät mit Headsets und anderem Audiozubehör kompatibel ist, die den 3,5-mm-Audioanschluss im gesamten Android-Ökosystem verwenden, SOLLTE mindestens einer der Audioanschlüsse ein 3,5-mm-Audioanschluss mit 4 Leitern sein, wenn eine Geräteimplementierung einen oder mehrere analoge Audioanschlüsse enthält.

Wenn Geräteimplementierungen eine 3,5‑mm-Audiobuchse mit 4 Leitern haben, gilt Folgendes:

• [C-1-1] MUSS die Audiowiedergabe über Stereo-Kopfhörer und Stereo-Headsets mit Mikrofon unterstützen.
• [C-1-2] MÜSSEN TRRS-Audiostecker mit der CTIA-Pinbelegung unterstützen.
• [C-1-3] MÜSSEN die Erkennung und Zuordnung zu den Tastencodes für die folgenden drei Bereiche der äquivalenten Impedanz zwischen dem Mikrofon und den Masseleitern am Audio-Stecker unterstützen:
  • 70 Ohm oder weniger: KEYCODE_HEADSETHOOK
  • 210–290 Ohm: KEYCODE_VOLUME_UP
  • 360–680 Ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] MUSS ACTION_HEADSET_PLUG auslösen, wenn ein Stecker eingesteckt wird, aber erst, nachdem alle Kontakte des Steckers die entsprechenden Segmente der Buchse berühren.
• [C-1-5] MUSS bei einer Lautsprecherimpedanz von 32 Ohm mindestens 150 mV ± 10% der Ausgangsspannung liefern können.
• [C-1-6] MUSS eine Mikrofonvorspannung zwischen 1,8 V und 2,9 V haben.
• [SR] Es wird DRINGEND EMPFOHLEN, den Tastencode für den folgenden Bereich des entsprechenden Widerstands zwischen dem Mikrofon und den Masseleitern am Audio-Stecker zu erkennen und zuzuordnen:
  • 110–180 Ohm:KEYCODE_VOICE_ASSIST
• Sollte Audio-Stecker mit der OMTP-Pinbelegung unterstützen.
• Sollte die Audioaufnahme von Stereo-Headsets mit Mikrofon unterstützen.

Wenn Geräteimplementierungen einen 3, 5‑mm-Audioanschluss mit 4 Leitern haben und ein Mikrofon unterstützen und android.intent.action.HEADSET_PLUG mit dem zusätzlichen Wert „Mikrofon“ auf 1 gesetzt übertragen, gilt Folgendes:

• [C-2-1] MUSS die Erkennung des Mikrofons am angeschlossenen Audiozubehör unterstützen.

7.8.3. Nahe am Ultraschallbereich

Audio im Grenzbereich zum Ultraschall liegt im Bereich von 18,5 kHz bis 20 kHz.

Geräteimplementierungen:

• MUSS die Unterstützung der Near-Ultrasound-Audiofunktion über die AudioManager.getProperty API korrekt melden:

Wenn PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND „true“ ist, MÜSSEN die Audioquellen VOICE_RECOGNITION und UNPROCESSED die folgenden Anforderungen erfüllen:

• [C-1-1] Die mittlere Leistungsreaktion des Mikrofons im Bereich von 18,5 kHz bis 20 kHz DARF nicht mehr als 15 dB unter der Reaktion bei 2 kHz liegen.
• [C-1-2] Das ungewichtete Signal-Rausch-Verhältnis des Mikrofons über 18,5 kHz bis 20 kHz für einen 19‑kHz-Ton bei -26 dBFS MUSS mindestens 50 dB betragen.

Wenn PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND „true“ ist:

• [C-2-1] Die mittlere Reaktion des Lautsprechers im Bereich von 18,5 kHz bis 20 kHz DARF nicht niedriger als 40 dB unter der Reaktion bei 2 kHz sein.

7.9. Virtual Reality

Android bietet APIs und Funktionen zum Erstellen von Virtual Reality-Anwendungen (VR), einschließlich hochwertiger mobiler VR-Erlebnisse. Geräteimplementierungen MÜSSEN diese APIs und Verhaltensweisen wie in diesem Abschnitt beschrieben ordnungsgemäß implementieren.

7.9.1. Virtual Reality-Modus

Android unterstützt den VR-Modus. Diese Funktion übernimmt das stereoskopische Rendern von Benachrichtigungen und deaktiviert monokulare System-UI-Komponenten, während eine VR-Anwendung den Fokus des Nutzers hat.

7.9.2. Virtual Reality High Performance

Wenn Geräteimplementierungen die Unterstützung von leistungsstarker VR für längere Nutzungszeiten über das Feature-Flag android.hardware.vr.high_performance identifizieren, gilt Folgendes:

• [C-1-1] MUSS mindestens 2 physische Kerne haben.
• [C-1-2] MÜSSEN android.software.vr.mode feature deklarieren.
• [C-1-3] MUSS den Modus für nachhaltige Leistung unterstützen.
• [C-1-4] MUSS OpenGL ES 3.2 unterstützen.
• [C-1-5] MÜSSEN Vulkan Hardware Level 0 unterstützen und SOLLTEN Vulkan Hardware Level 1 unterstützen.
• [C-1-6] MUSS EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content implementieren und die Erweiterungen in der Liste der verfügbaren EGL-Erweiterungen verfügbar machen.
• [C-1-7] Die GPU und das Display MÜSSEN den Zugriff auf den gemeinsamen Front-Buffer so synchronisieren können, dass die abwechselnde Darstellung von VR-Inhalten für das linke und rechte Auge mit 60 fps mit zwei Renderkontexten ohne sichtbare Tearing-Artefakte erfolgt.
• [C-1-8] MUSS GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures, GL_EXT_EGL_image_array und GL_EXT_external_buffer implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen verfügbar machen.
• [C-1-9] MÜSSEN die Unterstützung für die AHardwareBuffer-Flags AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER und AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA implementieren, wie im NDK beschrieben.
• [C-1-10] MUSS die Unterstützung für AHardwareBuffers mit mehr als einer Ebene implementieren.
• [C-1-11] MUSS die H.264-Decodierung mit mindestens 3840 × 2160 bei 30 fps und 40 Mbit/s unterstützen (entspricht 4 Instanzen von 1920 × 1080 bei 30 fps und 10 Mbit/s oder 2 Instanzen von 1920 × 1080 bei 60 fps und 20 Mbit/s).
• [C-1-12] MUSS HEVC und VP9 unterstützen, MUSS mindestens 1920 × 1080 bei 30 fps und 10 Mbit/s decodieren können und SOLLTE 3840 × 2160 bei 30 fps und 20 Mbit/s decodieren können (entspricht 4 Instanzen von 1920 × 1080 bei 30 fps und 5 Mbit/s).
• [C-1-13] MUSS die HardwarePropertiesManager.getDeviceTemperatures API unterstützen und genaue Werte für die Hauttemperatur zurückgeben.
• [C-1-14] MUSS einen eingebetteten Bildschirm haben. Die Auflösung MUSS mindestens Full-HD(1080p) betragen und SOLLTE Quad-HD (1440p) oder höher sein.
• [C-1-15] Das Display MUSS im VR-Modus mit mindestens 60 Hz aktualisiert werden.
• [C-1-16] Die Displaylatenz (gemessen an der Schaltzeit von Grau zu Grau, Weiß zu Schwarz und Schwarz zu Weiß) MUSS ≤ 6 Millisekunden betragen.
• [C-1-17] Das Display MUSS einen Modus mit geringer Persistenz mit einer Persistenz von ≤ 5 Millisekunden unterstützen. Die Persistenz wird als die Zeit definiert, in der ein Pixel Licht emittiert.
• [C-1-18] MÜSSEN Bluetooth 4.2 und die Bluetooth LE Data Length Extension Abschnitt 7.4.3 unterstützen.
• [C-1-19] MUSS den Direct Channel Type für alle folgenden Standardsensortypen unterstützen und korrekt melden:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-1-20] MUSS den direkten Channeltyp TYPE_HARDWARE_BUFFER für alle oben aufgeführten direkten Channeltypen unterstützen.
• [SR] Es wird DRINGEND EMPFOHLEN, die android.hardware.sensor.hifi_sensors-Funktion zu unterstützen. Außerdem MÜSSEN die Anforderungen an Gyroskop, Beschleunigungsmesser und Magnetometer für android.hardware.hifi_sensors erfüllt werden.
• MAY kann einen exklusiven Kern für die Vordergrundanwendung bereitstellen und MAY kann die Process.getExclusiveCores API unterstützen, um die Anzahl der CPU-Kerne zurückzugeben, die exklusiv für die oberste Vordergrundanwendung sind. Wenn ein exklusiver Core unterstützt wird, DÜRFEN auf diesem Core keine anderen Userspace-Prozesse ausgeführt werden (mit Ausnahme von Gerätetreibern, die von der Anwendung verwendet werden). Es DÜRFEN jedoch einige Kernelprozesse ausgeführt werden, sofern dies erforderlich ist.

8. Leistung und Energie

Einige Mindestkriterien für Leistung und Stromverbrauch sind für die Nutzerfreundlichkeit entscheidend und wirken sich auf die grundlegenden Annahmen aus, die Entwickler bei der Entwicklung einer App treffen.

8.1. Konsistenz der Nutzererfahrung

Eine reibungslose Benutzeroberfläche kann für den Endnutzer bereitgestellt werden, wenn bestimmte Mindestanforderungen erfüllt sind, um eine konsistente Framerate und Reaktionszeiten für Anwendungen und Spiele zu gewährleisten. Je nach Gerätetyp KÖNNEN Geräteimplementierungen messbare Anforderungen an die Latenz der Benutzeroberfläche und den Aufgabenwechsel haben, wie in Abschnitt 2 beschrieben.

8.2. Leistung beim Zugriff auf Datei-E/A

Eine gemeinsame Baseline für eine konsistente Dateizugriffsleistung im privaten Datenspeicher der Anwendung (/data-Partition) ermöglicht es App-Entwicklern, eine angemessene Erwartung zu formulieren, die ihnen bei der Softwareentwicklung hilft. Je nach Gerätetyp KÖNNEN Geräteimplementierungen bestimmte Anforderungen haben, die in Abschnitt 2 für die folgenden Lese- und Schreibvorgänge beschrieben werden:

• Sequenzielle Schreibleistung: Gemessen durch Schreiben einer 256‑MB-Datei mit einem 10‑MB-Schreibpuffer.
• Leistung beim zufälligen Schreiben. Gemessen durch Schreiben einer 256 MB großen Datei mit einem 4 KB großen Schreibpuffer.
• Sequenzielle Leseleistung: Gemessen durch das Lesen einer 256 MB großen Datei mit einem 10 MB großen Schreibpuffer.
• Leistung beim zufälligen Lesen: Gemessen durch Lesen einer 256-MB-Datei mit einem 4-KB-Schreibpuffer.

8.3. Energiesparmodi

Android bietet die Energiesparmodi „App-Standby“ und „Doze“, um die Akkunutzung zu optimieren. [SR] Es wird DRINGEND EMPFOHLEN, alle Apps, die von diesen Modi ausgenommen sind, für den Endnutzer sichtbar zu machen. [SR] Es wird DRINGEND EMPFOHLEN, dass die Auslöse-, Wartungs- und Aktivierungsalgorithmen sowie die Verwendung globaler Systemeinstellungen dieser Energiesparmodi NICHT vom Android Open Source Project abweichen.

Zusätzlich zu den Energiesparmodi KÖNNEN Android-Geräteimplementierungen alle oder einige der vier Ruhezustände implementieren, die vom Advanced Configuration and Power Interface (ACPI) definiert werden.

Wenn Geräteimplementierungen die von ACPI definierten S3- und S4-Energiezustände implementieren, gilt Folgendes:

• [C-1-1] Diese Status DÜRFEN nur beim Schließen eines Deckels erreicht werden, der physisch Teil des Geräts ist.

8.4. Stromverbrauchsabrechnung

Eine genauere Abrechnung und Berichterstellung des Stromverbrauchs bietet dem App-Entwickler sowohl Anreize als auch Tools zur Optimierung des Stromverbrauchs der Anwendung.

Geräteimplementierungen:

• [SR] Es wird DRINGEND EMPFOHLEN, ein Energieprofil pro Komponente bereitzustellen, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch durch die Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.
• [SR] Es wird DRINGEND EMPFOHLEN, alle Werte zum Stromverbrauch in Milliamperestunden (mAh) anzugeben.
• [SR] Es wird DRINGEND EMPFOHLEN, den CPU-Stromverbrauch für die UID jedes Prozesses zu melden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• [SR] ES WIRD DRINGEND EMPFOHLEN, diese Informationen zur Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung zu stellen.
• Sollte der Hardwarekomponente selbst zugeschrieben werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.

8.5. Symbol: Konstante Leistung

Die Leistung kann bei leistungsstarken, lang laufenden Apps aufgrund anderer Apps, die im Hintergrund ausgeführt werden, oder der CPU-Drosselung aufgrund von Temperaturgrenzen stark schwanken. Android umfasst programmatische Schnittstellen, sodass die oberste Vordergrundanwendung, wenn das Gerät dazu in der Lage ist, anfordern kann, dass das System die Zuweisung der Ressourcen optimiert, um solchen Schwankungen entgegenzuwirken.

Geräteimplementierungen:

• [C-0-1] MUSS die Unterstützung des Modus für nachhaltige Leistung über die API-Methode PowerManager.isSustainedPerformanceModeSupported() genau melden.

• Sollte den Modus für nachhaltige Leistung unterstützen.

Wenn Geräteimplementierungen die Unterstützung des Modus für nachhaltige Leistung melden, gilt Folgendes:

• [C-1-1] Die oberste Vordergrundanwendung MUSS mindestens 30 Minuten lang ein gleichbleibendes Leistungsniveau bieten, wenn die App dies anfordert.
• [C-1-2] MUSS die Window.setSustainedPerformanceMode() API und andere zugehörige APIs unterstützen.

Wenn Geräteimplementierungen zwei oder mehr CPU-Kerne enthalten, gilt Folgendes:

• Sollte mindestens einen exklusiven Kern bereitstellen, der von der wichtigsten Vordergrundanwendung reserviert werden kann.

Wenn Geräteimplementierungen das Reservieren eines exklusiven Kerns für die oberste Vordergrundanwendung unterstützen, gilt Folgendes:

• [C-2-1] Die ID-Nummern der exklusiven Kerne, die von der wichtigsten Vordergrundanwendung reserviert werden können, MÜSSEN über die API-Methode Process.getExclusiveCores() gemeldet werden.
• [C-2-2] Es DÜRFEN keine Userspace-Prozesse außer den von der Anwendung verwendeten Gerätetreibern auf den exklusiven Kernen ausgeführt werden. Es DÜRFEN jedoch einige Kernelprozesse nach Bedarf ausgeführt werden.

Wenn Geräteimplementierungen keinen exklusiven Kern unterstützen, gilt Folgendes:

• [C-3-1] MUSS über die API-Methode Process.getExclusiveCores() eine leere Liste zurückgeben.

9. Kompatibilität des Sicherheitsmodells

Geräteimplementierungen:

• [C-0-1] MÜSSEN ein Sicherheitsmodell implementieren, das mit dem Sicherheitsmodell der Android-Plattform übereinstimmt, wie im Referenzdokument zu Sicherheit und Berechtigungen in der Android-Entwicklerdokumentation definiert.

• [C-0-2] Die Installation selbstsignierter Anwendungen MUSS unterstützt werden, ohne dass zusätzliche Berechtigungen/Zertifikate von Dritten/Behörden erforderlich sind. Kompatible Geräte MÜSSEN die in den folgenden Unterabschnitten beschriebenen Sicherheitsmechanismen unterstützen.

9.1. Berechtigungen

Geräteimplementierungen:

• [C-0-1] MÜSSEN das Android-Berechtigungsmodell unterstützen, wie in der Android-Entwicklerdokumentation definiert. Insbesondere MÜSSEN sie jede Berechtigung wie in der SDK-Dokumentation beschrieben erzwingen. Berechtigungen dürfen nicht ausgelassen, geändert oder ignoriert werden.

• Es DÜRFEN zusätzliche Berechtigungen hinzugefügt werden, sofern die neuen Berechtigungs-ID-Strings nicht im Namespace android.\* enthalten sind.

• [C-0-2] Berechtigungen mit einem protectionLevel von PROTECTION_FLAG_PRIVILEGED DÜRFEN NUR Apps erteilt werden, die im privilegierten Pfad des System-Images vorinstalliert sind, und nur innerhalb der Teilmenge der explizit auf die Zulassungsliste gesetzten Berechtigungen für jede App. Die AOSP-Implementierung erfüllt diese Anforderung, indem sie die auf die Zulassungsliste gesetzten Berechtigungen für jede App aus den Dateien im Pfad etc/permissions/ liest und berücksichtigt und den Pfad system/priv-app als privilegierten Pfad verwendet.

Berechtigungen mit dem Schutzlevel „gefährlich“ sind Laufzeitberechtigungen. Bei Anwendungen mit targetSdkVersion > 22 werden sie zur Laufzeit angefordert.

Geräteimplementierungen:

• [C-0-3] MUSS eine spezielle Benutzeroberfläche für den Nutzer anzeigen, über die er entscheiden kann, ob er die angeforderten Laufzeitberechtigungen erteilen möchte. Außerdem MUSS eine Benutzeroberfläche für die Verwaltung von Laufzeitberechtigungen bereitgestellt werden.
• [C-0-4] MUSS genau eine Implementierung beider Benutzeroberflächen haben.
• [C-0-5] Vorinstallierte Apps DÜRFEN keine Laufzeitberechtigungen erhalten, es sei denn:
• Die Einwilligung des Nutzers kann eingeholt werden, bevor die Anwendung die Daten verwendet.
• Die Laufzeitberechtigungen sind einem Intent-Muster zugeordnet, für das die vorinstallierte Anwendung als Standard-Handler festgelegt ist.

Wenn Geräteimplementierungen eine vorinstallierte App enthalten oder Drittanbieter-Apps den Zugriff auf die Nutzungsstatistiken ermöglichen möchten, müssen sie:

• [C-1-1] Es wird DRINGEND EMPFOHLEN, einen für Nutzer zugänglichen Mechanismus bereitzustellen, mit dem der Zugriff auf die Nutzungsstatistiken als Reaktion auf die Intention android.settings.ACTION_USAGE_ACCESS_SETTINGS für Apps, die die Berechtigung android.permission.PACKAGE_USAGE_STATS deklarieren, gewährt oder widerrufen werden kann.

Wenn Geräteimplementierungen den Zugriff auf die Nutzungsstatistiken für Apps, einschließlich vorinstallierter Apps, nicht zulassen sollen, müssen sie:

• [C-2-1] Es MUSS weiterhin eine Aktivität geben, die das Intent-Muster android.settings.ACTION_USAGE_ACCESS_SETTINGS verarbeitet, aber es MUSS als No-Op implementiert werden, d. h. es MUSS ein Verhalten haben, das dem entspricht, wenn dem Nutzer der Zugriff verweigert wird.

9.2. UID und Prozessisolation

Geräteimplementierungen:

• [C-0-1] MUSS das Android-App-Sandbox-Modell unterstützen, in dem jede App als eindeutige UID im Unix-Stil und in einem separaten Prozess ausgeführt wird.
• [C-0-2] Es MUSS möglich sein, mehrere Anwendungen mit derselben Linux-Nutzer-ID auszuführen, sofern die Anwendungen ordnungsgemäß signiert und erstellt wurden, wie in der Referenz zu Sicherheit und Berechtigungen definiert.

9.3. Dateisystemberechtigungen

Geräteimplementierungen:

• [C-0-1] MÜSSEN das Android-Modell für Dateizugriffsberechtigungen unterstützen, wie in der Referenz zu Sicherheit und Berechtigungen definiert.

9.4. Alternative Ausführungsumgebungen

Geräteimplementierungen MÜSSEN das Android-Sicherheits- und Berechtigungsmodell beibehalten, auch wenn sie Laufzeitumgebungen enthalten, in denen Anwendungen mit anderer Software oder Technologie als dem Dalvik Executable Format oder nativem Code ausgeführt werden. Mit anderen Worten:

• [C-0-1] Alternative Runtimes MÜSSEN selbst Android-Anwendungen sein und dem standardmäßigen Android-Sicherheitsmodell entsprechen, wie an anderer Stelle in Abschnitt 9 beschrieben.

• [C-0-2] Alternativen Laufzeitumgebungen DÜRFEN über den <uses-permission>-Mechanismus KEINEN Zugriff auf Ressourcen erhalten, die durch Berechtigungen geschützt sind, die nicht in der AndroidManifest.xml-Datei der Laufzeitumgebung angefordert werden.

• [C-0-3] Alternative Runtimes DÜRFEN Anwendungen NICHT erlauben, Funktionen zu nutzen, die durch Android-Berechtigungen geschützt sind, die auf Systemanwendungen beschränkt sind.

• [C-0-4] Alternative Runtimes MÜSSEN das Android-Sandbox-Modell einhalten und installierte Anwendungen, die eine alternative Runtime verwenden, DÜRFEN die Sandbox einer anderen auf dem Gerät installierten App NICHT wiederverwenden, es sei denn, dies erfolgt über die Standard-Android-Mechanismen der gemeinsamen Nutzer-ID und des Signaturzertifikats.

• [C-0-5] Alternative Runtimes DÜRFEN NICHT mit den Sandboxes anderer Android-Anwendungen gestartet werden, Zugriff auf diese gewähren oder Zugriff auf diese erhalten.

• [C-0-6] Alternative Runtimes DÜRFEN NICHT mit Superuser-Berechtigungen (Root) oder Berechtigungen einer anderen Nutzer-ID gestartet werden, solche Berechtigungen erhalten oder anderen Anwendungen erteilen.

• [C-0-7] Wenn die .apk-Dateien alternativer Runtimes im System-Image von Geräteimplementierungen enthalten sind, MÜSSEN sie mit einem Schlüssel signiert werden, der sich von dem Schlüssel unterscheidet, der zum Signieren anderer Anwendungen verwendet wird, die in den Geräteimplementierungen enthalten sind.

• [C-0-8] Bei der Installation von Anwendungen MÜSSEN alternative Laufzeiten die Einwilligung des Nutzers für die von der Anwendung verwendeten Android-Berechtigungen einholen.

• [C-0-9] Wenn eine Anwendung eine Geräteressource verwenden muss, für die eine entsprechende Android-Berechtigung vorhanden ist (z. B. Kamera, GPS usw.), MUSS die alternative Laufzeit den Nutzer darüber informieren, dass die Anwendung auf diese Ressource zugreifen kann.

• [C-0-10] Wenn die Laufzeitumgebung Anwendungsfunktionen nicht auf diese Weise aufzeichnet, MUSS sie bei der Installation einer Anwendung mit dieser Laufzeit alle Berechtigungen auflisten, die die Laufzeit selbst hat.

• Alternative Runtimes SOLLTEN Apps über PackageManager in separaten Android-Sandboxes (Linux-Nutzer-IDs usw.) installieren.

• Alternative Laufzeiten KÖNNEN eine einzelne Android-Sandbox bereitstellen, die von allen Anwendungen verwendet wird, die die alternative Laufzeit verwenden.

9.5. Unterstützung mehrerer Nutzer

Android bietet Unterstützung für mehrere Nutzer und vollständige Nutzerisolation.

• Bei Geräteimplementierungen KANN, SOLLTE aber NICHT die Unterstützung mehrerer Nutzer aktiviert werden, wenn Wechselmedien als primärer externer Speicher verwendet werden.

Wenn Geräteimplementierungen mehrere Nutzer umfassen, gilt Folgendes:

• [C-1-1] MUSS die folgenden Anforderungen in Bezug auf die Unterstützung mehrerer Nutzer erfüllen.
• [C-1-2] MUSS für jeden Nutzer ein Sicherheitsmodell implementieren, das mit dem Sicherheitsmodell der Android-Plattform übereinstimmt, wie im Referenzdokument zu Sicherheit und Berechtigungen in den APIs definiert.
• [C-1-3] Es MUSS separate und isolierte Verzeichnisse für den gemeinsamen Anwendungsspeicher (auch bekannt als /sdcard) für jede Nutzerinstanz geben.
• [C-1-4] MUSS dafür sorgen, dass Anwendungen, die einem bestimmten Nutzer gehören und in seinem Namen ausgeführt werden, die Dateien eines anderen Nutzers nicht auflisten, lesen oder in sie schreiben können, auch wenn die Daten beider Nutzer auf demselben Volume oder Dateisystem gespeichert sind.
• [C-1-5] Der Inhalt der SD-Karte MUSS verschlüsselt werden, wenn die Mehrbenutzerfunktion aktiviert ist. Dazu muss ein Schlüssel verwendet werden, der nur auf nicht entfernbaren Medien gespeichert ist, auf die nur das System zugreifen kann, wenn Geräteimplementierungen entfernbare Medien für die APIs für externen Speicher verwenden. Da die Medien dadurch für einen Host-PC unlesbar werden, müssen Geräteimplementierungen auf MTP oder ein ähnliches System umgestellt werden, um Host-PCs Zugriff auf die Daten des aktuellen Nutzers zu ermöglichen.

Wenn Geräteimplementierungen mehrere Nutzer umfassen und das Feature-Flag android.hardware.telephony nicht deklarieren, gilt Folgendes:

• [C-2-1] Das Gerät MUSS eingeschränkte Profile unterstützen. Mit dieser Funktion können Geräteeigentümer zusätzliche Nutzer und ihre Funktionen auf dem Gerät verwalten. Mit eingeschränkten Profilen können Geräteinhaber schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen für die in diesen Umgebungen verfügbaren Apps verwalten.

Wenn Geräteimplementierungen mehrere Nutzer umfassen und das Feature-Flag android.hardware.telephony deklarieren, gilt Folgendes:

• [C-3-1] Eingeschränkte Profile DÜRFEN NICHT unterstützt werden, MÜSSEN aber mit der AOSP-Implementierung von Steuerelementen übereinstimmen, mit denen andere Nutzer den Zugriff auf Sprachanrufe und SMS aktivieren /deaktivieren können.

9.6. Warnung zu Premium-SMS

Android unterstützt die Warnung von Nutzern vor ausgehenden Premium-SMS-Nachrichten. Premium-SMS sind Textnachrichten, die an einen bei einem Mobilfunkanbieter registrierten Dienst gesendet werden und für den dem Nutzer möglicherweise Kosten entstehen.

Wenn Geräteimplementierungen Unterstützung für android.hardware.telephony deklarieren, gilt Folgendes:

• [C-1-1] MUSS Nutzer warnen, bevor eine SMS an Nummern gesendet wird, die durch reguläre Ausdrücke identifiziert werden, die in der /data/misc/sms/codes.xml-Datei auf dem Gerät definiert sind. Das Upstream-Open-Source-Projekt für Android bietet eine Implementierung, die diese Anforderung erfüllt.

9.7. Kernel-Sicherheitsfunktionen

Die Android-Sandbox umfasst Funktionen, die das obligatorische Zugriffssteuerungssystem (Mandatory Access Control, MAC) von Security-Enhanced Linux (SELinux), Seccomp-Sandboxing und andere Sicherheitsfunktionen im Linux-Kernel verwenden. Geräteimplementierungen:

• [C-0-1] Die Kompatibilität mit bestehenden Anwendungen MUSS aufrechterhalten werden, auch wenn SELinux oder andere Sicherheitsfunktionen unterhalb des Android-Frameworks implementiert werden.
• [C-0-2] DARF KEINE sichtbare Benutzeroberfläche haben, wenn ein Sicherheitsverstoß erkannt und von der Sicherheitsfunktion, die unter dem Android-Framework implementiert ist, erfolgreich blockiert wird. Sie DARF jedoch eine sichtbare Benutzeroberfläche haben, wenn ein nicht blockierter Sicherheitsverstoß auftritt, der zu einem erfolgreichen Exploit führt.
• [C-0-3] SELinux oder andere Sicherheitsfunktionen, die unterhalb des Android-Frameworks implementiert sind, DÜRFEN NICHT für den Nutzer oder App-Entwickler konfigurierbar sein.
• [C-0-4] Eine Anwendung, die eine andere Anwendung über eine API (z. B. eine Geräteadministrator-API) beeinflussen kann, DARF NICHT zulassen, dass eine Richtlinie konfiguriert wird, die die Kompatibilität beeinträchtigt.
• [C-0-5] Das Media-Framework MUSS in mehrere Prozesse aufgeteilt werden, damit der Zugriff für jeden Prozess wie auf der Android Open Source Project-Website beschrieben genauer gewährt werden kann.
• [C-0-6] MUSS einen Kernel-Anwendungssandboxing-Mechanismus implementieren, der das Filtern von Systemaufrufen mithilfe einer konfigurierbaren Richtlinie aus Multithread-Programmen ermöglicht. Das Upstream-Open-Source-Projekt für Android erfüllt diese Anforderung, indem seccomp-BPF mit Threadgroup Synchronization (TSYNC) aktiviert wird, wie im Abschnitt „Kernel Configuration“ auf source.android.com beschrieben.

Die Kernelintegrität und die Selbstschutzfunktionen sind ein wichtiger Bestandteil der Android-Sicherheit. Geräteimplementierungen:

• [C-0-7] MÜSSEN Schutzmaßnahmen gegen Pufferüberläufe im Kernel-Stack implementieren (z.B. CONFIG_CC_STACKPROTECTOR_STRONG).
• [C-0-8] Es MUSS ein strenger Schutz des Kernel-Speichers implementiert werden, bei dem ausführbarer Code schreibgeschützt ist, schreibgeschützte Daten nicht ausführbar und nicht beschreibbar sind und beschreibbare Daten nicht ausführbar sind (z.B. CONFIG_DEBUG_RODATA oder CONFIG_STRICT_KERNEL_RWX).
• [SR] Es wird DRINGEND EMPFOHLEN, Kerneldaten, die nur während der Initialisierung geschrieben werden, nach der Initialisierung als schreibgeschützt zu markieren (z.B. __ro_after_init).
• [SR} Es wird DRINGEND EMPFOHLEN, die statische und dynamische Größenbeschränkung von Kopien zwischen Nutzerbereich und Kernelbereich (z.B. CONFIG_HARDENED_USERCOPY) zu implementieren.
• [SR] Es wird DRINGEND EMPFOHLEN, niemals Benutzermodusspeicher auszuführen, wenn der Kernel ausgeführt wird (z.B. Hardware-PXN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN).
• [SR] Es wird DRINGEND EMPFOHLEN, im Kernel niemals auf den Speicher des Nutzerbereichs zuzugreifen, es sei denn, dies erfolgt über normale Usercopy-Zugriffs-APIs (z.B. Hardware-PAN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN).
• [SR] Es wird DRINGEND EMPFOHLEN, das Layout des Kernel-Codes und des Arbeitsspeichers zu randomisieren und Offenlegungen zu vermeiden, die die Randomisierung beeinträchtigen könnten (z.B. CONFIG_RANDOMIZE_BASE mit Bootloader-Entropie über /chosen/kaslr-seed Device Tree node oder EFI_RNG_PROTOCOL).

Wenn Geräteimplementierungen einen Linux-Kernel verwenden, gilt Folgendes:

• [C-1-1] MUSS SELinux implementieren.
• [C-1-2] SELinux MUSS auf den globalen Erzwingungsmodus eingestellt werden.
• [C-1-3] ALLE Domains MÜSSEN im Erzwingungsmodus konfiguriert werden. Es sind keine Domains im permissiven Modus zulässig, einschließlich Domains, die für ein Gerät oder einen Anbieter spezifisch sind.
• [C-1-4] DÜRFEN die neverallow-Regeln im System-/sepolicy-Ordner, die im Upstream-Android Open Source Project (AOSP) enthalten sind, NICHT ändern, weglassen oder ersetzen. Die Richtlinie MUSS mit allen vorhandenen neverallow-Regeln kompiliert werden, sowohl für AOSP-SELinux-Domains als auch für geräte-/anbieterspezifische Domains.
• Sollten die standardmäßige SELinux-Richtlinie beibehalten, die im Ordner „system/sepolicy“ des Upstream-Android Open Source Project bereitgestellt wird, und diese Richtlinie nur für ihre eigene gerätespezifische Konfiguration erweitern.

Wenn in Geräteimplementierungen ein anderes Betriebssystem als Linux verwendet wird, gilt Folgendes:

• [C-2-1] MUSS ein System zur obligatorischen Zugriffssteuerung verwenden, das SELinux entspricht.

9.8. Datenschutz

9.8.1. Nutzungsverlauf

Android speichert den Verlauf der Nutzerauswahl und verwaltet ihn mit UsageStatsManager.

Geräteimplementierungen:

• [C-1-1] MUSS einen angemessenen Aufbewahrungszeitraum für diesen Nutzerverlauf einhalten.
• [SR] Es wird DRINGEND EMPFOHLEN, die standardmäßig in der AOSP-Implementierung konfigurierte Aufbewahrungsdauer von 14 Tagen beizubehalten.

9.8.2. Aufnahme

Wenn Geräteimplementierungen Funktionen im System enthalten, die die auf dem Bildschirm angezeigten Inhalte erfassen und/oder den auf dem Gerät wiedergegebenen Audiostream aufzeichnen, gilt Folgendes:

• [C-1-1] MUSS eine laufende Benachrichtigung für den Nutzer anzeigen, wenn diese Funktion aktiviert ist und aktiv Daten erfasst/aufzeichnet.

Wenn Geräteimplementierungen eine Komponente enthalten, die standardmäßig aktiviert ist und Umgebungsgeräusche aufzeichnen kann, um nützliche Informationen über den Kontext des Nutzers abzuleiten, gilt Folgendes:

• [C-2-1] Aufgezeichnete Rohaudiodaten oder ein Format, das in die Originalaudiodaten oder ein ähnliches Format zurückkonvertiert werden kann, DÜRFEN NICHT im persistenten On-Device-Speicher gespeichert oder vom Gerät übertragen werden, es sei denn, der Nutzer hat ausdrücklich zugestimmt.

9.8.3. Konnektivität

Wenn Geräteimplementierungen einen USB-Anschluss mit Unterstützung für den USB-Peripheriemodus haben, gilt Folgendes:

• [C-1-1] MUSS eine Benutzeroberfläche präsentieren, in der der Nutzer um seine Einwilligung gebeten wird, bevor über den USB-Anschluss auf die Inhalte des freigegebenen Speichers zugegriffen werden darf.

9.8.4. Netzwerkverkehr

Geräteimplementierungen:

• [C-0-1] Es MUSS dieselben Root-Zertifikate für den vom System vertrauenswürdigen Zertifizierungsstellenspeicher vorinstallieren, die im Upstream-Android Open Source Project bereitgestellt werden.
• [C-0-2] MÜSSEN mit einem leeren Nutzer-Stammzertifizierungsstellenspeicher ausgeliefert werden.
• [C-0-3] MUSS dem Nutzer eine Warnung anzeigen, dass der Netzwerkverkehr überwacht werden kann, wenn eine Root-Zertifizierungsstelle für Nutzer hinzugefügt wird.

Wenn der Geräteverkehr über ein VPN geleitet wird, müssen Geräteimplementierungen:

• [C-1-1] Dem Nutzer MUSS eine Warnung angezeigt werden, die Folgendes angibt:
  • Dieser Netzwerkverkehr wird möglicherweise überwacht.
  • Dieser Netzwerkverkehr wird über die jeweilige VPN-Anwendung weitergeleitet, die das VPN bereitstellt.

Wenn Geräteimplementierungen einen Mechanismus haben, der standardmäßig aktiviert ist und mit dem Netzwerkdatenverkehr über einen Proxyserver oder ein VPN-Gateway geleitet wird (z. B. durch Vorabinstallation eines VPN-Dienstes mit der Berechtigung android.permission.CONTROL_VPN), gilt Folgendes:

• [C-2-1] Der Nutzer MUSS um Einwilligung gebeten werden, bevor dieser Mechanismus aktiviert wird, es sei denn, das VPN wird vom Geräteinhaber über DevicePolicyManager.setAlwaysOnVpnPackage() aktiviert. In diesem Fall muss der Nutzer keine separate Einwilligung erteilen, sondern NUR benachrichtigt werden.

Wenn Geräteimplementierungen eine Möglichkeit für Nutzer bieten, die Funktion „Durchgehend aktives VPN“ einer VPN-App eines Drittanbieters zu aktivieren, gilt Folgendes:

• [C-3-1] Diese Nutzerfreundlichkeit MUSS für Apps deaktiviert werden, die durchgehend aktives VPN nicht unterstützen. Dazu muss das Attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON in der Datei AndroidManifest.xml auf false gesetzt werden.

9.9. Verschlüsselung der Datenspeicherung

Wenn Geräteimplementierungen eine sichere Displaysperre unterstützen, wie in Abschnitt 9.11.1 beschrieben, gilt Folgendes:

• [C-1-1] MUSS die Verschlüsselung der privaten Daten der Anwendung (/data partition) sowie der freigegebenen Speicherpartition der Anwendung (/sdcard partition) unterstützen, wenn diese ein permanenter, nicht entfernbarer Teil des Geräts ist.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm wie in Abschnitt 9.11.1 beschrieben und die Verschlüsselung von Datenspeicher mit AES-Krypto-Leistung (Advanced Encryption Standard) über 50 MiB/s unterstützen, gilt Folgendes:

• [C-2-1] Die Verschlüsselung der Datenspeicherung MUSS standardmäßig aktiviert werden, sobald der Nutzer die Einrichtung abgeschlossen hat. Wenn Geräteimplementierungen bereits mit einer früheren Android-Version eingeführt wurden, bei der die Verschlüsselung standardmäßig deaktiviert ist, kann ein solches Gerät die Anforderung nicht durch ein Systemsoftware-Update erfüllen und KANN daher ausgenommen werden.

• Sollte die oben genannte Anforderung zur Verschlüsselung von Datenspeichern durch die Implementierung der dateibasierten Verschlüsselung (File Based Encryption, FBE) erfüllen.

9.9.1. Direct Boot

Geräteimplementierungen:

• [C-0-1] Die APIs für den Direct Boot-Modus MÜSSEN implementiert werden, auch wenn die Speicherverschlüsselung nicht unterstützt wird.

• [C-0-2] Die Intents ACTION_LOCKED_BOOT_COMPLETED und ACTION_USER_UNLOCKED MÜSSEN weiterhin übertragen werden, um Direct Boot-fähigen Anwendungen zu signalisieren, dass verschlüsselte Gerätespeicherorte (Device Encrypted, DE) und mit Anmeldedaten verschlüsselte Speicherorte (Credential Encrypted, CE) für den Nutzer verfügbar sind.

9.9.2. Dateibasierte Verschlüsselung

Wenn Geräteimplementierungen FBE unterstützen, gilt Folgendes:

• [C-1-1] Das Gerät MUSS ohne Aufforderung zur Eingabe von Anmeldedaten starten und Direct Boot-kompatiblen Apps den Zugriff auf den verschlüsselten Gerätespeicher (Device Encrypted, DE) ermöglichen, nachdem die ACTION_LOCKED_BOOT_COMPLETED-Nachricht gesendet wurde.
• [C-1-2] Der Zugriff auf den mit Anmeldedaten verschlüsselten Speicher (Credential Encrypted, CE) MUSS erst möglich sein, nachdem der Nutzer das Gerät durch Angabe seiner Anmeldedaten (z. B. Sicherheitscode, PIN, Muster oder Fingerabdruck) entsperrt hat und die ACTION_USER_UNLOCKED-Nachricht gesendet wurde.
• [C-1-3] Es DARF keine Methode zum Entsperren des CE-geschützten Speichers ohne die vom Nutzer bereitgestellten Anmeldedaten geben.
• [C-1-4] MUSS den Bootmodus mit Verifikation unterstützen und dafür sorgen, dass die DE-Schlüssel kryptografisch an die Hardware-Root of Trust des Geräts gebunden sind.
• [C-1-5] MUSS die Verschlüsselung von Dateiinhalten mit AES mit einer Schlüssellänge von 256 Bit im XTS-Modus unterstützen.

• [C-1-6] MUSS die Verschlüsselung von Dateinamen mit AES mit einer Schlüssellänge von 256 Bit im CBC-CTS-Modus unterstützen.

• Die Schlüssel, mit denen die Speicherbereiche für CE und DE geschützt werden:

• [C-1-7] MUSS kryptografisch an einen hardwaregestützten Keystore gebunden sein.

• [C-1-8] CE-Schlüssel MÜSSEN an die Anmeldedaten für den Sperrbildschirm eines Nutzers gebunden sein.
• [C-1-9] CE-Schlüssel MÜSSEN an einen Standardsicherheitscode gebunden sein, wenn der Nutzer keine Anmeldedaten für den Sperrbildschirm angegeben hat.

• [C-1-10] MUSS eindeutig und unterschiedlich sein. Das bedeutet, dass der CE- oder DE-Schlüssel eines Nutzers nicht mit dem CE- oder DE-Schlüssel eines anderen Nutzers übereinstimmt.

• Vorinstallierte wichtige Apps (z.B. Wecker, Telefon, Messenger) SOLLTEN Direct Boot-fähig sein.

• Es KANN alternative Chiffren, Schlüssellängen und Modi für die Verschlüsselung von Dateiinhalten und Dateinamen unterstützen, MUSS aber standardmäßig die obligatorisch unterstützten Chiffren, Schlüssellängen und Modi verwenden.

Das Upstream-Android Open Source-Projekt bietet eine bevorzugte Implementierung dieser Funktion, die auf der ext4-Verschlüsselungsfunktion des Linux-Kernels basiert.

9.9.3. Vollständige Datenträgerverschlüsselung

Wenn Geräteimplementierungen die Datenträgervollverschlüsselung (Full Disk Encryption, FDE) unterstützen, gilt Folgendes:

• [C-1-1] MUSS AES mit einem Schlüssel von 128 Bit (oder mehr) und einem für die Speicherung entwickelten Modus (z. B. AES-XTS, AES-CBC-ESSIV) verwenden.
• [C-1-2] MUSS einen Standard-Sicherheitscode verwenden, um den Verschlüsselungsschlüssel zu umschließen, und DARF den Verschlüsselungsschlüssel zu keinem Zeitpunkt unverschlüsselt in den Speicher schreiben.
• [C-1-3] Der Verschlüsselungsschlüssel MUSS standardmäßig mit AES verschlüsselt werden, es sei denn, der Nutzer deaktiviert dies ausdrücklich. Dies gilt nicht, wenn der Schlüssel aktiv verwendet wird. In diesem Fall werden die Anmeldedaten für den Sperrbildschirm mit einem langsamen Stretching-Algorithmus (z. B. PBKDF2 oder scrypt) gestreckt.
• [C-1-4] Der oben genannte Standardalgorithmus für das Dehnen von Passwörtern MUSS kryptografisch an diesen Keystore gebunden sein, wenn der Nutzer keine Anmeldedaten für den Sperrbildschirm angegeben oder die Verwendung des Sicherheitscodes für die Verschlüsselung deaktiviert hat und das Gerät einen hardwaregestützten Keystore bietet.
• [C-1-5] Der Verschlüsselungsschlüssel DARF NICHT vom Gerät gesendet werden, auch wenn er mit dem Sicherheitscode des Nutzers und/oder einem an die Hardware gebundenen Schlüssel verschlüsselt ist.

Das Upstream-Open-Source-Projekt für Android bietet eine bevorzugte Implementierung dieser Funktion, die auf der Linux-Kernel-Funktion „dm-crypt“ basiert.

9.10. Geräteintegrität

Die folgenden Anforderungen sorgen für Transparenz in Bezug auf den Status der Geräteintegrität. Geräteimplementierungen:

• [C-0-1] MUSS über die System API-Methode PersistentDataBlockManager.getFlashLockState() korrekt melden, ob der Bootloader-Status das Flashen des System-Images zulässt. Der Status FLASH_LOCK_UNKNOWN ist für Geräteimplementierungen reserviert, die von einer früheren Android-Version aktualisiert werden, in der diese neue System-API-Methode noch nicht vorhanden war.

Der Bootmodus mit Verifikation ist eine Funktion, die die Integrität der Gerätesoftware garantiert. Wenn eine Geräteimplementierung die Funktion unterstützt, gilt Folgendes:

• [C-1-1] MUSS das Plattform-Funktions-Flag android.software.verified_boot deklarieren.
• [C-1-2] Die Überprüfung MUSS bei jeder Boot-Sequenz durchgeführt werden.
• [C-1-3] Die Überprüfung MUSS mit einem unveränderlichen Hardwareschlüssel als Root of Trust beginnen und bis zur Systempartition reichen.
• [C-1-4] Jede Phase der Überprüfung MUSS implementiert werden, um die Integrität und Authentizität aller Bytes in der nächsten Phase zu prüfen, bevor der Code in der nächsten Phase ausgeführt wird.
• [C-1-5] MUSS Verifizierungsalgorithmen verwenden, die so stark sind wie die aktuellen Empfehlungen des NIST für Hash-Algorithmen (SHA-256) und Größen öffentlicher Schlüssel (RSA-2048).
• [C-1-6] Das Booten darf nicht abgeschlossen werden, wenn die Systemüberprüfung fehlschlägt, es sei denn, der Nutzer stimmt zu, das Booten trotzdem zu versuchen. In diesem Fall dürfen die Daten aus nicht überprüften Speicherblöcken NICHT verwendet werden.
• [C-1-7] VERIFIZIERTE Partitionen auf dem Gerät DÜRFEN NICHT geändert werden, es sei denn, der Nutzer hat den Bootloader explizit entsperrt.
• [SR] Wenn das Gerät mehrere separate Chips hat (z.B. Funkchip, spezieller Bildprozessor), wird DRINGEND EMPFOHLEN, dass der Bootvorgang jedes dieser Chips bei jedem Booten jede Phase überprüft.
• [SR] Es wird DRINGEND EMPFOHLEN, einen manipulationssicheren Speicher zu verwenden, wenn der Bootloader entsperrt ist. Manipulationssicherer Speicher bedeutet, dass der Bootloader erkennen kann, ob der Speicher vom HLOS (High Level Operating System) aus manipuliert wurde.
• [SR] Es wird DRINGEND EMPFOHLEN, den Nutzer während der Verwendung des Geräts aufzufordern, die physische Bestätigung zu verlangen, bevor ein Übergang vom gesperrten Bootloader-Modus zum entsperrten Bootloader-Modus zugelassen wird.
• [SR] Es wird DRINGEND EMPFOHLEN, einen Rollback-Schutz für das HLOS (z.B. Boot- und Systempartitionen) zu implementieren und einen manipulationssicheren Speicher zum Speichern der Metadaten zu verwenden, die zur Bestimmung der zulässigen Mindest-Betriebssystemversion verwendet werden.
• Es SOLLTE ein Rollback-Schutz für alle Komponenten mit persistenter Firmware (z.B. Modem, Kamera) implementiert werden und es SOLLTE ein manipulationssicherer Speicher zum Speichern der Metadaten verwendet werden, die zur Bestimmung der zulässigen Mindestversion verwendet werden.

Das Upstream-Android Open Source Project bietet eine bevorzugte Implementierung dieser Funktion im Repository external/avb/, die in den Bootloader integriert werden kann, der zum Laden von Android verwendet wird.

Wenn Geräteimplementierungen das Feature-Flag android.hardware.ram.normal melden , gilt Folgendes:

• [C-2-1] MUSS den Bootmodus mit Verifikation für die Geräteintegrität unterstützen.

Wenn ein Gerät bereits ohne Unterstützung des Bootmodus mit Verifikation auf einer früheren Android-Version eingeführt wurde, kann die Unterstützung für diese Funktion nicht durch ein Systemsoftware-Update hinzugefügt werden. Solche Geräte sind daher von der Anforderung ausgenommen.

9.11. Schlüssel und Anmeldedaten

Mit dem Android Keystore System können App-Entwickler kryptografische Schlüssel in einem Container speichern und sie in kryptografischen Vorgängen über die KeyChain API oder die Keystore API verwenden. Geräteimplementierungen:

• [C-0-1] MUSS mindestens den Import von mehr als 8.192 Schlüsseln ermöglichen.
• [C-0-2] Die Authentifizierung auf dem Sperrbildschirm MUSS die Anzahl der Versuche begrenzen und einen exponentiellen Backoff-Algorithmus verwenden. Nach 150 fehlgeschlagenen Versuchen MUSS die Verzögerung mindestens 24 Stunden pro Versuch betragen.
• Die Anzahl der Schlüssel, die generiert werden können, sollte NICHT begrenzt werden.

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

• [C-1-1] MUSS die Keystore-Implementierung mit sicherer Hardware sichern.
• [C-1-2] MUSS Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie der Hashfunktionen MD5, SHA1 und SHA-2 enthalten, um die vom Android-Keystore-System unterstützten Algorithmen in einem Bereich, der sicher vom Code isoliert ist, der auf dem Kernel und darüber ausgeführt wird, ordnungsgemäß zu unterstützen. Die sichere Isolierung MUSS alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen könnte, einschließlich DMA. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Eine andere auf ARM TrustZone basierende Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer geeigneten hypervisorbasierten Isolation sind alternative Optionen.
• [C-1-3] Die Sperrbildschirmauthentifizierung MUSS in der isolierten Ausführungsumgebung erfolgen und die Verwendung der authentifizierungsgebundenen Schlüssel DARF nur bei erfolgreicher Authentifizierung zugelassen werden. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Authentifizierung für den Sperrbildschirm durchführen kann. Das Upstream-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, die verwendet werden können, um diese Anforderung zu erfüllen.
• [C-1-4] MUSS die Schlüsselattestierung unterstützen, wobei der Attestierungssignierschlüssel durch sichere Hardware geschützt ist und die Signierung in sicherer Hardware erfolgt. Die Attestierungssignaturschlüssel MÜSSEN auf einer ausreichend großen Anzahl von Geräten geteilt werden, um zu verhindern, dass die Schlüssel als Geräte-IDs verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer bestimmten Artikelnummer produziert werden. Wenn mehr als 100.000 Einheiten einer SKU produziert werden, KANN für jeweils 100.000 Einheiten ein anderer Schlüssel verwendet werden.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version eingeführt wurde, ist sie von der Anforderung, einen hardwarebasierten Keystore zu haben, ausgenommen, es sei denn, sie deklariert das android.hardware.fingerprint-Feature, für das ein hardwarebasierter Keystore erforderlich ist.

9.11.1. Sicherer Sperrbildschirm

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agents enthalten, die die TrustAgentService-System-API implementieren, dann:

• [C-1-1] Der Nutzer MUSS in der Benutzeroberfläche für die Einstellungen und den Sperrbildschirm darüber informiert werden, wenn die automatische Bildschirmsperre verzögert wird oder die Bildschirmsperre vom Trust Agent entsperrt werden kann. AOSP erfüllt die Anforderung, indem eine Textbeschreibung für die Menüs „Automatische Sperre“ und „Ein/Aus-Taste sperrt sofort“ sowie ein eindeutiges Symbol auf dem Sperrbildschirm angezeigt werden.
• [C-1-2] MUSS alle Trust-Agent-APIs in der Klasse DevicePolicyManager respektieren und vollständig implementieren, z. B. die Konstante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-1-3] Die Funktion TrustAgentService.addEscrowToken() DÜRFEN NICHT vollständig auf einem Gerät implementiert werden, das als primäres persönliches Gerät verwendet wird (z.B. ein Mobilgerät), aber DÜRFEN vollständig auf Geräteimplementierungen implementiert werden, die in der Regel gemeinsam genutzt werden.
• [C-1-4] MUSS die von TrustAgentService.addEscrowToken() hinzugefügten Tokens verschlüsseln, bevor sie auf dem Gerät gespeichert werden.
• [C-1-5] Der Verschlüsselungsschlüssel DARF NICHT auf dem Gerät gespeichert werden.
• [C-1-6] MUSS den Nutzer über die Sicherheitsrisiken informieren, bevor das Escrow-Token zum Entschlüsseln des Datenspeichers aktiviert wird.

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden, müssen sie die folgenden Anforderungen erfüllen, damit sie als sichere Methode zum Sperren des Bildschirms gelten:

• [C-2-1] MUSS die Nutzerauthentifizierungsmethode sein, die unter Nutzerauthentifizierung für die Schlüsselverwendung erforderlich beschrieben wird.
• [C-2-2] ALLE SCHLÜSSEL MÜSSEN für die Verwendung durch eine Drittanbieter-App freigeschaltet werden, wenn der Nutzer die sichere Displaysperre entsperrt. Beispielsweise MÜSSEN alle Schlüssel für eine Drittanbieter-Entwickler-App über relevante APIs wie createConfirmDeviceCredentialIntent und setUserAuthenticationRequired verfügbar sein.

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms auf einem bekannten Geheimnis basieren, müssen sie die folgenden Anforderungen erfüllen, um als sichere Methode zum Sperren des Bildschirms zu gelten:

• [C-3-1] Die Entropie der kürzesten zulässigen Eingabelänge MUSS größer als 10 Bit sein.
• [C-3-2] Die maximale Entropie aller möglichen Eingaben MUSS größer als 18 Bit sein.
• [C-3-3] DÜRFEN keine der vorhandenen Authentifizierungsmethoden (PIN, Muster, Passwort) ersetzen, die in AOSP implementiert und bereitgestellt werden.
• [C-3-4] MUSS deaktiviert werden, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie zur Passwortqualität über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_SOMETHING festgelegt hat.

Wenn Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms auf Grundlage eines physischen Tokens oder des Standorts hinzufügen oder ändern, müssen sie die folgenden Anforderungen erfüllen, damit eine solche Authentifizierungsmethode als sichere Methode zum Sperren des Bildschirms gilt:

• [C-4-1] Es MUSS ein Fallback-Mechanismus vorhanden sein, mit dem eine der primären Authentifizierungsmethoden verwendet werden kann, die auf einem bekannten Secret basiert und die Anforderungen für einen sicheren Sperrbildschirm erfüllt.
• [C-4-2] MUSS deaktiviert sein und das Entsperren des Bildschirms nur über die primäre Authentifizierung zulassen, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie entweder mit der Methode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) oder der Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_UNSPECIFIED festgelegt hat.
• [C-4-3] Der Nutzer MUSS mindestens alle 72 Stunden zur primären Authentifizierung (z.B.PIN, Muster, Passwort) aufgefordert werden.

Wenn Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms auf Grundlage biometrischer Daten hinzufügen oder ändern, müssen sie die folgenden Anforderungen erfüllen, damit eine solche Authentifizierungsmethode als sichere Methode zum Sperren des Bildschirms gilt:

• [C-5-1] Es MUSS einen Fallback-Mechanismus geben, mit dem eine der primären Authentifizierungsmethoden verwendet werden kann, die auf einem bekannten Secret basiert und die Anforderungen für einen sicheren Sperrbildschirm erfüllt.
• [C-5-2] MUSS deaktiviert sein und darf nur die primäre Authentifizierung zum Entsperren des Displays zulassen, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie für die Funktion „keguard“ durch Aufrufen der Methode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) festgelegt hat.
• [C-5-3] MUSS eine Falschakzeptanzrate haben, die der für einen Fingerabdrucksensor in Abschnitt 7.3.10 beschriebenen Rate entspricht oder besser ist. Andernfalls MUSS sie deaktiviert sein und das Entsperren des Displays darf nur über die primäre Authentifizierung erfolgen, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie für die Passwortqualität über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_BIOMETRIC_WEAK festgelegt hat.
• [SR] Es wird DRINGEND EMPFOHLEN, dass die Akzeptanzraten für Spoofing und Identitätsdiebstahl gleich oder besser sind als die für einen Fingerabdrucksensor gemäß Abschnitt 7.3.10.

Wenn die Akzeptanzraten für Spoofing und Identitätsdiebstahl nicht gleich oder höher sind als die für einen Fingerabdrucksensor erforderlichen Raten, wie in Abschnitt 7.3.10 beschrieben, und die DPC-Anwendung (Device Policy Controller) die Richtlinie für die Passwortqualität über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_BIOMETRIC_WEAK festgelegt hat, gilt Folgendes:

• [C-6-1] MUSS diese biometrischen Methoden deaktivieren und nur die primäre Authentifizierung zum Entsperren des Bildschirms zulassen.
• [C-6-2] Der Nutzer MUSS mindestens alle 72 Stunden zur primären Authentifizierung (z.B.PIN, Muster, Passwort) aufgefordert werden.

Wenn Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzufügen oder ändern und eine solche Authentifizierungsmethode zum Entsperren des Keyguards verwendet wird, aber nicht als sicherer Sperrbildschirm behandelt wird, gilt Folgendes:

• [C-7-1] MUSS für die Methoden KeyguardManager.isKeyguardSecure() und KeyguardManager.isDeviceSecure() false zurückgeben.
• [C-7-2] MUSS deaktiviert werden, wenn die Device Policy Controller-Anwendung (DPC) die Richtlinie für die Passwortqualität über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_UNSPECIFIED festgelegt hat.
• [C-7-3] DÜRFEN die von DevicePolicyManager.setPasswordExpirationTimeout() festgelegten Timer für den Ablauf des Passworts NICHT zurücksetzen.
• [C-7-4] Der Zugriff auf Keystores DARF NICHT authentifiziert werden, wenn die Anwendung KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) aufgerufen hat.

9.12. Löschen von Daten

Für alle Geräteimplementierungen gilt:

• [C-0-1] Nutzer MÜSSEN die Möglichkeit haben, das Gerät auf die Werkseinstellungen zurückzusetzen.
• [C-0-2] ALLE nutzergenerierten Daten MÜSSEN gelöscht werden. Das heißt, alle Daten außer den folgenden:
  • Das Systemimage
  • Alle Betriebssystemdateien, die für das System-Image erforderlich sind
• [C-0-3] Die Daten MÜSSEN so gelöscht werden, dass die relevanten Branchenstandards wie NIST SP800-88 erfüllt werden.
• [C-0-4] MUSS den oben genannten Vorgang zum Zurücksetzen auf die Werkseinstellungen auslösen, wenn die DevicePolicyManager.wipeData() API von der Device Policy Controller App des primären Nutzers aufgerufen wird.
• MAY bietet möglicherweise eine Option zum schnellen Löschen von Daten an, bei der nur ein logisches Löschen von Daten durchgeführt wird.

9.13. Abgesicherter Startmodus

Android bietet den abgesicherten Modus, in dem nur vorinstallierte System-Apps ausgeführt werden dürfen und alle Drittanbieter-Apps deaktiviert sind. In diesem Modus, dem sogenannten „abgesicherten Startmodus“, können Nutzer potenziell schädliche Drittanbieter-Apps deinstallieren.

Geräteimplementierungen:

• [SR] Es wird DRINGEND EMPFOHLEN, den abgesicherten Modus zu implementieren.

Wenn Geräteimplementierungen den abgesicherten Bootmodus implementieren, gilt Folgendes:

• [C-1-1] Der Nutzer MUSS die Möglichkeit haben, den abgesicherten Modus so zu starten, dass er nicht durch auf dem Gerät installierte Drittanbieter-Apps unterbrochen wird, es sei denn, die Drittanbieter-App ist ein Gerätepolicy-Controller und hat das Flag UserManager.DISALLOW_SAFE_BOOT auf „true“ gesetzt.

• [C-1-2] Der Nutzer MUSS die Möglichkeit haben, alle Drittanbieter-Apps im abgesicherten Modus zu deinstallieren.

• Der Nutzer SOLLTE die Möglichkeit haben, über das Bootmenü in den abgesicherten Modus zu wechseln. Der Workflow dafür SOLLTE sich von dem eines normalen Starts unterscheiden.

9.14. Isolierung von Fahrzeugsystemen

Android Automotive-Geräte müssen Daten mit wichtigen Fahrzeugsubsystemen austauschen. Dazu wird die Fahrzeug-HAL verwendet, um Nachrichten über Fahrzeugnetzwerke wie den CAN-Bus zu senden und zu empfangen.

Der Datenaustausch kann durch die Implementierung von Sicherheitsfunktionen unter den Android-Framework-Ebenen gesichert werden, um böswillige oder unbeabsichtigte Interaktionen mit diesen Subsystemen zu verhindern.

10. Softwarekompatibilitätstests

Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen.

Kein Softwaretestpaket ist jedoch vollständig. Aus diesem Grund wird Geräteherstellern DRINGEND EMPFOHLEN, die Mindestanzahl an Änderungen an der Referenz- und bevorzugten Implementierung von Android vorzunehmen, die im Android Open Source Project verfügbar ist. Dadurch wird das Risiko minimiert, dass Fehler eingeführt werden, die Inkompatibilitäten verursachen, die eine Überarbeitung und potenzielle Geräteupdates erfordern.

10.1. Compatibility Test Suite

Geräteimplementierungen MÜSSEN die Android Compatibility Test Suite (CTS) bestehen, die im Android Open Source Project verfügbar ist. Dabei muss die endgültige Software auf dem Gerät verwendet werden. Außerdem SOLLTEN Geräteimplementierer die Referenzimplementierung im Android Open Source-Baum so weit wie möglich verwenden und MÜSSEN die Kompatibilität bei Unklarheiten im CTS und bei allen Neuimplementierungen von Teilen des Referenzquellcodes sicherstellen.

Das CTS ist für die Ausführung auf einem echten Gerät konzipiert. Wie jede Software kann auch das CTS Fehler enthalten. Das CTS wird unabhängig von dieser Kompatibilitätsdefinition versioniert und es können mehrere Überarbeitungen des CTS für Android 8.1 veröffentlicht werden. Geräteimplementierungen MÜSSEN die neueste CTS-Version bestehen, die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbar ist.

10.2. CTS‑Prüfung

Geräteimplementierungen MÜSSEN alle anwendbaren Fälle im CTS-Verifier korrekt ausführen. Der CTS-Verifier ist in der Compatibility Test Suite enthalten und soll von einem menschlichen Bediener ausgeführt werden, um Funktionen zu testen, die nicht von einem automatisierten System getestet werden können, z. B. die korrekte Funktion einer Kamera und von Sensoren.

Der CTS-Verifier enthält Tests für viele Arten von Hardware, einschließlich einiger optionaler Hardware. Geräteimplementierungen MÜSSEN alle Tests für die Hardware bestehen, die sie enthalten. Wenn ein Gerät beispielsweise einen Beschleunigungsmesser hat, MUSS es den Beschleunigungsmesser-Testfall im CTS-Verifier korrekt ausführen. Testläufe für Funktionen, die in diesem Kompatibilitätsdefinitionsdokument als optional gekennzeichnet sind, KÖNNEN übersprungen oder ausgelassen werden.

Auf jedem Gerät und in jedem Build MUSS der CTS-Verifier wie oben beschrieben korrekt ausgeführt werden. Da viele Builds jedoch sehr ähnlich sind, wird von Geräteimplementierern nicht erwartet, dass sie den CTS-Verifier explizit für Builds ausführen, die sich nur in geringfügigen Details unterscheiden. Insbesondere Geräteimplementierungen, die sich von einer Implementierung, die den CTS-Verifier bestanden hat, nur durch die Menge der enthaltenen Gebietsschemas, das Branding usw. unterscheiden, DÜRFEN den CTS-Verifier-Test auslassen.

11. Aktualisierbare Software

Geräteimplementierungen MÜSSEN einen Mechanismus zum Ersetzen der gesamten Systemsoftware enthalten. Der Mechanismus muss keine „Live“-Upgrades durchführen. Das heißt, ein Neustart des Geräts KANN erforderlich sein.

Es kann jede Methode verwendet werden, sofern damit die gesamte auf dem Gerät vorinstallierte Software ersetzt werden kann. Diese Anforderung kann beispielsweise auf folgende Weise erfüllt werden:

• „Over-the-Air“-Downloads (OTA) mit Offline-Update über Neustart.
• „Tethered“-Updates über USB von einem Host-PC.
• „Offline“-Updates über einen Neustart und ein Update über eine Datei auf einem Wechselspeicher.

Wenn die Geräteimplementierung jedoch die Unterstützung einer Datenverbindung ohne Volumenbegrenzung wie 802.11 oder Bluetooth PAN (Personal Area Network) umfasst, MUSS sie OTA-Downloads mit Offline-Update über Neustart unterstützen.

Der verwendete Aktualisierungsmechanismus MUSS Aktualisierungen ohne Löschen von Nutzerdaten unterstützen. Das heißt, der Aktualisierungsmechanismus MUSS private Anwendungsdaten und freigegebene Anwendungsdaten beibehalten. Die Upstream-Android-Software enthält einen Aktualisierungsmechanismus, der diese Anforderung erfüllt.

Bei Geräteimplementierungen, die mit Android 6.0 und höher eingeführt werden, SOLLTE der Aktualisierungsmechanismus unterstützen, dass das System-Image nach einer OTA-Aktualisierung binär mit dem erwarteten Ergebnis identisch ist. Die blockbasierte OTA-Implementierung im Upstream-Open-Source-Projekt für Android, die seit Android 5.1 hinzugefügt wurde, erfüllt diese Anforderung.

Außerdem SOLLTEN Geräteimplementierungen A/B-Systemupdates unterstützen. In AOSP wird diese Funktion mit dem Boot Control HAL implementiert.

Wenn nach der Veröffentlichung eines Geräts, aber innerhalb seiner angemessenen Produktlebensdauer, die in Absprache mit dem Android-Kompatibilitätsteam festgelegt wird, ein Fehler in der Geräteimplementierung gefunden wird, der die Kompatibilität von Drittanbieteranwendungen beeinträchtigt, MUSS der Geräteimplementierer den Fehler über ein Softwareupdate beheben, das gemäß dem gerade beschriebenen Mechanismus angewendet werden kann.

Android enthält Funktionen, mit denen die Geräteinhaber-App (falls vorhanden) die Installation von Systemupdates steuern kann. Dazu muss das Systemaktualisierungs-Subsystem für Geräte, die android.software.device_admin melden, das in der Klasse SystemUpdatePolicy beschriebene Verhalten implementieren.

12. Änderungsprotokoll des Dokuments

Eine Zusammenfassung der Änderungen an der Kompatibilitätsdefinition in dieser Version finden Sie hier:

• Änderungslog für Dokumente

Zusammenfassung der Änderungen an den einzelnen Abschnitten:

1. Einführung
2. Gerätetypen
3. Software
4. Anwendungspaketierung
5. Multimedia
6. Entwicklertools und ‑optionen
7. Hardwarekompatibilität
8. Leistung und Energie
9. Sicherheitsmodell
10. Softwarekompatibilität testen
11. Aktualisierbare Software
12. Dokument-Changelog
13. Kontakt

12.1. Tipps zum Ansehen des Änderungsprotokolls

Änderungen werden so gekennzeichnet:

• CDD
  Substantielle Änderungen an den Kompatibilitätsanforderungen.

• Docs
  Kosmetische oder buildbezogene Änderungen.

Für eine optimale Darstellung sollten Sie die URL-Parameter pretty=full und no-merges an die URLs Ihres Changelogs anhängen.

13. Kontakt

Sie können dem android-compatibility-Forum beitreten und um Klarstellungen bitten oder Probleme ansprechen, die Ihrer Meinung nach im Dokument nicht behandelt werden.