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 1.6
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Definition der Android-Kompatibilität: Android 1.6
Android 1.6 r2
Google Inc.
compatibility@android.com

1. Einführung
In diesem Dokument werden die Anforderungen aufgeführt, die Smartphones erfüllen müssen, um mit Android 1.6 kompatibel zu sein.
Für diese Definition wird vorausgesetzt, dass Sie mit dem Android-Kompatibilitätsprogramm vertraut sind
[Ressourcen, 1].
Die Verwendung von „muss“, „darf nicht“, „erforderlich“, „wird“, „wird nicht“, „sollte“, „sollte nicht“, „empfohlen“,
„kann“ und „optional“ erfolgt gemäß dem IETF-Standard, der in RFC2119 [Ressourcen, 2] definiert ist.
Im Sinne dieses Dokuments ist ein „Geräteimplementierer“ oder „Implementierer“ eine Person oder Organisation, die eine Hardware-/Softwarelösung mit Android 1.6 entwickelt.
Eine „Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte
Hardware-/Softwarelösung.
Damit Geräte mit Android 1.6 kompatibel sind, müssen sie folgende Anforderungen erfüllen:
1. MÜSSEN die in dieser Kompatibilitätsdefinition aufgeführten Anforderungen erfüllen, einschließlich aller Dokumente,
die durch Verweis einbezogen werden.
2. MÜSSEN die Android Compatibility Test Suite (CTS) bestehen, die im Rahmen des Android Open
Source Project verfügbar ist [Ressourcen, 3]. Der CTS testet die meisten, aber nicht alle Komponenten, die in diesem
Dokument beschrieben sind.
Wenn diese Definition oder die CTS nicht eindeutig oder unvollständig ist, liegt es in der Verantwortung des Geräteimplementers, für die Kompatibilität mit bestehenden Implementierungen zu sorgen.
Aus diesem Grund ist das
Open-Source-Projekt von Android [Ressourcen, 4] sowohl die Referenz- als auch die bevorzugte Implementierung von Android. Geräteimplementatoren
sollten ihre Implementierungen auf dem „Upstream“-Quellcode
basieren lassen, der im Android Open Source Project verfügbar ist. Theoretisch können einige Komponenten durch alternative Implementierungen ersetzt werden. Wir raten jedoch dringend davon ab, da das Bestehen der CTS-Tests dann deutlich schwieriger wird.

Der Implementierer ist dafür verantwortlich, dass die Verhaltenskompatibilität mit der
Standard-Android-Implementierung vollständig gegeben ist, einschließlich und über die Compatibility Test Suite hinaus.
2. Ressourcen
Diese Kompatibilitätsdefinition verweist auf eine Reihe von Ressourcen, die Sie hier finden.
1. Android-Kompatibilitätsprogramm – Übersicht: https://sites.google.com/a/android.com/compatibility/
how-it-works
2. IETF-Anforderungen gemäß RFC 2119: http://www.ietf.org/rfc/rfc2119.txt
3. Kompatibilitätstestsuite: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. Android Open Source Project: http://source.android.com/
5. API-Definitionen und ‑Dokumentation: http://developer.android.com/reference/packages.html
6. Contentanbieter: http://code.google.com/android/reference/android/provider/package-
summary.html
7. Verfügbare Ressourcen: http://code.google.com/android/reference/available-resources.html
8. Android-Manifestdateien: http://code.google.com/android/devel/bblocks-manifest.html
9. Referenz zu Android-Berechtigungen: http://developer.android.com/reference/android/
Manifest.permission.html
10. Build-Konstanten: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Gears-Browsererweiterungen: http://code.google.com/apis/gears/

13. Dalvik Virtual Machine-Spezifikation, im Verzeichnis „dalvik/docs“ eines Quellcode
Checkouts; auch verfügbar unter http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. App-Widgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. Benachrichtigungen: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. Styleguide für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Suchmanager: http://developer.android.com/reference/android/app/SearchManager.html
18. Toast: http://developer.android.com/reference/android/widget/Toast.html
19. Apps For Android: http://code.google.com/p/apps-for-android
20. Beschreibung der Android-APK-Datei: http://developer.android.com/guide/topics/fundamentals.html
21. Android Debug Bridge (adb): http://code.google.com/android/reference/adb.html
22. Dalvik Debug Monitor Service (ddms): http://code.google.com/android/reference/ddms.html
23. Monkey: http://developer.android.com/guide/developing/tools/monkey.html
24. Dokumentation zur Displayunabhängigkeit:
25. Konfigurationskonstanten: http://developer.android.com/reference/android/content/res/
Configuration.html
26. Displaymesswerte: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Kamera: http://developer.android.com/reference/android/hardware/Camera.html
28. Sensorkoordinatenraum: http://developer.android.com/reference/android/hardware/
SensorEvent.html
29. Referenz zu Sicherheit und Berechtigungen unter Android: http://developer.android.com/guide/topics/security/
security.html
Viele dieser Ressourcen stammen direkt oder indirekt aus dem Android 1.6 SDK und sind funktional mit den Informationen in der Dokumentation dieses SDK identisch.
Wenn diese
Kompatibilitätsdefinition nicht mit der SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als
maßgeblich. Alle technischen Details in den oben genannten Referenzen sind durch ihre Aufnahme in diese Definition
Teil dieser Kompatibilitätsdefinition.
3. Software
Die Android-Plattform umfasst sowohl eine Reihe von verwalteten („harten“) APIs als auch eine Reihe von sogenannten „weichen“ APIs
, z. B. das Intent-System, APIs mit nativem Code und APIs für Webanwendungen. In diesem Abschnitt werden die Hard- und Soft-APIs beschrieben, die für die Kompatibilität unerlässlich sind, sowie bestimmte andere relevante technische und
Nutzeroberflächen-
Verhaltensweisen. Geräteimplementierungen MÜSSEN alle Anforderungen in diesem Abschnitt erfüllen.
3.1. Kompatibilität mit verwalteten APIs
Die verwaltete (Dalvik-basierte) Ausführungsumgebung ist das primäre Mittel für Android-Anwendungen. Die
Android API (Application Programming Interface) ist die Gruppe von Android-Plattformschnittstellen, die für Anwendungen verfügbar sind, die in der verwalteten VM-Umgebung ausgeführt werden.
Geräteimplementierungen MÜSSEN vollständige Implementierungen aller dokumentierten APIs bereitstellen, die vom Android 1.6 SDK bereitgestellt werden, einschließlich aller dokumentierten Verhaltensweisen, z. B.:
1.

Core Android Java-language APIs [Resources, 5].
2. Contentanbieter [Resources, 6].
3. Ressourcen [Resources, 7].
4. AndroidManifest.xml-Attribute und ‑Elemente [Resources, 8].

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

3.2. Soft API-Kompatibilität
Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 enthält Android eine wichtige, nur zur Laufzeit verfügbare „Soft“-
API in Form von Intents, Berechtigungen und ähnlichen Aspekten von Android-Anwendungen
, die bei der Kompilierung der Anwendung nicht erzwungen werden können. In diesem Abschnitt werden die „Soft“-APIs und Systemverhalten beschrieben, die für die Kompatibilität mit Android 1.6 erforderlich sind.
Geräteimplementierungen MÜSSEN alle in diesem Abschnitt aufgeführten
Anforderungen erfüllen.
3.2.1. Berechtigungen
Geräteimplementierer MÜSSEN alle Berechtigungskonstanten unterstützen und erzwingen, wie auf der
Referenzseite für Berechtigungen [Ressourcen, 9] beschrieben. 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, 10] , 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 aktuell ausgeführten Android-Systems in einem für Menschen lesbaren Format.
android.os.Build.VERSION.RELEASE
Für Android 1.6 MUSS dieses Feld den Stringwert
„1.6“ haben.
Die Version des derzeit ausgeführten Android-Systems in einem Format
android.os.Build.VERSION.SDK
, das für den Anwendungscode von Drittanbietern zugänglich ist. Bei Android 1.6 muss dieses Feld
den Ganzzahlwert 4 haben.
Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Version
des derzeit ausgeführten Android-Systems in einem visuell lesbaren Format angibt.
Dieser Wert darf NICHT für verschiedene Versionen wiederverwendet werden, die an Endnutzer von
android.os.Build.VERSION.INCREMENTAL ausgeliefert werden. Dieses Feld wird in der Regel verwendet, um anzugeben, welche Build-Nummer oder
Änderungs-ID der Quellkontrollversion zum Generieren des Builds verwendet wurde. Es gibt keine Anforderungen an das 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 visuell lesbaren Format angibt.

