Kompatibilitätsdefinition für Android 9

1. Einführung

In diesem Dokument werden die Anforderungen aufgeführt, die erfüllt sein müssen, damit Geräte mit Android 9 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 9 entwickelt. Eine „Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte Hardware-/Softwarelösung.

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

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 ausgetauscht 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 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
  • Tab: Android-Tablet-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 „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.

1.1.3. Anforderungs-ID in Abschnitt 2

Die Anforderungs-ID in Abschnitt 2 beginnt mit der entsprechenden Abschnitts-ID, gefolgt von der oben beschriebenen Anforderungs-ID.

• Die ID in Abschnitt 2 besteht aus : Abschnitts-ID / Geräte-ID – Bedingungs-ID – Anforderungs-ID (z.B. 7.4.3/A-0-1).

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 für einige Gerätetypen gibt es ein relativ gut etabliertes Ökosystem für die App-Verteilung.

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-Handheldgerät 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 Bildschirmdiagonale muss zwischen 2,5 und 8 Zoll liegen.

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

2.2.1. Hardware

Implementierungen für Handheld-Geräte:

• [7.1.1.1/H-0-1] MÜSSEN ein Display mit einer physischen Diagonale von mindestens 2,5 Zoll haben.
• [7.1.1.3/H-SR] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, die Displaygröße zu ändern (Bildschirmdichte).

Wenn Handheld-Geräteimplementierungen über Configuration.isScreenHdr() Unterstützung für HDR-Displays (High Dynamic Range) beanspruchen , gilt Folgendes:

• [7.1.4.5/H-1-1] MUSS die Unterstützung für die Erweiterungen EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace und VK_EXT_hdr_metadata bewerben.

Implementierungen für Handheld-Geräte:

• [7.1.5/H-0-1] MUSS die Unterstützung für den Legacy-Anwendungskompatibilitätsmodus enthalten, wie er vom Upstream-Android-Quellcode implementiert wird. 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.
• [7.2.1/H-0-1] MUSS Unterstützung für IME-Apps (Input Method Editor) von Drittanbietern enthalten.
• [7.2.3/H-0-1] MÜSSEN die Funktionen „Home“, „Letzte“ und „Zurück“ bereitstellen.
• [7.2.3/H-0-2] MUSS sowohl das normale als auch das lange Drücken der Zurück-Funktion (KEYCODE_BACK) an die im Vordergrund ausgeführte Anwendung senden. Diese Ereignisse DÜRFEN NICHT vom System verarbeitet werden und KÖNNEN außerhalb des Android-Geräts ausgelöst werden (z.B. über eine externe Hardwaretastatur, die mit dem Android-Gerät verbunden ist).
• [7.2.4/H-0-1] MÜSSEN Touchscreen-Eingabe unterstützen.
• [7.2.4/H-SR] Es wird DRINGEND EMPFOHLEN, die vom Nutzer ausgewählte Assistenz-App, also die App, die VoiceInteractionService implementiert, oder eine Aktivität zu starten, die ACTION_ASSIST bei langem Drücken von KEYCODE_MEDIA_PLAY_PAUSE oder KEYCODE_HEADSETHOOK verarbeitet, wenn die Vordergrundaktivität diese Ereignisse bei langem Drücken nicht verarbeitet.
• [7.3.1/H-SR] Es wird DRINGEND EMPFOHLEN, einen 3‑Achsen-Beschleunigungsmesser einzubauen.

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

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

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

