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.2 entwickelt. Eine „Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte Hardware-/Softwarelösung.

Um als mit Android 4.2 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.2 zulässige Versionszeichenfolgen: http://source.android.com/docs/compatibility/4.2/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-Webdatenbank-API: http://www.w3.org/TR/webdatabase/

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/security.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

WLAN-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

Wifi Direct (Wifi 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

Viele dieser Ressourcen stammen direkt oder indirekt vom Android 4.2 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 4.2 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 10 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
android.os.Build.VERSION.RELEASE	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.
android.os.Build.VERSION.SDK	Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Anwendungscode von Drittanbietern zugreifen kann. Für Android 4.2 MUSS dieses Feld den ganzzahligen Wert 17 haben.
android.os.Build.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.2 MUSS dieses Feld den ganzzahligen Wert 17 haben.
android.os.Build.VERSION.INCREMENTAL	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.
android.os.Build.BOARD	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.
android.os.Build.BRAND	Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Unternehmens, der Organisation, der Person usw. identifiziert, die das Gerät hergestellt haben, in einem für Menschen lesbaren Format. Eine mögliche Verwendung dieses Feldes besteht darin, den OEM und/oder Netzbetreiber anzugeben, der das Gerät verkauft hat. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^[a-zA-Z0-9.,_-]+$"` übereinstimmen.
android.os.Build.CPU_ABI	Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3: Native API-Kompatibilität .
android.os.Build.CPU_ABI2	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3: Native API-Kompatibilität .
android.os.Build.DEVICE	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Konfiguration oder Revision des Gehäuses (manchmal auch „Industriedesign“ genannt) 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.
android.os.Build.FINGERPRINT	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/mydevice/generic:4.2/JRN53/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.
android.os.Build.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.
android.os.Build.HOST	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.
android.os.Build.ID	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.
android.os.Build.MANUFACTURER	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.
android.os.Build.MODEL	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.
android.os.Build.PRODUCT	Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des Produkts (SKU) enthält. 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.
android.os.Build.SERIAL	Eine Hardware-Seriennummer, falls verfügbar. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck `"^([a-zA-Z0-9]{0,20})$"` übereinstimmen.
android.os.Build.TAGS	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.
android.os.Build.TIME	Ein Wert, der den Zeitstempel des Buildvorgangs darstellt.
android.os.Build.TYPE	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.
android.os.Build.USER	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.2 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.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 android.os.Build.CPU_ABI -API genau melden
Es MÜSSEN nur die ABIs gemeldet werden, die in der neuesten Version des Android NDK in der Datei docs/CPU-ARCH-ABIS.txt dokumentiert sind
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)
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.

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 die WebKit-Rendering-Engine, um android.webkit.WebView zu implementieren. Da es nicht möglich ist, eine umfassende Testsuite für ein Web-Rendering-System zu entwickeln, MÜSSEN Geräteimplementierer den spezifischen Upstream-Build von WebKit in der WebView-Implementierung verwenden. Speziell:

Die android.webkit.WebView -Implementierungen der Geräteimplementierungen MÜSSEN auf dem 534.30 WebKit-Build aus dem Upstream-Android-Open-Source-Baum für Android 4.2 basieren. Dieser Build enthält einen bestimmten Satz an Funktionen und Sicherheitskorrekturen für WebView. Geräteimplementierer KÖNNEN Anpassungen an der WebKit-Implementierung vornehmen; Solche Anpassungen DÜRFEN jedoch das Verhalten des WebView, einschließlich des Rendering-Verhaltens, NICHT verändern.
Die von WebView gemeldete Benutzeragentenzeichenfolge MUSS in diesem Format vorliegen:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30
- Der Wert der Zeichenfolge $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE identisch sein
- Der Wert der Zeichenfolge $(LOCALE) SOLLTE den ISO-Konventionen für Ländercode und Sprache entsprechen und sich auf das aktuell konfigurierte Gebietsschema des Geräts beziehen
- 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
- Bei Geräteimplementierungen kann Mobile in der Benutzeragentenzeichenfolge weggelassen werden

Die WebView-Komponente SOLLTE so viel HTML5 [ Ressourcen, 11 ] wie möglich unterstützen. Geräteimplementierungen MÜSSEN mindestens jede dieser mit HTML5 in der WebView verknüpften 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.

HTML5-APIs MÜSSEN wie alle JavaScript-APIs standardmäßig in einer WebView deaktiviert sein, es sei denn, der Entwickler aktiviert sie explizit über die üblichen Android-APIs.

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 ]

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
xlarge	mdpi	32 MB
xlarge	tvdpi / hdpi	64 MB
xlarge	xhdpi	128 MB

3.8. Kompatibilität der Benutzeroberfläche

