1. Einführung

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

Die Verwendung von „MUST“, „MUST NOT“, „REQUIRED“, „SHALL“, „SHALL NOT“, „SHOULD“, „SHOULD NOT“, „RECOMMENDED“, „MAY“ und „OPTIONAL“ erfolgt gemäß dem IETF-Standard, der in RFC 2119 definiert ist .

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

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

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

Aus diesem Grund ist das Android Open Source Project 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 Compatibility Test Suite hinaus. Bestimmte Komponentenersetzungen und -änderungen sind gemäß diesem Dokument ausdrücklich untersagt.

Viele der in diesem Dokument verlinkten Ressourcen stammen direkt oder indirekt aus dem Android SDK und sind funktional mit den Informationen in der Dokumentation dieses SDK identisch. In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstestsuite nicht mit der SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als verbindlich. Alle technischen Details in den verlinkten Ressourcen in diesem Dokument gelten als 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 von 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 von Android-Handheld-Geräten:

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

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 .

Eine Android Automotive-Implementierung bezieht sich auf eine Auto-Haupteinheit, auf der Android als Betriebssystem für einen Teil oder alle System- und/oder Infotainmentfunktionen ausgeführt wird. Android Automotive-Implementierungen:

• MUSS ein Display mit einer physischen Diagonale von mindestens 15,2 cm haben.
• Die Funktion „android.hardware.type.automotive“ MUSS deklariert werden.
• MUSS uiMode = UI_MODE_TYPE_CAR unterstützen .
• Android Automotive-Implementierungen MÜSSEN alle öffentlichen APIs im Namespace android.car.* unterstützen.

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

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	SOLLTE		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
	Mobilfunkradio	7.4.5. Mindestnetzwerkanforderungen				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 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 oder von APIs mit dem Markierungs-Tag „@SystemApi“ im Upstream-Android-Quellcode bereitgestellt werden, einschließlich aller dokumentierten Verhaltensweisen.

Geräteimplementierungen MÜSSEN alle Klassen, Methoden und zugehörigen Elemente unterstützen/erhalten, die mit der TestApi-Anmerkung (@TestApi) gekennzeichnet sind.

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 vorhanden sein und sich angemessen verhalten. In Abschnitt 7 finden Sie spezifische Anforderungen für dieses Szenario.

3.1.1. Android-Erweiterungen

Android unterstützt die Erweiterung der verwalteten APIs bei Beibehaltung derselben API-Level-Version. Bei Android-Geräteimplementierungen MUSS die AOSP-Implementierung sowohl der freigegebenen Bibliothek ExtShared als auch der Dienste ExtServices mit Versionen vorgeladen werden, die mindestens den für jedes API-Level zulässigen Mindestversionen entsprechen. Beispielsweise müssen Geräteimplementierungen von Android 7.0 mit API-Level 24 mindestens Version 1 enthalten.

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 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“, 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 in 7.1 definierten Stringwerte haben .
VERSION.SDK	Die Version des aktuell ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 7.1 MUSS dieses Feld den Ganzzahlwert 7.1_INT haben.
VERSION.SDK_INT	Die Version des aktuell ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 7.1 MUSS dieses Feld den Ganzzahlwert 7.1_INT haben.
VERSION.INCREMENTAL	Ein vom Geräteimplementierer ausgewählter Wert, der den Build des derzeit ausgeführten Android-Systems in einem visuell lesbaren Format angibt. Dieser Wert darf NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. Dieses Feld wird in der Regel verwendet, um anzugeben, welche Build-Nummer oder Änderungs-ID der Quellkontrolldatei 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 des Geräts widerspiegelt, der den Endnutzern bekannt ist. 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. Dieser Gerätename darf sich während der Lebensdauer des Produkts NICHT ändern.
FINGERPRINT	Ein String, der diesen Build eindeutig identifiziert. Er 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:7.1/LMYXX/3359:userdebug/test-keys Der Fingerabdruck darf KEINE Leerzeichen enthalten. Wenn andere Felder in der Vorlage oben Leerzeichen enthalten, MÜSSEN sie im Build-Fingerabdruck durch ein anderes Zeichen ersetzt werden, z. B. durch den Unterstrich („_“). Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein.
Hardware	Der Name der Hardware (aus der Kernel-Befehlszeile oder /proc). Er sollte für Menschen gut lesbar sein. 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 ausreichend aussagekräftigen Wert haben, damit Endnutzer zwischen 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. Dieser Produktname darf sich während der Lebensdauer des Produkts NICHT ändern.
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 werden und die den Build weiter unterscheiden. 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. Sie MUSS angeben, dass der Build in keiner Weise anfällig für die in dem angegebenen öffentlichen Sicherheitsbulletin für Android beschriebenen Probleme ist. Es MUSS im Format [JJJJ-MM-TT] vorliegen und mit einem definierten String übereinstimmen, der im öffentlichen Sicherheitsbulletin für Android oder in der Sicherheitswarnung für Android dokumentiert ist , z. B. „2015-11-01“.
BASE_OS	Ein Wert, der dem FINGERPRINT-Parameter des Builds entspricht, der mit Ausnahme der im Android Public Security Bulletin bereitgestellten Patches mit diesem Build identisch ist. 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

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 oder eine Komponente, die dieselben Intent-Muster implementiert, die von allen Aktivitäts- oder Dienstkomponenten dieser Android-Kernanwendungen definiert wurden und die anderen Anwendungen implizit oder explizit über das Attribut android:exported zur Verfügung gestellt werden.

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 KEINE speziellen Berechtigungen für die Verwendung dieser Intent-Muster durch Systemanwendungen anhängen 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 Anwendungen 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 außerdem einen Mechanismus, mit dem Drittanbieter-Apps ein vertrauenswürdiges Standard-App-Verknüpfungsverhalten für bestimmte Arten von Web-URI-Intents angeben können. 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 sie die in der Digital Asset Links-Spezifikation definierten Validierungsschritte ausführen, die 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 infrage kommenden 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 dem Nutzer die Möglichkeit bieten, 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 Namespace „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 sind auf die Plattform angewiesen, um bestimmte Intents zu senden, die sie über Änderungen in der Hardware- oder Softwareumgebung informieren. Android-kompatible Geräte MÜSSEN die öffentlichen Intents für die öffentliche Übertragung 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. Wenn 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 Geräteimplementierung muss die Absicht android.settings.HOME_SETTINGS einhalten, um ein Standardmenü für App-Einstellungen für den Startbildschirm anzuzeigen, wenn android.software.home_screen gemeldet wird.
• 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.
• MÜSSEN die Intent android.settings.NFC_PAYMENT_SETTINGS einhalten, um ein Standardmenü für App-Einstellungen für mobiles Bezahlen anzuzeigen, wenn die Geräteimplementierung android.hardware.nfc.hce meldet.
• Die Intent android.telecom.action.CHANGE_DEFAULT_DIALER MUSS berücksichtigt werden, um ein Dialogfeld anzuzeigen, über das der Nutzer die Standard-Telefon-App ändern kann, wenn die Geräteimplementierung android.hardware.telephony meldet .
• MÜSSEN die Intent android.settings.ACTION_VOICE_INPUT_SETTINGS berücksichtigen, wenn das Gerät den VoiceInteractionService unterstützt, und ein Standardmenü für App-Einstellungen für die Spracheingabe und Unterstützung anzeigen.

3.3 Kompatibilität mit nativen APIs

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

3.3.1. Application Binary Interfaces

Verwalteter Dalvik-Bytecode kann auf den nativen Code zugreifen, 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.
• Es 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 über die Parameter „android.os.Build.SUPPORTED_ABIS“, „android.os.Build.SUPPORTED_32_BIT_ABIS“ und „android.os.Build.SUPPORTED_64_BIT_ABIS“ korrekt angegeben werden. Jede dieser kommagetrennten Listen von ABIs muss von der am häufigsten bis zur am wenigsten bevorzugten ABI sortiert sein.
• Es MÜSSEN über die oben genannten Parameter nur die ABIs gemeldet werden, die in der aktuellen Version der Android NDK ABI Management-Dokumentation dokumentiert und beschrieben sind. Außerdem MÜSSEN sie die Erweiterung Advanced SIMD (auch NEON genannt) unterstützen.
• MÜSSEN mit dem Quellcode und den Headerdateien erstellt werden, die im Upstream-Android-Open-Source-Projekt verfügbar sind

In zukünftigen Versionen des Android NDK werden möglicherweise weitere ABIs unterstützt. Wenn eine Geräteimplementierung nicht mit einer vorhandenen vordefinierten ABI kompatibel ist, darf sie KEINE Unterstützung für ABIs melden.

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

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

Für die oben aufgeführten nativen Bibliotheken dürfen die öffentlichen Funktionen in der Geräteimplementierung NICHT hinzugefügt oder entfernt werden.

Native Bibliotheken, die oben nicht aufgeführt, aber in AOSP als Systembibliotheken implementiert und bereitgestellt werden, sind reserviert und dürfen nicht für Drittanbieter-Apps freigegeben werden, die auf API-Level 24 oder höher ausgerichtet sind.

Geräteimplementierungen KÖNNEN nicht AOSP-Bibliotheken hinzufügen und sie direkt als API für Drittanbieter-Apps freigeben. Die zusätzlichen Bibliotheken MÜSSEN sich jedoch in /vendor/lib oder /vendor/lib64 befinden und MÜSSEN in /vendor/etc/public.libraries.txt aufgeführt sein.

Geräteimplementierungen MÜSSEN libGLESv3.so enthalten und alle Funktionssymbole von OpenGL ES 3.1 und dem Android Extension Pack exportieren, wie im NDK-Release android-24 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.

3.3.1.1. Grafikbibliotheken

Vulkan ist eine plattformübergreifende API mit geringem Overhead für leistungsstarke 3D-Grafiken. Geräteimplementierungen MÜSSEN die folgenden Anforderungen erfüllen, auch wenn sie die Vulkan APIs nicht unterstützen:

• Es MUSS immer eine native Bibliothek namens libvulkan.so bereitstellen , die Funktionssymbole für die Vulkan 1.0-Kern-API sowie die Erweiterungen VK_KHR_surface , VK_KHR_android_surface und VK_KHR_swapchain exportiert.

Geräteimplementierungen, sofern sie die Vulkan APIs unterstützen:

• MÜSSEN mindestens eine VkPhysicalDevices über den vkEnumeratePhysicalDevices-Aufruf melden.
• Jede aufgezählte VkPhysicalDevices MUSS die Vulkan 1.0 API vollständig implementieren.
• MÜSSEN die richtigen PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL- und PackageManager#FEATURE_VULKAN_HARDWARE_VERSION-Funktions-Flags enthalten.
• MÜSSEN Ebenen auflisten, die in nativen Bibliotheken mit dem Namen libVkLayer*.so im nativen Bibliotheksverzeichnis des Anwendungspakets enthalten sind, über die Funktionen vkEnumerateInstanceLayerProperties und vkEnumerateDeviceLayerProperties in libvulkan.so
• Es dürfen KEINE Ebenen aufgelistet werden, die von Bibliotheken außerhalb des Anwendungspakets bereitgestellt werden, und es dürfen KEINE anderen Möglichkeiten zum Überwachen oder Abfangen der Vulkan API bereitgestellt werden, es sei denn, die Anwendung hat das Attribut android:debuggable=”true”.

Geräteimplementierungen, die die Vulkan APIs nicht unterstützen:

• Es MUSS 0 VkPhysicalDevices über den vkEnumeratePhysicalDevices-Aufruf gemeldet werden.
• Es dürfen KEINE der Vulkan-Funktionsflags PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL und PackageManager#FEATURE_VULKAN_HARDWARE_VERSION deklariert werden .

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 eingestellten 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 sie von 64-Bit-ARM- oder Nicht-ARM-Anwendungen gelesen werden.

3.4. Webkompatibilität

3.4.1. WebView-Kompatibilität

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

• Die Implementierungen von android.webkit.WebView auf Geräten MÜSSEN auf dem Chromium-Build des Upstream-Android-Open-Source-Projekts für Android 7.1 basieren. Dieser Build enthält eine Reihe von Funktionen und Sicherheitskorrekturen für WebView.

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

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 Drittanbieteranwendungen 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 Ersatz von Drittanbietern basiert) MUSS möglichst viele HTML5-Funktionen unterstützen. Geräteimplementierungen müssen mindestens die folgenden APIs unterstützen, die mit HTML5 verknüpft sind:

• Anwendungscache/Offlinebetrieb
• <video>-Tag
• geolocation

Darüber hinaus MÜSSEN Geräteimplementierungen die HTML5/W3C-Webstorage API und SOLLTEN die HTML5/W3C-IndexedDB API unterstützen . Da die Standardsteuergruppen für die Webentwicklung IndexedDB gegenüber Webstorage 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 mit der bevorzugten Implementierung des Upstream-Android Open Source Project übereinstimmen . 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-Anbieter) 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) testet einen Großteil der Plattform auf Verhaltenskompatibilität, aber nicht alle Bereiche. Es liegt in der Verantwortung des Implementators, für eine Verhaltenskompatibilität mit dem Android Open Source Project zu sorgen. Aus diesem Grund sollten Geräteimplementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt wichtige Teile des Systems neu zu implementieren.

3.6. API-Namespaces

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

• 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. Geräteimplementierer dürfen also 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 diese 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-library>), von der erhöhten Speichernutzung dieser APIs betroffen sind.

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

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

3.7. Laufzeitkompatibilität

Geräteimplementierungen MÜSSEN das vollständige Dalvik-Ausführformat (DEX) und die Dalvik-Bytecodespezifikation und -Semantik unterstützen . Geräteimplementierer sollten ART, die Referenz-Upstream-Implementierung des Dalvik-Ausführbaren-Formats, 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 Drittanbieteranwendungen, 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 einen App-Widget zur Verfügung stellen können. 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 zum Hinzufügen, Konfigurieren, Ansehen und Entfernen von App-Widgets direkt im Launcher enthalten.
• Geräteimplementierungen MÜSSEN Widgets in der Standardrastergröße von 4 × 4 rendern können. Weitere Informationen finden Sie in der Android SDK-Dokumentation unter Designrichtlinien für App-Widgets.
• Geräteimplementierungen mit Unterstützung für den Sperrbildschirm KÖNNEN Anwendungs-Widgets auf dem Sperrbildschirm unterstützen.

3.8.3. Benachrichtigungen

Android bietet APIs, mit denen Entwickler Nutzer mithilfe von Hardware- und Softwarefunktionen des Geräts über wichtige Ereignisse informieren können.

Mit einigen APIs können Anwendungen Benachrichtigungen senden oder mithilfe von Hardware auf sich aufmerksam machen, insbesondere mit Ton, Vibration und Licht. 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 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 alle Ressourcen (Symbole, Animationsdateien usw.), die in den APIs oder im Symbolstilhandbuch für die Status-/Systemleiste bereitgestellt werden, 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 den Titel/Namen, das Symbol und den Text enthalten, wie in den Android APIs beschrieben .

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.

Implementierungen auf Mobilgeräten MÜSSEN das Aktualisieren, Entfernen, Beantworten und Bündeln von Benachrichtigungen unterstützen, wie in diesem Abschnitt beschrieben .

Außerdem MÜSSEN Implementierungen für Mobilgeräte Folgendes bieten:

• Benachrichtigungen können direkt in der Benachrichtigungsleiste verwaltet werden.
• Die visuelle Aufforderung, das Steuerfeld in der Benachrichtigungsleiste zu öffnen.
• Möglichkeit, Benachrichtigungseinstellungen für ein Paket sowohl im Inline-Steuerfeld als auch in den Einstellungen zu BLOCKIEREN, SCHUMMEN und ZURÜCKSETZEN.

Alle sechs direkten Unterklassen von Notification.Style class MÜSSEN wie in den SDK-Dokumenten beschrieben unterstützt werden .

Geräteimplementierungen, die die Funktion „Bitte nicht stören“ unterstützen, MÜSSEN die folgenden Anforderungen erfüllen:

• Es MUSS eine Aktivität implementiert werden, die auf die Absicht ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS reagiert. Bei Implementierungen mit UI_MODE_TYPE_NORMAL MUSS es sich dabei um eine Aktivität handeln, bei der der Nutzer der App Zugriff auf die Konfigurationen der DND-Richtlinie gewähren oder verweigern kann.
• MUSS: Wenn die Geräteimplementierung dem Nutzer die Möglichkeit bietet, Drittanbieter-Apps Zugriff auf die DND-Richtlinienkonfiguration zu gewähren oder zu verweigern, müssen neben den vom Nutzer erstellten und vordefinierten Regeln auch automatische DND-Regeln angezeigt werden, die von Apps erstellt wurden.
• MÜSSEN die über NotificationManager.Policy übergebenen suppressedVisualEffects-Werte berücksichtigen. Wenn eine App eines der Flags SUPPRESSED_EFFECT_SCREEN_OFF oder SUPPRESSED_EFFECT_SCREEN_ON gesetzt hat, MUSS dem Nutzer im Menü der Einstellungen für die Funktion „Bitte nicht stören“ angezeigt werden, dass die visuellen Effekte unterdrückt werden.

3.8.4. Suchen

Android bietet APIs, mit denen Entwickler die Suche in ihre Anwendungen einbinden und die Daten ihrer Anwendung in die globale Systemsuche einbinden 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 die Suche in ihren eigenen Apps 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 bereitstellen kann. Geräteimplementierungen MÜSSEN die APIs implementieren, mit denen Entwickler diese Benutzeroberfläche wiederverwenden können, um die Suche in ihren eigenen Anwendungen bereitzustellen. Geräteimplementierungen, die die Benutzeroberfläche für die globale 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 die Anzeige von Ergebnissen und Vorschlägen der Websuchmaschine erfolgen.

Bei Android-Geräten sollte und bei Android Automotive-Geräten muss ein Assistent auf dem Gerät implementiert werden, um die Hilfeaktion zu verarbeiten .

Android enthält außerdem die Assist APIs, mit denen Anwendungen festlegen können, wie viele Informationen des aktuellen Kontexts mit dem Assistant auf dem Gerät geteilt werden. 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.

Diese Angabe kann standardmäßig für vorinstallierte Apps deaktiviert werden, die die Assist API und die VoiceInteractionService API verwenden, wenn alle folgenden Anforderungen erfüllt sind:

• Die vorinstallierte App DARF die Freigabe des Kontexts nur dann anfordern, wenn der Nutzer die App auf eine der folgenden Arten aufgerufen hat und die App im Vordergrund ausgeführt wird:

  • Hotword-Aufruf
  • Eingabe der Navigationstaste/-schaltfläche/-geste für ASSIST

• Die Geräteimplementierung MUSS eine Option zum Aktivieren der Anzeige bieten, die sich maximal zwei Navigationsschritte vom Menü „Einstellungen für die Standardspracheingabe und die Assistant App“ entfernt befindet (Abschnitt 3.2.3.5).

3.8.5. Toasts

Mit der Toast API können Anwendungen Endnutzern kurze nicht modale Strings anzeigen, die nach kurzer Zeit verschwinden. 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 des Android SDK nachahmen möchten. Geräteimplementierungen dürfen KEINE der Holo-Designattribute ändern, die für Anwendungen freigegeben sind.

Android umfasst eine „Material“-Designfamilie mit einer Reihe von definierten Stilen, die App-Entwickler verwenden können, wenn sie das Erscheinungsbild des Designthemas auf die Vielzahl der verschiedenen Android-Gerätetypen abstimmen möchten. Geräteimplementierungen MÜSSEN die Designfamilie „Material“ unterstützen und DÜRFEN KEINE der Material Design-Attribute oder deren Assets ändern, die für Anwendungen freigegeben sind.

Android enthält auch die Designfamilie „Gerätestandard“, eine Reihe von definierten Stilen, die App-Entwickler verwenden können, wenn sie das Erscheinungsbild des vom Geräteimplementierer definierten Gerätedesigns anpassen möchten. Geräteimplementierungen KÖNNEN die Standarddesign-Designattribute des Geräts ändern, die für Anwendungen freigegeben sind.

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 bei Android-Geräten Symbole für den Systemstatus (z. B. Signalstärke und Akkustand) und vom System ausgegebene Benachrichtigungen weiß sein, es sei denn, das Symbol weist auf einen problematischen Status hin 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. Weitere Informationen finden Sie unter R.style.

