Kompatibilitätsdefinition für Android 2.3

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

Inhaltsverzeichnis

1. Einführung
2. Ressourcen
3. Software
4. Kompatibilität von App-Paketen
5. Multimediakompatibilität
6. Kompatibilität von Entwicklertools
7. Hardwarekompatibilität
7.1 Display und Grafik
7.2. Eingabegeräte
7.3. Sensoren
7.4 Datenverbindung
7.5. Kameras
7.6. Arbeitsspeicher und interner Speicher
7.7. USB
8. Leistungskompatibilität
9. Kompatibilität des Sicherheitsmodells
10. Softwarekompatibilitätstests
11. Aktualisierbare Software
12. Kontakt
Anhang A – Bluetooth-Testverfahren

1. Einführung

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

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

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

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

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

Diese Kompatibilitätsdefinition entspricht dem Update 2.3.3 für Android, also API-Level 10. Diese Definition ersetzt die Konformitätsdefinition für Android 2.3-Versionen vor 2.3.3. Die Versionen 2.3.1 und 2.3.2 sind also nicht mehr unterstützt. Kü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-Anforderungen gemäß RFC 2119: http://www.ietf.org/rfc/rfc2119.txt
  2. Android-Kompatibilitätsprogramm – Übersicht: http://source.android.com/docs/compatibility/index.html
  3. Open-Source-Projekt von Android: http://source.android.com/
  4. API-Definitionen und ‑Dokumentation: http://developer.android.com/reference/packages.html
  5. Referenz zu Android-Berechtigungen: http://developer.android.com/reference/android/Manifest.permission.html
  6. Referenz zu android.os.Build: http://developer.android.com/reference/android/os/Build.html
  7. Zulässige Versionsstrings für Android 2.3: http://source.android.com/docs/compatibility/2.3/versions.html
  8. Klasse „android.webkit.WebView“: http://developer.android.com/reference/android/webkit/WebView.html
  9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  10. Offlinefunktionen von HTML5: 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 Webdatabase API: http://www.w3.org/TR/webdatabase/
  14. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
  15. Spezifikation der Dalvik-Virtuellen Maschine: im Android-Quellcode unter dalvik/docs verfügbar
  16. App-Widgets: 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. Styleguide für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  20. Search Manager: 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. Referenzdokumentation zu Tools (für adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  24. Beschreibung von Android-APK-Dateien: 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. Camera Orientation 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 Sicherheit und Berechtigungen unter Android: 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 aus dem Android 2.3 SDK und sind funktional mit den Informationen in der Dokumentation dieses SDK identisch. In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstestsuite nicht mit der SDK-Dokumentation übereinstimmt, gilt die SDK-Dokumentation als verbindlich. Alle technischen Details in den oben genannten Referenzen gelten als Teil dieser Kompatibilitätsdefinition.

3. Software

Die Android-Plattform umfasst eine Reihe verwalteter APIs, eine Reihe nativer APIs und eine Reihe sogenannter „Soft“-APIs wie das Intent-System 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ächenbezogene 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 2.3 SDK bereitgestellt werden, einschließlich aller dokumentierten Verhaltensweisen [Ressourcen, 4].

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

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

3.2 Soft API Compatibility

Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 enthält Android eine wichtige „weiche“ API, die nur zur Laufzeit verwendet wird. Dazu gehören Intents, Berechtigungen und ähnliche Aspekte von Android-Anwendungen, die nicht zur Kompilierungszeit der Anwendung erzwungen werden können. In diesem Abschnitt werden die „Soft“-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 erzwingen, wie auf der Referenzseite für Berechtigungen [Ressourcen, 5] dokumentiert. In Abschnitt 10 sind zusätzliche Anforderungen im Zusammenhang mit dem Android-Sicherheitsmodell aufgeführt.

3.2.2. Parameter erstellen

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

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

3.2.3. Intent-Kompatibilität

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

3.2.3.1. Wichtige Anwendungsabsichten

Das Android-Upstream-Projekt definiert eine Reihe von Kernanwendungen wie einen Telefon-Wähler, 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 von Drittanbieter-Apps einhalten, um einen Titel auszuwählen.

Die folgenden Anwendungen gelten als Android-Systemanwendungen:

  • Tischuhr
  • Browser
  • Kalender
  • Rechner
  • Kontakte
  • E-Mail
  • Galerie
  • GlobalSearch
  • Werfer
  • Musik
  • Einstellungen

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

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

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

3.2.3.2. Intent-Überschreibungen

Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierer zulassen, dass jedes Intent-Muster, auf das in Abschnitt 3.2.3.1 verwiesen wird, von Drittanbieter-Apps überschrieben werden kann. Das Upstream-Android-Open-Source-Projekt erlaubt dies standardmäßig. Geräteimplementierer dürfen der Verwendung dieser Intent-Muster durch Systemanwendungen KEINE speziellen Berechtigungen zuweisen oder verhindern, dass Drittanbieteranwendungen eine Bindung an diese Muster herstellen und die Kontrolle übernehmen. Dieses Verbot umfasst insbesondere, aber nicht ausschließlich, die Deaktivierung der Benutzeroberfläche „Chooser“, ü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 einer ACTION, CATEGORY oder einem anderen Schlüsselstring im namespace „android.*“ berücksichtigen. Geräteimplementierer dürfen KEINE Android-Komponenten einbinden, die neue Intent- oder Broadcast Intent-Muster mit einer ACTION, CATEGORY oder einem anderen Schlüsselstring in einem Paketbereich einer anderen Organisation berücksichtigen. Geräteimplementierer DÜRFEN KEINE der Intent-Muster ändern oder erweitern, die von den in Abschnitt 3.2.3.1 aufgeführten Haupt-Apps verwendet werden.

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

3.2.3.4. Broadcast-Intents

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

3.3 Kompatibilität mit nativen APIs

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

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

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

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

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

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

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

3.4. Webkompatibilität

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

3.4.1. WebView-Kompatibilität

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

  • Die android.webkit.WebView-Implementierungen der Geräteimplementierungen MÜSSEN auf dem WebKit-Build 533.1 aus dem Upstream-Android Open Source-Baum für Android 2.3 basieren. Dieser Build enthält eine Reihe von Funktionen und Sicherheitskorrekturen für WebView. Geräteimplementierer KÖNNEN Anpassungen an der WebKit-Implementierung vornehmen. Diese dürfen jedoch NICHT das Verhalten der WebView ändern, einschließlich des Rendering-Verhaltens.
  • Der von WebView gemeldete User-Agent-String MUSS dieses Format haben:
    Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
    • Der Wert des Strings $(VERSION) MUSS mit dem Wert für android.os.Build.VERSION.RELEASE übereinstimmen.
    • Der Wert des Strings $(LOCALE) MUSS den ISO-Konventionen für Ländercode und Sprache entsprechen und MUSS sich auf das aktuell konfigurierte Gebietsschema des Geräts beziehen.
    • Der Wert des Strings $(MODEL) MUSS mit dem Wert für android.os.Build.MODEL übereinstimmen.
    • Der Wert des Strings $(BUILD) MUSS mit dem Wert für android.os.Build.ID übereinstimmen.

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

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

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

3.4.2. Browserkompatibilität

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

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

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

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

3.5. API-Verhaltenskompatibilität

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

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

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

3.6. API-Namespaces

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

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

Zu den unzulässigen Änderungen gehören:

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

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

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

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

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

3.7. Kompatibilität mit virtuellen Maschinen

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

Bei Geräten mit Bildschirmen mit mittlerer oder niedriger Dichte MUSS Dalvik so konfiguriert werden, dass jeder Anwendung mindestens 16 MB Arbeitsspeicher zugewiesen werden. Bei Geräten mit Bildschirmen, die als High-Density oder Extra-High-Density eingestuft sind, MUSS Dalvik so konfiguriert werden, dass jeder Anwendung mindestens 24 MB Arbeitsspeicher zugewiesen werden. Geräteimplementierungen können mehr Arbeitsspeicher zuweisen als diese Werte.

3.8. Kompatibilität der Benutzeroberfläche

Die Android-Plattform enthält einige Entwickler-APIs, mit denen Entwickler die Benutzeroberfläche des Systems nutzen können. Geräteimplementierungen MÜSSEN diese Standard-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 ein „App-Widget“ zur Verfügung stellen können [Ressourcen, 16]. Der Android Open Source-Referenzrelease 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 eine Alternative zum Referenz-Launcher (d.h. Startbildschirm) verwenden. Alternative Launcher MÜSSEN eine integrierte Unterstützung für App-Widgets bieten und Nutzeroberflächenelemente enthalten, mit denen App-Widgets direkt im Launcher hinzugefügt, konfiguriert, angezeigt und entfernt werden können. Alternative Launcher dürfen diese Elemente der Benutzeroberfläche ggf. weglassen. Wenn sie jedoch weggelassen werden, MUSS der Geräteimplementierer eine separate App bereitstellen, auf die über den Launcher zugegriffen werden kann und mit der Nutzer App-Widgets hinzufügen, konfigurieren, ansehen und entfernen können.

3.8.2. Benachrichtigungen

Android bietet APIs, mit denen Entwickler Nutzer über wichtige Ereignisse informieren können [Ressourcen, 17]. Geräteimplementierer MÜSSEN jede der so definierten Benachrichtigungsarten unterstützen, insbesondere Töne, Vibration, Licht und Statusleiste.

Außerdem MÜSSEN alle in den APIs [Ressourcen, 18] oder im Stilhandbuch für Statusleistensymbole [Ressourcen, 19] bereitgestellten Ressourcen (Symbole, Audiodateien usw.) korrekt gerendert werden. 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.

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

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

Geräteimplementierungen KÖNNEN alternative Suchoberflächen enthalten, MÜSSEN aber eine dedizierte Suchschaltfläche (Hardware- oder Softwareschaltfläche) haben, die jederzeit in jeder App verwendet werden kann, um das Such-Framework aufzurufen. Das Verhalten der Suchoberfläche ist in der API-Dokumentation beschrieben.

3.8.4. Toasts

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

3.8.5. Live-Hintergründe

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

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

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

4. Kompatibilität von Anwendungspaketen

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

Geräteimplementierungen dürfen die Formate .apk [Ressourcen, 24], Android-Manifest [Ressourcen, 25] oder Dalvik-Bytecode [Ressourcen, 15] 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.

5. Multimedia-Kompatibilität

Bei Geräteimplementierungen MÜSSEN alle Multimedia-APIs vollständig implementiert sein. Geräteimplementierungen MÜSSEN alle unten beschriebenen Multimedia-Codecs unterstützen und SOLLTEN die unten beschriebenen Richtlinien für die Audioverarbeitung erfüllen. Geräteimplementierungen MÜSSEN mindestens eine Form von Audioausgang haben, z. B. Lautsprecher, Kopfhöreranschluss oder Anschluss für externe Lautsprecher.

5.1. Medien-Codecs

Geräteimplementierungen MÜSSEN die Multimedia-Codecs unterstützen, die in den folgenden Abschnitten beschrieben werden. Alle diese Codecs werden als Softwareimplementierungen in der bevorzugten Android-Implementierung des Android Open Source Project bereitgestellt.

Weder Google noch die Open Handset Alliance geben eine Zusicherung dafür, dass diese Codecs frei von Patenten Dritter 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, Patentlizenzen der jeweiligen Patentinhaber erforderlich sein können.

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

5.1.1. Mediendecoder

Geräteimplementierungen MÜSSEN einen Decoder für jeden in der folgenden Tabelle beschriebenen Codec und jedes Format enthalten. Decoder für jeden dieser Medientypen werden vom Upstream-Android-Open-Source-Projekt bereitgestellt.

Audio
Name Details Datei-/Containerformat
AAC LC/LTP Mono-/Stereoinhalte in beliebiger Kombination aus Standardbitraten von bis zu 160 kbit/s und Abtastraten von 8 bis 48 kHz 3GPP (.3gp) und MPEG-4 (.mp4, .m4a) Keine Unterstützung für Raw AAC (.aac)
HE-AACv1 (AAC+)
HE-AACv2 (erweitertes AAC+)
AMR-NB 4,75 bis 12,2 kbit/s bei 8 kHz abgetastet 3GPP (.3gp)
AMR-WB 9 Raten von 6,60 kbit/s bis 23,85 kbit/s bei 16 kHz Abtastrate 3GPP (.3gp)
MP3 Mono/Stereo 8–320 kbit/s konstant (CBR) oder variable Bitrate (VBR) MP3 (.mp3)
MIDI MIDI-Typ 0 und 1 DLS-Version 1 und 2 XMF und Mobile XMF. Unterstützung für Klingeltonformate RTTTL/RTX, OTA und iMelody Typ 0 und 1 (.mid, .xmf, .mxmf) Auch RTTTL/RTX (.rtttl, .rtx), OTA (.ota) und iMelody (.imy)
Ogg Vorbis   Ogg (.ogg)
PCM Lineare PCM mit 8 und 16 Bit (Raten bis zur Grenze der Hardware) WAVE (.wav)
Bild
JPEG base+progressive  
GIF    
PNG    
BMP    
Video
H.263   3GPP-Dateien (.3gp)
H.264   3GPP- (.3gp) und MPEG-4-Dateien (.mp4)
MPEG4 Simple Profile   3GPP-Datei (.3gp)

5.1.2. Medien-Encoder

Geräteimplementierungen MÜSSEN Encoder für so viele der in Abschnitt 5.1.1 aufgeführten Medienformate wie möglich enthalten. Einige Encoder sind jedoch für Geräte ohne bestimmte optionale Hardware nicht sinnvoll. Ein Encoder für H.263-Videos ist beispielsweise nicht sinnvoll, wenn das Gerät keine Kameras hat. Daher MÜSSEN Geräteimplementierungen Medienencoder gemäß den in der folgenden Tabelle beschriebenen Bedingungen implementieren.

In Abschnitt 7 finden Sie Details zu den Bedingungen, unter denen Hardware bei der Geräteimplementierung möglicherweise weggelassen wird.

Audio
Name Details Datei-/Containerformat Bedingungen
AMR-NB 4,75 bis 12,2 kbit/s bei 8 kHz abgetastet 3GPP (.3gp) Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone definieren, MÜSSEN Encoder für diese Audioformate enthalten.
AMR-WB 9 Raten von 6,60 kbit/s bis 23,85 kbit/s bei 16 kHz Abtastrate 3GPP (.3gp)
AAC LC/LTP Mono-/Stereoinhalte in beliebiger Kombination aus Standardbitraten von bis zu 160 kbit/s und Abtastraten von 8 bis 48 kHz 3GPP (.3gp) und MPEG-4 (.mp4, .m4a)
Bild JPEG base+progressive   Alle Geräteimplementierungen MÜSSEN Encoder für diese Bildformate enthalten, da Android 2.3 APIs enthält, mit denen Anwendungen Dateien dieser Typen programmatisch generieren können.
PNG    
Video H.263   3GPP-Dateien (.3gp) Geräteimplementierungen, die Kamerahardware enthalten und entweder android.hardware.camera oder android.hardware.camera.front definieren, MÜSSEN Encoder für diese Videoformate enthalten.

Zusätzlich zu den oben aufgeführten Encodern MÜSSEN Geräteimplementierungen einen H.264-Encoder enthalten. In der Kompatibilitätsdefinition für eine zukünftige Version wird diese Anforderung voraussichtlich in „MUSS“ geändert. Die H.264-Codierung ist in Android 2.3 optional, wird aber in einer zukünftigen Version erforderlich sein. Wir empfehlen Ihnen dringend, diese Anforderung unter Android 2.3 zu erfüllen, da bestehende und neue Geräte mit Android 2.3 andernfalls nicht mit Android kompatibel sind, wenn Sie auf die zukünftige Version umstellen.

5.2. Audioaufnahmen

Wenn eine Anwendung die android.media.AudioRecord API verwendet hat, um die Aufzeichnung eines Audiostreams zu starten, MÜSSEN Geräteimplementierungen Audio mit den folgenden Verhaltensweisen erfassen:

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

Hinweis:Die oben beschriebenen Anforderungen sind für Android 2.3 als „SOLLTE“ angegeben. In der Kompatibilitätsdefinition für eine zukünftige Version werden sie jedoch in „MUSS“ geändert. Das heißt, diese Anforderungen sind in Android 2.3 optional, werden aber in einer zukünftigen Version erforderlich sein. Wir empfehlen Ihnen dringend, diese Anforderungen unter Android 2.3 auf bestehenden und neuen Geräten zu erfüllen, da diese sonst nicht mit Android kompatibel sind, wenn Sie auf die zukünftige Version umstellen.

5.3. Audiolatenz

Die Audiolatenz wird allgemein als Intervall zwischen dem Zeitpunkt definiert, zu dem eine Anwendung eine Audiowiedergabe oder einen Aufnahmevorgang anfordert, und dem Zeitpunkt, zu dem die Geräteimplementierung den Vorgang tatsächlich beginnt. Viele Anwendungsklassen erfordern kurze Latenzen, um Echtzeiteffekte wie Toneffekte oder VOIP-Kommunikation zu erzielen. Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone angeben, MÜSSEN alle in diesem Abschnitt beschriebenen Anforderungen an die Audiolatenz erfüllen. In Abschnitt 7 finden Sie Details zu den Bedingungen, unter denen Mikrofonhardware bei der Geräteimplementierung weggelassen werden kann.

Für die Zwecke dieses Abschnitts gilt:

  • Die „Latenz der kalten Ausgabe“ ist das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung die Audiowiedergabe anfordert, und dem Zeitpunkt, zu dem der Ton wiedergegeben wird, wenn das Audiosystem vor der Anfrage inaktiv und ausgeschaltet war.
  • Die „Warm-Output-Latenz“ ist das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung die Audiowiedergabe anfordert, und dem Zeitpunkt, zu dem der Ton wiedergegeben wird, wenn das Audiosystem vor Kurzem verwendet wurde, aber derzeit inaktiv ist (d. h. stummgeschaltet).
  • Die „kontinuierliche Ausgabelatenz“ ist das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung ein Sample zur Wiedergabe ausgibt, und dem Zeitpunkt, zu dem der Lautsprecher den entsprechenden Ton physisch wiedergibt, während auf dem Gerät gerade Audio wiedergegeben wird.
  • Die „Latenz bei kalter Eingabe“ ist das Intervall zwischen dem Zeitpunkt, zu dem eine Anwendung die Audioaufnahme anfordert, und dem Zeitpunkt, zu dem das erste Sample über den Callback an die Anwendung gesendet wird, wenn das Audiosystem und das Mikrofon vor der Anfrage inaktiv und ausgeschaltet waren.
  • „Continuous Input Latency“ (kontinuierliche Eingabelatenz) ist definiert als ein Umgebungsgeräusch, bei dem das dem Geräusch entsprechende Sample über den Rückruf an eine Aufnahmeanwendung gesendet wird, während sich das Gerät im Aufnahmemodus befindet.

Gemäß den oben genannten Definitionen sollten Geräteimplementierungen die folgenden Eigenschaften aufweisen:

  • Kaltstartlatenz von 100 Millisekunden oder weniger
  • Ausgabelatenz nach Warmstart von 10 Millisekunden oder weniger
  • eine kontinuierliche Ausgabelatenz von 45 Millisekunden oder weniger
  • Eingabelatenz nach dem Kaltstart von 100 Millisekunden oder weniger
  • eine kontinuierliche Eingabelatenz von 50 Millisekunden oder weniger

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

Wenn eine Geräteimplementierung die Anforderungen dieses Abschnitts erfüllt, kann sie die Unterstützung für Audio mit niedriger Latenz melden, indem sie die Funktion „android.hardware.audio.low-latency“ über die Klasse android.content.pm.PackageManager meldet. [Ressourcen, 27] Wenn die Geräteimplementierung diese Anforderungen nicht erfüllt, darf KEINE Unterstützung für Audio mit niedriger Latenz gemeldet werden.

6. Kompatibilität von Entwicklertools

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

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

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

7. Hardwarekompatibilität

Android soll Geräteimplementierern ermöglichen, innovative Formfaktoren und Konfigurationen zu erstellen. Gleichzeitig entwickeln Android-Entwickler innovative Anwendungen, die auf der verschiedenen Hardware und den Funktionen basieren, die über die Android APIs verfügbar sind. Die Anforderungen in diesem Abschnitt stellen eine Balance zwischen den Innovationen dar, die Geräteimplementierern zur Verfügung stehen, und den Anforderungen von Entwicklern, ihre Apps nur auf Geräten verfügbar zu machen, auf denen sie ordnungsgemäß funktionieren.

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

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

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

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

7.1. Display und Grafik

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

7.1.1. Bildschirmkonfigurationen

Bei Geräteimplementierungen KÖNNEN Bildschirme mit beliebigen Pixelabmessungen verwendet werden, sofern sie die folgenden Anforderungen erfüllen:

  • Bildschirme MÜSSEN eine Diagonale von mindestens 6,4 cm haben.
  • Die Dichte MUSS mindestens 100 dpi betragen.
  • Das Seitenverhältnis muss zwischen 1,333 (4:3) und 1,779 (16:9) liegen.
  • die verwendete Displaytechnologie quadratische Pixel hat

Geräteimplementierungen mit einem Display, das die oben genannten Anforderungen erfüllt, gelten als kompatibel und es sind keine weiteren Maßnahmen erforderlich. Die Android-Framework-Implementierung berechnet automatisch Displaymerkmale wie den Bucket für die Bildschirmgröße und den Bucket für die Dichte. In den meisten Fällen sind die Entscheidungen im Rahmen des Frameworks richtig. Wenn die Standard-Framework-Berechnungen verwendet werden, sind keine weiteren Maßnahmen erforderlich. Geräteimplementierer, die die Standardeinstellungen ändern oder einen Bildschirm verwenden möchten, der nicht den oben genannten Anforderungen entspricht, MÜSSEN sich gemäß Abschnitt 12 an das Android-Kompatibilitätsteam wenden.

Die in den oben genannten Anforderungen verwendeten Einheiten sind so definiert:

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

Bei Geräteimplementierungen dürfen nur Displays mit einer einzelnen statischen Konfiguration verwendet werden. Das heißt, bei Geräteimplementierungen dürfen KEINE Konfigurationen für mehrere Bildschirme aktiviert sein. Da ein typischer Fernseher beispielsweise mehrere Auflösungen wie 1080p, 720p usw. unterstützt, ist diese Konfiguration nicht mit Android 2.3 kompatibel. Die Unterstützung solcher Konfigurationen wird jedoch geprüft und für eine zukünftige Version von Android geplant.

7.1.2. Messwerte für Displaykampagnen

Geräteimplementierungen MÜSSEN korrekte Werte für alle in android.util.DisplayMetrics [Ressourcen, 29] definierten Anzeigemesswerte melden.

7.1.3. Deklarierte Bildschirmunterstützung

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

7.1.4. Displayausrichtung

Kompatible Geräte MÜSSEN die dynamische Ausrichtung durch Anwendungen für das Hoch- oder Querformat unterstützen. Das Gerät muss also die Anfrage der Anwendung für eine bestimmte Bildschirmausrichtung respektieren. Bei Geräteimplementierungen kann das Hoch- oder Querformat als Standard ausgewählt werden. Bei Geräten, die sich nicht physisch drehen lassen, kann diese Anforderung durch „Letterboxing“-Anwendungen erfüllt werden, die den Hochformatmodus anfordern und nur einen Teil des verfügbaren Displays verwenden.

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

7.1.5. 3D-Grafikbeschleunigung

Geräteimplementierungen MÜSSEN OpenGL ES 1.0 unterstützen, wie von den Android 2.3 APIs gefordert. Für Geräte ohne 3D-Beschleunigungshardware wird vom Upstream-Android-Open-Source-Projekt eine Softwareimplementierung von OpenGL ES 1.0 bereitgestellt. Geräteimplementierungen MÜSSEN OpenGL ES 2.0 unterstützen.

Die Unterstützung von OpenGL ES 2.0 kann bei Implementierungen weggelassen werden. Wenn die Unterstützung jedoch weggelassen wird, dürfen die Geräteimplementierungen nicht als OpenGL ES 2.0-kompatibel gemeldet werden. Insbesondere, wenn die OpenGL ES 2.0-Unterstützung bei Geräteimplementierungen fehlt:

  • Die verwalteten APIs (z. B. über die GLES10.getString()-Methode) dürfen KEINE Unterstützung für OpenGL ES 2.0 melden.
  • Die nativen C/C++-OpenGL-APIs (d. h. die für Apps über libGLES_v1CM.so, libGLES_v2.so oder libEGL.so verfügbar sind) DÜRFEN KEINE Unterstützung für OpenGL ES 2.0 melden.

Wenn eine Geräteimplementierung OpenGL ES 2.0 unterstützt, muss diese Unterstützung über die oben aufgeführten Routen korrekt gemeldet werden.

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

7.2. Eingabegeräte

Android 2.3 unterstützt eine Reihe von Modalitäten für die Nutzereingabe. Geräteimplementierungen MÜSSEN Eingabegeräte für Nutzer wie in diesem Abschnitt beschrieben unterstützen.

7.2.1. Tastatur

Geräteimplementierungen:

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

7.2.2. Bedienung ohne Touchscreen

Geräteimplementierungen:

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

7.2.3. Navigationstasten

Die Funktionen „Startseite“, „Menü“ und „Zurück“ sind für die Android-Navigation unerlässlich. Geräteimplementierungen MÜSSEN diese Funktionen dem Nutzer jederzeit zur Verfügung stellen, unabhängig vom Anwendungsstatus. Diese Funktionen MÜSSEN über spezielle Schaltflächen implementiert werden. Sie KÖNNEN mit 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 Sende- und Beendigungstasten für Telefonanrufe bereitstellen.

7.2.4. Touchscreen-Eingabe

Geräteimplementierungen:

  • MUSS einen Touchscreen haben
  • KANN einen kapazitiven oder resistiven Touchscreen haben
  • Der Wert von android.content.res.Configuration [Ressourcen, 30] MUSS dem Typ des Touchscreens auf dem Gerät entsprechen.
  • Sollte unabhängig voneinander erfasste Touchstifte unterstützen, wenn der Touchscreen mehrere Touchstifte unterstützt

7.3. Sensoren

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

  • MÜSSEN das Vorhandensein oder Fehlen von Sensoren gemäß der android.content.pm.PackageManager-Klasse korrekt melden. [Ressourcen, 27]
  • MUSS über SensorManager.getSensorList() und ähnliche Methoden eine genaue Liste der unterstützten Sensoren zurückgeben
  • MÜSSEN sich für alle anderen Sensor-APIs angemessen verhalten (z. B. durch Rückgabe von „wahr“ oder „falsch“, wenn Anwendungen versuchen, Listener zu registrieren, oder durch Nichtaufrufen von Sensor-Listenern, wenn die entsprechenden Sensoren nicht vorhanden sind).

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

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

Die Android 2.3 APIs führen den Begriff „Streaming-Sensor“ ein. Dieser Sensor gibt Daten kontinuierlich zurück, nicht nur, wenn sich die Daten ändern. Geräteimplementierungen MÜSSEN kontinuierlich zyklische Datenproben für jede API bereitstellen, die in der Android 2.3 SDK-Dokumentation als Streamingsensor angegeben ist.

7.3.1. Beschleunigungsmesser

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

  • MÜSSEN Ereignisse mit mindestens 50 Hz senden können
  • MÜSSEN dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben (siehe [Ressourcen, 31])
  • MÜSSEN im freien Fall bis zu doppelter Erdbeschleunigung (2 g) oder mehr in jedem dreidimensionalen Vektor messen können
  • MÜSSEN eine Genauigkeit von mindestens 8 Bit haben
  • Die Standardabweichung darf maximal 0,05 m/s² betragen.

7.3.2. Magnetometer

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

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

7.3.3. GPS

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

7.3.4. Gyroskop

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

  • MÜSSEN in der Lage sein, Ausrichtungsänderungen von bis zu 5,5 Pi Rad/Sekunde (d. h. etwa 1.000 Grad pro Sekunde) zu messen.
  • MÜSSEN Ereignisse mit mindestens 100 Hz senden können
  • MÜSSEN eine Genauigkeit von mindestens 8 Bit haben

7.3.5. Barometer

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

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

7.3.7. Thermometer

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

7.3.7. Fotometer

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

7.3.8. Näherungssensor

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

7.4. Datenverbindung

Netzwerkverbindung und Internetzugriff sind wichtige Funktionen von Android. Die Geräte-zu-Geräte-Interaktion bietet Android-Geräten und ‑Anwendungen einen erheblichen Mehrwert. Geräteimplementierungen MÜSSEN die Anforderungen an die Datenverbindung in diesem Abschnitt erfüllen.

7.4.1. Telefonie

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

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

7.4.2. IEEE 802.11 (Wi‑Fi)

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

7.4.3. Bluetooth

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

Die Kompatibilitätstestsuite umfasst Fälle, die den grundlegenden Betrieb der Android RFCOMM Bluetooth API abdecken. Da Bluetooth jedoch ein Kommunikationsprotokoll zwischen Geräten ist, kann es nicht vollständig durch Unit-Tests auf einem einzelnen Gerät getestet werden. Daher MÜSSEN Geräteimplementierungen auch den in Anhang A beschriebenen manuellen Bluetooth-Test bestehen.

7.4.4. Nahfeldkommunikation

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

  • Die Funktion „android.hardware.nfc“ MUSS über die Methode android.content.pm.PackageManager.hasSystemFeature() gemeldet werden. [Ressourcen, 27]
  • MÜSSEN NDEF-Nachrichten über die folgenden NFC-Standards lesen und schreiben können:
    • MÜSSEN als NFC-Forum-Lese-/Schreibgerät (wie in der technischen Spezifikation des NFC-Forums NFCForum-TS-DigitalProtocol-1.0 definiert) über die folgenden NFC-Standards funktionieren:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS 6319-4)
      • NfcV (ISO 15693)
      • IsoDep (ISO 14443-4)
      • NFC-Forum-Tag-Typen 1, 2, 3 und 4 (vom NFC-Forum definiert)
    • MÜSSEN Daten über die folgenden Peer-to-Peer-Standards und ‑Protokolle senden und empfangen können:
      • ISO 18092
      • LLCP 1.0 (vom NFC-Forum definiert)
      • SDP 1.0 (vom NFC Forum definiert)
      • NDEF Push Protocol [Resources, 33]
    • MUSS im NFC-Erkennungsmodus nach allen unterstützten Technologien suchen.
    • SOLLTE sich im NFC-Erkennungsmodus befinden, während das Gerät aktiv ist und das Display eingeschaltet ist.

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

    Außerdem sollten Geräteimplementierungen die folgenden weit verbreiteten MIFARE-Technologien unterstützen.

    Android 2.3.3 enthält APIs für diese MIFARE-Typen. Wenn eine Geräteimplementierung MIFARE unterstützt, gilt Folgendes:

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

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

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

    7.4.5. Mindestnetzwerkanforderungen

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

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

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

    7.5. Kameras

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

    7.5.1. Rückkamera

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

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

    7.5.2. Frontkamera

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

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

    7.5.3. Verhalten der Camera API

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

    1. Wenn eine Anwendung noch nie android.hardware.Camera.Parameters.setPreviewFormat(int) aufgerufen hat, MUSS das Gerät android.hardware.PixelFormat.YCbCr_420_SP für Vorschaudaten verwenden, die an Anwendungs-Callbacks übergeben werden.
    2. Wenn eine Anwendung eine Instanz von android.hardware.Camera.PreviewCallback registriert und das System die Methode onPreviewFrame() aufruft, wenn das Vorschauformat YCbCr_420_SP ist, müssen die Daten in den Byte-Arrays, die an onPreviewFrame() übergeben werden, außerdem im NV21-Codierungsformat vorliegen. Das heißt, NV21 MUSS der Standard sein.
    3. Geräteimplementierungen MÜSSEN das YV12-Format (wie durch die Konstante android.graphics.ImageFormat.YV12 angegeben) für Kameravorschauen sowohl für Front- als auch für Rückkameras unterstützen. Hinweis: In der Kompatibilitätsdefinition für eine zukünftige Version wird diese Anforderung voraussichtlich in „MUSS“ geändert. Die YV12-Unterstützung ist in Android 2.3 optional, wird aber in einer zukünftigen Version erforderlich sein. Wir empfehlen Ihnen dringend, diese Anforderung in Android 2.3 zu erfüllen, da Geräte mit Android 2.3 andernfalls nicht mit der zukünftigen Version kompatibel sind.

    Geräteimplementierungen MÜSSEN die vollständige Camera API implementieren, die in der Android 2.3 SDK-Dokumentation [Ressourcen, 41] enthalten ist, unabhängig davon, ob das Gerät einen Hardware-Autofokus oder andere Funktionen hat. Kameras ohne Autofokus MÜSSEN beispielsweise alle registrierten android.hardware.Camera.AutoFocusCallback-Instanzen aufrufen, auch wenn dies für eine Kamera ohne Autofokus keine Relevanz hat. Dies gilt auch für Frontkameras. Auch wenn die meisten Frontkameras keinen Autofokus unterstützen, müssen die API-Callbacks wie beschrieben „gefaket“ werden.

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

    7.5.4. Kameraausrichtung

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

    7.6. Arbeitsspeicher und Datenspeicher

    Die Hauptfunktion von Android 2.3 besteht darin, Anwendungen auszuführen. Geräteimplementierungen MÜSSEN die Anforderungen dieses Abschnitts erfüllen, um ausreichenden Speicher und Arbeitsspeicher für die ordnungsgemäße Ausführung von Anwendungen zu gewährleisten.

    7.6.1. Mindestarbeitsspeicher und Mindestspeicherplatz

    Für Geräteimplementierungen muss mindestens 128 MB Arbeitsspeicher für den Kernel und den Userspace verfügbar sein. Die 128 MB MÜSSEN zusätzlich zu dem Arbeitsspeicher für Hardwarekomponenten wie Funkschnittstelle, Speicher usw. sein, die nicht vom Kernel verwaltet werden.

    Für Geräteimplementierungen muss mindestens 150 MB nichtflüchtiger Speicherplatz für Nutzerdaten verfügbar sein. Die /data-Partition muss also mindestens 150 MB groß sein.

    Zusätzlich zu den oben genannten Anforderungen sollten Geräteimplementierungen mindestens 1 GB nichtflüchtigen Speicher für Nutzerdaten haben. Diese höhere Anforderung wird in einer zukünftigen Version von Android voraussichtlich als Mindestanforderung festgelegt. Bei Geräteimplementierungen wird dringend empfohlen, diese Anforderungen jetzt zu erfüllen, da sie sonst möglicherweise nicht mit einer zukünftigen Android-Version kompatibel sind.

    Die Android APIs enthalten einen Downloadmanager, mit dem Anwendungen Datendateien herunterladen können. Die Download-Manager-Implementierung MUSS in der Lage sein, einzelne Dateien mit einer Größe von mindestens 55 MB herunterzuladen. Die Download-Manager-Implementierung sollte in der Lage sein, Dateien mit einer Größe von mindestens 100 MB herunterzuladen.

    7.6.2. Gemeinsam genutzter Speicherplatz für Anwendungen

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

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

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

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

    Unabhängig von der verwendeten Form des freigegebenen Speichers MÜSSEN Geräteimplementierungen einen Mechanismus zum Zugriff auf den Inhalt des freigegebenen Speichers von einem Hostcomputer aus bereitstellen, z. B. USB-Massenspeicher oder Media Transfer Protocol.

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

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

    7.7. USB

    Geräteimplementierungen:

    • MUSS einen USB-Client implementieren, der mit einem USB-Host mit einem Standard-USB-A-Anschluss verbunden werden kann
    • MÜSSEN die Android Debug Bridge über USB implementieren (wie in Abschnitt 7 beschrieben)
    • MUSS die USB-Massenspeicherspezifikation implementieren, damit ein mit dem Gerät verbundener Host auf den Inhalt des Volumes „/sdcard“ zugreifen kann
    • SOLLTE den Micro-USB-Formfaktor auf der Geräteseite verwenden
    • Es kann einen nicht standardmäßigen Anschluss auf der Geräteseite haben. In diesem Fall MUSS jedoch ein Kabel mitgeliefert werden, mit dem die benutzerdefinierte Belegung mit dem Standard-USB-A-Anschluss verbunden werden kann.

    8. Leistungskompatibilität

    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 2.3 kompatiblen Geräts erfüllen, die in der folgenden Tabelle definiert sind:

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

    9. Kompatibilität des Sicherheitsmodells

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

    9.1. Berechtigungen

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

    9.2. UID und Prozessisolierung

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

    9.3. Dateisystemberechtigungen

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

    9.4. Alternative Ausführungsumgebungen

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

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

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

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

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

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

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

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

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

    10. Softwarekompatibilitätstests

    Das Android Open Source Project enthält verschiedene Testtools, mit denen die Kompatibilität von Geräteimplementierungen überprüft werden kann. Geräteimplementierungen MÜSSEN alle in diesem Abschnitt beschriebenen Tests bestehen.

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

    10.1. Compatibility Test Suite

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

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

    MÜSSEN die neueste Version der Android Compatibility Test Suite (CTS) bestehen, die zum Zeitpunkt der Implementierung der Gerätesoftware verfügbar ist. Der CTS ist Teil des Open-Source-Projekts von Android [Ressourcen, 2]. Der CTS prüft viele, aber nicht alle in diesem Dokument beschriebenen Komponenten.

    10.2. CTS-Verifier

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

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

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

    10.3. Referenzanwendungen

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

    • Die Apps „Apps for Android“ [Ressourcen, 43].
    • Replica Island (im Android Market verfügbar; nur für Geräteimplementierungen erforderlich, die OpenGL ES 2.0 unterstützen)

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

    11. Aktualisierbare Software

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

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

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

    Der verwendete Updatemechanismus MUSS Updates ohne Löschen von Nutzerdaten unterstützen. Die Upstream-Android-Software enthält einen Updatemechanismus, der diese Anforderung erfüllt.

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

    12. Kontakt

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

    Anhang A – Bluetooth-Testverfahren

    Die Kompatibilitätstestsuite umfasst Fälle, die den grundlegenden Betrieb der Android RFCOMM Bluetooth API abdecken. Da Bluetooth jedoch ein Kommunikationsprotokoll zwischen Geräten ist, kann es nicht vollständig durch Unit-Tests auf einem einzelnen Gerät getestet werden. Daher MÜSSEN Geräteimplementierungen auch den unten beschriebenen manuellen Bluetooth-Test bestehen.

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

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

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

    Einrichtung und Montage

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

    Bluetooth-Steuerung durch Apps testen

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

    Kopplung und Kommunikation testen

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

    Kopplung und Kommunikation in umgekehrter Richtung testen

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

    Testwiederholungen

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

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