Kompatibilitätsdefinition für Android 6.0

Inhaltsverzeichnis

1. Einführung

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

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

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

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

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

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

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

2. Gerätetypen

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

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

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

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

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

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

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

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

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

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

2.1 Gerätekonfigurationen

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

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

3. Software

3.1. Kompatibilität mit verwalteten APIs

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

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

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

3.2 Soft API Compatibility

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

3.2.1. Berechtigungen

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

3.2.2. Parameter erstellen

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

Parameter Details
VERSION.RELEASE Die Version des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format. Dieses Feld MUSS einen der Stringwerte haben, die in [Ressourcen, 9] definiert sind.
VERSION.SDK Die Version des derzeit ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 6.0 MUSS dieses Feld den Ganzzahlwert 23 haben.
VERSION.SDK_INT Die Version des derzeit ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 6.0 MUSS dieses Feld den Ganzzahlwert 23 haben.
VERSION.INCREMENTAL Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Version des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format angibt. Dieser Wert darf NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. Dieses Feld wird in der Regel verwendet, um anzugeben, welche Build-Nummer oder Änderungs-ID der Quellkontrollversion zum Generieren des Builds verwendet wurde. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String („"") sein.
BRETTSPIEL Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Hardware des Geräts in einem visuell lesbaren Format angibt. Dieses Feld kann beispielsweise verwendet werden, um die spezifische Version des Boards anzugeben, das das Gerät mit Strom versorgt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
MARKE Ein Wert, der den Markennamen widerspiegelt, der mit dem Gerät verknüpft ist und den Endnutzer kennen. MÜSSEN in einem für Menschen lesbaren Format vorliegen und SOLLEN den Hersteller des Geräts oder die Marke des Unternehmens repräsentieren, unter dem das Gerät vertrieben wird. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
SUPPORTED_ABIS Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
SUPPORTED_32_BIT_ABIS Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
SUPPORTED_64_BIT_ABIS Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
CPU_ABI Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
CPU_ABI2 Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3. Native API-Kompatibilität
GERÄT Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen enthält, der die Konfiguration der Hardwarefunktionen und das Industriedesign des Geräts identifiziert. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
FINGERPRINT Ein String, der diesen Build eindeutig identifiziert. Sie sollte für Menschen gut lesbar sein. Es MUSS dieser Vorlage entsprechen:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Beispiel:

acme/myproduct/
    mydevice:6.0/LMYXX/3359:userdebug/test-keys

Der Fingerabdruck darf KEINE Leerzeichen enthalten. Wenn andere Felder in der Vorlage oben Leerzeichen enthalten, MÜSSEN sie im Build-Fingerabdruck durch ein anderes Zeichen ersetzt werden, z. B. durch den Unterstrich („_“). Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein.
Hardware Der Name der Hardware (aus der Kernel-Befehlszeile oder /proc). Sie sollte in einem für Menschen lesbaren Format vorliegen. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
HOST Ein String, der den Host, auf dem der Build erstellt wurde, eindeutig in einem für Menschen lesbaren Format identifiziert. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
ID Eine vom Geräteimplementierer ausgewählte Kennung für eine bestimmte Version in einem für Menschen lesbaren Format. Dieses Feld kann mit „android.os.Build.VERSION.INCREMENTAL“ identisch sein, sollte aber einen aussagekräftigen Wert haben, damit Endnutzer Software-Builds unterscheiden können. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9._-]+$“ entsprechen.
HERSTELLER Der Handelsname des Erstausrüsters (Original Equipment Manufacturer, OEM) des Produkts. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
MODELL Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endnutzer bekannt ist. Dies sollte derselbe Name sein, unter dem das Gerät vermarktet und an Endnutzer verkauft wird. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
PRODUKT/FUNKTION Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des jeweiligen Produkts (SKU) enthält und innerhalb derselben Marke eindeutig sein MUSS. MÜSSEN für Menschen lesbar sein, sind aber nicht unbedingt für Endnutzer gedacht. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9_-]+$“ entsprechen.
SERIAL Eine Hardware-Seriennummer, die für alle Geräte mit demselben MODELL und HERSTELLER verfügbar und eindeutig sein MUSS. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^([a-zA-Z0-9]{6,20})$“ entsprechen.
TAGS Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt wird und die das Build weiter unterscheidet. Dieses Feld MUSS einen der Werte haben, die den drei gängigen Signaturkonfigurationen der Android-Plattform entsprechen: „release-keys“, „dev-keys“ und „test-keys“.
UHRZEIT Ein Wert, der den Zeitstempel des Builds angibt.
SCHREIBMASCHINE Ein vom Geräteimplementierer ausgewählter Wert, der die Laufzeitkonfiguration des Builds angibt. Dieses Feld MUSS einen der Werte haben, die den drei gängigen Android-Laufzeitkonfigurationen entsprechen: „user“, „userdebug“ oder „eng“.
NUTZER Ein Name oder eine Nutzer-ID des Nutzers (oder automatisierten Nutzers), der den Build generiert hat. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
SECURITY_PATCH Ein Wert, der den Stand der Sicherheits-Patches eines Builds angibt. Es MUSS darauf hinweisen, dass der Build alle Sicherheits-Patches enthält, die bis zum angegebenen öffentlichen Android-Sicherheitsbulletin veröffentlicht wurden. Es MUSS das Format [JJJJ-MM-TT] haben und mit einem der Strings für den Stand der Sicherheitsupdates von Android in den öffentlichen Sicherheitsbulletins übereinstimmen, z. B. „2015-11-01“.
BASE_OS Ein Wert, der dem FINGERPRINT-Parameter des Builds entspricht, der ansonsten mit diesem Build identisch ist, mit Ausnahme der Patches, die im Android Public Security Bulletin bereitgestellt werden. Es MUSS der richtige Wert angegeben werden. Wenn ein solcher Build nicht vorhanden ist, muss ein leerer String („"") angegeben werden.

3.2.3. Intent-Kompatibilität

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

3.2.3.1. Wichtige Anwendungsabsichten

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

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

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

3.2.3.2. Intent-Auflösung

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

Geräteimplementierungen MÜSSEN eine Benutzeroberfläche bereitstellen, über die Nutzer die Standardaktivität für Intents ändern können.

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

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

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

3.2.3.3. Intent-Namespaces

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

3.2.3.4. Broadcast-Intents

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

3.2.3.5. Standard-App-Einstellungen

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

Geräteimplementierungen:

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

3.3 Kompatibilität mit nativen APIs

3.3.1. Application Binary Interfaces

Verwalteter Dalvik-Bytecode kann nativen Code aufrufen, der in der .apk-Datei der Anwendung als ELF-.so-Datei bereitgestellt wird, die für die entsprechende Gerätehardwarearchitektur kompiliert wurde. Da nativer Code stark von der zugrunde liegenden Prozessortechnologie abhängt, definiert Android im Android NDK eine Reihe von Application Binary Interfaces (ABIs). Geräteimplementierungen MÜSSEN mit mindestens einer der definierten ABIs kompatibel sein und MÜSSEN die Kompatibilität mit dem Android NDK implementieren, wie unten beschrieben.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4. Webkompatibilität

3.4.1. WebView-Kompatibilität