3.8.1. 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 ]. Die Android Open Source-Referenzversion enthält eine Launcher-Anwendung mit Benutzeroberflächenfunktionen, die es dem Benutzer ermöglichen, AppWidgets zum Startbildschirm hinzuzufügen, anzuzeigen und zu entfernen.

Geräteimplementierungen können eine Alternative zum Referenz-Launcher (z. B. Startbildschirm) ersetzen. Alternative Launcher SOLLTEN eine integrierte Unterstützung für AppWidgets beinhalten und die Möglichkeiten der Benutzeroberfläche offenlegen, um AppWidgets direkt im Launcher hinzuzufügen, zu konfigurieren, anzuzeigen und zu entfernen. Alternative Launcher können diese Elemente der Benutzeroberfläche weglassen; Wenn sie jedoch weggelassen werden, MUSS die Geräteimplementierung eine separate Anwendung bereitstellen, auf die über den Launcher zugegriffen werden kann und die es Benutzern ermöglicht, AppWidgets hinzuzufügen, zu konfigurieren, anzuzeigen und zu entfernen.

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

3.8.2. 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 4.2 bietet Unterstützung für umfangreiche Benachrichtigungen, beispielsweise 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.3. 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.4. 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.5. Themen

Android bietet „Themen“ als Mechanismus für Anwendungen, um Stile auf eine gesamte Aktivität oder Anwendung anzuwenden. Android 4.2 enthält ein „Holo“- oder „holographisches“ Design als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Erscheinungsbild des Holo-Designs wie im Android SDK definiert anpassen möchten [ Ressourcen, 24 ]. Geräteimplementierungen DÜRFEN KEINE der Holo-Designattribute ändern, die Anwendungen zur Verfügung gestellt werden [ Ressourcen, 25 ].

Android 4.2 enthält ein neues „Device Default“-Design 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 ].

3.8.6. 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.7. Aktuelle Anwendungsanzeige

Der Upstream-Quellcode von Android 4.2 enthält eine Benutzeroberfläche zum Anzeigen aktueller Anwendungen mithilfe einer Miniaturansicht des grafischen Zustands 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 neuere Anwendungen die Upstream-Benutzeroberfläche von Android 4.2 (oder eine ähnliche, auf Miniaturansichten basierende Benutzeroberfläche) zu verwenden, andernfalls sind sie möglicherweise nicht mit einer zukünftigen Version von Android kompatibel.

3.8.8. Eingabeverwaltungseinstellungen

Android 4.2 bietet Unterstützung für Input Management Engines. Mit den Android 4.2-APIs können benutzerdefinierte App-IMEs vom Benutzer einstellbare Einstellungen festlegen. Geräteimplementierungen MÜSSEN eine Möglichkeit für den Benutzer enthalten, jederzeit auf IME-Einstellungen zuzugreifen, wenn ein IME angezeigt wird, das solche Benutzereinstellungen bereitstellt.

3.8.9. Sperr- und Startbildschirm-Widgets

Android 4.2 bietet Unterstützung für Anwendungs-Widgets, die Benutzer in den Startbildschirm oder den Sperrbildschirm einbetten können (Einzelheiten finden Sie in den Designrichtlinien für App-Widgets in der Android SDK-Dokumentation [ Ressourcen, 69 ]). Anwendungs-Widgets ermöglichen den schnellen Zugriff auf Anwendungsdaten und -dienste, ohne eine neue Aktivität zu starten. Widgets erklären die Unterstützung für die Verwendung auf dem Startbildschirm oder dem Sperrbildschirm, indem sie das Manifest-Tag android:widgetCategory deklarieren, das dem System mitteilt, wo das Widget platziert werden kann. Insbesondere MÜSSEN Geräteimplementierungen die folgenden Anforderungen erfüllen.

Geräteimplementierungen MÜSSEN Anwendungs-Widgets auf dem Startbildschirm unterstützen.
Geräteimplementierungen SOLLTEN den Sperrbildschirm unterstützen. Wenn Geräteimplementierungen Unterstützung für den Sperrbildschirm beinhalten, MÜSSEN Geräteimplementierungen Anwendungs-Widgets auf dem Sperrbildschirm unterstützen.

3.8.10. Sperrbildschirm-Medienfernbedienung

Android 4.2 bietet Unterstützung für die Remote Control API, mit der Medienanwendungen in Wiedergabesteuerungen integriert werden können, die in einer Remote-Ansicht wie dem Gerätesperrbildschirm angezeigt werden [ Ressourcen, 74 ]. Geräteimplementierungen MÜSSEN die Einbettung von Fernbedienungen in den Gerätesperrbildschirm unterstützen.

3.8.11. Träume

Android 4.2 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.9 Geräteverwaltung