Dieses Feld kann beispielsweise
android.os.Build.BOARD
verwendet werden, um die spezifische Version des Boards anzugeben, das das Gerät antreibt.
Es gibt keine Anforderungen an das spezifische Format dieses Felds.
Es darf jedoch NICHT null oder der leere String („""“) sein.
Ein vom Geräteimplementierer ausgewählter Wert,der den Namen des
android.os.Build.BRAND
Unternehmens, der Organisation, der Einzelperson usw. angibt, die das Gerät hergestellt hat, in
lesbarem Format. Dieses Feld kann beispielsweise verwendet werden, um den OEM

und/oder den Mobilfunkanbieter anzugeben, der das Gerät verkauft hat. Es gibt keine Anforderungen an das spezifische Format dieses Felds. Es darf jedoch nicht null oder der leere String ("") sein.
Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Konfiguration oder Version des Gehäuses (manchmal auch als „Industriedesign“ bezeichnet) des Geräts angibt.

Es gibt keine Anforderungen an das spezifische Format
dieses Felds, es darf jedoch NICHT null oder der leere String („""“) sein.
Ein String, der diesen Build eindeutig identifiziert. Sie sollte
für Menschen lesbar sein. Sie MUSS dieser Vorlage folgen:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
Beispiel: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/test-keys
Der Fingerabdruck darf KEINE Leerzeichen enthalten. Wenn andere Felder in der
Vorlage oben Leerzeichen enthalten, MÜSSEN sie im Fingerabdruck durch das ASCII-
Unterstrichzeichen („_“) ersetzt werden.
Ein String, der den Host, auf dem der Build erstellt wurde, eindeutig identifiziert, in einem für Menschen lesbaren Format.
android.os.Build.HOST
Es gibt keine Anforderungen an das spezifische Format dieses
Felds, es darf jedoch nicht null oder der leere String („"") sein.
Eine vom Geräteimplementierer ausgewählte Kennung, die sich auf eine bestimmte
Version bezieht, in einem für Menschen lesbaren Format. Dieses Feld kann mit
android.os.Build.VERSION.INCREMENTAL identisch sein, sollte aber einen Wert
android.os.Build.ID
haben, der für Endnutzer einigermaßen aussagekräftig ist. Es gibt keine
Anforderungen an das spezifische Format dieses Felds, es darf jedoch nicht
null oder der leere String („""“) sein.
Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des
Geräts enthält, wie er dem Endnutzer bekannt ist. Dies sollte derselbe Name sein
android.os.Build.MODEL
, 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 Geräts enthält.
MUSS menschenlesbar sein, ist aber nicht unbedingt für die Ansicht durch Endnutzer bestimmt.
android.os.Build.PRODUCT
Es gibt keine Anforderungen
an das spezifische Format dieses Felds, es darf jedoch nicht null oder der
leere String („"") sein.
Eine kommagetrennte Liste von Tags, die vom Geräteimplementierer ausgewählt werden und
die Build weiter unterscheiden. Beispiel: „unsigned,debug“. Dieses Feld
android.os.Build.TAGS
DARF NICHT null oder der leere String ("") sein. Ein einzelnes Tag (z. B.
"release") ist jedoch zulässig.
android.os.Build.TIME
Ein Wert, der den Zeitstempel der Erstellung angibt.
Wert, der vom Geräteimplementierer ausgewählt wird und die Laufzeitkonfiguration des Builds angibt.
Dieses Feld sollte einen der Werte
android.os.Build.TYPE
haben, die den drei gängigen Android-Laufzeitkonfigurationen entsprechen: „user“,
„userdebug“ oder „eng“.
Name oder Nutzer-ID des Nutzers (oder automatisierten Nutzers), der die
android.os.Build.USER
Build-Version erstellt hat. Es gibt keine Anforderungen an das spezifische Format dieses Felds.
Es darf jedoch NICHT null oder der leere String ("") sein.

3.2.3. Intent-Kompatibilität
Android verwendet Intents, um eine lockere Verknüpfung zwischen Anwendungen zu ermöglichen. In diesem Abschnitt werden die
Anforderungen an die Intent-Muster beschrieben, die von Geräteimplementierungen eingehalten WERDEN MÜSSEN. Mit
„geprüft“ ist gemeint, dass der Geräteimplementierer eine Android-Aktivität, einen Dienst oder eine andere
Komponente bereitstellen MUSS, die einen übereinstimmenden Intent-Filter angibt und das richtige Verhalten für jedes angegebene Intent-Muster bindet und implementiert.

3.2.3.1. Wichtige Anwendungsabsichten
Das Android-Upstream-Projekt definiert eine Reihe von Kernanwendungen wie einen Telefon-Dialer, einen Kalender,
ein Adressbuch und einen Musikplayer. Geräteimplementierer KÖNNEN diese Anwendungen durch
alternative Versionen ersetzen.
Alle diese alternativen Versionen MÜSSEN jedoch dieselben Intent-Muster einhalten, die vom Upstream-
Projekt bereitgestellt werden. Wenn ein Gerät beispielsweise einen alternativen Musikplayer enthält, muss es trotzdem das Intent-Muster
einhalten, das von Drittanbieteranwendungen zum Auswählen eines Titels ausgegeben wird. Geräteimplementierungen MÜSSEN alle in Anhang A aufgeführten Intent-Muster unterstützen.

3.2.3.2. Intent-Überschreibungen
Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierer zulassen, dass jedes in
Anhang A beschriebene Intent-Muster von Drittanbieter-Apps überschrieben wird. Das Upstream-Android-Open-Source-Projekt
ermöglicht 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 eine Bindung an diese Muster herstellen und die Kontrolle übernehmen.

Dieses Verbot schließt insbesondere die Deaktivierung der Benutzeroberfläche „Chooser“ ein, über die Nutzer
zwischen mehreren Anwendungen auswählen können, die alle dasselbe Intent-Muster verarbeiten.
3.2.3.3. Intent-Namespaces
Geräteimplementierer DÜRFEN KEINE Android-Komponenten einbinden, die neue Intent- oder
Broadcast Intent-Muster mit einem ACTION-, CATEGORY- oder anderen Schlüsselstring im Namespace „android.*“ berücksichtigen.
Geräteimplementierer DÜRFEN KEINE Android-Komponenten einbinden, die neue Intent- oder
Broadcast Intent-Muster mit einem ACTION-, CATEGORY- oder anderen Schlüsselstring in einem Paketbereich berücksichtigen,
der zu einer anderen Organisation gehört. Geräteimplementierer dürfen die in den Anhängen A oder B aufgeführten Intent
-Muster NICHT ändern oder erweitern.
Dieses Verbot entspricht dem für Java-Sprachklassen in Abschnitt 3.6.

3.2.3.4. Broadcast-Intents
Drittanbieteranwendungen nutzen die Plattform, um bestimmte Intents zu senden, um über Änderungen in der
Hardware- oder Softwareumgebung informiert zu werden. Android-kompatible Geräte MÜSSEN die öffentlichen
Intents als Reaktion auf entsprechende Systemereignisse senden. Eine Liste der erforderlichen Broadcast-Intents findest du in
Anhang B. Das SDK kann jedoch auch zusätzliche Broadcast-Intents definieren, die ebenfalls berücksichtigt werden MÜSSEN.

3.3. Native API-Kompatibilität
Verwalteter Code, der in Dalvik ausgeführt wird, kann nativen Code aufrufen, der in der .apk-Datei der Anwendung als ELF
.so-Datei bereitgestellt und für die entsprechende Gerätehardwarearchitektur kompiliert wurde. Geräteimplementierungen MÜSSEN
Code unterstützen, der in der verwalteten Umgebung ausgeführt wird, um nativen Code mithilfe der Standard-Java Native Interface (JNI)-Semantik aufzurufen.
Die folgenden APIs müssen für den nativen Code verfügbar sein:
• libc (C-Bibliothek)
• libm (Mathematische Bibliothek)
• JNI-Schnittstelle
• libz (Zlib-Komprimierung)
• liblog (Android-Protokollierung)
• Minimale Unterstützung für C++
• OpenGL ES 1.1
Diese Bibliotheken MÜSSEN mit den in Bionic vom Android Open Source Project bereitgestellten Versionen quellen- (d.h. Header-) und binärkompatibel (für eine bestimmte
Prozessorarchitektur) sein. Da
die Bionic-Implementierungen nicht vollständig mit anderen Implementierungen wie der GNU C-Bibliothek kompatibel sind, sollten Geräteimplementierer die Android-Implementierung verwenden.
Wenn Geräteimplementierer eine andere Implementierung dieser Bibliotheken verwenden, müssen sie für Header- und Binärkompatibilität sorgen.

