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
- Anforderungen gemäß IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
- Android Compatibility Program Overview: http://source.android.com/compatibility/index.html
- Open-Source-Projekt von Android: http://source.android.com/
- API-Definitionen und ‑Dokumentation: http://developer.android.com/reference/packages.html
- Referenz zu Android-Berechtigungen: http://developer.android.com/reference/android/Manifest.permission.html
- Referenz für android.os.Build: http://developer.android.com/reference/android/os/Build.html
- Zulässige Versionsstrings für Android 2.1: http://source.android.com/docs/compatibility/2.1/versions.html
- Klasse „android.webkit.WebView“: http://developer.android.com/reference/android/webkit/WebView.html
- HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
- Spezifikation der Dalvik-Virtuellen Maschine: im Android-Quellcode unter dalvik/docs verfügbar
- App-Widgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
- Benachrichtigungen: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
- Anwendungsressourcen: http://code.google.com/android/reference/available-resources.html
- Styleguide für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
- Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
- Toasts: http://developer.android.com/reference/android/widget/Toast.html
- Live-Hintergründe: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
- Apps für Android: http://code.google.com/p/apps-for-android
- Referenzdokumentation für Tools (für adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
- Beschreibung der Android-APK-Datei: http://developer.android.com/guide/topics/fundamentals.html
- Manifestdateien: http://developer.android.com/guide/topics/manifest/manifest-intro.html
- Monkey-Testtool: https://developer.android.com/studio/test/other-testing-tools/monkey
- Unterstützung mehrerer Bildschirme: http://developer.android.com/guide/practices/screens_support.html
- android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
- android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
- android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
- Sensorkoordinatenraum: http://developer.android.com/reference/android/hardware/SensorEvent.html
- Referenz zu Sicherheit und Berechtigungen unter Android: http://developer.android.com/guide/topics/security/security.html
- 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
- 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.
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.
- Der Wert des Strings $(VERSION) MUSS mit dem Wert für
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.
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].
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 alleadb
-Funktionen unterstützen, die im Android SDK dokumentiert sind. Der geräteseitigeadb
-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 alleddms
Funktionen unterstützen, die im Android SDK dokumentiert sind. Daddms
adb
verwendet, sollte die Unterstützung fürddms
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
oderFLASH_MODE_ON
einesCamera.Parameters
-Objekts aktiviert hat. Diese Einschränkung gilt nicht für die integrierte Systemkamera-App des Geräts, sondern nur für Drittanbieter-Apps, dieCamera.PreviewCallback
verwenden.
Geräteimplementierungen MÜSSEN die folgenden Verhaltensweisen für die kamerabezogenen APIs implementieren:
- 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.
- 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.
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.
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.
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.
|
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.