Android 4.2 enthält Funktionen, die es sicherheitsbewussten Anwendungen ermöglichen, Geräteverwaltungsfunktionen auf Systemebene auszuführen, z. B. die Durchsetzung von Kennwortrichtlinien oder die Durchführung einer Remote-Löschung, über die Android Device Administration API [ Ressourcen, 27 ]. Geräteimplementierungen MÜSSEN eine Implementierung der DevicePolicyManager Klasse [ Ressourcen, 28 ] bereitstellen und SOLLTEN den gesamten Bereich der in der Android SDK-Dokumentation definierten Geräteverwaltungsrichtlinien unterstützen [ Ressourcen, 27 ].

Hinweis: Während einige der oben beschriebenen Anforderungen für Android 4.2 als „SOLLTEN“ angegeben sind, MÜSSEN Geräteimplementierungen, die den Sperrbildschirm unterstützen, Geräterichtlinien zum Verwalten von Widgets auf dem Sperrbildschirm unterstützen, wie in der Android SDK-Dokumentation [ Ressourcen, 27 ] definiert.

Hinweis: Während einige der oben genannten Anforderungen für Android 4.2 als „SOLLTEN“ angegeben sind, 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.2 optional, werden aber in einer zukünftigen Version erforderlich sein . Bestehenden und neuen Geräten, auf denen Android 4.2 läuft, wird dringend empfohlen, diese Anforderungen in Android 4.2 zu erfüllen , da sie sonst bei einem Upgrade auf die zukünftige Version nicht die Android-Kompatibilität erreichen können.

3.10 Barrierefreiheit

Android 4.2 bietet eine Barrierefreiheitsebene, die Benutzern mit Behinderungen die Navigation auf ihren Geräten erleichtert. Darüber hinaus bietet Android 4.2 Plattform-APIs, die es Implementierungen von Barrierefreiheitsdiensten ermöglichen, Rückrufe für Benutzer- und Systemereignisse zu empfangen und alternative Feedbackmechanismen 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-to-Speech

Android 4.2 enthält 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 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 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 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 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 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 2.3.3+)		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.

5.2 Videokodierung

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

	SD (Geringe Qualität)	SD (Hohe Qualität)	HD (sofern von der Hardware unterstützt)
Video-Codec	H.264-Basisprofil	H.264-Basisprofil	H.264-Basisprofil
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

5.3 Videodekodierung

Android-Geräteimplementierungen SOLLTEN die folgenden VP8-Videodekodierungsprofile 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.

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 Echtzeiteffekte wie Soundeffekte oder VOIP-Kommunikation 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 Entwicklertools

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 4.2.2 bietet Unterstützung für Secure ADB. Secure ADB aktiviert ADB auf bekannten authentifizierten Hosts. Bestehenden und neuen Geräten, auf denen Android 4.2.2 ausgeführt wird, wird dringend empfohlen, diese Anforderung in Android 4.2 zu erfüllen , da sie sonst bei einem Upgrade auf die zukünftige Version nicht die Android-Kompatibilität erreichen können.

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 im Standard-Android-SDK bereitgestellt, 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 4.2 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.

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 4.2 umfasst 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 gemäß der Android SDK -Dokumentation [ Ressourcen, 38 ] melden und von der vorgelagerten Android -Plattform ermittelt werden. Insbesondere müssen Geräteimplementierungen die korrekte Bildschirmgröße gemäß den folgenden logischen dichteunabhängigen Pixel-Bildschirmabmessungen (DP) melden.

Geräte müssen Bildschirmgrößen von mindestens 426 dp x 320 dp haben ('klein')
Geräte, die die Bildschirmgröße 'Normal' melden
Geräte, die die Bildschirmgröße 'groß' melden, müssen Bildschirmgrößen von mindestens 640 dp x 480 dp haben
Geräte, die die Bildschirmgröße 'Xlarge' melden, müssen Bildschirmgrößen von mindestens 960 dp x 720 dp haben

Darüber hinaus müssen Geräte Bildschirmgrößen von mindestens 2,5 Zoll in physikalischer diagonaler Größe haben.

Geräte dürfen ihre gemeldete Bildschirmgröße zu keinem Zeitpunkt ändern.

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

Bildschirmseitenverhältnis

Das Seitenverhältnis muss zwischen 1,3333 (4: 3) und 1,85 (16: 9) liegen.

Bildschirmdichte

Das Android UI Framework definiert eine Reihe von logischen Standarddichten, um Anwendungsentwickler bei den Anwendungsressourcen zu unterstützen. Geräteimplementierungen müssen eine der folgenden logischen Android -Framework -Dichten über die APIs android.util.DisplayMetrics melden und müssen Anwendungen bei 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"
480 dpi, bekannt als "xxhdpi"

Geräteimplementierungen sollten die Standard -Android -Framework -Dichte definieren, die der physikalischen Dichte des Bildschirms numerisch am nächsten ist, es sei denn, diese logische Dichte drückt die gemeldete Bildschirmgröße unter den unterstützten Minimum. Wenn die Standard -Android -Framework -Dichte, die der physikalischen Dichte numerisch am nächsten ist, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 DP -Breite) ist, sollten die Geräteimplementierungen die nächstniedrigste Android -Framework -Dichte der Android -Framework angeben.