Die Kompatibilität mit nativem Code ist eine Herausforderung. Aus diesem Grund möchten wir noch einmal betonen, dass Geräteimplementierer
DRINGEND die Upstream-Implementierungen der oben aufgeführten Bibliotheken verwenden sollten, um die Kompatibilität zu gewährleisten.

3.4. Web API-Kompatibilität
Viele Entwickler und Anwendungen nutzen das Verhalten der Klasse „android.webkit.WebView“ [Ressourcen,
11] für ihre Benutzeroberflächen. Daher muss die WebView-Implementierung mit allen Android-Implementierungen kompatibel sein.
Bei der Android Open Source-Implementierung wird die WebKit-Rendering-Engine-Version verwendet, um das WebView zu implementieren.

Da es nicht möglich ist, eine umfassende Testsuite für einen Webbrowser zu entwickeln, müssen Geräteimplementierer
den spezifischen Upstream-Build von WebKit in der WebView-Implementierung verwenden. Im Detail:
• WebView MUSS die WebKit-Build-Version 528.5 oder höher aus dem Upstream-Android Open Source-Baum für
Android 1.6 verwenden. Dieser Build enthält eine Reihe von Funktionen und Sicherheitskorrekturen für WebView.
• Der von WebView gemeldete User-Agent-String MUSS dieses Format haben:
Mozilla/5.0 (Linux; U; Android 1.6; <language>-<country>; <device
name>; Build/<build ID>) AppleWebKit/528.5+ (KHTML, wie Gecko)
Version/3.1.2 Mobile Safari/525.20.1

◦ Der String „<device name>“ MUSS mit dem Wert für
android.os.Build.MODEL übereinstimmen.
◦ Der String „<build ID>“ MUSS mit dem Wert für android.os.Build.ID übereinstimmen.
◦ Die Strings „<language>“ und „<country>“ SOLLTEN den üblichen Konventionen für
Landescode und Sprache entsprechen und SOLLTEN sich auf die aktuelle Landeseinstellung des Geräts zum Zeitpunkt der Anfrage beziehen.

Implementierungen KÖNNEN einen benutzerdefinierten User-Agent-String in der eigenständigen Browseranwendung enthalten. Außerdem kann der eigenständige Browser auf einer alternativen Browsertechnologie basieren (z. B. Firefox oder Opera).

Auch wenn eine alternative Browseranwendung bereitgestellt wird, muss die WebView-Komponente
, die für Drittanbieteranwendungen bereitgestellt wird, wie oben beschrieben auf WebKit basieren.
Die eigenständige Browseranwendung SOLLTE Gears unterstützen [Ressourcen, 12] und KANN
einige oder alle HTML5-Funktionen unterstützen.
3.5. API-Verhaltenskompatibilität
Das Verhalten der einzelnen API-Typen (verwaltet, soft, nativ und Web) muss mit der
bevorzugten Implementierung von Android übereinstimmen, die im Android Open Source Project verfügbar ist.
Zu den Bereichen der Kompatibilität gehören:
• Geräte DÜRFEN das Verhalten oder die Bedeutung eines Standard-Intents NICHT ändern.
• Geräte DÜRFEN den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, Content-Provider usw.) NICHT ändern.

• Geräte DÜRFEN die Semantik einer bestimmten Berechtigung NICHT ändern
Die obige Liste ist nicht vollständig. Die Geräteimplementierer müssen für die Verhaltenskompatibilität sorgen.
Aus diesem Grund sollten Geräteimplementierer nach Möglichkeit den über das
Android Open Source Project verfügbaren Quellcode verwenden, anstatt wichtige Teile des Systems neu zu implementieren.
Die Compatibility Test Suite (CTS) prüft große Teile der Plattform auf Verhaltenskompatibilität,
aber nicht alle. Es liegt in der Verantwortung des Implementators, für eine Verhaltenskompatibilität mit dem
Open-Source-Projekt für Android zu sorgen.
3.6. API-Namespaces
Android folgt den Paket- und Klassen-Namespace-Konventionen, die von der Java-Programmiersprache
definiert wurden. Zur Gewährleistung der Kompatibilität mit Drittanbieteranwendungen dürfen Geräteimplementierer
keine verbotenen Änderungen (siehe unten) an diesen Paketnamenräumen vornehmen:
• java.*
• javax.*
• sun.*
• android.*
• com.android.*
Zu den unzulässigen Änderungen gehören:
• Geräteimplementierungen dürfen die öffentlich zugänglichen APIs auf der Android-Plattform NICHT ändern,
indem sie Methoden- oder Klassensignaturen ändern oder Klassen oder Klassenfelder entfernen.

• Geräteimplementierer DÜRFEN die zugrunde liegende Implementierung der APIs ändern. Solche
Änderungen DÜRFEN jedoch NICHT das angegebene Verhalten und die Java-Signatur von öffentlich zugänglichen APIs beeinträchtigen.

• Geräteimplementierer DÜRFEN den oben genannten APIs KEINE öffentlich zugänglichen Elemente hinzufügen, z. B. Klassen oder
Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen.
Ein „öffentlich zugängliches Element“ ist jedes Konstrukt, das im
Upstream-Android-Quellcode nicht mit der Markierung „@hide“ versehen ist. Mit anderen Worten: Geräteimplementierer DÜRFEN KEINE neuen APIs freigeben oder
vorhandene APIs in den oben genannten Namespaces ändern. Geräteimplementierer KÖNNEN nur interne
Änderungen vornehmen. Diese Änderungen DÜRFEN jedoch nicht beworben oder Entwicklern anderweitig zugänglich gemacht werden.
Geräteimplementierer KÖNNEN benutzerdefinierte APIs hinzufügen. Diese APIs DÜRFEN sich jedoch nicht in einem Namespace befinden, der zu 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 ein Geräteimplementierer vorschlägt, einen der oben genannten Paket-Namespaces zu verbessern (z. B. durch Hinzufügen einer nützlichen neuen Funktion zu einer vorhandenen API oder durch Hinzufügen einer neuen API), sollte er
source.android.com aufrufen und gemäß den Informationen auf dieser Website mit dem Einreichen von Änderungen und Code beginnen.

Die oben genannten Einschränkungen entsprechen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java.
Mit diesem Abschnitt sollen diese Konventionen lediglich bekräftigt und durch Aufnahme in diese Kompatibilitätsdefinition verbindlich gemacht werden.

3.7. Kompatibilität mit virtuellen Maschinen
Ein kompatibles Android-Gerät muss die vollständige DEX-Bytecodespezifikation (Dalvik Executable) und die
Dalvik Virtual Machine-Semantik unterstützen [Ressourcen, 13].
3.8. Kompatibilität der Benutzeroberfläche
Die Android-Plattform enthält einige Entwickler-APIs, mit denen Entwickler die Benutzeroberfläche des Systems
steuern können. Geräteimplementierungen MÜSSEN diese standardmäßigen UI-APIs in die von ihnen entwickelten benutzerdefinierten Benutzeroberflächen einbinden, wie unten erläutert.

3.8.1. Widgets
Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, mit denen Anwendungen Endnutzern einen
App-Widget [Resources, 14]zur Verfügung stellen können. Die Android Open Source-Referenzversion enthält eine
Launcher-Anwendung mit Benutzeroberflächenelementen, mit denen Nutzer
App-Widgets auf dem Startbildschirm hinzufügen, ansehen und entfernen können.
Geräteimplementierer KÖNNEN einen alternativen Launcher (d.h. Startbildschirm) verwenden.
Alternative Launcher MÜSSEN eine integrierte Unterstützung für App-Widgets enthalten und Elemente der Benutzeroberfläche bereitstellen, mit denen App-Widgets direkt im Launcher hinzugefügt, angezeigt und entfernt werden können.
Alternative Launcher KÖNNEN
diese Elemente der Benutzeroberfläche weglassen. Wenn sie jedoch weggelassen werden, MUSS der Geräteimplementierer eine
separate Anwendung bereitstellen, auf die über den Launcher zugegriffen werden kann und mit der Nutzer App-Widgets hinzufügen, ansehen und entfernen können.

3.8.2. Benachrichtigungen
Android bietet APIs, mit denen Entwickler Nutzer über wichtige Ereignisse informieren können [Ressourcen, 15]. Geräteimplementierer MÜSSEN Unterstützung für jede der so definierten Benachrichtigungsklassen bieten, insbesondere für Töne,
Vibration, Leuchten und Statusleiste.