3.8.7. Live-Hintergründe

Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, mit denen Anwendungen Nutzern einen oder mehrere Live-Hintergründe zur Verfügung stellen können. 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 aufgrund von Hardwareeinschränkungen Hintergründe und/oder Anwendungen abstürzen, nicht richtig funktionieren, zu 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-Feature-Flag „android.software.live_wallpaper“ melden.

3.8.8. Aktivitätswechsel

Der Upstream-Android-Quellcode enthält den Übersichtsbildschirm, 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. Bei Geräteimplementierungen, die die Navigationstaste für die letzten Aktivitäten enthalten, wie in Abschnitt 7.2.3 beschrieben, kann die Benutzeroberfläche geändert werden, sie MUSS jedoch die folgenden Anforderungen erfüllen:

• MÜSSEN mindestens 20 angezeigte Aktivitäten unterstützen.
• Es sollte mindestens der Titel von vier Aktivitäten gleichzeitig angezeigt werden.
• Sie MÜSSEN das Verhalten der Bildschirmsperre implementieren und den Nutzern ein Einstellungsmenü zur Verfügung stellen, mit dem sie die Funktion aktivieren und deaktivieren können.
• MÜSSEN die Markierungsfarbe, das Symbol und den Bildschirmtitel in den letzten Elementen anzeigen.
• Es sollte eine Schließfunktion („x“) geben, die aber verzögert werden kann, bis der Nutzer mit den Bildschirmen interagiert.
• Es sollte eine Tastenkombination geben, mit der Sie ganz einfach zur vorherigen Aktivität wechseln können.
• Es KANN sein, dass ähnliche aktuelle Inhalte als Gruppe angezeigt werden, die sich gemeinsam bewegt.
• Es sollte die Schnellwechselaktion zwischen den beiden zuletzt verwendeten Apps auslösen, wenn zweimal auf die Funktionstaste für die zuletzt verwendeten Apps getippt wird.
• Sollte den Splitscreen-Multifenstermodus auslösen, sofern unterstützt, wenn die Taste für die letzten Apps lange gedrückt wird.

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. Geräteimplementierungen, die es Nutzern ermöglichen, Eingabemethoden von Drittanbietern auf dem Gerät zu verwenden, MÜSSEN die Plattformfunktion „android.software.input_methods“ deklarieren und IME APIs gemäß der Definition in der Android SDK-Dokumentation unterstützen.

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. Bei Geräteimplementierungen MUSS die Einstellungsoberfläche als Reaktion auf die Intent-Aktion „android.settings.INPUT_METHOD_SETTINGS“ angezeigt werden.

3.8.10. Mediensteuerung auf dem Sperrbildschirm

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

3.8.11. Bildschirmschoner (früher „Träume“)

Android unterstützt interaktive Bildschirmschoner , die zuvor als „Träume“ bezeichnet wurden. Mit Bildschirmschonern 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 Bildschirmschoner implementiert werden. Andere Arten von Geräteimplementierungen MÜSSEN jedoch Bildschirmschoner unterstützen und eine Einstellungsoption für Nutzer bereitstellen, mit der sie Bildschirmschoner als Reaktion auf die android.settings.DREAM_SETTINGS-Intent konfigurieren können.

3.8.12. Standort

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

3.8.13. Unicode und Schriftart

Android unterstützt die Emoji-Zeichen, die in Unicode 9.0 definiert sind . Alle Geräteimplementierungen MÜSSEN diese Emoji-Zeichen als farbiges Gliederzeichen darstellen können. Wenn Android-Geräteimplementierungen eine IME enthalten, SOLLTE diese eine Eingabemethode für diese Emoji-Zeichen für den Nutzer bereitstellen.

Android-Handheld-Geräte MÜSSEN die Emojis für Hauttöne und vielfältige Familien unterstützen, wie im Unicode Technical Report #51 angegeben .

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

Eine Geräteimplementierung KANN auch keine Multifenstermodi implementieren. Wenn das Gerät jedoch mehrere Aktivitäten gleichzeitig anzeigen kann, MÜSSEN diese Multifenstermodi gemäß den in der Android SDK-Supportdokumentation zum Multifenstermodus beschriebenen Anwendungsverhalten und APIs implementiert werden und die folgenden Anforderungen erfüllen:

• Anwendungen können in der Datei „AndroidManifest.xml“ angeben, ob sie im Multifenstermodus ausgeführt werden können. Das kann entweder explizit über das Attribut android:resizeableActivity oder implizit durch eine targetSdkVersion > 24 erfolgen. Apps, bei denen dieses Attribut in ihrem Manifest explizit auf „false“ gesetzt ist, dürfen nicht im Mehrfenstermodus gestartet werden. Apps, die das Attribut in ihrer Manifestdatei nicht festlegen (targetSdkVersion < 24), können im Mehrfenstermodus gestartet werden. Das System MUSS jedoch eine Warnung anzeigen, dass die App im Mehrfenstermodus möglicherweise nicht wie erwartet funktioniert.
• Geräteimplementierungen dürfen KEIN Splitscreen- oder Freeform-Display anbieten, wenn sowohl die Höhe als auch die Breite des Displays weniger als 440 dp beträgt.
• Geräteimplementierungen mit einer Bildschirmgröße von xlarge MÜSSEN den Freeform-Modus unterstützen.
• Android TV-Geräteimplementierungen MÜSSEN den Modus „Bild-im-Bild“ (PIP) mit mehreren Fenstern unterstützen und das PIP-Fenster oben rechts platzieren, wenn PIP aktiviert ist.
• Geräteimplementierungen mit Unterstützung für mehrere Fenster im PIP-Modus MÜSSEN dem PIP-Fenster mindestens 240 × 135 dp zuweisen.
• Wenn der PIP-Multifenstermodus unterstützt wird, MUSS der Schlüssel KeyEvent.KEYCODE_WINDOW zum Steuern des PIP-Fensters verwendet werden. Andernfalls MUSS der Schlüssel für die Aktivität im Vordergrund verfügbar sein.

3.9. Geräteverwaltung

Android bietet Funktionen, mit denen sicherheitsbewusste Anwendungen Geräteverwaltungsfunktionen auf Systemebene ausführen können, z. B. die Erzwingung von Passwortrichtlinien oder das Löschen von Daten aus der Ferne über die Android Device Administration API. Geräteimplementierungen MÜSSEN eine Implementierung der Klasse DevicePolicyManager bereitstellen. Geräteimplementierungen, die einen sicheren Sperrbildschirm unterstützen, MÜSSEN die gesamte Palette der in der Android SDK-Dokumentation definierten Richtlinien für die Geräteverwaltung implementieren 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 android.software.device_admin-Funktion deklariert wird, MUSS die Bereitstellung der Device Owner App einer Device Policy Client-Anwendung (DPC) wie unten angegeben implementiert werden:

• Wenn für die Geräteimplementierung noch keine Nutzerdaten konfiguriert sind, geschieht Folgendes:
  • Es MUSS true für DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) angegeben werden .
  • Die DPC-Anwendung MUSS als App des Geräteeigentümers in Reaktion auf die Intent-Aktion android.app.action.PROVISION_MANAGED_DEVICE registriert werden .
  • Die DPC-Anwendung MUSS als App des Geräteeigentümers registriert werden, wenn das Gerät die NFC-Unterstützung (Near Field Communication) über das Feature-Flag android.hardware.nfc angibt und eine NFC-Nachricht mit einem Datensatz vom MIME-Typ MIME_TYPE_PROVISIONING_NFC empfängt .
• Wenn die Geräteimplementierung Nutzerdaten enthält, gilt Folgendes:
  • Es MUSS false für die DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) gemeldet werden .
  • Es darf KEINE DPC-Anwendung mehr als App des Geräteeigentümers registriert werden.

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.

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 Inhaber eines neuen verwalteten Profils zu registrieren .

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

Geräteimplementierungen MÜSSEN in den Einstellungen die folgenden Nutzeroptionen bereitstellen, um dem Nutzer anzuzeigen, wenn eine bestimmte Systemfunktion vom Device Policy Controller (DPC) deaktiviert wurde:

• Ein einheitliches Symbol oder eine andere Nutzerfunktion (z. B. das Infosymbol von AOSP) für den Fall, dass eine bestimmte Einstellung durch einen Geräteadministrator eingeschränkt ist.
• Eine kurze Erklärung, die der Geräteadministrator über die setShortSupportMessage angegeben hat .
• Das Symbol der DPC-Anwendung.

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).
• Weisen Sie internen (nicht entfernbaren) Speicher als gemeinsamen Speicher zu (siehe Abschnitt 7.6.2).

Geräte mit verwalteten Profilen MÜSSEN:

• Deklarieren Sie das Plattform-Funktions-Flag android.software.managed_users .
• Unterstützung verwalteter Profile über die android.app.admin.DevicePolicyManager APIs.
• Es darf nur ein einziges verwaltetes Profil erstellt werden .
• Verwenden Sie ein Symbolsymbol (ähnlich dem AOSP-Symbol für Upstream-Arbeiten), um die verwalteten Anwendungen und Widgets sowie andere UI-Elemente mit Symbolen 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 sich die App im Vordergrund im verwalteten Profil befindet, wird ein Toast angezeigt, der darauf hinweist, dass sich der Nutzer im verwalteten Profil befindet.
• Wenn ein verwaltetes Profil vorhanden ist, zeigen Sie in der Intent-Auswahl eine visuelle Aufforderung an, damit der Nutzer den Intent vom verwalteten Profil an den Hauptnutzer oder umgekehrt weiterleiten kann, sofern dies vom Device Policy Controller aktiviert wurde.
• 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 Nutzer oder im verwalteten Profil installiert sind.
  • Unabhängige Verwaltung von Konten im primären Nutzer- oder verwalteten Profil.
• Sorgen Sie dafür, dass die vorinstallierten Telefon-, Kontakt- und Messaging-Apps nach Anruferinformationen aus dem verwalteten Profil (falls vorhanden) und aus dem primären Profil suchen und diese abrufen können, sofern dies vom Device Policy Controller zulässig ist. Wenn Kontakte aus dem verwalteten Profil im vorinstallierten Anrufprotokoll, in der Anrufoberfläche, in Benachrichtigungen zu laufenden und verpassten Anrufen, in Kontakt- und Messaging-Apps angezeigt werden, MÜSSEN sie mit demselben Symbol gekennzeichnet sein, das für Anwendungen im verwalteten Profil verwendet wird.
• 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 gezählt wird.
• Es muss möglich sein, einen separaten Sperrbildschirm anzugeben, der die folgenden Anforderungen erfüllt, um Apps Zugriff zu gewähren, die in einem verwalteten Profil ausgeführt werden.
  • Geräteimplementierungen MÜSSEN die DevicePolicyManager.ACTION_SET_NEW_PASSWORD-Intent einhalten und eine Benutzeroberfläche anzeigen, über die separate Anmeldedaten für den Sperrbildschirm für das verwaltete Profil konfiguriert werden können.
  • Für die Anmeldedaten des Sperrbildschirms des verwalteten Profils MÜSSEN dieselben Speicher- und Verwaltungsmechanismen für Anmeldedaten wie für das übergeordnete Profil verwendet werden, wie auf der Android Open Source Project-Website beschrieben.
  • Die Passwortrichtlinien des DPC MÜSSEN nur auf die Anmeldedaten für den Sperrbildschirm des verwalteten Profils angewendet werden, es sei denn, die DevicePolicyManager-Instanz wird von getParentProfileInstance zurückgegeben .

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 Bedienungshilfen Rückrufe für Nutzer- und Systemereignisse erhalten und alternative Feedbackmechanismen wie Text-zu-Sprache-Funktion, haptisches Feedback und Navigation per Trackball/D-Pad generieren können.

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 android.accessibilityservice APIs unterstützen .
• Geräteimplementierungen (außer Android Automotive) MÜSSEN AccessibilityEvents generieren und diese Ereignisse in Übereinstimmung mit 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.

