Kompatibilitätsdefinition für Android 4.2

Revision 2
Letzte Aktualisierung: 17. Februar 2013

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

Inhaltsverzeichnis

1. Einleitung
2. Ressourcen
3. Software
3.1. Verwaltete API-Kompatibilität
3.2. Soft-API-Kompatibilität
3.3. Native API-Kompatibilität
3.4. Webkompatibilität
3.5. API-Verhaltenskompatibilität
3.6. API-Namespaces
3.7. Kompatibilität virtueller Maschinen
3.8. Kompatibilität der Benutzeroberfläche
3.9 Geräteverwaltung
3.10 Barrierefreiheit
3.11 Text-to-Speech
4. Kompatibilität der Anwendungspakete
5. Multimedia-Kompatibilität
6. Kompatibilität von Entwicklertools und -optionen
7. Hardwarekompatibilität
7.1. Anzeige und Grafiken
7.2. Eingabegeräte
7.3. Sensoren
7.4. Datenkonnektivität
7.5. Kameras
7.6. Erinnerung und Speicherung
7.7. USB
8. Leistungskompatibilität
9. Kompatibilität des Sicherheitsmodells
10. Softwarekompatibilitätstests
11. Aktualisierbare Software
12. Kontaktieren Sie uns
Anhang A – Bluetooth-Testverfahren

1. Einleitung

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

Um als mit Android 4.2 kompatibel zu gelten, MÜSSEN Geräteimplementierungen die in dieser Kompatibilitätsdefinition dargelegten Anforderungen erfüllen, einschließlich aller durch Verweis einbezogenen Dokumente.