Android-Smartwatch-Geräte KÖNNEN, alle anderen Geräteimplementierungen MÜSSEN eine vollständige Implementierung der android.webkit.Webview API bereitstellen.

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

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

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

    • Der Wert des Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE übereinstimmen.
    • Der Wert des Strings „$(MODEL)“ MUSS mit dem Wert für „android.os.Build.MODEL“ übereinstimmen.
    • Der Wert des Strings $(BUILD) MUSS mit dem Wert für android.os.Build.ID übereinstimmen.
    • Der Wert des Strings $(CHROMIUM_VER) MUSS der Version von Chromium im Upstream-Android-Open-Source-Projekt entsprechen.
    • Bei Geräteimplementierungen kann „Mobile“ im User-Agent-String weggelassen werden.

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

3.4.2. Browserkompatibilität

Bei Android Television-, Watch- und Android Automotive-Implementierungen kann eine Browseranwendung weggelassen werden, die öffentlichen Intent-Muster müssen jedoch wie in Abschnitt 3.2.3.1 beschrieben unterstützt werden. Alle anderen Arten von Geräteimplementierungen MÜSSEN eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten.

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

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

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

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

3.5. API-Verhaltenskompatibilität

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

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

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

3.6. API-Namespaces

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

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

Zu den unzulässigen Änderungen gehören:

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

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

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

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

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

3.7. Laufzeitkompatibilität

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

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

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

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

3.8. Kompatibilität der Benutzeroberfläche

3.8.1. Launcher (Startbildschirm)

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

3.8.2. Widgets

Widgets sind für alle Android-Geräte optional, sollten aber auf Android-Handheld-Geräten unterstützt werden.

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

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

3.8.3. Benachrichtigungen

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

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

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

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

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

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

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

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

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

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

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

3.8.5. Toasts

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

3.8.6. Designs

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

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

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

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

Android unterstützt ein Variante-Design mit durchsichtigen Systemleisten, mit dem App-Entwickler den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten füllen können. Damit Entwickler in dieser Konfiguration einheitlich arbeiten können, ist es wichtig, dass der Symbolstil der Statusleiste bei verschiedenen Geräteimplementierungen beibehalten wird. Daher müssen Android-Geräte weiß für Systemstatussymbole (z. B. Signalstärke und Akkustand) und vom System ausgegebene Benachrichtigungen verwenden, es sei denn, das Symbol weist auf einen problematischen Status hin oder eine App fordert mit dem Flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR eine helle Statusleiste an. Wenn eine App eine helle Statusleiste anfordert, MÜSSEN Android-Geräteimplementierungen die Farbe der Systemstatussymbole in Schwarz ändern [Ressourcen, 34].

3.8.7. Live-Hintergründe

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

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

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

3.8.8. Aktivitätswechsel

Da die Navigationstaste für die letzten Funktionen OPTIONAL ist, sind die Anforderungen für die Implementierung des Übersichtsbildschirms für Android-TV-Geräte und Android-Smartwatches OPTIONAL.

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

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

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

3.8.9. Eingabeverwaltung

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

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

3.8.10. Mediensteuerung auf dem Sperrbildschirm

Die Remote Control Client API wird ab Android 5.0 zugunsten der Media Notification Template eingestellt. Mit dieser Vorlage können Medienanwendungen mit Wiedergabesteuerungen integriert werden, die auf dem Sperrbildschirm als Sperrbildschirmbenachrichtigungen angezeigt werden [Ressourcen, 40]. Bei Geräteimplementierungen MUSS die Vorlage für Medienbenachrichtigungen als Teil der in Abschnitt 3.8.3 beschriebenen Sperrbildschirmbenachrichtigungen korrekt gerendert werden.

3.8.11. Träume

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

3.8.12. Standort

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

3.8.13. Unicode und Schriftart

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

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

3.9. Geräteverwaltung

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

3.9.1 Gerätebereitstellung

3.9.1.1 Geräteeigentümer-Bereitstellung

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

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

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

3.9.1.2 Bereitstellung verwalteter Profile

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

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

3.9.2 Unterstützung für verwaltete Profile

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

Geräte mit verwalteten Profilen MÜSSEN:

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

3.10. Bedienungshilfen

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

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

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

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

3.11. Sprachausgabe

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

Android Automotive-Implementierungen:

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

Alle anderen Geräteimplementierungen:

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

3.12. TV Input Framework

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

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

3.12.1. TV-App

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

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

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

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

3.12.1.1. Elektronischer Programmführer

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

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

3.12.1.2. Navigation

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

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

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

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

4. Kompatibilität von Anwendungspaketen

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

Geräteimplementierungen dürfen das APK-Format [Ressourcen, 62], das Android-Manifest [Ressourcen, 49], das Dalvik-Bytecode-Format [Ressourcen, 23] oder das RenderScript-Bytecode-Format nicht so erweitern, dass die Installation und Ausführung dieser Dateien auf anderen kompatiblen Geräten verhindert wird.

5. Multimedia-Kompatibilität

5.1. Medien-Codecs

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

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

5.1.1. Audio-Codecs

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

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

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

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

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

5.1.2. Bildcodecs

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

5.1.3. Video-Codecs

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

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

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

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

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

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

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

5.2. Videocodierung

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

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

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

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

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

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

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

1 Wenn von der Hardware unterstützt.

5.3. Videodekodierung

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4. Audioaufnahmen

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

5.4.1. Aufzeichnung von Roh-Audio

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

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

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

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

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

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

5.4.2. Für Spracherkennung aufnehmen

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

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

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

5.4.3. Daten für die Weiterleitung der Wiedergabe erfassen

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

  • STREAM_RING
  • STREAM_ALARM
  • STREAM_NOTIFICATION

5.5. Audiowiedergabe

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

5.5.1. Rohe Audiowiedergabe

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

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

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

  • Abtastraten: 24.000, 48.000

5.5.2. Audioeffekte

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

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

5.5.3. Lautstärke der Audioausgabe

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

5.6. Audiolatenz

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

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

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

Bei Geräteimplementierungen, die android.hardware.audio.output deklarieren, wird DRINGEND empfohlen, die folgenden Anforderungen an die Audioausgabe zu erfüllen oder zu übertreffen:

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

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

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

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

5.7. Netzwerkprotokolle

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

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

5.8. Secure Media

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

5.9. Musical Instrument Digital Interface (MIDI)

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

Die MIDI-fähigen Hardware-Transporte sind:

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

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

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

5.10. Professionelles Audio

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

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

6. Kompatibilität von Entwicklertools und ‑optionen

6.1. Entwicklertools

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

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

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

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

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

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

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

6.2. Entwickleroptionen

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

7. Hardwarekompatibilität

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

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

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

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

7.1. Display und Grafik

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

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

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

7.1.1. Bildschirmkonfiguration

7.1.1.1. Displaygröße

Android-Smartwatches (siehe Abschnitt 2) KÖNNEN kleinere Bildschirme haben, wie in diesem Abschnitt beschrieben.

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

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

Außerdem

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

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

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

7.1.1.2. Seitenverhältnis des Bildschirms

Android-Smartwatch-Geräte KÖNNEN ein Seitenverhältnis von 1,0 (1:1) haben.

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

7.1.1.3. Bildschirmdichte

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

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

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

7.1.2. Messwerte für Displaykampagnen

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

7.1.3. Displayausrichtung

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

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

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

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

