Kompatibilitätsdefinition für Android 2.1

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

1. Einführung

In diesem Dokument werden die Anforderungen aufgeführt, die erfüllt werden müssen, damit Smartphones mit Android 2.1 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.1 entwickelt. Eine „Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte Hardware-/Softwarelösung.

Damit Geräteimplementierungen als mit Android 2.1 kompatibel gelten, müssen folgende Anforderungen erfüllt sein:

  • MÜSSEN die in dieser Kompatibilitätsdefinition dargelegten Anforderungen erfüllen, einschließlich aller Dokumente, die durch Verweis einbezogen werden.
  • 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.

Wenn diese Definition oder das CTS keine Angaben enthält, mehrdeutig oder unvollständig ist, 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äteimplementierern wird dringend empfohlen, ihre Implementierungen auf dem „Upstream“-Quellcode zu basieren, der im Android Open Source Project verfügbar ist. Einige Komponenten können zwar theoretisch durch alternative Implementierungen ersetzt werden, wir raten jedoch dringend davon ab, da das Bestehen der CTS-Tests dadurch erheblich erschwert wird. Der Implementierer ist dafür verantwortlich, dass die Verhaltenskompatibilität mit der Standard-Android-Implementierung vollständig gegeben ist, einschließlich und über die Compatibility Test Suite hinaus. Bestimmte Komponentenersetzungen und ‑änderungen sind gemäß diesem Dokument ausdrücklich untersagt.

2. Ressourcen

  1. Anforderungen gemäß IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  2. Android Compatibility Program Overview: http://source.android.com/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 für android.os.Build: http://developer.android.com/reference/android/os/Build.html
  7. Zulässige Versionsstrings für Android 2.1: http://source.android.com/docs/compatibility/2.1/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. Spezifikation der Dalvik-Virtuellen Maschine: im Android-Quellcode unter dalvik/docs verfügbar
  11. App-Widgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. Benachrichtigungen: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. Anwendungsressourcen: http://code.google.com/android/reference/available-resources.html
  14. Styleguide für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
  16. Toasts: http://developer.android.com/reference/android/widget/Toast.html
  17. Live-Hintergründe: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. Apps für Android: http://code.google.com/p/apps-for-android
  19. Referenzdokumentation für Tools (für adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  20. Beschreibung der Android-APK-Datei: http://developer.android.com/guide/topics/fundamentals.html
  21. Manifestdateien: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. Monkey-Testtool: https://developer.android.com/studio/test/other-testing-tools/monkey
  23. Unterstützung mehrerer Bildschirme: http://developer.android.com/guide/practices/screens_support.html
  24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  25. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  26. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  27. Sensorkoordinatenraum: http://developer.android.com/reference/android/hardware/SensorEvent.html
  28. Referenz zu Sicherheit und Berechtigungen unter Android: http://developer.android.com/guide/topics/security/security.html
  29. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

Viele dieser Ressourcen stammen direkt oder indirekt aus dem Android 2.1 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.1 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.

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.1 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. Für Android 2.1 MUSS dieses Feld den Ganzzahlwert 7 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 an Endnutzer gesendet 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. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
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. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
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. Es gibt keine Anforderungen an das Format dieses Felds, es darf nur nicht null oder der leere String ("") sein.
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)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Beispiel:
acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys
Der Fingerabdruck darf KEINE Leerzeichen enthalten. Wenn andere Felder in der Vorlage oben Leerzeichen enthalten, MÜSSEN sie im Fingerabdruck durch das ASCII-Unterstrichzeichen („_“) ersetzt werden.
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. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch nicht null oder der leere String ("") sein.
android.os.Build.MODEL Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endnutzer bekannt ist. Dies sollte derselbe Name sein, unter dem das Gerät vermarktet und an Endnutzer verkauft wird. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
android.os.Build.PRODUCT Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des Geräts enthält. MÜSSEN menschenlesbar sein, sind aber nicht unbedingt für Endnutzer bestimmt. Es gibt keine Anforderungen an das Format dieses Felds, es darf jedoch NICHT null oder der leere String ("") sein.
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“. Dieses Feld darf NICHT den Wert „null“ oder den leeren String ("") haben. Ein einzelnes Tag wie „release“ ist jedoch zulässig.
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“.
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
  • Kamera
  • Kontakte
  • E-Mail
  • Galerie
  • GlobalSearch
  • Werfer
  • LivePicker (d. h. die App zur Auswahl von Live-Hintergründen; kann gemäß Abschnitt 3.8.5 weggelassen werden, wenn das Gerät keine Live-Hintergründe unterstützt)
  • Messaging (auch „MMS“)
  • Musik
  • Telefon
  • Einstellungen
  • SoundRecorder

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 in den Hauptsystem-Apps definierte Intent-Muster 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.

