Kompatibilitätsdefinition für Android 2.2

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

Inhaltsverzeichnis

1. Einleitung

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

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

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

Um als mit Android 2.2 kompatibel zu gelten, sind folgende Geräteimplementierungen erforderlich:

• MUSS die in dieser Kompatibilitätsdefinition dargelegten Anforderungen erfüllen, einschließlich aller durch Verweis einbezogenen Dokumente.
• MUSS die aktuellste Version der Android Compatibility Test Suite (CTS) bestehen, die zum Zeitpunkt der Fertigstellung der Geräteimplementierungssoftware verfügbar ist. (Das CTS ist als Teil des Android Open Source Project [ Ressourcen, 2 ] verfügbar.) Das CTS testet viele, aber nicht alle der in diesem Dokument beschriebenen Komponenten.

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

2. Ressourcen

1. IETF RFC2119-Anforderungsstufen: http://www.ietf.org/rfc/rfc2119.txt
2. Übersicht über das Android-Kompatibilitätsprogramm: http://source.android.com/docs/compatibility/index.html
3. Android Open Source-Projekt: http://source.android.com/
4. API-Definitionen und Dokumentation: http://developer.android.com/reference/packages.html
5. Referenz zu Android-Berechtigungen: http://developer.android.com/reference/android/Manifest.permission.html
6. android.os.Build-Referenz: http://developer.android.com/reference/android/os/Build.html
7. Für Android 2.2 zulässige Versionszeichenfolgen: http://source.android.com/docs/compatibility/2.2/versions.html
8. android.webkit.WebView-Klasse: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. Spezifikation der Dalvik Virtual Machine: verfügbar im Android-Quellcode unter dalvik/docs
11. AppWidgets: 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. Stilleitfaden für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. Suchmanager: 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. Dokumentation zum Referenztool (für adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
20. Beschreibung der Android-Apk-Datei: http://developer.android.com/guide/topics/fundamentals.html
21. Manifestdateien: http://developer.android.com/guide/topics/manifest/manifest-intro.html
22. Monkey-Testtool: https://developer.android.com/studio/test/other-testing-tools/monkey
23. 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 Android-Sicherheit und -Berechtigungen: 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 vom Android 2.2 SDK und sind funktional identisch mit den Informationen in der Dokumentation dieses SDK. In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstestsuite nicht mit der SDK-Dokumentation übereinstimmen, gilt die SDK-Dokumentation als maßgeblich. Alle in den oben aufgeführten Referenzen bereitgestellten technischen Details werden durch die Aufnahme als Teil dieser Kompatibilitätsdefinition betrachtet.

3. Software

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

3.1. Verwaltete API-Kompatibilität

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

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

3.2. Soft-API-Kompatibilität

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

3.2.2. Build-Parameter

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

3.2.3. Absichtskompatibilität

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

3.2.3.1. Kernanwendungsabsichten

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

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

Die folgenden Anwendungen gelten als Kernanwendungen des Android-Systems:

• Tischuhr
• Browser
• Kalender
• Taschenrechner
• Kamera
• Kontakte
• Email
• Galerie
• GlobalSearch
• Startprogramm
• LivePicker (d. h. die Anwendung zur Auswahl von Live-Hintergründen; kann weggelassen werden, wenn das Gerät Live-Hintergründe nicht unterstützt, gemäß Abschnitt 3.8.5.)
• Nachrichten (auch bekannt als „Mms“)
• Musik
• Telefon
• Einstellungen
• Tonaufnahmegerät

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

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

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

3.2.3.2. Absichtsüberschreibungen

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

3.2.3.3. Absichts-Namespaces

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

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

3.2.3.4. Sendeabsichten

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

3.3. Native API-Kompatibilität

In Dalvik ausgeführter verwalteter Code kann nativen Code aufrufen, der in der APK-Datei der Anwendung als ELF-SO-Datei bereitgestellt wird, die für die entsprechende Hardwarearchitektur des Geräts kompiliert wurde. Geräteimplementierungen MÜSSEN Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code unter Verwendung der standardmäßigen JNI-Semantik (Java Native Interface) aufzurufen. Die folgenden APIs MÜSSEN für nativen Code verfügbar sein:

• libc (C-Bibliothek)
• libm (Mathebibliothek)
• 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 mithilfe eines Software-Renderers implementieren. Geräteimplementierungen SOLLTEN so viel von OpenGL ES 1.1 implementieren, wie die Gerätehardware unterstützt. Geräteimplementierungen SOLLTEN eine Implementierung für OpenGL ES 2.0 bereitstellen, wenn die Hardware auf diesen APIs eine angemessene Leistung erbringen kann.

Diese Bibliotheken MÜSSEN quellkompatibel (dh Header-kompatibel) und binärkompatibel (für eine bestimmte Prozessorarchitektur) mit den vom Android Open Source-Projekt in Bionic bereitgestellten Versionen 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 Header-, Binär- und Verhaltenskompatibilität sicherstellen.

Geräteimplementierungen MÜSSEN die vom Gerät unterstützte native Application Binary Interface (ABI) über die android.os.Build.CPU_ABI API genau melden. Der ABI MUSS einer der Einträge sein, die in der neuesten Version des Android NDK in der Datei docs/CPU-ARCH-ABIS.txt dokumentiert sind. Beachten Sie, dass zusätzliche Versionen des Android NDK möglicherweise Unterstützung für zusätzliche ABIs einführen.

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

3.4. Webkompatibilität

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

3.4.1. WebView-Kompatibilität

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

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

Die WebView-Konfiguration MUSS Unterstützung für die HTML5-Datenbank, den Anwendungscache und Geolocation-APIs umfassen [ Ressourcen, 9 ]. Das WebView MUSS Unterstützung für das HTML5-Tag <video> enthalten. HTML5-APIs MÜSSEN wie alle JavaScript-APIs standardmäßig in einer WebView deaktiviert sein, es sei denn, der Entwickler aktiviert sie explizit über die üblichen Android-APIs.

3.4.2. Browser-Kompatibilität

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

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

Die eigenständige Browseranwendung (unabhängig davon, ob sie auf der Upstream-WebKit-Browseranwendung oder einem Ersatz eines Drittanbieters basiert) SOLLTE möglichst viel HTML5 [ Ressourcen, 9 ] unterstützen. Geräteimplementierungen MÜSSEN mindestens HTML5-Geolokalisierung, Anwendungscache und Datenbank-APIs sowie das <video>-Tag in der eigenständigen Browseranwendung unterstützen.

3.5. API-Verhaltenskompatibilität

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

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

Die obige Liste ist nicht vollständig und es liegt in der Verantwortung der Geräteimplementierer, 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 wesentliche Teile des Systems neu zu implementieren.

Die Compatibility Test Suite (CTS) testet wesentliche Teile der Plattform auf Verhaltenskompatibilität, jedoch nicht alle. Es liegt in der Verantwortung des Implementierers, die Verhaltenskompatibilität mit dem Android Open Source Project sicherzustellen.

3.6. API-Namespaces

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

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

Zu den verbotenen Änderungen gehören:

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

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

Geräteimplementierer KÖNNEN benutzerdefinierte APIs hinzufügen, solche APIs DÜRFEN sich jedoch NICHT in einem Namensraum befinden, der einer anderen Organisation gehört oder auf diese verweist. Beispielsweise DÜRFEN Geräteimplementierer KEINE APIs zum com.google.* oder einem ähnlichen Namespace hinzufügen. Nur Google darf dies tun. Ebenso DARF Google KEINE APIs zu den Namespaces anderer Unternehmen hinzufügen.

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

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

3.7. Kompatibilität virtueller Maschinen

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

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

3.8. Kompatibilität der Benutzeroberfläche

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

3.8.1. Widgets

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

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

3.8.2. Benachrichtigungen

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

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

3.8.3. Suchen

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

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

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

3.8.4. Toasts

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

3.8.5. Live-Hintergründe

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

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

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

4. Referenz-Softwarekompatibilität

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

• Rechner (im SDK enthalten)
• Lunar Lander (im SDK enthalten)
• Die „Apps für Android“-Anwendungen [ Ressourcen, 18 ].
• Replica Island (verfügbar im Android Market; nur erforderlich für Geräteimplementierungen, die OpenGL ES 2.0 unterstützen)

Jede der oben genannten Apps MUSS gestartet werden und sich bei der Implementierung korrekt verhalten, damit die Implementierung als kompatibel gilt.

Darüber hinaus MÜSSEN Geräteimplementierungen jedes Menüelement (einschließlich aller Untermenüs) jeder dieser Rauchtestanwendungen testen:

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

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

5. Kompatibilität der Anwendungspakete

Geräteimplementierungen MÜSSEN Android-„.apk“-Dateien installieren und ausführen, wie sie vom „aapt“-Tool generiert wurden, das im offiziellen Android SDK enthalten ist [ Ressourcen, 19 ].

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

6. Multimedia -Kompatibilität

Geräteimplementierungen müssen alle Multimedia -APIs vollständig implementieren. Die Geräteimplementierungen müssen die Unterstützung aller nachstehend beschriebenen Multimedia -Codecs enthalten und sollten die unten beschriebenen Schallverarbeitungsrichtlinien erfüllen.

6.1. Mediencodecs

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

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

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

6.2. Audio Aufnahme

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

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

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

6.3. Audio -Latenz

Die Audio -Latenz ist weitgehend definiert als das Intervall zwischen einem Antrag auf Audio -Wiedergabe oder Aufzeichnungsoperation und wenn die Geräteimplementierung tatsächlich mit dem Betrieb beginnt. Viele Anwendungsklassen stützen sich auf kurze Latenzen, um Echtzeiteffekte wie Soundeffekte oder VoIP-Kommunikation zu erzielen. Geräteimplementierungen sollten alle in diesem Abschnitt beschriebenen Audio -Latenzanforderungen erfüllen.

Für die Zwecke dieses Abschnitts:

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

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

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

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

7. Kompatibilität für Entwicklerwerkzeuge

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

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

8. Hardwarekompatibilität

Android soll Geräteimplementierer unterstützen, die innovative Formularfaktoren und Konfigurationen erstellen. Gleichzeitig erwarten Android -Entwickler bestimmte Hardware, Sensoren und APIs im gesamten Android -Gerät. In diesem Abschnitt werden die Hardwarefunktionen aufgeführt, die alle Android 2.2 -kompatiblen Geräte unterstützen müssen.

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

• Klassendefinitionen für die API der Komponente müssen vorhanden sein
• Das Verhalten der API muss in vernünftiger Weise als No-Ops implementiert werden
• API -Methoden müssen NULL -Werte zurückgeben, sodass durch die SDK -Dokumentation zulässig ist
• API-Methoden müssen keine OP-Implementierungen von Klassen zurückgeben, bei denen Nullwerte in der SDK-Dokumentation nicht zulässig sind

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

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

8.1. Anzeige

Android 2.2 umfasst Einrichtungen, die unter bestimmten Umständen bestimmte automatische Skalierungs- und Transformationsvorgänge ausführen, um sicherzustellen, dass Drittanbieter Anwendungen für eine Vielzahl von Hardwarekonfigurationen einigermaßen gut laufen [ Ressourcen, 24 ]. Geräte müssen diese Verhaltensweisen ordnungsgemäß implementieren, wie in diesem Abschnitt beschrieben.

Für Android 2.2 sind dies die häufigsten Display -Konfigurationen:

Geräteimplementierungen, die einer der oben genannten Standardkonfigurationen entsprechen, müssen so konfiguriert werden, dass die angegebene Bildschirmgröße über die android.content.res.Configuration [ Ressourcen, 24 ] -Klasse meldet.

Einige .APK -Pakete haben Manifests, die sie nicht als die Unterstützung eines bestimmten Dichtebereichs identifizieren. Beim Ausführen solcher Anwendungen gelten die folgenden Einschränkungen:

• Geräteimplementierungen müssen Ressourcen in einem .APK interpretieren, der eine Dichtequalifikatorin als "Medium" fehlt (in der SDK -Dokumentation als "MDPI" bezeichnet.)
• Beim Betrieb auf einem "niedrigen" Dichtebildschirm müssen Geräteimplementierungen das Medium/MDPI -Vermögen um einen Faktor von 0,75 skalieren.
• Beim Betrieb auf einem "hohen" Dichtebildschirm müssen Geräteimplementierungen das Medium/MDPI -Vermögen um einen Faktor 1,5 skalieren.
• Geräteimplementierungen dürfen die Vermögenswerte nicht innerhalb eines Dichtebereichs skalieren und müssen die Vermögenswerte nach genau diesen Faktoren zwischen den Dichtebereichen skalieren.

8.1.2. Nicht standardmäßige Anzeigenkonfigurationen

Zeigen Sie Konfigurationen an, die nicht mit einer der in Abschnitt 8.1.1 aufgeführten Standardkonfigurationen übereinstimmen. Erfordern Sie zusätzliche Überlegungen und Arbeiten, um kompatibel zu sein. Geräteimplementierer müssen sich wie in Abschnitt 13 beschrieben an das Android-Kompatibilitätsteam wenden, um Klassifizierungen für Bucket, Dichte und Skalierungsfaktor in der Bildschirmgröße zu erhalten. Bei dieser Informationen müssen Geräteimplementierungen sie wie angegeben implementieren.

Beachten Sie, dass einige Anzeigekonfigurationen (z. B. sehr große oder sehr kleine Bildschirme und einige Seitenverhältnisse) mit Android 2.2 grundsätzlich nicht kompatibel sind. Daher werden Geräteimplementierer aufgefordert, sich im Entwicklungsprozess so früh wie möglich auf das Android -Kompatibilitätsteam zu wenden.

8.1.3. Metriken anzeigen

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

8.1.4. Deklarierte Bildschirmunterstützung

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

8.2. Tastatur

Geräteimplementierungen:

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

8.3. Nicht-Touch-Navigation

Geräteimplementierungen:

• Kann eine Navigationsoptionen für Nicht-Touch-Navigation weglassen (dh kann ein Trackball, ein D-Pad oder ein Rad weglassen).
• Muss den korrekten Wert für android.content.res.Configuration.navigation [ Ressourcen, 25 ] melden.

8.4. Bildschirmausrichtung

Kompatible Geräte müssen die dynamische Orientierung durch Anwendungen entweder auf Porträt- oder Landschaftsbildschirmorientierung unterstützen. Das heißt, das Gerät muss die Anfrage der Anwendung nach einer bestimmten Bildschirmausrichtung respektieren. Geräteimplementierungen können entweder eine Porträt- oder Landschaftsorientierung als Standardeinstellung auswählen.

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

8.5. Touchscreen -Eingang

Geräteimplementierungen:

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

8.6. USB

Geräteimplementierungen:

• Muss einen USB-Client implementieren, der mit einem USB-Host mit einem Standard-USB-A-Port verbunden werden kann
• Muss die Android -Debug -Brücke über USB implementieren (wie in Abschnitt 7 beschrieben)
• Muss die USB -Massenspeicherspezifikation implementieren, damit ein Host, der mit dem Gerät angeschlossen ist
• Sollte den Micro -USB -Formfaktor auf der Geräteseite verwenden
• Kann einen nicht standardmäßigen Anschluss auf der Geräteseite enthalten. Wenn dies jedoch mit einem Kabel versendet werden muss, das die benutzerdefinierte Pinout mit einem Standard-USB-A-Anschluss anschließen kann
• Sollte Unterstützung für die USB -Massenspeicherspezifikation implementieren (so dass entweder abnehmbarer oder fester Speicher auf dem Gerät über einen Host -PC zugegriffen werden können)

8.7. Navigationstasten

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

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

8.8. Wireless Data Networking

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

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

Geräte können mehr als eine Form der drahtlosen Datenkonnektivität implementieren. Geräte können verdrahtete Datenkonnektivität (wie Ethernet) implementieren, müssen jedoch wie oben oben mindestens eine Form der drahtlosen Konnektivität enthalten.

8.9. Kamera

Die Geräteimplementierungen müssen eine nach hinten gerichtete Kamera enthalten. Die mitgelieferte Rückfahrkamera:

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

Geräteimplementierungen müssen das folgende Verhalten für die Kamera-bezogenen APIs implementieren:

1. Wenn eine Anwendung android.hardware.camera.Parameters.setPreviewFormat (int) noch nie genannt wurde, muss das Gerät Android.hardware.pixelformat.ycbcr_420_sp für Vorschau -Daten verwenden, die für Anwendungsrückrufe bereitgestellt werden.
2. Wenn eine Anwendung eine android.hardware.camera.PreviewCallback -Instanz und das System auf die OnPreviewFrame () -Methode aufruft, wenn das Vorschau -Format YCBCR_420_SP ist, müssen die Daten im BYTE [] in das OnPreviewFrame () übergeben () müssen das NV21 -Codierungsformat weiter sein. (Dies ist das Format, das nativ von der 7K -Hardwarefamilie 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 Hardware -Autofokus oder andere Funktionen enthält. Beispielsweise müssen Kameras, denen Autofokus fehlt, noch eine registrierte android.hardware.Camera.AutoFocusCallback Instanzen anrufen (obwohl dies für eine Nicht-Autofocus-Kamera nicht relevant ist.)

Geräteimplementierungen müssen jeden Parameternamen erkennen und ehren, der als Konstante auf der Klasse android.hardware.Camera.Parameters definiert ist, wenn die zugrunde liegende Hardware die Funktion unterstützt. Wenn die Gerätehardware keine Funktion unterstützt, muss sich die API wie dokumentiert verhalten. Umgekehrt dürfen Geräteimplementierungen keine an die android.hardware.Camera.setParameters() -Methode übergebene String -Konstanten ehren oder anerkennen, die nicht als Konstanten auf der android.hardware.Camera.Parameters dokumentiert sind. Das heißt, Geräteimplementierungen müssen alle Standard -Kameraparameter unterstützen, wenn die Hardware zulässt, und dürfen keine benutzerdefinierten Kameraparametertypen unterstützen.

Die Geräteimplementierungen können eine Frontkamera enthalten. Wenn jedoch eine Geräteimplementierung eine Kamera vorne mit der Vorderseite enthält, darf die auf dem Gerät implementierte Kamera-API standardmäßig die vorne ausgerichtete Kamera nicht verwenden. Das heißt, die Kamera-API in Android 2.2 dient nur für nach hinten gerichtete Kameras, und die Geräteimplementierungen dürfen die API nicht wiederverwenden oder überladen, um auf einer vorne gerichteten Kamera zu reagieren, wenn eine vorhanden ist. Beachten Sie, dass alle benutzerdefinierten APIs, die von Geräteimplementierern hinzugefügt wurden, um Kameras vor Front zu unterstützen, die Abschnitte 3.5 und 3.6 einhalten müssen. Wenn beispielsweise eine benutzerdefinierte android.hardware.Camera oder Camera.Parameters Unterklasse zur Unterstützung von Kameras vorne bereitgestellt wird, darf sie nicht in einem vorhandenen Namespace befinden, wie in den Abschnitten 3.5 und 3.6 beschrieben. Beachten Sie, dass die Einbeziehung einer vorne ausgerichteten Kamera nicht der Anforderung entspricht, dass Geräte eine nach hinten gerichtete Kamera enthalten.

8.10. Beschleunigungsmesser

Die Geräteimplementierungen müssen einen 3-Achsen-Beschleunigungsmesser enthalten und in der Lage sein, Ereignisse zu 50 Hz oder mehr zu liefern. Das vom Beschleunigungsmesser verwendete Koordinatensystem muss dem Android -Sensorkoordinatensystem gemäß den Android -APIs entsprechen (siehe [ Ressourcen, 28 ]).

8.11. Kompass

Die Geräteimplementierungen müssen einen 3-Achsen-Kompass enthalten und in der Lage sein, Ereignisse 10 Hz oder höher zu liefern. Das vom Kompass verwendete Koordinatensystem muss dem Android -Sensorkoordinatensystem gemäß der Android -API entsprechen (siehe [ Ressourcen, 28 ]).

8.12. GPS

Die Geräteimplementierungen müssen einen GPS-Empfänger enthalten und sollten eine Form der "unterstützten GPS" -Technik umfassen, um die GPS-Sperrenzeit zu minimieren.

8.13. Telefonie

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

Siehe auch Abschnitt 8.8, drahtloses Data -Netzwerk.

8.14. Erinnerung und Speicherung

Geräteimplementierungen müssen dem Kernel und dem Benutzerspeicher über mindestens 92 MB Speicher stehen. Der 92MB muss zusätzlich zu jedem Speicher sein, der Hardwarekomponenten wie Radio, Speicher usw. gewidmet ist, und so steht dies nicht unter der Steuerung des Kernels.

Geräteimplementierungen müssen für Benutzerdaten mindestens 150 MB nicht flüchtiger Speicher zur Verfügung stehen. Das heißt, die /data muss mindestens 150 MB betragen.

Über die oben genannten Anforderungen hinaus sollten Geräteimplementierungen zusätzlich zu den Hardwarekomponenten, die nicht unter der Steuerung des Kernels enthalten sind, über mindestens 128 MB Speicherspeicher zur Verfügung stehen. Geräteimplementierungen sollten für Benutzerdaten mindestens 1 GB nicht flüchtiger Speicher zur Verfügung stehen. Beachten Sie, dass diese höheren Anforderungen dazu geplant sind, in einer zukünftigen Version von Android zu harten Minimum zu werden. Geräteimplementierungen werden nachdrücklich aufgefordert, diese Anforderungen jetzt zu erfüllen, oder sie haben möglicherweise nicht berechtigt für eine zukünftige Version von Android.

8.15. Anwendungshilfespeicher

Geräteimplementierungen müssen gemeinsam genutztes Speicher für Anwendungen anbieten. Der freigegebene Speicher muss mindestens 2 GB groß sein.

Die Geräteimplementierungen müssen mit dem freigegebenen Speicher konfiguriert werden, der standardmäßig "aus der Box" montiert ist. Wenn der gemeinsam genutzte Speicher nicht auf dem Linux -Pfad /sdcard montiert ist, muss das Gerät eine symbolische Linux -Verbindung von /sdcard zum tatsächlichen Mountspunkt enthalten.

Geräteimplementierungen müssen als dokumentiert durch die android.permission.WRITE_EXTERNAL_STORAGE -Berechtigung für diesen gemeinsam genutzten Speicher. Der gemeinsame Speicher muss ansonsten von einer Anwendung beschreibbar sein, die diese Genehmigung erhält.

Geräteimplementierungen verfügen möglicherweise über Hardware für benutzergerechte abnehmbare Speicher, z. B. eine sichere digitale Karte. Alternativ können Geräteimplementierungen einen internen (nicht frequentierten) Speicher als gemeinsamer Speicher für Apps zuweisen.

Unabhängig von der Form des verwendeten Shared -Speichers muss der gemeinsam genutzte Speicher eine USB -Massenspeicherung implementieren, wie in Abschnitt 8.6 beschrieben. Wenn der gemeinsame Speicher mit dem Fat -Dateisystem aus dem Tellerrand versendet wird.

Es ist veranschaulichend, zwei gemeinsame Beispiele zu berücksichtigen. Wenn eine Geräteimplementierung einen SD-Kartensteckplatz enthält, um die gemeinsam genutzten Speicheranforderungen zu erfüllen, muss eine fettformatierte SD-Karte 2 GB in Größe oder größer mit dem Gerät enthalten sein, wie sie an Benutzer verkauft werden, und standardmäßig montiert werden. Wenn eine Geräteimplementierung einen internen festen Speicher verwendet, um diese Anforderung zu erfüllen, muss dieser Speicher eine Größe von 2 GB oder größer sein, als Fett formatiert und auf /sdcard montiert (oder /sdcard muss eine symbolische Verbindung zum physischen Standort sein, wenn es ist an anderer Stelle montiert.)

Geräteimplementierungen, die mehrere gemeinsam genutzte Speicherpfade (z. B. sowohl ein SD -Kartensteckplatz als auch der gemeinsame internationale Speicher) enthalten, sollten die Kernanwendungen wie den Medienscanner und ContentProvider ändern, um die an beiden Standorten platzierten Dateien zu unterstützen.

8.16. Bluetooth

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

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

9. Leistungskompatibilität

Eines der Ziele des Android -Kompatibilitätsprogramms ist es, den Verbrauchern einheitliche Anwendungserfahrung zu ermöglichen. Kompatible Implementierungen müssen nicht nur sicherstellen, dass die Anwendungen einfach auf dem Gerät korrekt ausgeführt werden, sondern dass diese mit angemessener Leistung und allgemein guter Benutzererfahrung dies tun. Geräteimplementierungen müssen die wichtigsten Leistungsmetriken eines in der folgenden Tabelle definierten Android 2.2 -kompatiblen Geräts erfüllen:

10. Sicherheitsmodellkompatibilität

Geräteimplementierungen müssen ein Sicherheitsmodell implementieren, das mit dem in der Sicherheits- und Berechtigungsreferenzdokument in den APIs [ Ressourcen, 29 ] in der Android -Entwicklerdokumentation definierten Sicherheitsmodell implementiert ist. Geräteimplementierungen müssen die Installation selbstsignierter Anträge unterstützen, ohne zusätzliche Berechtigungen/Zertifikate von Dritten/Behörden zu erfordern. Insbesondere müssen kompatible Geräte die in den folgenden Unterabschnitten beschriebenen Sicherheitsmechanismen unterstützen.

10.1. Berechtigungen

Geräteimplementierungen müssen das in der Android Developer -Dokumentation definierte Android -Berechtigungsmodell [ Ressourcen, 29 ] unterstützen. Insbesondere müssen Implementierungen jede in der SDK -Dokumentation beschriebene Genehmigung durchsetzen. Keine Berechtigungen dürfen weggelassen, geändert oder ignoriert werden. Implementierungen können zusätzliche Berechtigungen hinzufügen, vorausgesetzt, die neuen Berechtigungs -ID -Zeichenfolgen befinden sich nicht im Android.* Namespace.

10.2. UID und Prozessisolation

Geräteimplementierungen müssen das Android Application Sandbox-Modell unterstützen, bei dem jede Anwendung als eindeutige UID im Unix-Stil und in einem separaten Prozess ausgeführt wird. Geräteimplementierungen müssen unterstützen, dass mehrere Anwendungen als die gleiche Linux -Benutzer -ID ausgeführt werden, sofern die Anwendungen ordnungsgemäß signiert und konstruiert werden, wie in der Referenz für Sicherheit und Berechtigungen definiert [ Ressourcen, 29 ].

10.3. Dateisystem Berechtigungen

Geräteimplementierungen müssen das Modell der Android -Dateizugriffsberechtigungen wie definiert in der Referenz für Sicherheits- und Berechtigungen [ Ressourcen, 29 ] unterstützen.

10.4. Alternative Ausführungsumgebungen

Die Geräteimplementierungen können Laufzeitumgebungen umfassen, die Anwendungen verwenden, die eine andere Software oder Technologie verwenden, als der virtuelle Dalvik -Maschine oder den nativen Code. Solche alternativen Ausführungsumgebungen dürfen jedoch nicht das Android -Sicherheitsmodell oder die Sicherheit installierter Android -Anwendungen beeinträchtigen, wie in diesem Abschnitt beschrieben.

Alternative Laufzeiten müssen selbst Android -Anwendungen sein und sich an das Standard -Android -Sicherheitsmodell halten, wie an anderer Stelle in Abschnitt 10 beschrieben.

Alternative Laufzeiten dürfen keinen Zugriff auf Ressourcen erhalten, die durch Berechtigungen geschützt sind, die in der AndroidManifest.xml-Datei der Laufzeit nicht über den Mechanismus <uses-permission> angefordert wurden.

Alternative Laufzeiten dürfen Anträge nicht erlauben, die von Android -Berechtigungen geschützten Funktionen zu nutzen, die auf Systemanwendungen beschränkt sind.

Alternative Laufzeiten müssen sich am Android Sandbox -Modell einhalten. Speziell:

• Alternative Laufzeiten sollten Apps über den PackageManager in separate Android -Sandboxen installieren (dh Linux -Benutzer -IDs usw.)
• Alternative Laufzeiten bieten möglicherweise eine einzelne Android -Sandbox, die von allen Anwendungen mithilfe der alternativen Laufzeit gemeinsam genutzt wird.
• Alternative Laufzeiten und installierte Anwendungen mit einer alternativen Laufzeit darf die Sandbox einer anderen auf dem Gerät installierten App nicht wiederverwenden, außer über die Standard -Android -Mechanismen der gemeinsam genutzten Benutzer -ID und des Signierzertifikats
• Alternative Laufzeiten dürfen nicht mit den Sandkästen, die anderen Android -Anwendungen entsprechen, mit dem Zugriff auf die Sandkästen gestartet, gewährt oder erhalten.

Alternative Laufzeiten dürfen nicht mit anderen Bewerbungen des Superuser (Root) oder einer anderen Benutzer -ID gestartet, gewährt oder gewährt werden.

Die .APK -Dateien alternativer Laufzeiten können in das Systembild einer Geräteimplementierung aufgenommen werden, müssen jedoch mit einem Schlüssel unterzeichnet werden, der sich von dem Schlüssel unterscheidet, mit dem andere Anwendungen, die in der Geräteimplementierung enthalten sind, verwendet werden.

Bei der Installation von Anwendungen müssen alternative Laufzeiten die Einwilligung der Benutzer für die von der Anwendung verwendeten Android -Berechtigungen einholen. Das heißt, wenn eine Anwendung eine Geräteressource nutzen muss, für die eine entsprechende Android -Berechtigung (z. B. Kamera, GPS usw.) vorliegt, muss die alternative Laufzeit den Benutzer darüber informieren, dass die Anwendung auf diese Ressource zugreifen kann . Wenn die Laufzeitumgebung auf diese Weise keine Anwendungsfunktionen aufzeichnet, muss in der Laufzeitumgebung alle Berechtigungen aufgeführt, die von der Laufzeit selbst bei der Installation einer Anwendung mit dieser Laufzeit eingerichtet werden.

11. Kompatibilitätstest Suite

Die Geräteimplementierungen müssen die Android Compatibility Test Suite (CTS) [ Ressourcen, 2 ] über das Android Open Source -Projekt unter Verwendung der endgültigen Versandsoftware auf dem Gerät übergeben. Darüber hinaus sollten Geräteimplementierer die Referenzimplementierung im Android Open Source -Baum so weit wie möglich verwenden und die Kompatibilität bei Mehrdeutigkeiten in CTS und für alle Neuauflagen der Teile des Referenzquellencodes sicherstellen müssen.

Das CTS ist so konzipiert, dass sie auf einem tatsächlichen Gerät ausgeführt werden. Wie jede Software können die CTS selbst Fehler enthalten. Die CTS werden unabhängig von dieser Kompatibilitätsdefinition versioniert, und mehrere Überarbeitungen der CTS können für Android 2.2 veröffentlicht werden. Geräteimplementierungen müssen die neueste CTS -Version übergeben, die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbar ist.

12. Aktualisierbare Software

Die Geräteimplementierungen müssen einen Mechanismus enthalten, um die Gesamtheit der Systemsoftware zu ersetzen. Der Mechanismus muss keine "Live -Upgrades" durchführen - dh ein Neustart von Geräten ist erforderlich.

Jede Methode kann verwendet werden, sofern die gesamte auf dem Gerät vorinstallierte Software ersetzen kann. Beispielsweise erfüllt eine der folgenden Ansätze diese Anforderung:

• Downloads von Op-the-Air (OTA) mit Offline-Update über Neustart
• "Binded" Updates über USB von einem Host -PC
• "Offline" -Andates über einen Neustart und Update aus einer Datei auf abnehmbarem Speicher

Der verwendete Aktualisierungsmechanismus muss Updates unterstützen, ohne Benutzerdaten abzulösen. Beachten Sie, dass die vorgelagerte Android -Software einen Aktualisierungsmechanismus enthält, der diese Anforderung erfüllt.

Wenn in einer Geräteimplementierung nach seiner Veröffentlichung ein Fehler gefunden wird, jedoch innerhalb seiner angemessenen Produktlebensdauer, die in Absprache mit dem Android-Kompatibilitätsteam festgelegt wird, um die Kompatibilität von Thid-Party-Anwendungen zu beeinflussen, muss der Geräteimplementierer den Fehler über eine Software korrigieren Aktualisieren verfügbar, die gemäß dem gerade beschriebenen Mechanismus angewendet werden können.

13. Kontaktieren Sie uns

Sie können sich an die Dokumentautoren unter compatibilibility@android.com kontaktieren, um Klärungen zu erhalten, und um Probleme aufzurufen, von denen Sie glauben, dass das Dokument nicht behandelt wird.

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 getestet werden, die auf einem einzigen Gerät ausgeführt werden. Infolgedessen müssen Geräteimplementierungen auch das nachstehend beschriebene von Menschen angetriebene Bluetooth-Testverfahren bestehen.

Das Testverfahren basiert auf der Bluetoothchat-Beispiel-App, die im Android Open-Source-Projektbaum enthalten ist. Das Verfahren erfordert zwei Geräte:

• Eine Implementierung von Kandidatengeräten, die den zu testen
• Eine separate Geräteimplementierung, die bereits als kompatibel ist, und eines Modells aus der getesteten Geräteimplementierung - dh eine "bekannte gute" Geräteimplementierung

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

Einrichtung und Installation

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

Test Bluetooth Control by Apps

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

Test Pairing and Communication

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

Test Pairing and Communication in the Reverse Direction

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

Test Re-Launches

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

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