• Bei Android-Geräten mit Audioausgang wird DRINGEND empfohlen, Bedienungshilfen auf dem Gerät bereitzustellen, die mit den Bedienungshilfen TalkBack** und Schalterzugriff (https://github.com/google/talkback) vergleichbar sind oder diese übertreffen.

• Android-Smartwatches mit Audioausgang MÜSSEN auf dem Gerät eine Bedienungshilfe implementieren, die mit der Funktionalität der Bedienungshilfe TalkBack (https://github.com/google/talkback) vergleichbar ist oder diese übertrifft.
• Geräteimplementierungen MÜSSEN Nutzern in der Ersteinrichtung einen Mechanismus zur Verfügung stellen, mit dem sie relevante Bedienungshilfen aktivieren können, sowie Optionen zum Anpassen der Schrift- und Displaygröße und der Vergrößerungsbewegungen.

** Für Sprachen, die von der Funktion „Spracheingabe“ unterstützt werden.

Wenn ein vorinstallierter Bedienungshilfendienst vorhanden ist, muss es sich um eine {directBootAware}-kompatible App handeln, wenn der Speicher des Geräts mithilfe der dateibasierten Verschlüsselung (File Based Encryption, FBE) verschlüsselt ist.

3.11. Sprachausgabe

Android enthält APIs, mit denen Anwendungen TTS-Dienste (Text-to-Speech) nutzen und Dienstanbieter TTS-Dienste implementieren können. 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. Falls 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.
• Es MUSS eine für Nutzer zugängliche Benutzeroberfläche geben, ü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 Liveinhalten auf Android TV-Geräten. TIF bietet eine Standard-API zum Erstellen von Eingabemodulen, mit denen Android TV-Geräte gesteuert werden. Android-Fernseher-Geräteimplementierungen MÜSSEN das TV Input Framework unterstützen.

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 TV-Anwendung (TV-App) installiert sein. Das Android Open Source Project bietet eine Implementierung der TV App.

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

• Bei Geräteimplementierungen MÜSSEN TIF-basierte Eingaben von Drittanbietern ( Eingabegeräte von Drittanbietern) installiert und verwaltet werden können.
• Bei Geräteimplementierungen kann eine visuelle Trennung zwischen vorinstallierten TIF-basierten Eingaben (installierte Eingaben) und Eingaben von Drittanbietern erfolgen.
• Bei Geräteimplementierungen dürfen die Eingaben von Drittanbietern nicht weiter als eine Navigationsaktion von der TV-App entfernt angezeigt werden (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 MÜSSEN, der aus den Werten in den Feldern TvContract.Programs generiert wird. Das EPG MUSS die folgenden Anforderungen erfüllen:

• Der 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 Eingaben von Drittanbietern dürfen im EPG NICHT weiter als eine Navigationsaktion von den installierten Eingaben entfernt sein.
• Bei einem Kanalwechsel MÜSSEN Geräteimplementierungen EPG-Daten für das aktuell wiedergegebene Programm anzeigen.

3.12.1.2. Navigation

Die TV-App MUSS die Navigation für die folgenden Funktionen über das Steuerkreuz, die Schaltfläche „Zurück“ und die Schaltfläche „Startseite“ auf den Eingabegeräten des Android-Fernsehgeräts (z.B. Fernbedienung, Fernbedienungsanwendung oder Gamecontroller) zulassen:

• Fernsehsender wechseln
• EPG öffnen
• TIF-basierte Eingaben von Drittanbietern konfigurieren und optimieren
• Menü „Einstellungen“ öffnen

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. Die TV-App MUSS die Verknüpfung mit der TV-Eingabe-App anzeigen, sofern diese vorhanden ist.

3.12.1.4. Zeitverschiebung

Android TV-Geräteimplementierungen MÜSSEN die Zeitachsenfunktion unterstützen, mit der Nutzer Liveinhalte pausieren und fortsetzen können. Geräteimplementierungen MÜSSEN Nutzern die Möglichkeit bieten, das aktuell wiedergegebene Programm anzuhalten und fortzusetzen, wenn die Zeitverschiebung für dieses Programm verfügbar ist .

3.12.1.5. TV-Aufnahmen

Bei der Implementierung von Android TV-Geräten wird dringend empfohlen, die TV-Aufzeichnung zu unterstützen. Wenn der TV-Eingang die Aufzeichnung unterstützt, kann der EPG ggf. eine Möglichkeit bieten, ein Programm aufzunehmen, sofern die Aufzeichnung eines solchen Programms nicht untersagt ist. Geräteimplementierungen MÜSSEN eine Benutzeroberfläche zum Abspielen aufgezeichneter Programme bereitstellen.

3.13. Schnelleinstellungen

Android-Geräteimplementierungen MÜSSEN eine UI-Komponente für die Schnelleinstellungen enthalten, die einen schnellen Zugriff auf häufig verwendete oder dringend benötigte Aktionen ermöglicht.

Android enthält die quicksettings API, mit der Drittanbieter-Apps Kacheln implementieren können, die Nutzer neben den vom System bereitgestellten Kacheln in der Benutzeroberfläche der Schnelleinstellungen hinzufügen können. Wenn eine Geräteimplementierung eine Benutzeroberflächenkomponente für die Schnelleinstellungen hat, gilt Folgendes:

• Sie MÜSSEN es Nutzern ermöglichen, Kacheln aus einer Drittanbieter-App zu den Schnelleinstellungen hinzuzufügen oder daraus zu entfernen.
• Es darf KEINE Kachel aus einer Drittanbieter-App automatisch in die Schnelleinstellungen aufgenommen werden.
• Es MÜSSEN alle vom Nutzer hinzugefügten Kacheln von Drittanbieter-Apps neben den vom System bereitgestellten Kacheln für die Schnelleinstellungen angezeigt werden.

3.14. APIs für die Fahrzeugoberfläche

3.14.1. Benutzeroberfläche von Fahrzeugmedien

Jede Geräteimplementierung, die Unterstützung für die Automobilbranche deklariert, MUSS ein UI-Framework enthalten, um Drittanbieter-Apps zu unterstützen, die die APIs MediaBrowser und MediaSession nutzen.

Das UI-Framework, das Drittanbieter-Apps unterstützt, die von MediaBrowser und MediaSession abhängen, hat die folgenden visuellen Anforderungen:

• MediaItem-Symbole und Benachrichtigungssymbole MÜSSEN unverändert angezeigt werden.
• Diese Elemente MÜSSEN wie von MediaSession beschrieben angezeigt werden, z.B. Metadaten, Symbole und Bilder.
• Der App-Titel MUSS zu sehen sein.
• MUSS eine Leiste haben, um die MediaBrowser-Hierarchie darzustellen.

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. Aus diesem Grund sollten Geräteimplementierungen das Paketverwaltungssystem der Referenzimplementierung verwenden.

Der Paketmanager MUSS die Überprüfung von „.apk“-Dateien mit dem APK-Signaturschema v2 und der JAR-Signatur unterstützen .

Geräteimplementierungen dürfen das .apk-, Android-Manifest-, Dalvik-Bytecode- oder RenderScript-Bytecodeformat nicht so erweitern , dass die Installation und Ausführung dieser Dateien auf anderen kompatiblen Geräten verhindert wird.

Geräteimplementierungen dürfen nicht zulassen, dass Apps, die nicht der aktuelle „installer of record“ (eintragsberechtigter Installateur) für das Paket sind, die App ohne Aufforderung im Hintergrund deinstallieren, wie im SDK für die Berechtigung DELETE_PACKAGE dokumentiert. Die einzigen Ausnahmen sind die App zur Überprüfung von Systempaketen, die den Intent PACKAGE_NEEDS_VERIFICATION verarbeitet, und die App für den Speichermanager, die den Intent ACTION_MANAGE_STORAGE verarbeitet.

5. Multimedia-Kompatibilität

5.1. Medien-Codecs

Geräteimplementierungen:

• MÜSSEN die in der Android SDK-Dokumentation angegebenen Hauptmedienformate unterstützen, sofern dies nicht ausdrücklich in diesem Dokument erlaubt ist.

• Es MÜSSEN die in den folgenden Tabellen definierten und über MediaCodecList gemeldeten Medienformate, Encoder, Decoder, Dateitypen und Containerformate unterstützt werden .

• MÜSSEN auch alle Profile decodieren können, die in CamcorderProfile gemeldet werden.

• MÜSSEN alle Formate decodieren können, die sie codieren können. Dazu gehören alle Bitstreams, die von den Encodern generiert werden.

Codecs sollten eine minimale Codec-Latenz anstreben. Mit anderen Worten: Codecs –

• DÜRFEN Eingabebuffer nicht verbrauchen und speichern und geben Eingabebuffer nur nach der Verarbeitung zurück.
• Dekodierte Puffer DÜRFEN nicht länger als im Standard angegeben (z.B. SPS) aufbewahrt werden.
• Die codierten Puffer dürfen NICHT länger als von der GOP-Struktur erforderlich gehalten werden.

Alle in der folgenden Tabelle aufgeführten 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, Patentlizenzen der entsprechenden Patentinhaber erforderlich sein können.

5.1.1. Audio-Codecs

Format/Codec	Encoder	Decoder	Details	Unterstützte Dateitypen/Containerformate
MPEG-4 AAC-Profil (AAC LC)	ERFORDERLICH 1	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 wird nicht unterstützt) MPEG-TS (.ts, nicht suchbar, Android 3.0 und höher)
MPEG-4 HE AAC Profile (AAC+)	ERFORDERLICH 1 (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 Profile (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)	ERFORDERLICH 1 (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	ERFORDERLICH 3	ERFORDERLICH 3	4,75 bis 12,2 kbit/s bei 8 kHz abgetastet	3GPP (.3gp)
AMR-WB	ERFORDERLICH 3	ERFORDERLICH 3	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 für 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	ERFORDERLICH 4 (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), Ogg(.ogg)

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

2 Die Aufzeichnung oder Wiedergabe kann in Mono oder Stereo erfolgen. Bei der Dekodierung von AAC-Eingabepuffern von Mehrkanalstreams (d. h. mehr als zwei Kanäle) in PCM über den Standard-AAC-Audiodecoder in der android.media.MediaCodec API MUSS Folgendes unterstützt werden:

• die Dekodierung ohne Downmix erfolgt (z.B. muss ein 5.0-AAC-Stream in fünf PCM-Kanäle decodiert werden, ein 5.1-AAC-Stream in sechs PCM-Kanäle),
• Metadaten für den Dynamikbereich, wie in „Dynamic Range Control (DRC)“ in ISO/IEC 14496-3 definiert, und die DRC-Schlüssel von android.media.MediaFormat, um das dynamischbereichsbezogene Verhalten des Audiodecoders zu konfigurieren. Die AAC-DRC-Schlüssel wurden in API 21 eingeführt und sind: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL und KEY_AAC_ENCODED_TARGET_LEVEL.

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

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

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)
Raw		REQUIRED		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.3. Video-Codecs

• Codecs, die die Unterstützung von HDR-Profilen angeben, MÜSSEN das Parsen und die Verarbeitung von statischen HDR-Metadaten unterstützen.

• Wenn ein Mediencodec die Unterstützung von Zwischenaktualisierungen angibt, muss er die Aktualisierungszeiten im Bereich von 10 bis 60 Frames unterstützen und innerhalb von 20% des konfigurierten Aktualisierungszeitraums ordnungsgemäß funktionieren.

• Videocodecs MÜSSEN Ausgabe- und Eingabe-Bytebuffergrößen unterstützen, die den größten möglichen komprimierten und unkomprimierten Frame gemäß Standard und Konfiguration aufnehmen, aber auch nicht überbelegen.

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

Format/Codec	Encoder	Decoder	Details	Unterstützte Dateitypen/ Containerformate
H.263	MAI	MAI		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	ERFORDERLICH 2	ERFORDERLICH 2	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		ERFORDERLICH 5	Weitere Informationen finden Sie unter Abschnitt 5.3.	MPEG-4 (.mp4)
MPEG-2		EMPFOHLEN 6	Profil "Main"	MPEG2-TS
MPEG-4 SP		ERFORDERLICH 2		3GPP (.3gp)
VP8 3	ERFORDERLICH 2 (Android 4.3 und höher)	ERFORDERLICH 2 (Android 2.3.3 und höher)	Weitere Informationen finden Sie in den Abschnitten 5.2 und 5.3.	WebM (.webm) Matroska (.mkv, Android 4.0 und höher) 4
VP9		ERFORDERLICH 2 (Android 4.4 oder höher)	Weitere Informationen finden Sie unter Abschnitt 5.3.	WebM (.webm) Matroska (.mkv, Android 4.0 und höher) 4

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

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

3. Für eine akzeptable Qualität von Webvideostreaming und Videokonferenzdiensten SOLLTE bei Geräteimplementierungen ein Hardware-VP8-Codec verwendet werden, der die Anforderungen 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

H.264-, VP8-, VP9- und HEVC-Videoencoder:

• MÜSSEN dynamisch konfigurierbare Bitraten unterstützen.
• MÜSSEN variable Frameraten unterstützen, wobei der Videoencoder die momentane Framedauer anhand der Zeitstempel der Eingabebuffer bestimmen und den Bitbucket basierend auf dieser Framedauer zuweisen SOLLTE.

H.263- und MPEG-4-Videoencoder MÜSSEN dynamisch konfigurierbare Bitraten unterstützen.

Alle Videoencoder MÜSSEN die folgenden Bitrate-Ziele über zwei gleitende Zeitfenster hinweg einhalten:

• Sie sollte nicht mehr als etwa 15% über der Bitrate zwischen den Intervallen der Intraframe-Frames (I-Frames) liegen.
• Die Bandbreitenüberschreitung sollte in einem gleitenden Fenster von 1 Sekunde nicht mehr als 100% betragen.

5.2.1. H.263

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

5.2.2. H-264

Android-Geräteimplementierungen mit H.264-Codec-Unterstützung:

• MÜSSEN das Referenzprofil der Stufe 3 unterstützen.
  Die Unterstützung von ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist jedoch OPTIONAL. Außerdem wird empfohlen, ASO, FMO und RS nicht für das Baseline-Profil zu verwenden, um die Kompatibilität mit anderen Android-Geräten zu gewährleisten.
• MÜSSEN die Videocodierungsprofile für SD (Standard Definition) in der folgenden Tabelle unterstützen.
• Sollte Main Profile Level 4 unterstützen.
• MÜSSEN die HD-Videocodierungsprofile (High Definition) wie in der folgenden Tabelle angegeben unterstützen.
• Außerdem wird für Android TV-Geräte DRINGEND empfohlen, HD 1080p-Videos mit 30 fps zu codieren.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p 1	HD 1080p 1
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 TV-Geräte EMPFOHLENE Einstellung.

5.2.3. VP8

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

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

1 Wenn von der Hardware unterstützt.

5.3. Videodekodierung

Geräteimplementierungen:

• MÜSSEN die dynamische Videoauflösung und die Framerate-Umschaltung über die Standard-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.

• Implementierungen, die den Dolby Vision-Decoder unterstützen:

• Es MUSS ein Dolby Vision-fähiger Extractor bereitgestellt werden.

• MÜSSEN Dolby Vision-Inhalte korrekt auf dem Display des Geräts oder über einen Standard-Videoausgang (z.B. HDMI).

• Bei Implementierungen, die einen Dolby Vision-kompatiblen Extractor bereitstellen, MUSS der Titelindex der abwärtskompatiblen Basisebenen (falls vorhanden) mit dem Titelindex der kombinierten Dolby Vision-Ebene übereinstimmen.

5.3.1. MPEG-2

Android-Geräteimplementierungen mit MPEG-2-Decodern müssen das Main Profile High Level unterstützen.

5.3.2. H.263

Android-Geräteimplementierungen mit H.263-Decodern MÜSSEN das Baseline-Profil der Ebene 30 und der Ebene 45 unterstützen.

5.3.3. MPEG-4

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

5.3.4. H.264

Implementierungen von Android-Geräten mit H.264-Decodern:

• MUSS Main Profile Level 3.1 und Baseline Profile unterstützen.
  Die Unterstützung von ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) und RS (Redundant Slices) ist OPTIONAL.
• MÜSSEN Videos mit den in der folgenden Tabelle aufgeführten SD-Profilen (Standarddefinition) decodieren können, die mit dem Baseline-Profil und dem Hauptprofil der Ebene 3.1 codiert sind (einschließlich 720p30).
• MÜSSEN in der Lage sein, Videos mit den HD-Profilen (High Definition) zu decodieren, wie in der folgenden Tabelle angegeben.
• Außerdem gilt Folgendes für Android TV-Geräte:
  • MUSS High Profile Level 4.2 und das Dekodierungsprofil HD 1080p60 unterstützen.
  • MÜSSEN Videos mit beiden HD-Profilen decodieren können, die in der folgenden Tabelle aufgeführt sind und entweder mit dem Baseline-Profil, dem Main-Profil oder dem High-Profil der Stufe 4.2 codiert sind.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p 1	HD 1080p 1
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 fps 2)
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.

5.3.5. H.265 (HEVC)

Implementierungen von Android-Geräten, die den H.265-Codec wie in Abschnitt 5.1.3 beschrieben unterstützen :

• Es MUSS das Main Profile Level 3 Main Tier und die SD-Videodekodierungsprofile unterstützen, wie in der folgenden Tabelle angegeben.
• MÜSSEN die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
• MÜSSEN die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen, wenn ein Hardware-Decoder vorhanden ist.
• Außerdem haben Android TV-Geräte folgende Vorteile:
• MUSS das Decodierungsprofil HD 720p unterstützen.
• Es wird dringend empfohlen, das Decodierungsprofil für HD 1080p zu unterstützen. Wenn das Decodierungsprofil für HD 1080p unterstützt wird, MUSS es das Hauptprofil der Hauptebene 4.1 unterstützen.
• SOLLTE das UHD-Decodierungsprofil unterstützen. Wenn das UHD-Decodierungsprofil unterstützt wird, MUSS der Codec das Main10 Level 5 Main Tier-Profil unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p	HD 1080p	UHD
Videoauflösung	352 × 288 px	720 x 480 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	30 fps (60 fps 1)	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äteimplementierungen mit H.265-Hardwaredekodierung.

5.3.6. VP8

Implementierungen von Android-Geräten, die den VP8-Codec wie in Abschnitt 5.1.3 beschrieben unterstützen :

• MÜSSEN die SD-Dekodierungsprofile in der folgenden Tabelle unterstützen.
• MÜSSEN die HD-Dekodierungsprofile in der folgenden Tabelle unterstützen.
• Android TV-Geräte MÜSSEN das Dekodierungsprofil HD 1080p60 unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p 1	HD 1080p 1
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 fps 2)	30 (60 fps 2)
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.

5.3.7. VP9

Implementierungen von Android-Geräten, die den VP9-Codec wie in Abschnitt 5.1.3 beschrieben unterstützen :

• MÜSSEN die SD-Video-Dekodierungsprofile unterstützen, die in der folgenden Tabelle aufgeführt sind.
• MÜSSEN die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen.
• MÜSSEN die HD-Dekodierungsprofile wie in der folgenden Tabelle angegeben unterstützen, wenn ein Hardware-Decoder vorhanden ist.

• Außerdem haben Android TV-Geräte folgende Vorteile:

  • MUSS das Decodierungsprofil HD 720p unterstützen.
  • Es wird dringend empfohlen, das Decodierungsprofil für HD 1080p zu unterstützen.
  • SOLLTE das UHD-Decodierungsprofil 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 720p	HD 1080p	UHD
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	30 fps (60 fps 1)	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äteimplementierungen mit VP9-Hardware-Decodierung.

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 können sie nach dem Upgrade auf die zukünftige Version nicht mit Android kompatibel sein.

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

Die Audioquelle „android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION“ MUSS die Aufnahme mit einer der Abtastraten 44.100 und 48.000 unterstützen.

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 android.media.audiofx.NoiseSuppressor API 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 erfassen, 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. 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 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äteimplementierungen MÜSSEN die Unterstützung der Master-Lautstärke des Systems und die Lautstärkedämpfung der digitalen Audioausgabe auf unterstützten Ausgängen umfassen, mit Ausnahme der komprimierten Audio-Passthrough-Ausgabe (bei der keine Audiodekodierung auf dem Gerät erfolgt).

Bei der Implementierung von Android Automotive-Geräten MUSS die Audiolautstärke für jeden Audiostream separat anhand des Inhaltstyps oder der Verwendung gemäß AudioAttributes und der Verwendung von Auto-Audio gemäß android.car.CarAudioManager angepasst werden können .

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 der Ausgabe des entsprechenden Tons über einen On-Device-Wandler oder dem Verlassen des Signals über einen Port, das extern beobachtet 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 Ton von der Umgebung an einen On-Device-Transducer oder ein Signal über einen Port an das Gerät gesendet wird, und dem Zeitpunkt, zu dem eine Anwendung den entsprechenden Frame mit PCM-codierten Daten liest.
• Eingabe verloren . Der erste Teil eines Eingabesignals, der nicht verwendet werden kann oder nicht verfügbar ist.
• Cold-Input-Latenz . Die Summe aus der verlorenen Eingabezeit und der Eingabelatenz für den ersten Frame, wenn das Audioeingabesystem vor der Anfrage inaktiv und ausgeschaltet war.
• kontinuierliche Eingabelatenz . Die Eingabelatenz für nachfolgende Frames, während das Gerät Audio aufnimmt.
• Jitter bei kaltem Start . Die Variabilität zwischen verschiedenen Messungen der Latenzwerte der Kaltstartausgabe.
• Jitter bei kaltem Eingang . Die Variabilität 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 gibt der App Zeit, das Signal zu verarbeiten und die Phasendifferenz zwischen Eingabe- und Ausgabestreams zu verringern.
• OpenSL ES PCM-Puffer-Queue-API Die PCM-bezogenen OpenSL ES APIs im Android NDK .

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 Erstkalibrierung 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. Wenn die Geräteimplementierung diese Anforderungen nicht erfüllt, darf keine Unterstützung für Audio mit niedriger Latenz gemeldet werden.

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 Mediennetzwerkprotokolle für die Audio- und Videowiedergabe unterstützen, wie in der Android SDK-Dokumentation angegeben. Insbesondere MÜSSEN die Geräte die folgenden Mediennetzwerkprotokolle unterstützen:

• Progressives HTTP(S)-Streaming
  Alle erforderlichen Codecs und Containerformate in Abschnitt 5.1 MÜSSEN über HTTP(S) unterstützt werden.

• HTTP Live Streaming-Entwurfsprotokoll, Version 7
  Folgende Mediensegmentformate MÜSSEN unterstützt werden:

Segmentformate	Referenzen	Erforderliche Codec-Unterstützung
MPEG-2-Transportstream	ISO 13818	Video-Codecs: H264 AVC MPEG-4 SP MPEG-2 Abschnitt 5.1.3 enthält Details zu H264 AVC, MPEG2-4 SP und MPEG-2. Audio-Codecs: AAC Details zu AAC und seinen Varianten findest du unter Abschnitt 5.1.1.
AAC mit ADTS-Framing und ID3-Tags	ISO 13818-7	Weitere Informationen zu AAC und seinen Varianten findest du in Abschnitt 5.1.1.
WebVTT	WebVTT

• RTSP (RTP, SDP)

  Das folgende RTP-Audio-Videoprofil und die zugehörigen Codecs MÜSSEN unterstützt werden. Ausnahmen finden Sie in den Fußnoten der Tabelle in Abschnitt 5.1 .

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

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 angeben, 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äte 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 diese Anforderung erfüllt.

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.

Die MIDI-fähigen Hardware-Transporte sind:

• USB-Hostmodus (Abschnitt 7.7 USB)
• USB-Peripheriegerätemodus (Abschnitt 7.7 USB)
• MIDI over Bluetooth LE in zentraler Rolle (Abschnitt 7.4.3 Bluetooth)

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.

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

• Die Geräteimplementierung MUSS die Unterstützung der Funktion „android.hardware.audio.low_latency“ melden.
• Die kontinuierliche Audio-Rücklauflatenz, 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-Rücklauflatenz ü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 die Ausgabe in Stereo und acht Kanälen mit 20-Bit- oder 24-Bit-Tiefe und 192 kHz ohne Bittiefeverlust oder Resampling unterstützen.
• Die Geräteimplementierung MUSS die Unterstützung der Funktion „android.software.midi“ melden.
• Wenn das Gerät eine 4-polige 3,5-mm-Audiobuchse 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.

Latenzen und USB-Audioanforderungen MÜSSEN mit der OpenSL ES PCM-Pufferwarteschlangen-API erfüllt werden.

Außerdem sollte eine Geräteimplementierung, die die Unterstützung dieser Funktion meldet, Folgendes tun:

• Eine nachhaltige CPU-Leistung bieten, während Audio aktiv ist.
• Abweichungen der Audiouhr von der Standardzeit minimieren
• Minimiert die Abweichung der Audiotaktuhr im Vergleich zur CPU CLOCK_MONOTONIC, wenn beide aktiv sind.
• Minimieren der Audiolatenz über On-Device-Wandler.
• Minimiert die Audiolatenz über digitale USB-Audioverbindungen.
• Dokumentieren Sie Audiolatenzmessungen über alle Pfade.
• Minimieren Sie den Jitter bei den Callback-Eingabezeiten für den Abschluss des Audiopuffers, da dies sich auf den nutzbaren Prozentsatz der vollen CPU-Bandbreite durch den Callback auswirkt.
• Bei normaler Nutzung und bei der angegebenen Latenz dürfen keine Audiounterbrechungen (Ausgabe) oder Überläufe (Eingabe) auftreten.
• Die Latenz zwischen den Kanälen darf keinen Unterschied aufweisen.
• Minimieren Sie die durchschnittliche MIDI-Latenz über alle Transporte hinweg.
• Minimieren Sie die Variabilität der MIDI-Latenz bei Belastung (Jitter) über alle Transporte hinweg.
• Gib genaue MIDI-Zeitstempel für alle Übertragungen an.
• Minimieren Sie das Rauschen des Audiosignals über die Gerätewandler, einschließlich der Zeit unmittelbar nach dem Kaltstart.
• Die Audiotaktdifferenz zwischen der Eingabe- und Ausgabeseite der entsprechenden Endpunkte muss null sein, wenn beide aktiv sind. Beispiele für entsprechende Endpunkte sind das Mikrofon und der Lautsprecher auf dem Gerät oder der Audioeingang und -ausgang.
• Wenn beide aktiv sind, müssen Sie die Callbacks für den Abschluss des Audiopuffers für die Eingabe- und Ausgabeseite der entsprechenden Endpunkte im selben Thread verarbeiten und den Ausgabe-Callback sofort nach der Rückkehr aus dem Eingabe-Callback aufrufen. Wenn es nicht möglich ist, die Rückrufe im selben Thread zu verarbeiten, geben Sie den Ausgaberückruf kurz nach dem Eingaberückruf ein, damit die Anwendung eine einheitliche Zeitabfolge für die Eingabe- und Ausgabeseite hat.
• Minimieren Sie die Phasendifferenz zwischen der HAL-Audiopufferung für die Eingabe- und Ausgabeseite der entsprechenden Endpunkte.
• Minimieren Sie die Touch-Latenz.
• Minimieren Sie die Variabilität der Touch-Latenz bei Belastung (Jitter).

5.11. Aufnahme für „Unverarbeitet“

Ab Android 7.0 wurde eine neue Aufnahmequelle hinzugefügt. Der Zugriff erfolgt über die Audioquelle android.media.MediaRecorder.AudioSource.UNPROCESSED. In OpenSL ES kann über die Aufnahmevoreinstellung SL_ANDROID_RECORDING_PRESET_UNPROCESSED darauf zugegriffen werden .

Ein Gerät MUSS alle folgenden Anforderungen erfüllen, um die Unterstützung der unverarbeiteten Audioquelle über die android.media.AudioManager-Property PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED zu melden :

• Das Gerät MUSS im mittleren Frequenzbereich eine nahezu flache Amplitude-zu-Frequenz-Charakteristik aufweisen: insbesondere ± 10 dB von 100 Hz bis 7.000 Hz.

• Das Gerät MUSS im niedrigen Frequenzbereich Amplitudenwerte aufweisen: insbesondere von ± 20 dB von 5 Hz bis 100 Hz im Vergleich zum Mittelfrequenzbereich.

• Das Gerät MUSS Amplituden im Hochfrequenzbereich aufweisen: insbesondere von ± 30 dB von 7.000 Hz bis 22 kHz im Vergleich zum Mittelfrequenzbereich.

