Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Kompatibilitätsdefinition für Android 4.1
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Kompatibilitätsdefinition für Android 4.1
Version 3
Letzte Aktualisierung: 24. Juni 2013
Copyright © 2012, Google Inc. Alle Rechte vorbehalten.
compatibility@android.com
Inhaltsverzeichnis
1. Einführung
2. Ressourcen
3. Software
3.1. Verwaltete API-Kompatibilität
3 .2. Soft API-Kompatibilität
3.2.1. Berechtigungen
3.2.2. Build-Parameter
3.2.3. Intent-Kompatibilität
3.2.3.1. Core Application Intents
3 .2.3.2. Intent-Überschreibungen
3.2.3.3. Intent-Namespaces
3.2.3.4. Broadcast-Intents
3.3. Native API-Kompatibilität
3.3.1 Anwendungs-Binärschnittstellen
3.4. Webkompatibilität
3.4.1. WebView-Kompatibilität
3.4.2. Browserkompatibilität
3.5. API-Verhaltenskoompatibilität
3.6. API-Namespaces
3.7. Kompatibilität mit virtuellen Maschinen
3.8. Kompatibilität der Benutzeroberfläche
3.8.1. Widgets
3.8.2. Benachrichtigungen
3.8.3. Suchen
3.8.4. Toasts
3.8.5. Designs
3.8.6. Live Wal papers
3.8.7. Letzten App-Anzeige
3.8.8. Eingabeverwaltung Einstellungen
3.8.9. Sperrbildschirm-Fernsteuerung
3.9 Geräteverwaltung
3.10 Barrierefreiheit
3.11 Sprachausgabe
4. Kompatibilität von Anwendungs-Packaging
5. Multimedia-Kompatibilität
5.1. Medien-Codecs
5.2. Videocodierung
5.3. Audioaufnahme
5.4. Audiolatenz
5.5. Netzwerkprotokolle
6. Kompatibilität von Entwicklertools
7. Hardwarekompatibilität
7.1. Display und Grafik
7.1.1. Bildschirmkonfiguration
7.1.2. Displaymesswerte
7.1.3. Bildschirmausrichtung
7.1.4. 2D- und 3D-Grafikbeschleunigung
7.1.5. Kompatibilitätsmodus für ältere Anwendungen
7.1.6. Displaytypen
7.1.7. Bildschirmtechnologie
7.2. Unter Eingabegeräte
7.2.1. Tastatur
7.2.2. Bedienung ohne Touchbedienung
7.2.3. Navigationstasten
7.2.4. Touchscreen-Eingabe
7.2.5. Gefälschte Touch-Eingabe
7.2.6. Mikrofon
7.3. Sensoren
7.3.1. Beschleunigungsmesser

7.3.1. Beschleunigungsmesser
7.3.2. Magnetometer
7.3.3. GPS
7.3.4. Gyroskop
7.3.5. Barometer
7.3.6. Thermometer
7.3.7. Photometer
7.3.8. Näherungssensor
7.4. Datenverbindung
7.4.1. Telefonie
7.4.2. IEEE 802.11 (Wi‑Fi)
7.4.2.1. Wi‑Fi Direct
7.4.3. Bluetooth
7.4.4. Nahfeldkommunikation
7.4.5. Mindestnetzwerkanforderungen
7.5. Cameras
7.5.1. Rückkamera
7 .5.2. Frontkamera
7.5.3. Verhalten der Kamera-API
7.5.4. Kameraausrichtung
7.6. Arbeitsspeicher und interner Speicher
7.6.1. Minimaler Arbeitsspeicher und Speicherplatz
7.6.2. Freigegebener Speicherplatz der Anwendung
7.7. USB
8. Leistung Kompatibilität
9. Kompatibilität des Sicherheitsmodells
9.1. Berechtigungen
9.2. UID und Prozessisolierung
9.3. Dateisystemberechtigungen
9.4. Alternative Ausführungsumgebungen
10. Softwarekompatibilitätstests
10.1. Compatibility Test Suite
10.2. CTS Verifier
10.3. Referenzanwendungen
11. Aktualisierbare Software
12. Kontakt
Anhang A – Bluetooth-Testverfahren

1. Einführung
In diesem Dokument werden die Anforderungen aufgeführt, die erfüllt sein müssen, damit Geräte
mit Android 4.1 kompatibel sind.
Die Verwendung von „muss“, „darf nicht“, „erforderlich“, „wird“, „wird nicht“, „sollte“, „sollte nicht“,
„empfohlen“, „kann“ und „optional“ entspricht dem IETF-Standard, der in RFC 2119
[Ressourcen, 1] definiert ist.
Im Rahmen dieses Dokuments bezeichnet ein „Geräteimplementierer“ oder „Implementierer“ eine Person oder
Organisation, die eine Hardware-/Softwarelösung mit Android 4.1 entwickelt. Eine „
Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte Hardware-/Softwarelösung.
Damit Geräteimplementierungen als mit Android 4.1 kompatibel gelten, MÜSSEN sie die
Anforderungen in dieser Kompatibilitätsdefinition erfüllen, einschließlich aller
Dokumente, die durch Verweis einbezogen werden.
Wenn diese Definition oder die in Abschnitt 10 beschriebenen Softwaretests nicht eindeutig oder unvollständig sind, liegt es in der Verantwortung des Geräteimplementators, für die
Kompatibilität mit vorhandenen Implementierungen zu sorgen.

Aus diesem Grund ist das Android Open Source Project [Ressourcen, 3] sowohl die Referenz-
als auch die bevorzugte Implementierung von Android. Geräteimplementierer werden dringend
aufgefordert, ihre Implementierungen nach Möglichkeit auf dem
„Upstream“-Quellcode zu basieren, der im Android Open Source Project verfügbar ist. Auch wenn einige
Komponenten hypothetisch durch alternative Implementierungen ersetzt werden können, wird von dieser
Praxis dringend abgeraten, da das Bestehen der Softwaretests
erheblich schwieriger wird. Es liegt in der Verantwortung des Implementators, für eine vollständige
Verhaltenskompatibilität mit der Standard-Android-Implementierung zu sorgen, einschließlich und über die
Compatibility Test Suite hinaus. Bestimmte Komponentenersetzungen und
Änderungen sind gemäß diesem Dokument ausdrücklich verboten.
2. Ressourcen
1.  IETF RFC2119-Anforderungen: http://www.ietf.org/rfc/rfc2119.txt
2.  Android-Kompatibilitätsprogramm – Übersicht:
http://source.android.com/compatibility/index.html
3.  Android Open Source Project: 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.1:
http://source.android.com/compatibility/4.1/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.  android.webkit.WebView-Klasse:
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-Webdatenbank API: http://www.w3.org/TR/webdatabase/
16.HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17.  Dalvik Virtual Machine-Spezifikation: Verfügbar im Android-Quellcode unter
dalvik/docs
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.  App-Ressourcen: 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.  Designs: http://developer.android.com/guide/topics/ui/themes.html

25.  R.style-Klasse: http://developer.android.com/reference/android/R.style.html
26.  Live-Hintergründe: http://developer.android.com/resources/articles/live-
wal papers.html
27.  Android-Geräteverwaltung:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  android.app.admin.DevicePolicyManager-Klasse:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  Android Accessibility Service APIs:
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):
http://developer.android.com/guide/developing/tools/index.html
34.  Beschreibung der Android-APK-Datei:
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 Hardware
Funktionen
Liste:
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/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.  android.hardware.Camera:
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 Android-Sicherheit und Berechtigungen:
http://developer.android.com/guide/topics/security/security.html
55.  Apps für Android: http://code.google.com/p/apps-for-android
56.  android.app.DownloadManager-Klasse:
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 Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60.  NFC-Verbindungsübergabe: 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-Ladestandard:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65.  Android Beam: https://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.  Android-NFC-Freigabeeinstellungen:
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.  Media Remote Control Client:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  Motion Event API:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  Konfiguration der Touchbedienung: http://source.android.com/tech/input/touch-
devices.html
Viele dieser Ressourcen stammen direkt oder indirekt aus dem Android 4.1 SDK
und sind funktional mit den Informationen in der Dokumentation dieses SDK identisch.
Wenn diese Definition der Kompatibilität oder die Kompatibilitätstestsuite nicht mit der
SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als maßgebend. Alle
technischen Details, die in den oben aufgeführten Referenzen angegeben sind, werden durch
Einbeziehung als Teil dieser Kompatibilitätsdefinition angesehen.
3. Software
3.1. Kompatibilität mit verwalteten APIs
Die verwaltete (Dalvik-basierte) Ausführungsumgebung ist das primäre Medium für Android-
Anwendungen. Die Android-API (Application Programming Interface) besteht aus
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.1 SDK [Ressourcen, 4] bereitgestellt werden, einschließlich aller dokumentierten Verhaltensweisen.

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 zulässig.
Diese Kompatibilitätsdefinition erlaubt einige Arten von Hardware, für die Android
APIs enthält, die von Geräteimplementierungen weggelassen werden können. In solchen Fällen MÜSSEN
die APIs vorhanden sein und sich angemessen verhalten. Die spezifischen
Anforderungen für dieses Szenario finden Sie in Abschnitt 7.
3.2. Soft-API-Kompatibilität
Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 enthält Android auch eine wichtige
„Soft“-API, die nur zur Laufzeit verfügbar ist. Dazu gehören z. B. 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 Seite „Berechtigungsreferenz“
dokumentiert [Ressourcen, 5]. In Abschnitt 10
sind zusätzliche Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell aufgeführt.
3.2.2. Build-Parameter
Die Android APIs enthalten eine Reihe von Konstanten in der Klasse „android.os.Build“
[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
eingehalten werden MÜSSEN.
Parameter
Kommentare
Die Version des derzeit ausgeführten Android-Systems in einem für Menschen lesbaren Format. Dieses Feld MUSS einen der in [Resources, 7] definierten Stringwerte
android.os.Build.VERSION.RELEASE
enthalten.
Die Version des derzeit ausgeführten Android-Systems in einem Format, das für den Anwendungscode von Drittanbietern zugänglich ist.
android.os.Build.VERSION.SDK
Für Android 4.1 MUSS dieses Feld den Ganzzahlwert 16 haben.

Die Version des derzeit ausgeführten Android-Systems in einem Format, das für den Code von Drittanbieteranwendungen zugänglich ist.
android.os.Build.VERSION.SDK_INT
Bei Android 4.1 MUSS dieses Feld den Ganzzahlwert 16 haben.
Ein vom Geräteimplementierer ausgewählter Wert, der den Build des derzeit ausgeführten Android-
Systems in einem für Menschen lesbaren Format angibt. Dieser Wert darf NICHT für verschiedene Builds wiederverwendet werden, die für Endnutzer von
android.os.Build.VERSION.INCREMENTAL
zur Verfügung gestellt werden. Dieses Feld wird in der Regel verwendet, um anzugeben, welche Build-Nummer oder Änderungs-ID der Quellkontrolldatei zum Generieren des Builds verwendet wurde.
Es gibt keine Anforderungen an das spezifische Format dieses Felds, außer dass es
NICHT null oder der leere String ("") sein darf.
Ein vom Geräteimplementierer ausgewählter Wert, der die vom Gerät verwendete spezifische interne Hardware in einem
lesbaren Format angibt. Dieses Feld kann beispielsweise verwendet werden, um die spezifische Version des Boards anzugeben,
android.os.Build.BOARD
das das Gerät antreibt. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck
"^[a-zA-Z0-9.,_-]+$" entsprechen.
Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Unternehmens, der Organisation, der Person usw.
identifiziert, die das Gerät hergestellt hat, in einem visuell lesbaren Format. Dieses Feld kann beispielsweise verwendet werden, um den OEM
android.os.Build.BRAND
und/oder den 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.
Der Name des Instruction-Sets (CPU-Typ + ABI-Konvention) des Native-Codes. Siehe Abschnitt 3.3:
android.os.Build.CPU_ABI
Kompatibilität
Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des Native-Codes. Siehe Abschnitt 3.3: Native
android.os.Build.CPU_ABI2
API-Kompatibilität
Wert, der vom Geräteimplementierer ausgewählt wird und die spezifische Konfiguration oder Version des Gehäuses angibt
android.os.Build.DEVICE
(manchmal auch „Industriedesign“ genannt) des Geräts. Der Wert dieses Felds MUSS als 7‑Bit-
ASCII codierbar sein und dem regulären Ausdruck „^[a-zA-Z0-9.,_-]+$“ entsprechen.
Ein String, der diese Build eindeutig identifiziert. Sie SOLLTE für Menschen gut lesbar sein. Sie MUSS dieser
Vorlage folgen:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Beispiel:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
Der Fingerabdruck DARF KEINE Leerzeichen enthalten. Wenn andere Felder in der Vorlage oben
Leerzeichen enthalten, MÜSSEN sie im Build-Fingerabdruck durch ein anderes Zeichen ersetzt werden, z. B. durch das
Zeichen „_“. Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein.
Name der Hardware (aus der Kernel-Befehlszeile oder /proc). Er sollte für Menschen einigermaßen lesbar sein.
android.os.Build.HARDWARE
Der Wert dieses Felds MUSS als 7-Bit-ASCII codierbar sein und dem regulären Ausdruck „^[a-
zA-Z0-9.,_-]+$“ entsprechen.
Ein String, der den Host, auf dem der Build erstellt wurde, eindeutig identifiziert, in einem visuell lesbaren Format. Es gibt keine
android.os.Build.HOST
Anforderungen an das spezifische Format dieses Felds, mit Ausnahme der Tatsache, dass es NICHT null oder der leere String („"") sein darf.
Eine vom Geräteimplementierer ausgewählte Kennung, die sich auf eine bestimmte Version bezieht, in einem visuell lesbaren Format. Dieses
Feld kann mit „android.os.Build.VERSION.INCREMENTAL“ identisch sein, sollte aber einen
android.os.Build.ID
ausreichenden Wert haben, damit Endnutzer zwischen Software-Builds unterscheiden können. Der Wert dieses Felds MUSS als 7‑Bit-ASCI codierbar sein
und dem regulären Ausdruck „^[a-zA-Z0-9.,_-]+$“ entsprechen.
Der Handelsname des Original Equipment Manufacturers (OEM) des Produkts. Es gibt keine Anforderungen an
android.os.Build.MANUFACTURER
das spezifische Format dieses Felds, mit Ausnahme der Tatsache, dass es NICHT null oder der leere String („"") sein darf.
Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endnutzer bekannt ist. Dieser
android.os.Build.MODEL
sollte mit dem Namen übereinstimmen, unter dem das Gerät vermarktet und an Endnutzer verkauft wird. Es gibt keine
Anforderungen an das spezifische Format dieses Felds, außer dass es NICHT null oder der leere String („"") sein darf.
Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder den Codenamen des Produkts
android.os.Build.PRODUCT
(SKU) enthält. MUSS menschenlesbar sein, ist 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.
Eine Hardware-Seriennummer, falls verfügbar. Der Wert dieses Felds MUSS als 7-Bit-ASCI codierbar sein und dem regulären Ausdruck
android.os.Build.SERIAL
„^([a-zA-Z0-9]{0,20})$" entsprechen.
Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt werden und die Build weiter unterscheiden. Beispiel:
android.os.Build.TAGS
„unsigned,debug“. Der Wert dieses Felds MUSS als 7-Bit-ASCI codierbar sein und dem regulären Ausdruck
"^[a-zA-Z0-9.,_-]+$" entsprechen.
android.os.Build.TIME
Ein Wert, der den Zeitstempel des Builds angibt.
Wert, der vom Geräteimplementierer ausgewählt wird und die Laufzeitkonfiguration des Builds angibt. Dieses Feld
SOLLTE einen der Werte haben, die den drei gängigen Android-Laufzeitkonfigurationen entsprechen: „user“,
android.os.Build.TYPE
„userdebug“ oder „eng“. Der Wert dieses Felds MUSS als 7-Bit-ASCI codierbar sein und dem regulären Ausdruck
„^[a-zA-Z0-9.,_-]+$“ entsprechen.
Name oder Nutzer-ID des Nutzers (oder automatisierten Nutzers), der den Build generiert hat. Es gibt keine Anforderungen an das spezifische Format dieses Felds
android.os.Build.USER
, außer dass es NICHT null oder der leere String („"") sein darf.
3.2.3. Intent-Kompatibilität
Geräteimplementierungen MÜSSEN das lose gekoppelte Intent-System von Android einhalten,

wie in den folgenden Abschnitten beschrieben. Mit „geachtet“ ist gemeint, dass der Geräteimplementierer
EINE Android-Aktivität oder EINEN Android-Dienst angeben MUSS, der einen übereinstimmenden Intent-Filter angibt und
für jedes angegebene Intent-Muster das richtige Verhalten bindet und implementiert.
3.2.3.1. Intents für Hauptanwendungen
Das Android-Upstream-Projekt definiert eine Reihe von Hauptanwendungen, z. B. Kontakte,
Kalender, Fotogalerie, Musikplayer usw. 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 das Intent-Muster von Drittanbieter-Apps zur Auswahl eines Songs einhalten.
Die folgenden Anwendungen gelten als Android-System-Kernanwendungen:
Wecker
Browser
Kalender
Kontakte
Galerie
GlobalSearch
Launcher
Musik
Einstellungen
Die Android-System-Kernanwendungen 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, die bzw. der in einer der Android-Kernsystem-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 die
selben Intent-Filtermuster wie die Android-Kernsystem-App implementiert.
Mit anderen Worten: Eine Geräteimplementierung DARF Android-Kernsystem-Apps ersetzen.
In diesem Fall MUSS die Geräteimplementierung jedoch alle Intent-Muster unterstützen, die von jeder ersetzten Android-Kernsystem-App definiert werden.

3.2.3.2. Intent-Überschreibungen
Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen es zulassen, dass jedes Intent
-Muster, auf das in Abschnitt 3.2.3.2 verwiesen wird, von Drittanbieter-Apps überschrieben wird. Die
Upstream-Open-Source-Implementierung von Android erlaubt dies standardmäßig.
Geräteimplementierer DÜRFEN KEINE speziellen Berechtigungen für die Verwendung dieser Intent-Muster durch Systemanwendungen zuweisen oder verhindern, dass Anwendungen von Drittanbietern diese Muster binden und steuern.

Dieses Verbot umfasst unter anderem die
Deaktivierung der Benutzeroberfläche „Chooser“, über die Nutzer zwischen mehreren
Anwendungen auswählen können, die 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 spezifischeren 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äte
implementierungen 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 Namespace „android.*“ oder „com.android.*“ berücksichtigen.

Geräteimplementierer DÜRFEN KEINE
Android-Komponenten einbinden, die neue Intent- oder Broadcast Intent-Muster berücksichtigen
, die einen ACTION-, CATEGORY- oder anderen Schlüsselstring in einem Paketbereich verwenden, der zu einer anderen Organisation gehört.
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 ihrer
eigenen Organisation verknüpft sind.
Dieses Verbot entspricht dem für Java-Sprachklassen in Abschnitt
3.6.
3.2.3.4. Intents übertragen
Drittanbieteranwendungen nutzen die Plattform, um bestimmte Intents zu übertragen, um sie

über Änderungen in der Hardware- oder Softwareumgebung zu benachrichtigen. Android-kompatible Geräte
MÜSSEN die öffentlichen Intents als Reaktion auf entsprechende System
ereignisse senden. Broadcast-Intents werden in der SDK-Dokumentation beschrieben.
3.3. Native API Compatibility
3.3.1 Application Binary Interfaces
Verwalteter Code, der in Dalvik ausgeführt wird, kann auf nativen Code zugreifen, der in der Anwendung
.apk-Datei als ELF-.so-Datei für die entsprechende Gerätehardwarearchitektur kompiliert wurde.
Da nativer Code stark von der zugrunde liegenden Prozessortechnologie abhängt,
definiert Android eine Reihe von Application Binary Interfaces (ABIs) im Android NDK in der Datei
docs/CPU-ARCH-ABIS.html. Wenn eine Geräteimplementierung mit einer oder mehreren
definierten ABIs kompatibel ist, MUSS sie die Kompatibilität mit dem Android NDK implementieren, wie unten beschrieben.
Wenn eine Geräteimplementierung Unterstützung für eine Android-ABI enthält, gilt Folgendes:
MUSS Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um
nativen Code anhand der Standard-Semantik von Java Native Interface (JNI) aufzurufen.
MUSS quellkompatibel (d.h. Header-kompatibel) und binärkompatibel (für
die ABI) mit jeder erforderlichen Bibliothek in der Liste unten sein
MUSS über die API „android.os.Build.CPU_ABI“ die native Application Binary Interface (ABI) melden, die vom Gerät unterstützt wird
MUSS nur die ABIs melden, die in der neuesten Version des Android
NDK in der Datei „docs/CPU-ARCH-ABIS.txt“ dokumentiert sind
SOLLTE mit dem Quellcode und den Headerdateien erstellt werden, die im
Upstream-Android-Open-Source-Projekt verfügbar sind
Die folgenden Native-Code-APIs 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-Logging)
libz (Zlib-Komprimierung)
libdl (dynamischer Linker)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (native OpenGL-Oberflächenverwaltung)
libjnigraphics.so
libOpenSLES.so (OpenSL ES 1.0.1-Audiounterstützung)
libOpenMAXAL.so (OpenMAX AL 1.0.1-Unterstützung)
libandroid.so (native Android-Aktivitätsunterstützung)
Unterstützung für OpenGL, wie unten beschrieben
Hinweis: 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 einer vorhandenen vordefinierten ABI kompatibel ist, darf sie
KEINE Unterstützung für eine ABI melden .
Die Kompatibilität mit Native Code ist eine Herausforderung. Aus diesem Grund wird
Geräteimplementern 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 Android-Open-Source-Implementierung verwendet die WebKit-Rendering-Engine, um
die 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 534.30-WebKit-Build aus dem Upstream-Android-Open-Source-Tree
für Android 4.1 basieren. Dieser Build enthält eine Reihe von Funktions- und Sicherheits
korrekturen für die WebView. Geräteimplementierer KÖNNEN Anpassungen an der
WebKit-Implementierung vornehmen. Solche Anpassungen DÜRFEN das
Verhalten der WebView jedoch nicht ändern, einschließlich des Rendering-Verhaltens.
Der von der WebView gemeldete User-Agent-String MUSS dieses Format haben:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, wie Gecko) Version/4.1
Mobile Safari/534.30
Der Wert des Strings $(VERSION) MUSS mit dem Wert für