7.1.4. 2D- und 3D-Grafikbeschleunigung

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1.6. Displaytechnologie

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

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

7.1.7. Sekundäre Displays

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

7.2. Eingabegeräte

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

7.2.1. Tastatur

Bei Android Watch- und Android Automotive-Implementierungen kann eine Soft-Tastatur implementiert werden. Alle anderen Geräteimplementierungen MÜSSEN eine Soft-Tastatur implementieren und:

Geräteimplementierungen:

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

7.2.2. Bedienung ohne Touchscreen

Android TV-Geräte MÜSSEN ein D-Pad unterstützen.

Geräteimplementierungen:

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

7.2.3. Navigationstasten

Die Verfügbarkeit und Sichtbarkeit der Funktionen „Startseite“, „Letzte“ und „Zurück“ unterscheiden sich je nach Gerätetyp, wie in diesem Abschnitt beschrieben.

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

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

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

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

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

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

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

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

Android-Geräteimplementierungen, die die Assist-Aktion unterstützen [Ressourcen, 30], MÜSSEN diese Funktion mit einer einzelnen Aktion (z. B. Tippen, Doppelklicken oder Geste) zugänglich machen, wenn andere Navigationstasten sichtbar sind. Es wird DRINGEND empfohlen, als einzelne Aktion das lange Drücken der Startbildschirmtaste oder des Software-Tastensymbols zu verwenden.

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

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

7.2.4. Touchscreen-Eingabe

Android-Handhelds und -Smartwatches MÜSSEN die Eingabe per Touchscreen unterstützen.

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

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

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

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

7.2.5. Gefälschte Eingabe per Berührung

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

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

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

7.2.6. Unterstützung für Gamecontroller

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

7.2.6.1. Tastenbelegung

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

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

1 [Ressourcen, 88]

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

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

4 [Resources, 87]

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

1 [Ressourcen, 87]

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 [Ressourcen, 88].

7.3. Sensoren

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

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

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

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

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

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

7.3.1. Beschleunigungsmesser

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

  • Der Sensor TYPE_ACCELEROMETER MUSS implementiert und erfasst werden [Ressourcen, 94].
  • MUSS Ereignisse mit einer Häufigkeit von mindestens 50 Hz für Android-Smartwatches erfassen können, da diese Geräte strengere Energieeinschränkungen haben, und 100 Hz für alle anderen Gerätetypen.
  • MÜSSEN Ereignisse mit mindestens 200 Hz erfassen.
  • MÜSSEN dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs [Ressourcen, 90] beschrieben.
  • MÜSSEN in der Lage sein, von freiem Fall bis zu viermal die Erdbeschleunigung (4 g) oder mehr auf jeder Achse zu messen.
  • MÜSSEN eine Auflösung von mindestens 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.Sie sollte pro Achse anhand von Stichproben berechnet werden, die über einen Zeitraum von mindestens 3 Sekunden mit der höchsten Abtastrate erfasst wurden.
  • MÜSSEN die zusammengesetzten Sensoren TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR und TYPE_STEP_COUNTER wie im Android SDK-Dokument beschrieben implementieren. Für bestehende und neue Android-Geräte wird DRINGEND empfohlen, den zusammengesetzten Sensor TYPE_SIGNIFICANT_MOTION zu implementieren. Wenn einer dieser Sensoren implementiert ist, darf die Summe der Leistungsaufnahme immer weniger als 4 mW betragen und sollte für den dynamischen oder statischen Zustand des Geräts jeweils unter 2 mW und 0,5 mW liegen.
  • Wenn ein Gyroskopsensor enthalten ist, MÜSSEN die zusammengesetzten Sensoren TYPE_GRAVITY und TYPE_LINEAR_ACCELERATION implementiert werden und SOLLTE der zusammengesetzte Sensor TYPE_GAME_ROTATION_VECTOR implementiert werden. 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 ein Gyroskopsensor und ein Magnetometersensor vorhanden sind.

7.3.2. Magnetometer

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

  • Der Sensor vom Typ „MAGNETFELD“ MUSS implementiert sein und der Sensor vom Typ „MAGNETFELD_NICHT KALLIBRIERT“ SOLLTE implementiert sein. 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 erfassen und SOLLTEN Ereignisse mit einer Häufigkeit von mindestens 50 Hz erfassen.
  • MÜSSEN dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs [Ressourcen, 90] 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 µ betragen.
  • SOLLTE temperaturkompensiert sein.
  • MÜSSEN die Onlinekalibrierung und ‑kompensation der Magnetfeldabweichung unterstützen und die Kompensationsparameter zwischen den Neustarts des Geräts beibehalten.
  • Die weichmagnetische Kalibrierung MUSS angewendet werden. Die Kalibrierung kann entweder während der Nutzung oder während der Herstellung des Geräts erfolgen.
  • Die Standardabweichung, die auf der Grundlage von Stichproben berechnet wird, die über einen Zeitraum von mindestens 3 Sekunden mit der schnellsten Abtastrate erfasst wurden, sollte pro Achse nicht größer als 0,5 µT sein.
  • Es 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 weniger als 10 mW und sollte weniger als 3 mW verbrauchen, wenn er für den Batchmodus bei 10 Hz registriert ist.

7.3.3. GPS

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

7.3.4. Gyroskop

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

  • Der Sensor vom Typ TYPE_GYROSCOPE MUSS implementiert werden und der Sensor vom Typ TYPE_GYROSCOPE_UNCALIBRATED SOLLTE ebenfalls implementiert werden. 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.
  • MUSS Ereignisse mit einer Häufigkeit von mindestens 50 Hz für Android-Smartwatches erfassen können, da diese Geräte strengere Energieeinschränkungen haben, und 100 Hz für alle anderen Gerätetypen.
  • MÜSSEN Ereignisse mit mindestens 200 Hz erfassen.
  • Die Auflösung MUSS mindestens 12 Bit betragen und SOLLTE mindestens 16 Bit betragen.
  • MÜSSEN temperaturkompensiert sein.
  • MÜSSEN während der Nutzung kalibriert und kompensiert werden und die Kompensationsparameter zwischen den Neustarts des Geräts beibehalten.
  • Die Abweichung darf maximal 1 · 10−7 rad² / s² pro Hz betragen (Abweichung pro Hz oder rad² / s). Die Abweichung darf mit der Abtastrate variieren, muss aber durch diesen Wert begrenzt sein. Mit anderen Worten: Wenn Sie die Varianz des Gyroskops bei einer Abtastrate von 1 Hz messen, darf sie nicht größer als 1 E-7 rad²/s² sein.
  • Es 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 SOLLTE der zusammengesetzte Sensor TYPE_GAME_ROTATION_VECTOR 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 er als SENSOR_TYPE_AMBIENT_TEMPERATURE definiert sein und MUSS die Umgebungstemperatur (Raumtemperatur) in Grad Celsius messen.

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

7.3.7. Fotometer

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

7.3.8. Näherungssensor

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

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

7.3.9. Hochpräzise Sensoren

