Kompatibilitätsdefinition für Android 5.1

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

1. Einführung

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

Die Verwendung von „MUST“, „MUST NOT“, „REQUIRED“, „SHALL“, „SHALL NOT“, „SHOULD“, „SHOULD NOT“, „RECOMMENDED“, „MAY“ und „OPTIONAL“ entspricht dem IETF-Standard, der in RFC2119 [Ressourcen, 1] definiert ist.

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

Damit Geräte als mit Android 5.1 kompatibel gelten, MÜSSEN sie die in dieser Kompatibilitätsdefinition aufgeführten Anforderungen erfüllen, einschließlich aller Dokumente, die durch Verweis einbezogen werden.

Wenn diese Definition oder die in Abschnitt 10 beschriebenen Softwaretests nicht eindeutig oder unvollständig sind, liegt es in der Verantwortung des Geräteimplementers, für die Kompatibilität mit vorhandenen Implementierungen zu sorgen.

Aus diesem Grund ist das Open-Source-Projekt von Android [Ressourcen, 2] sowohl die Referenz- als auch die bevorzugte Implementierung von Android. Geräteimplementierer sollten ihre Implementierungen nach Möglichkeit auf dem „Upstream“-Quellcode basieren, der im Android Open Source Project verfügbar ist. Einige Komponenten können zwar hypothetisch durch alternative Implementierungen ersetzt werden, dies wird jedoch dringend abgeraten, da das Bestehen der Softwaretests dadurch erheblich erschwert wird. Es liegt in der Verantwortung des Implementators, für eine vollständige Verhaltenskompatibilität mit der Standard-Android-Implementierung zu sorgen, einschließlich und über die Kompatibilitätstestsuite hinaus. Bestimmte Komponentenersetzungen und ‑änderungen sind in diesem Dokument ausdrücklich untersagt.

Viele der in Abschnitt 14 aufgeführten Ressourcen sind direkt oder indirekt aus dem Android SDK abgeleitet und funktional mit den Informationen in der Dokumentation dieses SDK identisch. Wenn diese Kompatibilitätsdefinition oder die Kompatibilitätstestsuite nicht mit der SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als verbindlich. Alle technischen Details in den Referenzen in Abschnitt 14 sind Teil dieser Kompatibilitätsdefinition.

2. Gerätetypen

Das Android Open Source Project wurde zwar für die Implementierung verschiedener Gerätetypen und Formfaktoren verwendet, viele Aspekte der Architektur und Kompatibilitätsanforderungen wurden jedoch für Mobilgeräte optimiert. Ab Android 5.0 soll das Android Open Source Project eine größere Vielfalt an Gerätetypen unterstützen, wie in diesem Abschnitt beschrieben.

Ein Android-Handheld-Gerät ist eine Android-Geräteimplementierung, die in der Regel in der Hand gehalten wird, z. B. MP3-Player, Smartphones und Tablets. Implementierungen für Android-Mobilgeräte:

• Es MUSS einen Touchscreen haben, der in das Gerät integriert ist.
• MUSS eine Stromquelle haben, die Mobilität ermöglicht, z. B. einen Akku.

Ein Android TV-Gerät ist eine Android-Geräteimplementierung, die eine Unterhaltungsoberfläche für digitale Medien, Filme, Spiele, Apps und/oder Live-TV für Nutzer bietet, die etwa drei Meter entfernt sitzen (eine „Lean-back-Oberfläche“ oder „10-Foot-User-Interface“). Android TV-Geräte:

• Es MUSS einen integrierten Bildschirm ODER einen Videoausgang wie VGA, HDMI oder einen kabellosen Anschluss für das Display haben.
• MÜSSEN die Funktionen „android.software.leanback“ und „android.hardware.type.television“ deklarieren [Ressourcen, 3].

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

• MUSS ein Display mit einer physischen Diagonale von 28 bis 64 mm haben.
• Die Funktion „android.hardware.type.watch“ MUSS deklariert werden.
• MUSS uiMode = UI_MODE_TYPE_WATCH unterstützen [Ressourcen, 4].

Eine Android Automotive-Implementierung bezieht sich auf eine Auto-Haupteinheit, auf der Android als Betriebssystem für einen Teil oder das gesamte System und/oder die Infotainmentfunktionen ausgeführt wird. Android Automotive-Implementierungen MÜSSEN uiMode = UI_MODE_TYPE_CAR unterstützen [Ressourcen, 111].

Alle Android-Geräte, die in keinen der oben genannten Gerätetypen fallen, MÜSSEN trotzdem alle Anforderungen in diesem Dokument erfüllen, um mit Android 5.1 kompatibel zu sein, es sei denn, die Anforderung gilt ausdrücklich nur für einen bestimmten Android-Gerätetyp.

2.1 Gerätekonfigurationen

Hier sind die wichtigsten Unterschiede bei der Hardwarekonfiguration nach Gerätetyp zusammengefasst. Leere Zellen stehen für „MÖGLICH“. Nicht alle Konfigurationen sind in dieser Tabelle aufgeführt. Weitere Informationen finden Sie in den entsprechenden Hardwareabschnitten.

Kategorie	Funktion	Abschnitt	Handkamera	TV	Unterhaltung	Automotive	Sonstiges
Eingabe	Steuerkreuz	7.2.2. Bedienung ohne Touchbedienung		MUSS
	Touchscreen	7.2.4. Touchscreen-Eingabe	MUSS		MUSS		SOLLTE
	Mikrofon	7.8.1. Mikrofon	MUSS	SOLLTE	MUSS	MUSS	SOLLTE
Sensoren	Beschleunigungsmesser	7.3.1 Beschleunigungsmesser	SOLLTE		SOLLTE		SOLLTE
	GPS	7.3.3. GPS	SOLLTE			SOLLTE
Konnektivität	WLAN	7.4.2. IEEE 802.11	SOLLTE	MUSS		SOLLTE	SOLLTE
	Wi-Fi Direct	7.4.2.1. Wi‑Fi Direct	SOLLTE	SOLLTE			SOLLTE
	Bluetooth	7.4.3. Bluetooth	SOLLTE	MUSS	MUSS	MUSS	SOLLTE
	Bluetooth Low Energy	7.4.3. Bluetooth	SOLLTE	MUSS	SOLLTE	SOLLTE	SOLLTE
	USB-Peripheriegerät/-Host-Modus	7.7. USB	SOLLTE			SOLLTE	SOLLTE
Ausgabe	Lautsprecher- und/oder Audioausgangsanschlüsse	7.8.2. Audioausgabe	MUSS	MUSS		MUSS	MUSS

3. Software

3.1. Kompatibilität mit verwalteten APIs

Die verwaltete Dalvik-Bytecode-Ausführungsumgebung ist das primäre Mittel für Android-Anwendungen. Die Android API (Application Programming Interface) ist die Gruppe von Android-Plattformschnittstellen, die für Anwendungen verfügbar sind, die in der verwalteten Laufzeitumgebung ausgeführt werden. Geräteimplementierungen MÜSSEN vollständige Implementierungen aller dokumentierten APIs bereitstellen, die vom Android SDK [Ressourcen, 5] oder von APIs mit dem Markierungs-Tag „@SystemApi“ im Upstream-Android-Quellcode freigegeben wurden.

Geräteimplementierungen dürfen KEINE verwalteten APIs auslassen, API-Schnittstellen oder ‑Signaturen ändern, vom dokumentierten Verhalten abweichen oder No-Ops enthalten, es sei denn, dies ist ausdrücklich in dieser Kompatibilitätsdefinition erlaubt.

Diese Kompatibilitätsdefinition erlaubt es, dass einige Arten von Hardware, für die Android APIs enthält, von Geräteimplementierungen weggelassen werden. In solchen Fällen MÜSSEN die APIs weiterhin vorhanden sein und sich angemessen verhalten. In Abschnitt 7 finden Sie spezifische Anforderungen für dieses Szenario.

3.2 Soft API Compatibility

Neben den verwalteten APIs aus Abschnitt 3.1 enthält Android auch eine wichtige „weiche“ API, die nur zur Laufzeit verwendet wird. Dazu gehören beispielsweise Intents, Berechtigungen und ähnliche Aspekte von Android-Apps, die nicht zur Kompilierungszeit der App erzwungen werden können.

3.2.1. Berechtigungen

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

3.2.2. Parameter erstellen

Die Android APIs enthalten eine Reihe von Konstanten in der Klasse „android.os.Build“ [Resources, 7], die das aktuelle Gerät beschreiben sollen. Um für alle Geräteimplementierungen einheitliche, aussagekräftige Werte bereitzustellen, enthält die folgende Tabelle zusätzliche Einschränkungen für die Formate dieser Werte, die von Geräteimplementierungen einzuhalten SIND.

Parameter	Details
VERSION.RELEASE	Die Version des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format. Dieses Feld MUSS einen der Stringwerte haben, die in [Ressourcen, 8] definiert sind.
VERSION.SDK	Die Version des derzeit ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 5.1 MUSS dieses Feld den Ganzzahlwert 22 haben.
VERSION.SDK_INT	Die Version des derzeit ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 5.1 MUSS dieses Feld den Ganzzahlwert 22 haben.
VERSION.INCREMENTAL	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Version des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format angibt. Dieser Wert darf NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. Dieses Feld wird in der Regel verwendet, um anzugeben, welche Build-Nummer oder Änderungs-ID der Quellkontrollversion zum Generieren des Builds verwendet wurde. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String („"") sein.
BRETTSPIEL	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Hardware des Geräts in einem visuell lesbaren Format angibt. Dieses Feld kann beispielsweise verwendet werden, um die spezifische Version des Boards anzugeben, das das Gerät mit Strom versorgt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
MARKE	Ein Wert, der den Markennamen widerspiegelt, der mit dem Gerät verknüpft ist und den Endnutzer kennen. MÜSSEN in einem für Menschen lesbaren Format vorliegen und SOLLEN den Hersteller des Geräts oder die Marke des Unternehmens repräsentieren, unter dem das Gerät vertrieben wird. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
SUPPORTED_ABIS	Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
SUPPORTED_32_BIT_ABIS	Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
SUPPORTED_64_BIT_ABIS	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
CPU_ABI	Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
CPU_ABI2	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
GERÄT	Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen enthält, der die Konfiguration der Hardwarefunktionen und das Industriedesign des Geräts identifiziert. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
FINGERPRINT	Ein String, der diesen Build eindeutig identifiziert. Sie sollte für Menschen gut lesbar sein. Es MUSS dieser Vorlage entsprechen: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Beispiel: acme/myproduct/mydevice:5.1/LMYXX/3359:userdebug/test-keys Der Fingerabdruck darf KEINE Leerzeichen enthalten. Wenn andere Felder in der Vorlage oben Leerzeichen enthalten, MÜSSEN sie im Build-Fingerabdruck durch ein anderes Zeichen ersetzt werden, z. B. durch den Unterstrich („_“). Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein.
Hardware	Der Name der Hardware (aus der Kernel-Befehlszeile oder /proc). Sie sollte in einem für Menschen lesbaren Format vorliegen. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
HOST	Ein String, der den Host, auf dem der Build erstellt wurde, eindeutig in einem für Menschen lesbaren Format identifiziert. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
ID	Eine vom Geräteimplementierer ausgewählte Kennung für eine bestimmte Version in einem für Menschen lesbaren Format. Dieses Feld kann mit „android.os.Build.VERSION.INCREMENTAL“ identisch sein, sollte aber einen aussagekräftigen Wert haben, damit Endnutzer Software-Builds unterscheiden können. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein 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 Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
MODELL	Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endnutzer bekannt ist. Dies sollte derselbe Name sein, unter dem das Gerät vermarktet und an Endnutzer verkauft wird. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
PRODUKT/FUNKTION	Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des jeweiligen Produkts (SKU) enthält und innerhalb derselben Marke eindeutig sein MUSS. MÜSSEN für Menschen lesbar sein, sind aber nicht unbedingt für Endnutzer gedacht. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
SERIAL	Eine Hardware-Seriennummer, die MÜSSEN verfügbar sein. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^([a-zA-Z0-9]{6,20})$“ entsprechen.
TAGS	Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt wird und die das Build weiter unterscheidet. Dieses Feld MUSS einen der Werte haben, die den drei gängigen Signaturkonfigurationen der Android-Plattform entsprechen: „release-keys“, „dev-keys“ und „test-keys“.
UHRZEIT	Ein Wert, der den Zeitstempel des Builds angibt.
SCHREIBMASCHINE	Ein vom Geräteimplementierer ausgewählter Wert, der die Laufzeitkonfiguration des Builds angibt. Dieses Feld MUSS einen der Werte haben, die den drei gängigen Android-Laufzeitkonfigurationen entsprechen: „user“, „userdebug“ oder „eng“.
NUTZER	Ein Name oder eine Nutzer-ID des Nutzers (oder automatisierten Nutzers), der den Build generiert hat. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.

3.2.3. Intent-Kompatibilität

Geräteimplementierungen MÜSSEN das lose gekoppelte Intent-System von Android einhalten, wie in den folgenden Abschnitten beschrieben. „Erfüllt“ bedeutet, dass der Geräteimplementierer eine Android-Aktivität oder einen Android-Dienst bereitstellen MUSS, der einen übereinstimmenden Intent-Filter angibt, der an jedes angegebene Intent-Muster gebunden ist und das richtige Verhalten implementiert.

3.2.3.1. Wichtige Anwendungsabsichten

Mit Android-Intents können Anwendungskomponenten Funktionen von anderen Android-Komponenten anfordern. Das Android-Upstream-Projekt enthält eine Liste von Anwendungen, die als Android-Kernanwendungen gelten. Dort werden mehrere Intent-Muster für die Ausführung gängiger Aktionen implementiert. Die wichtigsten Android-Anwendungen sind:

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

Geräteimplementierungen MÜSSEN die Android-Kernanwendungen enthalten, MÜSSEN aber auch eine Komponente enthalten, die dieselben Intent-Muster implementiert, die von allen „öffentlichen“ Aktivitäts- oder Dienstkomponenten dieser Android-Kernanwendungen definiert werden. Aktivitäts- oder Dienstkomponenten gelten als „öffentlich“, wenn das Attribut „android:exported“ fehlt oder den Wert „true“ hat.

3.2.3.2. Intent-Überschreibungen

Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen zulassen, dass jedes Intent-Muster, auf das in Abschnitt 3.2.3.1 verwiesen wird, von Drittanbieter-Apps überschrieben werden kann. Die Upstream-Open-Source-Implementierung von Android erlaubt dies standardmäßig. Geräteimplementierer dürfen der Verwendung dieser Intent-Muster durch Systemanwendungen KEINE speziellen Berechtigungen zuweisen oder verhindern, dass Drittanbieteranwendungen eine Bindung an diese Muster herstellen und die Kontrolle übernehmen. Dieses Verbot umfasst insbesondere, aber nicht ausschließlich, die Deaktivierung der Benutzeroberfläche „Chooser“, über die Nutzer zwischen mehreren Apps auswählen können, die alle dasselbe Intent-Muster verarbeiten.

Geräteimplementierungen KÖNNEN jedoch Standardaktivitäten für bestimmte URI-Muster (z. B. http://play.google.com) bereitstellen, wenn die Standardaktivität einen spezifischeren Filter für die Daten-URI bietet. Ein Intent-Filter, der den Daten-URI „http://www.android.com“ angibt, ist beispielsweise spezifischer als der Browserfilter für „http://“. Geräteimplementierungen MÜSSEN eine Benutzeroberfläche bereitstellen, über die Nutzer die Standardaktivität für Intents ändern können.

3.2.3.3. Intent-Namespaces

Geräteimplementierungen dürfen KEINE Android-Komponenten enthalten, die neue Intent- oder Broadcast-Intent-Muster mit einer ACTION, CATEGORY oder einem anderen Schlüsselstring im Namensbereich „android.*“ oder „com.android.*“ berücksichtigen. Geräteimplementierer dürfen KEINE Android-Komponenten einbinden, die neue Intent- oder Broadcast-Intent-Muster mit einem ACTION-, CATEGORY- oder anderen Schlüsselstring in einem Paketbereich einer anderen Organisation berücksichtigen. Geräteimplementierer DÜRFEN KEINE der Intent-Muster ändern oder erweitern, die von den in Abschnitt 3.2.3.1 aufgeführten Haupt-Apps verwendet werden. Geräteimplementierungen KÖNNEN Intent-Muster mit Namespaces enthalten, die eindeutig und offensichtlich mit der eigenen Organisation verknüpft sind. Dieses Verbot entspricht dem für Java-Sprachklassen in Abschnitt 3.6.

3.2.3.4. Broadcast-Intents

Drittanbieteranwendungen nutzen die Plattform, um bestimmte Intents zu senden, um über Änderungen in der Hardware- oder Softwareumgebung informiert zu werden. Android-kompatible Geräte MÜSSEN die öffentlichen Broadcast-Intents als Reaktion auf entsprechende Systemereignisse senden. Broadcast-Intents werden in der SDK-Dokumentation beschrieben.

3.2.3.5. Standard-App-Einstellungen

Android bietet Einstellungen, mit denen Nutzer ihre Standard-Apps ganz einfach auswählen können, z. B. für den Startbildschirm oder SMS. Sofern sinnvoll, MÜSSEN Geräteimplementierungen ein ähnliches Einstellungsmenü bereitstellen und mit dem Intent-Filtermuster und den API-Methoden kompatibel sein, die in der SDK-Dokumentation unten beschrieben sind.

Geräteimplementierungen:

• Es MUSS das Intent „android.settings.HOME_SETTINGS“ berücksichtigen, um ein Standardmenü für die App-Einstellungen für den Startbildschirm anzuzeigen, wenn die Geräteimplementierung „android.software.home_screen“ meldet. [Ressourcen, 10]
• Es MUSS ein Einstellungsmenü geben, das die Intent „android.provider.Telephony.ACTION_CHANGE_DEFAULT“ aufruft, um ein Dialogfeld zum Ändern der Standard-SMS-Anwendung anzuzeigen, wenn die Geräteimplementierung „android.hardware.telephony“ meldet. [Ressourcen, 9]
• MUSS den Intent „android.settings.NFC_PAYMENT_SETTINGS“ berücksichtigen, um ein standardmäßiges App-Einstellungsmenü für mobiles Bezahlen anzuzeigen, wenn die Geräteimplementierung „android.hardware.nfc.hce“ meldet [Ressourcen, 10]

3.3 Kompatibilität mit nativen APIs

3.3.1. Application Binary Interfaces

Verwalteter 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 Application Binary Interfaces (ABIs). Geräteimplementierungen MÜSSEN mit mindestens einer der definierten ABIs kompatibel sein und MÜSSEN die Kompatibilität mit dem Android NDK implementieren, wie unten beschrieben.

Wenn eine Geräteimplementierung die Unterstützung einer Android-ABI umfasst, gilt Folgendes:

• MÜSSEN Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code mithilfe der Standard-Java Native Interface (JNI)-Semantik aufzurufen
• MÜSSEN mit jeder erforderlichen Bibliothek in der folgenden Liste quellen- (d.h. Header-) und binärkompatibel (für das ABI) sein
• MUSS das entsprechende 32-Bit-ABI unterstützen, wenn ein 64-Bit-ABI unterstützt wird
• Die vom Gerät unterstützte native Application Binary Interface (ABI) MUSS korrekt über die Parameter „android.os.Build.SUPPORTED_ABIS“, „android.os.Build.SUPPORTED_32_BIT_ABIS“ und „android.os.Build.SUPPORTED_64_BIT_ABIS“ angegeben werden. Jede dieser kommagetrennten Listen von ABIs muss von der am häufigsten bis zur am wenigsten bevorzugten ABI sortiert sein.
• Es dürfen nur die ABIs über die oben genannten Parameter gemeldet werden, die in der neuesten Version des Android NDK im Verzeichnis „docs/“ im „NDK Programmer’s Guide | ABI Management“ dokumentiert sind.
• MÜSSEN mit dem Quellcode und den Headerdateien erstellt werden, die im Upstream-Android-Open-Source-Projekt verfügbar sind

Die folgenden APIs für nativen Code MÜSSEN für Apps verfügbar sein, die nativen Code enthalten:

• libc (C-Bibliothek)
• libm (Mathematische Bibliothek)
• Minimale Unterstützung für C++
• JNI-Schnittstelle
• liblog (Android-Protokollierung)
• libz (Zlib-Komprimierung)
• libdl (dynamischer Linker)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libEGL.so (native OpenGL-Oberflächenverwaltung)
• libjnigraphics.so
• libOpenSLES.so (OpenSL ES 1.0.1-Audiounterstützung)
• libOpenMAXAL.so (Unterstützung von OpenMAX AL 1.0.1)
• libandroid.so (Unterstützung für native Android-Aktivitäten)
• libmediandk.so (Unterstützung nativer Medien-APIs)
• Unterstützung für OpenGL, wie unten beschrieben

In zukünftigen Releases des Android NDK wird möglicherweise Unterstützung für zusätzliche ABIs eingeführt. Wenn eine Geräteimplementierung nicht mit einem vorhandenen vordefinierten ABI kompatibel ist, darf sie KEINE Unterstützung für ABIs melden.

Geräteimplementierungen MÜSSEN libGLESv3.so enthalten und einen symbolischen Link zu libGLESv2.so haben. Außerdem MÜSSEN alle Funktionssymbole von OpenGL ES 3.1 und dem Android Extension Pack [Resources, 11] exportiert werden, wie im NDK-Release android-21 definiert. Alle Symbole müssen vorhanden sein, aber nur die entsprechenden Funktionen für OpenGL ES-Versionen und ‑Erweiterungen, die vom Gerät tatsächlich unterstützt werden, müssen vollständig implementiert sein.

Die Kompatibilität mit nativem Code ist eine Herausforderung. Aus diesem Grund wird Geräteimplementierern dringend empfohlen, die Implementierungen der oben aufgeführten Bibliotheken aus dem Upstream-Android Open Source Project zu verwenden.

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

Die ARMv8-Architektur hat mehrere CPU-Vorgänge eingestellt, darunter einige, die in vorhandenem nativem Code verwendet werden. Auf 64-Bit-ARM-Geräten MÜSSEN die folgenden veralteten Vorgänge für nativen 32-Bit-ARM-Code verfügbar bleiben, entweder über native CPU-Unterstützung oder über Softwareemulation:

• Anleitungen für das Löschen von Dienstdaten und das Löschen von Dienstdaten mit Bestätigung
• SETEND-Anweisung
• Barrierevorgänge CP15ISB, CP15DSB und CP15DMB

In älteren Versionen des Android NDK wurde /proc/cpuinfo verwendet, um CPU-Funktionen aus 32-Bit-ARM-Nativecode zu ermitteln. Für die Kompatibilität mit Anwendungen, die mit diesem NDK erstellt wurden, MÜSSEN Geräte die folgenden Zeilen in /proc/cpuinfo enthalten, wenn sie von 32-Bit-ARM-Anwendungen gelesen werden:

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

Diese Anforderungen gelten nur, wenn /proc/cpuinfo von 32-Bit-ARM-Anwendungen gelesen wird. Geräte DÜRFEN /proc/cpuinfo nicht ändern, wenn es von 64-Bit-ARM- oder Nicht-ARM-Anwendungen gelesen wird.

3.4. Webkompatibilität

3.4.1. WebView-Kompatibilität

Die Plattformfunktion „android.software.webview“ MUSS auf allen Geräten gemeldet werden, die eine vollständige Implementierung der „android.webkit.WebView API“ bieten. Sie darf NICHT auf Geräten ohne vollständige Implementierung der API gemeldet werden. Bei der Open-Source-Implementierung von Android wird Code aus dem Chromium-Projekt verwendet, um android.webkit.WebView zu implementieren [Ressourcen, 12]. Da es nicht möglich ist, eine umfassende Testsuite für ein Web-Rendering-System zu entwickeln, MÜSSEN Geräteimplementierer den spezifischen Upstream-Build von Chromium in der WebView-Implementierung verwenden. Im Detail:

• Die Implementierungen von android.webkit.WebView auf Geräten MÜSSEN auf dem Chromium-Build des Upstream-Android-Open-Source-Projekts für Android 5.1 basieren. Dieser Build enthält eine Reihe von Funktions- und Sicherheitskorrekturen für WebView [Ressourcen, 13].
• Der von der WebView gemeldete User-Agent-String MUSS dieses Format haben:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW)) 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 $(WEBVIEW) kann weggelassen werden, muss aber „; wv“ enthalten, um anzugeben, dass es sich um eine Webansicht handelt.
  • Der Wert des Strings „$(MODEL)“ MUSS mit dem Wert für „android.os.Build.MODEL“ übereinstimmen.
  • Der Wert des Strings $(BUILD) MUSS mit dem Wert für android.os.Build.ID übereinstimmen.
  • Der Wert des Strings $(CHROMIUM_VER) MUSS der Version von Chromium im Upstream-Android-Open-Source-Projekt entsprechen.
  • Bei Geräteimplementierungen kann „Mobile“ im User-Agent-String weggelassen werden.

