Die Verwendung von „muss“, „darf nicht“, „erforderlich“, „shall“, „shall not“, „should“, „should not“, „recommended“, „may“ und „optional“ entspricht dem IETF-Standard definiert in RFC2119 [ Ressourcen, 1 ].

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

Um als mit Android 4.4 kompatibel zu gelten, MÜSSEN Geräteimplementierungen die in dieser Kompatibilitätsdefinition dargelegten Anforderungen erfüllen, einschließlich aller durch Verweis einbezogenen Dokumente.

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

Aus diesem Grund ist das Android Open Source Project [ Ressourcen, 3 ] sowohl die Referenz als auch die bevorzugte Implementierung von Android. Geräteimplementierern wird dringend empfohlen, ihre Implementierungen so weit wie möglich auf dem „Upstream“-Quellcode zu basieren, der vom Android Open Source Project verfügbar ist. Obwohl einige Komponenten hypothetisch durch alternative Implementierungen ersetzt werden können, wird von dieser Praxis dringend abgeraten, da das Bestehen der Softwaretests wesentlich schwieriger wird. Es liegt in der Verantwortung des Implementierers, die vollständige Verhaltenskompatibilität mit der Standard-Android-Implementierung sicherzustellen, einschließlich der Compatibility Test Suite und darüber hinaus. Beachten Sie abschließend, dass bestimmte Komponentenersetzungen und -modifikationen in diesem Dokument ausdrücklich verboten sind.

2. Ressourcen

IETF RFC2119-Anforderungsstufen: http://www.ietf.org/rfc/rfc2119.txt

Übersicht über das Android-Kompatibilitätsprogramm: http://source.android.com/docs/compatibility/index.html

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

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

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

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

Für Android 4.4 zulässige Versionszeichenfolgen: http://source.android.com/docs/compatibility/4.4/versions.html

Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html

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

android.webkit.WebView-Klasse: http://developer.android.com/reference/android/webkit/WebView.html

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

HTML5-Offline-Funktionen: http://dev.w3.org/html5/spec/Overview.html#offline

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

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

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

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

Spezifikation der Dalvik Virtual Machine: verfügbar im Android-Quellcode unter dalvik/docs

AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

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

Anwendungsressourcen: http://code.google.com/android/reference/available-resources.html

Stilleitfaden für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

Suchmanager: http://developer.android.com/reference/android/app/SearchManager.html

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

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

R.style-Klasse: http://developer.android.com/reference/android/R.style.html

Live-Hintergründe: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

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

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

APIs des Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/package-summary.html

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

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

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

Dokumentation zum Referenztool (für ADB, AAPT, DDMS, Systrace): http://developer.android.com/guide/developing/tools/index.html

Beschreibung der Android-Apk-Datei: http://developer.android.com/guide/topics/fundamentals.html

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

Monkey-Testtool: https://developer.android.com/studio/test/other-testing-tools/monkey

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

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

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

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

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

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

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

MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

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

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

Offenes Android-Zubehör: http://developer.android.com/guide/topics/usb/accessory.html

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

Referenz zu Android-Sicherheit und -Berechtigungen: http://developer.android.com/guide/topics/security/permissions.html

Apps für Android: http://code.google.com/p/apps-for-android

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

Android-Dateiübertragung: http://www.android.com/filetransfer

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

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

NFC-Verbindungsübergabe: http://www.nfc-forum.org/specs/spec_list/#conn_handover

Bluetooth Secure Simple Pairing mit NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

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

Aktionsassistent: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

USB-Ladespezifikation: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

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

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

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

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

Sperr- und Startbildschirm-Widget: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

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

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

Externe Speicher-APIs: http://developer.android.com/reference/android/os/Environment.html

SMS-Kurzcode: http://en.wikipedia.org/wiki/Short_code

Media Remote Control-Client: http://developer.android.com/reference/android/media/RemoteControlClient.html

Display-Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

Träume: http://developer.android.com/reference/android/service/dreams/DreamService.html

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

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

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

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

Touch-Eingabekonfiguration: http://source.android.com/docs/core/interaction/input/touch-devices.html

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

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

Android-Gerätebesitzer-App: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

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

RTC-Hardware-Codierungsanforderungen: http://www.webmproject.org/hardware/rtc-coding-requirements/

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

Inhaltslöser: http://developer.android.com/reference/android/content/ContentResolver.html

SettingInjectorService: http://developer.android.com/reference/android/location/SettingInjectorService.html

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

Telefonanbieter: http://developer.android.com/reference/android/provider/Telephony.html

Viele dieser Ressourcen stammen direkt oder indirekt vom Android SDK und sind funktional identisch mit den Informationen in der Dokumentation dieses SDK. In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstestsuite nicht mit der SDK-Dokumentation übereinstimmen, gilt die SDK-Dokumentation als maßgeblich. Alle in den oben aufgeführten Referenzen bereitgestellten technischen Details werden durch die Aufnahme als Teil dieser Kompatibilitätsdefinition betrachtet.

3. Software

3.1. Verwaltete API-Kompatibilität

Die verwaltete (Dalvik-basierte) Ausführungsumgebung ist das primäre Vehikel für Android-Anwendungen. Bei der Android-Anwendungsprogrammierschnittstelle (API) handelt es sich um den Satz von Android-Plattformschnittstellen, die Anwendungen zur Verfügung gestellt werden, die in der verwalteten VM-Umgebung ausgeführt werden. Geräteimplementierungen MÜSSEN vollständige Implementierungen, einschließlich aller dokumentierten Verhaltensweisen, aller dokumentierten APIs bereitstellen, die vom Android SDK bereitgestellt werden [ Ressourcen, 4 ].

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 in dieser Kompatibilitätsdefinition ausdrücklich zulässig.

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

3.2. Soft-API-Kompatibilität

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

3.2.1. Berechtigungen

Geräteimplementierer MÜSSEN alle Berechtigungskonstanten unterstützen und durchsetzen, wie auf der Berechtigungsreferenzseite [ Ressourcen, 5 ] dokumentiert. Beachten Sie, dass in Abschnitt 9 zusätzliche Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell aufgeführt sind.

3.2.2. Build-Parameter

Die Android-APIs enthalten eine Reihe von Konstanten in der Klasse android.os.Build [ Ressourcen, 6 ], die das aktuelle Gerät beschreiben sollen. Um konsistente, aussagekräftige Werte über alle Geräteimplementierungen hinweg bereitzustellen, enthält die folgende Tabelle zusätzliche Einschränkungen für die Formate dieser Werte, denen Geräteimplementierungen entsprechen MÜSSEN.

Parameter	Kommentare
VERSION.VERSION	Die Version des aktuell ausgeführten Android-Systems im für Menschen lesbaren Format. Dieses Feld MUSS einen der in [ Ressourcen, 7 ] definierten Zeichenfolgenwerte haben.
VERSION.SDK	Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Anwendungscode von Drittanbietern zugreifen kann. Für Android 4.4 MUSS dieses Feld den ganzzahligen Wert 19 haben.
VERSION.SDK_INT	Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Anwendungscode von Drittanbietern zugreifen kann. Für Android 4.4 MUSS dieses Feld den ganzzahligen Wert 19 haben.
VERSION.INKREMENTAL	Ein vom Geräteimplementierer ausgewählter Wert, der den spezifischen Build des aktuell ausgeführten Android-Systems in einem für Menschen lesbaren Format angibt. Dieser Wert DARF NICHT für verschiedene Builds wiederverwendet werden, die Endbenutzern zur Verfügung gestellt werden. Eine typische Verwendung dieses Felds besteht darin, anzugeben, welche Build-Nummer oder welche Quellcodeverwaltungs-Änderungskennung zum Generieren des Builds verwendet wurde. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.
PLANKE	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Hardware identifiziert, die vom Gerät verwendet wird, in einem für Menschen lesbaren Format. Eine mögliche Verwendung dieses Feldes besteht darin, die spezifische Revision der Platine anzugeben, die das Gerät mit Strom versorgt. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^[a-zA-Z0-9.,_-]+$"` übereinstimmen.
MARKE	Ein Wert, der den mit dem Gerät verbundenen Markennamen widerspiegelt, wie er den Endbenutzern bekannt ist. MUSS in einem für Menschen lesbaren Format vorliegen und den Hersteller des Geräts oder die Unternehmensmarke, unter der das Gerät vermarktet wird, angeben. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^[a-zA-Z0-9.,_-]+$"` übereinstimmen.
CPU_ABI	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3: Native API-Kompatibilität .
CPU_ABI2	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3: Native API-Kompatibilität .
GERÄT	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 Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^[a-zA-Z0-9.,_-]+$"` übereinstimmen.
FINGERABDRUCK	Eine Zeichenfolge, die diesen Build eindeutig identifiziert. Es SOLLTE für Menschen einigermaßen lesbar sein. Es MUSS dieser Vorlage folgen: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Zum Beispiel: `acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys` Der Fingerabdruck DARF KEINE Leerzeichen enthalten. Wenn andere in der obigen Vorlage enthaltene Felder Leerzeichen enthalten, MÜSSEN diese im Build-Fingerabdruck durch ein anderes Zeichen ersetzt werden, beispielsweise durch den Unterstrich („_“). Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein.
HARDWARE	Der Name der Hardware (von der Kernel-Befehlszeile oder /proc). Es SOLLTE für Menschen einigermaßen lesbar sein. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^[a-zA-Z0-9.,_-]+$"` übereinstimmen.
GASTGEBER	Eine Zeichenfolge, die den Host, auf dem der Build erstellt wurde, in einem für Menschen lesbaren Format eindeutig identifiziert. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.
AUSWEIS	Eine vom Geräteimplementierer ausgewählte Kennung, um auf eine bestimmte Version in einem für Menschen lesbaren Format zu verweisen. Dieses Feld kann mit android.os.Build.VERSION.INCREMENTAL identisch sein, SOLLTE jedoch ein ausreichend aussagekräftiger Wert sein, damit Endbenutzer zwischen Software-Builds unterscheiden können. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^[a-zA-Z0-9.,_-]+$"` übereinstimmen.
HERSTELLER	Der Handelsname des Originalgeräteherstellers (OEM) des Produkts. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.
MODELL	Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endbenutzer bekannt ist. Dies SOLLTE derselbe Name sein, unter dem das Gerät vermarktet und an Endbenutzer verkauft wird. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.
PRODUKT	Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des spezifischen Produkts (SKU) enthält, das innerhalb derselben Marke eindeutig sein sollte. MUSS für Menschen lesbar sein, ist aber nicht unbedingt für die Anzeige durch Endbenutzer gedacht. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^[a-zA-Z0-9.,_-]+$"` übereinstimmen.
SERIE	Eine Hardware-Seriennummer, die verfügbar sein MUSS. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^([a-zA-Z0-9]{6,20})$"` übereinstimmen.
STICHWORTE	Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt wurden und den Build weiter unterscheiden. Beispiel: „unsigned,debug“. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^[a-zA-Z0-9.,_-]+$"` übereinstimmen.
ZEIT	Ein Wert, der den Zeitstempel des Buildvorgangs darstellt.
TYP	Ein vom Geräteimplementierer ausgewählter Wert, der die Laufzeitkonfiguration des Builds angibt. Dieses Feld SOLLTE einen der Werte haben, die den drei typischen Android-Laufzeitkonfigurationen entsprechen: „user“, „userdebug“ oder „eng“. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^[a-zA-Z0-9.,_-]+$"` übereinstimmen.
BENUTZER	Ein Name oder eine Benutzer-ID des Benutzers (oder automatisierten Benutzers), der den Build generiert hat. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.

3.2.3. Absichtskompatibilität

Geräteimplementierungen MÜSSEN das lose Kopplungs-Intent-System von Android berücksichtigen, wie in den folgenden Abschnitten beschrieben. Mit „gewürdigt“ ist gemeint, dass der Geräteimplementierer eine Android-Aktivität oder einen Android-Dienst bereitstellen MUSS, der einen passenden Intent-Filter angibt und an jedes angegebene Intent-Muster bindet und das korrekte Verhalten implementiert.

3.2.3.1. Kernanwendungsabsichten

Das Android-Upstream-Projekt definiert eine Reihe von Kernanwendungen wie Kontakte, Kalender, Fotogalerie, Musikplayer usw. Geräteimplementierer KÖNNEN diese Anwendungen durch alternative Versionen ersetzen.

Allerdings MÜSSEN solche alternativen Versionen dieselben Absichtsmuster berücksichtigen, die vom Upstream-Projekt bereitgestellt werden. Wenn ein Gerät beispielsweise einen alternativen Musikplayer enthält, muss es dennoch das von Drittanbieteranwendungen ausgegebene Intent-Muster zur Auswahl eines Songs berücksichtigen.

Die folgenden Anwendungen gelten als Kernanwendungen des Android-Systems:

Tischuhr
Browser
Kalender
Kontakte
Galerie
GlobalSearch
Startprogramm
Musik
Einstellungen

Die Kernanwendungen des Android-Systems umfassen verschiedene Aktivitäts- oder Dienstkomponenten, die als „öffentlich“ gelten. Das heißt, das Attribut „android:exported“ kann fehlen oder den Wert „true“ haben.

Für jede Aktivität oder jeden Dienst, der in einer der zentralen Android-System-Apps definiert ist und nicht über ein android:exported-Attribut mit dem Wert „false“ als nicht öffentlich markiert ist, MÜSSEN Geräteimplementierungen eine Komponente desselben Typs enthalten, die denselben Intent-Filter implementiert Muster als Kern-Android-System-App.

Mit anderen Worten: Eine Geräteimplementierung KANN Kern-Apps des Android-Systems ersetzen; Wenn dies jedoch der Fall ist, MUSS die Geräteimplementierung alle Intent-Muster unterstützen, die von jeder zu ersetzenden Kern-App des Android-Systems definiert werden.

3.2.3.2. Absichtsüberschreibungen

Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen zulassen, dass jedes in Abschnitt 3.2.3.1 genannte Absichtsmuster durch Anwendungen von Drittanbietern überschrieben wird. Die Upstream-Android-Open-Source-Implementierung ermöglicht dies standardmäßig; Geräteimplementierer DÜRFEN KEINE besonderen Privilegien für die Verwendung dieser Intent-Muster durch Systemanwendungen festlegen oder verhindern, dass Anwendungen Dritter sich an diese Muster binden und die Kontrolle über sie übernehmen. Dieses Verbot umfasst insbesondere die Deaktivierung der „Chooser“-Benutzeroberfläche, die es dem Benutzer ermöglicht, zwischen mehreren Anwendungen auszuwählen, die alle dasselbe Intent-Muster verarbeiten.