Darüber hinaus MUSS die Implementierung korrekt gerendert werden und alle in den APIs [Ressourcen, 7] oder im Styleguide für Statusleistensymbole [Ressourcen, 16] bereitgestellten Ressourcen (Symbole, Audiodateien usw.) müssen vorhanden sein.
Geräteimplementierer KÖNNEN eine alternative Nutzererfahrung für Benachrichtigungen bereitstellen, die von der
Referenzimplementierung von Android Open Source abweicht. Solche alternativen Benachrichtigungssysteme MÜSSEN jedoch vorhandene Benachrichtigungsressourcen wie oben beschrieben unterstützen.

3.8.3. Suche
Android bietet APIs [Ressourcen, 17], 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, während sie tippen, und Ergebnisse angezeigt werden.
Mit den Android APIs können Entwickler diese Benutzeroberfläche wiederverwenden, um eine Suche in ihren eigenen Apps bereitzustellen, und Ergebnisse für die gemeinsame globale Suchoberfläche bereitstellen.

Geräteimplementierungen MÜSSEN eine einzelne, gemeinsame, systemweite Suchoberfläche umfassen, die
in Echtzeit Vorschläge als Reaktion auf Nutzereingaben liefern kann. Geräteimplementierungen MÜSSEN die APIs implementieren, die es Entwicklern ermöglichen, diese Benutzeroberfläche wiederzuverwenden, um die Suche in ihren eigenen Anwendungen bereitzustellen.

Geräteimplementierungen MÜSSEN die APIs implementieren, die es Drittanbieter-Apps ermöglichen, dem Suchfeld Vorschläge hinzuzufügen, wenn es im Modus für die globale Suche ausgeführt wird.
Wenn keine Drittanbieter-Apps installiert sind, die diese Funktion nutzen, sollte standardmäßig die Anzeige von Ergebnissen und Vorschlägen der Websuchmaschine erfolgen.

Geräteimplementierungen KÖNNEN alternative Suchoberflächen enthalten, MÜSSEN aber eine dedizierte Suchschaltfläche (Hardware- oder Softwareschaltfläche) haben,
mit der jederzeit in jeder App das Such-Framework aufgerufen werden kann.
Das Verhalten der Suchschaltfläche muss der API-Dokumentation entsprechen.
3.8.4. Toasts
Anwendungen können die „Toast“ API (definiert in [Ressourcen, 18]) verwenden, um dem Endnutzer kurze nicht modale Strings anzuzeigen, die nach kurzer Zeit verschwinden.
Bei Geräteimplementierungen MÜSSEN Toasts von
Anwendungen für Endnutzer gut sichtbar angezeigt werden.
4. Referenzsoftwarekompatibilität
Geräteimplementierer MÜSSEN die Implementierungskompatibilität mit den folgenden Open-Source-
Anwendungen testen:
• Rechner (im SDK enthalten)
• Lunar Lander (im SDK enthalten)
• ApiDemos (im SDK enthalten)
• Die Anwendungen „Apps for Android“ [Ressourcen, 19]
Jede der oben genannten Apps MUSS auf der Implementierung gestartet werden und sich korrekt verhalten, damit die Implementierung als

kompatibel eingestuft wird.
5. Kompatibilität der Anwendungsverpackung
Geräteimplementierungen MÜSSEN Android-APK-Dateien installieren und ausführen, die vom Tool „aapt“
im offiziellen Android SDK generiert wurden [Ressourcen, 20].
Geräteimplementierungen dürfen die APK-, Android-Manifest- oder Dalvik-Bytecode-
Formate NICHT so erweitern, dass die Installation und Ausführung dieser Dateien auf anderen
kompatiblen Geräten verhindert wird. Geräteimplementierer SOLLTEN die Referenz-Upstream-Implementierung von Dalvik
und das Paketverwaltungssystem der Referenzimplementierung verwenden.
6. Multimediakompatibilität
Ein kompatibles Android-Gerät muss die folgenden Multimedia-Codecs unterstützen. Alle diese Codecs werden als Softwareimplementierungen in der bevorzugten Android-Implementierung des Android Open Source Project [Ressourcen, 4] bereitgestellt.

Weder Google noch die Open Handset Alliance geben eine Zusicherung dafür, dass diese
Codecs nicht durch Patente von Dritten eingeschränkt sind. Nutzer, die diesen Quellcode in Hardware- oder
Softwareprodukten verwenden möchten, werden darauf hingewiesen, dass für die Implementierung dieses Codes, einschließlich in Open-Source-Software oder
Shareware, möglicherweise Patentlizenzen der entsprechenden Patentinhaber erforderlich sind.
Audio
Name
Details zum Encoder/Decoder
Unterstützte Dateien
Mono-/Stereoinhalte in beliebiger
3GPP- (.3gp) und
Kombination von Standardbitraten
MPEG-4- (.mp4, .m4a)
AAC-LC/LTP
X
bis zu 160 kbit/s und Abtastfrequenzen. Keine Unterstützung für Roh
zwischen 8 und 48 kHz
AAC (.aac)
Mono-/Stereoinhalte in beliebigen
3GPP (.3gp) und
HE-AACv1
Kombinationen von Standardbitraten
MPEG-4 (.mp4, .m4a)
X
(AAC+)
bis zu 96 kbit/s und Abtastfrequenzen Dateien. Es wird keine Unterstützung für Roh
zwischen 8 und 48 kHz
AAC (.aac)
Mono-/Stereoinhalte in
HE-AACv2
3GPP (.3gp) und
Kombinationen von Standardbitraten
(erweiterte
MPEG-4 (.mp4, .m4a)
X
bis zu 96 kbit/s und Abtastrate
AAC+)
Dateien unterstützt. Keine Unterstützung für Roh
zwischen 8 und 48 kHz
AAC (.aac)
AMR-NB
4,75 bis 12,2 kbit/s bei
3GPP-Dateien (.3gp)
X
X
8 kHz
AMR-WB
9 Raten von 6,60 kbit/s bis 23,85
–3GPP-Dateien (.3gp)
X
kbit/s bei 16 kHz
MP3
Mono/Stereo 8–320 kbit/s konstante MP3-Dateien (.mp3)
X
(CBR) oder variable Bitrate (VBR)
Typ 0 und 1 (.mid, .xmf,
MIDI-Typ 0 und 1. DLS-Version 1
MIDI
X
.mxmf). Auch RTTTL/RTX
und 2. XMF und Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Unterstützung für Klingeltonformate
und iMelody (.imy)
RTTTL/RTX, OTA und iMelody
Ogg Vorbis
.ogg
X
8‑ und 16‑Bit-lineares PCM (Raten bis zum
PCM
X
WAVE
Limit der Hardware)
Bild
Dateien
Name
Encoder Decoder Details
Unterstützt
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
Video
Dateien
Name
Encoder Decoder Details
Unterstützt
3GPP (.3gp)
H.263
X
X
Dateien
3GPP (.3gp)
H.264
X
und MPEG-4
(.mp4) Dateien
MPEG4
X
3GPP (.3gp) Datei
SP
7. 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 oder adb [Ressourcen, 21]
Geräteimplementierungen MÜSSEN alle adb-Funktionen unterstützen, die im Android SDK dokumentiert sind.
Der geräteseitige adb-Daemon SOLLTE standardmäßig inaktiv sein. Es MUSS jedoch einen Mechanismus geben, mit dem Nutzer die Android Debug Bridge aktivieren können.

• Dalvik Debug Monitor Service oder ddms [Resources, 22]
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, MÜSSEN aber unterstützt werden,
wenn der Nutzer die Android Debug Bridge wie oben aktiviert hat.

• Monkey [Resources, 23]
Geräteimplementierungen MÜSSEN das Monkey-Framework enthalten und es für die Verwendung durch
Anwendungen verfügbar machen.
8. Hardwarekompatibilität
Android soll Geräteimplementierer bei der Entwicklung innovativer Formfaktoren und Konfigurationen unterstützen.
Gleichzeitig erwarten Android-Entwickler bestimmte Hardware, Sensoren und APIs auf allen Android-Geräten.
In diesem Abschnitt werden die Hardwarefunktionen aufgeführt, die alle mit Android 1.6 kompatiblen Geräte unterstützen müssen. Unter
Android 1.6 sind die meisten Hardwarefunktionen (z. B. WLAN, Kompass und Beschleunigungsmesser) erforderlich.
Wenn ein Gerät eine bestimmte Hardwarekomponente mit einer entsprechenden API für Drittanbieter hat, muss die Geräteimplementierung diese API gemäß der in der Android SDK-Dokumentation definierten Vorgehensweise implementieren.

8.1. Display
Android 1.6 enthält Funktionen, die unter bestimmten Umständen bestimmte automatische Skalierungs- und Transformationsvorgänge ausführen, um sicherzustellen, dass Anwendungen von Drittanbietern auf Hardwarekonfigurationen, für die sie nicht unbedingt explizit entwickelt wurden, einigermaßen gut laufen [Resources, 24].