• Die Empfindlichkeit des Audioinputs MUSS so eingestellt sein, dass eine Sinustonquelle mit 1.000 Hz, die bei 94 dB Schalldruckpegel (SPL) wiedergegeben wird, eine Antwort mit einem RMS von 520 für 16‑Bit-Samples (oder −36 dB Vollskala für Gleitkommazahlen mit doppelter Genauigkeit) liefert.

• SNR > 60 dB (Unterschied zwischen 94 dB SPL und dem äquivalenten SPL des Eigenrauschens, A-bewertet)

• Die Gesamtharmonische Verzerrung darf bei 1 kHz bei einem Eingangspegel von 90 dB SPL am Mikrofon nicht mehr als 1% betragen.

• Die einzige Signalverarbeitung, die im Pfad zulässig ist, ist ein Pegelmultiplikator, um den Pegel in den gewünschten Bereich zu bringen. Dieser Pegelmultiplikator DARF KEINE Verzögerung oder Latenz im Signalpfad verursachen.

• Im Pfad ist keine andere Signalverarbeitung zulässig, z. B. automatische Verstärkungsregelung, Hochpassfilter oder Echounterdrückung. Wenn die Architektur aus irgendeinem Grund eine Signalverarbeitung enthält, MUSS diese deaktiviert werden und darf keine zusätzliche Latenz oder Verzögerung im Signalpfad verursachen.

Alle SPL-Messungen werden direkt neben dem zu testenden Mikrofon durchgeführt.

Bei mehreren Mikrofonkonfigurationen gelten diese Anforderungen für jedes Mikrofon.

Es wird dringend empfohlen, dass ein Gerät so viele Anforderungen wie möglich für den Signalpfad der unbearbeiteten Aufnahmequelle erfüllt. Ein Gerät muss jedoch alle oben aufgeführten Anforderungen erfüllen, wenn es die unbearbeitete Audioquelle unterstützt.

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)
  • Geräteimplementierungen MÜSSEN alle im Android SDK dokumentierten adb-Funktionen unterstützen, einschließlich dumpsys .
  • 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 eine Geräteimplementierung den USB-Peripheriemodus nicht enthält, MUSS die Android Debug Bridge über ein lokales Netzwerk (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)
  • 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 aktiviert hat.
• Monkey-Geräteimplementierungen MÜSSEN das Monkey-Framework enthalten und für Anwendungen verfügbar machen.
• SysTrace
  • 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, Einstellungen für die App-Entwicklung zu konfigurieren. Geräteimplementierungen MÜSSEN die Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS einhalten, um Einstellungen für die Anwendungsentwicklung anzuzeigen. Die Upstream-Android-Implementierung blendet das Menü „Entwickleroptionen“ standardmäßig aus und ermöglicht es Nutzern, die Entwickleroptionen zu starten, nachdem sie siebenmal auf das Menüelement Einstellungen > Informationen zum Gerät > Build-Nummer gedrückt haben. Geräteimplementierungen MÜSSEN eine einheitliche Nutzung der Entwickleroptionen ermöglichen. Insbesondere MÜSSEN die Entwickleroptionen bei Geräteimplementierungen standardmäßig ausgeblendet sein und es MUSS einen Mechanismus zum Aktivieren der Entwickleroptionen geben, der mit der Android-Implementierung übereinstimmt.

7. Hardwarekompatibilität

Wenn ein Gerät eine bestimmte Hardwarekomponente mit einer entsprechenden API für Drittanbieterentwickler enthält, 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 weiterhin 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, die keine Smartphones sind, müssen diese APIs als sinnvolle No-Ops implementiert werden.

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

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 verschiedenen Hardwarekonfigurationen reibungslos funktionieren . 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 Spannweite 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 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, normalisiert auf ein Display mit 160 dpi, berechnet als: Pixel = dpi * (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 Anwendungen, 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 definiert und von der übergeordneten Android-Plattform bestimmt. Insbesondere MÜSSEN Geräteimplementierungen die korrekte Bildschirmgröße gemäß den folgenden logischen Bildschirmabmessungen in Dichte-unabhängigen Pixeln (dp) angeben.

• Die Bildschirmgröße der Geräte muss mindestens 426 dp × 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.

Darüber hinaus gilt Folgendes:

• Android-Smartwatches MÜSSEN ein Display mit einer physischen Diagonale von 28 bis 64 mm haben.
• Android Automotive-Geräte MÜSSEN ein Display mit einer physischen Diagonale von mindestens 6 Zoll haben.
• Android Automotive-Geräte MÜSSEN eine Bildschirmgröße von mindestens 750 dp × 480 dp 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.

Apps geben optional über das Attribut <supports-screens> in der Datei „AndroidManifest.xml“ an, welche Bildschirmgrößen sie unterstützen. 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

Für das Seitenverhältnis des physischen Displays gibt es keine Einschränkungen. Das Seitenverhältnis der Oberfläche, auf der Apps von Drittanbietern gerendert werden, und das aus den über DisplayMetrics gemeldeten Werten abgeleitet werden kann, MUSS jedoch die folgenden Anforderungen erfüllen:

• Wenn uiMode als UI_MODE_TYPE_WATCH konfiguriert ist, kann der Seitenverhältniswert auf 1,0 (1:1) festgelegt werden.
• Wenn die Drittanbieter-App über das Attribut android:resizeableActivity angibt, dass sie die Größe ändern kann, gibt es keine Einschränkungen für den Seitenverhältniswert.
• In allen anderen Fällen MUSS das Seitenverhältnis zwischen 1,3333 (4:3) und 1,86 (ungefähr 16:9) liegen, es sei denn, die App gibt über den Metadatenwert maxAspectRatio ausdrücklich an, dass sie ein höheres Bildschirmseitenverhältnis unterstützt.

7.1.1.3. Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe von standardmäßigen logischen Dichten, die Entwicklern helfen, ihre Anwendungsressourcen zu optimieren. Standardmäßig MÜSSEN Geräteimplementierungen über die DENSITY_DEVICE_STABLE API nur eine der folgenden logischen Android-Framework-Dichten melden und dieser Wert DARF sich zu keinem Zeitpunkt ändern. Das Gerät KANN jedoch eine andere beliebige Dichte melden, je nachdem, welche Änderungen an der Displaykonfiguration der Nutzer nach dem ersten Start vorgenommen hat (z. B. Displaygröße).

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

Bei Geräteimplementierungen sollte die Standarddichte des Android-Frameworks definiert werden, die der physischen Dichte des Bildschirms 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.

Bei Geräteimplementierungen wird DRINGEND empfohlen, Nutzern eine Einstellung zum Ändern der Bildschirmgröße zur Verfügung zu stellen. Wenn es eine Implementierung zum Ändern der Displaygröße des Geräts gibt, MUSS sie der AOSP-Implementierung entsprechen, wie unten angegeben:

• Die Displaygröße darf nicht größer als das 1,5-Fache der nativen Dichte skaliert werden oder eine effektive Mindestbildschirmgröße von weniger als 320 dp (entspricht dem Ressourcenqualifizierer „sw320dp“) aufweisen, je nachdem, was zuerst eintritt.
• Die Displaygröße darf NICHT auf weniger als 0,85-mal der nativen Dichte skaliert werden.
• Für eine gute Nutzerfreundlichkeit und einheitliche Schriftgrößen wird die folgende Skalierung der Optionen für native Anzeigen empfohlen (unter Einhaltung der oben genannten Limits):
• Klein: 0,85x
• Standard: 1x (native Displayskala)
• Groß: 1,15-fach
• Größer: 1,3-fach
• Größter Wert: 1,45-fach

7.1.2. Messwerte für Displaykampagnen

Geräteimplementierungen MÜSSEN korrekte Werte für alle in android.util.DisplayMetrics definierten Displaymesswerte melden und MÜSSEN dieselben Werte melden, unabhängig davon, ob der eingebettete oder externe Bildschirm 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 durch Anwendungen in 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, 3.1 oder 3.2 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 beschrieben.

Geräteimplementierungen MÜSSEN sich auch korrekt als Unterstützer von OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1 oder OpenGL 3.2 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, 3.1 oder 3.2 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, 3.1 oder 3.2 angeben, MUSS libGLESv2.so zusätzlich zu den OpenGL ES 2.0-Funktionssymbolen die entsprechenden Funktionssymbole exportieren.

Android bietet ein OpenGL ES-Erweiterungspaket mit Java-Schnittstellen und nativer Unterstützung für erweiterte Grafikfunktionen wie Tessellation und das ASTC-Texturkomprimierungsformat. Android-Geräteimplementierungen MÜSSEN das Erweiterungspaket unterstützen, wenn das Gerät OpenGL ES 3.2 unterstützt, und KÖNNEN es andernfalls unterstützen. Wenn das Erweiterungspaket vollständig unterstützt wird, MUSS das Gerät die Unterstützung ü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 alle unterstützten Erweiterungsstrings über die verwalteten und nativen OpenGL ES APIs melden und dürfen umgekehrt keine Erweiterungsstrings melden, die sie nicht unterstützen.

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

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

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 ein Verhalten zeigen, das der Android SDK-Dokumentation zur Hardwarebeschleunigung entspricht .

Android enthält ein TextureView-Objekt, mit dem Entwickler hardwarebeschleunigte OpenGL ES-Texturen direkt als Rendering-Ziele in 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 einem Video aufzeichnet. Geräteimplementierungen MÜSSEN die Erweiterung EGL_ANDROID_RECORDABLE unterstützen.

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

Android bietet einen „Kompatibilitätsmodus“, in dem das Framework mit einer „normalen“ Bildschirmgröße (320 dp Breite) arbeitet. Dieser Modus ist für ältere Anwendungen gedacht, die nicht für alte Android-Versionen entwickelt wurden, die noch keine Unabhängigkeit von der Bildschirmgröße hatten.

• 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 heißt, die Auslöser oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert wird, und das Verhalten des Kompatibilitätsmodus selbst DÜRFEN NICHT geändert werden.

7.1.6. Displaytechnologie

Die Android-Plattform enthält APIs, mit denen Anwendungen auf dem Display ansprechende Grafiken 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, sowie 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 Display Manager API wie in der Android SDK-Dokumentation beschrieben implementieren.

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. Softkeyboards) erstellen können, wie unter http://developer.android.com beschrieben .
• Es MUSS mindestens eine Soft-Tastatur implementiert sein (unabhängig davon, ob eine Hardwaretastatur 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 angegebenen Formate entspricht (QWERTY oder 12-Tasten).

7.2.2. Bedienung ohne Touchscreen

Geräteimplementierungen:

• Eine Option zur Bedienung ohne Touchbedienung (Trackball, D-Pad oder Rad) kann AUSGELASSEN WERDEN, wenn es sich bei der Geräteimplementierung nicht um ein Android TV-Gerät handelt.
• Es MUSS der korrekte Wert für android.content.res.Configuration.navigation angegeben werden .
• Es MUSS ein angemessener alternativer Mechanismus für die Benutzeroberfläche zur Auswahl und Bearbeitung von Text vorhanden sein, der mit Eingabeverwaltungs-Engines kompatibel ist. Die Upstream-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“ (zugeordnet den Tastenereignissen KEYCODE_HOME, KEYCODE_APP_SWITCH und KEYCODE_BACK) sind für die Android-Navigation unerlässlich und daher:

• Bei Android-Handheld-Implementierungen MÜSSEN die Funktionen „Startseite“, „Letzte Apps“ 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, das Gerät befindet sich in UI_MODE_TYPE_WATCH .
• Bei Android-Smartwatch-Implementierungen und bei keinem anderen Android-Gerätetyp KANN das Ereignis „Langes Drücken“ für das Tastenereignis KEYCODE_BACK verwendet werden, ohne dass es an die App im Vordergrund gesendet wird.
• Android Automotive-Implementierungen MÜSSEN die Startbildschirmfunktion 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 Teil 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 Wischen) zugänglich sein, wenn sie sichtbar sind.

Die Funktion „Letzte“ 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 älteren Android-Versionen umgestellt werden und physische Navigationstasten, aber keine Taste 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 7.1 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. Bei einer Geräteimplementierung, die vor Android 4.4 eingeführt wurde, aber auf Android 7.1 umgestellt wird, wird dies EMPFOHLEN.
• Die Position des Pop-ups für das Dreipunkt-Menü, das durch Auswahl der Dreipunkt-Schaltfläche in der Aktionsleiste angezeigt wird, darf NICHT geändert werden.
• Das Pop-up für die Aktionsüberlaufliste 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 und/oder VoiceInteractionService unterstützen, MÜSSEN eine Assistenz-App mit einer einzelnen Interaktion (z.B. Tippen, Doppelklicken oder Geste) starten können, wenn andere Navigationstasten sichtbar sind. Wir empfehlen DRINGEND, für diese Interaktion die Startbildschirmtaste lange zu drücken. Durch die festgelegte Interaktion MUSS die vom Nutzer ausgewählte Assistenz-App gestartet werden, d. h. die App, die einen VoiceInteractionService implementiert, oder eine Aktivität, die den Intent ACTION_ASSIST verarbeitet.

Bei Geräteimplementierungen kann ein bestimmter Bereich des Bildschirms 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 Bereich des Displays verwenden, der für Apps nicht verfügbar ist. Sie DÜRFEN den für Apps verfügbaren Bereich 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 Anwendungen 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 in Apps SYSTEM_UI_FLAG_LOW_PROFILE angegeben ist.
• Bei Geräteimplementierungen MÜSSEN die Navigationstasten ausgeblendet werden, wenn Anwendungen SYSTEM_UI_FLAG_HIDE_NAVIGATION angeben.

7.2.4. Touchscreen-Eingabe

Geräteimplementierungen MÜSSEN eine Art Zeiger-Eingabesystem haben (entweder mausähnlich oder Touch). Wenn eine Geräteimplementierung jedoch kein Eingabesystem für Zeiger unterstützt, darf die Geräteimplementierung die Funktionskonstante „android.hardware.touchscreen“ oder „android.hardware.faketouch“ NICHT melden. Geräteimplementierungen mit einem Eingabesystem für Eingabestifte:

• Sollte vollständig unabhängige Mauszeiger unterstützen, wenn das Eingabesystem des Geräts mehrere Mauszeiger unterstützt.
• Der Wert von android.content.res.Configuration.touchscreen MUSS dem Typ des Touchscreens auf dem Gerät entsprechen.

Android unterstützt eine Vielzahl von Touchscreens, Touchpads und Fake-Touch-Eingabegeräten. Touchscreen-basierte Geräteimplementierungen sind mit einem Display verbunden, sodass der Nutzer den Eindruck hat, Elemente direkt auf dem Bildschirm zu bearbeiten. Da der Nutzer den Bildschirm direkt berührt, 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ähernd nachahmt. Eine Maus oder Fernbedienung, die einen Cursor auf dem Bildschirm 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 Funktionskonstante „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“ deklarieren, 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 Eingabe 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 melden und MÜSSEN nur „android.hardware.faketouch“ melden, wenn sie die Anforderungen für Fake Touch 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 Cursors melden und einen visuellen Cursor auf dem Bildschirm anzeigen.
• 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 .
• MUSS den Mauszeiger auf ein Objekt auf dem Bildschirm bewegen und nach oben und unten bewegen, damit Nutzer das Tippen auf ein Objekt auf dem Bildschirm emulieren können.
• 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 ein Doppeltippen auf ein Objekt auf dem Display emulieren können.
• MUSS die Bewegung des Cursors auf einen beliebigen Punkt auf dem Bildschirm, die Bewegung des Cursors zu einem beliebigen anderen Punkt auf dem Bildschirm und dann die Bewegung des Cursors nach oben unterstützen, damit Nutzer ein Ziehen per Touch emulieren können.
• Es MUSS die Bewegung des Cursors nach unten unterstützen, damit Nutzer das Objekt schnell an eine andere Position auf dem Bildschirm verschieben können. Anschließend muss der Cursor auf dem Bildschirm nach oben bewegt werden können, damit Nutzer das Objekt auf dem Bildschirm wegschleudern können.

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-Nutzung 2	Android-Schaltfläche
A 1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B 1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X 1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Ja 1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-Pad nach oben 1 D-Pad nach unten 1	0x01 0x0039 3	AXIS_HAT_Y 4
Steuerkreuz links 1 Steuerkreuz rechts 1	0x01 0x0039 3	AXIS_HAT_X 4
Linke Schultertaste 1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Rechte Schultertaste 1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Linker Stick klicken 1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Rechter Stick klicken 1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Start 1	0x0c 0x0223	KEYCODE_HOME (3)
Zurück 1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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 Logikwert ist die Drehung im Uhrzeigersinn weg von der vertikalen Achse. Ein Logikwert von 0 steht beispielsweise für keine Drehung und die gedrückte Aufwärtstaste, während ein Logikwert von 1 für eine Drehung von 45 Grad und die gedrückten Auf- und Linkstasten steht.

4 MotionEvent

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

1 MotionEvent

7.2.7. Fernbedienung

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

• Suchaffordance Geräteimplementierungen MÜSSEN KEYCODE_SEARCH (oder KEYCODE_ASSIST, wenn das Gerät einen Assistenten unterstützt) auslösen, wenn der Nutzer die Sprachsuche über die physische oder softwarebasierte Fernbedienung startet.
• Navigation Alle Android TV-Fernbedienungen MÜSSEN die Tasten „Zurück“, „Startseite“ und „Auswählen“ sowie die Unterstützung für D-Pad-Ereignisse haben .

7.3. Sensoren

Android bietet APIs für den Zugriff auf verschiedene Sensortypen. Bei der Geräteimplementierung können diese Sensoren im Allgemeinen UNTERLIEGEN, wie in den folgenden Abschnitten beschrieben. Wenn ein Gerät einen bestimmten Sensortyp mit einer entsprechenden API für Drittanbieterentwickler hat, MUSS die Geräteimplementierung diese API wie in der Android SDK-Dokumentation und in der Android Open Source-Dokumentation zu Sensoren beschrieben implementieren . Beispielsweise bei Geräteimplementierungen:

• MÜSSEN das Vorhandensein oder Fehlen von Sensoren gemäß der Klasse android.content.pm.PackageManager korrekt melden.
• MÜSSEN über SensorManager.getSensorList() und ähnliche Methoden eine genaue Liste der unterstützten Sensoren zurückgeben.
• MÜSSEN sich für alle anderen Sensor-APIs angemessen verhalten (z. B. durch Rückgabe von „wahr“ oder „falsch“, wenn Anwendungen versuchen, Listener zu registrieren, oder durch Nichtaufrufen von Sensor-Listenern, wenn die entsprechenden Sensoren nicht vorhanden sind).
• Alle Sensormessungen müssen für jeden Sensortyp mit den entsprechenden metrischen Werten des internationalen Einheitensystems (SI) gemäß der Android SDK-Dokumentation erfasst werden.
• MUSS die Ereigniszeit in Nanosekunden angeben, wie in der Android SDK-Dokumentation definiert. Diese Zeit entspricht dem Zeitpunkt des Ereignisses und ist mit der SystemClock.elapsedRealtimeNano()-Uhr synchronisiert. Für bestehende und neue Android-Geräte wird DRINGEND empfohlen, diese Anforderungen zu erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt werden können, bei denen diese Komponente möglicherweise ERFORDERLICH ist. Der Synchronisierungsfehler sollte unter 100 Millisekunden liegen.
• Es MÜSSEN Sensordaten mit einer maximalen Latenz von 100 Millisekunden + 2 * „sample_time“ für den Fall eines gestreamten Sensors mit einer erforderlichen Mindestlatenz von 5 ms + 2 * „sample_time“ gemeldet werden, wenn der Anwendungsprozessor aktiv ist. Diese Verzögerung beinhaltet keine Filterverzögerungen.
• Die erste Sensormessung MUSS innerhalb von 400 Millisekunden + 2 * „sample_time“ nach der Aktivierung des Sensors gemeldet werden. Für dieses Beispiel ist eine Genauigkeit von 0 zulässig.

Die Liste oben ist nicht vollständig. Als verbindlich gilt das dokumentierte Verhalten des Android SDK und die Android Open Source-Dokumentation zu Sensoren.

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

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

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

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

7.3.1. Beschleunigungsmesser

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

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

7.3.2. Magnetometer

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

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

7.3.3. GPS