7.1.2. Messwerte anzeigen

Geräteimplementierungen müssen korrekte Werte für alle in android.util.DisplayMetrics [ Ressourcen, 39 ] definierten Anzeigenmetriken melden.

7.1.3. Bildschirmausrichtung

Geräte müssen die dynamische Orientierung durch Anwendungen entweder auf Porträt- oder Landschaftsbildschirmorientierung unterstützen. Das heißt, das Gerät muss die Anfrage der Anwendung nach einer bestimmten Bildschirmausrichtung respektieren. Geräteimplementierungen können entweder eine Porträt- oder Landschaftsorientierung als Standardeinstellung auswählen.

Geräte müssen den richtigen Wert für die aktuelle Ausrichtung des Geräts melden, wenn er über die Android.content.res.configuration.orientation, android.view.Display.Getorientation () oder andere APIs abgefragt wird.

Geräte dürfen beim Ändern der Orientierung die gemeldete Bildschirmgröße oder -dichte nicht ändern.

Geräte müssen melden, welche Bildschirmorientierungen sie unterstützen ( android.hardware.screen.portrait und/oder android.hardware.screen.landscape ) und müssen mindestens eine unterstützte Orientierung melden. Beispielsweise darf ein Gerät mit einem festen Landschaftsbildschirm wie einem Fernseher oder Laptop nur android.hardware.screen.landscape melden.

7.1.4. 2D- und 3D-Grafikbeschleunigung

Die Geräteimplementierungen müssen sowohl OpenGL ES 1.0 als auch 2.0 unterstützen, wie in den Android SDK -Dokumentationen enthalten und detailliert beschrieben. Geräteimplementierungen müssen auch Android Renderscript unterstützen, wie in der Android SDK -Dokumentation [ Ressourcen, 8 ] aufgeführt.

Geräteimplementierungen müssen sich auch als die Unterstützung von OpenGL ES 1.0 und 2.0 korrekt identifizieren. Das ist:

Die verwaltete APIs GLES10.getString() z.
Die nativen C/C ++ OpenGL -APIs (dh diejenigen, die Apps über libgles_v1cm.so, libgles_v2. oder libegl.so) zur Verfügung stellen müssen, müssen die Unterstützung für OpenGL ES 1.0 und 2.0 melden.

Geräteimplementierungen können alle gewünschten OpenGLE -Erweiterungen implementieren. Geräteimplementierungen müssen jedoch über die OpenGLE -verwalteten und nativen APIs alle Erweiterungsketten, die sie unterstützen, melden, und müssen umgekehrt keine Erweiterungsketten melden, die sie nicht unterstützen.

Beachten Sie, dass Android 4.2 die Unterstützung von Anwendungen enthält, um optional anzugeben, dass sie spezifische OpenGL -Textur -Komprimierungsformate benötigen. Diese Formate sind typischerweise vendorspezifisch. Geräteimplementierungen sind von Android 4.2 nicht erforderlich, um ein bestimmtes Texturkomprimierungsformat zu implementieren. Sie sollten jedoch über die getString() -Methode in der OpenGL -API genau die Texturkomprimierungsformate melden, die sie unterstützen.

Android 4.2 enthält einen Mechanismus für Anwendungen, um zu erklären, dass sie die Hardwarebeschleunigung für 2D -Grafiken in der Anwendung, Aktivität, Fenster oder Ansicht durch die Verwendung eines Manifest -Tag android:hardwareAccelerated oder Direct -API -Aufrufe [ Ressourcen, 9 ] ermöglichen.

In Android 4.2 müssen die Geräteimplementierungen die Hardwarebeschleunigung standardmäßig ermöglichen und die Hardwarebeschleunigung deaktivieren, wenn der Entwickler SO -Anforderungen android:hardwareAccelerated="false" oder die Deaktivierung der Hardware -Beschleunigung direkt über die Android View -APIs.

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

Android 4.2 enthält ein TextureView Objekt, mit dem Entwickler hardware-bewertete Opengles-Texturen direkt als Rendern von Zielen in eine UI-Hierarchie integrieren können. Geräteimplementierungen müssen die TextureView -API unterstützen und mit der vorgelagerten Android -Implementierung konsistentes Verhalten aufweisen.

7.1.5. Kompatibilitätsmodus für ältere Anwendungen

