1. Einführung

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

Damit Geräte als mit Android 6.0 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äteimplementierern wird DRINGEND empfohlen, ihre Implementierungen nach Möglichkeit auf dem „Upstream“-Quellcode zu 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:

• Die Funktion „android.hardware.type.automotive“ MUSS deklariert werden.
• MUSS uiMode = UI_MODE_TYPE_CAR [Ressourcen, 5] unterstützen.

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 6.0 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, 6] oder von APIs mit dem Markierungs-Tag „@SystemApi“ im Upstream-Android-Quellcode bereitgestellt werden.

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, 7] beschrieben. 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“ [Ressourcen, 8], 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, 9] 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 6.0 MUSS dieses Feld den Ganzzahlwert 23 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 6.0 MUSS dieses Feld den Ganzzahlwert 23 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:6.0/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 für alle Geräte mit demselben MODELL und HERSTELLER verfügbar und eindeutig sein MUSS. 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.
SECURITY_PATCH	Ein Wert, der den Stand der Sicherheits-Patches eines Builds angibt. Es MUSS darauf hinweisen, dass der Build alle Sicherheits-Patches enthält, die bis zum angegebenen öffentlichen Android-Sicherheitsbulletin veröffentlicht wurden. Es MUSS das Format [JJJJ-MM-TT] haben und mit einem der Strings für den Stand der Sicherheitsupdates von Android in den öffentlichen Sicherheitsbulletins übereinstimmen, z. B. „2015-11-01“.
BASE_OS	Ein Wert, der dem FINGERPRINT-Parameter des Builds entspricht, der ansonsten mit diesem Build identisch ist, mit Ausnahme der Patches, die im Android Public Security Bulletin bereitgestellt werden. Es MUSS der richtige Wert angegeben werden. Wenn ein solcher Build nicht vorhanden ist, muss ein leerer String („"") angegeben werden.

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-Auflösung

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 MÜSSEN eine Benutzeroberfläche bereitstellen, über die Nutzer die Standardaktivität für Intents ändern können.

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

Android bietet auch einen Mechanismus, mit dem Drittanbieter-Apps ein autoritatives Standardverhalten für die App-Verknüpfung für bestimmte Arten von Web-URI-Intents angeben können [Ressourcen, 140]. Wenn solche autorisierten Erklärungen in den Intent-Filtermustern einer App definiert sind, gilt für Geräteimplementierungen Folgendes:

• MÜSSEN alle Intent-Filter validieren, indem die in der Digital Asset Links-Spezifikation [Ressourcen, 141] definierten Validierungsschritte ausgeführt werden, wie sie vom Paketmanager im Upstream-Android Open Source Project implementiert wurden.
• MÜSSEN die Intent-Filter während der Installation der Anwendung validieren und alle erfolgreich validierten UIR-Intent-Filter als Standard-App-Handler für ihre UIRs festlegen.
• KÖNNEN bestimmte URI-Intent-Filter als Standard-App-Handler für ihre URIs festlegen, wenn sie erfolgreich überprüft wurden, andere infrage kommende URI-Filter jedoch nicht. Wenn eine Geräteimplementierung dies tut, MUSS sie dem Nutzer im Einstellungsmenü entsprechende URI-Musterüberschreibungen zur Verfügung stellen.
• MÜSSEN Nutzern in den Einstellungen App-Link-Einstellungen pro App zur Verfügung stellen:
  • Der Nutzer MUSS in der Lage sein, das Standardverhalten von App-Links für eine App ganzheitlich zu überschreiben: „Immer öffnen“, „Immer fragen“ oder „Nie öffnen“. Dies muss für alle Kandidaten für URI-Intent-Filter gleichermaßen gelten.
  • Der Nutzer MUSS eine Liste der Kandidaten für URI-Intent-Filter sehen können.
  • Die Geräteimplementierung KANN es dem Nutzer ermöglichen, bestimmte URI-Intent-Filter, die erfolgreich bestätigt wurden, pro Intent-Filter zu überschreiben.
  • Die Geräteimplementierung MUSS Nutzern die Möglichkeit bieten, bestimmte URI-Intent-Filter für Kandidaten aufzurufen und zu überschreiben, wenn bei der Geräteimplementierung einige URI-Intent-Filter für Kandidaten die Überprüfung bestehen, während andere fehlschlagen 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:

• Die Intent „android.settings.HOME_SETTINGS“ MUSS berücksichtigt werden, 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, 11]
• Die Intent-Aktion „android.settings.NFC_PAYMENT_SETTINGS“ MUSS berücksichtigt werden, um ein standardmäßiges Menü für die App-Einstellungen 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.
• MÜSSEN über die oben genannten Parameter nur die ABIs melden, die in der aktuellen Version der Android NDK ABI Management-Dokumentation [Ressourcen, 12] dokumentiert und beschrieben sind, und MÜSSEN die Unterstützung für die Advanced SIMD-Erweiterung (auch NEON genannt) [Ressourcen, 13] umfassen.
• 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, 14] 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.

Geräteimplementierungen, die eine native Bibliothek mit dem Namen „libvulkan.so“ enthalten, MÜSSEN Funktionssymbole exportieren und eine Implementierung der Vulkan 1.0 API sowie der VK_KHR_surface-, VK_KHR_swapchain- und VK_KHR_android_surface-Erweiterungen bereitstellen, wie von der Khronos Group definiert, und die Khronos-Konformitätstests bestehen.

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 die android.webkit.WebView-Komponente zu implementieren [Ressourcen, 15]. 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 Project für Android 6.0 basieren. Dieser Build enthält eine Reihe von Funktionen und Sicherheitskorrekturen für die WebView [Ressourcen, 16].
• Der von der WebView gemeldete User-Agent-String MUSS dieses Format haben:

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

  • Der Wert des Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE übereinstimmen.
  • Der 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, 17].

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, 17]. Geräteimplementierungen müssen mindestens die folgenden APIs unterstützen, die mit HTML5 verknüpft sind:

• Anwendungscache/Offlinebetrieb [Ressourcen, 18]
• das <video>-Tag [Ressourcen, 19]
• Standortbestimmung [Ressourcen, 20]

Darüber hinaus MÜSSEN Geräteimplementierungen die HTML5/W3C Webstorage API [Ressourcen, 21] und SOLLTEN die HTML5/W3C IndexedDB API [Ressourcen, 22] 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-Namensraums enthält, MÜSSEN diese APIs in einer freigegebenen Android-Bibliothek verpackt werden, damit nur Apps, die sie explizit verwenden (über den Mechanismus <uses-librarygt;), 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ührformat (DEX) sowie die Dalvik-Bytecode-Spezifikation und -Semantik unterstützen [Ressourcen, 23]. 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
Android-Uhr	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36 MB
	280 dpi (280dpi)
	320 dpi (xhdpi)	48 MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56 MB
	420 dpi (420dpi)	64 MB
	480 dpi (xxhdpi)	88 MB
	560 dpi (560dpi)	112 MB
	640 dpi (xxxhdpi)	154 MB
klein/normal	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48 MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80 MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96 MB
	420 dpi (420dpi)	112 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi (560dpi)	192 MB
	640 dpi (xxxhdpi)	256 MB
Groß	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)	48 MB
	213 dpi (tvdpi)	80 MB
	240 dpi (hdpi)
	280 dpi (280dpi)	96 MB
	320 dpi (xhdpi)	128 MB
	360 dpi (360dpi)	160 MB
	400 dpi (400dpi)	192 MB
	420 dpi (420dpi)	228 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi (560dpi)	384 MB
	640 dpi (xxxhdpi)	512 MB
xlarge	120 dpi (ldpi)	48 MB
	160 dpi (mdpi)	80 MB
	213 dpi (tvdpi)	96 MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144 MB
	320 dpi (xhdpi)	192 MB
	360 dpi (360dpi)	240 MB
	400 dpi (400dpi)	288 MB
	420 dpi (420dpi)	336 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi (560dpi)	576 MB
	640 dpi (xxxhdpi)	768 MB

3.8. Kompatibilität der Benutzeroberfläche

3.8.1. Launcher (Startbildschirm)

Android enthält eine Launcher-Anwendung (Startbildschirm) und unterstützt 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 dem Endnutzer ein „App-Widget“ zur Verfügung stellen können [Ressourcen, 24]. 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, 24].
• 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, 25], 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, 26] oder im Stilhandbuch für Symbole der Status-/Systemleiste [Ressourcen, 27] 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 [Ressourcen, 28] 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 bietet APIs [Ressourcen, 29], 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.