• [7.3.4/H-1-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz melden können.

Für Handheld-Geräteimplementierungen, mit denen Sprachanrufe getätigt werden können und die in getPhoneType einen anderen Wert als PHONE_TYPE_NONE angeben, gilt Folgendes:

• [7.3.8/H] SOLLTE einen Näherungssensor enthalten.

Implementierungen für Handheld-Geräte:

• [7.3.12/H-SR] Es wird EMPFOHLEN, den Lagesensor mit 6 Freiheitsgraden zu unterstützen.
• [7.4.3/H] SOLLTE Unterstützung für Bluetooth und Bluetooth LE enthalten.

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

• [7.4.7/H-1-1] MUSS den Datensparmodus bereitstellen.

Implementierungen für Handheld-Geräte:

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

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

• [7.6.1/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.

• [7.6.1/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.

• [7.6.1/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.

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

Wenn Handheld-Geräteimplementierungen die Unterstützung einer 64‑Bit-ABI (mit oder ohne 32‑Bit-ABI) deklarieren:

• [7.6.1/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.

• [7.6.1/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.

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

• [7.6.1/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 Kernel und Userspace verfügbarer Arbeitsspeicher“ bezieht sich auf den Arbeitsspeicher, der zusätzlich zu dem Arbeitsspeicher bereitgestellt wird, der bereits Hardwarekomponenten wie Funk und Video zugewiesen ist, die in Geräteimplementierungen nicht der Kontrolle des Kernels unterliegen.

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

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

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

• [7.6.1/H-10-1] MUSS mindestens 4 GB nicht flüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) zur Verfügung haben.
• SOLLTEN das Funktions-Flag android.hardware.ram.normal deklarieren.

Implementierungen für Handheld-Geräte:

• [7.6.2/H-0-1] MUSS einen gemeinsamen Speicher für Anwendungen mit einer Größe von mindestens 1 GiB bereitstellen.
• [7.7.1/H] SOLLTE einen USB-Port mit Unterstützung für den Peripheriemodus enthalten.

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

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

Implementierungen für Handheld-Geräte:

• [7.8.1/H-0-1] MUSS ein Mikrofon enthalten.
• [7.8.2/H-0-1] MÜSSEN eine Audioausgabe haben und android.hardware.audio.output deklarieren.

Wenn Implementierungen für Mobilgeräte alle Leistungsanforderungen für die Unterstützung des VR-Modus erfüllen und diesen unterstützen, gilt Folgendes:

• [7.9.1/H-1-1] MUSS das android.hardware.vr.high_performance-Funktions-Flag deklarieren.
• [7.9.1/H-1-2] MUSS eine Anwendung enthalten, die android.service.vr.VrListenerService implementiert und von VR-Anwendungen über android.app.Activity#setVrModeEnabled aktiviert werden kann.

2.2.2. Multimedia

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

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

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

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

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

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

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

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

2.2.3. Software

Implementierungen für Handheld-Geräte:

• [3.2.3.1/H-0-1] MUSS eine Anwendung haben, die die Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE und ACTION_CREATE_DOCUMENT wie in der SDK-Dokumentation beschrieben verarbeitet, und dem Nutzer die Möglichkeit bieten, über die DocumentsProvider API auf die Daten des Dokumentanbieters zuzugreifen.
• [3.4.1/H-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API bereitstellen.
• [3.4.2/H-0-1] MUSS eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten.
• [3.8.1/H-SR] Es wird DRINGEND EMPFOHLEN, einen Standard-Launcher zu implementieren, der das Anpinnen von Verknüpfungen, Widgets und widgetFeatures in der App unterstützt.
• [3.8.1/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.
• [3.8.1/H-SR] Es wird DRINGEND EMPFOHLEN, eine Standard-Launcher-App einzubinden, die Badges für die App-Symbole anzeigt.
• [3.8.2/H-SR] Es wird DRINGEND EMPFOHLEN, App-Widgets von Drittanbietern zu unterstützen.
• [3.8.3/H-0-1] MÜSSEN Drittanbieter-Apps Nutzern die Benachrichtigung über wichtige Ereignisse über die API-Klassen Notification und NotificationManager ermöglichen.
• [3.8.3/H-0-2] MÜSSEN Rich Notifications unterstützen.
• [3.8.3/H-0-3] MÜSSEN wichtige Benachrichtigungen unterstützen.
• [3.8.3/H-0-4] MUSS eine Benachrichtigungsleiste enthalten, über die der Nutzer Benachrichtigungen direkt steuern kann (z. B. antworten, verschieben, schließen, blockieren). Dazu müssen Nutzeraktionen wie Aktionsschaltflächen oder die in AOSP implementierte Steuerleiste möglich sein.
• [3.8.3/H-0-5] MUSS die über RemoteInput.Builder setChoices() bereitgestellten Optionen in der Benachrichtigungsleiste anzeigen.
• [3.8.3/H-SR] Es wird DRINGEND EMPFOHLEN, die erste über RemoteInput.Builder setChoices() bereitgestellte Auswahlmöglichkeit ohne zusätzliche Nutzerinteraktion im Benachrichtigungsfeld anzuzeigen.
• [3.8.3/H-SR] Es wird DRINGEND EMPFOHLEN, alle über RemoteInput.Builder setChoices() bereitgestellten Optionen in der Benachrichtigungsleiste anzuzeigen, wenn der Nutzer alle Benachrichtigungen in der Benachrichtigungsleiste maximiert.
• [3.8.4/H-SR] Es wird DRINGEND EMPFOHLEN, einen Assistenten auf dem Gerät zu implementieren, der die Assist-Aktion verarbeitet.

Wenn Implementierungen von Handheld-Geräten die Assist-Aktion unterstützen, gilt Folgendes:

• [3.8.4/H-SR] Es wird DRINGEND EMPFOHLEN, das lange Drücken der HOME-Taste als vorgesehene Interaktion zum Starten der Assist-App zu verwenden, wie in Abschnitt 7.2.3 beschrieben. Die vom Nutzer ausgewählte Assistenz-App, also die App, die VoiceInteractionService implementiert, oder eine Aktivität, die den ACTION_ASSIST-Intent verarbeitet, MUSS gestartet werden.

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

• [3.8.10/H-1-1] MÜSSEN die Sperrbildschirmbenachrichtigungen einschließlich der Medienbenachrichtigungsvorlage angezeigt werden.

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

• [3.9/H-1-1] MUSS die gesamte Bandbreite der in der Android SDK-Dokumentation definierten Richtlinien zur Geräteverwaltung implementieren.
• [3.9/H-1-2] 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.

Implementierungen für Handheld-Geräte:

• [3.10/H-0-1] MÜSSEN Barrierefreiheitsdienste von Drittanbietern unterstützen.
• [3.10/H-SR] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorab zu laden, die mit dem Schalterzugriff und TalkBack vergleichbar sind oder deren Funktionen übertreffen (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden), wie sie im TalkBack-Open-Source-Projekt bereitgestellt werden.
• [3.11/H-0-1] MUSS die Installation von Drittanbieter-TTS-Engines unterstützen.
• [3.11/H-SR] Es wird DRINGEND EMPFOHLEN, eine TTS-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
• [3.13/H-SR] Es wird DRINGEND EMPFOHLEN, eine UI-Komponente für die Schnelleinstellungen einzubinden.

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

• [3.16/H-1-1] MUSS die Funktion zur Kopplung von Begleitgeräten unterstützen.

2.2.4. Leistung und Energie

• [8.1/H-0-1] Gleichbleibende 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 unter 1 Frame pro Sekunde liegen.
• [8.1/H-0-2] Latenz der Benutzeroberfläche. Geräteimplementierungen MÜSSEN für eine geringe 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.
• [8.1/H-0-3] Task Switching (Aufgabenwechsel). Wenn mehrere Anwendungen gestartet wurden, muss das erneute Starten einer bereits laufenden Anwendung weniger als 1 Sekunde dauern.

Implementierungen für Handheld-Geräte:

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

Wenn Implementierungen für tragbare Geräte Funktionen zur Verbesserung der Energieverwaltung des Geräts enthalten, die in AOSP enthalten sind oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:

• [8.3/H-1-1] MUSS dem Nutzer die Möglichkeit geben, den Energiesparmodus zu aktivieren und zu deaktivieren.
• [8.3/H-1-2] MUSS eine Möglichkeit für Nutzer bieten, alle Apps anzuzeigen, die von den Stromsparmodi „App-Standby“ und „Stromsparmodus“ ausgenommen sind.

Implementierungen für Handheld-Geräte:

• [8.4/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.
• [8.4/H-0-2] MÜSSEN alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angegeben werden.
• [8.4/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.
• [8.4/H-0-4] MUSS diese Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.
• [8.4/H] 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:

• [8.4/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

Implementierungen für Handheld-Geräte:

• [9.1/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 bereitgestellt werden, mit dem der Zugriff auf solche Apps als Reaktion auf die Absicht android.settings.ACTION_USAGE_ACCESS_SETTINGS gewährt oder widerrufen werden kann.

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

• [9.11/H-1-1] Der Nutzer MUSS das kürzeste Zeitlimit für den Ruhemodus, d. h. die Übergangszeit vom entsperrten zum gesperrten Zustand, auf 15 Sekunden oder weniger festlegen können.
• [9.11/H-1-2] MUSS dem Nutzer die Möglichkeit bieten, Benachrichtigungen auszublenden und alle Formen der Authentifizierung mit Ausnahme der primären Authentifizierung gemäß 9.11.1 Sicherer Sperrbildschirm zu deaktivieren. AOSP erfüllt die Anforderung als Sperrmodus.

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 oder einen Videoausgang wie VGA, HDMI, DisplayPort oder einen drahtlosen Anschluss für die Anzeige haben.

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

2.3.1. Hardware

Implementierungen für Fernsehgeräte:

• [7.2.2/T-0-1] MUSS das Steuerkreuz unterstützen.
• [7.2.3/T-0-1] MÜSSEN die Funktionen „Home“ und „Zurück“ bereitstellen.
• [7.2.3/T-0-2] MUSS sowohl das normale als auch das Ereignis für langes Drücken der Zurück-Funktion (KEYCODE_BACK) an die im Vordergrund ausgeführte Anwendung senden.
• [7.2.6.1/T-0-1] MUSS Unterstützung für Gamecontroller enthalten und das android.hardware.gamepad-Feature-Flag deklarieren.
• [7.2.7/T] SOLLTE eine Fernbedienung enthalten, über die Nutzer auf Navigation ohne Touchbedienung und Eingaben über die wichtigsten Navigationstasten zugreifen können.

Wenn Fernsehgeräteimplementierungen ein Gyroskop enthalten, gilt Folgendes:

• [7.3.4/T-1-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz melden können.

Implementierungen für Fernsehgeräte:

• [7.4.3/T-0-1] MÜSSEN Bluetooth und Bluetooth LE unterstützen.
• [7.6.1/T-0-1] MUSS mindestens 4 GB nicht flüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition bezeichnet) bieten.

Wenn Fernsehgeräteimplementierungen einen USB-Anschluss enthalten, der den Hostmodus unterstützt, gilt Folgendes:

• [7.5.3/T-1-1] MUSS Unterstützung für eine externe Kamera enthalten, die über diesen USB-Anschluss verbunden wird, aber nicht unbedingt immer verbunden ist.

Wenn TV-Geräteimplementierungen 32 Bit haben:

• [7.6.1/T-1-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 896 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 400 dpi oder höher auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tv‑dpi oder höher auf besonders großen Bildschirmen

Wenn TV-Geräteimplementierungen 64-Bit-fähig sind:

• [7.6.1/T-2-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.280 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 400 dpi oder höher auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tv‑dpi oder höher auf besonders großen Bildschirmen

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

Implementierungen von Fernsehgeräten:

• [7.8.1/T] SOLLTE ein Mikrofon enthalten.
• [7.8.2/T-0-1] MÜSSEN eine Audioausgabe haben und android.hardware.audio.output deklarieren.

2.3.2. Multimedia

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

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

Implementierungen von Fernsehgeräten MÜSSEN die folgenden Video-Codierungsformate unterstützen:

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

Implementierungen für Fernsehgeräte:

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

Implementierungen von Fernsehgeräten MÜSSEN die folgenden Videodecodierungsformate unterstützen:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9

Es wird DRINGEND EMPFOHLEN, dass Fernsehgeräteimplementierungen die folgenden Videodecodierungsformate unterstützen:

• [5.3.1/T-SR] MPEG-2

Implementierungen auf Fernsehgeräten MÜSSEN die H.264-Decodierung unterstützen, wie in Abschnitt 5.3.4 beschrieben, bei Standard-Videobildraten und Auflösungen bis einschließlich:

• [5.3.4.4/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Baseline-Profil
• [5.3.4.4/T-1-2] HD 1080p bei 60 Bildern pro Sekunde mit Main Profile
• [5.3.4.4/T-1-3] HD 1080p bei 60 Bildern pro Sekunde mit High Profile Level 4.2

Implementierungen von Fernsehgeräten mit H.265-Hardwaredecodern MÜSSEN die H.265-Decodierung gemäß Abschnitt 5.3.5 bei Standard-Videobildraten und ‑auflösungen bis einschließlich der folgenden unterstützen:

• [5.3.5.4/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Main Profile Level 4.1

Wenn Fernsehgeräte mit H.265-Hardwaredecodern die H.265-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:

• [5.3.5.5/T-2-1] MUSS das UHD-Decodierungsprofil mit 60 Bildern pro Sekunde mit dem Main10-Profil der Main-Tier-Stufe 5 unterstützen.

Implementierungen von Fernsehgeräten MÜSSEN die VP8-Decodierung gemäß Abschnitt 5.3.6 bei Standard-Videobildraten und Auflösungen bis einschließlich:

• [5.3.6.4/T-1-1] HD 1080p bei 60 Bildern pro Sekunde (fps) – Dekodierungsprofil

Implementierungen von Fernsehgeräten mit VP9-Hardware-Decodern MÜSSEN die VP9-Decodierung gemäß Abschnitt 5.3.7 bei Standard-Videobildraten und ‑auflösungen bis einschließlich der folgenden unterstützen:

• [5.3.7.4/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Profil 0 (8-Bit-Farbtiefe)

Wenn Fernsehgeräteimplementierungen mit VP9-Hardware-Decodern die VP9-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:

• [5.3.7.5/T-2-1] MUSS das UHD-Decodierungsprofil mit 60 Bildern pro Sekunde mit Profil 0 (8-Bit-Farbtiefe) unterstützen.
• [5.3.7.5/T-2-1] Es wird DRINGEND EMPFOHLEN, das UHD-Decodierungsprofil mit 60 Bildern pro Sekunde mit Profil 2 (10 Bit Farbtiefe) zu unterstützen.

Implementierungen von Fernsehgeräten:

• [5.5.3/T-0-1] MUSS die Unterstützung für die Systemlautstärke und die Lautstärkeanpassung der digitalen Audioausgabe auf unterstützten Ausgängen enthalten, mit Ausnahme der Ausgabe für die Passthrough-Funktion für komprimiertes Audio (bei der keine Audiodecodierung auf dem Gerät erfolgt).
• [5.8/T-0-1] Der HDMI-Ausgabemodus MUSS so eingestellt werden, dass die maximale Auflösung ausgewählt wird, die mit einer Bildwiederholfrequenz von 50 Hz oder 60 Hz für alle kabelgebundenen Displays unterstützt werden kann.
• [5.8/T-SR] Es wird DRINGEND EMPFOHLEN, für alle kabelgebundenen Displays eine vom Nutzer konfigurierbare Auswahl für die HDMI-Aktualisierungsrate bereitzustellen.
• [5.8/T-SR] Es wird DRINGEND EMPFOHLEN, die gleichzeitige Decodierung von sicheren Streams zu unterstützen. Die gleichzeitige Dekodierung von mindestens zwei Streams wird DRINGEND EMPFOHLEN.
• [5.8] SOLLTE die Aktualisierungsrate des HDMI-Ausgangsmodus für alle kabelgebundenen Displays auf 50 Hz oder 60 Hz eingestellt werden, je nach der Aktualisierungsrate des Videos für die Region, in der das Gerät verkauft wird.

Wenn Fernsehgeräteimplementierungen die UHD-Decodierung unterstützen und externe Displays unterstützt werden, gilt Folgendes:

• [5.8/T-1-1] MUSS HDCP 2.2 unterstützen.

Wenn Fernsehgeräteimplementierungen die UHD-Decodierung nicht unterstützen, aber Unterstützung für externe Displays bieten, gilt Folgendes:

• [5.8/T-2-1] MUSS HDCP 1.4 unterstützen

2.3.3. Software

Implementierungen von Fernsehgeräten:

• [3/T-0-1] MÜSSEN die Funktionen android.software.leanback und android.hardware.type.television deklarieren.
• [3.4.1/T-0-1] MUSS eine vollständige Implementierung der android.webkit.Webview API bereitstellen.

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

• [3.8.10/T-1-1] MÜSSEN die Benachrichtigungen auf dem Sperrbildschirm einschließlich der Medienbenachrichtigungsvorlage angezeigt werden.

Implementierungen für Fernsehgeräte:

• [3.8.14/T-SR] Es wird DRINGEND EMPFOHLEN, den Bild-im-Bild-Modus (BiB) im Multi-Window-Modus zu unterstützen.
• [3.10/T-0-1] MÜSSEN Barrierefreiheitsdienste von Drittanbietern unterstützen.
• [3.10/T-SR] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorab zu laden, die mit dem Schalterzugriff und TalkBack vergleichbar sind oder deren Funktionen übertreffen (für Sprachen, die von der vorinstallierten Sprachausgabe unterstützt werden), wie sie im TalkBack-Open-Source-Projekt bereitgestellt werden.

Wenn Fernsehgeräte die Funktion android.hardware.audio.output melden, gilt Folgendes:

• [3.11/T-SR] Es wird DRINGEND EMPFOHLEN, eine TTS-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
• [3.11/T-1-1] MUSS die Installation von Drittanbieter-Sprachausgabe-Engines unterstützen.

Implementierungen für Fernsehgeräte:

• [3.12/T-0-1] MÜSSEN das TV Input Framework unterstützen.

2.3.4. Leistung und Energie

• [8.1/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 unter 1 Frame pro Sekunde liegen.
• [8.2/T-0-1] MUSS eine sequenzielle Schreibleistung von mindestens 5 MB/s gewährleisten.
• [8.2/T-0-2] MUSS eine zufällige Schreibleistung von mindestens 0,5 MB/s bieten.
• [8.2/T-0-3] MUSS eine sequenzielle Leseleistung von mindestens 15 MB/s gewährleisten.
• [8.2/T-0-4] MUSS eine zufällige Leseleistung von mindestens 3,5 MB/s gewährleisten.

Wenn Implementierungen von Fernsehgeräten Funktionen zur Verbesserung der Energieverwaltung des Geräts enthalten, die in AOSP enthalten sind oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:

• [8.3/T-1-1] MUSS dem Nutzer die Möglichkeit geben, den Energiesparmodus zu aktivieren und zu deaktivieren.
• [8.3/T-1-2] Nutzer müssen die Möglichkeit haben, alle Apps anzuzeigen, die von den Stromsparmodi „App-Standby“ und „Stromsparmodus“ ausgenommen sind.

Implementierungen für Fernsehgeräte:

• [8.4/T-0-1] MUSS ein Energieprofil pro Komponente bereitstellen, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch der Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.
• [8.4/T-0-2] MÜSSEN alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angegeben werden.
• [8.4/T-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.
• [8.4/T] Sollte der Hardwarekomponente selbst zugewiesen werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugewiesen werden kann.
• [8.4/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:

• Das Display 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

Smartwatch-Geräteimplementierungen:

• [7.1.1.1/W-0-1] MÜSSEN ein Display mit einer physischen Diagonalen von 1,1 bis 2,5 Zoll haben.

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

• [7.2.4/W-0-1] MÜSSEN Touchscreen-Eingabe unterstützen.

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

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

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

• [7.6.1/W-0-2] MÜSSEN mindestens 416 MB Arbeitsspeicher für den Kernel und den Nutzerbereich zur Verfügung haben.

• [7.8.1/W-0-1] MÜSSEN ein Mikrofon enthalten.

• [7.8.2/W] MAY but SHOULD NOT have audio output.

2.4.2. Multimedia

Keine zusätzlichen Anforderungen.

2.4.3. Software

Smartwatch-Geräteimplementierungen:

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

Smartwatch-Geräteimplementierungen:

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

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

• [3.10/W-1-1] MUSS Barrierefreiheitsdienste von Drittanbietern unterstützen.
• [3.10/W-SR] Es wird DRINGEND EMPFOHLEN, Bedienungshilfen auf dem Gerät vorab zu laden, 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.

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

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

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

2.4.4. Leistung und Energie

Wenn Watch-Geräteimplementierungen Funktionen zur Verbesserung der Geräte-Energieverwaltung enthalten, die in AOSP enthalten sind oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:

• [8.3/W-SR] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, alle Apps anzuzeigen, die von den Energiesparmodi „App-Standby“ und „Doze“ ausgenommen sind.
• [8.3/W-SR] Es wird DRINGEND EMPFOHLEN, dem Nutzer die Möglichkeit zu geben, den Energiesparmodus zu aktivieren und zu deaktivieren.

Smartwatch-Geräteimplementierungen:

• [8.4/W-0-1] Es MUSS ein Energieprofil für jede 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.
• [8.4/W-0-2] MÜSSEN alle Werte zum Stromverbrauch in Milliamperestunden (mAh) angegeben werden.
• [8.4/W-0-3] Der CPU-Stromverbrauch muss für die UID jedes Prozesses angegeben werden. Das Open-Source-Projekt für Android erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• [8.4/W-0-4] MUSS diese Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.
• [8.4/W] SOLLTE der Hardwarekomponente selbst zugeschrieben werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.

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

Automotive-Geräteimplementierungen:

• [7.1.1.1/A-0-1] MUSS ein Display mit einer physischen Diagonale von mindestens 6 Zoll haben.

• [7.1.1.1/A-0-2] MUSS ein Layout mit einer Bildschirmgröße von mindestens 750 dp × 480 dp haben.

• [7.2.3/A-0-1] MUSS die Home-Funktion bereitstellen und DARF die Zurück- und die Letzte-Funktion bereitstellen.

• [7.2.3/A-0-2] MÜSSEN sowohl das normale als auch das Ereignis für langes Drücken der Zurück-Funktion (KEYCODE_BACK) an die Vordergrundanwendung senden.

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

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

• [7.3.1/A-1-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz melden können.
• [7.3.1/A-1-2] MUSS dem Koordinatensystem für Autosensoren von Android entsprechen.

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

• [7.3.4/A-1-1] MUSS Ereignisse mit einer Häufigkeit von mindestens 100 Hz melden können.

Automotive-Geräteimplementierungen:

• [7.3.11/A-0-1] MUSS den aktuellen Gang als SENSOR_TYPE_GEAR angeben.

Automotive-Geräteimplementierungen:

• [7.3.11.2/A-0-1] MUSS den Tag-/Nachtmodus unterstützen, der als SENSOR_TYPE_NIGHT definiert ist.
• [7.3.11.2/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 KANN derselbe wie beim Photometer sein.

• [7.3.11.4/A-0-1] MUSS die Fahrzeuggeschwindigkeit gemäß SENSOR_TYPE_CAR_SPEED angeben.

• [7.3.11.5/A-0-1] MUSS den Status der Feststellbremse gemäß SENSOR_TYPE_PARKING_BRAKE angeben.

• [7.4.3/A-0-1] MÜSSEN Bluetooth unterstützen und SOLLTEN Bluetooth LE unterstützen.

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

• [7.4.3/A-SR] Es wird DRINGEND EMPFOHLEN, das Message Access Profile (MAP) zu unterstützen.

• [7.4.5/A] SOLLTE die Unterstützung für datenbasierte Mobilfunknetzverbindungen enthalten.

• [7.4.5/A] MAY use the System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID constant for networks that should be available to system apps.

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

Automotive-Geräteimplementierungen:

• [7.6.1/A] SOLLTE die Datenpartition formatieren, um die Leistung und Lebensdauer des Flash-Speichers zu verbessern, z. B. mit dem f2fs-Dateisystem.

Wenn Automotive-Geräteimplementierungen freigegebenen externen Speicher über einen Teil des internen, nicht entfernbaren Speichers bereitstellen, gilt Folgendes:

• [7.6.1/A-SR] Es wird DRINGEND EMPFOHLEN, den E/A-Aufwand bei Vorgängen, die auf dem externen Speicher ausgeführt werden, zu reduzieren, z. B. durch die Verwendung von SDCardFS.

Wenn Automotive-Geräteimplementierungen 32-Bit-Implementierungen sind:

• [7.6.1/A-1-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 512 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 280 dpi oder weniger auf kleinen/normalen Bildschirmen
  • ldpi oder niedriger auf extragroßen Bildschirmen
  • mdpi oder niedriger auf großen Bildschirmen

• [7.6.1/A-1-2] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 608 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • xhdpi oder höher auf kleinen/normalen Bildschirmen
  • hdpi oder höher auf großen Bildschirmen
  • mdpi oder höher auf besonders großen Bildschirmen

• [7.6.1/A-1-3] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 896 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 400 dpi oder höher auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tv‑dpi oder höher auf besonders großen Bildschirmen

• [7.6.1/A-1-4] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.344 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 560 dpi oder höher auf kleinen/normalen Bildschirmen
  • 400 dpi oder höher auf großen Bildschirmen
  • xhdpi oder höher auf extragroßen Bildschirmen

Wenn Automotive-Geräteimplementierungen 64-Bit-Implementierungen sind:

• [7.6.1/A-2-1] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 816 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 280 dpi oder weniger auf kleinen/normalen Bildschirmen
  • ldpi oder niedriger auf extragroßen Bildschirmen
  • mdpi oder niedriger auf großen Bildschirmen

• [7.6.1/A-2-2] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 944 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • xhdpi oder höher auf kleinen/normalen Bildschirmen
  • hdpi oder höher auf großen Bildschirmen
  • mdpi oder höher auf besonders großen Bildschirmen

• [7.6.1/A-2-3] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.280 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 400 dpi oder höher auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tv‑dpi oder höher auf besonders großen Bildschirmen

• [7.6.1/A-2-4] Der für den Kernel und den Nutzerbereich verfügbare Arbeitsspeicher MUSS mindestens 1.824 MB betragen, wenn eine der folgenden Dichten verwendet wird:

  • 560 dpi oder höher auf kleinen/normalen Bildschirmen
  • 400 dpi oder höher auf großen Bildschirmen
  • xhdpi oder höher auf extragroßen Bildschirmen

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

Automotive-Geräteimplementierungen:

• [7.7.1/A] SOLLTE einen USB-Port enthalten, der den Peripheriemodus unterstützt.

Automotive-Geräteimplementierungen:

• [7.8.1/A-0-1] MUSS ein Mikrofon enthalten.

Automotive-Geräteimplementierungen:

• [7.8.2/A-0-1] MÜSSEN eine Audioausgabe haben und android.hardware.audio.output deklarieren.

2.5.2. Multimedia

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

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

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

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

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

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

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

• [5.3/A-SR] H.265 HEVC

2.5.3. Software

Automotive-Geräteimplementierungen:

• [3/A-0-1] MÜSSEN die Funktion android.hardware.type.automotive deklarieren.

• [3/A-0-2] MÜSSEN uiMode = UI_MODE_TYPE_CAR unterstützen.

• [3/A-0-3] MÜSSEN alle öffentlichen APIs im Namespace android.car.* unterstützen.

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

• [3.8.3/A-0-1] MÜSSEN Benachrichtigungen angezeigt werden, die die Notification.CarExtender API verwenden, wenn sie von Drittanbieteranwendungen angefordert werden.

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

• [3.13/A-SR] Es wird DRINGEND EMPFOHLEN, eine Komponente für die Schnelleinstellungen zu verwenden.

Wenn Automotive-Geräteimplementierungen eine Push-to-Talk-Taste enthalten, gilt Folgendes:

• [3.8.4/A-1-1] MUSS ein kurzer Druck auf die Push-to-Talk-Taste als die vorgesehene Interaktion zum Starten der vom Nutzer ausgewählten Assistenz-App verwendet werden, d. h. der App, die VoiceInteractionService implementiert.

Automotive-Geräteimplementierungen:

• [3.14/A-0-1] MUSS ein UI-Framework enthalten, um Drittanbieter-Apps zu unterstützen, die die Media APIs gemäß Abschnitt 3.14 verwenden.

2.5.4. Leistung und Energie

Wenn Automotive-Geräteimplementierungen Funktionen zur Verbesserung der Geräte-Energieverwaltung enthalten, die in AOSP enthalten sind oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:

• [8.3/A-1-1] MUSS dem Nutzer die Möglichkeit bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.
• [8.3/A-1-2] MUSS eine Möglichkeit für Nutzer bieten, alle Apps anzuzeigen, die von den Stromsparmodi „App-Standby“ und „Stromsparmodus“ ausgenommen sind.

Automotive-Geräteimplementierungen:

• [8.2/A-0-1] MUSS die Anzahl der Byte, die pro UID jedes Prozesses in den nichtflüchtigen Speicher gelesen und geschrieben wurden, melden, damit die Statistiken Entwicklern über die System-API android.car.storagemonitoring.CarStorageMonitoringManager zur Verfügung stehen. Das Open-Source-Projekt für Android erfüllt die Anforderung durch das uid_sys_stats-Kernelmodul.
• [8.4/A-0-1] MUSS ein Energieprofil pro Komponente bereitstellen, das den Stromverbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch der Komponenten im Zeitverlauf definiert, wie auf der Android Open Source Project-Website dokumentiert.
• [8.4/A-0-2] MÜSSEN alle Werte für den Stromverbrauch in Milliamperestunden (mAh) angegeben werden.
• [8.4/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.
• [8.4/A] Sollte der Hardwarekomponente selbst zugeschrieben werden, wenn die Leistungsaufnahme der Hardwarekomponente nicht einer Anwendung zugeordnet werden kann.
• [8.4/A-0-4] MUSS diese Stromnutzung dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.

2.5.5. Sicherheitsmodell

Wenn Automotive-Geräteimplementierungen mehrere Nutzer unterstützen, gilt Folgendes:

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

Wenn Automotive-Geräteimplementierungen einen sicheren Sperrbildschirm unterstützen, gilt Folgendes:

• [9.9.2/A-1-1] MUSS die Verschlüsselung mit nutzerspezifischen Authentifizierungsschlüsseln unterstützen. Eine Möglichkeit ist die dateibasierte Verschlüsselung (File-Based Encryption, FBE).

Automotive-Geräteimplementierungen:

• [9.14/A-0-1] MÜSSEN Nachrichten von Fahrzeug-Subsystemen des Android-Frameworks filtern, z.B. durch Zulassen von zulässigen Nachrichtentypen und Nachrichtenquellen.
• [9.14/A-0-2] MUSS vor Denial-of-Service-Angriffen durch das Android-Framework oder Drittanbieter-Apps schützen. Dies schützt vor schädlicher Software, die das Fahrzeugnetzwerk mit Traffic überflutet, was zu Fehlfunktionen von Fahrzeugsubsystemen führen kann.

2.6. Tablet-Anforderungen

Ein Android-Tablet ist eine Android-Geräteimplementierung, die alle folgenden Kriterien erfüllt:

• Wird normalerweise mit beiden Händen gehalten.
• Das Gerät hat kein Clamshell- oder Convertible-Design.
• Jede physische Tastatur, die mit dem Gerät verwendet wird, MUSS über eine Standardverbindung angeschlossen werden.
• Das Gerät hat eine Stromquelle, die Mobilität ermöglicht, z. B. einen Akku.
• Die physische Bildschirmdiagonale liegt zwischen 7 und 18 Zoll.

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

• [7.1.1.1/Tab-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 Tablet-Geräteimplementierungen einen USB-Anschluss enthalten, der den Peripheriemodus unterstützt, gilt Folgendes:

• [7.7.1/Tab] 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.

Geräteimplementierungen:

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

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

• [C-0-3] Es DÜRFEN keine verwalteten APIs ausgelassen, API-Schnittstellen oder ‑Signaturen geändert, vom dokumentierten Verhalten abgewichen oder No-Ops eingeschlossen werden, sofern dies nicht ausdrücklich in dieser Kompatibilitätsdefinition zulässig ist.

• [C-0-4] Die APIs MÜSSEN weiterhin vorhanden sein 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.

• [C-0-5] Die Verwendung ausgeblendeter APIs durch Drittanbieter-Apps MUSS eingeschränkt werden. Ausgeblendete APIs sind APIs im Android-Namespace, die mit der Annotation @hidden, aber nicht mit @SystemAPI oder @TestApi versehen sind. Die Einschränkung muss wie in der SDK-Dokumentation beschrieben erfolgen. Außerdem muss jede ausgeblendete API in denselben eingeschränkten Listen enthalten sein, die über die Dateien mit der vorläufigen Liste und der Sperrliste im Pfad prebuilts/runtime/appcompat/ für den entsprechenden API-Level-Zweig im AOSP bereitgestellt werden. Allerdings:

  • MAY: Wenn eine verborgene API in der Geräteimplementierung fehlt oder anders implementiert ist, verschieben Sie sie in die Sperrliste oder lassen Sie sie in allen eingeschränkten Listen weg.
  • MAY: Wenn eine verborgene API noch nicht im AOSP vorhanden ist, fügen Sie sie einer der eingeschränkten Listen hinzu.
  • Es KANN ein dynamischer Aktualisierungsmechanismus implementiert werden, der eine verborgene API aus einer eingeschränkten Liste in eine weniger eingeschränkte Liste verschiebt, mit Ausnahme der Zulassungsliste.

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, auf denen API-Level 24 ausgeführt wird, MUSS mindestens Version 1 enthalten sein.

3.1.2. Android-Bibliothek

Aufgrund der Einstellung des Apache HTTP-Clients gilt für Geräteimplementierungen Folgendes:

• [C-0-1] Die org.apache.http.legacy-Bibliothek DARF NICHT im Bootclasspath platziert werden.
• [C-0-2] MUSS die org.apache.http.legacy-Bibliothek nur dann dem Classpath der Anwendung hinzugefügt werden, wenn die App eine der folgenden Bedingungen erfüllt:
  • Die App ist auf API-Level 28 oder niedriger ausgerichtet.
  • In seinem Manifest wird deklariert, dass die Bibliothek benötigt wird, indem das Attribut android:name von <uses-library> auf org.apache.http.legacy gesetzt wird.

Die AOSP-Implementierung erfüllt diese Anforderungen.

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 unter anderem 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 9 definierten Stringwerte enthalten.
VERSION.SDK	Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Drittanbieter-Anwendungscode zugreifen kann. Unter Android 9 MUSS dieses Feld den Ganzzahlwert 9_INT haben.
VERSION.SDK_INT	Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Drittanbieter-Anwendungscode zugreifen kann. Unter Android 9 MUSS dieses Feld den Ganzzahlwert 9_INT haben.
VERSION.INCREMENTAL	Ein vom Geräteimplementierer 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 Compatibility.
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 identifiziert. 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:9/LMYXX/3359:userdebug/test-keys Der Fingerabdruck darf keine Leerzeichen enthalten. Wenn andere Felder in der Vorlage oben Leerzeichen enthalten, MÜSSEN diese in der Build-Signatur 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 (SKU) enthält. Dieser MUSS innerhalb derselben Marke eindeutig sein. MUSS für Menschen lesbar 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	MUSS „UNKNOWN“ zurückgeben.
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 enthalten, 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 einem definierten String entsprechen, 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.
getSerial()	MUSS eine Hardware-Seriennummer sein oder zurückgeben, die für Geräte mit demselben MODELL und HERSTELLER verfügbar und eindeutig sein MUSS. Der Wert dieses Felds MUSS als 7-Bit-ASCII 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 gängige 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, MÜSSEN Geräteimplementierungen es ermöglichen, dass jedes in Abschnitt 3.2.3.1 referenzierte Intent-Muster, mit Ausnahme von Einstellungen, von Drittanbieteranwendungen überschrieben werden kann. 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 eine Bindung an diese Muster herstellen 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 Validierungsschritte ausgeführt werden, die in der Digital Asset Links-Spezifikation definiert sind, wie sie vom Paketmanager im Upstream-Android Open Source Project implementiert werden.
• [C-0-5] MUSS versuchen, die Intent-Filter während der Installation der Anwendung zu validieren, und alle erfolgreich validierten URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen.
• 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 Nutzern die Möglichkeit, ihre Standardanwendungen auszuwählen, z. B. für den Startbildschirm oder SMS.

Sofern sinnvoll, MUSS in Geräteimplementierungen ein ähnliches Einstellungsmenü vorhanden sein und die Geräte müssen mit dem Intent-Filtermuster und den API-Methoden kompatibel sein, 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.

  • Die Benutzeroberfläche der vom Nutzer ausgewählten Standard-Telefonie-App MUSS für eingehende und ausgehende Anrufe verwendet werden, mit Ausnahme von Notrufen, für die die vorinstallierte Telefonie-App verwendet wird.

• [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ü „Anrufe“ in den Einstellungen 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, eine Nutzersteuerung, mit der 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. Jeder kann eine Anzeige auf einem Display mit dem Flag android.view.Display.FLAG_PUBLIC starten.

3.3 Kompatibilität mit nativen APIs

Die Kompatibilität mit nativem Code ist eine Herausforderung. 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-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] MUSS über die oben genannten Parameter eine Teilmenge der folgenden Liste von ABIs melden und DARF keine ABI melden, die nicht in der Liste enthalten ist.

  • armeabi
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

  • [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)
  • libneuralnetworks.so (Neural Networks API)
  • 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] Die oben aufgeführten öffentlichen Funktionen für die nativen Bibliotheken dürfen NICHT hinzugefügt oder entfernt werden.

• [C-0-9] Zusätzliche Nicht-AOSP-Bibliotheken, die direkt für Drittanbieter-Apps verfügbar sind, 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 gemacht werden, da sie 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 wichtigsten Vulkan 1.0-Funktionssymbole 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-Projekt verfügbar sind

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

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

Wenn Geräteimplementierungen die Unterstützung des armeabi-ABI melden, gilt Folgendes:

• [C-3-1] MUSS auch armeabi-v7a unterstützen und die Unterstützung melden, da armeabi nur zur Abwärtskompatibilität mit älteren Apps dient.

Wenn Geräteimplementierungen die Unterstützung der armeabi-v7a-ABI melden, gilt für Apps, die diese ABI verwenden:

• [C-2-1] MUSS die folgenden Zeilen in /proc/cpuinfo enthalten und SOLLTE die Werte auf demselben Gerät nicht ändern, auch wenn sie von anderen ABIs gelesen werden.

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

• [C-2-2] Die folgenden Vorgänge MÜSSEN immer verfügbar sein, auch wenn das ABI auf einer ARMv8-Architektur implementiert ist, entweder durch native CPU-Unterstützung oder durch Software-Emulation:

  • Anleitungen für SWP und SWPB
  • SETEND-Anweisung.
  • CP15ISB-, CP15DSB- und CP15DMB-Barriereoperationen.

• [C-2-3] MUSS die Advanced SIMD-Erweiterung (auch NEON) unterstützen.

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] Die Implementierung der android.webkit.WebView API MUSS auf dem Chromium-Projekt-Build aus dem Upstream-Android-Open-Source-Projekt im Android 9-Branch basieren.

• [C-1-3] Der vom WebView gemeldete User-Agent-String MUSS folgendes 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 String $(MODEL) KANN leer sein. Wenn er nicht leer ist, MUSS er denselben Wert wie android.os.Build.MODEL haben.
  • „Build/$(BUILD)“ KANN ausgelassen werden. Wenn es jedoch vorhanden ist, MUSS der String „$(BUILD)“ 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 folgende Anforderungen erfüllen:

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

Geräteimplementierungen:

• [C-0-9] MUSS dafür sorgen, dass die API-Verhaltenskompatibilität für alle installierten Apps angewendet wird, sofern sie nicht wie in Abschnitt 3.5.1 beschrieben eingeschränkt sind.
• [C-0-10] Das Zulassungslistenverfahren, das die API-Verhaltenskompatibilität nur für Apps gewährleistet, die von Geräteimplementierern ausgewählt werden, DARF NICHT implementiert werden.

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-Intention 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 keine Broadcast-Empfänger für die impliziten Broadcasts von Standard-Android-Intents im App-Manifest registriert werden, es sei denn, für den Broadcast-Intent ist eine "signature"- oder "signatureOrSystem"-Berechtigung 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.
• [C-0-9] Geräte MÜSSEN die folgenden Sicherheitsanbieter als die ersten sieben Arraywerte der Methode Security.getProviders() in der angegebenen Reihenfolge und mit den angegebenen Namen (wie von Provider.getName() zurückgegeben) und Klassen zurückgeben, sofern die Liste nicht von der App über insertProviderAt() oder removeProvider() geändert wurde. Geräte KÖNNEN nach der unten angegebenen Liste zusätzlicher Anbieter zurückgeben.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC: com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

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.5.1. Einschränkung der Hintergrundnutzung

Wenn Geräteimplementierungen die in AOSP enthaltenen App-Einschränkungen implementieren oder erweitern, gilt Folgendes:

• [C-SR] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, die Liste der eingeschränkten Apps einzusehen.
• [C-1-2] MUSS dem Nutzer die Möglichkeit bieten, die Einschränkungen für jede App zu aktivieren bzw. zu deaktivieren.
• [C-1-3] Einschränkungen dürfen nicht automatisch ohne Nachweis eines schlechten Systemstatus angewendet werden. Sie DÜRFEN jedoch auf Apps angewendet werden, wenn ein schlechter Systemstatus wie blockierte Wakelocks, Dienste mit langer Laufzeit und andere Kriterien erkannt werden. Die Kriterien KÖNNEN von Geräteherstellern festgelegt werden, MÜSSEN sich aber auf die Auswirkungen der App auf den Systemzustand beziehen. Andere Kriterien, die nicht ausschließlich mit dem Systemzustand zusammenhängen, z. B. die mangelnde Beliebtheit der App auf dem Markt, DÜRFEN NICHT als Kriterien verwendet werden.
• [C-1-4] App-Einschränkungen dürfen nicht automatisch für Apps angewendet werden, wenn ein Nutzer App-Einschränkungen manuell deaktiviert hat. Der Nutzer kann jedoch aufgefordert werden, App-Einschränkungen anzuwenden.
• [C-1-5] MUSS Nutzer informieren, wenn App-Einschränkungen automatisch auf eine App angewendet werden.
• [C-1-6] MUSS für ActivityManager.isBackgroundRestricted() true zurückgeben, wenn die eingeschränkte App diese API aufruft.
• [C-1-7] Die oberste Vordergrund-App, die vom Nutzer explizit verwendet wird, DARF NICHT eingeschränkt werden.
• [C-1-8] Einschränkungen für eine App, die zur wichtigsten Vordergrund-App wird, MÜSSEN aufgehoben werden, wenn der Nutzer explizit beginnt, die App zu verwenden, die zuvor eingeschränkt war.

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.*
• androidx.*
• 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 den APIs in den oben genannten Namespaces KEINE öffentlich zugänglichen Elemente (z. B. Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) oder Test- oder System-APIs 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 er source.android.com aufrufen und gemäß den Informationen auf dieser Website mit dem Prozess zum Beitragen von Änderungen und Code beginnen.

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.

• Fuzz-Tests SOLLTEN 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 Apps unterstützt, gilt Folgendes:

• [C-2-1] MÜSSEN true für ShortcutManager.isRequestPinShortcutSupported() melden.
• [C-2-2] Es MUSS eine Nutzeraufforderung geben, in der der Nutzer gefragt wird, bevor eine von Apps über die API-Methode ShortcutManager.requestPinShortcut() angeforderte Verknüpfung 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() berücksichtigen. 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 überschreibt die App-Symbol-Badges mit dem eigenen Badging-Schema, wenn Drittanbieteranwendungen die Unterstützung des eigenen Badging-Schemas durch die Verwendung eigener APIs angeben. SHOULD verwendet die Ressourcen und Werte, die über die in dem SDK beschriebenen Benachrichtigungs-Badges-APIs bereitgestellt werden, z. B. die Notification.Builder.setNumber()- und die 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 in der Standardrastergröße 4 × 4 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] Es MUSS eine Nutzeraufforderung geben, in der der Nutzer gefragt wird, bevor eine von Apps über die API-Methode AppWidgetManager.requestPinAppWidget() angeforderte Verknüpfung 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] Die für die APIs beschriebenen Verhaltensweisen zum Aktualisieren, Entfernen und Gruppieren von Benachrichtigungen MÜSSEN eingehalten und ordnungsgemäß implementiert werden.
• [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.
• [C-1-7] ALLE über Notification.MessagingStyle bereitgestellten Ressourcen (Bilder, Sticker, Symbole usw.) MÜSSEN zusammen mit dem Benachrichtigungstext ohne zusätzliche Nutzerinteraktion korrekt gerendert werden. Beispielsweise MÜSSEN alle Ressourcen, einschließlich der über android.app.Person bereitgestellten Symbole, in einer Gruppenunterhaltung angezeigt werden, die über setGroupConversation festgelegt wird.
• [C-SR] Es wird DRINGEND EMPFOHLEN, Nutzern automatisch die Möglichkeit zu geben, Benachrichtigungen einer bestimmten Drittanbieter-App pro Kanal und App-Paketebene zu blockieren, nachdem sie diese Benachrichtigung mehrmals geschlossen haben.
• 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 Pop-up-Benachrichtigungen MUSS die Ansicht und die Ressourcen für Pop-up-Benachrichtigungen verwendet werden, die in der API-Klasse Notification.Builder beschrieben sind.
• [C-3-2] Die über Notification.Builder.addAction() bereitgestellten Aktionen MÜSSEN zusammen mit dem Benachrichtigungsinhalt ohne zusätzliche Nutzerinteraktion wie im SDK beschrieben angezeigt werden.

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] MUSS Benachrichtigungen vollständig und zeitnah an alle installierten und vom Nutzer aktivierten Listener-Dienste senden, 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, gilt Folgendes:

• [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 Pausieren 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, müssen die von Anwendungen erstellten Automatischen Regeln für „Bitte nicht stören“ neben den vom Nutzer erstellten und vordefinierten Regeln angezeigt werden.
• [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 umfasst APIs, mit denen Entwickler Suchfunktionen in ihre Anwendungen einbinden und die Daten ihrer Anwendungen in der globalen Systemsuchfunktion 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. Außerdem können sie Ergebnisse für die gemeinsame globale Suchoberfläche bereitstellen.

• 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 Assistant 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 um die Ränder 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ü mit den 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 in Abschnitt 7.2.3 beschriebene Interaktion zum Starten der Assistenz-App 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.

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 enthält 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 Attribute des Material-Designs 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 eine einheitliche Erfahrung haben, ist es wichtig, dass der Stil des Symbols in der Statusleiste 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. Dazu 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] MUSS das Verhalten beim Anpinnen von Bildschirmen implementieren und dem Nutzer ein Einstellungsmenü zum Aktivieren und Deaktivieren der Funktion zur Verfügung stellen.
• Die Markierungsfarbe, das Symbol und der Bildschirmtitel sollten in den letzten verwendeten Apps 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 Funktionstaste 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 Miniaturbild-basierte 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 einen für Nutzer zugänglichen Mechanismus zum Hinzufügen und Konfigurieren von Drittanbieter-Eingabemethoden als Reaktion auf den Intent „android.settings.INPUT_METHOD_SETTINGS“ geben.

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

• [C-2-1] Die APIs AutofillService und AutofillManager MÜSSEN vollständig implementiert werden und die Absicht android.settings.REQUEST_SET_AUTOFILL_SERVICE muss berücksichtigt werden, 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 (Vorlagen 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. Android-Smartwatches DÜRFEN Bildschirmschoner implementieren, andere Gerätetypen SOLLTEN jedoch 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-2] Der aktuelle Standortstatus MUSS im Menü „Standort“ in den Einstellungen angezeigt werden.
• [C-1-3] Standortmodi DÜRFEN im Menü „Standort“ in den Einstellungen NICHT 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] MÜSSEN Unterstützung für Folgendes enthalten:
  • 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“, „Latin Extended B“, „Latin Extended C“ und „Latin Extended 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:

• Sollte dem Nutzer eine Eingabemethode für diese Emojis zur Verfügung stellen.

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-Window MUSS zugeschnitten werden, SOLLTE aber einige Inhalte davon anzeigen, wenn die Launcher-App das fokussierte 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 zum Steuern des BiB-Fensters verwendet werden. 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] Für das BiB-Fenster MUSS eine Mindestbreite und ‑höhe von 108 dp und für das BiB-Fenster eine Mindestbreite von 240 dp und eine Mindesthöhe von 135 dp zugewiesen werden, wenn Configuration.uiMode als UI_MODE_TYPE_TELEVISION konfiguriert ist.

3.8.15. Display-Aussparung

Android unterstützt Display-Ausschnitte, wie im SDK-Dokument beschrieben. Mit der DisplayCutout API wird ein Bereich am Rand des Displays definiert, der nicht für die Anzeige von Inhalten verwendet werden kann.

Wenn Geräteimplementierungen Displayausschnitte enthalten, gilt Folgendes:

• [C-1-1] MUSS nur Ausschnitte an den kurzen Kanten des Geräts haben. Umgekehrt gilt: Wenn das Seitenverhältnis des Geräts 1, 0 (1:1) ist, darf es KEINE Ausschnitte haben.
• [C-1-2] Es darf nur ein Ausschnitt pro Kante vorhanden sein.
• [C-1-3] MUSS die von der App über die WindowManager.LayoutParams API festgelegten Flags für das Display-Cutout gemäß Beschreibung im SDK berücksichtigen.
• [C-1-4] MUSS korrekte Werte für alle in der DisplayCutout API definierten Ausschnittmesswerte zurückgeben.

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.

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] MUSS die Registrierung eines Gerätepolicy-Clients (Device Policy Client, DPC) als App für Geräteinhaber wie unten beschrieben unterstützen:
  • Wenn auf dem Gerät 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] Während der Bereitstellung muss eine aktive Handlung erforderlich sein, um der Festlegung der App als Geräteinhaber zuzustimmen. Die Einwilligung kann durch eine Nutzeraktion oder auf programmatische Weise während der Bereitstellung erfolgen, darf aber NICHT fest codiert sein oder die Verwendung anderer Geräteinhaber-Apps verhindern.

Wenn Geräteimplementierungen android.software.device_admin deklarieren, 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“ zum 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 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 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 Device Policy 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 Dialer-, 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 alle Sicherheitsanforderungen für ein Gerät mit mehreren aktivierten Nutzern erfüllen (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 sich NUR auf die Anmeldedaten für den Sperrbildschirm des verwalteten Profils beziehen, 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.9.3 Support für verwaltete Nutzer

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

• [C-1-1] MUSS eine Möglichkeit für Nutzer bieten, sich vom aktuellen Nutzer abzumelden und in einer Sitzung mit mehreren Nutzern zum primären Nutzer zurückzukehren, wenn isLogoutEnabled true zurückgibt. Die Nutzeraufforderung MUSS vom Sperrbildschirm aus zugänglich sein, ohne dass das Gerät entsperrt werden muss.

3.10. Bedienungshilfen

Android bietet eine Barrierefreiheitsebene, 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 zusammen mit 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 Aware-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-TTS-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 alle TIF-APIs unterstützen, sodass eine Anwendung, die diese APIs und den Dienst TIF-basierte Eingaben von Drittanbietern verwendet, auf dem Gerät installiert und verwendet werden kann.

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 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] MUSS diese Elemente wie in MediaSession beschrieben anzeigen, z.B. Metadaten, Symbole und Bilder.
• [C-1-3] Der App-Titel MUSS angezeigt werden.
• [C-1-4] MUSS ein Drawer oder einen anderen Mechanismus haben, um die MediaBrowser-Hierarchie zu präsentieren und dem Nutzer die MediaBrowser-Hierarchie zu ermöglichen.
• [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 "instant" 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 oder 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 geben, ein Companion-Gerät auszuwählen/zu bestätigen, das vorhanden und betriebsbereit ist.

3:17. Umfangreiche Apps

Wenn in Geräteimplementierungen das Feature FEATURE_CANT_SAVE_STATE deklariert wird, gilt Folgendes:

• [C-1-1] Es darf jeweils nur eine installierte App mit der Angabe cantSaveState im System ausgeführt werden. Wenn der Nutzer eine solche App verlässt, ohne sie explizit zu beenden (z. B. durch Drücken der Home-Taste, während eine aktive Aktivität im System ausgeführt wird, anstatt die Zurück-Taste zu drücken, wenn keine aktiven Aktivitäten im System mehr vorhanden sind), MUSS die Geräteimplementierung diese App im RAM priorisieren, wie sie es auch bei anderen Dingen tut, die voraussichtlich weiter ausgeführt werden, z. B. bei Vordergrunddiensten. Auch wenn sich eine solche App im Hintergrund befindet, kann das System weiterhin Funktionen zur Energieverwaltung darauf anwenden, z. B. den CPU- und Netzwerkzugriff einschränken.
• [C-1-2] Es MUSS eine Benutzeroberflächenfunktion bereitgestellt werden, mit der der Nutzer die App auswählen kann, die nicht am normalen Speichern/Wiederherstellen des Status beteiligt ist, sobald er eine zweite App startet, die mit dem Attribut cantSaveState deklariert ist.
• [C-1-3] Es DÜRFEN keine anderen Richtlinienänderungen auf Apps angewendet werden, in denen cantSaveState angegeben ist, z. B. Änderungen an der CPU-Leistung oder Änderungen an der Priorisierung der Planung.

Wenn Geräteimplementierungen das Feature FEATURE_CANT_SAVE_STATE nicht deklarieren, gilt Folgendes:

• [C-1-1] MUSS das von Apps festgelegte Attribut cantSaveState ignorieren und DARF das App-Verhalten nicht auf Grundlage dieses Attributs ändern.

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.

Geräteimplementierungen:

• [C-0-2] MUSS die Überprüfung von „.apk“-Dateien mit dem APK-Signaturschema v3 , 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, die nicht die aktuelle „Installer of Record“-App für das Paket sind, DÜRFEN die App nicht ohne Bestätigung durch den Nutzer 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.

• [C-0-5] MUSS eine Aktivität haben, die den Intent android.settings.MANAGE_UNKNOWN_APP_SOURCES verarbeitet.

• [C-0-6] App-Pakete dürfen NICHT 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.

• Es SOLLTE eine Möglichkeit für Nutzer geben, die Berechtigung zum Installieren von Apps aus unbekannten Quellen pro Anwendung zu erteilen/zu widerrufen. Es KANN jedoch auch als No-Op implementiert und RESULT_CANCELED für startActivityForResult() zurückgegeben werden, wenn die Geräteimplementierung Nutzern diese Auswahl nicht ermöglichen soll. Auch in solchen Fällen SOLLTEN sie dem Nutzer jedoch mitteilen, warum keine solche Auswahl angezeigt wird.

• [C-0-7] Vor dem Starten einer Aktivität in einer Anwendung, die von derselben System-API PackageManager.setHarmfulAppWarning als potenziell schädlich gekennzeichnet wurde, MUSS dem Nutzer ein Warndialog mit dem über die System-API PackageManager.setHarmfulAppWarning bereitgestellten Warnstring angezeigt werden.

• Es SOLLTE eine Möglichkeit für den Nutzer geben, eine Anwendung im Warnungsdialog zu deinstallieren oder zu starten.

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] MUSS die Unterstützung der Encoder und Decoder deklarieren und melden, die Drittanbieteranwendungen über MediaCodecList zur Verfügung stehen.
• [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 die Unterstützung für die Funktion android.hardware.audio.output deklarieren, müssen sie die folgenden Audioformate decodieren können:

• [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-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, das das USAC Baseline Profile und das ISO/IEC 23003-4 Dynamic Range Control Profile umfasst)
• [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 dynamischen Bereich MÜSSEN wie in „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 dynamischen Bereich. 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.

Beim Decodieren von USAC-Audio, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Metadaten für Lautstärke und DRC MÜSSEN gemäß MPEG-D DRC Dynamic Range Control Profile Level 1 interpretiert und angewendet werden.
• [C-3-2] Der Decoder MUSS sich gemäß der Konfiguration verhalten, die mit den folgenden android.media.MediaFormat-Schlüsseln festgelegt wurde: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL und KEY_AAC_DRC_EFFECT_TYPE.

MPEG-4-AAC-, HE-AAC- und HE-AACv2-Profildecoder:

• MAY unterstützt die Steuerung von Lautstärke und Dynamikbereich mit dem ISO/IEC 23003-4-Profil für die Steuerung des Dynamikbereichs.

Wenn ISO/IEC 23003-4 unterstützt wird und sowohl ISO/IEC 23003-4- als auch ISO/IEC 14496-3-Metadaten in einem decodierten Bitstream vorhanden sind, gilt Folgendes:

• Die Metadaten gemäß ISO/IEC 23003-4 haben Vorrang.

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.
USAC	Unterstützung für Mono-/Stereo-Inhalte mit Standard-Abtastraten von 7,35 bis 48 kHz.	MPEG-4 (.mp4, .m4a)
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, gesampelt 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. Bild-Decodierung

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

Geräteimplementierungen MÜSSEN die Decodierung der folgenden Bildcodierung 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
• [C-0-7] HEIF (HEIC)

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)
HEIF	Bild, Bildsammlung, Bildsequenz	HEIF (.heif), HEIC (.heic)

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

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.
• Sollte in einem gleitenden 1-Sekunden-Fenster 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 Videoausgangsanschluss 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 für 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 jedem Codec 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 Dolby Vision-fähigen Extraktor 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 das Main Profile Level 3.1 und das Baseline-Profil 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, gilt für Geräteimplementierungen Folgendes:

• [C-2-1] MUSS die HD‑Videodecodierungsprofile mit 720p in der folgenden Tabelle unterstützen.
• [C-2-2] MUSS die in der folgenden Tabelle aufgeführten HD‑1080p‑Videodecodierungsprofile 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:

• [C-2-1] 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-Profilen 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
  • Channels (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] Der 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 von Apps ü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] MUSS die Wiedergabe von rohen Audioinhalten mit den folgenden Merkmalen ermöglichen:

  • Format: Lineare PCM, 16 Bit, 8 Bit, Gleitkomma
  • Kanäle: Mono, Stereo, gültige Mehrkanal-Konfigurationen mit bis zu 8 Kanälen
  • Abtastraten (in Hz):
    • 8.000, 11.025, 16.000, 22.050, 32.000, 44.100, 48.000 bei den oben aufgeführten Channelkonfigurationen
    • 96.000 Hz in Mono und Stereo

• Die Wiedergabe von rohen Audioinhalten 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 die Funktion 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.
• [C-1-3] MUSS die EFFECT_TYPE_DYNAMICS_PROCESSING-Implementierung unterstützen, die über die AudioEffect-Unterklasse DynamicsProcessing gesteuert werden kann.
• Sollte die Implementierungen von 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.

Für die Zwecke dieses Abschnitts 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 inaktiv und heruntergefahren war.
• 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 ausgeschaltet 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 Kaltstart-Latenzwerten.
• Kalter Eingabe-Jitter: Die Variabilität zwischen einzelnen Messungen von Kaltstart-Eingabelatenzwerten.
• kontinuierliche Roundtrip-Latenz. Die Summe aus der Latenz für die kontinuierliche Eingabe, der Latenz für die kontinuierliche Ausgabe 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 buffer queue API Die Gruppe der PCM-bezogenen OpenSL ES-APIs im Android NDK.
• AAudio Native Audio API Die Gruppe der AAudio-APIs im Android NDK.
• Zeitstempel. Ein Paar aus einer relativen Frame-Position in einem Stream und der geschätzten Zeit, zu der dieser Frame in die Audioverarbeitungspipeline auf dem zugehörigen Endpunkt eintritt oder diese verlässt. Siehe auch AudioTimestamp.

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

• [C-SR] Kaltstart-Ausgabelatenz von maximal 100 Millisekunden
• [C-SR] Kontinuierliche Ausgabelatenz von höchstens 45 Millisekunden
• [C-SR] Minimierung von Kaltstart-Jitter
• [C-SR] Der von AudioTrack.getTimestamp und AAudioStream_getTimestamp zurückgegebene Zeitstempel ist auf +/-1 ms genau.

Wenn Geräteimplementierungen die oben genannten Anforderungen erfüllen, sind die kontinuierliche Ausgabelatenz und die Kaltstart-Ausgabelatenz bei Verwendung sowohl der OpenSL ES-PCM-Pufferwarteschlange als auch der nativen AAudio-Audio-APIs für mindestens ein unterstütztes Audioausgabegerät nach der ersten Kalibrierung:

• [C-SR] Es wird DRINGEND EMPFOHLEN, Audio mit geringer Latenz zu melden, indem das android.hardware.audio.low_latency-Funktions-Flag deklariert wird.
• [C-SR] Es wird DRINGEND EMPFOHLEN, die Anforderungen für Audio mit geringer Latenz über die AAudio API zu erfüllen.
• [C-SR] DRINGEND EMPFOHLEN, um sicherzustellen, dass für Streams, die AAUDIO_PERFORMANCE_MODE_LOW_LATENCY von AAudioStream_getPerformanceMode() zurückgeben, der von AAudioStream_getFramesPerBurst() zurückgegebene Wert kleiner oder gleich dem von android.media.AudioManager.getProperty(String) zurückgegebenen Wert für den Attributschlüssel AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER ist.

Wenn Geräteimplementierungen die Anforderungen für Audio mit geringer Latenz über die OpenSL ES-PCM-Pufferwarteschlange und die nativen AAudio-Audio-APIs 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:

• [C-SR] Kaltstart-Eingabelatenz von höchstens 100 Millisekunden.
• [C-SR] Kontinuierliche Eingabelatenz von maximal 30 Millisekunden.
• [C-SR] Kontinuierliche Umlauflatenz von höchstens 50 Millisekunden.
• [C-SR] Minimiere den Kaltstart-Jitter.
• [C-SR] Beschränke den Fehler bei Eingabe-Zeitstempeln, die von AudioRecord.getTimestamp oder AAudioStream_getTimestamp zurückgegeben werden, auf +/-1 ms.

5.7. Netzwerkprotokolle

Geräteimplementierungen MÜSSEN die Media Network Protocols 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 für Media-Segmente

Segmentformate	Referenz(en)	Erforderliche Codec-Unterstützung
MPEG-2-Transportstrom	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 in 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-Transportstrom unter HTTP-Livestreaming.

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 externen Displays unterstützen, die über einen für Nutzer zugänglichen kabelgebundenen Port verbunden sind.

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 mindestens auf einem unterstützten Pfad 20 Millisekunden oder weniger betragen und SOLLTE 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 Anforderungen an Latenz und USB-Audio sowohl mit der OpenSL ES-PCM-Pufferwarteschlange als auch mit den nativen AAudio-APIs 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 digitalen USB-Audio 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.
• Die Phasendifferenz zwischen der HAL-Audio-Pufferung für die Ein- und Ausgabeseiten der entsprechenden Endpunkte SOLLTE minimiert werden.
• Die Berührungslatenz SOLLTE minimiert werden.
• Die Variabilität der Berührungslatenz unter Last (Jitter) SOLLTE minimiert werden.
• Die Latenz vom Touch-Eingang bis zur Audioausgabe SOLLTE maximal 40 ms betragen.

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 einen 3,5‑mm-Audioanschluss mit 4 Leitern enthalten, gilt Folgendes:

• [C-2-1] Die kontinuierliche Audio-Roundtrip-Latenz muss über den Kopfhöreranschluss 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-Audioklasse implementieren.
• [C-3-2] MUSS im USB-Hostmodus über den USB-Audio-Class-Port eine kontinuierliche Audio-Umlauflatenz von höchstens 20 Millisekunden aufweisen.
• Die kontinuierliche Audio-Umlauflatenz SOLLTE im USB-Hostmodus-Port mit USB-Audioklasse 10 Millisekunden oder weniger betragen.

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

• [C-4-1] Das Gerät MUSS in mindestens einer Konfiguration 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 Aufnahmepreset 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-Wert 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 von 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 ADB unterstützen, wie im Android SDK und in den Shell-Befehlen im AOSP dokumentiert, die von App-Entwicklern verwendet werden können, einschließlich dumpsys und cmd stats.
  • [C-0-3] Das Format oder der Inhalt von Gerätesystemereignissen (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats), die über den Befehl „dumpsys“ protokolliert werden, DÜRFEN NICHT geändert werden.
  • [C-0-10] MUSS die folgenden Ereignisse vollständig aufzeichnen und über den cmd stats-Shell-Befehl und die StatsManager-System-API-Klasse zugänglich und verfügbar machen.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [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, MUSS jedoch unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben beschrieben aktiviert hat.
• Affe
  • [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.

Wenn Geräteimplementierungen die Unterstützung von Vulkan 1.0 oder höher über die Funktions-Flags android.hardware.vulkan.version melden, gilt Folgendes:

• [C-1-1] Der App-Entwickler MUSS die Möglichkeit haben, GPU-Debug-Ebenen zu aktivieren/deaktivieren.
• [C-1-2] MUSS, wenn die GPU-Debug-Ebenen aktiviert sind, Ebenen in Bibliotheken aufzählen, die von externen Tools bereitgestellt werden (d.h. nicht Teil des Plattform- oder Anwendungspakets sind) und sich im Basisverzeichnis von debugfähigen Anwendungen befinden, um die API-Methoden vkEnumerateInstanceLayerProperties() und vkCreateInstance() zu unterstützen.

6.2. Entwickleroptionen

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

Geräteimplementierungen MÜSSEN eine einheitliche Nutzung der Entwickleroptionen ermöglichen. Sie:

• [C-0-1] MUSS den Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS berücksichtigen, um Einstellungen für die Anwendungsentwicklung 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.
• [C-0-3] Es MUSS einen eindeutigen Mechanismus geben, der nicht eine Drittanbieter-App gegenüber einer anderen bevorzugt, um die Entwickleroptionen zu aktivieren. Es MUSS ein öffentlich sichtbares Dokument oder eine Website bereitgestellt werden, in dem beschrieben wird, wie die Entwickleroptionen aktiviert werden. Dieses Dokument oder diese Website MUSS über die Android SDK-Dokumente verlinkt werden können.
• Es SOLLTE eine fortlaufende visuelle Benachrichtigung für den Nutzer angezeigt werden, wenn die Entwickleroptionen aktiviert sind und die Sicherheit des Nutzers gefährdet ist.
• 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 auf angemessene 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 verschiedenen 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 = dp * (Dichte/160).

7.1.1. Bildschirmkonfiguration

7.1.1.1. Displaygröße und ‑form

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

Geräteimplementierungen:

• [C-0-1] MUSS 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] MUSS die angegebene Unterstützung von Bildschirmgrößen durch Anwendungen über das Attribut <supports-screens> in der Datei „AndroidManifest.xml“ korrekt berücksichtigen, wie in der Android SDK-Dokumentation beschrieben.

• Das Display KANN abgerundete Ecken haben.

Wenn Geräteimplementierungen UI_MODE_TYPE_NORMAL unterstützen und ein Display mit abgerundeten Ecken enthalten, gilt Folgendes:

• [C-1-1] Der Radius der abgerundeten Ecken MUSS kleiner oder gleich 38 dp sein.
• Es SOLLTE eine Möglichkeit für den Nutzer geben, zum Anzeigemodus mit den rechteckigen Ecken zu wechseln.

7.1.1.2. Seitenverhältnis des Bildschirms

Es gibt keine Einschränkung für das Seitenverhältnis des physischen Bildschirms. Das Seitenverhältnis des logischen Displays, in dem Drittanbieter-Apps gerendert werden, muss jedoch 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 Darstellung 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ändert werden kann.
  • Die App ist auf API‑Level 24 oder höher ausgerichtet und deklariert keine android:MaxAspectRatio, die 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 Displaykampagnen

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

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.1 als auch 2.0 unterstützen, wie in der Android SDK-Dokumentation beschrieben.
• [SR] Es wird DRINGEND EMPFOHLEN, OpenGL ES 3.1 zu unterstützen.
• SOLLTEN OpenGL ES 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.
• 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 Overhead für leistungsstarke 3D-Grafiken.

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

• [SR] Es wird DRINGEND EMPFOHLEN, Unterstützung für Vulkan 1.1 einzuschließen.

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

• SOLLTE Unterstützung für Vulkan 1.1 enthalten.

Wenn Geräteimplementierungen Unterstützung für Vulkan 1.0 enthalten, gilt Folgendes:

• [C-1-1] MUSS den richtigen Ganzzahlwert mit den Funktions-Flags android.hardware.vulkan.level und android.hardware.vulkan.version melden.
• [C-1-2] MUSS 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.
• [C-1-7] MÜSSEN die Erweiterungen VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain und VK_KHR_incremental_present unterstützen.

Wenn Geräteimplementierungen keine Unterstützung für Vulkan 1.0 enthalten, gilt Folgendes:

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

Wenn Geräteimplementierungen Unterstützung für Vulkan 1.1 enthalten, gilt Folgendes:

• [C-3-1] MUSS Unterstützung für die externen Semaphor- und Handle-Typen SYNC_FD bieten.
• [SR] Es wird DRINGEND EMPFOHLEN, die VK_ANDROID_external_memory_android_hardware_buffer-Erweiterung zu unterstützen.

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

Geräteimplementierungen:

• [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 Configuration.isScreenWideColorGamut() 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% von DCI‑P3 hat.
• [C-1-4] MÜSSEN OpenGL ES 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_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3 und EGL_KHR_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 mindestens 100% des sRGB-Farbraums im CIE 1931 xyY-Farbraum abdecken, obwohl der Farbumfang des Displays nicht definiert ist.

7.1.5. Kompatibilitätsmodus für ältere 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 veröffentlicht 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 (Pixel Aspect Ratio, PAR) zwischen 0,9 und 1,15 verwenden. 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 bietet Unterstützung für sekundäre Displays, um die Medienfreigabe zu ermöglichen, und 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 vorinstallierte Softwaretastatur haben.

Geräteimplementierungen: * [C-0-1] DÜRFEN keine Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard angegebenen Formate (QWERTY oder 12-Tasten) 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 Touchscreen.

Geräteimplementierungen:

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

Wenn Geräteimplementierungen keine Navigation ohne Touch-Eingabe 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 „Home“ 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 ist 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 in seiner Position geändert werden. Es DARF jedoch an einer anderen Position auf dem Bildschirm gerendert werden, wenn es durch Auswahl der Menüfunktion angezeigt wird.

Wenn Geräteimplementierungen die Menüfunktion nicht bereitstellen, müssen sie aus Gründen der Abwärtskompatibilität Folgendes tun: * [C-3-1] Die Menüfunktion muss Anwendungen zur Verfügung gestellt werden, wenn targetSdkVersion kleiner als 10 ist, entweder über eine physische Taste, eine Softwaretaste oder Gesten. 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-Funktion als diese bestimmte 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] Die durch die App über die API-Methode View.setSystemUiVisibility() festgelegten Flags MÜSSEN berücksichtigt werden, damit dieser separate Bereich des Bildschirms (die Navigationsleiste) 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 Fälschung 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 und 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 Fake-Touch 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 hochpräzisen 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] MUSS das Drücken und Loslassen 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 zwei oder mehr 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 in der Verpackung geliefert 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)
Klicken auf den rechten Stick1	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 Verwendung muss ein logisches Minimum von 0, ein logisches Maximum von 7, ein physisches Minimum von 0, ein physisches Maximum 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 steht beispielsweise für keine Drehung und das Drücken der Aufwärtstaste, während ein logischer Wert von 1 für eine Drehung um 45 Grad und das Drücken der Aufwärts- und der linken Taste steht.

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] MUSS Sensordaten mit einer maximalen Latenz von 100 Millisekunden + 2 * sample_time für den Fall eines Sensors melden, der mit einer minimalen erforderlichen Latenz von 5 ms + 2 * sample_time gestreamt wird, wenn der Anwendungsprozessor aktiv ist. Diese Verzögerung beinhaltet keine Filterverzögerungen.
• [C-1-3] MUSS die erste Sensorprobe innerhalb von 400 Millisekunden + 2 * sample_time nach der 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-4] Für jede API, die in der Android SDK-Dokumentation als kontinuierlicher Sensor angegeben ist, MÜSSEN Geräteimplementierungen kontinuierlich regelmäßige 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-5] MUSS dafür sorgen, dass der Sensorereignisstream nicht verhindert, dass die Geräte-CPU in den Ruhezustand wechselt oder aus dem Ruhezustand aufwacht.

• 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, müssen sie folgende Anforderungen erfüllen:

• [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 bestehende und neue Android-Geräte den TYPE_GAME_ROTATION_VECTOR-Sensor implementieren.

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] Das Gerät 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, die nicht größer als 1,5 µT ist; SOLLTE eine Standardabweichung haben, die nicht größer als 0,5 µT ist.
• SOLLTEN den TYPE_MAGNETIC_FIELD_UNCALIBRATED-Sensor implementieren.
• [SR] Es wird DRINGEND EMPFOHLEN, dass bestehende und neue Android-Geräte den TYPE_MAGNETIC_FIELD_UNCALIBRATED-Sensor implementieren.

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 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.
  • [C-1-6] Nach einer solchen Standortberechnung MUSS die Geräteimplementierung ihren Standort unter störungsfreien Bedingungen innerhalb von 5 Sekunden bestimmen, 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-/GNSS-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 GNSS-Messungen melden, sobald sie gefunden werden, auch wenn noch kein aus GPS/GNSS berechneter Standort gemeldet wurde.
• [C-2-2] MUSS GNSS-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-/GNSS-Positionsangabe 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 „2018“ oder neuer meldet, gilt Folgendes:

• [C-4-1] MUSS während eines von einem Mobilgerät initiierten Notrufs weiterhin normale GPS-/GNSS-Ausgaben an Anwendungen liefern.
• [C-4-2] MÜSSEN Positionen und Messungen an die APIs des GNSS Location Provider 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) aufweisen. Die Varianz darf mit der Stichprobenrate 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 bestehende und neue Android-Geräte den SENSOR_TYPE_GYROSCOPE_UNCALIBRATED-Sensor implementieren.
• [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 bestehende und neue Android-Geräte den TYPE_GAME_ROTATION_VECTOR-Sensor implementieren.
• 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,

• [C-1-1] MÜSSEN den TYPE_PRESSURE-Sensor implementieren und melden.
• [C-1-2] MUSS Ereignisse mit einer Frequenz von 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 sein und 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 ein 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 eine Genauigkeit von mindestens 1 Bit 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, gilt Folgendes:

• [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 zwischen mindestens -8 g und +8 g haben, SOLLTE einen Messbereich zwischen mindestens -16 g und +16 g haben.
  • MUSS eine Messauflösung von mindestens 2048 LSB/g haben.
  • MUSS eine Mindestmesshäufigkeit von 12,5 Hz oder weniger haben.
  • MUSS eine maximale Messfrequenz von 400 Hz oder höher haben; SOLLTE den SensorDirectChannel RATE_VERY_FAST unterstützen.
  • 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 Stromverbrauch für Batching von höchstens 3 mW haben.
  • [C-SR] Es wird DRINGEND EMPFOHLEN, dass die 3-dB-Messbandbreite mindestens 80% der Nyquist-Frequenz und das Rauschen in diesem Frequenzbereich ein weißes Rauschen ist.
  • SOLLTE bei Raumtemperatur einen zufälligen Gang der Beschleunigung von weniger als 30 μg √Hz aufweisen.
  • SOLLTE eine Bias-Änderung im Vergleich zur Temperatur von ≤ +/- 1 mg/°C haben.
  • 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 eine Querachsensensitivität von < 2,5 % und eine Variation der Querachsensensitivität von < 0,2% im Betriebstemperaturbereich des Geräts aufweisen.

• [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 400 Hz oder höher haben; SOLLTE den SensorDirectChannel RATE_VERY_FAST unterstützen.
  • Das Messrauschen DARF nicht über 0,014°/s/√Hz liegen.
  • [C-SR] Es wird DRINGEND EMPFOHLEN, dass die 3-dB-Messbandbreite mindestens 80% der Nyquist-Frequenz und das Rauschen in diesem Frequenzbereich ein weißes Rauschen ist.
  • SOLLTE bei Raumtemperatur einen Rate Random Walk von weniger als 0,001 °/s √Hz haben.
  • 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.
  • Der Kalibrierungsfehler SOLLTE im Temperaturbereich von 10 bis 40 °C weniger als 0,002 rad/s betragen, wenn das Gerät nicht bewegt wird.
  • SOLLTE eine g-Empfindlichkeit von weniger als 0,1°/s/g haben.
  • Die Querachsensensitivität SOLLTE im Betriebstemperaturbereich des Geräts < 4,0 % und die Querachsensensitivitätsabweichung < 0,3% betragen.

• [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 und zusätzlich:

  • MUSS eine Nicht-Wake-up-Version dieses Sensors mit einer Pufferkapazität von mindestens 600 Sensorereignissen implementieren.
  • [C-SR] Es wird DRINGEND EMPFOHLEN, ein Rauschen mit einem Spektrum von 1 Hz bis mindestens 10 Hz zu haben, wenn die Berichtsrate 50 Hz oder höher ist.

• [C-2-7] MUSS 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.
  • Es MUSS eine nicht aufweckende Form dieses Sensors mit einer Pufferkapazität von mindestens 300 Sensorereignissen implementiert werden.
  • 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] MÜSSEN 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] MÜSSEN einen TYPE_STEP_DETECTOR-Sensor haben, der:
  • Es MUSS eine Nicht-Wake-up-Version dieses Sensors mit einer Pufferkapazität von mindestens 100 Sensorereignissen implementiert werden.
  • 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. Der Ereigniszeitstempel desselben physischen Ereignisses, das vom Beschleunigungsmesser und vom Gyroskop gemeldet wird, SOLLTE sich innerhalb von 0,25 Millisekunden voneinander befinden.
• [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 Proben innerhalb von 5 Millisekunden nach dem Zeitpunkt, zu dem die Daten auf einem der oben genannten physischen Sensoren für die Anwendung verfügbar sind, an Anwendungen liefern.
• [C-2-16] DARF im statischen Zustand nicht mehr als 0,5 mW und im bewegten Zustand nicht mehr als 2,0 mW verbrauchen, 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 der Stromverbrauch der gesamten Sensorkette, also des Sensors, der unterstützenden Schaltungen, des dedizierten Sensorverarbeitungssystems usw.

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

• [C-3-1] MUSS die Unterstützung von direkten Kanaltypen und direkten Berichtsraten korrekt über die API isDirectChannelTypeSupported und getHighestDirectReportRateLevel 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
• MUSS die Ereignisberichterstellung über den direkten Sensorchannel für den primären Sensor (Nicht-Wakeup-Variante) der folgenden Typen unterstützen:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Biometrische Sensoren

7.3.10.1. Fingerabdrucksensoren

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] Versuche zur Fingerabdrucküberprüfung MÜSSEN nach fünf fehlgeschlagenen Versuchen für mindestens 30 Sekunden begrenzt werden.
• [C-1-6] MUSS eine hardwarebasierte Keystore-Implementierung haben und den Fingerabdruckabgleich in einer 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 nicht außerhalb der TEE oder eines Chips mit einem sicheren Kanal zur TEE erfasst, 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 geschützt ist. Die Android Open Source Project-Implementierung bietet den Mechanismus im Framework, um dies zu tun.
• [C-1-9] DRITTANBIETER-ANWENDUNGEN DÜRFEN NICHT in die Lage versetzt werden, 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.
• [C-1-12] ALLE identifizierbaren Fingerabdruckdaten für einen Nutzer MÜSSEN vollständig entfernt werden, wenn das Konto des Nutzers entfernt wird (auch durch Zurücksetzen auf die Werkseinstellungen).
• [C-1-13] Der Anwendungs-Prozessor DARF KEINEN unverschlüsselten Zugriff auf identifizierbare Fingerabdruckdaten oder daraus abgeleitete Daten (z. B. Einbettungen) ermöglichen.
• [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.
• Das im Android Open Source Project bereitgestellte Android-Fingerabdrucksymbol SOLLTE verwendet werden.

7.3.10.2. Andere biometrische Sensoren

Wenn Geräteimplementierungen einen oder mehrere nicht auf Fingerabdrücken basierende biometrische Sensoren enthalten und diese für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS eine Falsch-Akzeptanzrate von höchstens 0,002 % haben.
• [C-SR] Es wird DRINGEND EMPFOHLEN, dass die Akzeptanzrate für Spoofing und Identitätsdiebstahl nicht höher als 7 % ist.
• [C-1-2] Es MUSS offengelegt werden, dass dieser Modus möglicherweise weniger sicher ist als eine starke PIN, ein starkes Muster oder ein starkes Passwort, und die Risiken der Aktivierung müssen klar aufgeführt werden, wenn die Akzeptanzraten für Spoofing und Identitätsdiebstahl höher als 7 % sind.
• [C-1-3] MUSS Versuche zur biometrischen Überprüfung nach fünf fehlgeschlagenen Versuchen für mindestens 30 Sekunden einschränken. Ein fehlgeschlagener Versuch ist ein Versuch mit einer angemessenen Erfassungsqualität (ACQUIRED_GOOD), der nicht mit einem registrierten biometrischen Merkmal übereinstimmt.
• [C-1-4] MUSS eine hardwarebasierte Keystore-Implementierung haben und den biometrischen Abgleich in einer TEE oder auf einem Chip mit einem sicheren Kanal zur TEE durchführen.
• [C-1-5] Alle identifizierbaren Daten MÜSSEN verschlüsselt und kryptografisch authentifiziert werden, sodass sie nicht außerhalb der TEE oder eines Chips mit einem sicheren Kanal zur TEE erfasst, gelesen oder geändert werden können, wie in den Implementierungsrichtlinien auf der Android Open Source Project-Website dokumentiert.
• [C-1-6] Das Hinzufügen neuer biometrischer Verfahren MUSS verhindert werden, ohne dass zuerst eine Vertrauenskette eingerichtet wird, indem der Nutzer ein vorhandenes oder neues Geräte-Anmeldedatenpaar (PIN/Muster/Passwort) bestätigt, das durch die TEE geschützt ist. Die Android Open Source Project-Implementierung bietet den Mechanismus im Framework, um dies zu tun.
• [C-1-7] DÜRFEN Drittanbieteranwendungen NICHT ermöglichen, zwischen biometrischen Registrierungen zu unterscheiden.
• [C-1-8] MUSS das individuelle Flag für das jeweilige biometrische Verfahren (z. B. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE oder DevicePolicymanager.KEYGUARD_DISABLE_IRIS) berücksichtigen.
• [C-1-9] ALLE identifizierbaren biometrischen Daten eines Nutzers MÜSSEN vollständig entfernt werden, wenn das Konto des Nutzers entfernt wird (auch durch Zurücksetzen auf die Werkseinstellungen).
• [C-1-10] Es darf KEINEN unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder daraus abgeleitete Daten (z. B. Einbettungen) auf dem Anwendungsprozessor außerhalb des TEE geben.
• [C-SR] Es wird DRINGEND EMPFOHLEN, dass die Falsch-Ablehnungsrate auf dem Gerät gemessen weniger als 10 % beträgt.
• [C-SR] Es wird DRINGEND EMPFOHLEN, dass die Latenz für jedes registrierte biometrische Verfahren unter 1 Sekunde liegt. Die Latenz wird ab dem Zeitpunkt gemessen, an dem die biometrischen Daten erkannt werden, bis das Display entsperrt wird.

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

Diese Anforderung wurde eingestellt.

7.3.11.4. Raddrehzahlsensor

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.11.5. Feststellbremse

Gerätespezifische Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.12. Pose Sensor

Geräteimplementierungen:

• Unterstützt möglicherweise den Lagesensor 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-Funktionen und APIs für Telefonie 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] MUSS die vollständigen APIs als No-Ops implementieren.

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 Anruflistenanbieter der Plattform 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.
• Die blockierten Nummern SOLLTEN in den Anbieter migriert werden, 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-1-1] MUSS die im SDK beschriebenen ConnectionService-APIs unterstützen.
• [C-1-2] Ein neuer eingehender Anruf MUSS angezeigt werden und der Nutzer MUSS die Möglichkeit haben, den eingehenden Anruf anzunehmen oder abzulehnen, wenn er sich in einem laufenden Anruf befindet, der von einer Drittanbieter-App getätigt wurde, die die über CAPABILITY_SUPPORT_HOLD angegebene Funktion zum Halten von Anrufen nicht unterstützt.

• [C-SR] Es wird DRINGEND EMPFOHLEN, den Nutzer darüber zu informieren, dass ein laufender Anruf beendet wird, wenn er einen eingehenden Anruf annimmt.

  Die AOSP-Implementierung erfüllt diese Anforderungen durch eine Pop-up-Benachrichtigung, die den Nutzer darüber informiert, dass durch das Annehmen eines eingehenden Anrufs der andere Anruf beendet wird.

• [C-SR] Es wird DRINGEND EMPFOHLEN, die Standard-Dialer-App vorzuladen, in deren Anrufliste ein Anruflisteneintrag und der Name einer Drittanbieter-App angezeigt werden, wenn die Drittanbieter-App den Extras-Schlüssel EXTRA_LOG_SELF_MANAGED_CALLS in ihrem PhoneAccount auf true setzt.

• [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 kurzes Drücken des Tastaturereignisses erkannt wird.
  • Rufen Sie Connection.onReject() auf, wenn während eines eingehenden Anrufs ein langes Drücken des Tastaturereignisses erkannt wird.
  • Stummschaltung des 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 Funktion für eine Drittanbieteranwendung verfügbar machen, gilt Folgendes:

• [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.
• [C-1-5] Der Aufruf der WifiManager.enableNetwork() API-Methode darf NICHT als ausreichender Hinweis darauf gewertet werden, dass die aktuell aktive Network, die standardmäßig für den Anwendungs-Traffic verwendet und von ConnectivityManager API-Methoden wie getActiveNetwork und registerDefaultNetworkCallback zurückgegeben wird, gewechselt werden muss. Das heißt, sie DÜRFEN den Internetzugang, der von einem anderen Netzwerkanbieter (z.B. mobile Daten) bereitgestellt wird, NUR deaktivieren, wenn sie erfolgreich bestätigen, dass das WLAN einen Internetzugang bietet.
• [C-SR] Es wird DRINGEND EMPFOHLEN, bei Aufruf der ConnectivityManager.reportNetworkConnectivity() API-Methode den Internetzugriff auf dem Network neu zu bewerten und, sobald die Bewertung ergibt, dass das aktuelle Network keinen Internetzugriff mehr bietet, zu einem anderen verfügbaren Netzwerk (z.B. Mobilfunkdaten) zu wechseln, das Internetzugriff bietet.
• [C-SR] Es wird DRINGEND EMPFOHLEN, die MAC‑Quelladresse und Sequenznummer von Frames zur Prüfungsanfrage einmal zu Beginn jedes Scans zu randomisieren, während die 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.
• [C-SR] Es wird DRINGEND EMPFOHLEN, dass nur die folgenden Elemente in Probe Request-Frames zulässig sind, während die STA getrennt ist:
  • SSID-Parametersatz (0)
  • DS-Parametersatz (3)

Wenn Geräteimplementierungen WLAN unterstützen und WLAN für die Standortermittlung verwenden, gilt Folgendes:

• [C-2-1] MUSS eine Möglichkeit für Nutzer bieten, das Lesen des Werts über die API-Methode WifiManager.isScanAlwaysAvailable zu aktivieren/deaktivieren.

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.
• [C-1-4] MUSS WLAN- 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.

Wenn Geräteimplementierungen Unterstützung für Wi-Fi Aware und Wi-Fi Location enthalten, wie in Abschnitt 7.4.2.5 beschrieben, und diese Funktionen für Drittanbieter-Apps verfügbar machen, dann gilt Folgendes:

• [C-2-1] MUSS die standortbezogenen Erkennungs-APIs setRangingEnabled, setMinDistanceMm, setMaxDistanceMm und onServiceDiscoveredWithinRange implementieren.

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.2.5. WLAN-Standort (WLAN-Umlaufzeit – RTT)

Geräteimplementierungen:

• SOLLTE Unterstützung für WLAN-Standort enthalten.

Wenn Geräteimplementierungen die Unterstützung für WLAN-Standort enthalten und die Funktion für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS die WifiRttManager-APIs wie in der SDK-Dokumentation beschrieben implementieren.
• [C-1-2] MUSS das Funktions-Flag android.hardware.wifi.rtt deklarieren.
• [C-1-3] MUSS die MAC‑Quelladresse für jeden RTT-Burst randomisieren, der ausgeführt wird, während die WLAN-Schnittstelle, auf der der RTT ausgeführt wird, nicht mit einem Zugangspunkt verknüpft ist.

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 HFP, A2DP und AVRCP unterstützen, gilt Folgendes:

• Es SOLLTE mindestens 5 verbundene Geräte 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, AVRCP, OBEX, HFP usw. implementiert werden, je nach Gerät.

Wenn Geräteimplementierungen Unterstützung für Bluetooth Low Energy enthalten, gilt Folgendes:

• [C-3-1] MUSS 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 schützen.

Wenn Geräteimplementierungen Bluetooth LE unterstützen und Bluetooth LE für die Standortsuche verwenden, gilt Folgendes:

• [C-4-1] Es MUSS eine Möglichkeit für Nutzer geben, das Lesen des Werts über die System-API BluetoothAdapter.isBleScanAlwaysAvailable() zu aktivieren/deaktivieren.

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] android.nfc.NdefMessage- und android.nfc.NdefRecord-APIs MÜSSEN implementiert werden, auch wenn sie keine Unterstützung für NFC enthalten oder das android.hardware.nfc-Feature 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 fungieren können (gemäß der technischen Spezifikation NFCForum-TS-DigitalProtocol-1.0 des NFC-Forums):
  • 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 wie der SNEP-Standardserver verarbeitet werden.
• [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 das Festlegen der ausgehenden P2P-NDEF-Nachricht über android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback und android.nfc.NfcAdapter.enableForegroundNdefPush ermöglichen.
• 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] Im NFC-Erkennungsmodus MUSS nach allen unterstützten Technologien gesucht werden.
• 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.

Ö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 allgemeine NFC-Unterstützung gemäß diesem Abschnitt 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 eine oder mehrere Formen 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.
• SOLLTE auch die Unterstützung für mindestens einen gängigen drahtlosen Datenstandard wie 802.11 (WLAN) enthalten, wenn ein physischer Netzwerkstandard (z. B. Ethernet) die primäre Datenverbindung ist.
• MAY implement more than one form of data connectivity.
• [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 IPv4, z. B.:
  • [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.
• [C-0-6] Drittanbieteranwendungen MÜSSEN eine direkte IPv6-Verbindung zum Netzwerk bereitstellen, wenn eine Verbindung zu einem IPv6-Netzwerk besteht, ohne dass eine Adress- oder Portübersetzung lokal auf dem Gerät erfolgt. Sowohl verwaltete APIs wie Socket#getLocalAddress oder Socket#getLocalPort als auch NDK-APIs wie getsockname() oder IPV6_PKTINFO MÜSSEN die IP-Adresse und den Port zurückgeben, die tatsächlich zum Senden und Empfangen von Paketen im Netzwerk verwendet werden.

Das erforderliche Maß an IPv6-Unterstützung hängt vom Netzwerktyp ab, wie in den folgenden Anforderungen beschrieben.

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

• [C-1-1] MUSS Dual-Stack- und Nur-IPv6-Betrieb über WLAN unterstützen.

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

• [C-2-1] MUSS Dual-Stack-Betrieb über Ethernet unterstützen.

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

• Sollte den IPv6-Betrieb (nur IPv6 und möglicherweise Dual-Stack) über Mobilfunk unterstützen.

Wenn Geräteimplementierungen mehr als einen Netzwerktyp unterstützen (z.B. WLAN und mobile Daten)

• [C-3-1] MUSS gleichzeitig die oben genannten Anforderungen in jedem Netzwerk erfüllen, wenn das Gerät gleichzeitig mit mehr als einem Netzwerktyp verbunden ist.

7.4.6. Synchronisierungseinstellungen

Geräteimplementierungen:

• [C-0-1] Die Einstellung für 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 bereitstellen, 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.4.8. Secure Elements

Wenn Geräteimplementierungen sichere Elemente unterstützen, die mit der Open Mobile API kompatibel sind, und sie für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] Die verfügbaren Secure Element-Lesegeräte MÜSSEN aufgelistet werden, wenn die Methode android.se.omapi.SEService.getReaders() aufgerufen wird.

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 für die grundlegende Vorschau und die Aufnahme von Fotos 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:

• Eine nach hinten gerichtete Kamera SOLLTE vorhanden sein.

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 sein (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-4] 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-5] Das endgültige aufgenommene Standbild oder die an Anwendungs-Callbacks zurückgegebenen oder im Medienspeicher gespeicherten Videostreams dürfen NICHT gespiegelt werden.
• [C-1-6] 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-Host-Port verbunden wird.
• [C-1-3] MUSS die CTS-Tests für Kameras bestehen, wenn ein physisches externes Kameragerät angeschlossen ist. Details zum CTS-Test der Kamera sind unter source.android.com verfügbar.
• 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.

Wenn die kamerabasierte Videocodierung unterstützt wird:

• [C-2-1] Ein gleichzeitiger uncodierter / MJPEG-Stream (QVGA oder höhere Auflösung) MUSS 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.

Alle Funktionen, die in der eingestellten Klasse „android.hardware.Camera“ und im neueren Paket „android.hardware.camera2“ vorhanden sind, MÜSSEN in beiden APIs eine gleichwertige Leistung und Qualität bieten. Bei gleichwertigen Einstellungen müssen beispielsweise die Autofokusgeschwindigkeit und ‑genauigkeit identisch sein und die Qualität der aufgenommenen Bilder muss gleich sein. Funktionen, die von der unterschiedlichen Semantik der beiden APIs abhängen, müssen nicht die gleiche Geschwindigkeit oder Qualität haben, SOLLTEN aber so gut wie möglich übereinstimmen.

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 das NV21-Codierungsformat haben, 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 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 Media Store 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.
• [C-SR] Es wird DRINGEND EMPFOHLEN, ein logisches Kameragerät zu unterstützen, das die Funktion CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA für Geräte mit mehreren Kameras in derselben Richtung auflistet, die aus jeder physischen Kamera in dieser Richtung besteht, sofern der physische Kameratyp vom Framework unterstützt wird und CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL für die physischen Kameras entweder LIMITED, FULL oder LEVEL_3 ist.

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 primär im Querformat verwendet werden, als auch für Geräte, die primär 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, den Anwendungen zum Herunterladen von Datendateien verwenden 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 einen von Anwendungen gemeinsam genutzten Speicher anbieten, der auch als „freigegebener externer Speicher“, „von Anwendungen gemeinsam genutzter Speicher“ oder als der Linux-Pfad „/sdcard“ bezeichnet wird, 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] MUSS den freigegebenen Speicher der Anwendung direkt im Linux-Pfad sdcard einbinden oder einen symbolischen Linux-Link von sdcard zum tatsächlichen Mount-Punkt einfügen.
• [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 mit einer der folgenden Methoden erfüllen:

• Vom Nutzer zugänglicher Wechselspeicher, z. B. ein SD-Kartensteckplatz (Secure Digital).
• Ein Teil des internen (nicht herausnehmbaren) 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 Material, das zum Zeitpunkt des Kaufs verfügbar ist, 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 freigegebenen Speicher enthalten (z. B. sowohl einen SD-Kartensteckplatz als auch einen freigegebenen internen Speicher), gilt Folgendes:

• [C-2-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 die 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 storage 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 Traffics 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, die die Vbus-Spannung über die Standardwerte hinaus ändern oder die Sink-/Source-Rollen ändern, 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 das Gerät USB Typ-C und den USB-Hostmodus unterstützt.
• 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, gilt Folgendes:

• [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 Verbindung von Standard-USB-Peripheriegeräten unterstützen, d. h., es MUSS entweder:
  • Ein Typ-C-Anschluss am Gerät oder ein Kabel, das einen proprietären Anschluss am Gerät in einen Standard-USB-Typ-C-Anschluss umwandelt (USB-Typ-C-Gerät).
  • Sie haben einen Typ A-Anschluss oder werden mit Kabeln geliefert, die einen proprietären Anschluss des Geräts an einen Standard-USB-Typ A-Anschluss anpassen.
  • Das Gerät muss einen Micro-AB-Port haben, der mit einem Kabel geliefert wird, 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) implementiert werden.
• [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 Audioadapter-Zubehörmodus NICHT zu unterstützen, wie in Anhang A der USB Type-C Cable and Connector Specification 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, gilt Folgendes:

• [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 Aufnahme 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 Audioausgangsanschluss 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-Op 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 Geräteimplementierungen mit Headsets und anderem Audiozubehör kompatibel sind, die den 3,5‑mm-Audiostecker im gesamten Android-Ökosystem verwenden, gilt Folgendes, wenn sie einen oder mehrere analoge Audioanschlüsse enthalten:

• [C-SR] Es wird DRINGEND EMPFOHLEN, dass mindestens einer der Audioanschlüsse eine 3,5-mm-Audiobuchse mit vier Leitern ist.

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 den Mikrofon- und 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 bei Einstecken eines Steckers ACTION_HEADSET_PLUG auslösen, jedoch 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.
• [C-1-7] MÜSSEN den Tastencode für den folgenden Bereich der äquivalenten Impedanz zwischen dem Mikrofon und den Masseleitern am Audio-Stecker erkennen und zuordnen:
  • 110–180 Ohm:KEYCODE_VOICE_ASSIST
• [C-SR] Es wird DRINGEND EMPFOHLEN, Audio-Stecker mit der OMTP-Pinbelegung zu unterstützen.
• [C-SR] Es wird DRINGEND EMPFOHLEN, die Audioaufnahme über Stereo-Headsets mit Mikrofon zu 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 wird, gilt Folgendes:

• [C-2-1] MUSS die Erkennung des Mikrofons am angeschlossenen Audiozubehör unterstützen.

7.8.3. Nahe am Ultraschall

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-Modus – Hohe Leistung

Wenn Geräteimplementierungen den VR-Modus unterstützen, gilt Folgendes:

• [C-1-1] MUSS mindestens 2 physische Kerne haben.
• [C-1-2] MÜSSEN die android.hardware.vr.high_performance-Funktion 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 android.hardware.vulkan.level 0 unterstützen.
• Sollte android.hardware.vulkan.level 1 oder höher 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, EGL_EXT_image_gl_colorspace implementieren und die Erweiterungen in der Liste der verfügbaren EGL-Erweiterungen verfügbar machen.
• [C-1-8] MUSS GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture und GL_EXT_protected_textures implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen verfügbar machen.
• [C-SR] Es wird DRINGEND EMPFOHLEN, GL_EXT_external_buffer und GL_EXT_EGL_image_array zu implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen zu präsentieren.
• [C-SR] Es wird DRINGEND EMPFOHLEN, Vulkan 1.1 zu unterstützen.
• [C-SR] Es wird DRINGEND EMPFOHLEN, VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing und VK_KHR_shared_presentable_image zu implementieren und in der Liste der verfügbaren Vulkan-Erweiterungen verfügbar zu machen.
• [C-SR] Es wird DRINGEND EMPFOHLEN, mindestens eine Vulkan-Warteschlangenfamilie verfügbar zu machen, in der flags sowohl VK_QUEUE_GRAPHICS_BIT als auch VK_QUEUE_COMPUTE_BIT enthält und queueCount mindestens 2 ist.
• [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-9] MÜSSEN die Unterstützung für die AHardwareBuffer-Flags AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA und AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT implementieren, wie im NDK beschrieben.
• [C-1-10] MUSS die Unterstützung für AHardwareBuffer mit einer beliebigen Kombination der Nutzungs-Flags AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT für mindestens die folgenden Formate implementieren: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] Es wird DRINGEND EMPFOHLEN, die Zuweisung von AHardwareBuffers mit mehr als einer Ebene sowie Flags und Formaten zu unterstützen, die in C-1-10 angegeben sind.
• [C-1-11] MUSS die H.264-Decodierung mit mindestens 3840 × 2160 bei 30 fps unterstützen, komprimiert auf durchschnittlich 40 Mbit/s (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 und mindestens 1920 × 1080 bei 30 fps mit einer durchschnittlichen Komprimierung von 10 Mbit/s decodieren können. Das Gerät SOLLTE 3840 × 2160 bei 30 fps mit einer durchschnittlichen Komprimierung von 20 Mbit/s decodieren können (entspricht 4 Instanzen von 1920 × 1080 bei 30 fps mit einer durchschnittlichen Komprimierung von 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 und seine Auflösung MUSS mindestens 1.920 × 1.080 betragen.
• [C-SR] Es wird DRINGEND EMPFOHLEN, eine Bildschirmauflösung von mindestens 2560 × 1440 zu verwenden.
• [C-1-15] Das Display MUSS im VR-Modus mit mindestens 60 Hz aktualisiert werden.
• [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] MÜSSEN 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-SR] Es wird DRINGEND EMPFOHLEN, den direkten Channeltyp TYPE_HARDWARE_BUFFER für alle oben aufgeführten direkten Channeltypen zu unterstützen.
• [C-1-21] MÜSSEN die Anforderungen an Gyroskop, Beschleunigungsmesser und Magnetometer für android.hardware.hifi_sensors gemäß Abschnitt 7.3.9 erfüllen.
• [C-SR] Es wird DRINGEND EMPFOHLEN, die android.hardware.sensor.hifi_sensors-Funktion zu unterstützen.
• [C-1-22] Die End-to-End-Latenz von Bewegung zu Photon darf nicht höher als 28 Millisekunden sein.
• [C-SR] Es wird DRINGEND EMPFOHLEN, dass die End-to-End-Latenz zwischen Bewegung und Photon nicht höher als 20 Millisekunden ist.
• [C-1-23] Das Verhältnis des ersten Frames, also das Verhältnis zwischen der Helligkeit der Pixel im ersten Frame nach einem Übergang von Schwarz zu Weiß und der Helligkeit der weißen Pixel im Steady State, MUSS mindestens 85 % betragen.
• [C-SR] Es wird DRINGEND EMPFOHLEN, ein First-Frame-Verhältnis von mindestens 90 % zu haben.
• 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 reserviert sind.

Wenn der exklusive Kern unterstützt wird, gilt Folgendes:

• [C-2-1] Auf dem Prozessor dürfen 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 einheitliche Dateizugriffsleistung im privaten Datenspeicher der Anwendung (/data-Partition) ermöglicht es App-Entwicklern, eine angemessene Erwartung festzulegen, 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 sind:

• Sequenzielle Schreibleistung: Gemessen durch Schreiben einer 256 MB großen Datei mit einem 10 MB großen 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

Wenn Geräteimplementierungen Funktionen zur Verbesserung der Energieverwaltung des Geräts enthalten, die in AOSP enthalten sind oder die in AOSP enthaltenen Funktionen erweitern, gilt Folgendes:

• [C-1-1] Die Trigger-, Wartungs- und Weckalgorithmen sowie die Verwendung globaler Systemeinstellungen der App-Standby- und Doze-Energiesparmodi DÜRFEN NICHT von der AOSP-Implementierung abweichen.
• [C-1-2] Die Verwendung globaler Einstellungen zum Verwalten der Drosselung von Jobs, Alarmen und Netzwerken für Apps in den einzelnen App-Standby-Buckets darf NICHT von der AOSP-Implementierung abweichen.
• [C-1-3] Die Anzahl der für den App-Standby verwendeten App-Standby-Buckets DARF NICHT von der AOSP-Implementierung abweichen.
• [C-1-4] MÜSSEN App Standby Buckets und Doze wie unter Energieverwaltung beschrieben implementieren.
• [C-1-5] true MUSS für PowerManager.isPowerSaveMode() zurückgegeben werden, wenn sich das Gerät im Energiesparmodus befindet.
• [C-SR] Es wird DRINGEND EMPFOHLEN, dem Nutzer die Möglichkeit zu geben, den Energiesparmodus zu aktivieren und zu deaktivieren.
• [C-SR] Es wird DRINGEND EMPFOHLEN, Nutzern die Möglichkeit zu geben, alle Apps anzuzeigen, die von den Energiesparmodi „App-Standby“ und „Doze“ ausgenommen sind.

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 S4-Energiezustände gemäß ACPI implementieren, gilt Folgendes:

• [C-1-1] MUSS nur dann in diesen Status wechseln, wenn der Nutzer eine explizite Aktion ausgeführt hat, um das Gerät in einen inaktiven Status zu versetzen (z.B. durch Schließen eines Deckels, der physisch Teil des Geräts ist, oder durch Ausschalten eines Fahrzeugs oder Fernsehers), und bevor der Nutzer das Gerät reaktiviert (z.B. durch Öffnen des Deckels oder durch erneutes Einschalten des Fahrzeugs oder Fernsehers).

Wenn Geräteimplementierungen S3-Energiezustände gemäß ACPI implementieren, gilt Folgendes:

• [C-2-1] MUSS C-1-1 oben entsprechen ODER den S3-Status nur dann aufrufen, wenn Drittanbieteranwendungen die Systemressourcen (z.B. Bildschirm, CPU) nicht benötigen.

  Umgekehrt MUSS der S3-Status beendet werden, wenn Drittanbieteranwendungen die Systemressourcen benötigen, wie in diesem SDK beschrieben.

  Wenn Drittanbieteranwendungen beispielsweise über FLAG_KEEP_SCREEN_ON anfordern, dass der Bildschirm eingeschaltet bleibt, oder über PARTIAL_WAKE_LOCK, dass die CPU weiter ausgeführt wird, DARF das Gerät NICHT in den S3-Status wechseln, es sei denn, der Nutzer hat, wie in C-1-1 beschrieben, explizit Maßnahmen ergriffen, um das Gerät in einen inaktiven Status zu versetzen. Wenn hingegen eine Aufgabe, die von Drittanbieter-Apps über JobScheduler implementiert wird, ausgelöst wird oder Firebase Cloud Messaging an Drittanbieter-Apps gesendet wird, MUSS das Gerät den S3-Status verlassen, es sei denn, der Nutzer hat das Gerät in einen inaktiven Status versetzt. Dies sind keine umfassenden Beispiele. AOSP implementiert umfangreiche Wecksignale, die ein Aufwachen aus diesem Status auslösen.

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 für die APIs 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 gewährt 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 anzeigen, über die der Nutzer entscheiden kann, ob er die angeforderten Laufzeitberechtigungen erteilen möchte. Außerdem MUSS eine Benutzeroberfläche zur 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.
• [C-0-6] MUSS die Berechtigung android.permission.RECOVER_KEYSTORE nur System-Apps gewähren, die einen ordnungsgemäß gesicherten Wiederherstellungs-Agent registrieren. Ein ordnungsgemäß gesicherter Wiederherstellungs-Agent ist ein On-Device-Software-Agent, der mit einem Off-Device-Remotespeicher synchronisiert wird, der mit sicherer Hardware mit einem Schutz ausgestattet ist, der dem in Google Cloud Key Vault Service beschriebenen Schutz entspricht oder stärker ist, um Brute-Force-Angriffe auf den Sperrbildschirm-Wissensfaktor zu verhindern.

Wenn Geräteimplementierungen eine vorinstallierte App enthalten oder Drittanbieter-Apps Zugriff auf die Nutzungsstatistiken gewähren möchten, müssen sie:

• [SR] 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-1-1] MUSS weiterhin eine Aktivität haben, die das Intent-Muster android.settings.ACTION_USAGE_ACCESS_SETTINGS verarbeitet, MUSS es aber als No-Op implementieren, d. h. 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-Berechtigungsmodell für den Dateizugriff 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 NICHT auf Ressourcen zugreifen, 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 keiner anderen auf dem Gerät installierten App wiederverwenden, es sei denn, dies erfolgt über die standardmäßigen Android-Mechanismen für die gemeinsame Nutzer-ID und das Signaturzertifikat.

• [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] MUSS für jede Nutzerinstanz separate und isolierte Verzeichnisse für den gemeinsamen Anwendungsspeicher (auch /sdcard genannt) haben.
• [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] 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] MUSS keine eingeschränkten Profile unterstützen, MUSS aber der AOSP-Implementierung von Steuerelementen entsprechen, mit denen andere Nutzer den Zugriff auf Anrufe 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. Sicherheitsfunktionen

Geräteimplementierungen MÜSSEN die Einhaltung der Sicherheitsfunktionen sowohl im Kernel als auch auf der Plattform wie unten beschrieben sicherstellen.

Die Android-Sandbox umfasst Funktionen, die das obligatorische Zugriffssteuerungssystem (MAC) von Security-Enhanced Linux (SELinux), Seccomp-Sandboxing und andere Sicherheitsfunktionen im Linux-Kernel verwenden. Geräteimplementierungen:

• [C-0-1] Die Kompatibilität mit vorhandenen Anwendungen MUSS aufrechterhalten werden, auch wenn SELinux oder andere Sicherheitsfunktionen unter dem Android-Framework implementiert sind.
• [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-Android Open Source Project 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 Kernelstack 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).
• [C-0-9] Auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden, MUSS eine statische und dynamische Prüfung der Objektgrößenbegrenzungen von Kopien zwischen Nutzer- und Kernelbereich (z.B. CONFIG_HARDENED_USERCOPY) implementiert werden.
• [C-0-10] Auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden, DARF bei der Ausführung im Kernelmodus (z.B. Hardware-PXN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) KEIN Nutzerspeicher ausgeführt werden.
• [C-0-11] Auf Geräten, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden, DARF der Kernel den Arbeitsspeicher des Nutzerbereichs nicht außerhalb der normalen Usercopy-Zugriffs-APIs (z.B. Hardware-PAN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) lesen oder schreiben.
• [C-0-12] MUSS die Kernel-Seitentabellenisolation auf allen Geräten implementieren, die ursprünglich mit API-Ebene 28 oder höher ausgeliefert wurden (z.B. CONFIG_PAGE_TABLE_ISOLATION oder „CONFIG_UNMAP_KERNEL_AT_EL0“).
• [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, 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 NICHT die „neverallow“-Regeln ändern, weglassen oder ersetzen, die im System-/sepolicy-Ordner des Upstream-Android Open Source Project (AOSP) enthalten sind. Die Richtlinie MUSS mit allen vorhandenen „neverallow“-Regeln kompiliert werden, sowohl für AOSP-SELinux-Domains als auch für geräte-/anbieterspezifische Domains.
• [C-1-5] MÜSSEN Drittanbieteranwendungen, die auf API-Ebene 28 oder höher ausgerichtet sind, in SELinux-Sandboxes pro Anwendung mit SELinux-Einschränkungen pro App für das private Datenverzeichnis jeder Anwendung ausgeführt werden.
• 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 Geräteimplementierungen bereits mit einer früheren Android-Version eingeführt wurden und die Anforderungen [C-1-1] und [C-1-5] nicht durch ein Systemsoftware-Update erfüllen können, KÖNNEN sie von diesen Anforderungen ausgenommen werden.

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

• [C-2-1] MUSS ein System zur obligatorischen Zugriffssteuerung verwenden, das SELinux entspricht.

Android enthält mehrere Funktionen für gestaffelte Sicherheitsebenen, die für die Gerätesicherheit unerlässlich sind.

Geräteimplementierungen:

• [C-SR] Es wird DRINGEND EMPFOHLEN, die Control-Flow Integrity (CFI) oder die Integer Overflow Sanitization (IntSan) nicht für Komponenten zu deaktivieren, für die sie aktiviert sind.
• [C-SR] Es wird DRINGEND EMPFOHLEN, sowohl CFI als auch IntSan für alle zusätzlichen sicherheitssensiblen Nutzerbereichskomponenten zu aktivieren, wie in CFI und IntSan beschrieben.

9.8. Datenschutz

9.8.1. Nutzungsverlauf

Android speichert den Verlauf der Nutzerauswahl und verwaltet ihn mit UsageStatsManager.

Geräteimplementierungen:

• [C-0-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.

Android speichert die Systemereignisse mit den StatsLog-Kennungen und verwaltet den Verlauf über die System-APIs StatsManager und IncidentManager.

Geräteimplementierungen:

• [C-0-2] MUSS nur die Felder enthalten, die im Vorfallbericht, der von der System-API-Klasse IncidentManager erstellt wurde, mit DEST_AUTOMATIC gekennzeichnet sind.
• [C-0-3] Die Systemereignis-IDs DÜRFEN NICHT verwendet werden, um andere Ereignisse als die in der StatsLog-SDK-Dokumentation beschriebenen zu protokollieren. Wenn zusätzliche Systemereignisse protokolliert werden, kann dafür eine andere Atom-ID im Bereich zwischen 100.000 und 200.000 verwendet werden.

9.8.2. Aufnahme

Geräteimplementierungen:

• [C-0-1] Softwarekomponenten, die private Informationen des Nutzers (z.B. Tastenanschläge, auf dem Bildschirm angezeigter Text) ohne die Einwilligung des Nutzers oder klare fortlaufende Benachrichtigungen vom Gerät senden, DÜRFEN NICHT vorinstalliert oder standardmäßig verteilt werden.

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 eines Nutzers 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 Nutzeraufforderung zum Aktivieren der Funktion „Durchgehend aktives VPN“ einer VPN-App eines Drittanbieters implementieren, 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 die Krypto-Leistung des Advanced Encryption Standard (AES), gemessen mit der leistungsstärksten auf dem Gerät verfügbaren AES-Technologie (z.B. den ARM Cryptography Extensions), über 50 MiB/s liegt, müssen Geräteimplementierungen:

• [C-1-1] Die Verschlüsselung des Datenspeichers der privaten Daten der Anwendung (/data-Partition) sowie der Partition des von der Anwendung gemeinsam genutzten Speichers (/sdcard-Partition) MUSS unterstützt werden, wenn es sich um einen permanenten, nicht entfernbaren Teil des Geräts handelt, mit Ausnahme von Geräteimplementierungen, die in der Regel gemeinsam genutzt werden (z.B. Fernseher).
• [C-1-2] MUSS die Verschlüsselung des Datenspeichers standardmäßig aktivieren, sobald der Nutzer die Einrichtung abgeschlossen hat. Dies gilt nicht für Geräte, die in der Regel gemeinsam genutzt werden (z. B. Fernseher).

Wenn die AES-Verschlüsselungsleistung bei oder unter 50 MiB/s liegt, KÖNNEN Geräteimplementierungen Adiantum-XChaCha12-AES anstelle der in den folgenden Abschnitten aufgeführten AES-Formen verwenden: AES-256-XTS in Abschnitt 9.9.2 [C-1-5]; AES-256 im CBS-CTS-Modus in Abschnitt 9.9.2 [C-1-6]; AES in Abschnitt 9.9.3 [C-1-1]; AES in Abschnitt 9.9.3 [C-1-3].

Wenn Geräteimplementierungen bereits mit einer früheren Android-Version eingeführt wurden und die Anforderung nicht durch ein Systemsoftware-Update erfüllt werden kann, KÖNNEN sie von den oben genannten Anforderungen ausgenommen werden.

Geräteimplementierungen:

• 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] MUSS die APIs für den Direct Boot-Modus implementieren, 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-kompatiblen Apps zu signalisieren, dass die Speicherorte „Device Encrypted“ (DE) und „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 hochfahren, ohne den Nutzer nach Anmeldedaten zu fragen, und Apps, die Direct Boot unterstützen, den Zugriff auf den geräteverschlüsselten (Device Encrypted, DE) Speicher nach dem Broadcast der ACTION_LOCKED_BOOT_COMPLETED-Nachricht ermöglichen.
• [C-1-2] Der Zugriff auf den Credential Encrypted (CE)-Speicher MUSS erst dann möglich sein, wenn 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 angegebenen Anmeldedaten oder einen registrierten Escrow-Schlüssel angeboten werden.
• [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‑256‑XTS unterstützen. AES‑256‑XTS bezieht sich auf den Advanced Encryption Standard mit einer Schlüssellänge von 256 Bit, der im XTS-Modus betrieben wird. Die vollständige Länge des XTS-Schlüssels beträgt 512 Bit.

• [C-1-6] MUSS die Verschlüsselung von Dateinamen mit AES-256 im CBC-CTS-Modus unterstützen.

• Die Schlüssel zum Schutz der Speicherbereiche für CE und DE:

• [C-1-7] MUSS kryptografisch an einen hardwaregestützten Keystore gebunden sein.

• [C-1-8] CE-Schlüssel MÜSSEN an die Sperrbildschirm-Anmeldedaten 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 sein. Das heißt, der Schlüssel für die vertrauliche Umgebung oder das Geräte-Attest eines Nutzers darf nicht mit dem Schlüssel für die vertrauliche Umgebung oder das Geräte-Attest eines anderen Nutzers übereinstimmen.

• [C-1-11] MUSS standardmäßig die obligatorisch unterstützten Chiffren, Schlüssellängen und Modi verwenden.

• [C-SR] Es wird DRINGEND EMPFOHLEN, Dateisystemmetadaten wie Dateigrößen, Inhaberschaft, Modi und erweiterte Attribute (xattrs) mit einem Schlüssel zu verschlüsseln, der kryptografisch an den Hardware-Root of Trust des Geräts gebunden ist.

• WICHTIG: Vorinstallierte wichtige Apps (z.B. Wecker, Telefon, Messenger) SOLLTEN für den Direktstart optimiert werden.

• MAY support alternative ciphers, key lengths and modes for file content and file name encryption.

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 in einem für die Speicherung entwickelten Modus (z. B. XTS oder CBC-ESSIV) und mit einer Chiffrierschlüssellänge von mindestens 128 Bit 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.

• [C-0-2] MUSS den Bootmodus mit Verifikation zur Überprüfung der Geräteintegrität unterstützen.

Wenn Geräteimplementierungen bereits ohne Unterstützung des Bootmodus mit Verifikation in einer früheren Android-Version eingeführt wurden und die Unterstützung für diese Funktion nicht durch ein Systemsoftware-Update hinzugefügt werden kann, KÖNNEN sie von der Anforderung ausgenommen werden.

Der verifizierte Bootmodus ist eine Funktion, die die Integrität der Gerätesoftware garantiert. Wenn Geräteimplementierungen die Funktion unterstützen, 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 Bestätigung 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.
• [C-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.
• [C-1-8] MUSS manipulationssicheren Speicher verwenden, um zu speichern, ob der Bootloader entsperrt ist. Manipulationssicherer Speicher bedeutet, dass der Bootloader erkennen kann, ob der Speicher von Android aus manipuliert wurde.
• [C-1-9] MUSS den Nutzer während der Verwendung des Geräts auffordern und eine physische Bestätigung verlangen, bevor ein Übergang vom gesperrten Bootloader-Modus zum entsperrten Bootloader-Modus zugelassen wird.
• [C-1-10] Es MUSS ein Rollback-Schutz für von Android verwendete Partitionen (z.B. Boot- und Systempartitionen) implementiert werden und es MUSS ein manipulationssicherer Speicher zum Speichern der Metadaten verwendet werden, die zur Bestimmung der zulässigen Mindestversion des Betriebssystems verwendet werden.
• [C-SR] Es wird DRINGEND EMPFOHLEN, alle APK-Dateien privilegierter Apps mit einer Vertrauenskette zu überprüfen, die in /system verwurzelt ist und durch Verified Boot geschützt wird.
• [C-SR] Es wird DRINGEND EMPFOHLEN, alle ausführbaren Artefakte, die von einer privilegierten App außerhalb ihrer APK-Datei geladen werden (z. B. dynamisch geladener Code oder kompilierter Code), vor der Ausführung zu überprüfen oder DRINGEND EMPFOHLEN, sie überhaupt nicht auszuführen.
• 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.

Wenn Geräteimplementierungen bereits ohne Unterstützung von C-1-8 bis C-1-10 in einer früheren Android-Version eingeführt wurden und die Unterstützung dieser Anforderungen nicht durch ein Systemsoftware-Update hinzugefügt werden kann, KÖNNEN sie von den Anforderungen ausgenommen 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.

Geräteimplementierungen:

• [C-R] Es wird EMPFOHLEN, die Android Protected Confirmation API zu unterstützen.

Wenn Geräteimplementierungen die Android Protected Confirmation API unterstützen, gilt Folgendes:

• [C-3-1] MUSS true für die ConfirmationPrompt.isSupported() API melden.
• [C-3-2] MUSS dafür sorgen, dass die sichere Hardware die vollständige Kontrolle über das Display übernimmt, sodass das Android-Betriebssystem es nicht blockieren kann, ohne dass die sichere Hardware dies erkennt.
• [C-3-3] MUSS dafür sorgen, dass die sichere Hardware die vollständige Kontrolle über den Touchscreen übernimmt.

9.11. Schlüssel und Anmeldedaten

Mit dem Android Keystore System können App-Entwickler kryptografische Schlüssel in einem Container speichern und in kryptografischen Vorgängen über die KeyChain API oder die Keystore API verwenden. Geräteimplementierungen:

• [C-0-1] Es MUSS möglich sein,mindestens 8.192 Schlüssel zu importieren oder zu generieren.
• [C-0-2] Die Authentifizierung auf dem Sperrbildschirm MUSS Versuche ratenbegrenzen und einen exponentiellen Backoff-Algorithmus haben. 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] Die Keystore-Implementierung MUSS durch eine isolierte Ausführungsumgebung gesichert werden.
• [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 kann, 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, damit sie nicht als Geräte-IDs verwendet werden können. 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 jede Gruppe von 100.000 Einheiten ein anderer Schlüssel verwendet werden.
• [C-1-5] MUSS dem Nutzer ermöglichen, das Zeitlimit für den Übergang vom entsperrten in den gesperrten Zustand festzulegen. Das Mindestzeitlimit beträgt 15 Sekunden.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version eingeführt wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen durch eine isolierte Ausführungsumgebung gesicherten Keystore zu haben und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert das android.hardware.fingerprint-Feature, für das ein durch eine isolierte Ausführungsumgebung gesicherter Keystore erforderlich ist.

9.11.1. Sicherer Sperrbildschirm

Die AOSP-Implementierung folgt einem mehrstufigen Authentifizierungsmodell, bei dem eine primäre Authentifizierung auf Grundlage eines Wissensfaktors entweder durch eine sekundäre starke biometrische Authentifizierung oder durch schwächere tertiäre Modalitäten unterstützt werden kann.

Geräteimplementierungen:

• [C-SR] Es wird DRINGEND EMPFOHLEN, nur eine der folgenden Optionen als primäre Authentifizierungsmethode festzulegen:
  • Eine numerische PIN
  • Ein alphanumerisches Passwort
  • Ein Wischmuster auf einem Raster mit genau 3 × 3 Punkten

Die oben genannten Authentifizierungsmethoden werden in diesem Dokument als empfohlene primäre Authentifizierungsmethoden bezeichnet.

Wenn in Geräteimplementierungen die empfohlenen primären Authentifizierungsmethoden hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode als sichere Methode zum Sperren des Displays verwendet wird, muss die neue Authentifizierungsmethode:

• [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 EINE DRITTANBIETER-ENTWICKLER-APP ENTSPERRT 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 Grundlage eines bekannten Geheimnisses hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode als sichere Methode zum Sperren des Bildschirms verwendet wird:

• [C-3-1] Die Entropie der kürzesten zulässigen Länge von Eingaben 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] Die neue Authentifizierungsmethode DARF KEINE der empfohlenen primären Authentifizierungsmethoden (d.h. PIN, Muster, Passwort) ersetzen, die in AOSP implementiert und bereitgestellt werden.
• [C-3-4] Die neue Authentifizierungsmethode MUSS deaktiviert werden, wenn die DPC-Anwendung (Device Policy Controller) die Passwortrichtlinie über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_SOMETHING festgelegt hat.

Wenn in Geräteimplementierungen die empfohlenen primären Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode verwendet wird, die auf Biometrie basiert und als sichere Methode zum Sperren des Bildschirms gilt, muss die neue Methode:

• [C-4-1] MUSS alle in Abschnitt 7.3.10.2 beschriebenen Anforderungen erfüllen.
• [C-4-2] MUSS einen Fallback-Mechanismus haben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Secret basiert.
• [C-4-3] MUSS deaktiviert sein und darf nur die empfohlene primäre Authentifizierung zum Entsperren des Displays zulassen, wenn die DPC-Anwendung (Device Policy Controller) die Funktion „keguard“ durch Aufrufen der Methode DevicePolicyManager.setKeyguardDisabledFeatures() mit einem der zugehörigen biometrischen Flags (d.h. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE oder KEYGUARD_DISABLE_IRIS) festgelegt hat.
• [C-4-4] Der Nutzer MUSS mindestens einmal alle 72 Stunden oder weniger zur Eingabe der empfohlenen primären Authentifizierung (z.B. PIN, Muster, Passwort) aufgefordert werden.
• [C-4-5] MUSS eine Falschakzeptanzrate haben, die der für einen Fingerabdrucksensor gemäß Abschnitt 7.3.10 erforderlichen Rate entspricht oder niedriger ist. Andernfalls MUSS die Funktion deaktiviert sein und das Entsperren des Displays darf nur über die empfohlene 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.
• [C-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.
• [C-4-6] MUSS eine sichere Verarbeitungspipeline haben, sodass durch eine Kompromittierung des Betriebssystems oder des Kernels keine Daten direkt eingefügt werden können, um sich fälschlicherweise als Nutzer zu authentifizieren.
• [C-4-7] MUSS mit einer expliziten Bestätigungsaktion (z. B. einem Tastendruck) gekoppelt werden, um den Zugriff auf Keystore-Schlüssel zu ermöglichen, wenn die Anwendung true für KeyGenParameterSpec.Built.setUserAuthenticationRequired() festlegt und die biometrische Authentifizierung passiv ist (z. B. Gesicht oder Iris, bei denen kein explizites Signal für die Absicht vorhanden ist).
• [C-SR] Es wird DRINGEND EMPFOHLEN, die Bestätigungsaktion für passive Biometrie so zu sichern, dass sie nicht durch eine Kompromittierung des Betriebssystems oder des Kernels gefälscht werden kann. Das bedeutet beispielsweise, dass die Bestätigungsaktion, die auf einer physischen Schaltfläche basiert, über einen reinen Eingabe-GPIO-Pin (General-Purpose Input/Output) eines sicheren Elements (SE) geleitet wird, der nur durch Drücken einer physischen Schaltfläche ausgelöst werden kann.

Wenn die biometrischen Authentifizierungsmethoden die in Abschnitt 7.3.10 beschriebenen Akzeptanzraten für Spoofing und Identitätsdiebstahl nicht erfüllen:

• [C-5-1] Die Methoden MÜSSEN deaktiviert werden, 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.
• [C-5-2] Der Nutzer MUSS nach einem Inaktivitätszeitraum von 4 Stunden zur empfohlenen primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden. Der Inaktivitäts-Zeitüberschreitungszeitraum wird nach jeder erfolgreichen Bestätigung der Geräteanmeldedaten zurückgesetzt.
• [C-5-3] Die Methoden DÜRFEN NICHT als sicherer Sperrbildschirm behandelt werden und MÜSSEN die Anforderungen erfüllen, die in diesem Abschnitt unten mit C-8 beginnen.

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode auf einem physischen Token oder dem Standort basiert:

• [C-6-1] Sie MÜSSEN einen Fallback-Mechanismus haben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Secret basiert und die Anforderungen für einen sicheren Sperrbildschirm erfüllt.
• [C-6-2] Die neue Methode MUSS deaktiviert sein und nur eine der empfohlenen primären Authentifizierungsmethoden zum Entsperren des Bildschirms 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-6-3] Der Nutzer MUSS mindestens alle 72 Stunden oder weniger zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z.B.PIN, Muster, Passwort) aufgefordert werden.
• [C-6-4] Die neue Methode darf NICHT als sicherer Sperrbildschirm behandelt werden und muss den unten in C-8 aufgeführten Einschränkungen entsprechen.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und mindestens einen Trust-Agent enthalten, der die TrustAgentService-System-API implementiert, gilt Folgendes:

• [C-7-1] Es MUSS im Einstellungsmenü und auf dem Sperrbildschirm deutlich darauf hingewiesen werden, wenn die Gerätesperre verzögert wird oder durch Trust Agents entsperrt werden kann. AOSP erfüllt diese Anforderung beispielsweise, indem im Einstellungsmenü eine Textbeschreibung für die Einstellung „Automatisch sperren“ und „Ein/Aus-Taste sperrt sofort“ sowie ein eindeutiges Symbol auf dem Sperrbildschirm angezeigt werden.
• [C-7-2] MUSS alle Trust-Agent-APIs in der Klasse DevicePolicyManager respektieren und vollständig implementieren, z. B. die Konstante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] Die TrustAgentService.addEscrowToken()-Funktion 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), DÜRFEN aber vollständig auf Geräteimplementierungen implementiert werden, die in der Regel gemeinsam genutzt werden (z.B. Android-Fernseher oder Automotive-Geräte).
• [C-7-4] ALLE von TrustAgentService.addEscrowToken() hinzugefügten gespeicherten Tokens MÜSSEN verschlüsselt werden.
• [C-7-5] Der Verschlüsselungsschlüssel DARF NICHT auf demselben Gerät gespeichert werden, auf dem er verwendet wird. Beispiel: Ein auf einem Smartphone gespeicherter Schlüssel darf ein Nutzerkonto auf einem Fernseher entsperren.
• [C-7-6] Der Nutzer MUSS über die Sicherheitsrisiken informiert werden, bevor das Escrow-Token zum Entschlüsseln des Datenspeichers aktiviert wird.
• [C-7-7] MUSS einen Fallback-Mechanismus haben, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden.
• [C-7-8] Der Nutzer MUSS mindestens alle 72 Stunden oder weniger zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) aufgefordert werden.
• [C-7-9] Der Nutzer MUSS nach einem Inaktivitätszeitraum von 4 Stunden zur Eingabe einer der empfohlenen primären Authentifizierungsmethoden (z. B. PIN, Muster, Passwort) aufgefordert werden. Der Inaktivitäts-Zeitüberschreitungszeitraum wird nach jeder erfolgreichen Bestätigung der Geräteanmeldedaten zurückgesetzt.
• [C-7-10] DARF NICHT als sicherer Sperrbildschirm behandelt werden und MUSS die unten in C-8 aufgeführten Einschränkungen einhalten.

Wenn in Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms, der kein sicherer Sperrbildschirm wie oben beschrieben ist, hinzugefügt oder geändert werden und eine neue Authentifizierungsmethode zum Entsperren des Keyguards verwendet wird:

• [C-8-1] Die neue Methode MUSS deaktiviert werden, wenn die DPC-Anwendung (Device Policy Controller) die Passwortqualitätsrichtlinie über die Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_UNSPECIFIED festgelegt hat.
• [C-8-2] Sie DÜRFEN die von DevicePolicyManager.setPasswordExpirationTimeout() festgelegten Timer für den Ablauf des Passworts NICHT zurücksetzen.
• [C-8-3] Der Zugriff auf Keystores darf NICHT authentifiziert werden, wenn die Anwendung true für KeyGenParameterSpec.Builder.setUserAuthenticationRequired() festlegt.

9.11.2. StrongBox

Mit dem Android Keystore System können App-Entwickler kryptografische Schlüssel in einem dedizierten sicheren Prozessor sowie in der oben beschriebenen isolierten Ausführungsumgebung speichern.

Geräteimplementierungen:

• [C-SR] Es wird DRINGEND EMPFOHLEN, StrongBox zu unterstützen.

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

• [C-1-1] MUSS FEATURE_STRONGBOX_KEYSTORE deklarieren.

• [C-1-2] MUSS eine dedizierte sichere Hardware bereitstellen, die zur Unterstützung des Keystores und der sicheren Nutzerauthentifizierung verwendet wird.

• [C-1-3] MUSS eine separate CPU haben, die keinen Cache, DRAM, Coprozessoren oder andere Kernressourcen mit dem Anwendungsprozessor (AP) teilt.

• [C-1-4] MUSS dafür sorgen, dass Peripheriegeräte, die mit dem AP gemeinsam genutzt werden, die StrongBox-Verarbeitung in keiner Weise verändern oder Informationen aus der StrongBox abrufen können. Die AP kann den Zugriff auf StrongBox deaktivieren oder blockieren.

• [C-1-5] MUSS eine interne Uhr mit angemessener Genauigkeit (±10%) haben, die nicht durch den AP manipuliert werden kann.

• [C-1-6] MUSS einen echten Zufallszahlengenerator haben, der gleichmäßig verteilte und unvorhersehbare Ausgaben erzeugt.

• [C-1-7] MUSS manipulationssicher sein, einschließlich Schutz vor physischem Eindringen und Glitching.

• [C-1-8] MUSS gegen Seitenkanalangriffe geschützt sein, einschließlich des Schutzes gegen das Auslesen von Informationen über Seitenkanäle wie Strom, Zeit, elektromagnetische Strahlung und Wärmestrahlung.

• [C-1-9] MUSS über einen sicheren Speicher verfügen, der die Vertraulichkeit, Integrität, Authentizität, Konsistenz und Aktualität der Inhalte gewährleistet. Der Speicher darf nur über die StrongBox-APIs gelesen oder geändert werden.

• Zur Validierung der Einhaltung von [C-1-3] bis [C-1-9] müssen Geräteimplementierungen:

  • [C-1-10] MUSS die Hardware enthalten, die gemäß dem Schutzprofil für sichere ICs BSI-CC-PP-0084-2014 zertifiziert oder von einem national akkreditierten Prüflabor bewertet wurde, das eine Schwachstellenbewertung mit hohem Angriffspotenzial gemäß den Common Criteria Application of Attack Potential to Smartcards (Anwendung des Angriffspotenzials auf Smartcards gemäß Common Criteria) durchführt.
  • [C-1-11] MUSS die Firmware enthalten, die von einem national akkreditierten Prüflabor bewertet wird, das eine Schwachstellenbewertung mit hohem Angriffspotenzial gemäß den Common Criteria Application of Attack Potential to Smartcards durchführt.
  • [C-SR] Es wird DRINGEND EMPFOHLEN, die Hardware einzubeziehen, die mit einem Security Target, Evaluation Assurance Level (EAL) 5, ergänzt durch AVA_VAN.5, bewertet wird. Die EAL5-Zertifizierung wird wahrscheinlich in einem zukünftigen Release erforderlich sein.

• [C-SR] wird DRINGEND EMPFOHLEN, um Insider-Angriffen (Insider Attack Resistance, IAR) zu widerstehen. Das bedeutet, dass ein Insider mit Zugriff auf Firmware-Signaturschlüssel keine Firmware erstellen kann, die dazu führt, dass die StrongBox Geheimnisse preisgibt, funktionale Sicherheitsanforderungen umgeht oder auf andere Weise den Zugriff auf vertrauliche Nutzerdaten ermöglicht. Die empfohlene Methode zur Implementierung von IAR besteht darin, Firmware-Updates nur zuzulassen, wenn das Passwort des primären Nutzers über das IAuthSecret HAL angegeben wird.

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.

9.15. Abos

„Abos“ bezieht sich auf die Abrechnungsbeziehungsplandetails, die von einem Mobilfunkanbieter über SubscriptionManager.setSubscriptionPlans() bereitgestellt werden.

Für alle Geräteimplementierungen gilt:

• [C-0-1] MÜSSEN Abos nur an die Mobilfunkanbieter-App zurückgeben, die sie ursprünglich bereitgestellt hat.
• [C-0-2] DÜRFEN Abos NICHT per Fernzugriff sichern oder hochladen.
• [C-0-3] MÜSSEN nur Überschreibungen wie SubscriptionManager.setSubscriptionOverrideCongested() aus der Mobilfunkanbieter-App zulassen, die derzeit gültige Abos anbietet.

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:

• [C-0-1] MUSS 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.

• [C-0-2] MUSS die Kompatibilität bei Unklarheiten im CTS und bei allen Reimplementierungen von Teilen des Referenzquellcodes sicherstellen.

Der 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 9 veröffentlicht werden.

Geräteimplementierungen:

• [C-0-3] MUSS die neueste CTS-Version bestehen, die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbar ist.

• Sollte die Referenzimplementierung im Android Open Source-Baum so weit wie möglich verwendet werden.

10.2. CTS‑Prüfung

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.

Geräteimplementierungen:

• [C-0-1] ALLE relevanten Fälle im CTS-Verifier MÜSSEN korrekt ausgeführt werden.

Der CTS-Verifier enthält Tests für viele Arten von Hardware, einschließlich einiger optionaler Hardware.

Geräteimplementierungen:

• [C-0-2] 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.

• [C-0-2] 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, müssen Geräteimplementierer den CTS-Verifier nicht explizit für Builds ausführen, die sich nur in unwichtigen 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

• [C-0-1] 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 durch einen der folgenden Ansätze 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.

• [C-0-2] 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.

Wenn die Geräteimplementierung die Unterstützung einer Datenverbindung ohne Volumenbegrenzung wie 802.11 oder Bluetooth PAN (Personal Area Network) umfasst, gilt Folgendes:

• [C-1-1] OTA-Downloads mit Offline-Update über Neustart MUSS unterstützt werden.

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-Android Open Source Project, 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 einer Geräteimplementierung, aber innerhalb ihrer angemessenen Produktlebensdauer, die in Absprache mit dem Android-Kompatibilitätsteam festgelegt wird, ein Fehler gefunden wird, der die Kompatibilität von Drittanbieteranwendungen beeinträchtigt, gilt Folgendes:

• [C-2-1] Der Gerätehersteller MUSS den Fehler über ein Softwareupdate beheben, das über den gerade beschriebenen Mechanismus angewendet werden kann.

Android enthält Funktionen, mit denen die Geräteinhaber-App (falls vorhanden) die Installation von Systemupdates steuern kann. Wenn das Subsystem für Systemupdates für Geräte „android.software.device_admin“ meldet, gilt Folgendes:

• [C-3-1] MUSS 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 Änderungslogs 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.