Android 4.2 gibt einen "Kompatibilitätsmodus" an, in dem das Framework in einem "normalen" Bildschirmgröße äquivalente (320DP-Breite) arbeitet, zum Nutzen von Legacy-Anwendungen, die nicht für alte Android-Versionen entwickelt wurden, die die Unabhängigkeit der Bildschirmgröße vor der Bildschirmgröße haben. Die Geräteimplementierungen müssen die Unterstützung für den Kompatibilitätsmodus für Legacy -Anwendungen beinhalten, wie vom vorgelagerten Android Open Source -Code implementiert. Das heißt, Geräteimplementierungen dürfen die Auslöser oder Schwellenwerte, an denen der Kompatibilitätsmodus aktiviert ist, nicht ändern und dürfen das Verhalten des Kompatibilitätsmodus selbst nicht ändern.

7.1.6. Bildschirmtypen

Geräteimplementierungsbildschirme werden als einer von zwei Typen eingestuft:

Implementierungen mit fester Pixelanzeige: Der Bildschirm ist ein einzelnes Panel, das nur eine einzelne Pixelbreite und Höhe unterstützt. In der Regel ist der Bildschirm physikalisch in das Gerät integriert. Beispiele sind Mobiltelefone, Tablets usw.
Implementierungen der Variablen-Pixel-Anzeige: Die Geräteimplementierung verfügt entweder über keinen eingebetteten Bildschirm und enthält einen Videoausgabebestand wie VGA, HDMI oder einen drahtlosen Anschluss für die Anzeige oder verfügt über einen eingebetteten Bildschirm, mit dem die Pixelabmessungen geändert werden können. Beispiele sind Fernseher, Set-Top-Boxen usw.

Implementierungen des Geräts mit fester Pixel

Implementierungen mit fester Pixel-Geräte können Bildschirme in allen Pixeldimensionen verwenden, sofern sie den definierten Anforderungen dieser Kompatibilitätsdefinition erfüllen.

Implementierungen mit festen Pixeln können einen Videoausgangsport für die Verwendung mit einer externen Anzeige enthalten. Wenn diese Anzeige jedoch jemals zum Ausführen von Apps verwendet wird, muss das Gerät die folgenden Anforderungen erfüllen:

Das Gerät muss dieselbe Bildschirmkonfiguration und die in den Abschnitten 7.1.1 und 7.1.2 beschriebenen Metriken wie die Anzeige fester Pixel melden.
Das Gerät muss die gleiche logische Dichte wie die Festpixelanzeige melden.
Das Gerät muss Bildschirmabmessungen melden, die mit der Anzeige mit festem Pixel die gleichen oder sehr nahe bei der Festpixel entsprechen.

Beispielsweise wird ein Tablet mit einer 7-Zoll-diagonale Größe mit einer Auflösung von 1024 x 600 Pixel als Implementierung mit festem Pixel angesehen. Wenn es einen Videoausgangsport enthält, der bei 720p oder 1080p anzeigt Anwendungen werden nur in einem großen MDPI-Fenster ausgeführt, unabhängig davon, ob die Anzeige- oder Videoausgangsanschluss mit festem Pixel verwendet wird.

Implementierungen für Variable-Pixel-Geräte

Implementierungen von Variable-Pixel-Geräten müssen eine oder beide von 1280x720 oder 1920x1080 (dh 720p oder 1080p) unterstützen. Geräteimplementierungen mit Variablen-Pixel-Anzeigen dürfen keine andere Bildschirmkonfiguration oder -modus unterstützen. Geräteimplementierungen mit variablen Pixelbildschirmen können zur Laufzeit oder zum Startzeit die Bildschirmkonfiguration oder -modus ändern. Beispielsweise kann ein Benutzer eines Set-Top-Box eine 720p-Anzeige durch eine 1080p-Anzeige ersetzen, und die Geräteimplementierung kann sich entsprechend anpassen.

Darüber hinaus müssen die Implementierungen von Variable-Pixel-Geräten die folgenden Konfigurationsschalen für diese Pixel-Dimensionen melden:

1280x720 (auch bekannt als 720p): 'Large' Bildschirmgröße, 'TVDPI' (213 DPI) Dichte
1920x1080 (auch bekannt als 1080p): 'große' Bildschirmgröße, 'xhdpi' (320 dpi) Dichte

Für Klarheit sind Geräteimplementierungen mit variablen Pixelabmessungen auf 720p oder 1080p in Android 4.2 beschränkt und müssen so konfiguriert werden, dass die Bildschirmgröße und die Dichtekleber wie oben angegeben melden.

7.1.7. Bildschirmtechnologie

Die Android -Plattform enthält APIs, mit denen Anwendungen reichhaltige Grafiken für die Anzeige übertragen werden können. Geräte müssen alle diese APIs im Sinne des Android SDK unterstützen, sofern in diesem Dokument nicht ausdrücklich zulässig ist. Speziell:

Geräte müssen Anzeigen unterstützen, die 16-Bit-Farbgrafiken rendern können, und sollten Anzeigen unterstützen, die mit 24-Bit-Farbgrafiken in der Lage sind.
Geräte müssen Anzeigen unterstützen, die Animationen rendern können.
Die verwendete Display -Technologie muss ein Pixel -Seitenverhältnis (PAR) zwischen 0,9 und 1,1 haben. Das heißt, das Pixel -Seitenverhältnis muss mit einer Toleranz von 10% in der Nähe von Quadrat (1,0) sein.