Bei Android-Geräten MUSS ein Assistent auf dem Gerät implementiert werden, um die Assist-Aktion zu verarbeiten [Ressourcen, 30].

Android enthält auch die Assist APIs, mit denen Anwendungen festlegen können, wie viele Informationen des aktuellen Kontexts mit dem Assistant auf dem Gerät geteilt werden [Ressourcen, 31]. Bei Geräteimplementierungen, die die Assist-Aktion unterstützen, muss dem Endnutzer klar angezeigt werden, wann der Kontext geteilt wird. Dazu muss ein weißes Licht an den Rändern des Displays angezeigt werden. Damit der Endnutzer die Anzeige gut sehen kann, MUSS sie die Dauer und Helligkeit der Implementierung des Android Open Source Project erreichen oder überschreiten.

3.8.5. Toasts

Mit der Toast API können Apps Endnutzern kurze nicht modale Strings anzeigen, die nach kurzer Zeit verschwinden [Ressourcen, 32]. 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 nachahmen möchten [Ressourcen, 33]. Geräteimplementierungen dürfen KEINE der Holo-Designattribute ändern, die für Apps sichtbar sind [Ressourcen, 34].

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 Designfamilie „Material“ unterstützen und KEINE der Material Design-Attribute oder deren Assets ändern, die für Anwendungen freigegeben sind [Ressourcen, 35].

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“ ändern, die für Anwendungen freigegeben sind [Ressourcen, 34].

Android unterstützt ein 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 Android-Geräte weiß für Systemstatussymbole (z. B. Signalstärke und Akkustand) und vom System ausgegebene Benachrichtigungen verwenden, es sei denn, das Symbol weist auf einen problematischen Status hin oder eine App fordert mit dem Flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR eine helle Statusleiste an. Wenn eine App eine helle Statusleiste anfordert, MÜSSEN Android-Geräteimplementierungen die Farbe der Systemstatussymbole in Schwarz ändern [Ressourcen, 34].

3.8.7. Live-Hintergründe

Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, mit denen Apps dem Endnutzer einen oder mehrere „Live-Hintergründe“ zur Verfügung stellen können [Ressourcen, 36]. 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 [Ressourcen, 37], 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, 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 6 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 die Bildschirmanpinning-Funktion [Ressourcen, 38] implementieren und den Nutzern ein Einstellungsmenü zur Verfügung stellen, mit dem sie die Funktion aktivieren und deaktivieren können.
• 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, 39]. 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 mit Wiedergabesteuerungen integriert werden, die auf dem Sperrbildschirm als Sperrbildschirmbenachrichtigungen angezeigt werden [Ressourcen, 40]. Bei Geräteimplementierungen MUSS die Vorlage für Medienbenachrichtigungen als Teil der in Abschnitt 3.8.3 beschriebenen Sperrbildschirmbenachrichtigungen korrekt gerendert werden.

3.8.11. Träume

Android unterstützt interaktive Bildschirmschoner namens Dreams [Ressourcen, 41]. 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, 42].

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, 43]. 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, 44] Geräteverwaltungsfunktionen auf Systemebene ausführen können, z. B. die Erzwingung von Passwortrichtlinien oder das Löschen von Daten aus der Ferne. Geräteimplementierungen MÜSSEN eine Implementierung der Klasse „DevicePolicyManager“ bereitstellen [Ressourcen, 45]. Geräteimplementierungen, die die PIN- (numerisch) oder PASSWORT- (alphanumerisch) basierten Sperrbildschirme unterstützen, MÜSSEN die gesamte Palette der in der Android SDK-Dokumentation [Ressourcen, 44] definierten Richtlinien zur Geräteverwaltung unterstützen und die Plattformfunktion „android.software.device_admin“ melden.

3.9.1 Gerätebereitstellung

3.9.1.1 Geräteeigentümer-Bereitstellung