Die WebView-Komponente SOLLTE so viele HTML5-Funktionen wie möglich unterstützen und, sofern sie die Funktion unterstützt, der HTML5-Spezifikation entsprechen [Ressourcen, 14].

3.4.2. Browserkompatibilität

Der eigenständige Browser kann auf einer anderen Browsertechnologie als WebKit basieren. Auch wenn eine alternative Browseranwendung verwendet wird, muss die für Drittanbieter-Anwendungen bereitgestellte Komponente „android.webkit.WebView“ auf WebKit basieren, wie in Abschnitt 3.4.1 beschrieben.

Implementierungen KÖNNEN einen benutzerdefinierten User-Agent-String in der eigenständigen Browseranwendung enthalten.

Die eigenständige Browseranwendung (unabhängig davon, ob sie auf der Upstream-WebKit-Browseranwendung oder einem Drittanbieter-Ersatz basiert) SOLLTE so viel HTML5 wie möglich unterstützen [Ressourcen, 14]. Geräteimplementierungen müssen mindestens die folgenden APIs unterstützen, die mit HTML5 verknüpft sind:

• Anwendungscache/Offlinebetrieb [Ressourcen, 15]
• das <video>-Tag [Ressourcen, 16]
• geolocation [Ressourcen, 17]

Außerdem MÜSSEN Geräteimplementierungen die HTML5/W3C Webstorage API [Ressourcen, 18] und SOLLTEN die HTML5/W3C IndexedDB API [Ressourcen, 19] unterstützen. Da die Standardsteuergruppen für die Webentwicklung IndexedDB gegenüber Webspeicher bevorzugen, wird IndexedDB voraussichtlich in einer zukünftigen Version von Android zu einer erforderlichen Komponente.

3.5. API-Verhaltenskompatibilität

Das Verhalten der einzelnen API-Typen (verwaltet, weich, nativ und Web) muss der bevorzugten Implementierung des Upstream-Android-Open-Source-Projekts entsprechen [Ressourcen, 2]. Beispiele für Bereiche, in denen die Kompatibilität geprüft wird:

• Geräte dürfen das Verhalten oder die Semantik einer Standardabsicht NICHT ändern.
• Geräte dürfen den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, Content-Provider usw.) NICHT ändern.
• Die Semantik einer Standardberechtigung darf von Geräten NICHT geändert werden.

Die oben genannte Liste ist nicht vollständig. Die Compatibility Test Suite (CTS) prüft einen Großteil der Plattform auf Verhaltenskompatibilität, aber nicht alle Bereiche. Der Implementierer ist dafür verantwortlich, die Verhaltenskompatibilität mit dem Android Open Source Project sicherzustellen. Aus diesem Grund sollten Geräteimplementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt wichtige Teile des Systems neu zu implementieren.

3.6. API-Namespaces

Android folgt den Paket- und Klassen-Namespace-Konventionen, die von der Java-Programmiersprache definiert wurden. Um die Kompatibilität mit Anwendungen von Drittanbietern zu gewährleisten, dürfen Geräteimplementierer KEINE der folgenden verbotenen Änderungen an diesen Paketnamensräumen vornehmen:

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

Zu den unzulässigen Änderungen gehören:

• Geräteimplementierungen dürfen die öffentlich zugänglichen APIs auf der Android-Plattform NICHT ändern, indem sie Methoden- oder Klassensignaturen ändern oder Klassen oder Klassenfelder entfernen.
• Geräteimplementierer DÜRFEN die zugrunde liegende Implementierung der APIs ändern. Solche Änderungen DÜRFEN jedoch NICHT das angegebene Verhalten und die Java-Signatur öffentlich zugänglicher APIs beeinträchtigen.
• Geräteimplementierer DÜRFEN den oben genannten APIs KEINE öffentlich zugänglichen Elemente hinzufügen, z. B. Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen.

Ein „öffentlich zugängliches Element“ ist jedes Konstrukt, das nicht mit der Markierung „@hide“ versehen ist, wie sie im Upstream-Android-Quellcode verwendet wird. Mit anderen Worten: Geräteimplementierer DÜRFEN KEINE neuen APIs freigeben oder vorhandene APIs in den oben genannten Namespaces ändern. Geräteimplementierer DÜRFEN nur interne Änderungen vornehmen. Diese Änderungen DÜRFEN NICHT beworben oder Entwicklern anderweitig zugänglich gemacht werden.

Geräteimplementierer KÖNNEN benutzerdefinierte APIs hinzufügen. Diese APIs DÜRFEN jedoch nicht in einem Namespace enthalten sein, der einer anderen Organisation gehört oder sich auf eine andere Organisation bezieht. Geräteimplementierer dürfen dem Namespace „com.google.*“ oder einem ähnlichen Namespace KEINE APIs hinzufügen. Das darf nur Google tun. Ebenso darf Google KEINE APIs zu Namespaces anderer Unternehmen hinzufügen. Wenn eine Geräteimplementierung benutzerdefinierte APIs außerhalb des Standard-Android-Namespace enthält, MÜSSEN diese APIs in einer freigegebenen Android-Bibliothek verpackt werden, damit nur Apps, die sie explizit verwenden (über den Mechanismus <uses-library>), von der erhöhten Speichernutzung dieser APIs betroffen sind.

Wenn ein Geräteimplementierer vorschlägt, einen der oben genannten Paketnamensräume zu verbessern (z. B. durch Hinzufügen nützlicher neuer Funktionen zu einer vorhandenen API oder durch Hinzufügen einer neuen API), sollte er source.android.com aufrufen und gemäß den Informationen auf dieser Website mit dem Einreichen von Änderungen und Code beginnen.

Die oben genannten Einschränkungen entsprechen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java. Dieser Abschnitt soll diese Konventionen lediglich verstärken und durch Aufnahme in diese Kompatibilitätsdefinition verbindlich machen.

3.7. Laufzeitkompatibilität

Geräteimplementierungen MÜSSEN das vollständige Dalvik-Ausführbare-Format (DEX) sowie die Dalvik-Bytecode-Spezifikation und -Semantik unterstützen [Ressourcen, 20]. Geräteimplementierer sollten ART, die Referenz-Upstream-Implementierung des Dalvik Executable Format, und das Paketverwaltungssystem der Referenzimplementierung verwenden.

Geräteimplementierungen MÜSSEN Dalvik-Laufzeiten so konfigurieren, dass Speicher gemäß der Upstream-Android-Plattform und wie in der folgenden Tabelle angegeben zugewiesen wird. (Definitionen für Bildschirmgröße und Bildschirmdichte finden Sie unter Abschnitt 7.1.1.)

Die unten angegebenen Speicherwerte gelten als Mindestwerte. Geräteimplementierungen können mehr Arbeitsspeicher pro Anwendung zuweisen.

Bildschirmlayout	Bildschirmdichte	Mindestanforderung an den Arbeitsspeicher der Anwendung
klein/normal	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48 MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80 MB
	400 dpi (400dpi)	96 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi (560dpi)	192 MB
	640 dpi (xxxhdpi)	256 MB
Groß	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)	48 MB
	213 dpi (tvdpi)	80 MB
	240 dpi (hdpi)
	280 dpi (280dpi)	96 MB
	320 dpi (xhdpi)	128 MB
	400 dpi (400dpi)	192 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi (560dpi)	384 MB
	640 dpi (xxxhdpi)	512 MB
xlarge	120 dpi (ldpi)	48 MB
	160 dpi (mdpi)	80 MB
	213 dpi (tvdpi)	96 MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144 MB
	320 dpi (xhdpi)	192 MB
	400 dpi (400dpi)	288 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi (560dpi)	576 MB
	640 dpi (xxxhdpi)	768 MB

3.8. Kompatibilität der Benutzeroberfläche

3.8.1. Launcher (Startbildschirm)

Android enthält eine Launcher-Anwendung (Startbildschirm) und unterstützt Drittanbieter-Anwendungen, die den Geräte-Launcher (Startbildschirm) ersetzen. Bei Geräteimplementierungen, bei denen Drittanbieter-Apps den Startbildschirm des Geräts ersetzen können, MUSS die Plattformfunktion „android.software.home_screen“ deklariert werden.

3.8.2. Widgets

Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, mit denen Anwendungen Endnutzern ein „App-Widget“ zur Verfügung stellen können [Ressourcen, 21]. Diese Funktion wird für Implementierungen auf Mobilgeräten dringend empfohlen. Geräteimplementierungen, die das Einbetten von Widgets auf dem Startbildschirm unterstützen, MÜSSEN die folgenden Anforderungen erfüllen und die Unterstützung der Plattformfunktion „android.software.app_widgets“ angeben.

• Geräte-Launcher MÜSSEN eine integrierte Unterstützung für App-Widgets bieten und Nutzeroberflächenelemente enthalten, mit denen App-Widgets direkt im Launcher hinzugefügt, konfiguriert, angezeigt und entfernt werden können.
• Geräteimplementierungen MÜSSEN Widgets mit einer Standardrastergröße von 4 × 4 rendern können. Weitere Informationen finden Sie in den Designrichtlinien für App-Widgets in der Android SDK-Dokumentation [Ressourcen, 21].
• Geräteimplementierungen, die die Sperrbildschirmfunktion unterstützen, KÖNNEN Anwendungs-Widgets auf dem Sperrbildschirm unterstützen.

3.8.3. Benachrichtigungen

Android bietet APIs, mit denen Entwickler Nutzer über wichtige Ereignisse informieren können [Ressourcen, 22], indem sie Hardware- und Softwarefunktionen des Geräts nutzen.

Mit einigen APIs können Apps Benachrichtigungen senden oder mithilfe von Hardware – insbesondere Ton, Vibration und Licht – Aufmerksamkeit erregen. Geräteimplementierungen MÜSSEN Benachrichtigungen unterstützen, die Hardwarefunktionen verwenden, wie in der SDK-Dokumentation beschrieben und nach Möglichkeit mit der Hardware der Geräteimplementierung. Wenn eine Geräteimplementierung beispielsweise einen Vibrator enthält, MÜSSEN die Vibrations-APIs korrekt implementiert sein. Wenn bei einer Geräteimplementierung die entsprechende Hardware fehlt, MÜSSEN die entsprechenden APIs als No-Ops implementiert werden. Dieses Verhalten wird in Abschnitt 7 näher erläutert.

Außerdem MÜSSEN in der Implementierung alle in den APIs [Ressourcen, 23] oder im Stilhandbuch für Status-/Systemleistensymbole [Ressourcen, 24] bereitgestellten Ressourcen (Symbole, Animationsdateien usw.) korrekt gerendert werden. Bei einem Android TV-Gerät muss es außerdem möglich sein, Benachrichtigungen nicht anzuzeigen. Geräteimplementierer KÖNNEN eine andere Nutzererfahrung für Benachrichtigungen bieten als die der Referenzimplementierung von Android Open Source. Solche alternativen Benachrichtigungssysteme MÜSSEN jedoch vorhandene Benachrichtigungsressourcen wie oben beschrieben unterstützen.

Android unterstützt verschiedene Benachrichtigungen, z. B.:

• Rich Notifications Interaktive Ansichten für Benachrichtigungen über laufende Aktivitäten
• Heads-Up-Benachrichtigungen Interaktive Ansichten, auf die Nutzer reagieren oder die sie schließen können, ohne die aktuelle App zu verlassen.
• Benachrichtigungen auf dem Sperrbildschirm Benachrichtigungen, die über einem Sperrbildschirm angezeigt werden, mit detaillierter Sichtbarkeitssteuerung.

Bei der Implementierung von Android-Geräten müssen solche Benachrichtigungen korrekt ausgeführt werden und die Titel/Namen, Symbole und Texte enthalten, die in den Android APIs [Resources, 25] dokumentiert sind.

Android enthält Benachrichtigungs-Listener-Dienst-APIs, mit denen Apps (nachdem sie vom Nutzer ausdrücklich aktiviert wurden) eine Kopie aller Benachrichtigungen erhalten, sobald sie gepostet oder aktualisiert werden. Geräteimplementierungen MÜSSEN Benachrichtigungen korrekt und zeitnah in ihrer Gesamtheit an alle diese installierten und vom Nutzer aktivierten Listener-Dienste senden, einschließlich aller Metadaten, die dem Benachrichtigungsobjekt zugeordnet sind.

3.8.4. Suchen

Android enthält APIs [Ressourcen, 26], mit denen Entwickler die Suche in ihre Anwendungen einbinden und die Daten ihrer Anwendung in der globalen Systemsuche verfügbar machen können. Im Allgemeinen besteht diese Funktion aus einer einzigen systemweiten Benutzeroberfläche, über die Nutzer Suchanfragen eingeben können, während Vorschläge angezeigt werden und Ergebnisse angezeigt werden. Mit den Android APIs können Entwickler diese Benutzeroberfläche wiederverwenden, um in ihren eigenen Apps eine Suche bereitzustellen, und Ergebnisse für die gemeinsame Benutzeroberfläche der globalen Suche bereitstellen.

Android-Geräteimplementierungen MÜSSEN eine globale Suche enthalten, eine einzelne, gemeinsame, systemweite Suchoberfläche, die Echtzeitvorschläge als Reaktion auf Nutzereingaben liefern kann. Geräteimplementierungen MÜSSEN die APIs implementieren, die es Entwicklern ermöglichen, diese Benutzeroberfläche für die Suche in ihren eigenen Anwendungen wiederzuverwenden. Geräteimplementierungen, die die Benutzeroberfläche der globalen Suche implementieren, MÜSSEN die APIs implementieren, die es Drittanbieter-Apps ermöglichen, dem Suchfeld Vorschläge hinzuzufügen, wenn es im Modus für die globale Suche ausgeführt wird. Wenn keine Drittanbieteranwendungen installiert sind, die diese Funktion nutzen, sollte standardmäßig das Anzeigen von Ergebnissen und Vorschlägen der Websuchmaschine erfolgen.

3.8.5. Toasts

Mit der Toast API können Anwendungen Endnutzern kurze nicht modale Strings anzeigen, die nach kurzer Zeit verschwinden [Ressourcen, 27]. Bei Geräteimplementierungen MÜSSEN Toasts von Anwendungen für Endnutzer gut sichtbar angezeigt werden.

3.8.6. Designs

Android bietet „Designs“ als Mechanismus für Anwendungen, um Stile auf eine gesamte Aktivität oder Anwendung anzuwenden.

Android enthält eine „Holo“-Designfamilie mit einer Reihe von definierten Stilen, die App-Entwickler verwenden können, wenn sie das Holo-Design gemäß der Definition im Android SDK [Ressourcen, 28] umsetzen möchten. Geräteimplementierungen dürfen KEINE der Holo-Designattribute ändern, die für Anwendungen freigegeben sind [Ressourcen, 29].

Android umfasst eine „Material“-Designfamilie mit einer Reihe von definierten Stilen, die App-Entwickler verwenden können, wenn sie das Designthema auf die unterschiedlichsten Android-Gerätetypen abstimmen möchten. Geräteimplementierungen MÜSSEN die Material-Design-Designfamilie unterstützen und KEINE der Material-Design-Designattribute oder deren Assets ändern, die für Anwendungen freigegeben sind [Ressourcen, 30].

Android enthält auch eine Designfamilie „Gerätestandard“, die eine Reihe von definierten Stilen für App-Entwickler bietet, die das Erscheinungsbild des vom Geräteimplementierer definierten Gerätedesigns anpassen möchten. Geräteimplementierungen KÖNNEN die Designattribute „Gerätestandard“, die für Anwendungen freigegeben sind, ändern [Ressourcen, 29].

Android unterstützt ein neues Variante-Design mit durchsichtigen Systemleisten, mit dem App-Entwickler den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten füllen können. Damit Entwickler in dieser Konfiguration einheitlich arbeiten können, ist es wichtig, dass der Symbolstil der Statusleiste bei verschiedenen Geräteimplementierungen beibehalten wird. Daher müssen bei Android-Geräten Symbole für den Systemstatus (z. B. Signalstärke und Akkustand) und vom System ausgegebene Benachrichtigungen weiß sein, es sei denn, das Symbol weist auf einen problematischen Status hin [Ressourcen, 29].

3.8.7. Live-Hintergründe

Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, mit denen Anwendungen Endnutzern einen oder mehrere „Live-Hintergründe“ zur Verfügung stellen können [Ressourcen, 31]. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabemöglichkeiten, die als Hintergrund hinter anderen Apps angezeigt werden.

Hardware gilt als zuverlässig für die Ausführung von Live-Hintergründen, wenn sie alle Live-Hintergründe ohne Funktionseinschränkungen mit einer angemessenen Framerate und ohne negative Auswirkungen auf andere Anwendungen ausführen kann. Wenn Einschränkungen der Hardware dazu führen, dass Hintergründe und/oder Anwendungen abstürzen, nicht richtig funktionieren, übermäßig viel CPU- oder Akkuleistung verbrauchen oder mit unzumutbar niedrigen Frameraten laufen, ist die Hardware nicht in der Lage, Live-Hintergründe auszuführen. Einige Live-Hintergründe verwenden beispielsweise einen OpenGL 2.0- oder 3.x-Kontext, um ihre Inhalte zu rendern. Live-Hintergründe funktionieren auf Hardware, die keine mehreren OpenGL-Kontexte unterstützt, nicht zuverlässig, da die Verwendung eines OpenGL-Kontexts für den Live-Hintergrund mit anderen Anwendungen in Konflikt stehen kann, die ebenfalls einen OpenGL-Kontext verwenden.

Geräteimplementierungen, die wie oben beschrieben zuverlässig Live-Hintergründe ausführen können, MÜSSEN Live-Hintergründe implementieren und bei der Implementierung das Plattform-Funktionsflag „android.software.live_wallpaper“ melden.

3.8.8. Aktivitätswechsel

Der Upstream-Android-Quellcode enthält den Übersichtsbildschirm [Resources, 32], eine Benutzeroberfläche auf Systemebene zum Wechseln von Aufgaben und zum Anzeigen kürzlich aufgerufener Aktivitäten und Aufgaben mit einem Thumbnail-Bild des grafischen Zustands der Anwendung zum Zeitpunkt, als der Nutzer die Anwendung zuletzt verlassen hat. Geräteimplementierungen, die den Navigationsschlüssel für die Funktion „Letzte“ enthalten, wie in Abschnitt 7.2.3 beschrieben, DÜRFEN die Benutzeroberfläche ändern, MÜSSEN aber die folgenden Anforderungen erfüllen:

• Zugehörige aktuelle Inhalte MÜSSEN als Gruppe angezeigt werden, die sich gemeinsam bewegt.
• MÜSSEN mindestens 20 angezeigte Aktivitäten unterstützen.
• Es sollte mindestens der Titel von vier Aktivitäten gleichzeitig angezeigt werden.
• MÜSSEN die Markierungsfarbe, das Symbol und den Bildschirmtitel in den letzten Elementen anzeigen.
• MÜSSEN das Verhalten der Bildschirmanpinning implementieren [Ressourcen, 33] und dem Nutzer ein Einstellungsmenü zur Verfügung stellen, mit dem er die Funktion aktivieren oder deaktivieren kann.
• Es sollte eine Schließfunktion („x“) geben, die aber verzögert werden kann, bis der Nutzer mit den Bildschirmen interagiert.

Bei Geräteimplementierungen wird DRINGEND empfohlen, die Android-Benutzeroberfläche (oder eine ähnliche, auf Miniaturansichten basierende Benutzeroberfläche) für den Übersichtsbildschirm zu verwenden.

3.8.9. Eingabeverwaltung

Android unterstützt die Eingabeverwaltung und Editoren für Eingabemethoden von Drittanbietern [Ressourcen, 34]. Bei Geräteimplementierungen, die es Nutzern ermöglichen, Eingabemethoden von Drittanbietern auf dem Gerät zu verwenden, MUSS die Plattformfunktion „android.software.input_methods“ deklariert und IME APIs gemäß der Android SDK-Dokumentation unterstützt werden.

Geräteimplementierungen, die die Funktion „android.software.input_methods“ deklarieren, MÜSSEN einen nutzerzugänglichen Mechanismus zum Hinzufügen und Konfigurieren von Eingabemethoden von Drittanbietern bereitstellen. Geräteimplementierungen MÜSSEN die Einstellungen-Benutzeroberfläche als Reaktion auf den Intent „android.settings.INPUT_METHOD_SETTINGS“ anzeigen.

3.8.10. Mediensteuerung auf dem Sperrbildschirm

Die Remote Control Client API wird ab Android 5.0 zugunsten der Media Notification Template eingestellt. Mit dieser Vorlage können Medienanwendungen in Wiedergabesteuerungen eingebunden werden, die auf dem Sperrbildschirm angezeigt werden [Ressourcen, 35]. Bei Geräteimplementierungen, die einen Sperrbildschirm unterstützen, MÜSSEN die Sperrbildschirmbenachrichtigungen einschließlich der Vorlage für Medienbenachrichtigungen angezeigt werden, sofern es sich nicht um eine Android Automotive- oder Smartwatch-Implementierung handelt.

3.8.11. Träume

Android unterstützt interaktive Bildschirmschoner namens Dreams [Ressourcen, 36]. Mit Dreams können Nutzer mit Anwendungen interagieren, wenn ein an eine Stromquelle angeschlossenes Gerät inaktiv ist oder an einem Dock angedockt ist. Auf Android-Smartwatches KÖNNEN Dreams implementiert werden. Andere Arten von Geräteimplementierungen MÜSSEN jedoch Dreams unterstützen und eine Einstellungsoption für Nutzer bereitstellen, mit der sie Dreams als Reaktion auf den Intent „android.settings.DREAM_SETTINGS“ konfigurieren können.

3.8.12. Standort

Wenn ein Gerät einen Hardwaresensor (z.B. GPS) hat, der die Standortkoordinaten bereitstellen kann, MÜSSEN die Standortmodi im Menü „Standort“ in den Einstellungen angezeigt werden [Ressourcen, 37].

3.8.13. Unicode und Schriftart

Android unterstützt farbige Emojis. Wenn Android-Geräte eine IME enthalten, SOLLTEN sie Nutzern eine Eingabemethode für die in Unicode 6.1 definierten Emoji-Zeichen zur Verfügung stellen [Ressourcen, 38]. Alle Geräte MÜSSEN diese Emoji-Zeichen als farbiges Glyph rendern können.

Android unterstützt die Schriftart „Roboto 2“ mit verschiedenen Schriftschnitten: „sans-serif-thin“, „sans-serif-light“, „sans-serif-medium“, „sans-serif-black“, „sans-serif-condensed“ und „sans-serif-condensed-light“. Diese Schriftschnitte MÜSSEN für alle auf dem Gerät verfügbaren Sprachen und für die vollständige Unicode 7.0-Abdeckung von Lateinisch, Griechisch und Kyrillisch enthalten sein, einschließlich der Bereiche „Latin Extended A“, „Latin Extended B“, „Latin Extended C“ und „Latin Extended D“ sowie aller Zeichen im Block „Währungssymbole“ von Unicode 7.0.

3.9. Geräteverwaltung

Android bietet Funktionen, mit denen sicherheitsbewusste Anwendungen über die Android Device Administration API [Ressourcen, 39] Geräteverwaltungsfunktionen auf Systemebene ausführen können, z. B. die Durchsetzung von Passwortrichtlinien oder die Remote-Löschfunktion. Geräteimplementierungen MÜSSEN eine Implementierung der Klasse „DevicePolicyManager“ bereitstellen [Ressourcen, 40]. Geräteimplementierungen, die PIN- (numerisch) oder PASSWORT- (alphanumerisch) basierte Sperrbildschirme unterstützen, MÜSSEN die gesamte Palette der in der Android SDK-Dokumentation [Ressourcen, 39] definierten Richtlinien zur Geräteverwaltung unterstützen und die Plattformfunktion „android.software.device_admin“ melden.

Geräteimplementierungen KÖNNEN eine vorinstallierte Anwendung haben, die Funktionen zur Geräteverwaltung ausführt. Diese Anwendung DARF jedoch NICHT standardmäßig als App des Geräteeigentümers festgelegt sein [Ressourcen, 41].

3.10. Bedienungshilfen

Android bietet eine Bedienungshilfenebene, die es Nutzern mit Beeinträchtigungen erleichtert, ihre Geräte zu bedienen. Darüber hinaus bietet Android Plattform-APIs, mit denen Implementierungen von Bedienungshilfen Rückrufe für Nutzer- und Systemereignisse erhalten und alternative Feedbackmechanismen wie Text-zu-Sprache-Funktion, haptisches Feedback und Navigation per Trackball/D-Pad generieren können [Ressourcen, 42].