7.1.8. Externe Displays

Android 4.2 beinhaltet die Unterstützung für das Sekundärdisplay, um die Medienfreigabefunktionen und Entwickler -APIs für den Zugriff auf externe Displays zu ermöglichen. Wenn ein Gerät eine externe Anzeige entweder über eine verdrahtete, drahtlose oder eine eingebettete zusätzliche Anzeigeverbindung unterstützt, muss die Geräteimplementierung die in der Android -SDK -Dokumentation beschriebene Anzeige -Manager -API implementieren [ Ressourcen, 75 ]. Geräteimplementierungen, die sichere Videoausgaben unterstützen und sichere Oberflächen unterstützen können, müssen die Unterstützung für Display.SECURE_FLAG deklarieren. Insbesondere müssen Geräteimplementierungen, die die Unterstützung für Display.SECURE_FLAG deklarieren, HDCP 2.x oder höher für Miracast -Wireless -Displays oder HDCP 1.2 oder höher für kabelgebundene Anzeigen unterstützen. Die vorgelagerte Android Open Source -Implementierung beinhaltet die Unterstützung für drahtlose (Miracast) und Wired -Displays (HDMI), die diese Anforderung erfüllen.

7.2. Eingabegeräte

7.2.1. Tastatur

Geräteimplementierungen:

Muss die Unterstützung für das Input -Management -Framework (mit dem Drittanbieter -Entwickler es ermöglichen, Input -Management -Engines zu erstellen - dh Soft -Tastatur) unter http://developer.android.com detailliert beschrieben
Muss mindestens eine Implementierung von Soft -Tastaturen liefern (unabhängig davon, ob eine harte Tastatur vorhanden ist)
Kann zusätzliche Implementierungen für Softtastaturen enthalten
Kann eine Hardware -Tastatur beinhalten
Ich darf keine Hardware-Tastatur enthalten, die nicht mit einem der in android.content.res.Configuration.keyboard angegebenen Formate übereinstimmt.

Geräteimplementierungen:

Kann eine Nicht-Touch-Navigationsoption weglassen (dh kann ein Trackball, ein D-Pad oder ein Rad weglassen).
Muss den korrekten Wert für android.content.res.Configuration.navigation [ Ressourcen, 40 ] melden.
Muss einen angemessenen alternativen Benutzeroberflächenmechanismus für die Auswahl und Bearbeitung von Text bereitstellen, die mit Engine -Management -Motoren kompatibel sind. Die vorgelagerte Android Open-Source-Implementierung enthält einen Auswahlmechanismus, der für die Verwendung mit Geräten geeignet ist, denen keine Navigationseingänge ohne Berührung haben.

Das Heim-, Menü- und Rückfunktionen sind für das Android -Navigationsparadigma von wesentlicher Bedeutung. Geräteimplementierungen müssen diese Funktionen dem Benutzer jederzeit zur Verfügung stellen, wenn sie Anwendungen ausführen. Diese Funktionen können über dedizierte physische Schaltflächen (z. B. mechanische oder kapazitive Touch -Schaltflächen) implementiert werden oder können mit dedizierten Softwaretasten, Gesten, Touch Panel usw. implementiert werden. Android 4.2 unterstützt beide Implementierungen.

Android 4.2 beinhaltet Unterstützung für Assist -Aktionen [ Ressourcen, 63 ]. Geräteimplementierungen müssen die Assist -Aktion dem Benutzer jederzeit beim Ausführen von Anwendungen zur Verfügung stellen. Diese Funktion kann über Hardware- oder Softwareschlüssel implementiert werden.

Geräteimplementierungen können einen bestimmten Teil des Bildschirms verwenden, um die Navigationsschlüssel anzuzeigen. In diesem Fall muss jedoch diese Anforderungen erfüllen:

Die Navigationsschlüssel der Geräteimplementierung müssen einen bestimmten Teil des Bildschirms verwenden, der nicht für Anwendungen verfügbar ist, und dürfen den Teil des Bildschirms, der den Anwendungen zur Verfügung steht, nicht verkleinern oder auf andere Weise beeinträchtigen.
Geräteimplementierungen müssen einen Teil des Displays für Anwendungen zur Verfügung stellen, die den in Abschnitt 7.1.1 definierten Anforderungen erfüllen.
Geräteimplementierungen müssen die Navigationsschlüssel anzeigen, wenn Anwendungen keinen System -UI -Modus angeben, oder SYSTEM_UI_FLAG_VISIBLE angeben.
Die Geräteimplementierungen müssen die Navigationsschlüssel in einem unauffälligen "Low -Profile" -Modus (z. B. herzgetrieben) vorstellen, wenn Anwendungen SYSTEM_UI_FLAG_LOW_PROFILE angeben.
Geräteimplementierungen müssen die Navigationsschlüssel ausblenden, wenn Anwendungen SYSTEM_UI_FLAG_HIDE_NAVIGATION angeben.
Die Geräteimplementierung muss einen Menüschlüssel für Anwendungen vorlegen, wenn TargetsDkversion <= 10 einen Menüschlüssel darstellen sollte, wenn die Zieledkversion> 10.

