Kompatibilitätsdefinition für Android 4.2

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Version 2
Zuletzt aktualisiert: 17. Februar 2013

Copyright © 2012 Google Inc. Alle Rechte vorbehalten.
compatibility@android.com

Inhaltsverzeichnis

1. Einführung

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

Die Verwendung von „muss“, „darf nicht“, „erforderlich“, „wird“, „wird nicht“, „sollte“, „sollte nicht“, „empfohlen“, „kann“ und „optional“ erfolgt gemäß dem IETF-Standard, der in RFC2119 [Ressourcen, 1] definiert ist.

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

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

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

Aus diesem Grund ist das Open-Source-Projekt von Android [Ressourcen, 3] sowohl die Referenz- als auch die bevorzugte Implementierung von Android. Geräteimplementierer sollten ihre Implementierungen nach Möglichkeit auf dem „Upstream“-Quellcode basieren, der im Android Open Source Project verfügbar ist. Einige Komponenten können zwar theoretisch durch alternative Implementierungen ersetzt werden, dies wird jedoch dringend abgeraten, da das Bestehen der Softwaretests dadurch erheblich erschwert wird. Der Implementierer ist dafür verantwortlich, dass die Verhaltenskompatibilität mit der Standard-Android-Implementierung vollständig gegeben ist, einschließlich und über die Compatibility Test Suite hinaus. Bestimmte Komponentenersetzungen und ‑änderungen sind gemäß diesem Dokument ausdrücklich untersagt.

2. Ressourcen