Der Wert des Strings $(VERSION) MUSS mit dem Wert für
android.os.Build.VERSION.RELEASE übereinstimmen.
Der Wert des Strings $(LOCALE) SOLLTE den ISO-Konventionen für
Landescode und Sprache entsprechen und SOLLTE sich auf das aktuell konfigurierte
Land 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.
In Geräteimplementierungen KANN „Mobile“ im User-Agent-String weggelassen werden.
Die WebView-Komponente SOLLTE so weit wie möglich HTML5 unterstützen.
[Ressourcen, 11] Mindestens MÜSSEN Geräteimplementierungen alle
diesen APIs unterstützen, die mit HTML5 in der WebView verknüpft sind:
Anwendungscache/Offlinebetrieb [Ressourcen, 12]
das <video>-Tag [Ressourcen, 13]
Standortbestimmung [Resourcen, 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 Standardsteuerstellen für die Webentwicklung
IndexedDB anstelle von Webstorage bevorzugen, wird IndexedDB voraussichtlich in einer zukünftigen Version von Android zu einer erforderlichen
Komponente werden.
HTML5-APIs, wie alle JavaScript-APIs, MÜSSEN 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
Websurfen von Nutzern 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,
auf WebKit basieren, wie in Abschnitt 3.4.1 beschrieben.
In Implementierungen kann ein benutzerdefinierter User-Agent-String in der eigenständigen Browseranwendung
enthalten sein.
Die eigenständige Browseranwendung (unabhängig davon, ob sie auf der Upstream-
WebKit-Browseranwendung oder einem Drittanbieter-Ersatz basiert) SOLLTE möglichst viel
HTML5 [Ressourcen, 11] unterstützen. Mindestens müssen Geräteimplementierungen
jede dieser mit HTML5 verknüpften APIs unterstützen:
Anwendungscache/Offlinebetrieb [Ressourcen, 12]
das <video>-Tag [Ressourcen, 13]
Standortbestimmung [Ressourcen, 14]
Außerdem müssen Geräteimplementierungen die HTML5/W3C Web Storage 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 werden.
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 [Ressourcen, 3] übereinstimmen. Einige Bereiche der Kompatibilität sind:
Geräte DÜRFEN das Verhalten oder die Semantik einer Standard-Intent NICHT ändern
Geräte DÜRFEN den Lebenszyklus oder die Lebenszyklussemantik eines bestimmten Typs von
Systemkomponenten (z. B. Dienst, Aktivität, Contentanbieter usw.) NICHT ändern
Geräte DÜRFEN die Semantik einer Standardberechtigung NICHT ändern
Die obige Liste ist nicht vollständig. Die Compatibility Test Suite (CTS) testet
wichtige Teile der Plattform auf Verhaltenskompatibilität, aber nicht alle . Es liegt in der
Verantwortung des Implementators, für die Verhaltenskompatibilität mit dem Android
Open-Source-Projekt zu sorgen. Aus diesem Grund SOLLTEN Geräteimplementierer nach Möglichkeit den Quell
code verwenden, der über das Android Open Source Project verfügbar ist, anstatt wichtige Teile des Systems neu zu implementieren.

3.6. API-Namespaces
Android folgt den von der Programmiersprache Java

definierten Konventionen für Paket- und Klassen-Namespaces. Um die Kompatibilität mit Anwendungen von Drittanbietern zu gewährleisten, dürfen
Geräteimplementierer KEINE verbotenen Änderungen (siehe unten) an diesen
Paket-Namespaces vornehmen:
java.*
javax.*
sun.*
android.*
com.android.*
Zu den unzulässigen Änderungen gehören:
Geräteimplementierungen DÜRFEN die öffentlich zugänglichen APIs auf der
Android-Plattform NICHT ändern, indem sie Methoden- oder Klassensignaturen ändern oder
Klassen oder Klassenfelder entfernen.
Geräteimplementierer DÜRFEN die zugrunde liegende Implementierung der APIs ändern.
Solche Änderungen DÜRFEN jedoch NICHT das angegebene Verhalten und die Java-
Signatur der öffentlich zugänglichen APIs beeinflussen.
Geräteimplementierer DÜRFEN den oben genannten APIs KEINE öffentlich zugänglichen Elemente hinzufügen, z. B.
Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen.

Ein „öffentlich zugängliches Element“ ist jedes Konstrukt, das nicht mit der Markierung „@hide“
versehen ist, wie sie im Upstream-Android-Quellcode verwendet wird. Mit anderen Worten:
Geräteimplementierer DÜRFEN KEINE neuen APIs freigeben oder vorhandene APIs in den oben genannten Namespaces ändern.
Geräteimplementierer DÜRFEN nur interne Änderungen vornehmen. Diese
Änderungen DÜRFEN NICHT beworben oder Entwicklern anderweitig zugänglich gemacht werden.
Geräteimplementierer KÖNNEN benutzerdefinierte APIs hinzufügen. Diese APIs DÜRFEN jedoch NICHT in einem
Namespace enthalten sein, der einer anderen Organisation gehört oder sich auf diese bezieht.
Geräteimplementierer dürfen dem Namespace „com.google.*“ oder einem ähnlichen Namespace KEINE APIs hinzufügen. Das darf nur Google tun. Ebenso darf Google KEINE APIs zu Namespaces anderer Unternehmen hinzufügen.

Wenn eine Geräteimplementierung benutzerdefinierte APIs außerhalb des
Standard-Android-Namensraums enthält, MÜSSEN diese APIs in einer
freigegebenen Android-Bibliothek verpackt werden, damit nur Apps, die sie explizit verwenden (über den Mechanismus <uses-library>
), von der erhöhten Speichernutzung dieser APIs betroffen sind.
Wenn ein Geräteimplementierer vorschlägt, einen der oben genannten Paket-Namespaces 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 der Bereitstellung 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 bekräftigen und durch Aufnahme in diese Kompatibilitätsdefinition verbindlich machen.

3.7. Kompatibilität mit virtuellen Maschinen
Geräteimplementierungen MÜSSEN die vollständige
Bytecodespezifikation der Dalvik-Ausführbaren (DEX) und die Semantik der Dalvik-Virtuellen Maschine unterstützen [Ressourcen, 17].
Geräteimplementierungen MÜSSEN Dalvik so konfigurieren, dass Speicher gemäß der Upstream-Android-Plattform und wie in der folgenden Tabelle angegeben zugewiesen wird.
(Definitionen für Bildschirmgröße und Bildschirmdichte finden Sie unter
Abschnitt 7.1.1.)
Die unten angegebenen Speicherwerte gelten als Mindestwerte. Die
Geräteimplementierung kann mehr Speicher pro Anwendung zuweisen.
Displaygröße
Displaydichte
Anwendungsspeicher
smal  / normal / large
ldpi / mdpi
16 MB
smal  / normal / large
tvdpi / hdpi
32 MB
smal  / normal / large
xhdpi
64 MB
xlarge
mdpi
32 MB
xlarge
tvdpi / hdpi
64 MB
xlarge
xhdpi
128 MB
3.8. Kompatibilität der Benutzeroberfläche
3.8.1. Widgets
Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, die es

Anwendungen ermöglichen, dem Endnutzer ein „AppWidget“ zur Verfügung zu stellen [Resources, 18]. Die Android
Open Source-Referenzversion enthält eine Launcher-Anwendung mit Funktionen für die
Benutzeroberfläche, die es dem Nutzer ermöglichen, App-Widgets auf dem
Startbildschirm hinzuzufügen, anzusehen und zu entfernen.
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. Alternative Launcher MÜSSEN diese Elemente der
Benutzeroberfläche NICHT enthalten. Wenn sie jedoch nicht enthalten sind, 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 informieren können
[Ressourcen, 19], indem sie Hardware- und Softwarefunktionen des Geräts verwenden.
Einige APIs ermöglichen es Apps, Benachrichtigungen zu senden oder mithilfe von
Hardware, insbesondere Ton, Vibration und Licht, Aufmerksamkeit zu 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 keine Hardware vorhanden ist,
MÜSSEN die entsprechenden APIs als No-Ops implementiert werden. Dieses Verhalten wird
in Abschnitt 7 ausführlicher beschrieben.
Außerdem MUSS die Implementierung alle in den APIs [Ressourcen, 20] oder im Stilhandbuch für Symbole der Status-/Systemleiste [Ressourcen, 21] bereitgestellten Ressourcen (Symbole,
Tondateien usw.) korrekt darstellen.
Geräteimplementierer KÖNNEN eine alternative
Benutzeroberfläche für Benachrichtigungen bereitstellen, die von der Referenzimplementierung der Android-Open-Source-
Software abweicht. Solche alternativen Benachrichtigungssysteme MÜSSEN jedoch vorhandene
Benachrichtigungsressourcen wie oben beschrieben unterstützen.
Android 4.1 unterstützt erweiterte Benachrichtigungen, z. B. interaktive Ansichten für
laufende Benachrichtigungen. Geräteimplementierungen MÜSSEN Rich
-Benachrichtigungen wie in den Android APIs dokumentiert korrekt anzeigen und ausführen.
3.8.3. Suche
Android enthält APIs [Ressourcen, 22], mit denen Entwickler die Suche in ihre
Anwendungen einbinden und die Daten ihrer Anwendung in die globale Systemsuche einbinden können.
Im Allgemeinen besteht diese Funktion aus einer einzigen systemweiten Benutzeroberfläche
, über die Nutzer Suchanfragen eingeben können, Vorschläge angezeigt werden, während Nutzer tippen, und
Ergebnisse angezeigt werden. Die Android APIs ermöglichen es Entwicklern, diese Benutzeroberfläche wiederzuverwenden, um die Suche in ihren eigenen Apps bereitzustellen, und Ergebnisse für die gemeinsame globale
Suche bereitzustellen.

Geräteimplementierungen MÜSSEN eine einzelne, freigegebene, systemweite Suchoberfläche für Nutzer haben, die Echtzeitvorschläge als Reaktion auf Nutzereingaben liefern kann.

Geräteimplementierungen MÜSSEN die APIs implementieren, die es Entwicklern ermöglichen, diese
Benutzeroberfläche wiederzuverwenden, um in ihren eigenen Anwendungen eine Suche bereitzustellen. Geräteimplementierungen
MÜSSEN die APIs implementieren, die es Drittanbieteranwendungen 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 Suchergebnissen und Vorschlägen der Websuchmaschine erfolgen.
3.8.4. Toasts
Anwendungen können die „Toast“-API (definiert in [Ressourcen, 23]) verwenden, um dem Endnutzer kurze nicht modale Strings anzuzeigen, die nach kurzer Zeit verschwinden.
Geräte
implementierungen MÜSSEN Toasts von Anwendungen an Endnutzer auf eine
gut sichtbare Weise anzeigen.
3.8.5. Designs
Android bietet „Designs“ als Mechanismus für Anwendungen, um Stile auf eine gesamte Aktivität oder Anwendung anzuwenden.
Android 3.0 führte ein neues „Holo“- oder „holografisches“
Design als Reihe von definierten Stilen für Anwendungsentwickler ein, die das
Aussehen und die Benutzerfreundlichkeit des Holo-Designs gemäß der Definition im Android SDK nachahmen möchten [Ressourcen, 24].
Implementierungen auf Geräten dürfen KEINE der Holo-Designattribute ändern, die für

Anwendungen freigegeben sind [Ressourcen, 25].
Mit Android 4.0 wurde das neue Design „Gerätestandard“ eingeführt. Es besteht aus einer Reihe von definierten Stilen, die
Anwendungsentwickler verwenden können, wenn sie das Erscheinungsbild des
Gerätedesigns an das vom Geräteimplementierer definierte Design anpassen möchten. Geräteimplementierungen KÖNNEN die
DeviceDefault-Designattribute ändern, die für Anwendungen freigegeben sind [Resources, 25].
3.8.6. Live-Hintergründe
Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, die es ermöglichen, dass
Anwendungen dem Endnutzer einen oder mehrere „Live-Hintergründe“ zur Verfügung stellen [Ressourcen, 26].
Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabefunktionen, die als Hintergrund hinter anderen Anwendungen 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, zu viel CPU- oder Akkuleistung verbrauchen oder
mit unzumutbar niedrigen Frameraten laufen, ist die Hardware nicht in der Lage,
Live-Hintergründe auszuführen. Einige Live-Hintergründe verwenden beispielsweise einen Open GL 1.0- oder 2.0
-Kontext, um ihre Inhalte zu rendern. Live-Hintergründe funktionieren nicht zuverlässig auf Hardware, die
nicht mehrere OpenGL-Kontexte unterstützt, da die Verwendung eines
OpenGL-Kontexts für den Live-Hintergrund mit anderen Anwendungen in Konflikt stehen kann, die ebenfalls einen OpenGL-Kontext verwenden.
Geräteimplementierungen, die wie oben beschrieben zuverlässig Live-Hintergründe ausführen können, SOLLTEN Live-Hintergründe implementieren.
Geräteimplementierungen, die
Live-Hintergründe nicht zuverlässig wie oben beschrieben ausführen, DÜRFEN KEINE Live-Hintergründe implementieren.
3.8.7. Ansicht der zuletzt verwendeten Apps
Der Upstream-Android 4.1-Quellcode enthält eine Benutzeroberfläche zum Anzeigen der zuletzt verwendeten
Apps mit einem Thumbnail-Bild des grafischen Zustands der Anwendung im
Moment, in dem der Nutzer die Anwendung zuletzt verlassen hat. Geräteimplementierungen KÖNNEN diese Benutzeroberfläche ändern oder
entfernen. In einer zukünftigen Version von Android wird diese Funktion jedoch
ausführlicher genutzt. Bei Geräteimplementierungen wird
dringend empfohlen, die Benutzeroberfläche von Android 4.1 (oder eine ähnliche, auf Miniaturansichten basierende
Benutzeroberfläche) für aktuelle Anwendungen zu verwenden. Andernfalls sind sie möglicherweise nicht mit einer
zukünftigen Version von Android kompatibel.
3.8.8. Einstellungen für die Eingabeverwaltung
Android 4.1 unterstützt Eingabeverwaltungs-Engines. Die Android 4.1-APIs
ermöglichen es benutzerdefinierten App-IMEs, vom Nutzer anpassbare Einstellungen anzugeben. Geräteimplementierungen
MÜSSEN Nutzern jederzeit die Möglichkeit bieten, auf die Einstellungen der Eingabemethode zuzugreifen, wenn eine Eingabemethode angezeigt wird, die solche Nutzereinstellungen bietet.

3.8.9. Sperrbildschirm-Fernsteuerung
Mit Android 4.0 wurde die Remote Control API eingeführt, mit der sich Medienanwendungen in Wiedergabesteuerungen integrieren lassen, die in einer Remote-Ansicht wie dem Sperrbildschirm des Geräts angezeigt werden [Ressourcen, 69].

Geräteimplementierungen MÜSSEN die Unterstützung für die
Einbettung von Steuerelementen für die Fernbedienung in den Sperrbildschirm des Geräts umfassen.
3.9 Geräteverwaltung
Android 4.1 bietet Funktionen, mit denen sicherheitsbewusste Anwendungen
Geräteverwaltungsfunktionen auf Systemebene ausführen können, z. B. die Durchsetzung von Passwortrichtlinien oder
das Ausführen eines Remote-Wipes über die Android Device Administration API [Ressourcen,
27]. Geräteimplementierungen MÜSSEN eine Implementierung der
DevicePolicyManager-Klasse [Resources, 28] bereitstellen und SOLLTEN die gesamte Palette der
Richtlinien zur Geräteverwaltung unterstützen, die in der Android SDK-Dokumentation [Resources,
27] definiert sind.
Hinweis:Einige der oben aufgeführten Anforderungen sind für
Android 4.1 als „SOLLTE“ angegeben. In der Kompatibilitätsdefinition für eine zukünftige Version werden diese
jedoch in „MUSS“ geändert. Diese Anforderungen sind in Android 4.1 optional, werden aber in einer zukünftigen Version
erforderlich sein. Wir empfehlen dringend
, dass Sie diese Anforderungen unter Android 4.1 erfüllen, da Geräte mit Android 4.1 andernfalls nicht mit der zukünftigen Version kompatibel sind.

3.10 Bedienungshilfen
Android 4.1 bietet eine Bedienungshilfenebene, die es Nutzern mit Behinderungen erleichtert, ihre Geräte zu bedienen.
Außerdem bietet Android 4.1 Plattform-APIs, die es

Implementierungen von Barrierefreiheitsdiensten ermöglichen, Rückrufe für Nutzer- und Systemereignisse zu erhalten
und alternative Feedbackmechanismen wie Text-zu-Sprache-, haptisches
Feedback und Navigation per Touchpad /D-Pad zu generieren [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 Bedienungshilfen von Drittanbietern über die APIs von android.accessibilityservice [Resources,
30] unterstützen.
Geräteimplementierungen MÜSSEN Bedienungshilfenereignisse generieren und diese Ereignisse auf eine Weise an alle registrierten Bedienungshilfenimplementierungen senden, die mit der Standardimplementierung von Android übereinstimmt.
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 Intent-Aktion „android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS“ anzeigen.

Außerdem MÜSSEN Geräteimplementierungen einen
Bedienungshilfendienst auf dem Gerät implementieren und einen Mechanismus für Nutzer bereitstellen, mit dem sie
den Bedienungshilfendienst während der Geräteeinrichtung aktivieren können. Eine Open-Source-Implementierung
eines Bedienungshilfendiensts ist im Rahmen des Eyes Free-Projekts verfügbar [Ressourcen, 31].
3.11 Sprachausgabe
Android 4.1 enthält APIs, die es Anwendungen ermöglichen,
Sprachausgabedienste zu nutzen, und Dienstanbietern, TTS-Dienste zu implementieren
[Ressourcen, 32]. Geräteimplementierungen MÜSSEN diese 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-Android-Open-Source-Software 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 nutzerzugängliche Benutzeroberfläche bereitstellen, über die
Nutzer eine TTS-Engine für die Verwendung auf Systemebene auswählen können.
4. Kompatibilität von App-Objekten
Geräteimplementierungen MÜSSEN Android-APK-Dateien installieren und ausführen, die mit dem
Tool „aapt“ erstellt wurden, das im offiziellen Android SDK enthalten ist [Ressourcen, 33].
Geräteimplementierungen dürfen die .apk-[Resources, 34], Android
Manifest-[Resources, 35], Dalvik-Bytecode-[Resources, 17] oder Renderscript-Bytecode
formate nicht so erweitern, dass die Installation und Ausführung dieser Dateien auf anderen kompatiblen Geräten verhindert wird.
Geräteimplementierer SOLLTEN die
Upstream-Implementierung von Dalvik und das
Paketverwaltungssystem der Referenzimplementierung verwenden.
5. Multimedia-Kompatibilität
Geräteimplementierungen MÜSSEN mindestens eine Form von Audioausgabe haben, z. B.
Lautsprecher, Kopfhöreranschluss, Verbindung für externe Lautsprecher usw.
5.1. Medienkods
Geräteimplementierungen MÜSSEN die in der
Android SDK-Dokumentation [Resources, 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
dieser Codecs werden als Softwareimplementierungen in der bevorzugten Android-
Implementierung des Android Open Source Project bereitgestellt.
Weder Google noch die Open Handset Alliance
geben eine
Zusicherung dafür, dass diese Codecs frei von Patenten Dritter sind.
Nutzer, die diesen Quellcode in Hardware- oder Softwareprodukten verwenden möchten,
werden darauf hingewiesen, dass für Implementierungen dieses Codes, einschließlich in Open-Source-Software
oder Shareware, möglicherweise Patentlizenzen der jeweiligen 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 relevanten Standards angegebenen erforderlichen Bitraten entsprechen.
Stattdessen
MÜSSEN Geräteimplementierungen die höchste praktische Bitrate der Hardware unterstützen, bis

zu den in den Spezifikationen definierten Grenzwerten.

Dateityp(en) /
Format /
Typ
Encoder
Decoder
Details
Container
Codec
Formate
Unterstützung für
ERFORDERLICH
Mono/Stereo/5.0/5.1*
MPEG-4
Erforderlich für Geräteimplementierungen
Inhalte mit
AAC-Profil
mit Mikrofonhardware
ERFORDERLICH
Standard-Stichprobenerhebung
(AAC LC)
und Definition von
3GPP
Raten von 8 bis 48
android.hardware.microphone.
(.3gp)
kHz.
Unterstützung
für
MPEG-4
(.mp4,
MPEG-4
Mono/Stereo/5.0/5.1*
.m4a)
HE AAC
Inhalte
mit
ADTS-Roh

ERFORDERLICH
Profil
Standard
AAC-Stichproben
(.aac,
(AAC+)
Raten von 16 bis 48
kHz.
Android
3.1 und höher
Unterstützung
MPEG-4
ERFORDERLICH für die
Gerätecodierung
in
Mono/Stereo/5.0/5.1*
HE AAC v2
Implementierungen, die
Android
Inhalte mit
Profil
Mikrofonhardware und

4.0 und höher
ADIF-Standard
Stichprobenerhebung
(erweiterte
definieren
nicht
Raten von 16 bis 48
AAC+)
android.hardware.microphone
unterstützt)
kHz.
MPEG-TS
MPEG-4
(.ts, nicht
Audio
ERFORDERLICH
Unterstützung
für
suchbare,
Object Type
Implementierungen, die
Mono-/Stereoinhalte
Android
ER AAC
Mikrofonhardware
ERFORDERLICH
mit Standard
3.0+)
ELD
definieren
Abtastraten
(Enhanced
android.hardware.microphone
16 bis 48 kHz.
Niedrige Verzögerung
AAC)
ERFORDERLICH
Erforderlich für Geräteimplementierungen
4,75 bis 12,2 kbps
AMR-NB
mit Mikrofonhardware
ERFORDERLICH
3GPP (.3gp)
mit 8 kHz abgetastet
und definieren
android.hardware.microphone.
ERFORDERLICH
Erforderlich für Geräteimplementierungen
9 Raten von 6,60
AMR-WB
mit Mikrofonhardware
ERFORDERLICH
kbit/s bis 23,85 kbit/s
3GPP (.3gp)
und definieren
bei 16 kHz abgetastet
android.hardware.microphone.
Mono/Stereo (kein
Mehrkanalton).
Audio
Abtastraten bis
48 kHz (
44,1 kHz
wird auf
Geräten mit
FLAC
ERFORDERLICH

44,1
kHz-Ausgang
empfohlen, da der
FLAC

48
(.flac)
(Android 3.1 und höher)
zu 44,1 kHz
Downsampler
keinen
Tiefpass

16-Bit
wird empfohlen;
kein
Dither für 24-Bit.
Mono/Stereo 8–
320 kbit/s
konstante
MP3

ERFORDERLICH
MP3 (.mp3)
(CBR) oder
variable
Bitrate (VBR)
Typ 0 und
MIDI-Typ 0 und 1.
1 (.mid,
DLS-Version 1 und
.xmf, .mxmf)
2. XMF und Mobil
RTTTL/RTX
MIDI

ERFORDERLICH
XMF. Unterstützung für
(.rtttl, .rtx)
Klingeltonformate
OTA (.ota)
RTTTL/RTX, OTA,
iMelody
und iMelody
(.imy)

Ogg (.ogg)
Vorbis

ERFORDERLICH

Matroska
(.mkv)
8‑Bit- und 16‑Bit-
linearer PCM** (Raten
bis zum Limit der
Hardware). Geräte
MÜSSEN
PCM/WAVE
ERFORDERLICH
ERFORDERLICH
WAVE (.wav)
Abtastfrequenzen für
rohe PCM-Aufnahmen
bei 8.000,16.000 und
44.100 Hz

JPEG
ERFORDERLICH
ERFORDERLICH
Base+progressive
JPEG (.jpg)
GIF

ERFORDERLICH

GIF (.gif)
Bild
PNG
ERFORDERLICH
ERFORDERLICH

PNG (.png)
BMP

ERFORDERLICH

BMP (.bmp)
WEBP
ERFORDERLICH
ERFORDERLICH

WebP (.webp)
ERFORDERLICH
Erforderlich für Geräteimplementierungen
3GPP
mit Kamerahardware und
(.3gp)
H.263
ERFORDERLICH

definieren android.hardware.camera
MPEG-4
oder
(.mp4)
android.hardware.camera.front.
3GPP
(.3gp)
ERFORDERLICH
MPEG-4
(.mp4)
Erforderlich für Geräteimplementierungen
MPEG-TS
mit Kamerahardware und
Baseline-Profil
Video
H.264 AVC
ERFORDERLICH
(.ts, AAC
define android.hardware.camera
(BP)
audio only,
or
not
android.hardware.camera.front.
seekable,
Android
3.0+)
MPEG-4

ERFORDERLICH

3GPP (.3gp)
SP
WebM (.webm)
ERFORDERLICH
und Matroska
VP8

(Android

(.mkv, Android
2.3.3+)
4.0+)
*Hinweis: Nur der Downmix von 5.0/5.1-Inhalten ist 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 Aufzeichnung in 8-Bit-linearer PCM
ist nicht obligatorisch.
5.2 Videocodierung
Android-Geräteimplementierungen mit einer Rückkamera und der Deklarierung von
android.hardware.camera MÜSSEN die folgenden Videocodierungsprofile unterstützen.
HD (wenn von der

SD (niedrige Qualität) SD (hohe Qualität)
Hardware unterstützt)
H.264 Baseline
H.264 Baseline
Video-Codec
H.264 Baseline-Profil
Profil
Profil
Video
176 × 144 px
480 × 360 px
1280 × 720 px
Auflösung
Videoframe 12 fps
30 fps
30 fps
rate
500 Kbit/s oder
Videobitrate 56 Kbit/s
2 Mbit/s oder
höher
Audio-Codec AAC-LC
AAC-LC
AAC-LC

Audio
1 (Mono)
2 (Stereo)
2 (Stereo)
Kanäle
Audiobitrate 24 Kbit/s
128 Kbit/s
192 Kbit/s
5.3. Audioaufnahme
Wenn eine Anwendung die API „android.media.AudioRecord“ verwendet hat, um die Aufnahme eines Audiostreams zu starten, MÜSSEN Geräteimplementierungen, die Mikrofonhardware enthalten und „android.hardware.microphone“ deklarieren, Audio mit den folgenden Verhaltensweisen erfassen und aufzeichnen:
Das Gerät SOLLTE eine ungefähr flache Amplitude im Vergleich zur Frequenz aufweisen
, insbesondere ± 3 dB von 100 Hz bis 4.000 Hz.
Die Audioeingabeempfindlichkeit SOLLTE so eingestellt sein, dass eine Quelle mit einer Schallleistungspegel(SPL) von 90 dB bei 1.000 Hz einen RMS-Wert von 2.500 für 16‑Bit-Samples liefert.
Die PCM-Amplitudenwerte SOLLTEN die Änderungen des Eingangs-SPL über mindestens einen Bereich von 30 dB von − 18 dB bis + 12 dB bezogen auf 90 dB SPL am Mikrofon linear 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
einen Audiostream mit der Audioquelle
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION aufnimmt:
Die Geräuschunterdrückung MUSS deaktiviert sein.
Die automatische Lautstärkeregelung MUSS deaktiviert sein.
Hinweis:Einige der oben aufgeführten Anforderungen sind für
Android 4.1 als „SOLLTE“ angegeben. In der Kompatibilitätsdefinition für eine zukünftige Version werden diese jedoch voraussichtlich in „MUSS“ geändert.
Diese Anforderungen sind in Android 4.1 optional, werden aber in einer zukünftigen Version
erforderlich sein. Wir empfehlen dringend
, dass Sie diese Anforderungen unter Android 4.1 erfüllen, da Geräte mit Android 4.1 andernfalls nicht mit der zukünftigen Version kompatibel sind.

5.4. Audiolatenz
Die Audiolatenz wird allgemein als Intervall zwischen dem Zeitpunkt definiert, an dem eine Anwendung eine Audiowiedergabe oder einen Aufnahmevorgang anfordert, und dem Zeitpunkt, an dem die Geräteimplementierung den Vorgang tatsächlich beginnt.

Viele Anwendungsklassen setzen auf kurze Latenzen, um
Echtzeiteffekte wie Soundeffekte oder VoIP-Kommunikation zu erzielen. Geräteimplementierungen
, die Mikrofonhardware enthalten und android.hardware.microphone deklarieren
, MÜSSEN alle in diesem Abschnitt beschriebenen Anforderungen an die Audiolatenz erfüllen. Details zu den Bedingungen, unter denen Mikrofonhardware von Geräteimplementierungen weggelassen werden kann, finden Sie in Abschnitt 7.

Für diesen Abschnitt gilt Folgendes:
Die „kalte Ausgabelatenz“ ist das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung die Audiowiedergabe anfordert, und dem Zeitpunkt, zu dem der Ton wiedergegeben wird, wenn das Audiosystem vor der Anforderung inaktiv und ausgeschaltet war.
Die „warme Ausgabelatenz“ ist das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung die Audiowiedergabe anfordert, und dem Zeitpunkt, zu dem der Ton wiedergegeben wird, wenn das Audiosystem vor der Anforderung aktiv und eingeschaltet war.
Die „kontinuierliche Ausgabelatenz“ ist das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung ein Sample zur Wiedergabe ausgibt, und dem Zeitpunkt, zu dem der Lautsprecher den entsprechenden Ton physisch wiedergibt, während das Gerät gerade Audio wiedergibt.
Die „kalte Eingabelatenz“ ist das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung die Audioaufnahme anfordert, und dem Zeitpunkt, zu dem das erste Sample über den Rückruf an die Anwendung gesendet wird, wenn das Audiosystem und das Mikrofon vor der Anforderung inaktiv und ausgeschaltet waren.
Die „kontinuierliche Eingabelatenz“ ist das Intervall zwischen dem Zeitpunkt, zu dem ein Umgebungsgeräusch auftritt, und dem Zeitpunkt, zu dem das Sample, das diesem Geräusch entspricht, über den Rückruf an eine Aufnahmeanwendung gesendet wird, während sich das Gerät im Aufnahmemodus befindet.
Gemäß den oben genannten Definitionen SOLLTEN Geräteimplementierungen alle folgenden
Eigenschaften aufweisen:
Kalte Ausgabelatenz von 100 Millisekunden oder weniger
Warme Ausgabelatenz von 10 Millisekunden oder weniger
Kontinuierliche Ausgabelatenz von 45 Millisekunden oder weniger
Kalte Eingabelatenz von 100 Millisekunden oder weniger
Kontinuierliche Eingabelatenz von 50 Millisekunden oder weniger
Hinweis:Die oben beschriebenen Anforderungen sind für Android 4.1 als „SOLLTEN“ angegeben.

In der Kompatibilitätsdefinition für eine zukünftige Version sollen diese Anforderungen jedoch in „MÜSSEN“ geändert werden.
Das bedeutet, dass diese Anforderungen in Android 4.1 optional sind, in einer zukünftigen Version jedoch erforderlich sein werden.

Wir empfehlen dringend
, dass Sie diese Anforderungen unter Android 4.1 erfüllen, da Geräte mit Android 4.1 andernfalls nicht
mit der zukünftigen Android-Version kompatibel sind.
Wenn eine Geräteimplementierung die Anforderungen dieses Abschnitts 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.
[Resources, 37]
Wenn die Geräteimplementierung diese Anforderungen nicht erfüllt, darf
KEINE Unterstützung für Audio mit niedriger Latenz gemeldet werden.
5.5. Netzwerkprotokolle
Geräte MÜSSEN die Mediennetzwerkprotokolle für die Audio- und Videowiedergabe unterstützen, wie in der Android SDK-Dokumentation
[Ressourcen, 58] angegeben. Insbesondere müssen Geräte
die folgenden Protokolle für Mediennetzwerke unterstützen:
RTSP (RTP, SDP)
HTTP(S) Progressive Streaming
HTTP(S) Live Streaming Draft Protocol, Version 3 [Resources, 59]
6. Kompatibilität mit 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.
Dalvik Debug Monitor Service (ddms) [Ressourcen, 33]
Geräteimplementierungen MÜSSEN alle ddms-Funktionen unterstützen, wie im
Android SDK dokumentiert. Da ddms adb verwendet, sollte die Unterstützung für ddms standardmäßig inaktiv sein, muss aber unterstützt werden, wenn der Nutzer die Android Debug Bridge wie oben beschrieben aktiviert hat.
Monkey [Ressourcen, 36]
Geräteimplementierungen MÜSSEN das Monkey-Framework enthalten und es für die Verwendung durch Anwendungen verfügbar machen.

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 neue Geräte-IDs benutzerdefinierte USB-Treiber für
Windows-Systeme.) Wenn eine Geräteimplementierung vom adb-Tool nicht erkannt wird, das im Standard-Android-SDK enthalten ist, MÜSSEN die Geräteimplementierer Windows-
Treiber bereitstellen, damit Entwickler eine Verbindung zum Gerät über das adb-Protokoll herstellen können.
Diese
Treiber MÜSSEN für Windows XP, Windows Vista und Windows 7 sowohl in
32‑Bit- als auch in 64‑Bit-Versionen bereitgestellt werden.
7. Hardwarekompatibilität
Wenn ein Gerät eine bestimmte Hardwarekomponente mit einer entsprechenden API für
Drittanbieterentwickler hat, MUSS die Geräteimplementierung diese API gemäß der
Beschreibung in der Android SDK-Dokumentation 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 vorhanden sein
das Verhalten der API MÜSSEN auf angemessene Weise als No-Ops implementiert sein
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, sofern Nullwerte in der SDK-Dokumentation nicht zulässig sind
API-Methoden DÜRFEN KEINE Ausnahmen auslösen, die nicht in der SDK-Dokumentation dokumentiert sind
Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telephony API:
Selbst auf Geräten ohne Telefon müssen diese APIs als angemessene No-Ops implementiert sein.

Geräteimplementierungen MÜSSEN korrekte Informationen zur Hardwarekonfiguration
über die Methoden „getSystemAvailableFeatures()“ und „hasSystemFeature(String)“
der Klasse „android.content.pm.PackageManager“ melden. [Resources, 37]
7.1. Display und Grafik
Android 4.1 bietet Funktionen, mit denen sich Anwendungs-Assets und
UI-Layouts automatisch an das Gerät anpassen lassen, damit Drittanbieter-Apps auf einer Vielzahl von
Hardwarekonfigurationen ordnungsgemäß ausgeführt werden können [Ressourcen, 38]. Geräte MÜSSEN
diese APIs und Verhaltensweisen wie in diesem Abschnitt beschrieben implementieren.
Die in den Anforderungen in diesem Abschnitt genannten Maßeinheiten werden wie folgt definiert:
Die „physische 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 Spanne von 1" abgedeckt werden. Wenn dpi-Werte angegeben sind, müssen sowohl die horizontalen als auch die vertikalen dpi-Werte innerhalb des Bereichs liegen.
Das „Seitenverhältnis“ ist das Verhältnis der längeren Bildschirmdiagonale zur kürzeren.

Bei einem Display mit 480 × 854 Pixeln würde das 854 ÷ 480 =
1, 779 betragen, also ungefähr „16:9“.
Ein „dichteunabhängiges Pixel“ oder „dp“ ist die virtuelle Pixeleinheit, die auf ein 160
-dpi-Display normiert ist. Die Berechnung erfolgt so: Pixel = dps * (Dichte ÷ 160).
7.1.1. Bildschirmkonfiguration
Bildschirmgröße
Das Android-UI-Framework unterstützt eine Vielzahl verschiedener Bildschirmgrößen und ermöglicht es Anwendungen, die Bildschirmgröße des Geräts (auch „Bildschirmlayout“) über
android.content.res.Configuration.screenLayout mit der
SCREENLAYOUT_SIZE_MASK abzufragen.
Geräteimplementierungen MÜSSEN die richtige Bildschirm
größe melden, wie in der Android SDK-Dokumentation [Resources, 38] definiert und von der
übergeordneten Android-Plattform bestimmt. Insbesondere müssen Geräteimplementierungen die
richtige Bildschirmgröße gemäß den folgenden logischen, dichteunabhängigen Pixelabmessungen (dp)
angeben.
Die Bildschirmgröße von Geräten MUSS mindestens 426 dp × 320 dp ('smal ') betragen.
Die Bildschirmgröße von Geräten, die eine Bildschirmgröße von 'normal' angeben, MUSS mindestens 480 dp × 320 dp betragen.
Die Bildschirmgröße von Geräten, die eine Bildschirmgröße von 'large' angeben, MUSS mindestens 640 dp × 480 dp betragen.
Die Bildschirmgröße von Geräten, die eine Bildschirmgröße von 'xlarge' angeben, MUSS mindestens 960 dp × 720 dp betragen.
Darüber hinaus MUSS die Bildschirmdiagonale von Geräten mindestens 6,4 cm betragen.

Die gemeldete Bildschirmgröße von Geräten darf zu keinem Zeitpunkt geändert werden.
Anwendungen können optional über das Attribut <supports-
screens> in der Datei „AndroidManifest.xml“ angeben, welche Bildschirmgrößen sie unterstützen. Geräteimplementierungen MÜSSEN
die angegebene Unterstützung von Apps für kleine, normale, große und sehr große
Bildschirme gemäß der Android SDK-Dokumentation korrekt einhalten.
Seitenverhältnis
Das Seitenverhältnis MUSS zwischen 1,3333 (4:3) und 1,85 (16:9) liegen.
Bildschirmdichte
Das Android-UI-Framework definiert eine Reihe von standardmäßigen logischen Dichten, die Entwicklern von Anwendungen helfen sollen, ihre Anwendungsressourcen zu optimieren.
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
изпълняват.
120 dpi, auch als „ldpi“ bezeichnet
160 dpi, auch als „mdpi“ bezeichnet
213 dpi, auch als „tvdpi“ bezeichnet
240 dpi, auch als „hdpi“ bezeichnet
320 dpi, auch als „xhdpi“ bezeichnet
480 dpi, auch als „xxhdpi“ bezeichnet
Die Geräteimplementierung MUSS die Standarddichte des Android-Frameworks definieren, die
der physischen Dichte des Bildschirms numerisch am nächsten kommt, es sei denn, diese logische Dichte

der physischen Dichte des Bildschirms numerisch am nächsten kommt, es sei denn, diese logische Dichte
verringert die gemeldete Bildschirmgröße unter die unterstützte Mindestgröße. Wenn die Standard
-Android-Framework-Dichte, die der physischen Dichte numerisch am nächsten kommt, zu einer Bildschirm
größe führt, die kleiner ist als die kleinste unterstützte kompatible Bildschirmgröße (320 dp Breite), MÜSSEN Geräteimplementierungen die nächstniedrigste Standard
-Android-Framework-Dichte melden.

7.1.2. Displaymesswerte
Geräteimplementierungen MÜSSEN korrekte Werte für alle in
android.util.DisplayMetrics [Resources, 39] definierten Displaymesswerte zurückgeben.
7.1.3. Displayausrichtung
Geräte MÜSSEN die dynamische Ausrichtung von Anwendungen im Hoch- oder
Querformat unterstützen. Das Gerät muss also die
Anfrage der Anwendung für eine bestimmte Bildschirmausrichtung respektieren. Bei der Geräteimplementierung kann als Standard
Hoch- oder Querformat ausgewählt werden.
Geräte MÜSSEN den korrekten Wert für die aktuelle Ausrichtung des Geräts melden, wenn sie über die APIs „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. Beispielsweise muss ein Gerät mit einem
festen Querformat-Display, z. B. ein Fernseher oder Laptop, nur
android.hardware.screen.landscape melden.
7.1.4. 2D- und 3D-Grafikbeschleunigung
Geräteimplementierungen MÜSSEN sowohl OpenGL ES 1.0 als auch 2.0 unterstützen, wie in der
Android SDK-Dokumentation beschrieben. Geräteimplementierungen MÜSSEN außerdem
Android Renderscript unterstützen, wie in der Android SDK-Dokumentation beschrieben
[Ressourcen, 8].
Geräteimplementierungen MÜSSEN auch korrekt angeben, dass sie
OpenGL ES 1.0 und 2.0 unterstützen. Das bedeutet:
Die verwalteten APIs (z. B. über die Methode GLES10.getString()) 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 APIs von OpenGL ES alle Erweiterungsstrings melden, die sie unterstützen, und umgekehrt KEINE Erweiterungsstrings melden, die sie nicht unterstützen.

Android 4.1 unterstützt optional die Angabe von Anwendungen, für die bestimmte OpenGL-Texturkomprimierungsformate erforderlich sind.
Diese Formate sind in der Regel
anbieterspezifisch. Unter Android 4.1 müssen Geräteimplementierungen kein bestimmtes
Texturkomprimierungsformat implementieren. Sie MÜSSEN jedoch alle unterstützten
Texturkomprimierungsformate über die getString()-Methode in der
OpenGL API korrekt angeben.
Android 4.1 enthält einen Mechanismus, mit dem Anwendungen angeben können, dass sie die Hardwarebeschleunigung für 2D-Grafiken auf Anwendungs-, Aktivitäts-, Fenster- oder
Ansichtsebene über das Manifest-Tag „android:hardwareAccelerated“ oder direkte
API-Aufrufe aktivieren möchten [Ressourcen, 9].

Unter Android 4.1 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 ein Verhalten zeigen, das der
SDK-Dokumentation zur Hardwarebeschleunigung von Android [Ressourcen, 9] entspricht.
Android 4.1 enthält ein TextureView-Objekt, mit dem Entwickler
hardwaregeaccelerierte OpenGL ES-Texturen direkt als Renderingziele in eine UI-Hierarchie einbinden können.
Geräteimplementierungen MÜSSEN die TextureView API unterstützen und ein

konsistentes Verhalten mit der Upstream-Android-Implementierung aufweisen.
7.1.5. Kompatibilitätsmodus für ältere Anwendungen
Android 4.1 definiert einen „Kompatibilitätsmodus“, in dem das Framework
in einem Modus mit einer „normalen“ Bildschirmgröße (320 dp Breite) ausgeführt wird, um ältere
Anwendungen zu unterstützen, die nicht für alte Android-Versionen entwickelt wurden, die vor der
Bildschirmgrößenabhängigkeit eingeführt wurden. Geräteimplementierungen MÜSSEN den
Kompatibilitätsmodus für ältere Anwendungen unterstützen, wie er im Upstream-Android-Open-Source-Code implementiert ist. Das bedeutet, dass die Geräteimplementierungen die Auslöser oder Grenzwerte, bei denen der
Kompatibilitätsmodus aktiviert wird, NICHT ändern dürfen und auch das Verhalten des
Kompatibilitätsmodus selbst NICHT ändern dürfen.

7.1.6. Bildschirmtypen
Bildschirme der Geräteimplementierung werden in zwei Typen unterteilt:
Implementierungen mit fester Pixelanzahl: Der Bildschirm besteht aus einem einzigen Panel, das nur eine Pixelbreite und -höhe unterstützt.
In der Regel ist das Display
fest in das Gerät integriert. Beispiele hierfür sind Smartphones, Tablets usw.
Implementierungen mit variabler Pixelanzahl: Die Geräteimplementierung hat entweder kein
integriertes Display und einen Videoausgangsport wie VGA, HDMI oder einen
drahtlosen Anschluss für das Display oder ein integriertes Display, bei dem sich die Pixelabmessungen ändern lassen.
Beispiele hierfür sind Fernseher und Set-Top-Boxen.
Geräteimplementierungen mit fester Pixelanzahl
Bei Geräteimplementierungen 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 Displaymesswerte 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 Bildschirmabmessungen melden, die mit denen des Displays mit fester Pixelanzahl identisch sind oder diesen sehr nahe kommen.

Ein Tablet mit einer Diagonale von 7" und einer Auflösung von 1.024 x 600 Pixeln
wird als Large-mdpi-Display mit fester Pixelanzahl betrachtet. Wenn das Gerät einen
Videoausgang mit einer Auflösung von 720p oder 1080p hat, muss die Geräteimplementierung den
Ausgang 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 Videoausgang verwendet wird.

Implementierungen von Geräten mit variabler Pixelanzahl
Implementierungen von Geräten mit variabler Pixelanzahl MÜSSEN eine oder beide Auflösungen von 1280 × 720 oder
1920 × 1080 (d. h. 720p oder 1080p) unterstützen. Geräteimplementierungen mit variablen Pixeln
darf KEINE andere Bildschirmkonfiguration oder -modus unterstützen. Bei Geräten
mit variablen Pixeln kann die Bildschirmkonfiguration oder der
Modus 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 sich dann entsprechend anpassen.

Zusätzlich MÜSSEN Geräteimplementierungen mit variablen Pixelabmessungen die folgenden
Konfigurations-Buckets für diese Pixelabmessungen angeben:
1280x720 (auch bekannt als 720p): Bildschirmgröße „large“, Dichte „tvdpi“ (213 dpi)
1920x1080 (auch bekannt als 1080p): Bildschirmgröße „large“, Dichte „xhdpi“ (320 dpi)
Zur Klarstellung: Geräteimplementierungen mit variablen Pixelabmessungen sind in Android 4.1 auf
720p oder 1080p beschränkt und MÜSSEN so konfiguriert sein, dass sie die Bildschirmgröße und die
Dichte-Buckets wie oben angegeben angeben.
7.1.7. Bildschirmtechnologie
Die Android-Plattform enthält APIs, mit denen Apps reichhaltige Grafiken auf dem Display darstellen 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.
Geräte MÜSSEN Displays unterstützen, die Animationen rendern können.
Die verwendete Displaytechnologie MUSS ein Pixelseitenverhältnis (PAR) zwischen 0,9

und 1,1 haben. Das Seitenverhältnis der Pixel MUSS nahezu quadratisch (1,0) sein, mit einer Toleranz von 10 %.

7.2. Eingabegeräte
7.2.1. Tastatur
Geräteimplementierungen:
MÜSSEN Unterstützung für das Input Management Framework enthalten, mit dem Drittanbieter
Entwickler Input Management Engines (d. h. Soft-Tastaturen) erstellen können, wie
unter http://developer.android.com beschrieben
MÜSSEN mindestens eine Soft-Tastaturimplementierung bereitstellen (unabhängig davon, ob
eine Hardwaretastatur vorhanden ist)
DÜRFEN zusätzliche Soft-Tastaturimplementierungen enthalten
DÜRFEN eine Hardwaretastatur enthalten
DÜRFEN KEINE Hardwaretastatur enthalten, die nicht einem der in android.content.res.Configuration.keyboard [Resources, 40]
angegebenen Formate entspricht(d. h. QWERTY oder 12-Tasten)
7.2.2.
Bedienung ohne Touchbedienung
Geräteimplementierungen:
MÖGEN eine Option zur Bedienung ohne Touchbedienung weglassen (d. h. einen Trackball, ein D-Pad oder ein
Rad)
MÜSSEN den korrekten Wert für
android.content.res.Configuration.navigation [Resources, 40]
MÜSSEN einen angemessenen alternativen Benutzeroberflächenmechanismus für die
Auswahl und Bearbeitung von Text bereitstellen, der mit Eingabeverwaltungs-Engines kompatibel ist. Die
upstream-Android-Open-Source-Software enthält einen Auswahlmechanismus
, der für die Verwendung mit Geräten 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. Geräteimplementierungen MÜSSEN diese Funktionen für den Nutzer
immer verfügbar machen, wenn Anwendungen ausgeführt werden. Diese Funktionen KÖNNEN über
eigene physische Tasten (z. B. mechanische oder kapazitive Touch-Tasten) oder
über spezielle Softwaretasten, Touch-Gesten, Touchbedienung usw. implementiert werden. Android
4.1 unterstützt beide Implementierungen.
Android 4.1 unterstützt die Aktion „Hilfe“ [Ressourcen, 63].
Implementierungen auf Geräten MÜSSEN die Assist-Aktion jederzeit für den Nutzer verfügbar machen, wenn
Apps ausgeführt werden. Diese Funktion kann über Hardware- oder Softwareschlüssel
implementiert werden.
Bei der Geräteimplementierung KÖNNEN die Navigationstasten auf einem separaten Bereich des Bildschirms angezeigt werden. In diesem Fall MÜSSEN jedoch folgende Anforderungen erfüllt sein:
Bei der Geräteimplementierung MÜSSEN die Navigationstasten auf einem separaten Bereich des
Bildschirms angezeigt werden, der nicht für Anwendungen verfügbar ist. Außerdem MÜSSEN sie den für Anwendungen verfügbaren Bereich des Bildschirms NICHT verdecken oder anderweitig beeinträchtigen.
Bei der Geräteimplementierung MÜSSEN Anwendungen einen Teil des Displays zur Verfügung gestellt werden, der den in Abschnitt 7.1.1 definierten Anforderungen entspricht.
Bei der Geräteimplementierung MÜSSEN die Navigationstasten angezeigt werden, wenn Anwendungen keinen System-UI-Modus oder SYSTEM_UI_FLAG_VISIBLE angeben.
Bei der Geräteimplementierung MÜSSEN die Navigationstasten in einem unauffälligen
„Low-Profile“-Modus (z. B. gedimmt) angezeigt werden, wenn Anwendungen
SYSTEM_UI_FLAG_LOW_PROFILE angeben.

Geräteimplementierungen MÜSSEN die Navigationstasten ausblenden, wenn Anwendungen
SYSTEM_UI_FLAG_HIDE_NAVIGATION angeben.
Geräteimplementierungen MÜSSEN Anwendungen eine Menütaste anzeigen, wenn
targetSdkVersion <= 10 und DÜRFEN KEINE Menütaste anzeigen, wenn
targetSdkVersion > 10.
Geräteimplementierungen MÜSSEN Anwendungen einen Teil des Displays zur Verfügung stellen,
der den in Abschnitt 7.1.1 definierten Anforderungen entspricht.
7.2.4. Touchscreen-Eingabe
Geräteimplementierungen MÜSSEN eine Art Zeigereingabesystem haben (
Maus- oder Touchbedienung). Wenn eine Geräteimplementierung jedoch kein Eingabesystem für
Cursor unterstützt, darf die Geräteimplementierung die

�� Geräteimplementierungen, die ein

Zeigereingabesystem umfassen:
SOLLTEN unabhängig voneinander erfasste Zeiger unterstützen, wenn das Eingabesystem des Geräts
mehrere Zeiger unterstützt
MUSS den Wert von android.content.res.Configuration.touchscreen
[Resources, 40] cangeben, der dem Typ des jeweiligen Touchscreens auf dem
Gerät entspricht
Android 4.0 unterstützt eine Vielzahl von Touchscreens, Touchpads und Fake-Touch
Eingabegeräten. Geräte mit Touchbildschirmen sind mit einem
Display [Ressourcen, 71] verbunden, sodass der Nutzer den Eindruck hat, die
Elemente auf dem Bildschirm direkt zu bedienen. Da der Nutzer den Bildschirm direkt berührt,
erfordert das System keine zusätzlichen visuellen Hinweise, um die manipulierten Objekte anzuzeigen. Im
Gegensatz bietet eine gefälschte Touchbedienung ein Nutzereingabesystem, das eine
Untermenge der Touchscreenfunktionen approximiert. Eine Maus oder Fernbedienung, die einen
Cursor auf dem Bildschirm steuert, ähnelt der Touchbedienung, erfordert aber, dass der Nutzer zuerst auf das Element zeigt oder den Fokus darauf legt
und dann klickt. Zahlreiche Eingabegeräte wie Maus, Touchpad, gyrobasierte Luftmaus,
Gyro-Cursor, Joystick und Multi-Touch-Touchpad können Fake Touch-Interaktionen unterstützen.
Android 4.0 enthält die Funktionskonstante „android.hardware.faketouch“,
die einem High-Fidelity-Eingabegerät ohne Touchbedienung (d. h. einem Cursor-basierten Eingabegerät) wie einer
Maus oder einem Touchpad entspricht, das die Touchbedienung (einschließlich grundlegender
Gesten) angemessen emulieren kann. Außerdem gibt sie an, dass das Gerät eine emulierte Teilmenge der
Touchscreen-Funktionen unterstützt. Geräteimplementierungen, die die Funktion „Fake Touch“ angeben,
MÜSSEN die Anforderungen für Fake Touch in Abschnitt 7.2.5 erfüllen.
Geräteimplementierungen MÜSSEN die richtige Funktion für den verwendeten
Eingabetyp melden. Geräteimplementierungen mit Touchscreen (Einzelpunktberührung oder besser)
MÜSSEN die Plattformfunktionskonstante „android.hardware.touchscreen“ angeben. Geräte
implementierungen, die die Plattformfunktionskonstante
android.hardware.touchscreen melden, MÜSSEN auch die Plattformfunktionskonstante
android.hardware.faketouch melden. Geräteimplementierungen, die keinen
Touchscreen haben (und nur auf ein Zeigegerät angewiesen sind), DÜRFEN KEINE Touchscreen
funktion melden und MÜSSEN nur „android.hardware.faketouch“ melden, wenn sie die Anforderungen für die
Faketouch-Funktion in Abschnitt 7.2.5 erfüllen.
7.2.5.Fake-Touch-Eingaben
Geräteimplementierungen, die die Unterstützung für android.hardware.faketouch angeben
MÜSSEN die absoluten X- und Y-Bildschirmpositionen der Cursorposition melden und
einen visuellen Cursor auf dem Bildschirm anzeigen[Resources, 70]
MÜSSEN Touch-Ereignisse mit dem Aktionscode melden[Resources, 70], der die
Zustandsänderung angibt, die auftritt, wenn der Cursor auf dem Bildschirm gedrückt oder angehoben wird [Resources, 70]
MÜSSEN das Drücken und Loslassen des Cursors auf einem Objekt auf dem Bildschirm unterstützen, wodurch
Nutzer das Tippen auf ein Objekt auf dem Bildschirm emulieren können
MÜSSEN das Drücken, Loslassen, Drücken und Loslassen des Cursors an derselben Stelle auf einem Objekt auf dem Bildschirm innerhalb eines Zeitgrenzwerts unterstützen, wodurch Nutzer das Doppeltippen auf ein Objekt auf dem Bildschirm emulieren können [Resources, 70]
MÜSSEN das Drücken des Cursors an einem beliebigen Punkt auf dem Bildschirm, das Bewegen des Cursors zu einem beliebigen anderen Punkt auf dem Bildschirm und das anschließende Loslassen des Cursors unterstützen, wodurch Nutzer das Ziehen per Touch emulieren können
MÜSSEN das Drücken des Cursors unterstützen, wodurch Nutzer das Objekt schnell an eine andere Position auf dem Bildschirm bewegen und dann den Cursor loslassen können, wodurch Nutzer das Weitschleudern eines Objekts auf dem Bildschirm emulieren können
Geräte, die die Unterstützung für android.hardware.faketouch.multitouch.distinct angeben
MÜSSEN die oben genannten Anforderungen für Fake-Touch erfüllen und MÜSSEN außerdem das eindeutige Tracking von zwei oder mehr unabhängigen Cursoreingängen unterstützen.

7.2.6. Mikrofon
Geräteimplementierungen KÖNNEN ein Mikrofon auslassen. Wenn eine Geräteimplementierung
kein Mikrofon hat, DARF die Funktion „android.hardware.microphone“ NICHT als Konstante gemeldet werden
und die Audioaufzeichnungs-API muss gemäß Abschnitt 7 als No-Op implementiert werden.
Geräteimplementierungen mit Mikrofon müssen hingegen:
die Funktion „android.hardware.microphone“ als Konstante melden
die Anforderungen an die Audioqualität in Abschnitt 5.4 erfüllen
die Anforderungen an die Audiolatenz in Abschnitt 5.5 erfüllen
7.3. Sensoren

Android 4.1 enthält APIs für den Zugriff auf verschiedene Sensortypen. Bei der
Implementierung von Geräten können diese Sensoren im Allgemeinen
ausgelassen werden, wie in den folgenden Unterabschnitten beschrieben. Wenn ein Gerät einen bestimmten Sensortyp mit einer entsprechenden API
für Drittanbieterentwickler hat, MUSS die Geräteimplementierung diese API gemäß der
in der Android SDK-Dokumentation beschriebenen Vorgehensweise implementieren. Beispielsweise müssen Geräteimplementierungen:
das Vorhandensein oder Fehlen von Sensoren gemäß der
Klasse „android.content.pm.PackageManager“ korrekt melden. [Ressourcen, 37]
MUSS über die Methode
SensorManager.getSensorList() und ähnliche Methoden eine genaue Liste der unterstützten Sensoren zurückgeben
MUSS sich für alle anderen Sensor-APIs angemessen verhalten (z. B. durch Zurückgeben von „wahr“ oder „falsch“, wenn Anwendungen versuchen, Listener zu registrieren, oder durch Nichtaufrufen von Sensor-Listenern, wenn die entsprechenden Sensoren nicht vorhanden sind)
MUSS alle Sensormessungen mit den entsprechenden Werten des internationalen Einheitensystems (d. h. metrischen Werten) für jeden Sensortyp gemäß der Definition in der Android SDK-Dokumentation melden [Ressourcen, 41]
Die obige Liste ist nicht vollständig. Das dokumentierte Verhalten des Android SDK ist maßgeblich.

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 Sensor
typen implementieren, wenn sie die erforderlichen physischen Sensoren enthalten.
Die Android 4.1-APIs führen den Begriff „Streaming-Sensor“ ein.
Dieser gibt Daten kontinuierlich zurück, nicht nur, wenn sich die Daten ändern. Geräte
implementierungen MÜSSEN kontinuierlich zyklische Datenproben für jede API bereitstellen,
die in der Android 4.1 SDK-Dokumentation als Streamingsensor angegeben ist.
7.3.1. Beschleunigungsmesser
Geräteimplementierungen MÜSSEN einen 3-Achsen-Beschleunigungsmesser enthalten. Wenn eine Geräteimplementierung
ein 3‑Achsen-Beschleunigungsmesser enthält, sollte sie:
Ereignisse mit mindestens 120 Hz senden können. Die obige
Frequenz des Beschleunigungsmessers ist für Android 4.1 als „SOLLTE“ angegeben. In der
Kompatibilitätsdefinition für eine zukünftige Version soll dies jedoch in „MUSS“ geändert werden.
Diese Standards sind in Android 4.1 optional, werden aber in zukünftigen Versionen
erforderlich sein. Bestehende und neue Geräte mit Android 4.1 müssen
diese Anforderungen in Android 4.1 erfüllen , damit sie
auf die zukünftigen Plattformversionen umgestellt werden können.
MÜSSEN dem Android-Sensorkoordinatensystem entsprechen, wie in den
Android-APIs beschrieben (siehe [Ressourcen, 41])
MÜSSEN in der Lage sein, von freiem Fall bis zu doppelter Schwerkraft (2 g) oder mehr auf
einem beliebigen dreidimensionalenVektor zu messen
MÜSSEN eine Genauigkeit von mindestens 8 Bit haben
MÜSSEN eine Standardabweichung von maximal 0,05 m/s² haben
7.3.2. Magnetometer
Geräteimplementierungen MÜSSEN ein 3-Achsen-Magnetometer (z.B. Kompass) enthalten. Wenn ein
Gerät ein 3‑Achsen-Magnetometer enthält, muss es Folgendes erfüllen:
MUSS Ereignisse mit einer Häufigkeit von mindestens 10 Hz liefern
MUSS dem in den
Android-APIs beschriebenen Android-Sensorkoordinatensystem entsprechen (siehe [Ressourcen, 41]).
MUSS in der Lage sein, einen Bereich von Feldstärken zu erfassen, der das
geomagnetische Feld abdeckt
MUSS eine Genauigkeit von mindestens 8 Bit haben
MUSS eine Standardabweichung von maximal 0,5 µT haben
7.3.3. GPS
Geräteimplementierungen MÜSSEN einen GPS-Empfänger enthalten. Wenn eine Geräteimplementierung
einen GPS-Empfänger enthält, MUSS sie eine Form von „Assisted GPS“
enthalten, um die Zeit bis zur GPS-Fixierung zu minimieren.
7.3.4. Gyroskop
Geräteimplementierungen SOLLTEN ein Gyroskop (d.h. einen Winkeländerungssensor) enthalten.
Geräte SOLLTEN KEIN Gyroskop enthalten, es sei denn, es ist auch ein 3-Achsen-Beschleunigungsmesser
verfügbar. Wenn eine Geräteimplementierung ein Gyroskop enthält, muss es:

temperaturkompensiert sein
Orientierungsänderungen bis zu 5,5*Pi
Rad/Sekunde (d. h. etwa 1.000 Grad pro Sekunde) messen können
Ereignisse mit mindestens 200 Hz senden können. Die obige
Gyrometerfrequenz wird für Android 4.1 als „SOLLTE“ angegeben. In der
Kompatibilitätsdefinition für eine zukünftige Version soll sie jedoch in
„MUSS“ geändert werden. Diese Standards sind in Android 4.1 optional, werden aber in zukünftigen Versionen
erforderlich sein. Bestehende und neue Geräte mit Android 4.1
sollten diese Anforderungen in Android 4.1 erfüllen , damit sie
auf die zukünftigen Plattformversionen umgestellt werden können
MÜSSEN eine Genauigkeit von mindestens 12 Bit haben
MÜSSEN eine Abweichung von maximal 1e-7 rad² / s² pro Hz haben (Abweichung pro Hz,
oder rad² / s). Die Varianz darf sich mit der Abtastrate ändern, muss aber durch diesen Wert begrenzt werden.
Anders ausgedrückt: Wenn Sie die Varianz des Gyroskops
mit einer Abtastrate von 1 Hz messen, darf sie nicht größer als 1e-7 rad²/s² sein.
Die Zeitstempel müssen 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 Umgebungsluftdrucksensor) enthalten. Wenn
eine Geräteimplementierung ein Barometer enthält, muss es:
Ereignisse mit mindestens 5 Hz liefern können
eine ausreichende Genauigkeit haben, um die Höhe zu schätzen
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 Android 4.1 APIs nicht mehr unterstützt.)
7.3.7. Photometer
Geräteimplementierungen KÖNNEN einen Photometer (d.h. einen Umgebungslicht-Sensor) enthalten.
7.3.8. Näherungssensor
Geräteimplementierungen KÖNNEN einen Näherungssensor enthalten. Wenn eine Geräteimplementierung
einen Näherungssensor enthält, muss die Nähe eines Objekts in der
gleichen Richtung wie das Display gemessen werden. Der Näherungssensor MUSS so ausgerichtet sein, dass er
Objekte in der Nähe des Displays erkennt, da der primäre Zweck dieses Sensortyps darin besteht, ein
vom Nutzer verwendetes Smartphone zu erkennen. Wenn eine Geräteimplementierung einen Näherungssensor mit einer anderen Ausrichtung hat, darf er nicht über diese API zugänglich sein.
Wenn eine Geräteimplementierung einen Näherungssensor hat, MUSS die Genauigkeit mindestens 1 Bit betragen.

7.4. Datenverbindung
7.4.1. Telefonie
Der Begriff „Telefonie“ in den Android 4.1 APIs und in diesem Dokument bezieht sich speziell auf
Hardware, die zum Telefonieren und Senden von SMS über ein GSM- oder
CDMA-Netzwerk verwendet wird. Diese Sprachanrufe können paketvermittelt sein oder nicht. Sie werden
für Android 4.1 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.1 KANN auf Geräten ohne Telefonhardware verwendet werden. Das heißt,
Android 4.1 ist 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 Telefon
hardware enthalten, MÜSSEN die vollständigen APIs als No-Ops implementieren.
7.4.2. IEEE 802.11 (WLAN)
Android 4.1-Geräteimplementierungen 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 während des Betriebs filtern, auch nicht wenn das Display nicht aktiv ist.

7.4.2.1. Wi‑Fi Direct
Geräteimplementierungen MÜSSEN Wi‑Fi Direct (Wi‑Fi-Peer-to-Peer) unterstützen. Wenn
eine Geräteimplementierung Unterstützung für Wifi Direct umfasst, MUSS sie die
entsprechende Android API implementieren, wie in der SDK-Dokumentation beschrieben [Ressourcen, 68]. Wenn
eine Geräteimplementierung Wifi Direct unterstützt, muss sie:
den regulären WLAN-Betrieb unterstützen
SOLLTE den gleichzeitigen WLAN- und Wifi Direct-Betrieb unterstützen
7.4.3. Bluetooth
Geräteimplementierungen MÜSSEN einen Bluetooth-Transceiver enthalten. Geräteimplementierungen, die einen Bluetooth-Transceiver enthalten, MÜSSEN die RFCOMM-
basierte Bluetooth API aktivieren, wie in der SDK-Dokumentation beschrieben [Ressourcen, 42].

Implementierungen von Geräten MÜSSEN relevante Bluetooth-Profile implementieren, z. B. A2DP,
AVRCP, OBEX usw., wie für das Gerät geeignet.
Die Kompatibilitätstestsuite enthält 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 (NFC) enthalten. Wenn eine Geräteimplementierung NFC-Hardware
enthält, muss Folgendes erfüllt sein:
Die Funktion „android.hardware.nfc“ muss über die Methode
android.content.pm.PackageManager.hasSystemFeature() gemeldet werden.
[Resources, 37]
MUSS in der Lage sein, NDEF-Nachrichten über die folgenden NFC-
Standards zu lesen und zu schreiben:
MUSS in der Lage sein, als NFC Forum-Lesegerät/-Schreiber (wie in der NFC Forum-technischen Spezifikation NFCForum-TS-DigitalProtocol-1.0 definiert)
über die folgenden NFC-Standards zu funktionieren:
NfcA (ISO14443-3A)
NfcB (ISO14443-3B)
NfcF (JIS 6319-4)
IsoDep (ISO 14443-4)
NFC Forum-Tag-Typen 1, 2, 3, 4 (definiert vom NFC Forum)
SOLLTE in der Lage sein, NDEF-Nachrichten über die folgenden
NFC-Standards zu lesen und zu schreiben.
Die folgenden NFC-Standards sind für Android 4.1 als
„SHOULD“ (sollte) angegeben. Gemäß der Kompatibilitätsdefinition für eine zukünftige Version werden sie jedoch
in „MUST“ (muss) geändert. Diese Standards sind in
Android 4.1 optional, werden aber in zukünftigen Versionen erforderlich sein. Für bestehende und neue Geräte
mit Android 4.1 wird dringend empfohlen, diese
Anforderungen in Android 4.1 zu erfüllen, damit sie auf die zukünftigen
Plattformversionen umgestellt werden können.
NfcV (ISO 15693)
MUSS in der Lage sein, Daten über die folgenden Peer-to-Peer-Standards und ‑Protokolle zu übertragen und zu empfangen:
ISO 18092
LLCP 1.0 (vom NFC Forum definiert)
SDP 1.0 (vom NFC Forum definiert)
NDEF Push Protocol [Resources, 43]
SNEP 1.0 (vom NFC Forum definiert)
MUSS Unterstützung für Android Beam bieten [Resources, 65]:
MUSS den Standard-SNEP-Server implementieren.
Gültige NDEF-Nachrichten,
die vom Standard-SNEP-Server empfangen werden, MÜSSEN an Anwendungen gesendet werden
, indem der Intent „android.nfc.ACTION_NDEF_DISCOVERED“ verwendet wird. Das Deaktivieren von
Android Beam in den Einstellungen DARF NICHT die Weiterleitung eingehender NDEF-
Nachrichten deaktivieren.
Geräteimplementierungen MÜSSEN den Intent
android.settings.NFCSHARING_SETTINGS berücksichtigen, um die NFC-Freigabe

einstellungen anzuzeigen [Ressourcen, 67].
MÜSSEN den NPP-Server implementieren. Nachrichten, die vom NPP-Server empfangen werden,
MÜSSEN auf die gleiche Weise wie vom SNEP-Standardserver verarbeitet werden.
MÜSSEN einen SNEP-Client implementieren und versuchen, ausgehende P2P-NDEF
an den Standard-SNEP-Server zu senden, wenn Android Beam aktiviert ist. Wenn kein standardmäßiger
SNEP-Server gefunden wird, MUSS der Client versuchen, an einen NPP-
Server zu senden.
MUSS Aktivitäten im Vordergrund zulassen, die die ausgehende P2P-NDEF-Nachricht
mithilfe von android.nfc.NfcAdapter.setNdefPushMessage,
android.nfc.NfcAdapter.setNdefPushMessageCal back und
android.nfc.NfcAdapter.enableForegroundNdefPush festlegen.
SOLLTE eine Geste oder Bestätigung auf dem Bildschirm verwenden, z. B. „Zum Übertragen berühren
“, bevor ausgehende P2P-NDEF-Nachrichten gesendet werden.
SOLLTE Android Beam standardmäßig aktivieren
MUSS die NFC-Verbindungsweitergabe an Bluetooth unterstützen, wenn das Gerät
das Bluetooth Object Push Profile unterstützt. Geräteimplementierungen müssen die
Übergabe der Verbindung 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. Bei einer solchen Implementierung von SHOULD werden SNEP GET-Anfragen
für den Austausch der Übergabeanfrage / ausgewählten Datensätze über NFC verwendet und es
MUSS das Bluetooth Object Push Profile für die tatsächliche Bluetooth-Datenübertragung verwendet werden.

MUSS alle unterstützten Technologien im NFC-Suchmodus prüfen.
SOLLTE im NFC-Suchmodus sein, während das Gerät aktiv ist, das Display
aktiv ist und der Sperrbildschirm entsperrt ist.
(Hinweis: Für die oben genannten JIS-, ISO- und NFC Forum-
Spezifikationen sind keine öffentlich zugänglichen Links verfügbar.)
Außerdem können Geräteimplementierungen L/W-Unterstü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])
Hinweis: Android 4.1 enthält APIs für diese MIFARE-Typen. Wenn eine Geräte
implementierung MIFARE in der Rolle „Leser/Schreiber“ unterstützt, muss sie:
die entsprechenden Android APIs gemäß der Dokumentation im
Android SDK implementieren
die Funktion „com.nxp.mifare“ über die Methode
android.content.pm.PackageManager.hasSystemFeature() melden.
[Resources, 37] Hinweis: Dies ist keine Standard-Android-Funktion und wird daher
nicht als Konstante in der Klasse „PackageManager“ aufgeführt.
Die entsprechenden Android-APIs dürfen NICHT implementiert und die Funktion
com.nxp.mifare darf NICHT gemeldet werden, es sei denn, es wird auch die allgemeine NFC-Unterstützung gemäß
diesem Abschnitt implementiert.
Wenn eine Geräteimplementierung keine NFC-Hardware enthält, darf die Funktion
android.hardware.nfc nicht über die Methode
android.content.pm.PackageManager.hasSystemFeature() [Resources, 37] deklariert werden
und die NFC-API von Android 4.1 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 NFC-Unterstützung enthalten oder die Funktion
android.hardware.nfc nicht deklarieren.