Bei Geräteimplementierungen, die eine Reihe von Sensoren mit 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.
    • MÜSSEN eine Messauflösung von mindestens 1.024 LSB/G haben
    • Die Mindestmessungsfrequenz muss 12,5 Hz oder weniger betragen.
    • Die maximale Messfrequenz muss mindestens 200 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.
  • 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 200 Hz betragen.
    • Der Messrauschen darf maximal 0,014 °/s/√Hz betragen.
  • SENSOR_TYPE_GYROSCOPE_UNCALIBRATED mit denselben Qualitätsanforderungen wie SENSOR_TYPE_GYROSCOPE
  • SENSOR_TYPE_GEOMAGNETIC_FIELD
    • Der Messbereich muss mindestens -900 und +900 uT betragen.
    • MÜSSEN eine Messauflösung von mindestens 5 LSB/uT haben
    • 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.
  • 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-Energieverbrauch 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, Gyroskop und Magnetometer erfasst wird, darf maximal 2,5 Millisekunden voneinander abweichen.
  • Die Zeitstempel der Gyroskopsensorereignisse MÜSSEN auf derselben Zeitbasis wie das Kamera-Subsystem liegen und eine Abweichung von maximal 1 Millisekunde haben.
  • Die Latenz bei der Übermittlung von Samples an die HAL sollte unter 5 Millisekunden liegen, sobald die Daten auf der physischen Sensorhardware verfügbar sind.
  • Die Leistungsaufnahme darf bei inaktivem Gerät nicht über 0,5 mW und bei in Bewegung befindlichem Gerät nicht über 2,0 mW liegen, 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, 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 Drittanbieterentwickler hat, 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 [Ressourcen, 95].
  • Die Falsch-Akzeptanzrate darf maximal 0,002 % betragen.
  • Es wird DRINGEND empfohlen, dass die Falsch-Ablehnungsrate auf dem Gerät unter 10 % liegt.
  • Es wird DRINGEND empfohlen, dass die Latenz für einen registrierten Finger unter einer 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 die Fingerabdruckabgleiche 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 dokumentiert [Ressourcen, 96].
  • Es MUSS verhindert werden, dass ein Fingerabdruck hinzugefügt wird, ohne zuerst eine Vertrauenskette zu erstellen, indem der Nutzer vorhandene Anmeldedaten (PIN/Muster/Passwort) bestätigt oder neue Anmeldedaten hinzufügt, 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.4. Datenverbindung

7.4.1. Telefonie

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

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

7.4.2. IEEE 802.11 (Wi‑Fi)

Android TV-Geräte müssen WLAN unterstützen.

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

  • Das Hardware-Funktions-Flag „android.hardware.wifi“ MUSS angegeben werden.
  • Die Multicast API muss wie in der SDK-Dokumentation beschrieben implementiert werden [Ressourcen, 97].
  • 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 werden [Ressourcen, 98]. 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.

Android TV-Geräte müssen WLAN-Tunneled Direct Link Setup (TDLS) unterstützen.

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

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

7.4.3. Bluetooth

Android Watch- und Automotive-Implementierungen MÜSSEN Bluetooth unterstützen. Android-Fernseher müssen Bluetooth und Bluetooth LE unterstützen.

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

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

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

7.4.4. Nahfeldkommunikation

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

  • Die Funktion „android.hardware.nfc“ muss über die Methode „android.content.pm.PackageManager.hasSystemFeature()“ gemeldet werden [Ressourcen, 70].
  • MÜSSEN NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können:
    • MUSS als NFC-Forum-Lese-/Schreibgerät (wie in der technischen Spezifikation NFCForum-TS-DigitalProtocol-1.0 des NFC-Forums definiert) über die folgenden NFC-Standards funktionieren:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS 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 und Rohdaten über die folgenden NFC-Standards lesen und schreiben zu können. Hinweis: 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-Barcodeprodukten [Ressourcen, 102] 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 [Resources, 103]
      • SNEP 1.0 (vom NFC-Forum definiert)
    • MÜSSEN Android Beam unterstützen [Ressourcen, 104]:
      • Der SNEP-Standardserver MUSS implementiert werden. Gültige NDEF-Nachrichten, die vom Standard-SNEP-Server empfangen werden, MÜSSEN an Anwendungen mithilfe des Intents „android.nfc.ACTION_NDEF_DISCOVERED“ gesendet werden. Wenn Sie Android Beam in den Einstellungen deaktivieren, darf der Versand eingehender NDEF-Nachrichten NICHT deaktiviert werden.
      • Die Intent-Aktion „android.settings.NFCSHARING_SETTINGS“ MUSS berücksichtigt werden, um die NFC-Freigabeeinstellungen anzuzeigen [Ressourcen, 105].
      • Der NPP-Server MUSS implementiert sein. Nachrichten, die vom NPP-Server empfangen werden, MÜSSEN auf die gleiche Weise verarbeitet werden wie vom SNEP-Standardserver.
      • MUSS einen SNEP-Client implementieren und versuchen, ausgehende P2P-NDEF-Nachrichten an den Standard-SNEP-Server zu senden, wenn Android Beam aktiviert ist. Wenn kein standardmäßiger SNEP-Server gefunden wird, MUSS der Client versuchen, an einen NPP-Server zu senden.
      • Es MUSS zulässig sein, dass Aktivitäten im Vordergrund die ausgehende P2P-NDEF-Nachricht mit den Funktionen „android.nfc.NfcAdapter.setNdefPushMessage“, „android.nfc.NfcAdapter.setNdefPushMessageCallback“ und „android.nfc.NfcAdapter.enableForegroundNdefPush“ festlegen.
      • SOLLTE eine Geste oder Bestätigung auf dem Bildschirm verwenden, z. B. „Zum Übertragen berühren“, bevor ausgehende P2P-NDEF-Nachrichten gesendet werden.
      • Android Beam MUSS standardmäßig aktiviert sein und MUSS über Android Beam senden und empfangen können, auch wenn ein anderer proprietärer NFC-P2P-Modus aktiviert ist.
      • MUSS die NFC-Verbindungsweitergabe an Bluetooth unterstützen, wenn das Gerät das Bluetooth Object Push Profile unterstützt. Geräteimplementierungen MÜSSEN die Verbindungsweitergabe an Bluetooth unterstützen, wenn sie android.nfc.NfcAdapter.setBeamPushUris verwenden. Dazu müssen die Spezifikationen „Connection Handover version 1.2“ [Ressourcen, 106] und „Bluetooth Secure Simple Pairing Using NFC version 1.0“ [Ressourcen, 107] des NFC Forums implementiert werden. Eine solche Implementierung MUSS den LLCP-Übergabedienst mit dem Dienstnamen „urn:nfc:sn:handover“ zum Austausch von Übergabeanfragen/-auswahlen über NFC implementieren und MUSS das Bluetooth Object Push Profile für die eigentliche Bluetooth-Datenübertragung verwenden. Aus Gründen der Abwärtskompatibilität (für die Kompatibilität mit Android 4.1-Geräten) sollte die Implementierung weiterhin SNEP-GET-Anfragen zum Austausch der Übergabeanfrage/Auswahldatensätze über NFC akzeptieren. Eine Implementierung sollte jedoch KEINE SNEP-GET-Anfragen zum Übergeben der Verbindung senden.
    • MUSS im NFC-Erkennungsmodus nach allen unterstützten Technologien suchen.
    • MÜSSEN sich im NFC-Erkennungsmodus befinden, während das Gerät aktiv ist, das Display eingeschaltet und der Sperrbildschirm entsperrt ist.

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

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

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

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

  • MIFARE Classic
  • MIFARE Ultralight
  • NDEF auf MIFARE Classic

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

  • MÜSSEN die entsprechenden Android APIs gemäß der Dokumentation des Android SDK implementieren.
  • Die Funktion „com.nxp.mifare“ MUSS über die Methode „android.content.pm.PackageManager.hasSystemFeature()“ gemeldet werden [Ressourcen, 70]. 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()“ [Ressourcen, 70] deklariert werden. Außerdem muss die Android NFC API als No-Op implementiert werden.

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