7.2.4. Touchscreen-Eingabe

Geräteimplementierungen:

Muss ein Zeigereingangssystem irgendeiner Art haben (entweder mausähnlich oder berühren)
Kann einen Touchscreen jeglicher Modalität haben (wie kapazitiv oder resistiv)
Sollte unabhängig voneinander verfolgte Zeiger unterstützen, wenn ein Touchscreen mehrere Zeiger unterstützt
Muss den Wert von android.content.res.Configuration [ Ressourcen, 39 ] melden, die dem Typ des spezifischen Touchscreen auf dem Gerät entsprechend entsprechen

Geräteimplementierungen müssen die korrekte Funktion melden, die dem verwendeten Eingangstyp entspricht. Beachten Sie, dass Android 4.2 die Funktion android.hardware.faketouch enthält, die einem Eingabegerät mit hohem Fidelity-Nicht-Touch (dh Zeigerbasiert) entspricht, wie z. Gestenunterstützung) und zeigt an, dass das Gerät eine emulierte Teilmenge der Touchscreen -Funktionalität unterstützt. Geräteimplementierungen mit einem Touchscreen (Single-Touch oder besser) müssen auch Android.hardware.faketouch melden. 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.

7.2.5. 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 4.2 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.

Der Android 4.2 enthält einen Begriff eines "Streaming" -Sensors, der Daten kontinuierlich zurückgibt, und nicht nur, wenn sich die Daten ändert. Geräteimplementierungen müssen kontinuierlich periodische Datenproben für jede API liefern, die durch die Android 4.2 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.2 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 4.2 optional, werden jedoch in zukünftigen Versionen erforderlich sein . Bestehende und neue Geräte, die Android 4.2 ausführen
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 -Radianer/Sekunde (dh ungefähr 1.000 Grad pro Sekunde) messen können (ca. 1.000 Grad)
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.2 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 4.2 optional, werden jedoch in zukünftigen Versionen erforderlich sein . Bestehende und neue Geräte, die Android 4.2 ausführen
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.7. Thermometer

Geräteimplementierungen können jedoch kein Thermometer (dh Temperatursensor) enthalten. Wenn eine Geräteimplementierung ein Thermometer umfasst, muss die Temperatur der Geräte -CPU messen. Es darf keine andere Temperatur messen. (Beachten Sie, dass dieser Sensortyp in den Android 4.2 -APIs veraltet ist.)

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 4.2 -APIs verwendet, und dieses Dokument bezieht sich speziell auf Hardware, die sich auf das Platten von Sprachanrufen und das Senden von SMS -Nachrichten über ein GSM- oder CDMA -Netzwerk beziehen. Diese Sprachanrufe können zwar paketanschlitzt werden oder auch nicht, sie dienen zwar für die Zwecke von Android 4.2 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 4.2 kann auf Geräten verwendet werden, die keine Telefonie -Hardware enthalten. Das heißt, Android 4.2 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)

Android 4.2 -Geräteimplementierungen 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 den WLAN -Support 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 von WLAN Direct (WLAN-Peer-to-Peer) beinhalten. Wenn eine Geräteimplementierung die Unterstützung von WLI Direct enthält, muss die entsprechende Android -API wie in der SDK -Dokumentation beschrieben implementiert [ Ressourcen, 68 ]. Wenn eine Geräteimplementierung die Unterstützung von WLAN Direct beinhaltet, dann: dann:

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

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 [ Ressourcen, 42 ] beschriebene RFCOMM-basierte Bluetooth-API aktivieren. Geräteimplementierungen sollten relevante Bluetooth -Profile implementieren, wie z. B. A2DP, AVRCP, OBEX usw. gegebenenfalls für das Gerät.