Hinweis: Dieser Abschnitt wurde durch das Korrekturhinweis-EX6580 geändert.

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. Geräteimplementierungen MÜSSEN Code unterstützen, der in der verwalteten Umgebung ausgeführt wird, um nativen Code mithilfe der Standard-Java Native Interface (JNI)-Semantik aufzurufen. Die folgenden APIs MÜSSEN für nativen Code verfügbar sein:

  • libc (C-Bibliothek)
  • libm (Mathematische Bibliothek)
  • JNI-Schnittstelle
  • libz (Zlib-Komprimierung)
  • liblog (Android-Protokollierung)
  • Minimale Unterstützung für C++
  • Unterstützung für OpenGL, wie unten beschrieben

Geräteimplementierungen MÜSSEN OpenGL ES 1.0 unterstützen. Geräte ohne Hardwarebeschleunigung MÜSSEN OpenGL ES 1.0 mit einem Software-Renderer implementieren. Geräteimplementierungen MÜSSEN so viel von OpenGL ES 1.1 implementieren, wie die Gerätehardware unterstützt. Geräteimplementierungen MÜSSEN eine Implementierung für OpenGL ES 2.0 bereitstellen, wenn die Hardware eine angemessene Leistung bei diesen APIs erzielen kann.

Diese Bibliotheken MÜSSEN mit den Versionen in Bionic, die vom Android Open Source Project bereitgestellt werden, quellen- (d.h. Header-) und binärkompatibel (für eine bestimmte Prozessorarchitektur) sein. Da die Bionic-Implementierungen nicht vollständig mit anderen Implementierungen wie der GNU C-Bibliothek kompatibel sind, sollten Geräteimplementierer die Android-Implementierung verwenden. Wenn Geräteimplementierer eine andere Implementierung dieser Bibliotheken verwenden, MÜSSEN sie für Header-, Binär- und Verhaltenskompatibilität sorgen.

Geräteimplementierungen MÜSSEN das vom Gerät unterstützte native Application Binary Interface (ABI) über die android.os.Build.CPU_ABI API korrekt melden. Das ABI MUSS einer der Einträge in der Datei docs/CPU-ARCH-ABIS.txt sein, die in der neuesten Version des Android NDK dokumentiert ist. Beachten Sie, dass in zukünftigen Releases des Android NDK möglicherweise Unterstützung für weitere ABIs hinzugefügt wird.

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. Web API-Kompatibilitä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. Die Android Open Source-Implementierung verwendet die WebKit-Rendering-Engine, um die WebView zu implementieren.

Da es nicht möglich ist, eine umfassende Testsuite für einen Webbrowser zu entwickeln, MÜSSEN Geräteimplementierer den spezifischen Upstream-Build von WebKit in der WebView-Implementierung verwenden. Im Detail:

  • WebView MUSS den WebKit-Build 530.17 aus dem Upstream-Android Open Source-Baum für Android 2.1 verwenden. Dieser Build enthält eine Reihe von Funktionen und Sicherheitskorrekturen für die WebView.
  • Der von WebView gemeldete User-Agent-String MUSS dieses Format haben:
    Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
    • 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.

Implementierungen KÖNNEN einen benutzerdefinierten User-Agent-String in der eigenständigen Browseranwendung enthalten. Außerdem kann der eigenständige Browser auf einer alternativen Browsertechnologie basieren (z. B. Firefox oder Opera). Auch wenn eine alternative Browseranwendung bereitgestellt wird, muss die WebView-Komponente, die für Drittanbieteranwendungen bereitgestellt wird, wie oben beschrieben auf WebKit basieren.