7.4.5. Mindestnetzwerkanforderungen

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

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

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

Geräte MÜSSEN einen IPv6-Netzwerkstack enthalten und die IPv6-Kommunikation mithilfe der verwalteten APIs wie java.net.Socket und java.net.URLConnection sowie der 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 reinen IPv6-Betrieb ü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 möglicherweise 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 Unicast-IPv6-Pakete, die an das Gerät gesendet werden, 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 [Ressourcen, 109].

7.5. Kameras

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

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

7.5.1. Rückkamera

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

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

7.5.2. Frontkamera

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

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

7.5.3. Externe Kamera

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

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

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

7.5.4. Verhalten der Camera API

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

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

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

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

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

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

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

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

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

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

7.5.5. Kameraausrichtung

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

7.6. Arbeitsspeicher und Datenspeicher

7.6.1. Mindestarbeitsspeicher und Mindestspeicherplatz

Android TV-Geräte MÜSSEN mindestens 5 GB nichtflüchtigen Speicher für private Daten der Anwendung haben.

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

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

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

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

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

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

7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen

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

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

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

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

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

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

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

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

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

  • MÜSSEN mit dem Referenz-Android-MTP-Host, Android File Transfer, kompatibel sein [Ressourcen, 116].
  • 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, anpassbaren Speicher zu implementieren, wenn sich der Anschluss für das Wechselspeichergerät an einem dauerhaft stabilen Ort befindet, z. B. im Akkufach oder in einer anderen Schutzabdeckung [Ressourcen, 117].

Bei Geräten wie Fernsehern kann die Implementierung über USB-Ports MÖGLICHERWEISE möglich sein, da das Gerät voraussichtlich statisch und nicht mobil ist. Bei anderen mobilen Geräten wird jedoch DRINGEND empfohlen, den anpassbaren Speicher an einem dauerhaft stabilen Ort zu implementieren, da ein versehentliches Trennen 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.

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

  • Der Anschluss MUSS mit einem USB-Host mit einem Standard-USB-Typ-A- oder -Typ-C-Anschluss verbunden werden können.
  • Der Port sollte den USB-Formfaktor Micro-B, Micro-AB oder Typ-C haben. Wir EMPFEHLEN dringend, diese Anforderungen für bestehende und neue Android-Geräte zu erfüllen, damit sie auf zukünftige Plattformversionen umgestellt werden können.
  • Der Anschluss sollte sich entweder an der Unterseite des Geräts befinden (bei normaler Ausrichtung) oder die Bildschirmdrehung für alle Apps (einschließlich des Startbildschirms) ermöglichen, damit das Display korrekt dargestellt wird, wenn sich das Gerät mit dem Anschluss nach unten befindet. Für bestehende und neue Android-Geräte wird DRINGEND empfohlen, diese Anforderungen zu erfüllen, damit sie auf zukünftige Plattformversionen umgestellt werden können.
  • Es MUSS die Android Open Accessory API (AOA) und die Spezifikation gemäß der Dokumentation des Android SDK implementieren. Bei einem Android-Handheld-Gerät MUSS die AOA API implementiert sein. Geräteimplementierungen, die die AOA-Spezifikation implementieren:
    • MÜSSEN die Unterstützung für die Hardwarefunktion „android.hardware.usb.accessory“ angeben [Ressourcen, 118].
    • Es MUSS die Einrichtung einer AOA-protokollbasierten Kommunikation bei der erstmaligen Verbindung mit einem USB-Hostcomputer unterstützen, der als Zubehör dient, ohne dass der Nutzer den Standard-USB-Modus ändern muss.
    • Die USB-Audioklasse muss gemäß der Dokumentation des Android SDK implementiert werden [Ressourcen, 119].
    • Außerdem muss die USB-Massenspeicherklasse am Ende des Interface-Beschreibungsstrings iInterface des USB-Massenspeichers den String „android“ enthalten.
  • Es MUSS die Unterstützung für einen Stromverbrauch von 1,5 A während HS-Chirp und -Traffic implementieren, wie in der USB Battery Charging Specification, Revision 1.2 [Resources, 120] 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.
    • den Typ-C-Widerstandsstandard.
  • Der Wert von „iSerialNumber“ im USB-Standardgeräte-Descriptor MUSS mit dem Wert von „android.os.Build.SERIAL“ übereinstimmen.

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

  • Es sollte ein USB-Typ-C-Anschluss verwendet werden, wenn die Geräteimplementierung USB 3.1 unterstützt.
  • Es kann ein nicht standardmäßiger Port-Formfaktor verwendet werden. In diesem Fall MUSS das Gerät jedoch mit einem oder mehreren Kabeln geliefert werden, die den Anschluss an einen Standard-USB-Typ-A- oder -Typ-C-Anschluss ermöglichen.
  • Es kann ein Micro-AB-USB-Anschluss verwendet werden. In diesem Fall MUSS ein Kabel oder mehrere Kabel zum Anschließen an einen Standard-USB-Anschluss vom Typ A oder Typ C mitgeliefert werden.
  • Es wird DRINGEND empfohlen, die USB-Audioklasse gemäß der Dokumentation des Android SDK [Ressourcen, 119] zu implementieren.
  • Die Android USB Host API muss gemäß der Dokumentation im Android SDK implementiert werden und die Unterstützung für die Hardwarefunktion „android.hardware.usb.host“ muss erklärt werden [Ressourcen, 121].
  • 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“ (Begrenzungsparameter) der USB Type-C Cable and Connector Specification, Revision 1.2 [] für USB-Typ-C-Anschlüsse oder mit dem Ausgabestrombereich des Charging Downstream Port (CDP) gemäß der USB Battery Charging Specification, Revision 1.2 [Resources, 120] für Micro-AB-Anschlüsse angegeben.

7.8. Audio

7.8.1. Mikrofon

Android-Implementierungen für Smartphones, Smartwatches und die Automobilbranche MÜSSEN ein Mikrofon enthalten.

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

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

7.8.2. Audioausgabe

Android-Smartwatches KÖNNEN eine Audioausgabe haben.

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

  • Die Funktion „android.hardware.audio.output“ MUSS als Konstante gemeldet werden.
  • MÜSSEN die Anforderungen an die Audiowiedergabe in Abschnitt 5.5 erfüllen.
  • MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.6 erfüllen.
  • 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äten MÜSSEN jedoch eine Audioausgabe haben und android.hardware.audio.output angeben.

7.8.2.1. Analoge Audioports