Die Kompatibilitätstestsuite umfasst Fälle, die den grundlegenden Betrieb der Android RFCOMM Bluetooth -API abdecken. Da Bluetooth jedoch ein Kommunikationsprotokoll zwischen Geräten ist, kann es nicht vollständig durch Unit -Tests getestet werden, die auf einem einzigen Gerät ausgeführt werden. Infolgedessen müssen Geräteimplementierungen auch das in Anhang A beschriebene von Menschen angetriebene Bluetooth-Testverfahren bestehen.

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 die folgenden NFC -Standards zwar als "sollte" für Android 4.2 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 Android 4.2 optional, werden jedoch in zukünftigen Versionen erforderlich sein . Bestehende und neue Geräte, die Android 4.2 ausführen, werden sehr stark ermutigt, diese Anforderungen in Android 4.2 zu erfüllen, damit sie auf die zukünftigen Plattform -Releases 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 sollte Snep -GET -Anforderungen zum Austausch der Handover -Anforderung / Auswählen von Datensätzen über NFC verwenden und das Bluetooth -Objekt -Push -Profil für die tatsächliche Bluetooth -Datenübertragung verwenden.
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.)

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, 44 ])
Mifare Ultralight (NXP MF0ICU1 [ Ressourcen, 46 ], MF0ICU2 [ Ressourcen, 46 ])
NDEF auf Mifare Classic (NXP AN130511 [ Ressourcen, 48 ], AN130411 [ Ressourcen, 49 ])

Beachten Sie, dass Android 4.2 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() deklarieren. ein 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 (WLAN).

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

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 4.2 bietet eine spezielle Unterstützung für Kameras vorne, und Geräteimplementierungen dürfen die API nicht so konfigurieren, dass eine Kamera vorne als vorne als standardmäßige Kamera nach hinten gerichtet ist, auch wenn sie die einzige Kamera auf ist das 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 4.2 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.

Die Geräteimplementierungen müssen mindestens 350 MB nicht flüchtiger Speicher für Anwendungsdaten zur Verfügung stehen. Das heißt, die /data muss mindestens 350 MB betragen.

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 Anwendungsspeicher

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.

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 internationale Speicher) enthalten, sollten die Kernanwendungen wie den Medienscanner und ContentProvider ändern, um die an beiden Standorten platzierten Dateien zu unterstützen.

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 4.2 ausführen
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 Android 4.2 ausführen, werden sehr stark ermutigt, diese Anforderungen in Android 4.2 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 4.2 ausführen

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 in der folgenden Tabelle definierten Android 4.2 -kompatiblen Geräts erfüllen:

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 wie definiert in der Referenz für Sicherheits- und Berechtigungen [ Ressourcen, 54 ] unterstützen.

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:

Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

9.5. Mehrbenutzerunterstützung

Android 4.2 includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

Device implementations MUST meet these requirements related to multi-user support[ Resources, 71 ]:

As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]

Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage. The upstream Android open-source project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation. Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage

9.6. Premium-SMS-Warnung

Android 4.2 includes support for warning users for any outgoing premium SMS message. Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android open-source project provides an implementation that satisfies this requirement.

10. Softwarekompatibilitätstests

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 4.2 available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. Kompatibilitätstestsuite

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

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. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.2. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

10.2. CTS-Verifizierer

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3. Referenzanwendungen

Device implementers MUST test implementation compatibility using the following open source applications:

The "Apps for Android" applications [ Resources, 55 ]
Replica Island (available in Android Market)

Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

11. Aktualisierbare Software

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

Over-the-air (OTA) downloads with offline update via reboot
"Tethered" updates over USB from a host PC
"Offline" updates via a reboot and update from a file on removable storage

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

12. Kontaktieren Sie uns

You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

Anhang A – Bluetooth-Testverfahren

Die Kompatibilitätstestsuite umfasst Fälle, die den grundlegenden Betrieb der Android RFCOMM Bluetooth -API abdecken. Da Bluetooth jedoch ein Kommunikationsprotokoll zwischen Geräten ist, kann es nicht vollständig durch Unit -Tests getestet werden, die auf einem einzigen Gerät ausgeführt werden. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

The test procedure is based on the BluetoothChat sample app included in the Android open source project tree. The procedure requires two devices:

a candidate device implementation running the software build to be tested
a separate device implementation already known to be compatible, and of a model from the device implementation being tested - that is, a "known good" device implementation

The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

Setup and Installation

Build BluetoothChat.apk via 'make samples' from an Android source code tree
Install BluetoothChat.apk on the known-good device
Install BluetoothChat.apk on the candidate device

Test Bluetooth Control by Apps

Launch BluetoothChat on the candidate device, while Bluetooth is disabled
Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth

Test Pairing and Communication

Launch the Bluetooth Chat app on both devices
Make the known-good device discoverable from within BluetoothChat (using the Menu)
On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device
Send 10 or more messages from each device, and verify that the other device receives them correctly
Close the BluetoothChat app on both devices by pressing Home
Unpair each device from the other, using the device Settings app

Test Pairing and Communication in the Reverse Direction

Launch the Bluetooth Chat app on both devices.
Make the candidate device discoverable from within BluetoothChat (using the Menu).
On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
Send 10 or messages from each device, and verify that the other device receives them correctly.
Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

Test Re-Launches

Re-launch the Bluetooth Chat app on both devices.
Send 10 or messages from each device, and verify that the other device receives them correctly.

Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.