Wenn in einer Geräteimplementierung die Funktion „android.software.device_admin“ deklariert wird, MUSS die Out-of-the-Box-Einrichtung es ermöglichen, eine Device Policy Controller-Anwendung (DPC) als Geräteeigentümer-App zu registrieren [ Ressourcen, 46]. Geräteimplementierungen KÖNNEN eine vorinstallierte Anwendung haben, die Geräteverwaltungsfunktionen ausführt. Diese Anwendung darf jedoch NICHT ohne ausdrückliche Zustimmung oder Aktion des Nutzers oder Administrators des Geräts als App des Geräteeigentümers festgelegt werden.

Die Nutzerfreundlichkeit des Bereitstellungsverfahrens für Geräteeigentümer (der Ablauf, der durch android.app.action.PROVISION_MANAGED_DEVICE [ Ressourcen, 47] initiiert wird) MUSS der AOSP-Implementierung entsprechen.

Wenn die Geräteimplementierung „android.hardware.nfc“ meldet, muss NFC aktiviert sein, auch während der Out-of-the-Box-Einrichtung, damit die NFC-Bereitstellung für Geräteeigentümer möglich ist [Ressourcen, 48].

3.9.1.2 Bereitstellung verwalteter Profile

Wenn in einer Geräteimplementierung „android.software.managed_users“ deklariert wird, MUSS es möglich sein, eine Device Policy Controller-Anwendung (DPC) als Eigentümer eines neuen verwalteten Profils zu registrieren. [ Ressourcen, 49]

Die Nutzerfreundlichkeit des Bereitstellungsverfahrens für verwaltete Profile (der Ablauf, der durch android.app.action.PROVISION_MANAGED_PROFILE [ Ressourcen, 50] initiiert wird) MUSS der AOSP-Implementierung entsprechen.

3.9.2 Unterstützung für verwaltete Profile

Geräte, die verwaltete Profile unterstützen, haben folgende Eigenschaften:

• Deklarieren Sie android.software.device_admin (siehe Abschnitt 3.9 Geräteverwaltung).
• Sie haben nicht zu wenig RAM (siehe Abschnitt 7.6.1).
• Internen (nicht herausnehmbaren) Speicher als gemeinsamen Speicher zuweisen (siehe Abschnitt 7.6.2)

Geräte mit verwalteten Profilen MÜSSEN:

• Deklarieren Sie das Plattform-Funktions-Flag „android.software.managed_users“.
• Verwaltete Profile über die APIs von android.app.admin.DevicePolicyManager unterstützen
• Es darf nur ein einziges verwaltetes Profil erstellt werden. [Ressourcen, 50]
• Verwenden Sie ein Symbol-Logo (ähnlich dem AOSP-Logo für Upstream-Arbeiten), um die verwalteten Apps und Widgets sowie andere UI-Elemente mit Logos wie „Letzte“ und „Benachrichtigungen“ darzustellen.
• Ein Benachrichtigungssymbol (ähnlich dem AOSP-Upstream-Arbeitslogo) anzeigen, um anzugeben, wenn sich der Nutzer in einer Anwendung mit verwaltetem Profil befindet
• Wenn das Gerät aktiviert wird (ACTION_USER_PRESENT) und die App im Vordergrund sich im verwalteten Profil befindet, wird eine Toast-Mitteilung angezeigt, dass sich der Nutzer im verwalteten Profil befindet.
• Wenn ein verwaltetes Profil vorhanden ist, muss in der Intent-Auswahl eine visuelle Aufforderung angezeigt werden, damit der Nutzer den Intent vom verwalteten Profil an den Hauptnutzer oder umgekehrt weiterleiten kann, sofern dies vom Device Policy Controller aktiviert ist.
• Wenn ein verwaltetes Profil vorhanden ist, müssen sowohl für den Hauptnutzer als auch für das verwaltete Profil die folgenden Nutzerfunktionen angezeigt werden:
  • Separate Erfassung der Akku-, Standort-, mobilen Daten- und Speichernutzung für den Hauptnutzer und das verwaltete Profil.
  • Unabhängige Verwaltung von VPN-Anwendungen, die im primären Nutzer- oder verwalteten Profil installiert sind.
  • Unabhängige Verwaltung von Anwendungen, die im primären Nutzerkonto oder im verwalteten Profil installiert sind.
  • Unabhängige Verwaltung von Konten im primären Nutzer- oder verwalteten Profil