7.4.5. Mindestnetzwerkanforderungen
Geräteimplementierungen MÜSSEN mindestens eine Form von Daten
netzwerk 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 auch mindestens einen gängigen
drahtlosen Datenstandard wie 802.11 (WiFi) 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 gegenüber dem Display. Das heißt, sie nimmt Motive auf der Rückseite des Geräts auf, ähnlich wie eine
traditionelle 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. für
Videokonferenzen und ähnliche Anwendungen.
7.5.1. Rückkamera
Geräteimplementierungen MÜSSEN eine Rückkamera haben. Wenn eine Geräte
implementierung eine Rückkamera enthält, muss sie:
eine Auflösung von mindestens 2 Megapixeln haben
SOLLTE entweder einen Hardware-Autofokus oder einen Software-Autofokus haben, der
im Kameratreiber implementiert ist (für die Anwendungssoftware transparent)
KANN eine Hardware mit Festfokus oder EDOF (erweiterte Tiefenschärfe) haben
KANN einen Blitz haben. Wenn die Kamera einen Blitz hat, darf der Blitz
nicht aufleuchten, während eine Instanz von android.hardware.Camera.PreviewCal
auf einer Kameravorschauoberfläche registriert wurde, es sei denn, die Anwendung hat den Blitz
ausdrücklich 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
eingebaute Kamera-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, muss sie:
eine Auflösung von mindestens VGA (640 × 480 Pixel) haben
darf KEINE Frontkamera als Standard für die Camera API verwenden. Das heißt,
die Kamera-API in Android 4.1 unterstützt speziell Frontkameras und
Geräteimplementierungen DÜRFEN die API nicht so konfigurieren, dass eine Frontkamera
als Standardrückkamera behandelt wird, auch wenn sie die einzige Kamera auf dem
Gerät ist.
Die API DARF Funktionen wie Autofokus oder Blitz enthalten, die für Rückkameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.
Die API DARF den von einer App in einer
CameraPreview angezeigten Stream horizontal spiegeln (d. h. spiegeln), und zwar so:
Wenn die Geräteimplementierung vom Nutzer gedreht werden kann (z. B.
automatisch über ein Beschleunigungsmesser oder manuell über die Nutzereingabe), DARF die Kamera
Vorschau horizontal spiegeln (d. h. spiegeln), bezogen auf die aktuelle
Ausrichtung des Geräts.
Wenn die aktuelle Anwendung explizit anfordert, dass das Kameradisplay
über eine Anrufung der Methode
android.hardware.Camera.setDisplayOrientation() [Resources, 50]
gedreht wird, DARF die Kameravorschau horizontal spiegeln (d. h. spiegeln), bezogen auf die
von der Anwendung angegebene Ausrichtung.
Andernfalls DARF die Vorschau entlang der standardmäßigen horizontalen Achse des Geräts gespiegelt werden.

