Copyright © 2010, Google Inc. Alle Rechte vorbehalten.
Kompatibilität@android.com
1. Einleitung
In diesem Dokument werden die Anforderungen aufgeführt, die erfüllt sein müssen, damit Mobiltelefone mit Android 2.1 kompatibel sind.
Die Verwendung von „muss“, „darf nicht“, „erforderlich“, „shall“, „shall not“, „should“, „should not“, „recommended“, „may“ und „optional“ entspricht dem IETF-Standard definiert in RFC2119 [ Ressourcen, 1 ].
Wie in diesem Dokument verwendet, ist ein „Geräteimplementierer“ oder „Implementierer“ eine Person oder Organisation, die eine Hardware-/Softwarelösung mit Android 2.1 entwickelt. Eine „Geräteimplementierung“ oder „Implementierung“ ist die so entwickelte Hardware-/Softwarelösung.
Um als mit Android 2.1 kompatibel zu gelten, sind folgende Geräteimplementierungen erforderlich:
- MUSS die in dieser Kompatibilitätsdefinition dargelegten Anforderungen erfüllen, einschließlich aller durch Verweis einbezogenen Dokumente.
- MUSS die aktuellste Version der Android Compatibility Test Suite (CTS) bestehen, die zum Zeitpunkt der Fertigstellung der Geräteimplementierungssoftware verfügbar ist. (Das CTS ist als Teil des Android Open Source Project [ Ressourcen, 2 ] verfügbar.) Das CTS testet viele, aber nicht alle der in diesem Dokument beschriebenen Komponenten.
Wenn diese Definition oder das CTS stillschweigend, mehrdeutig oder unvollständig ist, liegt es in der Verantwortung des Geräteimplementierers, die Kompatibilität mit vorhandenen Implementierungen sicherzustellen. Aus diesem Grund ist das Android Open Source Project [ Ressourcen, 3 ] sowohl die Referenz als auch die bevorzugte Implementierung von Android. Geräteimplementierern wird dringend empfohlen, ihre Implementierungen auf dem „Upstream“-Quellcode zu basieren, der vom Android Open Source Project verfügbar ist. Obwohl einige Komponenten hypothetisch durch alternative Implementierungen ersetzt werden können, wird von dieser Praxis dringend abgeraten, da das Bestehen der CTS-Tests wesentlich schwieriger wird. Es liegt in der Verantwortung des Implementierers, die vollständige Verhaltenskompatibilität mit der Standard-Android-Implementierung sicherzustellen, einschließlich der Compatibility Test Suite und darüber hinaus. Beachten Sie abschließend, dass bestimmte Komponentenersetzungen und -modifikationen in diesem Dokument ausdrücklich verboten sind.
2. Ressourcen
Viele dieser Ressourcen stammen direkt oder indirekt vom Android 2.1 SDK und sind funktional identisch mit den Informationen in der Dokumentation dieses SDK . In allen Fällen, in denen diese Kompatibilitätsdefinition oder die Kompatibilitätstestsuite nicht mit der SDK-Dokumentation übereinstimmen, gilt die SDK-Dokumentation als maßgeblich. Alle in den oben aufgeführten Referenzen bereitgestellten technischen Details werden durch die Aufnahme als Teil dieser Kompatibilitätsdefinition betrachtet.
3. Software
Die Android-Plattform umfasst eine Reihe verwalteter APIs, eine Reihe nativer APIs und eine Reihe sogenannter „weicher“ APIs wie das Intent-System und Webanwendungs-APIs. In diesem Abschnitt werden die für die Kompatibilität wesentlichen Hard- und Soft-APIs sowie bestimmte andere relevante technische Verhaltensweisen und Verhaltensweisen der Benutzeroberfläche detailliert beschrieben. Geräteimplementierungen MÜSSEN alle Anforderungen in diesem Abschnitt erfüllen.
3.1. Verwaltete API-Kompatibilität
Die verwaltete (Dalvik-basierte) Ausführungsumgebung ist das primäre Vehikel für Android-Anwendungen. Bei der Android-Anwendungsprogrammierschnittstelle (API) handelt es sich um den Satz von Android-Plattformschnittstellen, die Anwendungen zur Verfügung gestellt werden, die in der verwalteten VM-Umgebung ausgeführt werden. Geräteimplementierungen MÜSSEN vollständige Implementierungen, einschließlich aller dokumentierten Verhaltensweisen, aller dokumentierten APIs bereitstellen, die vom Android 2.1 SDK bereitgestellt werden [ Ressourcen, 4 ].
Geräteimplementierungen DÜRFEN KEINE verwalteten APIs auslassen, API-Schnittstellen oder Signaturen ändern, vom dokumentierten Verhalten abweichen oder No-Ops enthalten, es sei denn, dies ist in dieser Kompatibilitätsdefinition ausdrücklich zulässig.
3.2. Soft-API-Kompatibilität
Zusätzlich zu den verwalteten APIs aus Abschnitt 3.1 enthält Android auch eine bedeutende, nur zur Laufzeit verfügbare „Soft“-API in Form von Dingen wie Absichten, Berechtigungen und ähnlichen Aspekten von Android-Anwendungen, die bei der Anwendung nicht erzwungen werden können Kompilierzeit. In diesem Abschnitt werden die „weichen“ APIs und Systemverhalten beschrieben, die für die Kompatibilität mit Android 2.1 erforderlich sind. Geräteimplementierungen MÜSSEN alle in diesem Abschnitt aufgeführten Anforderungen erfüllen.
3.2.1. Berechtigungen
Geräteimplementierer MÜSSEN alle Berechtigungskonstanten unterstützen und 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 2.1 MUSS dieses Feld den ganzzahligen Wert 7 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 an Endbenutzer versendet 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. 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.BRAND | Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Unternehmens, der Organisation, der Einzelperson 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. 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.DEVICE | Ein vom Geräteimplementierer ausgewählter Wert, der die spezifische Konfiguration oder Revision des Körpers (manchmal auch „Industriedesign“ genannt) des Geräts 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.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)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)Zum Beispiel: acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keysDer Fingerabdruck DARF KEINE Leerzeichen enthalten. Wenn andere in der obigen Vorlage enthaltene Felder Leerzeichen enthalten, SOLLTEN diese im Fingerabdruck durch den ASCII-Unterstrich („_“) ersetzt werden. |
| 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. 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 Geräts enthält. MUSS für Menschen lesbar sein, ist aber nicht unbedingt für die Anzeige durch Endbenutzer gedacht. 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.TAGS | Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt wurden und den Build weiter unterscheiden. Beispiel: „unsigned,debug“. Dieses Feld DARF NICHT null oder eine leere Zeichenfolge („“) sein, aber ein einzelnes Tag (z. B. „release“) ist in Ordnung. |
| 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“. |
| 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. Intent-Kompatibilität
Android verwendet Intents, um eine lose gekoppelte Integration zwischen Anwendungen zu erreichen. In diesem Abschnitt werden Anforderungen im Zusammenhang mit den Absichtsmustern beschrieben, die von Geräteimplementierungen berücksichtigt werden MÜSSEN. Mit „gewürdigt“ ist gemeint, dass der Geräteimplementierer eine Android-Aktivität oder einen Android-Dienst bereitstellen MUSS, der einen passenden Intent-Filter angibt und an jedes angegebene Intent-Muster bindet und das korrekte Verhalten implementiert.
3.2.3.1. Kernanwendungsabsichten
Das Android-Upstream-Projekt definiert eine Reihe von Kernanwendungen, wie z. B. einen Telefonwähler, einen Kalender, ein Kontaktbuch, einen Musikplayer usw. Geräteimplementierer KÖNNEN diese Anwendungen durch alternative Versionen ersetzen.
Allerdings MÜSSEN solche alternativen Versionen dieselben Absichtsmuster berücksichtigen, die vom Upstream-Projekt bereitgestellt werden. Wenn ein Gerät beispielsweise einen alternativen Musikplayer enthält, muss es dennoch das von Drittanbieteranwendungen ausgegebene Intent-Muster zur Auswahl eines Songs berücksichtigen.
Die folgenden Anwendungen gelten als Kernanwendungen des Android-Systems:
- Tischuhr ,
- Browser,
- Kalender,
- Rechner,
- Kamera ,
- Kontakte
- , E-Mail,
- Galerie
- , GlobalSearch
- Launcher
- , LivePicker (d. h. die Anwendung zur Auswahl von Live-Hintergründen; kann weggelassen werden, wenn das Gerät keine Live-Hintergründe gemäß Abschnitt 3.8.5 unterstützt). )
- Messaging (auch bekannt als „Mms“
- )
- Musik
- Telefoneinstellungen
- SoundRecorder
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äteimplementierer zulassen, dass jedes in Kernsystem-Apps definierte Absichtsmuster durch Anwendungen von Drittanbietern überschrieben wird. Das Upstream-Android-Open-Source-Projekt erlaubt dies standardmäßig; Geräteimplementierer DÜRFEN KEINE besonderen Privilegien für die Verwendung dieser Intent-Muster durch Systemanwendungen festlegen oder verhindern, dass Anwendungen Dritter sich an diese Muster binden und die Kontrolle über sie übernehmen. Dieses Verbot umfasst insbesondere die Deaktivierung der „Chooser“-Benutzeroberfläche, die es dem Benutzer ermöglicht, zwischen mehreren Anwendungen auszuwählen, die alle dasselbe Intent-Muster verarbeiten.
3.2.3.3. Intent-Namespaces
Geräteimplementierer DÜRFEN KEINE Android-Komponenten enthalten, die neue Intent- oder Broadcast-Intent-Muster mithilfe einer ACTION, CATEGORY oder einer anderen Schlüsselzeichenfolge im Namespace android.* berücksichtigen. Geräteimplementierer DÜRFEN KEINE Android-Komponenten einschließen, die neue Intent- oder Broadcast-Intent-Muster mithilfe einer ACTION, CATEGORY oder einer anderen Schlüsselzeichenfolge in einem Paketbereich einer anderen Organisation berücksichtigen. Geräteimplementierer DÜRFEN KEINE Absichtsmuster ändern oder erweitern, die von den in Abschnitt 3.2.3.1 aufgeführten Kern-Apps verwendet werden.
Dieses Verbot ist analog zu dem für Java-Sprachklassen in Abschnitt 3.6 festgelegten.
3.2.3.4. Broadcast Intents
Anwendungen von Drittanbietern verlassen sich darauf, dass die Plattform bestimmte Intents 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
Verwalteter Code, der in Dalvik ausgeführt wird, kann nativen Code aufrufen, der in der APK-Datei der Anwendung als ELF-SO-Datei bereitgestellt wird, die für die entsprechende Hardwarearchitektur des Geräts kompiliert wurde. Geräteimplementierungen MÜSSEN Unterstützung für Code enthalten, der in der verwalteten Umgebung ausgeführt wird, um nativen Code unter Verwendung der standardmäßigen JNI-Semantik (Java Native Interface) aufzurufen. Die folgenden APIs MÜSSEN für nativen Code verfügbar sein:
- libc (C-Bibliothek)
- libm (Mathe-Bibliothek)
- JNI-Schnittstelle
- libz (Zlib-Komprimierung)
- liblog (Android-Protokollierung)
- Minimale Unterstützung für C++
- Unterstützung für OpenGL, wie unten beschrieben
Geräteimplementierungen MÜSSEN OpenGL ES 1.0 unterstützen . Geräte ohne Hardwarebeschleunigung MÜSSEN OpenGL ES 1.0 mithilfe eines Software-Renderers implementieren. Geräteimplementierungen SOLLTEN so viel von OpenGL ES 1.1 implementieren, wie die Gerätehardware unterstützt. Geräteimplementierungen SOLLTEN eine Implementierung für OpenGL ES 2.0 bereitstellen, wenn die Hardware auf diesen APIs eine angemessene Leistung erbringen kann.
Diese Bibliotheken MÜSSEN quellkompatibel (dh Header-kompatibel) und binärkompatibel (für eine bestimmte Prozessorarchitektur) mit den vom Android Open Source-Projekt in Bionic bereitgestellten Versionen sein. Da die Bionic-Implementierungen nicht vollständig mit anderen Implementierungen wie der GNU C-Bibliothek kompatibel sind, SOLLTEN Geräteimplementierer die Android-Implementierung verwenden. Wenn Geräteimplementierer eine andere Implementierung dieser Bibliotheken verwenden, MÜSSEN sie Header-, Binär- und Verhaltenskompatibilität sicherstellen.
Geräteimplementierungen MÜSSEN die vom Gerät unterstützte native Application Binary Interface (ABI) über die android.os.Build.CPU_ABI API genau melden. Der ABI MUSS einer der Einträge sein, die in der neuesten Version des Android NDK in der Datei docs/CPU-ARCH-ABIS.txt dokumentiert sind. Beachten Sie, dass zusätzliche Versionen des Android NDK möglicherweise Unterstützung für zusätzliche ABIs einführen.
Die Kompatibilität mit nativem Code ist eine Herausforderung. Aus diesem Grund sollte wiederholt werden, dass Geräteimplementierern SEHR dringend empfohlen wird, die Upstream-Implementierungen der oben aufgeführten Bibliotheken zu verwenden, um die Kompatibilität sicherzustellen.
3.4. Web-API-Kompatibilität
Viele Entwickler und Anwendungen verlassen sich für ihre Benutzeroberflächen auf das Verhalten der android.webkit.WebView Klasse [ Ressourcen, 8 ], daher muss die WebView-Implementierung mit allen Android-Implementierungen kompatibel sein. Die Android Open Source-Implementierung verwendet die WebKit-Rendering-Engine, um WebView zu implementieren.
Da es nicht möglich ist, eine umfassende Testsuite für einen Webbrowser zu entwickeln, MÜSSEN Geräteimplementierer den spezifischen Upstream-Build von WebKit in der WebView-Implementierung verwenden. Konkret:
- WebView MUSS den 530.17 WebKit-Build aus dem Upstream-Android-Open-Source-Baum für Android 2.1 verwenden. Dieser Build enthält einen bestimmten Satz an Funktionen und Sicherheitskorrekturen für WebView.
- Die von WebView gemeldete Benutzeragentenzeichenfolge MUSS in diesem Format vorliegen:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17- der Die Zeichenfolge $(VERSION) MUSS mit dem Wert für
android.os.Build.VERSION.RELEASEidentisch sein. - Der Wert der Zeichenfolge $(LOCALE) SOLLTE den ISO-Konventionen für Ländercode und Sprache entsprechen und sich auf das aktuell konfigurierte Gebietsschema beziehen des Geräts
- Der Wert der Zeichenfolge $(MODEL) MUSS mit dem Wert für
android.os.Build.MODELidentisch sein. - Der Wert der Zeichenfolge $(BUILD) MUSS mit dem Wert für
android.os.Build.ID
- der Die Zeichenfolge $(VERSION) MUSS mit dem Wert für
Implementierungen liefern möglicherweise eine benutzerdefinierte Benutzeragentenzeichenfolge in der eigenständigen Browseranwendung. Darüber hinaus KANN der eigenständige Browser auf einer alternativen Browsertechnologie (wie Firefox, Opera usw.) basieren. Selbst wenn jedoch eine alternative Browseranwendung ausgeliefert wird, MUSS die WebView-Komponente, die Drittanbieteranwendungen bereitgestellt wird, auf WebKit basieren. wie oben.
Die WebView-Konfiguration MUSS Unterstützung für die HTML5-Datenbank, den Anwendungscache und Geolocation-APIs umfassen [ Ressourcen, 9 ]. Das WebView MUSS in irgendeiner Form Unterstützung für das HTML5- <video> -Tag enthalten. Die eigenständige Browseranwendung (unabhängig davon, ob sie auf der Upstream-WebKit-Browseranwendung oder einem Ersatz eines Drittanbieters basiert) MUSS Unterstützung für dieselben HTML5-Funktionen bieten, die gerade für WebView aufgeführt wurden.
3.5. API-Verhaltenskompatibilität
Das Verhalten jedes API-Typs (verwaltet, Soft, nativ und Web) muss mit der bevorzugten Implementierung des Upstream-Android-Open-Source-Projekts übereinstimmen [ Ressourcen, 3 ]. Einige spezifische Bereiche der Kompatibilität sind:
- Geräte DÜRFEN das Verhalten oder die Bedeutung eines Standardabsichts NICHT ändern.
- Geräte DÜRFEN den Lebenszyklus oder die Lebenszyklussemantik eines bestimmten Typs von Systemkomponenten (z. B. Dienst, Aktivität, ContentProvider usw.) NICHT ändern.
- Geräte DÜRFEN NICHT ändern
- Ändern Sie die Semantik einer bestimmten Berechtigung.
Die obige Liste ist nicht vollständig und es liegt in der Verantwortung der Geräteimplementierer, die Verhaltenskompatibilität sicherzustellen. Aus diesem Grund SOLLTEN Geräteimplementierer nach Möglichkeit den über das Android Open Source Project verfügbaren Quellcode verwenden, anstatt wesentliche Teile des Systems neu zu implementieren.
Die Compatibility Test Suite (CTS) testet wesentliche Teile der Plattform auf Verhaltenskompatibilität, jedoch nicht alle. Es liegt in der Verantwortung des Implementierers, die Verhaltenskompatibilität mit dem Android Open Source Project sicherzustellen.
3.6. API-Namespaces
Android folgt den von der Programmiersprache Java definierten Paket- und Klassen-Namespace-Konventionen. Um die Kompatibilität mit Anwendungen von Drittanbietern sicherzustellen, DÜRFEN Geräteimplementierer KEINE verbotenen Änderungen (siehe unten) an diesen Paket-Namespaces vornehmen:
- java.*
- javax.*
- sun.*
- android.*
- com.android.* Zu den
verbotenen Änderungen gehören:
- Geräteimplementierungen MÜSSEN Ändern Sie die öffentlich zugänglichen APIs auf der Android-Plattform NICHT, indem Sie Methoden- oder Klassensignaturen ändern oder Klassen oder Klassenfelder entfernen.
- Geräteimplementierer KÖNNEN die zugrunde liegende Implementierung der APIs ändern, aber solche Änderungen DÜRFEN KEINE Auswirkungen auf das angegebene Verhalten und die Java-Sprachsignatur von öffentlich zugänglichen APIs haben.
- Geräteimplementierer DÜRFEN KEINE öffentlich zugänglichen Elemente (wie Klassen oder Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) zu den oben genannten APIs hinzufügen.
Ein „öffentlich zugängliches Element“ ist jedes Konstrukt, das im ursprünglichen Android-Quellcode nicht mit der Markierung „@hide“ versehen ist. Mit anderen Worten: Geräteimplementierer DÜRFEN KEINE neuen APIs offenlegen oder bestehende APIs in den oben genannten Namespaces ändern. Geräteimplementierer KÖNNEN nur interne Änderungen vornehmen, diese Änderungen DÜRFEN jedoch NICHT angekündigt oder anderweitig den Entwicklern zugänglich gemacht werden.
Geräteimplementierer KÖNNEN benutzerdefinierte APIs hinzufügen, solche APIs DÜRFEN sich jedoch NICHT in einem Namensraum befinden, der einer anderen Organisation gehört oder auf diese verweist. Beispielsweise DÜRFEN Geräteimplementierer KEINE APIs zum com.google.* oder einem ähnlichen Namespace hinzufügen; Nur Google darf dies tun. Ebenso DARF Google KEINE APIs zu den Namespaces anderer Unternehmen hinzufügen.
Wenn ein Geräteimplementierer vorschlägt, einen der oben genannten Paketnamensräume zu verbessern (z. B. durch das Hinzufügen nützlicher neuer Funktionen zu einer vorhandenen API oder das Hinzufügen einer neuen API), SOLLTE der Implementierer source.android.com besuchen und mit dem Prozess zum Einbringen von Änderungen beginnen Code, gemäß den Informationen auf dieser Website.
Beachten Sie, dass die oben genannten Einschränkungen den Standardkonventionen für die Benennung von APIs in der Programmiersprache Java entsprechen; Dieser Abschnitt zielt lediglich darauf ab, diese Konventionen zu stärken und sie durch die Aufnahme in diese Kompatibilitätsdefinition verbindlich zu machen.
3.7. Kompatibilität mit virtuellen Maschinen
Geräteimplementierungen MÜSSEN die vollständige Dalvik Executable (DEX)-Bytecode-Spezifikation und die Dalvik Virtual Machine-Semantik unterstützen [ Ressourcen, 10 ].
Geräteimplementierungen MÜSSEN Dalvik so konfigurieren, dass jeder Anwendung auf Geräten mit Bildschirmen, die als mittlere oder niedrige Dichte eingestuft sind, mindestens 16 MB Speicher zugewiesen werden. Geräteimplementierungen MÜSSEN Dalvik so konfigurieren, dass jeder Anwendung auf Geräten mit Bildschirmen, die als hochdicht eingestuft sind, mindestens 24 MB Speicher zugewiesen werden. Beachten Sie, dass Geräteimplementierungen möglicherweise mehr Speicher als diese Zahlen zuweisen, dies jedoch nicht erforderlich ist.
3.8. Kompatibilität der Benutzeroberfläche
Die Android-Plattform umfasst einige Entwickler-APIs, die es Entwicklern ermöglichen, sich in die Benutzeroberfläche des Systems einzubinden. Geräteimplementierungen MÜSSEN diese Standard-UI-APIs in die von ihnen entwickelten benutzerdefinierten Benutzeroberflächen integrieren, wie unten erläutert.
3.8.1. Widgets
Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, die es Anwendungen ermöglichen, dem Endbenutzer ein „AppWidget“ zur Verfügung zu stellen [ Ressourcen, 11 ]. Die Android Open Source-Referenzversion enthält eine Launcher-Anwendung mit Elementen der Benutzeroberfläche, mit denen der Benutzer AppWidgets zum Startbildschirm hinzufügen, anzeigen und entfernen kann.
Geräteimplementierer KÖNNEN eine Alternative zum Referenz-Launcher (z. B. Startbildschirm) ersetzen. Alternative Launcher SOLLTEN integrierte Unterstützung für AppWidgets enthalten und Elemente der Benutzeroberfläche verfügbar machen, um AppWidgets direkt im Launcher hinzuzufügen, zu konfigurieren, anzuzeigen und zu entfernen. Alternative Launcher können diese Elemente der Benutzeroberfläche weglassen; Wenn sie jedoch weggelassen werden, MUSS der Geräteimplementierer eine separate Anwendung bereitstellen, auf die über den Launcher zugegriffen werden kann und die es Benutzern ermöglicht, AppWidgets hinzuzufügen, zu konfigurieren, anzuzeigen und zu entfernen.
3.8.2. Benachrichtigungen
Android enthält APIs, die es Entwicklern ermöglichen, Benutzer über wichtige Ereignisse zu benachrichtigen [ Ressourcen, 12 ]. Geräteimplementierer MÜSSEN Unterstützung für jede so definierte Benachrichtigungsklasse bereitstellen; Konkret: Töne, Vibration, Licht und Statusleiste.
Darüber hinaus MUSS die Implementierung alle in den APIs [ Ressourcen, 13 ] oder im Stilleitfaden für Statusleistensymbole [ Ressourcen, 14 ] bereitgestellten Ressourcen (Symbole, Sounddateien usw.) korrekt rendern. Geräteimplementierer KÖNNEN eine alternative Benutzererfahrung für Benachrichtigungen bieten als die Referenz-Android-Open-Source-Implementierung; Allerdings MÜSSEN solche alternativen Benachrichtigungssysteme vorhandene Benachrichtigungsressourcen unterstützen, wie oben beschrieben.
3.8.3. Search
Android umfasst APIs [ Ressourcen, 15 ], die es Entwicklern ermöglichen, die Suche in ihre Anwendungen zu integrieren und die Daten ihrer Anwendung in der globalen Systemsuche verfügbar zu machen. Im Allgemeinen besteht diese Funktionalität aus einer einzigen, systemweiten Benutzeroberfläche, die es Benutzern ermöglicht, Abfragen einzugeben, während der Benutzereingabe Vorschläge anzeigt und Ergebnisse anzeigt. Die Android-APIs ermöglichen es Entwicklern, diese Schnittstelle wiederzuverwenden, um eine Suche in ihren eigenen Apps bereitzustellen, und ermöglichen es Entwicklern, Ergebnisse an die gemeinsame Benutzeroberfläche für die globale Suche bereitzustellen.
Geräteimplementierungen MÜSSEN eine einzige, gemeinsame, systemweite Suchbenutzeroberfläche umfassen, die als Reaktion auf Benutzereingaben Echtzeitvorschläge machen kann. Geräteimplementierungen MÜSSEN die APIs implementieren, die es Entwicklern ermöglichen, diese Benutzeroberfläche wiederzuverwenden, um die Suche in ihren eigenen Anwendungen bereitzustellen. Geräteimplementierungen MÜSSEN die APIs implementieren, die es Drittanbieteranwendungen ermöglichen, Vorschläge zum Suchfeld hinzuzufügen, wenn es im globalen Suchmodus ausgeführt wird. Wenn keine Anwendungen von Drittanbietern installiert sind, die diese Funktionalität nutzen, SOLLTE das Standardverhalten darin bestehen, Ergebnisse und Vorschläge von Websuchmaschinen anzuzeigen.
Geräteimplementierungen KÖNNEN alternative Benutzeroberflächen für die Suche bereitstellen, SOLLTEN jedoch eine dedizierte Hard- oder Soft-Suchschaltfläche enthalten, die jederzeit in jeder App verwendet werden kann, um das Such-Framework aufzurufen, mit dem in der API-Dokumentation vorgesehenen Verhalten.
3.8.4. Toasts-
Anwendungen können die „Toast“-API (definiert in [ Ressourcen, 16 ]) verwenden, um dem Endbenutzer kurze nichtmodale Zeichenfolgen anzuzeigen, die nach kurzer Zeit verschwinden. Geräteimplementierungen MÜSSEN Toasts von Anwendungen an Endbenutzer gut sichtbar anzeigen.
3.8.5. Live Wallpapers
Android definiert einen Komponententyp und eine entsprechende API und einen Lebenszyklus, die es Anwendungen ermöglichen, dem Endbenutzer ein oder mehrere „Live Wallpapers“ zur Verfügung zu stellen [ Ressourcen, 17 ]. Live-Hintergründe sind Animationen, Muster oder ähnliche Bilder mit eingeschränkten Eingabemöglichkeiten, die als Hintergrund hinter anderen Anwendungen angezeigt werden.
Es wird davon ausgegangen, dass Hardware Live-Hintergründe zuverlässig ausführen kann, wenn sie alle Live-Hintergründe ohne Funktionseinschränkungen und mit einer angemessenen Bildrate ohne nachteilige Auswirkungen auf andere Anwendungen ausführen kann. Wenn Einschränkungen in der Hardware dazu führen, dass Hintergrundbilder und/oder Anwendungen abstürzen, nicht richtig funktionieren, übermäßig viel CPU- oder Akkuleistung verbrauchen oder mit unzulässig niedrigen Bildraten laufen, wird davon ausgegangen, dass die Hardware nicht in der Lage ist, Live-Hintergrundbilder auszuführen. Einige Live-Hintergründe können beispielsweise einen Open GL 1.0- oder 2.0-Kontext verwenden, um ihren Inhalt darzustellen. Das Live-Hintergrundbild wird auf Hardware, die nicht mehrere OpenGL-Kontexte unterstützt, nicht zuverlässig ausgeführt, da die Verwendung eines OpenGL-Kontexts durch das Live-Hintergrundbild möglicherweise mit anderen Anwendungen in Konflikt steht, die ebenfalls einen OpenGL-Kontext verwenden.
Geräteimplementierungen, die Live-Hintergründe wie oben beschrieben zuverlässig ausführen können, SOLLTEN Live-Hintergründe implementieren. Geräteimplementierungen, bei denen Live-Hintergründe wie oben beschrieben nicht zuverlässig ausgeführt werden, DÜRFEN KEINE Live-Hintergründe implementieren.
4. Referenzsoftwarekompatibilität
Geräteimplementierer MÜSSEN die Implementierungskompatibilität mit den folgenden Open-Source-Anwendungen testen:
- Taschenrechner (im SDK enthalten)
- Lunar Lander (im SDK enthalten)
- Die „Apps für Android“-Anwendungen [ Ressourcen, 18 ].
Jede der oben genannten Apps MUSS gestartet werden und sich bei der Implementierung korrekt verhalten, damit die Implementierung als kompatibel gilt.
Darüber hinaus MÜSSEN Geräteimplementierungen jedes Menüelement (einschließlich aller Untermenüs) jeder dieser Rauchtestanwendungen testen:
- ApiDemos (im SDK enthalten)
- ManualSmokeTests (im CTS enthalten)
Jeder Testfall in den oben genannten Anwendungen MUSS ordnungsgemäß auf dem Gerät ausgeführt werden Implementierung.
5. Anwendungspaketkompatibilität
Geräteimplementierungen MÜSSEN Android-„.apk“-Dateien installieren und ausführen, wie sie vom „aapt“-Tool generiert wurden, das im offiziellen Android SDK enthalten ist [ Ressourcen, 19 ].
Geräteimplementierungen DÜRFEN die Formate .apk [ Ressourcen, 20 ], Android Manifest [ Ressourcen, 21 ] oder Dalvik-Bytecode [ Ressourcen, 10 ] NICHT so erweitern, dass diese Dateien daran gehindert werden, auf anderen kompatiblen Geräten ordnungsgemäß installiert und ausgeführt zu werden . Geräteimplementierer SOLLTEN die Referenz-Upstream-Implementierung von Dalvik und das Paketverwaltungssystem der Referenzimplementierung verwenden.
6. Multimedia-Kompatibilität
Geräteimplementierungen MÜSSEN die folgenden Multimedia-Codecs unterstützen. Alle diese Codecs werden als 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. Wer beabsichtigt, diesen Quellcode in Hardware- oder Softwareprodukten zu verwenden, wird darauf hingewiesen, dass für Implementierungen dieses Codes, auch in Open-Source-Software oder Shareware, möglicherweise Patentlizenzen der jeweiligen Patentinhaber erforderlich sind.
| Audioname | ||||
| Encoder | - | Decoder- | Details | Datei-/Containerformat |
| AAC LC/LTP | X | Mono-/Stereo-Inhalte in jeder Kombination aus Standardbitraten bis zu 160 kbps und Abtastraten zwischen 8 und 48 kHz | 3GPP (.3gp) und MPEG-4 (.mp4, .m4a). Keine Unterstützung für rohes AAC (.aac) | |
| HE-AACv1 (AAC+) | X | |||
| HE-AACv2 (erweitertes AAC+) | X | |||
| AMR-NB | X | X | 4,75 bis 12,2 kbps abgetastet bei 8 kHz | 3GPP (0,3 gp) |
| AMR-WB | X | 9-Raten von 6,60 kbit/s bis 23,85 kbit/s, abgetastet bei 16 kHz | 3GPP (.3gp) | |
| MP3 | X | Mono/Stereo 8-320 Kbit/s mit konstanter (CBR) oder variabler Bitrate (VBR) | MP3 (.mp3) | |
| MIDI | X | MIDI Typ 0 und 1. DLS Version 1 und 2. XMF und Mobile XMF. Unterstützung für Klingeltonformate RTTTL/RTX, OTA und Imelody | Typ 0 und 1 (.MID, .xmf, .mxmf). Auch rtttl/rtx (.rtttl, .rtx), ota (.ota) und Imelody (.imy) | |
| ogg vorbis | X | OGG (.ogg) | ||
| PCM | X | 8- und 16-Bit-lineare PCM-PCM (Raten bis zur Grenze der Hardware) | Welle (.wav) | |
| Bild | ||||
| JPEG | X | X | Basis+Progressive | |
| GIF | X | |||
| Png | x | x | ||
| BMP | X | |||
| Video | ||||
| H.263 | x | x | 3GPP (.3GP) Dateien | |
| H.264 | X | 3GPP (.3GP) und MPEG-4 (.MP4) -Dateien | ||
| MPEG4 Einfaches Profil | X | 3GPP (.3GP) Datei |
Beachten Sie, dass in der obigen Tabelle die spezifischen Bitrate -Anforderungen für die meisten Video -Codecs nicht aufgeführt sind. Der Grund dafür ist, dass in der Praxis die aktuelle Gerätehardware nicht unbedingt Bitrate unterstützt, die genau den erforderlichen Bitraten zuordnen, die nach den entsprechenden Standards angegeben sind. Stattdessen sollten Geräteimplementierungen das höchste Bitrate -Praktikum auf der Hardware bis hin zu den durch die Spezifikationen definierten Grenzen unterstützen.
7. Implementierungen für Entwickler -Toolkompatibilitätsgeräte
müssen die im Android SDK bereitgestellten Android -Entwickler -Tools unterstützen. Insbesondere müssen Android-kompatible Geräte kompatibel sein mit:
- Android-Debug-Brücke (bekannt als ADB) [ Ressourcen, 19 ]
Geräteimplementierungen müssen alleadb-Funktionen unterstützen, wie sie im Android SDK dokumentiert sind. Der Gerätseiten-adbDaemon sollte standardmäßig inaktiv sein, aber es muss einen benutzergerechten Mechanismus geben, um die Android-Debug-Brücke einzuschalten. - DALVIK DEBUG Monitor Service (bekannt als DDMS) [ Ressourcen, 19 ]
Geräteimplementierungen müssen alleddms-Funktionen unterstützen, wie sie im Android SDK dokumentiert sind. Daddmsadbverwendet, sollte die Unterstützung fürddmsstandardmäßig inaktiv sein, muss jedoch wie oben der Benutzer die Android -Debug -Brücke aktiviert werden. - Affe [ Ressourcen, 22 ]
Die Geräteimplementierungen müssen das Monkey -Framework enthalten und die Verwendung von Anwendungen zur Verfügung stellen.
8. Hardwarekompatibilität
Android soll Geräteimplementierer unterstützen, die innovative Formularfaktoren und Konfigurationen erstellen. Gleichzeitig erwarten Android -Entwickler bestimmte Hardware, Sensoren und APIs im gesamten Android -Gerät. In diesem Abschnitt werden die Hardwarefunktionen aufgeführt, die alle Android 2.1 -kompatiblen Geräte unterstützen müssen.
Wenn ein Gerät eine bestimmte Hardwarekomponente enthält, die über eine entsprechende API für Entwickler von Drittanbietern verfügt, muss die Geräteimplementierung diese in der Android SDK-Dokumentation definierte API implementieren. Wenn eine API in der SDK mit einer Hardwarekomponente interagiert, die als optional angegeben ist, und die Geräteimplementierung nicht über diese Komponente besitzt:
- Klassendefinitionen
- für die API der Komponente müssen vorhanden sein.
- API-Methoden müssen Nullwerte zurückgeben, sodass von den SDK-Dokumentations
- -API-Methoden keine Implementierungen von Klassen zurückgeben müssen, bei denen Nullwerte von der SDK-Dokumentation nicht zulässig sind .
Ein typisches Beispiel für ein Szenario, in dem diese Anforderungen gelten -Phone-Geräte müssen diese APIs als angemessene No-Ops implementiert werden.
Geräteimplementierungen müssen genaue Bericht über genaue Hardwarekonfigurationsinformationen über die Methoden getSystemAvailableFeatures() und hasSystemFeature(String) auf der Klasse android.content.pm.PackageManager String) -Methoden (String).
8.1. Display
Android 2.1 enthält Einrichtungen, die bestimmte automatische Skalierungs- und Transformationsvorgänge unter bestimmten Umständen durchführen, um sicherzustellen, dass Drittanbieter Anwendungen für eine Vielzahl von Hardwarekonfigurationen einigermaßen gut laufen [ Ressourcen, 23 ]. Geräte müssen diese Verhaltensweisen ordnungsgemäß implementieren, wie in diesem Abschnitt beschrieben.
Für Android 2.1 sind dies die häufigsten Display -Konfigurationen:
| Bildschirmtypbreite | (Pixel) | Höhe (Pixel) | Diagonal Länge (Zoll) | Bildschirmgröße Gruppengröße | Bildschirmdichte Gruppe |
| QVGA | 240 | 320 | 2,6 - 3,0 | Kleine | niedrige |
| WQVGA | 240 | 400 | 3.2 - 3,5 | Normal | niedrig |
| FWQVGA | 240 | 432 | 3.5 - 3.8 | Normal | Low |
| HVGA | 320 | 480 | 3.0 - 3.5 | Normal | Medium |
| WVGA | 480 | 800 | 3.3 - 4.0 | Normal | High |
| FWVGA | 480 | 854 | 3.5 - 4.0 | Normal | High |
| WVGA | 480 | 800 | 4.8 - 5.5 | Large | Medium |
| FWVGA | 480 | 854 | 5.0 - 5.8 | Large | Medium |
Device implementations Entsprechend einer der obigen Standardkonfigurationen muss so konfiguriert sein, dass die angegebene Bildschirmgröße über die android.content.res.Configuration [ Ressourcen, 24 ] -Klasse meldet.
Einige .APK -Pakete haben Manifests, die sie nicht als die Unterstützung eines bestimmten Dichtebereichs identifizieren. Beim Ausführen solcher Anwendungen gelten die folgenden Einschränkungen:
- Geräteimplementierungen müssen Ressourcen in einem .APK interpretieren, bei denen eine Dichtequalifikatorin als "Medium" (in der SDK -Dokumentation bezeichnet "bezeichnet wird
- . Bildschirm, Geräteimplementierungen müssen die Medium/MDPI -Vermögenswerte um einen Faktor von 0,75 skalieren.
- Beim Betrieb auf einem "hohen" Dichtebildschirm müssen Geräteimplementierungen das Medium/MDPI -Vermögen um einen Faktor 1,5 skalieren.
- Geräteimplementierungen dürfen die Vermögenswerte nicht innerhalb eines Dichtebereichs skalieren und müssen die Vermögenswerte nach genau diesen Faktoren zwischen den Dichtebereichen skalieren.
8.1.2. Nicht standardmäßige Display-Konfigurationen
Display-Konfigurationen, die nicht mit einer der in Abschnitt 8.1.1 aufgeführten Standardkonfigurationen übereinstimmen, erfordern zusätzliche Überlegungen und Arbeiten, um kompatibel zu sein. Geräteimplementierer müssen sich wie in Abschnitt 12 vorgesehene Android-Kompatibilitätsteam wenden, um Klassifizierungen für Bucket, Dichte und Skalierungsfaktor in der Bildschirmgröße zu erhalten. Bei dieser Informationen müssen Geräteimplementierungen sie wie angegeben implementieren.
Beachten Sie, dass einige Anzeigenkonfigurationen (z. B. sehr große oder sehr kleine Bildschirme und einige Seitenverhältnisse) mit Android 2.1 grundsätzlich nicht kompatibel sind. Daher werden Geräteimplementierer aufgefordert, sich im Entwicklungsprozess so früh wie möglich auf das Android -Kompatibilitätsteam zu wenden.
8.1.3.
Implementierungen fürdie Geräteimplementierung von Metriken
müssen korrekte Werte für alle in android.util.DisplayMetrics [ Ressourcen, 25 ] definierten Anzeigenmetriken melden.
8.2.
Implementierungendes Tastaturgeräts
:
- Muss die Unterstützung für das Eingabeverwaltungs -Framework (sodass Entwickler von Drittanbietern es ermöglichen, Input -Management -Engines zu erstellen - dh Soft -Tastatur), wie bei Entwickler detailliert. Undroid.com
- muss mindestens eine Implementierung von Soft -Tastaturen bereitstellen (unabhängig davon, ob a Hardtastatur ist vorhanden)
- kann zusätzliche Implementierungen für Softtastaturen enthalten .
- Eine Hardware -Tastatur
- darf keine Hardware -Tastatur enthalten, die nicht mit einem der in
android.content.res.Configuration.keyboardangegebenen Formate übereinstimmt. QWERTY oder 12-TEY)
8.3.
Implementierungen vonNicht-Touch-
Navigationsgeräten:
- Möglicherweise muss eine Nicht-Touch-Navigationsoptionen (dh ein Trackball, ein D-Pad oder ein Rad weglassen),
- den korrekten Wert für
android.content.res.Configuration.navigation[ Ressourcen, 24, melden müssen. ]
8.4.
Kompatible Gerätemit Bildschirmorientierung
müssen die dynamische Ausrichtung durch Anwendungen für die Porträt- oder Landschaftsbildschirmorientierung unterstützen. Das heißt, das Gerät muss die Anfrage der Anwendung nach einer bestimmten Bildschirmausrichtung respektieren. Geräteimplementierungen können entweder eine Porträt- oder Landschaftsorientierung als Standardeinstellung auswählen.
Geräte müssen den richtigen Wert für die aktuelle Ausrichtung des Geräts melden, wenn er über die Android.content.res.configuration.orientation, android.view.Display.Getorientation () oder andere APIs abgefragt wird.
8.5.
Implementierungendes Touchscreen -Eingabegeräts
:
- Muss über einen Touchscreen verfügen.
- Möglicherweise
- muss der Wert von
android.content.res.Configuration[ Ressourcen, 24 ] entsprechend dem Typ des spezifischen Touchscreen auf dem Gerät
8.6 den Wert von Android melden. USB-
Geräteimplementierungen:
- Muss einen USB-Client implementieren, der mit einem
- USB
- -Host mit einem Standard-USB-A-Port verbunden werden
- kann
- An das Gerät, um auf den Inhalt des /sdcard-Volumens zuzugreifen,
- sollte der Micro-USB-Formfaktor auf der Geräteseite
- einen nicht standardmäßigen Anschluss auf der Geräteseite enthalten. Wenn dies jedoch mit einem Kabel versendet werden muss, das die benutzerdefinierte Pinout anschließen kann Standard USB-A Port
8.7. Navigationschlüsse
Das Haus-, Menü und die Rückfunktionen sind für das Android -Navigationsparadigma von wesentlicher Bedeutung. Geräteimplementierungen müssen diese Funktionen dem Benutzer jederzeit zur Verfügung stellen, unabhängig vom Anwendungszustand. Diese Funktionen sollten über dedizierte Schaltflächen implementiert werden. Sie können mit Software, Gesten, Touch Panel usw. implementiert werden. In diesem Fall müssen sie jedoch immer zugänglich sein und nicht den verfügbaren Anwendungsdisplayerbereich.
Geräteimplementierer sollten auch einen dedizierten Suchschlüssel bereitstellen. Geräteimplementierer können auch Sende- und Endschlüssel für Telefonanrufe bereitstellen.
8.8.
Implementierungendes drahtlosen Datennetzwerkgeräts
müssen die Unterstützung für drahtlose Hochgeschwindigkeitsdatennetzwerke enthalten. Insbesondere müssen Geräteimplementierungen die Unterstützung für mindestens einen drahtlosen Datenstandard von 200 kbit/s oder höher enthalten.
Beispiele fürTechnologien,
die diese Anforderung erfüllen
Die Implementierung muss die API unterstützen.
Geräte können mehr als eine Form der drahtlosen Datenkonnektivität implementieren. Geräte können verdrahtete Datenkonnektivität (wie Ethernet) implementieren, müssen jedoch wie oben oben mindestens eine Form der drahtlosen Konnektivität enthalten.
8.9.
Die Implementierungendes Kameratgeräts
müssen eine Kamera enthalten. Die mitgelieferte Kamera:
- Muss eine Auflösung von mindestens 2 Megapixeln haben
- , sollte entweder Hardware-automatisch-fokus oder im Kamera-Treiber implementiertes Software-Auto-Fokus haben,
- kann möglicherweise einen festen Fokus oder EDOF (erweiterte Feldtiefe) aufweisen (eine Feldtiefe). Hardware
- kann einen Blitz beinhalten. Wenn die Kamera einen Blitz enthält, darf die Blitzlampe nicht
FLASH_MODE_ONwerden, während eineFLASH_MODE_AUTO-Instanz auf einer Kamera -Vorschau -Oberfläche registriert wurde, es sei dennCamera.ParametersObjekt. Beachten Sie, dass diese Einschränkung nicht für die integrierte Systemkamera-Anwendung des Geräts, sondern nur für Anwendungen von Drittanbietern mitCamera.PreviewCallbackgelten.
Geräteimplementierungen müssen die folgenden Verhaltensweisen für die Kamera-bezogene APIs implementieren:
- Wenn eine Anwendung nie Android.hardware.camera.Parameters.setPreviewFormat (int) genannt hat, muss das Gerät Android.hardware.pixelformat.YCBCR_420_SP für Vorschau-Daten verwenden. Anwendungsrufe.
- Wenn eine Anwendung eine android.hardware.camera.PreviewCallback -Instanz und das System auf die OnPreviewFrame () -Methode aufruft, wenn das Vorschau -Format YCBCR_420_SP ist, müssen die Daten im BYTE [] in das OnPreviewFrame () übergeben () müssen das NV21 -Codierungsformat weiter sein. (Dies ist das Format, das nativ von der 7K -Hardwarefamilie verwendet wird.) Das heißt, Nv21 muss der Standard sein.
Geräteimplementierungen müssen die vollständige Kamera -API implementieren, die in der Android 2.1 SDK -Dokumentation [ Ressourcen, 26 ]) enthalten ist, unabhängig davon, ob das Gerät Hardware -Autofokus oder andere Funktionen enthält.
Zum Beispielmüssen
Kameras, denen android.hardware.Camera.AutoFocusCallback mangelt
android.hardware.Camera.Parameters Klasse, 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 der android.hardware.Camera.setParameters() -Methode übergebenen String -Konstanten ehren oder anerkennen, die nicht als Konstanten auf der android.hardware.Camera.Parameters dokumentiert sind, es sei denn Name des Geräteimplementierers. Das heißt, Geräteimplementierungen müssen alle Standard-Kameraparameter unterstützen, wenn die Hardware zulässt, und dürfen keine benutzerdefinierten Kamera-Parametertypen unterstützen, es sei denn, die Parameternamen werden über ein String-Präfix eindeutig angezeigt, um nicht standardmäßig zu sein.
8.10.
Die Implementierungen desBeschleunigungsmessers
müssen einen 3-Achsen-Beschleunigungsmesser enthalten und in der Lage sein, Ereignisse zu 50 Hz oder mehr zu liefern. Das vom Beschleunigungsmesser verwendete Koordinatensystem muss dem Android -Sensorkoordinatensystem gemäß den Android -APIs entsprechen (siehe [ Ressourcen, 27 ]).
8.11.
Die Implementierungenvon Kompassgeräten
müssen einen 3-Achsen-Kompass enthalten und in der Lage sein, Ereignisse 10 Hz oder höher zu liefern. Das vom Kompass verwendete Koordinatensystem muss dem Android -Sensorkoordinatensystem gemäß der Android -API entsprechen (siehe [ Ressourcen, 27 ]).
8.12. GPS-
Geräteimplementierungen müssen ein GPS enthalten und sollten irgendeine Form der "unterstützten GPS" -Technik umfassen, um die GPS-Sperrzeit zu minimieren.
8.13. Telefony
Android 2.1 kann auf Geräten verwendet werden, die keine Telefonie -Hardware enthalten. Das heißt, Android 2.1 ist mit Geräten kompatibel, die keine Telefone sind. Wenn jedoch eine Geräteimplementierung eine GSM- oder CDMA -Telefonie umfasst, muss sie die vollständige Unterstützung für die API für diese Technologie implementieren. Geräteimplementierungen, die keine Telefonie-Hardware enthalten, müssen die vollständigen APIs als No-OPS implementieren.
Siehe auch Abschnitt 8.8, drahtloses Data -Netzwerk.
8.14.
Implementierungen fürSpeicher- und Speichergeräte
müssen mindestens 92 MB Speicher für Kernel und Userspace zur Verfügung stehen. Der 92MB muss zusätzlich zu jedem Speicher sein, der Hardwarekomponenten wie Radio, Speicher usw. gewidmet ist, und so steht dies nicht unter der Steuerung des Kernels.
Geräteimplementierungen müssen für Benutzerdaten mindestens 150 MB nicht flüchtiger Speicher zur Verfügung stehen. Das heißt, die /data muss mindestens 150 MB betragen.
8.15.
Implementierungenfür gemeinsam genutzte Speichervorrichtungsgeräte
müssen freigegebenen Speicher für Anwendungen angeboten werden. Der freigegebene Speicher muss mindestens 2 GB groß sein.
Die Geräteimplementierungen müssen mit dem freigegebenen Speicher konfiguriert werden, der standardmäßig "aus der Box" montiert ist. Wenn der gemeinsam genutzte Speicher nicht auf dem Linux -Pfad /sdcard montiert ist, muss das Gerät eine symbolische Linux -Verbindung von /sdcard zum tatsächlichen Mountspunkt enthalten.
Geräteimplementierungen müssen als dokumentiert durch die android.permission.WRITE_EXTERNAL_STORAGE -Berechtigung für diesen gemeinsam genutzten Speicher. Der gemeinsame Speicher muss ansonsten von einer Anwendung beschreibbar sein, die diese Genehmigung erhält.
Geräteimplementierungen verfügen möglicherweise über Hardware für benutzergerechte abnehmbare Speicher, z. B. eine sichere digitale Karte. Alternativ können Geräteimplementierungen einen internen (nicht frequentierten) Speicher als gemeinsamer Speicher für Apps zuweisen.
Unabhängig von der Form des verwendeten Shared -Speichers muss der gemeinsam genutzte Speicher eine USB -Massenspeicherung implementieren, wie in Abschnitt 8.6 beschrieben. Wenn der gemeinsame Speicher mit dem Fat -Dateisystem aus dem Tellerrand versendet wird.
Es ist veranschaulichend, zwei gemeinsame Beispiele zu berücksichtigen. Wenn eine Geräteimplementierung einen SD-Kartensteckplatz enthält, um die gemeinsam genutzten Speicheranforderungen zu erfüllen, muss eine fettformatierte SD-Karte 2 GB in Größe oder größer mit dem Gerät enthalten sein, wie sie an Benutzer verkauft werden, und standardmäßig montiert werden.
eine Geräteimplementierung einen internen festen Speicher verwendet, um diese Anforderung zu erfüllen, muss dieser Speicher eine Größe von 2 GB oder größer sein und auf /sdcard /sdcard montiert werden
8.16. Bluetooth
-Geräteimplementierungen müssen einen Bluetooth -Transceiver enthalten. Geräteimplementierungen müssen die RFCOMM-basierte Bluetooth-API ermöglichen, wie in der SDK-Dokumentation [ Ressourcen, 29 ] beschrieben. Geräteimplementierungen sollten relevante Bluetooth -Profile implementieren, wie z. B. A2DP, AVRCP, OBEX usw. gegebenenfalls für das Gerät.
9. Leistungskompatibilität
Eines der Ziele des Android -Kompatibilitätsprogramms ist es, den Verbrauchern einheitliche Anwendungserfahrung zu ermöglichen. Kompatible Implementierungen müssen nicht nur sicherstellen, dass die Anwendungen einfach auf dem Gerät korrekt ausgeführt werden, sondern dass diese mit angemessener Leistung und allgemein guter Benutzererfahrung dies tun. Geräteimplementierungen müssen die wichtigsten Leistungsmetriken eines in der folgenden Tabelle definierten Android 2.1 -kompatiblen Geräts erfüllen:
| Metrische | Leistungsschwellenwert | -Kommentare | Der
| Antragsstartzeit | Die folgenden Anwendungen sollten innerhalb der angegebenen Zeit starten.
| 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 -Prozesss benötigt wird, laden Sie das Android Paket in die Dalvik VM und rufen Sie OnCreate an. |
| Simultane Anwendungen | Wenn mehrere Anwendungen gestartet wurden, muss die Neustart einer bereits laufenden Anwendung nach dem Start weniger als die ursprüngliche Startzeit dauern. |
10. Implementierungen für Sicherheitsmodellkompatibilitätsgeräte
müssen ein Sicherheitsmodell implementieren, das mit dem in den APIs [ Ressourcen, 28 ] in der Dokumentation Android Developer -Dokumentation definierten Sicherheitsmodell implementiert ist. Geräteimplementierungen müssen die Installation selbstsignierter Anträge unterstützen, ohne zusätzliche Berechtigungen/Zertifikate von Dritten/Behörden zu erfordern. Insbesondere müssen kompatible Geräte die in den folgenden Unterabschnitten beschriebenen Sicherheitsmechanismen unterstützen.
10.1. Berechtigungen
Geräteimplementierungen müssen das in der Android Developer -Dokumentation definierte Android -Berechtigungsmodell unterstützen [ Ressourcen, 28 ]. Insbesondere müssen Implementierungen jede in der SDK -Dokumentation beschriebene Genehmigung durchsetzen. Keine Berechtigungen dürfen weggelassen, geändert oder ignoriert werden. Implementierungen können zusätzliche Berechtigungen hinzufügen, vorausgesetzt, die neuen Berechtigungs -ID -Zeichenfolgen befinden sich nicht im Android.* Namespace.
10.2. UID- und Prozess-Isolationsgeräte-
Implementierungen müssen das Android Application Sandbox-Modell unterstützen, bei dem jede Anwendung als eindeutige UID im Unix-Stil und in einem separaten Prozess ausgeführt wird. Geräteimplementierungen müssen unterstützen, dass mehrere Anwendungen als die gleiche Linux -Benutzer -ID ausgeführt werden, sofern die Anwendungen ordnungsgemäß signiert und konstruiert werden, wie in der Referenz für Sicherheit und Berechtigungen definiert [ Ressourcen, 28 ].
10.3.
Die Implementierungenvon Dateisystemberechtigungen
müssen das Modell der Android -Dateizugriffsberechtigungen im Rahmen der in der Sicherheits- und Berechtigungsreferenz definierten Referenz [ Ressourcen, 28 ] unterstützen.
11. Implementierungen für Kompatibilitätstestsuite
-Geräte müssen die Android -Kompatibilitätstest Suite (CTS) [ Ressourcen, 2 ] über das Android Open Source -Projekt unter Verwendung der endgültigen Versandsoftware auf dem Gerät übergeben. Darüber hinaus sollten Geräteimplementierer die Referenzimplementierung im Android Open Source -Baum so weit wie möglich verwenden und die Kompatibilität bei Mehrdeutigkeiten in CTS und für alle Neuauflagen der Teile des Referenzquellencodes sicherstellen müssen.
Das CTS ist so konzipiert, dass sie auf einem tatsächlichen Gerät ausgeführt werden. Wie jede Software können die CTS selbst Fehler enthalten. Die CTS werden unabhängig von dieser Kompatibilitätsdefinition versioniert, und mehrere Überarbeitungen der CTS können für Android 2.1 veröffentlicht werden. Geräteimplementierungen müssen die neueste CTS -Version übergeben, die zum Zeitpunkt der Fertigstellung der Gerätesoftware verfügbar ist.
12. Aktualisierbare
Implementierungen von Software -Geräten müssen einen Mechanismus enthalten, um die gesamte Systemsoftware zu ersetzen. Der Mechanismus muss keine "Live -Upgrades" durchführen - dh ein Neustart von Geräten ist erforderlich.
Jede Methode kann verwendet werden, sofern die gesamte auf dem Gerät vorinstallierte Software ersetzen kann. Beispielsweise erfüllt eine der folgenden Ansätze diese Anforderung:
- Over-the-Air-Downloads (OTA) Downloads mit Offline-Update über Neustart
- "Anbindungen" -Andates über USB von einem Host-PC
- "Offline" -Prüfungen über einen Neustart und eine Aktualisierung einer Datei auf einer Datei auf Ausnehmbarer Speicher
Der verwendete Aktualisierungsmechanismus muss Updates unterstützen, ohne Benutzerdaten abzulösen. Beachten Sie, dass die vorgelagerte Android -Software einen Aktualisierungsmechanismus enthält, der diese Anforderung erfüllt.
Wenn in einer Geräteimplementierung nach seiner Veröffentlichung ein Fehler gefunden wird, jedoch innerhalb seiner angemessenen Produktlebensdauer, die in Absprache mit dem Android-Kompatibilitätsteam festgelegt wird, um die Kompatibilität von Thid-Party-Anwendungen zu beeinflussen, muss der Geräteimplementierer den Fehler über eine Software korrigieren Aktualisieren verfügbar, die gemäß dem gerade beschriebenen Mechanismus angewendet werden können.
13. Kontaktieren Sie uns.
Sie können die Dokumentautoren unter compatibility@android.com kontaktieren, um Klärungen zu erhalten, und um Probleme aufzurufen, von denen Sie glauben, dass das Dokument nicht abdeckt.