Für die Geräteimplementierung gelten die folgenden Anforderungen:

• Android Automotive-Implementierungen MÜSSEN eine Implementierung des Android-Bedienungshilfen-Frameworks bereitstellen, die mit der Standardimplementierung von Android übereinstimmt.
• Geräteimplementierungen (außer Android Automotive) MÜSSEN eine Implementierung des Android-Bedienungshilfen-Frameworks bereitstellen, die mit der Standardimplementierung von Android übereinstimmt.
• Geräteimplementierungen (außer Android Automotive) MÜSSEN Bedienungshilfen von Drittanbietern über die APIs von android.accessibilityservice unterstützen. [Ressourcen, 43]
• Geräteimplementierungen (außer Android Automotive) MÜSSEN AccessibilityEvents generieren und diese Ereignisse gemäß der Standardimplementierung von Android an alle registrierten AccessibilityService-Implementierungen senden.
• Geräteimplementierungen (ausgenommen Android Automotive- und Android Watch-Geräte ohne Audioausgang) MÜSSEN einen für Nutzer zugänglichen Mechanismus zum Aktivieren und Deaktivieren von Bedienungshilfen bereitstellen und MÜSSEN diese Benutzeroberfläche als Reaktion auf die Intent-Aktion „android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS“ anzeigen.

Außerdem MÜSSEN Geräteimplementierungen einen Bedienungshilfendienst auf dem Gerät implementieren und einen Mechanismus bereitstellen, mit dem Nutzer den Bedienungshilfendienst während der Geräteeinrichtung aktivieren können. Eine Open-Source-Implementierung eines Bedienungshilfendiensts ist im Rahmen des Eyes Free-Projekts verfügbar [Ressourcen, 44].

3.11. Sprachausgabe

Android bietet APIs, mit denen Anwendungen TTS-Dienste (Text-to-Speech) nutzen und Dienstanbieter TTS-Dienste implementieren können [Ressourcen, 45]. Geräteimplementierungen, die die Funktion „android.hardware.audio.output“ melden, MÜSSEN diese Anforderungen im Zusammenhang mit dem Android-TTS-Framework erfüllen.

Android Automotive-Implementierungen:

• MÜSSEN die APIs des Android TTS-Frameworks unterstützen.
• Unter Umständen wird die Installation von TTS-Engines von Drittanbietern unterstützt. Sofern unterstützt, MÜSSEN Partner eine für Nutzer zugängliche Benutzeroberfläche bereitstellen, über die Nutzer eine TTS-Engine für die Verwendung auf Systemebene auswählen können.

Alle anderen Geräteimplementierungen:

• MÜSSEN die APIs des Android TTS-Frameworks unterstützen und SOLLTEN eine TTS-Engine enthalten, die die auf dem Gerät verfügbaren Sprachen unterstützt. Die Upstream-Open-Source-Software von Android enthält eine vollständige TTS-Engine-Implementierung.
• MUSS die Installation von TTS-Engines von Drittanbietern unterstützen
• MÜSSEN eine für Nutzer zugängliche Benutzeroberfläche bereitstellen, über die Nutzer eine TTS-Engine für die Verwendung auf Systemebene auswählen können

3.12. TV Input Framework

Das Android Television Input Framework (TIF) vereinfacht die Bereitstellung von Live-Inhalten auf Android TV-Geräten. TIF bietet eine Standard-API zum Erstellen von Eingabemodulen, mit denen Android TV-Geräte gesteuert werden. Android TV-Geräteimplementierungen MÜSSEN das Television Input Framework unterstützen [Ressourcen, 46].

Geräteimplementierungen, die TIF unterstützen, MÜSSEN die Plattformfunktion „android.software.live_tv“ deklarieren.

4. Kompatibilität von Anwendungspaketen

Bei Geräteimplementierungen MÜSSEN Android-APK-Dateien installiert und ausgeführt werden, die mit dem im offiziellen Android SDK enthaltenen Tool „aapt“ generiert wurden [Ressourcen, 47].

Geräteimplementierungen dürfen die .apk-Dateien [Ressourcen, 48], das Android-Manifest [Ressourcen, 49], den Dalvik-Bytecode [Ressourcen, 20] oder die RenderScript-Bytecode-Formate NICHT so erweitern, dass die Installation und Ausführung dieser Dateien auf anderen kompatiblen Geräten verhindert wird.

5. Multimedia-Kompatibilität

5.1. Medien-Codecs

Geräteimplementierungen MÜSSEN die in der Android SDK-Dokumentation [Ressourcen, 50] angegebenen Hauptmedienformate unterstützen, sofern dies nicht ausdrücklich in diesem Dokument erlaubt ist. Insbesondere müssen Geräteimplementierungen die in den folgenden Tabellen definierten und über MediaCodecList [Resources,112] gemeldeten Medienformate, Encoder, Decoder, Dateitypen und Containerformate unterstützen. Geräteimplementierungen MÜSSEN außerdem alle Profile decodieren können, die in seinem CamcorderProfile gemeldet werden [Ressourcen, 113]. Alle diese Codecs werden als Softwareimplementierungen in der bevorzugten Android-Implementierung des Android Open Source Project bereitgestellt.

Weder Google noch die Open Handset Alliance geben eine Zusicherung dafür, dass diese Codecs frei von Patenten Dritter sind. Nutzer, die diesen Quellcode in Hardware- oder Softwareprodukten verwenden möchten, werden darauf hingewiesen, dass für die Implementierung dieses Codes, einschließlich in Open-Source-Software oder Shareware, möglicherweise Patentlizenzen der entsprechenden Patentinhaber erforderlich sind.

5.1.1. Audio-Codecs

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

1 Erforderlich für Geräteimplementierungen, die android.hardware.microphone definieren, aber optional für Geräteimplementierungen von Android-Smartwatches.

2 Nur Downmix von 5.0/5.1-Inhalten erforderlich; die Aufzeichnung oder das Rendern von mehr als zwei Kanälen ist optional.

3 Erforderlich für Implementierungen auf Android-Handheld-Geräten.

4 Erforderlich für Geräteimplementierungen, die „android.hardware.microphone“ definieren, einschließlich Android-Smartwatch-Implementierungen.

5.1.2. Bildcodecs

Format/Codec	Encoder	Decoder	Details	Unterstützte Dateitypen/Containerformate
JPEG	REQUIRED	REQUIRED	Basispreis + progressiver Preis	JPEG (JPG)
GIF		REQUIRED		GIF (.gif)
PNG	REQUIRED	REQUIRED		PNG (.png)
BMP		REQUIRED		BMP (.bmp)
WebP	REQUIRED	REQUIRED		WebP (.webp)

5.1.3. Video-Codecs

Videocodecs sind für die Implementierung von Android Watch-Geräten optional.

Format/Codec	Encoder	Decoder	Details	Unterstützte Dateitypen/ -Containerformate
H.263	ERFORDERLICH1	ERFORDERLICH2		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	ERFORDERLICH2	ERFORDERLICH2	Weitere Informationen finden Sie in den Abschnitten 5.2 und 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, nur AAC-Audio, nicht suchbar, Android 3.0 und höher)
H.265 HEVC		ERFORDERLICH5	Weitere Informationen finden Sie unter Abschnitt 5.3.	MPEG-4 (.mp4)
MPEG-4 SP		ERFORDERLICH2		3GPP (.3gp)
VP83	ERFORDERLICH2 (Android 4.3 und höher)	ERFORDERLICH2 (Android 2.3.3 und höher)	Weitere Informationen finden Sie in den Abschnitten 5.2 und 5.3.	WebM (.webm) [Ressourcen, 110 Matroska (.mkv, Android 4.0 und höher)4
VP9		ERFORDERLICH2 (Android 4.4 und höher)	Weitere Informationen finden Sie unter Abschnitt 5.3.	WebM (.webm) [Ressourcen, 110] Matroska (.mkv, Android 4.0 und höher)4

1 Erforderlich für Geräteimplementierungen, die Kamerahardware enthalten und android.hardware.camera oder android.hardware.camera.front definieren.

2 Erforderlich für Geräteimplementierungen mit Ausnahme von Android-Smartwatches.

3 Für eine akzeptable Qualität von Webvideostreaming und Videokonferenzdiensten SOLLTE bei Geräteimplementierungen ein Hardware-VP8-Codec verwendet werden, der die Anforderungen in [Ressourcen, 51] erfüllt.

4 Geräteimplementierungen MÜSSEN das Schreiben von Matroska WebM-Dateien unterstützen.

5 Stark empfohlen für Android Automotive, optional für Android Watch und erforderlich für alle anderen Gerätetypen.

5.2. Videocodierung

Implementierungen von Android-Geräten mit H.264-Codec-Unterstützung MÜSSEN das Baseline-Profil der Stufe 3 und die folgenden Videocodierungsprofile für SD (Standarddefinition) unterstützen und SOLLTEN das Hauptprofil der Stufe 4 und die folgenden Videocodierungsprofile für HD (High Definition) unterstützen. Für Android TV-Geräte wird DRINGEND empfohlen, HD 1080p-Videos mit 30 fps zu codieren.

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

1 Wenn von der Hardware unterstützt, aber für Android-Fernseher DREIFACH EMPFOHLEN.

Android-Geräteimplementierungen mit VP8-Codec-Unterstützung MÜSSEN die SD-Videocodierungsprofile unterstützen und SOLLTEN die folgenden HD-Videocodierungsprofile (High Definition) unterstützen.

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

1 Wenn von der Hardware unterstützt.

5.3. Videodekodierung

Geräteimplementierungen MÜSSEN die dynamische Umschaltung der Videoauflösung innerhalb desselben Streams für alle VP8-, VP9-, H.264- und H.265-Codecs unterstützen, die Entwicklern über die standardmäßigen Android APIs zur Verfügung gestellt werden.

Android-Geräteimplementierungen mit H.264-Decodern MÜSSEN das Baseline-Profil der 3. Ebene und die folgenden SD-Video-Decodierungsprofile unterstützen und SOLLTEN die HD-Decodierungsprofile unterstützen. Android-TV-Geräte MÜSSEN High Profile Level 4.2 und das Dekodierungsprofil HD 1080p unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p1	HD 1080p1
Videoauflösung	320 × 240 px	720 x 480 px	1.280 × 720 Pixel	1920 × 1080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30 fps / 60 fps2	30 fps / 60 fps2
Video-Bitrate	800 kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

1 Erforderlich für Android TV-Geräte, aber für andere Gerätetypen nur, wenn sie von der Hardware unterstützt werden.

2 Erforderlich für die Implementierung von Android TV-Geräten.

Android-Geräteimplementierungen, die den VP8-Codec wie in Abschnitt 5.1.3 beschrieben unterstützen, MÜSSEN die folgenden SD-Dekodierungsprofile und SOLLTEN die HD-Dekodierungsprofile unterstützen. Android TV-Geräte MÜSSEN das Decodierungsprofil für HD 1080p unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p1	HD 1080p1
Videoauflösung	320 × 180 px	640 x 360 px	1.280 × 720 Pixel	1920 × 1080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	30 fps / 60 fps2	30 / 60 fps2
Video-Bitrate	800 kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

1 Erforderlich für Android TV-Geräte, aber nur für andere Gerätetypen, wenn sie von der Hardware unterstützt werden.

2 Erforderlich für die Implementierung von Android TV-Geräten.

Android-Geräteimplementierungen, die den VP9-Codec wie in Abschnitt 5.1.3 beschrieben unterstützen, MÜSSEN die folgenden SD-Video-Dekodierungsprofile und SOLLTEN die HD-Dekodierungsprofile unterstützen. Android TV-Geräte sollten das Dekodierungsprofil für HD 1080p und das UHD-Dekodierungsprofil unterstützen. Wenn das UHD-Video-Dekodierungsprofil unterstützt wird, MUSS es eine Farbtiefe von 8 Bit unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p 1	HD 1080p 2	UHD 2
Videoauflösung	320 × 180 px	640 x 360 px	1.280 × 720 Pixel	1920 × 1080 Pixel	3840 x 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	600 Kbit/s	1,6 Mbit/s	4 Mbit/s	10 Mbit/s	20 Mbit/s

1 Erforderlich für Android TV-Geräte, aber nur für andere Gerätetypen, wenn sie von der Hardware unterstützt werden.

2 EMPFOHLENE IMPLEMENTIERUNG für Android TV-Geräte, wenn von der Hardware unterstützt.

Android-Geräteimplementierungen, die den H.265-Codec wie in Abschnitt 5.1.3 beschrieben unterstützen, MÜSSEN das Main Profile Level 3 Main Tier und die folgenden SD-Video-Dekodierungsprofile unterstützen und SOLLTEN die HD-Dekodierungsprofile unterstützen. Android-Fernseher MÜSSEN das Main10-Level-5-Main-Tier-Profil und das UHD-Decodierungsprofil unterstützen. Android TV-Geräte sollten das Dekodierungsprofil für HD 1080p UNBEDINGT unterstützen. Wenn das Dekodierungsprofil für HD 1080p unterstützt wird, MUSS es das Hauptprofil der Ebene 4.1 der Hauptebene unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p 1	HD 1080p 2	UHD 2
Videoauflösung	352 × 288 px	640 x 360 px	1.280 × 720 Pixel	1920 × 1080 Pixel	3840 x 2160 px
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	600 Kbit/s	1,6 Mbit/s	4 Mbit/s	10 Mbit/s	20 Mbit/s

1 Erforderlich für die Implementierung von Android-TV-Geräten, aber nur für andere Gerätetypen, wenn sie von der Hardware unterstützt werden.

2 EMPFOHLENE OPTION für Android-TV-Geräte, sofern von der Hardware unterstützt.

5.4. Audioaufnahmen

Einige der in diesem Abschnitt beschriebenen Anforderungen sind seit Android 4.3 als „SOLLTE“ angegeben. In der Kompatibilitätsdefinition für eine zukünftige Version sollen diese Anforderungen jedoch in „MUSS“ geändert werden. Für bestehende und neue Android-Geräte wird DRINGEND empfohlen, diese Anforderungen zu erfüllen, die als „sollte“ angegeben sind. Andernfalls sind sie nach dem Upgrade auf die zukünftige Version nicht mit Android kompatibel.

5.4.1. Aufzeichnung von Roh-Audio

Geräteimplementierungen, die android.hardware.microphone deklarieren, MÜSSEN die Erfassung von Roh-Audioinhalten mit den folgenden Eigenschaften zulassen:

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

Geräteimplementierungen, die android.hardware.microphone deklarieren, MÜSSEN die Erfassung von Rohaudioinhalten mit den folgenden Eigenschaften zulassen:

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

5.4.2. Für Spracherkennung aufnehmen

Zusätzlich zu den oben genannten Aufnahmespezifikationen gilt Folgendes, wenn eine Anwendung die Aufnahme eines Audiostreams mit der Audioquelle „android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION“ gestartet hat:

• Das Gerät sollte eine nahezu flache Amplituden-/Frequenzcharakteristik aufweisen, insbesondere ± 3 dB von 100 Hz bis 4.000 Hz.
• Die Empfindlichkeit des Audioeingangs MUSS so eingestellt sein, dass eine Quelle mit einer Schallleistungspegel (SPL) von 90 dB bei 1.000 Hz einen RMS von 2.500 für 16‑Bit-Samples liefert.
• Die PCM-Amplitudenstufen MÜSSEN lineare Änderungen des Eingangs-SPL über einen Bereich von mindestens 30 dB von −18 dB bis +12 dB bezogen auf 90 dB SPL am Mikrofon verfolgen.
• Die Gesamtharmonische Verzerrung sollte bei 1 kHz bei einem Eingangspegel von 90 dB SPL am Mikrofon unter 1% liegen.
• Die Geräuschunterdrückung muss deaktiviert sein.
• Die automatische Verstärkungsregelung muss deaktiviert sein.

Wenn die Plattform Technologien zur Geräuschunterdrückung unterstützt, die für die Spracherkennung optimiert sind, MUSS der Effekt über die API „android.media.audiofx.NoiseSuppressor“ steuerbar sein. Außerdem MUSS das UUID-Feld für den Effektdeskriptor des Rauschunterdrückers jede Implementierung der Rauschunterdrückungstechnologie eindeutig identifizieren.

5.4.3. Daten für die Weiterleitung der Wiedergabe erfassen

Die Klasse „android.media.MediaRecorder.AudioSource“ enthält die Audioquelle „REMOTE_SUBMIX“. Geräte, die android.hardware.audio.output deklarieren, MÜSSEN die Audioquelle REMOTE_SUBMIX korrekt implementieren. Wenn eine Anwendung die android.media.AudioRecord API verwendet, um von dieser Audioquelle aufzunehmen, kann sie einen Mix aller Audiostreams aufzeichnen, mit folgenden Ausnahmen:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5. Audiowiedergabe

Geräteimplementierungen, die android.hardware.audio.output deklarieren, MÜSSEN den Anforderungen in diesem Abschnitt entsprechen.

5.5.1. Rohe Audiowiedergabe

Das Gerät MUSS die Wiedergabe von Roh-Audioinhalten mit den folgenden Eigenschaften ermöglichen:

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

Das Gerät MUSS die Wiedergabe von Roh-Audioinhalten mit den folgenden Eigenschaften ermöglichen:

• Abtastraten: 24.000, 48.000

5.5.2. Audioeffekte

Android bietet eine API für Audioeffekte für Geräteimplementierungen [Ressourcen, 52]. Geräteimplementierungen, die die Funktion „android.hardware.audio.output“ deklarieren:

• MÜSSEN die Implementierungen von EFFECT_TYPE_EQUALIZER und EFFECT_TYPE_LOUDNESS_ENHANCER unterstützen, die über die AudioEffect-Unterklassen Equalizer und LoudnessEnhancer steuerbar sind.
• MÜSSEN die Visualizer API-Implementierung unterstützen, die über die Visualizer-Klasse gesteuert wird.
• MÜSSEN die Implementierungen von EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB und EFFECT_TYPE_VIRTUALIZER unterstützen, die über die AudioEffect-Unterklassen BassBoost, EnvironmentalReverb, PresetReverb und Virtualizer gesteuert werden.

5.5.3. Lautstärke der Audioausgabe

Android TV-Geräte müssen die Master-Lautstärke des Systems und die Lautstärkedämpfung der digitalen Audioausgabe auf unterstützten Ausgängen unterstützen, mit Ausnahme der komprimierten Audio-Passthrough-Ausgabe (bei der keine Audiodekodierung auf dem Gerät erfolgt).

5.6. Audiolatenz

Die Audiolatenz ist die Zeitverzögerung, die ein Audiosignal beim Durchlaufen eines Systems hat. Viele Anwendungsklassen erfordern kurze Latenzen, um Echtzeit-Toneffekte zu erzielen.

Im Sinne dieses Abschnitts gelten für die folgenden Begriffe die unten aufgeführten Definitionen:

• Ausgabelatenz. Das Intervall zwischen dem Schreiben eines Frames mit PCM-codierten Daten durch eine Anwendung und dem Zeitpunkt, zu dem der entsprechende Ton von einem externen Hörer gehört oder von einem Transducer erfasst werden kann.
• Cold-Output-Latenz. Die Ausgabelatenz für den ersten Frame, wenn das Audioausgabesystem vor der Anfrage inaktiv und ausgeschaltet war.
• Kontinuierliche Ausgabelatenz. Die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät Audio wiedergegeben hat.
• Eingabelatenz. Das Intervall zwischen dem Zeitpunkt, zu dem ein externer Ton dem Gerät präsentiert wird, und dem Zeitpunkt, zu dem eine Anwendung den entsprechenden Frame mit PCM-codierten Daten liest.
• Cold-Input-Latenz. Die Summe aus verlorener Eingabezeit und Eingabelatenz für den ersten Frame, wenn das Audioeingabesystem vor der Anfrage inaktiv und ausgeschaltet war.
• kontinuierliche Eingabelatenz. Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufnimmt.
• Jitter bei kaltem Start. Die Abweichung zwischen den einzelnen Messungen der Latenzwerte der Kaltstartausgabe.
• Jitter bei kaltem Eingang. Die Abweichung zwischen den einzelnen Messungen der Latenzwerte für die kalte Eingabe.
• kontinuierliche Umlauflatenz. Die Summe aus kontinuierlicher Eingabelatenz und kontinuierlicher Ausgabelatenz plus 5 Millisekunden.
• OpenSL ES PCM-Puffer-Queue-API Die PCM-bezogenen OpenSL ES APIs im Android NDK; siehe NDK_root/docs/opensles/index.html.

Geräteimplementierungen, die android.hardware.audio.output deklarieren, MÜSSEN diese Anforderungen an die Audioausgabe erfüllen oder übertreffen:

• Kaltstartlatenz von 100 Millisekunden oder weniger
• eine kontinuierliche Ausgabelatenz von 45 Millisekunden oder weniger
• Jitter der Kaltstartausgabe minimieren

Wenn eine Geräteimplementierung nach der anfänglichen Kalibrierung bei Verwendung der OpenSL ES PCM-Puffer-Queue-API die Anforderungen dieses Abschnitts für die kontinuierliche Ausgabelatenz und die Kaltstartlatenz über mindestens ein unterstütztes Audioausgabegerät erfüllt, KANN sie die Unterstützung für Audio mit niedriger Latenz melden, indem sie die Funktion „android.hardware.audio.low_latency“ über die Klasse „android.content.pm.PackageManager“ meldet [Resources, 53]. Wenn die Geräteimplementierung diese Anforderungen nicht erfüllt, darf sie KEINE Unterstützung für Audio mit niedriger Latenz melden.

Geräteimplementierungen, die android.hardware.microphone enthalten, MÜSSEN diese Anforderungen an die Audioeingabe erfüllen:

• Eingabelatenz nach dem Kaltstart von 100 Millisekunden oder weniger
• eine kontinuierliche Eingabelatenz von 30 Millisekunden oder weniger
• eine kontinuierliche Umlauflatenz von 50 Millisekunden oder weniger
• Jitter bei der Kaltstart-Eingabe minimieren

5.7. Netzwerkprotokolle

Geräte MÜSSEN die Media-Netzwerkprotokolle für die Audio- und Videowiedergabe unterstützen, wie in der Android SDK-Dokumentation [Ressourcen, 50] angegeben. Insbesondere MÜSSEN die Geräte die folgenden Mediennetzwerkprotokolle unterstützen:

• RTSP (RTP, SDP)
• HTTP(S)-progressives Streaming
• HTTP(S) Live Streaming Draft Protocol, Version 3 [Ressourcen, 54]

5.8. Secure Media

Geräteimplementierungen, die eine sichere Videoausgabe unterstützen und sichere Oberflächen unterstützen können, MÜSSEN die Unterstützung für Display.FLAG_SECURE deklarieren. Geräteimplementierungen, die die Unterstützung von Display.FLAG_SECURE deklarieren, müssen die Verbindung mit einem kryptografisch starken Mechanismus wie HDCP 2.x oder höher für Miracast-drahtlose Displays sichern, wenn sie ein drahtloses Displayprotokoll unterstützen. Wenn sie ein kabelgebundenes externes Display unterstützen, MÜSSEN die Geräteimplementierungen HDCP 1.2 oder höher unterstützen. Android TV-Geräteimplementierungen MÜSSEN HDCP 2.2 für Geräte mit 4K-Auflösung und HDCP 1.4 oder höher für niedrigere Auflösungen unterstützen. Die Upstream-Open-Source-Implementierung von Android unterstützt drahtlose (Miracast) und kabelgebundene (HDMI) Displays, was dieser Anforderung entspricht.

6. Kompatibilität von Entwicklertools und ‑optionen

6.1. Entwicklertools

Geräteimplementierungen MÜSSEN die im Android SDK bereitgestellten Android-Entwicklertools unterstützen. Android-kompatible Geräte MÜSSEN mit folgenden Funktionen kompatibel sein:

• Android Debug Bridge (adb) [Ressourcen, 55]

Geräteimplementierungen MÜSSEN alle adb-Funktionen unterstützen, die im Android SDK dokumentiert sind, einschließlich dumpsys [Ressourcen, 56]. Der geräteseitige adb-Daemon MUSS standardmäßig inaktiv sein und es MUSS einen nutzerzugänglichen Mechanismus geben, um die Android Debug Bridge zu aktivieren. Wenn bei einer Geräteimplementierung der USB-Peripheriemodus fehlt, MUSS die Android Debug Bridge über ein Local Area Network (z. B. Ethernet oder 802.11) implementiert werden.

Android unterstützt sichere adb-Verbindungen. Mit Secure adb wird adb auf bekannten authentifizierten Hosts aktiviert. Geräteimplementierungen MÜSSEN sicheres adb unterstützen.

• Dalvik Debug Monitor Service (ddms) [Ressourcen, 57]

Geräteimplementierungen MÜSSEN alle DDMS-Funktionen unterstützen, die im Android SDK dokumentiert sind. Da ddms adb verwendet, sollte die Unterstützung für ddms standardmäßig inaktiv sein, muss aber unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben beschrieben aktiviert hat.

• Monkey [Ressourcen, 58]

Geräteimplementierungen MÜSSEN das Monkey-Framework enthalten und es für Anwendungen verfügbar machen.

• SysTrace [Ressourcen, 59]

Geräteimplementierungen MÜSSEN das Systrace-Tool unterstützen, wie im Android SDK beschrieben. Systrace muss standardmäßig inaktiv sein und es MUSS einen nutzerzugänglichen Mechanismus zum Aktivieren von Systrace geben.

Die meisten Linux-basierten Systeme und Apple-Macintosh-Systeme erkennen Android-Geräte mit den Standard-Android-SDK-Tools ohne zusätzliche Unterstützung. Microsoft Windows-Systeme erfordern jedoch in der Regel einen Treiber für neue Android-Geräte. Beispielsweise erfordern neue Anbieter-IDs und manchmal auch neue Geräte-IDs benutzerdefinierte USB-Treiber für Windows-Systeme. Wenn eine Geräteimplementierung vom adb-Tool im Standard-Android SDK nicht erkannt wird, MÜSSEN Geräteimplementierer Windows-Treiber bereitstellen, mit denen Entwickler eine Verbindung zum Gerät über das adb-Protokoll herstellen können. Diese Treiber MÜSSEN für Windows XP, Windows Vista, Windows 7, Windows 8 und Windows 9 sowohl in 32-Bit- als auch in 64-Bit-Versionen bereitgestellt werden.

6.2. Entwickleroptionen

Android bietet Entwicklern die Möglichkeit, entwicklungsbezogene Einstellungen für Apps zu konfigurieren. Geräteimplementierungen MÜSSEN den Intent „android.settings.APPLICATION_DEVELOPMENT_SETTINGS“ berücksichtigen, um einstellungen für die Anwendungsentwicklung anzuzeigen [Ressourcen, 60]. In der Upstream-Android-Implementierung ist das Menü „Entwickleroptionen“ standardmäßig ausgeblendet. Nutzer können die Entwickleroptionen aufrufen, indem sie siebenmal auf das Menüelement Einstellungen > Informationen zum Gerät > Build-Nummer tippen. Geräteimplementierungen MÜSSEN eine einheitliche Nutzung der Entwickleroptionen ermöglichen. Insbesondere MÜSSEN Geräteimplementierungen die Entwickleroptionen standardmäßig ausblenden und MÜSSEN einen Mechanismus zum Aktivieren der Entwickleroptionen bereitstellen, der mit der Upstream-Android-Implementierung übereinstimmt.

7. Hardwarekompatibilität

Wenn ein Gerät eine bestimmte Hardwarekomponente mit einer entsprechenden API für Drittanbieter hat, MUSS die Geräteimplementierung diese API wie in der Android SDK-Dokumentation beschrieben implementieren. Wenn eine API im SDK mit einer Hardwarekomponente interagiert, die als optional angegeben ist und die Geräteimplementierung diese Komponente nicht hat:

• Vollständige Klassendefinitionen (wie im SDK dokumentiert) für die Komponenten-APIs MÜSSEN trotzdem angegeben werden.
• Das Verhalten der API MUSS auf angemessene Weise als No-Op implementiert werden.
• API-Methoden MÜSSEN Nullwerte zurückgeben, sofern dies in der SDK-Dokumentation zulässig ist.
• API-Methoden MÜSSEN No-Op-Implementierungen von Klassen zurückgeben, bei denen Nullwerte gemäß der SDK-Dokumentation nicht zulässig sind.
• API-Methoden DÜRFEN KEINE Ausnahmen auslösen, die nicht in der SDK-Dokumentation beschrieben sind.

Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telephony API: Auch auf Geräten ohne Telefonfunktion müssen diese APIs als vernünftige No-Ops implementiert werden.

Geräteimplementierungen MÜSSEN für denselben Build-Fingerabdruck über die Methoden „getSystemAvailableFeatures()“ und „hasSystemFeature(String)“ der Klasse „android.content.pm.PackageManager“ korrekte Informationen zur Hardwarekonfiguration angeben. [Ressourcen, 53]

7.1. Display und Grafik

Android bietet Funktionen, mit denen sich App-Assets und UI-Layouts automatisch an das Gerät anpassen lassen, damit Drittanbieter-Apps auf einer Vielzahl von Hardwarekonfigurationen reibungslos funktionieren [Ressourcen, 61]. Auf Geräten MÜSSEN diese APIs und Verhaltensweisen wie in diesem Abschnitt beschrieben ordnungsgemäß implementiert sein.

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

• die physische Diagonale. Der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Bereichs des Displays.
• Punkte pro Zoll (dpi). Die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1" abgedeckt werden. Wenn dpi-Werte aufgeführt sind, müssen sowohl die horizontalen als auch die vertikalen dpi in den Bereich fallen.
• Seitenverhältnis. Das Verhältnis der Pixel der längeren Seite zur kürzeren Seite des Bildschirms. Ein Display mit 480 × 854 Pixeln hat beispielsweise ein Seitenverhältnis von 854 ÷ 480 = 1, 779, also ungefähr „16:9“.
• Dichteunabhängiges Pixel (dp): Die virtuelle Pixeleinheit, die auf ein Display mit 160 dpi normiert ist. Die Berechnung erfolgt so: Pixel = dp * (Dichte/160).

7.1.1. Bildschirmkonfiguration

7.1.1.1. Displaygröße

Das Android-UI-Framework unterstützt eine Vielzahl verschiedener Bildschirmgrößen und ermöglicht es Apps, die Bildschirmgröße des Geräts (auch „Bildschirmlayout“) über android.content.res.Configuration.screenLayout mit der SCREENLAYOUT_SIZE_MASK abzufragen. Geräteimplementierungen MÜSSEN die korrekte Bildschirmgröße melden, wie in der Android SDK-Dokumentation [Ressourcen, 61] definiert und von der übergeordneten Android-Plattform bestimmt. Insbesondere MÜSSEN Geräteimplementierungen die richtige Bildschirmgröße gemäß den folgenden logischen Bildschirmabmessungen in Dichte-unabhängigen Pixeln (dp) angeben.

• Die Bildschirmgröße der Geräte muss mindestens 426 × 320 dp (klein) betragen, es sei denn, es handelt sich um eine Android-Smartwatch.
• Geräte, für die die Bildschirmgröße als „normal“ angegeben wird, MÜSSEN eine Bildschirmgröße von mindestens 480 dp × 320 dp haben.
• Geräte, für die die Bildschirmgröße „Groß“ angegeben ist, MÜSSEN eine Bildschirmgröße von mindestens 640 dp × 480 dp haben.
• Geräte, für die die Bildschirmgröße „xlarge“ angegeben ist, MÜSSEN eine Bildschirmgröße von mindestens 960 dp × 720 dp haben.

Außerdem

• Android-Smartwatches MÜSSEN ein Display mit einer physischen Diagonale von 28 bis 64 mm haben.
• Andere Arten von Android-Geräten mit einem physisch integrierten Display MÜSSEN ein Display mit einer physischen Diagonale von mindestens 6,4 cm haben.

Die gemeldete Bildschirmgröße von Geräten darf sich zu keinem Zeitpunkt ändern.

Optional können Entwickler in der Datei „AndroidManifest.xml“ über das Attribut <supports-screens> angeben, welche Bildschirmgrößen unterstützt werden. Geräteimplementierungen MÜSSEN die angegebene Unterstützung von Apps für kleine, normale, große und sehr große Bildschirme korrekt einhalten, wie in der Android SDK-Dokumentation beschrieben.

7.1.1.2. Seitenverhältnis des Bildschirms

Das Seitenverhältnis des Displays MUSS zwischen 1,3333 (4:3) und 1,86 (ungefähr 16:9) liegen. Bei Android-Smartwatches kann das Seitenverhältnis jedoch 1,0 (1:1) betragen, da bei einer solchen Geräteimplementierung UI_MODE_TYPE_WATCH als android.content.res.Configuration.uiMode verwendet wird.

7.1.1.3. Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe von standardmäßigen logischen Dichten, die Entwicklern helfen, ihre Anwendungsressourcen zu optimieren. Geräteimplementierungen MÜSSEN über die APIs „android.util.DisplayMetrics“ nur eine der folgenden logischen Android-Framework-Dichten angeben, MÜSSEN Anwendungen mit dieser Standarddichte ausführen und DÜRFEN den Wert für das Standarddisplay zu keinem Zeitpunkt ändern.

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

Bei Geräteimplementierungen sollte die Standarddichte des Android-Frameworks definiert werden, die der physischen Dichte des Bildschirms numerisch am nächsten kommt, es sei denn, diese logische Dichte drückt die gemeldete Bildschirmgröße unter die unterstützte Mindestgröße. Wenn die Standarddichte des Android-Frameworks, die der physischen Dichte numerisch am nächsten kommt, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 dp Breite) ist, MÜSSEN Geräteimplementierungen die nächstniedrigere Standarddichte des Android-Frameworks angeben.