DAS Bild, das in der Postview angezeigt wird, MUSS auf die gleiche Weise gespiegelt werden wie der
Bildstream der Kameravorschau. (Wenn die Geräteimplementierung
Postview nicht unterstützt, gilt diese Anforderung natürlich nicht.)
Dürfen die finalen aufgenommenen Stil-Bilder oder Videostreams, die an
Anwendungs-Callbacks zurückgegeben oder im Medienspeicher gespeichert werden, NICHT spiegeln.
7.5.3. Kamera-API-Verhalten
Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs sowohl für die Front- als auch für die Rückkamera implementieren:
1.
  Wenn eine Anwendung noch nie
android.hardware.Camera.Parameters.setPreviewFormat(int) aufgerufen hat, muss das
Gerät für die

�
2.  Wenn eine Anwendung eine Instanz von android.hardware.Camera.PreviewCallback
registriert und das System die Methode onPreviewFrame() aufruft, wenn das Vorschauformat YCbCr_420_SP ist, müssen die Daten in den Byte[]-Werten, die an onPreviewFrame() übergeben werden,
außerdem im NV21-Codierungsformat vorliegen.
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
Front- als auch für Rückkameras unterstützen. Der Hardware-Video-Decoder und die Kamera können
ein beliebiges natives Pixelformat verwenden, die Geräteimplementierung MUSS jedoch die
Umwandlung in YV12 unterstützen.)
Geräteimplementierungen MÜSSEN die vollständige Kamera-API implementieren, die in der Android
4.1-SDK-Dokumentation [Ressourcen, 51] enthalten ist, unabhängig davon, ob das Gerät einen
Hardware-Autofokus oder andere Funktionen hat. Bei Kameras ohne Autofokus
MÜSSEN
alle registrierten Instanzen von android.hardware.Camera.AutoFocusCallback aufgerufen werden, auch wenn dies für eine Kamera ohne Autofokus keine Relevanz hat.
Hinweis: Dieses gilt auch für Frontkameras. Auch wenn die meisten Frontkameras keinen Autofokus unterstützen, müssen die Rückkameras der API wie beschrieben „gefaket“ werden.