Wenn diese Definition oder die in Abschnitt 10 beschriebenen Softwaretests stillschweigend, mehrdeutig oder unvollständig sind, 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 so weit wie möglich 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 Softwaretests 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 4.2 zulässige Versionszeichenfolgen: http://source.android.com/docs/compatibility/4.2/versions.html
  8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
  9. Hardwarebeschleunigung: http://developer.android.com/guide/topics/graphics/hardware-accel.html
  10. android.webkit.WebView-Klasse: http://developer.android.com/reference/android/webkit/WebView.html
  11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  12. HTML5-Offline-Funktionen: http://dev.w3.org/html5/spec/Overview.html#offline
  13. HTML5-Video-Tag: http://dev.w3.org/html5/spec/Overview.html#video
  14. HTML5/W3C-Geolocation-API: http://www.w3.org/TR/geolocation-API/
  15. HTML5/W3C-Webdatenbank-API: http://www.w3.org/TR/webdatabase/
  16. HTML5/W3C IndexedDB-API: http://www.w3.org/TR/IndexedDB/
  17. Spezifikation der Dalvik Virtual Machine: verfügbar im Android-Quellcode unter dalvik/docs
  18. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  19. Benachrichtigungen: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  20. Anwendungsressourcen: http://code.google.com/android/reference/available-resources.html
  21. Stilleitfaden für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
  22. Suchmanager: http://developer.android.com/reference/android/app/SearchManager.html
  23. Toasts: http://developer.android.com/reference/android/widget/Toast.html
  24. Themen: http://developer.android.com/guide/topics/ui/themes.html
  25. R.style-Klasse: http://developer.android.com/reference/android/R.style.html
  26. Live-Hintergründe: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  27. Android-Geräteverwaltung: http://developer.android.com/guide/topics/admin/device-admin.html
  28. DevicePolicyManager-Referenz: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
  29. APIs des Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
  30. Android-Barrierefreiheits-APIs: http://developer.android.com/reference/android/view/accessibility/package-summary.html
  31. Eyes Free-Projekt: http://code.google.com/p/eyes-free
  32. Text-To-Speech-APIs: http://developer.android.com/reference/android/speech/tts/package-summary.html
  33. Dokumentation zum Referenztool (für ADB, AAPT, DDMS, Systrace): http://developer.android.com/guide/developing/tools/index.html
  34. Beschreibung der Android-Apk-Datei: http://developer.android.com/guide/topics/fundamentals.html
  35. Manifestdateien: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  36. Monkey-Testtool: https://developer.android.com/studio/test/other-testing-tools/monkey
  37. Android android.content.pm.PackageManager-Klasse und Liste der Hardwarefunktionen: http://developer.android.com/reference/android/content/pm/PackageManager.html
  38. Unterstützung mehrerer Bildschirme: http://developer.android.com/guide/practices/screens_support.html
  39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
  42. Bluetooth-API: http://developer.android.com/reference/android/bluetooth/package-summary.html
  43. NDEF-Push-Protokoll: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
  44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
  49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
  50. Kameraausrichtungs-API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  51. Kamera: http://developer.android.com/reference/android/hardware/Camera.html
  52. Offenes Android-Zubehör: http://developer.android.com/guide/topics/usb/accessory.html
  53. USB-Host-API: http://developer.android.com/guide/topics/usb/host.html
  54. Referenz zu Android-Sicherheit und -Berechtigungen: http://developer.android.com/guide/topics/security/security.html
  55. Apps für Android: http://code.google.com/p/apps-for-android
  56. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html
  57. Android-Dateiübertragung: http://www.android.com/filetransfer
  58. Android-Medienformate: http://developer.android.com/guide/appendix/media-formats.html
  59. HTTP-Live-Streaming-Protokollentwurf: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
  60. NFC-Verbindungsübergabe: http://www.nfc-forum.org/specs/spec_list/#conn_handover
  61. Bluetooth Secure Simple Pairing mit NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
  62. WLAN-Multicast-API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
  63. Aktionsassistent: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
  64. USB-Ladespezifikation: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
  65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
  66. Android USB-Audio: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
  67. Android-NFC-Freigabeeinstellungen: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
  68. Wifi Direct (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
  69. Sperr- und Startbildschirm-Widget: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
  70. UserManager-Referenz: http://developer.android.com/reference/android/os/UserManager.html
  71. Referenz zum externen Speicher: https://source.android.com/docs/core/storage
  72. Externe Speicher-APIs: http://developer.android.com/reference/android/os/Environment.html
  73. SMS-Kurzcode: http://en.wikipedia.org/wiki/Short_code
  74. Media Remote Control-Client: http://developer.android.com/reference/android/media/RemoteControlClient.html
  75. Display-Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
  76. Träume: http://developer.android.com/reference/android/service/dreams/DreamService.html
  77. Einstellungen für die Android-Anwendungsentwicklung: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
  • Kamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
  • Viele dieser Ressourcen stammen direkt oder indirekt vom Android 4.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

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

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

    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.

    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.

    Parameter Kommentare
    android.os.Build.VERSION.RELEASE Die Version des aktuell ausgeführten Android-Systems im für Menschen lesbaren Format. Dieses Feld MUSS einen der in [ Ressourcen, 7 ] definierten Zeichenfolgenwerte haben.
    android.os.Build.VERSION.SDK Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Anwendungscode von Drittanbietern zugreifen kann. Für Android 4.2 MUSS dieses Feld den ganzzahligen Wert 17 haben.
    android.os.Build.VERSION.SDK_INT Die Version des aktuell ausgeführten Android-Systems in einem Format, auf das Anwendungscode von Drittanbietern zugreifen kann. Für Android 4.2 MUSS dieses Feld den ganzzahligen Wert 17 haben.
    android.os.Build.VERSION.INCREMENTAL Ein vom Geräteimplementierer ausgewählter Wert, der den spezifischen Build des aktuell ausgeführten Android-Systems in einem für Menschen lesbaren Format angibt. Dieser Wert DARF NICHT für verschiedene Builds wiederverwendet werden, die Endbenutzern zur Verfügung gestellt werden. Eine typische Verwendung dieses Felds besteht darin, anzugeben, welche Build-Nummer oder welche Quellcodeverwaltungs-Änderungskennung zum Generieren des Builds verwendet wurde. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.
    android.os.Build.BOARD Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische interne Hardware identifiziert, die vom Gerät verwendet wird, in einem für Menschen lesbaren Format. Eine mögliche Verwendung dieses Feldes besteht darin, die spezifische Revision der Platine anzugeben, die das Gerät mit Strom versorgt. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
    android.os.Build.BRAND Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Unternehmens, der Organisation, der Person usw. identifiziert, die das Gerät hergestellt haben, in einem für Menschen lesbaren Format. Eine mögliche Verwendung dieses Feldes besteht darin, den OEM und/oder Netzbetreiber anzugeben, der das Gerät verkauft hat. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
    android.os.Build.CPU_ABI Der Name des Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3: Native API-Kompatibilität .
    android.os.Build.CPU_ABI2 Der Name des zweiten Befehlssatzes (CPU-Typ + ABI-Konvention) des nativen Codes. Siehe Abschnitt 3.3: Native API-Kompatibilität .
    android.os.Build.DEVICE Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Konfiguration oder Revision des Gehäuses (manchmal auch „Industriedesign“ genannt) des Geräts identifiziert. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
    android.os.Build.FINGERPRINT Eine Zeichenfolge, die diesen Build eindeutig identifiziert. Es SOLLTE für Menschen einigermaßen lesbar sein. Es MUSS dieser Vorlage folgen:
    $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
    Zum Beispiel:
    acme/mydevice/generic:4.2/JRN53/3359:userdebug/test-keys
    Der Fingerabdruck DARF KEINE Leerzeichen enthalten. Wenn andere in der obigen Vorlage enthaltene Felder Leerzeichen enthalten, MÜSSEN diese im Build-Fingerabdruck durch ein anderes Zeichen ersetzt werden, beispielsweise durch den Unterstrich („_“). Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein.
    android.os.Build.HARDWARE Der Name der Hardware (von der Kernel-Befehlszeile oder /proc). Es SOLLTE für Menschen einigermaßen lesbar sein. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
    android.os.Build.HOST Eine Zeichenfolge, die den Host, auf dem der Build erstellt wurde, in einem für Menschen lesbaren Format eindeutig identifiziert. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.
    android.os.Build.ID Eine vom Geräteimplementierer ausgewählte Kennung, um auf eine bestimmte Version in einem für Menschen lesbaren Format zu verweisen. Dieses Feld kann mit android.os.Build.VERSION.INCREMENTAL identisch sein, SOLLTE jedoch ein ausreichend aussagekräftiger Wert sein, damit Endbenutzer zwischen Software-Builds unterscheiden können. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
    android.os.Build.MANUFACTURER Der Handelsname des Originalgeräteherstellers (OEM) des Produkts. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.
    android.os.Build.MODEL Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält, wie er dem Endbenutzer bekannt ist. Dies SOLLTE derselbe Name sein, unter dem das Gerät vermarktet und an Endbenutzer verkauft wird. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.
    android.os.Build.PRODUCT Ein vom Geräteimplementierer ausgewählter Wert, der den Entwicklungsnamen oder Codenamen des Produkts (SKU) enthält. MUSS für Menschen lesbar sein, ist aber nicht unbedingt für die Anzeige durch Endbenutzer gedacht. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
    android.os.Build.SERIAL Eine Hardware-Seriennummer, falls verfügbar. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck "^([a-zA-Z0-9]{0,20})$" übereinstimmen.
    android.os.Build.TAGS Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt wurden und den Build weiter unterscheiden. Beispiel: „unsigned,debug“. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
    android.os.Build.TIME Ein Wert, der den Zeitstempel des Buildvorgangs darstellt.
    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 typischen Android-Laufzeitkonfigurationen entsprechen: „user“, „userdebug“ oder „eng“. Der Wert dieses Feldes MUSS als 7-Bit-ASCII kodierbar sein und mit dem regulären Ausdruck "^[a-zA-Z0-9.,_-]+$" übereinstimmen.
    android.os.Build.USER Ein Name oder eine Benutzer-ID des Benutzers (oder automatisierten Benutzers), der den Build generiert hat. Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es NICHT NULL oder eine leere Zeichenfolge („“) sein darf.

    3.2.3. Absichtskompatibilität

    Geräteimplementierungen MÜSSEN das lose Kopplungs-Intent-System von Android berücksichtigen, wie in den folgenden Abschnitten beschrieben. 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 Kontakte, Kalender, Fotogalerie, 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
    • Kontakte
    • Galerie
    • GlobalSearch
    • Startprogramm
    • Musik
    • Einstellungen

    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 Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierungen zulassen, dass jedes in Abschnitt 3.2.3.2 genannte Absichtsmuster durch Anwendungen von Drittanbietern überschrieben wird. Die Upstream-Android-Open-Source-Implementierung ermöglicht 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.

    Allerdings stellen Geräteimplementierungen möglicherweise Standardaktivitäten für bestimmte URI-Muster bereit (z. B. http://play.google.com), wenn die Standardaktivität einen spezifischeren Filter für den Daten-URI bereitstellt. Beispielsweise ist ein Absichtsfilter, der den Daten-URI „http://www.android.com“ angibt, spezifischer als der Browserfilter für „http://“. Geräteimplementierungen MÜSSEN eine Benutzeroberfläche bereitstellen, über die Benutzer die Standardaktivität für Absichten ändern können.

    3.2.3.3. Absichts-Namespaces

    Geräteimplementierungen 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.* oder com.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. Geräteimplementierungen KÖNNEN Absichtsmuster enthalten, die Namespaces verwenden, die eindeutig und offensichtlich mit ihrer eigenen Organisation verknüpft sind.

    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

    3.3.1 Binäre Anwendungsschnittstellen

    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. Da nativer Code stark von der zugrunde liegenden Prozessortechnologie abhängt, definiert Android im Android NDK in der Datei docs/CPU-ARCH-ABIS.html eine Reihe von Application Binary Interfaces (ABIs). Wenn eine Geräteimplementierung mit einem oder mehreren definierten ABIs kompatibel ist, SOLLTE sie die Kompatibilität mit dem Android NDK implementieren, wie unten beschrieben.

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

    • MUSS 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.
    • MUSS mit jeder erforderlichen Bibliothek in der Liste unten quellkompatibel (dh Header-kompatibel) und binärkompatibel (für das ABI) sein
    • MUSS die vom Gerät unterstützte native Application Binary Interface (ABI) über die android.os.Build.CPU_ABI -API genau melden
    • Es MÜSSEN nur die ABIs gemeldet werden, die in der neuesten Version des Android NDK in der Datei docs/CPU-ARCH-ABIS.txt dokumentiert sind
    • SOLLTE unter Verwendung des Quellcodes und der Header-Dateien erstellt werden, die im Upstream-Android-Open-Source-Projekt verfügbar sind

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

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

    Beachten Sie, dass zukünftige Versionen des Android NDK möglicherweise Unterstützung für zusätzliche ABIs einführen. Wenn eine Geräteimplementierung nicht mit einem vorhandenen vordefinierten ABI kompatibel ist, DARF sie überhaupt keine Unterstützung für ein ABI melden.

    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

    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 der Geräteimplementierungen MÜSSEN auf dem 534.30 WebKit-Build aus dem Upstream-Android-Open-Source-Baum für Android 4.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/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30
      • 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
      • Bei Geräteimplementierungen kann Mobile in der Benutzeragentenzeichenfolge weggelassen werden

    Die WebView-Komponente SOLLTE so viel HTML5 [ Ressourcen, 11 ] wie möglich unterstützen. Geräteimplementierungen MÜSSEN mindestens jede dieser mit HTML5 in der WebView verknüpften APIs unterstützen:

    Darüber hinaus MÜSSEN Geräteimplementierungen die HTML5/W3C-Webstorage-API [ Ressourcen, 15 ] unterstützen und SOLLTEN die HTML5/W3C-IndexedDB-API [ Ressourcen, 16 ] unterstützen. Beachten Sie, dass IndexedDB voraussichtlich eine erforderliche Komponente in einer zukünftigen Version von Android wird, da die Standardisierungsgremien für die Webentwicklung IndexedDB gegenüber Webstorage bevorzugen.

    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 verwendet 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, 11 ] unterstützen. Geräteimplementierungen MÜSSEN mindestens jede dieser mit HTML5 verbundenen APIs unterstützen:

    Darüber hinaus MÜSSEN Geräteimplementierungen die HTML5/W3C-Webstorage-API [ Ressourcen, 15 ] unterstützen und SOLLTEN die HTML5/W3C-IndexedDB-API [ Ressourcen, 16 ] unterstützen. Beachten Sie, dass IndexedDB voraussichtlich eine erforderliche Komponente in einer zukünftigen Version von Android wird, da die Standardisierungsgremien für die Webentwicklung IndexedDB gegenüber Webstorage bevorzugen.

    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 Semantik eines Standard-Intents 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 Standardberechtigung NICHT ändern

    Die obige Liste ist nicht vollständig. 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. 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.

    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 nicht mit der „@hide“-Markierung versehen ist, wie sie im ursprünglichen Android-Quellcode verwendet wird. 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 eine Geräteimplementierung außerdem benutzerdefinierte APIs außerhalb des standardmäßigen Android-Namespace enthält, MÜSSEN diese APIs in einer gemeinsam genutzten Android-Bibliothek gepackt werden, sodass nur Apps, die sie explizit verwenden (über den <uses-library> -Mechanismus), von der erhöhten Speichernutzung betroffen sind solcher APIs.

    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, 17 ].

    Geräteimplementierungen MÜSSEN Dalvik so konfigurieren, dass Speicher entsprechend der Upstream-Android-Plattform und wie in der folgenden Tabelle angegeben zugewiesen wird. (Definitionen zu Bildschirmgröße und Bildschirmdichte finden Sie in Abschnitt 7.1.1 .)

    Beachten Sie, dass die unten angegebenen Speicherwerte als Mindestwerte gelten und Geräteimplementierungen möglicherweise mehr Speicher pro Anwendung zuweisen.

    Bildschirmgröße Bildschirmdichte Anwendungsspeicher
    klein / normal / groß ldpi / mdpi 16 MB
    klein / normal / groß tvdpi / hdpi 32 MB
    klein / normal / groß xhdpi 64 MB
    xlarge mdpi 32 MB
    xlarge tvdpi / hdpi 64 MB
    xlarge xhdpi 128 MB

    3.8. Kompatibilität der Benutzeroberfläche

    3.8.1. Widgets

    Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, die es Anwendungen ermöglichen, dem Endbenutzer ein „AppWidget“ zur Verfügung zu stellen [ Ressourcen, 18 ]. Die Android Open Source-Referenzversion enthält eine Launcher-Anwendung mit Benutzeroberflächenfunktionen, die es dem Benutzer ermöglichen, AppWidgets zum Startbildschirm hinzuzufügen, anzuzeigen und zu entfernen.

    Geräteimplementierungen können eine Alternative zum Referenz-Launcher (z. B. Startbildschirm) ersetzen. Alternative Launcher SOLLTEN eine integrierte Unterstützung für AppWidgets beinhalten und die Möglichkeiten der Benutzeroberfläche offenlegen, 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 die Geräteimplementierung 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.

    Geräteimplementierungen MÜSSEN in der Lage sein, Widgets mit einer Größe von 4 x 4 in der Standardrastergröße darzustellen. (Weitere Informationen finden Sie in den App Widget Design Guidelines in der Android SDK-Dokumentation [ Ressourcen, 18 ].

    3.8.2. Benachrichtigungen

    Android enthält APIs, die es Entwicklern ermöglichen, Benutzer über wichtige Ereignisse zu benachrichtigen [ Ressourcen, 19 ], indem sie Hardware- und Softwarefunktionen des Geräts nutzen.

    Einige APIs ermöglichen es Anwendungen, Benachrichtigungen durchzuführen oder mithilfe von Hardware, insbesondere Ton, Vibration und Licht, Aufmerksamkeit zu erregen. Geräteimplementierungen MÜSSEN Benachrichtigungen unterstützen, die Hardwarefunktionen nutzen, wie in der SDK-Dokumentation beschrieben, und soweit dies mit der Geräteimplementierungshardware möglich ist. Wenn eine Geräteimplementierung beispielsweise einen Vibrator umfasst, MUSS sie die Vibrations-APIs korrekt implementieren. Wenn einer Geräteimplementierung Hardware fehlt, MÜSSEN die entsprechenden APIs als No-Ops implementiert werden. Beachten Sie, dass dieses Verhalten in Abschnitt 7 ausführlicher beschrieben wird.

    Darüber hinaus MUSS die Implementierung alle in den APIs [ Ressourcen, 20 ] oder im Stilleitfaden für Status-/Systemleistensymbole [ Ressourcen, 21 ] 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.

    Android 4.2 bietet Unterstützung für umfangreiche Benachrichtigungen, beispielsweise interaktive Ansichten für laufende Benachrichtigungen. Geräteimplementierungen MÜSSEN umfangreiche Benachrichtigungen ordnungsgemäß anzeigen und ausführen, wie in den Android-APIs dokumentiert.

    Android enthält APIs [ Ressourcen, 22 ], 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.

    3.8.4. Toasts

    Anwendungen können die „Toast“-API (definiert in [ Ressourcen, 23 ]) 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. Themen

    Android bietet „Themen“ als Mechanismus für Anwendungen, um Stile auf eine gesamte Aktivität oder Anwendung anzuwenden. Android 4.2 enthält ein „Holo“- oder „holographisches“ Design als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Erscheinungsbild des Holo-Designs wie im Android SDK definiert anpassen möchten [ Ressourcen, 24 ]. Geräteimplementierungen DÜRFEN KEINE der Holo-Designattribute ändern, die Anwendungen zur Verfügung gestellt werden [ Ressourcen, 25 ].

    Android 4.2 enthält ein neues „Device Default“-Design als eine Reihe definierter Stile, die Anwendungsentwickler verwenden können, wenn sie das Erscheinungsbild des vom Geräteimplementierer definierten Gerätedesigns anpassen möchten. Geräteimplementierungen KÖNNEN die DeviceDefault-Designattribute ändern, die Anwendungen zur Verfügung gestellt werden [ Ressourcen, 25 ].

    3.8.6. Live-Hintergründe

    Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, der es Anwendungen ermöglicht, dem Endbenutzer ein oder mehrere „Live-Hintergründe“ anzuzeigen [ Ressourcen, 26 ]. 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.

    3.8.7. Aktuelle Anwendungsanzeige

    Der Upstream-Quellcode von Android 4.2 enthält eine Benutzeroberfläche zum Anzeigen aktueller Anwendungen mithilfe einer Miniaturansicht des grafischen Zustands der Anwendung zum Zeitpunkt des letzten Verlassens der Anwendung durch den Benutzer. Geräteimplementierungen KÖNNEN diese Benutzeroberfläche ändern oder entfernen; Es ist jedoch geplant, dass eine zukünftige Android-Version diese Funktionalität umfassender nutzt. Bei Geräteimplementierungen wird dringend empfohlen, für neuere Anwendungen die Upstream-Benutzeroberfläche von Android 4.2 (oder eine ähnliche, auf Miniaturansichten basierende Benutzeroberfläche) zu verwenden, andernfalls sind sie möglicherweise nicht mit einer zukünftigen Version von Android kompatibel.

    3.8.8. Eingabeverwaltungseinstellungen

    Android 4.2 bietet Unterstützung für Input Management Engines. Mit den Android 4.2-APIs können benutzerdefinierte App-IMEs vom Benutzer einstellbare Einstellungen festlegen. Geräteimplementierungen MÜSSEN eine Möglichkeit für den Benutzer enthalten, jederzeit auf IME-Einstellungen zuzugreifen, wenn ein IME angezeigt wird, das solche Benutzereinstellungen bereitstellt.

    3.8.9. Sperr- und Startbildschirm-Widgets

    Android 4.2 bietet Unterstützung für Anwendungs-Widgets, die Benutzer in den Startbildschirm oder den Sperrbildschirm einbetten können (Einzelheiten finden Sie in den Designrichtlinien für App-Widgets in der Android SDK-Dokumentation [ Ressourcen, 69 ]). Anwendungs-Widgets ermöglichen den schnellen Zugriff auf Anwendungsdaten und -dienste, ohne eine neue Aktivität zu starten. Widgets erklären die Unterstützung für die Verwendung auf dem Startbildschirm oder dem Sperrbildschirm, indem sie das Manifest-Tag android:widgetCategory deklarieren, das dem System mitteilt, wo das Widget platziert werden kann. Insbesondere MÜSSEN Geräteimplementierungen die folgenden Anforderungen erfüllen.

    • Geräteimplementierungen MÜSSEN Anwendungs-Widgets auf dem Startbildschirm unterstützen.
    • Geräteimplementierungen SOLLTEN den Sperrbildschirm unterstützen. Wenn Geräteimplementierungen Unterstützung für den Sperrbildschirm beinhalten, MÜSSEN Geräteimplementierungen Anwendungs-Widgets auf dem Sperrbildschirm unterstützen.

    3.8.10. Sperrbildschirm-Medienfernbedienung

    Android 4.2 bietet Unterstützung für die Remote Control API, mit der Medienanwendungen in Wiedergabesteuerungen integriert werden können, die in einer Remote-Ansicht wie dem Gerätesperrbildschirm angezeigt werden [ Ressourcen, 74 ]. Geräteimplementierungen MÜSSEN die Einbettung von Fernbedienungen in den Gerätesperrbildschirm unterstützen.

    3.8.11. Träume

    Android 4.2 bietet Unterstützung für interaktive Bildschirmschoner namens Dreams [ Ressourcen, 76 ]. Mit Dreams können Benutzer mit Anwendungen interagieren, wenn ein Ladegerät im Leerlauf ist oder an einer Schreibtischstation angedockt ist. Geräteimplementierungen MÜSSEN Unterstützung für Dreams beinhalten und eine Einstellungsoption für Benutzer zum Konfigurieren von Dreams bereitstellen.

    3.9 Geräteverwaltung

    Android 4.2 enthält Funktionen, die es sicherheitsbewussten Anwendungen ermöglichen, Geräteverwaltungsfunktionen auf Systemebene auszuführen, z. B. die Durchsetzung von Kennwortrichtlinien oder die Durchführung einer Remote-Löschung, über die Android Device Administration API [ Ressourcen, 27 ]. Geräteimplementierungen MÜSSEN eine Implementierung der DevicePolicyManager Klasse [ Ressourcen, 28 ] bereitstellen und SOLLTEN den gesamten Bereich der in der Android SDK-Dokumentation definierten Geräteverwaltungsrichtlinien unterstützen [ Ressourcen, 27 ].

    Hinweis: Während einige der oben beschriebenen Anforderungen für Android 4.2 als „SOLLTEN“ angegeben sind, MÜSSEN Geräteimplementierungen, die den Sperrbildschirm unterstützen, Geräterichtlinien zum Verwalten von Widgets auf dem Sperrbildschirm unterstützen, wie in der Android SDK-Dokumentation [ Ressourcen, 27 ] definiert.

    Hinweis: Während einige der oben genannten Anforderungen für Android 4.2 als „SOLLTEN“ angegeben sind, ist geplant, diese in der Kompatibilitätsdefinition für eine zukünftige Version in „MUSS“ zu ändern. Das heißt, diese Anforderungen sind in Android 4.2 optional, werden aber in einer zukünftigen Version erforderlich sein . Bestehenden und neuen Geräten, auf denen Android 4.2 läuft, wird dringend empfohlen, diese Anforderungen in Android 4.2 zu erfüllen , da sie sonst bei einem Upgrade auf die zukünftige Version nicht die Android-Kompatibilität erreichen können.

    3.10 Barrierefreiheit

    Android 4.2 bietet eine Barrierefreiheitsebene, die Benutzern mit Behinderungen die Navigation auf ihren Geräten erleichtert. Darüber hinaus bietet Android 4.2 Plattform-APIs, die es Implementierungen von Barrierefreiheitsdiensten ermöglichen, Rückrufe für Benutzer- und Systemereignisse zu empfangen und alternative Feedbackmechanismen wie Text-to-Speech, haptisches Feedback und Trackball-/D-Pad-Navigation zu generieren [ Ressourcen, 29 ] . Geräteimplementierungen MÜSSEN eine Implementierung des Android-Barrierefreiheits-Frameworks bereitstellen, die mit der Standard-Android-Implementierung übereinstimmt. Insbesondere MÜSSEN Geräteimplementierungen die folgenden Anforderungen erfüllen.

    • Geräteimplementierungen MÜSSEN Implementierungen von Barrierefreiheitsdiensten von Drittanbietern über die android.accessibilityservice APIs unterstützen [ Ressourcen, 30 ].
    • Geräteimplementierungen MÜSSEN AccessibilityEvents generieren und diese Ereignisse an alle registrierten AccessibilityService Implementierungen in einer mit der Standard-Android-Implementierung konsistenten Weise übermitteln.
    • Geräteimplementierungen MÜSSEN einen für den Benutzer zugänglichen Mechanismus zum Aktivieren und Deaktivieren von Barrierefreiheitsdiensten bereitstellen und diese Schnittstelle als Reaktion auf die Absicht android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS anzeigen.

    Darüber hinaus SOLLTEN Geräteimplementierungen eine Implementierung eines Barrierefreiheitsdienstes auf dem Gerät bereitstellen und einen Mechanismus bereitstellen, mit dem Benutzer den Barrierefreiheitsdienst während der Geräteeinrichtung aktivieren können. Eine Open-Source-Implementierung eines Barrierefreiheitsdienstes ist im Eyes Free-Projekt verfügbar [ Ressourcen, 31 ].

    3.11 Text-to-Speech

    Android 4.2 enthält APIs, die es Anwendungen ermöglichen, Text-to-Speech-Dienste (TTS) zu nutzen, und ermöglicht es Dienstanbietern, Implementierungen von TTS-Diensten bereitzustellen [ Ressourcen, 32 ]. Geräteimplementierungen MÜSSEN diese Anforderungen in Bezug auf das Android TTS-Framework erfüllen:

    • Geräteimplementierungen MÜSSEN die APIs des Android TTS-Frameworks unterstützen und SOLLTEN eine TTS-Engine enthalten, die die auf dem Gerät verfügbaren Sprachen unterstützt. Beachten Sie, dass die Upstream-Android-Open-Source-Software eine TTS-Engine-Implementierung mit vollem Funktionsumfang enthält.
    • Geräteimplementierungen MÜSSEN die Installation von TTS-Engines von Drittanbietern unterstützen.
    • Geräteimplementierungen MÜSSEN eine für den Benutzer zugängliche Schnittstelle bereitstellen, die es Benutzern ermöglicht, eine TTS-Engine für die Verwendung auf Systemebene auszuwählen.

    4. 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, 33 ].

    Geräteimplementierungen DÜRFEN die Formate .apk [ Ressourcen, 34 ], Android Manifest [ Ressourcen, 35 ], Dalvik-Bytecode [ Ressourcen, 17 ] oder Renderscript-Bytecode NICHT in einer Weise erweitern, die verhindern würde, dass diese Dateien ordnungsgemäß installiert und ausgeführt werden andere kompatible Geräte. Geräteimplementierer SOLLTEN die Referenz-Upstream-Implementierung von Dalvik und das Paketverwaltungssystem der Referenzimplementierung verwenden.

    5. Multimedia-Kompatibilität

    Geräteimplementierungen MÜSSEN mindestens eine Form der Audioausgabe umfassen, z. B. Lautsprecher, Kopfhöreranschluss, externer Lautsprecheranschluss usw.

    5.1. Mediencodecs

    Geräteimplementierungen MÜSSEN die in der Android SDK-Dokumentation [ Ressourcen, 58 ] angegebenen Kernmedienformate unterstützen, sofern dies in diesem Dokument nicht ausdrücklich gestattet ist. Insbesondere MÜSSEN Geräteimplementierungen die in den folgenden Tabellen definierten Medienformate, Encoder, Decoder, Dateitypen und Containerformate unterstützen. Alle diese Codecs werden als Software-Implementierungen in der bevorzugten Android-Implementierung des Android Open Source Project bereitgestellt.

    Bitte beachten Sie, dass weder Google noch die Open Handset Alliance garantieren, dass diese Codecs nicht durch Patente Dritter belastet sind. Diejenigen, die beabsichtigen, diesen Quellcode in Hardware- oder Softwareprodukten zu verwenden, werden darauf hingewiesen, dass für Implementierungen dieses Codes, einschließlich in Open-Source-Software oder Shareware, möglicherweise Patentlizenzen der jeweiligen Patentinhaber erforderlich sind.

    Beachten Sie, dass in diesen Tabellen keine spezifischen Bitratenanforderungen für die meisten Videocodecs aufgeführt sind, da die aktuelle Gerätehardware nicht unbedingt Bitraten unterstützt, die genau den erforderlichen Bitraten entsprechen, die in den relevanten Standards angegeben sind. Stattdessen SOLLTEN Geräteimplementierungen die höchstmögliche Bitrate auf der Hardware unterstützen, bis zu den in den Spezifikationen definierten Grenzen.

    Typ Format / Codec Encoder Decoder Einzelheiten Dateityp(en)/Containerformate
    Audio MPEG-4 AAC-Profil (AAC LC) ERFORDERLICH
    Erforderlich für Geräteimplementierungen, die Mikrofonhardware umfassen und android.hardware.microphone definieren.
    ERFORDERLICH Unterstützung für Mono/Stereo/5.0/5.1*-Inhalte mit Standard-Abtastraten von 8 bis 48 kHz.
    • 3GPP (.3gp)
    • MPEG-4 (.mp4, .m4a)
    • ADTS Raw AAC (.aac, Dekodierung in Android 3.1+, Kodierung in Android 4.0+, ADIF nicht unterstützt)
    • MPEG-TS (.ts, nicht durchsuchbar, Android 3.0+)
    MPEG-4 HE AAC-Profil (AAC+) ERFORDERLICH für Geräteimplementierungen, die Mikrofonhardware umfassen und android.hardware.microphone definieren ERFORDERLICH Unterstützung für Mono/Stereo/5.0/5.1*-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.
    MPEG-4 HE AAC v2-Profil (erweitertes AAC+) ERFORDERLICH Unterstützung für Mono/Stereo/5.0/5.1*-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.
    MPEG-4-Audioobjekttyp ER AAC ELD (Enhanced Low Delay AAC) ERFORDERLICH für Geräteimplementierungen, die Mikrofonhardware umfassen und android.hardware.microphone definieren ERFORDERLICH Unterstützung für Mono-/Stereo-Inhalte mit Standard-Abtastraten von 16 bis 48 kHz.
    AMR-NB ERFORDERLICH
    Erforderlich für Geräteimplementierungen, die Mikrofonhardware umfassen und android.hardware.microphone definieren.
    ERFORDERLICH 4,75 bis 12,2 kbps abgetastet bei 8 kHz 3GPP (.3gp)
    AMR-WB ERFORDERLICH
    Erforderlich für Geräteimplementierungen, die Mikrofonhardware umfassen und android.hardware.microphone definieren.
    ERFORDERLICH 9 Raten von 6,60 kbit/s bis 23,85 kbit/s, abgetastet bei 16 kHz 3GPP (.3gp)
    FLAC ERFORDERLICH
    (Android 3.1+)
    Mono/Stereo (kein Mehrkanal). Abtastraten bis zu 48 kHz (bei Geräten mit 44,1-kHz-Ausgang werden jedoch bis zu 44,1 kHz empfohlen, da der Downsampler von 48 auf 44,1 kHz keinen Tiefpassfilter enthält). 16-Bit empfohlen; Für 24-Bit wurde kein Dither angewendet. Nur FLAC (.flac).
    MP3 ERFORDERLICH Mono/Stereo 8-320 Kbit/s konstante (CBR) oder variable Bitrate (VBR) MP3 (.mp3)
    MIDI ERFORDERLICH MIDI Typ 0 und 1. DLS Version 1 und 2. XMF und Mobile XMF. Unterstützung für die Klingeltonformate RTTTL/RTX, OTA und iMelody
    • Geben Sie 0 und 1 ein (.mid, .xmf, .mxmf)
    • RTTTL/RTX (.rtttl, .rtx)
    • OTA (.ota)
    • iMelody (.imy)
    Vorbis ERFORDERLICH
    • Ogg (.ogg)
    • Matroska (.mkv)
    PCM/WAVE ERFORDERLICH ERFORDERLICH 8-Bit- und 16-Bit-Linear-PCM** (Raten bis zur Grenze der Hardware). Geräte MÜSSEN Abtastraten für Roh-PCM-Aufzeichnung bei den Frequenzen 8000, 16000 und 44100 Hz unterstützen WELLE (.wav)
    Bild JPEG ERFORDERLICH ERFORDERLICH Basis+progressiv JPEG (.jpg)
    GIF ERFORDERLICH GIF (.gif)
    PNG ERFORDERLICH ERFORDERLICH PNG (.png)
    BMP ERFORDERLICH BMP (.bmp)
    WEBP ERFORDERLICH ERFORDERLICH WebP (.webp)
    Video H.263 ERFORDERLICH
    Erforderlich für Geräteimplementierungen, die Kamerahardware umfassen und android.hardware.camera oder android.hardware.camera.front definieren.
    ERFORDERLICH
    • 3GPP (.3gp)
    • MPEG-4 (.mp4)
    H.264 AVC ERFORDERLICH
    Erforderlich für Geräteimplementierungen, die Kamerahardware umfassen und android.hardware.camera oder android.hardware.camera.front definieren.
    ERFORDERLICH Basisprofil (BP)
    • 3GPP (.3gp)
    • MPEG-4 (.mp4)
    • MPEG-TS (.ts, nur AAC-Audio, nicht suchbar, Android 3.0+)
    MPEG-4 SP ERFORDERLICH 3GPP (.3gp)
    VP8 ERFORDERLICH
    (Android 2.3.3+)
    WebM (.webm) und Matroska (.mkv, Android 4.0+)
    *Hinweis: Es ist nur ein Downmix von 5.0/5.1-Inhalten erforderlich; Das Aufzeichnen oder Rendern von mehr als 2 Kanälen ist optional. **Hinweis: Eine lineare 16-Bit-PCM-Erfassung ist obligatorisch. Eine lineare 8-Bit-PCM-Erfassung ist nicht zwingend erforderlich.

    5.2 Videokodierung

    Android-Geräteimplementierungen, die eine nach hinten gerichtete Kamera enthalten und android.hardware.camera deklarieren, SOLLTEN die folgenden Videokodierungsprofile unterstützen.

    SD (Geringe Qualität) SD (Hohe Qualität) HD (sofern von der Hardware unterstützt)
    Video-Codec H.264-Basisprofil H.264-Basisprofil H.264-Basisprofil
    Video Auflösung 176 x 144 Pixel 480 x 360 Pixel 1280 x 720 Pixel
    Video-Bildrate 12 fps 30 fps 30 fps
    Video-Bitrate 56 Kbit/s 500 Kbit/s oder höher 2 Mbit/s oder höher
    Audio-Codec AAC-LC AAC-LC AAC-LC
    Audiokanäle 1 (Mono) 2 (Stereo) 2 (Stereo)
    Audio Bitrate 24 Kbit/s 128 Kbit/s 192 Kbit/s

    5.3 Videodekodierung

    Android-Geräteimplementierungen SOLLTEN die folgenden VP8-Videodekodierungsprofile unterstützen.

    SD (Geringe Qualität) SD (Hohe Qualität) HD 720p
    (Wenn von der Hardware unterstützt)
    HD 1080p
    (Wenn von der Hardware unterstützt)
    Video Auflösung 320 x 180 Pixel 640 x 360 Pixel 1280 x 720 Pixel 1920 x 1080 Pixel
    Video-Bildrate 30 fps 30 fps 30 fps 30 fps
    Video-Bitrate 800 Kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

    5.4. Audio Aufnahme

    Wenn eine Anwendung die android.media.AudioRecord API verwendet hat, um mit der Aufzeichnung eines Audiostreams zu beginnen, MÜSSEN Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone deklarieren, Audio mit jedem dieser Verhaltensweisen abtasten und aufzeichnen:

    • Das Gerät SOLLTE eine annähernd flache Amplituden-Frequenz-Charakteristik aufweisen; insbesondere ±3 dB, von 100 Hz bis 4000 Hz
    • Die Audioeingangsempfindlichkeit SOLLTE so eingestellt werden, dass eine Quelle mit einem Schallleistungspegel (SPL) von 90 dB bei 1000 Hz einen RMS von 2500 für 16-Bit-Samples ergibt.
    • PCM-Amplitudenpegel SOLLTEN Änderungen des Eingangs-Schalldruckpegels über mindestens einen 30-dB-Bereich von -18 dB bis +12 dB bei einem Schalldruckpegel von 90 dB am Mikrofon linear verfolgen.
    • Die gesamte harmonische Verzerrung SOLLTE bei 1 kHz und 90 dB SPL-Eingangspegel weniger als 1 % betragen.

    Wenn eine Anwendung zusätzlich zu den oben genannten Aufzeichnungsspezifikationen mit der Aufzeichnung eines Audiostreams mithilfe der Audioquelle android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION begonnen hat:

    • Die Rauschunterdrückungsverarbeitung MUSS, falls vorhanden, deaktiviert werden.
    • Falls vorhanden, MUSS die automatische Verstärkungsregelung deaktiviert werden.

    Hinweis: Während einige der oben genannten Anforderungen für Android 4.2 als „SOLLTEN“ angegeben sind, ist geplant, diese in der Kompatibilitätsdefinition für eine zukünftige Version in „MUSS“ zu ändern. Das heißt, diese Anforderungen sind in Android 4.2 optional, werden aber in einer zukünftigen Version erforderlich sein . Bestehenden und neuen Geräten, auf denen Android 4.2 läuft, wird dringend empfohlen, diese Anforderungen in Android 4.2 zu erfüllen , da sie sonst bei einem Upgrade auf die zukünftige Version nicht die Android-Kompatibilität erreichen können.

    5.5. Audiolatenz

    Unter Audiolatenz versteht man die Zeitverzögerung, während ein Audiosignal ein System durchläuft. Viele Anwendungsklassen sind auf kurze Latenzen angewiesen, um Echtzeiteffekte wie Soundeffekte oder VOIP-Kommunikation zu erzielen.

    Für die Zwecke dieses Abschnitts:

    • „Ausgabelatenz“ ist definiert als das Intervall zwischen dem Schreiben eines Frames PCM-codierter Daten durch eine Anwendung und dem Zeitpunkt, an dem der entsprechende Ton von einem externen Zuhörer gehört oder von einem Wandler beobachtet werden kann
    • „kalte Ausgabelatenz“ ist definiert als die Ausgabelatenz für den ersten Frame, wenn das Audioausgabesystem vor der Anforderung im Leerlauf war und ausgeschaltet wurde
    • „Kontinuierliche Ausgabelatenz“ ist definiert als die Ausgabelatenz für nachfolgende Frames, nachdem das Gerät bereits Audio abspielt
    • „Eingabelatenz“ ist die Zeitspanne zwischen der Präsentation eines externen Tons auf dem Gerät und dem Lesen des entsprechenden Frames PCM-codierter Daten durch eine Anwendung
    • „Cold-Input-Latenz“ ist definiert als die Summe der verlorenen Eingabezeit und der Eingabelatenz für den ersten Frame, wenn das Audio-Eingabesystem vor der Anforderung im Leerlauf war und ausgeschaltet war
    • „Kontinuierliche Eingabelatenz“ ist definiert als die Eingabelatenz für nachfolgende Frames, während das Gerät bereits Audio aufnimmt
    • „OpenSL ES PCM-Pufferwarteschlangen-API“ ist der Satz PCM-bezogener OpenSL ES-APIs innerhalb von Android NDK; siehe NDK_root /docs/opensles/index.html

    Gemäß Abschnitt 5 MÜSSEN alle kompatiblen Geräteimplementierungen mindestens eine Form der Audioausgabe umfassen. Geräteimplementierungen SOLLTEN diese Anforderungen an die Ausgabelatenz erfüllen oder übertreffen:

    • Kaltausgabelatenz von 100 Millisekunden oder weniger
    • Kontinuierliche Ausgabelatenz von 45 Millisekunden oder weniger

    Wenn eine Geräteimplementierung nach einer anfänglichen Kalibrierung bei Verwendung der OpenSL ES PCM-Pufferwarteschlangen-API die Anforderungen dieses Abschnitts für kontinuierliche Ausgabelatenz und Kaltausgabelatenz über mindestens ein unterstütztes Audioausgabegerät erfüllt, kann sie möglicherweise Unterstützung für Audio mit niedriger Latenz melden , indem die Funktion „android.hardware.audio.low-latency“ über die Klasse android.content.pm.PackageManager gemeldet wird. [ Ressourcen, 37 ] Wenn die Geräteimplementierung diese Anforderungen hingegen nicht erfüllt, DARF sie KEINE Unterstützung für Audio mit geringer Latenz melden.

    Gemäß Abschnitt 7.2.5 kann bei Geräteimplementierungen auf Mikrofonhardware verzichtet werden.

    Geräteimplementierungen, die Mikrofonhardware enthalten und android.hardware.microphone deklarieren, SOLLTEN diese Anforderungen an die Latenz der Eingabeaudio erfüllen:

    • Kalte Eingabelatenz von 100 Millisekunden oder weniger
    • Kontinuierliche Eingabelatenz von 50 Millisekunden oder weniger

    5.6. Netzwerkprotokolle

    Geräte MÜSSEN die Mediennetzwerkprotokolle für die Audio- und Videowiedergabe unterstützen, wie in der Android SDK-Dokumentation [ Ressourcen, 58 ] angegeben. Insbesondere MÜSSEN Geräte die folgenden Mediennetzwerkprotokolle unterstützen:

    • RTSP (RTP, SDP)
    • Progressives HTTP(S)-Streaming
    • HTTP(S)-Live-Streaming-Protokollentwurf, Version 3 [ Ressourcen, 59 ]

    6. Kompatibilität von Entwicklertools und -optionen

    6.1 Entwicklertools

    Geräteimplementierungen MÜSSEN die im Android SDK bereitgestellten Android Developer Tools unterstützen. Insbesondere MÜSSEN Android-kompatible Geräte kompatibel sein mit:

    • Android Debug Bridge (bekannt als adb) [ Ressourcen, 33 ]
      Geräteimplementierungen MÜSSEN alle adb Funktionen unterstützen, wie im Android SDK dokumentiert. Der geräteseitige adb Daemon MUSS standardmäßig inaktiv sein und es MUSS einen für den Benutzer zugänglichen Mechanismus zum Aktivieren der Android Debug Bridge geben.
    • Android 4.2.2 bietet Unterstützung für Secure ADB. Secure ADB aktiviert ADB auf bekannten authentifizierten Hosts. Bestehenden und neuen Geräten, auf denen Android 4.2.2 ausgeführt wird, wird dringend empfohlen, diese Anforderung in Android 4.2 zu erfüllen , da sie sonst bei einem Upgrade auf die zukünftige Version nicht die Android-Kompatibilität erreichen können.

    • Dalvik Debug Monitor Service (bekannt als ddms) [ Ressourcen, 33 ]
      Geräteimplementierungen MÜSSEN alle im Android SDK dokumentierten ddms Funktionen unterstützen. Da ddms adb verwendet, SOLLTE die Unterstützung für ddms standardmäßig inaktiv sein, MUSS jedoch immer dann unterstützt werden, wenn der Benutzer die Android Debug Bridge wie oben aktiviert hat.
    • Affe [ Ressourcen, 36 ]
      Geräteimplementierungen MÜSSEN das Monkey-Framework enthalten und es für die Verwendung durch Anwendungen verfügbar machen.
    • SysTrace [ Ressourcen, 33 ]
      Geräteimplementierungen MÜSSEN das Systrace-Tool unterstützen, wie im Android SDK dokumentiert. Systrace muss standardmäßig inaktiv sein und es MUSS einen für den Benutzer zugänglichen Mechanismus zum Aktivieren von Systrace geben.

    Die meisten Linux-basierten Systeme und Apple Macintosh-Systeme erkennen Android-Geräte mithilfe der Standard-Android-SDK-Tools ohne zusätzliche Unterstützung. Allerdings benötigen Microsoft Windows-Systeme normalerweise einen Treiber für neue Android-Geräte. (Beispielsweise erfordern neue Hersteller-IDs und manchmal auch neue Geräte-IDs benutzerdefinierte USB-Treiber für Windows-Systeme.) Wenn eine Geräteimplementierung vom adb Tool, wie im Standard-Android-SDK bereitgestellt, nicht erkannt wird, MÜSSEN Geräteimplementierer Windows-Treiber bereitstellen, mit denen Entwickler eine Verbindung herstellen können Das Gerät verwendet das adb Protokoll. Diese Treiber MÜSSEN für Windows XP, Windows Vista, Windows 7 und Windows 8 sowohl in der 32-Bit- als auch in der 64-Bit-Version bereitgestellt werden.

    6.2 Entwickleroptionen

    Android 4.2 unterstützt Entwickler beim Konfigurieren von Einstellungen für die Anwendungsentwicklung. Geräteimplementierungen MÜSSEN die Absicht android.settings.APPLICATION_DEVELOPMENT_SETTINGS berücksichtigen, um anwendungsentwicklungsbezogene Einstellungen anzuzeigen [ Ressourcen, 77 ]. Die Upstream-Android-Implementierung verbirgt standardmäßig das Menü „Entwickleroptionen“ und ermöglicht es Benutzern, die Entwickleroptionen zu starten, nachdem sie sieben (7) Mal auf den Menüpunkt „Einstellungen“ > „Über Gerät“ > „Build-Nummer“ gedrückt haben. Geräteimplementierungen MÜSSEN eine konsistente Erfahrung für Entwickleroptionen bieten. Insbesondere MÜSSEN Geräteimplementierungen Entwickleroptionen standardmäßig ausblenden und einen Mechanismus zum Aktivieren von Entwickleroptionen bereitstellen, der mit der Upstream-Android-Implementierung konsistent ist.

    7. Hardwarekompatibilität

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

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

    Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten, ist die Telefonie-API: Auch auf Nicht-Telefongeräten müssen diese APIs als sinnvolle No-Ops-Lösungen implementiert werden.

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

    7.1. Anzeige und Grafiken

    Android 4.2 umfasst Funktionen, die Anwendungsressourcen und UI-Layouts automatisch entsprechend dem Gerät anpassen, um sicherzustellen, dass Anwendungen von Drittanbietern auf einer Vielzahl von Hardwarekonfigurationen gut laufen [ Ressourcen, 38 ]. Geräte MÜSSEN diese APIs und Verhaltensweisen ordnungsgemäß implementieren, wie in diesem Abschnitt beschrieben.

    Die Einheiten, auf die sich die Anforderungen in diesem Abschnitt beziehen, sind wie folgt definiert:

    • „Physikalische Diagonalgröße“ ist der Abstand in Zoll zwischen zwei gegenüberliegenden Ecken des beleuchteten Teils des Displays.
    • „dpi“ (bedeutet „Punkte pro Zoll“) ist die Anzahl der Pixel, die von einer linearen horizontalen oder vertikalen Spanne von 1“ umfasst werden. Wenn dpi-Werte aufgeführt sind, müssen sowohl horizontale als auch vertikale dpi innerhalb des Bereichs liegen.
    • „Seitenverhältnis“ ist das Verhältnis der längeren Abmessung des Bildschirms zur kürzeren Abmessung. Beispielsweise wäre eine Anzeige mit 480 x 854 Pixeln 854 / 480 = 1,779, also ungefähr „16:9“.
    • Ein „dichteunabhängiges Pixel“ oder („dp“) ist die virtuelle Pixeleinheit, normalisiert auf einen 160-dpi-Bildschirm, berechnet als: pixels = dps * (density / 160) .

    7.1.1. Bildschirmkonfiguration

    Bildschirmgröße

    Das Android-UI-Framework unterstützt eine Vielzahl verschiedener Bildschirmgrößen und ermöglicht Anwendungen, die Bildschirmgröße des Geräts (auch „Bildschirmlayout“) über android.content.res.Configuration.screenLayout mit SCREENLAYOUT_SIZE_MASK abzufragen. Geräteimplementierungen müssen die korrekte Bildschirmgröße gemäß der Android SDK -Dokumentation [ Ressourcen, 38 ] melden und von der vorgelagerten Android -Plattform ermittelt werden. Insbesondere müssen Geräteimplementierungen die korrekte Bildschirmgröße gemäß den folgenden logischen dichteunabhängigen Pixel-Bildschirmabmessungen (DP) melden.

    • Geräte müssen Bildschirmgrößen von mindestens 426 dp x 320 dp haben ('klein')
    • Geräte, die die Bildschirmgröße 'Normal' melden
    • Geräte, die die Bildschirmgröße 'groß' melden, müssen Bildschirmgrößen von mindestens 640 dp x 480 dp haben
    • Geräte, die die Bildschirmgröße 'Xlarge' melden, müssen Bildschirmgrößen von mindestens 960 dp x 720 dp haben

    Darüber hinaus müssen Geräte Bildschirmgrößen von mindestens 2,5 Zoll in physikalischer diagonaler Größe haben.

    Geräte dürfen ihre gemeldete Bildschirmgröße zu keinem Zeitpunkt ändern.

    Anwendungen geben optional an, 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, normale, große und xlarge -Bildschirme korrekt ehren, wie in der Android SDK -Dokumentation beschrieben.

    Bildschirmseitenverhältnis

    Das Seitenverhältnis muss zwischen 1,3333 (4: 3) und 1,85 (16: 9) liegen.

    Bildschirmdichte

    Das Android UI Framework definiert eine Reihe von logischen Standarddichten, um Anwendungsentwickler bei den Anwendungsressourcen zu unterstützen. Geräteimplementierungen müssen eine der folgenden logischen Android -Framework -Dichten über die APIs android.util.DisplayMetrics melden und müssen Anwendungen bei dieser Standarddichte ausführen.

    • 120 dpi, bekannt als "LDPI"
    • 160 dpi, bekannt als 'MDPI'
    • 213 DPI, bekannt als "TVDPI"
    • 240 dpi, bekannt als 'HDPI'
    • 320 DPI, bekannt als "xhdpi"
    • 480 dpi, bekannt als "xxhdpi"
    Geräteimplementierungen sollten die Standard -Android -Framework -Dichte definieren, die der physikalischen Dichte des Bildschirms numerisch am nächsten ist, es sei denn, diese logische Dichte drückt die gemeldete Bildschirmgröße unter den unterstützten Minimum. Wenn die Standard -Android -Framework -Dichte, die der physikalischen Dichte numerisch am nächsten ist, zu einer Bildschirmgröße führt, die kleiner als die kleinste unterstützte kompatible Bildschirmgröße (320 DP -Breite) ist, sollten die Geräteimplementierungen die nächstniedrigste Android -Framework -Dichte der Android -Framework angeben.

    7.1.2. Messwerte anzeigen

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

    7.1.3. Bildschirmausrichtung

    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.

    Geräte dürfen beim Ändern der Orientierung die gemeldete Bildschirmgröße oder -dichte nicht ändern.

    Geräte müssen melden, welche Bildschirmorientierungen sie unterstützen ( android.hardware.screen.portrait und/oder android.hardware.screen.landscape ) und müssen mindestens eine unterstützte Orientierung melden. Beispielsweise darf ein Gerät mit einem festen Landschaftsbildschirm wie einem Fernseher oder Laptop nur android.hardware.screen.landscape melden.

    7.1.4. 2D- und 3D-Grafikbeschleunigung

    Die Geräteimplementierungen müssen sowohl OpenGL ES 1.0 als auch 2.0 unterstützen, wie in den Android SDK -Dokumentationen enthalten und detailliert beschrieben. Geräteimplementierungen müssen auch Android Renderscript unterstützen, wie in der Android SDK -Dokumentation [ Ressourcen, 8 ] aufgeführt.

    Geräteimplementierungen müssen sich auch als die Unterstützung von OpenGL ES 1.0 und 2.0 korrekt identifizieren. Das ist:

    • Die verwaltete APIs GLES10.getString() z.
    • Die nativen C/C ++ OpenGL -APIs (dh diejenigen, die Apps über libgles_v1cm.so, libgles_v2. oder libegl.so) zur Verfügung stellen müssen, müssen die Unterstützung für OpenGL ES 1.0 und 2.0 melden.

    Geräteimplementierungen können alle gewünschten OpenGLE -Erweiterungen implementieren. Geräteimplementierungen müssen jedoch über die OpenGLE -verwalteten und nativen APIs alle Erweiterungsketten, die sie unterstützen, melden, und müssen umgekehrt keine Erweiterungsketten melden, die sie nicht unterstützen.

    Beachten Sie, dass Android 4.2 die Unterstützung von Anwendungen enthält, um optional anzugeben, dass sie spezifische OpenGL -Textur -Komprimierungsformate benötigen. Diese Formate sind typischerweise vendorspezifisch. Geräteimplementierungen sind von Android 4.2 nicht erforderlich, um ein bestimmtes Texturkomprimierungsformat zu implementieren. Sie sollten jedoch über die getString() -Methode in der OpenGL -API genau die Texturkomprimierungsformate melden, die sie unterstützen.

    Android 4.2 enthält einen Mechanismus für Anwendungen, um zu erklären, dass sie die Hardwarebeschleunigung für 2D -Grafiken in der Anwendung, Aktivität, Fenster oder Ansicht durch die Verwendung eines Manifest -Tag android:hardwareAccelerated oder Direct -API -Aufrufe [ Ressourcen, 9 ] ermöglichen.

    In Android 4.2 müssen die Geräteimplementierungen die Hardwarebeschleunigung standardmäßig ermöglichen und die Hardwarebeschleunigung deaktivieren, wenn der Entwickler SO -Anforderungen android:hardwareAccelerated="false" oder die Deaktivierung der Hardware -Beschleunigung direkt über die Android View -APIs.

    Darüber hinaus müssen Geräteimplementierungen ein Verhalten aufweisen, das mit der Android -SDK -Dokumentation zur Hardwarebeschleunigung übereinstimmt [ Ressourcen, 9 ].

    Android 4.2 enthält ein TextureView Objekt, mit dem Entwickler hardware-bewertete Opengles-Texturen direkt als Rendern von Zielen in eine UI-Hierarchie integrieren können. Geräteimplementierungen müssen die TextureView -API unterstützen und mit der vorgelagerten Android -Implementierung konsistentes Verhalten aufweisen.

    7.1.5. Kompatibilitätsmodus für ältere Anwendungen

    Android 4.2 gibt einen "Kompatibilitätsmodus" an, in dem das Framework in einem "normalen" Bildschirmgröße äquivalente (320DP-Breite) arbeitet, zum Nutzen von Legacy-Anwendungen, die nicht für alte Android-Versionen entwickelt wurden, die die Unabhängigkeit der Bildschirmgröße vor der Bildschirmgröße haben. Die Geräteimplementierungen müssen die Unterstützung für den Kompatibilitätsmodus für Legacy -Anwendungen beinhalten, wie vom vorgelagerten Android Open Source -Code implementiert. Das heißt, Geräteimplementierungen dürfen die Auslöser oder Schwellenwerte, an denen der Kompatibilitätsmodus aktiviert ist, nicht ändern und dürfen das Verhalten des Kompatibilitätsmodus selbst nicht ändern.

    7.1.6. Bildschirmtypen

    Geräteimplementierungsbildschirme werden als einer von zwei Typen eingestuft:

    • Implementierungen mit fester Pixelanzeige: Der Bildschirm ist ein einzelnes Panel, das nur eine einzelne Pixelbreite und Höhe unterstützt. In der Regel ist der Bildschirm physikalisch in das Gerät integriert. Beispiele sind Mobiltelefone, Tablets usw.
    • Implementierungen der Variablen-Pixel-Anzeige: Die Geräteimplementierung verfügt entweder über keinen eingebetteten Bildschirm und enthält einen Videoausgabebestand wie VGA, HDMI oder einen drahtlosen Anschluss für die Anzeige oder verfügt über einen eingebetteten Bildschirm, mit dem die Pixelabmessungen geändert werden können. Beispiele sind Fernseher, Set-Top-Boxen usw.

    Implementierungen des Geräts mit fester Pixel

    Implementierungen mit fester Pixel-Geräte können Bildschirme in allen Pixeldimensionen verwenden, sofern sie den definierten Anforderungen dieser Kompatibilitätsdefinition erfüllen.

    Implementierungen mit festen Pixeln können einen Videoausgangsport für die Verwendung mit einer externen Anzeige enthalten. Wenn diese Anzeige jedoch jemals zum Ausführen von Apps verwendet wird, muss das Gerät die folgenden Anforderungen erfüllen:

    • Das Gerät muss dieselbe Bildschirmkonfiguration und die in den Abschnitten 7.1.1 und 7.1.2 beschriebenen Metriken wie die Anzeige fester Pixel melden.
    • Das Gerät muss die gleiche logische Dichte wie die Festpixelanzeige melden.
    • Das Gerät muss Bildschirmabmessungen melden, die mit der Anzeige mit festem Pixel die gleichen oder sehr nahe bei der Festpixel entsprechen.

    Beispielsweise wird ein Tablet mit einer 7-Zoll-diagonale Größe mit einer Auflösung von 1024 x 600 Pixel als Implementierung mit festem Pixel angesehen. Wenn es einen Videoausgangsport enthält, der bei 720p oder 1080p anzeigt Anwendungen werden nur in einem großen MDPI-Fenster ausgeführt, unabhängig davon, ob die Anzeige- oder Videoausgangsanschluss mit festem Pixel verwendet wird.

    Implementierungen für Variable-Pixel-Geräte

    Implementierungen von Variable-Pixel-Geräten müssen eine oder beide von 1280x720 oder 1920x1080 (dh 720p oder 1080p) unterstützen. Geräteimplementierungen mit Variablen-Pixel-Anzeigen dürfen keine andere Bildschirmkonfiguration oder -modus unterstützen. Geräteimplementierungen mit variablen Pixelbildschirmen können zur Laufzeit oder zum Startzeit die Bildschirmkonfiguration oder -modus ändern. Beispielsweise kann ein Benutzer eines Set-Top-Box eine 720p-Anzeige durch eine 1080p-Anzeige ersetzen, und die Geräteimplementierung kann sich entsprechend anpassen.

    Darüber hinaus müssen die Implementierungen von Variable-Pixel-Geräten die folgenden Konfigurationsschalen für diese Pixel-Dimensionen melden:

    • 1280x720 (auch bekannt als 720p): 'Large' Bildschirmgröße, 'TVDPI' (213 DPI) Dichte
    • 1920x1080 (auch bekannt als 1080p): 'große' Bildschirmgröße, 'xhdpi' (320 dpi) Dichte

    Für Klarheit sind Geräteimplementierungen mit variablen Pixelabmessungen auf 720p oder 1080p in Android 4.2 beschränkt und müssen so konfiguriert werden, dass die Bildschirmgröße und die Dichtekleber wie oben angegeben melden.

    7.1.7. Bildschirmtechnologie

    Die Android -Plattform enthält APIs, mit denen Anwendungen reichhaltige Grafiken für die Anzeige übertragen werden können. Geräte müssen alle diese APIs im Sinne des Android SDK unterstützen, sofern in diesem Dokument nicht ausdrücklich zulässig ist. Speziell:

    • Geräte müssen Anzeigen unterstützen, die 16-Bit-Farbgrafiken rendern können, und sollten Anzeigen unterstützen, die mit 24-Bit-Farbgrafiken in der Lage sind.
    • Geräte müssen Anzeigen unterstützen, die Animationen rendern können.
    • Die verwendete Display -Technologie muss ein Pixel -Seitenverhältnis (PAR) zwischen 0,9 und 1,1 haben. Das heißt, das Pixel -Seitenverhältnis muss mit einer Toleranz von 10% in der Nähe von Quadrat (1,0) sein.

    7.1.8. Externe Displays

    Android 4.2 beinhaltet die Unterstützung für das Sekundärdisplay, um die Medienfreigabefunktionen und Entwickler -APIs für den Zugriff auf externe Displays zu ermöglichen. Wenn ein Gerät eine externe Anzeige entweder über eine verdrahtete, drahtlose oder eine eingebettete zusätzliche Anzeigeverbindung unterstützt, muss die Geräteimplementierung die in der Android -SDK -Dokumentation beschriebene Anzeige -Manager -API implementieren [ Ressourcen, 75 ]. Geräteimplementierungen, die sichere Videoausgaben unterstützen und sichere Oberflächen unterstützen können, müssen die Unterstützung für Display.SECURE_FLAG deklarieren. Insbesondere müssen Geräteimplementierungen, die die Unterstützung für Display.SECURE_FLAG deklarieren, HDCP 2.x oder höher für Miracast -Wireless -Displays oder HDCP 1.2 oder höher für kabelgebundene Anzeigen unterstützen. Die vorgelagerte Android Open Source -Implementierung beinhaltet die Unterstützung für drahtlose (Miracast) und Wired -Displays (HDMI), die diese Anforderung erfüllen.

    7.2. Eingabegeräte

    7.2.1. Tastatur

    Geräteimplementierungen:

    • Muss die Unterstützung für das Input -Management -Framework (mit dem Drittanbieter -Entwickler es ermöglichen, Input -Management -Engines zu erstellen - dh Soft -Tastatur) unter http://developer.android.com detailliert beschrieben
    • 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.

    7.2.2. Non-Touch-Navigation

    Geräteimplementierungen:

    • Kann eine Nicht-Touch-Navigationsoption weglassen (dh kann ein Trackball, ein D-Pad oder ein Rad weglassen).
    • Muss den korrekten Wert für android.content.res.Configuration.navigation [ Ressourcen, 40 ] melden.
    • Muss einen angemessenen alternativen Benutzeroberflächenmechanismus für die Auswahl und Bearbeitung von Text bereitstellen, die mit Engine -Management -Motoren kompatibel sind. Die vorgelagerte Android Open-Source-Implementierung enthält einen Auswahlmechanismus, der für die Verwendung mit Geräten geeignet ist, denen keine Navigationseingänge ohne Berührung haben.

    7.2.3. 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, wenn sie Anwendungen ausführen. Diese Funktionen können über dedizierte physische Schaltflächen (z. B. mechanische oder kapazitive Touch -Schaltflächen) implementiert werden oder können mit dedizierten Softwaretasten, Gesten, Touch Panel usw. implementiert werden. Android 4.2 unterstützt beide Implementierungen.

    Android 4.2 beinhaltet Unterstützung für Assist -Aktionen [ Ressourcen, 63 ]. Geräteimplementierungen müssen die Assist -Aktion dem Benutzer jederzeit beim Ausführen von Anwendungen zur Verfügung stellen. Diese Funktion kann über Hardware- oder Softwareschlüssel implementiert werden.

    Geräteimplementierungen können einen bestimmten Teil des Bildschirms verwenden, um die Navigationsschlüssel anzuzeigen. In diesem Fall muss jedoch diese Anforderungen erfüllen:

    • Die Navigationsschlüssel der Geräteimplementierung müssen einen bestimmten Teil des Bildschirms verwenden, der nicht für Anwendungen verfügbar ist, und dürfen den Teil des Bildschirms, der den Anwendungen zur Verfügung steht, nicht verkleinern oder auf andere Weise beeinträchtigen.
    • Geräteimplementierungen müssen einen Teil des Displays für Anwendungen zur Verfügung stellen, die den in Abschnitt 7.1.1 definierten Anforderungen erfüllen.
    • Geräteimplementierungen müssen die Navigationsschlüssel anzeigen, wenn Anwendungen keinen System -UI -Modus angeben, oder SYSTEM_UI_FLAG_VISIBLE angeben.
    • Die Geräteimplementierungen müssen die Navigationsschlüssel in einem unauffälligen "Low -Profile" -Modus (z. B. herzgetrieben) vorstellen, wenn Anwendungen SYSTEM_UI_FLAG_LOW_PROFILE angeben.
    • Geräteimplementierungen müssen die Navigationsschlüssel ausblenden, wenn Anwendungen SYSTEM_UI_FLAG_HIDE_NAVIGATION angeben.
    • Die Geräteimplementierung muss einen Menüschlüssel für Anwendungen vorlegen, wenn TargetsDkversion <= 10 einen Menüschlüssel darstellen sollte, wenn die Zieledkversion> 10.

    7.2.4. Touchscreen-Eingabe

    Geräteimplementierungen:

    • Muss ein Zeigereingangssystem irgendeiner Art haben (entweder mausähnlich oder berühren)
    • Kann einen Touchscreen jeglicher Modalität haben (wie kapazitiv oder resistiv)
    • Sollte unabhängig voneinander verfolgte Zeiger unterstützen, wenn ein Touchscreen mehrere Zeiger unterstützt
    • Muss den Wert von android.content.res.Configuration [ Ressourcen, 39 ] melden, die dem Typ des spezifischen Touchscreen auf dem Gerät entsprechend entsprechen

    Geräteimplementierungen müssen die korrekte Funktion melden, die dem verwendeten Eingangstyp entspricht. Beachten Sie, dass Android 4.2 die Funktion android.hardware.faketouch enthält, die einem Eingabegerät mit hohem Fidelity-Nicht-Touch (dh Zeigerbasiert) entspricht, wie z. Gestenunterstützung) und zeigt an, dass das Gerät eine emulierte Teilmenge der Touchscreen -Funktionalität unterstützt. Geräteimplementierungen mit einem Touchscreen (Single-Touch oder besser) müssen auch Android.hardware.faketouch melden. Geräteimplementierungen, die keinen Touchscreen enthalten (und nur auf ein Zeigergerät angewiesen sind), dürfen keine Touchscreen -Funktion melden und müssen nur android.hardware.faketouch melden.

    7.2.5. Mikrofon

    Geräteimplementierungen können ein Mikrofon weglassen. Wenn eine Geräteimplementierung jedoch ein Mikrofon auslässt, darf sie nicht die Feature-Konstante android.hardware.microphone melden und die API von Audioaufzeichnungen als No-OPS gemäß Abschnitt 7 implementieren. Umgekehrt besitzen Geräteimplementierungen, die ein Mikrofon besitzen:

    • Muss die android.hardware.microphone -Funktionskonstante melden
    • Sollte die Anforderungen an die Audioqualität in Abschnitt 5.4 erfüllen
    • Sollte die Anforderungen an die Audiolatenz in Abschnitt 5.5 erfüllen

    7.3. Sensoren

    Android 4.2 enthält APIs zum Zugriff auf eine Vielzahl von Sensortypen. Geräteimplementierungen können diese Sensoren im Allgemeinen weglassen, wie in den folgenden Unterabschnitten vorgesehen. Wenn ein Gerät einen bestimmten Sensortyp enthält, der über eine entsprechende API für Entwickler von Drittanbietern verfügt, muss die Geräteimplementierung diese API implementieren, wie in der Android-SDK-Dokumentation beschrieben. Zum Beispiel Geräteimplementierungen:

    • Muss genau das Vorhandensein oder Fehlen von Sensoren gemäß android.content.pm.PackageManager -Klasse melden. [ Ressourcen, 37 ]
    • Muss eine genaue Liste unterstützter Sensoren über den SensorManager.getSensorList() und ähnliche Methoden zurückgeben
    • Muss sich für alle anderen Sensor -APIs vernünftigerweise verhalten (zum Beispiel, indem sie wahr oder falsch zurückgeben, wenn Anwendungen versuchen, die Hörer zu registrieren, und nicht die Sensor -Hörer aufzurufen, wenn die entsprechenden Sensoren nicht vorhanden sind; usw.)
    • Muss alle Sensormessungen mit dem entsprechenden internationalen System der Einheiten (IE -Metrik) für jeden Sensortyp gemäß der Android SDK -Dokumentation melden [ Ressourcen, 41 ]

    Die obige Liste ist nicht umfassend; Das dokumentierte Verhalten des Android SDK ist als maßgeblich angesehen zu werden.

    Einige Sensortypen sind synthetisch, dh sie können aus Daten abgeleitet werden, die von einem oder mehreren anderen Sensoren bereitgestellt werden. (Beispiele sind der Orientierungssensor und der lineare Beschleunigungssensor.) Die Geräteimplementierungen sollten diese Sensortypen implementieren, wenn sie die Voraussetzungen für physikalische Sensoren enthalten.

    Der Android 4.2 enthält einen Begriff eines "Streaming" -Sensors, der Daten kontinuierlich zurückgibt, und nicht nur, wenn sich die Daten ändert. Geräteimplementierungen müssen kontinuierlich periodische Datenproben für jede API liefern, die durch die Android 4.2 SDK -Dokumentation als Streaming -Sensor angegeben ist. Beachten Sie, dass die Geräteimplementierungen sicherstellen müssen, dass der Sensorstrom nicht verhindern darf, dass die CPU die Geräte -CPU in einen Suspendzustand eingeht oder aus einem Suspend -Status aufwacht.

    7.3.1. Beschleunigungsmesser

    Die Geräteimplementierungen sollten ein 3-Achsen-Beschleunigungsmesser enthalten. Wenn eine Geräteimplementierung ein 3-Achsen-Beschleunigungsmesser enthält, ist dies:

    • Sollte in der Lage sein, Veranstaltungen ab 120 Hz oder mehr zu liefern. Beachten Sie, dass die oben genannte Beschleunigungsmesserfrequenz für Android 4.2 als "sollte" angegeben ist, die Kompatibilitätsdefinition für eine zukünftige Version geplant ist, um diese in "Must" zu ändern. Das heißt, diese Standards sind in Android 4.2 optional, werden jedoch in zukünftigen Versionen erforderlich sein . Bestehende und neue Geräte, die Android 4.2 ausführen
    • Muss das Android -Sensorkoordinatensystem gemäß den Android -APIs entsprechen (siehe [ Ressourcen, 41 ])
    • Muss in der Lage sein, von Freefall bis zu zweimal Schwerkraft (2 g) oder mehr bei einem dreidimensionalen Vektor zu messen
    • Muss 8 Bit Genauigkeit oder mehr haben
    • Muss eine Standardabweichung von nicht mehr als 0,05 m/s^2 haben

    7.3.2. Magnetometer

    Die Geräteimplementierungen sollten ein 3-Achsen-Magnetometer (dh Kompass) enthalten. Wenn ein Gerät ein 3-Achsen-Magnetometer enthält, sollten Sie es enthalten.

    • Muss in der Lage sein, Ereignisse bei 10 Hz oder mehr zu liefern
    • Muss das Android -Sensorkoordinatensystem gemäß den Android -APIs entsprechen (siehe [ Ressourcen, 41 ]).
    • Muss in der Lage sein, eine Reihe von Feldstärken zu probieren, die für das geomagnetische Feld ausreichend sind
    • Muss 8 Bit Genauigkeit oder mehr haben
    • Muss eine Standardabweichung von nicht mehr als 0,5 µt haben

    7.3.3. GPS

    Die Geräteimplementierungen sollten einen GPS -Empfänger enthalten. Wenn eine Geräteimplementierung einen GPS-Empfänger enthält, sollte sie eine Form der "unterstützten GPS" -Technik enthalten, um die GPS-Sperrenzeit zu minimieren.

    7.3.4. Gyroskop

    Die Geräteimplementierungen sollten ein Gyroskop (dh Winkeländerungssensor) enthalten. Geräte sollten keinen Gyroskopsensor enthalten, es sei denn, es ist auch ein 3-Achsen-Beschleunigungsmesser enthalten. Wenn eine Geräteimplementierung ein Gyroskop enthält, ist dies:

    • Muss temperatur kompensiert sein
    • Muss in der Lage sein, die Orientierungsänderungen zu messen, die bis zu 5,5*PI -Radianer/Sekunde (dh ungefähr 1.000 Grad pro Sekunde) messen können (ca. 1.000 Grad)
    • Sollte in der Lage sein, Veranstaltungen zu 200 Hz oder mehr zu liefern. Beachten Sie, dass die obige Gyroskopfrequenz als "sollte" für Android 4.2 angegeben wird, die Kompatibilitätsdefinition für eine zukünftige Version geplant ist, um diese in "Must" zu ändern. Das heißt, diese Standards sind in Android 4.2 optional, werden jedoch in zukünftigen Versionen erforderlich sein . Bestehende und neue Geräte, die Android 4.2 ausführen
    • Muss 12 Bit Genauigkeit oder mehr haben
    • Muss eine Varianz von nicht mehr als 1E-7 rad^2 / s^2 pro Hz (Varianz pro Hz oder rad^2 / s) haben. Die Varianz kann mit der Stichprobenrate variieren, muss jedoch durch diesen Wert eingeschränkt werden. Mit anderen Worten, wenn Sie die Varianz des Gyro bei 1 Hz-Abtastrate messen, sollte es nicht mehr als 1E-7 rad^2/s^2 sein.
    • Muss Zeitstempel so nah wie möglich wie möglich haben. Die konstante Latenz muss entfernt werden.

    7.3.5. Barometer

    Die Geräteimplementierungen können ein Barometer (dh Umgebungsluftdrucksensor) umfassen. Wenn eine Geräteimplementierung ein Barometer enthält, ist es IT:

    • Muss in der Lage sein, Ereignisse bei 5 Hz oder mehr zu liefern
    • Muss eine ausreichende Genauigkeit haben, um die Schätzung der Höhe zu ermöglichen
    • Muss temperatur kompensiert sein

    7.3.7. Thermometer

    Geräteimplementierungen können jedoch kein Thermometer (dh Temperatursensor) enthalten. Wenn eine Geräteimplementierung ein Thermometer umfasst, muss die Temperatur der Geräte -CPU messen. Es darf keine andere Temperatur messen. (Beachten Sie, dass dieser Sensortyp in den Android 4.2 -APIs veraltet ist.)

    7.3.7. Photometer

    Geräteimplementierungen können ein Photometer (dh Umgebungslichtsensor) umfassen.

    7.3.8. Näherungssensor

    Die Geräteimplementierungen können einen Proximity -Sensor umfassen. Wenn eine Geräteimplementierung einen Näherungssensor enthält, muss sie die Nähe eines Objekts in die gleiche Richtung wie der Bildschirm messen. Das heißt, der Näherungssensor muss so ausgerichtet sein, dass Objekte in der Nähe des Bildschirms erfasst werden, da die primäre Absicht dieses Sensortyps darin besteht, ein vom Benutzer verwendetes Telefon zu erkennen. Wenn eine Geräteimplementierung einen Näherungssensor mit einer anderen Ausrichtung enthält, darf sie nicht über diese API zugänglich sein. Wenn eine Geräteimplementierung über einen Näherungssensor verfügt, muss sie 1-Bit Genauigkeit oder mehr haben.

    7.4. Datenkonnektivität

    7.4.1. Telefonie

    "Telefonie", wie von den Android 4.2 -APIs verwendet, und dieses Dokument bezieht sich speziell auf Hardware, die sich auf das Platten von Sprachanrufen und das Senden von SMS -Nachrichten über ein GSM- oder CDMA -Netzwerk beziehen. Diese Sprachanrufe können zwar paketanschlitzt werden oder auch nicht, sie dienen zwar für die Zwecke von Android 4.2 als unabhängig von einer Datenkonnektivität, die möglicherweise mit demselben Netzwerk implementiert werden kann. Mit anderen Worten, die Android "Telefonie" -Funktionalität und -APIs beziehen sich speziell auf Sprachanrufe und SMS. Beispielsweise dürfen Geräteimplementierungen, die keine Anrufe oder Senden/Empfangen von SMS-Nachrichten eingeben, die Funktion "Android.hardware.telephony" oder Unterfunktionen nicht melden, unabhängig davon, ob sie ein Mobilfunknetz für die Datenkonnektivität verwenden.

    Android 4.2 kann auf Geräten verwendet werden, die keine Telefonie -Hardware enthalten. Das heißt, Android 4.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.

    7.4.2. IEEE 802.11 (WLAN)

    Android 4.2 -Geräteimplementierungen sollten die Unterstützung für eine oder mehrere Formulare von 802.11 (b/g/a/n usw.) enthalten, wenn eine Geräteimplementierung die Unterstützung für 802.11 enthält, die entsprechende Android -API implementieren muss.

    Geräteimplementierungen müssen die Multicast -API implementieren, wie in der SDK -Dokumentation [ Ressourcen, 62 ] beschrieben. Geräteimplementierungen, die den WLAN -Support enthalten, müssen Multicast DNS (MDNS) unterstützen. Die Geräteimplementierungen dürfen MDNS -Pakete (224.0.0.251) zu einem Zeitpunkt des Betriebs nicht filtern, einschließlich der Zeit, in der sich der Bildschirm nicht in einem aktiven Zustand befindet.

    7.4.2.1. Wi-Fi Direct

    Die Geräteimplementierungen sollten die Unterstützung von WLAN Direct (WLAN-Peer-to-Peer) beinhalten. Wenn eine Geräteimplementierung die Unterstützung von WLI Direct enthält, muss die entsprechende Android -API wie in der SDK -Dokumentation beschrieben implementiert [ Ressourcen, 68 ]. Wenn eine Geräteimplementierung die Unterstützung von WLAN Direct beinhaltet, dann: dann:

    • Muss den regulären WLAN -Betrieb unterstützen
    • Sollte die gleichzeitige Direktoperation von WLAN und WLAN unterstützen

    7.4.3. Bluetooth

    Die Geräteimplementierungen sollten einen Bluetooth -Transceiver enthalten. Geräteimplementierungen, die einen Bluetooth-Transceiver enthalten, müssen die in der SDK-Dokumentation [ Ressourcen, 42 ] beschriebene RFCOMM-basierte Bluetooth-API aktivieren. 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.

    7.4.4. Nahfeldkommunikation

    Die Geräteimplementierungen sollten einen Transceiver und eine verwandte Hardware für die Nahfeldkommunikation (NFC) enthalten. Wenn eine Geräteimplementierung NFC -Hardware enthält, dann: dann:

    • Muss die Funktion von Android.hardware.nfc bei der Methode android.content.pm.PackageManager.hasSystemFeature() melden. [ Ressourcen, 37 ]
    • Muss in der Lage sein, NDEF -Nachrichten über die folgenden NFC -Standards zu lesen und zu schreiben:
      • Muss in der Lage sein, als NFC Forum Reader/Writer (wie vom NFC Forum Technical Specification NFCForum-TS-DigitalProtocol-1.0) zu fungieren sein.
        • NFCA (ISO14443-3a)
        • NFCB (ISO14443-3B)
        • NFCF (JIS 6319-4)
        • Isodep (ISO 14443-4)
        • NFC Forum Tag Typen 1, 2, 3, 4 (definiert durch das NFC -Forum)
    • Sollte in der Lage sein, NDEF -Nachrichten über die folgenden NFC -Standards zu lesen und zu schreiben. Beachten Sie, dass die folgenden NFC -Standards zwar als "sollte" für Android 4.2 angegeben sind, die Kompatibilitätsdefinition für eine zukünftige Version geplant ist, um diese in "Must" zu ändern. Das heißt, diese Standards sind in Android 4.2 optional, werden jedoch in zukünftigen Versionen erforderlich sein . Bestehende und neue Geräte, die Android 4.2 ausführen, werden sehr stark ermutigt, diese Anforderungen in Android 4.2 zu erfüllen, damit sie auf die zukünftigen Plattform -Releases aufrüsten können.
      • NFCV (ISO 15693)
    • Muss in der Lage sein, Daten über die folgenden Peer-to-Peer-Standards und -protokolle zu übertragen und zu empfangen:
      • ISO 18092
      • LLCP 1.0 (definiert vom NFC -Forum)
      • SDP 1.0 (definiert vom NFC -Forum)
      • Ndef Push Protocol [ Ressourcen, 43 ]
      • Snep 1.0 (definiert vom NFC -Forum)
    • Muss die Unterstützung für Android Beam enthalten [ Ressourcen, 65 ]:
      • Muss den Snep -Standardserver implementieren. Gültige NDEF -Nachrichten, die vom Standard -SNEP -Server empfangen werden, müssen mit der Intent von Android.nfc.Action_Ndef_Decovered an Anwendungen versandt werden. Das Deaktivieren von Android Beam in Einstellungen darf den Versand der eingehenden NDEF -Nachricht nicht deaktivieren.
      • Die Geräteimplementierungen müssen die Android.Settings.nfcsharing_Setings -Absicht ehren, NFC -Sharing -Einstellungen anzuzeigen [ Ressourcen, 67 ].
      • Muss den NPP -Server implementieren. Nachrichten, die vom NPP -Server empfangen werden, müssen auf die gleiche Weise wie der SNEP -Standardserver verarbeitet werden.
      • Muss einen Snep -Client implementieren und versuchen, den ausgehenden P2P -NDEF an den Standard -Snep -Server zu senden, wenn Android Beam aktiviert ist. Wenn kein Standard -Snep -Server gefunden wird, muss der Client versuchen, an einen NPP -Server zu senden.
      • Muss den Vordergrundaktivitäten die ausgehende P2P -NDEF -Nachricht mit Android.nfc.nfcadapter.setndefppushmessage und Android.nfc.nfcadapter.setndefppusMessageCallback und Android.nfc.nfcadapter.enableDeGroundndefpush.
      • Sollte eine Geste oder eine auf dem Bildschirm bestehende Bestätigung wie "Berührung zum Strahl" verwenden, bevor Sie ausgehende P2P-NDEF-Nachrichten senden.
      • Sollte Android Beam standardmäßig aktivieren
      • Muss die NFC -Verbindung über die Übergabe von Bluetooth unterstützen, wenn das Gerät Bluetooth -Objekt -Push -Profil unterstützt. Geräteimplementierungen müssen die Verbindung über die Verbindung über Bluetooth bei der Verwendung von android.nfc.nfcadapter.setBeampushuris unterstützen, indem die "Verbindungsübergabe Version 1.2" [ Ressourcen, 60 ] und "Bluetooth -sichere einfache Paarung mit NFC Version 1.0" [ Ressourcen, 61 ] Spezifikationen aus von SPARING aus der einfachen Pairing aus implementiert werden. Das NFC -Forum. Eine solche Implementierung sollte Snep -GET -Anforderungen zum Austausch der Handover -Anforderung / Auswählen von Datensätzen über NFC verwenden und das Bluetooth -Objekt -Push -Profil für die tatsächliche Bluetooth -Datenübertragung verwenden.
    • Muss für alle unterstützten Technologien im NFC -Erkennungsmodus befragt.
    • Sollte im NFC-Erkennungsmodus sein, während das Gerät mit aktivem Bildschirm aktiv ist und der Sperrbildschirm entsperrt ist.

    (Beachten Sie, dass öffentlich verfügbare Links für die oben genannten JIS-, ISO- und NFC -Forumspezifikationen nicht verfügbar sind.)

    Darüber hinaus können Geräteimplementierungen die Unterstützung von Leser/Schriftstellern für die folgenden Mifare -Technologien umfassen.

    Beachten Sie, dass Android 4.2 APIs für diese Mifare -Typen enthält. Wenn eine Geräteimplementierung MIFARE in der Rolle des Leser/Autors unterstützt, ist dies:

    • Muss die entsprechenden Android -APIs implementieren, wie sie vom Android SDK dokumentiert wurde
    • Muss die Funktion com.nxp.mifare von der methode android.content.pm.PackageManager.hasSystemFeature() melden. [ Ressourcen, 37 ] Beachten Sie, dass dies keine Standard -Android -Funktion ist und als solche nicht als Konstante in der PackageManager -Klasse erscheint.
    • Darf die entsprechenden Android -APIs weder implementieren noch die Funktion com.nxp.mifare melden, es sei denn

    Wenn eine Geräteimplementierung keine NFC -Hardware enthält , darf sie die Funktion von Android.hardware.nfc nicht aus der android.content.pm.PackageManager.hasSystemFeature() deklarieren. ein No-op.

    Da die Klassen android.nfc.NdefMessage und android.nfc.NdefRecord ein Protokoll-unabhängiger Datenrepräsentationsformat darstellen, müssen Geräteimplementierungen diese APIs auch dann implementieren, wenn sie keine Unterstützung für NFC enthalten oder die Feature von Android.hardware.nfc nicht deklarieren.

    7.4.5. Minimale Netzwerkfähigkeit

    Die Geräteimplementierungen müssen die Unterstützung für eine oder mehrere Formulare des Datennetzwerks enthalten. Insbesondere müssen Geräteimplementierungen die Unterstützung für mindestens einen 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, Ethernet usw.

    Geräteimplementierungen, bei denen ein physischer Netzwerkstandard (z. B. Ethernet) die primäre Datenverbindung ist, sollte auch die Unterstützung für mindestens einen gemeinsamen drahtlosen Datenstandard enthalten, z. B. 802.11 (WLAN).

    Geräte können mehr als eine Form der Datenkonnektivität implementieren.

    7.5. Kameras

    Die Geräteimplementierungen sollten eine nach hinten gerichtete Kamera enthalten und eine vorne ausgerichtete Kamera enthalten. Eine nach hinten gerichtete Kamera ist eine Kamera an der Seite des Geräts gegenüber dem Display. Das heißt, es bildet wie eine herkömmliche Kamera Szenen auf der anderen Seite des Geräts. Eine vorne gerichtete Kamera ist eine Kamera auf derselben Seite des Geräts wie das Display. Das heißt, eine Kamera, die normalerweise verwendet wird, um den Benutzer vorzustellen, z. B. für Videokonferenzen und ähnliche Anwendungen.

    7.5.1. Nach hinten gerichtete Kamera

    Die Geräteimplementierungen sollten eine nach hinten gerichtete Kamera enthalten. Wenn eine Geräteimplementierung eine nach hinten gerichtete Kamera enthält, ist dies:

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

    7.5.2. Front-Kamera

    Die Geräteimplementierungen können eine Frontkamera enthalten. Wenn eine Geräteimplementierung eine vorne gerichtete Kamera enthält, ist dies:

    • Muss eine Auflösung von mindestens VGA haben (dh 640x480 Pixel)
    • Darf keine vorne gerichtete Kamera als Standardeinstellung für die Kamera-API verwenden. Das heißt, die Kamera-API in Android 4.2 bietet eine spezielle Unterstützung für Kameras vorne, und Geräteimplementierungen dürfen die API nicht so konfigurieren, dass eine Kamera vorne als vorne als standardmäßige Kamera nach hinten gerichtet ist, auch wenn sie die einzige Kamera auf ist das Gerät.
    • Kann Funktionen (z. B. Autofokus, Blitz usw.) enthalten, die nach hinten gerichteten Kameras verfügbar sind, wie in Abschnitt 7.5.1 beschrieben.
    • Muss horizontal reflektieren (dh Spiegel) den von einer App in einem Camerapreview angezeigten Stream wie folgt:
      • Wenn die Geräteimplementierung vom Benutzer (z.
      • Wenn die aktuelle Anwendung ausdrücklich angefordert hat, dass die Kameraanzeige über einen Aufruf an die android.hardware.Camera.setDisplayOrientation() [ Ressourcen, 50 ] Methode gedreht wird, muss die Kameravorschau horizontal relativ zur von der Anwendung angegebenen Ausrichtung gespiegelt werden.
      • Andernfalls muss die Vorschau entlang der Standardhorizontalachse des Geräts spiegeln.
    • Muss das von der Postansicht angezeigte Bild auf die gleiche Weise wie der Vorschau -Image -Stream der Kamera angezeigt werden. (Wenn die Geräteimplementierung Postansicht nicht unterstützt, gilt diese Anforderung offensichtlich nicht.)
    • Darf nicht die endgültigen erfassten Standbilder- oder Video -Streams widerspiegeln, die an Anwendungsrufe zurückgegeben oder sich dem Medienspeicher verpflichtet haben

    7.5.3. Verhalten der Kamera-API

    Geräteimplementierungen müssen die folgenden Verhaltensweisen für die Kamera-bezogenen APIs sowohl für Front- als auch für die Rückverfolgungskameras 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() müssen das NV21 -Codierungsformat weiter sein. Das heißt, Nv21 muss der Standard sein.
    3. Geräteimplementierungen müssen das YV12-Format (wie durch die android.graphics.ImageFormat.YV12 konstant) für die Kamera-Vorschau sowohl für Front- als auch für nach hinten gerichtete Kameras unterstützen. (Der Hardware -Video -Encoder und die Kamera können ein beliebiges natives Pixelformat verwenden. Die Geräteimplementierung muss jedoch die Konvertierung in YV12 unterstützen.)

    Geräteimplementierungen müssen die vollständige Kamera -API implementieren, die in der Android 4.2 SDK -Dokumentation [ Ressourcen, 51 ]) enthalten ist, unabhängig davon, ob das Gerät Hardware -Autofokus oder andere Funktionen enthält. Beispielsweise müssen Kameras, denen Autofokus fehlt, noch alle registrierten android.hardware.Camera.AutoFocusCallback Instanzen anrufen (obwohl dies für eine Nicht-Autofocus-Kamera nicht relevant ist). Beachten Sie, dass dies für Kameras vorne geliefert wird. Obwohl die meisten Frontkameras den Autofokus nicht unterstützen, müssen die API-Rückrufe trotzdem wie beschrieben "gefälscht" werden.

    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. Beispielsweise müssen Geräteimplementierungen , die Bildaufnahmen mithilfe der Bildgebungstechniken (High Dynamic Range) unterstützen, die Kamera Camera.SCENE_MODE_HDR unterstützen.

    Geräteimplementierungen müssen die Camera.ACTION_NEW_PICTURE Intent Wenn ein neues Bild von der Kamera aufgenommen wird und der Eintrag des Bildes in den Medienspeicher hinzugefügt wurde.

    Geräteimplementierungen müssen die Camera.ACTION_NEW_VIDEO Intent, wenn ein neues Video von der Kamera aufgezeichnet wird und der Eintrag des Bildes zum Medienspeicher hinzugefügt wurde.

    7.5.4. Kameraausrichtung

    Sowohl die Front- als auch die nach hinten gerichteten Kameras müssen, falls vorhanden, so ausgerichtet sein, dass die lange Dimension der Kamera mit der langen Dimension des Bildschirms übereinstimmt. Das heißt, wenn das Gerät in der Landschaftsorientierung gehalten wird, müssen Kameras Bilder in der Landschaftsausrichtung aufnehmen. Dies gilt unabhängig von der natürlichen Ausrichtung des Geräts. Das heißt, es gilt für Landschafts-Primary-Geräte sowie für Porträt-Primary-Geräte.

    7.6. Erinnerung und Speicherung

    7.6.1. Minimaler Arbeitsspeicher und Speicherplatz

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

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

    Die Android -APIs enthalten einen Download -Manager, mit dem Anwendungen zum Herunterladen von Datendateien [ Ressourcen, 56 ] verwendet werden. Die Geräteimplementierung des Download -Managers muss in der Lage sein, einzelne Dateien von mindestens 100 MB in Größe "Cache" -Position "Cache" herunterzuladen.

    7.6.2. Gemeinsamer Anwendungsspeicher

    Geräteimplementierungen müssen gemeinsam genutztes Speicher für Anwendungen anbieten. Der freigegebene Speicher muss mindestens 1 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 Speicherspeichers müssen Geräteimplementierungen einen Mechanismus bereitstellen, um auf den Inhalt des gemeinsam genutzten Speichers von einem Host -Computer wie USB -Massenspeicher (UMS) oder Media Transfer Protocol (MTP) zugreifen zu können. Geräteimplementierungen verwenden möglicherweise USB -Massenspeicher, sollten jedoch Medienübertragungsprotokoll verwenden. Wenn die Geräteimplementierung Medienübertragungsprotokoll unterstützt:

    • Die Geräteimplementierung sollte mit dem Referenz Android MTP Host, Android -Dateiübertragung [ Ressourcen, 57 ] kompatibel sein.
    • Die Geräteimplementierung sollte eine USB -Geräteklasse von 0x00 melden.
    • Die Geräteimplementierung sollte einen USB -Schnittstellennamen von 'MTP' melden.

    Wenn der Geräteimplementierung USB -Ports fehlen, muss sie einem Host -Computer auf andere Weise auf den Inhalt des gemeinsam genutzten Speichers wie ein Netzwerkdateisystem zugreifen.

    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 1 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 1 GB oder größer sein und auf /sdcard montiert sein (oder /sdcard muss eine symbolische Verbindung zum physischen Ort sein, wenn sie an anderer Stelle montiert ist).

    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.

    7.7. USB

    Die Geräteimplementierungen sollten einen USB -Client -Port enthalten und einen USB -Host -Port enthalten.

    Wenn eine Geräteimplementierung einen USB -Client -Port enthält:

    • Der Port muss mit einem USB-Host mit einem Standard-USB-A-Port verbunden sein
    • Der Port sollte den Micro -USB -Formfaktor auf der Geräteseite verwenden. Bestehende und neue Geräte, die Android 4.2 ausführen
    • Der Hafen sollte in der Mitte einer Kante zentriert sein. Die Geräteimplementierungen sollten entweder den Port am unteren Rand des Geräts (gemäß der natürlichen Ausrichtung) suchen oder die Softwarebildschirmrotation für alle Apps (einschließlich Startbildschirm) aktivieren, damit das Display korrekt zeichnet, wenn das Gerät mit dem Port unten ausgerichtet ist. Bestehende und neue Geräte, die Android 4.2 ausführen, werden sehr stark ermutigt, diese Anforderungen in Android 4.2 zu erfüllen, damit sie auf zukünftige Plattform -Releases aufrüsten können.
    • Wenn das Gerät andere Ports (z. B. einen Nicht-USB-Ladeanschluss) verfügt
    • Es muss ein Host ermöglichen, der mit dem Gerät angeschlossen ist
    • Es muss die in der Android SDK -Dokumentation dokumentierte Android Open Accessoire API und Spezifikation implementiert und die Unterstützung für die Hardware -Funktion android.hardware.usb.accessory [ Ressourcen, 52 ] deklarieren.
    • Es muss die USB -Audioklasse implementieren, wie in der Android SDK -Dokumentation [ Ressourcen, 66 ] dokumentiert.
    • Es sollte die Unterstützung für USB -Akku -Ladespezifikation implementieren [ Ressourcen, 64 ] vorhandene und neue Geräte, die Android 4.2 ausführen

    Wenn eine Geräteimplementierung einen USB -Host -Port enthält:

    • Es kann einen nicht standardmäßigen Portformfaktor verwenden. In diesem Fall muss dies jedoch mit einem Kabel oder Kabel versendet werden, die den Port an Standard USB-A anpassen
    • Es muss die in Android SDK dokumentierte Android -USB -Host -API implementiert und die Unterstützung für die Hardware -Funktion android.hardware.usb.host [ Ressourcen, 53 ] deklarieren.

    Geräteimplementierungen müssen die Android -Debug -Brücke implementieren. Wenn eine Geräteimplementierung einen USB-Client-Port weglässt, muss die Android-Debug-Brücke über das lokale Netzwerk (wie Ethernet oder 802.11) implementiert werden.

    8. Leistungskompatibilität

    Geräteimplementierungen müssen die wichtigsten Leistungsmetriken eines in der folgenden Tabelle definierten Android 4.2 -kompatiblen Geräts erfüllen:

    Metrisch Leistungsschwelle Kommentare
    Anwendungsstartzeit Die folgenden Anwendungen sollten innerhalb der angegebenen Zeit auf den Markt kommen.
    • Browser: weniger als 1300 ms
    • Kontakte: weniger als 700 ms
    • Einstellungen: weniger als 700 ms
    Die Startzeit wird als Gesamtzeit für das Laden der Standardaktivität für die Anwendung gemessen, einschließlich der Zeit, die zum Starten des Linux -Vorgangs benötigt, das Android -Paket in die Dalvik -VM lädt und OnCreate anruft.
    Gleichzeitige Anwendungen Wenn mehrere Anwendungen gestartet wurden, muss die Neustart einer bereits laufenden Anwendung nach dem Start weniger als die ursprüngliche Startzeit dauern.

    9. Kompatibilität des Sicherheitsmodells

    Geräteimplementierungen müssen ein Sicherheitsmodell implementieren, das mit dem Sicherheitsmodell für Android -Plattform in Übereinstimmung in der Sicherheits- und Berechtigungsreferenzdokument in den APIs [ Ressourcen, 54 ] in der Android Developer -Dokumentation übereinstimmt. 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.

    9.1. Berechtigungen

    Geräteimplementierungen müssen das in der Android Developer -Dokumentation definierte Android -Berechtigungsmodell [ Ressourcen, 54 ] 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.

    9.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 Sicherheits- und Berechtigungen definiert [ Ressourcen, 54 ].

    9.3. Dateisystemberechtigungen

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

    9.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 9 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:

    • Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
    • Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
    • Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
    • Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

    Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

    The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

    When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

    9.5. Mehrbenutzerunterstützung

    Android 4.2 includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

    Device implementations MUST meet these requirements related to multi-user support[ Resources, 71 ]:

    • As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
    • Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]

    Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage. The upstream Android open-source project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation. Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage

    9.6. Premium-SMS-Warnung

    Android 4.2 includes support for warning users for any outgoing premium SMS message. Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android open-source project provides an implementation that satisfies this requirement.

    10. Softwarekompatibilitätstests

    Device implementations MUST pass all tests described in this section.

    However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 4.2 available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

    10.1. Kompatibilitätstestsuite

    Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

    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. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.2. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

    10.2. CTS-Verifizierer

    Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

    The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

    Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

    10.3. Referenzanwendungen

    Device implementers MUST test implementation compatibility using the following open source applications:

    • The "Apps for Android" applications [ Resources, 55 ]
    • Replica Island (available in Android Market)

    Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

    11. Aktualisierbare Software

    Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

    Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

    • Over-the-air (OTA) downloads with offline update via reboot
    • "Tethered" updates over USB from a host PC
    • "Offline" updates via a reboot and update from a file on removable storage

    The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

    If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

    12. Kontaktieren Sie uns

    You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

    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. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

    The test procedure is based on the BluetoothChat sample app included in the Android open source project tree. The procedure requires two devices:

    • a candidate device implementation running the software build to be tested
    • a separate device implementation already known to be compatible, and of a model from the device implementation being tested - that is, a "known good" device implementation

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

    Setup and 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.