7.1.2. Messwerte für Displaykampagnen

Geräteimplementierungen MÜSSEN korrekte Werte für alle in android.util.DisplayMetrics [Resources, 62] definierten Displaymesswerte melden und MÜSSEN dieselben Werte melden, unabhängig davon, ob das eingebettete oder externe Display als Standarddisplay verwendet wird.

7.1.3. Displayausrichtung

Geräte MÜSSEN angeben, welche Bildschirmausrichtungen sie unterstützen (android.hardware.screen.portrait und/oder android.hardware.screen.landscape) und MÜSSEN mindestens eine unterstützte Ausrichtung angeben. Ein Gerät mit einem Display im festen Querformat, z. B. ein Fernseher oder Laptop, sollte beispielsweise nur „android.hardware.screen.landscape“ melden.

Geräte, die beide Bildschirmausrichtungen melden, MÜSSEN die dynamische Ausrichtung von Anwendungen im Hoch- oder Querformat unterstützen. Das Gerät muss also die Anfrage der Anwendung für eine bestimmte Bildschirmausrichtung respektieren. Bei Geräteimplementierungen kann entweder das Hoch- oder das Querformat als Standard ausgewählt werden.

Geräte MÜSSEN den korrekten Wert für die aktuelle Ausrichtung des Geräts melden, wenn sie über „android.content.res.Configuration.orientation“, „android.view.Display.getOrientation()“ oder andere APIs abgefragt werden.

Die gemeldete Bildschirmgröße oder -dichte darf sich bei einer Änderung der Ausrichtung NICHT ändern.

7.1.4. 2D- und 3D-Grafikbeschleunigung

Geräteimplementierungen MÜSSEN sowohl OpenGL ES 1.0 als auch 2.0 unterstützen, wie in der Android SDK-Dokumentation beschrieben. Geräteimplementierungen MÜSSEN OpenGL ES 3.0 oder 3.1 auf Geräten unterstützen, die diese Versionen unterstützen können. Geräteimplementierungen MÜSSEN auch Android RenderScript unterstützen, wie in der Android SDK-Dokumentation [Ressourcen, 63] beschrieben.

Geräteimplementierungen MÜSSEN sich auch korrekt als Unterstützer von OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 oder OpenGL 3.1 identifizieren. Das bedeutet:

• Die verwalteten APIs (z. B. über die Methode GLES10.getString()) MÜSSEN OpenGL ES 1.0 und OpenGL ES 2.0 unterstützen.
• Die nativen C/C++-OpenGL-APIs (APIs, die Apps über libGLES_v1CM.so, libGLES_v2.so oder libEGL.so zur Verfügung stehen) MÜSSEN OpenGL ES 1.0 und OpenGL ES 2.0 unterstützen.
• Geräteimplementierungen, die die Unterstützung von OpenGL ES 3.0 oder 3.1 angeben, MÜSSEN die entsprechenden verwalteten APIs und native C/C++-APIs unterstützen. Bei Geräteimplementierungen, die die Unterstützung von OpenGL ES 3.0 oder 3.1 angeben, MUSS libGLESv2.so zusätzlich zu den OpenGL ES 2.0-Funktionssymbolen die entsprechenden Funktionssymbole exportieren.

Neben OpenGL ES 3.1 bietet Android ein Erweiterungspaket mit Java-Schnittstellen [Ressourcen, 64] und native Unterstützung für erweiterte Grafikfunktionen wie Tessellation und das ASTC-Texturkomprimierungsformat. Android-Geräteimplementierungen KÖNNEN dieses Erweiterungspaket unterstützen und MÜSSEN die Unterstützung – nur bei vollständiger Implementierung – über das Feature-Flag „android.hardware.opengles.aep“ angeben.

Außerdem KÖNNEN Geräteimplementierungen beliebige OpenGL ES-Erweiterungen implementieren. Geräteimplementierungen MÜSSEN jedoch über die verwalteten und nativen OpenGL ES-APIs alle unterstützten Erweiterungsstrings melden und umgekehrt KEINE nicht unterstützten Erweiterungsstrings.

Android unterstützt die optionale Angabe von Anwendungen, für die bestimmte OpenGL-Texturkomprimierungsformate erforderlich sind. Diese Formate sind in der Regel anbieterspezifisch. Für Geräteimplementierungen ist von Android kein bestimmtes Texturkomprimierungsformat erforderlich. Sie MÜSSEN jedoch alle unterstützten Texturkomprimierungsformate über die getString()-Methode in der OpenGL API korrekt melden.

Android bietet einen Mechanismus, mit dem Anwendungen die Hardwarebeschleunigung für 2D-Grafiken auf Anwendungs-, Aktivitäts-, Fenster- oder Ansichtsebene mithilfe des Manifest-Tags „android:hardwareAccelerated“ oder direkter API-Aufrufe aktivieren können [Ressourcen, 65].

Bei Geräteimplementierungen MUSS die Hardwarebeschleunigung standardmäßig aktiviert sein. Sie MUSS deaktiviert werden, wenn der Entwickler dies anfordert, indem er „android:hardwareAccelerated=“false““ festlegt oder die Hardwarebeschleunigung direkt über die Android View APIs deaktiviert.

Außerdem MÜSSEN Geräteimplementierungen dem Verhalten entsprechen, das in der Android SDK-Dokumentation zur Hardwarebeschleunigung beschrieben ist [Ressourcen, 65].

Android enthält ein TextureView-Objekt, mit dem Entwickler hardwarebeschleunigte OpenGL ES-Texturen direkt als Rendering-Ziele in eine UI-Hierarchie einbinden können. Geräteimplementierungen MÜSSEN die TextureView API unterstützen und ein einheitliches Verhalten mit der Android-Implementierung aufweisen.

Android unterstützt EGL_ANDROID_RECORDABLE, ein EGLConfig-Attribut, das angibt, ob die EGLConfig das Rendern in ein ANativeWindow unterstützt, das Bilder in ein Video aufnimmt. Geräteimplementierungen MÜSSEN die EGL_ANDROID_RECORDABLE-Erweiterung unterstützen [Ressourcen, 66].

7.1.5. Modus für die Kompatibilität mit älteren Anwendungen

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

• Android Automotive unterstützt den alten Kompatibilitätsmodus nicht.
• Alle anderen Geräteimplementierungen MÜSSEN den Modus für die Kompatibilität mit älteren Anwendungen unterstützen, wie er im Upstream-Android-Open-Source-Code implementiert ist. Das bedeutet, dass die Auslöser oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert wird, und das Verhalten des Kompatibilitätsmodus selbst NICHT geändert werden dürfen.

7.1.6. Displaytechnologie

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

• Geräte MÜSSEN Displays unterstützen, die 16-Bit-Farbgrafiken rendern können, und SOLLTEN Displays unterstützen, die 24-Bit-Farbgrafiken rendern können.
• Die Geräte MÜSSEN Displays unterstützen, die Animationen rendern können.
• Die verwendete Displaytechnologie MUSS ein Pixelseitenverhältnis (Pixel Aspect Ratio, PAR) zwischen 0,9 und 1,15 haben. Das Pixelseitenverhältnis muss also nahezu quadratisch (1,0) sein, mit einer Toleranz von 10 bis 15 %.

7.1.7. Sekundäre Displays

Android unterstützt ein sekundäres Display, um die Medienfreigabe zu ermöglichen, und Entwickler-APIs für den Zugriff auf externe Displays. Wenn ein Gerät ein externes Display entweder über eine kabelgebundene, drahtlose oder eine eingebettete zusätzliche Displayverbindung unterstützt, MUSS die Geräteimplementierung die Displaymanager API wie in der Android SDK-Dokumentation beschrieben implementieren [Ressourcen, 67].

7.2. Eingabegeräte

Die Geräte MÜSSEN einen Touchscreen unterstützen oder die in 7.2.2 aufgeführten Anforderungen für die Bedienung ohne Touchscreen erfüllen.

7.2.1. Tastatur

Geräteimplementierungen:

• Es MUSS Unterstützung für das Input Management Framework enthalten, mit dem Drittanbieter Eingabemethodeneditoren (d.h. Soft-Tastatur) erstellen können, wie unter http://developer.android.com beschrieben.
• Es MUSS mindestens eine Soft-Tastatur implementiert sein (unabhängig davon, ob eine physische Tastatur vorhanden ist), mit Ausnahme von Android-Smartwatches, bei denen aufgrund der Bildschirmgröße eine Soft-Tastatur weniger sinnvoll ist.
• KANN zusätzliche Bildschirmtastaturen umfassen.
• KANN eine Hardwaretastatur enthalten.
• Darf KEINE Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard [Resources, 68] angegebenen Formate entspricht (QWERTY oder 12-Tasten).

7.2.2. Bedienung ohne Touchscreen

Geräteimplementierungen:

• Eine Option zur Navigation ohne Touchbedienung (Trackball, D-Pad oder Rad) kann AUSGELASSEN werden, wenn es sich bei der Geräteimplementierung nicht um ein Android TV-Gerät handelt.
• Es MUSS der korrekte Wert für android.content.res.Configuration.navigation [Resources, 68] angegeben werden.
• Es MUSS einen angemessenen alternativen Mechanismus für die Benutzeroberfläche zur Auswahl und Bearbeitung von Text geben, der mit Eingabeverwaltungs-Engines kompatibel ist. Die vorgelagerte Open-Source-Implementierung von Android enthält einen Auswahlmechanismus, der für Geräte geeignet ist, die keine Eingaben für die Navigation ohne Touchbedienung haben.

7.2.3. Navigationstasten

Die Funktionen „Startseite“, „Letzte Apps“ und „Zurück“ (den Schlüsselereignissen KEYCODE_HOME, KEYCODE_APP_SWITCH und KEYCODE_BACK zugeordnet) sind für das Android-Navigationsparadigma unerlässlich und daher:

• Bei Android-Handheld-Implementierungen MÜSSEN die Funktionen „Startseite“, „Letzte Aktivitäten“ und „Zurück“ verfügbar sein.
• Android TV-Geräte müssen die Funktionen „Startseite“ und „Zurück“ unterstützen.
• Bei der Implementierung von Android-Smartwatch-Geräten MUSS die Startbildschirmfunktion für den Nutzer verfügbar sein, ebenso wie die Zurück-Funktion, es sei denn, der UI-Modus ist UI_MODE_TYPE_WATCH.
• Android Automotive-Implementierungen MÜSSEN die Startbildschirmfunktion bereitstellen und KÖNNEN die Funktionen „Zurück“ und „Letzte Aktivitäten“ bereitstellen.
• Alle anderen Arten von Geräteimplementierungen MÜSSEN die Funktionen „Zuhause“ und „Zurück“ bereitstellen.

Diese Funktionen KÖNNEN über spezielle physische Tasten (z. B. mechanische oder kapazitive Touch-Tasten) oder über spezielle Softwaretasten auf einem bestimmten Bereich des Displays, Gesten, Touchbedienung usw. implementiert werden. Android unterstützt beide Implementierungen. Alle diese Funktionen MÜSSEN mit einer einzelnen Aktion (z.B. Tippen, Doppelklicken oder Geste) zugänglich sein, wenn sie sichtbar sind.

Die Funktion „Letzte Aufrufe“ muss, sofern vorhanden, eine sichtbare Schaltfläche oder ein sichtbares Symbol haben, es sei denn, sie wird zusammen mit anderen Navigationsfunktionen im Vollbildmodus ausgeblendet. Dies gilt nicht für Geräte, die von früheren Android-Versionen umgestellt werden und physische Schaltflächen zur Navigation und keinen Schlüssel für die letzten Apps haben.

Die Funktionen „Zuhause“ und „Zurück“ (falls vorhanden) MÜSSEN jeweils eine sichtbare Schaltfläche oder ein sichtbares Symbol haben, es sei denn, sie werden zusammen mit anderen Navigationsfunktionen im Vollbildmodus ausgeblendet oder die uiMode UI_MODE_TYPE_MASK ist auf UI_MODE_TYPE_WATCH festgelegt.

Die Menüfunktion wurde seit Android 4.0 zugunsten der Aktionsleiste eingestellt. Daher dürfen neue Geräteimplementierungen, die mit Android 5.0 und höher ausgeliefert werden, KEINE dedizierte physische Taste für die Menüfunktion haben. Bei älteren Geräten sollte KEINE spezielle physische Schaltfläche für die Menüfunktion implementiert werden. Wenn die physische Menüschaltfläche jedoch implementiert ist und auf dem Gerät Anwendungen mit einer targetSdkVersion > 10 ausgeführt werden, gilt für die Geräteimplementierung Folgendes:

• Die Schaltfläche für das Dreipunkt-Menü muss in der Aktionsleiste angezeigt werden, wenn sie sichtbar ist, und das Pop-up-Menü des Dreipunkt-Menüs darf nicht leer sein. Bei einer Geräteimplementierung, die vor Android 4.4 eingeführt wurde, aber auf Android 5.1 umgestellt wird, wird dies EMPFOHLEN.
• Die Position des Pop-ups für das Dreipunkt-Menü darf NICHT durch Auswahl der Dreipunkt-Schaltfläche in der Aktionsleiste geändert werden.
• Das Pop-up-Menü wird MÖGLICHERWEISE an einer anderen Position auf dem Display angezeigt, wenn es durch Auswahl der physischen Menüschaltfläche aufgerufen wird.

Aus Gründen der Abwärtskompatibilität müssen Geräteimplementierungen die Menüfunktion für Anwendungen verfügbar machen, wenn die targetSdkVersion kleiner als 10 ist, entweder über eine physische Schaltfläche, einen Softwareschlüssel oder Touch-Gesten. Diese Menüfunktion sollte angezeigt werden, es sei denn, sie ist zusammen mit anderen Navigationsfunktionen ausgeblendet.

Android unterstützt die Assist-Aktion [Ressourcen, 69]. Bei Android-Geräten, mit Ausnahme von Android-Smartwatches, muss die Assist-Aktion dem Nutzer jederzeit beim Ausführen von Apps zur Verfügung stehen. Die Assistenzaktion sollte durch langes Drücken der Startbildschirmtaste oder Wischen nach oben auf die Software-Startbildschirmtaste implementiert werden. Diese Funktion kann über eine andere physische Taste, einen Software-Schlüssel oder eine Geste implementiert werden, muss aber mit einer einzelnen Aktion (z.B. Tippen, Doppelklicken oder Geste) zugänglich sein, wenn andere Navigationstasten sichtbar sind.

Bei Geräteimplementierungen kann ein bestimmter Bereich des Displays für die Navigationstasten verwendet werden. In diesem Fall MÜSSEN jedoch die folgenden Anforderungen erfüllt sein:

• Die Navigationstasten der Geräteimplementierung MÜSSEN einen separaten Teil des Displays verwenden, der für Anwendungen nicht verfügbar ist. Sie DÜRFEN den für Anwendungen verfügbaren Teil des Displays NICHT verdecken oder anderweitig beeinträchtigen.
• Geräteimplementierungen MÜSSEN einen Teil des Displays für Anwendungen verfügbar machen, die die in Abschnitt 7.1.1 definierten Anforderungen erfüllen.
• Bei Geräteimplementierungen MÜSSEN die Navigationstasten angezeigt werden, wenn Apps keinen System-UI-Modus angeben oder SYSTEM_UI_FLAG_VISIBLE angeben.
• Bei Geräteimplementierungen MÜSSEN die Navigationstasten im unauffälligen „Low-Profile“-Modus (z. B. gedimmt) angezeigt werden, wenn Anwendungen SYSTEM_UI_FLAG_LOW_PROFILE angeben.
• Bei der Geräteimplementierung MÜSSEN die Navigationstasten ausgeblendet werden, wenn Apps SYSTEM_UI_FLAG_HIDE_NAVIGATION angeben.