Geräteimplementierungen MÜSSEN jeden Parameternamen erkennen und berücksichtigen, der als Konstante in der Klasse „android.hardware.Camera.Parameters“ definiert ist, wenn die zugrunde liegende Hardware die Funktion unterstützt.

Wenn die Gerätehardware eine Funktion nicht unterstützt, muss die
API wie beschrieben funktionieren. Umgekehrt dürfen Geräteimplementierungen

Stringkonstanten, die an die Methode
android.hardware.Camera.setParameters() übergeben werden, nicht berücksichtigen oder erkennen, es sei denn, sie sind als Konstanten in den
Parametern von android.hardware.Camera dokumentiert. 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 MÜSSEN die Intent „Camera.ACTION_NEW_PICTURE“ senden,
wenn mit der Kamera ein neues Bild aufgenommen und der Eintrag des Bildes dem Medienspeicher hinzugefügt wurde.

Geräteimplementierungen MÜSSEN den Intent „Camera.ACTION_NEW_VIDEO“ senden,
wenn ein neues Video von der Kamera aufgenommen und der Eintrag des Bilds 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
Achse der Kamera mit der langen Achse des Bildschirms übereinstimmt. Das heißt, wenn das
Gerät 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, die hauptsächlich im Querformat verwendet werden, als auch für Geräte, die hauptsächlich im Hochformat verwendet werden.
7.6. Arbeitsspeicher und interner Speicher
7.6.1. Minimaler Arbeitsspeicher und Speicherplatz
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 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 Partition „/data“ MUSS also mindestens 350 MB groß sein.
Die Android-APIs enthalten einen Downloadmanager, mit dem Anwendungen
Dateien herunterladen können [Resources, 56]. Die Geräteimplementierung des Downloadmanagers
MUSS in der Lage sein, einzelne Dateien mit einer Größe von mindestens 100 MB an den
Standardspeicherort „Cache“ herunterzuladen.
7.6.2. Freigegebener Speicher für Anwendungen
Geräteimplementierungen MÜSSEN freigegebenen Speicher für Anwendungen bieten. Der bereitgestellte freigegebene
Speicherplatz MUSS mindestens 1 GB groß sein.
Geräteimplementierungen MÜSSEN so konfiguriert sein, dass freigegebener Speicher standardmäßig bereitgestellt wird,
also „out of the box“. Wenn der freigegebene Speicher nicht über den Linux-Pfad „/sdcard“ bereitgestellt wird,
MUSS das Gerät einen Linux-Symbollink von „/sdcard“ zum tatsächlichen Bereitstellungspunkt enthalten.
Geräteimplementierungen MÜSSEN die Berechtigung
android.permission.WRITE_EXTERNAL_STORAGE für diesen freigegebenen Speicher wie dokumentiert erzwingen.
Andernfalls MUSS der freigegebene Speicher von jeder Anwendung beschreibbar sein, die diese
Berechtigung erhält.
Geräteimplementierungen KÖNNEN Hardware für nutzerzugänglichen, herausnehmbaren Speicher haben,
z. B. eine Secure Digital-Karte. Alternativ können Geräteimplementierungen
internen (nicht entfernbaren) Speicher als freigegebenen 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 das Media Transfer Protocol (MTP).
Geräteimplementierungen KÖNNEN USB-Massenspeicher verwenden, SOLLTEN aber das Media
Transfer Protocol verwenden.
Wenn die Geräteimplementierung das Media-Transfer-Protokoll unterstützt:
Die Geräteimplementierung SOLLTE mit dem Referenz-Android
MTP-Host, Android File Transfer [Ressourcen, 57], kompatibel sein.
Die Geräteimplementierung SOLLTE 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
über andere Mittel wie ein Netzwerkdateisystem
Zugriff auf den Inhalt des freigegebenen Speichers gewähren.
Zur Veranschaulichung betrachten wir zwei gängige Beispiele. Wenn eine Geräteimplementierung einen
SD-Kartenslot zur Erfüllung der Anforderungen an den freigegebenen Speicher enthält, MUSS eine im FAT-Format formatierte SD-Karte
mit einer Größe von mindestens 1 GB im Lieferumfang des Geräts enthalten sein und MUSS
standardmäßig bereitgestellt werden. Alternativ: 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.