Die WebView-Konfiguration MUSS die Unterstützung der HTML5-Datenbank, des Anwendungscaches und der APIs für die Standortermittlung umfassen [Ressourcen, 9]. Die WebView MUSS in irgendeiner Form das HTML5-<video>-Tag unterstützen. Die eigenständige Browseranwendung (unabhängig davon, ob sie auf der Upstream-WebKit-Browseranwendung oder einem Ersatz von Drittanbietern basiert) MUSS dieselben HTML5-Funktionen unterstützen, die oben für WebView aufgeführt wurden.

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 Bedeutung einer Standardabsicht NICHT ändern.
  • Geräte dürfen den Lebenszyklus oder die Lebenszyklussemantik einer bestimmten Art von Systemkomponente (z. B. Dienst, Aktivität, Content-Provider usw.) NICHT ändern.
  • Geräte dürfen die Semantik einer bestimmten Berechtigung NICHT ändern.

Die oben genannte Liste ist nicht vollständig. Die Geräteimplementierer sind dafür verantwortlich, die Verhaltenskompatibilität sicherzustellen. Aus diesem Grund sollten Geräteimplementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt wichtige Teile des Systems neu zu implementieren.

Die Compatibility Test Suite (CTS) prüft einen Großteil der Plattform auf Verhaltenskompatibilität, aber nicht alle Bereiche. Der Implementierer ist dafür verantwortlich, die Verhaltenskompatibilität mit dem Android Open Source Project sicherzustellen.

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 im Upstream-Android-Quellcode nicht mit der Markierung „@hide“ versehen ist. 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 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, 10].

Bei Geräteimplementierungen MUSS Dalvik so konfiguriert werden, dass jeder Anwendung auf Geräten mit Bildschirmen mit mittlerer oder niedriger Dichte mindestens 16 MB Arbeitsspeicher zugewiesen werden. Bei Geräteimplementierungen MUSS Dalvik so konfiguriert werden, dass jeder Anwendung auf Geräten mit Bildschirmen mit hoher Dichte mindestens 24 MB Arbeitsspeicher zugewiesen werden. Geräteimplementierungen können mehr Arbeitsspeicher zuweisen als diese Werte, müssen dies aber nicht.

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, 11]. 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 enthält APIs, mit denen Entwickler Nutzer über wichtige Ereignisse informieren können [Ressourcen, 12]. Geräteimplementierer MÜSSEN jede der so definierten Benachrichtigungsarten unterstützen, insbesondere Töne, Vibration, Licht und Statusleiste.

Außerdem MÜSSEN in der Implementierung alle in den APIs [Ressourcen, 13] oder im Stilhandbuch für Statussymbole [Ressourcen, 14] 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, 15], 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, 16]) können Apps 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, 17]. 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 Referenzsoftware

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

  • Rechner (im SDK enthalten)
  • Lunar Lander (im SDK enthalten)
  • Die Apps „Apps für Android“ [Ressourcen, 18].

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

Außerdem MÜSSEN bei Geräteimplementierungen alle Menüpunkte (einschließlich aller Untermenüs) der folgenden Smoke-Test-Anwendungen getestet werden:

  • ApiDemos (im SDK enthalten)
  • ManualSmokeTests (in CTS enthalten)

Jeder Testfall in den oben genannten Anwendungen MUSS auf der Geräteimplementierung korrekt ausgeführt werden.

5. 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, 19].

Geräteimplementierungen dürfen die Formate .apk [Ressourcen, 20], Android-Manifest [Ressourcen, 21] oder Dalvik-Bytecode [Ressourcen, 10] NICHT so erweitern, dass die Installation und Ausführung dieser Dateien auf anderen kompatiblen Geräten verhindert wird. Geräteimplementierer sollten die Referenz-Upstream-Implementierung von Dalvik und das Paketverwaltungssystem der Referenzimplementierung verwenden.

6. Multimedia-Kompatibilität

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

Weder Google noch die Open Handset Alliance geben eine Zusicherung dafür, dass diese Codecs 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.

