Kompatibilitätsdefinition für Android 2.3

Copyright © 2010, Google Inc. Alle Rechte vorbehalten.
Kompatibilität@android.com

Inhaltsverzeichnis

1. Einleitung

In diesem Dokument werden die Anforderungen aufgeführt, die erfüllt sein müssen, damit Mobiltelefone mit Android 2.3 kompatibel sind.

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

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

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

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

Bitte beachten Sie, dass diese Kompatibilitätsdefinition herausgegeben wurde, um dem 2.3.3-Update für Android zu entsprechen, das API-Level 10 entspricht. Diese Definition ist veraltet und ersetzt die Kompatibilitätsdefinition für Android 2.3-Versionen vor 2.3.3. (Das heißt, die Versionen 2.3.1 und 2.3.2 sind veraltet.) Zukünftige Android-kompatible Geräte mit Android 2.3 MÜSSEN mit Version 2.3.3 oder höher ausgeliefert werden.

2. Ressourcen

1. IETF RFC2119-Anforderungsstufen: http://www.ietf.org/rfc/rfc2119.txt
2. Übersicht über das Android-Kompatibilitätsprogramm: http://source.android.com/docs/compatibility/index.html
3. Android Open Source-Projekt: 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. android.os.Build-Referenz: http://developer.android.com/reference/android/os/Build.html
7. Für Android 2.3 zulässige Versionszeichenfolgen: http://source.android.com/docs/compatibility/2.3/versions.html
8. android.webkit.WebView-Klasse: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. HTML5-Offline-Funktionen: http://dev.w3.org/html5/spec/Overview.html#offline
11. HTML5-Video-Tag: http://dev.w3.org/html5/spec/Overview.html#video
12. HTML5/W3C-Geolocation-API: http://www.w3.org/TR/geolocation-API/
13. HTML5/W3C-Webdatenbank-API: http://www.w3.org/TR/webdatabase/
14. HTML5/W3C IndexedDB-API: http://www.w3.org/TR/IndexedDB/
15. Spezifikation der Dalvik Virtual Machine: verfügbar im Android-Quellcode unter dalvik/docs
16. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. Benachrichtigungen: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
18. Anwendungsressourcen: http://code.google.com/android/reference/available-resources.html
19. Stilleitfaden für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
20. Suchmanager: http://developer.android.com/reference/android/app/SearchManager.html
21. Toasts: http://developer.android.com/reference/android/widget/Toast.html
22. Live-Hintergründe: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. Dokumentation zum Referenztool (für adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
24. Beschreibung der Android-Apk-Datei: http://developer.android.com/guide/topics/fundamentals.html
25. Manifestdateien: http://developer.android.com/guide/topics/manifest/manifest-intro.html
26. Monkey-Testtool: https://developer.android.com/studio/test/other-testing-tools/monkey
27. Liste der Android-Hardwarefunktionen: http://developer.android.com/reference/android/content/pm/PackageManager.html
28. Unterstützung mehrerer Bildschirme: http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
31. Sensorkoordinatenraum: http://developer.android.com/reference/android/hardware/SensorEvent.html
32. Bluetooth-API: http://developer.android.com/reference/android/bluetooth/package-summary.html
33. NDEF-Push-Protokoll: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. Kameraausrichtungs-API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
42. Referenz zu Android-Sicherheit und -Berechtigungen: http://developer.android.com/guide/topics/security/security.html
43. Apps für Android: http://code.google.com/p/apps-for-android

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

3. Software

Die Android-Plattform umfasst eine Reihe verwalteter APIs, eine Reihe nativer APIs und eine Reihe sogenannter „weicher“ APIs wie das Intent-System und Webanwendungs-APIs. In diesem Abschnitt werden die für die Kompatibilität wesentlichen Hard- und Soft-APIs sowie bestimmte andere relevante technische Verhaltensweisen und Verhaltensweisen der Benutzeroberfläche detailliert beschrieben. Geräteimplementierungen MÜSSEN alle Anforderungen in diesem Abschnitt erfüllen.

3.1. Verwaltete API-Kompatibilität

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

Geräteimplementierungen DÜRFEN KEINE verwalteten APIs auslassen, API-Schnittstellen oder Signaturen ändern, vom dokumentierten Verhalten abweichen oder No-Ops enthalten, es sei denn, dies ist in dieser Kompatibilitätsdefinition ausdrücklich zulässig.

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

3.2. Soft-API-Kompatibilität

Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 enthält Android auch eine bedeutende, nur zur Laufzeit verfügbare „weiche“ API in Form von Dingen wie Absichten, Berechtigungen und ähnlichen Aspekten von Android-Anwendungen, die beim Kompilieren der Anwendung nicht erzwungen werden können. In diesem Abschnitt werden die „weichen“ APIs und Systemverhalten beschrieben, die für die Kompatibilität mit Android 2.3 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 durchsetzen, wie auf der Berechtigungsreferenzseite [ Ressourcen, 5 ] dokumentiert. Beachten Sie, dass in Abschnitt 10 zusätzliche Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell aufgeführt sind.

3.2.2. Build-Parameter

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

3.2.3. Absichtskompatibilität

Android verwendet Intents, um eine lose gekoppelte Integration zwischen Anwendungen zu erreichen. In diesem Abschnitt werden Anforderungen im Zusammenhang mit den Absichtsmustern beschrieben, die von Geräteimplementierungen berücksichtigt werden MÜSSEN. Mit „gewürdigt“ ist gemeint, dass der Geräteimplementierer eine Android-Aktivität oder einen Android-Dienst bereitstellen MUSS, der einen passenden Intent-Filter angibt und an jedes angegebene Intent-Muster bindet und das korrekte Verhalten implementiert.

3.2.3.1. Kernanwendungsabsichten

Das Android-Upstream-Projekt definiert eine Reihe von Kernanwendungen, wie z. B. einen Telefonwähler, einen Kalender, ein Kontaktbuch, einen Musikplayer usw. Geräteimplementierer KÖNNEN diese Anwendungen durch alternative Versionen ersetzen.

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

Die folgenden Anwendungen gelten als Kernanwendungen des Android-Systems:

• Tischuhr
• Browser
• Kalender
• Taschenrechner
• Kontakte
• Email
• Galerie
• GlobalSearch
• Startprogramm
• Musik
• Einstellungen

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

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

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

3.2.3.2. Absichtsüberschreibungen

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

3.2.3.3. Absichts-Namespaces

Geräteimplementierer DÜRFEN KEINE Android-Komponenten enthalten, die neue Intent- oder Broadcast-Intent-Muster mithilfe einer ACTION, CATEGORY oder einer anderen Schlüsselzeichenfolge im Namespace android.* berücksichtigen. Geräteimplementierer DÜRFEN KEINE Android-Komponenten einschließen, die neue Intent- oder Broadcast-Intent-Muster mithilfe einer ACTION, CATEGORY oder einer anderen Schlüsselzeichenfolge in einem Paketbereich einer anderen Organisation berücksichtigen. Geräteimplementierer DÜRFEN KEINE Absichtsmuster ändern oder erweitern, die von den in Abschnitt 3.2.3.1 aufgeführten Kern-Apps verwendet werden.

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

3.2.3.4. Sendeabsichten

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

3.3. Native API-Kompatibilität

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

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

• MUSS Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code unter Verwendung der standardmäßigen JNI-Semantik (Java Native Interface) aufzurufen.
• MUSS mit jeder erforderlichen Bibliothek in der Liste unten quellkompatibel (dh Header-kompatibel) und binärkompatibel (für das ABI) sein
• MUSS die vom Gerät unterstützte native Application Binary Interface (ABI) über die android.os.Build.CPU_ABI -API genau melden
• Es MÜSSEN nur die ABIs gemeldet werden, die in der neuesten Version des Android NDK in der Datei docs/CPU-ARCH-ABIS.txt dokumentiert sind
• SOLLTE unter Verwendung des Quellcodes und der Header-Dateien erstellt werden, die im Upstream-Android-Open-Source-Projekt verfügbar sind

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

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

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

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

3.4. Webkompatibilität

Viele Entwickler und Anwendungen verlassen sich für ihre Benutzeroberflächen auf das Verhalten der Klasse android.webkit.WebView [ Ressourcen, 8 ], daher muss die WebView-Implementierung mit allen Android-Implementierungen kompatibel sein. Ebenso ist ein vollständiger, moderner Webbrowser für das Android-Benutzererlebnis von zentraler Bedeutung. Geräteimplementierungen MÜSSEN eine Version von android.webkit.WebView enthalten, die mit der Upstream-Android-Software konsistent ist, und MÜSSEN einen modernen HTML5-fähigen Browser enthalten, wie unten beschrieben.

3.4.1. WebView-Kompatibilität

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

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

Die WebView-Komponente SOLLTE möglichst viel HTML5 [ Ressourcen, 9 ] unterstützen. Geräteimplementierungen MÜSSEN mindestens jede dieser mit HTML5 in der WebView verknüpften APIs unterstützen:

• Anwendungscache/Offline-Betrieb [ Ressourcen, 10 ]
• das <video>-Tag [ Ressourcen, 11 ]
• Geolokalisierung [ Ressourcen, 12 ]

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

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

3.4.2. Browser-Kompatibilität

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

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

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

• Anwendungscache/Offline-Betrieb [ Ressourcen, 10 ]
• das <video>-Tag [ Ressourcen, 11 ]
• Geolokalisierung [ Ressourcen, 12 ]

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

3.5. API-Verhaltenskompatibilität

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

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

Die obige Liste ist nicht vollständig. Die Compatibility Test Suite (CTS) testet wesentliche Teile der Plattform auf Verhaltenskompatibilität, jedoch nicht alle. Es liegt in der Verantwortung des Implementierers, die Verhaltenskompatibilität mit dem Android Open Source Project sicherzustellen. Aus diesem Grund SOLLTEN Geräteimplementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt wesentliche Teile des Systems neu zu implementieren.

3.6. API-Namespaces

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

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

Zu den verbotenen Änderungen gehören:

• Geräteimplementierungen DÜRFEN die öffentlich zugänglichen APIs auf der Android-Plattform NICHT ändern, indem sie Methoden- oder Klassensignaturen ändern oder Klassen oder Klassenfelder entfernen.
• Geräteimplementierer KÖNNEN die zugrunde liegende Implementierung der APIs ändern, aber solche Änderungen DÜRFEN KEINE Auswirkungen auf das angegebene Verhalten und die Java-Sprachsignatur von öffentlich zugänglichen APIs haben.
• Geräteimplementierer DÜRFEN KEINE öffentlich zugänglichen Elemente (wie Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) zu den oben genannten APIs hinzufügen.

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

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

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

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

3.7. Kompatibilität virtueller Maschinen

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

Geräteimplementierungen mit Bildschirmen, die als mittlere oder niedrige Dichte klassifiziert sind, MÜSSEN Dalvik so konfigurieren, dass jeder Anwendung mindestens 16 MB Speicher zugewiesen werden. Geräteimplementierungen mit Bildschirmen, die als High-Density oder Extra-High-Density klassifiziert sind, MÜSSEN Dalvik so konfigurieren, dass jeder Anwendung mindestens 24 MB Speicher zugewiesen werden. Beachten Sie, dass Geräteimplementierungen möglicherweise mehr Speicher als diese Zahlen zuweisen.

3.8. Kompatibilität der Benutzeroberfläche

Die Android-Plattform umfasst einige Entwickler-APIs, die es Entwicklern ermöglichen, sich in die Benutzeroberfläche des Systems einzubinden. Geräteimplementierungen MÜSSEN diese Standard-UI-APIs in die von ihnen entwickelten benutzerdefinierten Benutzeroberflächen integrieren, wie unten erläutert.

3.8.1. Widgets

Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, die es Anwendungen ermöglichen, dem Endbenutzer ein „AppWidget“ zur Verfügung zu stellen [ Ressourcen, 16 ]. Die Android Open Source-Referenzversion enthält eine Launcher-Anwendung mit Elementen der Benutzeroberfläche, mit denen der Benutzer AppWidgets zum Startbildschirm hinzufügen, anzeigen und entfernen kann.

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

3.8.2. Benachrichtigungen

Android enthält APIs, die es Entwicklern ermöglichen, Benutzer über wichtige Ereignisse zu benachrichtigen [ Ressourcen, 17 ]. Geräteimplementierer MÜSSEN Unterstützung für jede so definierte Benachrichtigungsklasse bereitstellen; Konkret: Töne, Vibration, Licht und Statusleiste.

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

3.8.3. Suchen

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

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

Geräteimplementierungen KÖNNEN alternative Benutzeroberflächen für die Suche bereitstellen, SOLLTEN jedoch eine dedizierte Hard- oder Soft-Suchschaltfläche enthalten, die jederzeit in jeder App verwendet werden kann, um das Such-Framework aufzurufen, mit dem in der API-Dokumentation vorgesehenen Verhalten.

3.8.4. Toasts

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

3.8.5. Live-Hintergründe

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

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

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

4. Kompatibilität der Anwendungspakete

Geräteimplementierungen müssen Android ".APK" -Dateien installieren und ausführen, die vom "AAPT" -Tool generiert werden, das im offiziellen Android SDK [ Ressourcen, 23 ] enthalten ist.

Geräteimplementierungen dürfen weder den .APK [ Ressourcen, 24 ], Android Manifest [ Ressourcen, 25 ] oder Dalvik -Bytecode [ Ressourcen, 15 ] Formate so erweitern, dass diese Dateien verhindern würden, dass diese Dateien auf anderen kompatiblen Geräten korrekt installiert und ausgeführt werden. . Geräteimplementierer sollten die Referenz -Upstream -Implementierung von Dalvik und das Paketverwaltungssystem der Referenzimplementierung verwenden.

5. Multimedia -Kompatibilität

Geräteimplementierungen müssen alle Multimedia -APIs vollständig implementieren. Die Geräteimplementierungen müssen die Unterstützung aller nachstehend beschriebenen Multimedia -Codecs enthalten und sollten die unten beschriebenen Schallverarbeitungsrichtlinien erfüllen. Die Geräteimplementierungen müssen mindestens eine Form der Audioausgabe enthalten, z. B. Lautsprecher, Kopfhörerbuchse, externe Lautsprecherverbindung usw.

5.1. Mediencodecs

Die Geräteimplementierungen müssen die Multimedia -Codecs wie in den folgenden Abschnitten detailliert unterstützen. Alle diese Codecs werden als Software-Implementierungen in der bevorzugten Android-Implementierung aus dem Android Open-Source-Projekt bereitgestellt.

Bitte beachten Sie, dass weder Google noch die Open-Mobilset-Allianz eine Darstellung machen, dass diese Codecs von Patenten von Drittanbietern nicht belastet sind. Diejenigen, die diesen Quellcode in Hardware- oder Softwareprodukten verwenden möchten, wird empfohlen, dass die Implementierungen dieses Codes, einschließlich in Open -Source -Software oder Shareware, Patentlizenzen von den zuständigen Patentinhabern erfordern.

In den folgenden Tabellen werden spezifische Bitrate -Anforderungen für die meisten Video -Codecs nicht aufgeführt. Der Grund dafür ist, dass in der Praxis die aktuelle Gerätehardware nicht unbedingt Bitrate unterstützt, die genau den erforderlichen Bitraten zuordnen, die nach den entsprechenden Standards angegeben sind. Stattdessen sollten Geräteimplementierungen das höchste Bitrate -Praktikum auf der Hardware bis hin zu den durch die Spezifikationen definierten Grenzen unterstützen.

5.1.1. Mediendecoder

Die Geräteimplementierungen müssen eine Implementierung eines Decoders für jedes Codec und das in der folgende Tabelle beschriebene Format enthalten. Beachten Sie, dass Decoder für jeden dieser Medientypen durch das vorgelagerte Android Open-Source-Projekt bereitgestellt werden.

5.1.2. Mediencodierer

Geräteimplementierungen sollten Encoder für so viele der in Abschnitt 5.1.1 aufgeführten Medienformate enthalten. wie möglich. Einige Encoder sind jedoch keinen Sinn für Geräte, denen bestimmte optionale Hardware fehlt. Beispielsweise macht ein Encoder für das H.263 -Video keinen Sinn, wenn dem Gerät keine Kameras fehlen. Geräteimplementierungen müssen daher Mediencodierer gemäß den in der folgenden Tabelle beschriebenen Bedingungen implementieren.

In Abschnitt 7 finden Sie Einzelheiten zu den Bedingungen, unter denen Hardware durch Geräteimplementierungen weggelassen werden kann.

Zusätzlich zu den oben aufgeführten Encodern sollten Geräteimplementierungen einen H.264 -Encoder enthalten. Beachten Sie, dass die Kompatibilitätsdefinition für eine zukünftige Version geplant ist, um diese Anforderung an "Must" zu ändern. Das heißt, die H.264 -Codierung ist in Android 2.3 optional, wird jedoch von einer zukünftigen Version benötigt . Bestehende und neue Geräte, die Android 2.3 ausführen, werden sehr stark ermutigt, diese Anforderung in Android 2.3 zu erfüllen , oder sie können keine Android -Kompatibilität erreichen, wenn sie auf die zukünftige Version aktualisiert werden.

5.2. Audio Aufnahme

Wenn eine Anwendung die API von android.media.AudioRecord verwendet hat, um einen Audio -Stream aufzunehmen, sollten Geräteimplementierungen mit jedem dieser Verhaltensweisen Audio probieren und aufzeichnen:

• Die Verarbeitung von Rauschenreduzierungen sollte, falls vorhanden, deaktiviert werden.
• Wenn vorhanden, sollte die automatische Verstärkungssteuerung deaktiviert werden.
• Das Gerät sollte eine ungefähre Flachamplitude gegenüber Frequenzeigenschaften aufweisen. insbesondere ± 3 dB, von 100 Hz bis 4000 Hz
• Die Empfindlichkeit der Audioeingangsempfindlichkeit sollte so eingestellt werden, dass eine SPL-Quelle (90 dB Sound Power Level) bei 1000 Hz für 16-Bit-Proben RMS von 5000 RMS ergibt.
• Die PCM -Amplitudenpegel sollten linear verfolgen, wenn ein Eingangs -SPL -Veränderungen über mindestens 30 dB Bereich von -18 dB bis +12 dB RE 90 dB SPL am Mikrofon verfolgen.
• Die gesamte harmonische Verzerrung sollte von 100 Hz bis 4000 Hz bei 90 dB SPL -Eingangsniveau von 100 Hz betragen.

Hinweis: Während die oben beschriebenen Anforderungen als "sollte" für Android 2.3 angegeben sind, ist die Kompatibilitätsdefinition für eine zukünftige Version geplant, um diese in "Must" zu ändern. Das heißt, diese Anforderungen sind in Android 2.3 optional, werden jedoch von einer zukünftigen Version erforderlich sein . Bestehende und neue Geräte, die Android 2.3 ausführen, werden sehr stark ermutigt, diese Anforderungen in Android 2.3 zu erfüllen , oder sie können nicht in der Lage sein, Android -Kompatibilität zu erreichen, wenn sie auf die zukünftige Version aktualisiert werden.

5.3. Audio -Latenz

Die Audio -Latenz ist weitgehend definiert als das Intervall zwischen einem Antrag auf Audio -Wiedergabe oder Aufzeichnungsoperation und wenn die Geräteimplementierung tatsächlich mit dem Betrieb beginnt. Viele Anwendungsklassen stützen sich auf kurze Latenzen, um Echtzeiteffekte wie Soundeffekte oder VoIP-Kommunikation zu erzielen. Geräteimplementierungen mit Mikrofonhardware und Declare android.hardware.microphone sollten alle in diesem Abschnitt beschriebenen Audio -Latenzanforderungen erfüllen. In Abschnitt 7 finden Sie Einzelheiten zu den Bedingungen, unter denen Mikrofonhardware durch Geräteimplementierungen weggelassen werden kann.

Für die Zwecke dieses Abschnitts:

• "Kaltausgangslatenz" ist definiert als das Intervall zwischen dem Zeitpunkt, an dem eine Anwendung Audio -Wiedergabe fordert und wann der Ton spielt, wenn das Audiosystem vor der Anforderung nicht mehr war
• "Warm -Output -Latenz" ist definiert als das Intervall zwischen dem Zeitpunkt, an dem eine Anwendung die Audio -Wiedergabe anfordert und wann der Ton spielt, wenn das Audiosystem kürzlich verwendet wurde, aber derzeit nicht in der Lage ist (dh still)
• "Continuous Output Latenz" ist definiert als das Intervall zwischen dem Zeitpunkt, an dem eine Anwendung ein Beispiel ausgibt, und wenn der Lautsprecher den entsprechenden Sound physisch spielt, während das Gerät derzeit Audio zurückspielt
• "Kalteingangslatenz" ist definiert als das Intervall zwischen einer Anwendung, die Audioaufzeichnung anfordert und wenn die erste Stichprobe über seinen Rückruf geliefert wird, wenn das Audiosystem und das Mikrofon vor der Anforderung nicht mehr stand
• "Continuous Input Latenz" ist definiert, wenn ein Umgebungsschall auftritt und wenn das diesem Sound entsprechende Beispiel über seinen Rückruf an eine Aufnahmegelegenheit geliefert wird, während sich das Gerät im Aufnahmemodus befindet

Unter Verwendung der obigen Definitionen sollten Geräteimplementierungen jede dieser Eigenschaften aufweisen:

• Kaltausgangslatenz von 100 Millisekunden oder weniger
• Warmausgangslatenz von 10 Millisekunden oder weniger
• kontinuierliche Ausgangslatenz von 45 Millisekunden oder weniger
• Kalteingangslatenz von 100 Millisekunden oder weniger
• kontinuierliche Eingangslatenz von 50 Millisekunden oder weniger

Hinweis: Während die oben beschriebenen Anforderungen als "sollte" für Android 2.3 angegeben sind, ist die Kompatibilitätsdefinition für eine zukünftige Version geplant, um diese in "Must" zu ändern. Das heißt, diese Anforderungen sind in Android 2.3 optional, werden jedoch von einer zukünftigen Version erforderlich sein . Bestehende und neue Geräte, die Android 2.3 ausführen, werden sehr stark ermutigt, diese Anforderungen in Android 2.3 zu erfüllen , oder sie können nicht in der Lage sein, Android -Kompatibilität zu erreichen, wenn sie auf die zukünftige Version aktualisiert werden.

Wenn eine Geräteimplementierung die Anforderungen dieses Abschnitts erfüllt, kann sie die Unterstützung für Audio mit geringem Latenz melden, indem die Funktion "android.hardware.audio.low-Latency" über die Klasse von android.content.pm.PackageManager gemeldet wird. [ Ressourcen, 27 ] Wenn die Geräteimplementierung diese Anforderungen nicht erfüllt, darf sie die Unterstützung für Audio mit niedrigem Latenz nicht melden.

6. Kompatibilität für Entwicklerwerkzeuge

Geräteimplementierungen müssen die im Android SDK bereitgestellten Android -Entwickler -Tools unterstützen. Insbesondere müssen Android-kompatible Geräte kompatibel sein mit:

• Android Debugg Bridge (bekannt als ADB) [ Ressourcen, 23 ]
  Geräteimplementierungen müssen alle adb -Funktionen unterstützen, wie sie im Android SDK dokumentiert sind. Der Gerätseiten- adb Daemon sollte standardmäßig inaktiv sein, aber es muss einen benutzergerechten Mechanismus geben, um die Android-Debug-Brücke einzuschalten.
• DALVIK DEBUG Monitor Service (bekannt als DDMS) [ Ressourcen, 23 ]
  Geräteimplementierungen müssen alle ddms -Funktionen unterstützen, wie sie im Android SDK dokumentiert sind. Da ddms adb verwendet, sollte die Unterstützung für ddms standardmäßig inaktiv sein, muss jedoch wie oben der Benutzer die Android -Debug -Brücke aktiviert werden.
• Affe [ Ressourcen, 26 ]
  Die Geräteimplementierungen müssen das Monkey -Framework enthalten und die Verwendung von Anwendungen zur Verfügung stellen.

Die meisten Linux-basierten Systeme und Apple Macintosh-Systeme erkennen Android-Geräte mithilfe der Standard-Android-SDK-Tools ohne zusätzliche Unterstützung. Microsoft Windows Systems benötigen jedoch normalerweise einen Treiber für neue Android -Geräte. (Zum Beispiel 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 Gerät mit dem adb -Protokoll. Diese Treiber müssen für Windows XP, Windows Vista und Windows 7 in 32-Bit- und 64-Bit-Versionen bereitgestellt werden.

7. Hardwarekompatibilität

Android soll es Geräteimplementierern ermöglichen, innovative Formularfaktoren und Konfigurationen zu erstellen. Gleichzeitig schreiben Android -Entwickler innovative Anwendungen, die sich auf die verschiedenen Hardware und Funktionen stützen, die über die Android -APIs verfügbar sind. Die Anforderungen in diesem Abschnitt stimmen ein Gleichgewicht zwischen Innovationen, die Gerätenimplementierern zur Verfügung stehen, und den Anforderungen der Entwickler, um sicherzustellen, dass ihre Apps nur für Geräte zur Verfügung stehen, auf denen sie ordnungsgemäß ausgeführt werden.

Wenn ein Gerät eine bestimmte Hardwarekomponente enthält, die über eine entsprechende API für Entwickler von Drittanbietern verfügt, muss die Geräteimplementierung diese API implementieren, wie in der Android-SDK-Dokumentation beschrieben. Wenn eine API in der SDK mit einer Hardwarekomponente interagiert, die als optional angegeben ist und die Geräteimplementierung diese Komponente nicht besitzt:

• Vollständige Klassendefinitionen (wie vom SDK dokumentiert) für die API der Komponente muss noch vorhanden sein
• Das Verhalten der API muss in vernünftiger Weise als No-Ops implementiert werden
• API -Methoden müssen NULL -Werte zurückgeben, sodass durch die SDK -Dokumentation zulässig ist
• API-Methoden müssen keine OP-Implementierungen von Klassen zurückgeben, bei denen Nullwerte in der SDK-Dokumentation nicht zulässig sind
• API -Methoden dürfen keine Ausnahmen veröffentlichen, die nicht in der SDK -Dokumentation dokumentiert wurden

Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telefonie-API: Selbst auf Nicht-Telefon-Geräten müssen diese APIs als angemessene No-OPS implementiert werden.

Geräteimplementierungen müssen genaue Hardware -Konfigurationsinformationen über die Methoden getSystemAvailableFeatures() und hasSystemFeature(String) auf der Klasse android.content.pm.PackageManager über die Klasse GetSystemApleableFeatures () und HassystemFeature -Klasse melden. [ Ressourcen, 27 ]

7.1. Anzeige und Grafiken

Android 2.3 umfasst Einrichtungen, die die Anwendungsvermögen und UI-Layouts für das Gerät automatisch anpassen, um sicherzustellen, dass Drittanbieter-Anwendungen auf einer Vielzahl von Hardwarekonfigurationen gut ausgeführt werden [ Ressourcen, 28 ]. Geräte müssen diese APIs und Verhaltensweisen ordnungsgemäß implementieren, wie in diesem Abschnitt beschrieben.

7.1.1. Bildschirmkonfigurationen

Geräteimplementierungen können Bildschirme aller Pixelabmessungen verwenden, vorausgesetzt, sie erfüllen die folgenden Anforderungen:

• Die Bildschirme müssen mindestens 2,5 Zoll in der physikalischen diagonalen Größe betragen
• Die Dichte muss mindestens 100 dpi sein
• Das Seitenverhältnis muss zwischen 1,333 (4: 3) und 1,779 (16: 9) liegen.
• Die verwendete Display -Technologie besteht aus quadratischen Pixeln

Geräteimplementierungen mit einem Bildschirm erfüllen die oben genannten Anforderungen als kompatibel, und es sind keine zusätzlichen Maßnahmen erforderlich. Die Android Framework -Implementierung berechnet automatisch Anzeigeeigenschaften wie Bildschirmgröße und Dichte Eimer. In den meisten Fällen sind die Rahmenentscheidungen die richtigen. Wenn die Standard -Framework -Berechnungen verwendet werden, ist keine zusätzliche Aktion erforderlich. Geräteimplementierer, die die Standardeinstellungen ändern möchten, oder einen Bildschirm verwenden, der die oben genannten Anforderungen nicht erfüllt, müssen sich an das Android -Kompatibilitätsteam wenden, um Anleitungen zu erhalten, wie in Abschnitt 12 vorgesehen.

Die Einheiten, die nach den oben genannten Anforderungen verwendet werden, sind wie folgt definiert:

• "Physikalische diagonale Größe" ist der Abstand in Zoll zwischen zwei gegensätzlichen Ecken des beleuchteten Teils des Displays.
• "DPI" (was "Punkte pro Zoll" bedeutet) ist die Anzahl der Pixel, die durch eine lineare horizontale oder vertikale Spanne von 1 umfassen. Dabei werden die DPI -Werte aufgeführt, sowohl horizontale als auch vertikale DPI müssen in den Bereich fallen.
• "Seitenverhältnis" ist das Verhältnis der längeren Dimension des Bildschirms zur kürzeren Dimension. Beispielsweise wäre eine Anzeige von 480 x 854 Pixel 854 /480 = 1,779 oder ungefähr "16: 9".

Geräteimplementierungen dürfen nur Anzeigen mit einer einzelnen statischen Konfiguration verwenden. Das heißt, Geräteimplementierungen dürfen mehrere Bildschirmkonfigurationen nicht aktivieren. Da beispielsweise ein typisches Fernsehen mehrere Auflösungen wie 1080p, 720p usw. unterstützt, ist diese Konfiguration nicht mit Android 2.3 kompatibel. (Die Unterstützung für solche Konfigurationen wird jedoch untersucht und für eine zukünftige Version von Android geplant.)

7.1.2. Metriken anzeigen

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

7.1.3. Deklarierte Bildschirmunterstützung

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

7.1.4. Bildschirmausrichtung

Kompatible Geräte müssen die dynamische Orientierung durch Anwendungen entweder auf Porträt- oder Landschaftsbildschirmorientierung unterstützen. Das heißt, das Gerät muss die Anfrage der Anwendung nach einer bestimmten Bildschirmausrichtung respektieren. Geräteimplementierungen können entweder eine Porträt- oder Landschaftsorientierung als Standardeinstellung auswählen. Geräte, die nicht physisch gedreht werden können, können diese Anforderung durch "Briefkasten" -Anwendungen erfüllen, die den Porträtmodus anfordern und nur einen Teil der verfügbaren Anzeige verwenden.

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

7.1.5. 3D -Grafikbeschleunigung

Geräteimplementierungen müssen OpenGL ES 1.0 unterstützen, wie dies von den Android 2.3 -APIs erforderlich ist. Für Geräte, denen 3D-Beschleunigungshardware fehlt, wird eine Software-Implementierung von OpenGL ES 1.0 durch das vorgelagerte Android Open-Source-Projekt bereitgestellt. Geräteimplementierungen sollten OpenGL ES 2.0 unterstützen.

Implementierungen können offene GL es 2.0 -Unterstützung auslassen. Wenn die Unterstützung jedoch weggelassen wird, dürfen Geräteimplementierungen nicht als Unterstützung von OpenGL ES 2.0 melden. Insbesondere, wenn einem Gerät implementiert wird, fehlt OpenGL ES 2.0 -Unterstützung:

• Die verwaltete APIs GLES10.getString() z.
• Die nativen C/C ++ - OpenGL -APIs (dh diejenigen, die Apps über libgles_v1cm.so, libgles_v2. oder libegl.so verfügbar sind) dürfen die Unterstützung für OpenGL ES 2.0 nicht melden.

Wenn eine Geräteimplementierung OpenGL ES 2.0 unterstützt , muss sie diese Unterstützung über die gerade aufgeführten Routen genau berichten.

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

7.2. Eingabegeräte

Android 2.3 unterstützt eine Reihe von Modalitäten für Benutzereingaben. Geräteimplementierungen müssen Benutzereingabegeräte wie in diesem Abschnitt vorgesehen.

7.2.1. Tastatur

Geräteimplementierungen:

• Muss die Unterstützung für das Input -Management -Framework (mit dem Entwickler von Drittanbietern ermöglicht werden, Input -Management -Motoren zu erstellen - dh Soft -Tastatur) wie bei Entwickler detailliert. undroid.com detailliert
• Muss mindestens eine Implementierung von Soft -Tastaturen liefern (unabhängig davon, ob eine harte Tastatur vorhanden ist)
• Kann zusätzliche Implementierungen für Softtastaturen enthalten
• Kann eine Hardware -Tastatur beinhalten
• Ich darf keine Hardware-Tastatur enthalten, die nicht mit einem der in android.content.res.Configuration.keyboard angegebenen Formate übereinstimmt.

7.2.2. Nicht-Touch-Navigation

Geräteimplementierungen:

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

7.2.3. Navigationsschlüssel

Das Heim-, Menü- und Rückfunktionen sind für das Android -Navigationsparadigma von wesentlicher Bedeutung. Geräteimplementierungen müssen diese Funktionen dem Benutzer jederzeit zur Verfügung stellen, unabhängig vom Anwendungszustand. Diese Funktionen sollten über dedizierte Schaltflächen implementiert werden. Sie können mit Software, Gesten, Touch Panel usw. implementiert werden. In diesem Fall müssen sie jedoch immer zugänglich sein und nicht den verfügbaren Anwendungsdisplayerbereich.

Geräteimplementierer sollten auch einen dedizierten Suchschlüssel bereitstellen. Geräteimplementierer können auch Sende- und Endschlüssel für Telefonanrufe bereitstellen.

7.2.4. Touchscreen-Eingabe

Geräteimplementierungen:

• Muss einen Touchscreen haben
• Kann entweder kapazitiv oder widerstandsfähigem Touchscreen haben
• Muss den Wert von android.content.res.Configuration [ Ressourcen, 30 ] melden, die dem Typ des spezifischen Touchscreen auf dem Gerät entsprechen
• Sollte unabhängig voneinander verfolgte Zeiger unterstützen, wenn der Touchscreen mehrere Zeiger unterstützt

7.3. Sensoren

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

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

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

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

Die Android 2.3 -APIs führt einen Begriff eines "Streaming" -Sensors ein, der Daten kontinuierlich und nicht nur dann zurückgibt, wenn sich die Daten ändert. Geräteimplementierungen müssen kontinuierlich periodische Datenproben für jede API liefern, die durch die Android 2.3 -SDK -Dokumentation als Streaming -Sensor angegeben ist.

7.3.1. Beschleunigungsmesser

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

• Muss in der Lage sein, Veranstaltungen zu 50 Hz oder mehr zu liefern
• Muss das Android -Sensorkoordinatensystem gemäß den Android -APIs entsprechen (siehe [ Ressourcen, 31 ])
• Muss in der Lage sein, von Freefall bis zu zweimal Schwerkraft (2 g) oder mehr bei einem dreidimensionalen Vektor zu messen
• Muss 8 Bit Genauigkeit oder mehr haben
• Muss eine Standardabweichung von nicht mehr als 0,05 m/s^2 haben

7.3.2. Magnetometer

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

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

7.3.3. GPS

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

7.3.4. Gyroskop

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

• Muss in der Lage sein, die Orientierungsänderungen zu messen, die bis zu 5,5*PI -Radianer/Sekunde (dh ungefähr 1.000 Grad pro Sekunde) messen können (ca. 1.000 Grad)
• Muss in der Lage sein, Veranstaltungen zu 100 Hz oder mehr zu liefern
• Muss 8 Bit Genauigkeit oder mehr haben

7.3.5. Barometer

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

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

7.3.7. Thermometer

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

7.3.7. Photometer

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

7.3.8. Näherungssensor

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

7.4. Datenkonnektivität

Netzwerkkonnektivität und Zugriff auf das Internet sind wichtige Funktionen von Android. In der Zwischenzeit verleiht die Interaktion mit Geräte-zu-Geräte den Android-Geräten und -anwendungen einen erheblichen Wert. Geräteimplementierungen müssen die Anforderungen an die Datenkonnektivität in diesem Abschnitt erfüllen.

7.4.1. Telefonie

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

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

7.4.2. IEEE 802.11 (WiFi)

Android 2.3 -Geräteimplementierungen sollten die Unterstützung für eine oder mehrere Formulare von 802.11 (b/g/a/n usw.) enthalten, wenn eine Geräteimplementierung die Unterstützung für 802.11 enthält, die entsprechende Android -API implementieren muss.

7.4.3. Bluetooth

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

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

7.4.4. Nahfeldkommunikation

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

• Muss die Funktion von Android.hardware.nfc bei der Methode android.content.pm.PackageManager.hasSystemFeature() melden. [ Ressourcen, 27 ]
• Muss in der Lage sein, NDEF -Nachrichten über die folgenden NFC -Standards zu lesen und zu schreiben:
  • Muss in der Lage sein, als NFC Forum Reader/Writer (wie vom NFC Forum Technical Specification NFCForum-TS-DigitalProtocol-1.0) zu fungieren sein.
    • NFCA (ISO14443-3a)
    • NFCB (ISO14443-3B)
    • NFCF (JIS 6319-4)
    • NFCV (ISO 15693)
    • Isodep (ISO 14443-4)
    • NFC Forum Tag Typen 1, 2, 3, 4 (definiert durch das NFC -Forum)
  • Muss in der Lage sein, Daten über die folgenden Peer-to-Peer-Standards und -protokolle zu übertragen und zu empfangen:
    • ISO 18092
    • LLCP 1.0 (definiert vom NFC -Forum)
    • SDP 1.0 (definiert vom NFC -Forum)
    • Ndef Push -Protokoll [ Ressourcen, 33 ]
  • Muss im NFC -Erkennungsmodus nach allen unterstützten Technologien scannen.
  • Sollte im NFC -Erkennungsmodus sein, während das Gerät mit dem aktiven Bildschirm wach ist.

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

  Darüber hinaus sollten Geräteimplementierungen die folgenden weit verbreiteten Mifare-Technologien unterstützen.

  • Mifare Classic (NXP MF1S503X [ Ressourcen, 34 ], MF1S703X [ Ressourcen, 35 ])
  • Mifare Ultralight (NXP MF0ICU1 [ Ressourcen, 36 ], MF0ICU2 [ Ressourcen, 37 ])
  • NDEF auf Mifare Classic (NXP AN130511 [ Ressourcen, 38 ], AN130411 [ Ressourcen, 39 ])

  Beachten Sie, dass Android 2.3.3 APIs für diese Mifare -Typen enthält. Wenn eine Geräteimplementierung Mifare unterstützt, ist dies:

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

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

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

  7.4.5. Mindestnetzwerkfähigkeit

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

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

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

  7.5. Kameras

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

  7.5.1. Nach hinten gerichtete Kamera

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

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

  7.5.2. Front-Kamera

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

  • Muss eine Auflösung von mindestens VGA haben (dh 640x480 Pixel)
  • Darf keine vorne gerichtete Kamera als Standardeinstellung für die Kamera-API verwenden. Das heißt, die Kamera-API in Android 2.3 bietet eine spezielle Unterstützung für Kameras vorne, und Geräteimplementierungen dürfen die API nicht so konfigurieren, dass sie eine Kamera vorne mit der vorderen Kamera behandelt, auch wenn sie die einzige Kamera auf ist das Gerät.
  • Kann Funktionen (z. B. Autofokus, Blitz usw.) enthalten, die nach hinten gerichteten Kameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.
  • Muss horizontal reflektieren (dh Spiegel) den von einer App in einem Camerapreview angezeigten Stream wie folgt:
  • Wenn die Geräteimplementierung vom Benutzer (z.
  • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 40 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
  • Otherwise, the preview MUST be mirrored along the device's default horizontal axis.
  • MUST mirror the image data returned to any "postview" camera callback handlers, in the same manner as the camera preview image stream. (If the device implementation does not support postview callbacks, this requirement obviously does not apply.)
  • MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

  7.5.3. Camera API Behavior

  Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

  1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
  2. If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
  3. Device implementations SHOULD support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. Note that the Compatibility Definition for a future version is planned to change this requirement to "MUST". That is, YV12 support is optional in Android 2.3 but will be required by a future version. Existing and new devices that run Android 2.3 are very strongly encouraged to meet this requirement in Android 2.3 , or they will not be able to attain Android compatibility when upgraded to the future version.

  Device implementations MUST implement the full Camera API included in the Android 2.3 SDK documentation [ Resources, 41 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

  Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types.

  7.5.4. Camera Orientation

  Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, a cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

  7.6. Memory and Storage

  The fundamental function of Android 2.3 is to run applications. Device implementations MUST the requirements of this section, to ensure adequate storage and memory for applications to run properly.

  7.6.1. Minimum Memory and Storage

  Device implementations MUST have at least 128MB of memory available to the kernel and userspace. The 128MB MUST be in addition to any memory dedicated to hardware components such as radio, memory, and so on that is not under the kernel's control.

  Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

  Beyond the requirements above, device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that this higher requirement is planned to become a hard minimum in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

  The Android APIs include a Download Manager that applications may use to download data files. The Download Manager implementation MUST be capable of downloading individual files 55MB in size, or larger. The Download Manager implementation SHOULD be capable of downloading files 100MB in size, or larger.

  7.6.2. Application Shared Storage

  Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

  Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

  Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

  Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps.

  Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage or Media Transfer Protocol.

  It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

  Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

  7.7. USB

  Geräteimplementierungen:

  • MUST implement a USB client, connectable to a USB host with a standard USB-A port
  • MUST implement the Android Debug Bridge over USB (as described in Section 7)
  • MUST implement the USB mass storage specification, to allow a host connected to the device to access the contents of the /sdcard volume
  • SHOULD use the micro USB form factor on the device side
  • MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of connecting the custom pinout to standard USB-A port

  8. Performance Compatibility

  Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.3 compatible device defined in the table below:

  Metrisch	Leistungsschwelle	Kommentare
  Application Launch Time	The following applications should launch within the specified time. Browser: weniger als 1300 ms MMS/SMS: weniger als 700 ms Alarmclock: Weniger als 650 ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
  Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

  9. Security Model Compatibility

  Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 42 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

  9.1. Berechtigungen

  Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 42 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; Keine Berechtigungen dürfen weggelassen, geändert oder ignoriert werden. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

  9.2. UID and Process Isolation

  Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 42 ].

  9.3. Dateisystem Berechtigungen

  Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 42 ].

  9.4. Alternate Execution Environments

  Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

  Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

  Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

  Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

  Alternate runtimes MUST abide by the Android sandbox model. Speziell:

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

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

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

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

  10. Software Compatibility Testing

  The Android Open-Source Project includes various testing tools to verify that device implementations are compatible. Device implementations MUST pass all tests described in this section.

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

  10.1. Compatibility Test Suite

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

  Das CTS ist so konzipiert, dass sie auf einem tatsächlichen Gerät ausgeführt werden. Wie jede Software können die CTS selbst Fehler enthalten. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 2.3. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

  MUST pass the most recent version of the Android Compatibility Test Suite (CTS) available at the time of the device implementation's software is completed. (The CTS is available as part of the Android Open Source Project [ Resources, 2 ].) The CTS tests many, but not all, of the components outlined in this document.

  10.2. CTS-Verifizierer

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

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

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

  10.3. Reference Applications

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

  • The "Apps for Android" applications [ Resources, 43 ].
  • Replica Island (available in Android Market; only required for device implementations that support with OpenGL ES 2.0)

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

  11. Updatable Software

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

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

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

  The update mechanism used MUST support updates without wiping user data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

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

  12. Kontaktieren Sie uns

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

  Appendix A - Bluetooth Test Procedure

  The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

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

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

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

  Setup and Installation

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

  Test Bluetooth Control by Apps

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

  Test Pairing and Communication

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

  Test Pairing and Communication in the Reverse Direction

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

  Test Re-Launches

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

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