Bei Geräteimplementierungen mit mehreren freigegebenen Speicherpfaden (z. B. einem
SD-Kartenslot und einem freigegebenen internen Speicher) MÜSSEN die Hauptanwendungen wie
der Medienscanner und der Content-Provider so geändert werden, dass Dateien an beiden Speicherorten transparent unterstützt werden.

7.7. USB
Geräteimplementierungen MÜSSEN einen USB-Client-Port und einen
USB-Host-Port enthalten.
Wenn eine Geräteimplementierung einen USB-Clientanschluss hat:
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 verwenden. Bei bestehenden
und neuen Geräten mit Android 4.1 wird dringend empfohlen, diese Anforderungen in Android 4.1 zu erfüllen, damit sie auf die zukünftigen
Plattformversionen umgestellt werden können
. Der Anschluss sollte sich in der Mitte einer Kante befinden.
Bei der Geräteimplementierung
SOLLTE der Anschluss entweder unten am Gerät platziert werden (entsprechend der natürlichen
Ausrichtung) oder die Software-Displaydrehung für alle Apps (einschließlich des
Startbildschirms) aktiviert werden, damit das Display richtig dargestellt wird, wenn das Gerät mit dem Anschluss nach unten gehalten wird.
Bestehende und neue Geräte mit Android 4.1 werden dringend
aufgefordert, diese Anforderungen in Android 4.1 zu erfüllen, damit sie auf zukünftige Plattformversionen umgestellt werden können.
Wenn das Gerät andere Ports hat (z. B. einen nicht USB-fähigen Ladeanschluss),
sollten sie sich an derselben Kante wie der Micro-USB-Anschluss befinden.
Es MUSS einem mit dem Gerät verbundenen Host die Möglichkeit geben, über USB Mass Storage oder das Media Transfer Protocol auf den Inhalt des freigegebenen Speichervolumes zuzugreifen.
Es MUSS die Android Open Accessory API und ‑Spezifikation gemäß der Dokumentation im Android SDK implementieren und MUSS die Unterstützung für die Hardwarefunktion „android.hardware.usb.accessory“ angeben [Ressourcen, 52].
Es MUSS die USB-Audioklasse gemäß der Dokumentation im Android SDK implementieren [Ressourcen, 66].
Es SOLLTE die Unterstützung für die USB-Akkuladespezifikation implementieren [Ressourcen, 64]. Bestehende und neue Geräte mit Android 4.1 werden dringend
aufgefordert, diese Anforderungen in Android 4.1 zu erfüllen, damit sie auf zukünftige Plattformversionen umgestellt werden können.
Wenn eine Geräteimplementierung einen USB-Host-Port enthält:
Es KANN einen nicht standardmäßigen Port-Formfaktor verwenden. In diesem Fall MUSS es jedoch mit einem Kabel oder Kabeln geliefert werden, die den Port an den Standard-USB-A-Anschluss anpassen.
Es MUSS die Android USB Host API gemäß der Dokumentation im Android SDK implementieren und MUSS die Unterstützung für die Hardwarefunktion „android.hardware.usb.host“ angeben [Ressourcen, 53].
Geräteimplementierungen MÜSSEN die Android Debug Bridge implementieren.