Audio
Name Encoder Decoder Details Datei-/Containerformat
AAC LC/LTP   X 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+)   X
HE-AACv2 (erweitertes AAC+)   X
AMR-NB X X 4,75 bis 12,2 kbit/s bei 8 kHz abgetastet 3GPP (.3gp)
AMR-WB   X 9 Raten von 6,60 kbit/s bis 23,85 kbit/s bei 16 kHz Abtastrate 3GPP (.3gp)
MP3   X Mono/Stereo 8–320 kbit/s konstant (CBR) oder variable Bitrate (VBR) MP3 (.mp3)
MIDI   X 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   X   Ogg (.ogg)
PCM   X Lineare PCM mit 8 und 16 Bit (Raten bis zur Grenze der Hardware) WAVE (.wav)
Bild
JPEG X X base+progressive  
GIF   X    
PNG X X    
BMP   X    
Video
H.263 X X   3GPP-Dateien (.3gp)
H.264   X   3GPP- (.3gp) und MPEG-4-Dateien (.mp4)
MPEG4 Simple Profile   X   3GPP-Datei (.3gp)

In der Tabelle oben 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.

7. 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, 19]
    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, 19]
    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, 22]
    Geräteimplementierungen MÜSSEN das Monkey-Framework enthalten und für Anwendungen verfügbar machen.

8. Hardwarekompatibilität

Android soll Geräteimplementierer dabei unterstützen, innovative Formfaktoren und Konfigurationen zu entwickeln. Gleichzeitig erwarten Android-Entwickler bestimmte Hardware, Sensoren und APIs auf allen Android-Geräten. In diesem Abschnitt werden die Hardwarefunktionen aufgeführt, die alle mit Android 2.1 kompatiblen Geräte unterstützen müssen.

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

  • Klassendefinitionen für die APIs der Komponente MÜSSEN 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.

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.

8.1. Anzeige

Android 2.1 bietet Funktionen, die unter bestimmten Umständen bestimmte automatische Skalierungs- und Transformationsvorgänge ausführen, damit Drittanbieter-Anwendungen auf einer Vielzahl von Hardwarekonfigurationen relativ gut funktionieren [Ressourcen, 23]. Auf Geräten MÜSSEN diese Verhaltensweisen wie in diesem Abschnitt beschrieben implementiert sein.

Für Android 2.1 sind dies die gängigsten Displaykonfigurationen:

Bildschirmart Breite (Pixel) Höhe (Pixel) Diagonale Länge (Zoll) Bildschirmgrößengruppe Gruppe für Bildschirmdichte
QVGA 240 320 2,6–3,0 Klein Geringe Anzahl
WQVGA 240 400 3.2–3.5 Normal Geringe Anzahl
FWQVGA 240 432 3,5–3,8 Normal Geringe Anzahl
HVGA 320 480 3.0 - 3.5 Normal Mittel
WVGA 480 800 3.3–4.0 Normal Hoch
FWVGA 480 854 3,5–4,0 Normal Hoch
WVGA 480 800 4,8–5,5 Groß Mittel
FWVGA 480 854 5,0–5,8 Groß Mittel

Geräteimplementierungen, die einer der oben genannten Standardkonfigurationen entsprechen, MÜSSEN so konfiguriert sein, dass die angegebene Bildschirmgröße über die Klasse android.content.res.Configuration [Resources, 24] an Anwendungen gemeldet wird.

Einige .apk-Pakete haben Manifeste, in denen nicht angegeben ist, dass sie einen bestimmten Dichtebereich unterstützen. Beim Ausführen solcher Anwendungen gelten die folgenden Einschränkungen:

  • Geräteimplementierungen MÜSSEN Ressourcen in einer APK, die keinen Dichtequalifizierer haben, als Standardwert „medium“ (in der SDK-Dokumentation als „mdpi“ bezeichnet) interpretieren.
  • Bei der Verwendung auf einem Bildschirm mit niedriger Dichte MÜSSEN Geräteimplementierungen Medium-/mdpi-Assets um den Faktor 0, 75 verkleinern.
  • Bei der Verwendung auf einem Display mit hoher Dichte MÜSSEN Geräteimplementierungen Medium-/mdpi-Assets um den Faktor 1, 5 skalieren.
  • Bei Geräteimplementierungen dürfen Assets innerhalb eines Dichtebereichs NICHT skaliert werden. Zwischen den Dichtebereichen müssen sie jedoch genau mit diesen Faktoren skaliert werden.