1. IETF-Anforderungen gemäß RFC 2119: http://www.ietf.org/rfc/rfc2119.txt
2. Android-Kompatibilitätsprogramm – Übersicht: http://source.android.com/docs/compatibility/index.html
3. Open-Source-Projekt von Android: http://source.android.com/
4. API-Definitionen und ‑Dokumentation: http://developer.android.com/reference/packages.html
5. Referenz zu Android-Berechtigungen: http://developer.android.com/reference/android/Manifest.permission.html
6. Referenz zu android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Zulässige Versionsstrings für Android 4.2: http://source.android.com/docs/compatibility/4.2/versions.html
8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
9. Hardwarebeschleunigung: http://developer.android.com/guide/topics/graphics/hardware-accel.html
10. Klasse „android.webkit.WebView“: http://developer.android.com/reference/android/webkit/WebView.html
11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12. Offlinefunktionen von HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13. HTML5-Video-Tag: http://dev.w3.org/html5/spec/Overview.html#video
14. HTML5/W3C Geolocation API: http://www.w3.org/TR/geolocation-API/
15. HTML5/W3C Webdatabase API: http://www.w3.org/TR/webdatabase/
16. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17. Spezifikation der Dalvik-Virtuellen Maschine: im Android-Quellcode unter dalvik/docs verfügbar
18. App-Widgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19. Benachrichtigungen: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20. Anwendungsressourcen: http://code.google.com/android/reference/available-resources.html
21. Styleguide für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
23. Toasts: http://developer.android.com/reference/android/widget/Toast.html
24. Themen: http://developer.android.com/guide/topics/ui/themes.html
25. Klasse „R.style“: http://developer.android.com/reference/android/R.style.html
26. Live-Hintergründe: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
27. Android-Geräteverwaltung: http://developer.android.com/guide/topics/admin/device-admin.html
28. DevicePolicyManager-Referenz: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29. APIs für Android-Bedienungshilfen: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
30. Android Accessibility APIs: http://developer.android.com/reference/android/view/accessibility/package-summary.html
31. Eyes Free-Projekt: http://code.google.com/p/eyes-free
32. Text-to-Speech APIs: http://developer.android.com/reference/android/speech/tts/package-summary.html
33. Referenzdokumentation zu Tools (für adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html
34. Beschreibung von Android-APK-Dateien: http://developer.android.com/guide/topics/fundamentals.html
35. Manifestdateien: http://developer.android.com/guide/topics/manifest/manifest-intro.html
36. Monkey-Testtool: https://developer.android.com/studio/test/other-testing-tools/monkey
37. Android-Klasse „android.content.pm.PackageManager“ und Liste der Hardwarefunktionen: http://developer.android.com/reference/android/content/pm/PackageManager.html
38. Unterstützung mehrerer Bildschirme: http://developer.android.com/guide/practices/screens_support.html
39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
42. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
43. NDEF-Push-Protokoll: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
50. Camera Orientation API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51. Kamera: http://developer.android.com/reference/android/hardware/Camera.html
52. Android Open Accessories: http://developer.android.com/guide/topics/usb/accessory.html
53. USB Host API: http://developer.android.com/guide/topics/usb/host.html
54. Referenz zu Sicherheit und Berechtigungen unter Android: http://developer.android.com/guide/topics/security/security.html
55. Apps für Android: http://code.google.com/p/apps-for-android
56. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html
57. Android File Transfer: http://www.android.com/filetransfer
58. Android-Medienformate: http://developer.android.com/guide/appendix/media-formats.html
59. HTTP Live Streaming-Entwurfsprotokoll: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
60. NFC-Übergabe der Verbindung: http://www.nfc-forum.org/specs/spec_list/#conn_handover
61. Bluetooth Secure Simple Pairing Using NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62. Wifi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
63. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64. USB-Lade-Spezifikation: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66. Android USB Audio: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67. NFC-Freigabeeinstellungen unter Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68. Wifi Direct (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69. Sperr- und Startbildschirm-Widget: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
70. UserManager-Referenz: http://developer.android.com/reference/android/os/UserManager.html
71. Referenz zum externen Speicher: https://source.android.com/docs/core/storage
72. APIs für externen Speicher: http://developer.android.com/reference/android/os/Environment.html
73. SMS-Kurzcode: http://de.wikipedia.org/wiki/Kurzcode
74. Media Remote Control Client: http://developer.android.com/reference/android/media/RemoteControlClient.html
75. Displaymanager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
76. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html
77. Einstellungen für die Android-App-Entwicklung: 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 aus dem Android 4.2 SDK und sind funktional mit den Informationen in der Dokumentation dieses SDK identisch. In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstestsuite nicht mit der SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als verbindlich. Alle technischen Details in den oben genannten Referenzen gelten als Teil dieser Kompatibilitätsdefinition.

3. Software

3.1. Kompatibilität mit verwalteten APIs

Die verwaltete (Dalvik-basierte) Ausführungsumgebung ist das primäre Mittel für Android-Anwendungen. Die Android API (Application Programming Interface) ist die Gruppe von Android-Plattformschnittstellen, die für Anwendungen verfügbar sind, die in der verwalteten VM-Umgebung ausgeführt werden. Geräteimplementierungen MÜSSEN vollständige Implementierungen aller dokumentierten APIs bereitstellen, die vom Android 4.2 SDK bereitgestellt werden, einschließlich aller dokumentierten Verhaltensweisen [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 ausdrücklich in dieser Kompatibilitätsdefinition erlaubt.

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

3.2 Soft API Compatibility

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

3.2.1. Berechtigungen

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

3.2.2. Parameter erstellen

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

Parameter	Kommentare
android.os.Build.VERSION.RELEASE	Die Version des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format. Dieses Feld MUSS einen der Stringwerte haben, die in [Ressourcen, 7] definiert sind.
android.os.Build.VERSION.SDK	Die Version des aktuell ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 4.2 MUSS dieses Feld den Ganzzahlwert 17 haben.
android.os.Build.VERSION.SDK_INT	Die Version des aktuell ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist. Für Android 4.2 MUSS dieses Feld den Ganzzahlwert 17 haben.
android.os.Build.VERSION.INCREMENTAL	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Version des derzeit ausgeführten Android-Systems in einem visuell lesbaren Format angibt. Dieser Wert darf NICHT für verschiedene Builds wiederverwendet werden, die Endnutzern zur Verfügung gestellt werden. Dieses Feld wird in der Regel verwendet, um anzugeben, welche Build-Nummer oder Änderungs-ID der Quellkontrollversion zum Generieren des Builds verwendet wurde. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String („"") sein.
android.os.Build.BOARD	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Hardware des Geräts in einem visuell lesbaren Format angibt. Dieses Feld kann beispielsweise verwendet werden, um die spezifische Version des Boards anzugeben, das das Gerät mit Strom versorgt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" entsprechen.
android.os.Build.BRAND	Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Unternehmens, der Organisation, der Person usw. angibt, die das Gerät hergestellt hat, in einem visuell lesbaren Format. Dieses Feld kann beispielsweise verwendet werden, um den OEM und/oder Mobilfunkanbieter anzugeben, der das Gerät verkauft hat. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" entsprechen.
android.os.Build.CPU_ABI	Der Name des Instruction Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3: Kompatibilität mit nativen APIs.
android.os.Build.CPU_ABI2	Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Weitere Informationen finden Sie unter Abschnitt 3.3: Kompatibilität mit nativen APIs.
android.os.Build.DEVICE	Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Konfiguration oder Version des Gehäuses (manchmal auch „Industriedesign“ genannt) des Geräts angibt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
android.os.Build.FINGERPRINT	Ein String, der diesen Build eindeutig identifiziert. Sie sollte für Menschen gut lesbar sein. Er MUSS dieser Vorlage folgen: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Beispiel: acme/mydevice/generic:4.2/JRN53/3359:userdebug/test-keys Der Fingerabdruck darf KEINE Leerzeichen enthalten. Wenn andere Felder in der Vorlage oben Leerzeichen enthalten, MÜSSEN diese im Build-Fingerabdruck durch ein anderes Zeichen ersetzt werden, z. B. durch den Unterstrich („_“). Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein.
android.os.Build.HARDWARE	Der Name der Hardware (aus der Kernel-Befehlszeile oder /proc). Sie sollte in einem für Menschen lesbaren Format vorliegen. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
android.os.Build.HOST	Ein String, der den Host, auf dem der Build erstellt wurde, eindeutig in einem für Menschen lesbaren Format identifiziert. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String („"") sein.
android.os.Build.ID	Eine vom Geräteimplementierer ausgewählte Kennung für eine bestimmte Version in einem für Menschen lesbaren Format. Dieses Feld kann mit „android.os.Build.VERSION.INCREMENTAL“ identisch sein, sollte aber einen aussagekräftigen Wert haben, damit Endnutzer Software-Builds unterscheiden können. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" entsprechen.
android.os.Build.MANUFACTURER	Der Handelsname des Erstausrüsters (Original Equipment Manufacturer, OEM) des Produkts. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
android.os.Build.MODEL	Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endnutzer bekannt ist. Dies sollte derselbe Name sein, unter dem das Gerät vermarktet und an Endnutzer verkauft wird. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
android.os.Build.PRODUCT	Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des Produkts (SKU) enthält. MÜSSEN menschenlesbar sein, sind aber nicht unbedingt für Endnutzer bestimmt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" entsprechen.
android.os.Build.SERIAL	Eine Hardware-Seriennummer, falls verfügbar. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck "^([a-zA-Z0-9]{0,20})$" entsprechen.
android.os.Build.TAGS	Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt werden und die das Build weiter unterscheiden. Beispiel: „unsigned,debug“. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" entsprechen.
android.os.Build.TIME	Ein Wert, der den Zeitstempel des Builds angibt.
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 gängigen Android-Laufzeitkonfigurationen entsprechen: „user“, „userdebug“ oder „eng“. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" entsprechen.
android.os.Build.USER	Ein Name oder eine Nutzer-ID des Nutzers (oder automatisierten Nutzers), der den Build generiert hat. Es gibt keine Anforderungen an das spezifische Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.

3.2.3. Intent-Kompatibilität

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

3.2.3.1. Wichtige Anwendungsabsichten

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

Alle diese alternativen Versionen MÜSSEN jedoch dieselben Intent-Muster einhalten, die vom Upstream-Projekt bereitgestellt werden. Wenn ein Gerät beispielsweise einen alternativen Musikplayer enthält, muss es trotzdem das Intent-Muster von Drittanbieter-Apps einhalten, um einen Titel auszuwählen.

Die folgenden Anwendungen gelten als Android-Systemanwendungen:

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

Die wichtigsten Android-Systemanwendungen umfassen verschiedene Aktivitäts- oder Dienstkomponenten, die als „öffentlich“ gelten. Das Attribut „android:exported“ kann also fehlen oder den Wert „true“ haben.

Für jede Aktivität oder jeden Dienst, der in einer der wichtigsten Android-System-Apps definiert ist und nicht über das Attribut „android:exported“ mit dem Wert „false“ als nicht öffentlich gekennzeichnet ist, MÜSSEN Geräteimplementierungen eine Komponente desselben Typs enthalten, die dieselben Intent-Filtermuster wie die Haupt-Android-System-App implementiert.

Mit anderen Worten: Eine Geräteimplementierung DARF Android-System-Kern-Apps ersetzen. In diesem Fall MUSS die Geräteimplementierung jedoch alle Intent-Muster unterstützen, die von den ersetzten Android-System-Kern-Apps definiert wurden.

3.2.3.2. Intent-Überschreibungen

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

Geräteimplementierungen KÖNNEN jedoch Standardaktivitäten für bestimmte URI-Muster (z. B. http://play.google.com) bereitstellen, wenn die Standardaktivität einen genaueren Filter für die Daten-URI bietet. Ein Intent-Filter, der die Daten-URI „http://www.android.com“ angibt, ist beispielsweise spezifischer als der Browserfilter für „http://“. Geräteimplementierungen MÜSSEN eine Benutzeroberfläche bereitstellen, über die Nutzer die Standardaktivität für Intents ändern können.

3.2.3.3. Intent-Namespaces

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

Dieses Verbot entspricht dem für Java-Sprachklassen in Abschnitt 3.6.

3.2.3.4. Broadcast-Intents

Drittanbieteranwendungen sind auf die Plattform angewiesen, um bestimmte Intents zu senden, um sie über Änderungen in der Hardware- oder Softwareumgebung zu informieren. Android-kompatible Geräte MÜSSEN die öffentlichen Intents für die Übertragung in Reaktion auf entsprechende Systemereignisse senden. Broadcast-Intents werden in der SDK-Dokumentation beschrieben.

3.3 Kompatibilität mit nativen APIs

3.3.1 Binärschnittstellen

Verwalteter Code, der in Dalvik ausgeführt wird, kann nativen Code aufrufen, der in der .apk-Datei der Anwendung als ELF-.so-Datei bereitgestellt wird, die für die entsprechende Gerätehardwarearchitektur kompiliert wurde. Da nativer Code stark von der zugrunde liegenden Prozessortechnologie abhängt, definiert Android im Android NDK in der Datei docs/CPU-ARCH-ABIS.html eine Reihe von Application Binary Interfaces (ABIs). Wenn eine Geräteimplementierung mit einer oder mehreren definierten ABIs kompatibel ist, sollte sie wie unten beschrieben mit dem Android NDK kompatibel sein.

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

• MÜSSEN Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code mithilfe der Standard-Java Native Interface (JNI)-Semantik aufzurufen.
• MÜSSEN mit jeder erforderlichen Bibliothek in der folgenden Liste quellen- (d.h. Header-) und binärkompatibel (für das ABI) sein
• Die vom Gerät unterstützte native Application Binary Interface (ABI) muss über die android.os.Build.CPU_ABI API korrekt gemeldet werden.
• Es dürfen nur die ABIs gemeldet werden, die in der neuesten Version des Android NDK in der Datei docs/CPU-ARCH-ABIS.txt dokumentiert sind.
• MÜSSEN mit dem Quellcode und den Headerdateien erstellt werden, die im Upstream-Open-Source-Projekt von Android verfügbar sind

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

• libc (C-Bibliothek)
• libm (Mathematische Bibliothek)
• Minimale Unterstützung für C++
• JNI-Schnittstelle
• liblog (Android-Protokollierung)
• libz (Zlib-Komprimierung)
• libdl (dynamischer Linker)
• libGLESv1_CM.so (OpenGL ES 1.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 (Unterstützung von OpenMAX AL 1.0.1)
• libandroid.so (Unterstützung für native Android-Aktivitäten)
• Unterstützung für OpenGL, wie unten beschrieben

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

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

3.4. Webkompatibilität

3.4.1. WebView-Kompatibilität

Die Open-Source-Implementierung von Android verwendet die WebKit-Rendering-Engine, um den 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. Im Detail:

• Die android.webkit.WebView-Implementierungen der Geräteimplementierungen MÜSSEN auf dem WebKit-Build 534.30 aus dem Upstream-Android-Open-Source-Tree für Android 4.2 basieren. Dieser Build enthält eine Reihe von Funktionen und Sicherheitskorrekturen für WebView. Geräteimplementierer KÖNNEN Anpassungen an der WebKit-Implementierung vornehmen. Diese dürfen jedoch NICHT das Verhalten der WebView ändern, einschließlich des Rendering-Verhaltens.
• Der von WebView gemeldete User-Agent-String MUSS dieses Format haben:
  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 des Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE übereinstimmen.
  • Der Wert des Strings $(LOCALE) MUSS den ISO-Konventionen für Ländercode und Sprache entsprechen und MUSS sich auf das aktuell konfigurierte Gebietsschema des Geräts beziehen.
  • Der Wert des Strings $(MODEL) MUSS mit dem Wert für android.os.Build.MODEL übereinstimmen.
  • Der Wert des Strings $(BUILD) MUSS mit dem Wert für android.os.Build.ID übereinstimmen.
  • Bei Geräteimplementierungen kann Mobile im User-Agent-String weggelassen werden.

Die WebView-Komponente MUSS so viel HTML5 wie möglich unterstützen [Ressourcen, 11]. Geräteimplementierungen MÜSSEN mindestens die folgenden APIs unterstützen, die mit HTML5 in der WebView verknüpft sind:

• Anwendungscache/Offlinebetrieb [Ressourcen, 12]
• das <video>-Tag [Ressourcen, 13]
• Standortbestimmung [Ressourcen, 14]

Außerdem MÜSSEN Geräteimplementierungen die HTML5/W3C Webstorage API [Ressourcen, 15] und SOLLTEN die HTML5/W3C IndexedDB API [Ressourcen, 16] unterstützen. Hinweis: Da die Standardsteuergruppen für die Webentwicklung IndexedDB gegenüber Webstorage bevorzugen, wird IndexedDB voraussichtlich in einer zukünftigen Version von Android zu einer erforderlichen Komponente.

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. Browserkompatibilität

Geräteimplementierungen MÜSSEN eine eigenständige Browseranwendung für das allgemeine Surfen im Web enthalten. Der eigenständige Browser kann auf einer anderen Browsertechnologie als WebKit basieren. Auch wenn eine alternative Browseranwendung verwendet wird, muss die android.webkit.WebView-Komponente, die Drittanbieteranwendungen zur Verfügung gestellt wird, wie in Abschnitt 3.4.1 beschrieben auf WebKit basieren.

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

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

• Anwendungscache/Offlinebetrieb [Ressourcen, 12]
• das <video>-Tag [Ressourcen, 13]
• Standortbestimmung [Ressourcen, 14]

Außerdem MÜSSEN Geräteimplementierungen die HTML5/W3C Webstorage API [Ressourcen, 15] und SOLLTEN die HTML5/W3C IndexedDB API [Ressourcen, 16] unterstützen. Hinweis: Da die Standardsteuergruppen für die Webentwicklung IndexedDB gegenüber Webstorage bevorzugen, wird IndexedDB voraussichtlich in einer zukünftigen Version von Android zu einer erforderlichen Komponente.

3.5. API-Verhaltenskompatibilität

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

• Geräte dürfen das Verhalten oder die Semantik einer Standardabsicht NICHT ändern.
• Geräte dürfen den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, Contentanbieter) NICHT ändern.
• Geräte dürfen die Semantik einer Standardberechtigung NICHT ändern.

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

3.6. API-Namespaces

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

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

Zu den unzulässigen Änderungen gehören:

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

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

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

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

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

3.7. Kompatibilität mit virtuellen Maschinen

Geräteimplementierungen MÜSSEN die vollständige DEX-Bytecodespezifikation (Dalvik Executable) und die Semantik der Dalvik-Virtuellen Maschine unterstützen [Ressourcen, 17].

Bei Geräteimplementierungen MUSS Dalvik so konfiguriert werden, dass Speicher gemäß der übergeordneten Android-Plattform und wie in der folgenden Tabelle angegeben zugewiesen wird. Definitionen für Bildschirmgröße und Bildschirmdichte finden Sie unter Abschnitt 7.1.1.

Die unten angegebenen Speicherwerte gelten als Mindestwerte. Geräteimplementierungen KÖNNEN mehr Speicher pro Anwendung zuweisen.

Displaygröße	Displaydichte	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, mit denen Anwendungen Endnutzern ein „App-Widget“ zur Verfügung stellen können [Ressourcen, 18]. Die Open-Source-Referenzversion von Android enthält eine Launcher-Anwendung mit Benutzeroberflächenelementen, mit denen Nutzer App-Widgets auf dem Startbildschirm hinzufügen, ansehen und entfernen können.

Geräteimplementierungen KÖNNEN eine Alternative zum Referenz-Launcher (d.h. Startbildschirm) ersetzen. Alternative Launcher MÜSSEN eine integrierte Unterstützung für App-Widgets bieten und Nutzeroberflächenelemente zum Hinzufügen, Konfigurieren, Ansehen und Entfernen von App-Widgets direkt im Launcher enthalten. Alternative Launcher dürfen diese Elemente der Benutzeroberfläche ggf. weglassen. Wenn sie jedoch weggelassen werden, muss die Geräteimplementierung eine separate Anwendung bereitstellen, auf die über den Launcher zugegriffen werden kann und mit der Nutzer App-Widgets hinzufügen, konfigurieren, ansehen und entfernen können.

Geräteimplementierungen MÜSSEN Widgets in der Standardrastergröße von 4 × 4 rendern können. Weitere Informationen finden Sie in den Designrichtlinien für App-Widgets in der Android SDK-Dokumentation [Ressourcen, 18].

3.8.2. Benachrichtigungen

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

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

Außerdem MÜSSEN alle in den APIs [Ressourcen, 20] oder im Styleguide für Status-/Systemleistensymbole [Ressourcen, 21] bereitgestellten Ressourcen (Symbole, Audiodateien usw.) korrekt gerendert werden. Geräteimplementierer KÖNNEN eine andere Nutzererfahrung für Benachrichtigungen bieten als die der Referenzimplementierung von Android Open Source. Solche alternativen Benachrichtigungssysteme MÜSSEN jedoch vorhandene Benachrichtigungsressourcen wie oben beschrieben unterstützen.

Android 4.2 unterstützt erweiterte Benachrichtigungen, z. B. interaktive Ansichten für laufende Benachrichtigungen. Geräteimplementierungen MÜSSEN Rich Notifications wie in den Android APIs beschrieben korrekt anzeigen und ausführen.

3.8.3. Suchen

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

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

3.8.4. Toasts

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

3.8.5. Designs

Android bietet „Designs“ als Mechanismus für Anwendungen, um Stile auf eine gesamte Aktivität oder Anwendung anzuwenden. Android 4.2 enthält ein „Holo“- oder „holografisches“ Design als Reihe von definierten Stilen, die App-Entwickler verwenden können, wenn sie das Holo-Design gemäß der Definition im Android SDK [Ressourcen, 24] umsetzen möchten. Geräteimplementierungen dürfen KEINE der Holo-Designattribute ändern, die für Anwendungen freigegeben sind [Ressourcen, 25].

Android 4.2 enthält ein neues Design „Gerätestandard“ mit einer Reihe von definierten Stilen, die App-Entwickler verwenden können, wenn sie das Erscheinungsbild des vom Geräteimplementierer definierten Gerätedesigns anpassen möchten. Geräteimplementierungen dürfen die Designattribute „DeviceDefault“, die für Anwendungen freigegeben sind, ändern [Ressourcen, 25].

3.8.6. Live-Hintergründe

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

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

Geräteimplementierungen, die Live-Hintergründe wie oben beschrieben zuverlässig ausführen können, MÜSSEN Live-Hintergründe implementieren. Bei Geräten, bei denen festgestellt wurde, dass Live-Hintergründe nicht zuverlässig wie oben beschrieben ausgeführt werden, dürfen KEINE Live-Hintergründe implementiert werden.

3.8.7. Anzeige der zuletzt verwendeten Apps

Der Upstream-Quellcode von Android 4.2 enthält eine Benutzeroberfläche, mit der kürzlich verwendete Apps anhand eines Thumbnail-Bilds des grafischen Zustands der App angezeigt werden, in dem der Nutzer die App zuletzt verlassen hat. Geräteimplementierungen KÖNNEN diese Benutzeroberfläche ändern oder entfernen. In einer zukünftigen Version von Android soll diese Funktion jedoch noch stärker genutzt werden. Bei Geräteimplementierungen wird dringend empfohlen, für aktuelle Apps die 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 Android-Version kompatibel.

3.8.8. Einstellungen für die Eingabeverwaltung

Android 4.2 unterstützt Eingabeverwaltungs-Engines. Mit den APIs von Android 4.2 können benutzerdefinierte App-IMEs von Nutzern anpassbare Einstellungen festlegen. Geräteimplementierungen MÜSSEN Nutzern jederzeit die Möglichkeit bieten, auf die Einstellungen der Eingabemethode zuzugreifen, wenn eine Eingabemethode mit solchen Nutzereinstellungen angezeigt wird.

3.8.9. Widgets für Sperr- und Startbildschirm

Android 4.2 unterstützt App-Widgets, die Nutzer in den Start- oder Sperrbildschirm einbetten können. Weitere Informationen finden Sie in den Designrichtlinien für App-Widgets in der Android SDK-Dokumentation [Ressourcen, 69]. Mit App-Widgets können Sie schnell auf App-Daten und ‑Dienste zugreifen, ohne eine neue Aktivität zu starten. Widgets können für die Verwendung auf dem Start- oder Sperrbildschirm deklariert werden. Dazu wird das Manifest-Tag android:widgetCategory deklariert, 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 MÜSSEN einen Sperrbildschirm unterstützen. Wenn Geräteimplementierungen die Unterstützung für den Sperrbildschirm umfassen, MÜSSEN sie auch Anwendungs-Widgets auf dem Sperrbildschirm unterstützen.

3.8.10. Medienfernbedienung für den Sperrbildschirm

Android 4.2 unterstützt die Remote Control API, mit der sich Mediaanwendungen in Wiedergabesteuerungen integrieren lassen, die in einer Remoteansicht wie dem Sperrbildschirm des Geräts angezeigt werden[Ressourcen, 74]. Geräteimplementierungen MÜSSEN die Einbettung von Fernbedienungselementen in den Sperrbildschirm des Geräts unterstützen.

3.8.11. Träume

Android 4.2 unterstützt interaktive Bildschirmschoner namens Dreams [Ressourcen, 76]. Mit Dreams können Nutzer mit Anwendungen interagieren, wenn ein Ladegerät inaktiv ist oder in einem Tischdock angedockt ist. Geräteimplementierungen MÜSSEN Dreams unterstützen und eine Einstellungsoption für Nutzer zum Konfigurieren von Dreams bereitstellen.

3.9 Geräteverwaltung

Android 4.2 enthält Funktionen, mit denen sicherheitsbewusste Anwendungen über die Android Device Administration API Geräteverwaltungsfunktionen auf Systemebene ausführen können, z. B. die Durchsetzung von Passwortrichtlinien oder die Remote-Löschfunktion [Ressourcen, 27]. Geräteimplementierungen MÜSSEN eine Implementierung der Klasse DevicePolicyManager [Ressourcen, 28] bereitstellen und SOLLTEN die gesamte Palette der in der Android SDK-Dokumentation [Ressourcen, 27] definierten Richtlinien zur Geräteverwaltung unterstützen.

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

Hinweis:Einige der oben aufgeführten Anforderungen sind für Android 4.2 als „SOLLTE“ angegeben. In der Kompatibilitätsdefinition für eine zukünftige Version werden diese jedoch in „MUSS“ geändert. Das heißt, diese Anforderungen sind in Android 4.2 optional, werden aber in einer zukünftigen Version erforderlich sein. Wir empfehlen Ihnen dringend, diese Anforderungen unter Android 4.2 zu erfüllen, da bestehende und neue Geräte mit Android 4.2 andernfalls nicht mit der zukünftigen Version kompatibel sind.

3.10 Barrierefreiheit

Android 4.2 bietet eine Bedienungshilfenebene, die es Nutzern mit Behinderungen erleichtert, ihre Geräte zu bedienen. Darüber hinaus bietet Android 4.2 Plattform-APIs, mit denen Implementierungen von Bedienungshilfen Rückrufe für Nutzer- und Systemereignisse erhalten und alternative Feedbackmechanismen wie Text-zu-Sprache-Funktion, haptisches Feedback und Navigation per Trackball/D-Pad generieren können [Ressourcen, 29]. Geräteimplementierungen MÜSSEN eine Implementierung des Android-Bedienungshilfen-Frameworks bereitstellen, die mit der Standardimplementierung von Android übereinstimmt. Insbesondere müssen Geräteimplementierungen die folgenden Anforderungen erfüllen.

• Geräteimplementierungen MÜSSEN die Implementierungen von Drittanbietern für Bedienungshilfen über die android.accessibilityservice-APIs unterstützen [Ressourcen, 30].
• Geräteimplementierungen MÜSSEN AccessibilityEvents-Ereignisse generieren und diese Ereignisse gemäß der Standardimplementierung von Android an alle registrierten AccessibilityService -Implementierungen senden.
• Geräteimplementierungen MÜSSEN einen für Nutzer zugänglichen Mechanismus zum Aktivieren und Deaktivieren von Bedienungshilfen bereitstellen und MÜSSEN diese Benutzeroberfläche als Reaktion auf die android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS-Intent anzeigen.

Außerdem MÜSSEN Geräteimplementierungen einen Bedienungshilfendienst auf dem Gerät implementieren und MÜSSEN Nutzern einen Mechanismus zur Verfügung stellen, mit dem sie den Bedienungshilfendienst während der Geräteeinrichtung aktivieren können. Eine Open-Source-Implementierung eines Bedienungshilfendiensts ist im Rahmen des EyesFree-Projekts verfügbar [Ressourcen, 31].

3.11 Sprachausgabe

Android 4.2 enthält APIs, mit denen Anwendungen TTS-Dienste (Text-to-Speech) nutzen und Dienstanbieter TTS-Dienste implementieren können [Ressourcen, 32]. Geräteimplementierungen MÜSSEN die folgenden Anforderungen im Zusammenhang mit dem 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. Die Upstream-Open-Source-Software von Android enthält eine vollständige TTS-Engine-Implementierung.
• Geräteimplementierungen MÜSSEN die Installation von TTS-Engines von Drittanbietern unterstützen.
• Geräteimplementierungen MÜSSEN eine für Nutzer zugängliche Benutzeroberfläche bereitstellen, über die Nutzer eine TTS-Engine für die Verwendung auf Systemebene auswählen können.

4. Kompatibilität von Anwendungspaketen

Geräteimplementierungen MÜSSEN Android-APK-Dateien installieren und ausführen, die mit dem im offiziellen Android SDK enthaltenen Tool „aapt“ generiert wurden [Ressourcen, 33].

Geräteimplementierungen dürfen die .apk-Dateien [Ressourcen, 34], das Android-Manifest [Ressourcen, 35], den Dalvik-Bytecode [Ressourcen, 17] oder die RenderScript-Bytecode-Formate NICHT so erweitern, dass die Installation und Ausführung dieser Dateien auf anderen kompatiblen Geräten verhindert wird. Geräteimplementierer MÜSSEN die Upstream-Implementierung von Dalvik und das Paketverwaltungssystem der Referenzimplementierung verwenden.

5. Multimedia-Kompatibilität

Geräteimplementierungen MÜSSEN mindestens eine Form von Audioausgang haben, z. B. Lautsprecher, Kopfhöreranschluss oder Anschluss für externe Lautsprecher.

5.1. Medien-Codecs

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

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

In diesen Tabellen sind keine spezifischen Bitratenanforderungen für die meisten Videocodecs aufgeführt, da die aktuelle Gerätehardware nicht unbedingt Bitraten unterstützt, die genau den in den entsprechenden Standards angegebenen erforderlichen Bitraten entsprechen. Stattdessen sollten Geräteimplementierungen die praktisch höchste Bitrate der Hardware unterstützen, bis zu den in den Spezifikationen definierten Grenzwerten.

Eingeben	Format / Codec	Encoder	Decoder	Details	Dateityp(en) / Containerformate
Audio	MPEG-4 AAC-Profil (AAC LC)	ERFORDERLICH Erforderlich für Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone definieren.	REQUIRED	Unterstützung für Mono-/Stereo-/5.0-/5.1*-Inhalte mit Standardabtastraten von 8 bis 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS-Raw-AAC (.aac, Dekodierung unter Android 3.1 und höher, Codierung unter Android 4.0 und höher, ADIF wird nicht unterstützt) MPEG-TS (.ts, nicht suchbar, Android 3.0 und höher)
	MPEG-4 HE AAC Profile (AAC+)	ERFORDERLICH für Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone definieren	REQUIRED	Unterstützung für Mono-/Stereo-/5.0-/5.1*-Inhalte mit Standardabtastraten von 16 bis 48 kHz.
	MPEG-4 HE AAC v2-Profil (erweitertes AAC+)		REQUIRED	Unterstützung für Mono-/Stereo-/5.0-/5.1*-Inhalte mit Standardabtastraten von 16 bis 48 kHz.
	MPEG-4-Audioobjekttyp ER AAC ELD (Enhanced Low Delay AAC)	ERFORDERLICH für Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone definieren	REQUIRED	Unterstützung für Mono-/Stereoinhalte mit Standardabtastfrequenzen von 16 bis 48 kHz
	AMR-NB	ERFORDERLICH Erforderlich für Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone definieren.	REQUIRED	4,75 bis 12,2 kbit/s bei 8 kHz abgetastet	3GPP (.3gp)
	AMR-WB	ERFORDERLICH Erforderlich für Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone definieren.	REQUIRED	9 Raten von 6,60 kbit/s bis 23,85 kbit/s bei 16 kHz Abtastrate	3GPP (.3gp)
	FLAC		ERFORDERLICH (Android 3.1 oder höher)	Mono/Stereo (kein Mehrkanalton). Abtastraten bis zu 48 kHz (auf Geräten mit 44,1 kHz-Ausgabe 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 wird kein Dithering angewendet.	Nur FLAC (.flac)
	MP3		REQUIRED	Mono/Stereo 8–320 kbit/s konstant (CBR) oder variable Bitrate (VBR)	MP3 (.mp3)
	MIDI		REQUIRED	MIDI-Typ 0 und 1 DLS-Version 1 und 2 XMF und Mobile XMF. Unterstützung für Klingeltonformate RTTTL/RTX, OTA und iMelody	Typ 0 und 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbis		REQUIRED		Ogg (.ogg) Matroska (.mkv)
	PCM/WAVE	REQUIRED	REQUIRED	Lineare 8‑ und 16‑Bit-PCM** (Abtastraten bis zur Grenze der Hardware). Geräte MÜSSEN Abtastraten für die Aufzeichnung von Roh-PCM mit 8.000,16.000 und 44.100 Hz unterstützen.	WAVE (.wav)
Bild	JPEG	REQUIRED	REQUIRED	Basispreis + progressiver Preis	JPEG (JPG)
	GIF		REQUIRED		GIF (.gif)
	PNG	REQUIRED	REQUIRED		PNG (.png)
	BMP		REQUIRED		BMP (.bmp)
	WEBP	REQUIRED	REQUIRED		WebP (.webp)
Video	H.263	ERFORDERLICH Erforderlich für Geräteimplementierungen, die Kamerahardware enthalten und android.hardware.camera oder android.hardware.camera.front definieren.	REQUIRED		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	ERFORDERLICH Erforderlich für Geräteimplementierungen, die Kamerahardware enthalten und android.hardware.camera oder android.hardware.camera.front definieren.	REQUIRED	Baseline-Profil (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, nur AAC-Audio, nicht suchbar, Android 3.0 und höher)
	MPEG-4 SP		REQUIRED		3GPP (.3gp)
	VP8		ERFORDERLICH (Android 2.3.3 oder höher)		WebM (.webm) und Matroska (.mkv, Android 4.0 und höher)

*Hinweis: Es ist nur ein Downmix von 5.0/5.1-Inhalten erforderlich. Die Aufnahme oder das Rendern von mehr als zwei Kanälen ist optional. **Hinweis: Die Aufzeichnung in linearem 16-Bit-PCM ist obligatorisch. Die Erfassung mit 8-Bit-linearer PCM ist nicht obligatorisch.

5.2 Videocodierung

Android-Geräteimplementierungen mit einer Rückkamera und der Deklaration von android.hardware.camera MÜSSEN die folgenden Videocodierungsprofile unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD (sofern von der Hardware unterstützt)
Video-Codec	H.264-Profil "Baseline"	H.264-Profil "Baseline"	H.264-Profil "Baseline"
Videoauflösung	176 × 144 px	480 x 360 px	1.280 × 720 Pixel
Video-Framerate	12 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	56 kbit/s	500 Kbit/s oder höher	2 Mbit/s oder mehr
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 MÜSSEN die folgenden VP8-Video-Decodierungsprofile unterstützen.

	SD (niedrige Qualität)	SD (hohe Qualität)	HD 720p  (sofern von der Hardware unterstützt)	HD 1080p (sofern von der Hardware unterstützt)
Videoauflösung	320 × 180 px	640 x 360 px	1.280 × 720 Pixel	1920 × 1080 Pixel
Video-Framerate	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps	Frame-Rate: 30 fps
Video-Bitrate	800 kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.4. Audioaufnahmen

Wenn eine Anwendung die android.media.AudioRecord API verwendet hat, um die Aufnahme eines Audiostreams zu starten, müssen Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone angeben, Audio mit den folgenden Verhaltensweisen erfassen und aufzeichnen:

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

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

• Die Geräuschunterdrückung muss deaktiviert sein.
• Die automatische Verstärkungsregelung muss deaktiviert sein.

Hinweis:Einige der oben aufgeführten Anforderungen sind für Android 4.2 als „SOLLTE“ angegeben. In der Kompatibilitätsdefinition für eine zukünftige Version werden diese jedoch in „MUSS“ geändert. Das heißt, diese Anforderungen sind in Android 4.2 optional, werden aber in einer zukünftigen Version erforderlich sein. Wir empfehlen Ihnen dringend, diese Anforderungen unter Android 4.2 zu erfüllen, da bestehende und neue Geräte mit Android 4.2 andernfalls nicht mit der zukünftigen Version kompatibel sind.

5.5. Audiolatenz

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

Für die Zwecke dieses Abschnitts gilt:

• Die „Ausgabelatenz“ ist das Intervall zwischen dem Schreiben eines Frames mit PCM-codierten Daten durch eine Anwendung und dem Zeitpunkt, zu dem der entsprechende Ton von einem externen Hörer gehört oder von einem Wandler erfasst werden kann.
• Die „Latenz der kalten Ausgabe“ ist die Ausgabelatenz für den ersten Frame, wenn das Audioausgabesystem vor der Anfrage inaktiv und ausgeschaltet war.
• „Continuous Output Latency“ (kontinuierliche Ausgabelatenz) ist die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät bereits Audio wiedergibt.
• Die „Eingabelatenz“ ist das Intervall zwischen dem Zeitpunkt, zu dem ein externer Ton dem Gerät präsentiert wird, und dem Zeitpunkt, zu dem eine Anwendung den entsprechenden Frame mit PCM-codierten Daten liest.
• Die „Latenz der kalten Eingabe“ wird als Summe aus der verlorenen Eingabezeit und der Eingabelatenz für den ersten Frame definiert, wenn das Audioeingabesystem vor der Anfrage inaktiv und ausgeschaltet war.
• „Continuous Input Latency“ (kontinuierliche Eingabelatenz) ist die Eingabelatenz für nachfolgende Frames, während das Gerät bereits Audio erfasst.
• „OpenSL ES PCM-Puffer-Queue-API“ ist die Gruppe der PCM-bezogenen OpenSL ES APIs im Android NDK. Weitere Informationen finden Sie unter NDK_root./docs/opensles/index.html

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

• Kaltstartlatenz von 100 Millisekunden oder weniger
• eine kontinuierliche Ausgabelatenz von 45 Millisekunden oder weniger

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

Gemäß Abschnitt 7.2.5 kann die Mikrofonhardware bei Geräteimplementierungen weggelassen werden.

Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone angeben, MÜSSEN diese Anforderungen an die Audiolatenz erfüllen:

• Eingabelatenz nach dem Kaltstart von 100 Millisekunden oder weniger
• eine kontinuierliche Eingabelatenz von 50 Millisekunden oder weniger

5.6. Netzwerkprotokolle

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

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

6. Kompatibilität von Entwicklertools und ‑optionen

6.1 Entwicklertools

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

• Android Debug Bridge (adb) [Ressourcen, 33]
  Geräteimplementierungen MÜSSEN alle adb-Funktionen unterstützen, die im Android SDK dokumentiert sind. Der geräteseitige adb-Daemon MUSS standardmäßig inaktiv sein und es MUSS einen nutzerzugänglichen Mechanismus geben, um die Android Debug Bridge zu aktivieren.

Android 4.2.2 unterstützt sicheres adb. Mit Secure adb wird adb auf bekannten authentifizierten Hosts aktiviert. Wir empfehlen Ihnen dringend, diese Anforderung in Android 4.2 auf bestehenden und neuen Geräten mit Android 4.2.2 zu erfüllen, da sie sonst nicht mit Android kompatibel sind, wenn Sie auf die zukünftige Version aktualisieren.

• Dalvik Debug Monitor Service (ddms) [Ressourcen, 33]
  Geräteimplementierungen MÜSSEN alle ddms Funktionen unterstützen, die im Android SDK dokumentiert sind. Da ddms adb verwendet, sollte die Unterstützung für ddms standardmäßig inaktiv sein. Sie MUSS jedoch unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben aktiviert hat.
• Monkey [Ressourcen, 36]
  Geräteimplementierungen MÜSSEN das Monkey-Framework enthalten und für Anwendungen verfügbar machen.
• SysTrace [Ressourcen, 33]
  Geräteimplementierungen MÜSSEN das Systrace-Tool unterstützen, wie im Android SDK beschrieben. Systrace muss standardmäßig inaktiv sein und es MUSS einen nutzerzugänglichen Mechanismus geben, um Systrace zu aktivieren.

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

6.2 Entwickleroptionen

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

7. Hardwarekompatibilität

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

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

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

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

7.1. Display und Grafik

Android 4.2 bietet Funktionen, mit denen sich App-Assets und UI-Layouts automatisch an das Gerät anpassen lassen, damit Drittanbieter-Apps auf einer Vielzahl von Hardwarekonfigurationen reibungslos funktionieren [Ressourcen, 38]. Auf Geräten MÜSSEN diese APIs und Verhaltensweisen wie in diesem Abschnitt beschrieben implementiert sein.

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

• Die „Diagonale“ ist der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Bereichs des Displays.
• „dpi“ (dots per inch, Punkte pro Zoll) ist die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spannweite von 1" (2,54 cm) abgedeckt werden. Wenn dpi-Werte aufgeführt sind, müssen sowohl die horizontalen als auch die vertikalen dpi innerhalb des Bereichs liegen.
• Das Seitenverhältnis ist das Verhältnis zwischen der längeren und der kürzeren Bildschirmdimension. Bei einem Display mit 480 × 854 Pixeln würde das Verhältnis 854 ÷ 480 = 1, 779 ergeben, also ungefähr „16:9“.
• Ein „dichteunabhängiges Pixel“ oder „dp“ ist die virtuelle Pixeleinheit, die auf ein Display mit 160 dpi normiert ist. Sie wird so berechnet: pixels = dps * (density / 160).

7.1.1. Bildschirmkonfiguration

Displaygröße

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

• Die Bildschirmgröße der Geräte muss mindestens 426 dp × 320 dp (klein) betragen.
• Geräte, für die die Bildschirmgröße „normal“ angegeben ist, MÜSSEN eine Bildschirmgröße von mindestens 480 dp × 320 dp haben.
• Geräte, für die die Bildschirmgröße „Groß“ angegeben ist, MÜSSEN eine Bildschirmgröße von mindestens 640 dp × 480 dp haben.
• Geräte mit der Bildschirmgröße „xlarge“ MÜSSEN eine Bildschirmgröße von mindestens 960 dp × 720 dp haben.

Außerdem müssen die Geräte eine Bildschirmdiagonale von mindestens 6, 4 cm haben.

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

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

Seitenverhältnis des Bildschirms

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

Bildschirmdichte

Das Android-UI-Framework definiert eine Reihe von standardmäßigen logischen Dichten, die Entwicklern bei der Ausrichtung von Anwendungsressourcen helfen. Geräteimplementierungen MÜSSEN eine der folgenden logischen Android-Framework-Dichten über die android.util.DisplayMetrics APIs melden und MÜSSEN Anwendungen mit dieser Standarddichte ausführen.

• 120 dpi, auch „ldpi“ genannt
• 160 dpi, auch „mdpi“ genannt
• 213 dpi, auch „tvdpi“ genannt
• 240 dpi, auch „hdpi“ genannt
• 320 dpi, auch „xhdpi“ genannt
• 480 dpi, auch „xxhdpi“ genannt

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

7.1.2. Messwerte für Displaykampagnen

Bei Geräteimplementierungen MÜSSEN korrekte Werte für alle in android.util.DisplayMetrics [Ressourcen, 39] definierten Displaymesswerte angegeben werden.

7.1.3. Displayausrichtung

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

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

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

Geräte MÜSSEN angeben, welche Bildschirmausrichtungen sie unterstützen (android.hardware.screen.portrait und/oder android.hardware.screen.landscape) und MÜSSEN mindestens eine unterstützte Ausrichtung angeben. Bei einem Gerät mit einem fixierten Querformat-Display, z. B. einem Fernseher oder Laptop, MUSS nur android.hardware.screen.landscape gemeldet werden.

7.1.4. 2D- und 3D-Grafikbeschleunigung

Geräteimplementierungen MÜSSEN sowohl OpenGL ES 1.0 als auch 2.0 unterstützen, wie in der Android SDK-Dokumentation beschrieben. Geräteimplementierungen MÜSSEN auch Android Renderscript unterstützen, wie in der Android SDK-Dokumentation [Ressourcen, 8] beschrieben.

Geräteimplementierungen MÜSSEN sich auch korrekt als OpenGL ES 1.0- und 2.0-kompatibel identifizieren. Das bedeutet:

• Die verwalteten APIs (z. B. über die GLES10.getString()-Methode) MÜSSEN OpenGL ES 1.0 und 2.0 unterstützen.
• Die nativen C/C++-OpenGL-APIs (d. h. die für Apps über libGLES_v1CM.so, libGLES_v2.so oder libEGL.so verfügbar sind) MÜSSEN OpenGL ES 1.0 und 2.0 unterstützen.

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

Android 4.2 unterstützt die optionale Angabe von Anwendungen, für die bestimmte OpenGL-Texturkomprimierungsformate erforderlich sind. Diese Formate sind in der Regel anbieterspezifisch. Android 4.2 erfordert keine Implementierung eines bestimmten Texturkomprimierungsformats. Sie MÜSSEN jedoch alle unterstützten Texturkomprimierungsformate über die getString()-Methode in der OpenGL API korrekt angeben.

Android 4.2 enthält einen Mechanismus, mit dem Anwendungen über ein Manifest-Tagandroid:hardwareAccelerated oder direkte API-Aufrufe die Hardwarebeschleunigung für 2D-Grafiken auf Anwendungs-, Aktivitäts-, Fenster- oder Ansichtsebene aktivieren können [Ressourcen, 9].

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

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

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

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

Android 4.2 enthält einen „Kompatibilitätsmodus“, in dem das Framework im Modus einer „normalen“ Bildschirmgröße (320 dp Breite) ausgeführt wird. Dies ist für ältere Anwendungen von Vorteil, die nicht für alte Android-Versionen entwickelt wurden, die noch nicht unabhängig von der Bildschirmgröße waren. Geräteimplementierungen MÜSSEN den Modus für die Kompatibilität mit älteren Anwendungen unterstützen, wie er im Upstream-Android-Open-Source-Code implementiert ist. Das heißt, die Auslöser oder Grenzwerte, bei denen der Kompatibilitätsmodus aktiviert wird, und das Verhalten des Kompatibilitätsmodus selbst DÜRFEN NICHT geändert werden.

7.1.6. Bildschirmtypen

Bildschirme für die Geräteimplementierung werden in zwei Typen unterteilt:

• Implementierungen mit fester Pixelanzahl: Der Bildschirm besteht aus einem einzelnen Panel, das nur eine Pixelbreite und -höhe unterstützt. In der Regel ist das Display physisch in das Gerät integriert. Beispiele hierfür sind Smartphones und Tablets.
• Implementierungen mit variabler Pixelanzahl: Die Geräteimplementierung hat entweder keinen integrierten Bildschirm und einen Videoausgang wie VGA, HDMI oder einen kabellosen Anschluss für das Display oder einen integrierten Bildschirm, bei dem sich die Pixelabmessungen ändern lassen. Beispiele hierfür sind Fernseher und Set-Top-Boxen.

Implementierungen mit fester Pixelanzahl

Bei Geräten mit fester Pixelanzahl KÖNNEN Bildschirme mit beliebigen Pixelabmessungen verwendet werden, sofern sie die in dieser Kompatibilitätsdefinition definierten Anforderungen erfüllen.

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

• Das Gerät MUSS dieselbe Bildschirmkonfiguration und dieselben Bildschirmmesswerte wie das Display mit fester Pixelanzahl melden, wie in den Abschnitten 7.1.1 und 7.1.2 beschrieben.
• Das Gerät MUSS dieselbe logische Dichte wie das Display mit fester Pixelanzahl melden.
• Das Gerät MUSS Displayabmessungen angeben, die mit denen des Displays mit fester Pixelanzahl übereinstimmen oder sehr nahe daran liegen.

Ein Tablet mit einer Diagonale von 7" und einer Auflösung von 1.024 x 600 Pixeln gilt beispielsweise als Large-mdpi-Display mit fester Pixelanzahl. Wenn es einen Videoausgangsport mit einer Auflösung von 720p oder 1080p hat, MUSS die Geräteimplementierung die Ausgabe so skalieren, dass Anwendungen nur in einem großen mdpi-Fenster ausgeführt werden, unabhängig davon, ob das Display mit fester Pixelanzahl oder der Videoausgangsport verwendet wird.

Implementierungen von Geräten mit variabler Pixelanzahl

Geräteimplementierungen mit variabler Pixelanzahl MÜSSEN eine oder beide Auflösungen 1280 x 720 oder 1920 x 1080 (d. h. 720p oder 1080p) unterstützen. Geräteimplementierungen mit variablen Pixeldisplays DÜRFEN KEINE andere Bildschirmkonfiguration oder -modus unterstützen. Bei Geräten mit variabler Pixelanzahl kann die Displaykonfiguration oder der Displaymodus während der Laufzeit oder beim Starten geändert werden. Ein Nutzer eines Set-Top-Boxes kann beispielsweise ein 720p-Display durch ein 1080p-Display ersetzen. Die Geräteimplementierung wird dann entsprechend angepasst.

Bei Geräten mit variablen Pixeln MÜSSEN außerdem die folgenden Konfigurations-Buckets für diese Pixelabmessungen angegeben werden:

• 1280 × 720 (auch als 720p bezeichnet): Bildschirmgröße „large“, Dichte „tvdpi“ (213 dpi)
• 1920 × 1080 (auch als 1080p bezeichnet): Bildschirmgröße „large“, Dichte „xhdpi“ (320 dpi)

Zur Klarstellung: Geräteimplementierungen mit variablen Pixelabmessungen sind in Android 4.2 auf 720p oder 1080p beschränkt und MÜSSEN so konfiguriert werden, dass sie die oben genannten Bereiche für Displaygröße und ‑dichte melden.

7.1.7. Displaytechnologie

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

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

7.1.8. Externe Displays

Android 4.2 unterstützt ein sekundäres Display, um die Medienfreigabe zu ermöglichen, und Entwickler-APIs für den Zugriff auf externe Displays. Wenn ein Gerät ein externes Display entweder über eine kabelgebundene, drahtlose oder eine eingebettete zusätzliche Displayverbindung unterstützt, MUSS die Geräteimplementierung die Displaymanager API wie in der Android SDK-Dokumentation beschrieben implementieren [Ressourcen, 75]. Geräteimplementierungen, die eine sichere Videoausgabe und sichere Oberflächen unterstützen, MÜSSEN Display.SECURE_FLAG unterstützen. Insbesondere müssen Geräteimplementierungen, die die Unterstützung von Display.SECURE_FLAG angeben, HDCP 2.x oder höher für Miracast-drahtlose Displays oder HDCP 1.2 oder höher für kabelgebundene Displays unterstützen. Die Upstream-Open-Source-Implementierung von Android unterstützt drahtlose (Miracast) und kabelgebundene (HDMI) Displays, was diese Anforderung erfüllt.

7.2. Eingabegeräte

7.2.1. Tastatur

Geräteimplementierungen:

• MÜSSEN Unterstützung für das Input Management Framework enthalten, mit dem Drittanbieter Input Management Engines (d. h. Soft-Tastatur) erstellen können, wie unter http://developer.android.com beschrieben.
• Es muss mindestens eine Soft-Tastatur implementiert sein (unabhängig davon, ob eine Hardwaretastatur vorhanden ist).
• KANN zusätzliche Implementierungen von Bildschirmtastaturen umfassen
• KANN eine Hardwaretastatur enthalten
• Darf KEINE Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard[Ressourcen, 40] angegebenen Formate entspricht (d. h. QWERTY oder 12-Tasten)

7.2.2. Bedienung ohne Touchscreen

Geräteimplementierungen:

• Es kann sein, dass eine Option zur Navigation ohne Touchbedienung (z. B. ein Trackball, ein D-Pad oder ein Rad) nicht enthalten ist.
• Es MUSS der richtige Wert für android.content.res.Configuration.navigation [Resources, 40] angegeben werden.
• Es MUSS einen angemessenen alternativen Mechanismus für die Benutzeroberfläche zur Auswahl und Bearbeitung von Text geben, der mit Eingabeverwaltungs-Engines kompatibel ist. Die vorgelagerte Open-Source-Implementierung von Android enthält einen Auswahlmechanismus, der für Geräte geeignet ist, die keine Eingaben für die Navigation ohne Touchbedienung haben.

7.2.3. Navigationstasten

Die Funktionen „Startseite“, „Menü“ und „Zurück“ sind für die Android-Navigation unerlässlich. Bei der Geräteimplementierung MÜSSEN diese Funktionen dem Nutzer jederzeit beim Ausführen von Anwendungen zur Verfügung stehen. Diese Funktionen KÖNNEN über spezielle physische Tasten (z. B. mechanische oder kapazitive Touch-Tasten) oder über spezielle Softwaretasten, Touch-Gesten, Touchbedienung usw. implementiert werden. Android 4.2 unterstützt beide Implementierungen.

Android 4.2 unterstützt die Assist-Aktion [Ressourcen, 63]. Bei der Geräteimplementierung MUSS die Assist-Aktion dem Nutzer jederzeit beim Ausführen von Apps zur Verfügung stehen. Diese Funktion kann über Hardware- oder Softwareschlüssel implementiert werden.

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

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

7.2.4. Touchscreen-Eingabe

Geräteimplementierungen:

• MUSS eine Art Eingabesystem für den Cursor haben (entweder Maus- oder Touchbedienung)
• KANN einen Touchscreen beliebiger Art haben (z. B. kapazitiv oder resistiv)
• MÜSSEN vollständig unabhängige Touchstifte unterstützen, wenn ein Touchscreen mehrere Touchstifte unterstützt
• Der Wert von android.content.res.Configuration [Ressourcen, 39] muss dem Typ des Touchscreens des Geräts entsprechen.

Bei Geräteimplementierungen MUSS die richtige Funktion für die verwendete Eingabeart angegeben werden. Android 4.2 enthält die Funktion android.hardware.faketouch, die einem High-Fidelity-Eingabegerät ohne Touchbedienung (d. h. einem Zeigergerät) wie einer Maus oder einem Touchpad entspricht, das die Touchbedienung (einschließlich grundlegender Gesten) angemessen emulieren kann. Das bedeutet, dass das Gerät eine emulierte Teilmenge der Touchscreenfunktionen unterstützt. Geräteimplementierungen mit Touchscreen (Einzelpunktberührung oder besser) MÜSSEN auch „android.hardware.faketouch“ melden. Bei Geräten ohne Touchscreen (die nur ein Zeigegerät verwenden) DÜRFEN KEINE Touchscreen-Funktionen gemeldet werden. Es muss nur android.hardware.faketouch gemeldet werden.

7.2.5. Mikrofon

Bei Geräteimplementierungen kann ein Mikrofon UNTER UMSTÄNDEN weggelassen werden. Wenn eine Geräteimplementierung jedoch kein Mikrofon enthält, darf die Funktion android.hardware.microphone NICHT gemeldet werden und die Audioaufzeichnungs-API muss gemäß Abschnitt 7 als No-Op implementiert werden. Geräteimplementierungen mit Mikrofon:

• Die Funktion android.hardware.microphone MUSS als Konstante angegeben werden.
• MÜSSEN den Anforderungen an die Audioqualität in Abschnitt 5.4 entsprechen
• MÜSSEN die Anforderungen an die Audiolatenz in Abschnitt 5.5 erfüllen

7.3. Sensoren

Android 4.2 enthält APIs für den Zugriff auf verschiedene Sensortypen. Bei der Geräteimplementierung können diese Sensoren in der Regel gemäß den folgenden Abschnitten weggelassen werden. Wenn ein Gerät einen bestimmten Sensortyp mit einer entsprechenden API für Drittanbieterentwickler enthält, MUSS die Geräteimplementierung diese API gemäß der Beschreibung in der Android SDK-Dokumentation implementieren. Beispiel für Geräteimplementierungen:

• MÜSSEN das Vorhandensein oder Fehlen von Sensoren gemäß der android.content.pm.PackageManager-Klasse korrekt melden. [Ressourcen, 37]
• MUSS über SensorManager.getSensorList() und ähnliche Methoden eine genaue Liste der unterstützten Sensoren zurückgeben
• MÜSSEN sich für alle anderen Sensor-APIs angemessen verhalten (z. B. durch Rückgabe von „wahr“ oder „falsch“, wenn Anwendungen versuchen, Listener zu registrieren, oder durch Nichtaufrufen von Sensor-Listenern, wenn die entsprechenden Sensoren nicht vorhanden sind).
• Alle Sensormessungen MÜSSEN für jeden Sensortyp gemäß der Definition in der Android SDK-Dokumentation mit den entsprechenden Werten des internationalen Einheitensystems (d.h. metrischen Werten) erfasst werden [Ressourcen, 41]

Die Liste oben ist nicht vollständig. Das dokumentierte Verhalten des Android SDK ist verbindlich.

Einige Sensortypen sind synthetisch, d. h., sie können aus Daten abgeleitet werden, die von einem oder mehreren anderen Sensoren bereitgestellt werden. Beispiele sind der Orientierungssensor und der lineare Beschleunigungssensor. Geräteimplementierungen MÜSSEN diese Sensortypen implementieren, wenn sie die erforderlichen physischen Sensoren enthalten.

Android 4.2 enthält den Begriff „Streaming-Sensor“, der kontinuierlich Daten zurückgibt, nicht nur, wenn sich die Daten ändern. Geräteimplementierungen MÜSSEN kontinuierlich zyklische Datenproben für jede API bereitstellen, die in der Android 4.2 SDK-Dokumentation als Streamingsensor angegeben ist. Die Geräteimplementierungen MÜSSEN dafür sorgen, dass der Sensorstream die CPU des Geräts nicht daran hindert, in den Ruhemodus zu wechseln oder aus dem Ruhemodus aufzuwachen.

7.3.1. Beschleunigungsmesser

Geräteimplementierungen MÜSSEN einen 3-Achsen-Beschleunigungsmesser enthalten. Wenn eine Geräteimplementierung einen 3-Achsen-Beschleunigungsmesser enthält, gilt Folgendes:

• MÜSSEN Ereignisse mit mindestens 120 Hz senden können. Die oben angegebene Frequenz des Beschleunigungsmessers ist für Android 4.2 als „SOLLTE“ angegeben. In der Kompatibilitätsdefinition für eine zukünftige Version wird dies jedoch in „MUSS“ geändert. Das heißt, diese Standards sind in Android 4.2 optional, in zukünftigen Versionen jedoch erforderlich. Wir empfehlen Ihnen dringend, diese Anforderungen unter Android 4.2 zu erfüllen, damit Sie auf zukünftige Plattformversionen aktualisieren können.
• MÜSSEN dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben (siehe [Ressourcen, 41])
• MÜSSEN im freien Fall bis zu doppelter Erdbeschleunigung (2 g) oder mehr in jedem dreidimensionalen Vektor messen können
• MÜSSEN eine Genauigkeit von mindestens 8 Bit haben
• Die Standardabweichung darf maximal 0,05 m/s² betragen.

7.3.2. Magnetometer

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

• MÜSSEN Ereignisse mit mindestens 10 Hz senden können
• MÜSSEN dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben (siehe [Ressourcen, 41]).
• MÜSSEN in der Lage sein, eine Reihe von Feldstärken zu erfassen, die ausreichen, um das geomagnetische Feld abzudecken.
• MÜSSEN eine Genauigkeit von mindestens 8 Bit haben
• Die Standardabweichung darf maximal 0,5 µT betragen.

7.3.3. GPS

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

7.3.4. Gyroskop

Geräteimplementierungen MÜSSEN ein Gyroskop (d.h. einen Sensor für Winkeländerungen) enthalten. Geräte DÜRFEN KEIN Gyroskop enthalten, es sei denn, es ist auch ein 3-Achsen-Beschleunigungsmesser vorhanden. Wenn eine Geräteimplementierung ein Gyroskop enthält, gilt Folgendes:

• MÜSSEN temperaturkompensiert sein
• MÜSSEN in der Lage sein, Ausrichtungsänderungen von bis zu 5,5 Pi Rad/Sekunde (d. h. etwa 1.000 Grad pro Sekunde) zu messen.
• MÜSSEN Ereignisse mit mindestens 200 Hz senden können. Die oben angegebene Gyroskopfrequenz für Android 4.2 ist zwar als „SOLLTE“ angegeben, in der Kompatibilitätsdefinition für eine zukünftige Version soll sie jedoch in „MUSS“ geändert werden. Das heißt, diese Standards sind in Android 4.2 optional, in zukünftigen Versionen jedoch erforderlich. Wir empfehlen Ihnen dringend, diese Anforderungen unter Android 4.2 zu erfüllen, damit Sie auf zukünftige Plattformversionen aktualisieren können.
• MÜSSEN eine Genauigkeit von mindestens 12 Bit haben
• Die Abweichung darf maximal 1e-7 rad² / s² pro Hz (Abweichung pro Hz oder rad² / s) betragen. Die Abweichung darf mit der Abtastrate variieren, muss aber durch diesen Wert begrenzt sein. Mit anderen Worten: Wenn Sie die Abweichung des Gyroskops bei einer Abtastrate von 1 Hz messen, sollte sie nicht größer als 1 E-7 rad²/s² sein.
• MÜSSEN Zeitstempel haben, die so nah wie möglich am Zeitpunkt des Hardwareereignisses liegen. Die konstante Latenz muss entfernt werden.

7.3.5. Barometer

Geräteimplementierungen KÖNNEN ein Barometer (d.h. einen Sensor für den Umgebungsluftdruck) enthalten. Wenn eine Geräteimplementierung ein Barometer enthält, gilt Folgendes:

• MÜSSEN Ereignisse mit mindestens 5 Hz senden können
• MÜSSEN eine ausreichende Genauigkeit haben, um die Höhe schätzen zu können
• MÜSSEN temperaturkompensiert sein

7.3.7. Thermometer

Geräteimplementierungen KÖNNEN, MÜSSEN aber KEIN Thermometer (d.h. Temperatursensor) enthalten. Wenn eine Geräteimplementierung ein Thermometer enthält, MUSS es die Temperatur der CPU des Geräts messen. Es darf KEINE andere Temperatur messen. Hinweis: Dieser Sensortyp wird in den APIs von Android 4.2 nicht mehr unterstützt.

7.3.7. Fotometer

Geräteimplementierungen KÖNNEN einen Fotometer (d.h. einen Umgebungslichtsensor) enthalten.

7.3.8. Näherungssensor

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

7.4. Datenverbindung

7.4.1. Telefonie

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

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

7.4.2. IEEE 802.11 (Wi‑Fi)

Geräteimplementierungen mit Android 4.2 MÜSSEN eine oder mehrere Formen von 802.11 (b/g/a/n usw.) unterstützen. Wenn eine Geräteimplementierung 802.11 unterstützt, MUSS die entsprechende Android API implementiert werden.

Geräteimplementierungen MÜSSEN die Multicast API wie in der SDK-Dokumentation beschrieben implementieren [Ressourcen, 62]. Geräteimplementierungen mit WLAN-Unterstützung MÜSSEN Multicast DNS (mDNS) unterstützen. Geräteimplementierungen dürfen mDNS-Pakete (224.0.0.251) zu keinem Zeitpunkt filtern, auch nicht, wenn sich das Display nicht im aktiven Zustand befindet.

7.4.2.1. Wi‑Fi Direct

Geräteimplementierungen MÜSSEN Wifi Direct (Wifi-Peer-to-Peer) unterstützen. Wenn eine Geräteimplementierung Wifi Direct unterstützt, MUSS die entsprechende Android API wie in der SDK-Dokumentation beschrieben implementiert werden [Ressourcen, 68]. Wenn eine Geräteimplementierung die Unterstützung von Wifi Direct umfasst, gilt Folgendes:

• MUSS den regulären WLAN-Betrieb unterstützen
• SOLLTE gleichzeitiges WLAN und WLAN-Direkt unterstützen

7.4.3. Bluetooth

Geräteimplementierungen MÜSSEN einen Bluetooth-Transceiver enthalten. Bei Geräteimplementierungen mit Bluetooth-Transceiver muss die RFCOMM-basierte Bluetooth API wie in der SDK-Dokumentation beschrieben aktiviert werden [Ressourcen, 42]. Bei der Geräteimplementierung MÜSSEN relevante Bluetooth-Profile wie A2DP, AVRCP und OBEX implementiert werden, sofern für das Gerät erforderlich.

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 auf einem einzelnen Gerät getestet werden. Daher MÜSSEN Geräteimplementierungen auch den in Anhang A beschriebenen manuellen Bluetooth-Test bestehen.

7.4.4. Nahfeldkommunikation

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

• Die Funktion „android.hardware.nfc“ MUSS über die Methode android.content.pm.PackageManager.hasSystemFeature() gemeldet werden. [Ressourcen, 37]
• MÜSSEN NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können:
  • MÜSSEN als NFC-Forum-Lese-/Schreibgerät (wie in der technischen NFC-Forum-Spezifikation NFCForum-TS-DigitalProtocol-1.0 definiert) über die folgenden NFC-Standards funktionieren:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC-Forum-Tag-Typen 1, 2, 3 und 4 (vom NFC-Forum definiert)
• MÜSSEN NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können. Die unten aufgeführten NFC-Standards sind für Android 4.2 als „SHOULD“ (sollte) angegeben. In der Kompatibilitätsdefinition für eine zukünftige Version werden sie jedoch voraussichtlich in „MUST“ (muss) geändert. Das heißt, diese Standards sind in Android 4.2 optional, aber in zukünftigen Versionen erforderlich. Wir empfehlen Ihnen dringend, diese Anforderungen in Android 4.2 zu erfüllen, damit Sie auf die zukünftigen Plattformversionen umstellen können.
  • NfcV (ISO 15693)
• MÜSSEN Daten über die folgenden Peer-to-Peer-Standards und ‑Protokolle übertragen und empfangen können:
  • ISO 18092
  • LLCP 1.0 (vom NFC-Forum definiert)
  • SDP 1.0 (vom NFC Forum definiert)
  • NDEF Push Protocol [Resources, 43]
  • SNEP 1.0 (vom NFC-Forum definiert)
• MUSS Android Beam unterstützen [Ressourcen, 65]:
  • Der SNEP-Standardserver MUSS implementiert werden. Gültige NDEF-Nachrichten, die vom Standard-SNEP-Server empfangen werden, MÜSSEN an Anwendungen gesendet werden, die die Intent-Aktion „android.nfc.ACTION_NDEF_DISCOVERED“ verwenden. Das Deaktivieren von Android Beam in den Einstellungen darf NICHT den Versand eingehender NDEF-Nachrichten deaktivieren.
  • Geräteimplementierungen MÜSSEN die Intent „android.settings.NFCSHARING_SETTINGS“ berücksichtigen, um die NFC-Freigabeeinstellungen anzuzeigen [Ressourcen, 67].
  • Der NPP-Server MUSS implementiert sein. Nachrichten, die vom NPP-Server empfangen werden, MÜSSEN auf die gleiche Weise verarbeitet werden wie vom SNEP-Standardserver.
  • MUSS einen SNEP-Client implementieren und versuchen, ausgehende P2P-NDEF an den Standard-SNEP-Server zu senden, wenn Android Beam aktiviert ist. Wenn kein Standard-SNEP-Server gefunden wird, MUSS der Client versuchen, an einen NPP-Server zu senden.
  • Aktivitäten im Vordergrund MÜSSEN die ausgehende P2P-NDEF-Nachricht mithilfe von android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback und android.nfc.NfcAdapter.enableForegroundNdefPush festlegen können.
  • Es sollte eine Geste oder Bestätigung auf dem Bildschirm verwendet werden, z. B. „Zum Übertragen berühren“, bevor ausgehende P2P-NDEF-Nachrichten gesendet werden.
  • Android Beam sollte standardmäßig aktiviert sein
  • MÜSSEN die NFC-Verbindungsweitergabe an Bluetooth unterstützen, wenn das Gerät das Bluetooth Object Push Profile unterstützt. Geräteimplementierungen müssen die Verbindungsweitergabe an Bluetooth unterstützen, wenn android.nfc.NfcAdapter.setBeamPushUris verwendet wird. Dazu müssen die Spezifikationen „Connection Handover version 1.2“ [Ressourcen, 60] und „Bluetooth Secure Simple Pairing Using NFC version 1.0“ [Ressourcen, 61] des NFC Forums implementiert werden. Für eine solche Implementierung MÜSSEN SNEP-GET-Anfragen zum Austausch der Übergabeanfrage / ausgewählten Einträge über NFC verwendet werden. Für die eigentliche Bluetooth-Datenübertragung MUSS das Bluetooth Object Push Profile verwendet werden.
• MUSS im NFC-Erkennungsmodus nach allen unterstützten Technologien suchen.
• MÜSSEN sich im NFC-Erkennungsmodus befinden, während das Gerät aktiv ist, das Display eingeschaltet und der Sperrbildschirm entsperrt ist.

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

Außerdem kann die Geräteimplementierung die Leser-/Schreiberunterstützung 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])

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

• MÜSSEN die entsprechenden Android APIs gemäß der Dokumentation des Android SDK implementieren
• Die Funktion „com.nxp.mifare“ MUSS über die Methode android.content.pm.PackageManager.hasSystemFeature() gemeldet werden. [Ressourcen, 37] Hinweis: Dies ist keine Standardfunktion von Android und wird daher nicht als Konstante in der Klasse PackageManager angezeigt.
• DÜRFEN NICHT die entsprechenden Android APIs implementieren oder die Funktion „com.nxp.mifare“ melden, es sei denn, sie implementieren auch die allgemeine NFC-Unterstützung wie in diesem Abschnitt beschrieben.

Wenn eine Geräteimplementierung keine NFC-Hardware enthält, DARF die Funktion „android.hardware.nfc“ NICHT über die Methode android.content.pm.PackageManager.hasSystemFeature() deklariert werden [Ressourcen, 37] und die NFC API von Android 4.2 MUSS als No-Op implementiert werden.

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

7.4.5. Mindestnetzwerkanforderungen

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

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

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

7.5. Kameras

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

7.5.1. Rückkamera

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

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

7.5.2. Frontkamera

Geräteimplementierungen KÖNNEN eine Frontkamera enthalten. Wenn eine Geräteimplementierung eine Frontkamera enthält, gilt Folgendes:

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

7.5.3. Verhalten der Camera API

Geräteimplementierungen MÜSSEN das folgende Verhalten für die kamerabezogenen APIs sowohl für die Front- als auch für die Rückkamera implementieren:

1. Wenn eine Anwendung android.hardware.Camera.Parameters.setPreviewFormat(int) noch nie aufgerufen hat, MUSS das Gerät android.hardware.PixelFormat.YCbCr_420_SP für Vorschaudaten verwenden, die an Anwendungs-Callbacks übergeben werden.
2. Wenn eine Anwendung eine android.hardware.Camera.PreviewCallback -Instanz registriert und das System die onPreviewFrame()-Methode aufruft, wenn das Vorschauformat YCbCr_420_SP ist, müssen die Daten in der byte[], die an onPreviewFrame() übergeben werden, außerdem im NV21-Codierungsformat vorliegen. Das heißt, NV21 MUSS der Standard sein.
3. Geräteimplementierungen MÜSSEN das YV12-Format (wie durch die Konstante android.graphics.ImageFormat.YV12 angegeben) für Kameravorschauen sowohl für die Front- als auch für die Rückkamera unterstützen. Der Hardware-Videoencoder und die Kamera können beliebige native Pixelformate verwenden, aber die Geräteimplementierung MUSS die Umwandlung in YV12 unterstützen.

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 einen Hardware-Autofokus oder andere Funktionen hat. Kameras ohne Autofokus MÜSSEN beispielsweise alle registrierten android.hardware.Camera.AutoFocusCallback-Instanzen aufrufen, auch wenn dies für eine Kamera ohne Autofokus keine Relevanz hat. Dies gilt auch für Frontkameras. Auch wenn die meisten Frontkameras keinen Autofokus unterstützen, müssen die API-Callbacks wie beschrieben „gefaket“ werden.

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

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

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

7.5.4. Kameraausrichtung

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

7.6. Arbeitsspeicher und Datenspeicher

7.6.1. Mindestarbeitsspeicher und Mindestspeicherplatz

Für Geräteimplementierungen muss mindestens 340 MB Arbeitsspeicher für den Kernel und den Userspace verfügbar sein. Die 340 MB MÜSSEN zusätzlich zu dem Arbeitsspeicher vorhanden sein, der für Hardwarekomponenten wie Radio, Video usw. reserviert ist, die nicht vom Kernel verwaltet werden.

Für die Geräteimplementierung muss mindestens 350 MB nichtflüchtiger Speicher für private Anwendungsdaten verfügbar sein. Die /data-Partition muss also mindestens 350 MB groß sein.

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

7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen

Geräteimplementierungen MÜSSEN freigegebenen Speicher für Anwendungen anbieten. Der bereitgestellte freigegebene Speicher muss mindestens 1 GB groß sein.

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

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

Geräteimplementierungen KÖNNEN Hardware für nutzerzugänglichen, entfernbaren Speicher haben, z. B. eine Secure Digital-Karte. Alternativ KÖNNEN Geräteimplementierungen internen (nicht entfernbaren) Speicher als gemeinsamen Speicher für Apps zuweisen.

Unabhängig von der verwendeten Form des freigegebenen Speichers MÜSSEN Geräteimplementierungen einen Mechanismus zum Zugriff auf den Inhalt des freigegebenen Speichers von einem Hostcomputer bereitstellen, z. B. USB-Massenspeicher (UMS) oder Media Transfer Protocol (MTP). Geräteimplementierungen KÖNNEN USB-Massenspeicher verwenden, MÜSSEN aber das Media-Übertragungsprotokoll verwenden. Wenn die Geräteimplementierung das Media Transfer Protocol unterstützt:

• Die Geräteimplementierung MUSS mit dem Referenz-Android-MTP-Host, Android File Transfer [Ressourcen, 57], kompatibel sein.
• Die Geräteimplementierung MUSS eine USB-Geräteklasse von 0x00 melden.
• Die Geräteimplementierung sollte den Namen „MTP“ für die USB-Schnittstelle melden.

Wenn die Geräteimplementierung keine USB-Ports hat, muss sie einem Hostcomputer auf andere Weise Zugriff auf den Inhalt des freigegebenen Speichers gewähren, z. B. über ein Netzwerkdateisystem.

Sehen wir uns zwei gängige Beispiele an. Wenn eine Geräteimplementierung einen SD-Kartensteckplatz zur Erfüllung der Anforderung an den freigegebenen Speicher enthält, MUSS dem Gerät eine FAT-formatierte SD-Karte mit einer Größe von mindestens 1 GB beiliegen und standardmäßig bereitgestellt werden. Wenn bei einer Geräteimplementierung ein interner fester Speicher verwendet wird, um diese Anforderung zu erfüllen, MUSS dieser Speicher mindestens 1 GB groß sein und auf /sdcard bereitgestellt werden. Andernfalls MUSS /sdcard ein symbolischer Link zum physischen Speicherort sein, wenn er an anderer Stelle bereitgestellt wird.

Bei Geräteimplementierungen mit mehreren freigegebenen Speicherpfaden (z. B. sowohl ein SD-Kartenslot als auch freigegebener interner Speicher) MÜSSEN die Hauptanwendungen wie der Medienscanner und der ContentProvider so geändert werden, dass Dateien an beiden Speicherorten transparent unterstützt werden.

7.7. USB

Geräteimplementierungen MÜSSEN einen USB-Clientport und einen USB-Hostport enthalten.

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

• Der Anschluss MUSS mit einem USB-Host mit einem Standard-USB-A-Anschluss verbunden werden können.
• Der Anschluss sollte auf Geräteseite den Micro-USB-Formfaktor haben. Wir empfehlen Ihnen dringend, diese Anforderungen unter Android 4.2 zu erfüllen, damit Sie auf zukünftige Plattformversionen aktualisieren können.
• Der Anschluss sollte mittig an einer Kante platziert sein. Bei Geräteimplementierungen sollte der Anschluss entweder an der Unterseite des Geräts (entsprechend der natürlichen Ausrichtung) platziert oder die Bildschirmdrehung für alle Apps (einschließlich Startbildschirm) aktiviert werden, damit das Display korrekt dargestellt wird, wenn sich das Gerät mit dem Anschluss nach unten befindet. Wir empfehlen Ihnen dringend, diese Anforderungen in Android 4.2 zu erfüllen, damit Sie auf zukünftige Plattformversionen umstellen können.
• Wenn das Gerät andere Anschlüsse hat (z. B. einen anderen Ladeanschluss), sollten diese sich an derselben Seite wie der Micro-USB-Anschluss befinden.
• Es MUSS einem mit dem Gerät verbundenen Host über USB-Massenspeicher oder das Media-Transfer-Protokoll Zugriff auf den Inhalt des freigegebenen Speichervolumes gewähren.
• Es MUSS die Android Open Accessory API und die Spezifikation gemäß der Dokumentation des Android SDK implementieren und MUSS die Unterstützung der Hardwarefunktion android.hardware.usb.accessory angeben. [Ressourcen, 52]
• Es MUSS die USB-Audioklasse implementieren, wie in der Android SDK-Dokumentation beschrieben [Ressourcen, 66]
• Es sollte Unterstützung für die USB-Spezifikation zum Aufladen von Akkus implementieren [Ressourcen, 64] Bestehende und neue Geräte mit Android 4.2 sollten diese Anforderungen in Android 4.2 erfüllen, damit sie auf die zukünftigen Plattformversionen umgestellt werden können.

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

• Es kann einen nicht standardmäßigen Port-Formfaktor haben. In diesem Fall MUSS es jedoch mit einem oder mehreren Kabeln geliefert werden, die den Port an Standard-USB-A anpassen.
• Es MUSS die Android USB Host API gemäß der Dokumentation im Android SDK implementieren und MUSS die Unterstützung der Hardwarefunktion erklären.android.hardware.usb.host [Ressourcen, 53]

Geräteimplementierungen MÜSSEN die Android Debug Bridge implementieren. Wenn bei einer Geräteimplementierung ein USB-Clientport fehlt, MUSS die Android Debug Bridge über ein Local Area Network (z. B. Ethernet oder 802.11) implementiert werden.

8. Leistungskompatibilität

Geräteimplementierungen MÜSSEN die in der folgenden Tabelle definierten wichtigsten Leistungsmesswerte eines mit Android 4.2 kompatiblen Geräts erfüllen:

Messwert	Leistungsgrenzwert	Kommentare
Startzeit der Anwendung	Die folgenden Anwendungen sollten innerhalb der angegebenen Zeit gestartet werden. Browser: weniger als 1.300 ms Kontakte: weniger als 700 Millisekunden Einstellungen: weniger als 700 Millisekunden	Die Startzeit wird als Gesamtzeit gemessen, die zum Laden der Standardaktivität für die Anwendung benötigt wird, einschließlich der Zeit, die zum Starten des Linux-Prozesses, zum Laden des Android-Pakets in die Dalvik-VM und zum Aufrufen von onCreate benötigt wird.
Gleichzeitige Anwendungen	Wenn mehrere Anwendungen gestartet wurden, darf das erneute Starten einer bereits laufenden Anwendung nach dem Start nicht länger als die ursprüngliche Startzeit dauern.

9. Kompatibilität des Sicherheitsmodells

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

9.1. Berechtigungen

Geräteimplementierungen MÜSSEN das Android-Berechtigungsmodell gemäß der Android-Entwicklerdokumentation unterstützen [Ressourcen, 54]. Insbesondere MÜSSEN Implementierungen jede Berechtigung erzwingen, die in der SDK-Dokumentation beschrieben ist. Es dürfen keine Berechtigungen ausgelassen, geändert oder ignoriert werden. Implementierungen KÖNNEN zusätzliche Berechtigungen hinzufügen, sofern die Strings für die neuen Berechtigungs-IDs nicht im Namespace „android.*“ liegen.

9.2. UID und Prozessisolierung

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

9.3. Dateisystemberechtigungen

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

9.4. Alternative Ausführungsumgebungen

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

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

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

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

Alternative Laufzeiten MÜSSEN dem Android-Sandbox-Modell entsprechen. Im Detail:

• Alternative Laufzeiten MÜSSEN Apps über den Paketmanager in separaten Android-Sandboxes (d. h. Linux-Nutzer-IDs usw.) installieren.
• Alternative Laufzeiten KÖNNEN eine einzelne Android-Sandbox bereitstellen, die von allen Anwendungen gemeinsam genutzt wird, die die alternative Laufzeit verwenden.
• Alternative Laufzeiten und installierte Anwendungen, die eine alternative Laufzeit verwenden, dürfen die Sandbox einer anderen auf dem Gerät installierten App NICHT wiederverwenden, es sei denn, dies geschieht über die standardmäßigen Android-Mechanismen für die gemeinsame Nutzer-ID und das Signaturzertifikat.
• Alternative Laufzeiten dürfen NICHT mit den Sandboxes anderer Android-Anwendungen gestartet werden, ihnen NICHT den Zugriff auf diese Sandboxes gewähren und ihnen NICHT den Zugriff auf diese Sandboxes gewähren.

Alternative Laufzeiten dürfen NICHT mit Berechtigungen des Superusers (root) oder einer anderen Nutzer-ID gestartet werden, ihnen dürfen NICHT Berechtigungen des Superusers (root) oder einer anderen Nutzer-ID gewährt werden und sie dürfen anderen Anwendungen NICHT Berechtigungen des Superusers (root) oder einer anderen Nutzer-ID gewähren.

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

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

9.5. Unterstützung mehrerer Nutzer

Android 4.2 unterstützt mehrere Nutzer und bietet eine vollständige Nutzerisolierung. [Ressourcen, 70]

Geräteimplementierungen MÜSSEN die folgenden Anforderungen in Bezug auf die Unterstützung mehrerer Nutzer erfüllen[Ressourcen, 71]:

• Da das Verhalten der Telefonie-APIs auf Geräten mit mehreren Nutzern derzeit nicht definiert ist, darf die Unterstützung mehrerer Nutzer bei Geräteimplementierungen, die android.hardware.telephony deklarieren, NICHT aktiviert werden.
• Geräteimplementierungen MÜSSEN für jeden Nutzer ein Sicherheitsmodell implementieren, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument „Sicherheit und Berechtigungen“ in den APIs definiert [Ressourcen, 54].

Jede Nutzerinstanz auf einem Android-Gerät MUSS separate und isolierte externe Speicherverzeichnisse haben. Bei Geräteimplementierungen KÖNNEN Daten mehrerer Nutzer auf demselben Volume oder Dateisystem gespeichert werden. Die Geräteimplementierung MUSS jedoch dafür sorgen, dass Anwendungen, die einem bestimmten Nutzer gehören und im Namen dieses Nutzers ausgeführt werden, keine Daten auflisten, lesen oder darauf schreiben können, die einem anderen Nutzer gehören. Hinweis: Über Wechselmedien wie SD-Kartensteckplätze kann ein Nutzer über einen Host-PC auf die Daten eines anderen Nutzers zugreifen. Aus diesem Grund MÜSSEN Geräteimplementierungen, die Wechselmedien für die externen Speicher-APIs verwenden, den Inhalt der SD-Karte verschlüsseln, wenn die Mehrfachnutzung aktiviert ist, und zwar mit einem Schlüssel, der nur auf nicht entfernbaren Medien gespeichert ist, auf die nur das System zugreifen kann. Da die Medien dadurch für einen Host-PC nicht mehr lesbar sind, müssen Geräteimplementierungen zu MTP oder einem ähnlichen System wechseln, um Host-PCs Zugriff auf die Daten des aktuellen Nutzers zu gewähren. Daher KÖNNEN, aber sollten nicht, Geräteimplementierungen die Nutzung durch mehrere Nutzer aktivieren, wenn sie Wechseldatenträger [Ressourcen, 72] als primären externen Speicher verwenden. Das Upstream-Open-Source-Android-Projekt enthält eine Implementierung, bei der der interne Gerätespeicher für APIs für externen Speicher von Anwendungen verwendet wird. Geräteimplementierungen sollten diese Konfiguration und Softwareimplementierung verwenden. Bei Geräteimplementierungen mit mehreren externen Speicherpfaden dürfen Android-Apps NICHT auf den sekundären externen Speicher schreiben.

9.6. Warnung zu Premium-SMS

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

10. Softwarekompatibilitätstests

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

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

10.1. Compatibility Test Suite

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

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

10.2. CTS-Verifier

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

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

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

10.3. Referenzanwendungen

Geräteimplementierer MÜSSEN die Implementierungskompatibilität mit den folgenden Open-Source-Anwendungen testen:

• Die Apps „Apps für Android“ [Ressourcen, 55]
• Replica Island (im Android Market verfügbar)

Jede der oben genannten Apps MUSS gestartet werden und sich in der Implementierung korrekt verhalten, damit die Implementierung als kompatibel eingestuft werden kann.

11. Aktualisierbare Software

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

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

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

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

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

12. Kontakt

Sie können sich unter compatibility@android.com an die Autoren des Dokuments wenden, um Fragen zu stellen oder Probleme anzusprechen, die Ihrer Meinung nach nicht im Dokument behandelt werden.

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 auf einem einzelnen Gerät getestet werden. Daher MÜSSEN Geräteimplementierungen auch den unten beschriebenen manuellen Bluetooth-Test bestehen.

Das Testverfahren basiert auf der Beispiel-App „BluetoothChat“, die im Android-Open-Source-Projektbaum enthalten ist. Für die Übertragung sind zwei Geräte erforderlich:

• eine Geräteimplementierung, auf der der zu testende Software-Build ausgeführt wird
• einer separaten Geräteimplementierung, die bereits als kompatibel bekannt ist, und eines Modells der getesteten Geräteimplementierung, also einer „bekannten guten“ Geräteimplementierung

Im folgenden Testverfahren werden diese Geräte als „Kandidat“ und „als funktionierend bekannt“ bezeichnet.

Einrichtung und Montage

1. BluetoothChat.apk über „make samples“ aus einem Android-Quellcodebaum erstellen
2. BluetoothChat.apk auf dem fehlerfreien Gerät installieren
3. BluetoothChat.apk auf dem Testgerät installieren

Bluetooth-Steuerung durch Apps testen

1. BluetoothChat auf dem ausgewählten Gerät starten, während Bluetooth deaktiviert ist
2. Prüfen Sie, ob auf dem ausgewählten Gerät Bluetooth entweder aktiviert wird oder der Nutzer in einem Dialogfeld aufgefordert wird, Bluetooth zu aktivieren.

Kopplung und Kommunikation testen

1. Bluetooth Chat auf beiden Geräten starten
2. Das bekannte Gerät in BluetoothChat über das Dreipunkt-Menü sichtbar machen
3. Suchen Sie auf dem Kandidatengerät über das Menü in BluetoothChat nach Bluetooth-Geräten und koppeln Sie es mit dem Gerät, das Sie als fehlerfrei kennen.
4. Senden Sie von jedem Gerät mindestens zehn Nachrichten und prüfen Sie, ob das andere Gerät sie korrekt empfängt.
5. Schließen Sie die BluetoothChat App auf beiden Geräten, indem Sie die Startbildschirmtaste drücken.
6. Entkoppeln Sie die Geräte über die Einstellungen des jeweiligen Geräts.

Kopplung und Kommunikation in umgekehrter Richtung testen

1. Starten Sie die Bluetooth Chat App auf beiden Geräten.
2. Machen Sie das gewünschte Gerät in BluetoothChat über das Dreipunkt-Menü sichtbar.
3. Suchen Sie auf dem fehlerfreien Gerät in BluetoothChat über das Dreipunkt-Menü nach Bluetooth-Geräten und koppeln Sie es mit dem gewünschten Gerät.
4. Senden Sie von jedem Gerät 10 Nachrichten und prüfen Sie, ob das andere Gerät sie richtig empfängt.
5. Schließen Sie die Bluetooth Chat App auf beiden Geräten, indem Sie wiederholt die Schaltfläche „Zurück“ drücken, bis Sie den Launcher aufrufen.

Testwiederholungen

1. Starten Sie die Bluetooth Chat App auf beiden Geräten neu.
2. Senden Sie von jedem Gerät 10 Nachrichten und prüfen Sie, ob das andere Gerät sie richtig empfängt.

Hinweis: In den obigen Tests wird in einigen Fällen der Testabschnitt mit der Schaltfläche „Startseite“ und in anderen mit der Schaltfläche „Zurück“ beendet. Diese Tests sind nicht redundant und nicht optional: Ziel ist es, zu prüfen, ob die Bluetooth API und der Bluetooth-Stack sowohl dann ordnungsgemäß funktionieren, wenn Aktivitäten explizit beendet werden (durch Drücken der Schaltfläche „Zurück“, was die Funktion „finish()“ aufruft), als auch dann, wenn sie implizit in den Hintergrund gesendet werden (durch Drücken der Schaltfläche „Startbildschirm“). Jede Testabfolge MUSS wie beschrieben durchgeführt werden.