Wenn eine Geräte
implementierung keinen USB-Client-Port hat, 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 wichtigsten Leistungsmesswerte eines mit Android 4.1 kompatiblen Geräts erfüllen, die in der folgenden Tabelle definiert sind:
Messwert
Leistungsgrenzwert
Hinweise
Die folgenden Anwendungen
sollten innerhalb der angegebenen Zeit gestartet werden.

Die Startzeit wird als
Summe der Zeit gemessen, die zum vollständigen Laden der
Browser: unter
Standardaktivität für die Anwendung,
Anwendung
1.300 ms
benötigt wird, einschließlich der Zeit, die für das Starten des
Startzeit
Linux-Prozesses, das Laden des Android-
700 ms
Pakets in die Dalvik-VM und das Aufrufen von
Einstellungen: unter
onCreate erforderlich ist.

700 ms
Wenn mehrere Anwendungen
gestartet wurden,
muss der Neustart einer bereits
parallel
laufenden Anwendung nach dem Start
der
Anwendungen
weniger als die ursprüngliche Startzeit
betragen.

9. Kompatibilität des Sicherheitsmodells
Geräteimplementierungen MÜSSEN ein Sicherheitsmodell implementieren, das dem Sicherheitsmodell der Android-
Plattform entspricht, wie im Referenzdokument zu Sicherheit und Berechtigungen in den
APIs [Ressourcen, 54] in der Android-Entwicklerleitfaden definiert. Geräte
implementierungen 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 unterstützen, wie in der
Android-Entwicklerdokumentation [Ressourcen, 54] definiert. Insbesondere müssen Implementierungen
ALLE in der SDK-Dokumentation beschriebenen Berechtigungen erzwingen.
Keine Berechtigungen dürfen weggelassen, geändert oder ignoriert werden. In Implementierungen können zusätzliche
Berechtigungen hinzugefügt werden, sofern die neuen Berechtigungs-ID-Strings nicht im Namespace „android.*
“ enthalten sind.
9.2. UID- und Prozessisolierung
Geräteimplementierungen MÜSSEN das Sandbox-Modell für Android-Anwendungen unterstützen,
in 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 als dieselbe
Linux-Nutzer-ID unterstützen, sofern die Anwendungen wie in der Referenz zu Sicherheit und Berechtigungen [Ressourcen, 54] definiert ordnungsgemäß signiert und erstellt sind.

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
nativem Code ausgeführt werden. Solche alternativen Ausführungsumgebungen dürfen jedoch nicht das
Android-Sicherheitsmodell oder die Sicherheit installierter Android-Anwendungen gefährden, wie in diesem Abschnitt beschrieben.