• Der Standard-Telefon-Dialer muss die Anruferinformationen aus dem verwalteten Profil (falls vorhanden) zusammen mit denen aus dem primären Profil abrufen können, sofern dies vom Device Policy Controller zulässig ist.
• Es MUSS dafür sorgen, dass alle Sicherheitsanforderungen für ein Gerät mit mehreren Nutzern erfüllt werden (siehe Abschnitt 9.5), auch wenn das verwaltete Profil nicht zusätzlich zum primären Nutzer als weiterer Nutzer gezählt wird.

3.10. Bedienungshilfen

Android bietet eine Bedienungshilfenebene, die es Nutzern mit Beeinträchtigungen erleichtert, ihre Geräte zu bedienen. Außerdem bietet Android Plattform-APIs, mit denen Implementierungen von Diensten zur Barrierefreiheit Rückrufe für Nutzer- und Systemereignisse erhalten und alternative Feedbackmechanismen wie Text-zu-Sprache-Funktionen, haptisches Feedback und Navigation per Trackball/D-Pad generieren können [Ressourcen, 51].

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, 52]
• 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, 53].

3.11. Sprachausgabe

Android bietet APIs, mit denen Anwendungen TTS-Dienste (Text-to-Speech) nutzen und Dienstanbieter TTS-Dienste implementieren können [Ressourcen, 54]. 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 TV Input Framework unterstützen [Ressourcen, 55].

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

3.12.1. TV-App

Auf jeder Geräteimplementierung, die die Unterstützung von Live-TV angibt, MUSS eine installierte TV-Anwendung (TV-App) vorhanden sein. Das Android Open Source Project bietet eine Implementierung der TV-App.

Die Standard-TV-App muss Zugriff auf Kanäle über installierte und Drittanbieter-Eingabequellen bieten. Die installierten Eingaben umfassen alle standardmäßig bereitgestellten Eingaben, unabhängig davon, ob sie TIF-basiert sind oder nicht.

Die TV-App MUSS Funktionen zum Installieren und Verwenden von TV-Kanälen bieten [Ressourcen, 56] und die folgenden Anforderungen erfüllen:

• Bei Geräteimplementierungen MÜSSEN TIF-basierte Eingaben von Drittanbietern (Drittanbietereingaben) [Ressourcen, 57] installiert und verwaltet werden können.
• Bei Geräteimplementierungen kann eine visuelle Trennung zwischen vorinstallierten TIF-basierten Eingaben (installierte Eingaben) [Ressourcen, 58] und Eingaben von Drittanbietern erfolgen.
• Die Eingaben von Drittanbietern dürfen in den Geräteimplementierungen nicht weiter als eine Navigationsaktion von der TV-App entfernt sein (d.h. eine Liste der Eingaben von Drittanbietern aus der TV-App maximieren).

3.12.1.1. Elektronischer Programmführer

Android TV-Geräteimplementierungen MÜSSEN ein informatives und interaktives Overlay anzeigen, das einen elektronischen Programmführer (EPG) enthalten MUSS, der aus den Werten in den Feldern „TvContract.Programs“ generiert wird [Ressourcen, 59]. Das EPG MUSS die folgenden Anforderungen erfüllen:

• Das EPG MUSS Informationen von allen installierten und Drittanbieter-Eingängen enthalten.
• Das EPG KANN eine visuelle Trennung zwischen den installierten und den von Drittanbietern bereitgestellten Eingängen bieten.
• Im EPG sollten installierte und Drittanbieter-Eingabequellen GLEICHWERTIG präsentiert werden. Die Eingänge von Drittanbietern dürfen im EPG NICHT weiter als eine Navigationsaktion von den installierten EPG-Eingängen entfernt sein.
• Bei einem Kanalwechsel MÜSSEN Geräteimplementierungen EPG-Daten für das aktuell wiedergegebene Programm anzeigen.

3.12.1.2. Navigation

Eingabegeräte für Android TV-Geräte (z.B. Fernbedienung, Fernbedienungsanwendung oder Gamecontroller) MÜSSEN die Navigation zu allen ausführbaren Bereichen des Bildschirms über das Steuerkreuz ermöglichen. Das Steuerkreuz nach oben und unten MUSS verwendet werden, um Live-TV-Kanäle zu wechseln, wenn auf dem Bildschirm kein ausführbarer Bereich angezeigt wird.

Die TV-App MUSS wichtige Ereignisse über CEC an HDMI-Eingänge weitergeben.