7.2.4. Touchscreen-Eingabe

Geräteimplementierungen MÜSSEN eine Art Eingabesystem für den Cursor haben (entweder mausähnlich oder per Berührung). Wenn eine Geräteimplementierung jedoch kein Eingabesystem für Touchbedienung unterstützt, darf die Funktion „android.hardware.touchscreen“ oder „android.hardware.faketouch“ NICHT gemeldet werden. Geräteimplementierungen mit einem Eingabesystem für Eingabestifte:

• Sollte unabhängig voneinander erfasste Touchstifte unterstützen, wenn das Eingabesystem des Geräts mehrere Touchstifte unterstützt.
• Der Wert von „android.content.res.Configuration.touchscreen“ [Resources, 68] MUSS dem Typ des Touchscreens auf dem Gerät entsprechen.

Android unterstützt eine Vielzahl von Touchscreens, Touchpads und Eingabegeräten mit Touch-Emulation. Touchscreen-basierte Geräteimplementierungen sind mit einem Display [Ressourcen, 70] verknüpft, sodass der Nutzer den Eindruck hat, Elemente direkt auf dem Bildschirm zu bearbeiten. Da der Nutzer direkt auf das Display tippt, sind keine zusätzlichen visuellen Hinweise erforderlich, um die manipulierten Objekte anzuzeigen. Eine gefälschte Touch-Oberfläche bietet hingegen ein Nutzereingabesystem, das eine Teilmenge der Touchscreen-Funktionen annähert. Eine Maus oder eine Fernbedienung, die einen Bildschirmcursor steuert, ähnelt beispielsweise dem Tippen, erfordert aber, dass der Nutzer zuerst den Cursor bewegt oder den Fokus darauf legt und dann klickt. Zahlreiche Eingabegeräte wie Maus, Touchpad, gyrobasierte Air Mouse, Gyro-Cursor, Joystick und Multi-Touch-Touchpad können gefälschte Touch-Interaktionen unterstützen. Android enthält die Konstante „android.hardware.faketouch“, die einem High-Fidelity-Eingabegerät ohne Touchbedienung (Maus oder Touchpad) entspricht, das die Touchbedienung (einschließlich grundlegender Gestenunterstützung) angemessen emulieren kann. Sie gibt an, dass das Gerät eine emulierte Teilmenge der Touchscreen-Funktionen unterstützt. Geräteimplementierungen, die die Funktion „Fake Touch“ angeben, MÜSSEN die Anforderungen für Fake Touch in Abschnitt 7.2.5 erfüllen.

Bei Geräteimplementierungen MUSS die richtige Funktion für die verwendete Eingabeart angegeben werden. Geräteimplementierungen mit Touchscreen (Einzelpunktberührung oder besser) MÜSSEN die Plattformfunktionskonstante „android.hardware.touchscreen“ angeben. Geräteimplementierungen, die die Plattformfunktionskonstante „android.hardware.touchscreen“ melden, MÜSSEN auch die Plattformfunktionskonstante „android.hardware.faketouch“ melden. Geräteimplementierungen, die keinen Touchscreen haben (und nur auf ein Zeigegerät angewiesen sind), DÜRFEN KEINE Touchscreen-Funktionen angeben und MÜSSEN nur „android.hardware.faketouch“ angeben, wenn sie die Anforderungen an die Fake Touch-Funktion in Abschnitt 7.2.5 erfüllen.

7.2.5. Gefälschte Eingabe per Berührung

Geräteimplementierungen, die die Unterstützung von „android.hardware.faketouch“ deklarieren:

• MÜSSEN die absoluten X- und Y-Bildschirmpositionen des Mauszeigers angeben und einen visuellen Mauszeiger auf dem Bildschirm anzeigen [Ressourcen, 71].
• Es MUSS ein Touch-Ereignis mit dem Aktionscode gemeldet werden, der die Statusänderung angibt, die auftritt, wenn der Cursor auf dem Bildschirm nach unten oder oben bewegt wird [Ressourcen, 71].
• MÜSSEN den Zeiger auf ein Objekt auf dem Bildschirm bewegen können, um das Tippen auf ein Objekt auf dem Bildschirm zu emulieren.
• MUSS das Bewegen des Cursors auf ein Objekt auf dem Display nach unten, nach oben, nach unten und dann nach oben innerhalb eines Zeitgrenzwerts unterstützen, damit Nutzer das Doppeltippen auf ein Objekt auf dem Display emulieren können [Ressourcen, 71].
• Es MUSS unterstützt werden, dass der Cursor an einer beliebigen Stelle auf dem Display gedrückt wird, der Cursor an eine andere beliebige Stelle auf dem Display bewegt wird und der Cursor dann wieder losgelassen wird, damit Nutzer ein Ziehen per Touch emulieren können.
• Es MUSS die Möglichkeit geben, den Cursor nach unten zu bewegen und das Objekt dann schnell an eine andere Position auf dem Bildschirm zu verschieben. Danach muss es möglich sein, den Cursor auf dem Bildschirm nach oben zu bewegen, um das Objekt auf dem Bildschirm zu bewegen.

Geräte, die die Unterstützung für android.hardware.faketouch.multitouch.distinct angeben, MÜSSEN die oben genannten Anforderungen für Faketouch erfüllen und MÜSSEN auch das eindeutige Tracking von zwei oder mehr unabhängigen Eingaben des Touchstifts unterstützen.

7.2.6. Unterstützung für Gamecontroller

Android TV-Geräteimplementierungen MÜSSEN die unten aufgeführten Tastenzuordnungen für Gamecontroller unterstützen. Die Upstream-Android-Implementierung enthält eine Implementierung für Gamecontroller, die diese Anforderung erfüllt.

7.2.6.1. Tastenbelegung

Android TV-Geräteimplementierungen MÜSSEN die folgenden Tastenzuordnungen unterstützen:

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

1 [Ressourcen, 72]

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

3 Dieser Wert muss ein logisches Minimum von 0, ein logisches Maximum von 7, ein physikalisches Minimum von 0, ein physikalisches Maximum von 315, Einheiten in Grad und eine Berichtsgröße von 4 haben. Der logische Wert wird als Drehung im Uhrzeigersinn weg von der vertikalen Achse definiert. Ein logischer Wert von 0 steht beispielsweise für keine Drehung und die gedrückte Aufwärtstaste, während ein logischer Wert von 1 für eine Drehung von 45 Grad und die gedrückten Auf- und Linkstasten steht.

4 [Ressourcen, 71]

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

1 [Ressourcen, 71]

7.2.7. Fernbedienung

Android TV-Geräte müssen eine Fernbedienung haben, damit Nutzer auf die TV-Oberfläche zugreifen können. Die Fernbedienung kann eine physische oder eine softwarebasierte Fernbedienung sein, auf die über ein Smartphone oder Tablet zugegriffen werden kann. Die Fernbedienung MUSS die unten aufgeführten Anforderungen erfüllen.

• Suchaffordance Bei Geräteimplementierungen MUSS KEYCODE_SEARCH ausgelöst werden, wenn der Nutzer die Sprachsuche entweder über die physische oder softwarebasierte Fernbedienung aufruft.
• Navigation Alle Android TV-Fernbedienungen MÜSSEN die Tasten „Zurück“, „Startseite“ und „Auswählen“ sowie die Unterstützung für D-Pad-Ereignisse enthalten [Ressourcen, 72].

7.3. Sensoren

Android bietet APIs für den Zugriff auf verschiedene Sensortypen. Bei der Geräteimplementierung können diese Sensoren in der Regel gemäß den folgenden Abschnitten weggelassen werden. Wenn ein Gerät einen bestimmten Sensortyp mit einer entsprechenden API für Drittanbieter enthält, MUSS die Geräteimplementierung diese API gemäß der Beschreibung in der Android SDK-Dokumentation und der Android Open Source-Dokumentation zu Sensoren [Ressourcen, 73] implementieren. Beispielsweise bei Geräteimplementierungen:

• MÜSSEN das Vorhandensein oder Fehlen von Sensoren gemäß der Klasse „android.content.pm.PackageManager“ [Ressourcen, 53] korrekt melden.
• MÜSSEN über die Methode „SensorManager.getSensorList()“ und ähnliche Methoden eine genaue Liste der unterstützten Sensoren zurückgeben.
• MÜSSEN sich für alle anderen Sensor-APIs angemessen verhalten (z. B. durch Rückgabe von „wahr“ oder „falsch“, wenn Anwendungen versuchen, Listener zu registrieren, oder durch Nichtaufrufen von Sensor-Listenern, wenn die entsprechenden Sensoren nicht vorhanden sind).
• Alle Sensormessungen MÜSSEN für jeden Sensortyp gemäß der Definition in der Android SDK-Dokumentation [Ressourcen, 74] mit den entsprechenden Werten des internationalen Einheitensystems (metrisch) erfasst werden.
• Die Ereigniszeit sollte in Nanosekunden angegeben werden, wie in der Android SDK-Dokumentation definiert. Sie entspricht dem Zeitpunkt des Ereignisses und ist mit der SystemClock.elapsedRealtimeNano()-Uhr synchronisiert. Wir empfehlen Ihnen dringend, diese Anforderung für bestehende und neue Android-Geräte zu erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt werden können, bei denen diese Funktion möglicherweise zur ERFORDERLICHEN Komponente wird. Der Synchronisierungsfehler sollte unter 100 Millisekunden liegen [Ressourcen, 75].

Die Liste oben ist nicht vollständig. Das dokumentierte Verhalten des Android SDK und der Android Open Source-Dokumentationen zu Sensoren [Ressourcen, 73] ist als verbindlich anzusehen.

Einige Sensortypen sind zusammengesetzt, d. h., sie können aus Daten abgeleitet werden, die von einem oder mehreren anderen Sensoren bereitgestellt werden. Beispiele sind der Orientierungssensor und der lineare Beschleunigungssensor. Geräteimplementierungen MÜSSEN diese Sensortypen implementieren, wenn sie die erforderlichen physischen Sensoren enthalten, wie in [Ressourcen, 76] beschrieben. Wenn eine Geräteimplementierung einen Kompositsensor enthält, MUSS der Sensor wie in der Android Open Source-Dokumentation zu Kompositsensoren beschrieben implementiert werden [Ressourcen, 76].

Einige Android-Sensoren unterstützen einen „kontinuierlichen“ Triggermodus, bei dem Daten kontinuierlich zurückgegeben werden [Ressourcen, 77]. Für alle APIs, die in der Android SDK-Dokumentation als kontinuierlicher Sensor angegeben sind, MÜSSEN Geräteimplementierungen kontinuierliche Datenproben bereitstellen, deren Jitter UNTER 3 % liegen SOLLTE. Jitter wird als Standardabweichung der Differenz der gemeldeten Zeitstempelwerte zwischen aufeinanderfolgenden Ereignissen definiert.

Die Geräteimplementierungen MÜSSEN dafür sorgen, dass der Sensorereignisstream NICHT verhindert, dass die CPU des Geräts in den Ruhemodus wechselt oder aus dem Ruhemodus aufwacht.

Wenn mehrere Sensoren aktiviert sind, darf die Stromaufnahme NICHT die Summe der gemeldeten Stromaufnahme der einzelnen Sensoren überschreiten.

7.3.1. Beschleunigungsmesser

Geräteimplementierungen MÜSSEN einen 3-Achsen-Beschleunigungsmesser enthalten. Bei Android-Mobilgeräten und Android-Smartwatches wird dringend empfohlen, diesen Sensor zu verwenden. Wenn eine Geräteimplementierung einen 3-Achsen-Beschleunigungsmesser enthält, gilt Folgendes:

• Der Sensor TYPE_ACCELEROMETER MUSS implementiert und gemeldet werden [Ressourcen, 78].
• MUSS Ereignisse mit einer Häufigkeit von mindestens 50 Hz für Android-Smartwatches erfassen können, da diese Geräte strengere Energieeinschränkungen haben, und 100 Hz für alle anderen Gerätetypen.
• MÜSSEN Ereignisse mit mindestens 200 Hz erfassen.
• MÜSSEN dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben [Ressourcen, 74].
• MÜSSEN in der Lage sein, von freiem Fall bis zu viermal die Erdbeschleunigung (4 g) oder mehr auf jeder Achse zu messen.
• MÜSSEN eine Auflösung von mindestens 8 Bit haben und SOLLTEN eine Auflösung von mindestens 16 Bit haben.
• MÜSSEN während der Nutzung kalibriert werden, wenn sich die Eigenschaften im Laufe des Lebenszyklus ändern und kompensiert werden, und die Kompensationsparameter zwischen den Neustarts des Geräts beibehalten.
• SOLLTE temperaturkompensiert sein.
• Die Standardabweichung darf maximal 0,05 m/s² betragen.Sie sollte pro Achse anhand von Stichproben berechnet werden, die über einen Zeitraum von mindestens 3 Sekunden mit der höchsten Abtastrate erfasst wurden.
• MÜSSEN die zusammengesetzten Sensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR und TYPE_STEP_COUNTER wie im Android SDK-Dokument beschrieben implementieren. Für bestehende und neue Android-Geräte wird dringend empfohlen, den zusammengesetzten Sensor TYPE_SIGNIFICANT_MOTION zu implementieren. Wenn einer dieser Sensoren implementiert ist, darf die Summe der Leistungsaufnahme immer weniger als 4 mW betragen und sollte für den dynamischen oder statischen Zustand des Geräts jeweils unter 2 mW und 0,5 mW liegen.
• Wenn ein Gyroskopsensor enthalten ist, MÜSSEN die zusammengesetzten Sensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementiert werden und SOLLTE der zusammengesetzte Sensor TYPE_GAME_ROTATION_VECTOR implementiert werden. Wir empfehlen dringend, den Sensor TYPE_GAME_ROTATION_VECTOR auf bestehenden und neuen Android-Geräten zu implementieren.
• Es sollte ein zusammengesetzter TYPE_ROTATION_VECTOR-Sensor implementiert werden, wenn auch ein Gyroskopsensor und ein Magnetometersensor vorhanden sind.

7.3.2. Magnetometer

Geräteimplementierungen MÜSSEN ein 3-Achsen-Magnetometer (Kompass) enthalten. Wenn ein Gerät ein 3-Achsen-Magnetometer enthält, gilt Folgendes:

• Der Sensor vom Typ „MAGNETFELD“ MUSS implementiert sein und der Sensor vom Typ „MAGNETFELD_NICHT KALLIBRIERT“ SOLLTE implementiert sein. Wir empfehlen Ihnen dringend, den Sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED auf bestehenden und neuen Android-Geräten zu implementieren.
• MÜSSEN Ereignisse mit einer Häufigkeit von mindestens 10 Hz erfassen und SOLLTEN Ereignisse mit einer Häufigkeit von mindestens 50 Hz erfassen.
• MÜSSEN dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben [Ressourcen, 74].
• MÜSSEN in der Lage sein, zwischen -900 µT und +900 µT auf jeder Achse zu messen, bevor sie übersättigt sind.
• Der Wert für den harten Eisenabstand MUSS unter 700 µT liegen und sollte unter 200 µT liegen. Platzieren Sie den Magnetometer daher weit entfernt von dynamischen (strominduzierten) und statischen (magnetinduzierten) Magnetfeldern.
• Die Auflösung MUSS mindestens 0,6 µT betragen und sollte mindestens 0,2 µ betragen.
• SOLLTE temperaturkompensiert sein.
• MÜSSEN die Onlinekalibrierung und ‑kompensation der Magnetfeldabweichung unterstützen und die Kompensationsparameter zwischen den Neustarts des Geräts beibehalten.
• Die weichmagnetische Kalibrierung MUSS angewendet werden. Die Kalibrierung kann entweder während der Nutzung oder während der Herstellung des Geräts erfolgen.
• Die Standardabweichung, die auf der Grundlage von Stichproben berechnet wird, die über einen Zeitraum von mindestens 3 Sekunden mit der schnellsten Abtastrate erfasst wurden, sollte pro Achse nicht größer als 0,5 µT sein.
• Es sollte ein zusammengesetzter TYPE_ROTATION_VECTOR-Sensor implementiert werden, wenn auch ein Beschleunigungsmesser und ein Gyroskop vorhanden sind.
• Der Sensor vom Typ TYPE_GEOMAGNETIC_ROTATION_VECTOR kann implementiert werden, wenn auch ein Beschleunigungssensor implementiert ist. Bei der Implementierung darf der Sensor jedoch weniger als 10 mW und sollte weniger als 3 mW verbrauchen, wenn er für den Batchmodus bei 10 Hz registriert ist.

7.3.3. GPS

Geräteimplementierungen MÜSSEN einen GPS-Empfänger enthalten. Wenn eine Geräteimplementierung einen GPS-Empfänger enthält, sollte sie eine Form von „Assisted GPS“ (erweitertes GPS) enthalten, um die Zeit bis zur GPS-Fixierung zu minimieren.

7.3.4. Gyroskop

Geräteimplementierungen MÜSSEN ein Gyroskop (Winkeländerungssensor) enthalten. Geräte sollten KEIN Gyroskop enthalten, es sei denn, es ist auch ein 3-Achsen-Beschleunigungsmesser vorhanden. Wenn eine Geräteimplementierung ein Gyroskop enthält, gilt Folgendes:

• Der Sensor vom Typ TYPE_GYROSCOPE MUSS implementiert werden und der Sensor vom Typ TYPE_GYROSCOPE_UNCALIBRATED SOLLTE ebenfalls implementiert werden. Wir empfehlen Ihnen dringend, den Sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED auf bestehenden und neuen Android-Geräten zu implementieren.
• MÜSSEN in der Lage sein,Ausrichtungsänderungen von bis zu 1.000 Grad pro Sekunde zu messen.
• MUSS Ereignisse mit einer Häufigkeit von mindestens 50 Hz für Android-Smartwatches erfassen können, da diese Geräte strengere Energieeinschränkungen haben, und 100 Hz für alle anderen Gerätetypen.
• MÜSSEN Ereignisse mit mindestens 200 Hz erfassen.
• Die Auflösung MUSS mindestens 12 Bit betragen und SOLLTE mindestens 16 Bit betragen.
• MÜSSEN temperaturkompensiert sein.
• MÜSSEN während der Nutzung kalibriert und kompensiert werden und die Kompensationsparameter zwischen den Neustarts des Geräts beibehalten.
• Die Abweichung darf maximal 1 · 10−7 rad² / s² pro Hz betragen (Abweichung pro Hz oder rad² / s). Die Abweichung darf mit der Abtastrate variieren, muss aber durch diesen Wert begrenzt sein. Mit anderen Worten: Wenn Sie die Varianz des Gyroskops bei einer Abtastrate von 1 Hz messen, darf sie nicht größer als 1 E-7 rad²/s² sein.
• Es sollte ein zusammengesetzter TYPE_ROTATION_VECTOR-Sensor implementiert werden, wenn auch ein Beschleunigungsmesser und ein Magnetometer vorhanden sind.
• Wenn ein Beschleunigungssensor enthalten ist, MÜSSEN die zusammengesetzten Sensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementiert werden und SOLLTE der zusammengesetzte Sensor TYPE_GAME_ROTATION_VECTOR implementiert werden. Wir empfehlen dringend, den Sensor TYPE_GAME_ROTATION_VECTOR auf bestehenden und neuen Android-Geräten zu implementieren.

7.3.5. Barometer

Geräteimplementierungen MÜSSEN ein Barometer (Umgebungsluftdrucksensor) enthalten. Wenn eine Geräteimplementierung ein Barometer enthält, gilt Folgendes:

• Der Sensor TYPE_PRESSURE MUSS implementiert und gemeldet werden.
• MÜSSEN Ereignisse mit mindestens 5 Hz senden können.
• MÜSSEN eine ausreichende Genauigkeit haben, um die Höhe schätzen zu können.
• MÜSSEN temperaturkompensiert sein.

7.3.6. Thermometer

Geräteimplementierungen KÖNNEN ein Umgebungsthermometer (Temperatursensor) enthalten. Falls vorhanden, MUSS er als SENSOR_TYPE_AMBIENT_TEMPERATURE definiert sein und MUSS die Umgebungstemperatur (Raumtemperatur) in Grad Celsius messen.

Geräteimplementierungen KÖNNEN, MÜSSEN aber keinen CPU-Temperatursensor enthalten. Wenn vorhanden, MUSS er als SENSOR_TYPE_TEMPERATURE definiert sein, MUSS die Temperatur der Geräte-CPU messen und DARF KEINE andere Temperatur messen. Der Sensortyp SENSOR_TYPE_TEMPERATURE wurde in Android 4.0 eingestellt.

7.3.7. Fotometer

Geräteimplementierungen KÖNNEN einen Photometer (Umgebungslicht-Sensor) enthalten.

7.3.8. Näherungssensor

Geräteimplementierungen KÖNNEN einen Näherungssensor enthalten. Geräte, die Sprachanrufe starten können und in getPhoneType einen anderen Wert als PHONE_TYPE_NONE angeben, MÜSSEN einen Näherungssensor haben. Wenn eine Geräteimplementierung einen Näherungssensor enthält, gilt Folgendes:

• MÜSSEN die Nähe eines Objekts in derselben Richtung wie das Display messen. Der Näherungssensor MUSS so ausgerichtet sein, dass er Objekte in der Nähe des Displays erkennt, da dieser Sensortyp in erster Linie dazu dient, ein vom Nutzer verwendetes Smartphone zu erkennen. Wenn eine Geräteimplementierung einen Näherungssensor mit einer anderen Ausrichtung enthält, darf er NICHT über diese API zugänglich sein.
• MÜSSEN eine Genauigkeit von mindestens 1 Bit haben.

7.4. Datenverbindung

7.4.1. Telefonie

„Telefonie“ bezieht sich in den Android APIs und in diesem Dokument speziell auf Hardware, die für das Tätigen von Sprachanrufen und das Senden von SMS über ein GSM- oder CDMA-Netzwerk verwendet wird. Diese Sprachanrufe können paketvermittelt sein oder nicht, werden aber für Android unabhängig von jeglicher Datenverbindung betrachtet, die über dasselbe Netzwerk implementiert werden kann. Mit anderen Worten: Die Android-Funktionen und APIs für die „Telefonie“ beziehen sich speziell auf Sprachanrufe und SMS. Geräteimplementierungen, die keine Anrufe starten oder SMS senden/empfangen können, dürfen beispielsweise die Funktion „android.hardware.telephony“ oder Unterfunktionen nicht melden, unabhängig davon, ob sie ein Mobilfunknetz für die Datenverbindung verwenden.

Android KANN auf Geräten verwendet werden, die keine Telefoniehardware enthalten. Android ist also mit Geräten kompatibel, die keine Smartphones sind. Wenn eine Geräteimplementierung jedoch GSM- oder CDMA-Telefonie umfasst, MUSS sie die API für diese Technologie vollständig unterstützen. Bei Geräteimplementierungen ohne Telefoniehardware MÜSSEN die APIs vollständig als No-Ops implementiert werden.

7.4.2. IEEE 802.11 (Wi‑Fi)

Android TV-Geräteimplementierungen MÜSSEN eine oder mehrere Formen von 802.11 (b/g/a/n usw.) unterstützen und andere Arten von Android-Geräteimplementierungen SOLLTEN eine oder mehrere Formen von 802.11 unterstützen. Wenn eine Geräteimplementierung 802.11 unterstützt und die Funktion für eine Drittanbieteranwendung freigibt, MUSS die entsprechende Android API implementiert werden und:

• Das Hardware-Funktions-Flag „android.hardware.wifi“ MUSS angegeben werden.
• Die Multicast API muss wie in der SDK-Dokumentation beschrieben implementiert werden [Ressourcen, 79].
• MUSS Multicast-DNS (mDNS) unterstützen und darf mDNS-Pakete (224.0.0.251) zu keinem Zeitpunkt filtern, auch nicht, wenn sich der Bildschirm nicht im aktiven Zustand befindet.

7.4.2.1. Wi-Fi Direct

Geräteimplementierungen MÜSSEN Wi‑Fi Direct (Wi‑Fi-Peer-to-Peer) unterstützen. Wenn eine Geräteimplementierung Wi‑Fi Direct unterstützt, MUSS die entsprechende Android API wie in der SDK-Dokumentation beschrieben implementiert werden [Ressourcen, 80]. Wenn eine Geräteimplementierung Wi‑Fi Direct unterstützt, gilt Folgendes:

• Die Hardwarefunktion „android.hardware.wifi.direct“ MUSS angegeben werden.
• MÜSSEN den regulären WLAN-Betrieb unterstützen.
• SOLLTE gleichzeitiges WLAN und Wi‑Fi Direct unterstützen.