Geräteimplementierungen MÜSSEN einen GPS-/GNSS-Empfänger enthalten. Wenn eine Geräteimplementierung einen GPS-/GNSS-Empfänger enthält und die Funktion über das android.hardware.location.gps-Funktionsflag an Anwendungen meldet:

• Es wird DRINGEND empfohlen, dass das Gerät während eines Notrufs weiterhin normale GPS-/GNSS-Ausgaben an Anwendungen liefert und dass die Standortausgabe während eines Notrufs nicht blockiert wird.
• Es MUSS Standortausgaben mit einer Rate von mindestens 1 Hz unterstützen, wenn sie über LocationManager#requestLocationUpdate angefordert werden .
• Der Standort muss bei freiem Blick (starke Signale, vernachlässigbare Mehrwegeausbreitung, HDOP < 2) innerhalb von 10 Sekunden (schnelle Zeit bis zur ersten Fixierung) bestimmt werden können, wenn eine Internetverbindung mit einer Datenübertragungsrate von mindestens 0,5 Mbit/s besteht. Diese Anforderung wird in der Regel durch die Verwendung einer Form von unterstütztem oder prognostiziertem GPS/GNSS-Verfahren erfüllt, um die GPS/GNSS-Anlaufzeit zu minimieren. Zu den Hilfsdaten gehören Referenzzeit, Referenzstandort und Satellitenephemeris/-uhr.
  • Nach einer solchen Standortberechnung sollte das Gerät seinen Standort unter freiem Himmel innerhalb von 10 Sekunden bestimmen können, wenn Standortanfragen neu gestartet werden, bis zu einer Stunde nach der ersten Standortberechnung, auch wenn die nachfolgende Anfrage ohne Datenverbindung und/oder nach einem Neustart erfolgt.
• Bei freiem Blick nach der Standortbestimmung, wenn Sie stehen oder sich mit weniger als 1 m/s² bewegen:
  • Es muss in mindestens 95% der Fälle in der Lage sein, den Standort innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0, 5 Metern pro Sekunde zu bestimmen.
  • Es MUSS mindestens acht Satelliten aus einer Konstellation gleichzeitig über GnssStatus.Callback verfolgen und melden.
  • Es sollte mindestens 24 Satelliten aus mehreren Konstellationen gleichzeitig verfolgen können (z.B. GPS + mindestens eine von Glonass, Beidou, Galileo).
• Die GNSS-Technologiegeneration muss über die Test-API „getGnssYearOfHardware“ gemeldet werden.
• Es wird DRINGEND empfohlen, alle unten aufgeführten Anforderungen zu erfüllen, wenn die GNSS-Technologie als „2016“ oder höher angegeben ist.
  • GPS-Messungen MÜSSEN gemeldet werden, sobald sie gefunden werden, auch wenn ein aus GPS/GNSS berechneter Standort noch nicht gemeldet wurde.
  • Es MÜSSEN GPS-Pseudostrecken und Pseudostreckenraten gemeldet werden, die bei freiem Blick nach der Standortbestimmung, bei Stillstand oder bei einer Beschleunigung von weniger als 0,2 Metern pro Sekunde zum Quadrat ausreichen, um mindestens 95% der Zeit die Position innerhalb von 20 Metern und die Geschwindigkeit innerhalb von 0,2 Metern pro Sekunde zu berechnen.

Hinweis: Einige der oben genannten GPS-Anforderungen sind zwar als „EMPFOHLENE“ gekennzeichnet, in der Kompatibilitätsdefinition für die nächste Hauptversion werden sie voraussichtlich als „ERFORDERLICH“ eingestuft.

7.3.4. Gyroskop

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

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

7.3.5. Barometer

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

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

7.3.6. Thermometer

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

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

7.3.7. Fotometer

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

7.3.8. Näherungssensor

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

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

7.3.9. Hochpräzise Sensoren

Bei Geräteimplementierungen, die eine Reihe von Sensoren höherer Qualität unterstützen, die alle in diesem Abschnitt aufgeführten Anforderungen erfüllen, MUSS die Unterstützung über das Feature-Flag android.hardware.sensor.hifi_sensors angegeben werden.

Ein Gerät, das android.hardware.sensor.hifi_sensors deklariert, MUSS alle folgenden Sensortypen unterstützen, die die folgenden Qualitätsanforderungen erfüllen:

• SENSOR_TYPE_ACCELEROMETER
  • Der Messbereich muss mindestens -8 g bis +8 g betragen.
  • Die Messauflösung muss mindestens 1.024 LSB/G betragen.
  • Die Mindestmessungsfrequenz muss 12,5 Hz oder weniger betragen.
  • Die maximale Messfrequenz muss mindestens 400 Hz betragen.
  • Der Messrauschen darf maximal 400 µG/√Hz betragen.
  • Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 3.000 Sensorereignissen implementiert werden.
  • Der Batch-Stromverbrauch darf maximal 3 mW betragen.
  • MÜSSEN eine Stabilität der stationären Rauschvorspannung von weniger als 15 µg √Hz aus einem 24-stündigen statischen Datensatz haben.
  • Die Vorabweichung sollte bei einer Temperaturänderung von ≤ ± 1 mg/°C liegen.
  • Die Nichtlinearität der Bestfit-Linie sollte ≤ 0,5 % und die Empfindlichkeitsänderung bei Temperaturschwankungen ≤ 0,03%/°C betragen.

• SENSOR_TYPE_GYROSCOPE

  • Der Messbereich muss mindestens -1.000 und +1.000 dps betragen.
  • MÜSSEN eine Messauflösung von mindestens 16 LSB/dps haben.
  • Die Mindestmessungsfrequenz muss 12,5 Hz oder weniger betragen.
  • Die maximale Messfrequenz muss mindestens 400 Hz betragen.
  • Der Messrauschen darf maximal 0,014 °/s/√Hz betragen.
  • MÜSSEN eine stationäre Voreinstellbarkeitsstabilität von weniger als 0,0002 °/s √Hz aus einem 24-stündigen statischen Datensatz haben.
  • Die Voreingestellten Werte sollten sich bei Temperaturänderungen um maximal +/- 0,05 °/ s / °C ändern.
  • Die Empfindlichkeit sollte sich bei Temperaturänderungen um maximal 0,02 % pro °C ändern.
  • Die Nichtlinearität der Ausgleichsgerade sollte ≤ 0,2 % betragen.
  • MÜSSEN eine Rauschdichte von ≤ 0,007 °/s/√Hz haben.

• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED mit denselben Qualitätsanforderungen wie SENSOR_TYPE_GYROSCOPE.

• SENSOR_TYPE_GEOMAGNETIC_FIELD
  • Der Messbereich muss mindestens -900 und +900 µT betragen.
  • Die Messauflösung muss mindestens 5 LSB/uT betragen.
  • Die Mindestmessungsfrequenz muss 5 Hz oder weniger betragen.
  • Die maximale Messfrequenz muss mindestens 50 Hz betragen.
  • Der Messrauschen darf maximal 0,5 µT betragen.
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED mit denselben Qualitätsanforderungen wie SENSOR_TYPE_GEOMAGNETIC_FIELD und zusätzlich:
  • Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 600 Sensorereignissen implementiert werden.
• SENSOR_TYPE_PRESSURE
  • Der Messbereich muss mindestens 300 bis 1.100 hPa betragen.
  • MÜSSEN eine Messauflösung von mindestens 80 LSB/hPa haben.
  • Die Mindestmessungsfrequenz muss 1 Hz oder weniger betragen.
  • Die maximale Messfrequenz muss mindestens 10 Hz betragen.
  • Der Messrauschen darf maximal 2 Pa/√Hz betragen.
  • Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 300 Sensorereignissen implementiert werden.
  • Der Batch-Stromverbrauch darf maximal 2 mW betragen.
• SENSOR_TYPE_GAME_ROTATION_VECTOR
  • Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 300 Sensorereignissen implementiert werden.
  • Der Batch-Stromverbrauch darf maximal 4 mW betragen.
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
• SENSOR_TYPE_STEP_DETECTOR
  • Es MUSS eine Variante dieses Sensors ohne Weckfunktion mit einer Pufferkapazität von mindestens 100 Sensorereignissen implementiert werden.
  • Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
  • Der Batch-Stromverbrauch darf maximal 4 mW betragen.
• SENSOR_TYPE_STEP_COUNTER
  • Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.
• SENSOR_TILT_DETECTOR
  • Der Stromverbrauch darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 1,5 mW liegen.

Außerdem muss ein solches Gerät die folgenden Anforderungen an das Sensor-Subsystem erfüllen:

• Der Zeitstempel des Ereignisses für dasselbe physische Ereignis, das vom Beschleunigungsmesser, Gyroskopsensor und Magnetometer erfasst wird, MUSS innerhalb von 2,5 Millisekunden liegen.
• Die Zeitstempel der Gyroskopsensorereignisse MÜSSEN auf derselben Zeitbasis wie das Kamera-Subsystem liegen und eine Abweichung von maximal 1 Millisekunde aufweisen.
• High-Fidelity-Sensoren MÜSSEN Daten innerhalb von 5 Millisekunden nach dem Zeitpunkt, zu dem die Daten am physischen Sensor verfügbar sind, an die Anwendung senden.
• Die Leistungsaufnahme darf bei inaktivem Gerät nicht mehr als 0,5 mW und bei in Bewegung befindlichem Gerät nicht mehr als 2,0 mW betragen, wenn eine beliebige Kombination der folgenden Sensoren aktiviert ist:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

Hinweis: Alle in diesem Abschnitt aufgeführten Anforderungen an den Stromverbrauch umfassen nicht den Stromverbrauch des Anwendungsprozessors. Sie umfasst den Stromverbrauch der gesamten Sensorkette – des Sensors, aller unterstützenden Schaltkreise und aller speziellen Sensorverarbeitungssysteme usw.

Die folgenden Sensortypen KÖNNEN auch in einer Geräteimplementierung unterstützt werden, die android.hardware.sensor.hifi_sensors deklariert. Wenn diese Sensortypen vorhanden sind, MÜSSEN sie jedoch die folgenden Mindestanforderungen an die Pufferung erfüllen:

• SENSOR_TYPE_PROXIMITY: 100 Sensorereignisse

7.3.10. Fingerabdrucksensor

Geräteimplementierungen mit einer sicheren Sperre MÜSSEN einen Fingerabdrucksensor enthalten. Wenn eine Geräteimplementierung einen Fingerabdrucksensor und eine entsprechende API für Drittanbieter enthält, gilt Folgendes:

• MÜSSEN die Unterstützung für die Funktion „android.hardware.fingerprint“ angeben.
• Die entsprechende API muss vollständig wie in der Android SDK-Dokumentation beschrieben implementiert sein.
• Die Falsch-Akzeptanzrate darf maximal 0,002 % betragen.
• Es wird DRINGEND empfohlen, dass die Falschablehnungsrate auf dem Gerät unter 10 % liegt.
• Es wird EMPFOHLEN, dass die Latenz für einen registrierten Finger unter 1 Sekunde liegt, gemessen vom Zeitpunkt, an dem der Fingerabdrucksensor berührt wird, bis das Display entsperrt wird.
• Nach fünf falschen Versuchen bei der Fingerabdruckbestätigung MUSS die Rate der Versuche für mindestens 30 Sekunden begrenzt werden.
• MUSS eine hardwaregestützte Keystore-Implementierung haben und den Fingerabdruckabgleich in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) oder auf einem Chip mit einem sicheren Kanal zur TEE ausführen.
• Alle identifizierbaren Fingerabdruckdaten MÜSSEN verschlüsselt und kryptografisch authentifiziert sein, damit sie nicht außerhalb der Trusted Execution Environment (TEE) abgerufen, gelesen oder geändert werden können, wie in den Implementierungsrichtlinien auf der Website des Android Open Source Project beschrieben.
• Es MUSS verhindert werden, dass ein Fingerabdruck hinzugefügt wird, ohne zuerst eine Vertrauenskette zu erstellen. Dazu muss der Nutzer vorhandene Anmeldedaten (PIN/Muster/Passwort) bestätigen oder neue Anmeldedaten hinzufügen, die durch TEE geschützt sind. Die Implementierung des Android Open Source Project bietet dafür den Mechanismus im Framework.
• Drittanbieter-Apps dürfen KEINE Möglichkeit haben, zwischen einzelnen Fingerabdrücken zu unterscheiden.
• Das Flag „DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT“ MUSS berücksichtigt werden.
• Bei einem Upgrade von einer Version vor Android 6.0 MÜSSEN die Fingerabdruckdaten sicher migriert werden, um die oben genannten Anforderungen zu erfüllen, oder entfernt werden.
• SOLLTE das Android-Fingerabdrucksymbol verwenden, das im Android Open Source Project verfügbar ist.

7.3.11. Nur für Android Automotive verfügbare Sensoren

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

7.3.11.1. Aktuelles Übersetzungsverhältnis

Android Automotive-Implementierungen MÜSSEN den aktuellen Gang als SENSOR_TYPE_GEAR angeben.

7.3.11.2. Tag-/Nachtmodus

Android Automotive-Implementierungen MÜSSEN den Tag-/Nachtmodus unterstützen, der als SENSOR_TYPE_NIGHT definiert ist. Der Wert dieses Flags MUSS mit dem Tag-/Nachtmodus des Dashboards übereinstimmen und SOLLTE auf dem Eingang des Umgebungslichtsensors basieren. Der zugrunde liegende Umgebungslichtsensor kann mit dem Photometer identisch sein .

7.3.11.3. Fahrstatus

Android Automotive-Implementierungen MÜSSEN den Fahrstatus unterstützen, der als SENSOR_TYPE_DRIVING_STATUS definiert ist, mit dem Standardwert DRIVE_STATUS_UNRESTRICTED, wenn das Fahrzeug vollständig angehalten und geparkt ist. Es liegt in der Verantwortung der Gerätehersteller, SENSOR_TYPE_DRIVING_STATUS gemäß allen Gesetzen und Bestimmungen zu konfigurieren, die für die Märkte gelten, in denen das Produkt vertrieben wird.

7.3.11.4. Raddrehzahl

Android Automotive-Implementierungen MÜSSEN die Fahrzeuggeschwindigkeit als SENSOR_TYPE_CAR_SPEED angeben.

7.3.12. Positionssensor

Geräteimplementierungen KÖNNEN einen Positionssensor mit 6 Freiheitsgraden unterstützen. Android-Handhelds sollten diesen Sensor UNTERSTÜTZEN. Wenn eine Geräteimplementierung einen 6-Achsen-Pose-Sensor unterstützt, gilt Folgendes:

• Der Sensor TYPE_POSE_6DOF MUSS implementiert und gemeldet werden.
• MÜSSEN genauer sein als der Drehvektor allein.

7.4. Datenverbindung

7.4.1. Telefonie

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

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

7.4.1.1. Kompatibilität mit der Nummernblockierung

Android-Telefonimplementierungen MÜSSEN die Blockierung von Nummern unterstützen und:

• BlockedNumberContract und die entsprechende API MÜSSEN vollständig wie in der SDK-Dokumentation beschrieben implementiert sein.
• MÜSSEN alle Anrufe und Nachrichten von einer Telefonnummer in „BlockedNumberProvider“ blockieren, ohne dass eine Interaktion mit Apps erforderlich ist. Die einzige Ausnahme ist, wenn die Blockierung von Nummern wie in der SDK-Dokumentation beschrieben vorübergehend aufgehoben wird.
• Darf NICHT für einen blockierten Anruf an den Anbieter der Anrufliste der Plattform schreiben.
• Darf nicht an den Telefonieanbieter wegen einer blockierten Nachricht schreiben.
• Es MUSS eine Benutzeroberfläche zum Verwalten blockierter Nummern implementiert werden, die mit der Intent geöffnet wird, die von der Methode TelecomManager.createManageBlockedNumbersIntent() zurückgegeben wird.
• Sekundäre Nutzer dürfen die blockierten Nummern auf dem Gerät NICHT ansehen oder bearbeiten, da die Android-Plattform davon ausgeht, dass der Hauptnutzer die vollständige Kontrolle über die Telefondienste auf dem Gerät hat. Alle blockierungsbezogenen Benutzeroberflächen MÜSSEN für sekundäre Nutzer ausgeblendet sein und die Blockierungsliste MÜSSEN weiterhin berücksichtigt werden.
• Die blockierten Nummern MÜSSEN zum Anbieter migriert werden, wenn ein Gerät auf Android 7.0 aktualisiert wird.

7.4.2. IEEE 802.11 (Wi‑Fi)

Alle Android-Geräteimplementierungen MÜSSEN eine oder mehrere Formen von 802.11 unterstützen. Wenn eine Geräteimplementierung 802.11 unterstützt und die Funktion für eine Drittanbieteranwendung freigibt, MUSS sie die entsprechende Android API implementieren und:

• Das Hardware-Funktions-Flag „android.hardware.wifi“ MUSS angegeben werden.
• Die Multicast API muss wie in der SDK-Dokumentation beschrieben implementiert werden.
• MUSS Multicast-DNS (mDNS) unterstützen und darf mDNS-Pakete (224.0.0.251) zu keinem Zeitpunkt filtern, einschließlich:
  • Auch wenn der Bildschirm nicht aktiv ist.
  • Bei Android TV-Geräten auch im Standby-Modus.

7.4.2.1. Wi-Fi Direct

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

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

7.4.2.2. Einrichtung eines Wi‑Fi-Tunneled Direct Link

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

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

7.4.3. Bluetooth

Geräteimplementierungen, die die Funktion android.hardware.vr.high_performance unterstützen, MÜSSEN Bluetooth 4.2 und die Bluetooth LE-Datenlängenerweiterung unterstützen.

Android unterstützt Bluetooth und Bluetooth Low Energy . Geräteimplementierungen, die Bluetooth und Bluetooth Low Energy unterstützen, MÜSSEN die entsprechenden Plattformfunktionen (android.hardware.bluetooth und android.hardware.bluetooth_le) deklarieren und die Plattform-APIs implementieren. Geräteimplementierungen MÜSSEN relevante Bluetooth-Profile wie A2DP, AVCP, OBEX usw. implementieren, sofern dies für das Gerät zutrifft.

Android Automotive-Implementierungen MÜSSEN das Message Access Profile (MAP) unterstützen. Android Automotive-Implementierungen MÜSSEN die folgenden Bluetooth-Profile unterstützen:

• Telefonanrufe über das Hands-Free Profile (HFP)
• Medienwiedergabe über Audio Distribution Profile (A2DP)
• Steuerung der Medienwiedergabe über das Remote Control Profile (AVRCP).
• Kontaktfreigabe über das Phone Book Access Profile (PBAP)

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

• Die Hardwarefunktion „android.hardware.bluetooth_le“ MUSS deklariert werden.
• Die GATT-basierten (Generic Attribute Profile) Bluetooth APIs MÜSSEN wie in der SDK-Dokumentation und in android.bluetooth beschrieben aktiviert sein .
• Wir EMPFEHLEN dringend, ein Zeitlimit für resolvable private addresses (RPA) von maximal 15 Minuten zu implementieren und die Adresse nach Ablauf des Zeitlimits zu wechseln, um den Datenschutz für Nutzer zu schützen.
• Die Auslagerung der Filterlogik an den Bluetooth-Chipsatz sollte bei der Implementierung der ScanFilter API unterstützt WERDEN und der korrekte Wert für die Implementierung der Filterlogik MUSS bei jeder Abfrage über die Methode android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() gemeldet WERDEN.
• Sollte das Auslagern des Batch-Scans an den Bluetooth-Chip unterstützen. Wenn dies nicht unterstützt wird, MUSS bei jeder Abfrage über die Methode android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported() „false“ zurückgegeben werden.
• Sollte mehrere Anzeigen mit mindestens 4 Slots unterstützen. Wenn nicht unterstützt, MUSS bei jeder Abfrage über die Methode „android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported()“ „false“ zurückgegeben werden.

7.4.4. Nahfeldkommunikation

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

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

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

Android unterstützt den NFC-HCE-Modus (Host Card Emulation). Wenn eine Geräteimplementierung einen HCE-fähigen NFC-Controller-Chipsatz (für NfcA und/oder NfcB) enthält und das Routing der Anwendungs-ID (AID) unterstützt, gilt Folgendes:

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

Wenn eine Geräteimplementierung einen HCE-fähigen NFC-Controller-Chipsatz für NfcF enthält und die Funktion für Drittanbieter-Apps implementiert, gilt Folgendes:

• Die Funktion „android.hardware.nfc.hcef“ MUSS als Konstante gemeldet werden.
• MÜSSEN die NfcF Card Emulation APIs wie im Android SDK definiert implementieren.

Außerdem kann die Geräteimplementierung die Leser-/Schreiberunterstützung für die folgenden MIFARE-Technologien umfassen.

• MIFARE Classic
• MIFARE Ultralight
• NDEF auf MIFARE Classic

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

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

Wenn eine Geräteimplementierung keine NFC-Hardware enthält, darf die Funktion „android.hardware.nfc“ nicht über die Methode android.content.pm.PackageManager.hasSystemFeature() deklariert werden. Die Android NFC API muss als No-Op implementiert werden.

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

7.4.5. Mindestnetzwerkanforderungen

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

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

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

Geräte MÜSSEN einen IPv6-Netzwerkstack enthalten und die IPv6-Kommunikation über die verwalteten APIs wie java.net.Socket und java.net.URLConnection sowie die nativen APIs wie AF_INET6-Sockets unterstützen. Die erforderliche IPv6-Unterstützung hängt vom Netzwerktyp ab:

• Geräte, die WLANs unterstützen, MÜSSEN Dual-Stack und den Betrieb nur mit IPv6 über WLAN unterstützen.
• Geräte, die Ethernet-Netzwerke unterstützen, MÜSSEN den Dual-Stack-Betrieb über Ethernet unterstützen.
• Geräte, die mobile Daten unterstützen, MÜSSEN IPv6-Betrieb (nur IPv6 und eventuell Dual-Stack) über mobile Daten unterstützen.
• Wenn ein Gerät gleichzeitig mit mehreren Netzwerken verbunden ist (z.B. WLAN und mobile Daten) müssen diese Anforderungen gleichzeitig in jedem Netzwerk erfüllen, mit dem sie verbunden sind.

IPv6 MUSS standardmäßig aktiviert sein.

Damit die IPv6-Kommunikation so zuverlässig wie IPv4 ist, dürfen an das Gerät gesendete Unicast-IPv6-Pakete NICHT verworfen werden, auch wenn sich das Display nicht im aktiven Zustand befindet. Redundante Multicast-IPv6-Pakete, z. B. wiederholte identische Router-Anzeigen, KÖNNEN in Hardware oder Firmware durch eine Ratenbegrenzung begrenzt werden, wenn dies zur Energieeinsparung erforderlich ist. In solchen Fällen darf die Ratenbegrenzung NICHT dazu führen, dass das Gerät die IPv6-Verbindung in einem IPv6-kompatiblen Netzwerk verliert, das RA-Lebensdauern von mindestens 180 Sekunden verwendet.

Die IPv6-Konnektivität MUSS im Ruhemodus aufrechterhalten werden.

7.4.6. Synchronisierungseinstellungen

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

7.4.7. Datensparmodus

Bei Geräteimplementierungen mit einer getakteten Verbindung wird der Datensparmodus DRINGEND empfohlen.

Wenn eine Geräteimplementierung den Datensparmodus bietet, gilt Folgendes:

• MÜSSEN alle APIs in der ConnectivityManager-Klasse unterstützen, wie in der SDK-Dokumentation beschrieben.

• Es MUSS eine Benutzeroberfläche in den Einstellungen geben, mit der Nutzer Anwendungen zur Zulassungsliste hinzufügen oder daraus entfernen können.

Wenn eine Geräteimplementierung den Datensparmodus nicht bietet, gilt Folgendes:

• MUSS den Wert RESTRICT_BACKGROUND_STATUS_DISABLED für ConnectivityManager.getRestrictBackgroundStatus() zurückgeben

• Darf ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED NICHT übertragen

• Es MUSS eine Aktivität geben, die die Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS-Intention verarbeitet, sie KANN aber als No-Op implementiert werden.

7.5. Kameras

Geräteimplementierungen MÜSSEN eine Rückkamera und KÖNNEN eine Frontkamera haben. Eine Rückkamera befindet sich auf der Seite des Geräts, die dem Display gegenüberliegt. Sie nimmt also Bilder auf der Rückseite des Geräts auf, ähnlich wie eine herkömmliche Kamera. Eine Frontkamera befindet sich auf derselben Seite des Geräts wie das Display. Sie wird in der Regel zum Aufnehmen von Bildern des Nutzers verwendet, z. B. für Videokonferenzen und ähnliche Anwendungen.

Wenn eine Geräteimplementierung mindestens eine Kamera enthält, MUSS es für eine Anwendung möglich sein, gleichzeitig drei RGBA_8888-Bitmaps zuzuweisen, die der Größe der Bilder entsprechen, die vom Kamerasensor mit der höchsten Auflösung auf dem Gerät erzeugt werden, während die Kamera für eine einfache Vorschau und Standbildaufnahme geöffnet ist.

7.5.1. Rückkamera

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

• MÜSSEN die Funktions-Flags „android.hardware.camera“ und „android.hardware.camera.any“ melden.
• MÜSSEN eine Auflösung von mindestens 2 Megapixeln haben.
• Es sollte entweder ein Hardware- oder Software-Autofokus im Kameratreiber implementiert sein (für die Anwendungssoftware transparent).
• KANN Hardware mit fester Brennweite oder erweiterter Schärfentiefe haben.
• Kann einen Blitz enthalten. Wenn die Kamera einen Blitz hat, darf die Blitzlampe NICHT leuchten, während eine Instanz von android.hardware.Camera.PreviewCallback auf einer Kameravorschauoberfläche registriert ist, es sei denn, die Anwendung hat den Blitz explizit aktiviert, indem sie die Attribute FLASH_MODE_AUTO oder FLASH_MODE_ON eines Camera.Parameters-Objekts aktiviert hat. Diese Einschränkung gilt nicht für die integrierte Systemkamera-App des Geräts, sondern nur für Drittanbieter-Apps, die Camera.PreviewCallback verwenden.

7.5.2. Frontkamera

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

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

7.5.3. Externe Kamera

Geräteimplementierungen KÖNNEN die Unterstützung einer externen Kamera umfassen, die nicht unbedingt immer verbunden ist. Wenn ein Gerät eine externe Kamera unterstützt, gilt Folgendes:

• MÜSSEN die Plattform-Funktions-Flags android.hardware.camera.external und android.hardware camera.any deklarieren .
• Unter Umständen wird die Nutzung mehrerer Kameras unterstützt.
• MUSS USB Video Class (UVC 1.0 oder höher) unterstützen, wenn die externe Kamera über den USB-Port verbunden wird.
• MÜSSEN Videokomprimierungen wie MJPEG unterstützen, um die Übertragung von hochwertigen, nicht codierten Streams (d.h. Roh- oder unabhängig komprimierte Bildstreams) zu ermöglichen.
• Unter Umständen wird die kamerabasierte Videocodierung unterstützt. Sofern unterstützt, muss die Geräteimplementierung auf einen gleichzeitigen uncodierten / MJPEG-Stream (QVGA oder höhere Auflösung) zugreifen können.

7.5.4. Verhalten der Camera API

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

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

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

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

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

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

Da nicht alle Geräteimplementierungen alle Funktionen der android.hardware.camera2 API vollständig unterstützen können, MÜSSEN Geräteimplementierungen die richtige Unterstützungsstufe mit der Eigenschaft android.info.supportedHardwareLevel gemäß der Beschreibung im Android SDK angeben und die entsprechenden Framework-Funktions-Flags melden .

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

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

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

7.5.5. Kameraausrichtung

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

7.6. Arbeitsspeicher und Datenspeicher

7.6.1. Mindestarbeitsspeicher und Mindestspeicherplatz

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

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

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

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

Android TV-Geräte MÜSSEN mindestens 4 GB und andere Geräteimplementierungen MÜSSEN mindestens 3 GB nichtflüchtigen Speicher für private Daten der Anwendung haben. Die Partition „/data“ muss also mindestens 4 GB für Android TV-Geräte und mindestens 3 GB für andere Geräteimplementierungen haben. Für Geräteimplementierungen mit Android wird DRINGEND empfohlen, mindestens 4 GB nichtflüchtigen Speicher für private Anwendungsdaten zu haben, damit sie auf die zukünftigen Plattformversionen umgestellt werden können.

Die Android APIs enthalten einen Downloadmanager, den Anwendungen zum Herunterladen von Datendateien verwenden KÖNNEN. Die Geräteimplementierung des Download-Managers MUSS in der Lage sein, einzelne Dateien mit einer Größe von mindestens 100 MB an den Standardspeicherort „cache“ herunterzuladen.

7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen

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

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

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

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

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

Bei Geräteimplementierungen MUSS die Berechtigung „android.permission.WRITE_EXTERNAL_STORAGE“ wie dokumentiert auf diesem freigegebenen Speicher erzwungen werden. Andernfalls MUSS der freigegebene Speicher für alle Anwendungen beschreibbar sein, die diese Berechtigung erhalten.

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

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

Unabhängig von der verwendeten Form des freigegebenen Speichers muss die Geräteimplementierung, wenn sie einen USB-Anschluss mit Unterstützung des USB-Peripheriemodus hat, einen Mechanismus zum Zugriff auf den Inhalt des freigegebenen Speichers von einem Hostcomputer aus bereitstellen. Bei Geräteimplementierungen kann USB-Massenspeicher verwendet werden, sollte aber das Media Transfer Protocol verwenden, um diese Anforderung zu erfüllen. Wenn die Geräteimplementierung das Media Transfer Protocol unterstützt, gilt Folgendes:

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

7.6.3. Verwendbarer Speicher

Bei Geräteimplementierungen wird DRINGEND empfohlen, adaptable storage zu implementieren, wenn sich der Anschluss des Wechseldatenträgers an einem dauerhaft stabilen Ort befindet, z. B. im Akkufach oder in einem anderen Schutzabdeckung.

Bei Geräten wie Fernsehern kann die Nutzung über USB-Anschlüsse MÖGLICH sein, da das Gerät voraussichtlich stationär und nicht mobil ist. Bei anderen mobilen Geräten wird jedoch DRINGEND empfohlen, den anpassbaren Speicher an einem dauerhaft stabilen Ort zu implementieren, da eine versehentliche Trennung zu Datenverlusten oder Beschädigungen führen kann.

7.7. USB

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

7.7.1. USB-Peripheriegerätemodus

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

• Der Anschluss MUSS mit einem USB-Host mit einem Standard-USB-Typ-A- oder -Typ-C-Anschluss verbunden werden können.
• Der Port sollte den USB-Formfaktor Micro-B, Micro-AB oder Typ-C haben. Für bestehende und neue Android-Geräte wird dringend empfohlen, diese Anforderungen zu erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt werden können.
• Der Anschluss sollte sich an der Unterseite des Geräts befinden (entsprechend der natürlichen Ausrichtung). Alternativ kann die Bildschirmdrehung für alle Apps (einschließlich Startbildschirm) aktiviert werden, damit das Display korrekt dargestellt wird, wenn sich das Gerät mit dem Anschluss nach unten befindet. Für bestehende und neue Android-Geräte wird dringend empfohlen, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen umgestellt werden können.
• Es MUSS einem mit dem Android-Gerät verbundenen USB-Host entweder über USB-Massenspeicher oder über das Media-Transfer-Protokoll (MTP) den Zugriff auf den Inhalt des freigegebenen Speichervolumes ermöglichen.
• Es MUSS die Android Open Accessory API (AOA) und die Spezifikation gemäß der Android SDK-Dokumentation implementieren. Bei einem Android-Handheld-Gerät MUSS die AOA API implementiert sein. Geräteimplementierungen, die die AOA-Spezifikation implementieren:
  • MÜSSEN die Unterstützung für die Hardwarefunktion android.hardware.usb.accessory angeben .
  • Die USB-Audioklasse muss gemäß der Android SDK-Dokumentation implementiert werden.
  • Die USB-Massenspeicherklasse MUSS am Ende des Interface-Beschreibungsstrings iInterface des USB-Massenspeichers den String „android“ enthalten.
• Es sollte Unterstützung für einen Stromverbrauch von 1,5 A während des HS-Chirps und des Traffics implementieren, wie in der USB-Spezifikation für das Aufladen von Akkus, Version 1.2 angegeben. Für bestehende und neue Android-Geräte wird dringend empfohlen, diese Anforderungen zu erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt werden können.
• USB-Typ-C-Geräte MÜSSEN gemäß dem USB-Typ-C-Widerstandsstandard Ladegeräte mit 1,5 A und 3,0 A erkennen und Änderungen in der Werbung erkennen.
• Bei Typ-C-Geräten, die auch den USB-Host-Modus unterstützen, wird DRINGEND empfohlen, die Stromversorgung für den Daten- und Stromrollenwechsel zu unterstützen.
• USB-Typ-C-Geräte MÜSSEN Power Delivery für das Laden mit hoher Spannung und alternative Modi wie Displayausgang unterstützen.
• Der Wert von „iSerialNumber“ im USB-Standardgeräte-Descriptor MUSS mit dem Wert von „android.os.Build.SERIAL“ übereinstimmen.
• Für USB-C-Geräte wird DRINGEND empfohlen, keine proprietären Lademethoden zu unterstützen, die die Vbus-Spannung über die Standardwerte hinaus ändern oder die Rolle des Sinks/der Quelle ändern, da dies zu Inkompatibilitätsproblemen mit Ladegeräten oder Geräten führen kann, die die standardmäßigen USB-PD-Methoden unterstützen. Diese Funktion wird zwar als „EMPFOHLENE OPTION“ gekennzeichnet, in zukünftigen Android-Versionen wird es jedoch möglicherweise erforderlich sein, dass alle Geräte mit USB-Typ-C-Anschluss die vollständige Interoperabilität mit Standard-USB-Typ-C-Ladegeräten unterstützen.

7.7.2. USB-Host-Modus

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

• Es sollte ein USB-Typ-C-Anschluss verwendet werden, wenn die Geräteimplementierung USB 3.1 unterstützt.
• Es kann ein nicht standardmäßiger Port-Formfaktor verwendet werden. In diesem Fall MUSS das Gerät jedoch mit einem oder mehreren Kabeln geliefert werden, die den Port an einen Standard-USB-Typ-A- oder -Typ-C-Anschluss anpassen.
• Es kann ein Micro-AB-USB-Anschluss verwendet werden. In diesem Fall MUSS das Gerät jedoch mit einem oder mehreren Kabeln geliefert werden, die den Anschluss an einen Standard-USB-Anschluss vom Typ A oder Typ C ermöglichen.
• Es wird DRINGEND empfohlen, die USB Audio Class gemäß der Dokumentation des Android SDK zu implementieren.
• Die Android USB Host API muss gemäß der im Android SDK dokumentierten Anleitung implementiert werden und die Unterstützung der Hardwarefunktion android.hardware.usb.host muss erklärt werden .
• MÜSSEN das Aufladen von Geräten im Hostmodus unterstützen und einen Quellstrom von mindestens 1,5 A angeben, wie im Abschnitt „Termination Parameters“ der [USB Type-C Cable and Connector Specification Revision 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) für USB-Typ-C-Anschlüsse oder mit dem Ausgabestrombereich des Charging Downstream Port(CDP) gemäß den USB Battery Charging specifications, revision 1.2 für Micro-AB-Anschlüsse.
• USB-Typ-C-Geräte sollten DisplayPort unterstützen und USB SuperSpeed-Datenraten unterstützen. Außerdem wird dringend empfohlen, dass sie Power Delivery für den Daten- und Stromversorgungsrollentausch unterstützen.
• Geräte mit Typ-A- oder Typ-AB-Anschlüssen dürfen KEIN Adapter enthalten, der von diesem Anschluss zu einem Typ-C-Anschluss konvertiert.
• MUSS alle per Fernzugriff verbundenen MTP-Geräte (Media Transfer Protocol) erkennen und deren Inhalte über die Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT und ACTION_CREATE_DOCUMENT zugänglich machen, wenn das Storage Access Framework (SAF) unterstützt wird.
• Wenn Sie einen USB-Typ-C-Anschluss verwenden und den Peripheriemodus unterstützen, MÜSSEN Sie die Funktion „Dual Role Port“ gemäß der USB-Typ-C-Spezifikation (Abschnitt 4.5.1.3.3) implementieren.
• Wenn die Funktion „Dual Role Port“ unterstützt wird, sollte das Modell „Try.*“ implementiert werden, das am besten zum Formfaktor des Geräts passt. Beispielsweise sollte ein Handheld das Try.SNK-Modell implementieren.

7.8. Audio

7.8.1. Mikrofon

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

• Die Funktion „android.hardware.microphone“ MUSS als konstant gemeldet werden.
• MÜSSEN den Anforderungen an Audioaufnahmen in Abschnitt 5.4 entsprechen .
• MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen .
• Es wird DRINGEND empfohlen, die Aufnahme von Nah-Ultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen .

7.8.2. Audioausgabe

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

• Die Funktion „android.hardware.audio.output“ MUSS als Konstante gemeldet werden.
• MÜSSEN die Anforderungen an die Audiowiedergabe in Abschnitt 5.5 erfüllen .
• MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen .
• Es wird DRINGEND empfohlen, die Wiedergabe von Near-Ultraschall wie in Abschnitt 7.8.3 beschrieben zu unterstützen .

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

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

7.8.2.1. Analoge Audioports

Damit Headsets und anderes Audiozubehör mit dem 3,5-mm-Audiostecker im Android-System kompatibel sind, muss mindestens einer der Audioanschlüsse einer Geräteimplementierung, die einen oder mehrere analoge Audioanschlüsse enthält, eine 4-polige 3,5-mm-Audiobuchse sein. Wenn eine Geräteimplementierung eine 3,5-mm-Audiobuchse mit vier Adern hat, gilt Folgendes:

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

7.8.3. Nah-Ultraschall

Nah-Ultraschall-Audio ist das Band von 18,5 kHz bis 20 kHz. Geräteimplementierungen MÜSSEN die Unterstützung der Near-Ultrasound-Audiofunktion über die AudioManager.getProperty API wie unten beschrieben korrekt melden:

• Wenn PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND „wahr“ ist, müssen die folgenden Anforderungen von den Audioquellen VOICE_RECOGNITION und UNPROCESSED erfüllt werden:
  • Die mittlere Leistungsantwort des Mikrofons im Bereich von 18,5 kHz bis 20 kHz darf maximal 15 dB unter der Antwort bei 2 kHz liegen.
  • Das ungewichtete Signal-Rausch-Verhältnis des Mikrofons bei 18,5 kHz bis 20 kHz für einen 19 kHz-Ton bei −26 dBFS darf nicht unter 50 dB liegen.
• Wenn PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND „wahr“ ist, darf die mittlere Antwort des Lautsprechers im Bereich von 18,5 kHz bis 20 kHz nicht unter 40 dB unter der Antwort bei 2 kHz liegen.

7.9. Virtual Reality

Android bietet APIs und Funktionen zum Erstellen von Virtual-Reality-Anwendungen (VR), einschließlich hochwertiger mobiler VR-Erlebnisse. Geräteimplementierungen MÜSSEN diese APIs und Verhaltensweisen wie in diesem Abschnitt beschrieben korrekt implementieren.

7.9.1. Virtual Reality-Modus

Implementierungen von Android-Handheld-Geräten, die einen Modus für VR-Anwendungen unterstützen, der das stereoskopische Rendern von Benachrichtigungen verarbeitet und monokulare System-UI-Komponenten deaktiviert, während eine VR-Anwendung den Nutzerfokus hat, MÜSSEN die Funktion android.software.vr.mode deklarieren. Geräte, für die diese Funktion deklariert wird, MÜSSEN eine Anwendung enthalten, die android.service.vr.VrListenerService implementiert und von VR-Anwendungen über android.app.Activity#setVrModeEnabled aktiviert werden kann .

7.9.2. Virtual Reality High Performance

Bei der Implementierung von Android-Handheld-Geräten MUSS die Unterstützung von Hochleistungs-Virtual Reality für längere Nutzungszeiten über das android.hardware.vr.high_performance-Funktionsflag angegeben werden. Außerdem müssen die folgenden Anforderungen erfüllt sein.