3.12.1.3. App-Verknüpfung für TV-Eingang

Android TV-Geräteimplementierungen MÜSSEN die Verknüpfung von TV-Eingabe-Apps unterstützen. Dadurch können alle Eingaben Aktivitätslinks von der aktuellen Aktivität zu einer anderen Aktivität bereitstellen (z. B. einen Link von der Live-Programmierung zu ähnlichen Inhalten) [Ressourcen, 60]. Die TV-App MUSS die Verknüpfung mit der TV-Eingabe-App anzeigen, sofern diese vorhanden ist.

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, 61].

Geräteimplementierungen dürfen das APK-Format [Ressourcen, 62], das Android-Manifest [Ressourcen, 49], das Dalvik-Bytecode-Format [Ressourcen, 23] oder das RenderScript-Bytecode-Format 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, 64] 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 [Ressourcen, 65] gemeldeten Medienformate, Encoder, Decoder, Dateitypen und Containerformate unterstützen. Geräteimplementierungen MÜSSEN außerdem alle Profile decodieren können, die in ihrem CamcorderProfile angegeben sind [Ressourcen, 66], und alle Formate decodieren können, die sie codieren können. 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 oder höher)	ERFORDERLICH (Android 4.1 oder 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 wird jedoch eine Abtastrate von bis zu 44,1 kHz EMPFOHLEN, da der Downsampler von 48 auf 44,1 kHz keinen Tiefpassfilter enthält). 16 Bit 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

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-2 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-2		EMPFOHLEN6	Profil "Main"	MPEG2-TS
MPEG-4 SP		ERFORDERLICH2		3GPP (.3gp)
VP83	ERFORDERLICH2 (Android 4.3 und höher)	ERFORDERLICH2 (Android 2.3.3 oder höher)	Weitere Informationen finden Sie in den Abschnitten 5.2 und 5.3.	WebM (.webm) [Ressourcen, 67 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, 67] 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 Web-Videostreaming- und Videokonferenzdiensten SOLLTE bei Geräteimplementierungen ein Hardware-VP8-Codec verwendet werden, der die Anforderungen in [Ressourcen, 68] erfüllt.

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

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

6 Gilt nur für Android-TV-Geräteimplementierungen.

5.2. Videocodierung

Android-Geräteimplementierungen mit H.263-Encodern MÜSSEN das Baseline-Profil der Stufe 45 unterstützen.

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 dynamische Videoauflösungen und ‑Frameraten über die standardmäßigen Android APIs innerhalb desselben Streams für alle VP8-, VP9-, H.264- und H.265-Codecs in Echtzeit und bis zur maximalen Auflösung unterstützen, die von jedem Codec auf dem Gerät unterstützt wird.

Android-Geräteimplementierungen mit H.263-Decodern MÜSSEN Baseline Profile Level 30 unterstützen.

Android-Geräteimplementierungen mit MPEG-4-Decodern MÜSSEN Simple Profile Level 3 unterstützen.

Android-Geräteimplementierungen mit H.264-Decodern MÜSSEN das Hauptprofil Level 3.1 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	60 fps	30 fps / 60 fps2
Video-Bitrate	800 kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

1 ERFORDERLICH, wenn die Höhe, die von der Methode „Display.getSupportedModes()“ gemeldet wird, der Videoauflösung entspricht oder größer ist.

2 ERFORDERLICH für Android TV-Geräteimplementierungen.

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, wenn die Höhe, die von der Methode „Display.getSupportedModes()“ gemeldet wird, der Videoauflösung entspricht oder größer ist.

2 ERFORDERLICH für Android TV-Geräteimplementierungen.

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-Decodierungsprofil unterstützt wird, MUSS es eine Farbtiefe von 8 Bit und SOLLTE VP9-Profil 2 (10 Bit) unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p1	HD 1080p2	UHD2
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	60 fps	60 fps
Video-Bitrate	600 Kbit/s	1,6 Mbit/s	4 Mbit/s	5 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 OPTION für bestehende 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 TV-Geräte sollten das UHD-Decodierungsprofil und das HD 1080p-Decodierungsprofil UNTERSTÜTZEN. Wenn das Decodierungsprofil für HD 1080p unterstützt wird, MUSS es das Hauptprofil der Hauptebene der Stufe 4.1 unterstützen. Wenn die UHD-Dekodierung unterstützt wird, MUSS das Main10 Level 5 Main Tier-Profil unterstützt werden.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p1	HD 1080p2	UHD2
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	60 fps2	60 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 METHODE für bestehende 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