7.4.2.2. Einrichtung eines Wi‑Fi-Tunneled Direct Link

Android TV-Geräteimplementierungen MÜSSEN Wi‑Fi Tunneled Direct Link Setup (TDLS) unterstützen und andere Arten von Android-Geräteimplementierungen SOLLTEN Wi‑Fi TDLS unterstützen, wie in der Android SDK-Dokumentation [Ressourcen, 81] beschrieben. Wenn eine Geräteimplementierung TDLS unterstützt und TDLS über die WiFiManager API aktiviert ist, gilt für das Gerät Folgendes:

• TDLS sollte nur verwendet werden, wenn es möglich UND vorteilhaft ist.
• SOLLTE eine Heuristik haben und KEIN TDLS verwenden, wenn die Leistung möglicherweise schlechter ist als über den WLAN-Zugangspunkt.

7.4.3. Bluetooth

Android unterstützt Bluetooth und Bluetooth Low Energy [Ressourcen, 82]. Geräteimplementierungen, die Bluetooth und Bluetooth Low Energy unterstützen, MÜSSEN die entsprechenden Plattformfunktionen (android.hardware.bluetooth und android.hardware.bluetooth_le) deklarieren und die Plattform-APIs implementieren. Geräteimplementierungen MÜSSEN relevante Bluetooth-Profile wie A2DP, AVCP, OBEX usw. implementieren, sofern für das Gerät erforderlich. Android TV-Geräte müssen Bluetooth und Bluetooth LE unterstützen.

Geräteimplementierungen mit Unterstützung für Bluetooth Low Energy:

• Die Hardwarefunktion „android.hardware.bluetooth_le“ MUSS deklariert werden.
• Die GATT-basierten (Generic Attribute Profile) Bluetooth APIs MÜSSEN wie in der SDK-Dokumentation und in [Ressourcen, 82] beschrieben aktiviert werden.
• Die Auslagerung der Filterlogik an den Bluetooth-Chipsatz MUSS bei der Implementierung der ScanFilter API [Ressourcen, 83] unterstützt werden. Außerdem MUSS der korrekte Wert für die Implementierung der Filterlogik angegeben werden, wenn über die Methode „android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported()“ abgefragt wird.
• Sollte das Auslagern des Batch-Scans an den Bluetooth-Chip unterstützen. Wenn dies nicht unterstützt wird, MUSS bei jeder Abfrage über die Methode „android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported()“ „false“ zurückgegeben werden.
• Sollte mehrere Anzeigen mit mindestens 4 Slots unterstützen. Wenn nicht unterstützt, MUSS bei jeder Abfrage über die Methode „android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported()“ „false“ zurückgegeben werden.

7.4.4. Nahfeldkommunikation

Geräteimplementierungen MÜSSEN einen Transceiver und zugehörige Hardware für die Nahfeldkommunikation (Near Field Communication, NFC) enthalten. Wenn eine Geräteimplementierung NFC-Hardware enthält und diese für Drittanbieter-Apps verfügbar machen soll, gilt Folgendes:

• Die Funktion „android.hardware.nfc“ MUSS über die Methode „android.content.pm.PackageManager.hasSystemFeature()“ gemeldet werden [Ressourcen, 53].
• MÜSSEN NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können:
  • MUSS als NFC-Forum-Lese-/Schreibgerät (wie in der technischen Spezifikation NFCForum-TS-DigitalProtocol-1.0 des NFC-Forums definiert) über die folgenden NFC-Standards funktionieren:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC-Forum-Tag-Typen 1, 2, 3 und 4 (vom NFC-Forum definiert)
  • MÜSSEN NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können. Die folgenden NFC-Standards sind zwar als „SOLLTE“ angegeben, in der Kompatibilitätsdefinition für eine zukünftige Version werden sie jedoch voraussichtlich in „MUSS“ geändert. Diese Standards sind in dieser Version optional, werden aber in zukünftigen Versionen erforderlich sein. Wir empfehlen Ihnen dringend, diese Anforderungen jetzt auf bestehenden und neuen Geräten mit dieser Android-Version zu erfüllen, damit Sie auf die zukünftigen Plattformversionen umstellen können.
  • NfcV (ISO 15693)
  • MÜSSEN Daten über die folgenden Peer-to-Peer-Standards und ‑Protokolle senden und empfangen können:
    • ISO 18092
    • LLCP 1.0 (vom NFC-Forum definiert)
    • SDP 1.0 (vom NFC Forum definiert)
    • NDEF Push Protocol [Resources, 84]
    • SNEP 1.0 (vom NFC-Forum definiert)
  • MÜSSEN Android Beam unterstützen [Ressourcen, 85]:
    • Der SNEP-Standardserver MUSS implementiert werden. Gültige NDEF-Nachrichten, die vom Standard-SNEP-Server empfangen werden, MÜSSEN an Anwendungen mithilfe des Intents „android.nfc.ACTION_NDEF_DISCOVERED“ gesendet werden. Wenn Sie Android Beam in den Einstellungen deaktivieren, darf der Versand eingehender NDEF-Nachrichten NICHT deaktiviert werden.
    • Die Intent-Anfrage „android.settings.NFCSHARING_SETTINGS“ MUSS berücksichtigt werden, um die NFC-Freigabeeinstellungen anzuzeigen [Ressourcen, 86].
    • Der NPP-Server MUSS implementiert sein. Nachrichten, die vom NPP-Server empfangen werden, MÜSSEN auf die gleiche Weise verarbeitet werden wie vom SNEP-Standardserver.
    • MUSS einen SNEP-Client implementieren und versuchen, ausgehende P2P-NDEF-Nachrichten an den Standard-SNEP-Server zu senden, wenn Android Beam aktiviert ist. Wenn kein standardmäßiger SNEP-Server gefunden wird, MUSS der Client versuchen, an einen NPP-Server zu senden.
    • Es MUSS zulässig sein, dass Aktivitäten im Vordergrund die ausgehende P2P-NDEF-Nachricht mit den Funktionen „android.nfc.NfcAdapter.setNdefPushMessage“, „android.nfc.NfcAdapter.setNdefPushMessageCallback“ und „android.nfc.NfcAdapter.enableForegroundNdefPush“ festlegen.
    • SOLLTE eine Geste oder Bestätigung auf dem Bildschirm verwenden, z. B. „Zum Übertragen berühren“, bevor ausgehende P2P-NDEF-Nachrichten gesendet werden.
    • Android Beam MUSS standardmäßig aktiviert sein und MUSS über Android Beam senden und empfangen können, auch wenn ein anderer proprietärer NFC-P2P-Modus aktiviert ist.
    • MUSS die NFC-Verbindungsweitergabe an Bluetooth unterstützen, wenn das Gerät das Bluetooth Object Push Profile unterstützt. Geräteimplementierungen MÜSSEN die Verbindungsweitergabe an Bluetooth unterstützen, wenn android.nfc.NfcAdapter.setBeamPushUris verwendet wird. Dazu müssen die Spezifikationen „Connection Handover version 1.2“ [Ressourcen, 87] und „Bluetooth Secure Simple Pairing Using NFC version 1.0“ [Ressourcen, 88] des NFC Forums implementiert werden. Eine solche Implementierung MUSS den LLCP-Übergabedienst mit dem Dienstnamen „urn:nfc:sn:handover“ zum Austausch von Übergabeanfragen/-auswahlen über NFC implementieren und MUSS das Bluetooth Object Push Profile für die eigentliche Bluetooth-Datenübertragung verwenden. Aus Gründen der Abwärtskompatibilität (für die Kompatibilität mit Android 4.1-Geräten) sollte die Implementierung weiterhin SNEP-GET-Anfragen zum Austausch der Übergabeanfrage/Auswahldatensätze über NFC akzeptieren. Eine Implementierung sollte jedoch KEINE SNEP-GET-Anfragen zum Übergeben der Verbindung senden.
  • MUSS im NFC-Erkennungsmodus nach allen unterstützten Technologien suchen.
  • MÜSSEN sich im NFC-Erkennungsmodus befinden, während das Gerät aktiv ist, das Display eingeschaltet und der Sperrbildschirm entsperrt ist.

(Hinweis: Für die oben genannten JIS-, ISO- und NFC-Forum-Spezifikationen sind keine öffentlich zugänglichen Links verfügbar.)

Android unterstützt den NFC-HCE-Modus (Host Card Emulation). Wenn eine Geräteimplementierung einen NFC-Controller-Chipsatz mit HCE- und AID-Routing (Application ID) enthält, gilt Folgendes:

• Die Funktion „android.hardware.nfc.hce“ MUSS als Konstante gemeldet werden.
• MÜSSEN NFC HCE APIs gemäß der Definition im Android SDK unterstützen [Ressourcen, 10].

Darüber hinaus können Geräteimplementierungen L/W-Unterstützung für die folgenden MIFARE-Technologien umfassen.

• MIFARE Classic
• MIFARE Ultralight
• NDEF auf MIFARE Classic

Android enthält APIs für diese MIFARE-Typen. Wenn eine Geräteimplementierung MIFARE in der Leser-/Schreiberrolle unterstützt, gilt Folgendes:

• MÜSSEN die entsprechenden Android APIs gemäß der Dokumentation des Android SDK implementieren.
• Die Funktion „com.nxp.mifare“ MUSS über die Methode „android.content.pm.PackageManager.hasSystemFeature()“ gemeldet werden.[Resources, 53] Hinweis: Dies ist keine Standardfunktion von Android und wird daher nicht als Konstante in der PackageManager-Klasse angezeigt.
• Die entsprechenden Android APIs dürfen NICHT implementiert und die Funktion „com.nxp.mifare“ darf NICHT gemeldet werden, es sei denn, die allgemeine NFC-Unterstützung wird wie in diesem Abschnitt beschrieben implementiert.

Wenn eine Geräteimplementierung keine NFC-Hardware enthält, DARF die Funktion „android.hardware.nfc“ nicht über die Methode „android.content.pm.PackageManager.hasSystemFeature()“ [Resources, 53] deklariert werden. Außerdem MUSS die Android NFC API als No-Op implementiert werden.

Da die Klassen android.nfc.NdefMessage und android.nfc.NdefRecord ein protokollunabhängiges Datendarstellungsformat darstellen, MÜSSEN Geräteimplementierungen diese APIs implementieren, auch wenn sie keine Unterstützung für NFC enthalten oder die Funktion android.hardware.nfc deklarieren.

7.4.5. Mindestnetzwerkanforderungen

Geräteimplementierungen MÜSSEN eine oder mehrere Formen der Datenkommunikation unterstützen. Insbesondere müssen Geräteimplementierungen mindestens einen Datenstandard mit einer Geschwindigkeit von mindestens 200 Kbit/s unterstützen. Beispiele für Technologien, die diese Anforderung erfüllen, sind EDGE, HSPA, EV-DO, 802.11g, Ethernet und Bluetooth PAN.

Geräteimplementierungen, bei denen ein physischer Netzwerkstandard (z. B. Ethernet) die primäre Datenverbindung ist, MÜSSEN mindestens einen gängigen drahtlosen Datenstandard wie 802.11 (Wi‑Fi) unterstützen.

Geräte KÖNNEN mehrere Arten von Datenverbindungen implementieren.

7.4.6. Synchronisierungseinstellungen

Bei Geräteimplementierungen muss die Einstellung für die automatische Mastersynchronisierung standardmäßig aktiviert sein, damit die Methode „getMasterSyncAutomatically()“ „true“ zurückgibt [Ressourcen, 89].

7.5. Kameras

Geräteimplementierungen MÜSSEN eine Rückkamera und KÖNNEN eine Frontkamera haben. Eine Rückkamera befindet sich auf der Seite des Geräts, die dem Display gegenüberliegt. Sie nimmt also Bilder auf der Rückseite des Geräts auf, ähnlich wie eine herkömmliche Kamera. Eine Frontkamera befindet sich auf derselben Seite des Geräts wie das Display. Sie wird in der Regel verwendet, um den Nutzer abzubilden, z. B. bei Videokonferenzen und ähnlichen Anwendungen.

Wenn eine Geräteimplementierung mindestens eine Kamera enthält, sollte es für eine Anwendung möglich sein, gleichzeitig drei Bitmaps zuzuweisen, die der Größe der Bilder entsprechen, die vom Kamerasensor mit der höchsten Auflösung auf dem Gerät aufgenommen werden.

7.5.1. Rückkamera

Geräteimplementierungen MÜSSEN eine Rückkamera haben. Wenn eine Geräteimplementierung mindestens eine Rückkamera enthält, gilt Folgendes:

• MÜSSEN die Funktions-Flags „android.hardware.camera“ und „android.hardware.camera.any“ melden.
• MÜSSEN eine Auflösung von mindestens 2 Megapixeln haben.
• Der Kameratreiber sollte entweder einen Hardware- oder einen Software-Autofokus implementiert haben (für die Anwendungssoftware transparent).
• KANN Hardware mit fester Brennweite oder erweiterter Schärfentiefe haben.
• Kann einen Blitz enthalten. Wenn die Kamera einen Blitz hat, darf die Blitzlampe NICHT leuchten, während eine Instanz von android.hardware.Camera.PreviewCallback auf einer Kameravorschauoberfläche registriert ist, es sei denn, die Anwendung hat den Blitz explizit aktiviert, indem sie die Attribute FLASH_MODE_AUTO oder FLASH_MODE_ON eines Camera.Parameters-Objekts aktiviert hat. 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

Geräteimplementierungen KÖNNEN eine Frontkamera enthalten. Wenn eine Geräteimplementierung mindestens eine nach vorne gerichtete Kamera enthält, gilt Folgendes:

• MÜSSEN die Funktions-Flags „android.hardware.camera.any“ und „android.hardware.camera.front“ melden.
• MÜSSEN eine Auflösung von mindestens VGA (640 × 480 Pixel) haben.
• Die Frontkamera darf NICHT als Standard für die Camera API verwendet werden. Die Kamera API in Android unterstützt speziell Frontkameras. Geräteimplementierungen dürfen die API NICHT so konfigurieren, dass eine Frontkamera als Standard-Rückkamera behandelt wird, auch wenn es sich um die einzige Kamera auf dem Gerät handelt.
• KANN Funktionen wie Autofokus und Blitz enthalten, die für Rückkameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.
• Der von einer App in einer Kameravorschau angezeigte Stream MUSS horizontal gespiegelt (d.h. gedreht) werden:
  • Wenn die Geräteimplementierung vom Nutzer gedreht werden kann (z. B. automatisch über einen Beschleunigungsmesser oder manuell über die Nutzereingabe), muss die Kameravorschau horizontal gespiegelt werden, bezogen auf die aktuelle Ausrichtung des Geräts.
  • Wenn die aktuelle Anwendung ausdrücklich die Drehung des Kameradisplays über einen Aufruf der Methode android.hardware.Camera.setDisplayOrientation()[Resources, 90] angefordert hat, MUSS die Kameravorschau horizontal gespiegelt werden, bezogen auf die von der Anwendung angegebene Ausrichtung.
  • Andernfalls MUSS die Vorschau entlang der Standardhorizontalachse des Geräts gespiegelt werden.
• Das Bild, das in der Postview angezeigt wird, MUSS auf die gleiche Weise gespiegelt werden wie der Bildstream der Kameravorschau. Wenn die Geräteimplementierung keine Postview-Daten unterstützt, gilt diese Anforderung natürlich nicht.
• Die endgültig aufgenommenen Standbilder oder Videostreams, die an die Anwendungs-Callbacks zurückgegeben oder im Medienspeicher gespeichert werden, DÜRFEN NICHT gespiegelt werden.

7.5.3. Externe Kamera

Geräteimplementierungen mit USB-Hostmodus können die Unterstützung einer externen Kamera umfassen, die über den USB-Anschluss verbunden wird. Wenn ein Gerät eine externe Kamera unterstützt, gilt Folgendes:

• MÜSSEN die Plattformfunktionen „android.hardware.camera.external“ und „android.hardware.camera.any“ deklarieren.
• MUSS USB Video Class (UVC 1.0 oder höher) unterstützen.
• Unter Umständen wird die Nutzung mehrerer Kameras unterstützt.

Die Unterstützung der Videokomprimierung (z. B. MJPEG) wird EMPFOHLEN, um die Übertragung von hochwertigen, nicht codierten Streams (d. h. Roh- oder unabhängig komprimierte Bildstreams) zu ermöglichen. Kamerabasierte Videocodierung wird MÖGLICHERWEISE unterstützt. In diesem Fall MUSS die Geräteimplementierung gleichzeitig auf einen uncodierten/ MJPEG-Stream (QVGA oder höhere Auflösung) zugreifen können.

7.5.4. Verhalten der Camera API

Android bietet zwei API-Pakete für den Zugriff auf die Kamera. Die neuere android.hardware.camera2 API stellt der App eine Kamerasteuerung auf niedriger Ebene zur Verfügung, einschließlich effizienter Zero-Copy-Burst-/Streaming-Abläufe und Frames-spezifischer Einstellungen für Belichtung, Verstärkung, Weißabgleich, Farbkonvertierung, Rauschunterdrückung, Schärfung und mehr.

Das ältere API-Paket „android.hardware.Camera“ ist in Android 5.0 als veraltet gekennzeichnet. Da es jedoch weiterhin für Apps verfügbar sein sollte, müssen Android-Geräteimplementierungen die API wie in diesem Abschnitt und im Android SDK beschrieben weiterhin unterstützen.

Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs für alle verfügbaren Kameras implementieren:

• Wenn eine Anwendung noch nie android.hardware.Camera.Parameters.setPreviewFormat(int) aufgerufen hat, MUSS das Gerät android.hardware.PixelFormat.YCbCr_420_SP für Vorschaudaten verwenden, die an Anwendungs-Callbacks übergeben werden.
• Wenn eine Anwendung eine Instanz von android.hardware.Camera.PreviewCallback registriert und das System die Methode onPreviewFrame() aufruft, wenn das Vorschauformat YCbCr_420_SP ist, müssen die Daten in den an onPreviewFrame() übergebenen Bytes im NV21-Codierungsformat vorliegen. Das heißt, NV21 MUSS der Standard sein.
• Für android.hardware.Camera müssen Geräteimplementierungen das YV12-Format (wie durch die Konstante android.graphics.ImageFormat.YV12 angegeben) für Kameravorschauen sowohl für Front- als auch für Rückkameras unterstützen. Der Hardware-Videoencoder und die Kamera können beliebige native Pixelformate verwenden, aber die Geräteimplementierung MUSS die Umwandlung in YV12 unterstützen.
• Für android.hardware.camera2 müssen Geräteimplementierungen die Formate android.hardware.ImageFormat.YUV_420_888 und android.hardware.ImageFormat.JPEG als Ausgänge über die android.media.ImageReader API unterstützen.

Geräteimplementierungen MÜSSEN die vollständige Camera API implementieren, die in der Android SDK-Dokumentation [Ressourcen, 91] enthalten ist, unabhängig davon, ob das Gerät einen Hardware-Autofokus oder andere Funktionen hat. Kameras ohne Autofokus MÜSSEN beispielsweise alle registrierten Instanzen von android.hardware.Camera.AutoFocusCallback aufrufen, auch wenn dies für eine Kamera ohne Autofokus keine Relevanz hat. Dies gilt auch für Frontkameras. Auch wenn die meisten Frontkameras keinen Autofokus unterstützen, müssen die API-Callbacks wie beschrieben „gefaket“ werden.

Geräteimplementierungen MÜSSEN jeden Parameternamen erkennen und berücksichtigen, der in der Klasse „android.hardware.Camera.Parameters“ als Konstante definiert ist, sofern die zugrunde liegende Hardware die Funktion unterstützt. Wenn die Gerätehardware eine Funktion nicht unterstützt, muss sich die API wie dokumentiert verhalten. Geräteimplementierungen dürfen Stringkonstanten, die an die Methode android.hardware.Camera.setParameters() übergeben werden, nur dann berücksichtigen oder erkennen, wenn sie als Konstanten in android.hardware.Camera.Parameters dokumentiert sind. Das bedeutet, dass Geräteimplementierungen alle Standardkameraparameter unterstützen MÜSSEN, sofern die Hardware dies zulässt, und KEINE benutzerdefinierten Kameraparametertypen unterstützen DÜRFEN. Geräteimplementierungen, die die Bildaufnahme mit HDR-Bildgebungstechniken (High Dynamic Range) unterstützen, MÜSSEN beispielsweise den Kameraparameter „Camera.SCENE_MODE_HDR“ [Ressourcen, 92] unterstützen.

Da nicht alle Geräteimplementierungen alle Funktionen der android.hardware.camera2 API vollständig unterstützen können, MÜSSEN Geräteimplementierungen die richtige Unterstützungsstufe mit der Eigenschaft „android.info.supportedHardwareLevel“ melden, wie im Android SDK beschrieben [Ressourcen, 93], und die entsprechenden Framework-Funktions-Flags [Ressourcen, 94].

Geräteimplementierungen MÜSSEN auch die einzelnen Kamerafunktionen von android.hardware.camera2 über die Eigenschaft „android.request.availableCapabilities“ angeben und die entsprechenden Feature-Flags deklarieren [Ressourcen, 94]. Ein Gerät muss das Feature-Flag definieren, wenn eines der angeschlossenen Kamerageräte die Funktion unterstützt.

Geräteimplementierungen MÜSSEN die Intent „Camera.ACTION_NEW_PICTURE“ senden, wenn ein neues Bild mit der Kamera aufgenommen und der Eintrag des Bildes dem Medienspeicher hinzugefügt wurde.

Geräteimplementierungen MÜSSEN den Intent „Camera.ACTION_NEW_VIDEO“ senden, wenn ein neues Video von der Kamera aufgenommen und der Eintrag des Bildes dem Medienspeicher hinzugefügt wurde.

7.5.5. Kameraausrichtung

Sowohl die Front- als auch die Rückkamera (falls vorhanden) MÜSSEN so ausgerichtet sein, dass die lange Dimension der Kamera mit der langen Dimension des Displays übereinstimmt. Das bedeutet, dass die Kameras Bilder im Querformat aufnehmen MÜSSEN, wenn das Gerät im Querformat gehalten wird. Das gilt unabhängig von der natürlichen Ausrichtung des Geräts, also sowohl für Geräte, die hauptsächlich im Querformat als auch im Hochformat verwendet werden.

7.6. Arbeitsspeicher und Datenspeicher

7.6.1. Mindestarbeitsspeicher und Mindestspeicherplatz

Der für den Kernel und den Userspace bei Geräteimplementierungen verfügbare Arbeitsspeicher MUSS mindestens den in der folgenden Tabelle angegebenen Mindestwerten entsprechen. (Definitionen für Bildschirmgröße und ‑dichte finden Sie unter Abschnitt 7.1.1.)

Dichte und Bildschirmgröße	32-Bit-Gerät	64-Bit-Gerät
Android-Smartwatches (aufgrund kleinerer Bildschirme)	416 MB	Nicht zutreffend
280 dpi oder weniger auf kleinen/normalen Bildschirmen mdpi oder niedriger auf großen Bildschirmen ldpi oder niedriger auf sehr großen Bildschirmen	424 MB	704 MB
xhdpi oder höher auf kleinen/normalen Displays hdpi oder höher auf großen Bildschirmen mdpi oder höher auf sehr großen Bildschirmen	512 MB	832 MB
400 dpi oder höher auf kleinen/normalen Bildschirmen XHDPI oder höher auf großen Bildschirmen tvdpi oder höher auf sehr großen Bildschirmen	896 MB	1.280 MB
560 dpi oder höher auf kleinen/normalen Bildschirmen 400 dpi oder höher auf großen Bildschirmen XHDPI oder höher auf extra großen Bildschirmen	1.344 MB	1.824 MB

Die Mindestspeicherwerte MÜSSEN zusätzlich zu dem Arbeitsspeicherplatz angegeben werden, der bereits für Hardwarekomponenten wie Radio, Video usw. reserviert ist, die nicht vom Kernel verwaltet werden.

Bei Geräteimplementierungen mit weniger als 512 MB Arbeitsspeicher, der für den Kernel und den Userspace verfügbar ist, MUSS für ActivityManager.isLowRamDevice() der Wert „true“ zurückgegeben werden, es sei denn, es handelt sich um eine Android-Smartwatch.

Android TV-Geräte MÜSSEN mindestens 5 GB und andere Geräteimplementierungen MÜSSEN mindestens 1,5 GB nichtflüchtigen Speicher für private Daten der Anwendung haben. Die Partition „/data“ muss also mindestens 5 GB für Android TV-Geräte und mindestens 1, 5 GB für andere Geräteimplementierungen haben. Bei Geräten mit Android-Betriebssystem wird dringend empfohlen, mindestens 3 GB nichtflüchtigen Speicher für private Anwendungsdaten zu verwenden, damit ein Upgrade auf zukünftige Plattformversionen möglich ist.