Geräte MÜSSEN
diese Verhaltensweisen wie in diesem Abschnitt beschrieben implementieren.
8.1.1. Standarddisplaykonfigurationen
In dieser Tabelle sind die Standarddisplaykonfigurationen aufgeführt, die mit Android kompatibel sind:
Diagonale
Displaygröße
Displaydichte
Displaytyp
Breite (Pixel)
Höhe (Pixel)
Längenbereich
Gruppe
Gruppe
(Zoll)
QVGA
240
320
2,6–3,0
Klein
Niedrig
WQVGA
240
400
3,2–3,5
Normal
Niedrig
FWQVGA
240
432
3,5–3,8
Normal
Niedrig
HVGA
320
480
3,0–3,5
Normal
Mittel
WVGA
480
800
3,3–4,0
Normal
Hoch
FWVGA
480
854
3,5–4,0
Normal
Hoch
WVGA
480
800
4,8–5,5
Groß
Mittel
FWVGA
480
854
5,0–5,8
Groß
Mittel
Geräteimplementierungen, die einer der oben genannten Standardkonfigurationen entsprechen, MÜSSEN konfiguriert werden
, um die angegebene Bildschirmgröße über die Klasse „android.content.res.Configuration“ [Resources,
25] an Anwendungen zu melden.
Einige .apk-Pakete haben Manifeste, in denen sie nicht als unterstützend für einen bestimmten Dichtebereich gekennzeichnet sind.
Bei der Ausführung solcher Anwendungen gelten die folgenden Einschränkungen:

• Geräteimplementierungen MÜSSEN alle vorhandenen Ressourcen als Standardeinstellung für
„medium“ (in der SDK-Dokumentation als „mdpi“ bezeichnet) interpretieren.
• Bei der Verwendung auf einem Bildschirm mit niedriger Dichte MÜSSEN Geräteimplementierungen Medium-/
mdpi-Assets um den Faktor 0, 75 herunterskalieren.
• Bei der Verwendung auf einem Display mit hoher Dichte müssen Geräteimplementierungen Medium-/mdpi-Assets um den Faktor 1, 5 skalieren.

• Geräteimplementierungen dürfen Assets innerhalb eines Dichtebereichs NICHT skalieren und MÜSSEN Assets zwischen Dichtebereichen genau mit diesen Faktoren skalieren.

8.1.2. Nicht standardmäßige Displaykonfigurationen
Displaykonfigurationen, die nicht mit einer der in Abschnitt 8.2.1 aufgeführten Standardkonfigurationen übereinstimmen,
erfordern zusätzliche Überlegungen und Maßnahmen, um sie kompatibel zu machen. Geräteimplementierer MÜSSEN sich gemäß Abschnitt 12 an das Android-
Kompatibilitätsteam wenden, um Klassifizierungen für den Bildschirmgrößenbereich,die Dichte und den Skalierungsfaktor zu erhalten.
Wenn diese Informationen zur Verfügung gestellt werden, MÜSSEN sie in Geräteimplementierungen
wie angegeben implementiert werden.
Beachten Sie, dass einige Displaykonfigurationen (z. B. sehr große oder sehr kleine Bildschirme und einige Seitenverhältnisse)
grundsätzlich nicht mit Android 1.6 kompatibel sind. Daher sollten Geräteimplementierer sich
so früh wie möglich im Entwicklungsprozess an das Android-Kompatibilitätsteam wenden.
8.1.3. Displaymesswerte
Geräteimplementierungen MÜSSEN korrekte Werte für alle in
android.util.DisplayMetrics [Resources, 26] definierten Displaymesswerte angeben.
8.2. Tastatur
Geräteimplementierungen:
• MÜSSEN das Input Management Framework unterstützen, mit dem Drittanbieter
Entwickler Input Management Engines (d. h. Soft-Tastaturen) erstellen können, wie unter
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 [Resources, 25] angegebenen Formaten entspricht(d. h. QWERTY oder 12-Tasten)
8.3.
Bedienung ohne Touchbedienung
Geräteimplementierungen:
• Mögliche Optionen für die Bedienung ohne Touchbedienung (z. B. Trackball, 5‑Wege-Drehknopf oder
Rad) können weggelassen werden
• MÜSSEN über android.content.res.Configuration [Resources, 25] den korrekten Wert für die
Hardware des Geräts melden

8.4. Bildschirmausrichtung
Kompatible 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 Geräteimplementierungen kann entweder das Hoch- oder das Querformat als Standard ausgewählt werden.
Geräte MÜSSEN den korrekten Wert für die aktuelle Ausrichtung des Geräts melden, wenn sie über die APIs
android.content.res.Configuration.orientation, android.view.Display.getOrientation() oder andere APIs abgefragt werden.
8.5. Touchscreen-Eingabe
Geräteimplementierungen:
• MÜSSEN einen Touchscreen haben
• KÖNNEN einen kapazitiven oder resistiven Touchscreen haben
• MÜSSEN den Wert von android.content.res.Configuration [Resources, 25] angeben, der dem Typ des Touchscreens auf dem Gerät entspricht
8.6.
USB
Geräteimplementierungen:
• MUSS einen USB-Client implementieren, der mit einem USB-Host mit einem Standard-USB-A-Anschluss verbunden werden kann
• MUSS die Android Debug Bridge über USB implementieren (wie in Abschnitt 7 beschrieben)
• MUSS einen USB-Massenspeicherclient implementieren, wenn sich auf dem Gerät ein Wechsel-/Medienspeicher befindet
• SOLLTE auf Geräteseite den Micro-USB-Formfaktor verwenden
• SOLLTE Unterstützung für die USB-Massenspeicherspezifikation implementieren, damit auf den Wechsel- oder Festplattenspeicher auf dem Gerät von einem Host-PC aus zugegriffen werden kann
• DARF einen nicht standardmäßigen Anschluss auf Geräteseite haben. In diesem Fall MUSS das Gerät mit einem Kabel geliefert werden, mit dem die benutzerdefinierte Belegung mit dem Standard-USB-A-Anschluss verbunden werden kann
8.7.

Navigationstasten
Die Funktionen „Startseite“, „Menü“ und „Zurück“ sind für die Android-Navigation unerlässlich. Geräteimplementierungen MÜSSEN diese Funktionen jederzeit für den Nutzer verfügbar machen, unabhängig vom Anwendungsstatus.

Diese Funktionen MÜSSEN über spezielle Schaltflächen implementiert werden. Sie KÖNNEN mithilfe von Software, Gesten, Touchbedienung usw. implementiert werden. In diesem Fall MÜSSEN sie jedoch immer zugänglich sein und dürfen den verfügbaren Anzeigebereich der Anwendung nicht verdecken oder beeinträchtigen.

Geräteimplementierer MÜSSEN außerdem einen speziellen Suchschlüssel angeben. Geräteimplementierer KÖNNEN auch
Tasten zum Senden und Beenden von Telefonanrufen bereitstellen.
8.8. WLAN
Geräteimplementierungen MÜSSEN 802.11b und 802.11g unterstützen und KÖNNEN 802.11a unterstützen.

8.9. Kamera
Geräteimplementierungen MÜSSEN eine Kamera enthalten. Die Kamera muss folgende Anforderungen erfüllen:
• Sie MUSS eine Auflösung von mindestens 2 Megapixeln haben.
• Sie SOLLTE entweder einen Hardware-Autofokus oder einen Software-Autofokus im Kameratreiber haben (für die Anwendungssoftware transparent).
• Sie KANN eine Hardware mit Festfokus oder EDOF (erweiterte Tiefenschärfe) haben.
• Sie KANN einen Blitz haben.
Wenn die Kamera einen Blitz hat, darf die Blitzlampe NICHT leuchten, während eine Instanz von
android.hardware.Camera.PreviewCallback auf einer Kameravorschaufläche registriert ist.

Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs implementieren
[Resources, 27]:
1. Wenn eine Anwendung noch nie android.hardware.Camera.Parameters.setPreviewFormat(int) aufgerufen hat,
muss das Gerät android.hardware.PixelFormat.YCbCr_420_SP für die Vorschaudaten verwenden,
die an die Anwendungs-Callbacks übergeben werden.
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 der byte[]-Instanz, die an onPreviewFrame() übergeben wird, außerdem im NV21-Codierungsformat vorliegen.
(Dies ist das Format, das von der 7K-Hardwarefamilie nativ verwendet wird.)