• Geräteimplementierungen MÜSSEN mindestens 2 physische Kerne haben.
• Geräteimplementierungen MÜSSEN die Funktion „android.software.vr.mode“ deklarieren.
• Geräteimplementierungen KÖNNEN einen exklusiven Kern für die Anwendung im Vordergrund bereitstellen und KÖNNEN die Process.getExclusiveCores API unterstützen, um die Anzahl der CPU-Kerne zurückzugeben, die exklusiv für die oberste Anwendung im Vordergrund sind. Wenn der exklusive Kern unterstützt wird, darf der Kern keine anderen Userspace-Prozesse darauf ausführen (außer Gerätetreiber, die von der Anwendung verwendet werden). Es kann jedoch vorkommen, dass einige Kernel-Prozesse ausgeführt werden.
• Geräteimplementierungen MÜSSEN den Modus für konstante Leistung unterstützen.
• Geräteimplementierungen MÜSSEN OpenGL ES 3.2 unterstützen.
• Geräteimplementierungen MÜSSEN Vulkan-Hardwareebene 0 und SOLLTEN Vulkan-Hardwareebene 1 unterstützen.
• Geräteimplementierungen MÜSSEN EGL_KHR_mutable_render_buffer und EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync und EGL_KHR_wait_sync implementieren, damit sie für den Shared Buffer-Modus verwendet werden können, und die Erweiterungen in der Liste der verfügbaren EGL-Erweiterungen bereitstellen.
• Die GPU und das Display MÜSSEN den Zugriff auf den freigegebenen Front-Buffer synchronisieren können, damit das abwechselnde Rendern von VR-Inhalten mit zwei Rendering-Kontexten bei 60 fps ohne sichtbare Tearing-Artefakte angezeigt wird.
• Geräteimplementierungen MÜSSEN EGL_IMG_context_priority implementieren und die Erweiterung in der Liste der verfügbaren EGL-Erweiterungen angeben.
• Geräteimplementierungen MÜSSEN GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 und GL_OVR_multiview_multisampled_render_to_texture implementieren und die Erweiterungen in der Liste der verfügbaren GL-Erweiterungen verfügbar machen.
• Geräteimplementierungen MÜSSEN EGL_EXT_protected_content und GL_EXT_protected_textures implementieren, damit sie für die sichere Videowiedergabe mit Texturen verwendet werden können. Die Erweiterungen müssen in der Liste der verfügbaren EGL- und GL-Erweiterungen aufgeführt sein.
• Geräteimplementierungen MÜSSEN die H.264-Dekodierung mit mindestens 3.840 x 2.160 Pixeln bei 30 fps und 40 Mbit/s unterstützen (entspricht 4 Instanzen von 1.920 x 1.080 Pixeln bei 30 fps und 10 Mbit/s oder 2 Instanzen von 1.920 x 1.080 Pixeln bei 60 fps und 20 Mbit/s).
• Geräteimplementierungen MÜSSEN HEVC und VP9 unterstützen, MÜSSEN mindestens 1920 × 1080 bei 30 fps und 10 Mbit/s decodieren können und SOLLTEN 3840 × 2160 bei 30 fps und 20 Mbit/s decodieren können (entspricht 4 Instanzen von 1920 × 1080 bei 30 fps und 5 Mbit/s).
• Die Geräteimplementierungen MÜSSEN die Funktion „android.hardware.sensor.hifi_sensors“ unterstützen und die Anforderungen an Gyroskop, Beschleunigungsmesser und Magnetometer für „android.hardware.hifi_sensors“ erfüllen.
• Geräteimplementierungen MÜSSEN die HardwarePropertiesManager.getDeviceTemperatures API unterstützen und genaue Werte für die Hauttemperatur zurückgeben.
• Die Geräteimplementierung MUSS ein integriertes Display haben und die Auflösung MUSS mindestens FullHD(1080p) betragen. QuadHD (1440p) oder höher wird DRINGEND empfohlen.
• Die Diagonale des Displays MUSS zwischen 4,7 Zoll und 6 Zoll liegen.
• Das Display muss im VR-Modus mindestens 60 Hz haben.
• Die Displaylatenz bei der Grau-zu-Grau-, Weiß-zu-Schwarz- und Schwarz-zu-Weiß-Umschaltung DARF maximal 3 ms betragen.
• Das Display MUSS einen Modus mit geringer Nachleuchtdauer mit einer Nachleuchtdauer von ≤ 5 ms unterstützen. Die Nachleuchtdauer wird als die Zeit definiert,während der ein Pixel Licht ausstrahlt.
• Geräteimplementierungen MÜSSEN Bluetooth 4.2 und die Bluetooth LE Data Length Extension (Abschnitt 7.4.3) unterstützen .

8. Leistung und Stromverbrauch

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

8.1. Einheitliche Nutzererfahrung

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

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

8.2. Leistung des Datei-E/A-Zugriffs

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

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

8.3. Energiesparmodi

Mit Android 6.0 wurden die Energiesparmodi „App-Standby“ und „Doze“ eingeführt, um die Akkunutzung zu optimieren. Alle Apps, die von diesen Modi ausgenommen sind, MÜSSEN für den Endnutzer sichtbar sein. Außerdem dürfen die Trigger-, Wartungs- und Weckalgorithmen sowie die Verwendung globaler Systemeinstellungen dieser Energiesparmodi NICHT vom Android Open Source Project abweichen.

Zusätzlich zu den Energiesparmodi können Android-Geräteimplementierungen einen oder alle vier Energiesparmodi implementieren, die von der Advanced Configuration and Power Interface (ACPI) definiert sind. Wenn jedoch die Energiesparmodi S3 und S4 implementiert sind, können diese Modi nur beim Schließen eines Deckels aktiviert werden, der physisch zum Gerät gehört.

8.4. Stromverbrauchserfassung

Eine genauere Erfassung und Berichterstellung des Energieverbrauchs bietet App-Entwicklern sowohl Anreize als auch Tools, um den Energieverbrauch der App zu optimieren. Daher gelten für Geräteimplementierungen folgende Einschränkungen:

• MÜSSEN den Stromverbrauch von Hardwarekomponenten erfassen und diesen Verbrauch bestimmten Anwendungen zuordnen können. Insbesondere gilt dies für Implementierungen:
  • Sie MÜSSEN ein Energieprofil pro Komponente angeben, das den aktuellen Verbrauchswert für jede Hardwarekomponente und den ungefähren Akkuverbrauch definiert, der durch die Komponenten im Laufe der Zeit verursacht wird, wie auf der Website des Android Open Source Project dokumentiert.
  • Alle Werte für den Energieverbrauch MÜSSEN in Milliamperestunden (mAh) angegeben werden.
  • SOLLTE der Hardwarekomponente selbst zugeordnet werden, wenn die Stromaufnahme der Hardwarekomponente keiner Anwendung zugeordnet werden kann.
  • Der CPU-Energieverbrauch muss pro UID des Prozesses angegeben werden. Das Android Open Source Project erfüllt die Anforderung durch die Implementierung des uid_cputime-Kernelmoduls.
• MÜSSEN diese Stromaufnahme über den Shell-Befehl adb shell dumpsys batterystats für den App-Entwickler verfügbar machen.
• MÜSSEN den Intent android.intent.action.POWER_USAGE_SUMMARY berücksichtigen und ein Einstellungsmenü anzeigen, in dem diese Stromnutzung angezeigt wird.

8.5. Konstante Leistung

Bei leistungsstarken, lang laufenden Apps kann die Leistung stark schwanken, entweder aufgrund anderer Apps, die im Hintergrund ausgeführt werden, oder aufgrund der CPU-Drosselung aufgrund von Temperaturlimits. Android bietet programmatische Schnittstellen, mit denen die führende Anwendung im Vordergrund das System bitten kann, die Ressourcenzuweisung zu optimieren, um solche Schwankungen zu beheben.

Geräteimplementierungen MÜSSEN den Modus für nachhaltige Leistung unterstützen, der der aktiven App im Vordergrund über einen längeren Zeitraum eine gleichbleibende Leistung bieten kann, wenn dies über die Window.setSustainedPerformanceMode() API-Methode angefordert wird. Bei der Geräteimplementierung MUSS die Unterstützung des Modus für nachhaltige Leistung korrekt über die API-Methode PowerManager.isSustainedPerformanceModeSupported() gemeldet werden.

Geräteimplementierungen mit zwei oder mehr CPU-Kernen MÜSSEN mindestens einen exklusiven Kern bereitstellen, der von der aktiven Anwendung im Vordergrund reserviert werden kann. Falls vorhanden, MÜSSEN Implementierungen die folgenden Anforderungen erfüllen:

• Implementierungen MÜSSEN über die API-Methode Process.getExclusiveCores() die ID-Nummern der exklusiven Kerne melden, die von der führenden Anwendung im Vordergrund reserviert werden können.
• Geräteimplementierungen dürfen keine Prozesse im Nutzerbereich zulassen, mit Ausnahme der Gerätetreiber, die von der Anwendung auf den exklusiven Kernen ausgeführt werden. Es dürfen jedoch bei Bedarf einige Kernelprozesse ausgeführt werden.

Wenn eine Geräteimplementierung keinen exklusiven Kern unterstützt, MUSS sie über die API-Methode Process.getExclusiveCores() eine leere Liste zurückgeben.

9. Kompatibilität des Sicherheitsmodells

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

9.1. Berechtigungen

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

Berechtigungen mit einer protectionLevel von PROTECTION_FLAG_PRIVILEGED DÜRFEN nur Apps gewährt werden, die in den privilegierten Pfaden(auf der Zulassungsliste) des System-Images vorab geladen wurden, z. B. dem Pfad system/priv-app in der AOSP-Implementierung.

Berechtigungen mit dem Schutzniveau „Schädlich“ sind Laufzeitberechtigungen. Anwendungen mit einer targetSdkVersion > 22 fordern sie zur Laufzeit an. Geräteimplementierungen:

• Es MUSS eine spezielle Benutzeroberfläche geben, über die der Nutzer entscheiden kann, ob er die angeforderten Laufzeitberechtigungen gewähren möchte. Außerdem muss es eine Benutzeroberfläche geben, über die der Nutzer die Laufzeitberechtigungen verwalten kann.
• Es MUSS eine und nur eine Implementierung der beiden Benutzeroberflächen geben.
• Vorinstallierten Apps dürfen KEINE Laufzeitberechtigungen gewährt werden, es sei denn:
  • die Einwilligung des Nutzers eingeholt werden kann, bevor die Anwendung sie verwendet
  • die Laufzeitberechtigungen mit einem Intent-Muster verknüpft sind, für das die vorinstallierte Anwendung als Standard-Handler festgelegt ist

9.2. UID und Prozessisolierung

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

9.3. Dateisystemberechtigungen

Geräteimplementierungen MÜSSEN das Modell für Android-Dateizugriffsberechtigungen unterstützen, wie in der Referenz zu Sicherheit und Berechtigungen definiert .

9.4. Alternative Ausführungsumgebungen

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

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

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

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

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

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

Die .apk-Dateien alternativer Laufzeiten KÖNNEN im System-Image einer Geräteimplementierung enthalten sein, MÜSSEN aber mit einem anderen Schlüssel signiert sein als der Schlüssel, mit dem andere in der Geräteimplementierung enthaltene Anwendungen signiert wurden.

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

9.5. Unterstützung mehrerer Nutzer

Android unterstützt mehrere Nutzer und bietet eine vollständige Nutzerisolierung. Bei Geräteimplementierungen können mehrere Nutzer aktiviert werden. Wenn diese Funktion aktiviert ist, MÜSSEN jedoch die folgenden Anforderungen in Bezug auf die Unterstützung mehrerer Nutzer erfüllt sein :

• Android Automotive-Geräteimplementierungen mit aktivierter Unterstützung für mehrere Nutzer MÜSSEN ein Gastkonto enthalten, mit dem alle vom Fahrzeugsystem bereitgestellten Funktionen genutzt werden können, ohne dass sich ein Nutzer anmelden muss.
• Geräteimplementierungen, die das Feature-Flag „android.hardware.telephony“ nicht deklarieren, MÜSSEN eingeschränkte Profile unterstützen. Mit dieser Funktion können Geräteeigentümer zusätzliche Nutzer und deren Funktionen auf dem Gerät verwalten. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen für zusätzliche Nutzer einrichten und dabei detailliertere Einschränkungen für die in diesen Umgebungen verfügbaren Apps festlegen.
• Geräteimplementierungen, die das Feature-Flag „android.hardware.telephony“ angeben, dürfen KEINE eingeschränkten Profile unterstützen, sondern MÜSSEN der AOSP-Implementierung der Steuerelemente entsprechen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen oder zu deaktivieren.
• Geräteimplementierungen MÜSSEN für jeden Nutzer ein Sicherheitsmodell implementieren, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument zu Sicherheit und Berechtigungen in den APIs definiert.
• Jede Nutzerinstanz auf einem Android-Gerät MUSS separate und isolierte externe Speicherverzeichnisse haben. Bei Geräteimplementierungen KÖNNEN Daten mehrerer Nutzer auf demselben Volume oder Dateisystem gespeichert werden. Die Geräteimplementierung MUSS jedoch dafür sorgen, dass Anwendungen, die einem bestimmten Nutzer gehören und im Namen dieses Nutzers ausgeführt werden, keine Daten auflisten, lesen oder darauf schreiben können, die einem anderen Nutzer gehören. Hinweis: Über Wechselmedien wie SD-Kartensteckplätze kann ein Nutzer über einen Host-PC auf die Daten eines anderen Nutzers zugreifen. Aus diesem Grund MÜSSEN Geräteimplementierungen, die Wechselmedien für die externen Speicher-APIs verwenden, den Inhalt der SD-Karte verschlüsseln, wenn die Mehrfachnutzung aktiviert ist. Dazu muss ein Schlüssel verwendet werden, der nur auf nicht entfernbaren Medien gespeichert ist, auf die nur das System zugreifen kann. Da die Medien dadurch für einen Host-PC unlesbar werden, müssen Geräteimplementierungen zu MTP oder einem ähnlichen System wechseln, um Host-PCs Zugriff auf die Daten des aktuellen Nutzers zu gewähren. Daher KÖNNEN, aber sollten nicht, bei Geräteimplementierungen mehrere Nutzer aktiviert werden, wenn Wechseldatenträger als primärer externer Speicher verwendet werden.

9.6. Warnung zu Premium-SMS

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

9.7. Kernel-Sicherheitsfunktionen

Die Android-Sandbox umfasst Funktionen, die das MAC-System (Mandatory Access Control) von Security-Enhanced Linux (SELinux), das Seccomp-Sandboxing und andere Sicherheitsfunktionen im Linux-Kernel nutzen. SELinux oder andere Sicherheitsfunktionen, die unter dem Android-Framework implementiert sind:

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

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

Auf Geräten MUSS SELinux oder, wenn ein anderer Kernel als Linux verwendet wird, ein gleichwertiges System zur obligatorischen Zugriffssteuerung implementiert sein. Außerdem MÜSSEN die Geräte die folgenden Anforderungen erfüllen, die von der Referenzimplementierung im Upstream-Android-Open-Source-Projekt erfüllt werden.

Geräteimplementierungen:

• SELinux muss auf den globalen Erzwingungsmodus gesetzt werden.
• Alle Domains MÜSSEN im Erzwingungsmodus konfiguriert werden. Domains im permissiven Modus sind nicht zulässig, einschließlich geräte-/anbieterspezifischer Domains.
• Die Neverallow-Regeln im Ordner „system/sepolicy“ des Upstream-Android Open Source Project (AOSP) dürfen NICHT geändert, weggelassen oder ersetzt werden. Die Richtlinie MUSS mit allen vorhandenen Neverallow-Regeln kompiliert werden, sowohl für AOSP-SELinux-Domains als auch für geräte-/anbieterspezifische Domains.
• Das Media Framework muss in mehrere Prozesse aufgeteilt werden, damit für jeden Prozess der Zugriff eingeschränkt werden kann, wie auf der Website des Android Open Source Project beschrieben.

Bei Geräteimplementierungen sollte die Standard-SELinux-Richtlinie im Ordner „system/sepolicy“ des Upstream-Android Open Source Project beibehalten und nur für die eigene gerätespezifische Konfiguration erweitert werden. Geräteimplementierungen MÜSSEN mit dem Upstream-Android-Open-Source-Projekt kompatibel sein.

Auf Geräten MUSS ein Kernel-Sandboxing-Mechanismus für Anwendungen implementiert sein, der das Filtern von Systemaufrufen mithilfe einer konfigurierbaren Richtlinie aus mehrstufigen Programmen ermöglicht. Das Upstream-Android Open Source Project erfüllt diese Anforderung durch die Aktivierung von seccomp-BPF mit Threadgruppensynchronisierung (TSYNC), wie im Abschnitt „Kernel Configuration“ (Kernelkonfiguration) von source.android.com beschrieben .

9.8. Datenschutz

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

Wenn eine Geräteimplementierung einen Mechanismus hat, der den Netzwerkdatenverkehr standardmäßig über einen Proxyserver oder ein VPN-Gateway leitet (z. B. das Vorladen eines VPN-Dienstes mit der Berechtigung „android.permission.CONTROL_VPN“), muss die Geräteimplementierung die Einwilligung des Nutzers einholen, bevor dieser Mechanismus aktiviert wird, es sei denn, das VPN wird vom Device Policy Controller über die DevicePolicyManager.setAlwaysOnVpnPackage() aktiviert. In diesem Fall muss der Nutzer keine separate Einwilligung erteilen, sondern muss nur benachrichtigt werden.

Geräteimplementierungen MÜSSEN mit einem leeren, vom Nutzer hinzugefügten CA-Speicher (Certificate Authority) geliefert werden und MÜSSEN dieselben Stammzertifikate für den vom System als vertrauenswürdig eingestuften CA-Speicher vorinstallieren, die im Upstream-Android Open Source Project bereitgestellt werden.

Wenn Geräte über ein VPN geleitet werden oder eine Nutzer-Root-Zertifizierungsstelle installiert ist, MUSS die Implementierung eine Warnung anzeigen, dass der Netzwerkverkehr für den Nutzer überwacht werden kann.

Wenn eine Geräteimplementierung einen USB-Anschluss mit Unterstützung des USB-Peripheriemodus hat, MUSS eine Benutzeroberfläche angezeigt werden, auf der die Einwilligung des Nutzers eingeholt wird, bevor der Zugriff auf den Inhalt des freigegebenen Speichers über den USB-Anschluss zugelassen wird.

9.9. Datenspeicherverschlüsselung

Wenn die Geräteimplementierung einen sicheren Sperrbildschirm wie in Abschnitt 9.11.1 beschrieben unterstützt, MUSS das Gerät die Datenspeicherverschlüsselung der privaten Daten der Anwendung (/data-Partition) sowie der freigegebenen Speicherpartition der Anwendung (/sdcard-Partition) unterstützen, wenn diese ein permanenter, nicht entfernbarer Teil des Geräts ist.

Bei Geräteimplementierungen, die die Verschlüsselung des Datenspeichers unterstützen und eine AES-Kryptoleistung (Advanced Encryption Standard) von über 50 MiB/s haben, MUSS die Verschlüsselung des Datenspeichers standardmäßig aktiviert sein, wenn der Nutzer die Ersteinrichtung abgeschlossen hat. Wenn eine Geräteimplementierung bereits mit einer älteren Android-Version gestartet wurde, bei der die Verschlüsselung standardmäßig deaktiviert ist, kann dieses Gerät die Anforderung nicht durch ein Systemsoftwareupdate erfüllen und kann daher ggf. ausgenommen werden.

Geräteimplementierungen MÜSSEN die oben genannte Anforderung an die Datenspeicherverschlüsselung durch die Implementierung der dateibasierten Verschlüsselung (File Based Encryption, FBE) erfüllen.

9.9.1. Direct Boot

Alle Geräte MÜSSEN die APIs für den Direktstartmodus implementieren, auch wenn sie die Speicherverschlüsselung nicht unterstützen. Insbesondere müssen die Intents LOCKED_BOOT_COMPLETED und ACTION_USER_UNLOCKED weiterhin gesendet werden, um Direct Boot-kompatiblen Anwendungen zu signalisieren, dass Speicherorte mit Geräteverschlüsselung (Device Encrypted, DE) und Anmeldedatenverschlüsselung (Credential Encrypted, CE) für den Nutzer verfügbar sind.