Die Android APIs enthalten einen Downloadmanager, den Anwendungen zum Herunterladen von Datendateien VERWENDEN KÖNNEN [Ressourcen, 95]. Die Geräteimplementierung des Download-Managers MUSS in der Lage sein, einzelne Dateien mit einer Größe von mindestens 100 MB an den standardmäßigen Speicherort „Cache“ herunterzuladen.

7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen

Geräteimplementierungen MÜSSEN gemeinsamen Speicher für Anwendungen anbieten, der oft auch als „freigegebener externer Speicher“ bezeichnet wird.

Geräteimplementierungen MÜSSEN standardmäßig mit freigegebenem Speicher konfiguriert sein. Wenn der freigegebene Speicher nicht über den Linux-Pfad „/sdcard“ bereitgestellt wird, MUSS das Gerät einen Linux-Symbollink von „/sdcard“ zum tatsächlichen Bereitstellungspunkt enthalten.

Geräteimplementierungen KÖNNEN Hardware für von Nutzern zugänglichen Wechselspeicher haben, z. B. einen SD-Kartensteckplatz (Secure Digital). Wenn dieser Slot verwendet wird, um die Anforderung an den freigegebenen Speicher zu erfüllen, gilt für die Geräteimplementierung Folgendes:

• Es MUSS eine Toast- oder Pop-up-Benutzeroberfläche implementiert werden, die den Nutzer warnt, wenn keine SD-Karte vorhanden ist.
• MUSS eine FAT-formatierte SD-Karte mit einer Größe von mindestens 1 GB enthalten ODER auf der Verpackung und in anderen zum Zeitpunkt des Kaufs verfügbaren Materialien muss angegeben sein, dass die SD-Karte separat erworben werden muss.
• Die SD-Karte MUSS standardmäßig bereitgestellt werden.

Alternativ KÖNNEN Geräteimplementierungen internen (nicht entfernbaren) Speicher als freigegebenen Speicher für Apps zuweisen, die im Upstream-Android-Open-Source-Projekt enthalten sind. Geräteimplementierungen SOLLTEN diese Konfiguration und Softwareimplementierung verwenden. Wenn bei einer Geräteimplementierung der interne (nicht entfernbare) Speicherplatz zur Erfüllung der Anforderung an den freigegebenen Speicher verwendet wird, dieser Speicherplatz aber möglicherweise den privaten Daten der Anwendung gemeinsam genutzt wird, muss er mindestens 1 GB groß sein und unter „/sdcard“ bereitgestellt werden. Andernfalls muss „/sdcard“ ein symbolischer Link zum physischen Speicherort sein.

Bei Geräteimplementierungen MUSS die Berechtigung „android.permission.WRITE_EXTERNAL_STORAGE“ wie dokumentiert für diesen freigegebenen Speicher erzwungen werden. Andernfalls MUSS der freigegebene Speicher für jede Anwendung beschreibbar sein, die diese Berechtigung erhält.

Bei Geräteimplementierungen mit mehreren freigegebenen Speicherpfaden (z. B. einem SD-Kartenslot und einem freigegebenen internen Speicher) dürfen nur vorinstallierte und privilegierte Android-Apps mit der Berechtigung WRITE_EXTERNAL_STORAGE auf den sekundären externen Speicher schreiben, es sei denn, sie schreiben in ihre paketspezifischen Verzeichnisse oder in den URI, der durch das Auslösen der ACTION_OPEN_DOCUMENT_TREE-Intent zurückgegeben wird.

Bei Geräteimplementierungen sollten Inhalte aus beiden Speicherpfaden jedoch transparent über den Medien-Scandienst von Android und android.provider.MediaStore bereitgestellt werden.

Unabhängig von der verwendeten Form des freigegebenen Speichers muss die Geräteimplementierung einen USB-Anschluss mit Unterstützung des USB-Peripheriemodus haben, um über einen Hostcomputer auf den Inhalt des freigegebenen Speichers zugreifen zu können. Geräteimplementierungen KÖNNEN USB-Massenspeicher verwenden, MÜSSEN aber das Media-Transfer-Protokoll verwenden, um diese Anforderung zu erfüllen. Wenn die Geräteimplementierung das Media Transfer Protocol unterstützt, gilt Folgendes:

• MÜSSEN mit dem Referenz-Android-MTP-Host, Android File Transfer, kompatibel sein [Ressourcen, 96].
• MÜSSEN eine USB-Geräteklasse von 0x00 melden.
• MÜSSEN den Namen „MTP“ für die USB-Schnittstelle angeben.

7.7. USB

Geräteimplementierungen MÜSSEN den USB-Peripheriegerätemodus und den USB-Hostmodus unterstützen.

Wenn eine Geräteimplementierung einen USB-Anschluss mit Peripheriemodus enthält:

• Der Anschluss MUSS mit einem USB-Host mit einem Standard-USB-Typ-A- oder -Typ-C-Anschluss verbunden werden können.
• Der Port sollte den USB-Formfaktor Micro-B, Micro-AB oder Typ-C haben. Wir EMPFEHLEN dringend, diese Anforderungen für bestehende und neue Android-Geräte zu erfüllen, damit sie auf zukünftige Plattformversionen umgestellt werden können.
• Der Anschluss sollte sich entweder an der Unterseite des Geräts befinden (bei normaler Ausrichtung) oder die Bildschirmdrehung für alle Apps (einschließlich des Startbildschirms) ermöglichen, damit das Display korrekt dargestellt wird, wenn sich das Gerät mit dem Anschluss nach unten befindet. Für bestehende und neue Android-Geräte wird DRINGEND empfohlen, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen umgestellt werden können.
• Es MUSS die Android Open Accessory API (AOA) und die Spezifikation gemäß der Dokumentation des Android SDK implementieren. Bei einem Android-Handheld-Gerät MUSS die AOA API implementiert sein. Geräteimplementierungen, die die AOA-Spezifikation implementieren:
  • MÜSSEN die Unterstützung für die Hardwarefunktion „android.hardware.usb.accessory“ angeben [Ressourcen, 97].
  • Die USB-Audioklasse muss gemäß der Dokumentation des Android SDK implementiert werden [Ressourcen, 98].
• Es MUSS die Unterstützung für einen Stromverbrauch von 1,5 A während HS-Chirp und -Traffic implementieren, wie in der USB Battery Charging Specification, Revision 1.2 [Resources, 99] angegeben. Für bestehende und neue Android-Geräte wird dringend empfohlen, diese Anforderungen zu erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt werden können.
• Der Wert von „iSerialNumber“ im USB-Standardgeräte-Descriptor MUSS mit dem Wert von „android.os.Build.SERIAL“ übereinstimmen.

Wenn eine Geräteimplementierung einen USB-Anschluss mit Hostmodus enthält, gilt Folgendes:

• Es sollte ein USB-Typ-C-Anschluss verwendet werden, wenn die Geräteimplementierung USB 3.1 unterstützt.
• Es kann ein nicht standardmäßiger Port-Formfaktor verwendet werden. In diesem Fall MUSS das Gerät jedoch mit einem oder mehreren Kabeln geliefert werden, die den Anschluss an einen Standard-USB-Typ-A- oder -Typ-C-Anschluss ermöglichen.
• Es kann ein Micro-AB-USB-Anschluss verwendet werden. In diesem Fall MUSS ein Kabel oder mehrere Kabel zum Anschließen an einen Standard-USB-Anschluss vom Typ A oder Typ C mitgeliefert werden.
• Es wird dringend empfohlen, die USB-Audioklasse gemäß der Dokumentation des Android SDK [Ressourcen, 98] zu implementieren.
• Die Android USB Host API muss gemäß der im Android SDK dokumentierten Anleitung implementiert werden und die Unterstützung der Hardwarefunktion „android.hardware.usb.host“ muss erklärt werden [Ressourcen, 100].
• MÜSSEN den Ausgangsstrombereich von 1,5 A bis 5 A des Downstream-Ladeanschlusses unterstützen, wie in der USB-Spezifikation für das Laden von Akkus, Version 1.2 [Ressourcen, 99] angegeben.

7.8. Audio

7.8.1. Mikrofon

Bei Geräteimplementierungen kann ein Mikrofon UNTER UMSTÄNDEN weggelassen werden. Wenn in einer Geräteimplementierung jedoch kein Mikrofon vorhanden ist, darf die Funktion „android.hardware.microphone“ NICHT gemeldet werden und die Audioaufzeichnungs-API MUSS gemäß Abschnitt 7 mindestens als No-Op implementiert werden. Geräteimplementierungen mit Mikrofon:

• Die Funktion „android.hardware.microphone“ MUSS als konstant gemeldet werden.
• MÜSSEN die Anforderungen an Audioaufnahmen in Abschnitt 5.4 erfüllen
• MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen

7.8.2. Audioausgabe

Geräteimplementierungen mit Lautsprecher oder mit einem Audio-/Multimedia-Ausgabeanschluss für ein Audioausgabegerät wie ein Headset oder einen externen Lautsprecher:

• Die Funktion „android.hardware.audio.output“ MUSS als Konstante gemeldet werden.
• MÜSSEN die Anforderungen an die Audiowiedergabe in Abschnitt 5.5 erfüllen.
• MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.

Wenn eine Geräteimplementierung keinen Lautsprecher oder Audioausgang hat, darf die Funktion „android.hardware.audio“ NICHT gemeldet werden und die APIs für die Audioausgabe MÜSSEN mindestens als No-Ops implementiert werden.

Die Implementierung von Android-Smartwatches KANN, sollte aber KEINE Audioausgabe haben. Andere Arten von Android-Geräten MÜSSEN jedoch eine Audioausgabe haben und android.hardware.audio.output angeben.

7.8.2.1. Analoge Audioports

Damit die Kopfhörer und andere Audiozubehörteile mit dem 3,5-mm-Audiostecker im Android-System kompatibel sind [Ressourcen, 101], muss mindestens einer der Audioanschlüsse einer Geräteimplementierung, die einen oder mehrere analoge Audioanschlüsse enthält, eine 4-polige 3,5-mm-Audiobuchse sein. Wenn eine Geräteimplementierung eine 3,5‑mm-Audiobuchse mit vier Adern hat, gilt Folgendes:

• Müssen die Audiowiedergabe über Stereokopfhörer und Stereoheadsets mit Mikrofon unterstützen und sollten die Audioaufnahme über Stereoheadsets mit Mikrofon unterstützen.
• MÜSSEN TRRS-Audiostecker mit der CTIA-Belegung unterstützen und SOLLTEN Audiostecker mit der OMTP-Belegung unterstützen.
• MUSS die Erkennung des Mikrofons des angeschlossenen Audiozubehörs unterstützen, wenn die Geräteimplementierung ein Mikrofon unterstützt, und die Aktion „android.intent.action.HEADSET_PLUG“ mit dem zusätzlichen Wert „microphone“ als „1“ senden.
• MÜSSEN die Erkennung und Zuordnung zu den Schlüsselcodes für die folgenden drei Bereiche der äquivalenten Impedanz zwischen dem Mikrofon und den Erdleitern am Audiostecker unterstützen:
  • 70 Ohm oder weniger: KEYCODE_HEADSETHOOK
  • 210–290 Ohm: KEYCODE_VOLUME_UP
  • 360–680 Ohm: KEYCODE_VOLUME_DOWN
• MÜSSEN die Erkennung und Zuordnung zum Schlüsselcode für den folgenden Bereich der äquivalenten Impedanz zwischen den Mikrofon- und Erdleitern am Audiostecker unterstützen:
  • 110–180 Ohm : KEYCODE_VOICE_ASSIST
• MUSS ACTION_HEADSET_PLUG beim Einstecken des Steckers auslösen, aber erst, nachdem alle Kontakte am Stecker ihre entsprechenden Segmente an der Buchse berühren.
• MÜSSEN mindestens 150 mV ± 10% der Ausgangsspannung bei einer Lautsprecherimpedanz von 32 Ohm liefern.
• Die Mikrofonvorspannung muss zwischen 1,8 V und 2,9 V liegen.

8. Leistungskompatibilität

Einige Mindestleistungskriterien sind entscheidend für die Nutzerfreundlichkeit und wirken sich auf die Grundannahmen aus, die Entwickler bei der Entwicklung einer App haben. Android-Smartwatch-Geräte MÜSSEN und andere Arten von Geräteimplementierungen SOLLTEN die folgenden Kriterien erfüllen:

8.1. Einheitliche Nutzererfahrung

Geräteimplementierungen MÜSSEN eine flüssige Benutzeroberfläche bieten, indem eine gleichbleibende Framerate und Reaktionszeiten für Anwendungen und Spiele sichergestellt werden. Geräteimplementierungen MÜSSEN die folgenden Anforderungen erfüllen:

• Konstante Frame-Latenz Eine ungleichmäßige Frame-Latenz oder eine Verzögerung beim Rendern von Frames darf nicht häufiger als 5 mal pro Sekunde auftreten und sollte unter 1 Frame pro Sekunde liegen.
• Latenz der Benutzeroberfläche Geräteimplementierungen MÜSSEN eine geringe Latenz gewährleisten, indem eine Liste mit 10.000 Listeneinträgen gemäß der Android Compatibility Test Suite (CTS) in weniger als 36 Sekunden gescrollt wird.
• Aufgabenwechsel Wenn mehrere Anwendungen gestartet wurden, darf das erneute Starten einer bereits laufenden Anwendung nach dem Start weniger als eine Sekunde dauern.

8.2. Leistung des Datei-E/A-Zugriffs

Geräteimplementierungen MÜSSEN für Lese- und Schreibvorgänge eine konsistente Leistung beim Zugriff auf interne Speicherdateien gewährleisten.

• Sequenzielles Schreiben Geräteimplementierungen MÜSSEN eine sequenzielle Schreibleistung von mindestens 5 MB/s für eine 256 MB große Datei mit einem 10 MB großen Schreibpuffer gewährleisten.
• Zufallsschreiben. Geräteimplementierungen MÜSSEN eine zufällige Schreibleistung von mindestens 0,5 MB/s für eine 256 MB große Datei mit einem 4 KB großen Schreibpuffer gewährleisten.
• Sequenzielle Lese Geräteimplementierungen MÜSSEN eine sequenzielle Leseleistung von mindestens 15 MB/s für eine 256 MB große Datei mit einem 10 MB großen Schreibpuffer gewährleisten.
• Zufallslesevorgang Geräteimplementierungen MÜSSEN eine zufällige Leseleistung von mindestens 3,5 MB/s für eine 256 MB große Datei mit einem 4 KB großen Schreibpuffer gewährleisten.

9. Kompatibilität des Sicherheitsmodells

Geräteimplementierungen MÜSSEN ein Sicherheitsmodell implementieren, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument „Sicherheit und Berechtigungen“ in den APIs [Ressourcen, 102] in der Android-Entwicklerdokumentation definiert. Geräteimplementierungen MÜSSEN die Installation selbst signierter Anwendungen unterstützen, ohne dass zusätzliche Berechtigungen/Zertifikate von Drittanbietern/Behörden erforderlich sind. Insbesondere MÜSSEN kompatible Geräte die in den folgenden Unterabschnitten beschriebenen Sicherheitsmechanismen unterstützen.

9.1. Berechtigungen

Geräteimplementierungen MÜSSEN das Android-Berechtigungsmodell gemäß der Android-Entwicklerdokumentation unterstützen [Ressourcen, 102]. Insbesondere müssen Implementierungen jede Berechtigung erzwingen, die in der SDK-Dokumentation beschrieben ist. Keine Berechtigungen dürfen ausgelassen, geändert oder ignoriert werden. Implementierungen KÖNNEN zusätzliche Berechtigungen hinzufügen, sofern die neuen Berechtigungs-ID-Strings nicht zum Namespace „android.*“ gehören.

9.2. UID und Prozessisolierung

Geräteimplementierungen MÜSSEN das Android-Sandbox-Modell für Anwendungen unterstützen, bei dem jede Anwendung als eindeutige UID im Unix-Stil und in einem separaten Prozess ausgeführt wird. Geräteimplementierungen MÜSSEN das Ausführen mehrerer Anwendungen mit derselben Linux-Nutzer-ID unterstützen, sofern die Anwendungen ordnungsgemäß signiert und erstellt sind, wie in der Referenz zu Sicherheit und Berechtigungen [Ressourcen, 102] definiert.

9.3. Dateisystemberechtigungen

Geräteimplementierungen MÜSSEN das Modell für Berechtigungen für den Dateizugriff von Android unterstützen, wie in der Referenz zu Sicherheit und Berechtigungen [Ressourcen, 102] definiert.

9.4. Alternative Ausführungsumgebungen

Geräteimplementierungen KÖNNEN Laufzeitumgebungen enthalten, in denen Anwendungen mit einer anderen Software oder Technologie als dem Dalvik-Ausführformat oder nativem Code ausgeführt werden. Solche alternativen Ausführungsumgebungen dürfen jedoch nicht das Android-Sicherheitsmodell oder die Sicherheit installierter Android-Anwendungen gefährden, wie in diesem Abschnitt beschrieben.

Alternative Laufzeiten MÜSSEN selbst Android-Anwendungen sein und dem standardmäßigen Android-Sicherheitsmodell entsprechen, wie in Abschnitt 9 beschrieben.

Alternativlaufzeiten dürfen KEIN Zugriff auf Ressourcen gewährt werden, die durch Berechtigungen geschützt sind, die nicht über den Mechanismus <uses-permission> in der AndroidManifest.xml-Datei der Laufzeit angefordert wurden.

Alternative Laufzeiten DÜRFEN Anwendungen nicht die Nutzung von Funktionen erlauben, die durch Android-Berechtigungen geschützt sind, die auf Systemanwendungen beschränkt sind.

Alternative Laufzeiten MÜSSEN dem Android-Sandbox-Modell entsprechen. Insbesondere gilt Folgendes für alternative Laufzeiten:

• Apps sollten über den Paketmanager in separaten Android-Sandboxes installiert werden (z. B. Linux-Nutzer-IDs).
• KANN eine einzelne Android-Sandbox bereitstellen, die von allen Anwendungen gemeinsam genutzt wird, die die alternative Laufzeit verwenden.
• und installierte Anwendungen, die eine alternative Laufzeit verwenden, dürfen die Sandbox einer anderen auf dem Gerät installierten App NICHT wiederverwenden, es sei denn, dies erfolgt über die standardmäßigen Android-Mechanismen für die gemeinsame Nutzer-ID und das Signaturzertifikat.
• Darf nicht mit den Sandboxes anderer Android-Anwendungen gestartet werden, ihnen keinen Zugriff gewähren und ihnen keinen Zugriff gewährt werden.
• Darf NICHT mit Berechtigungen des Superusers (root) oder einer anderen Nutzer-ID gestartet werden, NICHT Berechtigungen des Superusers (root) oder einer anderen Nutzer-ID erhalten und NICHT anderen Anwendungen Berechtigungen des Superusers (root) oder einer anderen Nutzer-ID gewähren.

Die .apk-Dateien alternativer Laufzeiten KÖNNEN im System-Image einer Geräteimplementierung enthalten sein, MÜSSEN aber mit einem anderen Schlüssel signiert sein als der, der zum Signieren anderer Anwendungen verwendet wurde, die in der Geräteimplementierung enthalten sind.

Bei der Installation von Anwendungen MÜSSEN alternative Laufzeiten die Nutzereinwilligung für die von der Anwendung verwendeten Android-Berechtigungen einholen. Wenn eine Anwendung eine Geräteressource verwenden muss, für die es eine entsprechende Android-Berechtigung gibt (z. B. Kamera, GPS usw.), muss die alternative Laufzeit den Nutzer darüber informieren, dass die Anwendung auf diese Ressource zugreifen kann. Wenn die Laufzeitumgebung die Anwendungsfunktionen nicht auf diese Weise aufzeichnet, MUSS die Laufzeitumgebung bei der Installation einer Anwendung, die diese Laufzeit verwendet, alle Berechtigungen auflisten, die der Laufzeit selbst zugewiesen sind.

9.5. Unterstützung mehrerer Nutzer

Android unterstützt mehrere Nutzer und bietet eine vollständige Nutzerisolierung [Ressourcen, 103]. Bei Geräteimplementierungen können mehrere Nutzer aktiviert werden. Wenn dies der Fall ist, MÜSSEN sie jedoch die folgenden Anforderungen für die Unterstützung mehrerer Nutzer erfüllen [Ressourcen, 104]:

• Geräteimplementierungen, die das Feature-Flag „android.hardware.telephony“ nicht deklarieren, MÜSSEN eingeschränkte Profile unterstützen. Mit dieser Funktion können Geräteeigentümer zusätzliche Nutzer und deren Funktionen auf dem Gerät verwalten. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen in den Apps verwalten, die in diesen Umgebungen verfügbar sind.
• Geräteimplementierungen, die das Feature-Flag „android.hardware.telephony“ deklarieren, dürfen KEINE eingeschränkten Profile unterstützen, sondern MÜSSEN der AOSP-Implementierung von Steuerelementen entsprechen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen oder zu deaktivieren.
• Bei Geräteimplementierungen MUSS für jeden Nutzer ein Sicherheitsmodell implementiert werden, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument „Sicherheit und Berechtigungen“ in den APIs definiert [Ressourcen, 102].
• Geräteimplementierungen KÖNNEN das Erstellen von Nutzern und verwalteten Profilen über die APIs von android.app.admin.DevicePolicyManager unterstützen. Wenn dies unterstützt wird, MUSS die Plattformfunktionsflagge android.software.managed_users deklariert werden.
• Bei Geräteimplementierungen, die das Feature-Flag „android.software.managed_users“ deklarieren, MUSS das Upstream-AOSP-Symbolsymbol verwendet werden, um die verwalteten Anwendungen und andere Symbol-UI-Elemente wie „Letzte“ und „Benachrichtigungen“ darzustellen.
• Jede Nutzerinstanz auf einem Android-Gerät MUSS separate und isolierte externe Speicherverzeichnisse haben. Bei Geräteimplementierungen KÖNNEN Daten mehrerer Nutzer auf demselben Volume oder Dateisystem gespeichert werden. Die Geräteimplementierung MUSS jedoch dafür sorgen, dass Anwendungen, die einem bestimmten Nutzer gehören und in seinem Namen ausgeführt werden, keine Daten eines anderen Nutzers auflisten, lesen oder darauf schreiben können. Hinweis: Über Wechselmedien wie SD-Kartensteckplätze kann ein Nutzer über einen Host-PC auf die Daten eines anderen Nutzers zugreifen. Aus diesem Grund MÜSSEN Geräteimplementierungen, die für die primären externen Speicher-APIs Wechselmedien verwenden, den Inhalt der SD-Karte verschlüsseln, wenn die Mehrfachnutzung aktiviert ist. Dazu muss ein Schlüssel verwendet werden, der nur auf nicht entfernbaren Medien gespeichert ist, auf die nur das System zugreifen kann. Da die Medien dadurch für einen Host-PC unlesbar werden, müssen Geräteimplementierungen zu MTP oder einem ähnlichen System wechseln, um Host-PCs Zugriff auf die Daten des aktuellen Nutzers zu gewähren. Daher KÖNNEN, aber sollten nicht, die Geräteimplementierungen die Mehrfachnutzung aktivieren, wenn sie Wechselmedien [Ressourcen, 105] als primären externen Speicher verwenden.

9.6. Warnung zu Premium-SMS

Android unterstützt die Warnung von Nutzern vor ausgehenden Premium-SMS [Ressourcen, 106] . Premium-SMS sind Nachrichten, die an einen bei einem Mobilfunkanbieter registrierten Dienst gesendet werden und für den Nutzer möglicherweise kostenpflichtig sind. Bei Geräteimplementierungen, die die Unterstützung für android.hardware.telephony angeben, MÜSSEN Nutzer gewarnt werden, bevor eine SMS an Nummern gesendet wird, die durch reguläre Ausdrücke in der Datei „/data/misc/sms/codes.xml“ auf dem Gerät identifiziert werden. Das Upstream-Android-Open-Source-Projekt bietet eine Implementierung, die diese Anforderung erfüllt.

9.7. Kernel-Sicherheitsfunktionen

Die Android-Sandbox enthält Funktionen, die das MAC-System (Mandatory Access Control) von Security-Enhanced Linux (SELinux) und andere Sicherheitsfunktionen im Linux-Kernel nutzen können. SELinux oder andere Sicherheitsfunktionen, die unter dem Android-Framework implementiert sind:

• Die Kompatibilität mit vorhandenen Anwendungen MUSS erhalten bleiben.
• Darf KEINE sichtbare Benutzeroberfläche haben, wenn ein Sicherheitsverstoß erkannt und erfolgreich blockiert wurde. Darf EINE sichtbare Benutzeroberfläche haben, wenn ein nicht blockierter Sicherheitsverstoß auftritt, der zu einer erfolgreichen Ausnutzung führt.
• Darf NICHT vom Nutzer oder Entwickler konfiguriert werden.

Wenn eine API zur Konfiguration von Richtlinien für eine Anwendung freigegeben wird, die sich auf eine andere Anwendung auswirken kann (z. B. eine Device Administration API), darf die API KEINE Konfigurationen zulassen, die die Kompatibilität beeinträchtigen.

Geräte MÜSSEN SELinux oder ein vergleichbares System zur obligatorischen Zugriffssteuerung implementieren, wenn ein anderer Kernel als Linux verwendet wird, und die folgenden Anforderungen erfüllen, die von der Referenzimplementierung im Upstream-Android-Open-Source-Projekt erfüllt werden.

Geräteimplementierungen:

• MÜSSEN eine SELinux-Richtlinie unterstützen, mit der der SELinux-Modus pro Domain festgelegt werden kann, und MÜSSEN alle Domains im Erzwingungsmodus konfigurieren. Domains im permissiven Modus sind nicht zulässig, einschließlich geräte-/anbieterspezifischer Domains.
• SOLLTE die Richtlinie aus der Datei „/sepolicy“ auf dem Gerät laden.
• Die Neverallow-Regeln in der SEPolicy-Datei, die im Upstream-Android Open Source Project (AOSP) bereitgestellt wird, dürfen NICHT geändert, weggelassen oder ersetzt werden. Die Richtlinie MUSS mit allen vorhandenen Neverallow-Regeln kompiliert werden, sowohl für AOSP-SELinux-Domains als auch für geräte-/anbieterspezifische Domains.
• MÜSSEN dynamische Aktualisierungen der SELinux-Richtliniendatei unterstützen, ohne dass ein System-Image aktualisiert werden muss.

Bei Geräteimplementierungen sollte die Standard-SELinux-Richtlinie des Upstream-Android Open Source Project so lange beibehalten werden, bis die Ergänzungen zur SELinux-Richtlinie geprüft wurden. Geräteimplementierungen MÜSSEN mit dem Upstream-Android-Open-Source-Projekt kompatibel sein.

9.8. Datenschutz

Wenn das Gerät Funktionen im System implementiert, die den auf dem Display angezeigten Inhalt erfassen und/oder den auf dem Gerät wiedergegebenen Audiostream aufzeichnen, MUSS der Nutzer kontinuierlich benachrichtigt werden, wenn diese Funktion aktiviert ist und aktiv Inhalte erfasst bzw. aufzeichnet.

Wenn eine Geräteimplementierung einen Mechanismus hat, der Netzwerkdatenverkehr standardmäßig über einen Proxyserver oder ein VPN-Gateway leitet (z. B. das Vorladen eines VPN-Dienstes mit der Berechtigung „android.permission.CONTROL_VPN“), muss die Geräteimplementierung die Einwilligung des Nutzers einholen, bevor dieser Mechanismus aktiviert wird.

9.9. Datenträgervollverschlüsselung

Wenn die Geräteimplementierung einen Sperrbildschirm mit PIN (numerisch) oder PASSWORD (alphanumerisch) unterstützt, MUSS das Gerät die Volldiskoverschlüsselung der privaten Daten der Anwendung (/data-Partition) sowie der SD-Kartenpartition unterstützen, wenn diese ein permanenter, nicht entfernbarer Teil des Geräts ist [Ressourcen, 107]. Bei Geräten, die die Festplattenvollverschlüsselung unterstützen, sollte die Festplattenvollverschlüsselung nach der Ersteinrichtung immer aktiviert sein. Diese Anforderung ist für diese Version der Android-Plattform zwar als „SOLLTE“ angegeben, wird aber dringend empfohlen, da sie in zukünftigen Android-Versionen voraussichtlich in „MUSS“ geändert wird. Für die Verschlüsselung MUSS AES mit einem Schlüssel von mindestens 128 Bit und einem für die Speicherung vorgesehenen Modus verwendet werden (z. B. AES-XTS, AES-CBC-ESSIV). Der Verschlüsselungsschlüssel darf niemals unverschlüsselt in den Speicher geschrieben werden. Außer bei aktiver Nutzung sollte der Verschlüsselungsschlüssel mit dem Passcode des Sperrbildschirms mit einem langsamen Stretching-Algorithmus (z.B. PBKDF2 oder scrypt) AES-verschlüsselt werden. Wenn der Nutzer keinen Sicherheitscode für den Sperrbildschirm angegeben oder die Verwendung des Sicherheitscodes für die Verschlüsselung deaktiviert hat, sollte das System einen Standardsicherheitscode zum Verpacken des Verschlüsselungsschlüssels verwenden. Wenn das Gerät einen hardwaregestützten Schlüsselspeicher bietet, MUSS der Passwort-Stretching-Algorithmus kryptografisch an diesen Schlüsselspeicher gebunden sein. Der Verschlüsselungsschlüssel darf NICHT vom Gerät gesendet werden, auch nicht, wenn er mit dem Sicherheitscode des Nutzers und/oder einem hardwaregebundenen Schlüssel verpackt ist. Das Upstream-Android-Open-Source-Projekt bietet eine bevorzugte Implementierung dieser Funktion, die auf der Linux-Kernel-Funktion „dm-crypt“ basiert.

9.10. Verified Boot

Der verifizierte Bootmodus ist eine Funktion, die die Integrität der Gerätesoftware garantiert. Wenn eine Geräteimplementierung die Funktion unterstützt, MUSS Folgendes erfüllt sein:

• Deklarieren Sie das Plattform-Funktions-Flag „android.software.verified_boot“.
• Überprüfung bei jeder Bootreihenfolge durchführen
• Die Überprüfung beginnt mit einem Hardwareschlüssel, der als Root of Trust dient, und geht bis zur Systempartition.
• Implementieren Sie jede Phase der Überprüfung, um die Integrität und Authentizität aller Bytes in der nächsten Phase zu prüfen, bevor der Code in der nächsten Phase ausgeführt wird.
• Überprüfungsalgorithmen verwenden, die den aktuellen Empfehlungen des NIST für Hash-Algorithmen (SHA-256) und Public-Key-Größen (RSA-2048) entsprechen

Geräteimplementierungen MÜSSEN den Bootmodus mit Verifikation für die Geräteintegrität unterstützen. Diese Anforderung ist für diese Version der Android-Plattform zwar als „sollte“ gekennzeichnet, wird aber dringend empfohlen, da sie in zukünftigen Android-Versionen voraussichtlich in „muss“ geändert wird. Das Upstream-Android Open Source Project bietet eine bevorzugte Implementierung dieser Funktion, die auf der Linux-Kernel-Funktion dm-verity basiert.

10. Softwarekompatibilitätstests

Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen.

Beachten Sie jedoch, dass kein Softwaretestpaket vollständig ist. Aus diesem Grund werden Geräteimplementierer dringend aufgefordert, nur so wenige Änderungen wie möglich an der Referenz- und bevorzugten Implementierung von Android vorzunehmen, die im Android Open Source Project verfügbar ist. So wird das Risiko minimiert, dass Fehler auftreten, die Inkompatibilitäten verursachen und zu Überarbeitungen und möglichen Geräteupdates führen.

10.1. Compatibility Test Suite

Geräteimplementierungen MÜSSEN die Android Compatibility Test Suite (CTS) [Ressourcen, 108] bestehen, die im Android Open Source Project verfügbar ist. Dabei muss die finale Software auf dem Gerät verwendet werden. Außerdem sollten Geräteimplementierer die Referenzimplementierung im Android Open Source-Baum nach Möglichkeit verwenden und für Kompatibilität bei Unklarheiten im CTS und bei jeder Neuimplementierung von Teilen des Referenz-Quellcodes sorgen.

Der CTS ist für die Ausführung auf einem echten Gerät konzipiert. Wie jede Software kann auch die CTS Fehler enthalten. Die CTS-Versionen werden unabhängig von dieser Kompatibilitätsdefinition erstellt. Es können mehrere CTS-Versionen für Android 5.1 veröffentlicht werden. Geräteimplementierungen MÜSSEN die neueste CTS-Version bestehen, die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbar ist.

10.2. CTS-Verifier

Bei der Geräteimplementierung MÜSSEN alle anwendbaren Fälle im CTS-Verifier korrekt ausgeführt werden. Der CTS Verifier ist in der Compatibility Test Suite enthalten und soll von einem menschlichen Operator ausgeführt werden, um Funktionen zu testen, die nicht von einem automatisierten System getestet werden können, z. B. die ordnungsgemäße Funktion einer Kamera und von Sensoren.

Der CTS Verifier bietet Tests für viele Arten von Hardware, einschließlich optionaler Hardware. Geräteimplementierungen MÜSSEN alle Tests für die vorhandene Hardware bestehen. Wenn ein Gerät beispielsweise einen Beschleunigungsmesser hat, MUSS der Testfall für den Beschleunigungsmesser im CTS-Verifier korrekt ausgeführt werden. Testfälle für Funktionen, die in diesem Compatibility Definition Document als optional gekennzeichnet sind, KÖNNEN übersprungen oder weggelassen werden.

Auf jedem Gerät und für jeden Build MUSS der CTS-Verifier wie oben beschrieben korrekt ausgeführt werden. Da viele Builds jedoch sehr ähnlich sind, müssen Geräteimplementierer den CTS-Verifier nicht explizit auf Builds ausführen, die sich nur in unwesentlichen Punkten unterscheiden. Insbesondere bei Geräteimplementierungen, die sich von einer Implementierung, die den CTS Verifier bestanden hat, nur durch die enthaltenen Sprachen, das Branding usw. unterscheiden, kann der CTS Verifier-Test weggelassen werden.

11. Aktualisierbare Software

Geräteimplementierungen MÜSSEN einen Mechanismus zum Ersetzen der gesamten Systemsoftware enthalten. Der Mechanismus muss keine „Live-Upgrades“ ausführen. Das Gerät muss also möglicherweise neu gestartet werden.

Es kann jede Methode verwendet werden, sofern damit die gesamte auf dem Gerät vorinstallierte Software ersetzt werden kann. Beispielsweise erfüllen alle der folgenden Ansätze diese Anforderung:

• Over-the-air-Downloads (OTA) mit Offlineupdate über Neustart
• Tethering-Updates über USB von einem Host-PC
• „Offline“-Updates über einen Neustart und ein Update über eine Datei auf einem Wechseldatenträger

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

• Android Automotive-Implementierungen MÜSSEN OTA-Downloads mit Offline-Update über Neustart unterstützen.
• Alle anderen Geräteimplementierungen MÜSSEN OTA-Downloads mit Offlineupdate über einen Neustart unterstützen.

Der verwendete Updatemechanismus MUSS Updates ohne Löschen von Nutzerdaten unterstützen. Das bedeutet, dass der Aktualisierungsmechanismus private Daten der Anwendung und freigegebene Daten der Anwendung MUSS beibehalten. Die Android-Software enthält einen Updatemechanismus, der diese Anforderung erfüllt.

Bei Geräteimplementierungen, die mit Android 5.1 und höher gestartet werden, sollte der Updatemechanismus die Überprüfung unterstützen, ob das System-Image nach einem Over-the-air-Update binär mit dem erwarteten Ergebnis identisch ist. Die blockbasierte OTA-Implementierung im Upstream-Android Open Source Project, die seit Android 5.1 hinzugefügt wurde, erfüllt diese Anforderung.

Wenn nach der Veröffentlichung, aber innerhalb der angemessenen Produktlebensdauer, die in Absprache mit dem Android-Kompatibilitätsteam festgelegt wird, ein Fehler in einer Geräteimplementierung gefunden wird, der die Kompatibilität von Drittanbieteranwendungen beeinträchtigt, MUSS der Geräteimplementierer den Fehler über ein verfügbares Softwareupdate beheben, das gemäß dem gerade beschriebenen Mechanismus angewendet werden kann.

12. Änderungsprotokoll für Dokumente

Die folgende Tabelle enthält eine Zusammenfassung der Änderungen an der Definition der Kompatibilität in dieser Version.

Abschnitt	Zusammenfassung der Änderung
2. Gerätetypen	Definition für die Implementierung von Android Automotive hinzugefügt.
2.1 Gerätekonfigurationen	Spalte für die Android Auto-Implementierung hinzugefügt.
3.3.2. Kompatibilität mit nativem 32-Bit-ARM-Code	Neuer Abschnitt hinzugefügt.
3.4.1. WebView-Kompatibilität	Die Anforderung für den Webview-User-Agent-String wurde aktualisiert, um eine Änderung der Upstream-Implementierung zu berücksichtigen.
3.4.2. Browserkompatibilität	Android Automotive-Implementierungen wurden als weiterer Fall hinzugefügt, in dem eine Browseranwendung UNTER UMSTÄNDEN weggelassen werden kann.
3.7. Laufzeitkompatibilität	Die erforderliche Laufzeit-Heap-Größe für kleinere Bildschirme wurde aktualisiert und eine Anforderung für den neuen dpi-Bucket (280 dpi) hinzugefügt.
3.8.3. Benachrichtigungen	Die Benachrichtigungsanforderung für Android-Smartwatches, -Fernseher und -Automotive-Implementierungen wurde klarer formuliert.
3.8.8. Aktivitätswechsel	Lockerung der Anforderung an die Anzahl der Titel in der Übersicht.
3.8.10. Mediensteuerung auf dem Sperrbildschirm	Die Anforderung für Android Watch- und Automotive-Implementierungen wurde klarer formuliert.
3.8.13. Unicode und Schriftart	Erleichterte Anforderungen an die Eingabemethode für Emojis
3.9. Geräteverwaltung	Die Bedingung, unter der die gesamte Palette der Richtlinien für die Geräteverwaltung unterstützt werden muss, wurde klarer formuliert.
3.10. Bedienungshilfen	Anforderungen für Android Automotive hinzugefügt.
3.11. Text-in-Sprache	Anforderungen für Android Automotive hinzugefügt.
5.1. Medien-Codecs	Erforderliche Dekodierungsunterstützung für Codecs, die von CamcorderProfile gemeldet werden.
5.1.3 Video-Codecs	Anforderungen für Android Automotive hinzugefügt.
5.4. Audioaufnahmen	Die Sprache am Anfang des Abschnitts wurde klarer formuliert, damit die MUST-Anforderungen als ERFORDERLICH gelesen werden.
7.1.1.3. Bildschirmdichte	Neue Bildschirm-dpi (280 dpi) hinzugefügt.
7.1.5. Modus für die Kompatibilität mit älteren Anwendungen	Anforderungen für Android Automotive hinzugefügt.
7.2 Eingabegeräte	Allgemeine Einführungsbeschreibung hinzugefügt.
7.2.1. Tastatur	Android Automotive-Anforderungen hinzugefügt.
7.2.3. Navigationstasten	Android Automotive-Anforderungen hinzugefügt.
7.3.1. Beschleunigungsmesser	Erleichterte Anforderungen an die Berichtshäufigkeit auf Android-Smartwatches.
7.3.4. Gyroskop	Erleichterte Anforderungen an die Berichtshäufigkeit auf Android-Smartwatches.
7.4.3 Bluetooth	Android Automotive-Anforderungen hinzugefügt.
7.4.4. Nahfeldkommunikation	Die Bedingung, unter der die Host Card Emulation erforderlich ist, wurde klarer formuliert.
7.6.1. Mindestarbeitsspeicher und Mindestspeicherplatz	Die Mindestspeicheranforderungen für Geräte mit niedrigerer Bildschirmauflösung wurden aktualisiert und die harte Grenze „isLowRamDevice()“ wurde hinzugefügt.
7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen	Aktualisierte Anforderungen, wenn der Zugriff auf den Hostcomputer erforderlich ist.
7,7 USB	Tippfehler im Abschnitt „USB“ korrigiert
7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen	Aktualisierte Anforderungen für vorinstallierte System-Apps, die auf sekundären externen Speicher schreiben dürfen.
7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen	Apps können ACTION_OPEN_DOCUMENT_TREE verwenden, um auf sekundären externen Speicher zu schreiben
7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen	Erläutern, dass /sdcard den Speicherplatz mit /data teilen kann
7,7 USB	Redundante Anforderung an UMS/MTP in Version 7.7 entfernen
7.8.1. Mikrofon	Android Automotive-Anforderungen hinzugefügt.
8.2. Leistung des Datei-E/A-Zugriffs	Die Anforderungen wurden klarer formuliert.
9.5. Unterstützung mehrerer Nutzer	Für den primären externen Speicher ist eine SD-Kartenverschlüsselung erforderlich.
9.8. Datenschutz	Es wurde eine Datenschutzanforderung für vorinstallierte VPNs hinzugefügt.
9.9. Datenträgervollverschlüsselung	Die Bedingung, unter der die Unterstützung der Festplattenvollverschlüsselung erforderlich ist, wurde verdeutlicht.
9.10. Verified Boot	Die Definition des verifizierten Bootmodus wurde klarer formuliert.
11. Aktualisierbare Software	Es wurde klargestellt, dass die OTA-Downloadanforderung für Android Automotive-Implementierungen zulässig, aber nicht obligatorisch ist.

13. Kontakt

Sie können dem Android-Kompatibilitätsforum [Ressourcen, 109] beitreten und um Klarstellungen bitten oder Probleme ansprechen, die Ihrer Meinung nach im Dokument nicht behandelt werden.

14. Ressourcen

1. IETF-Anforderungen gemäß RFC 2119: http://www.ietf.org/rfc/rfc2119.txt

2. Open-Source-Projekt von Android: http://source.android.com/

3. Android TV-Funktionen: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Android-Smartwatch-Funktion: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. API-Definitionen und ‑Dokumentation: http://developer.android.com/reference/packages.html

6. Referenz zu Android-Berechtigungen: http://developer.android.com/reference/android/Manifest.permission.html

7. Referenz zu android.os.Build: http://developer.android.com/reference/android/os/Build.html

8. Zulässige Versionsstrings für Android 5.1: http://source.android.com/compatibility/5.1/versions.html

9. Telefonieanbieter: http://developer.android.com/reference/android/provider/Telephony.html

10. Hostbasierte Kartenemulation: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep

12. Klasse „android.webkit.WebView“: http://developer.android.com/reference/android/webkit/WebView.html

13. WebView-Kompatibilität: http://www.chromium.org/

14. HTML5: http://html.spec.whatwg.org/multipage/

15. Offlinefunktionen von HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

16. HTML5-Video-Tag: http://dev.w3.org/html5/spec/Overview.html#video

17. HTML5/W3C Geolocation API: http://www.w3.org/TR/geolocation-API/

18. HTML5/W3C Webstorage API: http://www.w3.org/TR/webstorage/

19. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/

20. Dalvik-Ausführbares Format und Bytecode-Spezifikation: Im Android-Quellcode unter dalvik/docs verfügbar

21. App-Widgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

22. Benachrichtigungen: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

23. Anwendungsressourcen: https://developer.android.com/guide/topics/resources/available-resources.html

24. Styleguide für Statusleistensymbole: http://developer.android.com/design/style/iconography.html

25. Ressourcen zu Benachrichtigungen: https://developer.android.com/design/patterns/notifications.html

26. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html

27. Toasts: http://developer.android.com/reference/android/widget/Toast.html

28. Themen: http://developer.android.com/guide/topics/ui/themes.html

29. Klasse „R.style“: http://developer.android.com/reference/android/R.style.html

30. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. Live-Hintergründe: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. Ressourcen zum Übersichtsbildschirm: http://developer.android.com/guide/components/recents.html

33. Bildschirmanpinning: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. Eingabemethoden: http://developer.android.com/guide/topics/text/creating-input-method.html

35. Medienbenachrichtigung: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

36. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

37. Settings.Secure LOCATION_MODE:

http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

39. Android-Geräteverwaltung: http://developer.android.com/guide/topics/admin/device-admin.html

40. DevicePolicyManager-Referenz: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

41. Android Device Owner App:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. APIs für den Android-Bedienungsservice: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. Android Accessibility APIs: http://developer.android.com/reference/android/view/accessibility/package-summary.html

44. Eyes Free-Projekt: http://code.google.com/p/eyes-free

45. Text-to-Speech APIs: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. Television Input Framework: /devices/tv/index.html

47. Referenzdokumentation zu Tools (für adb, aapt, ddms, systrace): http://developer.android.com/tools/help/index.html

48. Beschreibung von Android-APK-Dateien: http://developer.android.com/guide/components/fundamentals.html

49. Manifestdateien: http://developer.android.com/guide/topics/manifest/manifest-intro.html

50. Android-Medienformate: http://developer.android.com/guide/appendix/media-formats.html

51. Anforderungen an die RTC-Hardwarecodierung: http://www.webmproject.org/hardware/rtc-coding-requirements/

52. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. Android-Klasse „android.content.pm.PackageManager“ und Liste der Hardwarefunktionen:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. HTTP Live Streaming-Entwurfsprotokoll: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: http://developer.android.com/tools/help/adb.html

56. Dumpsys: /devices/input/diagnostics.html

57. DDMS: http://developer.android.com/tools/debugging/ddms.html

58. Monkey-Testtool: http://developer.android.com/tools/help/monkey.html

59. SysyTrace-Tool: http://developer.android.com/tools/help/systrace.html

60. Einstellungen für die Entwicklung von Android-Anwendungen:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

61. Unterstützung mehrerer Bildschirme: http://developer.android.com/guide/practices/screens_support.html

62. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

63. RenderScript: http://developer.android.com/guide/topics/renderscript/

64. Android-Erweiterungspaket für OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. Hardwarebeschleunigung: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. EGL-Erweiterung – EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

67. Displaymanager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

68. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

69. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

70. Konfiguration der Touchbedienung: http://source.android.com/devices/tech/input/touch-devices.html

71. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html

72. Key Event API: http://developer.android.com/reference/android/view/KeyEvent.html

73. Open-Source-Sensoren für Android: http://source.android.com/devices/sensors

74. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

75. Zeitstempel für Sensorereignisse: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. Android Open Source-Kompositsensoren: /devices/sensors/sensor-types.html#composite_sensor_type_summary

77. Modus für kontinuierlichen Trigger: /docs/core/interaction/sensors/report-modes#continuous

78. Beschleunigungsmesser: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

79. Wi‑Fi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

80. Wi‑Fi Direct (Wi‑Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

81. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

82. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

83. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. NDEF-Push-Protokoll: http://source.android.com/compatibility/ndef-push-protocol.pdf

85. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

86. NFC-Freigabeeinstellungen für Android:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

87. NFC-Übergabe: http://members.nfc-forum.org/specs/spec_list/#conn_handover

88. Bluetooth Secure Simple Pairing Using NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

90. Camera Orientation API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

91. Kamera: http://developer.android.com/reference/android/hardware/Camera.html

92. Kamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

93. Kamera-Hardwareebene: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. Unterstützung der Kameraversion: http://source.android.com/devices/camera/versioning.html

95. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

96. Android File Transfer: http://www.android.com/filetransfer

97. Android Open Accessories: http://developer.android.com/guide/topics/connectivity/usb/accessory.html

98. Android USB Audio: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

99. USB-Lade-Spezifikation: http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf

100. USB Host API: http://developer.android.com/guide/topics/connectivity/usb/host.html

101. Kabelgebundenes Audio-Headset: http://source.android.com//docs/core/interaction/accessories/headset/plug-headset-spec.html

102. Informationen zu Sicherheit und Berechtigungen unter Android: http://developer.android.com/guide/topics/security/permissions.html

103. UserManager-Referenz: http://developer.android.com/reference/android/os/UserManager.html

104. Referenz zum externen Speicher: http://source.android.com/docs/core/storage

105. APIs für externen Speicher: http://developer.android.com/reference/android/os/Environment.html

106. SMS-Kurzcode: http://de.wikipedia.org/wiki/Kurzcode

107. Android Open Source Encryption: http://source.android.com/docs/security/features/encryption

108. Android-Kompatibilitätsprogramm – Übersicht: http://source.android.com//docs/compatibility

109. Android Compatibility Forum: https://groups.google.com/forum/#!forum/android-compatibility

110. WebM-Projekt: http://www.webmproject.org/

111. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

112. Android MediaCodecList API: http://developer.android.com/reference/android/media/MediaCodecList.html

113. Android CamcorderProfile API: http://developer.android.com/reference/android/media/CamcorderProfile.html

Viele dieser Ressourcen stammen direkt oder indirekt aus dem Android SDK und sind funktional mit den Informationen in der Dokumentation dieses SDK identisch. In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstestsuite nicht mit der SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als verbindlich. Alle technischen Details in den oben genannten Referenzen gelten als Teil dieser Kompatibilitätsdefinition.