Android 9-Kompatibilitätsdefinition

1. Einführung

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

Die Verwendung von „MUSS“, „DARF NICHT“, „ERFORDERLICH“, „WIRD“, „WIRD NICHT“, „SOLLTE“, „SOLLTE NICHT“, „EMPFOHLEN“, „KÖNNEN“ und „OPTIONAL“ gemäß dem in RFC 2119 definierten IETF-Standard verwendet werden.

In diesem Dokument ist ein „Geräteimplementierung“ oder „Implementierer“ eine Person oder Organisation, die eine Hardware-/Softwarelösung für Android 9 entwickelt. Eine „Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte Hardware-/Softwarelösung.

Um als mit Android 9 kompatibel zu gelten, MÜSSEN Geräteimplementierungen den Anforderungen dieser Kompatibilitätsdefinition entsprechen, einschließlich aller Dokumente, auf die sie Bezug nimmt.

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

Aus diesem Grund ist das Android Open Source Project sowohl die Referenz als auch die bevorzugte Implementierung von Android. Implementierungen von Geräten wird dringend empfohlen, ihre Implementierungen so weit wie möglich auf dem vorgelagerten Quellcode des Android Open Source Project zu basieren. Zwar können einige Komponenten hypothetisch durch alternative Implementierungen ersetzt werden, es wird jedoch UNBEDINGT EMPFOHLEN, diese Vorgehensweise nicht zu befolgen, da das Bestehen der Softwaretests erheblich schwieriger wird. Es liegt in der Verantwortung des Implementierers, die vollständige Verhaltenskompatibilität mit der Android-Standardimplementierung sicherzustellen, einschließlich der Kompatibilitätstest-Suite und darüber hinaus. Beachten Sie schließlich, dass bestimmte Ersetzungen und Änderungen von Komponenten gemäß diesem Dokument ausdrücklich verboten sind.

Viele der in diesem Dokument verlinkten Ressourcen stammen direkt oder indirekt vom Android SDK und sind funktional mit den Informationen in der Dokumentation dieses SDK identisch. In Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstest-Suite nicht mit der SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als maßgeblich. Alle technischen Details, die in den verlinkten Ressourcen in diesem Dokument enthalten sind, werden als Teil dieser Kompatibilitätsdefinition angesehen.

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 in Abschnitt 2 bezieht sich auf einen bestimmten Gerätetyp.

Alle anderen Anforderungen, die allgemein für alle Implementierungen von Android-Geräten gelten, sind in den Abschnitten nach Abschnitt 2 aufgeführt. Diese Anforderungen werden in diesem Dokument als „zentrale Anforderungen“ bezeichnet.

1.1.2 Anforderungs-ID

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

• Die ID wird nur für MUSS-Anforderungen zugewiesen.
• Anforderungen sind mit "[SR]" gekennzeichnet, aber es ist keine ID zugewiesen.
• Die ID besteht aus folgenden Komponenten : Gerätetyp-ID - Bedingungs-ID - Anforderungs-ID (z.B. C-0-1).

Jede ID ist wie folgt definiert:

• Gerätetyp-ID (weitere Informationen unter 2. Gerätetypen)
  • C: Kern (Anforderungen, die für alle Implementierungen von Android-Geräten gelten)
  • H: Android-Handheld-Gerät
  • T: Android TV-Gerät
  • A: Android Automotive-Implementierung
  • Tab: Android-Tablet-Implementierung
• Bedingungs-ID
  • Wenn die Anforderung unbedingt erforderlich ist, wird diese ID auf 0 gesetzt.
  • Wenn die Anforderung bedingt ist, wird für die erste Bedingung „1“ zugewiesen und die Zahl wird im selben Bereich und für denselben Gerätetyp um 1 erhöht.
• Anforderungs-ID
  • Diese ID beginnt bei 1 und wird im selben Abschnitt 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 folgenden Komponenten : Abschnitts-ID / Gerätetyp-ID - Bedingungs-ID - Anforderungs-ID (z.B. 7.4.3/A-0-1).

2. Gerätetypen

Das Open-Source-Projekt von Android stellt einen Software-Stack bereit, der für eine Vielzahl von Gerätetypen und Formfaktoren verwendet werden kann. Einige Gerätetypen haben jedoch ein relativ besseres Ökosystem für die Anwendungsverteilung.

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

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

2.1 Gerätekonfigurationen

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

2.2. Anforderungen an Handhelds

Ein Android-Handheld-Gerät bezieht sich auf eine Android-Geräteimplementierung, die normalerweise verwendet wird, indem das Gerät in der Hand gehalten wird, z. B. ein MP3-Player, ein Smartphone oder ein Tablet.

Implementierungen von Android-Geräten werden als Handhelds eingestuft, wenn sie die folgenden Kriterien erfüllen:

• eine Stromquelle nutzen, die Mobilität ermöglicht, z. B. einen Akku.
• Das Display hat eine physische Diagonale von 2,5 bis 8 Zoll.

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

2.2.1. Hardware

Implementierungen von Handheld-Geräten:

• [7.1.1.1/H-0-1] MUSS eine Bildschirmdiagonale von mindestens 2,5 Zoll haben.
• [7.1.1.3/H-SR] EMPFOHLEN, Nutzern die Möglichkeit zu bieten, die Displaygröße zu ändern (Bildschirmdichte)

Wenn Implementierungen von Handheld-Geräten eine Unterstützung für Displays mit hoher Dynamik über Configuration.isScreenHdr() versprechen , geschieht Folgendes:

• [7.1.4.5/H-1-1] MÜSSEN 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 unterstützen.

Implementierungen von Handheld-Geräten:

• [7.1.5/H-0-1] MÜSSEN Unterstützung für den Kompatibilitätsmodus für ältere Apps enthalten, wie er durch den vorgelagerten Open-Source-Code von Android implementiert wird. Das heißt, Geräteimplementierungen DÜRFEN NICHT die Trigger oder Grenzwerte ändern, bei denen der Kompatibilitätsmodus aktiviert ist, und DÜRFEN NICHT das Verhalten des Kompatibilitätsmodus selbst ändern.
• [7.2.1/H-0-1] MUSS Support für IME-Anwendungen (Input Method Editor) von Drittanbietern enthalten.
• [7.2.3/H-0-1] MÜSSEN die Funktionen „Zuhause“, „Letzte“ und „Zurück“ bereitstellen.
• [7.2.3/H-0-2] MÜSSEN sowohl das normale als auch das lange Drücken der Funktion „Zurück“ (KEYCODE_BACK) an die Anwendung im Vordergrund senden. Diese Ereignisse dürfen NICHT vom System verarbeitet werden und KÖNNEN auch von außerhalb des Android-Geräts ausgelöst werden, z.B. über eine mit dem Android-Gerät verbundene externe Hardwaretastatur.
• [7.2.4/H-0-1] MUSS die Touchscreen-Eingabe unterstützen.
• [7.2.4/H-SR] wird dringend empfohlen, die vom Nutzer ausgewählte Assistent-App zu starten, also die App, die VoiceInteractionService implementiert, oder eine Aktivität, die ACTION_ASSIST beim langen Drücken von KEYCODE_MEDIA_PLAY_PAUSE oder KEYCODE_HEADSETHOOK verarbeitet, wenn diese Ereignisse durch langes Drücken nicht durch die Vordergrundaktivität verarbeitet werden.
• [7.3.1/H-SR] wird dringend empfohlen, einen dreiachsigen Beschleunigungsmesser zu verwenden.

Wenn Handheld-Geräte einen dreiachsigen Beschleunigungsmesser enthalten, gilt Folgendes:

• [7.3.1/H-1-1] MÜSSEN in der Lage sein, Ereignisse bis zu einer Frequenz von mindestens 100 Hz zu melden.

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

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

Implementierungen von Handheld-Geräten, die einen Sprachanruf tätigen und einen anderen Wert als PHONE_TYPE_NONE in getPhoneType anzeigen können:

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

Implementierungen von Handheld-Geräten:

• [7.3.12/H-SR] EMPFOHLEN für Positionssensoren mit 6 Freiheitsgraden
• [7.4.3/H] SOLLTEN Bluetooth und Bluetooth LE unterstützen.

Wenn Handheld-Geräte eine getaktete Verbindung enthalten, gilt Folgendes:

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

Implementierungen von Handheld-Geräten:

• [7.6.1/H-0-1] MUSS mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition) verfügbar haben.
• [7.6.1/H-0-2] MÜSSEN „true“ für ActivityManager.isLowRamDevice() zurückgeben, wenn weniger als 1 GB Arbeitsspeicher für den Kernel und Userspace zur Verfügung steht.

Wenn Implementierungen von Handheld-Geräten nur eine 32-Bit-ABI unterstützen:

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

• [7.6.1/H-2-1] Der für Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 592 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis HD+ verwendet (z.B. HD, WSVGA).

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

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

Wenn Implementierungen von Handheld-Geräten die Unterstützung von 64-Bit-ABIs (mit oder ohne 32-Bit-ABI) deklarieren:

• [7.6.1/H-5-1] Der für Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 816 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis zu qHD (z.B. FWVGA) verwendet.

• [7.6.1/H-6-1] Der für Kernel und Userspace verfügbare Arbeitsspeicher MUSS mindestens 944 MB betragen, wenn die Standardanzeige Framebuffer-Auflösungen bis HD+ verwendet (z.B. HD, WSVGA).

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

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

Beachten Sie, dass sich der oben angegebene „für den Kernel und Userspace verfügbaren Arbeitsspeicher“ auf den Arbeitsspeicher bezieht, der zusätzlich zu jeglichen Arbeitsspeichern bereitgestellt wird, die bereits für Hardwarekomponenten wie Radio, Video usw. vorgesehen sind und nicht der Kontrolle des Kernels auf Geräteimplementierungen unterliegen.

Wenn Handheld-Geräteimplementierungen weniger als oder gleich 1 GB Arbeitsspeicher für den Kernel und Userspace umfassen, geschieht 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 nichtflüchtigen Speicher für private Anwendungsdaten haben (auch als „/data“-Partition bezeichnet).

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

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

Implementierungen von Handheld-Geräten:

• [7.6.2/H-0-1] DARF KEINEN freigegebenen Speicher für Anwendungen mit weniger als 1 GiB bereitstellen.
• [7.7.1/H] SOLLTEN einen USB-Anschluss haben, der den Peripheriemodus unterstützt.

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

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

Implementierungen von Handheld-Geräten:

• [7.8.1/H-0-1] MUSS ein Mikrofon enthalten.
• [7.8.2/H-0-1] MUSS einen Audioausgang haben und android.hardware.audio.output deklarieren.

Wenn Handheld-Implementierungen 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 Funktions-Flag android.hardware.vr.high_performance deklarieren.
• [7.9.1/H-1-2] MUSS eine App enthalten, die android.service.vr.VrListenerService implementiert, die von VR-Anwendungen über android.app.Activity#setVrModeEnabled aktiviert werden kann.

2.2.2. Multimedia

Implementierungen von Handheld-Geräten MÜSSEN die folgende Audiocodierung 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 Profile (AAC LC)
• [5.1.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
• [5.1.1/H-0-5] AAC ELD (Optimierte AAC mit niedriger Verzögerung)

Implementierungen von Handheld-Geräten MÜSSEN die folgende Audiodecodierung unterstützen:

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

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

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

Implementierungen von Handheld-Geräten MÜSSEN die folgende Videodecodierung 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 von Handheld-Geräten:

• [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 verarbeitet, wie in den SDK-Dokumenten beschrieben, 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] 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] wird dringend empfohlen, einen Standard-Launcher zu implementieren, der schnellen Zugriff auf die zusätzlichen Verknüpfungen von Drittanbieter-Apps über die ShortcutManager API ermöglicht.
• [3.8.1/H-SR] wird dringend empfohlen, eine Standard-Launcher-App einzubinden, die Kennzeichen für die App-Symbole anzeigt.
• [3.8.2/H-SR] wird dringend empfohlen, App-Widgets von Drittanbietern zu unterstützen.
• [3.8.3/H-0-1] MÜSSEN Drittanbieter-Apps erlauben, Nutzer über die API-Klassen Notification und NotificationManager über wichtige Ereignisse zu informieren.
• [3.8.3/H-0-2] MUSS die Rich-Benachrichtigungen unterstützen.
• [3.8.3/H-0-3] MUSS Vorabbenachrichtigungen unterstützen.
• [3.8.3/H-0-4] MÜSSEN eine Benachrichtigungsleiste enthalten, mit der der Nutzer die Benachrichtigungen direkt steuern (z.B. beantworten, zurückstellen, schließen oder blockieren kann) über Aktionsschaltflächen oder das Steuerfeld, wie in der AOSP implementiert.
• [3.8.3/H-0-5] MÜSSEN die in RemoteInput.Builder setChoices() bereitgestellten Auswahlmöglichkeiten in der Benachrichtigungsleiste anzeigen.
• [3.8.3/H-SR] WIRD DRINGEND empfohlen, die erste über RemoteInput.Builder setChoices() bereitgestellte Auswahl ohne zusätzliche Nutzerinteraktion in der Benachrichtigungsleiste 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] wird dringend empfohlen, auf dem Gerät einen Assistenten für die Unterstützungsaktion zu implementieren.

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

• [3.8.4/H-SR] WIRD DRINGEND empfohlen, das lange Drücken der HOME-Taste als vorgesehene Interaktion zum Starten der Assistenten-App zu verwenden, wie in Abschnitt 7.2.3 beschrieben. MÜSSEN die vom Nutzer ausgewählte Assistent-App, also die App, in der VoiceInteractionService implementiert ist, oder eine Aktivität, die den Intent ACTION_ASSIST verarbeitet, gestartet werden.

Wenn Implementierungen von Android-Handheld-Geräten einen Sperrbildschirm unterstützen, gilt Folgendes:

• [3.8.10/H-1-1] MÜSSEN die Sperrbildschirmbenachrichtigungen einschließlich der Media Notification Template anzeigen.

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

• [3.9/H-1-1] MÜSSEN alle in der Android SDK-Dokumentation definierten Richtlinien zur Geräteverwaltung implementieren.
• [3.9/H-1-2] MÜSSEN die Unterstützung verwalteter Profile mit dem Funktions-Flag „android.software.managed_users“ deklarieren, es sei denn, das Gerät ist so konfiguriert, dass es sich als Gerät mit wenig RAM meldet oder internen (nicht entfernbaren) Speicher als gemeinsamen Speicher zuweist.

Implementierungen von Handheld-Geräten:

• [3.10/H-0-1] MÜSSEN Bedienungshilfen von Drittanbietern unterstützen.
• [3.10/H-SR] WIRD DRINGEND empfohlen, Bedienungshilfen vorab auf dem Gerät zu laden, die mit den Bedienungshilfen des Schalterzugriffs und TalkBack (für Sprachen, die von der vorinstallierten Text-in-Sprache-Engine unterstützt werden) vergleichbar oder sogar übertreffen, wie im Open-Source-Projekt „Talkback“ enthalten.
• [3.11/H-0-1] MUSS die Installation der Sprachausgabe-Engines von Drittanbietern unterstützen.
• [3.11/H-SR] wird dringend empfohlen, eine Sprachausgabe-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.
• [3.13/H-SR] wird dringend empfohlen, eine Komponente der Benutzeroberfläche für Schnelleinstellungen einzubinden.

Wenn in den Implementierungen von Android-Handheld-Geräten die Unterstützung von FEATURE_BLUETOOTH oder FEATURE_WIFI deklariert wird, geschieht Folgendes:

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

2.2.4 Leistung und Leistung

• [8.1/H-0-1] Konsistente Framelatenz. Inkonsistente Frame-Latenz oder Verzögerung beim Rendern von Frames DÜRFEN NICHT häufiger als 5 Frames pro Sekunde auftreten und SOLLTEN unter einem Frame in einer Sekunde liegen.
• [8.1/H-0-2] Latenz der Benutzeroberfläche. Geräteimplementierungen MÜSSEN für eine geringe Latenz sorgen, indem in einer Liste mit 10.000 Listeneinträgen, wie von der Android Compatibility Test Suite (CTS) definiert, in weniger als 36 Sekunden gescrollt wird.
• [8.1/H-0-3] Aufgabenwechsel. Wenn mehrere Anwendungen gestartet wurden, MUSS der Neustart einer bereits laufenden Anwendung nach dem Start weniger als eine Sekunde dauern.

Implementierungen von Handheld-Geräten:

• [8.2/H-0-1] MUSS eine sequentielle 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 sequentielle Leseleistung von mindestens 15 MB/s gewährleisten.
• [8.2/H-0-4] MUSS eine zufällige Leseleistung von mindestens 3,5 MB/s gewährleisten.

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

• [8.3/H-1-1] MUSS Nutzern die Möglichkeit bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.
• [8.3/H-1-2] MÜSSEN Nutzern die Möglichkeit bieten, alle Apps anzuzeigen, die vom App-Standby- und Stromsparmodus ausgenommen sind.

Implementierungen von Handheld-Geräten:

• [8.4/H-0-1] MÜSSEN ein Leistungsprofil pro Komponente angeben, in dem der Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkuleistung durch die Komponenten im Zeitverlauf definiert wird, wie auf der Website des Android Open Source Project dokumentiert.
• [8.4/H-0-2] MÜSSEN alle Werte zum Energieverbrauch in Milliamperestunden (mAh) angeben.
• [8.4/H-0-3] MÜSSEN die CPU-Energieverbrauchsaufnahme gemäß der UID jedes Prozesses melden. Das Android Open Source-Projekt erfüllt die Anforderung über die Implementierung des Kernelmoduls uid_cputime.
• [8.4/H-0-4] MUSS dem App-Entwickler diesen Stromverbrauch über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.
• [8.4/H] SOLLTEN der Hardwarekomponente selbst zugeschrieben werden, wenn sie einer Anwendung den Stromverbrauch der Hardwarekomponente nicht zuordnen können.

Implementierungen von Handheld-Geräten, die eine Bildschirm- oder Videoausgabe beinhalten:

• [8.4/H-1-1] MÜSSEN den Intent android.intent.action.POWER_USAGE_SUMMARY berücksichtigen und ein Einstellungsmenü mit Angaben zu diesem Stromverbrauch anzeigen.

2.2.5 Sicherheitsmodell

Implementierungen von Handheld-Geräten:

• [9.1/H-0-1] MÜSSEN Drittanbieter-Apps über die Berechtigung „android.permission.PACKAGE_USAGE_STATS“ den Zugriff auf die Nutzungsstatistiken ermöglichen und einen für Nutzer zugänglichen Mechanismus anbieten, mit dem in Reaktion auf den Intent von android.settings.ACTION_USAGE_ACCESS_SETTINGS Zugriff auf solche Apps gewährt oder widerrufen werden kann.

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

• [9.11/H-1-1] MÜSSEN Nutzer das kürzeste Zeitlimit für den Ruhemodus wählen. Das ist eine Übergangszeit von maximal 15 Sekunden vom entsperrten in den gesperrten Zustand.
• [9.11/H-1-2] MÜSSEN Nutzern die Möglichkeit bieten, Benachrichtigungen auszublenden und alle Formen der Authentifizierung zu deaktivieren. Ausgenommen hiervon ist die unter 9.11.1 Sicherer Sperrbildschirm beschriebene primäre Authentifizierung. Der AOSP erfüllt die Anforderung an den Sperrmodus.

2.3. Fernsehanforderungen

Ein Android-Fernsehgerät bezieht sich auf eine Android-Geräteimplementierung, die eine Unterhaltungsoberfläche für die Wiedergabe digitaler Medien, Filme, Spiele, Apps und/oder Live-TV für Nutzer, die etwa drei Meter entfernt sitzen, darstellt (eine „lehnende Benutzeroberfläche“ oder „3 Meter große Benutzeroberfläche“).

Implementierungen von Android-Geräten werden als Fernseher eingestuft, wenn sie die folgenden Kriterien erfüllen:

• Bereitstellung eines Mechanismus zur Fernsteuerung der gerenderten Benutzeroberfläche auf dem Bildschirm, die etwa drei Meter vom Nutzer entfernt sein kann
• Sie haben einen eingebetteten Bildschirm mit einer diagonalen Länge von mehr als 24 Zoll ODER einen Videoausgangsanschluss (z. B. VGA, HDMI, DisplayPort) oder einen kabellosen Anschluss für die Anzeige.

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

2.3.1 Hardware

Implementierungen von Fernsehgeräten:

• [7.2.2/T-0-1] MUSS das Steuerkreuz unterstützen.
• [7.2.3/T-0-1] MÜSSEN die Funktionen „Startbildschirm“ und „Zurück“ bereitstellen.
• [7.2.3/T-0-2] MÜSSEN sowohl das normale als auch das lange Drücken der Funktion „Zurück“ (KEYCODE_BACK) an die Anwendung im Vordergrund senden.
• [7.2.6.1/T-0-1] MÜSSEN Support für Controller enthalten und das Funktions-Flag android.hardware.gamepad deklarieren.
• [7.2.7/T] SOLLTE eine Fernbedienung bereitstellen, mit der Nutzer auf die Bedienung ohne Touchscreen und die Hauptnavigationstasten zugreifen können.

Wenn Fernsehgeräte ein Gyroskop enthalten, gilt Folgendes:

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

Implementierungen von Fernsehgeräten:

• [7.4.3/T-0-1] MUSS Bluetooth und Bluetooth LE unterstützen.
• [7.6.1/T-0-1] MUSS mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition) verfügbar haben.

Wenn Implementierungen von Fernsehgeräten einen USB-Port enthalten, der den Hostmodus unterstützt, gilt Folgendes:

• [7.5.3/T-1-1] MÜSSEN Support für eine externe Kamera anbieten, die über diesen USB-Anschluss angeschlossen wird, aber nicht unbedingt immer angeschlossen ist.

Bei 32-Bit-Implementierungen von TV-Geräten:

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

  • Mindestens 400 dpi auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tvdpi oder höher auf sehr großen Bildschirmen

Bei 64-Bit-Implementierungen von TV-Geräten:

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

  • Mindestens 400 dpi auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tvdpi oder höher auf sehr großen Bildschirmen

Beachten Sie, dass sich der oben angegebene „für den Kernel und Userspace verfügbaren Arbeitsspeicher“ auf den Arbeitsspeicher bezieht, der zusätzlich zu jeglichen Arbeitsspeichern bereitgestellt wird, die bereits für Hardwarekomponenten wie Radio, Video usw. vorgesehen sind und nicht der Kontrolle des Kernels auf Geräteimplementierungen unterliegen.

Implementierungen von Fernsehgeräten:

• [7.8.1/T] SOLLTEN ein Mikrofon enthalten.
• [7.8.2/T-0-1] MUSS einen Audioausgang haben und android.hardware.audio.output deklarieren.

2.3.2 Multimedia

Implementierungen auf Fernsehgeräten MÜSSEN die folgenden Audiocodierungsformate unterstützen:

• [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC-Profil (AAC+)
• [5.1/T-0-3] AAC ELD (Optimierte AAC mit niedriger Verzögerung)

Implementierungen auf Fernsehgeräten MÜSSEN die folgenden Videocodierungsformate unterstützen:

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

Implementierungen von Fernsehgeräten:

• [5.2.2/T-SR] 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 auf 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

Bei Implementierungen von Fernsehgeräten wird dringend empfohlen, die folgenden Videodecodierungsformate zu unterstützen:

• [5.3.1/T-SR] MPEG-2

Implementierungen von Fernsehgeräten MÜSSEN die H.264-Decodierung, wie in Abschnitt 5.3.4 beschrieben, bei Standard-Video-Framerates und -Auflösungen bis einschließlich:

• [5.3.4.4/T-1-1] HD 1080p bei 60 Bildern pro Sekunde mit Basline-Profil
• [5.3.4.4/T-1-2] HD 1080p bei 60 Bildern pro Sekunde mit Hauptprofil
• [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-Hardwaredecoder müssen die H.265-Decodierung, wie in Abschnitt 5.3.5 beschrieben, bei Standard-Frameraten und -auflösungen von bis zu einschließlich der Folgenden unterstützen:

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

Wenn Implementierungen von Fernsehgeräten mit H.265-Hardwaredecodierern die H.265-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:

• [5.3.5.5/T-2-1] MÜSSEN das UHD-Decodierungsprofil bei 60 Bildern pro Sekunde im Main10-Profil der Ebene 5 für die Hauptstufe unterstützen.

Implementierungen von Fernsehgeräten MÜSSEN wie in Abschnitt 5.3.6 beschrieben die VP8-Decodierung bei Standard-Framerates und Auflösungen von Videos unterstützen, einschließlich:

• [5.3.6.4/T-1-1] Decodierungsprofil in HD 1080p bei 60 Bildern pro Sekunde

Implementierungen von Fernsehgeräten mit VP9-Hardwaredecoder müssen die VP9-Decodierung wie in Abschnitt 5.3.7 beschrieben unterstützen. Dabei gelten die Standard-Framerates und Auflösungen für Video-Frames bis einschließlich:

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

Wenn Implementierungen von Fernsehgeräten mit VP9-Hardwaredecodierern die VP9-Decodierung und das UHD-Decodierungsprofil unterstützen, gilt Folgendes:

• [5.3.7.5/T-2-1] MÜSSEN das UHD-Decodierungsprofil bei 60 Bildern pro Sekunde mit Profil 0 (8-Bit-Farbtiefe) unterstützen.
• [5.3.7.5/T-2-1] WIRD UNBEDINGT EMPFOHLEN, das UHD-Decodierungsprofil bei 60 Bildern pro Sekunde mit Profil 2 (10-Bit-Farbtiefe) zu unterstützen.

Implementierungen von Fernsehgeräten:

• [5.5.3/T-0-1] MÜSSEN auf unterstützten Ausgängen Unterstützung für die Hauptlautstärke des Systems und die Lautstärkedämpfung der digitalen Audioausgabe enthalten. Ausgenommen hiervon sind die komprimierten Audio-Passthrough-Ausgabeformate, bei denen keine Audiodecodierung auf dem Gerät durchgeführt wird.
• [5.8/T-0-1] MÜSSEN im HDMI-Ausgabemodus die maximale Auflösung auswählen, die mit einer Aktualisierungsrate von 50 Hz oder 60 Hz für alle kabelgebundenen Bildschirme unterstützt wird.
• [5.8/T-SR] WIRD DRINGEND empfohlen, eine vom Nutzer konfigurierbare Auswahl der HDMI-Aktualisierungsrate für alle kabelgebundenen Bildschirme bereitzustellen.
• [5.8/T-SR] WIRD UNBEDINGT EMPFOHLEN, die gleichzeitige Decodierung sicherer Streams zu unterstützen. Die gleichzeitige Decodierung von zwei Datendampfen wird dringend empfohlen.
• [5.8] SOLLTEN die Aktualisierungsrate des HDMI-Ausgabemodus auf 50 Hz oder 60 Hz festlegen. Das ist abhängig von der Videoaktualisierungsrate in der Region, in der das Gerät für alle kabelgebundenen Bildschirme verkauft wird.

Wenn Implementierungen von Fernsehgeräten die UHD-Decodierung und externe Bildschirme unterstützen, gilt Folgendes:

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

Wenn bei Implementierungen von Fernsehgeräten die UHD-Decodierung, jedoch externe Bildschirme unterstützt werden, 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 Sperrbildschirm-Benachrichtigungen einschließlich der Media Notification Template anzeigen.

Implementierungen von Fernsehgeräten:

• [3.8.14/T-SR] WIRD UNBEDINGT EMPFOHLEN, den Bild-im-Bild-Modus (BiB) den Mehrfenstermodus zu unterstützen.
• [3.10/T-0-1] MÜSSEN Bedienungshilfen von Drittanbietern unterstützen.
• [3.10/T-SR] WIRD DRINGEND empfohlen, Bedienungshilfen vorab auf dem Gerät zu laden, die mit den Bedienungshilfen des Schalterzugriffs und TalkBack (für Sprachen, die von der vorinstallierten Text-in-Sprache-Engine unterstützt werden) vergleichbar oder sogar übertreffen, wie im Open-Source-Projekt TalkBack enthalten.

Wenn Implementierungen von Fernsehgeräten die Funktion android.hardware.audio.output melden, geschieht Folgendes:

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

Implementierungen von Fernsehgeräten:

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

2.3.4 Leistung und Leistung

• [8.1/T-0-1] Konsistente Framelatenz. Inkonsistente Frame-Latenz oder Verzögerung beim Rendern von Frames DÜRFEN NICHT häufiger als 5 Frames pro Sekunde auftreten und SOLLTEN unter einem Frame in einer 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 gewährleisten.
• [8.2/T-0-3] MÜSSEN eine sequentielle 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 für Fernsehgeräte Funktionen zur Verbesserung der Energieverwaltung für Geräte enthalten, die in AOSP enthalten sind, oder um die in AOSP enthaltenen Funktionen zu erweitern, gilt Folgendes:

• [8.3/T-1-1] MUSS Nutzern die Möglichkeit bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.
• [8.3/T-1-2] MÜSSEN Nutzern die Möglichkeit bieten, alle Apps anzuzeigen, die vom App-Standby- und Stromsparmodus ausgenommen sind.

Implementierungen von Fernsehgeräten:

• [8.4/T-0-1] MÜSSEN ein Leistungsprofil pro Komponente angeben, in dem der Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkuleistung durch die Komponenten im Zeitverlauf definiert wird, wie auf der Website des Android Open Source Project dokumentiert.
• [8.4/T-0-2] MÜSSEN alle Werte zum Energieverbrauch in Milliamperestunden (mAh) angeben.
• [8.4/T-0-3] MÜSSEN die CPU-Energieverbrauchsaufnahme gemäß der UID jedes Prozesses melden. Das Android Open Source-Projekt erfüllt die Anforderung über die Implementierung des Kernelmoduls uid_cputime.
• [8.4/T] SOLLTEN der Hardwarekomponente selbst zugeschrieben werden, wenn sie einer Anwendung den Stromverbrauch der Hardwarekomponente nicht zuordnen können.
• [8.4/T-0-4] MUSS dem App-Entwickler diesen Stromverbrauch über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.

2.4. Smartwatch-Anforderungen

Eine Android Watch bezieht sich auf eine Android-Geräteimplementierung, die am Körper getragen werden soll, z. B. am Handgelenk.

Implementierungen von Android-Geräten werden als Smartwatch eingestuft, wenn sie die folgenden Kriterien erfüllen:

• Die Bildschirmdiagonale sollte zwischen 2,8 und 5 cm liegen.
• Ein Mechanismus zum Tragen am Körper muss vorhanden sein.

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

2.4.1 Hardware

Implementierungen von Smartwatch-Geräten:

• [7.1.1.1/W-0-1] MÜSSEN über ein Display mit einer physischen Diagonale zwischen 1,1 und 2,5 Zoll verfügen.

• [7.2.3/W-0-1] MÜSSEN die Startbildschirm- und die Zurück-Funktion für den Nutzer verfügbar sein, es sei denn, sie befinden sich in UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] MUSS die Touchscreen-Eingabe unterstützen.

• [7.3.1/W-SR] wird dringend empfohlen, einen dreiachsigen Beschleunigungsmesser zu verwenden.

• [7.4.3/W-0-1] MUSS Bluetooth unterstützen.

• [7.6.1/W-0-1] MUSS mindestens 1 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition) verfügbar haben.

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

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

• [7.8.2/W] KANN aber KEINE Audioausgabe haben.

2.4.2 Multimedia

Keine zusätzlichen Anforderungen.

2.4.3 Software

Implementierungen von Smartwatch-Geräten:

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

Implementierungen von Smartwatch-Geräten:

• [3.8.4/W-SR] wird dringend empfohlen, auf dem Gerät einen Assistenten für die Unterstützungsaktion zu implementieren.

Beobachten Sie Implementierungen von Geräten, die das Funktions-Flag android.hardware.audio.output deklarieren:

• [3.10/W-1-1] MÜSSEN Bedienungshilfen von Drittanbietern unterstützen.
• [3.10/W-SR] WIRD DRINGEND empfohlen, Bedienungshilfen vorab auf dem Gerät zu laden, die mit den Bedienungshilfen des Schalterzugriffs und TalkBack (für Sprachen, die von der vorinstallierten Text-in-Sprache-Engine unterstützt werden) vergleichbar oder sogar übertreffen, wie im Open-Source-Projekt TalkBack enthalten.

Wenn Smartwatch-Implementierungen die Funktion „android.hardware.audio.output“ melden, geschieht Folgendes:

• [3.11/W-SR] wird dringend empfohlen, eine Sprachausgabe-Engine einzubinden, die die auf dem Gerät verfügbaren Sprachen unterstützt.

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

2.4.4 Leistung und Leistung

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

• [8.3/W-SR] werden UNBEDINGT empfohlen, Nutzern die Möglichkeit zu bieten, alle Apps anzuzeigen, die vom App-Standby- und Stromsparmodus ausgenommen sind.
• [8.3/W-SR] sind UNBEDINGT EMPFOHLEN, Nutzern die Möglichkeit zu bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.

Implementierungen von Smartwatch-Geräten:

• [8.4/W-0-1] MÜSSEN ein Leistungsprofil pro Komponente angeben, in dem der Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkuleistung durch die Komponenten im Zeitverlauf definiert wird, wie auf der Website des Android Open Source Project dokumentiert.
• [8.4/W-0-2] MÜSSEN alle Werte zum Energieverbrauch in Milliamperestunden (mAh) angeben.
• [8.4/W-0-3] MÜSSEN die CPU-Energieverbrauchsaufnahme gemäß der UID jedes Prozesses melden. Das Android Open Source-Projekt erfüllt die Anforderung über die Implementierung des Kernelmoduls uid_cputime.
• [8.4/W-0-4] MUSS dem App-Entwickler diesen Stromverbrauch über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung stellen.
• [8.4/W] SOLLTEN der Hardwarekomponente selbst zugeordnet werden, wenn sie einer Anwendung den Stromverbrauch der Hardwarekomponente nicht zuordnen können.

2.5. Fahrzeuganforderungen

Die Android Automotive-Implementierung bezieht sich auf die Haupteinheit eines Fahrzeugs, auf der Android als Betriebssystem für einen Teil oder die gesamte System- und/oder Infotainmentfunktionalität ausgeführt wird.

Implementierungen von Android-Geräten werden als „Automobil“ eingestuft, wenn sie die Funktion „android.hardware.type.automotive“ deklarieren oder alle folgenden Kriterien erfüllen.

• Sie sind als Teil eines Fahrzeugs eingebettet oder können an das angeschlossene Fahrzeug angeschlossen werden.
• ein Display in der Fahrersitzreihe als primäres Display verwenden.

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

2.5.1 Hardware

Implementierungen von Automobilgeräten:

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

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

• [7.2.3/A-0-1] MÜSSEN die Home-Funktion sowie die Funktionen „Zurück“ und „Letzte“ bereitstellen.

• [7.2.3/A-0-2] MÜSSEN sowohl das normale als auch das lange Drücken der Funktion „Zurück“ (KEYCODE_BACK) an die Anwendung im Vordergrund senden.

• [7.3.1/A-SR] wird dringend empfohlen, einen dreiachsigen Beschleunigungsmesser zu verwenden.

Wenn die Implementierung von Automobil-Geräten einen 3-Achsen-Beschleunigungsmesser umfasst, gilt Folgendes:

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

Wenn Automobil-Geräteimplementierungen ein Gyroskop enthalten, ist Folgendes zu beachten:

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

Implementierungen von Automobilgeräten:

• [7.3.11/A-0-1] MÜSSEN das aktuelle Getriebe als SENSOR_TYPE_GEAR angeben.

Implementierungen von Automobilgeräten:

• [7.3.11.2/A-0-1] MUSS den als SENSOR_TYPE_NIGHT definierten Tag-/Nachtmodus unterstützen.
• [7.3.11.2/A-0-2] Der Wert des Flags SENSOR_TYPE_NIGHT MÜSSEN mit dem Tag-/Nachtmodus im Dashboard übereinstimmen und auf der Eingabe des Umgebungslicht-Sensors basieren.

• Der zugrunde liegende Umgebungslicht-Sensor KANN der gleiche wie Fotometer sein.

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

• [7.3.11.5/A-0-1] MÜSSEN den Status der Parkbremse gemäß der Definition von SENSOR_TYPE_PARKING_BRAKE angeben.

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

• [7.4.3/A-0-2] Android Automotive-Implementierungen MÜSSEN die folgenden Bluetooth-Profile unterstützen:
  • Telefonanrufe über Hands-Free Profile (HFP).
  • Medienwiedergabe über das Audio Distribution Profile (A2DP)
  • Steuerung der Medienwiedergabe über das Remote Control Profile (AVRCP)
  • Kontaktfreigabe über das Phone Book Access Profile (PBAP)

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

• [7.4.5/A] SOLLTE Unterstützung für mobilnetzbasierte Datenverbindungen enthalten.

• [7.4.5/A] KANN die NetworkCapabilities#NET_CAPABILITY_OEM_PAID-Konstante der System API für Netzwerke verwenden, die für System-Apps verfügbar sein sollen.

• [7.6.1/A-0-1] MUSS mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten (auch als „/data“-Partition) verfügbar haben.

Implementierungen von Automobilgeräten:

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

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

• [7.6.1/A-SR] wird dringend empfohlen, den E/A-Overhead für Vorgänge zu reduzieren, die auf dem externen Speicher ausgeführt werden, z. B. mit SDCardFS.

Bei Automotive-Geräten mit 32-Bit-Implementierungen:

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

  • 280 dpi oder niedriger auf kleinen/normalen Bildschirmen
  • LDPI oder niedriger auf sehr großen Bildschirmen
  • mdpi oder niedriger auf großen Bildschirmen

• [7.6.1/A-1-2] Der für Kernel und Userspace 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 mehr auf großen Bildschirmen
  • mdpi oder höher auf extragroßen Bildschirmen

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

  • Mindestens 400 dpi auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tvdpi oder höher auf sehr großen Bildschirmen

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

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

Bei Automotive-Geräten mit 64-Bit-Implementierungen:

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

  • 280 dpi oder niedriger auf kleinen/normalen Bildschirmen
  • LDPI oder niedriger auf sehr großen Bildschirmen
  • mdpi oder niedriger auf großen Bildschirmen

• [7.6.1/A-2-2] Der für Kernel und Userspace 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 mehr auf großen Bildschirmen
  • mdpi oder höher auf extragroßen Bildschirmen

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

  • Mindestens 400 dpi auf kleinen/normalen Bildschirmen
  • xhdpi oder höher auf großen Bildschirmen
  • tvdpi oder höher auf sehr großen Bildschirmen

• [7.6.1/A-2-4] Der für Kernel und Userspace 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
  • Mindestens 400 dpi auf großen Bildschirmen
  • xhdpi oder höher auf extragroßen Bildschirmen

Beachten Sie, dass sich der oben angegebene „für den Kernel und Userspace verfügbaren Arbeitsspeicher“ auf den Arbeitsspeicher bezieht, der zusätzlich zu jeglichen Arbeitsspeichern bereitgestellt wird, die bereits für Hardwarekomponenten wie Radio, Video usw. vorgesehen sind und nicht der Kontrolle des Kernels auf Geräteimplementierungen unterliegen.

Implementierungen von Automobilgeräten:

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

Implementierungen von Automobilgeräten:

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

Implementierungen von Automobilgeräten:

• [7.8.2/A-0-1] MUSS einen Audioausgang haben und android.hardware.audio.output deklarieren.

2.5.2 Multimedia

Implementierungen für Automobilgeräte MÜSSEN die folgenden Audiocodierungen unterstützen:

• [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC-Profil (AAC+)
• [5.1/A-0-3] AAC ELD (Optimierte AAC mit niedriger Verzögerung)

Implementierungen für Automobilgeräte MÜSSEN die folgende Videocodierung unterstützen:

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

Implementierungen für Automobilgeräte MÜSSEN die folgende Videodecodierung 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

Implementierungen für Automobilgeräte werden dringend empfohlen, die folgende Videodecodierung zu unterstützen:

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

2.5.3 Software

Implementierungen von Automobilgeräten:

• [3/A-0-1] MUSS das Element als android.hardware.type.automotive deklarieren.

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

• [3/A-0-3] MUSS 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 anzeigen, die die Notification.CarExtender API verwenden, wenn sie von Anwendungen von Drittanbietern angefordert werden.

• [3.8.4/A-SR] wird dringend empfohlen, auf dem Gerät einen Assistenten für die Unterstützungsaktion zu implementieren.

• [3.13/A-SR] wird dringend empfohlen, eine Komponente der Benutzeroberfläche für Schnelleinstellungen einzubinden.

Wenn Implementierungen von Automobil-Geräten eine Push-to-Talk-Taste enthalten, gilt Folgendes:

• [3.8.4/A-1-1] MÜSSEN durch kurzes Drücken der Push-to-Talk-Taste die vom Nutzer ausgewählte Assistent-App gestartet werden, also die App, in der VoiceInteractionService implementiert ist.

Implementierungen von Automobilgeräten:

• [3.14/A-0-1] MÜSSEN ein UI-Framework zur Unterstützung von Drittanbieter-Apps enthalten, die Medien-APIs verwenden, wie in Abschnitt 3.14 beschrieben.

2.5.4 Leistung und Leistung

Wenn Automotive-Geräteimplementierungen Funktionen zur Verbesserung der Geräteverwaltung für Geräte in AOSP oder Erweiterung der in AOSP enthaltenen Funktionen enthalten, gilt Folgendes:

• [8.3/A-1-1] MUSS Nutzern die Möglichkeit bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.
• [8.3/A-1-2] MÜSSEN Nutzern die Möglichkeit bieten, alle Apps anzuzeigen, die vom App-Standby- und Stromsparmodus ausgenommen sind.

Implementierungen von Automobilgeräten:

• [8.2/A-0-1] MÜSSEN die Anzahl der gelesenen und geschriebenen Byte pro UID jedes Prozesses in den nichtflüchtigen Speicher melden, damit die Statistiken über die System API android.car.storagemonitoring.CarStorageMonitoringManager für Entwickler verfügbar sind. Das Android Open Source-Projekt erfüllt die Anforderung über das Kernelmodul uid_sys_stats.
• [8.4/A-0-1] MÜSSEN ein Leistungsprofil pro Komponente angeben, in dem der Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkukapazität definiert wird, die durch die Komponenten im Laufe der Zeit verursacht wird, wie auf der Website des Android Open Source Project dokumentiert.
• [8.4/A-0-2] MÜSSEN alle Werte zum Energieverbrauch in Milliamperestunden (mAh) angeben.
• [8.4/A-0-3] MÜSSEN die CPU-Energieverbrauchsaufnahme gemäß der UID jedes Prozesses melden. Das Android Open Source-Projekt erfüllt die Anforderung über die Implementierung des Kernelmoduls uid_cputime.
• [8.4/A] SOLLTEN der Hardwarekomponente selbst zugeschrieben werden, wenn sie einer Anwendung den Stromverbrauch der Hardwarekomponente nicht zuordnen können.
• [8.4/A-0-4] MUSS dem App-Entwickler diesen Stromverbrauch ü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] MÜSSEN ein Gastkonto angeben, mit dem alle vom Fahrzeugsystem bereitgestellten Funktionen genutzt werden können, ohne dass sich Nutzer anmelden müssen.

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

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

Implementierungen von Automobilgeräten:

• [9.14/A-0-1] MÜSSEN die Nachrichten von Fahrzeug-Subsystemen von Android-Frameworks, z.B. die Zulassungsliste der zulässigen Nachrichtentypen und Nachrichtenquellen, mit einem Gatekeeper umgehen.
• [9.14/A-0-2] MÜSSEN Sie gegen Denial-of-Service-Angriffe vom Android-Framework oder von Drittanbieter-Apps überwachen. So wird verhindert, dass schädliche Software das Fahrzeugnetzwerk mit Traffic überflutet, was zu defekten Fahrzeug-Subsystemen führen kann.

2.6. Tablet-Anforderungen

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

• Wird normalerweise in beiden Händen verwendet.
• Hat keine Clamshell- oder Convertible-Konfiguration.
• Jede Implementierung einer physischen Tastatur, die mit dem Gerät verwendet wird, MUSS über eine Standardverbindung verbunden werden.
• Das Gerät hat eine Stromquelle, die Mobilität ermöglicht, z. B. einen Akku.
• Das Display hat eine physische Diagonale von 7 bis 18 Zoll.

Bei der Implementierung auf Tablets gelten ähnliche Anforderungen wie bei Handheld-Geräten. Die Ausnahmen werden in diesem Abschnitt durch und * gekennzeichnet und in diesem Abschnitt als Referenz vermerkt.

2.4.1 Hardware

Displaygröße

• [7.1.1.1/Tab-0-1] MUSS die Bildschirmgröße zwischen 7 und 18 Zoll groß sein.

Mindestanforderungen an Arbeitsspeicher und Speicherplatz (Abschnitt 7.6.1)

Die in den Anforderungen für Handhelds für kleine/normale Bildschirme aufgeführte Bildschirmdichten gelten nicht für Tablets.

USB-Peripheriemodus (Abschnitt 7.7.1)

Wenn Tablet-Implementierungen einen USB-Port enthalten, der den Peripheriemodus unterstützt, ist Folgendes zu beachten:

• [7.7.1/Tab] KANN die Android Open Accessory (AOA) API implementieren.

Virtual-Reality-Modus (Abschnitt 7.9.1)

Virtual Reality: High Performance (Abschnitt 7.9.2)

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

3. Software

3.1. Kompatibilität mit verwalteten APIs

Die verwaltete Dalvik-Umgebung für die Bytecode-Ausführung ist das wichtigste Instrument für Android-Apps. Die Android Application Programming Interface (API) besteht aus mehreren Android-Plattformschnittstellen, die für Anwendungen sichtbar sind, die in der verwalteten Laufzeitumgebung ausgeführt werden.

Geräteimplementierungen:

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

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

• [C-0-3] DÜRFEN KEINE verwalteten APIs auslassen, API-Schnittstellen oder Signaturen ändern, vom dokumentierten Verhalten abweichen oder No-Ops-Funktionen einschließen, sofern dies nicht ausdrücklich durch diese Kompatibilitätsdefinition gestattet ist.

• [C-0-4] MÜSSEN die APIs weiterhin vorhanden sein und sich einwandfrei verhalten, selbst wenn einige Hardwarefunktionen, für die Android APIs enthält, weggelassen werden. Informationen zu den spezifischen Anforderungen für dieses Szenario finden Sie in Abschnitt 7.

• [C-0-5] MÜSSEN die Nutzung von Drittanbieter-Apps mit verborgenen APIs einschränken, die als APIs im Android-Namespace definiert sind, die mit der Annotation @hidden, aber nicht mit einer @SystemAPI oder @TestApi versehen sind, wie in den SDK-Dokumenten beschrieben. Außerdem MUSS die Verwendung der ausgeblendeten APIs auf den gleichen eingeschränkten Listen wie in der vorläufigen Liste und den Sperrlistendateien im Pfad prebuilts/runtime/appcompat/ für den entsprechenden API-Level-Zweig im AOSP versendet werden. Allerdings gilt:

  • Wenn eine versteckte API fehlt oder in der Geräteimplementierung anders implementiert wurde, verschieben Sie die verborgene API in die Sperrliste oder lassen Sie sie aus allen eingeschränkten Listen weg.
  • MAG, wenn noch keine ausgeblendete API im AOSP vorhanden ist, füge die ausgeblendete API einer der eingeschränkten Listen hinzu.
  • KANN einen Mechanismus für dynamische Updates implementieren, mit dem eine ausgeblendete API von einer eingeschränkten Liste in eine weniger restriktive Liste (mit Ausnahme der Zulassungsliste) verschoben wird.

3.1.1. Android-Erweiterungen

Android bietet die Unterstützung der Erweiterung der verwalteten APIs unter Beibehaltung derselben API-Level-Version.

• [C-0-1] Implementierungen auf Android-Geräten MÜSSEN die AOSP-Implementierung der gemeinsam genutzten Bibliothek ExtShared und der Dienste ExtServices vorab mit Versionen laden, die mindestens der für jedes API-Level zulässigen Mindestversion entsprechen. Beispielsweise MUSS bei Geräteimplementierungen mit Android 7.0 mit dem API-Level 24 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] DARF die Bibliothek org.apache.http.legacy NICHT im Bootklassenpfad platzieren.
• [C-0-2] MUSS die org.apache.http.legacy-Bibliothek nur dann zum Klassenpfad der Anwendung hinzufügen, wenn die App eine der folgenden Bedingungen erfüllt:
  • Ausrichtung auf API-Level 28 oder niedriger.
  • Deklariert im Manifest, 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-Kompatibilität

Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 enthält Android auch eine erhebliche nur zur Laufzeit verfügbare „weiche“ API in Form von Intents, Berechtigungen und ähnlichen Aspekten von Android-Apps, die nicht zum Kompilieren der Anwendung erzwungen werden können.

3.2.1. Berechtigungen

• [C-0-1] Geräteimplementierungen MÜSSEN alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der Referenzseite für Berechtigungen dokumentiert. In Abschnitt 9 sind zusätzliche Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell aufgeführt.

3.2.2. Build-Parameter

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

• [C-0-1] Um einheitliche, aussagekräftige Werte für alle Geräteimplementierungen bereitzustellen, enthält die folgende Tabelle zusätzliche Beschränkungen für die Formate dieser Werte, denen die Geräteimplementierungen entsprechen MÜSSEN.

Parameter	Details
VERSION.VERÖFFENTLICHUNG	Die Version des derzeit ausgeführten Android-Systems in einem visuell lesbaren Format. Dieses Feld MUSS einen der in 9 definierten Stringwerte enthalten.
SDK VERSION	Die Version des derzeit ausgeführten Android-Systems in einem Format, auf das Drittanbieter-App-Code zugreifen kann. Bei Android 9 MUSS dieses Feld den Ganzzahlwert 9_INT haben.
VERSION.SDK_INT	Die Version des derzeit ausgeführten Android-Systems in einem Format, auf das Drittanbieter-App-Code zugreifen kann. Bei Android 9 MUSS dieses Feld den Ganzzahlwert 9_INT haben.
VERSION.INCREMENTAL	Ein vom Geräte-Implementierer ausgewählter Wert, der den spezifischen Build des derzeit ausgeführten Android-Systems in einem visuell lesbaren Format angibt. Dieser Wert DARF NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. Mit diesem Feld wird üblicherweise angegeben, welche Build-Nummer oder Versionsverwaltungs-ID zum Generieren des Builds verwendet wurde. Es gibt keine Anforderungen für das spezifische Format dieses Felds, außer dass es NICHT null sein oder der leere String ("") sein darf.
BRETTSPIEL	Ein von der Geräteimplementierung ausgewählter Wert, der die vom Gerät verwendete spezifische interne Hardware in einem für Menschen lesbaren Format identifiziert. Dieses Feld kann verwendet werden, um die spezifische Version der Leiterplatte anzugeben, über die das Gerät betrieben wird. 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 mit dem Gerät assoziierten Markennamen widerspiegelt, der den Endnutzern bekannt ist. MÜSSEN in einem visuell lesbaren Format vorliegen und den Hersteller des Geräts oder die Unternehmensmarke repräsentieren, unter der das Gerät vertrieben wird. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck "^[a-zA-Z0-9_-]+$" entsprechen.
UNTERSTÜTZTE ABIS	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität.
UNTERSTÜTZT_32_BIT_ABIS	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität.
UNTERSTÜTZT_64_BIT_ABIS	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität.
CPU_ABI	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität.
CPU_ABI2	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3. Native API-Kompatibilität.
GERÄT	Wert, der vom Geräte-Implementierer ausgewählt wird und den Entwicklungsnamen oder Codenamen enthält, der die Konfiguration der Hardwarefunktionen und das industrielle Design des Geräts identifiziert. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen. Dieser Gerätename DARF NICHT während der Lebensdauer des Produkts geändert werden.
Fingerabdruck	Ein String, der diesen Build eindeutig identifiziert. Sie SOLLTEN menschenlesbar sein. Sie MUSS dieser Vorlage folgen: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Beispiel: acme/meinprodukt/ mydevice:9/LMYXX/3359:userdebug/test-keys Der Fingerabdruck DARF KEINE Leerzeichen enthalten. Wenn andere Felder in der obigen Vorlage Leerzeichen enthalten, MÜSSEN sie im Build-Fingerabdruck durch ein anderes Zeichen ersetzt werden, z. B. den Unterstrich ("_"). Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden können.
Hardware	Der Name der Hardware (aus der Kernel-Befehlszeile oder aus „/proc“). Sie SOLLTEN menschenlesbar sein. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck "^[a-zA-Z0-9_-]+$" entsprechen.
Moderator	Ein String, der den Host, auf dem der Build basiert, in einem für Menschen lesbaren Format eindeutig identifiziert. Es gibt keine Anforderungen für das spezifische Format dieses Felds, außer dass es NICHT null sein oder der leere String ("") sein darf.
ID	Eine vom Geräteimplementierung ausgewählten Kennung in einem visuell lesbaren Format, um auf eine bestimmte Version zu verweisen. Dieses Feld kann mit „android.os.Build.VERSION.INCREMENTAL“ übereinstimmen, SOLLTE aber ein Wert sein, 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 Handelsname des Erstausrüsters (Original Equipment Manufacturer, OEM) des Produkts. Es gibt keine Anforderungen an das spezifische Format dieses Felds, mit der Ausnahme, dass es NICHT null sein oder der leere String (""). Dieses Feld DARF NICHT während der Lebensdauer des Produkts geändert werden.
MODELL	Wert, der von der Geräteimplementierung ausgewählt wird und den Namen des Geräts enthält, der dem Endnutzer bekannt ist. Dies SOLLTE der Name sein, unter dem das Gerät vermarktet und an Endnutzer verkauft wird. Es gibt keine Anforderungen an das spezifische Format dieses Felds, mit der Ausnahme, dass es NICHT null sein oder der leere String (""). Dieses Feld DARF NICHT während der Lebensdauer des Produkts geändert werden.
PRODUKT/FUNKTION	Ein Wert, der vom Geräte-Implementierer ausgewählt wird und den Entwicklungs- oder Codenamen des spezifischen Produkts (SKU) enthält, der innerhalb derselben Marke eindeutig sein MUSS. MÜSSEN lesbar sein, sind aber nicht unbedingt zur Ansicht für Endnutzer gedacht. Der Wert dieses Feldes MÜSSEN als 7-Bit-ASCII codiert werden und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen. Dieser Produktname DARF NICHT während der Lebensdauer des Produkts geändert werden.
Seriennummer	MÜSSEN "UNKNOWN" zurückgeben.
TAGS	Eine durch Kommas getrennte Liste von Tags, die vom Geräte-Implementierer ausgewählt wurden und den Build weiter unterscheiden. Dieses Feld MUSS einen der Werte enthalten, die den drei typischen Signaturkonfigurationen für Android-Plattformen entsprechen: Releaseschlüssel, Entwicklerschlüssel, Testschlüssel.
UHRZEIT	Ein Wert, der den Zeitstempel für den Build darstellt.
SCHREIBMASCHINE	Wert, der vom Geräte-Implementierer ausgewählt wird, der die Laufzeitkonfiguration des Builds angibt. Dieses Feld MUSS einen der Werte enthalten, die den drei typischen Android-Laufzeitkonfigurationen entsprechen: user, userdebug oder eng.
NUTZER	Ein Name oder die Nutzer-ID des Nutzers (oder des automatisierten Nutzers), der den Build generiert hat. Es gibt keine Anforderungen für das spezifische Format dieses Felds, außer dass es NICHT null sein oder der leere String ("") sein darf.
SICHERHEITSPATCH	Ein Wert, der die Sicherheitspatch-Ebene eines Builds angibt. Er MUSS angeben, dass der Build in keiner Weise anfällig für eines der Probleme ist, die im ausgewiesenen öffentlichen Sicherheitsbulletin für Android beschrieben sind. Sie MUSS das Format [JJJJ-MM-TT] haben und mit einem definierten String übereinstimmen, der im öffentlichen Sicherheitsbulletin von Android oder in den Sicherheitshinweisen für Android dokumentiert ist, z. B. „2015-11-01“.
BASIS_OS	Ein Wert, der den FINGERPrint-Parameter des Builds darstellt, der ansonsten mit diesem Build identisch ist, mit Ausnahme der Patches, die im Android Public Security Bulletin bereitgestellt werden. Sie MÜSSEN den richtigen Wert melden. Wenn ein solcher Build nicht vorhanden ist, wird ein leerer String („“) gemeldet.
BOOTLOADER	Ein vom Geräte-Implementierer ausgewählter Wert, der die spezifische interne Bootloader-Version identifiziert, die auf dem Gerät verwendet wird, in einem für Menschen lesbaren Format. Der Wert dieses Felds MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen.
getRadioVersion()	MÜSSEN (oder zurückgegeben) ein vom Geräte-Implementierer ausgewählter Wert sein, der die spezifische interne Funk-/Modemversion in einem visuell lesbaren Format identifiziert. Wenn ein Gerät über keine interne Funkschnittstelle bzw. kein internes Modem verfügt, MUSS das Gerät NULL zurückgeben. Der Wert in diesem Feld MUSS als 7-Bit-ASCII codiert werden können und dem regulären Ausdruck „^[a-zA-Z0-9._-,]+$“ entsprechen.
getSerial()	MÜSSEN (oder zurückgeben) eine Hardware-Seriennummer, die für alle Geräte mit demselben MODELL und MANUFACTURER verfügbar und eindeutig sein muss. Der Wert in diesem Feld 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 Kernanwendungs-Intents

Android-Intents ermöglichen es Anwendungskomponenten, Funktionen von anderen Android-Komponenten anzufordern. Das Android-Upstream-Projekt umfasst eine Liste von Anwendungen, die als Android-Kernanwendungen gelten und die mehrere Intent-Muster zum Ausführen gängiger Aktionen implementiert.

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

  • Schreibtischuhr
  • Browser
  • Kalender
  • Kontakte
  • Galerie
  • Globale Suche
  • Werfer
  • Musik
  • Einstellungen

3.2.3.2 Intent-Auflösung

• [C-0-1] Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen zulassen, dass jedes in Abschnitt 3.2.3.1 erwähnte Intent-Muster (mit Ausnahme der Einstellungen) von Drittanbieter-Apps überschrieben wird. Bei der vorgelagerten Open-Source-Implementierung von Android ist dies standardmäßig möglich.

• [C-0-2] Geräte-Implementierer DÜRFEN KEINE besonderen Berechtigungen für die Verwendung dieser Intent-Muster durch Systemanwendungen zuweisen oder verhindern, dass Anwendungen von Drittanbietern an diese Muster binden und die Kontrolle über sie übernehmen. Dieses Verbot umfasst insbesondere die Deaktivierung der Benutzeroberfläche „Auswahl“, über die Nutzer zwischen mehreren Anwendungen wählen können, die alle dasselbe Intent-Muster verarbeiten.

• [C-0-3] Geräteimplementierungen MÜSSEN eine Benutzeroberfläche bereitstellen, ü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. Beispielsweise ist ein Intent-Filtermuster, das den Daten-URI „http://www.android.com“ angibt, spezifischer als das grundlegende Intent-Muster des Browsers für „http://“.

Android umfasst auch einen Mechanismus, mit dem Drittanbieter-Apps ein autoritatives Standardverhalten zum Verknüpfen von Apps für bestimmte Arten von Web-URI-Intents deklarieren können. Wenn solche maßgeblichen Deklarationen in den Intent-Filtermustern einer App definiert sind, gilt für Geräteimplementierungen Folgendes:

• [C-0-4] MÜSSEN versuchen, Intent-Filter zu validieren, indem Sie die in der Digital Asset Links-Spezifikation definierten Validierungsschritte ausführen, die vom Paketmanager im vorgelagerten Android-Open-Source-Projekt implementiert wurden.
• [C-0-5] MÜSSEN während der Installation der Anwendung die Intent-Filter 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 mögliche URI-Filter die Überprüfung nicht bestehen. Wenn dies bei einer Geräteimplementierung geschieht, MUSS dem Nutzer im Einstellungsmenü die entsprechenden Pro-URI-Musterüberschreibungen bereitgestellt werden.
• Dem Nutzer MUSS in den Einstellungen die folgenden Einstellungen für App-Links zur Verfügung stehen:
  • [C-0-6] Der Nutzer MÜSSEN in der Lage sein, das Standardverhalten von App-Links für eine App als Ganzes zu überschreiben: immer offen, immer fragen oder nie öffnen, was für alle möglichen URI-Intent-Filter gleichermaßen gelten muss.
  • [C-0-7] Der Nutzer MÜSSEN eine Liste möglicher URI-Intent-Filter sehen können.
  • Mit der Geräteimplementierung MÖGLICHERWEISE dem Nutzer die Möglichkeit geben, bestimmte URI-Intent-Filter, die erfolgreich verifiziert wurden, für einzelne Intent-Filter zu überschreiben.
  • [C-0-8] Die Geräteimplementierung MÜSSEN Nutzern die Möglichkeit geben, bestimmte mögliche URI-Intent-Filter aufzurufen und zu überschreiben, wenn bei der Geräteimplementierung einige der möglichen URI-Intent-Filter erfolgreich überprüft werden können, während andere fehlschlagen können.

3.2.3.3 Intent-Namespaces

• [C-0-1] Geräteimplementierungen DÜRFEN KEINE Android-Komponente enthalten, die neue Intent- oder Broadcast-Intent-Muster berücksichtigt und dabei eine ACTION-, CATEGORY- oder einen anderen Schlüsselstring im Android- oder com.android.-Namespace verwendet.
• [C-0-2] Geräte-Implementierer DÜRFEN KEINE Android-Komponenten enthalten, die neue Intent- oder Broadcast-Intent-Muster berücksichtigen und dabei eine ACTION-, CATEGORY- oder einen anderen Schlüsselstring in einem Paketbereich, der zu einer anderen Organisation gehört, verwenden.
• [C-0-3] Geräteimplementierungen DÜRFEN KEINE Intent-Muster ändern oder erweitern, die von den in Abschnitt 3.2.3.1 aufgeführten Kern-Apps verwendet werden.
• Geräteimplementierungen KÖNNEN Intent-Muster mit Namespaces enthalten, die klar und deutlich mit der eigenen Organisation verknüpft sind. Dieses Verbot entspricht dem, das in Abschnitt 3.6 für Java-Sprachklassen festgelegt wurde.

3.2.3.4 Übertragungs-Intents

Drittanbieteranwendungen nutzen die Plattform, um bestimmte Intents zu senden und so über Änderungen in der Hardware- oder Softwareumgebung zu informieren.

Geräteimplementierungen:

• [C-0-1] MÜSSEN die Public-Broadcast-Intents als Reaktion auf entsprechende Systemereignisse wie in der SDK-Dokumentation beschrieben übertragen. Diese Anforderung steht nicht im Widerspruch zu Abschnitt 3.5, da die Einschränkungen für Hintergrundanwendungen auch in der SDK-Dokumentation beschrieben sind.

3.2.3.5 Standard-App-Einstellungen

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

Wo es sinnvoll ist, MÜSSEN Geräteimplementierungen ein ähnliches Einstellungsmenü bereitstellen und mit dem Intent-Filtermuster und den API-Methoden kompatibel sein, die in der SDK-Dokumentation beschrieben werden (siehe unten).

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

• [C-1-1] MÜSSEN den Intent android.settings.HOME_SETTINGS berücksichtigen, um ein Standardmenü mit App-Einstellungen für den Startbildschirm anzuzeigen.

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

• [C-2-1] MÜSSEN ein Einstellungsmenü bereitstellen, über das der Intent android.provider.Telephony.ACTION_CHANGE_DEFAULT aufgerufen wird, um ein Dialogfeld zum Ändern der Standard-SMS-Anwendung anzuzeigen.

• [C-2-2] MÜSSEN den Intent android.telecom.action.CHANGE_DEFAULT_DIALER berücksichtigen, um ein Dialogfeld anzuzeigen, über das der Nutzer die Standard-Telefon-App ändern kann.

  • MÜSSEN die vom Nutzer ausgewählte Benutzeroberfläche der Standard-Telefon-App für ein- und ausgehende Anrufe verwendet werden. Eine Ausnahme bilden Notrufe, für die die vorinstallierte Telefon App verwendet wird.

• [C-2-3] MÜSSEN den Intent android.telecom.action.CHANGE_PHONE_ACCOUNTS berücksichtigen, um dem Nutzer die Möglichkeit zu bieten, das mit PhoneAccounts verknüpfte ConnectionServices sowie ein standardmäßiges PhoneAccount zu konfigurieren, das der Telekommunikationsanbieter für ausgehende Anrufe verwendet. Die AOSP-Implementierung erfüllt diese Anforderung, indem im Einstellungsmenü „Anrufe“ ein Menü „Anrufkonten“ hinzugefügt wird.

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

• [C-3-1] MÜSSEN den Intent android.settings.NFC_PAYMENT_SETTINGS berücksichtigen, um ein Standardmenü mit App-Einstellungen für das mobile Bezahlen anzuzeigen.

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

• [C-4-1] MÜSSEN den android.settings.ACTION_VOICE_INPUT_SETTINGS-Intent berücksichtigen, um ein Standardmenü mit App-Einstellungen für Spracheingabe und Unterstützung anzuzeigen.

3.2.4 Aktivitäten auf sekundären Displays

Wenn die Geräteimplementierung das Starten normaler Android-Aktivitäten auf sekundären Displays zulässt, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag „android.software.activities_on_secondary_displays“ festlegen.
• [C-1-2] MUSS eine API-Kompatibilität ähnlich einer Aktivität, die auf dem Hauptdisplay ausgeführt wird, garantiert werden.
• [C-1-3] Wenn die neue Aktivität gestartet wird, ohne eine Zielanzeige über die ActivityOptions.setLaunchDisplayId() API anzugeben, MUSS die neue Aktivität zur selben Anzeige wie die Aktivität geführt werden, mit der sie gestartet wurde.
• [C-1-4] MUSS alle Aktivitäten löschen, wenn eine Anzeige mit dem Flag Display.FLAG_PRIVATE entfernt wird.
• [C-1-5] MÜSSEN die Größe aller Aktivitäten in einem VirtualDisplay entsprechend angepasst werden, wenn die Größe des Bildschirms selbst geändert wird.
• KANN auf dem primären Bildschirm ein IME (Eingabemethodeneditor, ein Nutzersteuerelement, mit dem Nutzer Text eingeben können) auf dem primären Bildschirm angezeigt werden, wenn ein Texteingabefeld auf einen sekundären Bildschirm fokussiert wird.
• SOLLTEN Sie den Eingabefokus unabhängig vom primären Bildschirm auf dem sekundären Display implementieren, wenn die Eingabe per Berührung oder Tasten unterstützt wird.
• SOLLTEN SIE android.content.res.Configuration haben, das zu diesem Bildschirm gehört, damit sie angezeigt wird, richtig funktioniert und die Kompatibilität aufrechterhalten wird, wenn eine Aktivität auf dem zweiten Display gestartet wird.

Wenn die Geräteimplementierung das Starten normaler Android-Aktivitäten auf sekundären Displays und primären und sekundären Displays unterschiedliche android.util.DisplayMetrics ermöglicht:

• [C-2-1] Nicht anpassbare Aktivitäten (mit resizeableActivity=false in AndroidManifest.xml) und Apps, die auf API-Level 23 oder niedriger ausgerichtet sind, DÜRFEN auf sekundären Displays NICHT erlaubt sein.

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

• [C-3-1] Nur der Eigentümer dieses Displays, Systems und Aktivitäten, die sich bereits auf diesem Display befinden, MUSS das Gerät starten können. Jeder kann einen Bildschirm mit dem Flag android.view.Display.FLAG_PUBLIC starten.

3.3. Native API-Kompatibilität

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

• [SR] EMPFOHLEN, die Implementierungen der unten aufgeführten Bibliotheken aus dem vorgelagerten Android-Open-Source-Projekt zu verwenden.

3.3.1 Binäre Anwendungsschnittstellen

Der verwaltete Dalvik-Bytecode kann nativen Code aufrufen, der in der .apk-Datei der Anwendung als ELF-.so-Datei 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 Binärschnittstellen (Application Binary Interfaces, ABIs).

Geräteimplementierungen:

• [C-0-1] MÜSSEN mit einem oder mehreren definierten ABIs kompatibel sein und die Kompatibilität mit dem Android NDK implementieren.
• [C-0-2] MÜSSEN Support für Code bereitstellen, der in der verwalteten Umgebung ausgeführt wird, um nativen Code mit der standardmäßigen JNI-Semantik (Java Native Interface) aufzurufen.
• [C-0-3] MÜSSEN mit jeder erforderlichen Bibliothek in der Liste unten quellkompatibel (d.h. header-kompatibel) und binär kompatibel (für das ABI) sein.
• [C-0-5] MÜSSEN die native Binärschnittstelle (Application Binary Interface, ABI), die vom Gerät unterstützt wird, korrekt über die Parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS und android.os.Build.SUPPORTED_64_BIT_ABIS melden, jeweils eine durch Kommas getrennte Liste von ABIs, sortiert von der am häufigsten bis zur am wenigsten bevorzugten.

• [C-0-6] MÜSSEN über die oben genannten Parameter eine Teilmenge der folgenden Liste von ABIs melden und DARF KEINE ABIs melden, die nicht auf der Liste stehen.

  • 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 zur Verfügung stellen:

  • libaaudio.so (Unterstützung für natives AAudio-Audio)

  • libandroid.so (native Unterstützung für Android-Aktivitäten)
  • libc (C-Bibliothek)
  • libcamera2ndk.so
  • libdl (dynamische Verknüpfung)
  • libEGL.so (natives OpenGL-Oberflächenmanagement)
  • 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 von OpenMAX AL 1.0.1)
  • libOpenSLES.so (Audiounterstützung von OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (Minimale Unterstützung für C++)
  • libvulkan.so (Vulkan)
  • libz (Zlib-Komprimierung)
  • JNI-Schnittstelle

• [C-0-8] DÜRFEN die öffentlichen Funktionen für die oben aufgeführten nativen Bibliotheken NICHT hinzufügen oder entfernen.

• [C-0-9] MÜSSEN zusätzliche Bibliotheken ohne AOSP auflisten, die direkt in /vendor/etc/public.libraries.txt von Drittanbieter-Apps bereitgestellt 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 freigegeben werden, da diese reserviert sind.
• [C-0-11] MÜSSEN alle Funktionssymbole für OpenGL ES 3.1 und Android Extension Pack, wie im NDK definiert, über die libGLESv3.so-Bibliothek exportieren. Beachten Sie, dass alle Symbole vorhanden sein MÜSSEN, in Abschnitt 7.1.4.1 jedoch genauer beschrieben wird, wann die vollständige Implementierung der entsprechenden Funktionen erwartet wird.
• [C-0-12] MÜSSEN Funktionssymbole für die Hauptfunktionssymbole von Vulkan 1.0 sowie die Erweiterungen VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 und VK_KHR_get_physical_device_properties2 über die libvulkan.so-Bibliothek exportieren. Beachten Sie, dass alle Symbole vorhanden sein MÜSSEN, in Abschnitt 7.1.4.2 jedoch genauer beschrieben wird, wann die vollständige Implementierung der entsprechenden Funktionen erwartet wird.
• SOLLTE mit dem Quellcode und den Header-Dateien erstellt werden, die im vorgelagerten Android Open Source Project verfügbar sind.

In zukünftigen Android-Versionen werden möglicherweise weitere ABIs unterstützt.

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

Wenn Geräteimplementierungen die Unterstützung des ABI für armeabi melden, geschieht Folgendes:

• [C-3-1] MÜSSEN auch armeabi-v7a unterstützen und dies melden, da armeabi nur der Abwärtskompatibilität mit älteren Apps dient.

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

• [C-2-1] MÜSSEN die folgenden Zeilen in /proc/cpuinfo einfügen und die Werte auf demselben Gerät NICHT ändern, selbst 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] MÜSSEN die folgenden Vorgänge immer verfügbar halten, auch wenn das ABI in einer ARMv8-Architektur implementiert ist, entweder durch native CPU-Unterstützung oder durch Softwareemulation:

  • Anweisungen zu SWP und SWPB
  • SETEND-Anweisung
  • CP15ISB-, CP15DSB- und CP15DMB-Hürdenoperationen

• [C-2-3] MÜSSEN Support für die Erweiterung Advanced SIMD (NEON) bereitstellen.

3.4 Webkompatibilität

3.4.1 WebView-Kompatibilität

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

• [C-1-1] MÜSSEN android.software.webview melden.
• [C-1-2] MUSS zur Implementierung der android.webkit.WebView API den Chromium-Projekt-Build aus dem übergeordneten Android Open Source Project im Android 9-Zweig verwenden.

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

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, wie 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, aber wenn er nicht leer ist, MUSS er denselben Wert wie android.os.Build.MODEL haben.
  • „Build/$(BUILD)“ KANN weggelassen werden, aber wenn vorhanden ist, MUSS der String $(BUILD) mit dem Wert für android.os.Build.ID identisch sein.
  • Der Wert des Strings $(CHROMIUM_VER) MUSS der Version von Chromium im vorgelagerten Android-Open-Source-Projekt 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. Sofern sie dies unterstützt, SOLLTE die WebView-Komponente der HTML5-Spezifikation entsprechen.

3.4.2 Browserkompatibilität

Wenn Geräteimplementierungen eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten, gilt Folgendes:

• [C-1-1] MUSS alle der folgenden mit HTML5 verknüpften APIs unterstützen:
  • Anwendungscache/Offlinevorgang
  • <video>-Tag
  • Standortbestimmung
• [C-1-2] MÜSSEN die HTML5/W3C Webstorage API und die HTML5/W3C IndexedDB API unterstützen. Im Zuge der Umstellung der Normen zur Webentwicklung auf IndexedDB gegenüber Webspeichern wird erwartet, dass IndexedDB in einer zukünftigen Android-Version eine erforderliche Komponente sein wird.
• KANN einen benutzerdefinierten User-Agent-String in der eigenständigen Browseranwendung versenden.
• SOLLTEN SIE in der eigenständigen Browseranwendung möglichst viele HTML5-Elemente unterstützen (unabhängig davon, ob diese auf der vorgelagerten WebKit-Browseranwendung oder einer Ersatzanwendung durch einen Drittanbieter basiert).

Wenn Geräteimplementierungen jedoch keine eigenständige Browser-App enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN weiterhin die in Abschnitt 3.2.3.1 beschriebenen Muster für die öffentliche Absicht unterstützen.

3.5 API-Verhaltenskompatibilität

Geräteimplementierungen:

• [C-0-9] MÜSSEN sicherstellen, dass die API-Verhaltenskompatibilität auf alle installierten Apps angewendet wird, es sei denn, sie sind wie in Abschnitt 3.5.1 beschrieben eingeschränkt.
• [C-0-10] DÜRFEN NICHT die Zulassungsliste implementieren, die die Verhaltenskompatibilität der API nur bei Apps gewährleistet, die von den Geräteimplementierungen ausgewählt wurden.

Das Verhalten der einzelnen API-Typen (verwaltet, weich, nativ und Web) muss der bevorzugten Implementierung des vorgelagerten Android-Open-Source-Projekts entsprechen. Einige spezifische Kompatibilitätsbereiche sind:

• [C-0-1] Geräte DÜRFEN NICHT das Verhalten oder die Semantik eines Standard-Intents ändern.
• [C-0-2] Geräte DÜRFEN den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (wie Dienst, Aktivität, ContentProvider usw.) NICHT verändern.
• [C-0-3] Geräte DÜRFEN die Semantik einer Standardberechtigung NICHT ändern.
• Auf den Geräten DÜRFEN die Beschränkungen für Hintergrund-Apps NICHT geändert werden. Genauer gesagt für Hintergrund-Apps:
  • [C-0-4] Sie MÜSSEN die Ausführung von Callbacks beenden, die von der App registriert sind, um Ausgaben von GnssMeasurement und GnssNavigationMessage zu erhalten.
  • [C-0-5] MÜSSEN die Häufigkeit von Updates, die für die App über die API-Klasse LocationManager oder die Methode WifiManager.startScan() bereitgestellt werden, begrenzt werden.
  • [C-0-6] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, DÜRFEN SIE NICHT erlauben, Broadcast-Empfänger für die impliziten Broadcasts von standardmäßigen Android-Intents im Manifest der App zu registrieren, es sei denn, der Broadcast-Intent erfordert eine "signature"- oder "signatureOrSystem"-protectionLevel-Berechtigung oder befindet sich auf der Ausnahmeliste.
  • [C-0-7] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN sie die Hintergrunddienste der App beenden, so als ob die App die Methode stopSelf() des Dienstes aufgerufen hätte, es sei denn, die App wird auf eine temporäre Zulassungsliste gesetzt, um eine Aufgabe auszuführen, die für den Nutzer sichtbar ist.
  • [C-0-8] Wenn die App auf API-Level 25 oder höher ausgerichtet ist, MÜSSEN die von der App zurückgehaltenen 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, es sei denn, die App hat die Liste über insertProviderAt() oder removeProvider() geändert. Geräte können neben der unten angegebenen Liste mit Anbietern weitere 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 signifikante Teile der Plattform auf Verhaltenskompatibilität, aber nicht alle. Der Implementierer ist dafür verantwortlich, die Verhaltenskompatibilität mit dem Android Open Source Project zu gewährleisten. Aus diesem Grund sollten Geräte-Implementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt große Teile des Systems erneut zu implementieren.

3.5.1 Hintergrundbeschränkung

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

• [C-SR] EMPFOHLEN, Nutzern eine Liste der eingeschränkten Apps anzeigen zu können, wird dringend empfohlen.
• [C-1-2] MÜSSEN Nutzern die Möglichkeit bieten, die Einschränkungen für jede App zu aktivieren / deaktivieren.
• [C-1-3] DÜRFEN nicht automatisch Einschränkungen anwenden, wenn kein Anzeichen für ein schlechtes Systemzustand vorliegt. Die Einschränkungen für Apps MÖGLICHERWEISE jedoch MÖGLICH, die Einschränkungen für Apps anwenden, wenn ein schlechtes Systemzustandsverhalten wie hängende Wakelocks, Dienste mit langer Laufzeit und andere Kriterien erkannt werden. Die Kriterien MÖGLICHERWEISE von den Geräteimplementierungen festgelegt werden, MÜSSEN jedoch im Zusammenhang mit den Auswirkungen der App auf den Systemzustand stehen. Andere Kriterien, die sich nicht nur auf den Systemzustand beziehen, z. B. die geringe Beliebtheit der App auf dem Markt, DÜRFEN NICHT als Kriterien verwendet werden.
• [C-1-4] MUSS nicht automatisch App-Einschränkungen für Apps anwenden, wenn ein Nutzer App-Einschränkungen manuell deaktiviert hat, und KANN dem Nutzer vorschlagen, App-Einschränkungen anzuwenden.
• [C-1-5] MÜSSEN Nutzer informieren, wenn App-Einschränkungen automatisch auf eine App angewendet werden.
• [C-1-6] MÜSSEN true für ActivityManager.isBackgroundRestricted() zurückgeben, wenn die eingeschränkte App diese API aufruft.
• [C-1-7] DARF NICHT die im Vordergrund verwendete App einschränken, die vom Nutzer explizit verwendet wird.
• [C-1-8] MÜSSEN die Einschränkungen für eine App aussetzen, die zur obersten App im Vordergrund wird, wenn der Nutzer explizit beginnt, die zuvor eingeschränkte App zu verwenden.

3.6. API-Namespaces

Android folgt den Konventionen für Paket- und Klassen-Namespaces, die von der Programmiersprache Java definiert werden. Um die Kompatibilität mit Anwendungen von Drittanbietern sicherzustellen, dürfen Geräte-Implementierer KEINE unzulässigen Änderungen (siehe unten) an diesen Paket-Namespaces vornehmen:

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

Das heißt:

• [C-0-1] DÜRFEN die öffentlich zugänglichen APIs auf der Android-Plattform NICHT verändern, indem Sie Methoden oder Klassensignaturen ändern oder Klassen oder Klassenfelder entfernen.
• [C-0-2] DÜRFEN KEINE öffentlich zugänglichen Elemente (wie Klassen oder Schnittstellen bzw. Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) oder Test- oder System-APIs zu den APIs in den oben genannten Namespaces hinzufügen. Ein „öffentlich sichtbares Element“ ist ein Konstrukt, das nicht mit der Markierung „@hide“ dekoriert ist, wie es im vorgelagerten Android-Quellcode verwendet wird.

Geräte-Implementierer KÖNNEN die zugrunde liegende Implementierung der APIs ändern. Durch solche Änderungen gilt jedoch Folgendes:

• [C-0-3] DÜRFEN das angegebene Verhalten und die Java-Sprachsignatur von öffentlich zugänglichen APIs NICHT beeinflussen.
• [C-0-4] DÜRFEN NICHT beworben und nicht auf andere Weise Entwicklern zugänglich gemacht werden.

Geräte-Implementierer KÖNNEN jedoch benutzerdefinierte APIs außerhalb des standardmäßigen Android-Namespace hinzufügen. Die benutzerdefinierten APIs jedoch:

• [C-0-5] DÜRFEN sich NICHT in einem Namespace befinden, der einer anderen Organisation gehört oder auf diese verweist. Zum Beispiel dürfen Geräte-Implementierer KEINE APIs zu com.google.* oder einem ähnlichen Namespace hinzufügen, sondern nur von Google. Ebenso DARF Google KEINE APIs zu Namespaces anderer Unternehmen hinzufügen.
• [C-0-6] MÜSSEN in einer gemeinsam genutzten Bibliothek von Android gepackt sein, damit nur Apps, die diese explizit (über den Mechanismus <uses-library>) verwenden, von der erhöhten Speichernutzung solcher APIs betroffen sind.

Wenn ein Geräte-Implementierer vorschlägt, einen der oben genannten Paket-Namespaces zu verbessern, z. B. durch das Hinzufügen nützlicher neuer Funktionen zu einer vorhandenen API oder das Hinzufügen einer neuen API, sollte der Implementierer source.android.com aufrufen und mit dem Prozess beginnen, Änderungen und Code gemäß den Informationen auf dieser Website beizusteuern.

Beachten Sie, dass die oben genannten Einschränkungen Standardkonventionen für die Benennung von APIs in der Programmiersprache Java entsprechen. In diesem Abschnitt soll lediglich versucht werden, diese Konventionen zu verstärken und durch Einbeziehung in diese Kompatibilitätsdefinition bindend zu machen.

3.7 Laufzeitkompatibilität

Geräteimplementierungen:

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

• [C-0-2] MÜSSEN Dalvik-Laufzeiten so konfigurieren, dass Speicher entsprechend der vorgelagerten Android-Plattform und wie in der folgenden Tabelle angegeben zugeordnet wird. Informationen zu Bildschirmgrößen und Bildschirmdichten finden Sie in Abschnitt 7.1.1.

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

• SOLLTEN Sie Fuzz-Tests in verschiedenen Ausführungsmodi und Zielarchitekturen durchführen, um die Stabilität der Laufzeit sicherzustellen. Weitere Informationen finden Sie auf der Website des Android Open Source Project unter JFuzz und DexFuzz.

Hinweis: Die unten angegebenen Speicherwerte gelten als Mindestwerte. Bei Geräteimplementierungen MÖGLICHERWEISE kann mehr Speicher pro Anwendung zugewiesen werden.

Bildschirmlayout	Bildschirmdichte	Mindestanforderungen an den Anwendungsarbeitsspeicher
Android-Uhr	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	280 dpi (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
klein/normal	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
groß	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
xlarge	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8 Kompatibilität der Benutzeroberfläche

3.8.1 Launcher (Startbildschirm)

Android umfasst eine Launcher-App (Startbildschirm) und Unterstützung für Drittanbieter-Apps als Ersatz für den Geräte-Launcher (Startbildschirm).

Wenn auf Geräten Drittanbieter-Apps den Startbildschirm des Geräts ersetzen können, geschieht Folgendes:

• [C-1-1] MÜSSEN die Plattformfunktion android.software.home_screen deklarieren.
• [C-1-2] MÜSSEN das AdaptiveIconDrawable-Objekt zurückgeben, wenn die Drittanbieter-App das <adaptive-icon>-Tag zur Bereitstellung ihres Symbols verwendet und die PackageManager-Methoden zum Abrufen von Symbolen aufgerufen werden.

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

• [C-2-1] MÜSSEN true für ShortcutManager.isRequestPinShortcutSupported() melden.
• [C-2-2] MÜSSEN den Nutzer fragen, ob er eine Verknüpfung hinzufügen kann, die von Apps über die API-Methode ShortcutManager.requestPinShortcut() angefordert wird.
• [C-2-3] MÜSSEN angepinnte Verknüpfungen sowie dynamische und statische Verknüpfungen unterstützen, wie auf der Seite „App-Verknüpfungen“ beschrieben.

Umgekehrt gilt: Wenn Geräteimplementierungen das Anpinnen von Verknüpfungen innerhalb der App nicht unterstützen, hat das folgende Auswirkungen:

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

Wenn in Geräteimplementierungen ein Standard-Launcher implementiert wird, der schnellen Zugriff auf zusätzliche Verknüpfungen von Drittanbieter-Apps über die ShortcutManager API bietet, geschieht Folgendes:

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

Wenn Geräte eine Standard-Launcher-App mit Badges für die App-Symbole enthalten, gilt Folgendes:

• [C-5-1] MUSS die API-Methode NotificationChannel.setShowBadge() berücksichtigen. Mit anderen Worten: Zeigen Sie ein visuelles Angebot, das mit dem App-Symbol verknüpft ist, wenn der Wert auf true festgelegt ist, und kein Kennzeichen für App-Symbole, wenn alle Benachrichtigungskanäle der App den Wert auf false gesetzt haben.
• KÖNNEN die App-Symbol-Logos durch das eigene Logo-Schema überschreiben, wenn Drittanbieter-Apps die Unterstützung des proprietären Kennzeichens mit proprietären APIs angeben, SOLLTEN jedoch die Ressourcen und Werte verwenden, die über die im SDK beschriebenen APIs für Benachrichtigungs-Badges bereitgestellt werden, z. B. Notification.Builder.setNumber() und die Notification.Builder.setBadgeIconType() API.

3.8.2 Widgets

Android unterstützt Widgets von Drittanbieter-Apps, indem ein Komponententyp, eine entsprechende API und ein Lebenszyklus definiert werden, die es Anwendungen ermöglichen, dem Endnutzer ein „AppWidget“ zur Verfügung zu stellen.

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

• [C-1-1] MÜSSEN die Unterstützung für Plattformfunktion android.software.app_widgets erklären.
• [C-1-2] MÜSSEN integrierte Unterstützung für AppWidgets zur Verfügung stehen und Funktionen der Benutzeroberfläche zum Hinzufügen, Konfigurieren, Anzeigen und Entfernen von AppWidgets direkt im Launcher anzeigen.
• [C-1-3] MÜSSEN Widgets mit dem Format 4 x 4 in der Standardrastergröße rendern können. Weitere Informationen finden Sie in den DesignGuidelines für App-Widgets in der Android SDK-Dokumentation.
• KANN App-Widgets auf dem Sperrbildschirm unterstützen.

Wenn Geräteimplementierungen Drittanbieter-App-Widgets 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] MÜSSEN den Nutzer fragen, ob er eine Verknüpfung hinzufügen kann, die von Apps über die API-Methode AppWidgetManager.requestPinAppWidget() angefordert wird.

3.8.3 Benachrichtigungen

Android umfasst Notification und NotificationManager APIs, mit denen Entwickler von Drittanbieter-Apps Nutzer über wichtige Ereignisse informieren und die Aufmerksamkeit der Nutzer mithilfe von Hardwarekomponenten (z.B. Ton, Vibration und Licht) und Softwarefunktionen (z.B. Benachrichtigungsleiste, Systemleiste) des Geräts wecken können.

3.8.3.1 Darstellung von Benachrichtigungen

Wenn Drittanbieter-Apps Nutzer über wichtige Ereignisse benachrichtigen dürfen, gilt Folgendes:

• [C-1-1] MÜSSEN Benachrichtigungen unterstützen, die Hardwarefunktionen verwenden, wie in der SDK-Dokumentation beschrieben, und soweit dies mit der Hardware zur Geräteimplementierung möglich ist. Wenn beispielsweise eine Geräteimplementierung einen Vibrationsalarm enthält, MÜSSEN die Vibrations-APIs korrekt implementiert werden. Wenn bei einer Geräteimplementierung keine Hardware vorhanden ist, MÜSSEN die entsprechenden APIs als managementfrei implementiert werden. Dieses Verhalten wird in Abschnitt 7 ausführlicher beschrieben.
• [C-1-2] MÜSSEN alle Ressourcen (Symbole, Animationsdateien usw.), die in den APIs oder im Symbol-Styleguide für Status/Systemleiste angegeben sind, korrekt rendern. Sie MÖGLICHERWEISE jedoch eine alternative Nutzererfahrung für Benachrichtigungen bieten als die, die in der Referenzimplementierung von Android Open Source bereitgestellt wird.
• [C-1-3] MÜSSEN die für die APIs beschriebenen Verhaltensweisen einhalten und korrekt implementieren, um Benachrichtigungen zu aktualisieren, zu entfernen und zu gruppieren.
• [C-1-4] MUSS das vollständige Verhalten der NotificationChannel API, die im SDK dokumentiert ist, bereitstellen.
• [C-1-5] MÜSSEN auf jeder Kanal- und App-Paketebene eine Nutzeroption zum Blockieren und Ändern der Benachrichtigung einer bestimmten Drittanbieter-App bereitstellen.
• [C-1-6] MÜSSEN auch eine Nutzeroption zum Anzeigen gelöschter Benachrichtigungskanäle anbieten.
• [C-1-7] MÜSSEN alle über Notification.MessagingStyle bereitgestellten Ressourcen (Bilder, Sticker, Symbole usw.) zusammen mit dem Benachrichtigungstext ohne zusätzliche Nutzerinteraktion korrekt rendern. Beispielsweise MÜSSEN alle Ressourcen und Symbole angezeigt werden, die von android.app.Person in einer Gruppenunterhaltung bereitgestellt werden, die über setGroupConversation festgelegt wird.
• [C-SR] Es wird dringend empfohlen, die Benachrichtigung einer bestimmten Drittanbieter-App für jeden Kanal und jede App-Paketebene automatisch anzuzeigen, nachdem der Nutzer die Benachrichtigung mehrmals geschlossen hat.
• SOLLTEN erweiterte Benachrichtigungen unterstützen.
• SOLLTEN Benachrichtigungen mit höherer Priorität als Vorabbenachrichtigungen präsentiert werden.
• SOLLTEN die Nutzer die Möglichkeit haben, Benachrichtigungen zurückzustellen.
• KANN nur die Sichtbarkeit und das Timing festlegen, wann Nutzer von Drittanbieter-Apps über wichtige Ereignisse informiert werden dürfen, um Sicherheitsprobleme wie die Ablenkung des Fahrers zu verringern.

Wenn Geräteimplementierungen umfassende Benachrichtigungen unterstützen, gilt Folgendes:

• [C-2-1] MUSS exakt die Ressourcen verwenden, die über die API-Klasse Notification.Style und deren Unterklassen für die dargestellten Ressourcenelemente bereitgestellt werden.
• SOLLTEN Sie jedes einzelne Ressourcenelement (z.B. Symbol, Titel und Zusammenfassungstext) präsentieren, das in der Notification.Style API-Klasse und den zugehörigen Unterklassen definiert ist.

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

• [C-3-1] MÜSSEN die Ansicht und die Ressourcen für Vorabbenachrichtigungen wie in der API-Klasse Notification.Builder beschrieben verwenden, wenn Vorabbenachrichtigungen angezeigt werden.
• [C-3-2] MÜSSEN die über Notification.Builder.addAction() bereitgestellten Aktionen zusammen mit dem Inhalt der Benachrichtigung ohne zusätzliche Nutzerinteraktion, wie im SDK beschrieben, angezeigt werden.

3.8.3.2 Mitteilungs-Listener-Dienst

Android enthält die NotificationListenerService APIs, über die Apps (sobald sie vom Nutzer explizit aktiviert wurden) eine Kopie aller Benachrichtigungen erhalten, sobald diese gepostet oder aktualisiert werden.

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

• [C-1-1] MÜSSEN Benachrichtigungen in ihrer Gesamtheit korrekt und unverzüglich vollständig für alle installierten und nutzeraktivierten Listener-Dienste, einschließlich aller an das Benachrichtigungsobjekt angehängten Metadaten, aktualisieren.
• [C-1-2] MÜSSEN den snoozeNotification()-API-Aufruf respektieren, die Benachrichtigung schließen und nach der im API-Aufruf festgelegten Schlummerdauer einen Rückruf tätigen.

Wenn Geräteimplementierungen Nutzern die Möglichkeit bieten, Benachrichtigungen zurückzustellen, geschieht Folgendes:

• [C-2-1] MÜSSEN den Status der zurückgestellten Benachrichtigungen über die Standard-APIs wie NotificationListenerService.getSnoozedNotifications() korrekt wiedergeben.
• [C-2-2] MÜSSEN diesem Nutzer die Möglichkeit zum Pausieren von Benachrichtigungen von jeder installierten Drittanbieter-App zur Verfügung stellen, es sei denn, diese stammen aus dauerhaften Diensten bzw. aus Diensten im Vordergrund.

3.8.3.3 Nicht stören

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

• [C-1-1] MÜSSEN eine Aktivität implementieren, die auf den Intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS reagieren würde. Bei Implementierungen mit UI_MODE_TYPE_NORMAL MUSS es eine Aktivität sein, bei der der Nutzer der App Zugriff auf nicht störende Richtlinienkonfigurationen gewähren oder verweigern kann.
• [C-1-2] MÜSSEN, wenn der Nutzer durch die Geräteimplementierung den Zugriff von Drittanbieter-Apps auf die „Nicht stören“-Richtlinienkonfiguration erlauben oder verweigern kann, die von Apps erstellten automatischen Regeln für „Nicht stören“ zusammen mit den vom Nutzer erstellten und vordefinierten Regeln angezeigt werden.
• [C-1-3] MÜSSEN die mit NotificationManager.Policy übergebenen Werte für suppressedVisualEffects berücksichtigen. Wenn für eine App eines der Flags SUPPRESSED_EFFEKT_SCREEN_OFF oder SUPPRESSED_EFFECT_SCREEN_ON festgelegt ist, SOLLTEN die Nutzer darauf hingewiesen werden, dass die visuellen Effekte im Einstellungsmenü „Nicht stören“ unterdrückt werden.

3.8.4. Suche

Android enthält APIs, mit denen Entwickler die Suche in ihre Anwendungen einbinden und die Daten ihrer Anwendungen in die globale Systemsuche aufnehmen können. Im Allgemeinen besteht diese Funktion aus einer einzigen, systemweiten Benutzeroberfläche, über die Nutzer Suchanfragen eingeben, Vorschläge während der Eingabe anzeigen und Ergebnisse anzeigen können. Mit den Android-APIs können Entwickler diese Oberfläche wiederverwenden, um eine Suche in ihren eigenen Apps durchzuführen, und ermöglichen es Entwicklern, Ergebnisse über die allgemeine Benutzeroberfläche für die globale Suche bereitzustellen.

• Implementierungen von Android-Geräten SOLLTEN die globale Suche umfassen. Dabei handelt es sich um eine einzige, gemeinsam genutzte, systemweite Suchoberfläche, die in Echtzeit Vorschläge als Reaktion auf Nutzereingaben erhalten kann.

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

• [C-1-1] MÜSSEN die APIs implementieren, die es Drittanbieteranwendungen erlauben, dem Suchfeld Vorschläge hinzuzufügen, wenn es im globalen Suchmodus ausgeführt wird.

Wenn keine Anwendungen von Drittanbietern installiert sind, die die globale Suche verwenden:

• Das Standardverhalten sollte sein, dass Ergebnisse und Vorschläge von Suchmaschinen angezeigt werden.

Android umfasst auch die Assist APIs, über die Apps festlegen können, wie viele Informationen des aktuellen Kontextes mit dem Assistenten auf dem Gerät geteilt werden.

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

• [C-2-1] MÜSSEN Endnutzer deutlich darauf hinweisen, wenn der Kontext auf eine der folgenden Arten geteilt wird:
  • Jedes Mal, wenn die Assistent-App auf den Kontext zugreift, wird ein weißes Licht am Bildschirmrand angezeigt, das der Dauer und Helligkeit der Android Open Source Project-Implementierung entspricht oder diese überschreitet.
  • Die vorinstallierte Assistent-App bietet dem Nutzer weniger als zwei Navigationsoptionen vom standardmäßigen Einstellungsmenü für Spracheingabe und Assistant-App entfernt. Der Kontext wird nur weitergegeben, wenn der Nutzer die Assistent-App explizit über ein Hotword oder die Eingabe der Navigationstaste für die Unterstützung aufrufen kann.
• [C-2-2] Die vorgesehene Interaktion zum Starten der Assist-App, wie in Abschnitt 7.2.3 beschrieben, MÜSSEN die vom Nutzer ausgewählte Assistent-App starten, also die App, die VoiceInteractionService implementiert, oder eine Aktivität, die den Intent ACTION_ASSIST verarbeitet.

3.8.5 Benachrichtigungen und Toasts

Anwendungen können die Toast API verwenden, um dem Endnutzer kurze nicht modale Strings anzuzeigen, die nach kurzer Zeit ausgeblendet werden. Mit der TYPE_APPLICATION_OVERLAY-Fenstertyp-API können Sie Benachrichtigungsfenster als Overlay über anderen Apps einblenden.

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

• [C-1-1] MÜSSEN eine App anbieten, die verhindert, dass Warnfenster angezeigt werden, in denen TYPE_APPLICATION_OVERLAY verwendet wird . Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente in der Benachrichtigungsleiste.

• [C-1-2] MÜSSEN die Toast API berücksichtigen und Endnutzern in gut sichtbarer Weise Toasts von Anwendungen anzeigen.

3.8.6. Designs

Android bietet „Designs“, mit denen Apps Stile auf eine gesamte Aktivität oder App anwenden können.

Android umfasst die Designfamilie „Holo“ und „Material“ als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie dem Design von Holo gemäß der Definition im Android SDK entsprechen möchten.

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

• [C-1-1] DÜRFEN KEINE der Holo-Designattribute verändern, die Anwendungen zur Verfügung stehen.
• [C-1-2] MUSS die Designfamilie "Material" unterstützen und DÜRFEN KEINE Attribute des Materials oder deren Assets ändern, die in Anwendungen sichtbar sind.

Android umfasst auch eine „Gerätestandard“-Designfamilie als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Erscheinungsbild des Gerätedesigns anpassen möchten, das vom Geräte-Implementierer definiert wurde.

• Bei Geräteimplementierungen KÖNNEN die Attribute für Gerätestandarddesigns, die Apps zur Verfügung stehen, geändert werden.

Android unterstützt ein Variantendesign mit durchscheinenden Systemleisten, mit denen App-Entwickler den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten ausfüllen können. Damit Entwickler in dieser Konfiguration einheitlich arbeiten können, ist es wichtig, dass das Symbol der Statusleiste bei verschiedenen Geräteimplementierungen beibehalten wird.

Wenn Geräteimplementierungen eine Systemstatusleiste enthalten, gilt Folgendes:

• [C-2-1] MUSS Weiß für Systemstatussymbole (z. B. Signalstärke und Akkustand) und vom System ausgegebene Benachrichtigungen verwenden, es sei denn, das Symbol zeigt einen problematischen Status an oder eine App fordert mit der Markierung SYSTEM_UI_FLAG_LIGHT_STATUS_BAR eine Lichtstatusleiste an.
• [C-2-2] Bei Implementierungen von Android-Geräten MÜSSEN die Farbe der Systemstatussymbole zu Schwarz ändern (weitere Informationen finden Sie unter R.style), wenn eine App eine helle Statusleiste anfordert.

3.8.7 Live-Hintergründe

Android definiert einen Komponententyp sowie eine entsprechende API und einen entsprechenden Lebenszyklus, die es Anwendungen ermöglichen, einem oder mehreren Live-Hintergründen für Endnutzer verfügbar zu sein. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabemöglichkeiten, die als Hintergrund hinter anderen Anwendungen angezeigt werden.

Hardware gilt als in der Lage, Live-Hintergründe zuverlässig auszuführen, wenn sie alle Live-Hintergründe ohne Einschränkung der Funktionalität mit einer angemessenen Framerate und ohne negative Auswirkungen auf andere Anwendungen ausführen kann. Wenn Einschränkungen in der Hardware dazu führen, dass Hintergründe und/oder Anwendungen abstürzen, nicht richtig funktionieren, übermäßige CPU- oder Akkuleistung verbraucht wird oder mit inakzeptablen niedrigen Frame-Rates ausgeführt wird, wird davon ausgegangen, dass die Hardware keinen Live-Hintergrund ausführen kann. So können beispielsweise einige Live-Hintergründe zum Rendern ihrer Inhalte möglicherweise den OpenGL 2.0- oder 3.x-Kontext verwenden. Live-Hintergrund funktioniert nicht zuverlässig auf Hardware, die nicht mehrere OpenGL-Kontexte unterstützt, da die Verwendung eines OpenGL-Kontexts mit anderen Anwendungen in Konflikt stehen kann, die ebenfalls einen OpenGL-Kontext verwenden.

• In Geräteimplementierungen, in denen Live-Hintergründe wie oben beschrieben zuverlässig ausgeführt werden können, SOLLTEN Live-Hintergründe implementiert werden.

Wenn Live-Hintergründe auf Geräten implementiert sind, gilt Folgendes:

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

3.8.8. Wechseln zwischen Aktivitäten

Der vorgelagerte Android-Quellcode umfasst den Übersichtsbildschirm, eine Benutzeroberfläche auf Systemebene zum Wechseln zwischen Aufgaben und zur Anzeige der zuletzt aufgerufenen Aktivitäten und Aufgaben. Dabei wird eine Miniaturansicht der grafischen Darstellung der App zum Zeitpunkt des letzten Verlassens der App angezeigt.

Bei Geräteimplementierungen, einschließlich der Navigationstaste für die Funktion „Zuletzt verwendet“, wie in Abschnitt 7.2.3 beschrieben, KANN die Benutzeroberfläche verändert werden.

Wenn Geräteimplementierungen, die die Navigationstaste für die Funktion „Kürzlich verwendet“ wie in Abschnitt 7.2.3 beschrieben, geändert haben, geschieht Folgendes:

• [C-1-1] MUSS mindestens bis zu sieben angezeigte Aktivitäten unterstützen.
• SOLLTE mindestens den Titel von vier Aktivitäten gleichzeitig anzeigen.
• [C-1-2] MÜSSEN die Funktion zur Bildschirmfixierung implementieren und dem Nutzer ein Einstellungsmenü zur Ein/Aus-Schaltfläche für die Funktion zur Verfügung stellen.
• SOLLTEN unter „Letzte“ die Farbe, das Symbol und den Bildschirmtitel hervorheben.
• SOLLTE ein abschließendes Angebot („x“) angezeigt werden, aber KANN die Anzeige verzögern, bis der Nutzer mit den Bildschirmen interagiert.
• SOLLTEN Sie eine Verknüpfung implementieren, um einfach zur vorherigen Aktivität zu wechseln.
• SOLLTEN Sie den schnellen Wechsel zwischen den beiden zuletzt verwendeten Apps auslösen, wenn zweimal auf die Taste „Zuletzt verwendet“ getippt wird.
• SOLLTE den Splitscreen-Mehrfenstermodus (falls unterstützt) auslösen, wenn die Taste „Recents“ (Zuletzt verwendet) gedrückt wird.
• KANN verbundene zuletzt verwendete Elemente als Gruppe angezeigt werden, die zusammen verschoben wird.
• [SR] wird dringend empfohlen, für den Übersichtsbildschirm die vorgelagerte Android-Benutzeroberfläche (oder eine ähnliche, Miniaturbildbasierte Oberfläche) zu verwenden.

3.8.9. Eingabeverwaltung

Android unterstützt Input Management und Eingabemethodeneditoren von Drittanbietern.

Wenn Nutzer bei der Geräteimplementierung Eingabemethoden von Drittanbietern auf dem Gerät verwenden können, gilt Folgendes:

• [C-1-1] MÜSSEN die Plattformfunktion android.software.input_methods und die Unterstützung von IME APIs gemäß der Definition in der Android SDK-Dokumentation angeben.
• [C-1-2] MÜSSEN einen für Nutzer zugänglichen Mechanismus bereitstellen, mit dem Eingabemethoden von Drittanbietern als Reaktion auf den Intent android.settings.INPUT_METHOD_SETTINGS hinzugefügt und konfiguriert werden können.

Wenn in Geräteimplementierungen das Funktions-Flag android.software.autofill deklariert ist, gilt Folgendes:

• [C-2-1] MÜSSEN die AutofillService und AutofillManager APIs vollständig implementieren und dem android.settings.REQUEST_SET_AUTOFILL_SERVICE-Intent folgen, um ein Standardmenü für App-Einstellungen zum Aktivieren und Deaktivieren von Autofill anzuzeigen und den standardmäßigen Autofill-Service für den Nutzer zu ändern.

3.8.10 Mediensteuerung auf dem Sperrbildschirm

Die Remote Control Client API wird von Android 5.0 durch die Media Notification Template ersetzt, mit der Medien-Apps in die Wiedergabesteuerung auf dem Sperrbildschirm integriert werden können.

3.8.11 Bildschirmschoner (früher „Dreams“)

Android unterstützt interaktive Bildschirmschoner, die zuvor als Dreams bezeichnet wurden. Mit Bildschirmschonern können Nutzer mit Apps interagieren, wenn ein an eine Stromquelle angeschlossenes Gerät inaktiv ist oder in einem Dock angedockt ist. Android Watch-Geräte KÖNNEN Bildschirmschoner implementieren. Andere Arten von Geräteimplementierungen SOLLTEN jedoch Bildschirmschoner unterstützen und Nutzern eine Option zur Konfiguration von Bildschirmschonern als Reaktion auf den Intent android.settings.DREAM_SETTINGS bieten.

3.8.12. Standort

Wenn die Geräteimplementierung einen Hardwaresensor (z.B. GPS) zur Bereitstellung der Standortkoordinaten umfasst, werden

• [C-1-2] MÜSSEN den aktuellen Status des Standorts im Menü "Standort" in den Einstellungen anzeigen.
• [C-1-3] DÜRFEN KEINE Standortmodi im Menü "Standort" in den Einstellungen angezeigt werden.

3.8.13. Unicode und Schriftart

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

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

• [C-1-1] MUSS diese Emoji-Zeichen in Farbglyphen rendern können.
• [C-1-2] MUSS Folgendes unterstützen:
  • Roboto 2-Schriftart mit unterschiedlichen Schriftstärken: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, Sans Serif-kondensierte, Sans Serif-Kondensat-Light-Light.
  • Vollständige Unicode 7.0-Abdeckung für lateinische, griechische und kyrillische Sprachen, einschließlich der erweiterten lateinischen Bereiche A, B, C und D sowie aller Glyphen im Währungssymbolblock von Unicode 7.0.
• SOLLTEN den Hautton und verschiedene Familien-Emojis gemäß Unicode Technical Report Nr. 51 unterstützen.

Wenn Geräteimplementierungen einen IME enthalten, gilt Folgendes:

• SOLLTE dem Nutzer eine Eingabemethode für diese Emoji-Zeichen zur Verfügung stellen.

3.8.14. Mehrere Fenster

Wenn Geräteimplementierungen die Möglichkeit haben, mehrere Aktivitäten gleichzeitig anzuzeigen, gilt Folgendes:

• [C-1-1] MÜSSEN diese Mehrfenstermodi gemäß dem Anwendungsverhalten und den APIs, die in der Dokumentation zur Unterstützung des Mehrfenstermodus des Android SDK beschrieben sind, implementieren und die folgenden Anforderungen erfüllen:
• [C-1-2] Anwendungen können angeben, ob sie in der Datei AndroidManifest.xml im Mehrfenstermodus arbeiten können. Dies kann entweder explizit durch Festlegen des Attributs android:resizeableActivity auf true oder implizit durch Festlegen des Werts für targetSdkVersion > 24 erfolgen. Apps, bei denen dieses Attribut in ihrem Manifest explizit auf false festgelegt ist, DÜRFEN NICHT im Mehrfenstermodus gestartet werden. Ältere Apps mit targetSdkVersion < 24, für die dieses Attribut „android:resizeableActivity“ nicht festgelegt wurde, KÖNNEN im Mehrfenstermodus gestartet werden. Das System MÜSSEN jedoch darauf hinweisen, dass die App im Mehrfenstermodus möglicherweise nicht wie erwartet funktioniert.
• [C-1-3] DÜRFEN KEINEN Splitscreen- oder Freeform-Modus anbieten, wenn die Bildschirmhöhe < 440 dp und die Bildschirmbreite unter 440 dp beträgt.
• 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] MÜSSEN einen in der Größe anpassbaren Launcher vorab als Standard laden.
• [C-2-2] MÜSSEN die angedockte Aktivität eines Mehrfenstermodus mit geteiltem Bildschirm zuschneiden, SOLLTE aber einige Inhalte des Bildschirms anzeigen, wenn die Launcher-App das Fenster im Fokus ist.
• [C-2-3] MÜSSEN die deklarierten Werte AndroidManifestLayout_minWidth und AndroidManifestLayout_minHeight der Drittanbieter-Launcher-App berücksichtigen und dürfen 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] MÜSSEN Aktivitäten im Mehrfenstermodus „Bild im Bild“ gestartet werden, wenn die App: * auf API-Level 26 oder höher ausgerichtet ist und android:supportsPictureInPicture * auf API-Level 25 oder niedriger ausgerichtet ist und sowohl android:resizeableActivity als auch android:supportsPictureInPicture deklariert.
• [C-3-2] MÜSSEN die Aktionen in der System-UI gemäß der aktuellen PIP-Aktivität über die setActions() API anzeigen.
• [C-3-3] MUSS Seitenverhältnisse größer oder gleich 1:2,39 und kleiner oder gleich 2,39:1 unterstützen, wie in der PIP-Aktivität über die setAspectRatio() API angegeben.
• [C-3-4] MÜSSEN das PIP-Fenster mit KeyEvent.KEYCODE_WINDOW steuern. Wenn der BiB-Modus nicht implementiert ist, MUSS der Schlüssel für die Vordergrundaktivität verfügbar sein.
• [C-3-5] MÜSSEN eine App an der Anzeige im BiB-Modus hindern. Die AOSP-Implementierung erfüllt diese Anforderung durch Steuerelemente in der Benachrichtigungsleiste.
• [C-3-6] MÜSSEN eine minimale Breite und Höhe von 108 dp für das BiB-Fenster und eine Mindestbreite von 240 dp und eine Höhe von 135 dp für das BiB-Fenster zugewiesen werden, wenn Configuration.uiMode als UI_MODE_TYPE_TELEVISION konfiguriert ist.

3.8.15. Display-Aussparung

Android unterstützt eine Display-Aussparung, wie im SDK-Dokument beschrieben. Die DisplayCutout API definiert einen Bereich am Rand des Displays, in dem keine Inhalte angezeigt werden können.

Wenn Geräteimplementierungen Display-Aussparungen enthalten, gilt Folgendes:

• [C-1-1] DÜRFEN nur Aussparungen an den kurzen Kanten des Geräts haben. Beträgt das Seitenverhältnis jedoch 1, 0 (1:1), DÜRFEN es KEINE Aussparungen haben.
• [C-1-2] DÜRFEN NICHT mehr als eine Aussparung pro Rand haben.
• [C-1-3] MÜSSEN die von der App über die WindowManager.LayoutParams API festgelegten Flags für Display-Aussparungen berücksichtigen, wie im SDK beschrieben.
• [C-1-4] MÜSSEN korrekte Werte für alle Messwerte für Aussparungen melden, die in der DisplayCutout API definiert sind.

3.9. Geräteverwaltung

Android umfasst Funktionen, mit denen sicherheitsbewusste Apps über die Android Device Administration API Geräteverwaltungsfunktionen auf Systemebene ausführen können. So können beispielsweise Passwortrichtlinien erzwungen oder Daten aus der Ferne gelöscht werden.

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

• [C-1-1] MUSS android.software.device_admin deklarieren.
• [C-1-2] MUSS die Nutzerverwaltung für Geräte unterstützen, wie in Abschnitt 3.9.1 und Abschnitt 3.9.1.1 beschrieben.

3.9.1 Gerätebereitstellung

3.9.1.1 Nutzerverwaltung für Geräteinhaber

Wenn in Geräteimplementierungen android.software.device_admin deklariert wird, gilt Folgendes:

• [C-1-1] MUSS die Registrierung eines Device Policy-Clients (DPC) als Device Owner-App wie unten beschrieben unterstützen:
  • Wenn in der Geräteimplementierung noch keine Nutzerdaten konfiguriert sind, geschieht Folgendes:
    • [C-1-3] MÜSSEN true für DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) melden.
    • [C-1-4] MÜSSEN die DPC-Anwendung als Reaktion auf die Intent-Aktion android.app.action.PROVISION_MANAGED_DEVICE als Geräteinhaber-App registrieren.
    • [C-1-5] MÜSSEN die DPC-Anwendung als Geräteeigentümer-App registrieren, wenn das Gerät NFC-Unterstützung (Nahfeldkommunikation) über das Funktions-Flag android.hardware.nfc deklariert und eine NFC-Nachricht mit einem Eintrag vom MIME-Typ MIME_TYPE_PROVISIONING_NFC erhält.
  • Wenn die Geräteimplementierung Nutzerdaten enthält, geschieht Folgendes:
    • [C-1-6] MÜSSEN false für DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) melden.
    • [C-1-7] DARF keine DPC-Anwendung mehr als Geräteinhaber-App registrieren.
• [C-1-2] MUSS während des Bereitstellungsprozesses eine Bestätigung erforderlich machen, damit die App als Geräteinhaber festgelegt werden kann. Die Einwilligung kann über eine Nutzeraktion oder programmatisch während der Bereitstellung erfolgen. Sie DARF aber NICHT hartcodiert werden oder die Verwendung anderer Geräteinhaber-Apps verhindern.

Wenn in Geräteimplementierungen android.software.device_admin deklariert wird, aber auch eine proprietäre Lösung für die Verwaltung von Geräteinhabern enthalten ist und dass eine in der Lösung konfigurierte App als „Geräteinhaber-Äquivalent“ zum standardmäßigen „Geräteinhaber“ hochgestuft wird, der von den standardmäßigen DevicePolicyManager APIs von Android erkannt wird, geschieht Folgendes:

• [C-2-1] MÜSSEN über ein Verfahren verfügen, mit dem geprüft wird, ob die beworbene App zu einer legitimen Geräteverwaltungslösung für Unternehmen gehört. Außerdem muss sie in der proprietären Lösung so konfiguriert sein, dass die entsprechenden Rechte als „Geräteinhaber“ festgelegt sind.
• [C-2-2] MÜSSEN dieselbe Offenlegung zur Einwilligung des AOSP-Geräteinhabers anzeigen wie in dem von android.app.action.PROVISION_MANAGED_DEVICE initiierten Ablauf, bevor die DPC-Anwendung als „Geräteinhaber“ registriert wird.
• MÖGLICHERWEISE haben Nutzerdaten auf dem Gerät, bevor die DPC-Anwendung als "Geräteinhaber" registriert wurde.

3.9.1.2 Verwaltete Bereitstellung von Profilen

Wenn in Geräteimplementierungen android.software.managed_users deklariert wird, gilt Folgendes:

• [C-1-1] MÜSSEN die APIs implementieren, die es einer DPC-Anwendung ermöglichen, Inhaber eines neuen verwalteten Profils zu werden.

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

• [C-1-3] MÜSSEN die folgenden Nutzereigenschaften in den Einstellungen zur Verfügung stellen, um dem Nutzer anzuzeigen, wenn eine bestimmte Systemfunktion durch den Device Policy Controller (DPC) deaktiviert wurde:

  • Ein einheitliches Symbol oder ein anderes Nutzerangebot (z. B. das vorgelagerte AOSP-Infosymbol), das angibt, wann eine bestimmte Einstellung von einem Geräteadministrator eingeschränkt wird.
  • Eine kurze Erklärung, die der Device Admin über das setShortSupportMessage bereitstellt.
  • Das Symbol der DPC-Anwendung.

3.9.2 Unterstützung für verwaltete Profile

Wenn in Geräteimplementierungen android.software.managed_users deklariert wird, gilt Folgendes:

• [C-1-1] MUSS verwaltete Profile über die android.app.admin.DevicePolicyManager APIs unterstützen.
• [C-1-2] MUSS die Erstellung nur eines einzigen verwalteten Profils zulassen.
• [C-1-3] MUSS ein Symbol verwenden (ähnlich dem AOSP-Upstream-Logo), um verwaltete Anwendungen und Widgets und andere Badge-UI-Elemente wie „Letzte“ und „Benachrichtigungen“ zu repräsentieren.
• [C-1-4] MÜSSEN ein Benachrichtigungssymbol anzeigen (ähnlich dem AOSP-Upstream-Arbeitsabzeichen), das darauf hinweist, dass sich der Nutzer in einer Anwendung mit verwaltetem Profil befindet.
• [C-1-5] MÜSSEN Sie darauf hinweisen, dass sich der Nutzer im verwalteten Profil befindet, wenn das Gerät aktiviert wird (ACTION_USER_PRESENT) und sich die Anwendung im Vordergrund im verwalteten Profil befindet.
• [C-1-6] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN Sie im Intent-Auswahlfenster eine visuelle Darstellung anzeigen, damit der Nutzer den Intent vom verwalteten Profil an den primären Nutzer weiterleiten kann oder umgekehrt, sofern er vom Device Policy Controller aktiviert wurde.
• [C-1-7] Wenn ein verwaltetes Profil vorhanden ist, MÜSSEN die folgenden Nutzereigenschaften sowohl für den primären Nutzer als auch für das verwaltete Profil angezeigt werden:
  • Separate Abrechnung von Akku, Standort, mobiler Daten und Speichernutzung für den Hauptnutzer und das verwaltete Profil.
  • Unabhängige Verwaltung von VPN-Anwendungen, die im primären Nutzer oder verwalteten Profil installiert sind
  • Unabhängige Verwaltung von Anwendungen, die im primären Nutzer oder im verwalteten Profil installiert sind
  • Unabhängige Verwaltung von Konten innerhalb des primären Nutzers oder des verwalteten Profils
• [C-1-8] MÜSSEN sicherstellen, dass die vorinstallierten Telefon-, Kontakt- und Messaging-Anwendungen Anruferinformationen im verwalteten Profil (sofern vorhanden) neben denen aus dem primären Profil suchen und nachschlagen können, wenn der Device Policy Controller dies zulässt.
• [C-1-9] MUSS alle Sicherheitsanforderungen erfüllen, die für ein Gerät mit mehreren aktivierten Nutzern gelten (siehe Abschnitt 9.5), auch wenn das verwaltete Profil nicht zusätzlich zum Hauptnutzer als weiterer Nutzer gezählt wird.
• [C-1-10] MÜSSEN die Möglichkeit bieten, 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 Schnittstelle zum Konfigurieren separater Anmeldedaten für den Sperrbildschirm für das verwaltete Profil anzeigen.
  • Für die Sperrbildschirm-Anmeldedaten des verwalteten Profils MÜSSEN dieselben Mechanismen zum Speichern und Verwalten von Anmeldedaten wie beim übergeordneten Profil verwendet werden. Näheres hierzu finden Sie auf der Website des Android-Open-Source-Projekts.
  • Die DPC-Passwortrichtlinien MÜSSEN nur für die Sperrbildschirm-Anmeldedaten des verwalteten Profils gelten, es sei denn, sie werden über die DevicePolicyManager-Instanz aufgerufen, die von getParentProfileInstance zurückgegeben wird.
• Wenn Kontakte aus dem verwalteten Profil in der vorinstallierten Anrufliste, auf der Benutzeroberfläche für laufende Anrufe, in Benachrichtigungen über laufende und verpasste Anrufe, Kontakte und Messaging-Apps angezeigt werden, SOLLTEN sie mit demselben Kennzeichen versehen sein, das für die Anwendungen des verwalteten Profils verwendet wird.

3.9.3 Support für verwaltete Nutzer

Wenn in Geräteimplementierungen android.software.managed_users deklariert wird, gilt Folgendes:

• [C-1-1] MÜSSEN Nutzern die Möglichkeit bieten, sich vom aktuellen Nutzer abzumelden und in einer Sitzung mit mehreren Nutzern zum primären Nutzer zurückzuwechseln, wenn isLogoutEnabled den Wert true zurückgibt. Das Angebot MUSS vom Sperrbildschirm aus zugänglich sein, ohne das Gerät zu entsperren.

3:10. Bedienungshilfen

Android bietet eine Ebene der Bedienungshilfen, über die Nutzer mit Behinderungen ihre Geräte einfacher bedienen können. Darüber hinaus bietet Android Plattform-APIs, die Implementierungen von Bedienungshilfen ermöglichen, Rückrufe für Nutzer- und Systemereignisse zu empfangen und alternative Feedback-Mechanismen wie Sprachausgabe, haptisches Feedback und Trackball-/Steuerkreuz-Navigation zu generieren.

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

• [C-1-1] MÜSSEN eine Implementierung des Android-Frameworks für Barrierefreiheit im Internet zur Verfügung stellen, wie in der SDK-Dokumentation für die Accessibility APIs beschrieben.
• [C-1-2] MÜSSEN Ereignisse für Bedienungshilfen generieren und die entsprechende AccessibilityEvent an alle registrierten AccessibilityService-Implementierungen übergeben, wie im SDK dokumentiert.
• [C-1-3] MÜSSEN dem android.settings.ACCESSIBILITY_SETTINGS-Intent zustimmen, einen für Nutzer zugänglichen Mechanismus bereitzustellen, mit dem die Bedienungshilfen von Drittanbietern neben den vorinstallierten Bedienungshilfen aktiviert und deaktiviert werden können.
• [C-1-4] MÜSSEN eine Schaltfläche in der Navigationsleiste des Systems hinzufügen, mit der der Nutzer die Bedienungshilfe steuern kann, wenn die aktivierten Bedienungshilfen die AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON deklarieren . Beachten Sie, dass diese Anforderung für Geräteimplementierungen ohne Systemnavigationsleiste nicht zutrifft. Geräteimplementierungen SOLLTEN jedoch den Nutzern die Möglichkeit bieten, diese Bedienungshilfen zu steuern.

Wenn Geräteimplementierungen vorinstallierte Bedienungshilfen enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN diese vorinstallierten Bedienungshilfen als Direct Boot Aware-Apps implementieren, wenn der Datenspeicher durch File-Based Encryption (FBE) verschlüsselt ist.
• SOLLTEN in der vorkonfigurierten Einrichtung einen Mechanismus enthalten, mit dem Nutzer relevante Bedienungshilfen aktivieren können, sowie Optionen zum Anpassen der Schriftgröße, der Anzeigegröße und der Vergrößerungsbewegungen.

3:11. Sprachausgabe

Android umfasst APIs, mit denen Anwendungen die Sprachausgabedienste nutzen können. Außerdem können Dienstanbieter Implementierungen von Text-in-Sprache-Diensten zur Verfügung stellen.

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

• [C-1-1] MÜSSEN die Android TTS Framework-APIs unterstützen.

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

• [C-2-1] MÜSSEN Nutzern die Möglichkeit bieten, eine Text-in-Sprache-Engine für die Verwendung auf Systemebene auszuwählen.

3:12. TV-Eingabe-Framework

Das Android Television Input Framework (TIF) vereinfacht die Übertragung von Live-Inhalten auf Android Television-Geräten. TIF stellt eine Standard-API zum Erstellen von Eingabemodulen zur Steuerung von Android TV-Geräten bereit.

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

• [C-1-1] MÜSSEN die Plattformfunktion android.software.live_tv deklarieren.
• [C-1-2] MÜSSEN alle TIF APIs so unterstützen, dass eine Anwendung, die diese APIs und den TIF-basierten Eingabedienst eines Drittanbieters 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 Schnelleinstellungen enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN Nutzer die über die quicksettings APIs bereitgestellten Kacheln in einer Drittanbieter-App hinzufügen oder entfernen können.
• [C-1-2] DÜRFEN NICHT automatisch eine Kachel aus einer Drittanbieter-App direkt zu den Schnelleinstellungen hinzufügen.
• [C-1-3] MÜSSEN alle vom Nutzer hinzugefügten Kacheln aus Drittanbieter-Apps zusammen mit den vom System bereitgestellten Kacheln für die Schnelleinstellungen angezeigt werden.

3:14. Medien-UI

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

• [C-1-1] MÜSSEN die MediaItem- und Benachrichtigungssymbole unverändert anzeigen.
• [C-1-2] MÜSSEN diese Elemente wie von MediaSession beschrieben anzeigen, z.B. Metadaten, Symbole, Bilder.
• [C-1-3] MÜSSEN den App-Titel anzeigen.
• [C-1-4] MÜSSEN über eine Leiste oder einen anderen Mechanismus verfügen, um die MediaBrowser-Hierarchie und Nutzerangebote für die MediaBrowser-Hierarchie darzustellen.
• [C-1-5] MUSS doppelt auf KEYCODE_HEADSETHOOK oder KEYCODE_MEDIA_PLAY_PAUSE als KEYCODE_MEDIA_NEXT für MediaSession.Callback#onMediaButtonEvent doppeltippen.

3:15. Android Instant Apps

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

• [C-0-1] Instant Apps DÜRFEN nur Berechtigungen erhalten, bei denen 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 enthält CATEGORY_BROWSABLE
  • Es handelt sich um eine der folgenden Aktionen: ACTION_SEND, ACTION_SENDTO oder ACTION_SEND_MULTIPLE
  • Das Ziel wird explizit mit android:visibleToInstantApps bereitgestellt.
• [C-0-3] Instant Apps DÜRFEN NICHT explizit mit installierten Apps interagieren, es sei denn, die Komponente wird über android:visibleToInstantApps bereitgestellt.
• [C-0-4] Installierte Apps DÜRFEN KEINE Details zu Instant Apps auf dem Gerät sehen, es sei denn, die Instant App stellt ausdrücklich eine Verbindung zur installierten App her.

3:16. Begleitgerät koppeln

Android unterstützt das Koppeln von Begleitgeräten, um die Verknüpfung mit Begleitgeräten effektiver zu verwalten, und bietet die CompanionDeviceManager API für Apps, die auf diese Funktion zugreifen können.

Wenn Geräteimplementierungen die Kopplungsfunktion von Begleitgeräten unterstützen, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag FEATURE_COMPANION_DEVICE_SETUP deklarieren .
• [C-1-2] MÜSSEN darauf achten, dass die APIs im Paket android.companion vollständig implementiert sind.
• [C-1-3] MÜSSEN Nutzern Angebote zur Verfügung stellen, damit sie auswählen/bestätigen können, dass ein Begleitgerät vorhanden und betriebsbereit ist.

3:17. Komplexe Apps

Wenn die Funktion FEATURE_CANT_SAVE_STATE in Geräteimplementierungen deklariert ist, gilt Folgendes:

• [C-1-1] MUSS immer nur eine App im System installiert haben, in der cantSaveState angegeben ist. Wenn der Nutzer eine solche App verlässt, ohne sie explizit zu beenden (z. B. durch Drücken der Startbildschirmtaste beim Verlassen einer aktiven Aktivität, anstatt auf die Schaltfläche „Zurück“ zu drücken, wenn keine aktiven Aktivitäten im System vorhanden sind), MÜSSEN Geräteimplementierungen diese App im RAM priorisieren, so wie für andere Dinge, die weiterhin ausgeführt werden sollen, z. B. Dienste im Vordergrund. Solange eine solche App im Hintergrund ausgeführt wird, kann das System trotzdem Energieverwaltungsfunktionen darauf anwenden, z. B. die Begrenzung des CPU- und Netzwerkzugriffs.
• [C-1-2] MÜSSEN eine UI-Option zur Auswahl der App zur Verfügung stellen, die nicht am Mechanismus zum Speichern/Wiederherstellen des normalen Status verwendet wird, sobald der Nutzer eine zweite App startet, die mit dem Attribut cantSaveState deklariert ist.
• [C-1-3] DÜRFEN KEINE anderen Richtlinienänderungen auf Apps anwenden, in denen cantSaveState angegeben ist, z. B. Änderungen der CPU-Leistung oder der Zeitplanpriorität.

Wenn die Funktion FEATURE_CANT_SAVE_STATE in Geräteimplementierungen nicht deklariert wird, passiert Folgendes:

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

4. Kompatibilität der App-Paketerstellung

Implementierungen auf Geräten:

• [C-0-1] MÜSSEN in der Lage sein, Android-APK-Dateien zu installieren und auszuführen, die von dem im offiziellen Android SDK enthaltenen Tool "aapt" generiert wurden.
• Da die oben genannte Anforderung eine Herausforderung sein kann, wird bei Geräteimplementierungen EMPFOHLEN, das Paketverwaltungssystem der AOSP-Referenzimplementierung zu verwenden.

Geräteimplementierungen:

• [C-0-2] MUSS die Überprüfung von APK-Dateien mit dem APK Signature Scheme v3 , dem APK Signature Scheme v2 und der JAR-Signatur unterstützen.
• [C-0-3] DÜRFEN die Bytecode-Formate .apk, Android Manifest, Dalvik-Bytecode oder RenderScript NICHT so erweitern, dass diese Dateien nicht korrekt installiert und auf anderen kompatiblen Geräten ausgeführt werden können.

• [C-0-4] DÜRFEN nur dem aktuellen „Installer of Record“ für das Paket erlauben, die App im Hintergrund ohne Bestätigung durch den Nutzer zu deinstallieren, wie im SDK für die Berechtigung DELETE_PACKAGE dokumentiert. Die einzigen Ausnahmen sind die Systempaketprüfungs-App, die den Intent PACKAGE_NEEDS_VERIFICATION verarbeitet, und die Speichermanager-App, die den Intent ACTION_MANAGE_STORAGE verarbeitet.

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

• [C-0-6] DÜRFEN KEINE Anwendungspakete aus unbekannten Quellen installieren, es sei denn, die App, die die Installation anfordert, erfüllt die folgenden Anforderungen:

  • Sie MÜSSEN die Berechtigung REQUEST_INSTALL_PACKAGES deklarieren oder android:targetSdkVersion auf 24 oder niedriger festgelegt haben.
  • Der Nutzer MUSS die Berechtigung erhalten haben, Apps aus unbekannten Quellen zu installieren.

• SOLLTE Nutzern die Möglichkeit bieten, die Berechtigung zum Installieren von Apps aus unbekannten Quellen pro App zu gewähren/zu widerrufen. KANN dies jedoch als No-Op implementieren und RESULT_CANCELED für startActivityForResult() zurückgeben, wenn die Geräteimplementierung den Nutzern diese Auswahl nicht ermöglichen soll. Aber selbst in solchen Fällen SOLLTEN sie dem Nutzer mitteilen, warum die Auswahl nicht möglich ist.

• [C-0-7] MÜSSEN einen Warnhinweis mit dem Warnstring anzeigen, der dem Nutzer über die System-API PackageManager.setHarmfulAppWarning bereitgestellt wird, bevor eine Aktivität in einer Anwendung gestartet wird, die von derselben System-API PackageManager.setHarmfulAppWarning als potenziell schädlich markiert wurde.

• SOLLTEN im Warndialogfeld dem Nutzer die Möglichkeit gegeben werden, eine App zu deinstallieren oder zu starten.

5. Multimedia-Kompatibilität

Geräteimplementierungen:

• [C-0-1] MUSS für jeden von MediaCodecList deklarierten Codec die in Abschnitt 5.1 definierten Medienformate, Encoder, Decodierer, Dateitypen und Containerformate unterstützen.
• [C-0-2] MÜSSEN über MediaCodecList die Unterstützung von Encodern und Decodern, die für Drittanbieteranwendungen verfügbar sind, deklarieren und melden.
• [C-0-3] MÜSSEN in der Lage sein, alle Formate, die codiert werden können, zu decodieren und für Drittanbieter-Apps verfügbar zu machen. Dazu gehören alle von seinen Encodern generierten Bitstreams und die in der CamcorderProfile gemeldeten Profile.

Geräteimplementierungen:

• SOLLTE eine minimale Codec-Latenz anstreben, d. h.:
  • Eingabepuffer sollten NICHT verbraucht und gespeichert und nur nach der Verarbeitung zurückgegeben werden.
  • Decodierte Puffer sollten NICHT länger aufbewahrt werden, als vom Standard vorgegeben (z.B. SPS).
  • Sie sollten codierte Puffer NICHT länger aufbewahren, als von der GoP-Struktur vorgegeben.

Alle im folgenden Abschnitt aufgeführten Codecs sind Software-Implementierungen in der bevorzugten Android-Implementierung aus dem Android Open Source Project.

Weder Google noch die Open Handset Alliance machen Zusicherungen, dass diese Codecs frei von Patenten Dritter sind. Personen, die diesen Quellcode in Hardware- oder Softwareprodukten verwenden möchten, werden darauf hingewiesen, dass für Implementierungen dieses Codes, einschließlich in Open-Source-Software oder Shareware, möglicherweise Patentlizenzen von den entsprechenden Patentinhabern erforderlich sind.

5.1. Medien-Codecs

5.1.1 Audiocodierung

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

Wenn in Geräteimplementierungen android.hardware.microphone deklariert wird, MUSS die folgende Audiocodierung unterstützt werden:

• [C-1-1] PCM/WAVE

5.1.2 Audiodecodierung

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

Wenn in Geräteimplementierungen die Funktion „android.hardware.audio.output“ unterstützt wird, muss die Decodierung der folgenden Audioformate unterstützt werden:

• [C-1-1] MPEG-4 AAC Profile (AAC LC)
• [C-1-2] MPEG-4 HE AAC-Profil (AAC+)
• [C-1-3] MPEG-4 HE AACv2 Profile (erweitertes AAC+)
• [C-1-4] AAC ELD (Optimierte AAC mit niedriger Verzögerung)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, das das USAC Baseline Profile und ISO/IEC 23003-4 Dynamic Range Control Profile enthält)
• [C-1-5] FLAC
• [C-1-6] MP3-Datei
• [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 Mehrkanalstreams (d.h. mehr als zwei Kanälen) in PCM über den Standard-AAC-Audiodecoder in der android.media.MediaCodec API unterstützen, MÜSSEN Folgendes unterstützt werden:

• [C-2-1] Die Decodierung MUSS ohne Downmix durchgeführt werden (z.B. muss ein 5.0-AAC-Stream in fünf PCM-Kanäle decodiert werden, ein 5.1-AAC-Stream muss in sechs PCM-Kanäle decodiert werden).
• [C-2-2] Die Metadaten für den dynamischen Bereich MÜSSEN der Definition in „Dynamic Range Control (DRC)“ in ISO/IEC 14496-3 entsprechen und die DRC-Tasten von android.media.MediaFormat entsprechen, um das Verhalten des Audiodecoders in Bezug auf den dynamischen Bereich zu konfigurieren. 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.

Bei der Decodierung von USAC-Audio mit MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Lautstärke und DRC-Metadaten MÜSSEN gemäß MPEG-D DRC Dynamic Range Control Profile Level 1 interpretiert und angewendet werden.
• [C-3-2] Der Decoder MÜSSEN 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:

• KANN die Steuerung der Lautstärke und des dynamischen Bereichs mit dem Profil für die dynamische Bereichskontrolle gemäß ISO/IEC 23003-4 unterstützen.

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

• ISO/IEC 23003-4-Metadaten WERDEN Vorrang haben.

5.1.3 Details zu Audio-Codecs

Format/Codec	Details	Unterstützte Dateitypen/Containerformate
MPEG-4 AAC Profile (AAC LC)	Unterstützung für Mono-/Stereo-/5.0/5.1-Inhalte mit Standardabtastraten von 8 bis 48 kHz.	3GPP (3GP) MPEG-4 (MP4, M4A) ADTS-Roh-AAC (AAC, ADIF nicht unterstützt) MPEG-TS (.ts, nicht suchbar)
MPEG-4 HE AAC Profile (AAC+)	Unterstützung für Mono-/Stereo-/5.0/5.1-Inhalte mit Standardabtastraten von 16 bis 48 kHz.
MPEG-4 HE AACv2 Profile (erweitertes AAC+)	Unterstützung für Mono-/Stereo-/5.0/5.1-Inhalte mit Standardabtastraten von 16 bis 48 kHz.
AAC ELD (Optimierte AAC mit geringer Verzögerung)	Unterstützung für Mono-/Stereoinhalte mit Standardabtastraten von 16 bis 48 kHz.
Logo: USAC	Unterstützung für Mono-/Stereoinhalte mit Standardabtastraten von 7,35 bis 48 kHz.	MPEG-4 (MP4, M4A)
AMR-NB	4,75 bis 12,2 kbit/s, Stichproben bei 8 kHz	3GPP (3GP)
AMR-WB	9 Raten von 6,60 kbit/s bis 23,85 kbit/s, Stichproben bei 16 kHz
FLAC	Mono/Stereo (kein Multi-Channel). Abtastraten von bis zu 48 kHz (bei Geräten mit einer Ausgabe von 44,1 kHz werden jedoch bis zu 44,1 kHz empfohlen, da der Downsampler von 48 bis 44,1 kHz keinen Tiefpassfilter hat). 16-Bit EMPFOHLEN; bei 24-Bit wird kein Dither angewendet.	Nur FLAC (.flac)
MP3	Mono/Stereo, 8–320 Kbit/s konstant (CBR) oder variable Bitrate (VBR)	MP3 (.mp3)
MIDI	MIDI-Typ 0 und 1. DLS Version 1 und 2. XMF und XMF für Mobilgeräte Unterstützung der Klingeltonformate RTTTL/RTX, OTA und iMelody	Geben Sie 0 und 1 (.mid, .xmf, .mxmf) ein RTTTL/RTX (.rtttl, .rtx) Onlinereisebüro (OTA) iMelody (Imy)
Vorbis		OGG (OGG) Matroska (MKV, Android 4.0 und höher)
PCM/WAVE	Lineare 16-Bit-PCM (Raten bis zur Grenze der Hardware). Geräte MÜSSEN Abtastraten für PCM-Rohdaten bei Frequenzen von 8.000, 11.025, 1.6.000 und 4.4.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 Image-Codecs.

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

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

5.1.5 Bilddecodierung

Weitere Informationen finden Sie unter 5.1.6. Details zu Image-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 Image-Codecs

Format/Codec	Details	Unterstützte Dateitypen/Containerformate
JPEG	Base+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, Bildersammlung, Bildsequenz	HEIF (.heif), HEIC (.heic)

5.1.7. Video-Codecs

• Für eine akzeptable Qualität von Webvideostreamingdiensten und Videokonferenzen SOLLTEN Sie bei der Geräteimplementierung einen VP8-Hardware-Codec verwenden, der die Anforderungen erfüllt.

Wenn Geräteimplementierungen einen Videodecoder oder Encoder umfassen:

• [C-1-1] Video-Codecs MÜSSEN Ausgabe- und Eingabe-Bytebuffer-Größen unterstützen, die den größtmöglichen komprimierten und unkomprimierten Frame gemäß den Vorgaben des Standards und der Konfiguration unterstützen, aber auch nicht zu viel zuweisen.

• [C-1-2] Videoencoder und -decoder müssen das flexible Farbformat YUV420 unterstützen (COLOR_FormatYUV420Flexible).

Wenn Geräteimplementierungen den Support für HDR-Profile über Display.HdrCapabilities bewerben, geschieht Folgendes:

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

Wenn Geräteimplementierungen Support für Intra-Aktualisierungen über FEATURE_IntraRefresh in der Klasse MediaCodecInfo.CodecCapabilities bewerben, geschieht Folgendes:

• [C-3-1] MUSS die Aktualisierungszeiträume zwischen 10 und 60 Frames unterstützen und innerhalb von 20% des konfigurierten Aktualisierungszeitraums korrekt 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	Einzelheiten finden Sie in Abschnitten 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	Einzelheiten finden Sie in Abschnitten 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 Video-Encoder unterstützen und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• Über zwei gleitende Fenster NICHT mehr als ca. 15% über der Bitrate zwischen Intraframe-Intervallen (I-Frame) liegen
• NICHT mehr als ca. 100% über der Bitrate über ein gleitendes Fenster von 1 Sekunde liegen

Wenn Geräteimplementierungen einen eingebetteten Bildschirm mit einer diagonalen Länge von mindestens 2,5 Zoll, einen Videoausgabeanschluss oder die Unterstützung einer Kamera über das Funktions-Flag android.hardware.camera.any deklarieren, gilt Folgendes:

• [C-1-1] MÜSSEN mindestens einen VP8- oder H.264-Videoencoder unterstützen und für Drittanbieteranwendungen verfügbar machen.
• SOLLTEN sowohl VP8- als auch H.264-Videoencoder unterstützen und für Drittanbieteranwendungen verfügbar machen.

Wenn Geräteimplementierungen H.264-, VP8-, VP9- oder HEVC-Videoencoder unterstützen und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

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

Wenn Geräteimplementierungen den Videoencoder MPEG-4 SP unterstützen und für Drittanbieter-Apps verfügbar machen, geschieht Folgendes:

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

5.2.1 H.263

Wenn Geräteimplementierungen H.263-Encoder unterstützen und in Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS Baseline-Profilebene 45 unterstützen.
• SOLLTEN für den unterstützten Encoder dynamisch konfigurierbare Bitraten unterstützen.

5.2.2 H-264

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

• [C-1-1] MUSS Baseline-Profilebene 3 unterstützen. Die Unterstützung für ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (redundante Slices) ist jedoch OPTIONAL. Aus Gründen der Kompatibilität mit anderen Android-Geräten wird empfohlen, ASO, FMO und RS von Encodern nicht für das Baseline-Profil zu verwenden.
• [C-1-2] MÜSSEN die SD-Videocodierungsprofile (Standard Definition) in der folgenden Tabelle unterstützen.
• SOLLTEN die Hauptprofilebene 4 unterstützen.
• SOLLTEN die Videocodierungsprofile in HD (High Definition) unterstützen, wie in der folgenden Tabelle angegeben.

Wenn Geräteimplementierungen die Unterstützung der H.264-Codierung für Videos mit einer Auflösung von 720p oder 1080p über die Medien-APIs 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 x 240 px	720 x 480 Pixel	1280 x 720 px	1920 x 1080 px
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-Video-Codierungsprofile unterstützen.
• SOLLTEN die folgenden HD-Videocodierungsprofile (High Definition) unterstützen.
• SOLLTEN das Schreiben von Matroska WebM-Dateien unterstützen.
• SOLLTEN SIE einen VP8-Hardware-Codec verwenden, der die Anforderungen zur RTC-Hardwarecodierung des WebM-Projekts erfüllt, um eine akzeptable Qualität von Webvideostreaming- und Videokonferenzen sicherzustellen.

Wenn Geräteimplementierungen die Unterstützung der VP8-Codierung für Videos mit einer Auflösung von 720p oder 1080p über die Medien-APIs 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 x 180 Pixel	640 x 360 Pixel	1280 x 720 px	1920 x 1080 px
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:

• SOLLTEN 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] MÜSSEN die dynamische Videoauflösung und Framerate-Wechsel durch die standardmäßigen Android-APIs innerhalb eines 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 in Geräteimplementierungen die Unterstützung des Dolby Vision-Decoders über HDR_TYPE_DOLBY_VISION deklariert wird , gilt Folgendes:

• [C-2-1] MÜSSEN einen Dolby Vision-fähigen Extraktor bereitstellen.
• [C-2-2] MÜSSEN Dolby Vision-Inhalte auf dem Gerätebildschirm oder an einem Standard-Videoausgangsanschluss (z.B. HDMI).
• [C-2-3] MÜSSEN den Trackindex der abwärtskompatiblen Basisebenen (falls vorhanden) so einstellen, dass er mit dem Trackindex der kombinierten Dolby Vision-Ebene übereinstimmt.

5.3.1 MPEG-2

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

• [C-1-1] MUSS die allgemeine Ebene "Hauptprofil" unterstützen.

5.3.2 H.263

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

• [C-1-1] MÜSSEN Baseline-Profillevel 30 und -Level 45 unterstützen.

5.3.3 MPEG-4

Bei Geräteimplementierungen mit MPEG-4-Decodierern gilt Folgendes:

• [C-1-1] MÜSSEN die einfache Profilebene 3 unterstützen.

5.3.4. H.264

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

• [C-1-1] MÜSSEN die Hauptprofilebene 3.1 und das Basisprofil unterstützen. Die Unterstützung für ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (redundante Slices) ist OPTIONAL.
• [C-1-2] MÜSSEN Videos mit den in der folgenden Tabelle aufgeführten SD-Profilen (Standard Definition) decodieren können und mit dem Basisprofil und dem Hauptprofil der Ebene 3.1 (einschließlich 720p30) codiert sein.
• SOLLTEN in der Lage sein, Videos mit HD-Profilen (High Definition) zu decodieren, wie in der folgenden Tabelle angegeben.

Wenn die von der Methode Display.getSupportedModes() gemeldete Höhe der Videoauflösung entspricht oder größer ist, wird auf dem Gerät Folgendes implementiert:

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

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 x 240 px	720 x 480 Pixel	1280 x 720 px	1920 x 1080 px
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] MÜSSEN die Hauptprofilebene 3 der Hauptstufe und die SD-Video-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
• SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
• [C-1-2] MUSS die HD-Decodierungsprofile wie in der folgenden Tabelle angegeben unterstützen, wenn es einen Hardware-Decodierer gibt.

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

• [C-2-1] Geräteimplementierungen MÜSSEN mindestens eine H.265- oder VP9-Decodierung von 720-, 1080- und UHD-Profilen unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	352 x 288 px	720 x 480 Pixel	1280 x 720 px	1920 x 1080 px	3840 x 2160 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30/60 fps (60 fpsFernsehen mit H.265-Hardware-Decodierung)	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] MÜSSEN die SD-Decodierungsprofile in der folgenden Tabelle unterstützen.
• SOLLTEN SIE einen Hardware-VP8-Codec verwenden, der die Anforderungen erfüllt.
• SOLLTEN die HD-Decodierungsprofile in der folgenden Tabelle unterstützen.

Wenn die von der Methode Display.getSupportedModes() gemeldete Höhe der Videoauflösung entspricht oder größer ist, dann gilt:

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

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p
Videoauflösung	320 x 180 Pixel	640 x 360 Pixel	1280 x 720 px	1920 x 1080 px
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] MÜSSEN die SD-Videodecodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
• SOLLTEN die HD-Decodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.

Wenn Geräteimplementierungen den VP9-Codec und einen Hardwaredecoder unterstützen:

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

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

• [C-3-1] Geräteimplementierungen MÜSSEN mindestens eine VP9- oder H.265-Decodierung des 720-, 1080- und UHD-Profils unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	320 x 180 Pixel	640 x 360 Pixel	1280 x 720 px	1920 x 1080 px	3840 x 2160 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30 fps (60 fpsFernsehen 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

Während einige der in diesem Abschnitt beschriebenen Anforderungen seit Android 4.3 als SOLLTEN aufgelistet werden, werden diese in der Kompatibilitätsdefinition für zukünftige Versionen in MÜSSEN geändert. Bestehenden und neuen Android-Geräten wird dringend empfohlen, diese Anforderungen zu erfüllen, da sie sonst die Android-Kompatibilität nach einem Upgrade auf die zukünftige Version nicht erreichen sollten.

5.4.1 Aufzeichnung von Rohaudio

Wenn in Geräteimplementierungen android.hardware.microphone deklariert wird, gilt Folgendes:

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

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

• [C-1-2] MÜSSEN bei den obigen Stichprobenraten ohne Up-Sampling erfassen.

• [C-1-3] MÜSSEN einen geeigneten Anti-Aliasing-Filter verwenden, wenn die oben angegebenen Abtastraten mit Downsampling erfasst werden.

• SOLLTEN die Aufnahme von Audio-Rohinhalten in AM-Radio- und DVD-Qualität erlauben. Das sollte folgende Merkmale aufweisen:

  • Format: Lineare PCM, 16 Bit
  • Abtastraten: 22.050, 48.000 Hz
  • Kanäle: Stereo

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

• [C-2-1] MÜSSEN ohne Upsampling bei einem Verhältnis von mehr als 16.000:22.050 oder 44.100:48.000 Aufnahmen erfassen.
• [C-2-2] MÜSSEN einen geeigneten Anti-Aliasing-Filter für jedes Up- bzw. Downsampling verwenden.

5.4.2 Für Spracherkennung aufnehmen

Wenn in Geräteimplementierungen android.hardware.microphone deklariert wird, gilt Folgendes:

• [C-1-1] MÜSSEN die Audioquelle android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION mit einer der Abtastraten 44.100 und 4.8.000 erfassen.
• [C-1-2] MÜSSEN standardmäßig die Audioverarbeitung zur Rauschunterdrückung deaktivieren, wenn du einen Audiostream von der Audioquelle „AudioSource.VOICE_RECOGNITION“ aufnimmst.
• [C-1-3] MÜSSEN standardmäßig die automatische Verstärkungsregelung bei der Aufzeichnung eines Audiostreams von der Audioquelle AudioSource.VOICE_RECOGNITION deaktivieren.
• SOLLTE den Audiostream der Spracherkennung mit einer ungefähren Charakteristiken der Amplitude gegenüber Frequenz aufzeichnen, insbesondere ±3 dB von 100 Hz bis 4.000 Hz.
• SOLLTEN Sie den Audiostream der Spracherkennung mit einer eingestellten Eingangsempfindlichkeit so aufnehmen, dass eine Schallleistungsquelle von 90 dB bei 1.000 Hz einen RMS-Wert von 2.500 für 16-Bit-Samples ergibt.
• SOLLTE den Audiostream der Spracherkennung so aufzeichnen, dass die PCM-Amplitudenpegel linear Änderungen des Eingangs-SPL in einem Bereich von -18 dB bis +12 dB bzw. 90 dB SPL am Mikrofon erfassen.
• SOLLTE den Audiostream der Spracherkennung mit einer THD-Gesamtheit von weniger als 1% für 1 kHz bei 90 dB SPL-Eingangslautstärke am Mikrofon aufzeichnen.

Wenn in Geräteimplementierungen android.hardware.microphone und Technologien zur Rauschunterdrückung bzw. Rauschunterdrückung für die Spracherkennung deklariert sind, gilt Folgendes:

• [C-2-1] MÜSSEN erlauben, dass dieser Audioeffekt mit der android.media.audiofx.NoiseSuppressor API gesteuert werden kann.
• [C-2-2] MÜSSEN jede Implementierung der Rauschunterdrückungstechnologie eindeutig über das Feld AudioEffect.Descriptor.uuid identifizieren.

5.4.3 Aufnahme für 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 sind, gilt Folgendes:

• [C-1-1] MÜSSEN die Audioquelle REMOTE_SUBMIX ordnungsgemäß implementieren, sodass eine Anwendung, die die android.media.AudioRecord API zum Aufzeichnen aus dieser Audioquelle verwendet, eine Mischung aus allen Audiostreams erfasst, mit Ausnahme der folgenden:

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

5.5. Audiowiedergabe

Wie in Abschnitt 7.8.2 definiert, unterstützt Android die Möglichkeit, Apps die Wiedergabe von Audio über das Audioausgabe-Peripheriegerät zu ermöglichen.

5.5.1 Raw-Audiowiedergabe

Wenn in Geräteimplementierungen android.hardware.audio.output deklariert wird, gilt Folgendes:

• [C-1-1] MUSS die Wiedergabe von unformatierten Audioinhalten mit den folgenden Eigenschaften zulassen:

  • Format: Lineare PCM, 16 Bit, 8 Bit, Gleitkommazahl
  • Kanäle: Mono, Stereo, gültige Mehrkanalkonfigurationen mit bis zu acht Kanälen
  • Abtastraten (in Hz):
    • 8000, 11025, 16000, 22050, 32000, 44100, 48000 bei den oben aufgeführten Kanalkonfigurationen
    • 96.000 in Mono und Stereo

• SOLLTEN die Wiedergabe von unformatierten Audioinhalten mit den folgenden Eigenschaften zulassen:

  • Abtastraten: 24.000, 48.000

5.5.2 Audioeffekte

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

Wenn in Geräteimplementierungen die Funktion android.hardware.audio.output deklariert wird, geschieht Folgendes:

• [C-1-1] MUSS die Implementierungen EFFECT_TYPE_EQUALIZER und EFFECT_TYPE_LOUDNESS_ENHANCER unterstützen, die über die AudioEffect-Unterklassen Equalizer, LoudnessEnhancer gesteuert werden können.
• [C-1-2] MUSS die Visualizer API-Implementierung 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.
• SOLLTEN die Implementierungen EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB und EFFECT_TYPE_VIRTUALIZER unterstützen, die über die abgeleiteten AudioEffect-Klassen BassBoost, EnvironmentalReverb, PresetReverb und Virtualizer gesteuert werden können.

5.5.3 Audioausgabelautstärke

Implementierungen von Automobilgeräten:

• MÜSSEN die Audiolautstärke für jeden Audiostream separat anpassen. Dazu müssen der Inhaltstyp oder die Nutzung gemäß der Definition in den Audioattributen und die öffentlich in android.car.CarAudioManager definierte Nutzung von Autoaudiodaten verwendet werden.

5.6. Audiolatenz

Die Audiolatenz ist die Zeitverzögerung, wenn ein Audiosignal ein System durchläuft. Viele Arten von Anwendungen nutzen kurze Latenzen, um Soundeffekte in Echtzeit zu erzielen.

Verwenden Sie für die Zwecke dieses Abschnitts 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 der Umgebung über einen geräteinternen Transducer oder ein Signal präsentiert wird, das das Gerät über einen Anschluss verlässt und extern erfasst werden kann.
• Kalte Ausgabelatenz. Die Ausgabelatenz für den ersten Frame, wenn das Audioausgabesystem vor der Anfrage inaktiv und heruntergefahren wurde.
• Kontinuierliche Ausgabelatenz: Die Ausgabelatenz für nachfolgende Frames nach der Audiowiedergabe auf dem Gerät.
• Eingabelatenz Das Intervall zwischen dem Zeitpunkt, zu dem ein Schall dem Gerät von der Umgebung über einen geräteinternen Transducer oder ein Signal übertragen wird, der über einen Port in das Gerät eintritt, und wenn eine Anwendung den entsprechenden Frame von PCM-codierten Daten liest.
• keine Eingabe mehr. Der erste Teil eines Eingabesignals, der nicht verwendbar oder nicht verfügbar ist.
• Kalteingabelatenz Die Summe der verlorenen Eingabezeit und der Eingabelatenz für den ersten Frame, wenn das Audioeingabesystem vor der Anfrage inaktiv war und heruntergefahren wurde.
• Kontinuierliche Eingabelatenz. Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufzeichnet.
• Kalter Ausgabejitter. Die Variabilität zwischen separaten Messungen der Latenzwerte für die kalte Ausgabe.
• Kalter Eingabejitter. Die Variabilität zwischen separaten Messungen der Latenzwerte für die Cold-Eingabe.
• Kontinuierliche Umlauflatenz. Die Summe der kontinuierlichen Eingabelatenz plus der kontinuierlichen Ausgabelatenz plus einem Pufferzeitraum. Der Pufferzeitraum gibt der App Zeit, das Signal zu verarbeiten, und die App hat genug Zeit, um den Phasenunterschied zwischen Ein- und Ausgabestreams abzuschwächen.
• OpenSL ES PCM Buffer Queue API Eine Reihe von PCM-bezogenen OpenSL ES APIs im Android NDK.
• Native Audio API von Audio. Die AAudio APIs im Android-NDK.
• Zeitstempel. Ein Paar, das aus einer relativen Frame-Position in einem Stream und der geschätzten Zeit besteht, zu der dieser Frame die Audioverarbeitungspipeline auf dem zugehörigen Endpunkt erreicht oder verlässt. Siehe auch AudioTimestamp.

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

• [C-SR] Kaltausgabelatenz von maximal 100 Millisekunden
• [C-SR] Kontinuierliche Ausgabelatenz von maximal 45 Millisekunden
• [C-SR] Kalten Ausgabejitter minimieren
• [C-SR] Der von AudioTrack.getTimestamp und AAudioStream_getTimestamp zurückgegebene Ausgabezeitstempel ist auf +/- 1 ms genau.

Wenn Geräteimplementierungen die oben genannten Anforderungen nach jeder anfänglichen Kalibrierung erfüllen und sowohl die OpenSL ES PCM-Zwischenspeicherwarteschlange als auch die nativen AAudio-Audio-APIs für kontinuierliche und kalte Ausgabelatenz für mindestens ein unterstütztes Audioausgabegerät verwendet werden, gilt Folgendes:

• [C-SR] WIRD DRINGEND empfohlen, Audio mit niedriger Latenz zu melden, indem du das Funktions-Flag „android.hardware.audio.low_latency“ deklarierst.
• [C-SR] EMPFOHLEN, die Anforderungen an Audio mit niedriger Latenz über die AAudio API zu erfüllen.
• [C-SR] EMPFOHLEN, damit bei Streams, die AAUDIO_PERFORMANCE_MODE_LOW_LATENCY von AAudioStream_getPerformanceMode() zurückgeben, der von AAudioStream_getFramesPerBurst() zurückgegebene Wert kleiner oder gleich dem Wert ist, der von android.media.AudioManager.getProperty(String) für den Property-Schlüssel AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER zurückgegeben wird.

Wenn Geräteimplementierungen die Anforderungen für Audio mit niedriger Latenz über die OpenSL ES PCM-Zwischenspeicherwarteschlange und die nativen AAudio-Audio-APIs nicht erfüllen, geschieht Folgendes:

• [C-1-1] DARF KEINE Unterstützung für Audio mit niedriger Latenz melden.

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

• [C-SR] Kalteingabelatenz von maximal 100 Millisekunden.
• [C-SR] Kontinuierliche Eingabelatenz von maximal 30 Millisekunden.
• [C-SR] Kontinuierliche Umlauflatenz von maximal 50 Millisekunden.
• [C-SR] Minimieren Sie den kalten Eingabejitter.
• [C-SR] Begrenzen Sie den Fehler bei den Eingabezeitstempeln, die von AudioRecord.getTimestamp oder AAudioStream_getTimestamp zurückgegeben werden, auf +/- 1 ms.

5.7. Netzwerkprotokolle

Geräteimplementierungen MÜSSEN die Mediennetzwerkprotokolle 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 in Abschnitt 5.1 erforderlichen Codecs und Containerformate über HTTP(S) unterstützen.

• [C-1-2] MÜSSEN die in der Tabelle unten aufgeführten Mediensegmentformate über HTTP Live Streaming Entwurf Protocol, Version 7 unterstützen.

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

Formate für Mediensegmente

Segmentformate	Referenz(en)	Codec-Unterstützung erforderlich
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 in 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)	Codec-Unterstützung erforderlich
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	Weitere Informationen zu H263 finden Sie in Abschnitt 5.1.3.
H263–2000	RFC 4629	Weitere Informationen zu H263 finden Sie in Abschnitt 5.1.3.
Logo: 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 in Abschnitt 5.1.3.
MPEG4-generisch	RFC 3640	Weitere Informationen zu AAC und seinen Varianten finden Sie in Abschnitt 5.1.1.
MP2T	RFC 2250	Weitere Informationen findest du im Abschnitt MPEG-2 Transport Stream unter "HTTP Live Streaming"

5.8. Sichere Medien

Wenn Geräteimplementierungen eine sichere Videoausgabe und sichere Oberflächen unterstützen, ist Folgendes zu beachten:

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

Wenn in Geräteimplementierungen die Unterstützung für Display.FLAG_SECURE und das Protokoll für kabellose Übertragungen deklariert werden, gilt Folgendes:

• [C-2-1] MÜSSEN die Verbindung mit einem kryptografisch starken Mechanismus wie HDCP 2.x oder höher für die Bildschirme sichern, die über WLAN-Protokolle wie Miracast verbunden sind.

Wenn in Geräteimplementierungen die Unterstützung von Display.FLAG_SECURE deklariert wird und externe Bildschirme mit Kabel unterstützt werden, gilt Folgendes:

• [C-3-1] MUSS HDCP 1.2 oder höher für alle externen Bildschirme unterstützen, die über einen vom Nutzer zugänglichen kabelgebundenen Port angeschlossen werden.

5.9. MIDI (Musical Instrument Digital Interface)

Wenn Geräteimplementierungen die Unterstützung der Funktion android.software.midi über die Klasse android.content.pm.PackageManager melden, geschieht Folgendes:

• [C-1-1] MÜSSEN MIDI über alle MIDI-fähigen Hardwaretransporte unterstützen, für die sie generische Nicht-MIDI-Verbindungen bereitstellen. Dazu gehören:

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

• [C-1-2] MÜSSEN den App-übergreifenden MIDI-Softwaretransport (virtuelle MIDI-Geräte) unterstützen.

5.10. Professionelles Audio

Wenn Geräteimplementierungen die Unterstützung der Funktion android.hardware.audio.pro über die Klasse android.content.pm.PackageManager melden, geschieht Folgendes:

• [C-1-1] MÜSSEN die Unterstützung für Funktion android.hardware.audio.low_latency melden.
• [C-1-2] MÜSSEN die in Abschnitt 5.6: Audiolatenz definierte kontinuierliche Umlauf-Audiolatenz haben, MUSS bei mindestens einem unterstützten Pfad 20 Millisekunden oder weniger betragen und 10 Millisekunden oder weniger betragen.
• [C-1-3] MUSS einen oder mehrere USB-Ports haben, die den USB-Hostmodus und den USB-Peripheriemodus unterstützen.
• [C-1-4] MÜSSEN die Unterstützung für Funktion android.software.midi melden.
• [C-1-5] MÜSSEN sowohl die OpenSL ES-PCM-Pufferwarteschlange als auch die native AAudio-Audio-APIs verwenden, um Latenzen und USB-Audioanforderungen zu erfüllen.
• [SR] wird dringend empfohlen, bei aktiver Audiowiedergabe und schwankender CPU-Auslastung eine konstante CPU-Leistung zu bieten. Dies sollte mit dem SimpleSynth-Commit 1bd6391 getestet werden. Die SimpleSynth-Anwendung muss mit den folgenden Parametern ausgeführt werden und nach 10 Minuten keine Unterläufe erreichen:
  • Arbeitszyklen: 200.000
  • Variable Belastung: AN (Wechselt alle 2 Sekunden zwischen 100% und 10% des Arbeitszykluswerts und dient zum Testen des Verhaltens des CPU-Reglers)
  • Stabilisierte Last: AUS
• SOLLTEN die Ungenauigkeit der Audiouhr und die Abweichung gegenüber der Standardzeit minimieren.
• SOLLTEN Sie die Abweichung des Audiotakts relativ zum CLOCK_MONOTONIC der CPU minimieren, wenn beide aktiv sind.
• SOLLTEN die Audiolatenz über geräteinterne Transducer minimieren.
• SOLLTEN die Audiolatenz im Vergleich zu digitalen USB-Audioquellen minimieren.
• SOLLTEN die Messungen der Audiolatenz für alle Pfade dokumentieren.
• SOLLTEN Jitter bei den Callback-Eingabezeiten für den Abschluss des Audiopuffers minimieren, da dies den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback beeinflusst.
• SOLLTE bei normaler Nutzung und mit der gemeldeten Latenz keine Audiounterläufe (Ausgabe) oder Überläufe (Eingabe) für Audioanzeigen bereitstellen.
• SOLLTEN keinen Unterschied bei der kanalübergreifenden Latenz haben.
• SOLLTEN die durchschnittliche MIDI-Latenz für alle Transporte minimieren.
• SOLLTEN die MIDI-Latenzvariabilität unter Last (Jitter) bei allen Transporten minimieren.
• SOLLTEN für alle Transporte genaue MIDI-Zeitstempel angeben.
• SOLLTEN Störungen des Audiosignals über Aufkleber auf dem Gerät minimiert werden, einschließlich des Zeitraums unmittelbar nach dem Kaltstart.
• SOLLTEN keine Audiotaktdifferenz zwischen den Ein- und Ausgabeseiten der entsprechenden Endpunkte erhalten, wenn beide aktiv sind. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher auf dem Gerät oder der Ein- und Ausgang des Audioanschlusses.
• SOLLTEN Callbacks zum Abschluss des Audiopuffers für die Eingabe- und Ausgabeseiten der entsprechenden Endpunkte im selben Thread verarbeiten, wenn beide aktiv sind, und den Ausgabe-Callback unmittelbar nach der Rückgabe des Eingabe-Callbacks eingeben. Wenn es nicht möglich ist, die Callbacks im selben Thread zu verarbeiten, geben Sie den Ausgabe-Callback kurz nach dem Eingeben des Eingabe-Callbacks ein, damit die Anwendung ein einheitliches Timing der Ein- und Ausgabeseiten hat.
• SOLLTEN Sie den Phasenunterschied zwischen der HAL-Audiozwischenspeicherung für die Ein- und Ausgabeseiten der entsprechenden Endpunkte minimieren.
• SOLLTEN die Berührungslatenz minimieren.
• SOLLTEN Sie die Schwankungen der Berührungslatenz unter Last (Jitter) minimieren.
• Die Latenz von der Eingabe per Berührung bis zur Audioausgabe sollte höchstens 40 ms betragen.

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

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

Wenn Geräte eine 3,5-mm-Audiobuchse mit 4 Kabeln enthalten, ist Folgendes zu beachten:

• [C-2-1] MÜSSEN die kontinuierliche Audioumlauflatenz über den Audioanschlusspfad auf maximal 20 Millisekunden betragen.
• [SR] EMPFOHLEN, den Abschnitt Spezifikationen für Mobilgeräte (Anschlusse) in der Spezifikation für kabelgebundene Audio-Headsets (Version 1.1) einzuhalten.
• Die kontinuierliche Umlauf-Audiolatenz SOLLTE höchstens 10 Millisekunden über dem Pfad der Audiobuchse betragen.

Wenn Geräte auf einen 3,5-mm-Audioanschluss mit 4 Kabeln verzichten und einen oder mehrere USB-Ports enthalten, die den USB-Hostmodus unterstützen, gilt Folgendes:

• [C-3-1] MÜSSEN die USB-Audioklasse implementieren.
• [C-3-2] MÜSSEN eine kontinuierliche Umlauf-Audiolatenz von maximal 20 Millisekunden über dem USB-Hostmodus-Port mit der USB-Audioklasse haben.
• Die kontinuierliche Umlauf-Audiolatenz SOLLTE höchstens 10 Millisekunden über dem USB-Hostmodus-Port bei Verwendung der USB-Audioklasse betragen.

Wenn Geräteimplementierungen einen HDMI-Port enthalten, ist Folgendes erforderlich:

• [C-4-1] MUSS in mindestens einer Konfiguration die Ausgabe in Stereo und acht Kanäle bei einer Tiefe von 20 Bit oder 24 Bit und 192 kHz ohne Bittiefenverlust oder Resampling unterstützen.

5:11. Für unverarbeitet erfassen

Android unterstützt die Aufzeichnung von nicht verarbeiteten Audioinhalten über die Audioquelle „android.media.MediaRecorder.AudioSource.UNPROCESSED“. In OpenSL ES kann über die Datensatzvoreinstellung SL_ANDROID_RECORDING_PRESET_UNPROCESSED darauf zugegriffen werden.

Wenn bei der Implementierung von Geräten eine unverarbeitete Audioquelle unterstützt und für Drittanbieter-Apps verfügbar gemacht werden soll, gilt Folgendes:

• [C-1-1] MÜSSEN den Support über die android.media.AudioManager-Property PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED melden.

• [C-1-2] MUSS im mittleren Frequenzbereich annähernd flache Amplitude-gegen-Frequenz-Eigenschaften aufweisen, insbesondere ±10 dB von 100 Hz bis 7.000 Hz für jedes Mikrofon, das zur Aufzeichnung der unverarbeiteten Audioquelle verwendet wird.

• [C-1-3] MUSS Amplitudenpegel im niedrigen Frequenzbereich aufweisen, insbesondere im Bereich von ±20 dB von 5 Hz bis 100 Hz im Vergleich zum Mittenfrequenzbereich jedes einzelnen Mikrofons, das zur Aufnahme der unverarbeiteten Audioquelle verwendet wird.

• [C-1-4] MÜSSEN Amplitudenpegel im hohen Frequenzbereich aufweisen, insbesondere von ±30 dB von 7.000 bis 22 kHz im Vergleich zum Mittelfrequenzbereich jedes einzelnen Mikrofons, das zur Aufnahme der unverarbeiteten Audioquelle verwendet wird.

• [C-1-5] MÜSSEN die Empfindlichkeit der Audioeingabe so einstellen, dass eine sinusoidale 1.000-Hz-Tonquelle, die bei 94 dB Schalldruckpegel abgespielt wird, für 16 Bit-Samples (oder -36 dB Full Scale) für jedes nicht verarbeitete Mikrofon, das für die Aufnahme verwendet wird, einen RMS-Wert von 520 liefert.

• [C-1-6] MUSS für jedes Mikrofon, das zur Aufnahme der unverarbeiteten Audioquelle verwendet wird, ein Signal-Rausch-Verhältnis (SNR) von 60 dB oder höher haben. (der SNR-Wert wird als Differenz zwischen 94 dB SPL und dem äquivalenten Schalldruckpegel des Eigenrauschens mit A-Gewichtung gemessen).

• [C-1-7] MÜSSEN bei jedem Mikrofon, das für die Aufnahme der unverarbeiteten Audioquelle verwendet wird, bei einem Eingangspegel von 1 kHz bei 90 dB SPL eine harmonische Verzerrung (THD) unter 1% liegen.

• DÜRFEN im Pfad keine andere Signalverarbeitung (z.B. automatische Verstärkungsregelung, Hochpassfilter oder Echounterdrückung) außer einem Levelmultiplikator verwendet werden, um das Level in den gewünschten Bereich zu bringen. Mit anderen Worten:

• [C-1-8] Wenn in der Architektur aus irgendeinem Grund Signalverarbeitung vorhanden ist, MUSS diese deaktiviert werden und der Signalpfad muss praktisch keine Verzögerung oder zusätzliche Latenz mit sich bringen.
• [C-1-9] Der Levelmultiplikator darf zwar im Pfad vorhanden sein, DARF aber KEINE Verzögerung oder Latenz in den Signalpfad einbringen.

Alle Schallpegelmessungen erfolgen direkt neben dem zu testenden Mikrofon. Bei mehreren Mikrofonkonfigurationen gelten diese Anforderungen für jedes Mikrofon.

Wenn in Geräteimplementierungen android.hardware.microphone deklariert ist, aber keine unverarbeitete Audioquelle unterstützt wird, gilt Folgendes:

• [C-2-1] MÜSSEN null für die API-Methode AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) zurückgeben, um richtig anzuzeigen, dass keine Unterstützung vorhanden ist.
• [SR] wird weiterhin UNBEDINGT empfohlen, so viele Anforderungen 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 gemäß den Dokumentationen im Android SDK und den im AOSP bereitgestellten Shell-Befehlen unterstützen, die von App-Entwicklern verwendet werden können, einschließlich dumpsys und cmd stats.
  • [C-0-3] DÜRFEN das Format oder den Inhalt von Gerätesystemereignissen (batterystats, diskstats, Fingerabdruck, generierte Grafiken, Netstats, Benachrichtigung, procstats) NICHT ändern, die über den Befehl dumpsys protokolliert wurden.
  • [C-0-10] MÜSSEN die folgenden Ereignisse ohne Auslassung aufgezeichnet und für den cmd stats-Shell-Befehl und die System-API-Klasse StatsManager zugänglich und verfügbar gemacht werden.
    • AktivitätsforegroundState geändert
    • Anomalie erkannt
    • AppBreadcrumbReported
    • App-Absturz aufgetreten
    • AppStartAuftreten
    • Akkustand geändert
    • Energiesparmodus geändert
    • BleScanResultReceived
    • BleScanStateGeändert
    • Ladestatus geändert
    • DeviceIdleModeStateGeändert
    • Dienststatus im Vordergrund geändert
    • GpsScanStateGeändert
    • JobStateChanged (Jobstatus geändert)
    • PluggedStateChanged
    • ScheduledJobStateGeändert
    • Bildschirmstatus geändert
    • Synchronisierungsstatus geändert
    • SystemElapsedRealtime
    • UidProcessStateGeändert
    • WakelockStateGeändert
    • Wakeup-Alarm aufgetreten
    • WifiLockStateGeändert
    • WifiMulticastLockStateGeändert
    • WifiScanStateGeändert
  • [C-0-4] MÜSSEN der geräteseitige ADB-Daemon standardmäßig inaktiv sein und es MÜSSEN einen vom Nutzer zugänglichen Mechanismus zum Aktivieren der Android Debug Bridge vorhanden sein.
  • [C-0-5] MUSS sicheres ADB unterstützen. Android unterstützt Secure ADB. „Secure adb“ aktiviert ADB auf bekannten authentifizierten Hosts.

  • [C-0-6] MÜSSEN einen Mechanismus bereitstellen, der die Verbindung von ADB mit einem Hostcomputer ermöglicht. Beispiel:

    • Geräteimplementierungen ohne USB-Port, die den Peripheriemodus unterstützen, MÜSSEN ADB über ein lokales Netzwerk (z. B. Ethernet oder WLAN) implementieren.
    • MÜSSEN Treiber für Windows 7, 9 und 10 bereitstellen, damit Entwickler über das ADB-Protokoll eine Verbindung zum Gerät herstellen können.

• Dalvik Debug Monitor-Dienst (ddms)

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

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

• [C-1-1] MÜSSEN dem App-Entwickler eine Option zum Aktivieren/Deaktivieren von GPU-Debug-Ebenen anbieten.
• [C-1-2] MÜSSEN, wenn die GPU-Debug-Ebenen aktiviert sind, Ebenen in Bibliotheken aufzählen, die von externen Tools bereitgestellt werden (d.h., die nicht Teil der Plattform oder des Anwendungspakets sind), die sich im Basisverzeichnis von Debug-fähigen Anwendungen befinden, um die API-Methoden vkEnumerateInstanceLayerProperties() und vkCreateInstance() zu unterstützen.

6.2 Entwickleroptionen

Android unterstützt Entwickler bei der Konfiguration von Einstellungen für die Anwendungsentwicklung.

Geräteimplementierungen MÜSSEN die Entwickleroptionen einheitlich nutzen. Sie:

• [C-0-1] MÜSSEN den Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS berücksichtigen, um auf die App-Entwicklung bezogene Einstellungen anzuzeigen. Durch die vorgelagerte Android-Implementierung wird das Menü mit den Entwickleroptionen standardmäßig ausgeblendet. Nutzer können die Entwickleroptionen dann starten, nachdem sie sieben (7) Mal auf den Menüpunkt Einstellungen > Über das Gerät > Build-Nummer geklickt haben.
• [C-0-2] MÜSSEN die Entwickleroptionen standardmäßig ausblenden.
• [C-0-3] MÜSSEN Sie einen klaren Mechanismus bereitstellen, durch den eine Drittanbieter-App keiner anderen bevorzugt behandelt wird, um Entwickleroptionen zu aktivieren. MÜSSEN ein öffentlich sichtbares Dokument oder eine öffentlich sichtbare Website zur Verfügung gestellt werden, auf dem bzw. der beschrieben wird, wie die Entwickleroptionen aktiviert werden. Dieses Dokument oder diese Website MUSS in den Android SDK-Dokumenten verknüpfbar sein.
• SOLLTE eine visuelle Benachrichtigung an den Nutzer eingeblendet werden, wenn die Entwickleroptionen aktiviert sind und die Sicherheit des Nutzers von Bedeutung ist.
• KANN den Zugriff auf das Menü „Entwickleroptionen“ vorübergehend einschränken, indem das Menü visuell ausgeblendet oder deaktiviert wird, um Ablenkungen in Situationen zu vermeiden, in denen die Sicherheit des Nutzers von Belang ist.

7. Hardwarekompatibilität

Wenn ein Gerät eine bestimmte Hardwarekomponente mit einer entsprechenden API für Drittentwickler hat:

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

Wenn eine API im SDK mit einer Hardwarekomponente interagiert, die als optional ausgewiesen wird, und die Geräteimplementierung diese Komponente nicht besitzt, gilt Folgendes:

• [C-0-2] Vollständige Klassendefinitionen (wie im SDK dokumentiert) für die Komponenten-APIs MÜSSEN weiterhin angezeigt werden.
• [C-0-3] Das Verhalten der API MÜSSEN in angemessener Weise managementfrei implementiert werden.
• [C-0-4] API-Methoden MÜSSEN NULL-Werte zurückgeben, sofern dies gemäß der SDK-Dokumentation zulässig ist.
• [C-0-5] API-Methoden MÜSSEN No-Op-Implementierungen von Klassen zurückgeben, bei denen Nullwerte gemäß der 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 konsistente Informationen zur Hardwarekonfiguration über die Methoden getSystemAvailableFeatures() und hasSystemFeature(String) in der Klasse android.content.pm.PackageManager für denselben Build-Fingerabdruck melden.

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

7.1. Display und Grafik

Android bietet Funktionen, mit denen App-Assets und UI-Layouts automatisch an das Gerät angepasst werden, um sicherzustellen, dass Apps von Drittanbietern mit verschiedenen Hardwarekonfigurationen einwandfrei ausgeführt werden können. Die Geräte MÜSSEN diese APIs und Verhaltensweisen ordnungsgemäß implementieren, wie in diesem Abschnitt beschrieben.

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

• physische diagonale Größe. Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Teils des Displays.
• DPI (Punkte pro Zoll) Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1 Zoll eingeschlossen werden. Wenn dpi-Werte angegeben sind, muss sowohl der horizontale als auch vertikale dpi innerhalb des Bereichs liegen.
• Seitenverhältnis. Das Verhältnis der Pixel der längeren Seite zur kürzeren Seite. Ein Display mit 480 × 854 Pixeln wäre beispielsweise 854/480 = 1, 779, also ungefähr „16:9“.
• dichteunabhängige Pixel (dp): Die virtuelle Pixeleinheit, normalisiert auf einen Bildschirm mit 160 dpi, berechnet wie folgt: Pixel = dps × (Dichte/160).

7.1.1 Bildschirmkonfiguration

7.1.1.1 Displaygröße und -form

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

Geräteimplementierungen:

• [C-0-1] MÜSSEN die korrekte Layoutgröße für Configuration.screenLayout angeben, wie in der Android SDK-Dokumentation definiert. Insbesondere MÜSSEN bei Geräteimplementierungen die korrekten dp-Bildschirmabmessungen (logisch dichteunabhängige Pixel) wie folgt gemeldet werden:

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

• [C-0-2] MÜSSEN die in der App angegebenen Unterstützung für Bildschirmgrößen durch das Attribut <supports-screens> in der Datei „AndroidManifest.xml“ korrekt berücksichtigt werden, wie in der Android SDK-Dokumentation beschrieben.

• KANN ein Display mit abgerundeten Ecken haben.

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

• [C-1-1] MÜSSEN sicherstellen, dass der Radius der abgerundeten Ecken kleiner oder gleich 38 dp ist.
• SOLLTEN die Nutzer die Möglichkeit haben, in den Anzeigemodus mit rechteckigen Ecken zu wechseln.

7.1.1.2 Bildschirmseitenverhältnis

Es gibt zwar keine Einschränkungen für das Seitenverhältnis des physischen Bildschirms, aber das Seitenverhältnis der logischen Anzeige, auf der Drittanbieter-Apps gerendert werden. Es muss sich aus den Werten für Höhe und Breite ableiten lassen, die über die view.Display APIs und die Configuration API gemeldet werden. MÜSSEN die folgenden Anforderungen erfüllt werden:

• [C-0-1] Geräteimplementierungen, bei denen Configuration.uiMode auf UI_MODE_TYPE_NORMAL festgelegt ist, MÜSSEN ein Seitenverhältnis zwischen 1,3333 (4:3) und 1,86 (ungefähr 16:9) haben, es sei denn, die App lässt sich länger verlängern, indem eine der folgenden Bedingungen erfüllt ist:

  • Die App hat angegeben, dass sie über den Metadatenwert android.max_aspect ein größeres Bildschirmseitenverhältnis unterstützt.
  • Die App deklariert über das Attribut android:resizeableActivity, dass ihre Größe angepasst werden kann.
  • Die App ist auf API-Level 24 oder höher ausgerichtet und gibt keine android:MaxAspectRatio an, 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 das Seitenverhältnis auf 1,0 (1:1) eingestellt sein.

7.1.1.3 Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe logischer Standarddichten, um Anwendungsentwicklern die Ausrichtung auf Anwendungsressourcen zu ermöglichen.

• [C-0-1] Geräteimplementierungen MÜSSEN standardmäßig nur eine der folgenden logischen Android-Framework-Dichten über die DENSITY_DEVICE_STABLE API melden. Dieser Wert DARF NICHT geändert werden. Das Gerät MÖGLICHT jedoch eine andere beliebige Dichte entsprechend den vom Nutzer vorgenommenen Änderungen an der Anzeigekonfiguration (z. B. der Anzeigegröße), die nach dem ersten Start vorgenommen wurden, melden.

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

• Bei Geräteimplementierungen SOLLTE die standardmäßige Android-Framework-Dichte definiert werden, die numerisch der physischen Dichte des Bildschirms am nächsten kommt, es sei denn, diese logische Dichte führt dazu, dass die gemeldete Bildschirmgröße unter das unterstützte Minimum fällt. Wenn die standardmäßige Android-Framework-Dichte, die numerisch der physischen Dichte am nächsten kommt, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 dp) ist, SOLLTEN die Geräteimplementierungen die nächstniedrigere Standard-Android-Framework-Dichte melden.

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

• [C-1-1] Die Displaygröße DARF NICHT größer als das 1,5-Fache der nativen Dichte skaliert werden oder eine effektive Mindestbildschirmgröße von weniger als 320 dp haben (entspricht dem Ressourcen-Qualifier sw320dp), je nachdem, was zuerst eintritt.
• [C-1-2] Die Anzeigegröße DARF NICHT kleiner als das 0,85-Fache der nativen Dichte skaliert werden.
• Um eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen zu gewährleisten, wird empfohlen, die folgende Skalierung der nativen Displayoptionen bereitzustellen (unter Einhaltung der oben genannten Beschränkungen).
• Klein: 0,85x
• Standardeinstellung: 1x (Skalierung für native Displayanzeige)
• Groß: 1,15x
• Größer: 1,3x
• Größte 1,45x

7.1.2 Messwerte anzeigen

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

• [C-1-1] MÜSSEN korrekte Werte für alle Displaymesswerte melden, die in der android.util.DisplayMetrics API definiert sind.

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

• [C-2-1] MÜSSEN angemessene Werte für alle Displaymesswerte melden, die in der android.util.DisplayMetrics API für den emulierten Standardwert view.Display definiert sind.

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 mindestens eine unterstützte Ausrichtung angeben. Beispielsweise sollte ein Gerät mit einer festen Ausrichtung im Querformat, wie ein Fernseher oder Laptop, nur android.hardware.screen.landscape melden.
• [C-0-2] MÜSSEN bei Abfragen über android.content.res.Configuration.orientation, android.view.Display.getOrientation() oder andere APIs den richtigen Wert für die aktuelle Ausrichtung des Geräts melden.

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

• [C-1-1] MUSS die dynamische Ausrichtung von Apps im Hoch- oder Querformat unterstützen. Das heißt, das Gerät muss die Anforderung der App für eine bestimmte Bildschirmausrichtung berücksichtigen.
• [C-1-2] DÜRFEN die gemeldete Bildschirmgröße oder -dichte beim Ändern der Ausrichtung NICHT ändern.
• Sie können als Standardeinstellung das Hoch- oder Querformat auswählen.

7.1.4 2D- und 3D-Grafikbeschleunigung

7.1.4.1 OpenGL ES

Geräteimplementierungen:

• [C-0-1] MÜSSEN 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, die sie unterstützen, enthalten.

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

• [C-1-1] MUSS sowohl OpenGL ES 1.1 als auch OpenGL 2.0 unterstützen, wie in der Android SDK-Dokumentation beschrieben.
• [SR] 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 über die von OpenGL ES verwalteten APIs und nativen APIs alle anderen von ihnen implementierten OpenGL ES-Erweiterungen melden. Umgekehrt DARF NICHT Erweiterungsstrings gemeldet werden, die von ihnen 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] wird dringend empfohlen, EGL_KHR_partial_update zu unterstützen.
• SOLLTEN mithilfe der Methode getString() alle unterstützten Texturkomprimierungsformate, die in der Regel anbieterspezifisch sind, korrekt melden.

Wenn in Geräteimplementierungen OpenGL ES 3.0, 3.1 oder 3.2 unterstützt werden, gilt Folgendes:

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

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

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

Wenn Geräteimplementierungen das gesamte Android-Erweiterungspaket von OpenGL ES unterstützen, gilt Folgendes:

• [C-5-1] MUSS die Unterstützung mit dem Funktions-Flag „android.hardware.opengles.aep“ identifizieren.

Wenn Geräteimplementierungen die Erweiterung EGL_KHR_mutable_render_buffer unterstützen, geschieht Folgendes:

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

7.1.4.2 Vulkan

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

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

• [SR] WIRD UNBEDINGT EMPFOHLEN, Support für Vulkan 1.1 aufzunehmen.

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

• SOLLTEN Support für Vulkan 1.1 beinhalten.

Wenn Geräteimplementierungen Vulkan 1.0 unterstützen, 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 aufgezählt werden, mindestens ein VkPhysicalDevice für die Vulkan-API vkEnumeratePhysicalDevices() .
• [C-1-3] MÜSSEN die Vulkan 1.0-APIs für jedes aufgeführte VkPhysicalDevice vollständig implementieren.
• [C-1-4] MÜSSEN Ebenen in nativen Bibliotheken mit dem Namen libVkLayer*.so im Bibliotheksverzeichnis des Anwendungspakets über die nativen Vulkan-APIs vkEnumerateInstanceLayerProperties() und vkEnumerateDeviceLayerProperties() aufzählen .
• [C-1-5] DARF KEINE Ebenen auflisten, die von Bibliotheken außerhalb des Anwendungspakets bereitgestellt werden, und keine anderen Möglichkeiten zum Nachverfolgen oder Abfangen der Vulkan API bieten, es sei denn, für die Anwendung ist das Attribut android:debuggable auf true festgelegt.
• [C-1-6] MÜSSEN alle Erweiterungsstrings melden, die von ihnen über die nativen Vulkan-APIs unterstützt werden. Umgekehrt DÜRFEN SIE KEINE Erweiterungsstrings melden, die von ihnen 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 Vulkan 1.0 nicht unterstützen, passiert Folgendes:

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

Wenn Geräteimplementierungen Vulkan 1.1 unterstützen, gilt Folgendes:

• [C-3-1] MÜSSEN die Unterstützung für die externe Semaphore und die Handle-Typen SYNC_FD anbieten.
• [SR] wird dringend empfohlen, die Erweiterung VK_ANDROID_external_memory_android_hardware_buffer 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 Beschleunigung der 2D-Grafik

In Android gibt es einen Mechanismus, mit dem Apps angeben können, dass sie die Hardwarebeschleunigung für 2D-Grafiken auf App-, Aktivitäts-, Fenster- oder Ansichtsebene durch die Verwendung des Manifest-Tags android:hardwareAccelerated oder direkte API-Aufrufe aktivieren möchten.

Geräteimplementierungen:

• [C-0-1] MÜSSEN die Hardwarebeschleunigung standardmäßig aktivieren und MÜSSEN die Hardwarebeschleunigung deaktivieren, wenn der Entwickler dies anfordert. Legen Sie dazu android:hardwareAccelerated="false" fest oder deaktivieren Sie die Hardwarebeschleunigung direkt über die Android View APIs.
• [C-0-2] MUSS ein Verhalten aufweisen, das der Android SDK-Dokumentation zur Hardwarebeschleunigung entspricht.

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

Geräteimplementierungen:

• [C-0-3] MÜSSEN die TextureView API unterstützen und ein einheitliches Verhalten mit der vorgelagerten Android-Implementierung zeigen.

7.1.4.5 Breitwinkel-Displays

Wenn Geräteimplementierungen Unterstützung für Breitbild-Displays über Configuration.isScreenWideColorGamut() versprechen , ist Folgendes zu beachten:

• [C-1-1] MUSS ein farbkalibriertes Display haben.
• [C-1-2] MÜSSEN über ein Display verfügen, dessen Farbumfang den sRGB-Farbraum im CIE 1931 xyY-Raum vollständig abdeckt.
• [C-1-3] MÜSSEN über ein Display verfügen, dessen Gamut eine Fläche von mindestens 90% des DCI-P3-Werts in CIE 1931 xyY ausmacht.
• [C-1-4] MUSS OpenGL ES 3.1 oder 3.2 unterstützen und ordnungsgemäß melden.
• [C-1-5] MÜSSEN Support 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] wird dringend empfohlen, GL_EXT_sRGB zu unterstützen.

Umgekehrt gilt: Wenn Geräteimplementierungen keine Wide-Gamut-Displays unterstützen, kann das folgende Gründe haben:

• [C-2-1] SOLLTEN mindestens 100% des sRGB-Bereichs im xyY-Bereich von CIE 1931 abdecken, wobei die Bildschirmfarbpalette nicht definiert ist.

7.1.5 Legacy-App-Kompatibilitätsmodus

Android gibt einen „Kompatibilitätsmodus“ an, in dem das Framework in einem „normalen“ Modus für die Bildschirmgröße (320 dp Breite) arbeitet. Das hat Vorteile für ältere Anwendungen, die nicht für ältere Versionen von Android entwickelt wurden und noch älter waren als die Bildschirmgröße.

7.1.6 Bildschirmtechnologie

Die Android-Plattform umfasst APIs, mit denen Anwendungen komplexe Grafiken auf dem Display rendern können. Geräte MÜSSEN gemäß der Definition des Android SDK alle diese APIs unterstützen, sofern dies in diesem Dokument nicht ausdrücklich zulässig ist.

Geräteimplementierungen:

• [C-0-1] MUSS Bildschirme unterstützen, die 16-Bit-Farbgrafiken unterstützen können.
• SOLLTEN Bildschirme unterstützt werden, die 24-Bit-Farbgrafiken unterstützen.
• [C-0-2] MÜSSEN Bildschirme unterstützen, die Animationen rendern können.
• [C-0-3] MUSS die Displaytechnologie mit einem Pixelseitenverhältnis (PAR) zwischen 0,9 und 1,15 verwenden. Das heißt, das Pixel-Seitenverhältnis MUSS nahe dem Quadratformat (1,0) mit einer Toleranz von 10 bis 15% liegen.

7.1.7 Sekundäre Displays

Android unterstützt einen sekundären Bildschirm, um Funktionen zum Teilen von Medien und Entwickler-APIs für den Zugriff auf externe Bildschirme zu aktivieren.

Wenn Geräteimplementierungen einen externen Bildschirm über eine kabelgebundene, drahtlose oder einen eingebetteten zusätzlichen Bildschirm unterstützen, gilt Folgendes:

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

7.2. Eingabegeräte

Geräteimplementierungen:

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

7.2.1 Tastatur

Wenn Geräteimplementierungen IME-Anwendungen (Input Method Editor) von Drittanbietern unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN das Funktions-Flag android.software.input_methods deklarieren.
• [C-1-2] MUSS 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. * SOLLTEN zusätzliche Implementierungen von Softtastaturen beinhalten. * KANN eine Hardware-Tastatur enthalten.

7.2.2 Berührungslose Navigation

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

Geräteimplementierungen:

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

Wenn Geräteimplementierungen keine berührungslose Navigation haben, kann das folgende Gründe haben:

• [C-1-1] MÜSSEN eine geeignete alternative Benutzeroberfläche zum Auswählen und Bearbeiten von Text bereitstellen, die mit Input Management Engines kompatibel ist. Die vorgelagerte Open-Source-Implementierung von Android enthält einen Auswahlmechanismus, der sich für Geräte eignet, die keine berührungslosen Navigationseingaben enthalten.

7.2.3 Navigationstasten

Die Funktionen Start, Letzte und Zurück, die in der Regel über eine Interaktion mit einer dedizierten physischen Taste oder einem bestimmten Teil des Touchscreens bereitgestellt werden, sind für das Navigationsparadigma von Android und daher für Geräteimplementierungen unerlässlich:

• [C-0-1] MÜSSEN ein Nutzerangebot zum Starten installierter Apps mit einer Aktivität bieten, bei der <intent-filter> bei Implementierungen von Fernsehgeräten mit ACTION=MAIN und CATEGORY=LAUNCHER oder CATEGORY=LEANBACK_LAUNCHER festgelegt ist. Die Home-Funktion SOLLTE der Mechanismus für dieses Nutzerangebot sein.
• SOLLTEN Schaltflächen für die Funktionen Recents und Zurück bereitstellen.

Wenn die Funktionen „Startbildschirm“, „Letzte“ und „Zurück“ verfügbar sind, geschieht Folgendes:

• [C-1-1] MÜSSEN mit einer einzigen Aktion (z.B. Tippen, Doppelklick oder Touch-Geste) aufgerufen werden, wenn eine davon zugänglich ist.
• [C-1-2] MÜSSEN deutlich darauf hinweisen, welche Aktion die jeweilige Funktion auslösen würde. Beispiele für solche Hinweise sind ein sichtbares Symbol auf der Schaltfläche, ein Softwaresymbol in der Navigationsleiste des Bildschirms oder die geführte Demo-Schritt-für-Schritt-Anleitung während der Out-of-Box-Einrichtung.

Geräteimplementierungen:

• [SR] wird dringend empfohlen, den Eingabemechanismus für die Menüfunktion nicht bereitzustellen, da diese Funktion seit Android 4.0 zugunsten der Aktionsleiste eingestellt wurde.

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

• [C-2-1] MÜSSEN die Dreipunkt-Menüschaltfläche für die Aktion anzeigen, wenn das Pop-up-Fenster für das Aktionsmenü nicht leer und die Aktionsleiste sichtbar ist.
• [C-2-2] DÜRFEN die Position des Aktions-Überlauf-Pop-ups, das angezeigt wird, indem Sie die Überlauf-Schaltfläche in der Aktionsleiste auswählen, NICHT ändern. Es KANN jedoch an einer geänderten Position auf dem Bildschirm gerendert werden, wenn es durch Auswahl der Menüfunktion angezeigt wird.

Geräteimplementierungen, die die Menüfunktion nicht enthalten, müssen aus Gründen der Abwärtskompatibilität: * [C-3-1] MÜSSEN die Menüfunktion für Apps verfügbar machen, wenn die targetSdkVersion kleiner als 10 ist, entweder durch eine physische Taste, eine Softwaretaste oder Touch-Gesten. Diese Menüfunktion sollte zugänglich sein, sofern sie nicht zusammen mit anderen Navigationsfunktionen ausgeblendet wird.

Wenn Geräte eine Unterstützungsfunktion bieten, gilt Folgendes: * [C-4-1] MÜSSEN die Assistenten mit einer einzigen Aktion (z.B. Tippen, Doppelklick oder Geste) zugänglich machen, wenn andere Navigationstasten verfügbar sind. * [SR] EMPFOHLEN, als vorgesehene Interaktion langes Drücken auf die Startbildschirmtaste zu verwenden.

Wenn bei Geräteimplementierungen die Navigationstasten nur an einem bestimmten Teil des Bildschirms angezeigt werden, geschieht Folgendes:

• [C-5-1] Die Navigationstasten MÜSSEN einen deutlich erkennbaren Teil des Bildschirms verwenden, der für Apps nicht sichtbar ist, und dürfen den für Apps verfügbaren Teil des Bildschirms NICHT verdecken oder anderweitig beeinträchtigen.
• [C-5-2] MUSS einen Teil des Bildschirms für Anwendungen verfügbar machen, die die in Abschnitt 7.1.1 definierten Anforderungen erfüllen.
• [C-5-3] MÜSSEN die von der App über die API-Methode View.setSystemUiVisibility() festgelegten Flags berücksichtigen, damit dieser bestimmte Teil des Bildschirms (die Navigationsleiste) ordnungsgemäß verborgen ist, wie im SDK dokumentiert.

7.2.4 Touchscreeneingabe

Android unterstützt eine Vielzahl von Zeigereingabesystemen wie Touchscreens, Touchpads und gefälschte Eingabegeräte. Implementierungen von Touchscreen-Geräten sind mit einem Display so verknüpft, dass der Nutzer den Eindruck hat, Elemente auf dem Bildschirm direkt zu manipulieren. Da der Nutzer den Bildschirm direkt berührt, benötigt das System keine zusätzlichen Angebote, um anzuzeigen, welche Objekte manipuliert werden.

Geräteimplementierungen:

• SOLLTEN über ein Zeigereingabesystem verfügen (z. B. Maus- oder Touch-Eingabe).
• SOLLTEN vollständig unabhängig nachverfolgte Zeiger unterstützen.

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

• [C-1-1] MÜSSEN 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 melden.

Wenn Geräte einen Touchscreen haben, mit dem mehrere Berührungen erfasst werden können, gilt Folgendes:

• [C-2-1] MÜSSEN die entsprechenden Funktions-Flags android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand melden, die dem Typ des Touchscreens des Geräts entsprechen.

Wenn Geräteimplementierungen keinen Touchscreen haben (und nur ein Zeigergerät verwenden) und die Anforderungen in Abschnitt 7.2.5 erfüllen, gilt Folgendes:

• [C-3-1] DÜRFEN KEINE Funktions-Flags melden, die mit android.hardware.touchscreen beginnen, und MÜSSEN nur android.hardware.faketouch melden.

7.2.5 Eingabe von gefälschten Berührungen

Die gefälschte Touch-Oberfläche bietet ein Eingabesystem für den Nutzer, das einen Teil der Touchscreen-Funktionen darstellt. So kann z. B. eine Maus oder Fernbedienung, die einen Bildschirmcursor ansteuert, eine Berührung annähern, aber der Nutzer muss zuerst die Maus oder den Fokus fokussieren und dann klicken. Zahlreiche Eingabegeräte wie Maus, Touchpad, Gyroskop, Gyroskop, Joystick und Multi-Touch-Touchpad können gefälschte Touch-Interaktionen unterstützen. Android enthält die Funktion „android.hardware.faketouch“, die einem High-Fidelity-Eingabegerät ohne Touchscreen entspricht, z. B. einer Maus oder einem Touchpad, das berührungsbasierte Eingaben angemessen emulieren kann (einschließlich der grundlegenden Unterstützung von Touch-Gesten) und darauf hinweist, dass das Gerät eine emulierte Teilmenge von Touchscreen-Funktionen unterstützt.

Wenn Geräteimplementierungen keinen Touchscreen haben, sondern ein anderes Zeigereingabesystem, das verfügbar gemacht werden soll, geschieht Folgendes:

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

Wenn in Geräteimplementierungen die Unterstützung von android.hardware.faketouch deklariert wird, gilt Folgendes:

• [C-1-1] MÜSSEN die absoluten X- und Y-Bildschirmpositionen der Zeigerposition melden und einen visuellen Zeiger auf dem Bildschirm anzeigen.
• [C-1-2] MÜSSEN ein Touch-Ereignis mit dem Aktionscode melden, der die Statusänderung angibt, die auf dem nach unten oder oben auf dem Bildschirm laufenden Zeiger auftritt.
• [C-1-3] MUSS den Zeiger nach unten und oben auf einem Objekt auf dem Bildschirm unterstützen, damit Nutzer das Tippen auf ein Objekt auf dem Bildschirm emulieren können.
• [C-1-4] MÜSSEN innerhalb eines bestimmten Zeitraums an derselben Stelle auf dem Bildschirm eines Objekts an derselben Stelle auf dem Bildschirm nach unten, nach oben und nach unten zeigen und dann nach oben zeigen, sodass Nutzer doppeltippen auf ein Objekt auf dem Bildschirm emulieren können.
• [C-1-5] MUSS den Zeiger nach unten an einem beliebigen Punkt auf dem Bildschirm unterstützen, den Zeiger zu einem beliebigen anderen beliebigen Punkt auf dem Bildschirm, gefolgt von einem Zeiger nach oben, mit dem Nutzer eine Touch-Ziehbewegung emulieren können.
• [C-1-6] MUSS den Zeiger nach unten unterstützen, damit Nutzer das Objekt schnell an eine andere Position auf dem Bildschirm und den Mauszeiger dann auf dem Bildschirm nach oben verschieben können.
• [C-1-7] MÜSSEN TOUCHSCREEN_NOTOUCH für das API-Feld Configuration.touchscreen melden.

Wenn in Geräteimplementierungen die Unterstützung von android.hardware.faketouch.multitouch.distinct deklariert wird, gilt Folgendes:

• [C-2-1] MÜSSEN die Unterstützung für android.hardware.faketouch erklären.
• [C-2-2] MÜSSEN das separate Tracking von zwei oder mehr unabhängigen Zeigereingaben unterstützen.

Wenn in Geräteimplementierungen die Unterstützung von android.hardware.faketouch.multitouch.jazzhand deklariert wird, gilt Folgendes:

• [C-3-1] MÜSSEN die Unterstützung für android.hardware.faketouch erklären.
• [C-3-2] MUSS das separate Tracking von 5 oder mehr Zeigereingaben vollständig unabhängig unterstützen, d. h. das Erfassen einer Hand mit Fingern.

7.2.6 Unterstützung für Gamecontroller

7.2.6.1 Schaltflächenzuordnungen

Wenn Geräteimplementierungen das Funktions-Flag android.hardware.gamepad deklarieren, geschieht Folgendes:

• [C-1-1] MUSS einen Controller oder ein Schiff mit einem separaten Controller im Lieferumfang enthalten sein, damit alle in den nachfolgenden 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 vorgelagerte Android-Implementierung umfasst eine Implementierung für Gamecontroller, die diese Anforderung erfüllen.

Schaltfläche	HID-Nutzung2	Android-Taste
A1	0x09 0x0001	KEYCODE_SCHALTFLÄCHE (96)
B1	0x09 0x0002	KEYCODE_SCHALTFLÄCHE (97)
X1	0x09 0x0004	KEYCODE_button_X (99)
J1	0x09 0x0005	KEYCODE_SCHALTFLÄCHE (100)
Steuerkreuz oben1 Steuerkreuz unten1	0x01 0x00393	AXIS_HAT_Y4
Steuerkreuz links1 Steuerkreuz rechts1	0x01 0x00393	AXIS_HAT_X4
Taste auf der linken Schulter1	0x09 0x0007	KEYCODE_button_L1 (102)
Rechte Schultertaste1	0x09 0x0008	KEYCODE_button_R1 (103)
Mit linker Maustaste klicken1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Mit der rechten Maustaste klicken1	0x09 0x000F	KEYCODE_button_THUMBR (107)
Zuhause1	0x0c 0x0223	KEYCODE_HOME (3)
Zurück1	0x0c 0x0224	KEYCODE_BACK (4)

1 Schlüsselereignis

2 Die oben genannten HID-Nutzungen müssen innerhalb einer Game Pad-CA (0x01 0x0005) deklariert werden.

3 Diese Nutzung muss ein logisches Minimum von 0, ein logisches Maximum von 7, ein physisches Minimum von 0, ein physisches Maximum von 315, ein Einheiten in Grad und eine Berichtsgröße von 4 sein. Der logische Wert ist als Drehung im Uhrzeigersinn weg von der vertikalen Achse definiert. Der logische Wert 0 steht beispielsweise für keine Drehung und das Drücken der Aufwärtstaste, während ein logischer Wert von 1 eine Drehung um 45 Grad bei gleichzeitiger Betätigung der Nach-oben- und der Nach-links-Taste darstellt.

4 MotionEvent

Analoge Steuerelemente1	HID-Nutzung	Android-Taste
Linker Trigger	0x02 0x00C5	WASSERGRÖSSE
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

Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.3.1.

7.3. Sensoren

Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittentwickler enthalten, MÜSSEN 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] MÜSSEN das Vorhandensein oder Fehlen von Sensoren gemäß der android.content.pm.PackageManager-Klasse korrekt melden.
• [C-0-2] MÜSSEN über die SensorManager.getSensorList() und ähnliche Methoden eine genaue Liste der unterstützten Sensoren zurückgeben.
• [C-0-3] MÜSSEN sich bei allen anderen Sensor-APIs angemessen verhalten, z. B. indem true oder false zurückgegeben werden, wenn Anwendungen versuchen, Listener zu registrieren, und keine Sensor-Listener aufrufen, wenn die entsprechenden Sensoren nicht vorhanden sind.

Wenn Geräteimplementierungen einen bestimmten Sensortyp mit einer entsprechenden API für Drittentwickler enthalten, geschieht Folgendes:

• [C-1-1] MÜSSEN alle Sensormessungen unter Verwendung der relevanten internationalen Maßeinheiten für jeden Sensortyp melden, wie in der Android SDK-Dokumentation definiert.
• [C-1-2] MÜSSEN Sensordaten mit einer maximalen Latenz von 100 Millisekunden + 2 * sample_time berichten, wenn ein Sensor mit einer minimalen erforderlichen Latenz von 5 ms + 2 * sample_time gestreamt wird, wenn der Anwendungsprozessor aktiv ist. Diese Verzögerung umfasst keine Filterverzögerungen.
• [C-1-3] MÜSSEN die erste Sensorprobe innerhalb von 400 Millisekunden + 2 * sample_time des Sensors melden, der aktiviert wird. Eine Genauigkeit von 0 ist für diese Stichprobe akzeptabel.

• [SR] SOLLTEN die Ereigniszeit in Nanosekunden angeben, wie in der Android SDK-Dokumentation definiert. Dabei muss es sich um den Zeitpunkt handeln, zu dem das Ereignis aufgetreten ist und mit der SystemClock.elapsedRealtimeNano()-Uhr synchronisiert wurde. Bestehenden und neuen Android-Geräten wird dringend empfohlen, diese Anforderungen zu erfüllen, sodass ein Upgrade auf zukünftige Plattform-Releases möglich ist, bei denen diese Komponente möglicherweise erforderlich ist. Der Synchronisierungsfehler SOLLTE unter 100 Millisekunden liegen.

• [C-1-4] Damit eine API, die in der Android SDK-Dokumentation als kontinuierlicher Sensor angegeben ist, MÜSSEN Geräteimplementierungen kontinuierlich regelmäßige Datenstichproben bereitstellen, die einen Jitter unter 3 % haben sollten, wobei der Jitter als Standardabweichung der Differenz der gemeldeten Zeitstempelwerte zwischen aufeinanderfolgenden Ereignissen definiert ist.

• [C-1-5] MUSS sicherstellen, dass der Sensorereignisstream NICHT verhindern darf, dass die CPU des Geräts in den Ruhemodus wechselt oder wieder aufwacht.

• Wenn mehrere Sensoren aktiviert sind, sollte der Stromverbrauch NICHT die Summe der vom einzelnen Sensor gemeldeten Stromverbrauch überschreiten.

Die Liste oben ist nicht vollständig. Das dokumentierte Verhalten des Android SDK und der Open-Source-Dokumentation von Android auf Sensoren wird als maßgeblich angesehen.

Einige Sensortypen sind zusammengesetzt, d. h., sie können aus Daten abgeleitet werden, die von einem oder mehreren anderen Sensoren bereitgestellt werden. (Beispiele hierfür sind der Ausrichtungssensor und der lineare Beschleunigungssensor.)

Geräteimplementierungen:

• SOLLTEN diese Sensortypen implementieren, 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 zusammengesetzten Sensoren beschrieben implementieren.

7.3.1 Beschleunigungsmesser

• Geräteimplementierungen SOLLTEN einen dreiachsigen Beschleunigungsmesser enthalten.

Wenn Geräte einen dreiachsigen Beschleunigungsmesser enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN Ereignisse bis zu 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-Sensorkoordinatensystem entsprechen, das in den Android-APIs beschrieben wird.
• [C-1-4] MUSS vom freien Fall bis zur vierfachen Schwerkraft(4 g) oder mehr auf jeder Achse gemessen werden können.
• [C-1-5] MUSS eine Auflösung von mindestens 12 Bit haben.
• [C-1-6] MUSS eine Standardabweichung von maximal 0,05 m/s^ haben, wobei die Standardabweichung pro Achse mit Stichproben berechnet werden sollte, die über einen Zeitraum von mindestens 3 Sekunden mit der schnellsten Stichprobe erfasst werden.
• [SR] wird dringend empfohlen, den TYPE_SIGNIFICANT_MOTION-Verbundsensor zu implementieren.
• [SR] wird dringend empfohlen, den TYPE_ACCELEROMETER_UNCALIBRATED-Sensor zu implementieren, wenn eine Kalibrierung des Online-Beschleunigungsmessers verfügbar ist.
• SOLLTEN die TYPE_SIGNIFICANT_MOTION-, TYPE_TILT_DETECTOR-, TYPE_STEP_DETECTOR- und TYPE_STEP_COUNTER-Sensoren wie im Android SDK-Dokument beschrieben implementieren.
• SOLLTE Ereignisse mit bis zu 200 Hz melden.
• SOLLTEN eine Auflösung von mindestens 16 Bit haben.
• SOLLTEN während der Verwendung kalibriert werden, wenn sich die Eigenschaften im Laufe des Lebenszyklus ändern und kompensiert werden. Die Kompensationsparameter müssen zwischen Geräteneustarts beibehalten werden.
• SOLLTE temperaturkompensiert werden.
• SOLLTEN auch den TYPE_ACCELEROMETER_UNCALIBRATED-Sensor implementiert werden.

Wenn die Geräteimplementierung einen dreiachsigen Beschleunigungsmesser umfasst und einer der zusammengesetzten TYPE_SIGNIFICANT_MOTION-, TYPE_TILT_DETECTOR-, TYPE_STEP_DETECTOR- oder TYPE_STEP_COUNTER-Sensoren implementiert ist:

• [C-2-1] Die Summe ihres Stromverbrauchs MUSS immer kleiner als 4 mW sein.
• SOLLTE jeweils unter 2 mW bzw.0,5 mW liegen, wenn das Gerät in einem dynamischen oder statischen Zustand ist.

Wenn Geräte einen 3-Achsen-Beschleunigungsmesser und einen Gyroskopsensor umfassen, gilt Folgendes:

• [C-3-1] MÜSSEN die zusammengesetzten Sensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren.
• SOLLTEN den TYPE_GAME_ROTATION_VECTOR-Sensoren implementieren.
• [SR] Für bestehende und neue Android-Geräte wird dringend empfohlen, den TYPE_GAME_ROTATION_VECTOR-Sensor zu implementieren.

Wenn Geräte einen dreiachsigen Beschleunigungsmesser, einen Gyroskopsensor und einen Magnetometersensor umfassen, gilt Folgendes:

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

7.3.2 Magnetometer

• Geräteimplementierungen SOLLTEN ein dreiachsiges Magnetometer (Kompass) enthalten.

Wenn Geräteimplementierungen ein 3-Achsen-Magnetometer umfassen, gilt Folgendes:

• [C-1-1] MÜSSEN den TYPE_MAGNETIC_FIELD-Sensor implementieren.
• [C-1-2] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 10 Hz und Ereignisse bis zu einer Frequenz von mindestens 50 Hz melden können.
• [C-1-3] MUSS dem Android-Sensorkoordinatensystem entsprechen, das in den Android-APIs beschrieben wird.
• [C-1-4] MUSS vor der Sättigung zwischen -900 μT und +900 μT auf jeder Achse messen können.
• [C-1-5] MUSS einen Offset-Wert von hartem Eisen unter 700 μT haben und einen Wert unter 200 μT haben. Platzieren Sie das Magnetometer in der Nähe von dynamischen (strominduzierten) und statischen (magnetinduzierten) Magnetfeldern.
• [C-1-6] MUSS eine Auflösung von mindestens 0,6 μT haben.
• [C-1-7] MUSS die Online-Kalibrierung und -kompensation unterstützen und die Kompensationsparameter zwischen Geräteneustarts beibehalten.
• Auf [C-1-8] MUSS die Kompensation für weiches Eisen angewendet werden. Die Kalibrierung kann entweder während der Verwendung oder während der Produktion des Geräts erfolgen.
• [C-1-9] MÜSSEN eine Standardabweichung haben, die achsenbasiert für Stichproben, die über einen Zeitraum von mindestens 3 Sekunden mit der schnellsten Abtastrate (nicht größer als 1,5 μT) erfasst wurden, berechnet; SOLLTE eine Standardabweichung von maximal 0,5 μT haben.
• SOLLTEN SIE TYPE_MAGNETIC_FIELD_UNCALIBRATED-Sensor implementieren.
• [SR] Für bestehende und neue Android-Geräte wird dringend empfohlen, den TYPE_MAGNETIC_FIELD_UNCALIBRATED-Sensor zu implementieren.

Wenn Geräteimplementierungen ein 3-Achsen-Magnetometer, einen Beschleunigungsmessersensor und einen Gyroskopsensor umfassen, gilt Folgendes:

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

Wenn Geräteimplementierungen ein dreiachsiges Magnetometer oder einen Beschleunigungsmesser enthalten, ist Folgendes zu beachten:

• KANN den TYPE_GEOMAGNETIC_ROTATION_VECTOR-Sensor implementieren.

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

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

7.3.3 GPS

Geräteimplementierungen:

• SOLLTE 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, geschieht Folgendes:

• [C-1-1] MUSS die Standortausgaben mit einer Frequenz von mindestens 1 Hz unterstützen, wenn sie über LocationManager#requestLocationUpdate angefordert werden.
• [C-1-2] MÜSSEN in der Lage sein, den Standort unter freiem Himmel (starke Signale, vernachlässigbarer Multipfad, HDOP < 2) innerhalb von 10 Sekunden (schnelle Zeit bis zur ersten Behebung) zu bestimmen, wenn eine Internetverbindung mit einer Geschwindigkeit von mindestens 0,5 Mbit/s verbunden ist. Diese Anforderung wird in der Regel durch die Verwendung einer unterstützten oder vorhergesagten GPS-/GNSS-Technik erfüllt, um die GPS-/GNSS-Lock-On-Zeit zu minimieren (Unterstützungsdaten umfassen Referenzzeit, Referenzstandort und Satelliten-Ephemeris/Uhr).
  • [C-1-6] Nach einer solchen Standortberechnung MÜSSEN Geräteimplementierungen den Standort unter freiem Himmel innerhalb von 5 Sekunden nach dem Neustart von Standortanfragen und bis zu einer Stunde nach der ursprünglichen Standortberechnung ermitteln, selbst wenn die nachfolgende Anfrage ohne Datenverbindung und/oder nach dem Neustart erfolgt ist.

• Bei freiem Himmel, nachdem der Ort bestimmt wurde, während Sie sich nicht bewegen oder sich im Stil von weniger als 1 Meter pro Sekunde im Quadrat der Beschleunigung bewegen:

  • [C-1-3] MÜSSEN in mindestens 95% der Fälle den Standort in einem Umkreis von 20 Metern und eine Geschwindigkeit von 0,5 Metern pro Sekunde bestimmen können.
  • [C-1-4] MÜSSEN mindestens 8 Satelliten einer Konstellation gleichzeitig über GnssStatus.Callback erfassen und melden.
  • SOLLTEN in der Lage sein, mindestens 24 Satelliten aus mehreren Konstellationen gleichzeitig zu verfolgen (z.B. GPS und mindestens eines von Glonass, Beidou oder Galileo).
  • [C-1-5] MÜSSEN die GNSS-Technologie über die Test-API „getGnssYearOfHardware“ melden.
  • [SR] Bei einem Notruf wird weiterhin die normale GPS-/GNSS-Standortausgabe genutzt.
  • [SR] GNSS-Messungen aller erfassten Konstellationen melden (wie in GnssStatus-Nachrichten gemeldet), mit Ausnahme von SBAS.
  • [SR] AGC und Häufigkeit der GNSS-Messung melden.
  • [SR] Alle Genauigkeitsschätzungen (einschließlich Peilung, Geschwindigkeit und Branche) als Teil jedes GPS/GNSS-Standorts melden.
  • [SR] wird dringend empfohlen, über die Test API LocationManager.getGnssYearOfHardware() die zusätzlichen Anforderungen für Geräte, die das Jahr "2016" oder "2017" melden, so viele wie möglich zu erfüllen.

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

• [C-2-1] MÜSSEN GNSS-Messungen melden, sobald sie gefunden werden, auch wenn ein über GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
• [C-2-2] MÜSSEN GNSS-Pseudobereiche und Pseudorangeraten melden, die unter freiem Himmel nach der Bestimmung des Standorts ausreichen, wenn sie sich nicht bewegen oder sich mit einer Beschleunigung von weniger als 0,2 Metern pro Quadratsekunde bewegen, um die Position innerhalb von 20 Metern und eine Geschwindigkeit innerhalb von 0,2 Metern pro Sekunde in mindestens 95% der Zeit zu berechnen.

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

• [C-3-1] MUSS während eines Notrufs weiterhin die normalen GPS-/GNSS-Standortausgaben liefern.
• [C-3-2] MÜSSEN GNSS-Messungen von allen erfassten Konstellationen melden (wie in GnssStatus-Nachrichten angegeben), mit Ausnahme von SBAS.
• [C-3-3] MÜSSEN die AGC und die Häufigkeit der GNSS-Messung melden.
• [C-3-4] MÜSSEN alle Schätzungen zur Genauigkeit (einschließlich Peilung, Geschwindigkeit und Branche) für jeden GPS-/GNSS-Standort melden.

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

• [C-4-1] MUSS während eines Notrufs, der von einem Mobile Station-basierten (MS-basierten) Netzwerk initiiert wird, weiterhin normale GPS-/GNSS-Ausgaben an Apps senden.
• [C-4-2] MÜSSEN Positionen und Messwerte an die GNSS Location Provider-APIs melden.

7.3.4 Gyroskop

Geräteimplementierungen:

• SOLLTE ein Gyroskop, also ein Winkelsensor, enthalten.
• SOLLTE KEINEN Gyroskopsensor verwendet werden, es sei denn, es ist auch ein dreiachsiger Beschleunigungsmesser vorhanden.

Wenn Geräteimplementierungen ein Gyroskop umfassen, gilt Folgendes:

• [C-1-1] MÜSSEN Ereignisse bis zu einer Frequenz von mindestens 50 Hz melden können.
• [C-1-2] MÜSSEN den TYPE_GYROSCOPE-Sensor und auch den TYPE_GYROSCOPE_UNCALIBRATED-Sensor implementieren.
• [C-1-3] MÜSSEN Ausrichtungsänderungen von bis zu 1.000 Grad pro Sekunde messen können.
• [C-1-4] MÜSSEN eine Auflösung von mindestens 12 Bit und eine Auflösung von mindestens 16 Bit haben.
• [C-1-5] MUSS temperaturkompensiert werden.
• [C-1-6] MÜSSEN während der Verwendung kalibriert und kompensiert werden und die Kompensationsparameter zwischen Geräteneustarts beibehalten.
• [C-1-7] MUSS eine Abweichung von höchstens 1e–7 rad^2 / s^2 pro Hz (Abweichung pro Hz oder rad^2 / s) haben. Die Varianz darf mit der Stichprobenrate variieren, MUSS aber durch diesen Wert eingeschränkt werden. Mit anderen Worten: Wenn Sie die Varianz des Gyros mit einer Abtastrate von 1 Hz messen, SOLLTE sie nicht größer als 1e-7 rad^2/s^2 sein.
• [SR] Für bestehende und neue Android-Geräte wird dringend empfohlen, den SENSOR_TYPE_GYROSCOPE_UNCALIBRATED-Sensor zu implementieren.
• [SR] Der Kalibrierungsfehler liegt UNBEDINGT unter 0,01 Rad/s, wenn das Gerät bei Raumtemperatur steht.
• SOLLTE Ereignisse mit bis zu 200 Hz melden.

Wenn Geräte ein Gyroskop, einen Beschleunigungsmessersensor und einen Magnetometersensor enthalten, ist Folgendes zu beachten:

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

Wenn Geräte ein Gyroskop und einen Beschleunigungsmesser enthalten, ist Folgendes zu beachten:

• [C-3-1] MÜSSEN die zusammengesetzten Sensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementieren.
• [SR] Für bestehende und neue Android-Geräte wird dringend empfohlen, den TYPE_GAME_ROTATION_VECTOR-Sensor zu implementieren.
• SOLLTEN den TYPE_GAME_ROTATION_VECTOR-Sensoren implementieren.

7.3.5 Barometer

• Geräteimplementierungen SOLLTEN ein Barometer (Umgebungsdrucksensor) umfassen.

Wenn Geräteimplementierungen ein Barometer enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN den TYPE_PRESSURE-Sensor implementieren und melden.
• [C-1-2] MUSS Ereignisse bei 5 Hz oder mehr liefern können.
• [C-1-3] MUSS temperaturkompensiert werden.
• [SR] WIRD UNBEDINGT EMPFOHLEN, Druckmessungen in einem Bereich von 300 hPa bis 1100 hPa übermitteln zu können.
• SOLLTEN eine absolute Genauigkeit von 1 hPa haben.
• SOLLTE eine relative Genauigkeit von 0,12 hPa in einem Bereich von 20 hPa haben (entspricht einer Genauigkeit von ~1 m über ~200 m Änderung auf Meereshöhe).

7.3.6 Thermometer

Geräteimplementierung: * KANN ein Umgebungsthermometer (Temperatursensor) enthalten. * KANN, aber SOLLTE KEINEN CPU-Temperatursensor enthalten.

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

• [C-1-1] MUSS als SENSOR_TYPE_AMBIENT_TEMPERATURE definiert sein und MÜSSEN die Umgebungstemperatur (Raum-/Fahrzeugraum) in Grad Celsius messen, bei der der Nutzer mit dem Gerät interagiert.
• [C-1-2] MUSS als SENSOR_TYPE_TEMPERATURE definiert sein.
• [C-1-3] MUSS die Temperatur der CPU des Geräts messen.
• [C-1-4] DARF KEINE andere Temperatur messen.

Beachte, dass der Sensortyp SENSOR_TYPE_TEMPERATURE in Android 4.0 eingestellt wurde.

7.3.7 Fotometer

• Sie können ein Fotometer (Umgebungslicht-Sensor) verwenden, in dem ein entsprechendes Gerät implementiert ist.

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] MÜSSEN die Nähe eines Objekts in derselben Richtung wie der Bildschirm messen. Das heißt, der Näherungssensor MUSS so ausgerichtet sein, dass Objekte in der Nähe des Bildschirms erkannt werden, da die Hauptabsicht dieses Sensortyps darin besteht, ein vom Nutzer verwendetes Smartphone zu erkennen. Wenn Geräteimplementierungen einen Näherungssensor mit einer anderen Ausrichtung beinhalten, DARF NICHT über diese API darauf zugegriffen werden.
• [C-1-2] MUSS eine Genauigkeit von mindestens 1 Bit haben.

7.3.9 Hochwertige Sensoren

Wenn Geräteimplementierungen eine Reihe hochwertiger Sensoren (wie in diesem Abschnitt definiert) enthalten und sie für Drittanbieter-Apps zur Verfügung stellen, gilt Folgendes:

• [C-1-1] MUSS die Funktion mit dem Funktions-Flag android.hardware.sensor.hifi_sensors identifizieren.

Wenn in Geräteimplementierungen android.hardware.sensor.hifi_sensors deklariert wird, gilt Folgendes:

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

  • MÜSSEN einen Messbereich zwischen -8 g und +8 g haben, SOLLTEN zwischen -16 g und +16 g liegen.
  • MÜSSEN eine Auflösung von mindestens 2.048 LSB/g haben.
  • MUSS eine Mindest-Messfrequenz von 12,5 Hz oder weniger haben.
  • MÜSSEN eine maximale Messfrequenz von 400 Hz oder höher haben; SOLLTE SensorDirectChannel RATE_VERY_FAST unterstützen.
  • MUSS ein Messrauschen nicht über 400 μg/√Hz haben.
  • MÜSSEN eine Nicht-Aktivierungsform dieses Sensors mit einer Pufferfunktion von mindestens 3.000 Sensorereignissen implementiert werden.
  • MUSS einen Batch-Stromverbrauch haben, der nicht unter 3 mW liegt.
  • [C-SR] Es wird dringend empfohlen, eine 3-dB-Messbandbreite von mindestens 80% der Nyquist-Frequenz und ein Spektrum für weißes Rauschen innerhalb dieser Bandbreite zu haben.
  • SOLLTEN Beschleunigungen, die zufallsgesteuert werden, unter 30 μg √Hz bei Raumtemperatur laufen.
  • SOLLTE eine Verzerrungsänderung gegenüber der Temperatur von ≤ +/- 1 mg/°C auftreten.
  • SOLLTEN eine optimale Linien-Nichtlinearität von ≤ 0,5 % und Empfindlichkeitsänderung gegenüber Temperatur ≤ 0,03%/C° haben.
  • SOLLTE eine Querachsenempfindlichkeit unter 2,5 % und eine Abweichung der Querachsenempfindlichkeit unter 0,2% im Betriebstemperaturbereich des Geräts haben.

• [C-2-2] MUSS eine 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 -1.000 und +1.000 dps haben.
  • MÜSSEN eine Auflösung von mindestens 16 LSB/dps haben.
  • MUSS eine Mindest-Messfrequenz von 12,5 Hz oder weniger haben.
  • MÜSSEN eine maximale Messfrequenz von 400 Hz oder höher haben; SOLLTE SensorDirectChannel RATE_VERY_FAST unterstützen.
  • MUSS ein Messrauschen von maximal 0,014°/s/√Hz haben.
  • [C-SR] Es wird dringend empfohlen, eine 3-dB-Messbandbreite von mindestens 80% der Nyquist-Frequenz und ein Spektrum für weißes Rauschen innerhalb dieser Bandbreite zu haben.
  • SOLLTE eine Zufallsfrequenz von unter 0,001°/s √Hz bei Raumtemperatur laufen lassen.
  • SOLLTE eine Verzerrungsänderung gegenüber der Temperatur von ≤ +/- 0,05 °/ s / °C auftreten.
  • SOLLTE eine Änderung der Empfindlichkeit gegenüber der Temperatur von ≤ 0,02% / °C betragen.
  • SOLLTEN eine Nichtlinearität der bestmöglichen Linie von ≤ 0,2 % haben.
  • SOLLTEN eine Rauschdichte von ≤ 0,007°/s/√Hz haben.
  • SOLLTE ein Kalibrierungsfehler unter 0,002 Rad/s im Temperaturbereich zwischen 10 und 40 °C auftreten, wenn das Gerät steht.
  • SOLLTE eine G-Empfindlichkeit unter 0,1°/s/g aufweisen.
  • SOLLTE eine Querachsenempfindlichkeit unter 4,0 % und die Abweichung der achsenübergreifenden Empfindlichkeit im Temperaturbereich des Gerätebetriebs unter 0,3% liegen.

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

• [C-2-5] MUSS einen TYPE_GEOMAGNETIC_FIELD-Sensor haben, der:

  • MÜSSEN einen Messbereich zwischen -900 und +900 μT haben.
  • MÜSSEN eine Auflösung von mindestens 5 LSB/uT haben.
  • MUSS eine Mindest-Messfrequenz von 5 Hz oder niedriger haben.
  • MUSS eine maximale Messfrequenz von 50 Hz oder höher haben.
  • MUSS ein Messrauschen aufweisen, das nicht über 0,5 uT liegt.

• [C-2-6] MUSS eine TYPE_MAGNETIC_FIELD_UNCALIBRATED mit denselben Qualitätsanforderungen wie TYPE_GEOMAGNETIC_FIELD sowie zusätzlich Folgendes haben:

  • MÜSSEN eine Nicht-Aktivierungsform dieses Sensors mit einer Pufferfunktion von mindestens 600 Sensorereignissen implementiert werden.
  • [C-SR] Es wird dringend empfohlen, ein weißes Rauschenspektrum von 1 Hz bis mindestens 10 Hz zu haben, wenn die Melderate mindestens 50 Hz beträgt.

• [C-2-7] MUSS einen TYPE_PRESSURE-Sensor haben, der:

  • MÜSSEN einen Messbereich zwischen mindestens 300 und 1100 hPa aufweisen.
  • MÜSSEN eine Auflösung von mindestens 80 LSB/hPa haben.
  • MUSS eine Mindest-Messfrequenz von 1 Hz oder niedriger haben.
  • MUSS eine maximale Messfrequenz von 10 Hz oder höher haben.
  • MUSS ein Messrauschen von maximal 2 P/√Hz haben.
  • MÜSSEN eine Nicht-Aktivierungsform dieses Sensors mit einer Pufferfunktion von mindestens 300 Sensorereignissen implementiert werden.
  • Der Stromverbrauch für die Batchverarbeitung MUSS nicht unter 2 mW liegen.
• [C-2-8] MUSS einen TYPE_GAME_ROTATION_VECTOR-Sensor haben, der:
  • MÜSSEN eine Nicht-Aktivierungsform dieses Sensors mit einer Pufferfunktion von mindestens 300 Sensorereignissen implementiert werden.
  • MÜSSEN einen Batch-Stromverbrauch haben, der nicht unter 4 mW liegt.
• [C-2-9] MUSS einen TYPE_SIGNIFICANT_MOTION-Sensor haben, der:
  • MUSS einen Stromverbrauch von nicht weniger als 0,5 mW haben, wenn das Gerät statisch ist, und 1,5 mW, wenn das Gerät in Bewegung ist.
• [C-2-10] MUSS einen TYPE_STEP_DETECTOR-Sensor haben, der:
  • MÜSSEN eine Nicht-Aktivierungsform dieses Sensors mit einer Pufferfunktion von mindestens 100 Sensorereignissen implementiert werden.
  • MUSS einen Stromverbrauch von nicht weniger als 0,5 mW haben, wenn das Gerät statisch ist, und 1,5 mW, wenn das Gerät in Bewegung ist.
  • MÜSSEN einen Batch-Stromverbrauch haben, der nicht unter 4 mW liegt.
• [C-2-11] MUSS einen TYPE_STEP_COUNTER-Sensor haben, der:
  • MUSS einen Stromverbrauch von nicht weniger als 0,5 mW haben, wenn das Gerät statisch ist, und 1,5 mW, wenn das Gerät in Bewegung ist.
• [C-2-12] MUSS einen TILT_DETECTOR-Sensor haben, der:
  • MUSS einen Stromverbrauch von nicht weniger als 0,5 mW haben, wenn das Gerät statisch ist, und 1,5 mW, wenn das Gerät in Bewegung ist.
• [C-2-13] Der vom Beschleunigungsmesser, Gyroskop und Magnetometer gemeldete Zeitstempel desselben physischen Ereignisses MUSS nicht weiter als 2, 5 Millisekunden voneinander entfernt sein. Der vom Beschleunigungsmesser und dem Gyroskop gemeldete Zeitstempel desselben physischen Ereignisses SOLLTEN nicht weiter als 0,25 Millisekunden voneinander entfernt sein.
• [C-2-14] MÜSSEN Zeitstempel für Gyroskopsensor-Ereignisse auf derselben Zeitbasis wie das Kamerasubsystem und innerhalb von 1 Millisekunden nach Ablauf haben.
• [C-2-15] MÜSSEN innerhalb von 5 Millisekunden ab dem Zeitpunkt, an dem die Daten auf einem der oben genannten physischen Sensoren für die Anwendung verfügbar sind, Stichproben an Anwendungen übergeben.
• [C-2-16] DÜRFEN keinen Stromverbrauch von mehr als 0,5 mW haben, wenn das Gerät statisch ist, und 2,0 mW, wenn das Gerät in Bewegung ist, wenn eine Kombination der folgenden Sensoren aktiviert ist:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] KÖNNEN einen TYPE_PROXIMITY-Sensor haben, MUSS aber eine Mindestpufferkapazität von 100 Sensorereignissen haben, falls vorhanden.

Beachten Sie, dass die Anforderungen an den Stromverbrauch in diesem Abschnitt nicht den Stromverbrauch des Anwendungsprozessors umfassen. Sie schließt auch die Leistung ein, die von der gesamten Sensorkette – Sensor, unterstützenden Schaltkreisen, dedizierten Sensorverarbeitungssystemen usw. – verbraucht wird.

Wenn Geräte eine direkte Sensorunterstützung bieten, gilt Folgendes:

• [C-3-1] MÜSSEN die Unterstützung von Typen für direkte Kanäle und der Preise für direkte Berichte über die isDirectChannelTypeSupported und getHighestDirectReportRateLevel API korrekt deklarieren.
• [C-3-2] MUSS mindestens einen der beiden direkten Sensorkanaltypen für alle Sensoren unterstützen, die das unterstützen.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• SOLLTEN Ereignisberichte über den direkten Sensorkanal für den primären Sensor (Variante ohne Weckfunktion) 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 beinhalten, gilt Folgendes:

• SOLLTE einen Fingerabdrucksensor enthalten.

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

• [C-1-1] MÜSSEN die Unterstützung für die Funktion android.hardware.fingerprint erklären.
• [C-1-2] MÜSSEN die entsprechende API vollständig implementieren, wie in der Android SDK-Dokumentation beschrieben.
• [C-1-3] MUSS eine falsche Annahmequote von 0,002 % haben.
• [SR] Uns wird dringend empfohlen, eine Akzeptanzrate von Spoofing und Hochstapler-Syndrom auf maximal 7 % zu setzen.
• [C-1-4] MÜSSEN darauf hinweisen, dass dieser Modus möglicherweise nicht so sicher ist als eine starke PIN, ein starkes Muster oder ein starkes Passwort. Außerdem müssen die Risiken einer Aktivierung klar aufgezählt werden, wenn die Annahmequoten für Spoofing und Hochstapler 7 % übersteigen.
• [C-1-5] MUSS nach fünf falschen Tests zur Bestätigung per Fingerabdruck mindestens 30 Sekunden lang eine Begrenzung der Versuche fällig werden.
• [C-1-6] MÜSSEN eine hardwaregestützte Schlüsselspeicherimplementierung haben und den Fingerabdruckabgleich in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) oder auf einem Chip mit einem sicheren Kanal zum TEE durchführen.
• [C-1-7] MÜSSEN alle identifizierbaren Fingerabdruckdaten verschlüsselt und kryptografisch authentifiziert werden, sodass sie nicht außerhalb des TEE erfasst, gelesen oder geändert werden können, oder über einen Chip mit einem sicheren Kanal zum TEE, wie in den Implementierungsrichtlinien auf der Website des Android Open Source Project beschrieben.
• [C-1-8] MÜSSEN verhindern, dass ein Fingerabdruck hinzugefügt wird, ohne zuerst eine Vertrauenskette zu schaffen. Dazu muss der Nutzer die vorhandenen Anmeldedaten bestätigen oder neue, durch TEE gesicherte Geräteanmeldedaten hinzufügen (PIN/Muster/Passwort). Die Implementierung des Android Open Source Project stellt den entsprechenden Mechanismus im Framework bereit.
• [C-1-9] DÜRFEN Anwendungen von Drittanbietern NICHT aktivieren, um zwischen individuellen Fingerabdrücken zu unterscheiden.
• [C-1-10] MUSS die Kennzeichnung „DevicePolicyManager.KEYGUARD_DISABLE_FINGERPrint“ berücksichtigen.
• [C-1-11] Bei einem Upgrade von einer älteren Version als Android 6.0 MÜSSEN die Fingerabdruckdaten sicher migriert oder entfernt werden, damit sie die oben genannten Anforderungen erfüllen.
• [C-1-12] MÜSSEN alle identifizierbaren Fingerabdruckdaten eines Nutzers vollständig entfernen, wenn das Konto des Nutzers entfernt wird (auch über das Zurücksetzen auf die Werkseinstellungen).
• [C-1-13] DÜRFEN dem Anwendungsprozessor den unverschlüsselten Zugriff auf identifizierbare Fingerabdruckdaten oder daraus abgeleitete Daten (z. B. Einbettungen) nicht gestatten.
• [SR] Wir empfehlen dringend, eine Rate falscher Ablehnungen von weniger als 10 % (gemessen am Gerät) zu haben.
• [SR] wird dringend empfohlen, eine Latenz von unter einer Sekunde zu haben, gemessen ab dem Berühren des Fingerabdrucksensors bis zum Entsperren des Displays für einen registrierten Finger.
• SOLLTE das Android-Fingerabdrucksymbol aus dem Android Open Source Project verwenden.

7.3.10.2 Andere biometrische Sensoren

Wenn Geräteimplementierungen einen oder mehrere biometrische Sensoren ohne Fingerabdruck enthalten und für Drittanbieter-Apps verfügbar machen, gilt Folgendes:

• [C-1-1] MUSS eine falsche Annahmequote von 0,002 % haben.
• [C-SR] wird dringend empfohlen, eine Akzeptanzrate von Parodien und Hochstapler-Syndrom zu verwenden, die nicht über 7 % liegt.
• [C-1-2] MÜSSEN darauf hinweisen, dass dieser Modus möglicherweise weniger sicher ist als eine starke PIN, ein starkes Muster oder ein starkes Passwort. Außerdem müssen die Risiken einer Aktivierung klar angegeben werden, wenn die Annahmequoten durch Spoofing und Hochstapler-Betrüger über 7 % liegen.
• [C-1-3] MUSS die Anzahl der Versuche zur biometrischen Überprüfung mindestens 30 Sekunden lang begrenzt werden, wenn ein falscher Versuch ein Test mit einer angemessenen Erfassungsqualität (ACQUIRED_GOOD) ist, die nicht mit einem registrierten biometrischen Verfahren übereinstimmt.
• [C-1-4] MÜSSEN eine hardwaregestützte Schlüsselspeicherimplementierung haben und den biometrischen Abgleich in einem TEE oder auf einem Chip mit einem sicheren Kanal zum TEE durchführen.
• [C-1-5] MÜSSEN alle identifizierbaren Daten verschlüsselt und kryptografisch authentifiziert haben, sodass sie nicht außerhalb des TEE beschafft, gelesen oder geändert werden können, oder über einen Chip mit einem sicheren Kanal zum TEE, wie in den Implementierungsrichtlinien auf der Website des Android Open Source Project beschrieben.
• [C-1-6] MÜSSEN das Hinzufügen neuer biometrischer Daten verhindern, ohne zuvor eine Vertrauenskette zu schaffen. Dazu muss der Nutzer das Vorhandensein vorhandener Anmeldedaten bestätigen oder neue Geräteanmeldedaten (PIN/Muster/Passwort) hinzufügen, die durch TEE gesichert sind. Die Implementierung des Android Open Source Project stellt den entsprechenden Mechanismus im Framework bereit.
• [C-1-7] DÜRFEN Anwendungen von Drittanbietern NICHT aktivieren, um zwischen biometrischen Registrierungen zu unterscheiden.
• [C-1-8] MUSS die individuelle Kennzeichnung für dieses biometrische Verfahren (d. h. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE oder DevicePolicymanager.KEYGUARD_DISABLE_IRIS) berücksichtigen.
• [C-1-9] MÜSSEN alle identifizierbaren biometrischen Daten eines Nutzers vollständig entfernen, wenn das Konto des Nutzers entfernt wird (auch über das Zurücksetzen auf die Werkseinstellungen).
• [C-1-10] DÜRFEN dem Anwendungsprozessor den unverschlüsselten Zugriff auf identifizierbare biometrische Daten oder daraus abgeleitete Daten (z. B. Einbettungen) außerhalb des Kontexts des TEE nicht gestatten.
• [C-SR] Wir empfehlen dringend, eine Rate falscher Ablehnungen von weniger als 10 % (gemessen am Gerät) zu haben.
• [C-SR] Für jedes registrierte biometrische Verfahren wird dringend eine Latenz von unter 1 Sekunde empfohlen, gemessen ab dem Zeitpunkt, an dem das biometrische Verfahren erkannt wird, bis zum Entsperren des Bildschirms.

7.3.11 Reine Android Automotive-Sensoren

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

7.3.11.1 Aktuelles Getriebe

Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.11.2 Tag-/Nachtmodus

Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.11.3 Fahrstatus

Diese Anforderung wurde eingestellt.

7.3.11.4 Radgeschwindigkeit

Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.11.5 Feststellbremse

Informationen zu gerätespezifischen Anforderungen finden Sie in Abschnitt 2.5.1.

7.3.12 Positionssensor

Geräteimplementierungen:

• KANN Positionssensor mit 6 Freiheitsgraden unterstützen.

Wenn Geräteimplementierungen einen Positionssensor mit 6 Freiheitsgraden unterstützen, ist Folgendes möglich:

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

Der von den Android-APIs verwendete Begriff "Telefonie" bezieht sich in diesem Dokument speziell auf Hardware für das Tätigen von Sprachanrufen und das Senden von SMS-Nachrichten über ein GSM- oder CDMA-Netzwerk. Auch wenn diese Sprachanrufe Paketvermittlung sein können oder nicht, gelten sie im Rahmen von Android als unabhängig von Datenverbindungen, die über dasselbe Netzwerk implementiert werden. Mit anderen Worten: Die Android-Telefoniefunktionen und APIs beziehen sich speziell auf Sprachanrufe und SMS. Beispielsweise gelten Geräteimplementierungen, die keine Anrufe tätigen oder keine SMS senden/empfangen können, nicht als Telefoniegerät, unabhängig davon, ob sie ein Mobilfunknetz für die Datenkonnektivität verwenden.

• Android KANN auf Geräten ohne Telefonie-Hardware verwendet werden. Das heißt, Android ist mit Geräten kompatibel, die keine Smartphones sind.

Wenn Geräteimplementierungen GSM- oder CDMA-Telefonie umfassen, gilt Folgendes:

• [C-1-1] MÜSSEN das Funktions-Flag „android.hardware.telephony“ und andere Flags für untergeordnete Elemente der Technologie entsprechend deklarieren.
• [C-1-2] MÜSSEN für diese Technologie den vollen Support für die API implementieren.

Wenn Geräteimplementierungen keine Telefoniehardware enthalten, gilt Folgendes:

• [C-2-1] MÜSSEN die vollständigen APIs als managementfrei implementieren.

7.4.1.1 Kompatibilität mit Nummernblockierungen

Wenn Geräteimplementierungen das android.hardware.telephony feature melden, geschieht Folgendes:

• [C-1-1] MUSS die Unterstützung für das Blockieren von Nummern enthalten.
• [C-1-2] MÜSSEN BlockedNumberContract und die entsprechende API vollständig implementieren, wie in der SDK-Dokumentation beschrieben.
• [C-1-3] MÜSSEN alle Anrufe und Nachrichten von einer Telefonnummer in „BlockingNumberProvider“ ohne Interaktion mit Apps blockieren. Die einzige Ausnahme ist, wenn die Blockierung von Nummern vorübergehend aufgehoben wird, wie in der SDK-Dokumentation beschrieben.
• [C-1-4] Bei einem blockierten Anruf DARF NICHT in den Plattformanbieter der Anrufliste geschrieben werden.
• [C-1-5] Bei einer blockierten Nachricht DARF NICHT an den Telefonieanbieter geschrieben werden.
• [C-1-6] MÜSSEN eine UI für die Verwaltung blockierter Nummern implementieren, die mit dem von der Methode TelecomManager.createManageBlockedNumbersIntent() zurückgegebenen Intent geöffnet wird.
• [C-1-7] Sie dürfen sekundären Nutzern NICHT erlauben, die blockierten Nummern auf dem Gerät anzusehen oder zu bearbeiten, da die Android-Plattform davon ausgeht, dass der primäre Nutzer die vollständige Kontrolle über die Telefoniedienste auf dem Gerät in einer einzigen Instanz hat. Alle Benutzeroberflächen zu Blockierungen MÜSSEN für sekundäre Nutzer ausgeblendet werden und die Liste der blockierten Nutzer MÜSSEN weiterhin berücksichtigt werden.
• SOLLTEN Sie die blockierten Nummern zum Anbieter migrieren, wenn ein Gerät auf Android 7.0 aktualisiert wird.

7.4.1.2 Telekommunikations-API

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

• [C-1-1] MUSS die im SDK beschriebenen ConnectionService APIs unterstützen.
• [C-1-2] MÜSSEN einen neuen eingehenden Anruf anzeigen und dem Nutzer die Möglichkeit bieten, den eingehenden Anruf anzunehmen oder abzulehnen, wenn der Nutzer gerade einen Anruf über eine Drittanbieter-App getätigt hat, die die über CAPABILITY_SUPPORT_HOLD angegebene Funktion zum Halten von Anrufen nicht unterstützt.

• [C-SR] wird dringend empfohlen, den Nutzer darüber zu informieren, dass ein eingehender Anruf unterbrochen wird, wenn er einen eingehenden Anruf annimmt.

  Die AOSP-Implementierung erfüllt diese Anforderungen durch eine Vorabbenachrichtigung, die den Nutzer darüber informiert, dass die Annahme eines eingehenden Anrufs dazu führt, dass der andere Anruf beendet wird.

• [C-SR] wird dringend empfohlen, die Standard-Telefon-App vorab zu laden, die einen Anruflisteneintrag und den Namen einer Drittanbieter-App in der Anrufliste anzeigt, wenn die Drittanbieter-App den EXTRA_LOG_SELF_MANAGED_CALLS-Extrasschlüssel auf der PhoneAccount auf true festlegt.

• [C-SR] wird dringend empfohlen, die KEYCODE_MEDIA_PLAY_PAUSE- und KEYCODE_HEADSETHOOK-Ereignisse des Audio-Headsets für die android.telecom APIs so zu verarbeiten:
  • Rufen Sie Connection.onDisconnect() auf, wenn während eines laufenden Anrufs nur kurz das Schlüsselereignis gedrückt wird.
  • Ruf Connection.onAnswer() an, wenn bei einem eingehenden Anruf nur kurzes Drücken des Schlüsselereignisses erkannt wird.
  • Rufe Connection.onReject() an, wenn bei einem eingehenden Anruf langes Drücken des Schlüsselereignisses erkannt wird.
  • Stummschaltung des CallAudioState aktivieren oder deaktivieren.

7.4.2 IEEE 802.11 (Wi-Fi)

Geräteimplementierungen:

• SOLLTEN eine oder mehrere 802.11-Formulare unterstützen.

Wenn Geräteimplementierungen 802.11 unterstützen und die Funktionalität einer Drittanbieter-App zur Verfügung stellen, geschieht Folgendes:

• [C-1-1] MÜSSEN die entsprechende Android API implementieren.
• [C-1-2] MÜSSEN das Hardwarefunktions-Flag android.hardware.wifi melden.
• [C-1-3] MÜSSEN die Multicast API wie in der SDK-Dokumentation beschrieben implementieren.
• [C-1-4] MÜSSEN Multicast-DNS (mDNS) unterstützen und mDNS-Pakete (224.0.0.251) zu keinem Zeitpunkt des Betriebs filtern, darunter:
  • Auch wenn der Bildschirm nicht aktiv ist.
  • Für Android TV-Geräteimplementierungen, auch im Stand-by-Modus.
• [C-1-5] DARF NICHT den API-Methodenaufruf WifiManager.enableNetwork() als ausreichenden Hinweis zum Ändern der derzeit aktiven Network behandeln, die standardmäßig für Anwendungstraffic verwendet und von ConnectivityManager-API-Methoden wie getActiveNetwork und registerDefaultNetworkCallback zurückgegeben wird. Anders ausgedrückt: Sie können den Internetzugriff, der von einem anderen Netzwerkanbieter zur Verfügung gestellt wird (z.B. mobile Daten), nur dann deaktivieren, wenn sie bestätigen konnten, dass das WLAN den Internetzugriff bereitstellt.
• [C-SR] werden UNBEDINGT empfohlen, wenn die API-Methode ConnectivityManager.reportNetworkConnectivity() aufgerufen wird, um den Internetzugriff auf der Network neu zu bewerten. Sobald die Bewertung ergibt, dass das aktuelle Network keinen Internetzugriff mehr bietet, wechseln Sie zu einem anderen verfügbaren Netzwerk (z. B. mobiler Daten), das Internetzugriff bietet.
• [C-SR] Es wird dringend empfohlen, die MAC-Quelladresse und die Sequenznummer der Prüfungsanfrageframes einmal zu Beginn jedes Scans zufällig zu wählen, während die STA getrennt ist.
  • Jede Gruppe von Prüfungsanfrageframes, die einen Scan enthalten, sollte eine konsistente MAC-Adresse verwenden (MAC-Adresse sollte NICHT nach der Hälfte des Scans zufällig ausgewählt werden).
  • Die Sequenznummer der Prüfungsanfrage sollte wie gewohnt (sequentiell) zwischen den Prüfungsanfragen in einem Scan iterieren.
  • Die Sequenznummer der Prüfungsanfrage sollte zufällig zwischen der letzten Prüfungsanfrage eines Scans und der ersten Prüfungsanfrage des nächsten Scans liegen.
• [C-SR] werden dringend empfohlen, auch wenn die STA getrennt ist, damit nur die folgenden Elemente in Prüfungsanfrageframes zugelassen werden:
  • SSID-Parametersatz (0)
  • DS-Parametersatz (3)

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

• [C-2-1] MÜSSEN eine Nutzeroption zum Aktivieren/Deaktivieren des Werts bereitstellen, der über die API-Methode WifiManager.isScanAlwaysAvailable gelesen wird.

7.4.2.1 Wi-Fi Direct

Geräteimplementierungen:

• SOLLTE Unterstützung für Wi-Fi Direct (Wi-Fi Peer-to-Peer) beinhalten.

Wenn Geräteimplementierungen Wi-Fi Direct unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN 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 normalen WLAN-Betrieb unterstützen.
• [C-1-4] MUSS die gleichzeitige Verwendung von Wi-Fi und Wi-Fi Direct unterstützen.

7.4.2.2 WLAN: Tunneled Direct Link-Einrichtung

Geräteimplementierungen:

• SOLLTE Unterstützung für Wi-Fi Tunneled Direct Link Setup (TDLS) beinhalten, wie in der Android SDK-Dokumentation beschrieben.

Wenn Geräteimplementierungen die Unterstützung für TDLS und TDLS durch die WiFiManager API aktivieren, geschieht Folgendes:

• [C-1-1] MÜSSEN die Unterstützung für TDLS über WifiManager.isTdlsSupported deklarieren.
• SOLLTEN TDLS nur verwenden, wenn es möglich UND vorteilhaft ist.
• SOLLTEN heuristisch sein und KEINE TDLS verwenden, wenn die Leistung schlechter ist als die Nutzung des WLAN-Zugangspunkts.

7.4.2.3 WLAN-fähig

Geräteimplementierungen:

• SOLLTE Support für Wi-Fi Aware beinhalten.

Wenn Geräteimplementierungen Wi-Fi Aware unterstützen und die Funktion in Drittanbieter-Apps verfügbar sind, gilt Folgendes:

• [C-1-1] MÜSSEN die WifiAwareManager APIs wie in der SDK-Dokumentation beschrieben implementieren.
• [C-1-2] MÜSSEN das Funktions-Flag android.hardware.wifi.aware deklarieren.
• [C-1-3] MUSS die gleichzeitige Verwendung von WLAN und Wi-Fi Aware unterstützen.
• [C-1-4] MÜSSEN die Adresse der Wi-Fi Aware-Verwaltungsoberfläche in Abständen von maximal 30 Minuten zufällig anordnen, wenn WLAN Aware aktiviert ist.

Wenn Geräteimplementierungen die in Abschnitt 7.4.2.5 beschriebenen Unterstützung für Wi-Fi Aware und die Funktion „WLAN-Standort“ enthalten und diese Funktionen in Drittanbieter-Apps verfügbar sind, gilt Folgendes:

• [C-2-1] MÜSSEN die APIs zur Standorterkennung implementieren: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm und onServiceDiscoveredWithinRange.

7.4.2.4 WLAN-Passpoint

Geräteimplementierungen:

• SOLLTEN Unterstützung für WLAN-Passpoint beinhalten.

Wenn Geräteimplementierungen Wi-Fi Passpoint unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN die Passpoint-bezogenen WifiManager APIs wie in der SDK-Dokumentation beschrieben implementieren.
• [C-1-2] MÜSSEN den IEEE 802.11u-Standard unterstützen, insbesondere in Bezug auf die Netzwerkerkennung und -auswahl, z. B. Generic Advertising Service (GAS) und Access Network Query Protocol (ANQP).

Umgekehrt gilt, wenn Geräteimplementierungen keinen Wi-Fi-Passpoint unterstützen:

• [C-2-1] Die Implementierung der Passpoint-bezogenen WifiManager APIs MÜSSEN eine UnsupportedOperationException auslösen.

7.4.2.5 WLAN-Standort (WLAN-Umlaufzeit – RTT)

Geräteimplementierungen:

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

Wenn Geräteimplementierungen die Funktion „WLAN-Standort“ unterstützen und die Funktion in Drittanbieter-Apps verfügbar sind, gilt Folgendes:

• [C-1-1] MÜSSEN die WifiRttManager APIs wie in der SDK-Dokumentation beschrieben implementieren.
• [C-1-2] MÜSSEN das Funktions-Flag android.hardware.wifi.rtt deklarieren.
• [C-1-3] MÜSSEN die MAC-Quelladresse für jeden RTT-Burst zufällig anordnen, während die WLAN-Schnittstelle, auf der die RTT ausgeführt wird, keinem Zugangspunkt zugeordnet ist.

7.4.3 Bluetooth

Wenn Geräteimplementierungen das Bluetooth Audio-Profil unterstützen, gilt Folgendes:

• Erweiterte Audio-Codecs und Bluetooth-Audio-Codecs (z.B. LDAC) sollten unterstützt werden.

Wenn Geräteimplementierungen HFP, A2DP und AVRCP unterstützen, gilt Folgendes:

• SOLLTEN mindestens 5 verbundene Geräte unterstützen.

Wenn in Geräteimplementierungen die Funktion android.hardware.vr.high_performance deklariert wird, geschieht Folgendes:

• [C-1-1] MÜSSEN Bluetooth 4.2 und Bluetooth LE-Datenlängenerweiterung unterstützen.

Android unterstützt Bluetooth und Bluetooth Low Energy.

Wenn Geräteimplementierungen Bluetooth und Bluetooth Low Energy unterstützen, gilt Folgendes:

• [C-2-1] MÜSSEN die relevanten Plattformfunktionen (android.hardware.bluetooth bzw. android.hardware.bluetooth_le) deklarieren und die Plattform-APIs implementieren.
• SOLLTEN Sie je nach Gerät entsprechende Bluetooth-Profile wie A2DP, AVRCP, OBEX, HFP usw. implementieren.

Wenn Geräteimplementierungen Bluetooth Low Energy unterstützen, gilt Folgendes:

• [C-3-1] MÜSSEN die Hardwarefunktion android.hardware.bluetooth_le deklarieren.
• [C-3-2] MÜSSEN die auf GATT (allgemeinen Attributprofil) basierenden Bluetooth-APIs aktivieren, wie in der SDK-Dokumentation und unter android.bluetooth beschrieben.
• [C-3-3] MÜSSEN den richtigen Wert für BluetoothAdapter.isOffloadedFilteringSupported() melden, um anzugeben, ob die Filterlogik für die ScanFilter API-Klassen implementiert ist.
• [C-3-4] MÜSSEN den richtigen Wert für BluetoothAdapter.isMultipleAdvertisementSupported() melden, um anzugeben, ob Werbung mit geringem Energieverbrauch unterstützt wird.
• SOLLTEN bei der Implementierung der ScanFilter API die Übertragung der Filterlogik auf den Bluetooth-Chipsatz unterstützen.
• SOLLTEN die Übertragung des Batch-Scans auf den Bluetooth-Chipsatz unterstützen.

• SOLLTEN mehrere Anzeigen mit mindestens 4 Anzeigenflächen unterstützen.

• [SR] UNBEDINGT EMPFOHLEN, eine Zeitüberschreitung für die auflösbare Privatadresse (RPA) zu implementieren, die maximal 15 Minuten beträgt und die Adresse bei einer Zeitüberschreitung rotieren, um die Privatsphäre 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] MÜSSEN eine Funktion zum Aktivieren/Deaktivieren des über die System-API BluetoothAdapter.isBleScanAlwaysAvailable() gelesenen Werts bieten.

7.4.4 Nahfeldkommunikation

Geräteimplementierungen:

• SOLLTEN ein Transceiver und die zugehörige Hardware für die Nahfeldkommunikation (NFC) enthalten.
• [C-0-1] MÜSSEN die APIs android.nfc.NdefMessage und android.nfc.NdefRecord implementieren, auch wenn sie keine NFC-Unterstützung bieten oder die android.hardware.nfc-Funktion nicht deklarieren, da die Klassen ein protokollunabhängiges Datendarstellungsformat darstellen.

Wenn Geräteimplementierungen NFC-Hardware enthalten und für Drittanbieter-Apps verfügbar sein sollen, geschieht 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 gemäß der technischen Spezifikation „NFCForum-TS-DigitalProtocol-1.0“ des NFC-Forums über die folgenden NFC-Standards als Lese-/Schreiber im NFC-Forum fungieren können:
  • NfcA (ISO14443-3A)
  • NFCB (ISO 14443-3B)
  • NFCF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • NFC-Forum Tag-Typen 1, 2, 3, 4, 5 (definiert vom NFC-Forum)

• [SR] EMPFOHLEN, NDEF-Nachrichten sowie Rohdaten über die folgenden NFC-Standards zu lesen und zu schreiben. Beachten Sie, dass die NFC-Standards zwar als UNBEDINGT EMPFOHLEN angegeben sind, diese jedoch in der Kompatibilitätsdefinition für eine zukünftige Version zu MUSS geändert werden sollen. Diese Standards sind in dieser Version optional, werden aber in zukünftigen Versionen erforderlich sein. Bestehenden und neuen Geräten, auf denen diese Android-Version ausgeführt wird, wird dringend empfohlen, diese Anforderungen schon jetzt zu erfüllen, damit ein Upgrade auf die zukünftigen Plattform-Releases möglich ist.

• [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-Protokoll
  • SNEP 1.0 (definiert vom NFC-Forum)
• [C-1-4] MÜSSEN Android Beam unterstützen und Android Beam standardmäßig aktivieren.
• [C-1-5] MÜSSEN mit Android Beam senden und empfangen können, wenn Android Beam oder ein anderer proprietärer NFC-P2p-Modus aktiviert ist.
• [C-1-6] MÜSSEN den SNEP-Standardserver implementieren. Gültige NDEF-Nachrichten, die vom Standard-SNEP-Server empfangen werden, MÜSSEN an Anwendungen mit dem Intent android.nfc.ACTION_NDEF_DISCOVERED weitergeleitet werden. Durch die Deaktivierung von Android Beam in den Einstellungen DARF NICHT die Weiterleitung eingehender NDEF-Nachrichten deaktiviert werden.
• [C-1-7] MÜSSEN den Intent android.settings.NFCSHARING_SETTINGS berücksichtigen, um die NFC-Freigabeeinstellungen anzuzeigen.
• [C-1-8] MÜSSEN den NPP-Server implementieren. Nachrichten, die vom NPP-Server empfangen werden, MÜSSEN genauso verarbeitet werden wie der SNEP-Standardserver.
• [C-1-9] MÜSSEN 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, eine Nachricht an einen NPP-Server zu senden.
• [C-1-10] MÜSSEN Aktivitäten im Vordergrund zulassen, um die ausgehende P2P-NDEF-Nachricht mit android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback und android.nfc.NfcAdapter.enableForegroundNdefPush festzulegen.
• SOLLTEN Sie vor dem Senden ausgehender P2P-NDEF-Nachrichten eine Geste oder eine Bestätigung auf dem Bildschirm verwenden, z. B. „Zum Beamen berühren“.
• [C-1-11] MÜSSEN die NFC-Verbindungsübergabe an Bluetooth unterstützen, wenn das Gerät das Bluetooth-Objekt Push-Profil unterstützt.
• [C-1-12] MÜSSEN bei Verwendung von android.nfc.NfcAdapter.setBeamPushUris die Verbindungsübergabe zu Bluetooth unterstützen. Dazu müssen die Spezifikationen für Connection Handover Version 1.2 und Bluetooth Secure Simple Pairing Using NFC Version 1.0 aus dem NFC-Forum implementiert werden. Eine solche Implementierung MÜSSEN den Handover LLCP-Dienst mit dem Dienstnamen „urn:nfc:sn:handover“ für den Austausch der Handover-Anfrage-/Auswahleinträge über NFC implementieren. Außerdem MUSS das Bluetooth Object Push Profile für die eigentliche Bluetooth-Datenübertragung verwendet werden. Aus Gründen der Kompatibilität mit Android 4.1-Geräten SOLLTE die Implementierung weiterhin SNEP-GET-Anfragen für den Austausch der Handover-Anfrage/die Auswahl von Einträgen über NFC akzeptieren. Die Implementierung selbst sollte jedoch KEINE SNEP GET-Anfragen zur Durchführung eines Verbindungs-Handovers senden.
• [C-1-13] MÜSSEN im NFC-Erkennungsmodus alle unterstützten Technologien abfragen.
• Muss sich im NFC-Erkennungsmodus befinden, wenn das Gerät aktiv ist, der Bildschirm aktiv und der Sperrbildschirm entsperrt ist.
• SOLLTEN Barcode und URL (falls codiert) von Thinfilm-NFC-Barcode-Produkten lesen können.

Beachten Sie, dass öffentlich verfügbare Links für die oben genannten Spezifikationen des JIS-, ISO- und NFC-Forums nicht verfügbar sind.

Android unterstützt den NFC-Modus "Host Card Emulation" (HCE).

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz (für NfcA und/oder NfcB) enthalten und das Routing nach Anwendungs-ID (AID) unterstützen, gilt Folgendes:

• [C-2-1] MÜSSEN die android.hardware.nfc.hce-Funktionskonstante melden.
• [C-2-2] MÜSSEN die im Android SDK definierten NFC HCE APIs unterstützen.

Wenn Geräteimplementierungen einen HCE-fähigen NFC-Controller-Chipsatz für NfcF enthalten und die Funktion für Drittanbieteranwendungen implementiert ist, gilt Folgendes:

• [C-3-1] MÜSSEN die android.hardware.nfc.hcef-Funktionskonstante melden.
• [C-3-2] MÜSSEN die NfcF Card Emulation APIs wie im Android SDK definiert implementieren.

Wenn Geräteimplementierungen allgemeine NFC-Unterstützung wie in diesem Abschnitt beschrieben und MIFARE-Technologien (MIFARE Classic, MIFARE Ultralight, NDEF auf MIFARE Classic) in der Rolle „Reader/Writer“ unterstützen, gilt Folgendes:

• [C-4-1] MÜSSEN die entsprechenden Android-APIs gemäß der Dokumentation des Android SDK implementieren.
• [C-4-2] MÜSSEN die Funktion com.nxp.mifare über die Methode android.content.pm.PackageManager.hasSystemFeature() melden. Beachten Sie, dass dies keine Android-Standardfunktion ist und daher nicht als Konstante in der android.content.pm.PackageManager-Klasse angezeigt wird.

7.4.5 Minimale Netzwerkfähigkeit

Geräteimplementierungen:

• [C-0-1] MÜSSEN Support für eine oder mehrere Formen von Datennetzwerken bereitstellen. Insbesondere MÜSSEN Geräteimplementierungen Unterstützung für mindestens einen Datenstandard beinhalten, der 200 kbit/s oder mehr unterstützen kann. Beispiele für Technologien, die diese Anforderung erfüllen, sind EDGE, HSPA, EV-DO, 802.11g, Ethernet und Bluetooth PAN.
• SOLLTEN auch mindestens einen gängigen Standard für drahtlose Daten, z. B. 802.11 (Wi-Fi), unterstützen, wenn ein physischer Netzwerkstandard (z. B. Ethernet) die primäre Datenverbindung ist.
• KANN mehr als eine Form der Datenverbindung implementieren.
• [C-0-2] MÜSSEN einen IPv6-Netzwerkstack enthalten und IPv6-Kommunikation über die verwalteten APIs (z. B. 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.
• MÜSSEN sicherstellen, dass die IPv6-Kommunikation so zuverlässig ist wie IPv4, z. B.:
  • [C-0-4] MÜSSEN die IPv6-Verbindungen im Stromsparmodus aufrechterhalten.
  • [C-0-5] Die Ratenbegrenzung DARF NICHT dazu führen, dass das Gerät die IPv6-Verbindung in einem IPv6-kompatiblen Netzwerk verliert, dessen RA-Lebensdauer mindestens 180 Sekunden beträgt.
• [C-0-6] MÜSSEN Anwendungen von Drittanbietern eine direkte IPv6-Verbindung zum Netzwerk bereitstellen, wenn sie mit einem IPv6-Netzwerk verbunden sind. Eine lokale Adress- oder Portübersetzung darf dabei nicht lokal auf dem Gerät erfolgen. 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.

Die erforderliche IPv6-Unterstützung hängt vom Netzwerktyp ab, wie in den folgenden Anforderungen dargestellt.

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

• [C-1-1] MÜSSEN Dual-Stack- und Nur-IPv6-Betrieb im WLAN unterstützen.

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

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

Wenn Geräteimplementierungen mobile Daten unterstützen, gilt Folgendes:

• SOLLTE IPv6-Betrieb (nur IPv6 und möglicherweise Dual-Stack) auf Mobilfunk unterstützen.

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

• [C-3-1] MÜSSEN die oben genannten Anforderungen für jedes Netzwerk gleichzeitig erfüllen, wenn das Gerät gleichzeitig mit mehr als einem Netzwerktyp verbunden ist.

7.4.6 Synchronisierungseinstellungen

Geräteimplementierungen:

• [C-0-1] MÜSSEN die automatische Mastersynchronisierung standardmäßig aktiviert sein, damit die Methode getMasterSyncAutomatically() den Wert „true“ zurückgibt.

7.4.7 Datensparmodus

Wenn Geräteimplementierungen eine getaktete Verbindung beinhalten, gilt Folgendes:

• [SR] UNBEDINGT EMPFOHLEN, den Datensparmodus bereitzustellen.

Wenn Geräteimplementierungen den Datensparmodus unterstützen, ist Folgendes möglich:

• [C-1-1] MUSS alle APIs der ConnectivityManager-Klasse unterstützen, wie in der SDK-Dokumentation beschrieben.
• [C-1-2] MÜSSEN in den Einstellungen eine Benutzeroberfläche bereitstellen, die den Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS-Intent verarbeitet und es Nutzern ermöglicht, Anwendungen zur Zulassungsliste hinzuzufügen oder von ihr zu entfernen.

Wenn Geräteimplementierungen den Datensparmodus nicht unterstützen, kann das folgende Gründe haben:

• [C-2-1] MUSS den Wert RESTRICT_BACKGROUND_STATUS_DISABLED für ConnectivityManager.getRestrictBackgroundStatus() zurückgeben.
• [C-2-2] DÜRFEN KEINE ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED übertragen.
• [C-2-3] MÜSSEN über eine Aktivität verfügen, die den Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS-Intent verarbeitet, diese jedoch KANN als "No-Op" implementiert werden.

7.4.8 Secure Elemente

Wenn Geräteimplementierungen Open Mobile API-fähige sichere Elemente unterstützen und für Drittanbieter-Apps verfügbar machen, geschieht Folgendes:

• [C-1-1] MÜSSEN die verfügbaren Secure Elements-Leser aufzählen, wenn die Methode android.se.omapi.SEService.getReaders() aufgerufen wird.

7.5 Kameras

Wenn eine Geräteimplementierung mindestens eine Kamera umfasst, gilt Folgendes:

• [C-1-1] MUSS das Funktions-Flag android.hardware.camera.any deklarieren.
• [C-1-2] MÜSSEN in einer Anwendung gleichzeitig 3 RGBA_8888-Bitmaps zugewiesen werden, die der Größe der Bilder entsprechen, die der Kamerasensor mit der höchsten Auflösung des Geräts erzeugt, während die Kamera für eine einfache Vorschau und dennoch für Aufnahmen geöffnet ist.

7.5.1 Rückkamera

Eine Kamera auf der Rückseite ist eine Kamera, die sich an der Seite des Geräts gegenüber dem Display befindet. Sie nimmt also wie bei einer herkömmlichen Kamera Szenen auf der anderen Seite des Geräts auf.

Geräteimplementierungen:

• SOLLTE eine Rückkamera enthalten.

Wenn Geräteimplementierungen mindestens eine Kamera auf der Rückseite enthalten, ist Folgendes zu beachten:

• [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 Megapixel haben.
• Im Kameratreiber sollte entweder Hardware-Autofokus oder Software-Autofokus implementiert sein (für die Anwendungssoftware transparent).
• KÖNNEN mit Fixfokus oder EDOF-Hardware (erweiterte Tiefenschärfe) ausgestattet sein.
• KANN einen Blitz enthalten.

Wenn die Kamera einen Blitz hat:

• [C-2-1] Die Blitzlampe DARF NICHT eingeschaltet werden, solange eine android.hardware.Camera.PreviewCallback-Instanz auf einer Kameravorschauoberfläche registriert ist, 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 ist eine Kamera, die sich an der gleichen Seite des Geräts wie das Display befindet. Das ist eine Kamera, die in der Regel zum Abbilden des Nutzers verwendet wird, z. B. für Videokonferenzen und ähnliche Anwendungen.

Geräteimplementierungen:

• KANN eine Frontkamera enthalten.

Wenn Geräteimplementierungen mindestens eine Frontkamera umfassen, ist Folgendes zu beachten:

• [C-1-1] MÜSSEN die Funktions-Flags android.hardware.camera.any und android.hardware.camera.front melden.
• [C-1-2] MUSS mindestens eine Auflösung von mindestens VGA (640 x 480 Pixel) haben.
• [C-1-3] DÜRFEN KEINE Frontkamera als Standard für die Camera API verwenden und die API DARF NICHT so konfiguriert werden, dass eine Frontkamera als Standardrückkamera behandelt wird, selbst wenn sie die einzige Kamera des Geräts ist.
• [C-1-4] Die Kameravorschau MUSS horizontal relativ zur von der App angegebenen Ausrichtung gespiegelt werden, wenn die aktuelle Anwendung ausdrücklich das Drehen des Kameradisplays über einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() angefordert hat. Umgekehrt muss die Vorschau entlang der horizontalen Standardachse des Geräts gespiegelt werden, wenn die aktuelle Anwendung das Drehen des Kameradisplays nicht explizit über einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation() anfordert.
• [C-1-5] DÜRFEN NICHT die endgültigen aufgenommenen Standbilder oder Videostreams spiegeln, die an Anwendungsrückrufe zurückgegeben oder in den Medienspeicher übergeben werden.
• [C-1-6] MÜSSEN das im PostView angezeigte Bild auf dieselbe Weise spiegeln wie im Bildstream der Kameravorschau.
• KÖNNEN Funktionen wie Autofokus, Blitz usw. für Rückkameras enthalten, 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 Nutzereingabe):

• [C-2-1] Die Kameravorschau MUSS horizontal relativ zur aktuellen Ausrichtung des Geräts gespiegelt werden.

7.5.3 Externe Kamera

Geräteimplementierungen:

• KÖNNEN Support für eine externe Kamera anbieten, die nicht unbedingt immer angeschlossen ist.

Wenn Geräteimplementierungen eine externe Kamera unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN die Funktions-Flags für die Plattform android.hardware.camera.external und android.hardware camera.any deklarieren.
• [C-1-2] MÜSSEN die USB-Videoklasse (UVC 1.0 oder höher) unterstützen, wenn die externe Kamera über den USB-Hostport verbunden wird.
• [C-1-3] MÜSSEN die CTS-Tests der Kamera mit einem angeschlossenen physischen Kameragerät bestehen. Details zu den CTS-Tests für Kameras finden Sie unter source.android.com.
• SOLLTEN Videokomprimierungen wie MJPEG unterstützen, um die Übertragung von qualitativ nicht codierten Streams (rohe oder unabhängig komprimierte Bildstreams) zu ermöglichen.
• KANN mehrere Kameras unterstützen.
• KANN die kamerabasierte Videocodierung unterstützen.

Wenn die kamerabasierte Videocodierung unterstützt wird:

• [C-2-1] Ein gleichzeitiger, nicht codierter / 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 ermöglicht die Steuerung der Kamera auf niedrigerer Ebene für die App, einschließlich effizienter Zero-Copy-Burst-/Streaming-Abläufe und Steuerungen pro Frame für Belichtung, Verstärkung, Weißabgleichzunahme, Farbkonvertierung, Geräuschunterdrückung, Schärfe und mehr.

Das ältere API-Paket android.hardware.Camera ist in Android 5.0 als veraltet gekennzeichnet, sollte aber weiterhin für Apps zur Verfügung stehen. Bei Implementierungen von Android-Geräten MÜSSEN die API wie in diesem Abschnitt und im Android SDK beschrieben weiterhin unterstützt werden.

Alle Funktionen, die in den veralteten Versionen der Klasse „android.hardware.Camera“ und dem neueren Paket „android.hardware.camera2“ vorkommen, MÜSSEN in beiden APIs gleichwertige Leistung und Qualität aufweisen. Beispielsweise müssen bei gleichwertigen Einstellungen die Geschwindigkeit und Genauigkeit des Autofokus sowie die Qualität der aufgenommenen Bilder identisch sein. Funktionen, die von der unterschiedlichen Semantik der beiden APIs abhängen, müssen nicht unbedingt eine übereinstimmende Geschwindigkeit oder Qualität haben, SOLLTEN aber so genau wie möglich übereinstimmen.

Bei Geräteimplementierungen MÜSSEN für alle verfügbaren Kameras die folgenden Verhaltensweisen für die kamerabezogenen APIs implementiert werden. Geräteimplementierungen:

• [C-0-1] MUSS android.hardware.PixelFormat.YCbCr_420_SP für Vorschaudaten verwenden, die App-Callbacks zur Verfügung gestellt werden, wenn eine App android.hardware.Camera.Parameters.setPreviewFormat(int) nie aufgerufen hat.
• [C-0-2] MÜSSEN weiterhin im NV21-Codierungsformat vorliegen, wenn eine Anwendung eine android.hardware.Camera.PreviewCallback-Instanz registriert, das System die onPreviewFrame()-Methode aufruft und das Vorschauformat YCbCr_420_SP ist. Die Daten im Byte[] werden an onPreviewFrame() übergeben. Das heißt, NV21 MUSS die Standardeinstellung sein.
• [C-0-3] MUSS das YV12-Format (wie durch die Konstante android.graphics.ImageFormat.YV12 angegeben) für die Kameravorschau der Front- und Rückkameras für android.hardware.Camera unterstützen. Der Hardware-Videoencoder und die Kamera können jedes native Pixelformat verwenden. Die Geräteimplementierung muss jedoch die Konvertierung in YV12 unterstützen.
• [C-0-4] MUSS 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 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE-Funktion in android.request.availableCapabilities bewerben.
• [C-0-5] MÜSSEN weiterhin die vollständige Camera API implementieren, die in der Android SDK-Dokumentation enthalten ist, unabhängig davon, ob das Gerät über Hardware-Autofokus oder andere Funktionen verfügt. Kameras ohne Autofokus MÜSSEN beispielsweise alle registrierten android.hardware.Camera.AutoFocusCallback-Instanzen aufrufen, auch wenn dies für eine Kamera ohne Autofokus nicht relevant ist. Beachten Sie, dass dies für Frontkameras gilt. Auch wenn die meisten Frontkameras beispielsweise keinen Autofokus unterstützen, müssen die API-Callbacks wie beschrieben „gefälscht“ werden.
• [C-0-6] MÜSSEN jeden Parameternamen erkennen und berücksichtigen, der in der Klasse android.hardware.Camera.Parameters als Konstante definiert ist. Umgekehrt DÜRFEN Geräteimplementierungen keine Stringkonstanten, die an die Methode android.hardware.Camera.setParameters() übergeben werden, berücksichtigen oder erkennen, außer den, die als Konstanten in der android.hardware.Camera.Parameters dokumentiert sind. Das heißt, Geräteimplementierungen MÜSSEN alle standardmäßigen Kameraparameter unterstützen, wenn dies die Hardware zulässt. Benutzerdefinierte Kameraparametertypen DÜRFEN NICHT unterstützt werden. Beispielsweise MÜSSEN Geräteimplementierungen, die die Bilderfassung mit HDR-Bildverarbeitungstechniken unterstützen, den Kameraparameter Camera.SCENE_MODE_HDR unterstützen.
• [C-0-7] MÜSSEN die korrekte Unterstützung für die android.info.supportedHardwareLevel-Eigenschaft wie im Android SDK beschrieben und die entsprechenden Flags für Framework-Funktionen melden.
• [C-0-8] MÜSSEN auch die jeweiligen Kamerafunktionen von android.hardware.camera2 über die Property android.request.availableCapabilities sowie die entsprechenden Funktions-Flags deklarieren. MÜSSEN das Funktions-Flag definiert werden, wenn eine der angeschlossenen Kamerageräte diese Funktion unterstützt.
• [C-0-9] MÜSSEN den Intent Camera.ACTION_NEW_PICTURE übertragen, sobald mit der Kamera ein neues Bild aufgenommen und das Bild zum Medienspeicher hinzugefügt wurde.
• [C-0-10] MÜSSEN den Intent Camera.ACTION_NEW_VIDEO übertragen, sobald die Kamera ein neues Video aufzeichnet und das Bild zum Medienspeicher hinzugefügt wurde.
• [C-SR] wird dringend empfohlen, ein logisches Kameragerät mit den Funktionen CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA zu unterstützen, bei Geräten mit mehreren Kameras, die in die gleiche Richtung weisen, wobei jede physische Kamera in diese Richtung zeigt. Voraussetzung ist, dass 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äte eine Front- oder Rückkamera haben, z. B. eine oder mehrere Kameras:

• [C-1-1] MÜSSEN so ausgerichtet werden, dass die lange Seite der Kamera mit der des Bildschirms übereinstimmt. Wenn das Gerät also in Querformat gehalten wird, MÜSSEN Kameras Bilder im Querformat aufnehmen. Dies gilt unabhängig von der natürlichen Ausrichtung des Geräts, d. h. für Primärgeräte im Querformat sowie für Primärgeräte im Hochformat.

7.6 Arbeitsspeicher und Datenspeicher

7.6.1 Mindestanforderungen an Arbeitsspeicher und Speicherplatz

Geräteimplementierungen:

• [C-0-1] MÜSSEN einen Download-Manager bereitstellen, mit dem Anwendungen Datendateien herunterladen dürfen, und sie MÜSSEN in der Lage sein, einzelne Dateien mit einer Größe von mindestens 100 MB in den standardmäßigen Cache-Speicherort herunterzuladen.

7.6.2 Freigegebener Anwendungsspeicher

Geräteimplementierungen:

• [C-0-1] MÜSSEN Ihnen Speicher zur gemeinsamen Nutzung durch Anwendungen anbieten. Dieser Speicher wird oft als „freigegebener externer Speicher“ oder „freigegebener Anwendungsspeicher“ oder über den Linux-Pfad „/sdcard“ bezeichnet, auf dem der Speicher bereitgestellt ist.
• [C-0-2] MÜSSEN mit freigegebenem Speicher konfiguriert werden, d. h. standardmäßig bereitgestellt werden, unabhängig davon, ob der Speicher in einer internen Speicherkomponente oder einem Wechselmedium (z. B. Secure Digital-Kartensteckplatz) implementiert ist.
• [C-0-3] MÜSSEN den freigegebenen Speicher der Anwendung direkt unter dem Linux-Pfad sdcard bereitstellen oder einen symbolischen Linux-Link von sdcard zum tatsächlichen Bereitstellungspunkt einfügen.
• [C-0-4] MÜSSEN die Berechtigung android.permission.WRITE_EXTERNAL_STORAGE für diesen freigegebenen Speicher wie im SDK dokumentiert durchgesetzt werden. Freig. Speicher MUSS ansonsten von jeder Anwendung beschreibbar sein, die diese Berechtigung erhält.

Geräteimplementierungen KÖNNEN die oben genannten Anforderungen erfüllen, wenn eine der folgenden Voraussetzungen erfüllt ist:

• Vom Nutzer zugänglicher Wechselspeicher, z. B. ein SD-Kartensteckplatz (Secure Digital).
• Ein Teil des internen (nicht entfernbaren) Speichers, wie er im Android Open Source Project (AOSP) implementiert ist.

Wenn auf Geräten Wechseldatenträger verwendet werden, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

• [C-1-1] MÜSSEN eine Toast- oder Pop-up-Benutzeroberfläche implementieren, die den Nutzer warnt, wenn sich kein Speichermedium im Slot befindet.
• [C-1-2] MÜSSEN Sie ein Speichermedium im Format FAT (z.B. eine SD-Karte) beifügen oder auf der Verpackung und anderem Material, das zum Zeitpunkt des Kaufs verfügbar war, nachweisen, dass das Speichermedium separat erworben werden muss.

Wenn Geräteimplementierungen einen Teil des nicht entfernbaren Speichers nutzen, um die oben genannten Anforderungen zu erfüllen, gilt Folgendes:

• SOLLTEN die AOSP-Implementierung des internen freigegebenen Speichers der Anwendung verwenden.
• KANN den Speicherplatz mit den privaten Daten der Anwendung teilen.

Wenn Geräteimplementierungen mehrere Pfade zum gemeinsamen Speicher umfassen (z. B. einen SD-Kartensteckplatz und einen gemeinsamen internen Speicher), gilt Folgendes:

• [C-2-1] MUSS nur vorinstallierte und privilegierte Android-Apps mit der Berechtigung WRITE_EXTERNAL_STORAGE zum Schreiben in den sekundären externen Speicher zulassen, es sei denn, sie schreiben in ihre paketspezifischen Verzeichnisse oder innerhalb des URI, der durch Auslösen des Intents ACTION_OPEN_DOCUMENT_TREE zurückgegeben wird.

Wenn Geräteimplementierungen einen USB-Port mit Unterstützung für den USB-Peripheriemodus haben, gilt Folgendes:

• [C-3-1] MÜSSEN einen Mechanismus bereitstellen, mit dem von einem Hostcomputer aus auf die Daten im freigegebenen Anwendungsspeicher zugegriffen werden kann.
• SOLLTEN Inhalte aus beiden Speicherpfaden transparent über den Medienscanner-Dienst von Android und über android.provider.MediaStore verfügbar gemacht werden.
• KANN USB-Massenspeicher verwenden, sollte jedoch das Media Transfer Protocol verwenden, um diese Anforderung zu erfüllen.

Wenn Geräteimplementierungen einen USB-Port mit USB-Peripheriemodus haben und Media Transfer Protocol unterstützen, gilt Folgendes:

• SOLLTEN mit dem Android-MTP-Referenzhost Android File Transfer kompatibel sein.
• SOLLTE eine USB-Geräteklasse von 0x00 melden.
• MÜSSEN den Namen „MTP“ für die USB-Schnittstelle melden.

7.6.3 Verwendbare Speicher

Wenn es sich um ein Mobilgerät handelt, bei dem es sich nicht um ein Fernsehgerät handelt, gilt Folgendes:

• [SR] WIRD DRINGEND empfohlen, den nutzbaren Speicher an einem langfristigen, stabilen Standort zu implementieren, da das versehentliche Trennen der Verbindung zu Datenverlusten oder -beschädigungen führen kann.

Wenn sich der Anschluss für das austauschbare Speichergerät an einem langfristigen stabilen Standort befindet, z. B. im Akkufach oder einer anderen Schutzabdeckung, ist Folgendes möglich:

• [SR] UNBEDINGT EMPFOHLEN, akzeptablen Speicher zu implementieren.

7.7 USB

Wenn Geräteimplementierungen einen USB-Port haben, ist Folgendes zu beachten:

• SOLLTEN den USB-Peripheriemodus und den USB-Hostmodus unterstützen.

7.7.1 USB-Peripheriemodus

Wenn Geräte einen USB-Port enthalten, der den Peripheriemodus unterstützt:

• [C-1-1] Der Port MUSS mit einem USB-Host mit einem Standard-USB-Port des Typs A oder Typ C verbunden werden können.
• [C-1-2] MÜSSEN den korrekten Wert von iSerialNumber in der USB-Standard-Gerätebeschreibung über android.os.Build.SERIAL melden.
• [C-1-3] MÜSSEN Ladegeräte mit 1,5 A und 3,0 A nach Typ-C-Standardwiderstand erkennen und MÜSSEN Änderungen in der Werbung erkennen, wenn sie Typ-C-USB-Geräte unterstützen.
• [SR] Am Anschluss SOLLTEN Sie micro-B, micro-AB oder einen USB-Typ-C-Anschluss verwenden. Bestehende und neue Android-Geräte EMPFOHLEN, diese Anforderungen zu erfüllen, damit ein Upgrade auf die zukünftigen Plattform-Releases möglich ist.
• [SR] Der Anschluss sollte sich entsprechend der natürlichen Ausrichtung auf der Unterseite des Geräts befinden oder die Softwarebildschirmdrehung für alle Apps aktivieren (einschließlich des Startbildschirms), sodass der Bildschirm korrekt dargestellt wird, wenn das Gerät am Anschluss unten ausgerichtet ist. Bestehende und neue Android-Geräte EMPFOHLEN, diese Anforderungen zu erfüllen, damit ein Upgrade auf zukünftige Plattform-Releases möglich ist
• [SR] SOLLTEN die Nutzung von 1,5 A bei HS-Piepton und Traffic unterstützen, wie in der Spezifikation für das Laden von USB-Batterien, Version 1.2 beschrieben. Bestehende und neue Android-Geräte EMPFOHLEN, diese Anforderungen zu erfüllen, damit ein Upgrade auf die zukünftigen Plattform-Releases möglich ist.
• [SR] DRINGEND, keine proprietären Lademethoden zu unterstützen, bei denen die Vbus-Spannung über die Standardniveaus hinaus geändert wird, oder die Rollen der Senke/Quelle so ändern, dass dies zu Interoperabilitätsproblemen mit den Ladegeräten oder Geräten führen kann, die die standardmäßigen USB-Power Delivery-Methoden unterstützen. Dies wird zwar als „Dringend empfohlen“ bezeichnet, in zukünftigen Android-Versionen benötigen wir jedoch möglicherweise alle Typ-C-Geräte, um die vollständige Interoperabilität mit standardmäßigen Typ-C-Ladegeräten zu ermöglichen.
• [SR] WIRD UNBEDINGT EMPFOHLEN, Power Delivery für den Austausch von Daten- und Stromversorgungsrollen zu unterstützen, wenn USB-Typ-C-USB- und USB-Hostmodus unterstützt werden.
• SOLLTEN Power Delivery für Hochspannungsladevorgänge und alternative Modi wie Display-out unterstützen.
• SOLLTEN die Android Open Accessory (AOA) API und die Spezifikation implementieren, wie in der Android SDK-Dokumentation beschrieben.

Wenn Geräteimplementierungen einen USB-Port umfassen und die AOA-Spezifikation implementieren, gilt Folgendes:

• [C-2-1] MÜSSEN die Unterstützung für die Hardwarefunktion android.hardware.usb.accessory erklären.
• [C-2-2] Die USB-Massenspeicherklasse MUSS den String "android" am Ende der Schnittstellenbeschreibung iInterface des USB-Massenspeichers enthalten.

7.7.2 USB-Hostmodus

Wenn Geräte einen USB-Port enthalten, der den Hostmodus unterstützt, gilt Folgendes:

• [C-1-1] MÜSSEN die Android-USB-Host-API gemäß der Dokumentation im Android SDK implementieren und die Unterstützung für die Hardwarefunktion android.hardware.usb.host deklarieren.
• [C-1-2] MÜSSEN Support für den Anschluss standardmäßiger USB-Peripheriegeräte implementieren. Sie MÜSSEN also eine der folgenden Aktionen ausführen:
  • Sie haben einen Typ-C-Anschluss auf dem Gerät oder werden mit einem oder mehreren Kabeln geliefert, die einen proprietären Port des Geräts an einen Standard-USB-Typ-C-Anschluss (USB Typ-C-Gerät) anpassen.
  • Das Gerät muss über ein Gerät vom Typ A verfügen oder mit einem oder mehreren Kabeln für einen proprietären On-Device-Port an einen Standard-USB-Typ-A-Port angepasst werden.
  • einen Micro-AB-Port auf dem Gerät haben, der mit einem Kabel geliefert werden sollte, das für einen Standard-Typ-A-Port geeignet ist
• [C-1-3] DÜRFEN NICHT mit einem Adapter geliefert werden, der von USB Typ-A- oder Micro-AB-Ports in einen Typ-C-Anschluss (Buchse) umgewandelt wird.
• [SR] WIRD DRINGEND empfohlen, die USB-Audioklasse zu implementieren, wie in der Android SDK-Dokumentation beschrieben.
• SOLLTEN das Laden des verbundenen USB-Peripheriegeräts im Hostmodus unterstützen.Angegeben ist eine Stromquelle von mindestens 1,5 A, wie im Abschnitt „Beendigungsparameter“ des Abschnitts „Beendigungsparameter“ des USB Typ-C-Kabels und der Connector-Spezifikation Version 1.2 für USB-Typ-C-Anschlüsse oder über den CDP-Ausgangsstrombereich angegeben, wie in den Ladespezifikationen für USB-Akkus, Version 1.2 für Micro-AB-Anschlüsse angegeben.
• SOLLTEN USB-Typ-C-Standards implementieren und unterstützen.

Wenn Geräteimplementierungen einen USB-Port umfassen, 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-Nutzungstabellen und der Anfrage zur Nutzung von Sprachbefehlen angegeben sind, den KeyEvent-Konstanten unterstützen (siehe unten):
  • Nutzungsseite (0xC) Nutzungs-ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Nutzungsseite (0xC) Nutzungs-ID (0x0E9): KEYCODE_VOLUME_UP
  • Nutzungsseite (0xC) Nutzungs-ID (0x0EA): KEYCODE_VOLUME_DOWN
  • Nutzungsseite (0xC) Nutzungs-ID (0x0CF): KEYCODE_VOICE_ASSIST

Wenn Geräteimplementierungen einen USB-Port umfassen, der den Hostmodus und das Storage Access Framework (SAF) unterstützt, gilt Folgendes:

• [C-3-1] MÜSSEN alle remote 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äte einen USB-Port enthalten, der den Hostmodus und USB Typ-C unterstützt, gilt Folgendes:

• [C-4-1] MÜSSEN die Funktion „Dual-Rollen-Port“ gemäß der Definition in der USB Typ-C-Spezifikation (Abschnitt 4.5.1.3.3) implementieren.
• [SR] WIRD UNBEDINGT zur Unterstützung von DisplayPort empfohlen, SOLLTEN USB SuperSpeed-Datenübertragungsraten unterstützen und wird dringend empfohlen, Power Delivery für das Austauschen von Daten und Power-Rollen zu unterstützen.
• [SR] WIRD DRINGEND empfohlen, den Audioadapter-Zubehörmodus nicht zu unterstützen, wie in Anhang A der Version 1.2 der USB Typ-C-Kabel- und Verbindungsspezifikation beschrieben.
• SOLLTEN das Try.*-Modell implementieren, das für den Formfaktor des Geräts am besten geeignet ist. Auf einem Handheld sollte beispielsweise das Modell „Try.SNK“ implementiert werden.

7.8 Audio

7.8.1 Mikrofon

Wenn Geräte ein Mikrofon enthalten, gilt Folgendes:

• [C-1-1] MÜSSEN die android.hardware.microphone-Funktionskonstante melden.
• [C-1-2] MUSS die Anforderungen in Abschnitt 5.4 erfüllen.
• [C-1-3] MUSS die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
• [SR] wird dringend empfohlen, die Nah-Ultraschallaufzeichnung wie in Abschnitt 7.8.3 beschrieben zu unterstützen.

Wenn Geräteimplementierungen kein Mikrofon enthalten, geschieht Folgendes:

• [C-2-1] DARF NICHT die android.hardware.microphone-Funktionskonstante melden.
• [C-2-2] MÜSSEN die Audio-Aufzeichnungs-API mindestens gemäß Abschnitt 7 im Nullmodus implementieren.

7.8.2 Audioausgabe

Wenn Geräteimplementierungen einen Lautsprecher oder einen Audio-/Multimedia-Ausgabeport für ein Peripheriegerät für die Audioausgabe enthalten, z. B. eine 3,5-mm-Audiobuchse mit 4 Kabeln oder einen USB-Hostmodus-Port mit USB-Audioklasse, 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] WIRD UNBEDINGT ZUR Unterstützung der beinahe-Ultraschallwiedergabe empfohlen, wie in Abschnitt 7.8.3 beschrieben.

Wenn Geräteimplementierungen keinen Lautsprecher- oder Audioausgabeport umfassen, ist Folgendes zu beachten:

• [C-2-1] DÜRFEN NICHT die Funktion android.hardware.audio.output melden.
• [C-2-2] MÜSSEN die APIs zur Audioausgabe zumindest als managementfrei implementieren.

In diesem Abschnitt ist ein „Ausgabeport“ eine physische Schnittstelle, z. B. eine 3, 5-mm-Audiobuchse, ein HDMI- oder USB-Hostmodus-Port mit USB-Audioklasse. Die Unterstützung der Audioausgabe über Funkprotokolle wie Bluetooth, WLAN oder Mobilfunknetze umfasst keinen „Ausgabeport“.

7.8.2.1 Analoge Audioanschlüsse

Damit die Kompatibilität mit den Headsets und anderem Audiozubehör über den 3, 5-mm-Audiostecker aus dem gesamten Android-Ökosystem gewährleistet werden kann, müssen Geräteimplementierungen einen oder mehrere analoge Audioanschlüsse enthalten:

• [C-SR] Es wird dringend empfohlen, mindestens einen der Audioports als 3,5-mm-Audioanschluss mit vier Kabeln anzugeben.

Geräteimplementierungen mit einem 3, 5-mm-Audioanschluss mit 4 Kabeln:

• [C-1-1] MÜSSEN die Audiowiedergabe über Stereo-Kopfhörer und Stereo-Headsets mit Mikrofon unterstützen.
• [C-1-2] MUSS TRRS-Audiostecker mit CTIA-Pin-out-Reihenfolge unterstützen.
• [C-1-3] MUSS die Erkennung und Zuordnung zu den Keycodes für die folgenden drei Bereiche der entsprechenden Impedanz zwischen dem Mikrofon und den Erdleitern am Audiostecker unterstützen:
  • Max. 70 Ohm: KEYCODE_HEADSETHOOK
  • 210–290 Ohm: KEYCODE_VOLUME_UP
  • 360–680 Ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] MÜSSEN bei einem Steckerstecker ACTION_HEADSET_PLUG auslösen, aber erst, wenn alle Kontakte am Stecker die relevanten Segmente an der Buchse berühren.
• [C-1-5] MUSS mindestens 150 mV ± 10% der Ausgangsspannung über eine 32-Ohm-Lautsprecherimpedanz liefern können.
• [C-1-6] MÜSSEN über eine Mikrofonspannung zwischen 1,8 und 2,9 V verfügen.
• [C-1-7] MUSS den folgenden Bereich der äquivalenten Impedanz zwischen dem Mikrofon und den Erdleitern am Audiostecker erkennen und dem Schlüsselcode zuordnen:
  • 110–180 Ohm: KEYCODE_VOICE_ASSIST
• [C-SR] wird dringend empfohlen, Audiostecker mit der OMTP-Pin-out-Reihenfolge zu unterstützen.
• [C-SR] wird dringend empfohlen, die Audioaufnahme von Stereo-Headsets mit Mikrofon zu unterstützen.

Wenn Geräteimplementierungen eine 3, 5-mm-Audiobuchse mit 4 Kabeln haben und ein Mikrofon unterstützen und android.intent.action.HEADSET_PLUG mit dem zusätzlichen Mikrofon auf „1“ übertragen, geschieht Folgendes:

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

7.8.3 Nah-Ultraschall

Nah-Ultraschall-Audio ist das Frequenzband von 18,5 kHz bis 20 kHz.

Geräteimplementierungen:

• MÜSSEN die Unterstützung von Nah-Ultraschall-Audiofunktionen über die AudioManager.getProperty API wie folgt gemeldet werden:

Wenn PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND auf „true“ gesetzt ist, MÜSSEN die folgenden Anforderungen von den Audioquellen VOICE_RECOGNITION und UNPROCESSED erfüllt werden:

• [C-1-1] Der durchschnittliche Stromeingang des Mikrofons im Band von 18,5 kHz bis 20 kHz DARF nicht mehr als 15 dB unter dem Antwortbereich 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 Ton von 19 kHz bei -26 dBFS DARF nicht unter 50 dB liegen.

Wenn PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND „true“ ist:

• [C-2-1] Der Mittelwert des Lautsprechers in einem Bereich von 18,5 kHz bis 20 kHz DARF nicht unter 40 dB unter dem Wert bei 2 kHz liegen.

7.9. Virtual Reality

Android umfasst APIs und Einrichtungen zur Entwicklung von Virtual-Reality-Anwendungen (VR-Anwendungen), einschließlich hochwertiger VR-Erlebnisse für Mobilgeräte. Bei Geräteimplementierungen MÜSSEN diese APIs und Verhaltensweisen korrekt implementiert werden, wie in diesem Abschnitt beschrieben.

7.9.1 Virtual-Reality-Modus

Android unterstützt den VR-Modus, eine Funktion, die die stereoskopische Wiedergabe von Benachrichtigungen verarbeitet und monokulare System-UI-Komponenten deaktiviert, während eine VR-Anwendung auf den Nutzer ausgerichtet ist.

7.9.2 Virtual-Reality-Modus – hohe Leistung

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

• [C-1-1] MUSS mindestens zwei physische Kerne haben.
• [C-1-2] MÜSSEN die Funktion android.hardware.vr.high_performance deklarieren.
• [C-1-3] MÜSSEN den Modus für kontinuierliche Leistung unterstützen.
• [C-1-4] MUSS OpenGL ES 3.2 unterstützen.
• [C-1-5] MUSS android.hardware.vulkan.level 0 unterstützen.
• SOLLTEN android.hardware.vulkan.level 1 oder höher unterstützen.
• [C-1-6] MÜSSEN 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 anzeigen.
• [C-1-8] MÜSSEN 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 anzeigen.
• [C-SR] 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 sehen.
• [C-SR] wird dringend empfohlen, Vulkan 1.1 zu unterstützen.
• [C-SR] 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 zu sehen.
• [C-SR] Es wird dringend empfohlen, mindestens eine Vulkan-Warteschlangenfamilie offenzulegen, in der flags sowohl VK_QUEUE_GRAPHICS_BIT als auch VK_QUEUE_COMPUTE_BIT enthält und queueCount mindestens 2 ist.
• [C-1-7] GPU und Display MÜSSEN in der Lage sein, den Zugriff auf den gemeinsamen Frontpuffer zu synchronisieren, sodass VR-Inhalte mit 60 fps und zwei Rendering-Kontexten abwechselnd mit 60 fps ohne sichtbare Tearing-Artefakte gerendert werden.
• [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] MÜSSEN die Unterstützung für AHardwareBuffers 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] wird dringend empfohlen, die Zuordnung von AHardwareBuffers mit mehr als einer Ebene und Flags und Formaten zu unterstützen, die in C-1-10 angegeben sind.
• [C-1-11] MÜSSEN H.264-Decodierung bei mindestens 3840 × 2160 bei 30 fps unterstützen, komprimiert auf durchschnittlich 40 Mbit/s (entspricht 4 Instanzen von 1920 x 1080 bei 30 fps-10 Mbit/s oder 2 Instanzen mit 1080 Mbit/s x 10 Mbit/s 20 Mbit/s).
• [C-1-12] MÜSSEN HEVC und VP9 unterstützen, MÜSSEN mindestens 1920 × 1080 bei 30 fps decodieren können, die auf durchschnittlich 10 Mbit/s komprimiert sind, und 3840 × 2160 bei 30 fps-20 fps von 10 fps bis 20 fps decodieren.
• [C-1-13] MUSS die HardwarePropertiesManager.getDeviceTemperatures API unterstützen und genaue Werte für die Hauttemperatur zurückgeben.
• [C-1-14] MÜSSEN einen eingebetteten Bildschirm haben und die Auflösung muss mindestens 1920 x 1080 betragen.
• [C-SR] Eine Bildschirmauflösung von mindestens 2560 x 1440 wird dringend empfohlen.
• [C-1-15] Im VR-Modus MUSS das Display mindestens 60 Hz aktualisiert werden.
• [C-1-17] Die Anzeige MUSS einen Modus mit niedriger Persistenz mit einer Persistenz von weniger als 5 Millisekunden unterstützen. Sie ist definiert als die Zeit, während der ein Pixel Licht ausstrahlt.
• [C-1-18] MÜSSEN Bluetooth 4.2 und Bluetooth LE-Datenlängenerweiterung unterstützen Abschnitt 7.4.3.
• [C-1-19] MUSS den Direktkanaltyp für die folgenden Standardsensortypen unterstützen und ordnungsgemäß melden:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] wird dringend empfohlen, den TYPE_HARDWARE_BUFFER-Direktkanaltyp für alle oben aufgeführten direkten Kanaltypen zu unterstützen.
• [C-1-21] MUSS die Anforderungen für Gyroskop, Beschleunigungsmesser und Magnetometer für android.hardware.hifi_sensors erfüllen, wie in Abschnitt 7.3.9 beschrieben.
• [C-SR] wird dringend empfohlen, die android.hardware.sensor.hifi_sensors-Funktion zu unterstützen.
• [C-1-22] MUSS eine End-to-End-Latenz von Bewegung zu Photon auf maximal 28 Millisekunden aufweisen.
• [C-SR] Es wird dringend empfohlen, eine End-to-End-Latenz von Bewegung zu Photon auf maximal 20 Millisekunden zu haben.
• [C-1-23] MÜSSEN das Verhältnis für den ersten Frame haben. Dies ist das Verhältnis zwischen der Helligkeit der Pixel im ersten Frame nach einem Übergang von Schwarz zu Weiß und der Helligkeit weißer Pixel bei konstantem Zustand von mindestens 85%.
• [C-SR] wird dringend empfohlen, ein Verhältnis für den ersten Frame von mindestens 90 % zu haben.
• KÖNNEN einen exklusiven Kern für die Anwendung im Vordergrund bereitstellen und die Process.getExclusiveCores API unterstützen, um die Anzahl der CPU-Kerne zurückzugeben, die ausschließlich für die Anwendung im Vordergrund gelten.

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

• [C-2-1] DARF keine anderen Userspace-Prozesse auf dem Gerät ausführen (mit Ausnahme der von der Anwendung verwendeten Gerätetreiber). Möglicherweise werden jedoch einige Kernel-Prozesse bei Bedarf ausgeführt.

8. Leistung und Leistung

Einige Mindestleistungs- und Leistungskriterien sind entscheidend für die Nutzererfahrung und wirken sich auf die grundlegenden Annahmen aus, die Entwickler bei der Entwicklung einer App haben.

8.1. Konsistente Nutzererfahrung

Wenn bestimmte Mindestanforderungen erfüllt werden müssen, um eine konsistente Framerate und konsistente Antwortzeiten für Apps und Spiele zu gewährleisten, kann eine reibungslose Benutzeroberfläche für den Endnutzer bereitgestellt werden. Geräteimplementierungen haben je nach Gerätetyp messbare Anforderungen an die Latenz der Benutzeroberfläche und den Aufgabenwechsel, wie in Abschnitt 2 beschrieben.

8.2. Leistung des Datei-E/A-Zugriffs

Die Bereitstellung einer gemeinsamen Basis für eine konsistente Dateizugriffsleistung im privaten Datenspeicher der Anwendung (/data-Partition) ermöglicht es App-Entwicklern, eine angemessene Erwartung festzulegen, die für ihr Softwaredesign hilfreich ist. Bei Geräteimplementierungen gelten je nach Gerätetyp möglicherweise bestimmte in Abschnitt 2 beschriebene Anforderungen für die folgenden Lese- und Schreibvorgänge:

• Leistung sequentieller Schreibvorgänge: Dieser Wert wird ermittelt, indem eine 256 MB große Datei mit einem 10 MB-Schreibpuffer geschrieben wird.
• Zufällige Schreibleistung: Gemessen durch Schreiben einer 256 MB großen Datei mit einem 4-KB-Schreibpuffer.
• Leistung sequentieller Lesevorgänge: Gemessen durch Lesen einer 256 MB großen Datei mit einem 10-MB-Schreibpuffer.
• Zufällige Leseleistung: Gemessen durch Lesen einer 256 MB großen Datei mit einem 4-KB-Schreibpuffer.

8.3. Energiesparmodi

Wenn Geräteimplementierungen Funktionen zur Verbesserung der Verwaltung des Energieverbrauchs von Geräten in AOSP oder Erweiterung der in AOSP enthaltenen Funktionen enthalten, gilt Folgendes:

• [C-1-1] DARF NICHT von der AOSP-Implementierung für die Trigger-, Wartungs-, Wakeup-Algorithmen und die Verwendung der globalen Systemeinstellungen des App-Standby- und des Stromsparmodus abweichen.
• [C-1-2] DARF NICHT von der AOSP-Implementierung abweichen, wenn die Drosselung von Jobs, Alarmen und Netzwerken für Anwendungen in jedem Bucket für den Anwendungs-Standby-Modus über globale Einstellungen verwaltet wird.
• [C-1-3] Dürfen in Bezug auf die Anzahl der für App-Standby verwendeten App-Standby-Buckets NICHT von der AOSP-Implementierung abweichen.
• [C-1-4] MÜSSEN App-Standby-Buckets und den Stromsparmodus wie unter Energiesparmodus beschrieben implementieren.
• [C-1-5] MÜSSEN true für PowerManager.isPowerSaveMode() zurückgeben, wenn sich das Gerät im Energiesparmodus befindet.
• [C-SR] werden UNBEDINGT empfohlen, Nutzern die Möglichkeit zu bieten, den Energiesparmodus zu aktivieren und zu deaktivieren.
• [C-SR] Wir empfehlen dringend, Nutzern die Möglichkeit zu bieten, alle Apps anzuzeigen, die vom App-Standby- und Stromsparmodus ausgenommen sind.

Zusätzlich zu den Energiesparmodi KÖNNEN Implementierungen von Android-Geräten einen oder alle der vier Energiezustände für den Ruhemodus implementieren, die in der Advanced Configuration and Power Interface (ACPI) definiert sind.

Wenn Geräteimplementierungen den S4-Leistungsstatus gemäß ACPI-Definition implementieren, gilt Folgendes:

• [C-1-1] MUSS diesen Status erst erhalten, nachdem der Nutzer das Gerät durch eine explizite Aktion in den inaktiven Zustand versetzt hat (z.B. durch Schließen eines Deckels, der Teil des Geräts ist, oder indem ein Fahrzeug oder Fernseher ausgeschaltet wird) und bevor der Nutzer das Gerät wieder aktiviert (z.B. durch Öffnen des Deckels oder Anschalten des Fahrzeugs oder Fernsehers).

Wenn Geräteimplementierungen den S3-Leistungsstatus gemäß ACPI-Definition implementieren, gilt Folgendes:

• [C-2-1] MÜSSEN die obigen C-1-1-Anforderungen erfüllen oder MÜSSEN nur dann in den S3-Status wechseln, wenn Drittanbieter-Anwendungen keine Systemressourcen (z.B. Bildschirm oder CPU) benötigen.

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

  Während die Drittanbieter-Apps beispielsweise anfordern, dass der Bildschirm über FLAG_KEEP_SCREEN_ON eingeschaltet bleibt oder die CPU über PARTIAL_WAKE_LOCK läuft, 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 den Status „Inaktiv“ zu versetzen. Umgekehrt MUSS das Gerät den S3-Status beenden, wenn eine Aufgabe ausgelöst wird, die von Drittanbieter-Apps über den JobScheduler implementiert wird, oder Firebase Cloud Messaging an Drittanbieter-Apps liefert, es sei denn, der Nutzer hat das Gerät in den Status „Inaktiv“ versetzt. Dies sind keine umfassenden Beispiele und AOSP implementiert umfangreiche Wakeup-Signale, die einen Wakeup aus diesem Zustand auslösen.

8.4. Berechnung des Stromverbrauchs

Eine genauere Berechnung und Berichterstellung des Stromverbrauchs bietet dem App-Entwickler sowohl Anreize als auch Tools zur Optimierung des Stromverbrauchsmusters der Anwendung.

Geräteimplementierungen:

• [SR] WIRD UNBEDINGT GEWÜNSCHT, ein Leistungsprofil pro Komponente anzugeben, in dem der Wert des aktuellen Verbrauchs für jede Hardwarekomponente und die ungefähre Entladung der Akkus durch die Komponenten im Zeitverlauf angegeben wird, wie auf der Website des Android Open Source Project dokumentiert.
• [SR] EMPFOHLEN, alle Werte zum Energieverbrauch in Milliamperestunden (mAh) anzugeben.
• [SR] UNBEDINGT EMPFOHLEN, den CPU-Energieverbrauch pro Prozess-UID zu melden. Das Android Open Source-Projekt erfüllt die Anforderung über die Implementierung des Kernelmoduls uid_cputime.
• [SR] EMPFOHLEN, diesen Stromverbrauch dem App-Entwickler über den Shell-Befehl adb shell dumpsys batterystats zur Verfügung zu stellen.
• SOLLTEN der Hardwarekomponente selbst zugeordnet werden, wenn sie den Stromverbrauch der Hardwarekomponente nicht einer Anwendung zuordnen können.

8.5. Konstante Leistung

Bei leistungsstarken Apps mit langer Laufzeit kann die Leistung stark schwanken – entweder aufgrund der anderen Apps, die im Hintergrund ausgeführt werden, oder aufgrund der CPU-Drosselung aufgrund von Temperaturlimits. Android umfasst programmatische Schnittstellen, mit denen die Anwendung im Vordergrund, wenn das Gerät fähig ist, eine Optimierung der Ressourcenzuweisung zum Beheben solcher Schwankungen anfordern kann.

Geräteimplementierungen:

• [C-0-1] MÜSSEN die Unterstützung des Modus für kontinuierliche Leistung mithilfe der API-Methode PowerManager.isSustainedPerformanceModeSupported() korrekt melden.

• SOLLTEN den Modus für kontinuierliche Leistung unterstützen.

Wenn Geräteimplementierungen den Modus für kontinuierliche Leistung unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN für die Anwendung im Vordergrund, wenn die App sie anfordert, mindestens 30 Minuten lang eine konstante Leistung erzielen.
• [C-1-2] MÜSSEN die Window.setSustainedPerformanceMode() API und andere zugehörige APIs berücksichtigen.

Wenn Geräteimplementierungen zwei oder mehr CPU-Kerne umfassen, gilt Folgendes:

• SOLLTEN mindestens einen exklusiven Kern bereitstellen, der von der App im Vordergrund reserviert werden kann.

Wenn Geräteimplementierungen die Reservierung eines exklusiven Kerns für die oberste App im Vordergrund unterstützen, gilt Folgendes:

• [C-2-1] MÜSSEN die ID-Nummern der exklusiven Kerne, die von der obersten Anwendung im Vordergrund reserviert werden können, über die API-Methode Process.getExclusiveCores() melden.
• [C-2-2] DARF keine User-Space-Prozesse mit Ausnahme der von der Anwendung verwendeten Gerätetreiber auf den exklusiven Kernen ausführen, aber KANN die Ausführung einiger Kernel-Prozesse nach Bedarf zulassen.

Wenn Geräteimplementierungen keinen exklusiven Kern unterstützen, geschieht Folgendes:

• [C-3-1] MUSS mit der 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 dem Sicherheitsmodell der Android-Plattform entspricht, wie in den APIs in der Android-Entwicklerdokumentation im Referenzdokument zu Sicherheit und Berechtigungen definiert.

• [C-0-2] MUSS die Installation selbst signierter Anwendungen unterstützen, ohne dass zusätzliche Berechtigungen/Zertifikate von Dritten oder Behörden erforderlich sind. Insbesondere MÜSSEN kompatible Geräte die in den folgenden Unterabschnitten beschriebenen Sicherheitsmechanismen unterstützen.

9.1 Berechtigungen

Geräteimplementierungen:

• [C-0-1] MUSS das in der Android-Entwicklerdokumentation definierte Android-Berechtigungsmodell unterstützen. Insbesondere MÜSSEN sie jede in der SDK-Dokumentation beschriebene Berechtigung durchsetzen. Es dürfen keine Berechtigungen weggelassen, verändert oder ignoriert werden.

• KANN zusätzliche Berechtigungen hinzufügen, sofern sich die neuen Berechtigungs-ID-Strings nicht im Namespace android.\* befinden.

• [C-0-2] Berechtigungen mit dem protectionLevel-Wert PROTECTION_FLAG_PRIVILEGED MÜSSEN nur Apps gewährt werden, die vorinstalliert sind unter den privilegierten Pfaden des System-Images und innerhalb der Teilmenge der explizit zugelassenen Berechtigungen für jede App. Die AOSP-Implementierung erfüllt diese Anforderung, indem die Berechtigungen auf der Zulassungsliste für jede App aus den Dateien im Pfad etc/permissions/ gelesen und berücksichtigt werden und der Pfad system/priv-app als privilegierter Pfad verwendet wird.

Berechtigungen mit dem Schutzniveau „gefährlich“ sind Laufzeitberechtigungen. Anwendungen mit targetSdkVersion > 22 fordern sie zur Laufzeit an.

Geräteimplementierungen:

• [C-0-3] MÜSSEN eine spezielle Schnittstelle für den Nutzer anzeigen, über die er entscheiden kann, ob die angeforderten Laufzeitberechtigungen gewährt werden sollen, und dem Nutzer außerdem eine Schnittstelle zur Verwaltung der Laufzeitberechtigungen zur Verfügung stellen.
• [C-0-4] MUSS nur eine Implementierung beider Benutzeroberflächen haben.
• [C-0-5] DÜRFEN KEINEN Laufzeitberechtigungen für vorinstallierte Apps gewähren, es sei denn:
  • Die Einwilligung des Nutzers kann eingeholt werden, bevor die Anwendung sie verwendet.
  • Die Laufzeitberechtigungen sind mit einem Intent-Muster verknüpft, für das die vorinstallierte Anwendung als Standard-Handler festgelegt ist.
• [C-0-6] MUSS die Berechtigung android.permission.RECOVER_KEYSTORE nur System-Apps erteilen, die einen ordnungsgemäß gesicherten Wiederherstellungs-Agent registrieren. Ein ordnungsgemäß gesicherter Wiederherstellungs-Agent wird als Software-Agent auf dem Gerät definiert, der sich mit einem Remote-Speicher auf dem Gerät synchronisiert. Dieser ist mit einer sicheren Hardware ausgestattet, die einen Schutz aufweist, der dem im Google Cloud Key Vault-Dienst 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 Sie Apps von Drittanbietern den Zugriff auf die Nutzungsstatistiken ermöglichen möchten, gilt Folgendes:

• [SR] wird dringend empfohlen, Apps, die die Berechtigung android.permission.PACKAGE_USAGE_STATS deklarieren, mit einem Mechanismus bereitzustellen, mit dem Nutzer als Reaktion auf den Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS Zugriff auf die Nutzungsstatistiken gewähren oder entziehen können.

Wenn in Geräteimplementierungen festgelegt wird, dass Apps, einschließlich vorinstallierter Apps, nicht auf die Nutzungsstatistiken zugreifen können, gilt Folgendes:

• [C-1-1] MÜSSEN weiterhin eine Aktivität haben, die das Intent-Muster android.settings.ACTION_USAGE_ACCESS_SETTINGS verarbeitet, aber MÜSSEN sie als No-Op implementieren, d. h. ein gleichwertiges Verhalten wie bei der Zugriffsablehnung des Nutzers haben.

9.2. UID und Prozessisolierung

Geräteimplementierungen:

• [C-0-1] MÜSSEN das Sandbox-Modell der Android-Anwendung unterstützen, bei dem jede Anwendung als eindeutige Unixstyle-UID und in einem separaten Prozess ausgeführt wird.
• [C-0-2] MUSS die Ausführung mehrerer Anwendungen unter derselben Linux-Nutzer-ID unterstützen, vorausgesetzt, die Anwendungen sind ordnungsgemäß signiert und konstruiert (siehe Referenz zu Sicherheit und Berechtigungen).

9.3 Dateisystemberechtigungen

Geräteimplementierungen:

• [C-0-1] MUSS das Android-Modell für Dateizugriffsberechtigungen unterstützen, wie in der Referenz zu Sicherheit und Berechtigungen definiert.

9.4 Alternative Ausführungsumgebungen

Geräteimplementierungen MÜSSEN die Konsistenz des Android-Sicherheits- und Berechtigungsmodells aufrechterhalten, auch wenn sie Laufzeitumgebungen enthalten, in denen Anwendungen mit einer anderen Software oder Technologie als dem Dalvik Executable Format oder nativem Code ausgeführt werden. Mit anderen Worten:

• [C-0-1] Alternative Laufzeiten MÜSSEN selbst Android-Apps sein und dem standardmäßigen Android-Sicherheitsmodell entsprechen, wie an anderer Stelle in Abschnitt 9 beschrieben.

• [C-0-2] Alternative Laufzeiten DÜRFEN KEINEN Zugriff auf Ressourcen erhalten, die durch Berechtigungen geschützt sind, die nicht in der Datei AndroidManifest.xml der Laufzeit über den <uses-permission>-Mechanismus angefordert werden.

• [C-0-3] Alternative Laufzeiten DÜRFEN NICHT zulassen, dass Anwendungen Funktionen verwenden, die durch Android-Berechtigungen geschützt sind, die auf Systemanwendungen beschränkt sind.

• [C-0-4] Alternative Laufzeiten MÜSSEN dem Android-Sandbox-Modell entsprechen und installierte Anwendungen, die eine alternative Laufzeit verwenden, DÜRFEN NICHT die Sandbox einer anderen auf dem Gerät installierten App wiederverwenden, es sei denn, dies geschieht über die Android-Standardmechanismen der gemeinsamen Nutzer-ID und des Signaturzertifikats.

• [C-0-5] Alternative Laufzeiten DÜRFEN NICHT mit den Sandboxes gestartet werden, die anderen Android-Apps entsprechen, oder ihnen Zugriff darauf gewähren.

• [C-0-6] Alternative Laufzeiten DÜRFEN NICHT mit anderen Anwendungen gestartet, zugewiesen werden oder ihnen die Berechtigungen des Superuser (Root) oder einer anderen Nutzer-ID gewähren.

• [C-0-7] Wenn die .apk-Dateien alternativer Laufzeiten im System-Image von Geräteimplementierungen enthalten sind, MÜSSEN sie mit einem Schlüssel signiert werden, der sich von dem Schlüssel unterscheidet, mit dem andere Anwendungen in den Geräteimplementierungen signiert werden.

• [C-0-8] Bei der Installation von Anwendungen MÜSSEN alternative Laufzeiten die Nutzereinwilligung für die von der App verwendeten Android-Berechtigungen einholen.

• [C-0-9] Wenn eine App 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 App auf diese Ressource zugreifen kann.

• [C-0-10] Wenn die Laufzeitumgebung die Anwendungsfunktionen nicht auf diese Weise aufzeichnet, MUSS die Laufzeitumgebung alle Berechtigungen auflisten, die der Laufzeit selbst zugewiesen sind, wenn eine Anwendung installiert wird, die diese Laufzeit verwendet.

• Alternative Laufzeiten 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 gemeinsam genutzt wird, die die alternative Laufzeit verwenden.

9.5 Unterstützung mehrerer Nutzer

Android umfasst Unterstützung für mehrere Nutzer und eine vollständige Nutzerisolation.

• Bei Geräteimplementierungen MÖGLICHERWEISE MÖGLICHERWEISE jedoch NICHT für die Verwendung durch mehrere Nutzer geeignet sein, wenn sie als primären externen Speicher Wechselmedien verwenden.

Wenn mehrere Nutzer an einer Geräteimplementierung teilnehmen, gilt Folgendes:

• [C-1-1] MUSS die folgenden Anforderungen in Bezug auf die Unterstützung mehrerer Nutzer erfüllen.
• [C-1-2] MÜSSEN für jeden Nutzer ein Sicherheitsmodell implementieren, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument zu Sicherheit und Berechtigungen in den APIs definiert.
• [C-1-3] MÜSSEN separate und isolierte gemeinsame Anwendungsspeicherverzeichnisse (auch als /sdcard bezeichnet) für jede Nutzerinstanz haben.
• [C-1-4] MÜSSEN sicherstellen, dass Anwendungen, die einem bestimmten Nutzer gehören und im Namen eines bestimmten Nutzers ausgeführt werden, keine Dateien auflisten, lesen oder bearbeiten können, auch wenn die Daten beider Nutzer auf demselben Volume oder Dateisystem gespeichert sind.
• [C-1-5] MÜSSEN den Inhalt der SD-Karte bei Aktivierung der Mehrfachbenutzer-Funktion mit einem Schlüssel verschlüsseln, der nur auf nicht entfernbaren Medien gespeichert ist, auf die nur das System zugreifen kann, wenn bei Geräteimplementierungen Wechseldatenträger für die externen Speicher-APIs verwendet werden. Da die Medien dann von einem Host-PC nicht mehr gelesen werden können, müssen die 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 Funktions-Flag android.hardware.telephony nicht deklariert wird, geschieht Folgendes:

• [C-2-1] MÜSSEN eingeschränkte Profile unterstützen, eine Funktion, mit der Geräteeigentümer zusätzliche Nutzer und deren Berechtigungen auf dem Gerät verwalten können. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen einrichten, in denen zusätzliche Nutzer arbeiten können. Außerdem haben sie die Möglichkeit, detailliertere Einschränkungen in den Apps zu verwalten, die in diesen Umgebungen verfügbar sind.

Wenn Geräteimplementierungen mehrere Nutzer umfassen und das Funktions-Flag android.hardware.telephony deklarieren, geschieht Folgendes:

• [C-3-1] DÜRFEN KEINE eingeschränkten Profile unterstützen, MÜSSEN jedoch mit der AOSP-Implementierung der Steuerelemente übereinstimmen, mit denen andere Nutzer am Zugriff auf Sprachanrufe und SMS teilnehmen können.

9.6 Warnung bei Premium-SMS

Android kann Nutzer auch vor ausgehenden Premium-SMS warnen. Premium-SMS sind SMS, die an einen bei einem Mobilfunkanbieter registrierten Dienst gesendet werden und für den Nutzer Gebühren anfallen können.

Wenn in Geräteimplementierungen die Unterstützung von android.hardware.telephony deklariert wird, gilt Folgendes:

• [C-1-1] MÜSSEN Nutzer warnen, bevor sie eine SMS an Nummern senden, die durch reguläre Ausdrücke identifiziert werden, die in der Datei /data/misc/sms/codes.xml auf dem Gerät definiert sind. Das vorgelagerte Open-Source-Projekt von Android bietet eine Implementierung, die diese Anforderung erfüllt.

9.7 Sicherheitsfunktionen

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

Die Android-Sandbox enthält Funktionen, die das MAC-System (Security-Enhanced Linux) und andere Sicherheitsfunktionen im Linux-Kernel verwenden sowie die Seccomp-Sandboxing. Geräteimplementierungen:

• [C-0-1] MÜSSEN die Kompatibilität mit vorhandenen Anwendungen aufrechterhalten, auch wenn SELinux oder andere Sicherheitsfunktionen unterhalb des Android-Frameworks implementiert sind.
• [C-0-2] DÜRFEN KEINE sichtbare Benutzeroberfläche haben, wenn ein Sicherheitsverstoß erkannt und erfolgreich durch die Sicherheitsfunktion unterhalb des Android-Frameworks blockiert wird. KANN jedoch eine sichtbare Benutzeroberfläche haben, wenn ein nicht blockierter Sicherheitsverstoß zu einem erfolgreichen Exploit führt.
• [C-0-3] DÜRFEN SELinux oder andere Sicherheitsfunktionen, die unter dem Android-Framework implementiert sind, NICHT für den Nutzer oder App-Entwickler konfigurieren.
• [C-0-4] DARF NICHT zulassen, dass eine Anwendung, die sich über eine API auf eine andere Anwendung auswirkt (z. B. eine Device Administration API), die Konfiguration einer Richtlinie erlaubt, die gegen die Kompatibilität verstößt.
• [C-0-5] MÜSSEN das Medien-Framework in mehrere Prozesse aufteilen, damit es möglich ist, den Zugriff für jeden Prozess präziser zu gewähren, wie auf der Website des Android Open Source Project beschrieben.
• [C-0-6] MÜSSEN einen Sandbox-Mechanismus für Kernel-Anwendungen implementieren, der das Filtern von Systemaufrufen mithilfe einer konfigurierbaren Richtlinie aus Multithread-Programmen ermöglicht. Das vorgelagerte Android-Open-Source-Projekt erfüllt diese Anforderung durch die Aktivierung von seccomp-BPF mit Threadgroup-Synchronisierung (TSYNC), wie im Abschnitt zur Kernel-Konfiguration von source.android.com beschrieben.

Die Kernel-Integrität und Selbstschutzfunktionen sind wesentlich für die Sicherheit von Android. Geräteimplementierungen:

• [C-0-7] MÜSSEN den Pufferüberlaufschutz für den Kernel-Stack implementieren (z.B. CONFIG_CC_STACKPROTECTOR_STRONG).
• [C-0-8] MÜSSEN strenge Kernel-Speicherschutzmaßnahmen implementieren, bei denen 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] MÜSSEN auf Geräten mit ursprünglich API-Level 28 oder höher statische und dynamische Objektgrößenprüfung von Kopien zwischen Nutzer- und Kernel-Bereich (z.B. CONFIG_HARDENED_USERCOPY) implementieren.
• [C-0-10] DÜRFEN KEINEN User-Space-Speicher bei Ausführung im Kernel-Modus (z.B. Hardware-PXN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) auf Geräten ausführen, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden.
• [C-0-11] DARF KEINEN User-Space-Arbeitsspeicher im Kernel außerhalb von normalen Benutzerkopie-Zugriffs-APIs (z.B. Hardware-PAN oder emuliert über CONFIG_CPU_SW_DOMAIN_PAN oder CONFIG_ARM64_SW_TTBR0_PAN) auf Geräten lesen oder schreiben, die ursprünglich mit API-Level 28 oder höher ausgeliefert wurden.
• [C-0-12] MÜSSEN die Isolierung der Kernel-Seitentabelle auf allen Geräten implementieren, die ursprünglich über API-Level 28 oder höher ausgeliefert wurden (z.B. CONFIG_PAGE_TABLE_ISOLATION oder `CONFIG_UNMAP_KERNEL_AT_EL0).
• [SR] WIRD DRINGEND empfohlen, Kerneldaten, die nur während der Initialisierung geschrieben werden, nach der Initialisierung als schreibgeschützt markiert zu behalten (z.B. __ro_after_init).
• [SR] EMPFOHLEN, das Layout des Kernel-Codes und des Arbeitsspeichers zufällig zu gestalten und Offenlegungen zu vermeiden, die die Randomisierung beeinträchtigen würden (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] MÜSSEN SELinux in den globalen Erzwingungsmodus setzen.
• [C-1-3] MÜSSEN alle Domains im Erzwingungsmodus konfigurieren. Domains im moderaten Modus sind nicht zulässig, auch nicht geräte- oder anbieterspezifische Domains.
• [C-1-4] DÜRFEN die „Neverallow“-Regeln im Ordner „system/sepolicy“, der im vorgelagerten Android Open Source Project (AOSP) angegeben ist, NICHT ändern, weglassen oder ersetzen. Die Richtlinie MÜSSEN sowohl für AOSP SELinux-Domains als auch geräte-/anbieterspezifische Domains mit allen „Neverallow“-Regeln kompiliert werden.
• [C-1-5] MÜSSEN Drittanbieter-Anwendungen mit Ausrichtung auf API-Level 28 oder höher in anwendungsspezifischen SELinux-Sandboxes mit app-spezifischen SELinux-Einschränkungen für das private Datenverzeichnis jeder Anwendung ausführen.
• SOLLTEN die standardmäßige SELinux-Richtlinie beibehalten, die im Ordner "system/sepolicy" des vorgelagerten Android-Open-Source-Projekts bereitgestellt wird, und diese Richtlinie nur für ihre eigene gerätespezifische Konfiguration ergänzen.

Geräteimplementierungen, die bereits unter einer älteren Android-Version eingeführt wurden und die Anforderungen [C-1-1] und [C-1-5] nicht durch ein Systemsoftwareupdate erfüllen können, sind KÖNNEN von diesen Anforderungen ausgenommen.

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

• [C-2-1] MÜSSEN ein obligatorisches Zugriffssteuerungssystem verwenden, das SELinux entspricht.

Android umfasst mehrere gestaffelte Sicherheitsebenen, die für die Gerätesicherheit von zentraler Bedeutung sind.

Geräteimplementierungen:

• [C-SR] Es wird DRINGEND empfohlen, die Control-Flow Integrity (CFI) oder die Integer Overflow Sanitization (IntSan) für Komponenten, für die diese Funktion aktiviert ist, nicht zu deaktivieren.
• [C-SR] wird dringend empfohlen, sowohl CFI als auch IntSan für alle zusätzlichen sicherheitsrelevanten Userspace-Komponenten zu aktivieren, wie unter CFI und IntSan erläutert.

9.8 Datenschutz

9.8.1 Nutzungsverlauf

Android speichert den Verlauf der Auswahl des Nutzers und verwaltet ihn durch UsageStatsManager.

Geräteimplementierungen:

• [C-0-1] MÜSSEN eine angemessene Aufbewahrungsdauer für einen solchen Nutzerverlauf beibehalten.
• [SR] wird dringend empfohlen, die in der AOSP-Implementierung standardmäßig konfigurierte Aufbewahrungsdauer von 14 Tagen beizubehalten.

Android speichert die Systemereignisse mithilfe der StatsLog-IDs und verwaltet diesen Verlauf über die StatsManager und die IncidentManager-System-API.

Geräteimplementierungen:

• [C-0-2] DARF nur die mit DEST_AUTOMATIC gekennzeichneten Felder im Vorfallsbericht enthalten, der von der System-API-Klasse IncidentManager erstellt wurde.
• [C-0-3] DÜRFEN die Systemereignis-IDs nicht verwenden, um andere Ereignisse als in den StatsLog SDK-Dokumenten beschrieben zu protokollieren. Wenn zusätzliche Systemereignisse protokolliert werden, KÖNNEN sie eine andere Atomkennung im Bereich zwischen 100.000 und 200.000 verwenden.

9.8.2 Aufnahme läuft

Geräteimplementierungen:

• [C-0-1] DÜRFEN KEINE Softwarekomponenten vorab laden oder verbreiten, die persönliche Informationen des Nutzers (z.B. Tastenanschläge oder auf dem Bildschirm angezeigter Text) ohne Zustimmung des Nutzers vom Gerät senden oder laufende Benachrichtigungen löschen.

Wenn Geräteimplementierungen Funktionen im System umfassen, die die auf dem Bildschirm angezeigten Inhalte erfassen und/oder den auf dem Gerät wiedergegebenen Audiostream aufzeichnen, gilt Folgendes:

• [C-1-1] Der Nutzer MUSS eine dauerhafte Benachrichtigung erhalten, wenn diese Funktion aktiviert ist und aktiv Daten erfasst/aufzeichnet.

Wenn Geräteimplementierungen eine standardmäßig aktivierte Komponente enthalten, die Umgebungsgeräusche aufzeichnen kann, um nützliche Informationen zum Nutzerkontext abzuleiten, gilt Folgendes:

• [C-2-1] DARF NICHT im dauerhaften Speicher auf dem Gerät gespeichert oder das aufgezeichnete Rohaudio oder ein anderes Format, das zurück in die Originalaudioinhalte oder ein FAST-Faxe konvertiert werden kann, vom Gerät übertragen, es sei denn, dies ist ausdrücklich erlaubt.

9.8.3 Internetverbindung

Wenn Geräteimplementierungen einen USB-Port mit Unterstützung für den USB-Peripheriemodus haben, gilt Folgendes:

• [C-1-1] MÜSSEN eine Benutzeroberfläche einblenden, in der der Nutzer um seine Zustimmung gebeten wird, bevor er über den USB-Port auf den Inhalt des freigegebenen Speichers zugreifen darf.

9.8.4 Netzwerkverkehr

Geräteimplementierungen:

• [C-0-1] MÜSSEN die Root-Zertifikate für den vertrauenswürdigen Zertifizierungsstellenspeicher des Systems vorinstallieren, die im vorgelagerten Android-Open-Source-Projekt bereitgestellt wurden.
• [C-0-2] MÜSSEN mit einem leeren Root-CA-Nutzerspeicher ausgeliefert werden.
• [C-0-3] MÜSSEN dem Nutzer eine Warnung angezeigt werden, die besagt, dass der Netzwerkverkehr möglicherweise überwacht wird, wenn eine Root-Zertifizierungsstelle des Nutzers hinzugefügt wird.

Wenn Gerätetraffic über ein VPN weitergeleitet wird, gilt für Geräteimplementierungen Folgendes:

• [C-1-1] MUSS dem Nutzer eine Warnung mit folgenden Informationen anzeigen:
  • Dieser Netzwerkverkehr wird möglicherweise überwacht.
  • Dieser Netzwerkverkehr wird über die spezifische VPN-Anwendung geleitet, die das VPN bereitstellt.

Wenn Geräteimplementierungen einen Mechanismus haben, der standardmäßig standardmäßig aktiviert ist und Netzwerkdatenverkehr über einen Proxyserver oder VPN-Gateway weiterleitet (z. B. durch Vorabladen eines VPN-Dienstes mit gewährter android.permission.CONTROL_VPN), gilt Folgendes:

• [C-2-1] MÜSSEN vor der Aktivierung dieses Mechanismus die Einwilligung des Nutzers einholen, es sei denn , das VPN wird vom Device Policy Controller über die DevicePolicyManager.setAlwaysOnVpnPackage() aktiviert. In diesem Fall muss der Nutzer keine gesonderte Einwilligung geben, sondern nur benachrichtigt werden.

Wenn in Geräteimplementierungen die Funktion „durchgehend aktives VPN“ einer Drittanbieter-VPN-App für Nutzer aktiviert werden soll, gilt Folgendes:

• [C-3-1] MÜSSEN diese Funktion für Apps deaktivieren, die in der Datei AndroidManifest.xml keinen durchgehend aktiven VPN-Dienst unterstützen. Dazu setzen Sie das Attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON auf false.

9.9. Verschlüsselung der Datenspeicherung

Bei AES-Verschlüsselung (Advanced Encryption Standard) liegt, gemessen mit der leistungsfähigsten AES-Technologie auf dem Gerät (z.B. ARM Cryptography Extensions), über 50 MiB/s, Geräteimplementierungen:

• [C-1-1] MUSS die Verschlüsselung der privaten Daten der Anwendung (Partition /data) sowie die Partition /sdcard der Anwendung unterstützen, wenn es sich um einen dauerhaften, nicht austauschbaren Teil des Geräts handelt. Ausgenommen hiervon sind Geräteimplementierungen, die in der Regel gemeinsam genutzt werden (z. B. Fernseher).
• [C-1-2] MÜSSEN die Verschlüsselung von Datenspeichern standardmäßig zu dem Zeitpunkt aktivieren, zu dem der Nutzer die Einrichtung abgeschlossen hat. Ausgenommen hiervon sind Geräteimplementierungen, die normalerweise gemeinsam genutzt werden (z. B. Fernseher).

Wenn die AES-Krypto-Leistung bei oder unter 50 MiB/Sek. liegt, dürfen Geräteimplementierungen Adiantum-XChaCha12-AES anstelle der Form von AES verwenden, die in einem der folgenden Punkte aufgeführt ist: AES-256-XTS in Abschnitt 9.9.2 [C-1-5]; [AES-256 in CBS-C.9.9. AES-256 im Modus „CBS-CTS“.

Geräteimplementierungen, die bereits unter einer älteren Android-Version eingeführt wurden und die Anforderung nicht durch ein Systemsoftwareupdate erfüllen können, sind KÖNNEN von den oben genannten Anforderungen ausgenommen.

Geräteimplementierungen:

• SOLLTEN die oben genannten Anforderungen an die Verschlüsselung von Datenspeicher durch die Implementierung der dateibasierten Verschlüsselung (File-Based Encryption, FBE) erfüllen.

9.9.1 Direct Boot

Geräteimplementierungen:

• [C-0-1] MÜSSEN die APIs für den Direct Boot Mode auch dann implementieren, wenn sie die Speicherverschlüsselung nicht unterstützen.

• [C-0-2] Die Intents ACTION_LOCKED_BOOT_COMPLETED und ACTION_USER_UNLOCKED MÜSSEN weiterhin übertragen werden, um Direct Boot-fähige Anwendungen zu signalisieren, dass die Speicherstandorte für Geräteverschlüsselung (DE) und Credential Encrypted (CE) für Nutzer verfügbar sind.

9.9.2 Dateibasierte Verschlüsselung

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

• [C-1-1] MÜSSEN gestartet werden, ohne dass der Nutzer nach Anmeldedaten gefragt wird, und Direct Boot-fähige Apps den Zugriff auf den DE-Speicher (Device Encrypted = Device Encrypted) ermöglichen, nachdem die Nachricht ACTION_LOCKED_BOOT_COMPLETED gesendet wurde.
• [C-1-2] DARF erst den Zugriff auf den Credential Encrypted (CE)-Speicher gewähren, nachdem der Nutzer das Gerät durch Angabe seiner Anmeldedaten (z. B. Sicherheitscode, PIN, Muster oder Fingerabdruck) entsperrt hat und die ACTION_USER_UNLOCKED-Nachricht übertragen wurde.
• [C-1-3] DARF KEINE Methode zum Entsperren des CE-geschützten Speichers ohne die vom Nutzer bereitgestellten Anmeldedaten oder einen registrierten Treuhandschlüssel anbieten.
• [C-1-4] MÜSSEN den verifizierten Bootmodus unterstützen und sicherstellen, dass DE-Schlüssel kryptografisch an den Hardware-Vertrauensstamm 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 volle 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 CE- und DE-Speicherbereiche:

• [C-1-7] MÜSSEN kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein.

• [C-1-8] CE-Schlüssel MÜSSEN an die Anmeldedaten des Nutzers auf dem Sperrbildschirm gebunden sein.
• [C-1-9] CE-Schlüssel MÜSSEN an einen Standard-Sicherheitscode gebunden werden, wenn der Nutzer keine Anmeldedaten für den Sperrbildschirm angegeben hat.

• [C-1-10] MÜSSEN eindeutig und eindeutig sein. Mit anderen Worten: Der CE- oder DE-Schlüssel eines Nutzers stimmt nicht mit den CE- oder DE-Schlüsseln anderer Nutzer überein.

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

• [C-SR] wird dringend empfohlen, Dateisystemmetadaten wie Dateigrößen, Eigentumsrechte, Modi und erweiterte Attribute (Xattrs) mit einem Schlüssel zu verschlüsseln, der kryptografisch an die Hardware-Root of Trust des Geräts gebunden ist.

• SOLLTEN vorinstallierte wichtige Apps wie Wecker, Telefon oder Messenger auf den Direct Boot-Modus achten.

• KANN alternative Chiffren, Schlüssellängen und Modi für die Verschlüsselung von Dateiinhalten und Dateinamen unterstützen.

Das vorgelagerte Open-Source-Projekt von Android bietet eine bevorzugte Implementierung dieser Funktion, die auf der ext4-Verschlüsselungsfunktion des Linux-Kernels basiert.

9.9.3 Datenträgervollverschlüsselung

Wenn Geräteimplementierungen die Laufwerksverschlüsselung (Full Disk Encryption, FDE) unterstützen, gilt Folgendes:

• [C-1-1] MÜSSEN AES in einem für die Speicherung vorgesehenen Modus (z. B. XTS oder CBC-ESSIV) und mit einer Chiffreschlüssellänge von mindestens 128 Bit verwenden.
• [C-1-2] MÜSSEN einen Standard-Sicherheitscode zum Verpacken des Verschlüsselungsschlüssels verwenden und DÜRFEN den Verschlüsselungsschlüssel zu keinem Zeitpunkt ohne Verschlüsselung in den Speicher schreiben.
• [C-1-3] MÜSSEN den Verschlüsselungsschlüssel standardmäßig mit AES verschlüsseln, es sei denn, der Nutzer deaktiviert dies explizit, es sei denn, er wird gerade aktiv verwendet. Dabei werden die Anmeldedaten für den Sperrbildschirm mithilfe eines langsamen Stretching-Algorithmus (z. B. PBKDF2 oder scrypt) erweitert.
• [C-1-4] Der obige Standardalgorithmus für die Passwortdehnung MÜSSEN kryptografisch an diesen Schlüsselspeicher gebunden werden, 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 Schlüsselspeicher bereitstellt.
• [C-1-5] DARF KEINEN Verschlüsselungsschlüssel vom Gerät senden, selbst wenn er mit einem Nutzer-Sicherheitscode und/oder einem hardwaregebundenen Schlüssel verpackt ist.

Das vorgelagerte Open-Source-Projekt von Android bietet eine bevorzugte Implementierung dieser Funktion, die auf der Linux-Kernelfunktion 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] MÜSSEN über die System-API-Methode PersistentDataBlockManager.getFlashLockState() korrekt melden, ob ihr Bootloader-Status das Flashen des System-Images zulässt. Der Status FLASH_LOCK_UNKNOWN ist für Geräteimplementierungen reserviert, die ein Upgrade von einer früheren Android-Version ausführen, bei denen diese neue System-API-Methode nicht vorhanden war.

• [C-0-2] MUSS zur Geräteintegrität den verifizierten Bootmodus unterstützen.

Wenn Geräteimplementierungen bereits auf einer früheren Android-Version ohne Unterstützung des verifizierten Bootmodus eingeführt werden und diese Funktion nicht durch ein Systemsoftwareupdate unterstützt werden kann, sind sie MÖGLICHERWEISE von der Anforderung ausgenommen.

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] MÜSSEN das Funktions-Flag für die Plattform android.software.verified_boot deklarieren.
• [C-1-2] MUSS bei jeder Startsequenz eine Überprüfung durchführen.
• [C-1-3] MÜSSEN die Bestätigung von einem unveränderlichen Hardwareschlüssel starten, der die Root of Trust ist, und bis zur Systempartition gehen.
• [C-1-4] MÜSSEN in der nächsten Phase jede Überprüfungsphase implementieren, um die Integrität und Authentizität aller Byte zu prüfen, bevor der Code in der nächsten Phase ausgeführt wird.
• [C-1-5] MÜSSEN Verifikationsalgorithmen verwendet werden, die den aktuellen Empfehlungen von NIST für Hash-Algorithmen (SHA-256) und Größen öffentlicher Schlüssel (RSA-2048) entsprechen.
• [C-1-6] DARF NICHT erlauben, den Bootvorgang abzuschließen, wenn die Systemüberprüfung fehlschlägt, es sei denn, der Nutzer willigt ein, trotzdem zu starten. In diesem Fall DÜRFEN die Daten aus nicht verifizierten Speicherblöcken nicht verwendet werden.
• [C-1-7] DÜRFEN NICHT zulassen, dass verifizierte Partitionen auf dem Gerät geändert werden, es sei denn, der Nutzer hat den Bootloader explizit entsperrt.
• [C-SR] Wenn sich im Gerät mehrere separate Chips befinden (z.B. ein Funkgerät oder ein spezialisierter Bildprozessor), wird dringend empfohlen, für jeden einzelnen Chip alle Phasen beim Starten zu überprüfen.
• [C-1-8] MÜSSEN einen manipulationssicheren Speicher verwenden, um zu speichern, ob der Bootloader entsperrt ist. Ein fälschungssicherer Speicher bedeutet, dass der Bootloader erkennen kann, ob er innerhalb von Android manipuliert wurde.
• [C-1-9] MÜSSEN den Nutzer bei der Verwendung des Geräts auffordern und vor einem Wechsel vom gesperrten Bootloader-Modus zum entsperrten Bootloader-Modus eine Bestätigung anfordern.
• [C-1-10] MÜSSEN für von Android verwendete Partitionen (z.B. Boot- und Systempartitionen) einen Rollback-Schutz implementieren und einen manipulationssicheren Speicher zum Speichern der Metadaten verwenden, die zum Ermitteln der minimal zulässigen Betriebssystemversion verwendet werden.
• [C-SR] Wir empfehlen dringend, alle privilegierten APK-Dateien von privilegierten Apps mit einer Vertrauenskette in /system zu prüfen, die durch den verifizierten Bootmodus geschützt ist.
• [C-SR] Wir empfehlen dringend, ausführbare Artefakte, die von einer privilegierten App von außerhalb ihrer APK-Datei geladen werden (z. B. dynamisch geladener oder kompilierter Code), vor der Ausführung zu prüfen, oder UNBEDINGT EMPFOHLEN, sie überhaupt nicht auszuführen.
• SOLLTEN Sie einen Rollback-Schutz für alle Komponenten mit dauerhafter Firmware implementieren (z.B. Modem oder Kamera) und SOLLTEN einen manipulationssicheren Speicher zum Speichern der Metadaten verwenden, die zur Bestimmung der zulässigen Mindestversion verwendet werden.

Wenn Geräteimplementierungen bereits auf einer früheren Version von Android ohne Unterstützung von C-1-8 bis C-1-10 eingeführt wurden und diese Anforderungen nicht durch ein Systemsoftwareupdate erfüllt werden können, sind sie MÖGLICHERWEISE von den Anforderungen ausgenommen.

Das vorgelagerte Open-Source-Projekt von Android bietet eine bevorzugte Implementierung dieser Funktion im Repository external/avb/, das in den Bootloader integriert werden kann, der zum Laden von Android verwendet wird.

Geräteimplementierungen:

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

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

• [C-3-1] MÜSSEN true für die ConfirmationPrompt.isSupported() API melden.
• [C-3-2] MÜSSEN sicherstellen, dass die sichere Hardware die vollständige Kontrolle über den Bildschirm übernimmt, sodass das Android-Betriebssystem ihn nicht blockieren kann, ohne dass dies durch die sichere Hardware erkannt wird.
• [C-3-3] MUSS sicherstellen, dass sichere Hardware die volle 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 über die KeyChain API oder die Keystore API für kryptografische Vorgänge verwenden. Geräteimplementierungen:

• [C-0-1] MÜSSEN zulassen,dass mindestens 8.192 Schlüssel importiert oder generiert werden.
• [C-0-2] Die Authentifizierung auf dem Sperrbildschirm MUSS die Anzahl der Versuche begrenzen und MUSS einen exponentiellen Backoff-Algorithmus haben. Nach 150 fehlgeschlagenen Versuchen MUSS die Verzögerung mindestens 24 Stunden pro Versuch betragen.
• SOLLTE die Anzahl der Schlüssel, die generiert werden können, nicht einschränken

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

• [C-1-1] MÜSSEN die Schlüsselspeicherimplementierung in einer isolierten Ausführungsumgebung sichern.
• [C-1-2] MÜSSEN Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie Hash-Funktionen der Familie MD5, SHA1 und SHA-2 haben, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich zu unterstützen, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird. Sichere Isolation MÜSSEN alle potenziellen Mechanismen blockieren, über die Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das vorgelagerte Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternativ können auch eine andere ARM TrustZone-basierte Lösung oder eine von einem Drittanbieter geprüfte sichere Implementierung einer ordnungsgemäßen Hypervisor-basierten Isolierung verwendet werden.
• [C-1-3] MÜSSEN die Sperrbildschirm-Authentifizierung in der isolierten Ausführungsumgebung durchführen und nur bei erfolgreicher Ausführung die Verwendung der mit der Authentifizierung verbundenen Schlüssel zulassen. Anmeldedaten für den Sperrbildschirm MÜSSEN so gespeichert werden, dass nur die isolierte Ausführungsumgebung die Sperrbildschirm-Authentifizierung durchführen kann. Das vorgelagerte Android-Open-Source-Projekt bietet den Gatekeeper Hardware Abstraktionsschicht (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.
• [C-1-4] MÜSSEN die Schlüsselattestierung unterstützen, wenn der Attestierungssignaturschlüssel durch sichere Hardware geschützt und die Signatur auf sicherer Hardware erfolgt. Die Signaturschlüssel für die Attestierung MÜSSEN für eine ausreichend große Anzahl von Geräten freigegeben werden, um zu verhindern, dass die Schlüssel als Gerätekennungen verwendet werden. Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, denselben Attestierungsschlüssel zu verwenden, sofern nicht mindestens 100.000 Einheiten einer bestimmten Artikelnummer erzeugt werden. Wenn mehr als 100.000 Einheiten einer Artikelnummer produziert werden, kann für 100.000 Einheiten ein anderer Schlüssel verwendet werden.
• [C-1-5] MÜSSEN Nutzer das Zeitlimit für den Ruhemodus für den Wechsel vom entsperrten in den gesperrten Zustand mit einem zulässigen Mindestzeitlimit von bis zu 15 Sekunden auswählen können.

Wenn eine Geräteimplementierung bereits unter einer früheren Android-Version gestartet wurde, ist ein solches Gerät von der Anforderung ausgenommen, einen Schlüsselspeicher in einer isolierten Ausführungsumgebung zu verwenden und die Schlüsselattestierung zu unterstützen, es sei denn, es deklariert die Funktion android.hardware.fingerprint, die einen Schlüsselspeicher erfordert, der von einer isolierten Ausführungsumgebung unterstützt wird.

9.11.1. Sicherer Sperrbildschirm

Die AOSP-Implementierung folgt einem gestaffelten Authentifizierungsmodell, bei dem eine auf Wissensfabriken basierende primäre Authentifizierung entweder durch eine sekundäre starke biometrische Methode oder durch schwächere tertiäre Modalitäten gestützt werden kann.

Geräteimplementierungen:

• [C-SR] 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 x 3 Punkten

Beachten Sie, dass die oben genannten Authentifizierungsmethoden in diesem Dokument als empfohlene primäre Authentifizierungsmethoden bezeichnet werden.

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

• [C-2-1] MUSS die Nutzerauthentifizierungsmethode sein, wie unter Nutzerauthentifizierung für Schlüsselverwendung erforderlich beschrieben.
• [C-2-2] MÜSSEN alle Schlüssel für eine Drittanbieter-Entwickler-App entsperren, wenn der Nutzer den sicheren Sperrbildschirm entsperrt. Beispielsweise MÜSSEN alle Schlüssel für eine Drittanbieter-Entwickler-App über relevante APIs wie createConfirmDeviceCredentialIntent und setUserAuthenticationRequired verfügbar sein.

Wenn bei Geräteimplementierungen die Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzugefügt oder geändert werden, sofern dies auf einem bekannten Secret basiert, und eine neue Authentifizierungsmethode verwenden, die als sichere Methode zum Sperren des Bildschirms behandelt wird, gilt Folgendes:

• [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 (z.B. 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 Richtlinie für die Passwortqualität in der Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_SOMETHING festgelegt hat.

Wenn bei 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 biometrischen Verfahren als sichere Methode zum Sperren des Bildschirms basiert, gilt die neue Methode:

• [C-4-1] MÜSSEN alle in Abschnitt 7.3.10.2 beschriebenen Anforderungen erfüllen.
• [C-4-2] MÜSSEN über einen Fallback-Mechanismus verfügen, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Secret basieren.
• [C-4-3] MÜSSEN deaktiviert sein und nur die empfohlene primäre Authentifizierung zum Entsperren des Bildschirms zulassen, wenn die Device Policy Controller-Anwendung (DPC) die Keguard-Funktionsrichtlinie durch Aufrufen der Methode DevicePolicyManager.setKeyguardDisabledFeatures() mit einem der zugehörigen biometrischen Flags (z.B. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE oder KEYGUARD_DISABLE_IRIS) festgelegt hat.
• [C-4-4] MÜSSEN den Nutzer mindestens einmal innerhalb von 72 Stunden zur primären Authentifizierung (z.B. PIN, Muster, Passwort) auffordern.
• [C-4-5] MÜSSEN eine falsche Annahmequote haben, die mindestens dem entspricht, was für einen Fingerabdrucksensor erforderlich ist, wie in Abschnitt 7.3.10 beschrieben. Andernfalls MÜSSEN sie deaktiviert werden und die empfohlene primäre Authentifizierung zum Entsperren des Bildschirms nur zulassen, wenn die DPC-App (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] Wir empfehlen dringend, die Akzeptanzraten für Spoofing und Hochstapler festzulegen, die mindestens dem Wert entspricht, der für einen Fingerabdrucksensor erforderlich ist (siehe Abschnitt 7.3.10).
• [C-4-6] MÜSSEN über eine sichere Verarbeitungspipeline verfügen, die verhindert, dass aufgrund einer Manipulation des Betriebssystems oder des Kernels keine Daten direkt eingeschleust werden, um sich fälschlicherweise als Nutzer zu authentifizieren.
• [C-4-7] MUSS mit einer ausdrücklichen Bestätigung (z. B. Drücken einer Taste) gekoppelt werden, um den Zugriff auf Schlüsselspeicherschlüssel zu ermöglichen, wenn die Anwendung true für KeyGenParameterSpec.Built.setUserAuthenticationRequired() festlegt und das biometrische Verfahren passiv ist (z. B. Gesicht oder Iris, wenn kein explizites Absichtssignal vorhanden ist).
• [C-SR] Es wird dringend empfohlen, sich so sicher zu machen, dass ein Betriebssystem oder ein Kernel manipuliert werden kann. Das bedeutet zum Beispiel, dass die Bestätigungsaktion basierend auf einer physischen Schaltfläche über einen GPIO-(Eingabe-/Ausgabe-)Pin eines Secure Elements (SE) weitergeleitet wird, das ausschließlich durch Drücken einer physischen Taste angestoßen werden kann.

Wenn die biometrischen Authentifizierungsmethoden die in Abschnitt 7.3.10 beschriebene Akzeptanzrate von Spoofing und Identitätsdiebstahl nicht erreichen, gehen Sie so vor:

• [C-5-1] Die Methoden MÜSSEN deaktiviert werden, wenn die Device Policy Controller-App (DPC) 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] Nach einem Zeitlimit von 4 Stunden bei Inaktivität MUSS der Nutzer zur primären Authentifizierung aufgefordert werden (z. B. mit PIN, Muster, Passwort). Das Zeitlimit für die Inaktivität wird zurückgesetzt, nachdem die Geräteanmeldedaten erfolgreich bestätigt wurden.
• [C-5-3] Die Methoden DÜRFEN NICHT als sicherer Sperrbildschirm behandelt werden und MÜSSEN die Anforderungen erfüllen, die mit C-8 in diesem Abschnitt beginnen.

Wenn bei 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 über einen Fallback-Mechanismus verfügen, um eine der empfohlenen primären Authentifizierungsmethoden zu verwenden, die auf einem bekannten Secret basieren und die Anforderungen für einen sicheren Sperrbildschirm erfüllen.
• [C-6-2] Die neue Methode MÜSSEN deaktiviert werden und nur eine der empfohlenen primären Authentifizierungsmethoden zum Entsperren des Bildschirms zulassen, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie 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 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 MÜSSEN den unten in C-8 aufgeführten Einschränkungen entsprechen.

Wenn Geräteimplementierungen einen sicheren Sperrbildschirm haben und einen oder mehrere Trust Agenten enthalten, die die TrustAgentService System API implementieren, geschieht Folgendes:

• [C-7-1] MUSS im Menü "Einstellungen" und auf dem Sperrbildschirm deutlich erkennbar sein, wenn die Gerätesperre ausgesetzt ist oder von einem Trust Agent entsperrt werden kann. AOSP erfüllt diese Anforderung beispielsweise mit einer Textbeschreibung für die Einstellung „Automatische Sperre“ und „Ein/Aus-Taste wird sofort gesperrt“ sowie ein deutlich erkennbares Symbol auf dem Sperrbildschirm.
• [C-7-2] MÜSSEN alle Trust Agent-APIs in der Klasse DevicePolicyManager, z. B. die Konstante KEYGUARD_DISABLE_TRUST_AGENTS, respektieren und vollständig implementieren.
• [C-7-3] DARF die TrustAgentService.addEscrowToken()-Funktion NICHT vollständig auf einem Gerät implementieren, das als primäres persönliches Gerät verwendet wird (z.B. ein Handheld), aber bei Geräteimplementierungen, die in der Regel gemeinsam genutzt werden (z.B. Android TV- oder Automotive-Geräte), DARF die Funktion vollständig implementiert werden.
• [C-7-4] MÜSSEN alle von TrustAgentService.addEscrowToken() hinzugefügten gespeicherten Tokens verschlüsseln.
• [C-7-5] Der Verschlüsselungsschlüssel DARF NICHT auf dem Gerät gespeichert werden, auf dem er verwendet wird. Beispielsweise ist es mit einem auf einem Smartphone gespeicherten Schlüssel zulässig, ein Nutzerkonto auf einem Fernseher zu entsperren.
• [C-7-6] MÜSSEN den Nutzer über die Auswirkungen auf die Sicherheit informieren, bevor das Treuhandtoken zur Entschlüsselung des Datenspeichers aktiviert wird.
• [C-7-7] MÜSSEN einen Fallback-Mechanismus haben, damit eine der empfohlenen primären Authentifizierungsmethoden verwendet werden kann.
• [C-7-8] Der Nutzer MUSS mindestens alle 72 Stunden zur Eingabe einer der empfohlenen Methoden zur primären Authentifizierung (z. B. PIN, Muster, Passwort) aufgefordert werden.
• [C-7-9] Nach einem Zeitlimit von 4 Stunden bei Inaktivität MUSS der Nutzer eine der empfohlenen Methoden zur primären Authentifizierung (z. B. PIN, Muster, Passwort) anfordern. Das Zeitlimit für die Inaktivität wird zurückgesetzt, nachdem die Geräteanmeldedaten erfolgreich bestätigt wurden.
• [C-7-10] DARF NICHT als sicherer Sperrbildschirm behandelt werden und MÜSSEN die in C-8 unten aufgeführten Einschränkungen einhalten.

Wenn bei 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 Keyguard verwendet wird:

• [C-8-1] Die neue Methode MUSS deaktiviert werden, wenn die Device Policy Controller-App (DPC) die Richtlinie für die Passwortqualität in der 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 das Ablaufen des Passworts NICHT zurücksetzen.
• [C-8-3] Sie DARF NICHT den Zugriff auf Schlüsselspeicher authentifizieren, wenn die Anwendung true für KeyGenParameterSpec.Builder.setUserAuthenticationRequired() festlegt.

9.11.2. Kofferraum

Mit dem Android-Schlüsselspeichersystem 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] 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] MÜSSEN dedizierte sichere Hardware zur Sicherung des Schlüsselspeichers und der sicheren Nutzerauthentifizierung bereitstellen.

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

• [C-1-4] MÜSSEN Sie sicherstellen, dass Peripheriegeräte, die mit dem Zugangspunkt gemeinsam genutzt werden, die StrongBox-Verarbeitung in keiner Weise verändern und keine Informationen von der StrongBox beziehen können. Der AP kann den Zugriff auf StrongBox deaktivieren oder blockieren.

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

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

• [C-1-7] MUSS manipulationsgeschützt sein, einschließlich physikalischer Durchdringung und Störungen.

• [C-1-8] MUSS einen Seitenkanalwiderstand haben, einschließlich Widerstand gegen das Auslaufen von Informationen über die Seitenkanäle für Strom, Zeit, elektromagnetische und Wärmestrahlung.

• [C-1-9] MÜSSEN über einen sicheren Speicher verfügen, der Vertraulichkeit, Integrität, Authentizität, Konsistenz und Aktualität der Inhalte gewährleistet. Der Speicher DÜRFEN NICHT gelesen oder geändert werden, sofern dies nicht gemäß den StrongBox-APIs zulässig ist.

• Um die Einhaltung von [C-1-3] bis [C-1-9] zu prüfen, müssen folgende Geräteimplementierungen erfüllt sein:

  • [C-1-10] MÜSSEN die Hardware enthalten, die gemäß dem Secure IC Protection Profile BSI-CC-PP-0084-2014 zertifiziert oder von einem landesweit akkreditierten Testlabor bewertet wurde, das eine Bewertung von Sicherheitslücken mit hohem Angriffspotenzial gemäß der Common Criteria-Anwendung des Angriffspotenzials auf Smartcards aufweist.
  • [C-1-11] MUSS die Firmware enthalten, die von einem landesweit akkreditierten Testlabor bewertet wird, das eine Bewertung des Angriffspotenzials mit hohem Angriffspotenzial gemäß der Common Criteria-Anwendung des Angriffspotenzials auf Smartcards anbietet.
  • [C-SR] wird dringend empfohlen, die Hardware einzubeziehen, die anhand eines Sicherheitsziels, EAL 5 (Evaluation Assurance Level, EAL) 5 (geprüft durch AVA_VAN.5) bewertet wird. Die EAL 5-Zertifizierung wird voraussichtlich in einem zukünftigen Release eine Voraussetzung sein.

• [C-SR] wird UNBEDINGT dazu empfohlen, die IAR (Insider-Angriffe) zu schützen. Das bedeutet, dass Insider mit Zugriff auf Firmware-Signaturschlüssel keine Firmware produzieren können, die dazu führt, dass StrongBox Geheimnisse preisgibt, Funktionssicherheitsanforderungen umgeht oder anderweitig den Zugriff auf sensible Nutzerdaten ermöglicht. Die empfohlene Methode zur Implementierung von IAR besteht darin, Firmware-Updates nur dann zuzulassen, wenn das Passwort des primären Nutzers über den IAuthSecret-HAL bereitgestellt wird.

9.12. Löschen von Daten

Alle Geräteimplementierungen:

• [C-0-1] MÜSSEN Nutzern eine Methode zum Zurücksetzen auf die Werkseinstellungen zur Verfügung stellen.
• [C-0-2] MÜSSEN alle nutzergenerierten Daten löschen. Das sind alle Daten mit Ausnahme der folgenden:
  • Das System-Image
  • Alle Betriebssystemdateien, die für das System-Image erforderlich sind
• [C-0-3] MÜSSEN die Daten auf eine Weise löschen, die den relevanten Branchenstandards wie NIST SP800-88 entspricht.
• [C-0-4] MÜSSEN den oben beschriebenen Vorgang zum Zurücksetzen auf die Werkseinstellungen auslösen, wenn die DevicePolicyManager.wipeData() API von der Device Policy Controller-App des Hauptnutzers aufgerufen wird.
• KANN eine Option zur schnellen Datenlöschung anbieten, bei der nur eine logische Löschung durchgeführt wird.

9:13. Abgesicherter Modus

Android bietet den abgesicherten Bootmodus, mit dem Nutzer in einem Modus starten können, in dem nur vorinstallierte System-Apps ausgeführt werden und alle Drittanbieter-Apps deaktiviert sind. In diesem Modus, der als „Abgesicherter Modus“ bekannt ist, können Nutzer potenziell schädliche Apps von Drittanbietern deinstallieren.

Es gibt folgende Geräteimplementierungen:

• [SR] UNBEDINGT EMPFOHLEN, den abgesicherten Bootmodus zu implementieren.

Wenn Geräteimplementierungen den abgesicherten Bootmodus implementieren, gilt Folgendes:

• [C-1-1] MÜSSEN dem Nutzer die Möglichkeit geben, den abgesicherten Bootmodus so zu starten, dass er mit auf dem Gerät installierten Drittanbieter-Apps nicht unterbrochen werden kann, es sei denn, die Drittanbieter-App ist ein Device Policy Controller und hat das Flag UserManager.DISALLOW_SAFE_BOOT auf „true“ gesetzt.

• [C-1-2] MÜSSEN Nutzern die Möglichkeit geben, Drittanbieter-Apps im abgesicherten Modus zu deinstallieren.

• SOLLTE dem Nutzer eine Option anbieten, mit der er über das Bootmenü in den abgesicherten Modus wechseln kann.

9:14. Kfz-Systemisolierung

Android Automotive-Geräte müssen Daten mit wichtigen Fahrzeug-Subsystemen austauschen. Dazu verwenden sie den Fahrzeug-HAL, um Nachrichten über Fahrzeugnetzwerke wie den CAN-Bus zu senden und zu empfangen.

Der Datenaustausch kann gesichert werden, indem Sicherheitsfunktionen unterhalb der Android-Framework-Ebenen implementiert werden, um bösartige oder unbeabsichtigte Interaktionen mit diesen Subsystemen zu verhindern.

9:15. Abos

„Abos“ beziehen sich auf die Details zur Abrechnungsbeziehung, die von einem Mobilfunkanbieter über SubscriptionManager.setSubscriptionPlans() bereitgestellt werden.

Alle Geräteimplementierungen:

• [C-0-1] MÜSSEN Abonnements nur an die App des Mobilfunkanbieters zurückgeben, von der sie ursprünglich bereitgestellt wurden.
• [C-0-2] DÜRFEN KEINE Abos per Remotezugriff sichern oder hochladen.
• [C-0-3] MUSS nur Überschreibungen wie SubscriptionManager.setSubscriptionOverrideCongested() aus der Mobilfunkanbieter-App zulassen, die aktuell gültige Abos anbietet.

10. Software-Kompatibilitätstests

Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen. Beachten Sie jedoch, dass kein Softwaretestpaket vollständig umfassend ist. Aus diesem Grund wird Entwicklern, die Geräte implementieren, Dringend empfohlen, die im Android Open Source Project verfügbare Referenz und bevorzugte Implementierung von Android so gering wie möglich zu ändern. Dadurch wird das Risiko minimiert, dass Fehler eingebaut werden, die zu Inkompatibilitäten führen, die überarbeitet werden müssen und potenzielle Geräteupdates erfordern.

10.1. Kompatibilitätstest-Suite

Geräteimplementierungen:

• [C-0-1] MÜSSEN die im Android Open Source Project verfügbare Android Compatibility Test Suite (CTS) mit der endgültigen Versandsoftware auf dem Gerät erfolgreich durchlaufen.

• [C-0-2] MÜSSEN die Kompatibilität bei Unklarheiten in CTS und bei Neuimplementierungen von Teilen des Referenzquellcodes gewährleisten.

Das CTS ist für die Ausführung auf einem echten Gerät konzipiert. Wie jede Software kann auch die CTS selbst Fehler enthalten. Die CTS wird unabhängig von dieser Kompatibilitätsdefinition versioniert und für Android 9 können mehrere Versionen der CTS veröffentlicht werden.

Geräteimplementierungen:

• [C-0-3] MÜSSEN die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbare CTS-Version verwendet werden.

• SOLLTEN so weit wie möglich die Referenzimplementierung in der Android Open Source-Struktur verwenden.

10.2. CTS-Prüfung

Der CTS Verifier ist in der Kompatibilitätstest-Suite enthalten und wurde für einen menschlichen Bediener vorgesehen, um Funktionen zu testen, die von einem automatisierten System nicht getestet werden können, z. B. die korrekte Funktion einer Kamera und von Sensoren.

Geräteimplementierungen:

• [C-0-1] MÜSSEN alle anwendbaren Fälle in der CTS-Prüfung korrekt ausführen.

Der CTS Verifier bietet Tests für viele Arten von Hardware, unter anderem für einige optionale Hardware.

Geräteimplementierungen:

• [C-0-2] MÜSSEN alle Tests für ihre Hardware bestehen. Wenn ein Gerät beispielsweise über einen Beschleunigungsmesser verfügt, MÜSSEN die Testläufe des Beschleunigungsmessers im CTS Verifier ordnungsgemäß ausgeführt werden.

Testläufe für Funktionen, die in diesem Dokument zur Kompatibilitätsdefinition als optional gekennzeichnet sind, können übersprungen oder weggelassen werden.

• [C-0-2] Jedes Gerät und jeder Build MÜSSEN den CTS Verifier wie oben beschrieben korrekt ausführen. Da viele Builds sehr ähnlich sind, wird jedoch nicht erwartet, dass Geräte-Implementierer den CTS Verifier explizit auf Builds ausführen, die sich nur geringfügig unterscheiden. Insbesondere bei Geräteimplementierungen, die sich von einer Implementierung unterscheiden, die den CTS Verifier nur durch die Gruppe der enthaltenen Sprachen, Branding usw. bestanden hat, KÖNNEN den CTS Verifier-Test weglassen.

11. Software zum Aktualisieren

• [C-0-1] Geräteimplementierungen MÜSSEN einen Mechanismus enthalten, der die gesamte Systemsoftware ersetzt. Der Mechanismus muss keine „Live“-Upgrades durchführen, d. h. es ist KÖNNEN ein Neustart des Geräts erforderlich. Es kann jede Methode verwendet werden, vorausgesetzt, sie ersetzt die gesamte auf dem Gerät vorinstallierte Software. Diese Anforderung wird beispielsweise von einem der folgenden Ansätze erfüllt:

  • Over-the-Air-Downloads (OTA) mit Offline-Aktualisierung durch Neustart
  • Aktualisierungen per Tethering von einem Host-PC über USB
  • „Offline“-Updates werden nach einem Neustart durchgeführt und über eine Datei auf einem Wechseldatenträger aktualisiert.

• [C-0-2] Der verwendete Aktualisierungsmechanismus MÜSSEN Updates unterstützen, ohne die Nutzerdaten zu löschen. Das heißt, der Aktualisierungsmechanismus MÜSSEN die privaten Daten der Anwendung und die freigegebenen Daten der Anwendung beibehalten. Beachten Sie, dass die vorgelagerte Android-Software einen Updatemechanismus enthält, der diese Anforderung erfüllt.

Wenn Geräteimplementierungen eine nicht getaktete Datenverbindung unterstützen, z. B. ein 802.11- oder Bluetooth PAN-Profil (Personal Area Network), gilt Folgendes:

• [C-1-1] MÜSSEN OTA-Downloads mit Offline-Updates per Neustart unterstützen.

Bei Geräteimplementierungen, die mit Android 6.0 und höher auf den Markt gebracht werden, sollte der Updatemechanismus die Überprüfung unterstützen, ob das System-Image binär identisch mit dem erwarteten Ergebnis nach einem OTA-Update ist. Die blockbasierte OTA-Implementierung im vorgelagerten Android-Open-Source-Projekt, die seit Android 5.1 hinzugefügt wurde, erfüllt diese Anforderung.

Außerdem sollten Geräteimplementierungen A/B-Systemupdates unterstützen. Der AOSP implementiert diese Funktion mithilfe des Boot-Steuerelement-HAL.

Wenn in einer Geräteimplementierung ein Fehler gefunden wird, nachdem diese veröffentlicht wurde, aber innerhalb der angemessenen Produktlebensdauer, die in Absprache mit dem Android-Kompatibilitätsteam ermittelt wurde, um die Kompatibilität von Drittanbieter-Apps zu beeinflussen, dann:

• [C-2-1] Der Implementierer des Geräts MÜSSEN den Fehler über ein verfügbares Softwareupdate beheben, das mit dem oben beschriebenen Mechanismus angewendet werden kann.

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

• [C-3-1] MÜSSEN das in der Klasse SystemUpdatePolicy beschriebene Verhalten implementieren.

12. Änderungsprotokoll für Dokumente

Für eine Zusammenfassung der Änderungen an der Kompatibilitätsdefinition in diesem Release:

• Änderungsprotokoll des Dokuments

Zusammenfassung der Änderungen in einzelnen Abschnitten:

1. Einführung
2. Gerätetypen
3. Software
4. Anwendungspaket erstellen
5. Multimedia
6. Entwicklertools und -optionen
7. Kompatibilität mit Hardware
8. Leistung und Leistung
9. Sicherheitsmodell
10. Software-Kompatibilitätstests
11. Aktualisierungen von Software
12. Änderungsprotokoll für Dokumente
13. Kontakt

12.1 Tipps zum Aufrufen des Änderungsprotokolls

Änderungen sind wie folgt gekennzeichnet:

• CDD
  Wesentliche Änderungen an den Kompatibilitätsanforderungen.

• Google Docs
  Optische oder entwicklungsbezogene Änderungen.

Für eine optimale Darstellung hängen Sie die URL-Parameter pretty=full und no-merges an Ihre Änderungsprotokoll-URLs an.

13. Kontakt

Sie können dem Forum zur Android-Kompatibilität beitreten und dort um Erläuterungen bitten oder Probleme melden, die im Dokument Ihrer Meinung nach nicht behandelt werden.