Damit das Gerät mit Headsets und anderem Audiozubehör kompatibel ist, das den 3,5‑mm-Audiostecker verwendet, muss mindestens einer der Audioanschlüsse eine 4-polige 3,5‑mm-Audiobuchse sein. [Ressourcen, 122] Wenn eine Geräteimplementierung eine 3,5‑mm-Audiobuchse mit vier Adern hat, gilt Folgendes:

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

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, gilt Folgendes:
    • Die durchschnittliche 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 (SNR) 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 um mehr als 40 dB unter der Antwort bei 2 kHz liegen.

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 mal pro Sekunde auftreten und sollte unter 1 Frame pro Sekunde liegen.
  • Latenz der Benutzeroberfläche Geräteimplementierungen MÜSSEN eine geringe Latenz gewährleisten, indem eine Liste mit 10.000 Listeneinträgen gemäß der Android Compatibility Test Suite (CTS) in weniger als 36 Sekunden gescrollt wird.
  • Aufgabenwechsel Wenn mehrere Anwendungen gestartet wurden, darf das erneute Starten einer bereits laufenden Anwendung nach dem Start weniger als eine Sekunde dauern.

8.2. Leistung des Datei-E/A-Zugriffs

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

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

8.3. Energiesparmodi

Alle Apps, die vom App-Standby- und/oder Ruhemodus ausgenommen sind, MÜSSEN für den Endnutzer sichtbar sein. Außerdem dürfen die Trigger-, Wartungs- und Weckalgorithmen sowie die Verwendung der globalen Systemeinstellungen dieser Energiesparmodi NICHT vom Android Open Source Project abweichen.

8.4. Stromverbrauchserfassung

Eine genauere Erfassung und Berichterstellung des Energieverbrauchs bietet App-Entwicklern sowohl Anreize als auch Tools, um das Verbrauchsmuster 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 Folgendes für Implementierungen:
    • Es MUSS ein Energieprofil pro Komponente bereitgestellt werden, das den aktuellen Verbrauchswert für jede Hardwarekomponente und die ungefähre Akkuentladung durch die Komponenten im Laufe der Zeit definiert, wie auf der Website des Android Open Source Project [Ressourcen, 123] 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 adb shell dumpsys batterystats-Shell-Befehl für den App-Entwickler verfügbar machen [Ressourcen, 124].
  • MÜSSEN den Intent „android.intent.action.POWER_USAGE_SUMMARY“ berücksichtigen und ein Einstellungsmenü anzeigen, in dem diese Stromnutzung angezeigt wird [Ressourcen, 125].

9. Kompatibilität des Sicherheitsmodells

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

9.1. Berechtigungen

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

Berechtigungen mit dem Schutzniveau „Schädlich“ sind Laufzeitberechtigungen. Anwendungen mit einer targetSdkVersion von über 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 ordnungsgemäß signiert und erstellt sind, wie in der Referenz zu Sicherheit und Berechtigungen [Ressourcen, 126] definiert.

9.3. Dateisystemberechtigungen

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

9.4. Alternative Ausführungsumgebungen

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

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

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

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

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

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

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

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

9.5. Unterstützung mehrerer Nutzer

Diese Funktion ist für alle Gerätetypen optional.

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

  • Geräteimplementierungen, die das Feature-Flag „android.hardware.telephony“ nicht deklarieren, MÜSSEN eingeschränkte Profile unterstützen. Mit dieser Funktion können Geräteeigentümer zusätzliche Nutzer und deren Funktionen auf dem Gerät verwalten. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen für zusätzliche Nutzer einrichten und detailliertere Einschränkungen in den Apps verwalten, die in diesen Umgebungen verfügbar sind.
  • Geräteimplementierungen, die das Feature-Flag „android.hardware.telephony“ deklarieren, dürfen KEINE eingeschränkten Profile unterstützen, sondern MÜSSEN der AOSP-Implementierung von Steuerelementen entsprechen, um anderen Nutzern den Zugriff auf Sprachanrufe und SMS zu ermöglichen oder zu deaktivieren.
  • Bei Geräteimplementierungen MUSS für jeden Nutzer ein Sicherheitsmodell implementiert werden, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument zu Sicherheit und Berechtigungen in den APIs definiert [Ressourcen, 126].
  • Jede Nutzerinstanz auf einem Android-Gerät MUSS separate und isolierte externe Speicherverzeichnisse haben. Bei Geräteimplementierungen KÖNNEN Daten mehrerer Nutzer auf demselben Volume oder Dateisystem gespeichert werden. Die Geräteimplementierung MUSS jedoch dafür sorgen, dass Anwendungen, die einem bestimmten Nutzer gehören und in seinem Namen ausgeführt werden, keine Daten eines anderen Nutzers auflisten, lesen oder darauf schreiben können. Hinweis: Über Wechselmedien wie SD-Kartensteckplätze kann ein Nutzer über einen Host-PC auf die Daten eines anderen Nutzers zugreifen. Aus diesem Grund MÜSSEN Geräteimplementierungen, die Wechselmedien für die primären 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, die Mehrfachnutzung für Geräte implementiert werden, wenn sie Wechselmedien [Ressourcen, 129] als primären externen Speicher verwenden.

9.6. Warnung zu Premium-SMS

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

9.7. Kernel-Sicherheitsfunktionen

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

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

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

Auf Geräten MUSS SELinux implementiert sein oder, wenn ein anderer Kernel als Linux verwendet wird, ein gleichwertiges System zur obligatorischen Zugriffssteuerung. Geräte MÜSSEN außerdem die folgenden Anforderungen erfüllen, die von der Referenzimplementierung im Upstream-Android Open Source Project 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 „external/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.

Bei Geräteimplementierungen sollte die Standard-SELinux-Richtlinie im Ordner „external/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.

9.8. Datenschutz

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

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

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 gewährt wird.

9.9. Datenträgervollverschlüsselung

Optional für Android-Geräteimplementierungen ohne Sperrbildschirm.

Wenn die Geräteimplementierung einen sicheren Sperrbildschirm unterstützt, der „true“ für KeyguardManager.isDeviceSecure() meldet [Resources, 131], und kein Gerät mit eingeschränktem Arbeitsspeicher ist, wie über die Methode ActivityManager.isLowRamDevice() gemeldet, MUSS das Gerät die Volldiskenverschlüsselung [Resources, 132] der privaten Daten der Anwendung (/data-Partition) sowie der freigegebenen Speicherpartition der Anwendung (/sdcard-Partition) unterstützen, wenn es sich um einen dauerhaften, nicht entfernbaren Teil des Geräts handelt.

Bei Geräteimplementierungen, die die Festplattenvollverschlüsselung unterstützen und eine AES-Kryptoleistung von über 50 MiB/s haben, MUSS die Festplattenvollverschlüsselung 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 Datenträgervollverschlüsselung standardmäßig deaktiviert ist, kann diese Anforderung nicht durch ein Systemsoftwareupdate erfüllt werden. Das Gerät kann daher ggf. ausgenommen werden.