NV21 MUSS also der Standard sein.
8.9.1. Kameras ohne Autofokus
Wenn ein Gerät keine Kamera mit Autofokus hat, MUSS der Geräteimplementierer die zusätzlichen Anforderungen in
diesem Abschnitt erfüllen. Geräteimplementierungen MÜSSEN die vollständige Camera API implementieren, die in der Android 1.6-SDK-
Dokumentation enthalten ist, und zwar auf eine angemessene Weise, unabhängig von den tatsächlichen Funktionen der Kamerahardware.
Wenn die Kamera unter Android 1.6 keinen Autofokus hat, MUSS die Geräteimplementierung Folgendes einhalten:
1. Das System MUSS eine schreibgeschützte Systemeigenschaft namens „ro.workaround.noautofocus“
mit dem Wert „1“ enthalten. Dieser Wert soll von Anwendungen wie dem Android Market verwendet werden, um
Gerätefunktionen selektiv zu identifizieren. Er wird in einer zukünftigen Version von Android durch eine
robuste API ersetzt.
2. Wenn eine Anwendung android.hardware.Camera.autoFocus() aufruft, MUSS das System die Rückrufmethode
onAutoFocus() für alle registrierten Instanzen von
android.hardware.Camera.AutoFocusCallback aufrufen, auch wenn keine Fokussierung stattgefunden hat.
So wird verhindert, dass bestehende Anwendungen durch endloses Warten auf einen Autofokus-
Callback, der nie kommt, unterbrochen werden.
3. Der Aufruf der Methode „AutoFocusCallback.onAutoFocus()“ MUSS vom Treiber oder
Framework in einem neuen Ereignis im Looper-Hauptthread des Frameworks ausgelöst werden. Das heißt, Camera.autoFocus()
DARF AutoFocusCallback.onAutoFocus() NICHT direkt aufrufen, da dies gegen das Android-
Framework-Threading-Modell verstößt und Apps beschädigt.
8.10. Beschleunigungsmesser
Geräteimplementierungen MÜSSEN einen 3‑Achsen-Beschleunigungsmesser enthalten und MÜSSEN Ereignisse mit mindestens 50 Hz senden können. Das vom Beschleunigungsmesser verwendete Koordinatensystem MUSS dem Android-Sensorkoordinatensystem entsprechen, wie in der Android API[Resources, 28] beschrieben.

8.11. Kompass
Geräteimplementierungen MÜSSEN einen 3‑Achsen-Kompass enthalten und MÜSSEN Ereignisse mit mindestens
10 Hz senden können. Das vom Kompass verwendete Koordinatensystem MUSS dem Android-Sensorkoordinatensystem
entsprechen, wie in der Android API definiert [Resources, 28].
8.12. GPS
Geräteimplementierungen MÜSSEN ein GPS und SOLLTEN eine Form von „Assisted GPS“
enthalten, um die Zeit bis zur GPS-Fixierung zu minimieren.
8.13. Telefonie
Geräteimplementierungen:
• MÜSSEN entweder GSM- oder CDMA-Telefonie umfassen
• MÜSSEN die entsprechenden APIs implementieren, wie in der Android SDK-Dokumentation unter
developer.android.com beschrieben
Hinweis: Diese Anforderung bedeutet, dass Geräte, die keine Smartphones sind, nicht mit Android 1.6 kompatibel sind. Android 1.6-Geräte MÜSSEN Telefoniehardware enthalten.
Informationen zu anderen Geräten finden Sie im Anhang C.

8.14. Lautstärkeregelung
Android-kompatible Geräte MÜSSEN einen Mechanismus haben, mit dem Nutzer die
Lautstärke erhöhen und verringern können. Geräteimplementierungen MÜSSEN diese Funktionen jederzeit für den Nutzer verfügbar machen,
unabhängig vom Anwendungsstatus. Diese Funktionen KÖNNEN mit physischen Hardwaretasten,
Software, Touch-Gesten, Touchbedienung usw. implementiert werden, MÜSSEN aber immer zugänglich sein und dürfen den verfügbaren Displaybereich der Anwendung nicht verdecken oder beeinträchtigen (siehe Display oben).

Wenn diese Schaltflächen verwendet werden, MÜSSEN die entsprechenden Schlüsselereignisse generiert und an die
Anwendung im Vordergrund gesendet werden. Wenn das Ereignis nicht von der Anwendung abgefangen und unterdrückt wird, MUSS die Geräteimplementierung das Ereignis als Systemlautstärkeregelung behandeln.

9. Leistungskompatibilität
Ein Ziel des Android-Kompatibilitätsprogramms besteht darin, für eine einheitliche Anwendungserfahrung für
Nutzer zu sorgen. Kompatible Implementierungen müssen nicht nur dafür sorgen, dass Anwendungen auf dem Gerät ordnungsgemäß ausgeführt werden, sondern auch, dass sie eine angemessene Leistung bieten und insgesamt nutzerfreundlich sind.

Geräteimplementierungen MÜSSEN die wichtigsten Leistungsmesswerte eines mit Android 1.6 kompatiblen Geräts erfüllen,
wie in der folgenden Tabelle dargestellt:
Messwert
Leistungsgrenzwert
Hinweise

Dieser Wert wird von CTS geprüft.
Die folgenden Anwendungen
Die Startzeit wird als Gesamtzeit gemessen, die
müssen innerhalb der
vergeht, bis die Standardaktivität für die
Anwendung
vollständig geladen ist.
Anwendung
Startzeit
Browser: weniger als 1.300 ms
MMS/SMS: weniger als 700 ms
Dalvik-VM und rufen Sie onCreate auf.

Wecker: weniger als 650 ms
Mehrere Anwendungen werden
Dieser Test wird von CTS durchgeführt.
veröffentlicht. Das erneute Starten der
Simultanen ersten Anwendung sollte
Anwendungen
innerhalb der
ursprünglichen Startzeit abgeschlossen werden.
10. Kompatibilität des Sicherheitsmodells
Geräteimplementierungen MÜSSEN ein Sicherheitsmodell implementieren, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument „Sicherheit und Berechtigungen“ in den APIs [Ressourcen, 29] in der
Android-Entwicklerdokumentation definiert.
Geräteimplementierungen MÜSSEN die Installation selbstsignierter
Anwendungen unterstützen, ohne dass zusätzliche Berechtigungen/Zertifikate von Drittanbietern/Behörden erforderlich sind.
Kompatible Geräte MÜSSEN insbesondere die folgenden Sicherheitsmechanismen unterstützen:
10.1. Berechtigungen
Geräteimplementierungen MÜSSEN das Android-Berechtigungsmodell gemäß der Android-Entwicklerdokumentation [Ressourcen, 9] unterstützen.
Insbesondere MÜSSEN Implementierungen jede Berechtigung erzwingen,
die in der SDK-Dokumentation beschrieben ist. Keine Berechtigungen dürfen weggelassen, geändert oder ignoriert werden.
Implementierungen KÖNNEN zusätzliche Berechtigungen hinzufügen, sofern die neuen Berechtigungs-ID-Strings nicht zum Namespace
android.* gehören.
10.2. Nutzer- und Prozessisolierung
Geräteimplementierungen MÜSSEN das Android-Sandbox-Modell für Anwendungen unterstützen, bei dem jede Anwendung
als eindeutige UID im Unix-Format und in einem separaten Prozess ausgeführt wird.
Geräteimplementierungen MÜSSEN das Ausführen mehrerer Anwendungen mit derselben Linux-Nutzer-ID unterstützen, sofern
die Anwendungen wie in der Referenz zu Sicherheit und Berechtigungen
[Ressourcen, 29] definiert korrekt signiert und erstellt sind.

10.3. Dateisystemberechtigungen
Geräteimplementierungen MÜSSEN das Android-Modell für Dateizugriffsberechtigungen unterstützen, wie in der Referenz zu Sicherheit und Berechtigungen [Resources, 29] definiert.

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

Der CTS ist für die Ausführung auf einem echten Gerät konzipiert. Wie jede Software kann auch die CTS Fehler enthalten.
Die CTS wird unabhängig von dieser Kompatibilitätsdefinition versioniert und es können mehrere Versionen der
CTS für Android 1.6 veröffentlicht werden. Bei solchen Releases werden jedoch nur Verhaltensfehler in den CTS
-Tests behoben. Es werden keine neuen Tests, Verhaltensweisen oder APIs für einen bestimmten Plattformrelease eingeführt.
12. Kontakt
Sie können sich unter compatibility@android.com an das Android-Kompatibilitätsteam wenden, um Fragen zu dieser Kompatibilitätsdefinition zu stellen oder Feedback dazu zu geben.