8.1.2. Außergewöhnliche Displaykonfigurationen

Displaykonfigurationen, die nicht mit einer der in Abschnitt 8.1.1 aufgeführten Standardkonfigurationen übereinstimmen, erfordern zusätzliche Überlegungen und Maßnahmen, um sie kompatibel zu machen. Geräteimplementierer MÜSSEN sich gemäß Abschnitt 12 an das Android-Kompatibilitätsteam wenden, um Klassifizierungen für den Bildschirmgrößenbereich, die Dichte und den Skalierungsfaktor zu erhalten. Wenn diese Informationen zur Verfügung gestellt werden, MÜSSEN sie in Geräteimplementierungen wie angegeben implementiert werden.

Einige Displaykonfigurationen (z. B. sehr große oder sehr kleine Bildschirme und einige Seitenverhältnisse) sind grundsätzlich nicht mit Android 2.1 kompatibel. Daher sollten Geräteimplementierer sich so früh wie möglich im Entwicklungsprozess an das Android-Kompatibilitätsteam wenden.

8.1.3. Messwerte für Displaykampagnen

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

8.2. 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, 24] angegebenen Formate entspricht (d. h. QWERTY oder 12-Tasten)

8.3. Bedienung ohne Touchscreen

Geräteimplementierungen:

  • Navigationsoptionen ohne Touchbedienung (z. B. Trackball, Steuerkreuz oder Rad) KÖNNEN weggelassen werden.
  • MÜSSEN den korrekten Wert für android.content.res.Configuration.navigation [Ressourcen, 24] angeben.

8.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.

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.

8.5. Touchscreen-Eingabe

Geräteimplementierungen:

  • MUSS einen Touchscreen haben
  • KANN einen kapazitiven oder resistiven Touchscreen haben
  • Der Wert von android.content.res.Configuration[Resources, 24] muss dem Typ des Touchscreens auf dem Gerät entsprechen.

8.6. 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.7. 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.

8.8. Wireless Data Networking

Geräteimplementierungen MÜSSEN die Unterstützung für drahtlose Hochgeschwindigkeitsdatennetzwerke umfassen. Insbesondere müssen Geräteimplementierungen mindestens einen drahtlosen 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 und 802.11g.

Wenn eine Geräteimplementierung eine bestimmte Modalität enthält, für die das Android SDK eine API enthält (z. B. WLAN, GSM oder CDMA), MUSS die Implementierung die API unterstützen.

Geräte KÖNNEN mehrere Arten von drahtlosen Datenverbindungen implementieren. Geräte KÖNNEN eine kabelgebundene Datenverbindung (z. B. Ethernet) implementieren, MÜSSEN aber mindestens eine Form der drahtlosen Verbindung wie oben beschrieben haben.

8.9. Kamera

Geräteimplementierungen MÜSSEN eine Kamera enthalten. Die mitgelieferte Kamera:

  • 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.

Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs 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. (Dies ist das Format, das von der 7k-Hardwarefamilie nativ verwendet wird.) Das heißt, NV21 MUSS der Standard sein.

Geräteimplementierungen MÜSSEN die vollständige Kamera-API implementieren, die in der Android 2.1 SDK-Dokumentation [Ressourcen, 26] 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.

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 keine anderen Strings als die als Konstanten in der android.hardware.Camera.Parameters dokumentierten an die android.hardware.Camera.setParameters()-Methode übergebenen Strings berücksichtigen oder erkennen, es sei denn, die Strings beginnen mit einem String, der den Namen des Geräteimplementators angibt. 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, es sei denn, die Parameternamen sind durch ein Stringpräfix eindeutig als nicht standardmäßig gekennzeichnet.

8.10. Beschleunigungsmesser

Geräteimplementierungen MÜSSEN einen 3-Achsen-Beschleunigungsmesser enthalten und MÜSSEN Ereignisse mit mindestens 50 Hz senden können. Das vom Beschleunigungsmesser verwendete Koordinatensystem MUSS dem Android-Sensorkoordinatensystem entsprechen, wie in den Android APIs beschrieben (siehe [Ressourcen, 27]).