Allerdings stellen Geräteimplementierungen möglicherweise Standardaktivitäten für bestimmte URI-Muster bereit (z. B. http://play.google.com), wenn die Standardaktivität einen spezifischeren Filter für den Daten-URI bereitstellt. Beispielsweise ist ein Absichtsfilter, der den Daten-URI „http://www.android.com“ angibt, spezifischer als der Browserfilter für „http://“. Geräteimplementierungen MÜSSEN eine Benutzeroberfläche bereitstellen, über die Benutzer die Standardaktivität für Absichten ändern können.

3.2.3.3. Absichts-Namespaces

Geräteimplementierungen DÜRFEN KEINE Android-Komponenten enthalten, die neue Intent- oder Broadcast-Intent-Muster mithilfe einer ACTION, CATEGORY oder einer anderen Schlüsselzeichenfolge im Namespace android.* oder com.android.* berücksichtigen. Geräteimplementierer DÜRFEN KEINE Android-Komponenten einschließen, die neue Intent- oder Broadcast-Intent-Muster mithilfe einer ACTION, CATEGORY oder einer anderen Schlüsselzeichenfolge in einem Paketbereich einer anderen Organisation berücksichtigen. Geräteimplementierer DÜRFEN KEINE Absichtsmuster ändern oder erweitern, die von den in Abschnitt 3.2.3.1 aufgeführten Kern-Apps verwendet werden. Geräteimplementierungen KÖNNEN Absichtsmuster enthalten, die Namespaces verwenden, die eindeutig und offensichtlich mit ihrer eigenen Organisation verknüpft sind.

Dieses Verbot ist analog zu dem für Java-Sprachklassen in Abschnitt 3.6 festgelegten.

3.2.3.4. Sendeabsichten

Anwendungen von Drittanbietern verlassen sich darauf, dass die Plattform bestimmte Absichten sendet, um sie über Änderungen in der Hardware- oder Softwareumgebung zu informieren. Android-kompatible Geräte MÜSSEN die öffentlichen Sendeabsichten als Reaktion auf entsprechende Systemereignisse übertragen. Broadcast Intents werden in der SDK-Dokumentation beschrieben.

3.2.3.5. Standard-App-Einstellungen

Android 4.4 fügt Einstellungen hinzu, die es Benutzern ermöglichen, ihre Standard-Home- und SMS-Anwendungen auszuwählen. Geräteimplementierungen MÜSSEN jeweils ein ähnliches Benutzereinstellungsmenü bereitstellen, das mit dem Intent-Filtermuster und den API-Methoden kompatibel ist, die in der SDK-Dokumentation [ Ressourcen, 91 ] beschrieben sind.

3.3. Native API-Kompatibilität

3.3.1 Binäre Anwendungsschnittstellen

In Dalvik ausgeführter verwalteter Code kann nativen Code aufrufen, der in der APK-Datei der Anwendung als ELF-SO-Datei bereitgestellt wird, die für die entsprechende Hardwarearchitektur des Geräts kompiliert wurde. Da nativer Code stark von der zugrunde liegenden Prozessortechnologie abhängt, definiert Android im Android NDK in der Datei docs/CPU-ARCH-ABIS.html eine Reihe von Application Binary Interfaces (ABIs). Wenn eine Geräteimplementierung mit einem oder mehreren definierten ABIs kompatibel ist, SOLLTE sie die Kompatibilität mit dem Android NDK implementieren, wie unten beschrieben.

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

MUSS Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code unter Verwendung der standardmäßigen JNI-Semantik (Java Native Interface) aufzurufen
MUSS mit jeder erforderlichen Bibliothek in der Liste unten quellkompatibel (dh Header-kompatibel) und binärkompatibel (für das ABI) sein
MUSS die vom Gerät unterstützte native Application Binary Interface (ABI) über die Parameter android.os.Build.CPU_ABI API und android.os.Build.CPU_ABI2 genau melden.
MÜSSEN über android.os.Build.CPU_ABI2 nur die ABIs melden, die in der neuesten Version des Android NDK in der Datei docs/CPU-ARCH-ABIS.html dokumentiert sind
MUSS über android.os.Build.CPU_ABI nur eines der unten aufgeführten ABIs melden

armeabi-v7a
x86
mips

SOLLTE unter Verwendung des Quellcodes und der Header-Dateien erstellt werden, die im Upstream-Android-Open-Source-Projekt verfügbar sind

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

libc (C-Bibliothek)
libm (Mathebibliothek)
Minimale Unterstützung für C++
JNI-Schnittstelle
liblog (Android-Protokollierung)
libz (Zlib-Komprimierung)
libdl (dynamischer Linker)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libGLESv3.so (OpenGL ES 3.0)
libEGL.so (native OpenGL-Oberflächenverwaltung)
libjnigraphics.so
libOpenSLES.so (OpenSL ES 1.0.1 Audiounterstützung)
libOpenMAXAL.so (OpenMAX AL 1.0.1-Unterstützung)
libandroid.so (native Android-Aktivitätsunterstützung)
Unterstützung für OpenGL, wie unten beschrieben

Beachten Sie, dass zukünftige Versionen des Android NDK möglicherweise Unterstützung für zusätzliche ABIs einführen. Wenn eine Geräteimplementierung nicht mit einem vorhandenen vordefinierten ABI kompatibel ist, DARF sie überhaupt keine Unterstützung für ein ABI melden.

Beachten Sie, dass Geräteimplementierungen libGLESv3.so enthalten MÜSSEN und einen symbolischen Link zu libGLESv2.so haben. Bei Geräteimplementierungen, die Unterstützung für OpenGL ES 3.0 deklarieren, MUSS libGLESv2.so zusätzlich zu den OpenGL ES 2.0-Funktionssymbolen auch die OpenGL ES 3.0-Funktionssymbole exportieren.

Die Kompatibilität mit nativem Code ist eine Herausforderung. Aus diesem Grund sollte wiederholt werden, dass Geräteimplementierern SEHR dringend empfohlen wird, die Upstream-Implementierungen der oben aufgeführten Bibliotheken zu verwenden, um die Kompatibilität sicherzustellen.

3.4. Webkompatibilität

3.4.1. WebView-Kompatibilität

Die Android Open Source-Implementierung verwendet Code aus dem Chromium-Projekt, um android.webkit.WebView [ Ressourcen, 10 ] zu implementieren. Da es nicht möglich ist, eine umfassende Testsuite für ein Web-Rendering-System zu entwickeln, MÜSSEN Geräteimplementierer den spezifischen Upstream-Build von Chromium in der WebView-Implementierung verwenden. Speziell:

Geräteimplementierungen android.webkit.WebView MÜSSEN auf dem Chromium-Build aus dem Upstream-Android-Open-Source-Projekt für Android 4.4 basieren. Dieser Build enthält einen bestimmten Satz an Funktionen und Sicherheitskorrekturen für WebView. [ Ressourcen, 83 ]
Die von WebView gemeldete Benutzeragentenzeichenfolge MUSS in diesem Format vorliegen:
Mozilla/5.0 (Linux; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Der Wert der Zeichenfolge $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE identisch sein.
- Der Wert der Zeichenfolge $(LOCALE) ist optional, SOLLTE den ISO-Konventionen für Ländercode und Sprache folgen und sich auf das aktuell konfigurierte Gebietsschema des Geräts beziehen. Wenn es weggelassen wird, MUSS auch das abschließende Semikolon entfernt werden.
- Der Wert der Zeichenfolge $(MODEL) MUSS mit dem Wert für android.os.Build.MODEL identisch sein.
- Der Wert der Zeichenfolge $(BUILD) MUSS mit dem Wert für android.os.Build.ID identisch sein.
- Der Wert der Zeichenfolge $(CHROMIUM_VER) MUSS die Version von Chromium im Upstream-Android-Open-Source-Projekt sein.
- Bei Geräteimplementierungen kann Mobile in der Benutzeragentenzeichenfolge weggelassen werden.

Die WebView-Komponente SOLLTE so viel HTML5 [ Ressourcen, 11 ] wie möglich unterstützen.

3.4.2. Browser-Kompatibilität

Geräteimplementierungen MÜSSEN eine eigenständige Browseranwendung für das allgemeine Surfen im Internet durch Benutzer enthalten. Der eigenständige Browser basiert möglicherweise auf einer anderen Browsertechnologie als WebKit. Selbst wenn jedoch eine alternative Browseranwendung verwendet wird, MUSS die Komponente android.webkit.WebView , die Drittanbieteranwendungen bereitgestellt wird, auf WebKit basieren, wie in Abschnitt 3.4.1 beschrieben.

Implementierungen KÖNNEN eine benutzerdefinierte Benutzeragentenzeichenfolge in der eigenständigen Browseranwendung liefern.

Die eigenständige Browseranwendung (unabhängig davon, ob sie auf der Upstream-WebKit-Browseranwendung oder einem Ersatz eines Drittanbieters basiert) SOLLTE möglichst viel HTML5 [ Ressourcen, 11 ] unterstützen. Geräteimplementierungen MÜSSEN mindestens jede dieser mit HTML5 verbundenen APIs unterstützen:

Anwendungscache/Offline-Betrieb [ Ressourcen, 12 ]
das <video>-Tag [ Ressourcen, 13 ]
Geolokalisierung [ Ressourcen, 14 ]

Darüber hinaus MÜSSEN Geräteimplementierungen die HTML5/W3C-Webstorage-API [ Ressourcen, 15 ] unterstützen und SOLLTEN die HTML5/W3C-IndexedDB-API [ Ressourcen, 16 ] unterstützen. Beachten Sie, dass IndexedDB voraussichtlich eine erforderliche Komponente in einer zukünftigen Version von Android wird, da die Standardisierungsgremien für die Webentwicklung IndexedDB gegenüber Webstorage bevorzugen.

3.5. API-Verhaltenskompatibilität

Das Verhalten der einzelnen API-Typen (verwaltet, Soft, nativ und Web) muss mit der bevorzugten Implementierung des Upstream-Android-Open-Source-Projekts [ Ressourcen, 3 ] übereinstimmen. Einige spezifische Kompatibilitätsbereiche sind:

Geräte DÜRFEN das Verhalten oder die Semantik eines Standard-Intents NICHT ändern
Geräte DÜRFEN NICHT den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, ContentProvider usw.) verändern.
Geräte DÜRFEN die Semantik einer Standardberechtigung NICHT ändern

Die obige Liste ist nicht vollständig. Die Compatibility Test Suite (CTS) testet wesentliche Teile der Plattform auf Verhaltenskompatibilität, jedoch nicht alle. Es liegt in der Verantwortung des Implementierers, 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 wesentliche Teile des Systems neu zu implementieren.

3.6. API-Namespaces

Android folgt den von der Programmiersprache Java definierten Paket- und Klassen-Namespace-Konventionen. Um die Kompatibilität mit Anwendungen von Drittanbietern sicherzustellen, DÜRFEN Geräteimplementierer KEINE verbotenen Änderungen (siehe unten) an diesen Paket-Namespaces vornehmen:

Java.*
javax.*
Sonne.*
Android.*
com.android.*

Zu den verbotenen Ä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 KÖNNEN die zugrunde liegende Implementierung der APIs ändern, aber solche Änderungen DÜRFEN KEINE Auswirkungen auf das angegebene Verhalten und die Java-Sprachsignatur von öffentlich zugänglichen APIs haben.
Geräteimplementierer DÜRFEN KEINE öffentlich zugänglichen Elemente (wie Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) zu den oben genannten APIs hinzufügen.

Ein „öffentlich zugängliches Element“ ist jedes Konstrukt, das nicht mit der „@hide“-Markierung versehen ist, wie sie im ursprünglichen Android-Quellcode verwendet wird. Mit anderen Worten: Geräteimplementierer DÜRFEN KEINE neuen APIs offenlegen oder bestehende APIs in den oben genannten Namespaces ändern. Geräteimplementierer KÖNNEN nur interne Änderungen vornehmen, diese Änderungen DÜRFEN jedoch NICHT angekündigt oder anderweitig den Entwicklern zugänglich gemacht werden.

Geräteimplementierer KÖNNEN benutzerdefinierte APIs hinzufügen, solche APIs DÜRFEN sich jedoch NICHT in einem Namensraum befinden, der einer anderen Organisation gehört oder auf diese verweist. Beispielsweise DÜRFEN Geräteimplementierer KEINE APIs zum com.google.* oder einem ähnlichen Namespace hinzufügen. Nur Google darf dies tun. Ebenso DARF Google KEINE APIs zu den Namespaces anderer Unternehmen hinzufügen. Wenn eine Geräteimplementierung außerdem benutzerdefinierte APIs außerhalb des standardmäßigen Android-Namespace enthält, MÜSSEN diese APIs in einer gemeinsam genutzten Android-Bibliothek gepackt werden, sodass nur Apps, die sie explizit verwenden (über den <uses-library> -Mechanismus), von der erhöhten Speichernutzung betroffen sind solcher APIs.

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

Beachten Sie, dass die oben genannten Einschränkungen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java entsprechen; Dieser Abschnitt zielt lediglich darauf ab, diese Konventionen zu stärken und sie durch die Aufnahme in diese Kompatibilitätsdefinition verbindlich zu machen.

3.7. Kompatibilität virtueller Maschinen

Geräteimplementierungen MÜSSEN die vollständige Dalvik Executable (DEX)-Bytecode-Spezifikation und die Dalvik Virtual Machine-Semantik unterstützen [ Ressourcen, 17 ].

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

Beachten Sie, dass die unten angegebenen Speicherwerte als Mindestwerte gelten und Geräteimplementierungen möglicherweise mehr Speicher pro Anwendung zuweisen.

Bildschirmgröße	Bildschirmdichte	Anwendungsspeicher
klein / normal / groß	ldpi / mdpi	16 MB
klein / normal / groß	tvdpi / hdpi	32 MB
klein / normal / groß	xhdpi	64 MB
klein / normal / groß	400dpi	96 MB
klein / normal / groß	xxhdpi	128 MB
klein / normal / groß	xxxhdpi	256 MB
xlarge	mdpi	32 MB
xlarge	tvdpi / hdpi	64 MB
xlarge	xhdpi	128 MB
xlarge	400dpi	192 MB
xlarge	xxhdpi	256 MB
xlarge	xxxhdpi	512 MB

3.8. Kompatibilität der Benutzeroberfläche

3.8.1. Launcher (Startbildschirm)

Android umfasst eine Launcher-Anwendung (Startbildschirm) und Unterstützung für Anwendungen von Drittanbietern, die den Geräte-Launcher (Startbildschirm) ersetzen. Geräteimplementierungen, die es Anwendungen von Drittanbietern ermöglichen, den Startbildschirm des Geräts zu ersetzen, MÜSSEN die Plattformfunktion android.software.home_screen deklarieren.

3.8.2. Widgets

Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, die es Anwendungen ermöglichen, dem Endbenutzer ein „AppWidget“ zur Verfügung zu stellen [ Ressourcen, 18 ]. Geräteimplementierungen, die das Einbetten von Widgets auf dem Startbildschirm unterstützen, MÜSSEN die folgenden Anforderungen erfüllen und Unterstützung für die Plattformfunktion android.software.app_widgets deklarieren.

Gerätestarter MÜSSEN über integrierte Unterstützung für AppWidgets verfügen und Benutzeroberflächenfunktionen zum Hinzufügen, Konfigurieren, Anzeigen und Entfernen von AppWidgets direkt im Launcher bereitstellen.
Geräteimplementierungen MÜSSEN in der Lage sein, Widgets mit einer Größe von 4 x 4 in der Standardrastergröße darzustellen. (Weitere Informationen finden Sie in den App Widget Design Guidelines in der Android SDK-Dokumentation [ Ressourcen, 18 ].
Geräteimplementierungen, die den Sperrbildschirm unterstützen, MÜSSEN Anwendungs-Widgets auf dem Sperrbildschirm unterstützen.

3.8.3. Benachrichtigungen

Android enthält APIs, die es Entwicklern ermöglichen, Benutzer über wichtige Ereignisse zu benachrichtigen [ Ressourcen, 19 ], indem sie Hardware- und Softwarefunktionen des Geräts nutzen.

Einige APIs ermöglichen es Anwendungen, Benachrichtigungen durchzuführen oder mithilfe von Hardware, insbesondere Ton, Vibration und Licht, Aufmerksamkeit zu erregen. Geräteimplementierungen MÜSSEN Benachrichtigungen unterstützen, die Hardwarefunktionen nutzen, wie in der SDK-Dokumentation beschrieben, und soweit dies mit der Geräteimplementierungshardware möglich ist. Wenn eine Geräteimplementierung beispielsweise einen Vibrator umfasst, MUSS sie die Vibrations-APIs korrekt implementieren. Wenn einer Geräteimplementierung Hardware fehlt, MÜSSEN die entsprechenden APIs als No-Ops implementiert werden. Beachten Sie, dass dieses Verhalten in Abschnitt 7 ausführlicher beschrieben wird.

Darüber hinaus MUSS die Implementierung alle in den APIs [ Ressourcen, 20 ] oder im Stilleitfaden für Status-/Systemleistensymbole [ Ressourcen, 21 ] bereitgestellten Ressourcen (Symbole, Sounddateien usw.) korrekt rendern. Geräteimplementierer KÖNNEN eine alternative Benutzererfahrung für Benachrichtigungen bieten als die Referenz-Android-Open-Source-Implementierung; Allerdings MÜSSEN solche alternativen Benachrichtigungssysteme vorhandene Benachrichtigungsressourcen unterstützen, wie oben beschrieben.

Android bietet Unterstützung für umfangreiche Benachrichtigungen, z. B. interaktive Ansichten für laufende Benachrichtigungen. Geräteimplementierungen MÜSSEN umfangreiche Benachrichtigungen ordnungsgemäß anzeigen und ausführen, wie in den Android-APIs dokumentiert.

3.8.4. Suchen

Android enthält APIs [ Ressourcen, 22 ], die es Entwicklern ermöglichen, die Suche in ihre Anwendungen zu integrieren und die Daten ihrer Anwendung in der globalen Systemsuche verfügbar zu machen. Im Allgemeinen besteht diese Funktionalität aus einer einzigen, systemweiten Benutzeroberfläche, die es Benutzern ermöglicht, Abfragen einzugeben, während der Benutzereingabe Vorschläge anzeigt und Ergebnisse anzeigt. Die Android-APIs ermöglichen es Entwicklern, diese Schnittstelle wiederzuverwenden, um eine Suche in ihren eigenen Apps bereitzustellen, und ermöglichen es Entwicklern, Ergebnisse an die gemeinsame Benutzeroberfläche für die globale Suche bereitzustellen.

Geräteimplementierungen MÜSSEN eine einzige, gemeinsame, systemweite Suchbenutzeroberfläche umfassen, die als Reaktion auf Benutzereingaben Echtzeitvorschläge machen kann. Geräteimplementierungen MÜSSEN die APIs implementieren, die es Entwicklern ermöglichen, diese Benutzeroberfläche wiederzuverwenden, um die Suche in ihren eigenen Anwendungen bereitzustellen. Geräteimplementierungen MÜSSEN die APIs implementieren, die es Drittanbieteranwendungen ermöglichen, Vorschläge zum Suchfeld hinzuzufügen, wenn es im globalen Suchmodus ausgeführt wird. Wenn keine Anwendungen von Drittanbietern installiert sind, die diese Funktionalität nutzen, SOLLTE das Standardverhalten darin bestehen, Ergebnisse und Vorschläge von Websuchmaschinen anzuzeigen.

3.8.5. Toasts

Anwendungen können die „Toast“-API (definiert in [ Ressourcen, 23 ]) verwenden, um dem Endbenutzer kurze nichtmodale Zeichenfolgen anzuzeigen, die nach kurzer Zeit verschwinden. Geräteimplementierungen MÜSSEN Toasts von Anwendungen an Endbenutzer gut sichtbar anzeigen.

3.8.6. Themen

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

Android enthält eine „Holo“-Themenfamilie als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie dem Erscheinungsbild des Holo-Themas entsprechen möchten, wie es im Android SDK definiert ist [ Ressourcen, 24 ]. Geräteimplementierungen DÜRFEN KEINE der Holo-Designattribute ändern, die Anwendungen zur Verfügung gestellt werden [ Ressourcen, 25 ].

Android enthält außerdem eine „Device Default“-Designfamilie als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Erscheinungsbild des vom Geräteimplementierer definierten Gerätedesigns anpassen möchten. Geräteimplementierungen KÖNNEN die DeviceDefault-Designattribute ändern, die Anwendungen zur Verfügung gestellt werden [ Ressourcen, 25 ].

Ab Version 4.4 unterstützt Android nun eine neue Theme-Variante mit durchsichtigen Systemleisten, die es Anwendungsentwicklern ermöglicht, den Bereich hinter der Status- und Navigationsleiste mit ihren App-Inhalten zu füllen. Um eine konsistente Entwicklererfahrung in dieser Konfiguration zu ermöglichen, ist es wichtig, dass der Symbolstil der Statusleiste über verschiedene Geräteimplementierungen hinweg beibehalten wird. Daher MÜSSEN Android-Geräteimplementierungen Weiß für Systemstatussymbole (wie Signalstärke und Batteriestand) und vom System ausgegebene Benachrichtigungen verwenden, es sei denn, das Symbol weist auf einen problematischen Status hin [ Ressourcen, 25 ].

3.8.7. Live-Hintergründe

Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, der es Anwendungen ermöglicht, dem Endbenutzer ein oder mehrere „Live-Hintergründe“ anzuzeigen [ Ressourcen, 26 ]. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabemöglichkeiten, die als Hintergrund hinter anderen Anwendungen angezeigt werden.

Es wird davon ausgegangen, dass Hardware Live-Hintergründe zuverlässig ausführen kann, wenn sie alle Live-Hintergründe ohne Funktionseinschränkungen und mit einer angemessenen Bildrate ohne nachteilige Auswirkungen auf andere Anwendungen ausführen kann. Wenn Einschränkungen in der Hardware dazu führen, dass Hintergrundbilder und/oder Anwendungen abstürzen, nicht richtig funktionieren, übermäßig viel CPU- oder Akkuleistung verbrauchen oder mit unannehmbar niedrigen Bildraten laufen, wird davon ausgegangen, dass die Hardware nicht in der Lage ist, Live-Hintergrundbilder auszuführen. Einige Live-Hintergründe können beispielsweise einen Open GL 1.0- oder 2.0-Kontext verwenden, um ihren Inhalt darzustellen. Das Live-Hintergrundbild wird auf Hardware, die nicht mehrere OpenGL-Kontexte unterstützt, nicht zuverlässig ausgeführt, da die Verwendung eines OpenGL-Kontexts durch das Live-Hintergrundbild möglicherweise mit anderen Anwendungen in Konflikt steht, die ebenfalls einen OpenGL-Kontext verwenden.

Geräteimplementierungen, die Live-Hintergründe wie oben beschrieben zuverlässig ausführen können, SOLLTEN Live-Hintergründe implementieren. Geräteimplementierungen, bei denen Live-Hintergründe wie oben beschrieben nicht zuverlässig ausgeführt werden, DÜRFEN KEINE Live-Hintergründe implementieren.

3.8.8. Aktuelle Anwendungsanzeige

Der Upstream-Android-Quellcode enthält eine Benutzeroberfläche zum Anzeigen aktueller Anwendungen mithilfe einer Miniaturansicht des grafischen Status der Anwendung zum Zeitpunkt des letzten Verlassens der Anwendung durch den Benutzer. Geräteimplementierungen KÖNNEN diese Benutzeroberfläche ändern oder entfernen; Es ist jedoch geplant, dass eine zukünftige Android-Version diese Funktionalität umfassender nutzt. Bei Geräteimplementierungen wird dringend empfohlen, für aktuelle Anwendungen die Upstream-Android-Benutzeroberfläche (oder eine ähnliche, auf Miniaturansichten basierende Oberfläche) zu verwenden, da sie sonst möglicherweise nicht mit einer zukünftigen Android-Version kompatibel sind.

3.8.9. Eingabemanagement

Android bietet Unterstützung für die Eingabeverwaltung und Unterstützung für Eingabemethoden-Editoren von Drittanbietern. Geräteimplementierungen, die es Benutzern ermöglichen, Eingabemethoden von Drittanbietern auf dem Gerät zu verwenden, MÜSSEN die Plattformfunktion android.software.input_methods deklarieren und IME-APIs unterstützen, wie in der Android SDK-Dokumentation definiert.

Geräteimplementierungen, die die Funktion android.software.input_methods deklarieren, MÜSSEN einen für den Benutzer zugänglichen Mechanismus zum Hinzufügen und Konfigurieren von Eingabemethoden von Drittanbietern bereitstellen. Geräteimplementierungen MÜSSEN die Einstellungsschnittstelle als Reaktion auf die Absicht android.settings.INPUT_METHOD_SETTINGS anzeigen.

3.8.10. Sperrbildschirm-Medienfernbedienung

Android bietet Unterstützung für die Remote Control API, die es Medienanwendungen ermöglicht, Wiedergabesteuerungen zu integrieren, die in einer Remote-Ansicht wie dem Gerätesperrbildschirm angezeigt werden [ Ressourcen, 74 ]. Geräteimplementierungen, die den Sperrbildschirm im Gerät unterstützen und es Benutzern ermöglichen, Widgets auf dem Startbildschirm hinzuzufügen, MÜSSEN Unterstützung für die Einbettung von Fernbedienungen in den Gerätesperrbildschirm enthalten [ Ressourcen, 69 ].

3.8.11. Träume

Android bietet Unterstützung für interaktive Bildschirmschoner namens Dreams [ Ressourcen, 76 ]. Mit Dreams können Benutzer mit Anwendungen interagieren, wenn ein Ladegerät im Leerlauf ist oder an einer Schreibtischstation angedockt ist. Geräteimplementierungen MÜSSEN Unterstützung für Dreams beinhalten und eine Einstellungsoption für Benutzer zum Konfigurieren von Dreams bereitstellen.

3.8.12. Standort

Standortmodi MÜSSEN im Standortmenü in den Einstellungen [ Ressourcen, 87 ] angezeigt werden. Standortdienste, die über den in Android 4.4 eingeführten SettingInjectorService bereitgestellt werden, müssen im gleichen Standortmenü angezeigt werden [ Ressourcen, 89 ].

3.8.13. Unicode

Android 4.4 bietet Unterstützung für farbige Emoji-Zeichen. Android-Geräteimplementierungen MÜSSEN dem Benutzer eine Eingabemethode für die in Unicode 6.1 [ Ressourcen, 82 ] definierten Emoji-Zeichen bieten und in der Lage sein, diese Emoji-Zeichen in Farbglyphen darzustellen.

3.9. Geräteverwaltung

Android umfasst Funktionen, die es sicherheitsbewussten Anwendungen ermöglichen, Geräteverwaltungsfunktionen auf Systemebene auszuführen, wie z. B. die Durchsetzung von Kennwortrichtlinien oder die Durchführung einer Remote-Löschung, über die Android-Geräteverwaltungs-API [ Ressourcen, 27 ]. Geräteimplementierungen MÜSSEN eine Implementierung der DevicePolicyManager Klasse [ Ressourcen, 28 ] bereitstellen. Geräteimplementierungen, die Unterstützung für den Sperrbildschirm beinhalten, MÜSSEN den gesamten Bereich der Geräteverwaltungsrichtlinien unterstützen, die in der Android SDK-Dokumentation [ Ressourcen, 27 ] definiert sind.

Geräteimplementierungen KÖNNEN über eine vorinstallierte Anwendung verfügen, die Geräteverwaltungsfunktionen ausführt, diese Anwendung DARF jedoch NICHT standardmäßig als Standard-Gerätebesitzer-App festgelegt werden [ Ressourcen, 84 ].

3.10. Barrierefreiheit

Android bietet eine Barrierefreiheitsebene, die Benutzern mit Behinderungen die Navigation auf ihren Geräten erleichtert. Darüber hinaus stellt Android Plattform-APIs bereit, die es Implementierungen von Barrierefreiheitsdiensten ermöglichen, Rückrufe für Benutzer- und Systemereignisse zu empfangen und alternative Feedback-Mechanismen wie Text-to-Speech, haptisches Feedback und Trackball-/D-Pad-Navigation zu generieren [ Ressourcen, 29 ]. Geräteimplementierungen MÜSSEN eine Implementierung des Android-Barrierefreiheits-Frameworks bereitstellen, die mit der Standard-Android-Implementierung übereinstimmt. Insbesondere MÜSSEN Geräteimplementierungen die folgenden Anforderungen erfüllen.

Geräteimplementierungen MÜSSEN Implementierungen von Barrierefreiheitsdiensten von Drittanbietern über die android.accessibilityservice APIs unterstützen [ Ressourcen, 30 ].
Geräteimplementierungen MÜSSEN AccessibilityEvents generieren und diese Ereignisse an alle registrierten AccessibilityService Implementierungen in einer mit der Standard-Android-Implementierung konsistenten Weise übermitteln.
Geräteimplementierungen MÜSSEN einen für den Benutzer zugänglichen Mechanismus zum Aktivieren und Deaktivieren von Barrierefreiheitsdiensten bereitstellen und diese Schnittstelle als Reaktion auf die Absicht android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS anzeigen.

Darüber hinaus SOLLTEN Geräteimplementierungen eine Implementierung eines Barrierefreiheitsdienstes auf dem Gerät bereitstellen und einen Mechanismus bereitstellen, mit dem Benutzer den Barrierefreiheitsdienst während der Geräteeinrichtung aktivieren können. Eine Open-Source-Implementierung eines Barrierefreiheitsdienstes ist im Eyes Free-Projekt verfügbar [ Ressourcen, 31 ].

3.11. Text zu Sprache

Android umfasst APIs, die es Anwendungen ermöglichen, Text-to-Speech-Dienste (TTS) zu nutzen, und ermöglicht es Dienstanbietern, Implementierungen von TTS-Diensten bereitzustellen [ Ressourcen, 32 ]. Geräteimplementierungen MÜSSEN diese Anforderungen in Bezug auf das Android TTS-Framework erfüllen:

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. Beachten Sie, dass die Upstream-Android-Open-Source-Software eine TTS-Engine-Implementierung mit vollem Funktionsumfang enthält.
Geräteimplementierungen MÜSSEN die Installation von TTS-Engines von Drittanbietern unterstützen.
Geräteimplementierungen MÜSSEN eine für den Benutzer zugängliche Schnittstelle bereitstellen, die es Benutzern ermöglicht, eine TTS-Engine für die Verwendung auf Systemebene auszuwählen.

4. Kompatibilität der Anwendungspakete

Geräteimplementierungen MÜSSEN Android-„.apk“-Dateien installieren und ausführen, wie sie vom „aapt“-Tool generiert wurden, das im offiziellen Android SDK enthalten ist [ Ressourcen, 33 ].

Geräteimplementierungen DÜRFEN die Formate .apk [ Ressourcen, 34 ], Android Manifest [ Ressourcen, 35 ], Dalvik-Bytecode [ Ressourcen, 17 ] oder Renderscript-Bytecode NICHT in einer Weise erweitern, die verhindern würde, dass diese Dateien ordnungsgemäß installiert und ausgeführt werden andere kompatible Geräte. Geräteimplementierer SOLLTEN die Referenz-Upstream-Implementierung von Dalvik und das Paketverwaltungssystem der Referenzimplementierung verwenden.

5. Multimedia-Kompatibilität

Geräteimplementierungen MÜSSEN mindestens eine Form der Audioausgabe umfassen, z. B. Lautsprecher, Kopfhöreranschluss, externer Lautsprecheranschluss usw.

5.1. Mediencodecs

Geräteimplementierungen MÜSSEN die in der Android SDK-Dokumentation [ Ressourcen, 58 ] angegebenen Kernmedienformate unterstützen, sofern dies in diesem Dokument nicht ausdrücklich gestattet ist. Insbesondere MÜSSEN Geräteimplementierungen die in den folgenden Tabellen definierten Medienformate, Encoder, Decoder, Dateitypen und Containerformate unterstützen. Alle diese Codecs werden als Software-Implementierungen in der bevorzugten Android-Implementierung des Android Open Source Project bereitgestellt.

Bitte beachten Sie, dass weder Google noch die Open Handset Alliance garantieren, dass diese Codecs nicht durch Patente Dritter belastet sind. Diejenigen, die beabsichtigen, diesen Quellcode in Hardware- oder Softwareprodukten zu verwenden, werden darauf hingewiesen, dass für Implementierungen dieses Codes, einschließlich in Open-Source-Software oder Shareware, möglicherweise Patentlizenzen der jeweiligen Patentinhaber erforderlich sind.

Beachten Sie, dass in diesen Tabellen keine spezifischen Bitratenanforderungen für die meisten Videocodecs aufgeführt sind, da die aktuelle Gerätehardware nicht unbedingt Bitraten unterstützt, die genau den erforderlichen Bitraten entsprechen, die in den relevanten Standards angegeben sind. Stattdessen SOLLTEN Geräteimplementierungen die höchstmögliche Bitrate auf der Hardware unterstützen, bis zu den in den Spezifikationen definierten Grenzen.

Typ	Format / Codec	Encoder	Decoder	Einzelheiten	Dateityp(en)/Containerformate
Audio	MPEG-4 AAC-Profil (AAC LC)	ERFORDERLICH für Geräteimplementierungen, die Mikrofonhardware umfassen und `android.hardware.microphone` definieren.	ERFORDERLICH	Unterstützung für Mono/Stereo/5.0/5.1*-Inhalte mit Standard-Abtastraten von 8 bis 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS Raw AAC (.aac, Dekodierung in Android 3.1+, Kodierung in Android 4.0+, ADIF nicht unterstützt) MPEG-TS (.ts, nicht durchsuchbar, Android 3.0+)
	MPEG-4 HE AAC-Profil (AAC+)	ERFORDERLICH für Geräteimplementierungen, die Mikrofonhardware umfassen und android.hardware.microphone definieren	ERFORDERLICH	Unterstützung für Mono/Stereo/5.0/5.1*-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.
	MPEG-4 HE AAC v2-Profil (erweitertes AAC+)		ERFORDERLICH	Unterstützung für Mono/Stereo/5.0/5.1*-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.
	MPEG-4-Audioobjekttyp ER AAC ELD (Enhanced Low Delay AAC)	ERFORDERLICH für Geräteimplementierungen, die Mikrofonhardware umfassen und android.hardware.microphone definieren	ERFORDERLICH	Unterstützung für Mono-/Stereo-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.
	AMR-NB	ERFORDERLICH für Geräteimplementierungen, die Mikrofonhardware umfassen und `android.hardware.microphone` definieren.	ERFORDERLICH	4,75 bis 12,2 kbps abgetastet bei 8 kHz	3GPP (.3gp)
	AMR-WB	ERFORDERLICH für Geräteimplementierungen, die Mikrofonhardware umfassen und `android.hardware.microphone` definieren.	ERFORDERLICH	9 Raten von 6,60 kbit/s bis 23,85 kbit/s, abgetastet bei 16 kHz	3GPP (.3gp)
	FLAC		ERFORDERLICH (Android 3.1+)	Mono/Stereo (kein Mehrkanal). Abtastraten bis zu 48 kHz (bei Geräten mit 44,1-kHz-Ausgang werden jedoch bis zu 44,1 kHz empfohlen, da der Downsampler von 48 auf 44,1 kHz keinen Tiefpassfilter enthält). 16-Bit empfohlen; Für 24-Bit wurde kein Dither angewendet.	Nur FLAC (.flac).
	MP3		ERFORDERLICH	Mono/Stereo 8-320 Kbit/s konstante (CBR) oder variable Bitrate (VBR)	MP3 (.mp3)
	MIDI		ERFORDERLICH	MIDI Typ 0 und 1. DLS Version 1 und 2. XMF und Mobile XMF. Unterstützung für die Klingeltonformate RTTTL/RTX, OTA und iMelody	Geben Sie 0 und 1 ein (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbis		ERFORDERLICH		Ogg (.ogg) Matroska (.mkv)
	PCM/WAVE	ERFORDERLICH	ERFORDERLICH	8-Bit- und 16-Bit-Linear-PCM** (Raten bis zur Grenze der Hardware). Geräte MÜSSEN Abtastraten für Roh-PCM-Aufzeichnung bei den Frequenzen 8000, 16000 und 44100 Hz unterstützen	WELLE (.wav)
Bild	JPEG	ERFORDERLICH	ERFORDERLICH	Basis+progressiv	JPEG (.jpg)
	GIF		ERFORDERLICH		GIF (.gif)
	PNG	ERFORDERLICH	ERFORDERLICH		PNG (.png)
	BMP		ERFORDERLICH		BMP (.bmp)
	WEBP	ERFORDERLICH	ERFORDERLICH		WebP (.webp)
Video	H.263	ERFORDERLICH für Geräteimplementierungen, die Kamerahardware umfassen und `android.hardware.camera` oder `android.hardware.camera.front` definieren.	ERFORDERLICH		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	ERFORDERLICH für Geräteimplementierungen, die Kamerahardware umfassen und `android.hardware.camera` oder `android.hardware.camera.front` definieren.	ERFORDERLICH	Basisprofil (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, nur AAC-Audio, nicht suchbar, Android 3.0+)
	MPEG-4 SP		ERFORDERLICH		3GPP (.3gp)
	VP8****	ERFORDERLICH (Android 4.3+)	ERFORDERLICH (Android 2.3.3+)		WebM (.webm) und Matroska (.mkv, Android 4.0+)***
	VP9		ERFORDERLICH (Android 4.4+)		WebM (.webm) und Matroska (.mkv, Android 4.0+)***

*Hinweis: Es ist nur ein Downmix von 5.0/5.1-Inhalten erforderlich; Das Aufzeichnen oder Rendern von mehr als 2 Kanälen ist optional.
**Hinweis: Eine lineare 16-Bit-PCM-Erfassung ist obligatorisch. Eine lineare 8-Bit-PCM-Erfassung ist nicht zwingend erforderlich.
***Hinweis: Geräteimplementierungen SOLLTEN das Schreiben von Matroska WebM-Dateien unterstützen.
****Hinweis: Für eine akzeptable Qualität von Web-Video-Streaming und Videokonferenzdiensten SOLLTEN Geräteimplementierungen einen Hardware-VP8-Codec verwenden, der die Anforderungen in [ Ressourcen, 86 ] erfüllt.

5.2. Videokodierung

Android-Geräteimplementierungen, die eine nach hinten gerichtete Kamera enthalten und android.hardware.camera deklarieren, SOLLTEN die folgenden H.264-Videokodierungsprofile unterstützen.

	SD (Geringe Qualität)	SD (Hohe Qualität)	HD (sofern von der Hardware unterstützt)
Video Auflösung	176 x 144 Pixel	480 x 360 Pixel	1280 x 720 Pixel
Video-Bildrate	12 fps	30 fps	30 fps
Video-Bitrate	56 Kbit/s	500 Kbit/s oder höher	2 Mbit/s oder höher
Audio-Codec	AAC-LC	AAC-LC	AAC-LC
Audiokanäle	1 (Mono)	2 (Stereo)	2 (Stereo)
Audio Bitrate	24 Kbit/s	128 Kbit/s	192 Kbit/s

Android-Geräteimplementierungen, die eine nach hinten gerichtete Kamera enthalten und android.hardware.camera deklarieren, SOLLTEN die folgenden VP8-Videokodierungsprofile unterstützen

	SD (Geringe Qualität)	SD (Hohe Qualität)	HD 720p (Wenn von der Hardware unterstützt)	HD 1080p (Wenn von der Hardware unterstützt)
Video Auflösung	320 x 180 Pixel	640 x 360 Pixel	1280 x 720 Pixel	1920 x 1080 Pixel
Video-Bildrate	30 fps	30 fps	30 fps	30 fps
Video-Bitrate	800 Kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.3. Videodekodierung

Android-Geräteimplementierungen SOLLTEN die folgenden VP8-, VP9- und H.264-Videodekodierungsprofile unterstützen. Geräteimplementierungen SOLLTEN auch die dynamische Umschaltung der Videoauflösung innerhalb desselben Streams für die Codecs VP8, VP9 und H.264 unterstützen.

	SD (Geringe Qualität)	SD (Hohe Qualität)	HD 720p (Wenn von der Hardware unterstützt)	HD 1080p (Wenn von der Hardware unterstützt)
Video Auflösung	320 x 180 Pixel	640 x 360 Pixel	1280 x 720 Pixel	1920 x 1080 Pixel
Video-Bildrate	30 fps	30 fps	30 fps	30 fps
Video-Bitrate	800 Kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.4. Audio Aufnahme

Wenn eine Anwendung die android.media.AudioRecord API verwendet hat, um mit der Aufzeichnung eines Audiostreams zu beginnen, MÜSSEN Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone deklarieren, Audio mit jedem dieser Verhaltensweisen abtasten und aufzeichnen:

Das Gerät SOLLTE eine annähernd flache Amplituden-Frequenz-Charakteristik aufweisen; insbesondere ±3 dB, von 100 Hz bis 4000 Hz
Die Audioeingangsempfindlichkeit SOLLTE so eingestellt werden, dass eine Quelle mit einem Schallleistungspegel (SPL) von 90 dB bei 1000 Hz einen RMS von 2500 für 16-Bit-Samples ergibt.
PCM-Amplitudenpegel SOLLTEN Änderungen des Eingangs-Schalldruckpegels über mindestens einen 30-dB-Bereich von -18 dB bis +12 dB bei einem Schalldruckpegel von 90 dB am Mikrofon linear verfolgen.
Die gesamte harmonische Verzerrung SOLLTE bei 1 kHz und 90 dB SPL-Eingangspegel weniger als 1 % betragen.

Wenn eine Anwendung zusätzlich zu den oben genannten Aufzeichnungsspezifikationen mit der Aufzeichnung eines Audiostreams mithilfe der Audioquelle android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION begonnen hat:

Die Rauschunterdrückungsverarbeitung MUSS, falls vorhanden, deaktiviert werden.
Falls vorhanden, MUSS die automatische Verstärkungsregelung deaktiviert werden.

Ab Android 4.4 verfügt die Klasse android.media.MediaRecorder.AudioSource über eine neue Audioquelle: REMOTE_SUBMIX . Geräte MÜSSEN die Audioquelle REMOTE_SUBMIX ordnungsgemäß implementieren, damit eine Anwendung, wenn sie die API android.media.AudioRecord zum Aufzeichnen von dieser Audioquelle verwendet, eine Mischung aller Audiostreams mit Ausnahme der folgenden erfassen kann:

STREAM_RING
STREAM_ALARM
STREAM_NOTIFICATION

Hinweis: Während einige der oben genannten Anforderungen seit Android 4.3 als „SOLLTEN“ angegeben werden, ist geplant, diese in der Kompatibilitätsdefinition für eine zukünftige Version in „MUSS“ zu ändern. Das heißt, diese Anforderungen sind in Android 4.4 optional, werden aber in einer zukünftigen Version erforderlich sein . Bestehende und neue Geräte, auf denen Android ausgeführt wird, sollten diese Anforderungen unbedingt erfüllen , da sie sonst bei einem Upgrade auf die zukünftige Version nicht die Android-Kompatibilität erreichen können.

Wenn die Plattform Geräuschunterdrückungstechnologien unterstützt, die auf die Spracherkennung abgestimmt sind, MUSS der Effekt über die android.media.audiofx.NoiseSuppressor -API steuerbar sein. Darüber hinaus MUSS das „UUID“-Feld für den Effektdeskriptor des Rauschunterdrückers jede Implementierung der Rauschunterdrückungstechnologie eindeutig identifizieren.

5.5. Audiolatenz

Unter Audiolatenz versteht man die Zeitverzögerung, während ein Audiosignal ein System durchläuft. Viele Anwendungsklassen sind auf kurze Latenzen angewiesen, um Echtzeit-Soundeffekte zu erzielen.

Für die Zwecke dieses Abschnitts:

„Ausgabelatenz“ ist definiert als das Intervall zwischen dem Schreiben eines Frames PCM-codierter Daten durch eine Anwendung und dem Zeitpunkt, an dem der entsprechende Ton von einem externen Zuhörer gehört oder von einem Wandler beobachtet werden kann
„kalte Ausgabelatenz“ ist definiert als die Ausgabelatenz für den ersten Frame, wenn das Audioausgabesystem vor der Anforderung im Leerlauf war und ausgeschaltet wurde
„Kontinuierliche Ausgabelatenz“ ist definiert als die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät bereits Audio abspielt
„Eingabelatenz“ ist die Zeitspanne zwischen der Präsentation eines externen Tons auf dem Gerät und dem Lesen des entsprechenden Frames PCM-codierter Daten durch eine Anwendung
„Cold-Input-Latenz“ ist definiert als die Summe der verlorenen Eingabezeit und der Eingabelatenz für den ersten Frame, wenn das Audio-Eingabesystem vor der Anforderung im Leerlauf war und ausgeschaltet war
„Kontinuierliche Eingabelatenz“ ist definiert als die Eingabelatenz für nachfolgende Frames, während das Gerät bereits Audio aufnimmt
„OpenSL ES PCM-Pufferwarteschlangen-API“ ist der Satz PCM-bezogener OpenSL ES-APIs innerhalb von Android NDK; siehe NDK_root /docs/opensles/index.html

Gemäß Abschnitt 5 MÜSSEN alle kompatiblen Geräteimplementierungen mindestens eine Form der Audioausgabe umfassen. Geräteimplementierungen SOLLTEN diese Anforderungen an die Ausgabelatenz erfüllen oder übertreffen:

Kaltausgabelatenz von 100 Millisekunden oder weniger
Kontinuierliche Ausgabelatenz von 45 Millisekunden oder weniger

Wenn eine Geräteimplementierung nach einer anfänglichen Kalibrierung bei Verwendung der OpenSL ES PCM-Pufferwarteschlangen-API die Anforderungen dieses Abschnitts für kontinuierliche Ausgabelatenz und Kaltausgabelatenz über mindestens ein unterstütztes Audioausgabegerät erfüllt, kann sie möglicherweise Unterstützung für Audio mit niedriger Latenz melden , indem die Funktion „android.hardware.audio.low-latency“ über die Klasse android.content.pm.PackageManager gemeldet wird. [ Ressourcen, 37 ] Wenn die Geräteimplementierung diese Anforderungen hingegen nicht erfüllt, DARF sie KEINE Unterstützung für Audio mit geringer Latenz melden.

Gemäß Abschnitt 7.2.5 kann bei Geräteimplementierungen auf Mikrofonhardware verzichtet werden.

Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone deklarieren, SOLLTEN diese Anforderungen an die Latenz der Eingabeaudio erfüllen:

Kalte Eingabelatenz von 100 Millisekunden oder weniger
Kontinuierliche Eingabelatenz von 50 Millisekunden oder weniger

5.6. Netzwerkprotokolle

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

RTSP (RTP, SDP)
Progressives HTTP(S)-Streaming
HTTP(S)-Live-Streaming-Protokollentwurf, Version 3 [ Ressourcen, 59 ]

6. Kompatibilität von Entwicklertools und -optionen

6.1. Entwicklerwerkzeuge

Geräteimplementierungen MÜSSEN die im Android SDK bereitgestellten Android Developer Tools unterstützen. Insbesondere MÜSSEN Android-kompatible Geräte kompatibel sein mit:

Android Debug Bridge (bekannt als adb) [ Ressourcen, 33 ]
Geräteimplementierungen MÜSSEN alle adb Funktionen unterstützen, wie im Android SDK dokumentiert. Der geräteseitige adb Daemon MUSS standardmäßig inaktiv sein und es MUSS einen für den Benutzer zugänglichen Mechanismus zum Aktivieren der Android Debug Bridge geben.
Android bietet Unterstützung für Secure ADB. Secure ADB aktiviert ADB auf bekannten authentifizierten Hosts. Geräteimplementierungen MÜSSEN Secure ADB unterstützen.
Dalvik Debug Monitor Service (bekannt als ddms) [ Ressourcen, 33 ]
Geräteimplementierungen MÜSSEN alle im Android SDK dokumentierten ddms Funktionen unterstützen. Da ddms adb verwendet, SOLLTE die Unterstützung für ddms standardmäßig inaktiv sein, MUSS jedoch immer dann unterstützt werden, wenn der Benutzer die Android Debug Bridge wie oben aktiviert hat.
Affe [ Ressourcen, 36 ]
Geräteimplementierungen MÜSSEN das Monkey-Framework enthalten und es für die Verwendung durch Anwendungen verfügbar machen.
SysTrace [ Ressourcen, 33 ]
Geräteimplementierungen MÜSSEN das Systrace-Tool unterstützen, wie im Android SDK dokumentiert. Systrace muss standardmäßig inaktiv sein und es MUSS einen für den Benutzer zugänglichen Mechanismus zum Aktivieren von Systrace geben.

Die meisten Linux-basierten Systeme und Apple Macintosh-Systeme erkennen Android-Geräte mithilfe der Standard-Android-SDK-Tools ohne zusätzliche Unterstützung. Allerdings benötigen Microsoft Windows-Systeme normalerweise einen Treiber für neue Android-Geräte. (Beispielsweise erfordern neue Hersteller-IDs und manchmal auch neue Geräte-IDs benutzerdefinierte USB-Treiber für Windows-Systeme.) Wenn eine Geräteimplementierung vom adb Tool, wie es im Standard-Android-SDK bereitgestellt wird, nicht erkannt wird, MÜSSEN Geräteimplementierer Windows-Treiber bereitstellen, mit denen Entwickler eine Verbindung herstellen können Das Gerät verwendet das adb Protokoll. Diese Treiber MÜSSEN für Windows XP, Windows Vista, Windows 7 und Windows 8 sowohl in der 32-Bit- als auch in der 64-Bit-Version bereitgestellt werden.

6.2. Entwickleroptionen

Android unterstützt Entwickler beim Konfigurieren von Einstellungen für die Anwendungsentwicklung. Geräteimplementierungen MÜSSEN die Absicht android.settings.APPLICATION_DEVELOPMENT_SETTINGS berücksichtigen, um anwendungsentwicklungsbezogene Einstellungen anzuzeigen [ Ressourcen, 77 ]. Die Upstream-Android-Implementierung verbirgt standardmäßig das Menü „Entwickleroptionen“ und ermöglicht es Benutzern, die Entwickleroptionen zu starten, nachdem sie sieben (7) Mal auf den Menüpunkt „Einstellungen“ > „Über Gerät“ > „Build-Nummer“ gedrückt haben. Geräteimplementierungen MÜSSEN eine konsistente Erfahrung für Entwickleroptionen bieten. Insbesondere MÜSSEN Geräteimplementierungen Entwickleroptionen standardmäßig ausblenden und einen Mechanismus zum Aktivieren von Entwickleroptionen bereitstellen, der mit der Upstream-Android-Implementierung konsistent ist.

6.2.1. Experimental

Mit Android 4.4 wird ART eingeführt, eine experimentelle Android-Laufzeitumgebung, die über das Menü „Entwickleroptionen“ als Vorschau aufgerufen werden kann. Geräteimplementierungen SOLLTEN ART (libart.so) enthalten und Dual-Boot über Entwickleroptionen unterstützen, MÜSSEN jedoch Dalvik (libdvm.so) als Standardlaufzeit beibehalten.

7. Hardwarekompatibilität

Wenn ein Gerät eine bestimmte Hardwarekomponente enthält, die über eine entsprechende API für Drittentwickler verfügt, 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 besitzt:

Vollständige Klassendefinitionen (wie vom SDK dokumentiert) für die APIs der Komponente MÜSSEN noch vorhanden sein
Das Verhalten der API MUSS auf vernünftige Weise als No-Ops implementiert werden
API-Methoden MÜSSEN Nullwerte zurückgeben, sofern die SDK-Dokumentation dies zulässt
API-Methoden MÜSSEN No-Op-Implementierungen von Klassen zurückgeben, bei denen Nullwerte in der SDK-Dokumentation nicht zulässig sind
API-Methoden DÜRFEN KEINE Ausnahmen auslösen, die nicht in der SDK-Dokumentation dokumentiert sind

Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telefonie-API: Auch auf Nicht-Telefongeräten müssen diese APIs als sinnvolle No-Ops-Lösungen implementiert werden.

Geräteimplementierungen MÜSSEN genaue Informationen zur Hardwarekonfiguration über die Methoden getSystemAvailableFeatures() und hasSystemFeature(String) in der Klasse android.content.pm.PackageManager melden. [ Ressourcen, 37 ]

7.1. Anzeige und Grafiken

Android verfügt über Funktionen, die Anwendungsressourcen und UI-Layouts automatisch entsprechend dem Gerät anpassen, um sicherzustellen, dass Anwendungen von Drittanbietern auf einer Vielzahl von Hardwarekonfigurationen gut laufen [ Ressourcen, 38 ]. Geräte MÜSSEN diese APIs und Verhaltensweisen ordnungsgemäß implementieren, wie in diesem Abschnitt beschrieben.

Die Einheiten, auf die sich die Anforderungen in diesem Abschnitt beziehen, sind wie folgt definiert:

„Physikalische Diagonalgröße“ ist der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Teils des Displays.
„dpi“ (bedeutet „Punkte pro Zoll“) ist die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1“ umfasst werden. Wenn dpi-Werte aufgeführt sind, müssen sowohl horizontale als auch vertikale dpi innerhalb des Bereichs liegen.
„Seitenverhältnis“ ist das Verhältnis der längeren Abmessung des Bildschirms zur kürzeren Abmessung. Beispielsweise wäre eine Anzeige mit 480 x 854 Pixeln 854 / 480 = 1,779, also ungefähr „16:9“.
Ein „dichteunabhängiges Pixel“ oder („dp“) ist die virtuelle Pixeleinheit, normalisiert auf einen 160-dpi-Bildschirm, berechnet als: pixels = dps * (density / 160) .

7.1.1. Bildschirmkonfiguration

Bildschirmgröße

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

Geräte MÜSSEN eine Bildschirmgröße von mindestens 426 dp x 320 dp („klein“) haben.
Geräte, die die Bildschirmgröße als „normal“ melden, MÜSSEN eine Bildschirmgröße von mindestens 480 dp x 320 dp haben
Geräte, die die Bildschirmgröße „groß“ melden, MÜSSEN eine Bildschirmgröße von mindestens 640 dp x 480 dp haben
Geräte, die die Bildschirmgröße „xlarge“ melden, MÜSSEN eine Bildschirmgröße von mindestens 960 dp x 720 dp haben

Darüber hinaus MÜSSEN Geräte eine Bildschirmgröße von mindestens 2,5 Zoll in der physischen Diagonale haben.

Geräte DÜRFEN zu keinem Zeitpunkt ihre gemeldete Bildschirmgröße ändern.

Anwendungen geben optional über das Attribut <supports-screens> in der Datei AndroidManifest.xml an, welche Bildschirmgrößen sie unterstützen. Geräteimplementierungen MÜSSEN die angegebene Unterstützung von Anwendungen für kleine, normale, große und XL-Bildschirme korrekt berücksichtigen, wie in der Android SDK-Dokumentation beschrieben.

Bildschirmseitenverhältnis

Das Seitenverhältnis MUSS ein Wert zwischen 1,3333 (4:3) und 1,86 (ungefähr 16:9) sein.

Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe standardmäßiger logischer Dichten, um Anwendungsentwicklern dabei zu helfen, Anwendungsressourcen gezielt einzusetzen. Geräteimplementierungen MÜSSEN über die android.util.DisplayMetrics APIs eine der folgenden logischen Android-Framework-Dichten melden und MÜSSEN Anwendungen mit dieser Standarddichte ausführen.

120 dpi, bekannt als „ldpi“
160 dpi, bekannt als „mdpi“
213 dpi, bekannt als „tvdpi“
240 dpi, bekannt als „hdpi“
320 dpi, bekannt als „xhdpi“
400 dpi, bekannt als „400 dpi“
480 dpi, bekannt als „xxhdpi“
640 dpi, bekannt als „xxxhdpi“

Geräteimplementierungen SOLLTEN die standardmäßige Android-Framework-Dichte definieren, die numerisch der physischen Dichte des Bildschirms am nächsten kommt, es sei denn, diese logische Dichte drückt die gemeldete Bildschirmgröße unter das unterstützte Minimum. Wenn die Standard-Android-Framework-Dichte, 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, SOLLTEN Geräteimplementierungen die nächstniedrigere Standard-Android-Framework-Dichte melden.

7.1.2. Messwerte anzeigen

Geräteimplementierungen MÜSSEN korrekte Werte für alle in android.util.DisplayMetrics [ Ressourcen, 39 ] definierten Anzeigemetriken melden.

7.1.3. Bildschirmausrichtung

Geräte MÜSSEN die dynamische Ausrichtung von Anwendungen auf die Bildschirmausrichtung im Hoch- oder Querformat unterstützen. Das heißt, das Gerät muss die Anforderung der Anwendung nach einer bestimmten Bildschirmausrichtung berücksichtigen. Geräteimplementierungen können standardmäßig entweder Hoch- oder Querformat auswählen.

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.

Geräte DÜRFEN die gemeldete Bildschirmgröße oder -dichte NICHT ändern, wenn sie die Ausrichtung ändern.

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. Beispielsweise DARF ein Gerät mit einem Bildschirm mit fester Ausrichtung im Querformat, etwa ein Fernseher oder ein Laptop, nur android.hardware.screen.landscape melden.

7.1.4. 2D- und 3D-Grafikbeschleunigung

Geräteimplementierungen MÜSSEN sowohl OpenGL ES 1.0 als auch 2.0 unterstützen, wie in den Android SDK-Dokumentationen dargelegt und detailliert beschrieben. Geräteimplementierungen SOLLTEN OpenGL ES 3.0 auf Geräten unterstützen, die OpenGL ES 3.0 unterstützen können. Geräteimplementierungen MÜSSEN auch Android Renderscript unterstützen, wie in der Android SDK-Dokumentation [ Ressourcen, 8 ] beschrieben.

Geräteimplementierungen MÜSSEN außerdem korrekt angeben, dass sie OpenGL ES 1.0, OpenGL ES 2.0 oder OpenGL ES 3.0 unterstützen. Das ist:

Die verwalteten APIs (z. B. über die Methode GLES10.getString() ) MÜSSEN Unterstützung für OpenGL ES 1.0 und OpenGL ES 2.0 melden
Die nativen C/C++ OpenGL-APIs (d. h. diejenigen, die für Apps über libGLES_v1CM.so, libGLES_v2.so oder libEGL.so verfügbar sind) MÜSSEN Unterstützung für OpenGL ES 1.0 und OpenGL ES 2.0 melden.
Geräteimplementierungen, die Unterstützung für OpenGL ES 3.0 deklarieren, MÜSSEN verwaltete OpenGL ES 3.0-APIs unterstützen und Unterstützung für native C/C++-APIs beinhalten. Bei Geräteimplementierungen, die Unterstützung für OpenGL ES 3.0 deklarieren, MUSS libGLESv2.so zusätzlich zu den OpenGL ES 2.0-Funktionssymbolen auch die OpenGL ES 3.0-Funktionssymbole exportieren.

Geräteimplementierungen KÖNNEN alle gewünschten OpenGL ES-Erweiterungen implementieren. Allerdings MÜSSEN Geräteimplementierungen über die von OpenGL ES verwalteten und nativen APIs alle Erweiterungszeichenfolgen melden, die sie unterstützen, und DÜRFEN umgekehrt keine Erweiterungszeichenfolgen melden, die sie nicht unterstützen.

Beachten Sie, dass Android Anwendungen unterstützt, um optional anzugeben, dass sie bestimmte OpenGL-Texturkomprimierungsformate erfordern. Diese Formate sind typischerweise herstellerspezifisch. Geräteimplementierungen sind für Android nicht erforderlich, um ein bestimmtes Texturkomprimierungsformat zu implementieren. Sie SOLLTEN jedoch alle von ihnen unterstützten Texturkomprimierungsformate über die Methode getString() in der OpenGL-API genau melden.

Android enthält einen Mechanismus, mit dem Anwendungen angeben können, dass sie die Hardwarebeschleunigung für 2D-Grafiken auf Anwendungs-, Aktivitäts-, Fenster- oder Ansichtsebene aktivieren möchten, indem sie ein Manifest-Tag android:hardwareAccelerated oder direkte API-Aufrufe verwenden [ Ressourcen, 9 ].

In Android 4.4 MÜSSEN Geräteimplementierungen die Hardwarebeschleunigung standardmäßig aktivieren und die Hardwarebeschleunigung deaktivieren, wenn der Entwickler dies anfordert, indem er android:hardwareAccelerated="false" festlegt oder die Hardwarebeschleunigung direkt über die Android View APIs deaktiviert.

Darüber hinaus MÜSSEN Geräteimplementierungen ein Verhalten aufweisen, das mit der Android SDK-Dokumentation zur Hardwarebeschleunigung übereinstimmt [ Ressourcen, 9 ].

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

Android bietet Unterstützung für EGL_ANDROID_RECORDABLE , ein EGLConfig-Attribut, das angibt, ob EGLConfig das Rendern in ein ANativeWindow unterstützt, das Bilder in einem Video aufzeichnet. Geräteimplementierungen MÜSSEN die Erweiterung EGL_ANDROID_RECORDABLE unterstützen [ Ressourcen, 79 ].

7.1.5. Kompatibilitätsmodus für ältere Anwendungen

Android gibt einen „Kompatibilitätsmodus“ an, in dem das Framework in einem „normalen“ Bildschirmgrößenäquivalentmodus (320 dp Breite) arbeitet, um älteren Anwendungen zugute zu kommen, die nicht für alte Android-Versionen entwickelt wurden, die älter als die Bildschirmgrößenunabhängigkeit waren. Geräteimplementierungen MÜSSEN Unterstützung für den Legacy-Anwendungskompatibilitätsmodus umfassen, wie er durch den Upstream-Open-Source-Code von Android implementiert wird. Das heißt, Geräteimplementierungen DÜRFEN NICHT die Auslöser oder Schwellenwerte ändern, bei denen der Kompatibilitätsmodus aktiviert wird, und DÜRFEN NICHT das Verhalten des Kompatibilitätsmodus selbst ändern.

7.1.6. Bildschirmtypen

Geräteimplementierungsbildschirme werden in einen von zwei Typen eingeteilt:

Implementierungen für die Anzeige mit festen Pixeln: Der Bildschirm ist ein einzelnes Panel, das nur eine einzelne Pixelbreite und -höhe unterstützt. Normalerweise ist der Bildschirm physisch in das Gerät integriert. Beispiele hierfür sind Mobiltelefone, Tablets usw.
Implementierungen mit variabler Pixelanzeige: Die Geräteimplementierung verfügt entweder über keinen eingebetteten Bildschirm und umfasst einen Videoausgangsanschluss wie VGA, HDMI oder einen drahtlosen Anschluss für die Anzeige, oder sie verfügt über einen eingebetteten Bildschirm, der die Pixelabmessungen ändern kann. Beispiele hierfür sind Fernseher, Set-Top-Boxen usw.

Implementierungen von Festpixel-Geräten

Implementierungen von Festpixel-Geräten KÖNNEN Bildschirme mit beliebigen Pixelabmessungen verwenden, sofern sie die in dieser Kompatibilitätsdefinition definierten Anforderungen erfüllen.

Implementierungen mit festen Pixeln KÖNNEN einen Videoausgangsanschluss für die Verwendung mit einem externen Display umfassen. Wenn dieses Display jedoch jemals zum Ausführen von Apps verwendet wird, MUSS das Gerät die folgenden Anforderungen erfüllen:

Das Gerät MUSS die gleichen Bildschirmkonfigurationen und Anzeigemetriken melden, wie in den Abschnitten 7.1.1 und 7.1.2 beschrieben, wie das Festpixel-Display.
Das Gerät MUSS die gleiche logische Dichte wie die Festpixelanzeige melden.
Das Gerät MUSS Bildschirmabmessungen melden, die mit denen der Festpixelanzeige übereinstimmen oder dieser sehr nahe kommen.

Beispielsweise gilt ein Tablet mit einer Diagonale von 7 Zoll und einer Auflösung von 1024 x 600 Pixeln als große MDPI-Anzeigeimplementierung mit festen Pixeln. Wenn es über einen Videoausgangsanschluss verfügt, der mit 720p oder 1080p angezeigt wird, MUSS die Geräteimplementierung die Ausgabe so skalieren, dass Anwendungen werden nur in einem großen MDPI-Fenster ausgeführt, unabhängig davon, ob die Festpixelanzeige oder der Videoausgangsport verwendet wird.

Implementierungen von Geräten mit variabler Pixelanzahl

Geräteimplementierungen mit variabler Pixelanzahl MÜSSEN mindestens eine Auflösung von 1280 x 720, 1920 x 1080 oder 3840 x 2160 (d. h. 720p, 1080p oder 4K) unterstützen. Geräteimplementierungen mit Displays mit variablen Pixeln DÜRFEN KEINE andere Bildschirmkonfiguration oder -modus unterstützen. Geräteimplementierungen mit Bildschirmen mit variablen Pixeln KÖNNEN die Bildschirmkonfiguration oder den Bildschirmmodus zur Laufzeit oder beim Booten ändern. Beispielsweise kann ein Benutzer einer Set-Top-Box ein 720p-Display durch ein 1080p-Display ersetzen und die Geräteimplementierung kann entsprechend angepasst werden.

Darüber hinaus MÜSSEN Geräteimplementierungen mit variablen Pixeln die folgenden Konfigurationsbereiche für diese Pixelabmessungen melden:

1280 x 720 (auch bekannt als 720p): „große“ Bildschirmgröße, „tvdpi“-Dichte (213 dpi).
1920 x 1080 (auch bekannt als 1080p): „große“ Bildschirmgröße, „xhdpi“-Dichte (320 dpi).
3840 x 2160 (auch bekannt als 4K): „große“ Bildschirmgröße, „xxxhdpi“ (640 dpi) Dichte

Aus Gründen der Übersichtlichkeit sind Geräteimplementierungen mit variablen Pixelabmessungen in Android 4.4 auf 720p, 1080p oder 4K beschränkt und MÜSSEN wie oben beschrieben für die Meldung von Bildschirmgröße und Dichte-Buckets konfiguriert werden.

7.1.7. Bildschirmtechnologie

Die Android-Plattform umfasst APIs, die es Anwendungen ermöglichen, umfangreiche Grafiken auf dem Display darzustellen. Geräte MÜSSEN alle diese APIs gemäß der Definition des Android SDK unterstützen, sofern dies in diesem Dokument nicht ausdrücklich gestattet ist. Speziell:

Geräte MÜSSEN Displays unterstützen, die 16-Bit-Farbgrafiken wiedergeben können, und SOLLTEN Displays unterstützen, die 24-Bit-Farbgrafiken unterstützen können.
Geräte MÜSSEN Displays unterstützen, die Animationen wiedergeben können.
Die verwendete Anzeigetechnologie MUSS ein Pixel-Seitenverhältnis (PAR) zwischen 0,9 und 1,1 haben. Das heißt, das Pixel-Seitenverhältnis MUSS nahezu quadratisch (1,0) mit einer Toleranz von 10 % sein.

7.1.8. Externe Displays

Android bietet Unterstützung für sekundäre Displays, um Medienfreigabefunktionen und Entwickler-APIs für den Zugriff auf externe Displays zu ermöglichen. Wenn ein Gerät eine externe Anzeige entweder über eine kabelgebundene, drahtlose oder eine eingebettete zusätzliche Anzeigeverbindung unterstützt, MUSS die Geräteimplementierung die Display-Manager-API implementieren, wie in der Android SDK-Dokumentation [ Ressourcen, 75 ] beschrieben. 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. Insbesondere Geräteimplementierungen, die Unterstützung für Display.FLAG_SECURE deklarieren, MÜSSEN HDCP 2.x oder höher für drahtlose Miracast-Displays oder HDCP 1.2 oder höher für kabelgebundene Displays unterstützen. Die Upstream-Android-Open-Source-Implementierung umfasst Unterstützung für drahtlose (Miracast) und kabelgebundene (HDMI) Displays, die diese Anforderung erfüllen.

7.2. Eingabegeräte

7.2.1. Tastatur

Geräteimplementierungen:

MUSS Unterstützung für das Input Management Framework enthalten (das es Drittentwicklern ermöglicht, Input Management Engines – z. B. Soft-Tastaturen) zu erstellen, wie unter http://developer.android.com beschrieben
MUSS mindestens eine Soft-Tastatur-Implementierung bereitstellen (unabhängig davon, ob eine Hard-Tastatur vorhanden ist)
KANN zusätzliche Soft-Tastatur-Implementierungen enthalten
KANN eine Hardware-Tastatur enthalten
DARF KEINE Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard [ Ressourcen, 40 ] angegebenen Formate entspricht (d. h. QWERTY oder 12-Tasten).

7.2.2. Non-Touch-Navigation

Geräteimplementierungen:

KANN eine Navigationsoption ohne Touch-Funktion weggelassen werden (d. h. ein Trackball, ein D-Pad oder ein Rad kann weggelassen werden)
MUSS den korrekten Wert für android.content.res.Configuration.navigation melden [ Ressourcen, 40 ]
MUSS einen angemessenen alternativen Benutzeroberflächenmechanismus für die Auswahl und Bearbeitung von Text bereitstellen, der mit Input Management Engines kompatibel ist. Die Upstream-Android-Open-Source-Implementierung umfasst einen Auswahlmechanismus, der für die Verwendung mit Geräten ohne berührungslose Navigationseingaben geeignet ist.

7.2.3. Navigationstasten

Die Funktionen „Home“, „Letzte“ und „Zurück“ sind für das Android-Navigationsparadigma von wesentlicher Bedeutung. Geräteimplementierungen MÜSSEN diese Funktionen dem Benutzer beim Ausführen von Anwendungen jederzeit verfügbar machen. Diese Funktionen KÖNNEN über dedizierte physische Tasten (z. B. mechanische oder kapazitive Touch-Tasten) oder über dedizierte Softwaretasten auf einem bestimmten Teil des Bildschirms, Gesten, Touchpanel usw. implementiert werden. Android unterstützt beide Implementierungen. Alle diese Funktionen MÜSSEN mit einer einzigen Aktion (z. B. Tippen, Doppelklicken oder Geste) zugänglich sein, wenn sie sichtbar sind.

Die Funktionen „Zurück“ und „Zuletzt verwendet“ SOLLTEN über eine sichtbare Schaltfläche oder ein sichtbares Symbol verfügen, sofern sie nicht zusammen mit anderen Navigationsfunktionen im Vollbildmodus ausgeblendet werden. Die Home-Funktion MUSS über eine sichtbare Schaltfläche oder ein sichtbares Symbol verfügen, sofern sie nicht zusammen mit anderen Navigationsfunktionen im Vollbildmodus ausgeblendet wird.

Die Menüfunktion ist seit Android 4.0 zugunsten der Aktionsleiste veraltet. Geräteimplementierungen SOLLTEN KEINE dedizierte physische Taste für die Menüfunktion implementieren. Wenn die physische Menüschaltfläche implementiert ist und das Gerät Anwendungen mit targetSdkVersion > 10 ausführt, gilt für die Geräteimplementierung Folgendes:

Bei einem Gerät, das mit Android 4.4 gestartet wird, MUSS die Aktionsüberlaufschaltfläche in der Aktionsleiste angezeigt werden, wenn die Aktionsleiste sichtbar ist und das resultierende Aktionsüberlaufmenü-Popup nicht leer ist.
Bei einem vorhandenen Gerät, das mit einer früheren Version gestartet wurde, aber auf Android 4.4 aktualisiert wird, SOLLTE die Schaltfläche „Aktionsüberlauf“ in der Aktionsleiste angezeigt werden, wenn die Aktionsleiste sichtbar ist und das resultierende Popup-Menü „Aktionsüberlauf“ nicht leer ist.
Die Position des Aktionsüberlauf-Popups, das durch Auswahl der Überlaufschaltfläche in der Aktionsleiste angezeigt wird, DARF NICHT geändert werden.
Das Aktionsüberlauf-Popup kann möglicherweise an einer geänderten Position auf dem Bildschirm angezeigt werden, wenn es durch Auswahl der physischen Menüschaltfläche angezeigt wird.

Aus Gründen der Abwärtskompatibilität MÜSSEN Geräteimplementierungen Anwendungen die Menüfunktion zur Verfügung stellen, wenn targetSdkVersion <= 10 ist, entweder über eine physische Taste, einen Softwareschlüssel oder Gesten. Diese Menüfunktion sollte angezeigt werden, sofern sie nicht zusammen mit anderen Navigationsfunktionen ausgeblendet wird.

Android unterstützt die Assist-Aktion [ Ressourcen, 63 ]. Geräteimplementierungen MÜSSEN die Assist-Aktion dem Benutzer beim Ausführen von Anwendungen jederzeit verfügbar machen. Die Assist-Aktion SOLLTE als langes Drücken der Home-Taste oder als Wischgeste nach oben auf der Software-Home-Taste implementiert werden. Diese Funktion KANN über eine andere physische Taste, Softwaretaste oder Gesten implementiert werden, MUSS jedoch mit einer einzigen Aktion (z. B. Tippen, Doppelklicken oder Geste) zugänglich sein, wenn andere Navigationstasten sichtbar sind.

Geräteimplementierungen KÖNNEN einen bestimmten Teil des Bildschirms zur Anzeige der Navigationstasten verwenden, MÜSSEN in diesem Fall jedoch die folgenden Anforderungen erfüllen:

Navigationstasten für die Geräteimplementierung MÜSSEN einen bestimmten Teil des Bildschirms belegen, der für Anwendungen nicht verfügbar ist, und DÜRFEN den für Anwendungen verfügbaren Teil des Bildschirms NICHT verdecken oder anderweitig beeinträchtigen.
Geräteimplementierungen MÜSSEN einen Teil der Anzeige für Anwendungen verfügbar machen, der die in Abschnitt 7.1.1 definierten Anforderungen erfüllt.
Geräteimplementierungen MÜSSEN die Navigationstasten anzeigen, wenn Anwendungen keinen System-UI-Modus angeben oder SYSTEM_UI_FLAG_VISIBLE angeben.
Geräteimplementierungen MÜSSEN die Navigationstasten in einem unauffälligen „unauffälligen“ (z. B. abgeblendeten) Modus darstellen, wenn Anwendungen SYSTEM_UI_FLAG_LOW_PROFILE angeben.
Geräteimplementierungen MÜSSEN die Navigationstasten ausblenden, wenn Anwendungen SYSTEM_UI_FLAG_HIDE_NAVIGATION angeben.

7.2.4. Touchscreen-Eingabe

Geräteimplementierungen SOLLTEN über ein Zeigereingabesystem verfügen (entweder mausähnlich oder per Berührung). Wenn eine Geräteimplementierung jedoch kein Zeigereingabesystem unterstützt, DARF sie NICHT die Funktionskonstante android.hardware.touchscreen oder android.hardware.faketouch melden. Geräteimplementierungen, die ein Zeigereingabesystem enthalten:

SOLLTE vollständig unabhängig verfolgte Zeiger unterstützen, wenn das Geräteeingabesystem mehrere Zeiger unterstützt
MUSS den Wert von android.content.res.Configuration.touchscreen [ Ressourcen, 40 ] melden, der dem Typ des spezifischen Touchscreens auf dem Gerät entspricht

Android bietet Unterstützung für eine Vielzahl von Touchscreens, Touchpads und Fake-Touch-Eingabegeräten. Touchscreen-basierte Geräteimplementierungen sind mit einer Anzeige verbunden [ Ressourcen, 81 ], so dass der Benutzer den Eindruck hat, Elemente auf dem Bildschirm direkt zu manipulieren. Da der Benutzer den Bildschirm direkt berührt, benötigt das System keine zusätzlichen Möglichkeiten, um die zu manipulierenden Objekte anzuzeigen. Im Gegensatz dazu bietet eine Fake-Touch-Schnittstelle ein Benutzereingabesystem, das einer Teilmenge der Touchscreen-Funktionen nahekommt. Beispielsweise ähnelt eine Maus oder Fernbedienung, die einen Bildschirmcursor steuert, einer Berührung, erfordert jedoch, dass der Benutzer zuerst zeigt oder fokussiert und dann klickt. Zahlreiche Eingabegeräte wie Maus, Trackpad, Gyro-basierte Air Mouse, Gyro-Pointer, Joystick und Multi-Touch-Trackpad können Fake-Touch-Interaktionen unterstützen. Android 4.0 enthält die Feature Constant android.hardware.faketouch , die einem Nicht-Touch-Eingabegerät mit hohem Fdentialität (dh Zeigerbasis) wie einer Maus oder einer Trackpad entspricht, die angemessene berührungsbasierte Eingabe (einschließlich Basisgestik Unterstützung) und gibt an, dass das Gerät eine emulierte Teilmenge der Touchscreen -Funktionalität unterstützt. Geräteimplementierungen, die die gefälschte Touch -Funktion deklarieren, müssen die gefälschten Berührungsanforderungen in Abschnitt 7.2.5 erfüllen.

Geräteimplementierungen müssen die korrekte Funktion melden, die dem verwendeten Eingangstyp entspricht. Geräteimplementierungen mit einem Touchscreen (Single-Touch oder besser) müssen die Plattformfunktion konstant android.hardware.touchscreen melden. Geräteimplementierungen, die die Plattformfunktion konstant android.hardware.touchscreen melden müssen auch die Plattformfunktion konstant android.hardware.faketouch . Geräteimplementierungen, die keinen Touchscreen enthalten (und nur auf ein Zeigergerät angewiesen sind), dürfen keine Touchscreen -Funktion melden und müssen nur android.hardware.faketouch melden, wenn sie die gefälschten Berührungsanforderungen in Abschnitt 7.2.5 erfüllen.

7.2.5. Gefälschte Berührungseingabe

Geräteimplementierungen, die die Unterstützung für android.hardware.faketouch deklarieren

Müssen die Absolute X- und Y -Bildschirmpositionen des Zeigerortes melden und einen visuellen Zeiger auf dem Bildschirm anzeigen [ Ressourcen, 80 ]
Muss Touch Event mit dem Aktionscode [ Ressourcen, 80 ] melden, der die Statusänderung angibt, die auf dem Zeiger auf dem Bildschirm nach down oder up dem Bildschirm auftritt [ Ressourcen, 80 ]
Muss den Zeiger auf einem Objekt auf dem Bildschirm down und up und auf dem Bildschirm unterstützen
Muss Zeiger down , den Zeiger, den Zeiger down up und dann innerhalb eines Zeitschwellenwerts an derselben Stelle auf einem Objekt auf dem Bildschirm auf den Bildschirm up , sodass Benutzer ein Objekt auf einem Objekt auf dem Bildschirm emulieren können [ Ressourcen, 80 ]
Muss den Zeiger down einen willkürlichen Punkt auf dem Bildschirm unterstützen, wechseln Zeiger zu einem anderen willkürlichen Punkt auf dem Bildschirm, gefolgt von einem up , mit dem Benutzer einen Berührungswiderstand emulieren können
Muss Zeiger down unterstützen und den Benutzern ermöglichen, das Objekt schnell in eine andere Position auf dem Bildschirm zu verschieben und dann auf dem Bildschirm up , sodass Benutzer ein Objekt auf den Bildschirm kleben können

Geräte, die die Unterstützung für android.hardware.faketouch.multitouch.distinct erfüllen müssen, müssen die Anforderungen für Faketouch oben erfüllen und auch eine unterschiedliche Verfolgung von zwei oder mehr unabhängigen Zeigereingaben unterstützen.

7.2.6. Mikrofon

Geräteimplementierungen können ein Mikrofon weglassen. Wenn eine Geräteimplementierung jedoch ein Mikrofon auslässt, darf sie nicht die Feature-Konstante android.hardware.microphone melden und die API von Audioaufzeichnungen als No-OPS gemäß Abschnitt 7 implementieren. Umgekehrt besitzen Geräteimplementierungen, die ein Mikrofon besitzen:

Muss die android.hardware.microphone -Funktionskonstante melden
Sollte die Anforderungen an die Audioqualität in Abschnitt 5.4 erfüllen
Sollte die Anforderungen an die Audiolatenz in Abschnitt 5.5 erfüllen

7.3. Sensoren

Android enthält APIs zum Zugriff auf eine Vielzahl von Sensortypen. Geräteimplementierungen können diese Sensoren im Allgemeinen weglassen, wie in den folgenden Unterabschnitten vorgesehen. Wenn ein Gerät einen bestimmten Sensortyp enthält, der über eine entsprechende API für Entwickler von Drittanbietern verfügt, muss die Geräteimplementierung diese API implementieren, wie in der Android-SDK-Dokumentation beschrieben. Zum Beispiel Geräteimplementierungen:

Muss genau das Vorhandensein oder Fehlen von Sensoren gemäß android.content.pm.PackageManager -Klasse melden. [ Ressourcen, 37 ]
Muss eine genaue Liste unterstützter Sensoren über den SensorManager.getSensorList() und ähnliche Methoden zurückgeben
Muss sich für alle anderen Sensor -APIs vernünftigerweise verhalten (zum Beispiel, indem sie wahr oder falsch zurückgeben, wenn Anwendungen versuchen, die Hörer zu registrieren, und nicht die Sensor -Hörer aufzurufen, wenn die entsprechenden Sensoren nicht vorhanden sind; usw.)
Muss alle Sensormessungen mit dem entsprechenden internationalen System der Einheiten (IE -Metrik) für jeden Sensortyp gemäß der Android SDK -Dokumentation melden [ Ressourcen, 41 ]

Die obige Liste ist nicht umfassend; Das dokumentierte Verhalten des Android SDK ist als maßgeblich angesehen zu werden.

Einige Sensortypen sind synthetisch, dh sie können aus Daten abgeleitet werden, die von einem oder mehreren anderen Sensoren bereitgestellt werden. (Beispiele sind der Orientierungssensor und der lineare Beschleunigungssensor.) Die Geräteimplementierungen sollten diese Sensortypen implementieren, wenn sie die Voraussetzungen für physikalische Sensoren enthalten.

Android enthält einen Begriff eines "Streaming" -Sensors, der Daten kontinuierlich und nicht nur dann zurückgibt, wenn sich die Daten ändert. Geräteimplementierungen müssen kontinuierlich periodische Datenproben für jede API liefern, die durch die Android -SDK -Dokumentation als Streaming -Sensor angegeben ist. Beachten Sie, dass die Geräteimplementierungen sicherstellen müssen, dass der Sensorstrom nicht verhindern darf, dass die CPU die Geräte -CPU in einen Suspendzustand eingeht oder aus einem Suspend -Status aufwacht.

7.3.1. Beschleunigungsmesser

Die Geräteimplementierungen sollten ein 3-Achsen-Beschleunigungsmesser enthalten. Wenn eine Geräteimplementierung ein 3-Achsen-Beschleunigungsmesser enthält, ist dies:

Sollte in der Lage sein, Veranstaltungen ab 120 Hz oder mehr zu liefern. Beachten Sie, dass die oben genannte Beschleunigungsmesserfrequenz für Android 4.4 als "sollte" angegeben ist, die Kompatibilitätsdefinition für eine zukünftige Version geplant ist, um diese in "Must" zu ändern. Das heißt, diese Standards sind in Android optional, werden jedoch in zukünftigen Versionen erforderlich sein . Bestehende und neue Geräte, die Android betreiben
Muss das Android -Sensorkoordinatensystem gemäß den Android -APIs entsprechen (siehe [ Ressourcen, 41 ])
Muss in der Lage sein, von Freefall bis zu zweimal Schwerkraft (2 g) oder mehr bei einem dreidimensionalen Vektor zu messen
Muss 8 Bit Genauigkeit oder mehr haben
Muss eine Standardabweichung von nicht mehr als 0,05 m/s^2 haben

7.3.2. Magnetometer

Die Geräteimplementierungen sollten ein 3-Achsen-Magnetometer (dh Kompass) enthalten. Wenn ein Gerät ein 3-Achsen-Magnetometer enthält, sollten Sie es enthalten.

Muss in der Lage sein, Ereignisse bei 10 Hz oder mehr zu liefern
Muss das Android -Sensorkoordinatensystem gemäß den Android -APIs entsprechen (siehe [ Ressourcen, 41 ]).
Muss in der Lage sein, eine Reihe von Feldstärken zu probieren, die für das geomagnetische Feld ausreichend sind
Muss 8 Bit Genauigkeit oder mehr haben
Muss eine Standardabweichung von nicht mehr als 0,5 µt haben

7.3.3. GPS

Die Geräteimplementierungen sollten einen GPS -Empfänger enthalten. Wenn eine Geräteimplementierung einen GPS-Empfänger enthält, sollte sie eine Form der "unterstützten GPS" -Technik enthalten, um die GPS-Sperrenzeit zu minimieren.

7.3.4. Gyroskop

Die Geräteimplementierungen sollten ein Gyroskop (dh Winkeländerungssensor) enthalten. Geräte sollten keinen Gyroskopsensor enthalten, es sei denn, es ist auch ein 3-Achsen-Beschleunigungsmesser enthalten. Wenn eine Geräteimplementierung ein Gyroskop enthält, ist dies:

Muss temperatur kompensiert sein.
Muss in der Lage sein, die Orientierungsänderungen zu messen, die bis zu 5,5*PI -Radians/Sekunde (dh ungefähr 1.000 Grad pro Sekunde).
Sollte in der Lage sein, Veranstaltungen zu 200 Hz oder mehr zu liefern. Beachten Sie, dass die obige Gyroskopfrequenz als "sollte" für Android 4.4 angegeben wird, die Kompatibilitätsdefinition für eine zukünftige Version geplant ist, um diese in "Must" zu ändern. Das heißt, diese Standards sind in Android optional, werden jedoch in zukünftigen Versionen erforderlich sein . Bestehende und neue Geräte, die Android betreiben, werden sehr stark ermutigt, diese Anforderungen zu erfüllen, damit sie auf die zukünftigen Plattform -Releases ein Upgrade durchführen können.
Muss 12 Bit Genauigkeit oder mehr haben
Muss eine Varianz von nicht mehr als 1E-7 rad^2 / s^2 pro Hz (Varianz pro Hz oder rad^2 / s) haben. Die Varianz kann mit der Stichprobenrate variieren, muss jedoch durch diesen Wert eingeschränkt werden. Mit anderen Worten, wenn Sie die Varianz des Gyro bei 1 Hz-Abtastrate messen, sollte es nicht mehr als 1E-7 rad^2/s^2 sein.
Muss Zeitstempel so nah wie möglich wie möglich haben. Die konstante Latenz muss entfernt werden.

7.3.5. Barometer

Die Geräteimplementierungen können ein Barometer (dh Umgebungsluftdrucksensor) umfassen. Wenn eine Geräteimplementierung ein Barometer enthält, ist es IT:

Muss in der Lage sein, Ereignisse bei 5 Hz oder mehr zu liefern
Muss eine ausreichende Genauigkeit haben, um die Schätzung der Höhe zu ermöglichen
Muss temperatur kompensiert sein

7.3.6. Thermometer

Die Geräteimplementierungen können ein Umgebungsthermometer (dh Temperatursensor) umfassen. Wenn vorhanden, muss es als SENSOR_TYPE_AMBIENT_TEMPERATURE definiert werden und muss die Umgebungstemperatur (Raum-) Temperatur in Grad Celsius messen.

Geräteimplementierungen können jedoch keinen CPU -Temperatursensor enthalten. Wenn vorhanden, muss es als SENSOR_TYPE_TEMPERATURE definiert werden, muss die Temperatur der CPU der Geräte messen und keine andere Temperatur messen. Beachten Sie, dass der Sensor SENSOR_TYPE_TEMPERATURE -Typ Sensor_Type_Temperature in Android 4.0 veraltet war.

7.3.7. Photometer

Geräteimplementierungen können ein Photometer (dh Umgebungslichtsensor) umfassen.

7.3.8. Näherungssensor

Die Geräteimplementierungen können einen Proximity -Sensor umfassen. Wenn eine Geräteimplementierung einen Näherungssensor enthält, muss sie die Nähe eines Objekts in die gleiche Richtung wie der Bildschirm messen. Das heißt, der Näherungssensor muss so ausgerichtet sein, dass Objekte in der Nähe des Bildschirms erfasst werden, da die primäre Absicht dieses Sensortyps darin besteht, ein vom Benutzer verwendetes Telefon zu erkennen. Wenn eine Geräteimplementierung einen Näherungssensor mit einer anderen Ausrichtung enthält, darf sie nicht über diese API zugänglich sein. Wenn eine Geräteimplementierung über einen Näherungssensor verfügt, muss sie 1-Bit Genauigkeit oder mehr haben.

7.4. Datenkonnektivität

7.4.1. Telefonie

"Telefonie", wie von den Android -APIs verwendet, und dieses Dokument bezieht sich speziell auf Hardware, die sich mit dem Platzieren von Sprachanrufen und dem Senden von SMS -Nachrichten über ein GSM- oder CDMA -Netzwerk beziehen. Diese Sprachanrufe können zwar paketanschlitzt werden oder auch nicht, aber sie stehen für die Zwecke von Android als unabhängig von einer Datenkonnektivität, die möglicherweise mit demselben Netzwerk implementiert werden kann. Mit anderen Worten, die Android "Telefonie" -Funktionalität und -APIs beziehen sich speziell auf Sprachanrufe und SMS. Beispielsweise dürfen Geräteimplementierungen, die keine Anrufe oder Senden/Empfangen von SMS-Nachrichten eingeben, die Funktion "Android.hardware.telephony" oder Unterfunktionen nicht melden, unabhängig davon, ob sie ein Mobilfunknetz für die Datenkonnektivität verwenden.

Android kann auf Geräten verwendet werden, die keine Telefonie -Hardware enthalten. Das heißt, Android ist mit Geräten kompatibel, die keine Telefone sind. Wenn jedoch eine Geräteimplementierung eine GSM- oder CDMA -Telefonie umfasst, muss sie die vollständige Unterstützung für die API für diese Technologie implementieren. Geräteimplementierungen, die keine Telefonie-Hardware enthalten, müssen die vollständigen APIs als No-OPS implementieren.

7.4.2. IEEE 802.11 (WLAN)

Die Implementierungen von Android -Geräten sollten die Unterstützung für eine oder mehrere Formulare von 802.11 (B/G/A/N usw.) enthalten, wenn eine Geräteimplementierung die Unterstützung für 802.11 enthält, die entsprechende Android -API implementieren muss.

Geräteimplementierungen müssen die Multicast -API implementieren, wie in der SDK -Dokumentation [ Ressourcen, 62 ] beschrieben. Geräteimplementierungen, die Wi-Fi-Unterstützung enthalten, müssen Multicast DNS (MDNS) unterstützen. Die Geräteimplementierungen dürfen MDNS -Pakete (224.0.0.251) zu einem Zeitpunkt des Betriebs nicht filtern, einschließlich der Zeit, in der sich der Bildschirm nicht in einem aktiven Zustand befindet.

7.4.2.1. Wi-Fi Direct

Die Geräteimplementierungen sollten die Unterstützung für Wi-Fi Direct (Wi-Fi Peer-to-Peer) beinhalten. Wenn eine Geräteimplementierung die Unterstützung von Wi-Fi Direct beinhaltet, muss die entsprechende Android-API wie in der SDK-Dokumentation beschrieben implementiert [ Ressourcen, 68 ]. Wenn eine Geräteimplementierung die Unterstützung für Wi-Fi Direct beinhaltet, dann: dann:

Muss den regulären Wi-Fi-Betrieb unterstützen
Sollte die gleichzeitige Direktoperation von Wi-Fi und Wi-Fi unterstützen

7.4.2.2. Einrichtung einer Wi-Fi-Tunnel-Direktverbindung

Die Geräteimplementierungen sollten die Unterstützung für das Wi-Fi-Tunneled Direct Link Setup (TDLS) enthalten, wie in der Android SDK-Dokumentation [ Ressourcen, 85 ] beschrieben. Wenn eine Geräteimplementierung die Unterstützung von TDLs und TDLs beinhaltet, wird die Wifimanager -API aktiviert, das Gerät:

Sollte TDLS nur dann verwenden, wenn es möglich und vorteilhaft ist.
Sollte eine heuristische und nicht tdls verwenden, wenn seine Leistung schlechter sein könnte, als den Wi-Fi-Zugangspunkt zu durchlaufen.

7.4.3. Bluetooth

Die Geräteimplementierungen sollten einen Bluetooth -Transceiver enthalten. Geräteimplementierungen, die einen Bluetooth-Transceiver enthalten, müssen die in der SDK-Dokumentation beschriebene RFCOMM-basierte Bluetooth-API aktivieren und die Hardware-Funktion Android.hardware.bluetooth [ Ressourcen, 42 ] deklarieren. Geräteimplementierungen sollten relevante Bluetooth -Profile implementieren, wie z. B. A2DP, AVRCP, OBEX usw. gegebenenfalls für das Gerät.

Geräteimplementierungen, die die Unterstützung für Bluetooth-GATT (Generic Attributprofil) für die Kommunikation mit Bluetooth Smart oder Smart Ready Devices enthalten, muss die in der SDK-Dokumentation beschriebene GATT-basierte Bluetooth-API aktivieren und die Hardware-Funktion Android.Hardware.BLUETOOTH_LE [ Ressourcen, Ressourcen, Ressourcen, Deklary Declare-Funktion, deklarieren. 42 ].

7.4.4. Nahfeldkommunikation

Die Geräteimplementierungen sollten einen Transceiver und eine verwandte Hardware für die Nahfeldkommunikation (NFC) enthalten. Wenn eine Geräteimplementierung NFC -Hardware enthält, dann: dann:

Muss die Funktion von Android.hardware.nfc bei der Methode android.content.pm.PackageManager.hasSystemFeature() melden. [ Ressourcen, 37 ]
Muss in der Lage sein, NDEF -Nachrichten über die folgenden NFC -Standards zu lesen und zu schreiben:
- Muss in der Lage sein, als NFC Forum Reader/Writer (wie vom NFC Forum Technical Specification NFCForum-TS-DigitalProtocol-1.0) zu fungieren sein.
  - NFCA (ISO14443-3a)
  - NFCB (ISO14443-3B)
  - NFCF (JIS 6319-4)
  - Isodep (ISO 14443-4)
  - NFC Forum Tag Typen 1, 2, 3, 4 (definiert durch das NFC -Forum)
Sollte in der Lage sein, NDEF -Nachrichten über die folgenden NFC -Standards zu lesen und zu schreiben. Beachten Sie, dass zwar die folgenden NFC -Standards als "sollte" angegeben sind, die Kompatibilitätsdefinition für eine zukünftige Version geplant ist, um diese in "Must" zu ändern. Das heißt, diese Standards sind in dieser Version optional, werden jedoch in zukünftigen Versionen erforderlich sein . Vorhandene und neue Geräte, die diese Version von Android ausführen, werden sehr stark ermutigt, diese Anforderungen jetzt zu erfüllen, damit sie auf die zukünftigen Plattform -Veröffentlichungen aufrüsten können.
- NFCV (ISO 15693)
Muss in der Lage sein, Daten über die folgenden Peer-to-Peer-Standards und -protokolle zu übertragen und zu empfangen:
- ISO 18092
- LLCP 1.0 (definiert vom NFC -Forum)
- SDP 1.0 (definiert vom NFC -Forum)
- Ndef Push Protocol [ Ressourcen, 43 ]
- Snep 1.0 (definiert vom NFC -Forum)
Muss die Unterstützung für Android Beam enthalten [ Ressourcen, 65 ]:
- Muss den Snep -Standardserver implementieren. Gültige NDEF -Nachrichten, die vom Standard -SNEP -Server empfangen werden, müssen mit der Intent von Android.nfc.Action_Ndef_Decovered an Anwendungen versandt werden. Das Deaktivieren von Android Beam in Einstellungen darf den Versand der eingehenden NDEF -Nachricht nicht deaktivieren.
- Die Geräteimplementierungen müssen die Android.Settings.nfcsharing_Setings -Absicht ehren, NFC -Sharing -Einstellungen anzuzeigen [ Ressourcen, 67 ].
- Muss den NPP -Server implementieren. Nachrichten, die vom NPP -Server empfangen werden, müssen auf die gleiche Weise wie der SNEP -Standardserver verarbeitet werden.
- Muss einen Snep -Client implementieren und versuchen, den ausgehenden P2P -NDEF an den Standard -Snep -Server zu senden, wenn Android Beam aktiviert ist. Wenn kein Standard -Snep -Server gefunden wird, muss der Client versuchen, an einen NPP -Server zu senden.
- Muss den Vordergrundaktivitäten die ausgehende P2P -NDEF -Nachricht mit Android.nfc.nfcadapter.setndefppushmessage und Android.nfc.nfcadapter.setndefppusMessageCallback und Android.nfc.nfcadapter.enableDeGroundndefpush.
- Sollte eine Geste oder eine auf dem Bildschirm bestehende Bestätigung wie "Berührung zum Strahl" verwenden, bevor Sie ausgehende P2P-NDEF-Nachrichten senden.
- Sollte Android Beam standardmäßig aktivieren
- Muss die NFC -Verbindung über die Übergabe von Bluetooth unterstützen, wenn das Gerät Bluetooth -Objekt -Push -Profil unterstützt. Geräteimplementierungen müssen die Verbindung über die Verbindung über Bluetooth bei der Verwendung von android.nfc.nfcadapter.setBeampushuris unterstützen, indem die "Verbindungsübergabe Version 1.2" [ Ressourcen, 60 ] und "Bluetooth -sichere einfache Paarung mit NFC Version 1.0" [ Ressourcen, 61 ] Spezifikationen aus von SPARING aus der einfachen Pairing aus implementiert werden. Das NFC -Forum. Eine solche Implementierung muss den Handover LLCP -Dienst mit dem Dienstnamen "Urn: NFC: SN: Sendung" zum Austausch der Übergabeanforderung/Auswahl von Datensätzen über NFC implementieren. Sie muss das Bluetooth -Objekt -Push -Profil für die tatsächliche Bluetooth -Datenübertragung verwenden. Aus den älteren Gründen (um mit Android 4.1 -Geräten kompatibel zu bleiben) sollte die Implementierung immer noch SNEP -Anfragen zum Austausch der Handover -Anforderung/Auswahl von Datensätzen über NFC akzeptieren. Eine Implementierung selbst sollte jedoch keine Snep -GEP -Anfragen zur Durchführung von Verbindungsübergabe senden.
Muss für alle unterstützten Technologien im NFC -Erkennungsmodus befragt.
Sollte im NFC-Erkennungsmodus sein, während das Gerät mit aktivem Bildschirm aktiv ist und der Sperrbildschirm entsperrt ist.

(Beachten Sie, dass öffentlich verfügbare Links für die oben genannten JIS-, ISO- und NFC -Forumspezifikationen nicht verfügbar sind.)

Android 4.4 führt Unterstützung für den HCE -Modus (NFC Host Card Emulation) ein. Wenn eine Geräteimplementierung einen NFC -Controller enthält, der mit HCE- und Anwendungs -ID (AID) -Louting in der Lage ist, dann:

Muss die Feature -Konstante android.hardware.nfc.hce melden
Muss NFC HCE -APIs wie im Android SDK definiert [ Ressourcen, 90 ]

Darüber hinaus können Geräteimplementierungen die Unterstützung von Leser/Schriftstellern für die folgenden Mifare -Technologien umfassen.

Mifare Classic (NXP MF1S503X [ Ressourcen, 44 ], MF1S703X [ Ressourcen, 45 ])
Mifare Ultralight (NXP MF0ICU1 [ Ressourcen, 46 ], MF0ICU2 [ Ressourcen, 47 ])
NDEF auf Mifare Classic (NXP AN130511 [ Ressourcen, 48 ], AN130411 [ Ressourcen, 49 ])

Beachten Sie, dass Android APIs für diese Mifare -Typen enthält. Wenn eine Geräteimplementierung MIFARE in der Rolle des Leser/Autors unterstützt, ist dies:

Muss die entsprechenden Android -APIs implementieren, wie sie vom Android SDK dokumentiert wurde
Muss die Funktion com.nxp.mifare von der methode android.content.pm.PackageManager.hasSystemFeature() melden. [ Ressourcen, 37 ] Beachten Sie, dass dies keine Standard -Android -Funktion ist und als solche nicht als Konstante in der PackageManager -Klasse erscheint.
Darf die entsprechenden Android -APIs weder implementieren noch die Funktion com.nxp.mifare melden, es sei denn

Wenn eine Geräteimplementierung keine NFC -Hardware enthält, darf sie die Funktion von Android.hardware.nfc nicht aus der android.content.pm.PackageManager.hasSystemFeature() -Methode [ Ressourcen, 37 ] deklarieren. No-op.

Da die Klassen android.nfc.NdefMessage und android.nfc.NdefRecord ein Protokoll-unabhängiger Datenrepräsentationsformat darstellen, müssen Geräteimplementierungen diese APIs auch dann implementieren, wenn sie keine Unterstützung für NFC enthalten oder die Feature von Android.hardware.nfc nicht deklarieren.

7.4.5. Minimale Netzwerkfähigkeit

Die Geräteimplementierungen müssen die Unterstützung für eine oder mehrere Formulare des Datennetzwerks enthalten. Insbesondere müssen Geräteimplementierungen die Unterstützung für mindestens einen Datenstandard von 200 kbit/s oder höher enthalten. Beispiele für Technologien, die diese Anforderung erfüllen, sind Edge, Hspa, EV-DO, 802.11g, Ethernet usw.

Geräteimplementierungen, bei denen ein physischer Netzwerkstandard (z. B. Ethernet) die primäre Datenverbindung ist, sollte auch die Unterstützung für mindestens einen gemeinsamen drahtlosen Datenstandard enthalten, z. B. 802.11 (Wi-Fi).

Geräte können mehr als eine Form der Datenkonnektivität implementieren.

7.4.6. Synchronisierungseinstellungen

Geräteimplementierungen müssen standardmäßig die Einstellung automatisch synchronisiert haben, damit die Methode getMasterSyncAutomatically() "true" zurückgibt [ Ressourcen, 88 ].

7.5. Kameras

Die Geräteimplementierungen sollten eine nach hinten gerichtete Kamera enthalten und eine vorne ausgerichtete Kamera enthalten. Eine nach hinten gerichtete Kamera ist eine Kamera an der Seite des Geräts gegenüber dem Display. Das heißt, es bildet wie eine herkömmliche Kamera Szenen auf der anderen Seite des Geräts. Eine vorne gerichtete Kamera ist eine Kamera auf derselben Seite des Geräts wie das Display. Das heißt, eine Kamera, die normalerweise verwendet wird, um den Benutzer vorzustellen, z. B. für Videokonferenzen und ähnliche Anwendungen.

7.5.1. Nach hinten gerichtete Kamera

Die Geräteimplementierungen sollten eine nach hinten gerichtete Kamera enthalten. Wenn eine Geräteimplementierung eine nach hinten gerichtete Kamera enthält, ist dies:

Muss eine Auflösung von mindestens 2 Megapixeln haben
Sollte entweder Hardware-automatisch-fokus oder im Kamera-Treiber implementierte Software-Autofokus (transparent für Anwendungssoftware) haben
Kann feste Fokus- oder EDOF-Hardware (erweiterte Feldtiefe) haben
Kann einen Blitz beinhalten. Wenn die Kamera einen Blitz enthält, darf die Blitzlampe FLASH_MODE_ON beleuchtet werden, während eine FLASH_MODE_AUTO -Instanz auf einer Kamera -Vorschau -Oberfläche registriert wurde, es sei denn Camera.Parameters Objekt. Beachten Sie, dass diese Einschränkung nicht für die integrierte Systemkamera-Anwendung des Geräts, sondern nur für Anwendungen von Drittanbietern mit Camera.PreviewCallback gelten.

7.5.2. Front-Kamera

Die Geräteimplementierungen können eine Frontkamera enthalten. Wenn eine Geräteimplementierung eine vorne gerichtete Kamera enthält, ist dies:

Muss eine Auflösung von mindestens VGA haben (dh 640x480 Pixel)
Darf keine vorne gerichtete Kamera als Standardeinstellung für die Kamera-API verwenden. Das heißt, die Kamera-API in Android bietet spezifische Unterstützung für Kameras vorne, und Geräteimplementierungen dürfen die API nicht so konfigurieren, dass sie eine Kamera vorne mit der vorne ausgerichteten Kamera behandelt, auch wenn sie die einzige Kamera auf der Gerät.
Kann Funktionen (z. B. Autofokus, Blitz usw.) enthalten, die nach hinten gerichteten Kameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.
Muss horizontal reflektieren (dh Spiegel) den von einer App in einem Camerapreview angezeigten Stream wie folgt:

Wenn die Geräteimplementierung vom Benutzer (z.
Wenn die aktuelle Anwendung ausdrücklich angefordert hat, dass die Kameraanzeige über einen Aufruf an die android.hardware.Camera.setDisplayOrientation() [ Ressourcen, 50 ] Methode gedreht wird, muss die Kameravorschau horizontal relativ zur von der Anwendung angegebenen Ausrichtung gespiegelt werden.
Andernfalls muss die Vorschau entlang der Standardhorizontalachse des Geräts spiegeln.

Muss das von der Postansicht angezeigte Bild auf die gleiche Weise wie der Vorschau -Image -Stream der Kamera angezeigt werden. (Wenn die Geräteimplementierung Postansicht nicht unterstützt, gilt diese Anforderung offensichtlich nicht.)
Darf nicht die endgültigen erfassten Standbilder- oder Video -Streams widerspiegeln, die an Anwendungsrufe zurückgegeben oder sich dem Medienspeicher verpflichtet haben

7.5.3. Verhalten der Kamera-API

Geräteimplementierungen müssen die folgenden Verhaltensweisen für die Kamera-bezogenen APIs sowohl für Front- als auch für die Rückverfolgungskameras implementieren:

Wenn eine Anwendung android.hardware.Camera.Parameters.setPreviewFormat(int) noch nie genannt wurde, muss das Gerät android.hardware.PixelFormat.YCbCr_420_SP für Vorschau -Daten verwenden, die für Anwendungsrückrufe bereitgestellt werden.
Wenn eine Anwendung eine android.hardware.Camera.PreviewCallback -Instanz und das System auf die onPreviewFrame() -Methode aufruft, wenn das Vorschau -Format YCBCR_420_SP ist, müssen die Daten im byte[] in das onPreviewFrame() müssen das NV21 -Codierungsformat weiter sein. Das heißt, Nv21 muss der Standard sein.
Geräteimplementierungen müssen das YV12-Format (wie durch die android.graphics.ImageFormat.YV12 konstant) für die Kamera-Vorschau sowohl für Front- als auch für nach hinten gerichtete Kameras unterstützen. (Der Hardware -Video -Encoder und die Kamera können ein beliebiges natives Pixelformat verwenden. Die Geräteimplementierung muss jedoch die Konvertierung in YV12 unterstützen.)

Geräteimplementierungen müssen die vollständige Kamera -API implementieren, die in der Android SDK -Dokumentation [ Ressourcen, 51 ]) enthalten ist, unabhängig davon, ob das Gerät Hardware -Autofokus oder andere Funktionen enthält. Beispielsweise müssen Kameras, denen Autofokus fehlt, noch alle registrierten android.hardware.Camera.AutoFocusCallback Instanzen anrufen (obwohl dies für eine Nicht-Autofocus-Kamera nicht relevant ist). Beachten Sie, dass dies für Kameras vorne geliefert wird. Obwohl die meisten Frontkameras den Autofokus nicht unterstützen, müssen die API-Rückrufe trotzdem wie beschrieben "gefälscht" werden.

Geräteimplementierungen müssen jeden Parameternamen erkennen und ehren, der als Konstante auf der Klasse android.hardware.Camera.Parameters definiert ist, wenn die zugrunde liegende Hardware die Funktion unterstützt. Wenn die Gerätehardware keine Funktion unterstützt, muss sich die API wie dokumentiert verhalten. Umgekehrt dürfen Geräteimplementierungen keine an die android.hardware.Camera.setParameters() -Methode übergebene String -Konstanten ehren oder anerkennen, die nicht als Konstanten auf der android.hardware.Camera.Parameters dokumentiert sind. Das heißt, Geräteimplementierungen müssen alle Standard -Kameraparameter unterstützen, wenn die Hardware zulässt, und dürfen keine benutzerdefinierten Kameraparametertypen unterstützen. Beispielsweise müssen Geräteimplementierungen, die Bildaufnahmen mithilfe der Bildgebungstechniken (High Dynamic Range) unterstützen , die Kamera Camera.SCENE_MODE_HDR unterstützen.

Geräteimplementierungen müssen die Camera.ACTION_NEW_PICTURE Intent Wenn ein neues Bild von der Kamera aufgenommen wird und der Eintrag des Bildes in den Medienspeicher hinzugefügt wurde.

Geräteimplementierungen müssen die Camera.ACTION_NEW_VIDEO Intent, wenn ein neues Video von der Kamera aufgezeichnet wird und der Eintrag des Bildes zum Medienspeicher hinzugefügt wurde.

7.5.4. Kameraausrichtung

Sowohl die Front- als auch die nach hinten gerichteten Kameras müssen, falls vorhanden, so ausgerichtet sein, dass die lange Dimension der Kamera mit der langen Dimension des Bildschirms übereinstimmt. Das heißt, wenn das Gerät in der Landschaftsorientierung gehalten wird, müssen Kameras Bilder in der Landschaftsausrichtung aufnehmen. Dies gilt unabhängig von der natürlichen Ausrichtung des Geräts. Das heißt, es gilt für Landschafts-Primary-Geräte sowie für Porträt-Primary-Geräte.

7.6. Erinnerung und Speicherung

7.6.1. Minimaler Arbeitsspeicher und Speicherplatz

Geräteimplementierungen müssen dem Kernel und dem Benutzerspeicher über mindestens 340 MB Speicher stehen. Der 340 MB muss zusätzlich zu jedem Speicher sein, der Hardwarekomponenten wie Radio, Video usw. gewidmet ist, und so steht dies nicht unter der Steuerung des Kernels.

Geräteimplementierungen mit weniger als 512 MB Speicher, die dem Kernel und dem Benutzerspeicher zur Verfügung stehen, müssen den Wert "True" für ActivityManager.isLowRamDevice() zurückgeben.

Die Geräteimplementierungen müssen für mindestens 1 GB nicht flüchtiger Speicher für private Anwendungsdaten zur Verfügung stehen. Das heißt, die /data Datenpartition muss mindestens 1 GB betragen. Geräteimplementierungen, die Android ausführen, werden sehr dringend empfohlen, mindestens 2 GB nichtflüchtigen Speicher für private Anwendungsdaten zu haben, damit sie auf die zukünftigen Plattform-Releases aufrüsten können.

Die Android -APIs enthalten einen Download -Manager, mit dem Anwendungen zum Herunterladen von Datendateien [ Ressourcen, 56 ] verwendet werden. Die Geräteimplementierung des Download -Managers muss in der Lage sein, einzelne Dateien von mindestens 100 MB in Größe "Cache" -Position "Cache" herunterzuladen.

7.6.2. Gemeinsamer externer Speicher

Geräteimplementierungen müssen gemeinsam genutztes Speicher für Anwendungen anbieten. Der freigegebene Speicher muss mindestens 1 GB groß sein.

Die Geräteimplementierungen müssen mit dem freigegebenen Speicher konfiguriert werden, der standardmäßig "aus der Box" montiert ist. Wenn der gemeinsam genutzte Speicher nicht auf dem Linux -Pfad /sdcard montiert ist, muss das Gerät eine symbolische Linux -Verbindung von /sdcard zum tatsächlichen Mountspunkt enthalten.

Geräteimplementierungen müssen als dokumentiert durch die android.permission.WRITE_EXTERNAL_STORAGE -Berechtigung für diesen gemeinsam genutzten Speicher. Der gemeinsame Speicher muss ansonsten von einer Anwendung beschreibbar sein, die diese Genehmigung erhält.

Geräteimplementierungen verfügen möglicherweise über Hardware für benutzergerechte abnehmbare Speicher, z. B. eine sichere digitale Karte. Alternativ können Geräteimplementierungen einen internen (nicht frequentierten) Speicher als gemeinsamer Speicher für Apps zuweisen. Das vorgelagerte Android Open Source -Projekt enthält eine Implementierung, bei der der interne Gerätespeicher für gemeinsame externe Speicher -APIs verwendet wird. Geräteimplementierungen sollten diese Konfiguration und Software -Implementierung verwenden.

Unabhängig von der Form des verwendeten Speicherspeichers müssen Geräteimplementierungen einen Mechanismus bereitstellen, um auf den Inhalt des gemeinsam genutzten Speichers von einem Host -Computer wie USB -Massenspeicher (UMS) oder Media Transfer Protocol (MTP) zugreifen zu können. Geräteimplementierungen verwenden möglicherweise USB -Massenspeicher, sollten jedoch Medienübertragungsprotokoll verwenden. Wenn die Geräteimplementierung Medienübertragungsprotokoll unterstützt:

Die Geräteimplementierung sollte mit dem Referenz Android MTP Host, Android -Dateiübertragung [ Ressourcen, 57 ] kompatibel sein.
Die Geräteimplementierung sollte eine USB -Geräteklasse von 0x00 melden.
Die Geräteimplementierung sollte einen USB -Schnittstellennamen von 'MTP' melden.

Wenn der Geräteimplementierung USB -Ports fehlen, muss sie einem Host -Computer auf andere Weise auf den Inhalt des gemeinsam genutzten Speichers wie ein Netzwerkdateisystem zugreifen.

Es ist veranschaulichend, zwei gemeinsame Beispiele zu berücksichtigen. Wenn eine Geräteimplementierung einen SD-Kartensteckplatz enthält, um die gemeinsam genutzten Speicheranforderungen zu erfüllen, muss eine fettformatierte SD-Karte 1 GB in Größe oder größer mit dem Gerät enthalten sein, wie sie an Benutzer verkauft werden, und standardmäßig montiert werden. Wenn eine Geräteimplementierung einen internen festen Speicher verwendet, um diese Anforderung zu erfüllen, muss dieser Speicher eine Größe von 1 GB oder größer sein und auf /sdcard montiert sein (oder /sdcard muss eine symbolische Verbindung zum physischen Ort sein, wenn sie an anderer Stelle montiert ist).

Geräteimplementierungen, die mehrere gemeinsam genutzte Speicherpfade (z. B. sowohl ein SD-Kartensteckplatz als auch der gemeinsame Speicher) enthalten, dürfen Android-Anwendungen nicht zulassen Inhalte aus beiden Speicherpfaden transparent über den Medienscanner -Service von Android und Android.Provider.Mediastore.

7.7. USB

Die Geräteimplementierungen sollten einen USB -Client -Port enthalten und einen USB -Host -Port enthalten.

Wenn eine Geräteimplementierung einen USB -Client -Port enthält:

Der Port muss mit einem USB-Host mit einem Standard-USB-A-Port verbunden sein
Der Port sollte den Micro -USB -Formfaktor auf der Geräteseite verwenden. Bestehende und neue Geräte, die Android betreiben
Der Hafen sollte in der Mitte einer Kante zentriert sein. Die Geräteimplementierungen sollten entweder den Port am unteren Rand des Geräts (gemäß der natürlichen Ausrichtung) suchen oder die Softwarebildschirmrotation für alle Apps (einschließlich Startbildschirm) aktivieren, damit das Display korrekt zeichnet, wenn das Gerät mit dem Port unten ausgerichtet ist. Bestehende und neue Geräte, die Androidare ausführen , ermutigten sehr stark, diese Anforderungen in Android zu erfüllen, damit sie auf zukünftige Plattform -Releases aufrüsten können.
Wenn das Gerät andere Ports (z. B. einen Nicht-USB-Ladeanschluss) verfügt
Es muss ein Host ermöglichen, der mit dem Gerät angeschlossen ist
Es muss die in der Android SDK -Dokumentation dokumentierte Android Open Accessoire API und Spezifikation implementiert und die Unterstützung für die Hardware -Funktion android.hardware.usb.accessory [ Ressourcen, 52 ] deklarieren.
Es muss die USB -Audioklasse implementieren, wie in der Android SDK -Dokumentation [ Ressourcen, 66 ] dokumentiert.
Es sollte die Unterstützung für USB -Akku -Ladespezifikation implementieren [ Ressourcen, 64 ] vorhandene und neue Geräte, die Android ausführen
Der Wert von iSerialNumber im USB -Standard -Gerätedeskriptor muss dem Wert von Android.os.build.serial entsprechen.

Wenn eine Geräteimplementierung einen USB -Host -Port enthält:

Es kann einen nicht standardmäßigen Portformfaktor verwenden. In diesem Fall muss dies jedoch mit einem Kabel oder Kabel versendet werden, die den Port an Standard USB-A anpassen
Es muss die in Android SDK dokumentierte Android -USB -Host -API implementiert und die Unterstützung für die Hardware -Funktion android.hardware.usb.host [ Ressourcen, 53 ] deklarieren.

Geräteimplementierungen müssen die Android -Debug -Brücke implementieren. Wenn eine Geräteimplementierung einen USB-Client-Port weglässt, muss die Android-Debug-Brücke über das lokale Netzwerk (wie Ethernet oder 802.11) implementiert werden.

8. Leistungskompatibilität

Geräteimplementierungen müssen die wichtigsten Leistungsmetriken eines Android-kompatiblen Geräts erfüllen, das in der folgenden Tabelle definiert ist:

Metrisch	Leistungsschwelle	Kommentare
Anwendungsstartzeit	Die folgenden Anwendungen sollten innerhalb der angegebenen Zeit auf den Markt kommen. Browser: weniger als 1300 ms Kontakte: weniger als 700 ms Einstellungen: weniger als 700 ms	Die Startzeit wird als Gesamtzeit für das Laden der Standardaktivität für die Anwendung gemessen, einschließlich der Zeit, die zum Starten des Linux -Vorgangs benötigt, das Android -Paket in die Dalvik -VM lädt und OnCreate anruft.
Gleichzeitige Anwendungen	Wenn mehrere Anwendungen gestartet wurden, muss die Neustart einer bereits laufenden Anwendung nach dem Start weniger als die ursprüngliche Startzeit dauern.

9. Kompatibilität des Sicherheitsmodells

Geräteimplementierungen müssen ein Sicherheitsmodell implementieren, das mit dem Sicherheitsmodell für Android -Plattform in Übereinstimmung in der Sicherheits- und Berechtigungsreferenzdokument in den APIs [ Ressourcen, 54 ] in der Android Developer -Dokumentation übereinstimmt. Geräteimplementierungen müssen die Installation selbstsignierter Anträge unterstützen, ohne zusätzliche Berechtigungen/Zertifikate von Dritten/Behörden zu erfordern. Insbesondere müssen kompatible Geräte die in den folgenden Unterabschnitten beschriebenen Sicherheitsmechanismen unterstützen.

9.1. Berechtigungen

Geräteimplementierungen müssen das in der Android Developer -Dokumentation definierte Android -Berechtigungsmodell [ Ressourcen, 54 ] unterstützen. Insbesondere müssen Implementierungen jede in der SDK -Dokumentation beschriebene Genehmigung durchsetzen. Keine Berechtigungen dürfen weggelassen, geändert oder ignoriert werden. Implementierungen können zusätzliche Berechtigungen hinzufügen, vorausgesetzt, die neuen Berechtigungs -ID -Zeichenfolgen befinden sich nicht im Android.* Namespace.

9.2. UID und Prozessisolation

Geräteimplementierungen müssen das Android Application Sandbox-Modell unterstützen, bei dem jede Anwendung als eindeutige UID im Unix-Stil und in einem separaten Prozess ausgeführt wird. Geräteimplementierungen müssen unterstützen, dass mehrere Anwendungen als die gleiche Linux -Benutzer -ID ausgeführt werden, sofern die Anwendungen ordnungsgemäß signiert und konstruiert werden, wie in der Referenz für Sicherheits- und Berechtigungen definiert [ Ressourcen, 54 ].

9.3. Dateisystemberechtigungen

Geräteimplementierungen müssen das Modell der Android -Dateizugriffsberechtigungen unterstützen, wie in der Referenz für Sicherheits- und Berechtigungen definiert [ Ressourcen, 54 ].

9.4. Alternative Ausführungsumgebungen

Die Geräteimplementierungen können Laufzeitumgebungen umfassen, die Anwendungen verwenden, die eine andere Software oder Technologie verwenden, als der virtuelle Dalvik -Maschine oder den nativen Code. Solche alternativen Ausführungsumgebungen dürfen jedoch nicht das Android -Sicherheitsmodell oder die Sicherheit installierter Android -Anwendungen beeinträchtigen, wie in diesem Abschnitt beschrieben.

Alternative Laufzeiten müssen selbst Android -Anwendungen sein und sich an das Standard -Android -Sicherheitsmodell halten, wie an anderer Stelle in Abschnitt 9 beschrieben.

Alternative Laufzeiten dürfen keinen Zugriff auf Ressourcen erhalten, die durch Berechtigungen geschützt sind, die in der AndroidManifest.xml-Datei der Laufzeit nicht über den Mechanismus <uses-permission> angefordert wurden.

Alternative Laufzeiten dürfen Anträge nicht erlauben, die von Android -Berechtigungen geschützten Funktionen zu nutzen, die auf Systemanwendungen beschränkt sind.

Alternative Laufzeiten müssen sich am Android Sandbox -Modell einhalten. Speziell:

Alternative Laufzeiten sollten Apps über den PackageManager in separate Android -Sandboxen installieren (dh Linux -Benutzer -IDs usw.)
Alternative Laufzeiten bieten möglicherweise eine einzelne Android -Sandbox, die von allen Anwendungen mithilfe der alternativen Laufzeit gemeinsam genutzt wird
Alternative Laufzeiten und installierte Anwendungen mit einer alternativen Laufzeit darf die Sandbox einer anderen auf dem Gerät installierten App nicht wiederverwenden, außer über die Standard -Android -Mechanismen der gemeinsam genutzten Benutzer -ID und des Signierzertifikats
Alternative Laufzeiten dürfen nicht mit den Sandkästen, die anderen Android -Anwendungen entsprechen

Alternative Laufzeiten dürfen nicht mit anderen Bewerbungen des Superuser (Root) oder einer anderen Benutzer -ID gestartet, gewährt oder gewährt werden.

Die .APK -Dateien alternativer Laufzeiten können in das Systembild einer Geräteimplementierung aufgenommen werden, müssen jedoch mit einem Schlüssel unterzeichnet werden, der sich von dem Schlüssel unterscheidet, mit dem andere Anwendungen, die in der Geräteimplementierung enthalten sind, verwendet werden.

Bei der Installation von Anwendungen müssen alternative Laufzeiten die Einwilligung der Benutzer für die von der Anwendung verwendeten Android -Berechtigungen einholen. Das heißt, wenn eine Anwendung eine Geräteressource nutzen muss, für die eine entsprechende Android -Berechtigung (z. B. Kamera, GPS usw.) vorliegt, muss die alternative Laufzeit den Benutzer darüber informieren, dass die Anwendung auf diese Ressource zugreifen kann . Wenn die Laufzeitumgebung auf diese Weise keine Anwendungsfunktionen aufzeichnet, muss in der Laufzeitumgebung alle Berechtigungen aufgeführt, die von der Laufzeit selbst bei der Installation einer Anwendung mit dieser Laufzeit eingerichtet werden.

9.5. Mehrbenutzerunterstützung

Android beinhaltet die Unterstützung mehrerer Benutzer und bietet Unterstützung für die vollständige Benutzerisolation [ Ressourcen, 70 ].

Geräteimplementierungen müssen diese Anforderungen im Zusammenhang mit der Unterstützung von Multi-User-Unterstützung erfüllen [ Ressourcen, 71 ]:

Da das Verhalten der Telefonie-APIs auf Geräten mit mehreren Benutzern derzeit nicht definiert ist, dürfen die Geräteimplementierungen, die Android.hardware deklarieren.
Geräteimplementierungen müssen für jeden Benutzer ein Sicherheitsmodell implementieren, das mit dem Sicherheitsmodell für Android -Plattform in Einklang steht, wie in Sicherheits- und Berechtigungsreferenzdokument in der APIs [Ressourcen, 54]
Android beinhaltet Unterstützung für eingeschränkte Profile, eine Funktion, mit der Geräteeigentümer zusätzliche Benutzer und deren Funktionen auf dem Gerät verwalten können. Mit eingeschränkten Profilen können Geräteeigentümer schnell separate Umgebungen einrichten, in denen zusätzliche Benutzer arbeiten können, um feinere Einschränkungen in den in diesen Umgebungen verfügbaren Apps zu verwalten. Geräteimplementierungen, die die Unterstützung mehrerer Benutzer enthalten, müssen Unterstützung für eingeschränkte Profile enthalten. Das vorgelagerte Android Open Source -Projekt enthält eine Implementierung, die diese Anforderung erfüllt.

Jede Benutzerinstanz auf einem Android -Gerät muss separate und isolierte externe Speicherverzeichnisse haben. Geräteimplementierungen können mehrere Benutzerdaten auf demselben Volumen oder Dateisystem speichern. Die Geräteimplementierung muss jedoch sicherstellen, dass Anwendungen, die im Besitz von einem bestimmten Benutzer im Besitz von und im Ausführen eines bestimmten Benutzers sind, nicht auflisten, lesen oder in Daten schreiben können, die einem anderen Benutzer gehören. Beachten Sie, dass abnehmbare Medien wie SD -Karten -Slots es einem Benutzer ermöglichen können, über einen Host -PC auf die Daten eines anderen zugreifen zu können. Aus diesem Grund müssen Geräteimplementierungen, die abnehmbare Medien für die externe Speicher-APIs verwenden, den Inhalt der SD-Karte verschlüsseln, wenn Multi-User aktiviert wird, indem ein Schlüssel verwendet wird, das nur auf nicht abfließbaren Medien gespeichert ist, die nur zum System zugänglich sind. Da dies die Medien durch einen Host -PC unlesbar macht, müssen Geräteimplementierungen zu MTP oder einem ähnlichen System umsteigen, um Host -PCs zu Zugriff auf die Daten des aktuellen Benutzers zu gewähren. Dementsprechend können Geräteimplementierungen Multi-Benutzer jedoch nicht aktivieren, wenn sie abnehmbare Medien [ Ressourcen, 72 ] für den primären externen Speicher verwenden.

9.6. Premium-SMS-Warnung

Android beinhaltet die Unterstützung für Warnnutzer für eine ausgehende Premium -SMS -Nachricht [ Ressourcen, 73 ]. Premium -SMS -Nachrichten sind Textnachrichten, die an einen bei einem Spediteur registrierten Dienst gesendet werden, der dem Benutzer möglicherweise eine Gebühr erhoben. Geräteimplementierungen, die die Unterstützung für android.hardware.telephony deklarieren. Telephony muss Benutzer warnen, bevor sie eine SMS -Nachricht an Zahlen senden, die durch reguläre Ausdrücke in /data/misc/sms/codes.xml im Gerät identifiziert wurden. Das vorgelagerte 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 (Security-verbesserte Linux) und andere Sicherheitsfunktionen im Linux-Kernel verwenden können. Selinux oder andere Sicherheitsfunktionen, falls sie unter dem Android -Framework implementiert sind:

Muss die Kompatibilität mit vorhandenen Anwendungen beibehalten
Darf keine sichtbare Benutzeroberfläche haben, auch wenn Verstöße erkannt werden
Sollte nicht Benutzer oder Entwickler konfigurierbar sein

Wenn eine API zur Konfiguration der Richtlinien einer Anwendung ausgesetzt ist, die eine andere Anwendung (z. B. eine API für Geräteadministration) beeinflussen kann, darf die API keine Konfigurationen zulassen, die die Kompatibilität brechen.

Geräte müssen SELinux implementieren und die folgenden Anforderungen erfüllen, die durch die Referenzimplementierung im vorgelagerten Android Open Source -Projekt erfüllt sind.

Es muss eine Selinux-Richtlinie unterstützen, mit der der Selinux-Modus pro Domänenbasis festgelegt werden kann, mit:

Domänen, die sich im Durchsetzungsmodus in der vorgelagerten Android Open Source -Implementierung (z. B. Installd, Netd und VOLD) befinden
Domänen (en) für Anwendungen von Drittanbietern sollten im zulässigen Modus bleiben, um eine kontinuierliche Kompatibilität zu gewährleisten

Es sollte Richtlinien aus /sepolicy -Datei auf dem Gerät geladen werden
Es muss dynamische Aktualisierungen der Selinux -Richtliniendatei unterstützen, ohne dass ein Systembildaktualisierung erforderlich ist
Es muss Verstöße gegen Richtlinien protokollieren, ohne Anwendungen zu brechen oder das Systemverhalten zu beeinflussen

Geräteimplementierungen sollten die Standard -Selinux -Richtlinie beibehalten, die im vorgelagerten Android Open Source -Projekt bereitgestellt werden, bis sie ihre Ergänzungen zur Selinux -Richtlinie erstmals geprüft haben. Geräteimplementierungen müssen mit dem vorgelagerten Android Open Source -Projekt kompatibel sein.

9.8. Privatsphäre

Wenn das Gerät Funktionalität im System implementiert, das den auf dem Bildschirm angezeigten Inhalt erfasst und/oder den auf dem Gerät gespielten Audiostrom aufzeichnet, muss der Benutzer kontinuierlich benachrichtigt werden, wenn diese Funktionalität aktiviert ist und aktiv erfasst/aufzeichnet.

9.9. Vollständige Festplattenverschlüsselung

Wenn das Gerät Schlosser hat, muss das Gerät die Verschlüsselung mit voller Scheiben unterstützen.

10. Softwarekompatibilitätstests

Geräteimplementierungen müssen alle in diesem Abschnitt beschriebenen Tests bestehen.

Beachten Sie jedoch, dass kein Software -Testpaket vollständig umfassend ist. Aus diesem Grund werden Geräteimplementierer sehr stark empfohlen, die minimale Anzahl von Änderungen wie möglich an der Referenz und der bevorzugten Implementierung von Android vor dem Android Open Source -Projekt vorzunehmen. Dies minimiert das Risiko, Fehler einzuführen, die Inkompatibilitäten erzeugen, die Nacharbeit und potenzielle Geräteaktualisierungen erfordern.

10.1. Kompatibilitätstestsuite

Die Geräteimplementierungen müssen die Android Compatibility Test Suite (CTS) [ Ressourcen, 2 ] über das Android Open Source -Projekt unter Verwendung der endgültigen Versandsoftware auf dem Gerät übergeben. Darüber hinaus sollten Geräteimplementierer die Referenzimplementierung im Android Open Source -Baum so weit wie möglich verwenden und die Kompatibilität bei Mehrdeutigkeiten in CTS und für alle Neuauflagen der Teile des Referenzquellencodes sicherstellen müssen.

Das CTS ist so konzipiert, dass sie auf einem tatsächlichen Gerät ausgeführt werden. Wie jede Software können die CTS selbst Fehler enthalten. Die CTS werden unabhängig von dieser Kompatibilitätsdefinition versioniert, und mehrere Überarbeitungen der CTS können für Android 4.4 veröffentlicht werden. Geräteimplementierungen müssen die neueste CTS -Version übergeben, die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbar ist.

10.2. CTS-Verifizierer

Die Geräteimplementierungen müssen alle anwendbaren Fälle im CTS -Verifizierer korrekt ausführen. Der CTS -Verifizierer ist in der Kompatibilitätstest Suite enthalten und soll von einem menschlichen Bediener ausgeführt werden, um die Funktionalität zu testen, die nicht von einem automatisierten System getestet werden kann, z. B. die korrekte Funktion von Kamera und Sensoren.

Der CTS -Verifizierer hat Tests für viele Arten von Hardware, einschließlich einer optionalen Hardware. Geräteimplementierungen müssen alle Tests für Hardware bestehen, die sie besitzen. Wenn beispielsweise ein Gerät über ein Beschleunigungsmesser besitzt, muss es den Beschleunigungsmesser -Testfall im CTS -Verifizierer korrekt ausführen. Testfälle für Funktionen, die in diesem Dokument für Kompatibilitätsdefinition als optional angegeben sind, können übersprungen oder weggelassen werden.

Jedes Gerät und jedes Build muss den CTS -Verifier, wie oben erwähnt, korrekt ausführen. Da jedoch viele Builds sehr ähnlich sind, wird nicht erwartet, dass Geräteimplementierer den CTS -Verifizierer explizit für Builds ausführen, die sich nur auf triviale Weise unterscheiden. Insbesondere können Geräteimplementierungen, die sich von einer Implementierung unterscheiden, die den CTS -Überprüfer nur durch die eingeschlossenen Orte, Branding usw. überschritten hat, den CTS -Verifier -Test auslassen.

10.3. Referenzanwendungen

Geräteimplementierer müssen die Kompatibilität der Implementierung unter Verwendung der folgenden Open Source -Anwendungen testen:

Die "Apps for Android" -Anwendungen [ Ressourcen, 55 ]
Replica Island (verfügbar im Google Play Store)

Jede obige App muss sich in der Implementierung korrekt starten und verhalten, damit die Implementierung als kompatibel angesehen werden kann.

11. Aktualisierbare Software

Die Geräteimplementierungen müssen einen Mechanismus enthalten, um die Gesamtheit der Systemsoftware zu ersetzen. Der Mechanismus muss keine "Live -Upgrades" durchführen - dh ein Neustart des Geräts erforderlich sein.

Jede Methode kann verwendet werden, sofern die gesamte auf dem Gerät vorinstallierte Software ersetzen kann. Beispielsweise erfüllt eine der folgenden Ansätze diese Anforderung:

Downloads von Op-the-Air (OTA) mit Offline-Update über Neustart
"Binded" Updates über USB von einem Host -PC
"Offline" -Andates über einen Neustart und Update aus einer Datei auf abnehmbarem Speicher

Der verwendete Aktualisierungsmechanismus muss Updates unterstützen, ohne Benutzerdaten abzulösen. Das heißt, der Aktualisierungsmechanismus muss die Anwendungsdaten und die gemeinsam genutzten Anwendungsdaten beibehalten. Beachten Sie, dass die vorgelagerte Android -Software einen Aktualisierungsmechanismus enthält, der diese Anforderung erfüllt.

Wenn in einer Geräteimplementierung nach seiner Veröffentlichung ein Fehler gefunden wird, jedoch innerhalb seiner angemessenen Produktlebensdauer, die in Absprache mit dem Android-Kompatibilitätsteam festgelegt wird, um die Kompatibilität von Anwendungen von Drittanbietern zu beeinflussen, muss der Geräteimplementierer den Fehler über eine Software korrigieren Aktualisieren verfügbar, die gemäß dem gerade beschriebenen Mechanismus angewendet werden können.

12. Dokumentänderungsprotokoll

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

Abschnitt(e)	Zusammenfassung des Wandels
3.2.2. Build-Parameter	Überarbeitete Beschreibungen von Marken, Gerät und Produkt. Eine Serie ist jetzt erforderlich.
3.2.3.5. Standard-App-Einstellungen	Neuer Abschnitt, der die Anforderung zur Einhaltung neuer Standard -Anwendungseinstellungen hinzufügt
3.3.1 Binäre Anwendungsschnittstellen	Klar zugelassenen Werten für die `android.os.Build.CPU_ABI` und `android.os.Build.CPU_ABI2` Parameter.
3.4.1. WebView-Kompatibilität	Es wurde Chromium nach der erforderlichen Webview -Implementierung hinzugefügt.
3.7. Kompatibilität virtueller Maschinen	Die Anforderung für XXHDPI- und 400DPI -Bildschirmdichten hinzugefügt.
3.8.6. Themen	Aktualisiert, um die Verwendung von durchscheinenden Systembalken widerzuspiegeln.
3.8.12. Standort	Neuer Abschnitt, der die Einstellungen für die Anforderungen an den Standort hinzufügt, sind zentralisiert.
3.8.13. Unicode	Neuer Abschnitt, der die Unterstützung von Emoji erhöht.
3.9. Geräteverwaltung	Bekanntes vorinstallierte Verwaltungsanwendungen können nicht die Standardanwendung für Geräteeigentümer sein.
5.1. Mediencodecs	Hinzufügen von VP9 -Decoderanforderungen. Empfohlene Spezifikation für Hardware -VP8 -Codecs hinzugefügt.
5.3. Videodekodierung	VP9 hinzugefügt. Empfehlung für die dynamische Auflösungsschaltung hinzugefügt.
5.4. Audio Aufnahme	`REMOTE_SUBMIX` als neue erforderliche Audioquelle hinzugefügt. Benutzte von `android.media.audiofx.NoiseSuppressor` api eine Anforderung.
6.2.1 Experimentell	Neuer Abschnitt, der die Kunstlaufzeit einführt und Dalvik als Standardlaufzeit erfordert.
7.1.1. Bildschirmkonfiguration	1,85 Seitenverhältnis durch 1,86 ersetzt. 400DPI -Bildschirmdichte hinzugefügt.
7.1.6. Bildschirmtypen	Zusätzliche Konfiguration von 640 DPI (4K) Auflösungen hinzugefügt.
7.2.3. Navigationstasten	Hinzugefügte die Funktion der Rezents als wesentlich; Herabgestuftes Menüfunktion in Priorität.
7.3.6. Thermometer	Sensor_type_ambient_temperature wie empfohlenes Thermometer hinzugefügt.
7.4.2.2. Einrichtung einer Wi-Fi-Tunnel-Direktverbindung	Neuer Abschnitt, der Unterstützung für das Wi-Fi-Tunneled Direct Link Setup (TDLS) ergänzt.
7.4.4. Nahfeldkommunikation	HISTE Emulation (HCE) als Anforderung hinzugefügt. Ersetzt Snep durch logische Verbindungssteuerungsprotokoll (LLCP) und fügte das Bluetooth -Objekt -Push -Profil als Anforderung hinzu.
7.4.6. Synchronisierungseinstellungen	Neuer Abschnitt, der die automatischen Synchronisierungsdaten hinzufügt, werden standardmäßig aktiviert.
7.6.1. Minimaler Arbeitsspeicher und Speicherplatz	`ActivityManager.isLowRamDevice()` . Erhöhte Speicheranforderungen von 512 MB und 1 GB auf 1 GB bzw. 2 GB.
7.6.2. Gemeinsamer "externer" Speicher	Editoriale Korrekturen wie Änderungen des Abschnittsnamens und bewegten Text, der in diesem Abschnitt aus Abschnitt 9.5 passt. Bekanntliche Anwendungen können in ihre paketspezifischen Verzeichnisse über den sekundären externen Speicher schreiben.
7.7. USB	Anforderungen hinzugefügt Alle Geräte melden eine USB -Seriennummer.
9.5. Mehrbenutzerunterstützung	Verschiebter nicht multi-Benutzer-spezifischer Text in Abschnitt 7.6.2.
9.7. Kernel-Sicherheitsfunktionen	Umgeschrieben, um den Selinux -Schalter in die Durchsetzung des Modus und die Anforderung zu beachten, wird die Selinux -Ausgabe in der Benutzeroberfläche nicht gerendert.
9.8. Privatsphäre	Der neue Abschnitt, der die Anforderungen Audio- und Videoaufzeichnung hinzufügt, muss dem Benutzer kontinuierliche Benachrichtigungen auslösen.
9.9. Vollständige Festplattenverschlüsselung	Neuer Abschnitt, der Anforderungen Geräte mit Schlosser-Bildschirm hinzufügt, unterstützt die Verschlüsselung in der vollständigen Disk.
12. Dokumentänderungsprotokoll	Neuer Abschnitt, der Änderungen in der CDD nach Abschnitt zusammenfasst.

13. Kontaktieren Sie uns

Sie können sich an die Dokumentautoren unter compatibilibility@android.com kontaktieren, um Klärungen zu erhalten, und um Probleme aufzurufen, von denen Sie glauben, dass das Dokument nicht behandelt wird.