Anhang A: Erforderliche Anwendungsabsichten
HINWEIS: Diese Liste ist vorläufig und wird in Zukunft aktualisiert.
Anwendungsaktionen
Schemas MIME-Typen
(keine)
text/plain
http
text/html
Browser
android.intent.action.VIEW
https
application/xhtml+xml
application/
vnd.wap.xhtml+xml
(keine)
android.intent.action.WEB_SEARCH
http
(keine)
https
android.media.action.IMAGE_CAPTURE
android.media.action.STILL_IMAGE_CAMERA
Kamera
android.media.action.VIDEO_CAMERA
android.media.action.VIDEO_CAPTURE
vnd.android.cursor.dir/
android.intent.action.VIEW
Bild
android.intent.action.GET_CONTENT
vnd.android.cursor.dir/
android.intent.action.PICK
Video
android.intent.action.ATTACH_DATA
image/*
video/*
android.intent.action.VIEW
rtsp
video/mp4
video/3gp
android.intent.action.VIEW
http
video/3gpp
video/3gpp2
android.intent.action.DIAL
Telefon /
android.intent.action.VIEW
tel
Kontakte
android.intent.action.CALL
android.intent.action.DIAL
vnd.android.cursor.dir/
android.intent.action.VIEW
Person

vnd.android.cursor.dir/
Person
vnd.android.cursor.dir/
android.intent.action.PICK
Telefon
vnd.android.cursor.dir/
Postanschrift
vnd.android.cursor.item/
Person
vnd.android.cursor.item/
android.intent.action.GET_CONTENT
Telefon
vnd.android.cursor.item/
Postanschrift
Text/Plain
E-Mail
android.intent.action.SEND
Bild/*
Video/*
android.intent.action.VIEW
Mailto
android.intent.action.SENDTO
SMS
android.intent.action.VIEW
smsto
SMS / MMS android.intent.action.SENDTO
MMS
mmsto
audio/*
application/ogg
Musik
android.intent.action.VIEW
Datei
application/x-ogg
application/itunes
audio/mp3
audio/x-mp3
android.intent.action.VIEW
http
audio/mpeg
audio/mp4
audio/mp4a-latm
vnd.android.cursor.dir/
Interpretenalbum
vnd.android.cursor.dir/
Album
vnd.android.cursor.dir/
android.intent.action.PICK
Jetzt läuft
vnd.android.cursor.dir/
Titel
nd.android.cursor.dir/
Playlist
vnd.android.cursor.dir/
Video
media/*
audio/*
android.intent.action.GET_CONTENT
application/ogg
application/x-ogg
video/*

Inhalt
Paket
android.intent.action.VIEW
Datei
Installationsprogramm
Paket
Datei
android.intent.action.PACKAGE_INSTALL
http
https
android.intent.action.ALL_APPS
android.settings.SETTINGS
android.settings.WIRELESS_SETTINGS
android.settings.AIRPLANE_MODE_SETTINGS
android.settings.WIFI_SETTINGS
android.settings.APN_SETTINGS
android.settings.BLUETOOTH_SETTINGS
android.settings.DATE_SETTINGS
android.settings.LOCALE_SETTINGS
Einstellungen
android.settings.INPUT_METHOD_SETTINGS
com.android.settings.SOUND_SETTINGS
com.android.settings.DISPLAY_SETTINGS
android.settings.SECURITY_SETTING
android.settings.LOCATION_SOURCE_SETTINGS
android.settings.INTERNAL_STORAGE_SETTINGS
android.settings.MEMORY_CARD_SETTINGS
android.intent.action.SET_WALLPAPER
Suche
android.intent.action.SEARCH
Abfrage
android.intent.action.SEARCH_LONG_PRESS
Sprache
android.intent.action.VOICE_COMMAND
Kontaktverwaltung
Intent-Aktion
Beschreibung
Startet eine Aktivität, bei der der Nutzer
ATTACH_IMAGE
einen Kontakt auswählen kann, dem ein Bild angehängt werden soll.
Verwendet
EXTRA_CREATE_DESCRIPTION
mit SHOW_OR_CREATE_CONTACT , um
eine genaue Beschreibung anzugeben, die

angezeigt werden soll, wenn der Nutzer zum Erstellen eines neuen Kontakts aufgefordert wird.

Wird
mit SHOW_OR_CREATE_CONTACT verwendet,
EXTRA_FORCE_CREATE
um das Erstellen eines neuen Kontakts zu erzwingen, wenn kein
entsprechender Kontakt gefunden wird.
Dieser Intent wird ausgelöst, wenn ein
SEARCH_SUGGESTION_CLICKED
Suchvorschlag angeklickt wird.
Dieser Intent wird ausgelöst, wenn auf einen
Suchvorschlag zum Erstellen eines
Kontakts geklickt wird.
Dieser Intent wird ausgelöst, wenn auf einen
Suchvorschlag zum Wählen einer Nummer
geklickt wird.

Empfängt als Eingabe einen Daten-URI mit einem mailto:
SHOW_OR_CREATE_CONTACT
oder tel:-Schema.

Anhang B: Erforderliche Intents für StreamsHINWEIS: Diese Liste ist vorläufig und wird
zukünftig aktualisiert.
Intent-Aktion
Beschreibung
Broadcast-Aktion: Wird einmal gesendet, nachdem das
ACTION_BOOT_COMPLETED
System vollständig gestartet wurde.
Broadcast-Aktion: Wird einmal gesendet, wenn ein
ACTION_CALL_BUTTON
Aufruf empfangen wird.
Übertragungsaktion: Die
ACTION_CAMERA_BUTTON
Kamerataste wurde gedrückt.
Broadcast-Aktion: Die aktuelle
ACTION_CONFIGURATION_CHANGED
Geräte-Konfiguration (z. B. Ausrichtung, Sprache) hat sich
geändert.
ACTION_DATE_CHANGED
Übertragene Aktion: Das Datum hat sich geändert.
Broadcast-Aktion: Gibt an, dass der
ACTION_DEVICE_STORAGE_LOW
Speicherplatz auf dem Gerät
Broadcast-Aktion: Gibt an, dass der
ACTION_DEVICE_STORAGE_OK
Speicherplatz auf dem Gerät nicht mehr
Broadcast-Aktion: Gibt an, ob ein kabelgebundenes Headset
ACTION_HEADSET_PLUG
angesteckt oder abgetrennt ist.
Gesendete Aktion: Eine Eingabemethode wurde
ACTION_INPUT_METHOD_CHANGED
geändert.
Übertragungsaktion: Externe Medien wurden aus dem SD-Kartensteckplatz
ACTION_MEDIA_BAD_REMOVAL
entfernt, der Bereitstellungspunkt wurde jedoch nicht
getrennt.
Übertragene Aktion: Die „Media-Taste“ wurde
ACTION_MEDIA_BUTTON
gedrückt.
Broadcast-Aktion: Externe Medien sind vorhanden und werden

ACTION_MEDIA_CHECKING

��
Gesendete Aktion: Der Nutzer möchte
ACTION_MEDIA_EJECT
das externe Speichermedium entfernen.
Übertragungsaktion: Externe Medien sind vorhanden und
ACTION_MEDIA_MOUNTED
wurde an seinem Bereitstellungspunkt bereitgestellt.
Broadcast-Aktion: Externe Medien sind vorhanden, verwenden aber ein inkompatibles Dateisystem (oder sind leer). Der Pfad zu
ACTION_MEDIA_NOFS
dem Bereitstellungspunkt für die zu prüfenden Medien ist
im Feld „Intent.mData“ enthalten.

Übertragungsaktion: Externe Medien wurden
ACTION_MEDIA_REMOVED
entfernt.
Übertragungsaktion: Der Medienscanner hat den
ACTION_MEDIA_SCANNER_FINISHED
Scan eines Verzeichnisses abgeschlossen.
Übertragungsaktion: Der Medienscanner wird aufgefordert,
ACTION_MEDIA_SCANNER_SCAN_FILE
eine Datei zu scannen und der Mediendatenbank hinzuzufügen.

Übertragungsaktion: Der Medienscanner hat
ACTION_MEDIA_SCANNER_STARTED
das Scannen eines Verzeichnisses gestartet.
Übertragungsaktion: Externe Medien werden nicht bereitgestellt
ACTION_MEDIA_SHARED
, da sie über USB-Massenspeicher freigegeben werden.
Übertragungsaktion: Externe Medien sind vorhanden, können aber nicht bereitgestellt werden
ACTION_MEDIA_UNMOUNTABLE
.
Übertragungsaktion: Externe Medien sind vorhanden, aber
ACTION_MEDIA_UNMOUNTED
nicht an ihrem Bereitstellungspunkt bereitgestellt.
Broadcast-Aktion: Ein ausgehender Anruf wird gerade
ACTION_NEW_OUTGOING_CALL
getätigt.
Broadcast-Aktion: Auf dem Gerät wurde ein neues Anwendungspaket installiert.
ACTION_PACKAGE_ADDED

Broadcast-Aktion: Ein vorhandenes Anwendungspaket
ACTION_PACKAGE_CHANGED
wurde geändert (z.B. wurde eine Komponente aktiviert oder deaktiviert.

Broadcast-Aktion: Der Nutzer hat die Daten eines Pakets gelöscht.
Diesem Ereignis sollte ACTION_PACKAGE_RESTARTED
vorausgehen, nach dem alle persistenten Daten mit ACTION_PACKAGE_DATA_CLEARED
gelöscht und diese Nachricht gesendet werden.

Das freigegebene Paket
erhält diese Übertragung nicht. Die Daten enthalten
den Namen des Pakets.
Übertragungsaktion: Ein vorhandenes App-Paket
wurde vom Gerät entfernt. Die Daten
ACTION_PACKAGE_REMOVED
enthalten den Namen des Pakets. Das installierte Paket
erhält diesen Intent nicht .
Broadcast-Aktion: Es wurde eine neue Version eines Anwendungspakets
ACTION_PACKAGE_REPLACED
installiert, wodurch eine zuvor installierte Version ersetzt wurde.

Broadcast-Aktion: Der Nutzer hat ein
Paket neu gestartet und alle zugehörigen Prozesse wurden beendet.
Der gesamte zugehörige Laufzeitstatus (Prozesse,
ACTION_PACKAGE_RESTARTED
Benachrichtigungen usw.) sollte entfernt werden. Hinweis:
Das neu gestartete Paket empfängt diese
Übertragung nicht. Die Daten enthalten den Namen des
-Pakets.
Übertragungsaktion: Einige Inhaltsanbieter haben
Teile ihres Namespace, in denen sie neue
ACTION_PROVIDER_CHANGED
Ereignisse oder Elemente veröffentlichen, die für den Nutzer von besonderem
Interesse sein könnten.
ACTION_SCREEN_OFF
Broadcast-Aktion: Wird gesendet, nachdem das Display ausgeschaltet wurde.
ACTION_SCREEN_ON
Broadcast-Aktion: Wird gesendet, nachdem das Display eingeschaltet wurde.
Broadcast-Aktion: Eine Nutzer-ID wurde
ACTION_UID_REMOVED
aus dem System entfernt.
Broadcast-Aktion: Das Gerät ist in den
ACTION_UMS_CONNECTED
Mass Storage-Modus gewechselt.

Gesendete Aktion: Das Gerät hat den
ACTION_UMS_DISCONNECTED
Mass Storage-Modus
USB
verlassen.
Broadcast-Aktion: Wird gesendet, wenn der Nutzer
ACTION_USER_PRESENT
nach dem Aufwachen des Geräts anwesend ist (z. B. wenn
der Sperrbildschirm nicht mehr angezeigt wird).
Gesendete Aktion: Der aktuelle Systemhintergrund
ACTION_WALLPAPER_CHANGED
hat sich geändert.
ACTION_TIME_CHANGED
Übertragungsaktion: Die Uhrzeit wurde festgelegt.
ACTION_TIME_TICK
Übertragungsaktion: Die aktuelle Uhrzeit hat sich geändert.
ACTION_TIMEZONE_CHANGED
Gesendete Aktion: Die Zeitzone hat sich geändert.
Broadcast-Aktion: Der Ladezustand oder
ACTION_BATTERY_CHANGED
Akkustand hat sich geändert.
Broadcast-Aktion: Gibt an, dass der Akku
ACTION_BATTERY_LOW
des Geräts schwach ist. Diese Übertragung entspricht dem
Systemdialog „Warnung: Akkustand niedrig“.
Broadcast-Aktion: Gibt an, dass der Akku jetzt wieder aufgeladen ist
, nachdem er zuvor niedrig war. Diese wird
ACTION_BATTERY_OKAY
nach ACTION_BATTERY_LOW gesendet, sobald der Akku
wieder aufgeladen wurde.
Netzwerkstatus
Intent-Aktion
Beschreibung
Intent-Aktion, die darauf hinweist, dass sich der
NETWORK_STATE_CHANGED_ACTION
Status der WLAN-Verbindung geändert hat.
Intent-Aktion, die angibt, dass sich der
RSSI_CHANGED_ACTION
RSSI (Signalstärke) geändert hat.
Broadcast-Intent-Aktion, die angibt, dass eine
SUPPLICANT_STATE_CHANGED_ACTION
Verbindung zum Supplicant
hergestellt oder unterbrochen wurde.
Intent-Aktion, die angibt, dass das WLAN
WIFI_STATE_CHANGED_ACTION
aktiviert, deaktiviert, aktiviert wird,
deaktiviert wird oder unbekannt ist.
Die Netzwerk-IDs der konfigurierten Netzwerke
NETWORK_IDS_CHANGED_ACTION
können sich geändert haben.
Intent-Aktion, die darauf hinweist, dass sich die Einstellung
ACTION_BACKGROUND_DATA_SETTING_CHANGED für die Verwendung von Hintergrunddaten
geändert hat.
Intent, der darauf hinweist, dass sich die
CONNECTIVITY_ACTION
Netzwerkverbindung geändert hat.
Gesendete Aktion: Der Nutzer hat den
ACTION_AIRPLANE_MODE_CHANGED
Flugmodus des Smartphones aktiviert oder deaktiviert.

Anhang C: Zukünftige Überlegungen In diesem Anhang werden bestimmte Teile dieser Android
1.6-Kompatibilitätsdefinition erläutert und in einigen Fällen werden erwartete oder geplante Änderungen für eine zukünftige Version der Android-Plattform besprochen.
Dieser Anhang dient nur zu Informationszwecken und zur Planung.
Er ist nicht Teil der Definition der Kompatibilität für Android 1.6.
1. Geräte ohne Telefonfunktion
Android 1.6 ist ausschließlich für Smartphones gedacht. Die Telefonfunktionen sind nicht optional. In zukünftigen Versionen der Android-Plattform wird Telefonie voraussichtlich optional sein (und damit auch Android-Geräte ohne Telefon möglich sein). Derzeit sind jedoch nur Smartphones mit Android 1.6 kompatibel.

2. Bluetooth-Kompatibilität
Die Android 1.6-Version von Android unterstützt keine Bluetooth APIs. Aus Kompatibilitätsgründen
erfordert Bluetooth für diese Version der Plattform keine besonderen Maßnahmen. In einer zukünftigen Version von Android werden jedoch Bluetooth APIs eingeführt.
Ab diesem Zeitpunkt ist die Unterstützung von Bluetooth für die
Kompatibilität erforderlich.
Wir empfehlen daher dringend, dass Geräte mit Android 1.6 Bluetooth haben, damit sie mit zukünftigen Android-Versionen kompatibel sind, für die Bluetooth erforderlich ist.

3. Erforderliche Hardwarekomponenten
Alle Hardwarekomponenten in Abschnitt 8 (einschließlich WLAN, Magnetometer/Kompass, Beschleunigungsmesser usw.) sind
erforderlich und dürfen nicht fehlen. In zukünftigen Android-Versionen werden einige (aber nicht alle) dieser Komponenten voraussichtlich optional sein. Außerdem werden entsprechende Tools für Drittanbieter zur Verfügung gestellt, mit denen sie diese Änderungen bewältigen können.

4. Beispielanwendungen
Das Dokument zur Kompatibilitätsdefinition für eine zukünftige Version von Android enthält eine umfangreichere und
repräsentativere Liste von Anwendungen als die in Abschnitt 4 oben aufgeführten. Für Android 1.6 müssen die
in Abschnitt 4 aufgeführten Anwendungen getestet werden.
5. Touchscreens
In zukünftigen Versionen der Kompatibilitätsdefinition ist es unter Umständen zulässig, dass Geräte keinen Touchscreen haben.
Derzeit geht jedoch ein Großteil der Android-Framework-Implementierung von einem
Touchscreen aus. Wenn kein Touchscreen vorhanden ist,funktionieren die meisten aktuellen Android-Anwendungen von Drittanbietern nicht.
Daher ist unter Android 1.6 ein Touchscreen für die Kompatibilität erforderlich.

6. Leistung
In zukünftigen Versionen des CTS werden auch die CPU-Auslastung und die Leistung der folgenden
Komponenten einer Implementierung gemessen:
• 2D-Grafik
• 3D-Grafik
• Videowiedergabe
• Audiowiedergabe
• Bluetooth A2DP-Wiedergabe

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

Dokumentstruktur

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