Die Erfassung für die oben genannten Abtastfrequenzen MUSS ohne Upsampling erfolgen und jede Downsampling-Methode MUSS einen geeigneten Anti-Aliasing-Filter enthalten.

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

Wenn die Aufnahme für die oben genannten Abtastraten unterstützt wird, MUSS die Aufnahme ohne Upsampling bei einem Verhältnis von mehr als 16.000:22.050 oder 44.100:48.000 erfolgen. Jedes Up- oder Down-Sampling MUSS einen geeigneten Anti-Aliasing-Filter enthalten.

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, 69]. 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, kontinuierlicher Ausgabelatenz und einer Pufferzeit. Die Pufferzeit ermöglicht der App, die Verarbeitungszeit zu verlängern und die Phasendifferenz zwischen Eingabe- und Ausgabestreams zu verringern.
• OpenSL ES PCM-Puffer-Queue-API Die PCM-bezogenen OpenSL ES APIs im Android NDK; siehe NDK_root/docs/opensles/index.html.

Bei Geräteimplementierungen, die android.hardware.audio.output deklarieren, wird DRINGEND empfohlen, die folgenden Anforderungen an die Audioausgabe zu erfüllen oder zu ü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, wird dringend empfohlen, die Unterstützung für Audio mit niedriger Latenz zu melden, indem die Funktion „android.hardware.audio.low_latency“ über die Klasse „android.content.pm.PackageManager“ gemeldet wird [Ressourcen, 70]. Wenn die Geräteimplementierung diese Anforderungen nicht erfüllt, darf sie KEINE Unterstützung für Audio mit niedriger Latenz melden.

Bei Geräteimplementierungen, die android.hardware.microphone enthalten, wird dringend empfohlen, die folgenden Anforderungen an die Audioeingabe zu 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, 64] angegeben. Insbesondere MÜSSEN die Geräte die folgenden Mediennetzwerkprotokolle unterstützen:

• RTSP (RTP, SDP)
• HTTP(S)-progressives Streaming
• HTTP(S) Live Streaming-Entwurfsprotokoll, Version 3 [Ressourcen, 71]

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.

5.9. Musical Instrument Digital Interface (MIDI)

Wenn eine Geräteimplementierung den Inter-App-MIDI-Software-Transport (virtuelle MIDI-Geräte) und MIDI über alle der folgenden MIDI-fähigen Hardware-Transporte unterstützt, für die eine generische nicht-MIDI-Verbindung bereitgestellt wird, wird dringend empfohlen, die Unterstützung der Funktion „android.software.midi“ über die Klasse „android.content.pm.PackageManager“ zu melden [Ressourcen, 70].

Die MIDI-fähigen Hardware-Transporte sind:

• USB-Hostmodus (Abschnitt 7.7 USB)
• USB-Peripheriegerätemodus (Abschnitt 7.7 USB)

Wenn die Geräteimplementierung hingegen eine generische nicht-MIDI-Verbindung über einen der oben aufgeführten MIDI-fähigen Hardwaretransporte bietet, aber MIDI über diesen Hardwaretransport nicht unterstützt, darf die Unterstützung der Funktion „android.software.midi“ NICHT gemeldet werden.

MIDI over Bluetooth LE in der zentralen Rolle (Abschnitt 7.4.3 Bluetooth) befindet sich in der Testphase. Eine Geräteimplementierung, die die Funktion „android.software.midi“ meldet und eine generische nicht-MIDI-Verbindung über Bluetooth LE bereitstellt, sollte MIDI über Bluetooth LE unterstützen.

5.10. Professionelles Audio

Wenn eine Geräteimplementierung alle der folgenden Anforderungen erfüllt, wird dringend empfohlen, die Unterstützung der Funktion „android.hardware.audio.pro“ über die Klasse „android.content.pm.PackageManager“ [Ressourcen, 70] zu melden.