Für die Verschlüsselung MUSS AES mit einem Schlüssel von mindestens 128 Bit und einem für die Speicherung vorgesehenen Modus verwendet werden (z. B. AES-XTS, AES-CBC-ESSIV). Der Verschlüsselungsschlüssel darf niemals unverschlüsselt in den Speicher geschrieben werden. Außer bei aktiver Nutzung sollte der Verschlüsselungsschlüssel mit dem Passcode des Sperrbildschirms mit einem langsamen Stretching-Algorithmus (z.B. PBKDF2 oder scrypt) AES-verschlüsselt werden. Wenn der Nutzer keinen Sicherheitscode für den Sperrbildschirm angegeben oder die Verwendung des Sicherheitscodes für die Verschlüsselung deaktiviert hat, sollte das System einen Standardsicherheitscode zum Verpacken des Verschlüsselungsschlüssels verwenden. Wenn das Gerät einen hardwaregestützten Schlüsselspeicher bietet, MUSS der Passwort-Stretching-Algorithmus kryptografisch an diesen Schlüsselspeicher gebunden sein. Der Verschlüsselungsschlüssel darf NICHT vom Gerät gesendet werden, auch nicht, wenn er mit dem Sicherheitscode des Nutzers und/oder einem hardwaregebundenen Schlüssel verpackt ist. Das Upstream-Android-Open-Source-Projekt bietet eine bevorzugte Implementierung dieser Funktion, die auf der Linux-Kernelfunktion „dm-crypt“ basiert.

9.10. Verified Boot

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

  • Deklarieren Sie das Plattform-Funktions-Flag „android.software.verified_boot“.
  • Überprüfung bei jeder Bootreihenfolge durchführen
  • Die Überprüfung beginnt mit einem 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.
  • Überprüfungsalgorithmen verwenden, die den aktuellen Empfehlungen des NIST für Hash-Algorithmen (SHA-256) und Public-Key-Größen (RSA-2048) entsprechen

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-Kryptografieleistung 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 dieses 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 Keystore-System [Ressourcen, 133] können App-Entwickler kryptografische Schlüssel in einem Container speichern und sie über die KeyChain API [Ressourcen, 134] oder die Keystore API [Ressourcen, 135] 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 Sperrbildschirmauthentifizierung MUSS die Anzahl der Versuche begrenzen und SOLLTE einen exponentiellen Backoff-Algorithmus haben, wie er im Android Open Source Project implementiert ist.
  • Wenn die Geräteimplementierung einen sicheren Sperrbildschirm unterstützt und eine sichere Hardware wie ein Secure Element (SE) hat, in dem eine vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) implementiert werden kann, gilt Folgendes:
    • Es wird DRINGEND empfohlen, die Schlüsselspeicherimplementierung mit der sicheren Hardware zu sichern. Das Upstream-Android Open Source Project bietet die Keymaster Hardware Abstraction Layer (HAL)-Implementierung, mit der diese Anforderung erfüllt werden kann.
    • Die Authentifizierung auf dem Sperrbildschirm MUSS auf der sicheren Hardware ausgeführt werden, wenn das Gerät eine hardwaregestützte Keystore-Implementierung hat. Die Authentifizierungsgebundenen Schlüssel dürfen nur dann verwendet werden, wenn die Authentifizierung erfolgreich war. Das Upstream-Android Open Source Project bietet die Gatekeeper Hardware Abstraction Layer (HAL), mit der diese Anforderung erfüllt werden kann [Resources, 136].

Die oben genannten TEE-Anforderungen sind zwar als „STARK EMPFOHLEN“ gekennzeichnet, in der Kompatibilitätsdefinition für die nächste API-Version werden sie jedoch voraussichtlich in „ERFORDERLICH“ geändert. Wenn eine Geräteimplementierung bereits mit einer älteren Android-Version gestartet wurde und kein vertrauenswürdiges Betriebssystem auf der sicheren Hardware implementiert wurde, kann ein solches Gerät die Anforderungen möglicherweise nicht durch ein Systemsoftwareupdate erfüllen. Daher wird dringend empfohlen, ein TEE zu implementieren.

9.12. Löschen von Daten

Auf Geräten MUSS Nutzern ein Mechanismus zum Zurücksetzen auf die Werkseinstellungen zur Verfügung stehen, mit dem alle Daten logisch und physisch gelöscht werden können, mit Ausnahme des System-Images und der Daten in anderen Partitionen, die als Teil des System-Images betrachtet werden können. 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 wird.

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

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 möglichen Geräteupdates führen.

10.1. Compatibility Test Suite

Geräteimplementierungen MÜSSEN die Android Compatibility Test Suite (CTS) [Ressourcen, 137] 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 6.0 veröffentlicht werden. Geräteimplementierungen MÜSSEN die neueste CTS-Version bestehen, die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbar ist.

10.2. CTS-Verifier

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

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

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

11. Aktualisierbare Software

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

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

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

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

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

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

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

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

Android bietet Funktionen, mit denen die App „Geräteinhaber“ (falls vorhanden) die Installation von Systemupdates steuern kann. Um dies zu ermöglichen, MUSS das Systemupdate-Subsystem für Geräte, die android.software.device_admin melden, das in der Klasse „SystemUpdatePolicy“ beschriebene Verhalten implementieren [ Ressourcen, 138].

12. Änderungsprotokoll für Dokumente

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