9.9.2. Dateibasierte Verschlüsselung

Geräteimplementierungen, die FBE unterstützen:

• MUSS ohne Aufforderung des Nutzers zur Eingabe von Anmeldedaten starten und Direct Boot-kompatiblen Apps den Zugriff auf den verschlüsselten Gerätespeicher (Device Encrypted, DE) erlauben, nachdem die Nachricht LOCKED_BOOT_COMPLETED gesendet wurde.
• Der Zugriff auf den verschlüsselten Anmeldedatenspeicher (Credential Encrypted, CE) darf nur gewährt werden, nachdem der Nutzer das Gerät durch Eingabe seiner Anmeldedaten (z. B. Passcode, PIN, Muster oder Fingerabdruck) entsperrt und die Nachricht ACTION_USER_UNLOCKED gesendet wurde. Geräteimplementierungen DÜRFEN KEINE Methode zum Entsperren des durch die Client-Endgeräte-Verschlüsselung geschützten Speichers ohne die vom Nutzer bereitgestellten Anmeldedaten anbieten.
• MÜSSEN den verifizierten Boot unterstützen und dafür sorgen, dass DE-Schlüssel kryptografisch an die Root of Trust-Hardware des Geräts gebunden sind.
• MÜSSEN die Verschlüsselung von Dateiinhalten mit AES mit einer Schlüssellänge von 256 Bit im XTS-Modus unterstützen.
• MUSS die Verschlüsselung des Dateinamens mit AES mit einer Schlüssellänge von 256 Bit im CBC-CTS-Modus unterstützen.
• Es KANN alternative Chiffren, Schlüssellängen und Modi für die Verschlüsselung von Dateiinhalten und Dateinamen unterstützen, MUSS aber standardmäßig die obligatorisch unterstützten Chiffren, Schlüssellängen und Modi verwenden.
• Vorinstallierte wichtige Apps (z.B. Wecker, Telefon, Messenger) MÜSSEN Direct Boot unterstützen.

Die Schlüssel, die die CE- und DE-Speicherbereiche schützen:

• MÜSSEN kryptografisch an einen hardwaregestützten Schlüsselspeicher gebunden sein. CE-Schlüssel müssen an die Anmeldedaten eines Nutzers für den Sperrbildschirm gebunden sein. Wenn der Nutzer keine Anmeldedaten für den Sperrbildschirm angegeben hat, MÜSSEN die CE-Schlüssel an einen Standard-Sicherheitscode gebunden sein.
• MÜSSEN eindeutig und unterschiedlich sein. Mit anderen Worten: Der CE- oder DE-Schlüssel eines Nutzers darf nicht mit dem CE- oder DE-Schlüssel eines anderen Nutzers übereinstimmen.

Das Upstream-Android-Open-Source-Projekt bietet eine bevorzugte Implementierung dieser Funktion, die auf der Ext4-Verschlüsselungsfunktion des Linux-Kernels basiert.

9.9.3. Datenträgervollverschlüsselung

Geräteimplementierungen, die die Datenträgervollverschlüsselung (Full Disk Encryption, FDE) unterstützen. Es MUSS AES mit einem Schlüssel von 128 Bit (oder mehr) und einem für die Speicherung vorgesehenen Modus verwendet werden (z. B. AES-XTS, AES-CBC-ESSIV). Der Verschlüsselungsschlüssel darf niemals unverschlüsselt in den Speicher geschrieben werden. Der Nutzer MUSS die Möglichkeit haben, den Verschlüsselungsschlüssel mit AES zu verschlüsseln, es sei denn, er wird aktiv verwendet. Die Anmeldedaten für den Sperrbildschirm müssen mit einem langsamen Stretching-Algorithmus (z. B. PBKDF2 oder scrypt) gestreckt werden. Wenn der Nutzer keine Anmeldedaten für den Sperrbildschirm angegeben oder die Verwendung des Sicherheitscodes für die Verschlüsselung deaktiviert hat, sollte das System einen Standardsicherheitscode zum Verpacken des Verschlüsselungsschlüssels verwenden. Wenn das Gerät einen hardwaregestützten Schlüsselspeicher bietet, MUSS der Passwort-Stretching-Algorithmus kryptografisch an diesen Schlüsselspeicher gebunden sein. Der Verschlüsselungsschlüssel darf NICHT vom Gerät gesendet werden, auch nicht, wenn er mit dem Sicherheitscode des Nutzers und/oder einem hardwaregebundenen Schlüssel verpackt ist. Das Upstream-Android-Open-Source-Projekt bietet eine bevorzugte Implementierung dieser Funktion, die auf der Linux-Kernel-Funktion „dm-crypt“ basiert.

9.10. Geräteintegrität

Die folgenden Anforderungen sorgen für Transparenz beim Status der Geräteintegrität.

Geräteimplementierungen MÜSSEN über die System API-Methode „PersistentDataBlockManager.getFlashLockState()“ korrekt melden, ob der Bootloader-Status das Flashen des System-Images zulässt. Der Status FLASH_LOCK_UNKNOWN ist für Geräteimplementierungen reserviert, die von einer früheren Android-Version umgestellt werden, in der diese neue System-API-Methode nicht vorhanden war.

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

• Deklarieren Sie das Plattform-Funktions-Flag „android.software.verified_boot“.
• Führen Sie die Überprüfung bei jeder Bootreihenfolge aus.
• Die Überprüfung beginnt mit einem unveränderlichen Hardwareschlüssel, der als Root of Trust dient, und geht bis zur Systempartition.
• Implementieren Sie jede Phase der Überprüfung, um die Integrität und Authentizität aller Bytes in der nächsten Phase zu prüfen, bevor der Code in der nächsten Phase ausgeführt wird.
• Verwenden Sie Überprüfungsalgorithmen, die so stark sind wie die aktuellen Empfehlungen des NIST für Hash-Algorithmen (SHA-256) und öffentliche Schlüsselgrößen (RSA-2048).
• Der Start darf NICHT abgeschlossen werden, wenn die Systemüberprüfung fehlschlägt, es sei denn, der Nutzer stimmt dem Startversuch zu. In diesem Fall dürfen die Daten aus nicht bestätigten Speicherblöcken NICHT verwendet werden.
• Es darf NICHT zulässig sein, bestätigte Partitionen auf dem Gerät zu ändern, es sei denn, der Nutzer hat den Bootloader ausdrücklich entsperrt.

Das Upstream-Android Open Source Project bietet eine bevorzugte Implementierung dieser Funktion, die auf der Linux-Kernel-Funktion dm-verity basiert.

Ab Android 6.0 MÜSSEN Geräteimplementierungen mit einer AES-Kryptoleistung (Advanced Encryption Standard) von über 50 MiB/Sekunde den bestätigten Bootmodus für die Geräteintegrität unterstützen.

Wenn eine Geräteimplementierung bereits ohne Unterstützung des verifizierten Starts in einer früheren Android-Version eingeführt wurde, kann diese Funktion für ein solches Gerät nicht durch ein Systemsoftwareupdate hinzugefügt werden. Es ist daher von der Anforderung ausgenommen.

9.11. Schlüssel und Anmeldedaten

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

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

• Die Anzahl der generierten Schlüssel sollte NICHT begrenzt werden und es müssen mindestens 8.192 Schlüssel importiert werden können.
• Die Authentifizierung über den Sperrbildschirm MUSS eine Ratenbegrenzung für Versuche haben und MUSS einen exponentiellen Backoff-Algorithmus haben. Nach 150 fehlgeschlagenen Versuchen muss die Verzögerung mindestens 24 Stunden pro Versuch betragen.
• Wenn die Geräteimplementierung eine sichere Sperre unterstützt, MUSS die Keystore-Implementierung mit sicherer Hardware gesichert werden und die folgenden Anforderungen erfüllen:
  • MÜSSEN Implementierungen der kryptografischen Algorithmen RSA, AES, ECDSA und HMAC sowie Hash-Funktionen der MD5-, SHA1- und SHA-2-Familie haben, um die unterstützten Algorithmen des Android Keystore-Systems in einem Bereich ordnungsgemäß zu unterstützen, der sicher vom Code isoliert ist, der im Kernel und darüber ausgeführt wird. Die sichere Isolierung MUSS alle potenziellen Mechanismen blockieren, mit denen Kernel- oder Userspace-Code auf den internen Status der isolierten Umgebung zugreifen kann, einschließlich DMA. Das Upstream-Android Open Source Project (AOSP) erfüllt diese Anforderung durch die Verwendung der Trusty-Implementierung. Alternative Optionen sind jedoch eine andere ARM TrustZone-basierte Lösung oder eine von Drittanbietern geprüfte sichere Implementierung einer ordnungsgemäßen hypervisorbasierten Isolation.
  • Die Authentifizierung für den Sperrbildschirm MUSS in der isolierten Ausführungsumgebung erfolgen und nur bei Erfolg dürfen die an die Authentifizierung gebundenen Schlüssel verwendet werden. Das Upstream-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL) und Trusty, mit denen diese Anforderung erfüllt werden kann.

Wenn eine Geräteimplementierung bereits mit einer früheren Android-Version eingeführt wurde, ist dieses Gerät von der Anforderung ausgenommen, einen hardwaregestützten Schlüsselspeicher zu haben, es sei denn, die android.hardware.fingerprint-Funktion wird deklariert, für die ein hardwaregestützter Schlüsselspeicher erforderlich ist.

9.11.1. Sichere Displaysperre

Geräteimplementierungen KÖNNEN Authentifizierungsmethoden zum Entsperren des Sperrbildschirms hinzufügen oder ändern, MÜSSEN aber die folgenden Anforderungen erfüllen:

• Wenn die Authentifizierungsmethode auf einem bekannten Secret basiert, darf sie nur dann als sicherer Sperrbildschirm behandelt werden, wenn sie alle folgenden Anforderungen erfüllt:
  • Die Entropie der kürzesten zulässigen Länge von Eingaben MUSS größer als 10 Bit sein.
  • Die maximale Entropie aller möglichen Eingaben MUSS größer als 18 Bit sein.
  • Darf keine der in AOSP implementierten und bereitgestellten Authentifizierungsmethoden (PIN, Muster, Passwort) ersetzen.
  • MUSS deaktiviert sein, wenn die DPC-Anwendung (Device Policy Controller) die Passwortqualitätsrichtlinie über die Methode DevicePolicyManager.setPasswordQuality() mit einer strengeren Qualitätskonstante als PASSWORD_QUALITY_SOMETHING festgelegt hat .
• Die Authentifizierungsmethode, die auf einem physischen Token oder dem Standort basiert, darf NICHT als sicherer Sperrbildschirm behandelt werden, es sei denn, sie erfüllt alle folgenden Anforderungen:
  • Es MUSS einen Fallback-Mechanismus für die Verwendung einer der primären Authentifizierungsmethoden haben, die auf einem bekannten Geheimnis basiert und die Anforderungen erfüllt, um als sicherer Sperrbildschirm behandelt zu werden.
  • Sie MUSS deaktiviert sein und nur die primäre Authentifizierung zum Entsperren des Bildschirms zulassen, wenn die DPC-Anwendung (Device Policy Controller) die Richtlinie entweder mit der Methode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) oder der Methode DevicePolicyManager.setPasswordQuality() mit einer restriktiveren Qualitätskonstante als PASSWORD_QUALITY_UNSPECIFIED festgelegt hat .
• Die Authentifizierungsmethode, die auf Biometrie basiert, darf NICHT als sicherer Sperrbildschirm behandelt werden, es sei denn, sie erfüllt alle folgenden Anforderungen:
  • Es MUSS einen Fallback-Mechanismus für die Verwendung einer der primären Authentifizierungsmethoden haben, die auf einem bekannten Geheimnis basiert und die Anforderungen erfüllt, um als sicherer Sperrbildschirm behandelt zu werden.
  • Sie MUSS deaktiviert sein und nur die primäre Authentifizierung zum Entsperren des Bildschirms zulassen, wenn die Anwendung „Device Policy Controller“ (DPC) die Richtlinie für die KeGuard-Funktion durch Aufrufen der Methode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) festgelegt hat .
  • Die Falsch-Akzeptanzrate muss gleich oder strenger sein als die für einen Fingerabdrucksensor erforderliche, wie in Abschnitt 7.3.10 beschrieben. Andernfalls muss sie deaktiviert sein und nur die primäre Authentifizierung darf das Entsperren des Displays zulassen, wenn die DPC-Anwendung (Device Policy Controller) die Passwortqualitätsrichtlinie über die Methode DevicePolicyManager.setPasswordQuality() mit einer strengeren Qualitätskonstante als PASSWORD_QUALITY_BIOMETRIC_WEAK festgelegt hat.
• Wenn die Authentifizierungsmethode nicht als sicherer Sperrbildschirm behandelt werden kann, gilt Folgendes:
  • MUSS sowohl für die KeyguardManager.isKeyguardSecure()- als auch für die KeyguardManager.isDeviceSecure()-Methode false zurückgeben.
  • MUSS deaktiviert sein, wenn die DPC-Anwendung (Device Policy Controller) die Passwortqualitätsrichtlinie über die Methode DevicePolicyManager.setPasswordQuality() mit einer strengeren Qualitätskonstante als PASSWORD_QUALITY_UNSPECIFIED festgelegt hat .
  • Die von DevicePolicyManager.setPasswordExpirationTimeout() festgelegten Timer für das Ablaufen von Passwörtern dürfen NICHT zurückgesetzt werden .
  • Der Zugriff auf Schlüsselspeicher darf NICHT authentifiziert werden, wenn die Anwendung KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) aufgerufen hat.
• Wenn die Authentifizierungsmethode auf einem physischen Token, dem Standort oder biometrischen Daten basiert, die eine höhere Falsch-Akzeptanzrate als für Fingerabdrucksensoren haben, wie in Abschnitt 7.3.10 beschrieben, gilt Folgendes:
  • Die von DevicePolicyManager.setPasswordExpirationTimeout() festgelegten Timer für das Ablaufen von Passwörtern dürfen NICHT zurückgesetzt werden .
  • Der Zugriff auf Schlüsselspeicher darf NICHT authentifiziert werden, wenn die Anwendung KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) aufgerufen hat .

9.12. Löschen von Daten

Auf Geräten MUSS Nutzern ein Mechanismus zum Zurücksetzen auf die Werkseinstellungen zur Verfügung stehen, der das logische und physische Löschen aller Daten ermöglicht, mit Ausnahme der folgenden:

• Das System-Image
• Alle vom System-Image benötigten Betriebssystemdateien

Alle von Nutzern erstellten Daten MÜSSEN gelöscht werden. Dies MUSS den relevanten Branchenstandards für das Löschen von Daten wie NIST SP800-88 entsprechen. Dieser muss für die Implementierung der wipeData() API (Teil der Android Device Administration API) verwendet werden, die in Abschnitt 3.9 Geräteverwaltung beschrieben ist .

Geräte KÖNNEN ein schnelles Löschen der Daten anbieten, bei dem die Daten logisch gelöscht werden.

9.13. Abgesicherter Modus

Android bietet einen Modus, in dem nur vorinstallierte System-Apps ausgeführt werden dürfen und alle Drittanbieter-Apps deaktiviert sind. In diesem Modus, dem sogenannten „Abgesicherten Boot-Modus“, können Nutzer potenziell schädliche Drittanbieter-Apps deinstallieren.

Bei der Implementierung von Android-Geräten wird DRINGEND empfohlen, den abgesicherten Modus zu implementieren und die folgenden Anforderungen zu erfüllen:

• Geräteimplementierungen MÜSSEN Nutzern die Möglichkeit bieten, über das Boot-Menü in den abgesicherten Modus zu wechseln. Dieser Modus muss über einen Workflow erreichbar sein, der sich vom normalen Start unterscheidet.

• Geräteimplementierungen MÜSSEN Nutzern die Möglichkeit bieten, den abgesicherten Modus so zu aktivieren, dass er nicht von auf dem Gerät installierten Drittanbieter-Apps unterbrochen werden kann, es sei denn, die Drittanbieter-App ist ein Device Policy Controller und hat das Flag UserManager.DISALLOW_SAFE_BOOT auf „wahr“ gesetzt.

• Geräteimplementierungen MÜSSEN Nutzern die Möglichkeit bieten, Drittanbieter-Apps im abgesicherten Modus zu deinstallieren.

9.14. Isolation des Fahrzeugsystems

Android Automotive-Geräte sollen Daten mit kritischen Fahrzeug-Subsystemen austauschen, z.B. indem sie die HAL des Fahrzeugs verwenden, um Nachrichten über Fahrzeugnetzwerke wie den CAN-Bus zu senden und zu empfangen. Bei der Implementierung von Android Automotive-Geräten MÜSSEN Sicherheitsfunktionen unterhalb der Android-Framework-Ebenen implementiert werden, um schädliche oder unbeabsichtigte Interaktionen zwischen dem Android-Framework oder Drittanbieter-Apps und Fahrzeug-Subsystemen zu verhindern. Zu diesen Sicherheitsfunktionen gehören:

• Gatekeeping-Nachrichten von Fahrzeug-Subsystemen des Android-Frameworks, z. B. Zulassungsliste für zulässige Nachrichtentypen und Nachrichtenquellen
• Schutz vor Denial-of-Service-Angriffen über das Android-Framework oder Drittanbieter-Apps. So wird verhindert, dass Malware das Fahrzeugnetzwerk mit Traffic überlastet, was zu Fehlfunktionen von Fahrzeugsubsystemen führen kann.

10. Softwarekompatibilitätstests

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

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

10.1. Compatibility Test Suite

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

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

10.2. CTS-Verifier

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

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

Auf jedem Gerät und für jede Build-Version MUSS der CTS-Verifier wie oben beschrieben korrekt ausgeführt werden. Da viele Builds jedoch sehr ähnlich sind, wird von Geräteimplementierern nicht erwartet, dass sie den CTS-Verifier explizit auf Builds ausführen, die sich nur unwesentlich unterscheiden. Insbesondere bei Geräteimplementierungen, die sich von einer Implementierung, die den CTS-Verifier bestanden hat, nur durch die enthaltenen Sprachen, das Branding usw. unterscheiden, kann der CTS-Verifier-Test weggelassen werden.

11. Aktualisierbare Software

Geräteimplementierungen MÜSSEN einen Mechanismus zum Ersetzen der gesamten Systemsoftware enthalten. Der Mechanismus muss keine „Live-Upgrades“ ausführen. Das bedeutet, dass ein Neustart des Geräts möglicherweise erforderlich ist.

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

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

Wenn die Geräteimplementierung jedoch die Unterstützung einer unbegrenzten Datenverbindung wie 802.11 oder Bluetooth PAN (Personal Area Network) umfasst, MUSS sie OTA-Downloads mit Offlineaktualisierung über einen Neustart unterstützen.

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

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

Außerdem MÜSSEN Geräteimplementierungen A/B-Systemupdates unterstützen . Das AOSP implementiert diese Funktion mit der Boot Control HAL.

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

Android bietet Funktionen, mit denen die App „Geräteinhaber“ (falls vorhanden) die Installation von Systemupdates steuern kann. Dazu muss das Systemupdate-Subsystem für Geräte, die android.software.device_admin melden, das in der Klasse SystemUpdatePolicy beschriebene Verhalten implementieren.

12. Änderungsprotokoll für Dokumente

Hier eine Zusammenfassung der Änderungen an der Kompatibilitätsdefinition in dieser Version:

• Änderungslog dokumentieren

Hier eine Zusammenfassung der Änderungen an den Abschnitten für Einzelpersonen:

1. Einführung
2. Gerätetypen
3. Software
4. Anwendungs-Packaging
5. Multimedia
6. Entwicklertools und ‑optionen
7. Hardwarekompatibilität
8. Leistung und Stromversorgung
9. Sicherheitsmodell
10. Softwarekompatibilitätstests
11. Aktualisierbare Software
12. Änderungslog für Dokumente
13. Kontakt

12.1. Tipps zum Ansehen des Änderungslogs

Änderungen werden so gekennzeichnet:

• CDD
  Wesentliche Änderungen an den Kompatibilitätsanforderungen.

• Docs
  Änderungen am Erscheinungsbild oder am Build.

Für eine optimale Darstellung sollten Sie die URL-Parameter pretty=full und no-merges an die URLs der Änderungsliste anhängen.

13. Kontakt

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