• Die Geräteimplementierung MUSS die Unterstützung der Funktion „android.hardware.audio.low_latency“ melden.
• Die kontinuierliche Audio-Rundlauflatenz, wie in Abschnitt 5.6 „Audiolatenz“ definiert, DARF maximal 20 Millisekunden betragen und sollte über mindestens einen unterstützten Pfad 10 Millisekunden oder weniger betragen.
• Wenn das Gerät einen 4-Leiter-3,5-mm-Audioanschluss hat, darf die kontinuierliche Audio-Laufzeit über den Audioanschlusspfad 20 Millisekunden nicht überschreiten und sollte 10 Millisekunden nicht überschreiten.
• Die Geräteimplementierung MUSS USB-Ports enthalten, die den USB-Host-Modus und den USB-Peripheriegerätemodus unterstützen.
• Der USB-Hostmodus MUSS die USB-Audioklasse implementieren.
• Wenn das Gerät einen HDMI-Anschluss hat, MUSS die Geräteimplementierung den Ausgang in Stereo und acht Kanälen mit 20-Bit- oder 24-Bit-Tiefe und 192 kHz ohne Verlust der Bittiefe oder ohne Resampling unterstützen.
• Die Geräteimplementierung MUSS die Unterstützung der Funktion „android.software.midi“ melden.
• Wenn das Gerät eine 3,5‑mm-Audiobuchse mit vier Adern hat, wird dringend empfohlen, dass die Geräteimplementierung den Abschnitt Spezifikationen für Mobilgeräte (Buchse) der Spezifikation für kabelgebundene Audio-Headsets (Version 1.1) einhält.

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, 72]

Geräteimplementierungen MÜSSEN alle adb-Funktionen unterstützen, die im Android SDK dokumentiert sind, einschließlich dumpsys [Ressourcen, 73]. 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, 74]

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, 75]

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

• SysTrace [Ressourcen, 76]

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 10 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, 77]. 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, 70]

7.1. Display und Grafik

Android bietet Funktionen, mit denen Anwendungs-Assets und UI-Layouts automatisch an das Gerät angepasst werden, damit Drittanbieter-Apps auf einer Vielzahl von Hardwarekonfigurationen ordnungsgemäß funktionieren [Ressourcen, 78]. 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, 78] 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)
• 360 dpi (360dpi)
• 400 dpi (400dpi)
• 420 dpi (420dpi)
• 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, 79] definierten Displaymesswerte angeben und MÜSSEN dieselben Werte angeben, 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 außerdem Android RenderScript unterstützen, wie in der Android SDK-Dokumentation [Ressourcen, 80] 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.

Zusätzlich zu OpenGL ES 3.1 bietet Android ein Erweiterungspaket mit Java-Schnittstellen [Ressourcen, 81] 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, 82].

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, 82].

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, 83].

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, 84].

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, 85] 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 richtige Wert für android.content.res.Configuration.navigation angegeben werden [Ressourcen, 85].
• 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 6.0 und höher ausgeliefert werden, KEINE dedizierte physische Schaltfläche 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. Für eine Geräteimplementierung, die vor Android 4.4 eingeführt wurde, aber auf Android 6.0 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-Geräteimplementierungen, die die Assist-Aktion unterstützen [Ressourcen, 30], MÜSSEN diese Funktion mit einer einzelnen Aktion (z. B. Tippen, Doppelklicken oder Geste) zugänglich machen, wenn andere Navigationstasten sichtbar sind. Es wird DRINGEND empfohlen, als einzelne Aktion das lange Drücken der Startbildschirmtaste oder des Software-Tastensymbols zu verwenden.

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“ [Ressourcen, 85] 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 verbunden [Ressourcen, 86], 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, 87].
• 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, 87].
• MÜSSEN den Zeiger auf ein Objekt auf dem Bildschirm bewegen können, um das Tippen auf ein Objekt auf dem Bildschirm zu emulieren.
• Es MUSS möglich sein, innerhalb eines bestimmten Zeitlimits an derselben Stelle auf einem Objekt auf dem Display den Cursor nach unten, nach oben, nach unten und dann nach oben zu bewegen, damit Nutzer das Doppeltippen auf ein Objekt auf dem Display emulieren können [Ressourcen, 87].
• 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, 88]

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 [Resources, 87]

Analoge Steuerelemente1	HID-Nutzung	Android-Schaltfläche