Kompatibilitätsdefinition für Android 2.2

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

Inhaltsverzeichnis

1. Einführung

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

Damit Geräte mit Android 2.2 kompatibel sind, müssen sie folgende Anforderungen erfüllen:

• 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. 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.2: http://source.android.com/docs/compatibility/2.2/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 zu Tools (für adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
20. Beschreibung von Android-APK-Dateien: 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. Liste der Android-Hardwarefunktionen: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. Unterstützung mehrerer Bildschirme: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. Sensorkoordinatenraum: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. Referenz zu Sicherheit und Berechtigungen unter Android: http://developer.android.com/guide/topics/security/security.html
30. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

Viele dieser Ressourcen stammen direkt oder indirekt aus dem Android 2.2 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.2 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.2 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.2 MUSS dieses Feld den Ganzzahlwert 8 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. 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.2/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 („_“).
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
• Startbildschirm
• 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 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. 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. 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. Ebenso ist eine vollständige Webnutzung für die Android-Nutzererfahrung von zentraler Bedeutung. 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 von Geräten MÜSSEN auf dem WebKit-Build 533.1 aus dem Upstream-Android Open Source-Baum für Android 2.2 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-Konfiguration MUSS die Unterstützung der HTML5-Datenbank, des Anwendungscaches und der APIs für die Standortermittlung umfassen [Ressourcen, 9]. Das WebView MUSS das HTML5-<video>-Tag unterstützen. 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 bereitgestellt wird, muss die android.webkit.WebView-Komponente, die für Drittanbieteranwendungen bereitgestellt wird, auf WebKit basieren, wie in Abschnitt 3.4.1 beschrieben.

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 HTML5-Geolokalisierung, Anwendungscache, Datenbank-APIs und das <video>-Tag in der eigenständigen Browseranwendung unterstützen.

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ä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 mit hoher Dichte MUSS Dalvik so konfiguriert werden, dass jeder Anwendung mindestens 24 MB Arbeitsspeicher zugewiesen werden. Beachten Sie, dass Geräteimplementierungen möglicherweise 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, 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.

3.8.3. Suchen

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

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

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.

6.1. Medien-Codecs

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.

6.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.2 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.2 optional, werden aber in einer zukünftigen Version erforderlich sein. Wir empfehlen Ihnen dringend, diese Anforderungen in Android 2.2 zu erfüllen, da Geräte mit Android 2.2 andernfalls nicht mit der zukünftigen Version kompatibel sind.

6.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 MÜSSEN alle in diesem Abschnitt beschriebenen Anforderungen an die Audiolatenz erfüllen.

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.2 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.2 optional, werden aber in einer zukünftigen Version erforderlich sein. Wir empfehlen Ihnen dringend, diese Anforderungen in Android 2.2 zu erfüllen, da Geräte mit Android 2.2 andernfalls nicht mit der zukünftigen Version kompatibel sind.

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.2 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. [Ressourcen, 23]

8.1. Anzeige

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

Für Android 2.2 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 wie in Abschnitt 13 beschrieben an das Android-Kompatibilitätsteam wenden, um Klassifizierungen für den Bildschirmgrößen-Bucket, 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.2 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, 26] definierten Anzeigemesswerte korrekte Werte angegeben werden.

8.1.4. Deklarierte Bildschirmunterstützung

Anwendungen können über das Attribut <supports-screens> in der Datei „AndroidManifest.xml“ angeben, welche Bildschirmgrößen sie unterstützen. 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.

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, 25] 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, 25] 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 [Ressourcen, 25] 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

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.
• MÜSSEN die Unterstützung der USB-Massenspeicherspezifikation implementieren, damit entweder auf den Wechsel- oder den Festplattenspeicher des Geräts von einem Host-PC aus zugegriffen 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 Rückkamera haben. Die mitgelieferte Rückkamera:

• 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.2 SDK-Dokumentation [Ressourcen, 27] 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 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.

Geräteimplementierungen KÖNNEN eine Frontkamera enthalten. Wenn eine Geräteimplementierung jedoch eine Frontkamera enthält, darf die Kamera-API, die auf dem Gerät implementiert ist, die Frontkamera NICHT standardmäßig verwenden. Die Kamera-API in Android 2.2 ist also nur für Rückkameras gedacht. Geräteimplementierungen dürfen die API NICHT wiederverwenden oder überladen, um auf eine Frontkamera zuzugreifen, falls vorhanden. Alle benutzerdefinierten APIs, die von Geräteimplementierern zur Unterstützung von Frontkameras hinzugefügt werden, MÜSSEN den Abschnitten 3.5 und 3.6 entsprechen. Wenn beispielsweise eine benutzerdefinierte android.hardware.Camera- oder Camera.Parameters-Unterklasse zur Unterstützung von Frontkameras bereitgestellt wird, darf sie sich gemäß den Abschnitten 3.5 und 3.6 NICHT in einem vorhandenen Namespace befinden. Die Tatsache, dass ein Gerät eine Frontkamera hat, erfüllt nicht die Anforderung, dass Geräte eine Rückkamera haben müssen.

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, 28]).

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, 28]).

8.12. GPS

Geräteimplementierungen MÜSSEN einen GPS-Empfänger und SOLLTEN eine Art „Assisted GPS“-Technologie enthalten, um die Zeit für die GPS-Fixierung zu minimieren.

8.13. Telefonie

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

Zusätzlich zu den oben genannten Anforderungen sollten Geräteimplementierungen mindestens 128 MB Arbeitsspeicher für den Kernel und den Userspace haben, zusätzlich zu dem Arbeitsspeicher, der für Hardwarekomponenten reserviert ist, die nicht vom Kernel verwaltet werden. Für die Geräteimplementierung sollte mindestens 1 GB nichtflüchtiger Speicherplatz für Nutzerdaten verfügbar sein. Beachten Sie, dass diese höheren Anforderungen in einer zukünftigen Android-Version zu strikten Mindestanforderungen werden. 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.

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ß, als FAT formatiert und auf /sdcard bereitgestellt sein. 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.

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, 30]. Geräteimplementierungen MÜSSEN relevante Bluetooth-Profile wie A2DP, AVRCP, OBEX usw. implementieren, sofern dies für das Gerät zutrifft.

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.

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.2 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, 29] 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, 29]. 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, 29] 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, 29] definiert.

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

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

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.