Alternative Laufzeitumgebungen MÜSSEN Android-Anwendungen sein und dem
standardmäßigen Android-Sicherheitsmodell entsprechen, wie in Abschnitt 9 beschrieben.
Alternativlaufzeiten DÜRFEN KEINNEN Zugriff auf Ressourcen erhalten, die durch
Berechtigungen geschützt sind, die nicht über den Mechanismus <uses-
permission> in der Datei „AndroidManifest.xml“ 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 SOLLTEN Apps über den Paketmanager in separaten
Android-Sandboxes (z. B. Linux-Nutzer-IDs) 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
NICHT die Sandbox einer anderen auf dem Gerät installierten App wiederverwenden, außer über die
Standardmechanismen von Android für freigegebene Nutzer-IDs und Signaturzertifikate.
Alternative Laufzeiten DÜRFEN NICHT mit anderen
Sandboxes gestartet, anderen Sandboxes Zugriff gewährt oder anderen Anwendungen Berechtigungen des Superusers (Root) oder einer anderen Nutzer-ID gewährt werden.

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

Bei der Installation von Anwendungen MÜSSEN alternative Laufzeiten die Nutzereinwilligung für die von der Anwendung verwendeten
Android-Berechtigungen einholen. Wenn eine Anwendung also eine Geräteressource verwenden muss, für die es eine entsprechende Android-Berechtigung gibt (z. B. Kamera oder GPS), 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 von der Laufzeit selbst gehalten werden, wenn eine Anwendung mit dieser Laufzeit installiert wird.
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
sollten Geräteimplementierer möglichst wenige
Änderungen an der Referenz- und bevorzugten Implementierung von Android 4.1
vornehmen,die im Android Open Source Project verfügbar ist. So wird das Risiko minimiert, dass
Fehler auftreten, die Inkompatibilitäten verursachen, die eine Überarbeitung und möglicherweise 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, und dabei die
finale Software auf dem Gerät verwenden. Außerdem SOLLTEN Geräteimplementierer die
Referenzimplementierung im Android-Open-Source-Baum nach Möglichkeit verwenden und
MÜSSEN für Kompatibilität sorgen, wenn es in der CTS Unklarheiten gibt, und bei allen
Neuimplementierungen von Teilen des Referenz-Quellcodes.
Der CTS ist für die Ausführung auf einem echten Gerät konzipiert. Wie jede Software kann auch die CTS
Fehler enthalten. Der CTS wird unabhängig von dieser
Kompatibilitätsdefinition versioniert und es können mehrere Versionen des CTS für Android 4.1 veröffentlicht werden.
Geräteimplementierungen MÜSSEN die neueste CTS-Version bestehen, die zum Zeitpunkt der Fertigstellung der
Gerätesoftware verfügbar ist.
10.2. CTS-Verifier
Geräteimplementierungen MÜSSEN alle anwendbaren Fälle im CTS
Verifier korrekt ausführen. Der CTS Verifier ist in der Compatibility Test Suite enthalten und soll
von einem menschlichen 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 Kameras und Sensoren.
Der CTS-Verifier bietet Tests für viele Arten von Hardware, einschließlich optionaler Hardware.
Geräteimplementierungen MÜSSEN alle Tests für die Hardware bestehen, die sie haben. Wenn ein Gerät beispielsweise ein Beschleunigungsmesser hat, MUSS es den Testfall für den Beschleunigungsmesser im CTS-Verifier korrekt ausführen.

Testfälle für Funktionen, die in diesem Dokument zur Kompatibilitätsdefinition
als optional gekennzeichnet sind, KÖNNEN übersprungen oder weggelassen werden.
Wie oben erwähnt, MUSS der CTS-Verifier auf jedem Gerät und jeder Build-Version korrekt ausgeführt werden.
Da viele Builds jedoch sehr ähnlich sind, müssen Geräteimplementierer den
CTS-Verifier nicht explizit auf Builds ausführen, die sich nur in unwesentlichen Punkten unterscheiden. Insbesondere dürfen
Geräteimplementierungen, die sich nur durch die enthaltenen Sprachen, das Branding usw. von einer Implementierung unterscheiden, die den CTS
Verifier bestanden hat, den CTS
Verifier

Test UNTER UMSTÄNDEN AUSTELASSEN.
10.3. Referenzanwendungen
Geräteimplementierer MÜSSEN die Implementierungskompatibilität mit den folgenden Open
Source-Anwendungen testen:
Die Anwendungen „Apps for Android“ [Resources, 55]
Replica Island (im Android Market verfügbar)
Jede der oben genannten Apps MUSS auf der Implementierung gestartet werden und sich 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 MÖGLICH ist.
Jede Methode kann verwendet werden, sofern sie die gesamte auf dem Gerät vorinstallierte Software ersetzen kann.
Zum Beispiel erfüllen alle folgenden Ansätze
diese Anforderung:
Over-the-air-Downloads (OTA) mit Offline-Update über Neustart
„Tethered“-Updates über USB von einem Host-PC
„Offline“-Updates über einen Neustart und Update von einer Datei auf einem Wechseldatenträger
Der verwendete Updatemechanismus MUSS Updates unterstützen, ohne Nutzerdaten zu löschen. Das heißt,
der Aktualisierungsmechanismus MUSS private Daten der Anwendung und freigegebene Daten der Anwendung
erhalten. Die Upstream-Android-Software enthält einen Aktualisierungsmechanismus
, der diese Anforderung erfüllt.
Wenn nach der Markteinführung, aber innerhalb der in Absprache mit dem Android-Kompatibilitätsteam festgelegten angemessenen Lebensdauer eines Produkts ein Fehler in der Geräteimplementierung gefunden wird, der die Kompatibilität von Drittanbieteranwendungen beeinträchtigt, MUSS der Geräteimplementierer den Fehler über ein verfügbares Softwareupdate beheben, das gemäß dem oben 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 Compatibility Test Suite enthält 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.
Der Test basiert auf der Beispielanwendung „BluetoothChat“, die im Android-
Open-Source-Projektbaum enthalten ist. Für das Verfahren sind zwei Geräte erforderlich:
eine Geräteimplementierung, auf der der zu testende Software-Build ausgeführt wird
eine separate Geräteimplementierung, die bereits als kompatibel bekannt ist, und ein
Modell aus der zu testenden Geräteimplementierung – also eine „bekanntermaßen fehlerfreie“
Geräteimplementierung
Im folgenden Testverfahren werden diese Geräte als „Kandidat“ und „bekanntermaßen fehlerfreies Gerät“ bezeichnet.

Einrichtung und Installation
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.  Starten Sie BluetoothChat auf dem Testgerät, während Bluetooth deaktiviert ist.
2.  Prüfen Sie, ob das ausgewählte Gerät Bluetooth entweder aktiviert oder den Nutzer
über ein Dialogfeld auffordert, Bluetooth zu aktivieren.
Kopplung und Kommunikation testen
1.  Starten Sie die Bluetooth Chat App auf beiden Geräten.
2.  Machen Sie das bekannte Gerät in BluetoothChat über das
Menü sichtbar.
3.  Suchen Sie auf dem Kandidatengerät in BluetoothChat
(über das Dreipunkt-Menü) nach Bluetooth-Geräten und koppeln Sie es mit dem fehlerfreien Gerät
4.  Senden Sie von jedem Gerät mindestens zehn Nachrichten und prüfen Sie, ob das andere Gerät sie
richtig empfängt
5.  Schließen Sie die BluetoothChat App auf beiden Geräten durch Drücken der Start
-Taste.  Entkoppeln Sie jedes Gerät über die Geräteeinstellungen voneinander.
Testen Sie die Kopplung und Kommunikation in umgekehrter
Richtung
1.  Starten Sie die Bluetooth Chat App auf beiden Geräten.
2.  Machen Sie das gewünschte Gerät in BluetoothChat über das 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 Kandidaten.
4.  Senden Sie von jedem Gerät zehn 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 auf die Schaltfläche „Zurück“ drücken, um
zum Launcher zu gelangen.
Neustarts testen
1.  Starten Sie die Bluetooth Chat App auf beiden Geräten neu.
2.  Senden Sie von jedem Gerät zehn Nachrichten und prüfen Sie, ob das andere Gerät sie richtig empfängt.

Hinweis: Bei den obigen Tests gibt es einige Fälle, in denen ein Testabschnitt mit „Startseite“ und
andere mit „Zurück“ beendet wird. Diese Tests sind nicht redundant und nicht optional: Das Ziel besteht darin,
zu überprüfen, ob die Bluetooth API und der Bluetooth-Stack sowohl dann richtig funktionieren, wenn Aktivitäten
explizit beendet werden (durch Drücken der Schaltfläche „Zurück“, was „finish“ aufruft), als auch dann, wenn sie implizit
in den Hintergrund gesendet werden (durch Drücken der Schaltfläche „Startseite“). Jede Testsequenz MUSS
wie beschrieben ausgeführt werden.

Kompatibilitätsdefinition für Android 4.1 Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Kompatibilitätsdefinition für Android 4.1
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.