8.11. Kompass

Geräteimplementierungen MÜSSEN einen 3-Achsen-Kompass enthalten und MÜSSEN Ereignisse mit mindestens 10 Hz senden können. Das vom Kompass verwendete Koordinatensystem MUSS dem Android-Sensorkoordinatensystem entsprechen, wie es in der Android API definiert ist (siehe [Ressourcen, 27]).

8.12. GPS

Geräteimplementierungen MÜSSEN ein GPS enthalten und SOLLTEN eine Form von „Assisted GPS“ (erweitertes GPS) verwenden, um die Zeit bis zur GPS-Fixierung zu minimieren.

8.13. Telefonie

Android 2.1 KANN auf Geräten verwendet werden, die keine Telefoniehardware enthalten. Android 2.1 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.

Siehe auch Abschnitt 8.8, Drahtlose Datennetzwerke.

8.14. Arbeitsspeicher und Datenspeicher

Für Geräteimplementierungen muss mindestens 92 MB Arbeitsspeicher für den Kernel und den Userspace verfügbar sein. Die 92 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.

Hinweis: Dieser Abschnitt wurde durch das Korrigendum EX6580 geändert.

8.15. Gemeinsam genutzter Speicherplatz für Anwendungen

Geräteimplementierungen MÜSSEN freigegebenen Speicher für Anwendungen anbieten. Der bereitgestellte freigegebene Speicherplatz muss mindestens 2 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 Art des verwendeten freigegebenen Speichers MUSS der freigegebene Speicher USB-Massenspeicher implementieren, wie in Abschnitt 8.6 beschrieben. Der freigegebene Speicher muss ab Werk mit dem FAT-Dateisystem bereitgestellt werden.

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 2 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 2 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.

Hinweis: Dieser Abschnitt wurde durch das Erratum EX6580 hinzugefügt.

8.16. Bluetooth

Geräteimplementierungen MÜSSEN einen Bluetooth-Transceiver enthalten. Bei Geräteimplementierungen MUSS die RFCOMM-basierte Bluetooth API wie in der SDK-Dokumentation beschrieben aktiviert sein [Ressourcen, 29]. Geräteimplementierungen MÜSSEN relevante Bluetooth-Profile wie A2DP, AVRCP, OBEX usw. implementieren, sofern dies für das Gerät zutrifft.

Hinweis: Dieser Abschnitt wurde durch das Erratum EX6580 hinzugefügt.

9. Leistungskompatibilität

Eines der Ziele des Android-Kompatibilitätsprogramms besteht darin, Nutzern eine einheitliche Anwendungserfahrung zu ermöglichen. 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 in der folgenden Tabelle definierten wichtigsten Leistungsmesswerte eines mit Android 2.1 kompatiblen Geräts erfüllen:

Messwert Leistungsgrenzwert Kommentare
Startzeit der Anwendung Die folgenden Anwendungen sollten innerhalb der angegebenen Zeit gestartet werden.
  • Browser: weniger als 1.300 ms
  • 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.  

10. Kompatibilität des Sicherheitsmodells

Geräteimplementierungen MÜSSEN ein Sicherheitsmodell implementieren, das dem Sicherheitsmodell der Android-Plattform entspricht, wie im Referenzdokument „Sicherheit und Berechtigungen“ in den APIs [Ressourcen, 28] 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.

10.1. Berechtigungen

Geräteimplementierungen MÜSSEN das Android-Berechtigungsmodell gemäß der Android-Entwicklerdokumentation unterstützen [Ressourcen, 28]. 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.

10.2. UID und Prozessisolierung

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

10.3. Dateisystemberechtigungen

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

11. 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.1 veröffentlicht werden. Geräteimplementierungen MÜSSEN die neueste CTS-Version bestehen, die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbar ist.

12. 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 die Kompatibilität von Drittanbieteranwendungen beeinträchtigt, MUSS der Geräteimplementierer den Fehler über ein verfügbares Softwareupdate korrigieren, das gemäß dem gerade beschriebenen Mechanismus angewendet werden kann.

13. 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.