Abschnitt Zusammenfassung der Änderungen
Diverse Die Angabe „empfohlen“ wurde durch „EMPFOHLEN“ ersetzt.
2. Gerätetypen Update für Android Automotive-Implementierungen
3.2.2. Parameter erstellen Ergänzungen für die Hardware-Seriennummer und die Sicherheitspatch-Ebene eines Builds
3.2.3.2. Intent-Auflösung Der Abschnitt wurde von „Intent-Überschreibungen“ in „Intent-Auflösung“ umbenannt. Es gelten neue Anforderungen im Zusammenhang mit der autorisierten Standard-App-Verknüpfung.
3.3.1. Application Binary Interfaces Ergänzungen zur Unterstützung von Android-ABIs; Änderung am Namen der Vulkan-Bibliothek
3.4.1. WebView-Kompatibilität Änderung für den von der WebView gemeldeten User-Agent-String
3.7. Laufzeitkompatibilität Aktualisierung der Tabelle für die Speicherzuweisung
3.8.4. Suchen Aktualisierte Anforderungen an Assistant
3.8.6. Designs Es wurde eine Anforderung hinzugefügt, schwarze Systemsymbole zu unterstützen, wenn dies durch das Flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR angefordert wird.
3.8.8. Aktivitätswechsel Erleichterte Anforderungen an die Anzahl der Titel in der Übersicht.
3.8.10. Mediensteuerung auf dem Sperrbildschirm Mediensteuerung auf dem Sperrbildschirm, siehe 3.8.3
3.9.1. Gerätebereitstellung Enthält neue Abschnitte für die Bereitstellung des Geräteeigentümers und die Bereitstellung des verwalteten Profils
3.9.2. Support für verwaltete Profile Neuer Abschnitt mit Anforderungen an die Geräteunterstützung für die Funktion „Verwaltetes Profil“
3.12.1. TV-App Abschnitt hinzugefügt, in dem die Anforderungen an TV-Apps für Android TV-Geräte erläutert werden
3.12.1.1. Elektronischer Programmführer Abschnitt zu EPG-Anforderungen für Android-TV-Geräte hinzugefügt
3.12.1.2. Navigation Es wurde ein Abschnitt hinzugefügt, in dem die Anforderungen an die Navigation in TV-Apps für Android TV-Geräte erläutert werden.
3.12.1.3. App-Verknüpfung für TV-Eingang Es wurde ein Abschnitt hinzugefügt, in dem die Anforderungen an die Unterstützung der Verknüpfung von TV-Eingabe-Apps für Android TV-Geräte erläutert werden.
5.1. Medien-Codecs Updates zur Unterstützung grundlegender Medienformate und Dekodierung
5.1.3. Video-Codecs Änderungen und Ergänzungen im Zusammenhang mit Android-Fernsehern
5.2. Videocodierung Änderungen für Encoder
5.3. Videodekodierung Änderungen an Decodern, u. a. bei der Unterstützung dynamischer Videoauflösung und Framerate-Umschaltung
5.4. Audioaufnahmen Ergänzungen zur Audioaufnahme
5.6. Audiolatenz Update zur Meldung der Unterstützung für Audio mit niedriger Latenz
5.10. Professionelles Audio Allgemeine Updates für die Unterstützung professioneller Audioformate, Updates für die Spezifikationen von Mobilgeräten (Anschlüssen), USB-Audio-Hostmodus und weitere Updates
5.9. Musical Instrument Digital Interface (MIDI) Neuer Abschnitt zur optionalen Unterstützung von MIDI (Musical Instrument Digital Interface) hinzugefügt
6.1. Entwicklertools Update für Treiber, die Windows 10 unterstützen
7.1.1.3. Bildschirmdichte Aktualisierungen für die Bildschirmdichte, z. B. für eine Android-Smartwatch
7.2.3. Navigationstasten Aktualisierte Anforderungen für Geräteimplementierungen, die die Aktion „Hilfe“ umfassen
7.3. Sensoren (und Unterabschnitte) Neue Anforderungen für einige Sensortypen
7.3.9. Hochpräzise Sensoren Neuer Abschnitt mit Anforderungen für Geräte, die High-Fidelity-Sensoren unterstützen
7.3.10. Fingerabdrucksensor Neuer Abschnitt zu Anforderungen an Fingerabdrucksensoren
7.4.2. IEEE 802.11 (Wi‑Fi) Aktualisierungen zur Unterstützung von Multicast-DNS (mDNS)
7.4.3. Bluetooth Ergänzung zu resolvable private address (RPA) für Bluetooth Low Energy (BLE)
7.4.4. Nahfeldkommunikation Ergänzungen zu den Anforderungen für die Nahfeldkommunikation (Near Field Communication, NFC)
7.4.5. Mindestnetzwerkanforderungen Anforderungen für die IPv6-Unterstützung hinzugefügt
7.6.3. Verwendbarer Speicher Neuer Abschnitt zur Implementierung von verwendbarem Speicher
7.7. USB Anforderung im Zusammenhang mit der Implementierung der AOA-Spezifikation
7.8.3. Nah-Ultraschall Ergänzungen im Zusammenhang mit der Aufzeichnung, Wiedergabe und Audio von Nah-Ultraschall Die SNR-Anforderung für das Nah-Ultraschallmikrofon wurde gelockert.
8.3. Energiesparmodi Neuer Abschnitt mit Anforderungen für den App-Standby- und den Doze-Modus
8.4. Stromverbrauchserfassung Neuer Abschnitt mit Anforderungen zum Erfassen des Stromverbrauchs von Hardwarekomponenten und zum Zuordnen dieses Stromverbrauchs zu bestimmten Anwendungen
9.1. Berechtigungen Ergänzung zu den Berechtigungsanforderungen
9.7. Kernel-Sicherheitsfunktionen SE Linux-Updates
9.8. Datenschutz Ergänzung zur Einwilligung des Nutzers für den Zugriff auf freigegebenen Speicher über einen USB-Port
9.9. Datenträgervollverschlüsselung Anforderungen an die Datenträgervollverschlüsselung
9.10. Verified Boot Zusätzliche Anforderung für den bestätigten Start
9.11. Schlüssel und Anmeldedaten Neuer Abschnitt mit Anforderungen an Schlüssel und Anmeldedaten
9.12. Löschen von Daten Neuer Abschnitt für „Zurücksetzen auf die Werkseinstellungen“
11. Aktualisierbare Software Anforderung im Zusammenhang mit der vom Geräteeigentümer festgelegten Richtlinie für Systemupdates

13. Kontakt

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

14. Ressourcen

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

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

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

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

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

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

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

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

9. Zulässige Versionsstrings für Android 6.0: http://source.android.com/docs/compatibility/6.0/versions.html

10. Android-Entwicklereinstellungen: http://developer.android.com/reference/android/provider/Settings.html

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

12. Android NDK ABI-Verwaltung: https://developer.android.com/ndk/guides/abis.html

13. Erweiterte SIMD-Architektur: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31. Android Assist APIs: https://developer.android.com/reference/android/app/assist/package-summary.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

46. App des Geräteeigentümers: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

47. Bereitstellungsablauf für Geräteinhaber unter Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE

48. Geräteeigentümer-Bereitstellung per NFC: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc

49. Android-App für Profilinhaber:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)

50. Bereitstellungsablauf für verwaltete Android-Profile: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE

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

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

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

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

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

56. TV-App-Kanäle: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html

57. TV-Eingänge von Drittanbietern: /devices/tv/index.html#third-party_input_example

58. Fernseher-Eingänge: /devices/tv/index.html#tv_inputs

59. EPG-Felder für TV-Kanäle: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html

60. Verknüpfung von TV-Eingabe-Apps: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI

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

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

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

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

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

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

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

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

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

70. Android-Klasse „android.content.pm.PackageManager“ und Liste der Hardwarefunktionen: http://developer.android.com/reference/android/content/pm/PackageManager.html

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

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

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

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

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

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

77. Einstellungen für die Android-App-Entwicklung: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

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

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

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

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

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

83. EGL-Erweiterung EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

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

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

86. Konfiguration der Touchbedienung: http://source.android.com/docs/core/interaction/input/touch-devices

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

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

89. Android Open Source-Sensoren: http://source.android.com/docs/core/interaction/sensors

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

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

92. Android Open Source-Kompositsensoren: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary

93. Modus für kontinuierlichen Trigger: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

95. Android Fingerprint API: https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html

96. Android-Fingerabdruck-HAL: /devices/tech/security/authentication/fingerprint-hal.html

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

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

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

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

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

102. NFC-Barcode: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html

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

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

105. NFC-Freigabeeinstellungen unter Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

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

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

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

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

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

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

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

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

114. Unterstützung der Kameraversion: http://source.android.com/docs/core/camera/versioning

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

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

117. Adoptable Storage: http://source.android.com/docs/core/storage/adoptable

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

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

120. USB Battery Charging Specification, Revision 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

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

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

123. Komponenten des Energieprofils: http://source.android.com/docs/core/power/values

124. Batterystats: https://developer.android.com/tools/dumpsys#battery

125. Zusammenfassung des Stromverbrauchs: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY

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

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

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

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

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

131. Melden der Sicherheit des Sperrbildschirms: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()

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

133. Android-Schlüsselspeichersystem: https://developer.android.com/training/articles/keystore.html

134. KeyChain API: https://developer.android.com/reference/android/security/KeyChain.html

135. Keystore API: https://developer.android.com/reference/java/security/KeyStore.html

136. Gatekeeper HAL: http://source.android.com/docs/security/features/authentication/gatekeeper

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

138. Klasse „SystemUpdatePolicy“: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html

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

140. App-Links verwenden: https://developer.android.com/training/app-links/index.html

141. Digital Asset Links von Google: https://developers.google.com/digital-asset-links

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