Diese Seite wurde von der Cloud Translation API übersetzt.

Kompatibilitätsdefinition für Android 1.6

Android-Kompatibilitätsdefinition: Android 1.6
Android 1.6 r2
Google Inc.
Kompatibilität@android.com

1. Einleitung
In diesem Dokument werden die Anforderungen aufgeführt, die erfüllt sein müssen, damit Mobiltelefone dies tun können
kompatibel mit Android 1.6. Diese Definition setzt Vertrautheit mit dem Android-Kompatibilitätsprogramm voraus
[Ressourcen, 1].
Die Verwendung von „muss“, „darf nicht“, „erforderlich“, „soll“, „soll nicht“, „sollte“, „sollte nicht“, „empfohlen“
„kann“ und „optional“ entsprechen dem IETF-Standard, der in RFC2119 [ Ressourcen , 2] definiert ist.
Wie in diesem Dokument verwendet, ist ein „Geräteimplementierer“ oder „Implementierer“ eine Person oder Organisation, die sich entwickelt
eine Hardware-/Softwarelösung mit Android 1.6. Eine „Geräteimplementierung“ oder „Implementierung“ ist die
entwickelte Hardware-/Softwarelösung.
Um als kompatibel mit Android 1.6 zu gelten, sind Geräteimplementierungen:
1. MUSS die in dieser Kompatibilitätsdefinition dargelegten Anforderungen einschließlich aller Dokumente erfüllen
durch Verweis einbezogen.
2. MÜSSEN die Android Compatibility Test Suite (CTS) bestehen, die im Rahmen von Android Open verfügbar ist
Quellprojekt [ Ressourcen , 3]. Das CTS testet die meisten, aber nicht alle hier beschriebenen Komponenten
dokumentieren.
Wenn diese Definition oder das CTS stumm, mehrdeutig oder unvollständig ist, liegt die Verantwortung beim Gerät
Implementierer, um die Kompatibilität mit vorhandenen Implementierungen sicherzustellen. Aus diesem Grund ist das Android Open
Das Quellprojekt [ Ressourcen , 4] ist sowohl die Referenz als auch die bevorzugte Implementierung von Android. Gerät
Den Implementierern wird dringend empfohlen, ihre Implementierungen auf dem „Upstream“-Quellcode zu basieren
verfügbar im Android Open Source Project. Während einige Komponenten hypothetisch ersetzt werden können
Bei alternativen Implementierungen wird von dieser Praxis dringend abgeraten, da das Bestehen der CTS-Tests dazu führen wird
wesentlich schwieriger. Es liegt in der Verantwortung des Implementierers, die vollständige Verhaltenskompatibilität sicherzustellen
die Standard-Android-Implementierung, einschließlich und darüber hinaus der Compatibility Test Suite.
2. Ressourcen
Diese Kompatibilitätsdefinition verweist auf eine Reihe von Ressourcen, die hier abgerufen werden können.
1. Übersicht über das Android-Kompatibilitätsprogramm: https://sites.google.com/a/android.com/compatibility/
wie es funktioniert
2. IETF RFC2119-Anforderungsstufen: http://www.ietf.org/rfc/rfc2119.txt
3. Kompatibilitätstest-Suite: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. Android Open Source-Projekt: http://source.android.com/
5. API-Definitionen und Dokumentation: http://developer.android.com/reference/packages.html
6. Inhaltsanbieter: http://code.google.com/android/reference/android/provider/package-
Zusammenfassung.html
7. Verfügbare Ressourcen: http://code.google.com/android/reference/available-resources.html
8. Android-Manifestdateien: http://code.google.com/android/devel/bblocks-manifest.html
9. Referenz zu Android-Berechtigungen: http://developer.android.com/reference/android/
Manifest.permission.html
10. Build-Konstanten: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Gears-Browsererweiterungen: http://code.google.com/apis/gears/

13. Dalvik Virtual Machine-Spezifikation, zu finden im Verzeichnis dalvik/docs eines Quellcodes
Kasse; auch verfügbar unter http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. Benachrichtigungen: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. Styleguide für Statusleistensymbole: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Suchmanager: http://developer.android.com/reference/android/app/SearchManager.html
18. Toast: http://developer.android.com/reference/android/widget/Toast.html
19. Apps für Android: http://code.google.com/p/apps-for-android
20. Beschreibung der Android-Apk-Datei: http://developer.android.com/guide/topics/fundamentals.html
21. Android Debug Bridge (adb): http://code.google.com/android/reference/adb.html
22. Dalvik Debug Monitor Service (ddms): http://code.google.com/android/reference/ddms.html
23. Affe: http://developer.android.com/guide/developing/tools/monkey.html
24. Dokumentation zur Anzeigeunabhängigkeit:
25. Konfigurationskonstanten: http://developer.android.com/reference/android/content/res/
Konfiguration.html
26. Anzeigemetriken: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Kamera: http://developer.android.com/reference/android/hardware/Camera.html
28. Sensorkoordinatenraum: http://developer.android.com/reference/android/hardware/
SensorEvent.html
29. Referenz zu Android-Sicherheit und -Berechtigungen: http://developer.android.com/guide/topics/security/
security.html
Viele dieser Ressourcen sind direkt oder indirekt vom Android 1.6 SDK abgeleitet und werden es auch sein
funktional identisch mit den Informationen in der SDK-Dokumentation. In allen Fällen, in denen dies der Fall ist
Wenn die Kompatibilitätsdefinition nicht mit der SDK-Dokumentation übereinstimmt, wird die SDK-Dokumentation berücksichtigt
maßgeblich. Alle technischen Details, die in den oben aufgeführten Referenzen angegeben sind, werden durch die Einbeziehung berücksichtigt
Teil dieser Kompatibilitätsdefinition zu sein.
3. Software
Die Android-Plattform umfasst sowohl eine Reihe verwalteter („harter“) APIs als auch eine Reihe sogenannter „weicher“ APIs
wie das Intent-System, native Code-APIs und Webanwendungs-APIs. In diesem Abschnitt werden die harten und
Soft-APIs, die für die Kompatibilität von wesentlicher Bedeutung sind, sowie bestimmte andere relevante technische Schnittstellen und Benutzeroberflächen
Verhaltensweisen. 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. Der
Die Android-Anwendungsprogrammierschnittstelle (API) ist der Satz von Android-Plattformschnittstellen, denen ausgesetzt ist
Anwendungen, die in der verwalteten VM-Umgebung ausgeführt werden. Geräteimplementierungen MÜSSEN vollständig sein
Implementierungen, einschließlich aller dokumentierten Verhaltensweisen, aller dokumentierten APIs, die von Android bereitgestellt werden
1.6 SDK, wie zum Beispiel:
1. Kern-Android-Java-Sprach-APIs [Ressourcen, 5].
2. Inhaltsanbieter [Ressourcen , 6].
3. Ressourcen [Ressourcen, 7].
4. AndroidManifest.xml-Attribute und -Elemente [Ressourcen, 8].

Geräteimplementierungen DÜRFEN KEINE verwalteten APIs auslassen, API-Schnittstellen oder Signaturen ändern oder abweichen
vom dokumentierten Verhalten abweichen oder No-Ops einschließen, sofern diese Kompatibilität dies nicht ausdrücklich zulässt
Definition.
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.
API in Form von Dingen wie Absichten, Berechtigungen und ähnlichen Aspekten von Android-Anwendungen
Dies kann zur Kompilierungszeit der Anwendung nicht erzwungen werden. In diesem Abschnitt werden die „weichen“ APIs und das System detailliert beschrieben
Verhaltensweisen, die für die Kompatibilität mit Android 1.6 erforderlich sind. Geräteimplementierungen MÜSSEN alle Anforderungen erfüllen
Anforderungen, die in diesem Abschnitt aufgeführt sind.
3.2.1. Berechtigungen
Geräteimplementierer MÜSSEN alle im Dokument dokumentierten Berechtigungskonstanten unterstützen und durchsetzen
Berechtigungsreferenzseite [ Ressourcen , 9]. Beachten Sie, dass Abschnitt 10 zusätzliche Anforderungen im Zusammenhang mit auflistet
das Android-Sicherheitsmodell.
3.2.2. Build-Parameter
Die Android-APIs enthalten eine Reihe von Konstanten in der Klasse android.os.Build [Ressourcen, 10].
soll das aktuelle Gerät beschreiben. Bereitstellung konsistenter, aussagekräftiger Werte auf dem gesamten Gerät
Implementierungen enthält die folgende Tabelle zusätzliche Einschränkungen für die Formate dieser Werte
Geräteimplementierungen MÜSSEN konform sein.
Parameter
Kommentare
Die Version des aktuell ausgeführten Android-Systems, in menschlicher Form.
android.os.Build.VERSION.RELEASE
lesbares Format. Für Android 1.6 MUSS dieses Feld den Zeichenfolgenwert haben
„1,6“.
Die Version des aktuell ausgeführten Android-Systems in einem Format
android.os.Build.VERSION.SDK
für Anwendungscode von Drittanbietern zugänglich. Für Android 1.6 dieses Feld
MUSS den ganzzahligen Wert 4 haben.
Ein vom Geräteimplementierer ausgewählter Wert, der den spezifischen Build bezeichnet
des aktuell ausgeführten Android-Systems im für Menschen lesbaren Format.
Dieser Wert DARF NICHT für verschiedene Builds wiederverwendet werden, die bis zum Ende versendet werden
android.os.Build.VERSION.INCREMENTAL Benutzer. Eine typische Verwendung dieses Feldes besteht darin, anzugeben, welche Build-Nummer bzw
Zum Generieren des Builds wurde die Änderungskennung der Quellcodeverwaltung verwendet. Dort
Es gibt keine Anforderungen an das spezifische Format dieses Feldes, außer dass es
DARF NICHT null oder die leere Zeichenfolge ("") sein.
Ein vom Geräteimplementierer ausgewählter Wert, der das spezifische interne Gerät identifiziert
vom Gerät verwendete Hardware in einem für Menschen lesbaren Format. Eine mögliche Verwendung
android.os.Build.BOARD
Dieses Feld dient dazu, die spezifische Revision der Platine anzugeben, die das antreibt
Gerät. Es gibt keine Anforderungen an das spezifische Format dieses Feldes.
außer dass es NICHT NULL oder die leere Zeichenfolge ("") sein DARF.
Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts identifiziert
android.os.Build.BRAND
Unternehmen, Organisation, Einzelperson usw., die das Gerät hergestellt haben
menschenlesbares Format. Eine mögliche Verwendung dieses Feldes ist die Angabe des OEM

und/oder Spediteur, der das Gerät verkauft hat. Es gibt keine Anforderungen an die
spezifisches Format dieses Feldes, mit der Ausnahme, dass es NICHT NULL oder leer sein DARF
Zeichenfolge ("").
Ein vom Geräteimplementierer ausgewählter Wert, der das Spezifische identifiziert
Konfiguration oder Überarbeitung des Körpers (manchmal auch „industriell“ genannt).
android.os.Build.DEVICE
Design") des Geräts. Es gibt keine Anforderungen an das spezifische Format
dieses Felds, mit der Ausnahme, dass es NICHT NULL oder die leere Zeichenfolge ("") sein DARF.
Eine Zeichenfolge, die diesen Build eindeutig identifiziert. Es sollte vernünftig sein
für Menschen lesbar. Es MUSS dieser Vorlage folgen:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
Zum Beispiel: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/test-keys
Der Fingerabdruck DARF KEINE Leerzeichen enthalten. Wenn andere Felder in der enthalten sind
Wenn die obige Vorlage Leerzeichen enthält, SOLLTEN diese durch ASCII ersetzt werden
Unterstrich („_“) im Fingerabdruck.
Eine Zeichenfolge, die den Host, auf dem der Build erstellt wurde, in menschlicher Form eindeutig identifiziert
android.os.Build.HOST
lesbares Format. Es gibt keine Anforderungen an das spezifische Format
Feld, außer dass es NICHT NULL oder die leere Zeichenfolge ("") sein DARF.
Eine vom Geräteimplementierer ausgewählte Kennung, um auf ein bestimmtes Gerät zu verweisen
Veröffentlichung in einem für Menschen lesbaren Format. Dieses Feld kann dasselbe sein wie
android.os.Build.VERSION.INCREMENTAL, SOLLTE aber ein Wert sein
android.os.Build.ID
soll für Endbenutzer einigermaßen aussagekräftig sein. Es gibt keine
Anforderungen an das spezifische Format dieses Feldes erfüllen, mit der Ausnahme, dass dies NICHT der Fall sein darf
sei null oder die leere Zeichenfolge ("").
Ein vom Geräteimplementierer ausgewählter Wert, der den Namen des Geräts enthält
Gerät, wie es dem Endbenutzer bekannt ist. Dies SOLLTE derselbe Name sein
android.os.Build.MODEL
unter dem das Gerät vermarktet und an Endverbraucher verkauft wird. Es gibt keine
Anforderungen an das spezifische Format dieses Feldes erfüllen, mit der Ausnahme, dass dies NICHT der Fall sein darf
sei null oder die leere Zeichenfolge ("").
Ein vom Geräteimplementierer ausgewählter Wert, der die Entwicklung enthält
Name oder Codename des Geräts. MUSS für Menschen lesbar sein, ist es aber nicht
android.os.Build.PRODUCT
unbedingt zur Einsichtnahme durch Endbenutzer bestimmt. Es gibt keine Anforderungen
vom spezifischen Format dieses Feldes ab, mit der Ausnahme, dass es NICHT NULL oder das sein DARF
leerer String ("").
Eine durch Kommas getrennte Liste von Tags, die vom Geräteimplementierer ausgewählt wurden
differenzieren den Aufbau weiter. Beispiel: „unsigned,debug“. Dieses Feld
android.os.Build.TAGS
DARF NICHT null oder die leere Zeichenfolge ("") sein, sondern ein einzelnes Tag (z. B
„Release“) ist in Ordnung.
android.os.Build.TIME
Ein Wert, der den Zeitstempel des Buildvorgangs darstellt.
Ein vom Geräteimplementierer ausgewählter Wert, der die Laufzeit angibt
Konfiguration des Builds. Dieses Feld SOLLTE einen der Werte haben
android.os.Build.TYPE
entsprechend den drei typischen Android-Laufzeitkonfigurationen: „Benutzer“,
„userdebug“ oder „eng“.
Ein Name oder eine Benutzer-ID des Benutzers (oder automatisierten Benutzers), der das generiert hat
android.os.Build.USER
bauen. Es gibt keine Anforderungen an das spezifische Format dieses Feldes.
außer dass es NICHT NULL oder die leere Zeichenfolge ("") sein DARF.

3.2.3. Absichtskompatibilität
Android verwendet Intents, um eine lose gekoppelte Integration zwischen Anwendungen zu erreichen. In diesem Abschnitt wird beschrieben
Anforderungen im Zusammenhang mit den Absichtsmustern, die von Geräteimplementierungen berücksichtigt werden MÜSSEN. Von
„Geehrt“ bedeutet, dass der Geräteimplementierer eine Android-Aktivität, einen Android-Dienst oder etwas anderes bereitstellen MUSS
Komponente, die einen passenden Intent-Filter angibt und an jeden bindet und das richtige Verhalten für jeden implementiert
angegebenes Absichtsmuster.
3.2.3.1. Kernanwendungsabsichten
Das Android-Upstream-Projekt definiert eine Reihe von Kernanwendungen, wie z. B. einen Telefonwähler, einen Kalender,
Kontaktbuch, Musikplayer usw. Geräteimplementierer KÖNNEN diese Anwendungen durch ersetzen
alternative Versionen.
Allerdings MÜSSEN solche alternativen Versionen dieselben Absichtsmuster berücksichtigen, die vom Upstream bereitgestellt werden
Projekt. (Wenn ein Gerät beispielsweise einen alternativen Musikplayer enthält, muss es dennoch das Intent-Muster berücksichtigen
wird von Drittanbieteranwendungen ausgegeben, um einen Song auszuwählen.) Geräteimplementierungen MÜSSEN alle Intent-Muster unterstützen
sind in Anhang A aufgeführt.
3.2.3.2. Absichtsüberschreibungen
Da Android eine erweiterbare Plattform ist, MÜSSEN Geräteimplementierer jedes in beschriebene Absichtsmuster zulassen
Anhang A kann von Anwendungen Dritter überschrieben werden. Das Upstream-Android-Open-Source-Projekt
erlaubt dies standardmäßig; Geräteimplementierer DÜRFEN Systemanwendungen KEINE besonderen Privilegien hinzufügen.
Verwendung dieser Absichtsmuster oder verhindern, dass Anwendungen Dritter an sie binden und die Kontrolle darüber übernehmen
diese Muster. Dieses Verbot umfasst insbesondere die Deaktivierung der Benutzeroberfläche „Chooser“, die dies ermöglicht
Der Benutzer kann zwischen mehreren Anwendungen wählen, die alle dasselbe Intent-Muster verarbeiten.
3.2.3.3. Absichts-Namespaces
Geräteimplementierer DÜRFEN KEINE Android-Komponenten enthalten, die neue Absichten berücksichtigen oder
Senden Sie Absichtsmuster mithilfe einer ACTION, CATEGORY oder einer anderen Schlüsselzeichenfolge im Android.*-Namespace.
Geräteimplementierer DÜRFEN KEINE Android-Komponenten enthalten, die neue Absichten berücksichtigen oder
Senden Sie Absichtsmuster mithilfe einer ACTION, CATEGORY oder einer anderen Schlüsselzeichenfolge in einem Paketbereich
Zugehörigkeit zu einer anderen Organisation. Geräteimplementierer DÜRFEN die Absicht NICHT ändern oder erweitern
Muster, die in den Anhängen A oder B aufgeführt 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 Plattform zu informieren
Hardware- oder Softwareumgebung. Android-kompatible Geräte MÜSSEN die öffentliche Übertragung übertragen
Absichten als Reaktion auf entsprechende Systemereignisse. Eine Liste der erforderlichen Broadcast Intents finden Sie in
Anhang B; Beachten Sie jedoch, dass das SDK möglicherweise zusätzliche Broadcast-Absichten definiert, die ebenfalls vorhanden sein MÜSSEN
geehrt.
3.3. Native API-Kompatibilität
In Dalvik ausgeführter verwalteter Code kann nativen Code aufrufen, der in der APK-Datei der Anwendung als ELF bereitgestellt wird
.so-Datei, die für die entsprechende Gerätehardwarearchitektur kompiliert wurde. Geräteimplementierungen MÜSSEN enthalten
Unterstützung für Code, der in der verwalteten Umgebung ausgeführt wird, um nativen Code mithilfe von Standard-Java aufzurufen
Native Interface (JNI)-Semantik. 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++
• OpenGL ES 1.1
Diese Bibliotheken MÜSSEN quellkompatibel (d. h. Header-kompatibel) und binärkompatibel (für eine bestimmte Datei) sein
Prozessorarchitektur) mit den in Bionic vom Android Open Source-Projekt bereitgestellten Versionen. Seit
Die Bionic-Implementierungen sind nicht vollständig kompatibel mit anderen Implementierungen wie GNU C
Bibliothek, Geräteimplementierer SOLLTEN die Android-Implementierung verwenden. Wenn Geräteimplementierer a verwenden
Bei unterschiedlichen Implementierungen dieser Bibliotheken müssen sie die Header- und Binärkompatibilität sicherstellen.
Die Kompatibilität mit nativem Code ist eine Herausforderung. Aus diesem Grund möchten wir wiederholen, dass es Geräteimplementierer gibt
Es wird SEHR dringend empfohlen, die Upstream-Implementierungen der oben aufgeführten Bibliotheken zu verwenden, um zu helfen
stellen Sie die Kompatibilität sicher.
3.4. Web-API-Kompatibilität
Viele Entwickler und Anwendungen verlassen sich auf das Verhalten der Klasse android.webkit.WebView [ Ressourcen ,
11] für ihre Benutzeroberflächen, daher muss die WebView-Implementierung mit Android kompatibel sein
Implementierungen. Die Android Open Source-Implementierung verwendet die WebKit-Rendering-Engine-Version
Implementieren Sie die WebView.
Da es nicht möglich ist, eine umfassende Testsuite für einen Webbrowser und Geräteimplementierer zu entwickeln
MUSS den spezifischen Upstream-Build von WebKit in der WebView-Implementierung verwenden. Speziell:
• WebView MUSS den WebKit-Build 528.5+ aus dem Upstream-Android-Open-Source-Baum verwenden
Android 1.6. 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 1.6; <Sprache>-<Land>; <Gerät
Name>; Build/<Build-ID>) AppleWebKit/528.5+ (KHTML, wie Gecko)
Version/3.1.2 Mobile Safari/525.20.1

◦ Die Zeichenfolge „<Gerätename>“ MUSS mit dem Wert für übereinstimmen
android.os.Build.MODEL
◦ Die Zeichenfolge „<build ID>“ MUSS mit dem Wert für android.os.Build.ID identisch sein.
◦ Die Zeichenfolgen „<Sprache>“ und „<Land>“ SOLLTEN den üblichen Konventionen für folgen
Ländercode und Sprache, und SOLLTE sich auf das aktuelle Gebietsschema des Geräts beziehen
Zeitpunkt der Anfrage.
Implementierungen KÖNNEN eine benutzerdefinierte Benutzeragentenzeichenfolge in der eigenständigen Browseranwendung liefern. Was ist
Darüber hinaus KANN der eigenständige Browser auf einer alternativen Browsertechnologie basieren (z. B. Firefox,
Auch wenn eine alternative Browseranwendung ausgeliefert wird, ist die WebView-Komponente jedoch nicht verfügbar
Die Bereitstellung für Drittanwendungen MUSS wie oben auf WebKit basieren.
Die eigenständige Browseranwendung SOLLTE Unterstützung für Gears [ Ressourcen, 12] und MAY enthalten
umfassen Unterstützung für einige oder alle HTML5-Inhalte.
3.5. API-Verhaltenskompatibilität
Das Verhalten jedes API-Typs (verwaltet, Soft, nativ und Web) muss mit dem übereinstimmen
bevorzugte Implementierung von Android, verfügbar im Android Open Source Project.
Einige spezifische Kompatibilitätsbereiche sind:
• Geräte DÜRFEN das Verhalten oder die Bedeutung eines Standardabsichts NICHT ändern
• Geräte DÜRFEN NICHT den Lebenszyklus oder die Lebenszyklussemantik eines bestimmten Systemtyps verändern
Komponente (z. B. Service, Aktivität, ContentProvider usw.)
• Geräte DÜRFEN die Semantik einer bestimmten Berechtigung NICHT ändern
Die obige Liste ist nicht vollständig und es liegt in der Verantwortung der Geräteimplementierer, das Verhalten sicherzustellen
Kompatibilität. Aus diesem Grund SOLLTEN Geräteimplementierer den über den verfügbaren Quellcode verwenden
Verwenden Sie nach Möglichkeit das Android Open Source-Projekt, anstatt wesentliche Teile des Systems neu zu implementieren.
Die Compatibility Test Suite (CTS) testet wesentliche Teile der Plattform auf Verhaltenskompatibilität,
aber nicht alles. Es liegt in der Verantwortung des Implementierers, die Verhaltenskompatibilität mit Android sicherzustellen
Open-Source-Projekt.
3.6. API-Namespaces
Android folgt den durch die Java-Programmierung definierten Paket- und Klassen-Namespace-Konventionen
Sprache. Um die Kompatibilität mit Anwendungen von Drittanbietern sicherzustellen, DÜRFEN Geräteimplementierer KEINE Änderungen vornehmen
alle verbotenen Änderungen (siehe unten) an diesen Paket-Namespaces:
• 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
durch Ändern von Methoden- oder Klassensignaturen oder durch Entfernen von Klassen oder Klassenfeldern.

• Geräteimplementierer KÖNNEN die zugrunde liegende Implementierung der APIs ändern, aber z
Änderungen DÜRFEN KEINE Auswirkungen auf das angegebene Verhalten und die Java-Sprachsignatur haben
öffentlich zugängliche APIs.
• Geräteimplementierer DÜRFEN KEINE öffentlich zugänglichen Elemente hinzufügen (z. B. Klassen oder
Schnittstellen oder Felder oder Methoden zu vorhandenen Klassen oder Schnittstellen) zu den oben genannten APIs.
Ein „öffentlich zugängliches Element“ ist jedes Konstrukt, das nicht mit der Markierung „@hide“ versehen ist
Upstream-Android-Quellcode. Mit anderen Worten: Geräteimplementierer DÜRFEN KEINE neuen APIs offenlegen oder
Ändern Sie vorhandene APIs in den oben genannten Namespaces. Geräteimplementierer dürfen nur intern arbeiten
Änderungen, aber diese Änderungen DÜRFEN NICHT beworben 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 eigenen Namespace befinden
von einer anderen Organisation oder unter Bezugnahme auf diese. Beispielsweise DÜRFEN Geräteimplementierer KEINE APIs zum hinzufügen
com.google.* oder ähnlicher Namespace; Nur Google darf dies tun. Ebenso DARF Google KEINE APIs hinzufügen
Namensräume anderer Unternehmen.
Wenn ein Geräteimplementierer vorschlägt, einen der oben genannten Paket-Namespaces zu verbessern (z. B. durch Hinzufügen
Wenn Sie nützliche neue Funktionen zu einer vorhandenen API hinzufügen oder eine neue API hinzufügen möchten, SOLLTE der Implementierer einen Besuch abstatten
source.android.com und beginnen Sie mit dem Prozess zum Einbringen von Änderungen und Code
Informationen auf dieser Website.
Beachten Sie, dass die oben genannten Einschränkungen den Standardkonventionen für die Benennung von APIs in Java entsprechen
Programmiersprache; Dieser Abschnitt zielt lediglich darauf ab, diese Konventionen zu stärken und sie verbindlich zu machen
durch Aufnahme in diese Kompatibilitätsdefinition.
3.7. Kompatibilität virtueller Maschinen
Ein kompatibles Android-Gerät muss die vollständige Dalvik Executable (DEX)-Bytecode-Spezifikation unterstützen
Semantik der virtuellen Dalvik-Maschine [Ressourcen, 13].
3.8. Kompatibilität der Benutzeroberfläche
Die Android-Plattform umfasst einige Entwickler-APIs, die es Entwicklern ermöglichen, sich in den Systembenutzer einzubinden
Schnittstelle. Geräteimplementierungen MÜSSEN diese Standard-UI-APIs in benutzerdefinierte Benutzeroberflächen integrieren
Sie entwickeln sich, wie unten erläutert.
3.8.1. Widgets
Android definiert einen Komponententyp und die entsprechende API und den Lebenszyklus, die es Anwendungen ermöglichen, verfügbar zu machen
ein „AppWidget“ für den Endbenutzer [Ressourcen , 14] . Die Android Open Source-Referenzversion enthält a
Startanwendung, die Elemente der Benutzeroberfläche enthält, die dem Benutzer das Hinzufügen, Anzeigen und Entfernen ermöglichen
AppWidgets vom Startbildschirm aus.
Geräteimplementierer KÖNNEN eine Alternative zum Referenz-Launcher (z. B. Startbildschirm) ersetzen.
Alternative Launcher SOLLTEN integrierte Unterstützung für AppWidgets bieten und eine Benutzeroberfläche verfügbar machen
Elemente zum Hinzufügen, Anzeigen und Entfernen von AppWidgets direkt im Launcher. Alternative Trägerraketen KÖNNEN
diese Benutzeroberflächenelemente weglassen; Wenn sie jedoch weggelassen werden, MUSS der Geräteimplementierer eine bereitstellen
separate Anwendung, auf die über den Launcher zugegriffen werden kann und die es Benutzern ermöglicht, hinzuzufügen, anzuzeigen und zu entfernen
AppWidgets.

3.8.2. Benachrichtigungen
Android enthält APIs, die es Entwicklern ermöglichen, Benutzer über wichtige Ereignisse zu benachrichtigen [Ressourcen, 15]. Gerät
Implementierer MÜSSEN Unterstützung für jede so definierte Benachrichtigungsklasse bereitstellen; konkret: Geräusche,
Vibration, Licht und Statusleiste.
Darüber hinaus MUSS die Implementierung korrekt gerendert werden und alle Ressourcen (Symbole, Sounddateien usw.)
bereitgestellt in den APIs [Ressourcen, 7] oder im Stilleitfaden für Statusleistensymbole [Ressourcen , 16]. Gerät
Implementierer KÖNNEN eine alternative Benutzererfahrung für Benachrichtigungen bieten als die, die von bereitgestellt wird
Referenz Android Open Source-Implementierung; Allerdings MÜSSEN solche alternativen Benachrichtigungssysteme vorhanden sein
Unterstützt vorhandene Benachrichtigungsressourcen wie oben.
3.8.3. Suchen
Android enthält APIs [Ressourcen, 17], die es Entwicklern ermöglichen, die Suche in ihre Anwendungen zu integrieren.
und stellen Sie die Daten ihrer Anwendung in der globalen Systemsuche bereit. Im Allgemeinen ist diese Funktionalität
besteht aus einer einzigen, systemweiten Benutzeroberfläche, die es Benutzern ermöglicht, Abfragen einzugeben und Vorschläge anzuzeigen
während Benutzer tippen, und zeigt Ergebnisse an. Mit den Android-APIs können Entwickler diese Schnittstelle wiederverwenden und bereitstellen
Suchen Sie innerhalb ihrer eigenen Apps und ermöglichen Sie Entwicklern, Ergebnisse für den allgemeinen globalen Suchbenutzer bereitzustellen
Schnittstelle.
Geräteimplementierungen MÜSSEN eine einzige, gemeinsame, systemweite Suchbenutzeroberfläche umfassen, die dazu in der Lage ist
Echtzeitvorschläge als Reaktion auf Benutzereingaben. Geräteimplementierungen MÜSSEN die APIs implementieren, die
Ermöglichen Sie Entwicklern die Wiederverwendung dieser Benutzeroberfläche, um die Suche in ihren eigenen Anwendungen bereitzustellen.
Geräteimplementierungen MÜSSEN die APIs implementieren, die es Drittanbieteranwendungen ermöglichen, Vorschläge hinzuzufügen
zum Suchfeld hinzugefügt, wenn es im globalen Suchmodus ausgeführt wird. Wenn keine Anwendungen von Drittanbietern installiert sind
Wenn Sie diese Funktionalität nutzen, SOLLTE das Standardverhalten darin bestehen, Web-Suchmaschinenergebnisse anzuzeigen und
Vorschläge.
Geräteimplementierungen KÖNNEN alternative Benutzeroberflächen für die Suche bereitstellen, SOLLTEN jedoch eine harte oder weiche Benutzeroberfläche enthalten
spezielle Suchschaltfläche, 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, 18]) verwenden, um kurze nichtmodale Zeichenfolgen anzuzeigen
Endbenutzer, die nach kurzer Zeit verschwinden. Geräteimplementierungen MÜSSEN Toasts von anzeigen
Anwendungen den Endbenutzern auf gut sichtbare Weise zur Verfügung zu stellen.
4. Referenz-Softwarekompatibilität
Geräteimplementierer MÜSSEN die Implementierungskompatibilität mithilfe der folgenden Open-Source-Software testen
Anwendungen:
• Rechner (im SDK enthalten)
• Lunar Lander (im SDK enthalten)
• ApiDemos (im SDK enthalten)
• Die „Apps für Android“-Anwendungen [ Ressourcen, 19]
Damit die Implementierung funktioniert, MUSS jede der oben genannten Apps gestartet werden und sich bei der Implementierung korrekt verhalten

als kompatibel angesehen.
5. Kompatibilität der Anwendungspakete
Geräteimplementierungen MÜSSEN Android-„.apk“-Dateien installieren und ausführen, wie sie vom „aapt“-Tool generiert wurden
im offiziellen Android SDK enthalten [ Ressourcen , 20].
Geräteimplementierungen DÜRFEN weder den .apk-, Android-Manifest- noch den Dalvik-Bytecode erweitern
Formate in einer Weise, die verhindern würde, dass diese Dateien auf anderen Geräten ordnungsgemäß installiert und ausgeführt werden
kompatible Geräte. Geräteimplementierer SOLLTEN die Referenz-Upstream-Implementierung von Dalvik verwenden,
und das Paketverwaltungssystem der Referenzimplementierung.
6. Multimedia-Kompatibilität
Ein kompatibles Android-Gerät muss die folgenden Multimedia-Codecs unterstützen. Alle diese Codecs sind
werden als Software-Implementierungen in der bevorzugten Android-Implementierung von Android Open bereitgestellt
Quellprojekt [ Ressourcen , 4].
Bitte beachten Sie, dass weder Google noch die Open Handset Alliance eine Zusicherung dafür geben
Codecs sind nicht durch Patente Dritter belastet. Diejenigen, die beabsichtigen, diesen Quellcode in Hardware oder zu verwenden
Softwareprodukten wird empfohlen, dass Implementierungen dieses Codes, auch in Open-Source-Software oder
Shareware erfordert möglicherweise Patentlizenzen von den jeweiligen Patentinhabern.
Audio
Name
Encoder-Decoder-Details
Unterstützte Dateien
Mono-/Stereo-Inhalte in jedem
3GPP (.3gp) und
Kombination von Standard-Bitraten
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
Dateien mit bis zu 160 kbit/s und Abtastraten. Keine Unterstützung für Raw
zwischen 8 und 48 kHz
AAC (.aac)
Mono-/Stereo-Inhalte in jedem
3GPP (.3gp) und
HE-AACv1
Kombination von Standard-Bitraten
MPEG-4 (.mp4, .m4a)
X
(AAC+)
Dateien mit bis zu 96 kbit/s und Abtastraten. Keine Unterstützung für Raw
zwischen 8 und 48 kHz
AAC (.aac)
Mono-/Stereo-Inhalte in jedem
HE-AACv2
3GPP (.3gp) und
Kombination von Standard-Bitraten
(erweitert
MPEG-4 (.mp4, .m4a)
X
bis zu 96 kbps und Abtastraten
AAC+)
Dateien. Keine Unterstützung für Raw
zwischen 8 und 48 kHz
AAC (.aac)
AMR-NB
4,75 bis 12,2 kbit/s abgetastet bei
3GPP-Dateien (.3gp).
X
X
8kHz
AMR-WB
9 Tarife von 6,60 kbit/s bis 23,85
-3GPP-Dateien (.3gp).
X
kbit/s abgetastet bei 16 kHz
MP3
Mono/Stereo 8-320 Kbps konstante MP3-Dateien (.mp3).
X
(CBR) oder variable Bitrate (VBR)
Geben Sie 0 und 1 ein (.mid, .xmf,
MIDI Typ 0 und 1. DLS Version 1
MIDI
X
.mxmf). Auch RTTTL/RTX
und 2. XMF und Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Unterstützung für Klingeltonformate
und iMelody (.imy)
RTTTL/RTX, OTA und iMelody
Ogg Vorbis
.ogg
X
8- und 16-Bit lineares PCM (Raten höher).
PCM
X
WELLE
zur Begrenzung der Hardware)
Bild
Dateien
Name
Encoder -Decoderdetails
Unterstützt
JPEG
X
X
Basis+progressiv
GIF
X
Png
X
X
BMP
X
Video
Dateien
Name
Encoder -Decoderdetails
Unterstützt
3GPP (.3gp)
H.263
X
X
Dateien
3GPP (.3gp)
H.264
X
und MPEG-4
(.mp4) Dateien
MPEG4
X
3GPP (.3GP) Datei
SP
7. Kompatibilität für Entwicklerwerkzeuge
Geräteimplementierungen müssen die im Android SDK bereitgestellten Android -Entwickler -Tools unterstützen.
Insbesondere müssen Android-kompatible Geräte kompatibel sein mit:
• Android Debugg Bridge oder ADB [Ressourcen , 21]
Geräteimplementierungen müssen alle ADB -Funktionen unterstützen, wie sie im Android dokumentiert sind
SDK. Der Gerätseiten-ADB-Daemon sollte standardmäßig inaktiv sein, aber es muss ein Benutzer sein.
Zugänglicher Mechanismus zum Einschalten der Android -Debug -Brücke.
• DALVIK DEBUG Monitor Service oder DDMS [Ressourcen , 22]
Geräteimplementierungen müssen alle DDMS -Funktionen unterstützen, wie sie im Android SDK dokumentiert sind.
Da DDMS ADB verwendet, sollte die Unterstützung für DDMS standardmäßig inaktiv sein, muss jedoch unterstützt werden
Immer wenn der Benutzer die Android -Debug -Brücke wie oben aktiviert hat.

• Affen [Ressourcen, 23]
Die Geräteimplementierungen müssen das Monkey -Framework enthalten und es zur Verfügung stellen
zu verwendende Anwendungen.
8. Hardwarekompatibilität
Android soll Geräteimplementierer unterstützen, die innovative Formularfaktoren und Konfigurationen erstellen.
Gleichzeitig erwarten Android -Entwickler bestimmte Hardware, Sensoren und APIs in ganz Android
Gerät. In diesem Abschnitt werden die Hardwarefunktionen aufgeführt, die alle Android 1.6 -kompatiblen Geräte unterstützen müssen. In
Android 1.6, die Mehrheit der Hardwarefunktionen (wie WLAN, Kompass und Beschleunigungsmesser) ist erforderlich.
Wenn ein Gerät eine bestimmte Hardwarekomponente mit einer entsprechenden API für Drittanbieter enthält
Entwickler, die Geräteimplementierung muss diese API gemäß den Android SDK implementieren
Dokumentation.
8.1. Anzeige
Android 1.6 enthält Einrichtungen, die bestimmte automatische Skalierung und Transformationsvorgänge unterführen
Einige Umstände, um sicherzustellen, dass Anwendungen von Drittanbietern auf Hardware einigermaßen gut laufen
Konfigurationen, für die sie nicht unbedingt explizit gestaltet waren [Ressourcen, 24] . Geräte müssen
Implementieren Sie diese Verhaltensweisen ordnungsgemäß, wie in diesem Abschnitt beschrieben.
8.1.1. Standard -Anzeigekonfigurationen
Diese Tabelle listet die Standard -Bildschirmkonfigurationen auf, die mit Android kompatibel betrachtet werden:
Diagonale
Bildschirmgröße
Bildschirmdichte
Bildschirmtyp
Breite (Pixel)
Höhe (Pixel)
Längenbereich
Gruppe
Gruppe
(Zoll)
Qvga
240
320
2.6 - 3.0
Klein
Niedrig
Wqvga
240
400
3.2 - 3.5
Normal
Niedrig
Fwqvga
240
432
3,5 - 3.8
Normal
Niedrig
HVGA
320
480
3.0 - 3.5
Normal
Mittel
WVGA
480
800
3.3 - 4.0
Normal
Hoch
Fwvga
480
854
3.5 - 4.0
Normal
Hoch
WVGA
480
800
4,8 - 5,5
Groß
Mittel
Fwvga
480
854
5.0 - 5.8
Groß
Mittel
Geräteimplementierungen, die einer der oben genannten Standardkonfigurationen entsprechen
So melden Sie die angegebene Bildschirmgröße an Anwendungen über die Android.content.res.Configuration [Ressourcen, Ressourcen,
25] Klasse.
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 alle Ressourcen interpretieren, die als Verfall vorhanden sind
"Medium" (bekannt als "MDPI" in der SDK -Dokumentation.)
• Beim Betrieb auf einem "niedrigen" Dichtebildschirm müssen Geräteimplementierungen das Medium skalieren/
MDPI -Vermögenswerte um einen Faktor von 0,75.
• Wenn Sie auf einem "hohen" Dichtebildschirm arbeiten
MDPI -Vermögenswerte um einen Faktor 1,5.
• Geräteimplementierungen dürfen die Vermögenswerte nicht innerhalb eines Dichtebereichs skalieren und müssen skalieren
Vermögenswerte nach genau diesen Faktoren zwischen Dichtebereichen.
8.1.2. Nicht standardmäßige Anzeigenkonfigurationen
Zeigen Sie Konfigurationen an, die nicht mit einer der in Abschnitt 8.2.1 aufgeführten Standardkonfigurationen übereinstimmen
Zusätzliche Überlegungen und Arbeiten, um kompatibel zu sein. Geräteimplementierer müssen sich an Android wenden
Kompatibilitätsteam wie in Abschnitt 12 vorgesehen
und Skalierungsfaktor. Wenn diese Informationen zur Verfügung gestellt werden, müssen die Geräteimplementierungen sie implementieren
wie angegeben.
Beachten Sie, dass einige Anzeigenkonfigurationen (z. B. sehr große oder sehr kleine Bildschirme und einige Seitenverhältnisse)
sind grundsätzlich unvereinbar mit Android 1.6; Daher werden Geräteimplementierer dazu ermutigt
Kontaktieren Sie das Android -Kompatibilitätsteam so früh wie möglich im Entwicklungsprozess.
8.1.3. Metriken anzeigen
Geräteimplementierungen müssen korrekte Werte für alle in definierten Anzeigenmetriken melden
Android.util.DisplayMetrics [Ressourcen , 26].
8.2. Tastatur
Geräteimplementierungen:
• Muss die Unterstützung für das Input -Management -Framework enthalten (der Dritte erlaubt
Entwickler, um Input -Management -Motoren zu erstellen - dh Soft -Tastatur) wie detailliert bei
Entwickler.android.com
• Muss mindestens eine Implementierung von Softtastaturen liefern (unabhängig davon, ob eine schwierige
Tastatur ist vorhanden)
• Kann zusätzliche Implementierungen für Softtastaturen enthalten
• Kann eine Hardware -Tastatur enthalten
• darf keine Hardware -Tastatur enthalten, die nicht mit einem der angegebenen Formate übereinstimmt
In Android.content.res.Configuration [ Ressourcen, 25] (dh QWERTY oder 12-TEY)
8.3. Nicht-Touch-Navigation
Geräteimplementierungen:
• Kann Nicht-Touch-Navigationsoptionen weglassen (dh kann ein Trackball, ein 5-Wege-Richtungskissen weglassen oder
Rad)
• Muss über Android.content.res.Configuration [Ressourcen , 25] Der richtige Wert für die
Hardware des Geräts

8.4. Bildschirmausrichtung
Kompatible Geräte müssen die dynamische Orientierung durch Anwendungen entweder auf Porträt oder Landschaft unterstützen
Bildschirmausrichtung. Das heißt, das Gerät muss die Anfrage der Anwendung für einen bestimmten Bildschirm respektieren
Orientierung. 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 abfragt wird
android.content.res.configuration.orientation, android.view.display.getorientation () oder andere APIs.
8.5. Touchscreen-Eingabe
Geräteimplementierungen:
• Muss einen Touchscreen haben
• Kann entweder kapakativ oder konstantem Touchscreen haben
• Muss den Wert von Android.content.res.Configuration [ Ressourcen, 25] reflektieren
entspricht dem Typ des spezifischen Touchscreen auf dem Gerät
8.6. USB
Geräteimplementierungen:
• Muss einen USB-Client implementieren, der mit einem USB-Host mit einem Standard-USB-A-Port verbunden werden kann
• Muss die Android -Debug -Brücke über USB implementieren (wie in Abschnitt 7 beschrieben)
• Muss einen USB -Massenspeicher -Client für den Wechsel-/Medienspeicher implementieren, ist in der vorhanden
Gerät
• Sollte den Micro -USB -Formfaktor auf der Geräteseite verwenden
• Sollte Unterstützung für die USB -Massenspeicherspezifikation implementieren (so dass entweder abnehmbar
oder ein fester Speicher auf dem Gerät kann über einen Host -PC zugegriffen werden.
• Kann einen nicht standardmäßigen Anschluss auf der Geräteseite enthalten, aber in diesem Fall mit einem Kabel versendet werden, das in der Lage ist
Verbinden Sie die benutzerdefinierte Pinout mit dem Standard-USB-A-Port
8.7. Navigationsschlüssel
Das Heim-, Menü- und Rückfunktionen sind für das Android -Navigationsparadigma von wesentlicher Bedeutung. Gerät
Implementierungen müssen diese Funktionen dem Benutzer jederzeit zur Verfügung stellen, unabhängig von der Anwendung
Zustand. Diese Funktionen sollten über dedizierte Schaltflächen implementiert werden. Sie können implementiert werden
Verwenden von Software, Gesten, Touch Panel usw., aber in diesem Fall müssen sie immer zugänglich und nicht dunkel oder dunkel oder
Stören Sie den verfügbaren Anwendungsanzeigebereich.
Geräteimplementierer sollten auch einen dedizierten Suchschlüssel bereitstellen. Geräteimplementierer können auch
Geben Sie Send und Endschlüssel für Telefonanrufe an.
8.8. W-lan
Die Geräteimplementierungen müssen 802.11b und 802.11g unterstützen und 802.11a unterstützen.

8.9. Kamera
Geräteimplementierungen müssen eine Kamera enthalten. Die mitgelieferte Kamera:
• Muss eine Auflösung von mindestens 2 Megapixeln haben
• Sollte entweder Hardware-Autofokus oder eine in der Kamera implementierte Software-Autofokus haben
Treiber (transparent für Anwendungssoftware)
• Kann feste Fokus- oder EDOF-Hardware (erweiterte Feldtiefe) aufweisen
• Kann einen Blitz enthalten. Wenn die Kamera einen Blitz enthält, darf die Blitzlampe nicht angezündet werden, während eine
android.hardware.camera.PreviewCallback -Instanz wurde in einer Kamera -Vorschau registriert
Oberfläche.
Geräteimplementierungen müssen das folgende Verhalten für die Kamera-bezogenen APIs implementieren
[Ressourcen, 27] :
1. Wenn eine Anwendung android.hardware.camera.Parameters.setPreviewFormat (int) noch nie genannt wurde,
Dann muss das Gerät Android.hardware.pixelformat.ycbcr_420_sp für Vorschreiberdaten verwenden
Bereitstellung für Anwendungsrufe.
2. Wenn eine Anwendung eine android.hardware.camera.PreviewCallback -Instanz und die
System ruft die OnPreviewFrame () -Methode auf, wenn das Vorschau -Format ycbcr_420_sp ist, die
Daten im Byte [] müssen in OnPreviewFrame () weitergegeben werden im Nv21 -Codierungsformat.
(Dies ist das Format, das nativ von der 7K -Hardwarefamilie verwendet wird.) Das heißt, Nv21 muss der Standard sein.
8.9.1. Nicht-Autofokus-Kameras
Wenn einem Gerät eine Autofokus -Kamera fehlt, muss der Geräte -Implementierer die zusätzlichen Anforderungen erfüllen
diese Abteilung. Geräteimplementierungen müssen die in Android 1.6 enthaltene vollständige Kamera -API implementieren
SDK -Dokumentation in gewisser Weise, unabhängig von den Funktionen der tatsächlichen Kamera -Hardware.
Bei Android 1.6 muss die Geräteimplementierung die folgenden Einrichtungen einhalten, wenn die Kamera fehlt:
1. Das System muss eine schreibgeschützte Systemeigenschaft mit dem Namen "Ro.workaround.noautofocus" enthalten.
mit dem Wert von "1". Dieser Wert soll von Anwendungen wie dem Android -Markt an verwendet werden
Identifizieren Sie die Gerätefunktionen selektiv und werden in einer zukünftigen Version von Android durch a ersetzt
robuste API.
2. Wenn eine Anwendung Android.hardware.camera.autofocus () aufruft, muss das System das aufrufen
OnAutofocus () Rückrufmethode für eine registrierte Methode
android.hardware.camera.autofocuscallback -Instanzen, obwohl eigentlich kein Fokussierung
passiert. Dies soll vermieden werden, dass vorhandene Anwendungen das Brechen durch immer auf einen Autofokus warten lassen
Rückruf, der niemals kommen wird.
3. Der Aufruf zur Autofocuscallback.onautofocus () -Methode muss vom Fahrer oder ausgelöst werden oder
Framework in einem neuen Ereignis auf dem Hauptfrequenz -Thread. Das heißt camera.autofocus ()
Ich darf Autofocuscallback nicht direkt anrufen.
Framework -Threading -Modell und wird Apps brechen.
8.10. Beschleunigungsmesser
Die Geräteimplementierungen müssen ein 3-Achsen-Beschleunigungsmesser enthalten und müssen in der Lage sein, Ereignisse bei AT zu liefern
mindestens 50 Hz. Das vom Beschleunigungsmesser verwendete Koordinatensystem muss dem Android -Sensor entsprechen
Koordinatensystem wie in den Android -APIs [Ressourcen , 28].

8.11. Kompass
Geräteimplementierungen müssen einen 3-Achsen-Kompass enthalten und mindestens in der Lage sein, Ereignisse liefern zu können
10 Hz. Das vom Kompass verwendete Koordinatensystem muss der Android -Sensorkoordinate entsprechen
System wie in der Android -API definiert [Ressourcen , 28].
8.12. GPS
Die Geräteimplementierungen müssen ein GPS enthalten und sollten irgendeine Form von "assistiertem GPS" enthalten.
Technik zur Minimierung der GPS-Sperrzeit.
8.13. Telefonie
Geräteimplementierungen:
• Muss entweder die GSM- oder die CDMA -Telefonie enthalten
• Muss die entsprechenden APIs wie in der Android SDK -Dokumentation unter detailliert implementieren
Entwickler.android.com
Beachten Sie, dass diese Anforderung impliziert, dass Nicht-Phone-Geräte nicht mit Android 1.6 kompatibel sind. Android
1.6 Geräte müssen Telefonie -Hardware enthalten. Informationen zu Nicht-Phone finden Sie in Anhang C
Geräte.
8.14. Lautstärkeregler
Android-kompatible Geräte müssen einen Mechanismus enthalten, damit der Benutzer die Erhöhung und Verringerung des
Audiovolumen. Geräteimplementierungen müssen diese Funktionen dem Benutzer jederzeit zur Verfügung stellen.
unabhängig vom Anwendungszustand. Diese Funktionen können mithilfe physischer Hardwareschlüssel implementiert werden.
Software, Gesten, Touch Panel usw., aber sie müssen immer zugänglich und nicht dunkel oder stören
mit dem verfügbaren Anwendungsanzeigebereich (siehe Anzeige oben).
Wenn diese Schaltflächen verwendet werden, müssen die entsprechenden Schlüsselereignisse generiert und an die gesendet werden
Vordergrundanwendung. Wenn das Ereignis nicht abgefangen und von der Anwendung versenkt wird, dann Gerät
Die Implementierung muss das Ereignis als Systemvolumensteuerung behandeln.
9. Leistungskompatibilität
Eines der Ziele des Android -Kompatibilitätsprogramms ist es, eine konsistente Anwendungserfahrung für sicherzustellen
Verbraucher. Kompatible Implementierungen müssen nicht nur sicherstellen, dass Anwendungen einfach richtig ausgeführt werden
Das Gerät, aber dass sie dies mit angemessener Leistung und insgesamt guter Benutzererfahrung tun.
Geräteimplementierungen müssen die wichtigsten Leistungsmetriken eines Android 1.6 -kompatiblen Geräts erfüllen.
Wie in der folgenden Tabelle:
Metrisch
Leistungsschwelle
Kommentare

Dies wird von CTS getestet.
Die folgenden Anwendungen
Die Startzeit wird als die Gesamtzeit an gemessen
sollte innerhalb der starten
Laden Sie die Standardaktivität für die
Anwendung
angegebene Zeit.
Anwendung, einschließlich der Zeit, die zum Starten des Starts benötigt wird
Startzeit
Browser: weniger als 1300 ms
Linux -Prozess laden Sie das Android -Paket in die
MMS/SMS: weniger als 700 ms
Dalvik VM und rufen Sie OnCreate an.
Alarmclock: Weniger als 650 ms
Mehrere Anwendungen werden sein
Dies wird von CTS getestet.
gestartet. Neu starten
Die gleichzeitige erste Anwendung sollte
Anwendungen
vollständige Einnahme weniger als die
Originalstartzeit.
10. Sicherheitsmodellkompatibilität
Geräteimplementierungen müssen ein Sicherheitsmodell implementieren, das mit der Sicherheit der Android -Plattform übereinstimmt
Modell wie in Sicherheits- und Berechtigungsreferenzdokument in den APIs [Ressourcen, 29] in der
Android Developer -Dokumentation. Geräteimplementierungen müssen die Installation von selbstsigniert unterstützen
Bewerbungen ohne zusätzliche Berechtigungen/Zertifikate von Dritten/Behörden.
Insbesondere müssen kompatible Geräte die folgenden Sicherheitsmechanismen unterstützen:
10.1. Berechtigungen
Geräteimplementierungen müssen das in Android definierte Android -Berechtigungsmodell unterstützen
Entwicklerdokumentation [ Ressourcen , 9]. Insbesondere müssen Implementierungen jede Genehmigung durchsetzen
definiert wie in der SDK -Dokumentation beschrieben; Keine Berechtigungen dürfen weggelassen, geändert oder ignoriert werden.
Implementierungen können zusätzliche Berechtigungen hinzufügen, vorausgesetzt, die neuen Berechtigungs -ID -Zeichenfolgen sind nicht in der
Android.* Namespace.
10.2. Benutzer- und Prozessisolation
Geräteimplementierungen müssen das Android Application Sandbox -Modell unterstützen, bei dem jede Anwendung
Läuft als einzigartige UID im Unix-Stil und in einem separaten Prozess.
Geräteimplementierungen müssen unterstützen, dass mehrere Anwendungen als die gleiche Linux -Benutzer -ID bereitgestellt werden, die bereitgestellt werden
dass die Anwendungen ordnungsgemäß signiert und konstruiert sind, wie in den Sicherheits- und Berechtigungen definiert
Referenz [ Ressourcen , 29].

10.3. Dateisystem Berechtigungen
Geräteimplementierungen müssen das Modell der Android -Dateizugriffsberechtigungen wie definiert in AS unterstützen
Definiert in der Referenz für Sicherheit und Berechtigungen [Ressourcen , 29].
11. Kompatibilitätstest Suite
Geräteimplementierungen müssen die Android -Kompatibilitätstestsuite (CTS) [ Ressourcen, 3] übergeben
Aus dem Android Open Source -Projekt über die endgültige Versandsoftware auf dem Gerät. Zusätzlich,
Geräteimplementierer sollten die Referenzimplementierung im Android Open Source -Baum als verwenden
viel wie möglich und muss die Kompatibilität in Fällen von Unklarheiten in CTS und für alle sicherstellen
Neuauflagen von Teilen des Referenzquellcode.
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 und mehreren Überarbeitungen der
CTs können für Android 1.6 veröffentlicht werden. Solche Veröffentlichungen beheben jedoch nur Verhaltensfehler in den CTs
Tests und werden keine neuen Tests, Verhaltensweisen oder APIs für eine bestimmte Plattformfreigabe auferlegen.
12. Kontaktieren Sie uns
Sie können sich an das Android -Kompatibilitätsteam unter compatibility@android.com wenden
Diese Definition in dieser Kompatibilität und um Feedback zu dieser Definition zu geben.

Anhang A: Erforderliche Anwendungsabsichten
Hinweis: Diese Liste ist vorläufig und wird in Zukunft aktualisiert.
Anwendungsaktionen
Schemata -Mime -Typen
(keiner)
Text/einfach
http
text/html
Browser
Android.intent.Action.View
https
Anwendung/xhtml+xml
Anwendung/
vnd.wap.xhtml+xml
(keiner)
android.intent.action.web_search
http
(keiner)
https
android.media.action.image_capture
android.media.action.still_image_camera
Kamera
android.media.action.video_camera
android.media.action.video_capture
vnd.android.cursor.dir/
Android.intent.Action.View
Bild
android.intent.action.get_content
vnd.android.cursor.dir/
android.intent.action.pick
Video
Android.intent.Action.attach_data
Bild/*
Video/*
Android.intent.Action.View
rtsp
Video/mp4
Video/3GP
Android.intent.Action.View
http
Video/3GPP
Video/3GPP2
android.intent.action.dial
Telefon /
Android.intent.Action.View
Tel
Kontakte
android.intent.action.call
android.intent.action.dial
vnd.android.cursor.dir/
Android.intent.Action.View
Person

vnd.android.cursor.dir/
Person
vnd.android.cursor.dir/
android.intent.action.pick
Telefon
vnd.android.cursor.dir/
Anschrift
vnd.android.cursor.item/
Person
vnd.android.cursor.item/
android.intent.action.get_content
Telefon
vnd.android.cursor.item/
Anschrift
Text/einfach
Email
android.intent.action.send
Bild/*
Video/*
Android.intent.Action.View
Mailto
android.intent.action.sendto
SMS
Android.intent.Action.View
smsto
Sms / mms android.intent.action.sendto
mmm
mmsto
Audio/*
Anwendung/OGG
Musik
Android.intent.Action.View
Datei
Anwendung/X-OGG
Anwendung/iTunes
Audio/MP3
Audio/X-MP3
Android.intent.Action.View
http
Audio/MPEG
Audio/MP4
Audio/MP4A-Latm
vnd.android.cursor.dir/
Künstlerbum
vnd.android.cursor.dir/
Album
vnd.android.cursor.dir/
android.intent.action.pick
läuft gerade
vnd.android.cursor.dir/
Schiene
nd.android.cursor.dir/
Wiedergabeliste
vnd.android.cursor.dir/
Video
Medien/*
Audio/*
android.intent.action.get_content
Anwendung/OGG
Anwendung/X-OGG
Video/*

Inhalt
Paket
Android.intent.Action.View
Datei
Installateur
Paket
Datei
android.intent.action.package_install
http
https
android.intent.action.all_apps
Android.Settings.Settings
Android.Settings.Wireless_Setings
Android.Settings.AirPLANE_MODE_SETTINGS
Android.Settings.wifi_Setings
Android.Settings.APN_Settings
Android.Settings.Bluetooth_Setings
Android.Settings.date_Setings
Android.Settings.locale_Setings
Einstellungen
Android.Settings.Input_Method_Setings
com.android.settings.sound_Setings
com.android.settings.display_Setings
Android.Settings.Security_Setting
Android.Settings.location_Source_Setings
Android.Settings.internal_Storage_Setings
Android.Settings.Memory_Card_Setings
android.intent.action.set_wallpaper
Suchen
android.intent.action.search
Abfrage
android.intent.action.search_long_press
Stimme
android.intent.action.voice_command
Kontaktverwaltung
Absicht Aktion
Beschreibung
Startet eine Aktivität, mit der der Benutzer auswählen kann
Attach_image
Ein Kontakt zum Anhängen eines Bildes an.
Gebraucht
Extra_create_description
mit Show_OR_CREATE_CONTACT an
Geben Sie eine genaue Beschreibung an

angezeigt, wenn Sie den Benutzer auffordern
Erstellen eines neuen Kontakts.
Gebraucht
mit Show_OR_CREATE_CONTACT an
Extra_force_create
Erzwingen Sie, einen neuen Kontakt zu erstellen, wenn nein
passender Kontakt gefunden.
Dies ist die Absicht, die abgefeuert wird, wenn a
Search_suggestion_clicked
Suchvorschlag wird angeklickt.
Dies ist die Absicht, die abgefeuert wird, wenn a
Such_suggestion_create_contact_clicked Suchvorschlag zum Erstellen von a
Kontakt wird angeklickt.
Dies ist die Absicht, die abgefeuert wird, wenn a
Search_suggestion_dial_number_clicked
Suchvorschlag zum Wählen einer Nummer
wird angeklickt.
Nimmt als Daten URI mit einem Mailto ein:
Show_or_create_contact
oder Tel: Schema.

Anhang B: Erforderliche Broadcast -Absichten Hinweis: Diese Liste ist vorläufig und wird sein
In Zukunft aktualisiert.
Absicht Aktion
Beschreibung
Rundfunkaktion: Dies wird einmal nach dem ausgestrahlt
Action_boot_completed
Das System hat den Booten beendet.
Broadcast -Aktion: Dies wird einmal ausgestrahlt, wenn a
Action_call_button
Anruf wird empfangen.
Broadcast -Aktion: Die "Kamera -Taste" war
Action_camera_button
gedrückt.
Rundfunkaktion: der aktuelle
Action_Configuration_Changed
Gerätekonfiguration (Ausrichtung, Gebietsschema usw.) hat
geändert.
Action_date_changed
Rundfunkaktion: Das Datum hat sich geändert.
Rundfunkaktion: Zeigt eine geringe Speicherbedingung an
Action_device_storage_low
Auf dem Gerät
Rundfunkaktion: Zeigt eine geringe Speicherbedingung an
Action_device_storage_ok
auf dem Gerät existiert nicht mehr
Rundfunkaktion: Kabelgebundenes Headset in oder
Action_headset_plug
nicht angeschlossen.
Rundfunkaktion: Eine Eingabemethode war
Action_input_method_changed
geändert.
Rundfunkaktion: Externe Medien wurden entfernt
Action_media_bad_removal
Aus SD -Kartensteckplatz, aber der Mount Point war nicht
unmontiert.
Broadcast -Aktion: Der "Medienknopf" war
Action_media_button
gedrückt.
Rundfunkaktion: Externe Medien sind vorhanden und
Scheibenscheiben überprüft den Weg zum Mountspunkt für
Action_Media_Checking
Die Überprüfungsmedien sind in der enthalten
Intent.mdata Field.
Broadcast -Aktion: Der Benutzer hat den Wunsch zum Ausdruck gebracht
Action_media_eject
Entfernen Sie die externen Speichermedien.
Rundfunkaktion: Externe Medien sind vorhanden und
Action_media_mounted
am Mountspunkt montiert.
Rundfunkaktion: Externe Medien sind vorhanden, aber ist aber
Verwenden eines inkompatiblen FS (oder ist leer) der Weg zu Pfad zu
Action_media_nofs
Der Mountspunkt für die Überprüfungsmedien ist
in der Absicht enthalten.mdata -Feld.
Rundfunkaktion: Externe Medien waren
Action_media_removed
ENTFERNT.
Broadcast -Aktion: Der Medienscanner ist abgeschlossen
Action_media_scanner_finished
Scannen eines Verzeichnisses.
Sendung Aktion: Fordern Sie den Medienscanner an an
Action_media_scanner_scan_file
Scannen Sie eine Datei und fügen Sie sie der Mediendatenbank hinzu.

Broadcast -Aktion: Der Medienscanner hat begonnen
Action_media_scanner_started
Scannen eines Verzeichnisses.
Rundfunkaktion: Externe Medien sind unmontiert
Action_media_shared
Weil es über USB -Massenspeicher geteilt wird.
Rundfunkaktion: Externe Medien sind aber vorhanden, aber
Action_media_unmountable
kann nicht montiert werden.
Rundfunkaktion: Externe Medien sind vorhanden, aber aber
Action_media_unmounted
nicht an seinem Mountspunkt montiert.
Rundfunkaktion: Ein ausgehender Anruf steht kurz vor dem Auftritt
Action_new_outging_call
platziert.
Broadcast -Aktion: Ein neues Anwendungspaket hat
Action_package_added
wurde auf dem Gerät installiert.
Broadcast -Aktion: Ein vorhandenes Anwendungspaket
Action_package_changed
wurde verändert (z. B. eine Komponente war
aktiviert oder deaktiviert.
Broadcast -Aktion: Der Benutzer hat die Daten von gelöscht
Ein Packet. Dies sollte vorausgehen
durch action_package_restarted, danach
Action_package_data_cleared
Alle seine anhaltenden Daten werden gelöscht und diese
Sendung gesendet. Beachten Sie, dass das gelöschte Paket
Erhält diese Sendung nicht . Die Daten enthalten
Der Name des Pakets.
Broadcast -Aktion: Ein vorhandenes Anwendungspaket
wurde vom Gerät entfernt. Die Daten
Action_package_removed
Enthält den Namen des Pakets. Das Paket
Das wird diese Absicht nicht erhält.
Broadcast -Aktion: Eine neue Version einer Anwendung
Action_package_replaced
Das Paket wurde installiert, wodurch ein vorhandenes Austausch ersetzt wurde
Version, die zuvor installiert wurde.
Broadcast -Aktion: Der Benutzer hat a neu gestartet
Paket und alle seine Prozesse wurden getötet.
Alle damit verbundenen Laufzeitstaat (Prozesse,
Action_package_restarted
Alarme, Benachrichtigungen usw.) sollten entfernt werden. Notiz
dass das neu gesteuerte Paket dies nicht erhält
übertragen. Die Daten enthalten den Namen der
Paket.
Rundfunkaktion: Einige Inhaltsanbieter haben
Teile ihres Namespace, in denen sie neu veröffentlichen
Action_provider_changed
Ereignisse oder Elemente, die der Benutzer besonders sein kann
Interesse an.
Action_screen_off
Broadcast -Aktion: Nach dem Ausschalten des Bildschirms gesendet.
Action_screen_on
Broadcast -Aktion: Nach dem Einschalten des Bildschirms gesendet.
Broadcast -Aktion: Eine Benutzer -ID wurde entfernt
Action_uid_removed
aus dem System.
Broadcast -Aktion: Das Gerät hat USB eingegeben
Action_ums_connected
Massenspeichermodus.

Broadcast -Aktion: Das Gerät hat USB verlassen
Action_ums_disconnected
Massenspeichermodus.
Broadcast -Aktion: gesendet, wenn der Benutzer anwesend ist
Action_user_present
Nach dem Aufwachen des Geräts (z. B. wenn der KeyGuard ist
gegangen).
Rundfunkaktion: Das aktuelle System im System Tapete
Action_wallpaper_changed
hat sich verändert.
Action_time_changed
Rundfunkaktion: Die Zeit wurde festgelegt.
Action_time_tick
Rundfunkaktion: Die aktuelle Zeit hat sich geändert.
Action_timezone_changed
Rundfunkaktion: Die Zeitzone hat sich geändert.
Rundfunkaktion: Der Ladezustand oder die Gebühr
Action_battery_changed
Der Batteriepegel hat sich geändert.
Rundfunkaktion: Zeigt einen niedrigen Batteriezustand an
Action_battery_low
Auf dem Gerät. Diese Sendung entspricht der
"Low Battery Warning" -Systemdialog.
Broadcast Action: Zeigt an, dass der Akku jetzt in Ordnung ist
nach niedrigem. Dies wird verschickt
Action_battery_okay
Nach action_battery_low nach dem Akku
ist wieder in einen guten Zustand gegangen.
Netzwerkstaat
Absicht Aktion
Beschreibung
Sendungsabsichten Aktion, die anzeigen, dass die
Network_state_changed_action
Der Zustand der Wi-Fi-Konnektivität hat sich geändert.
Sendungsabsichten Aktion, die anzeigen, dass die
Rssi_changed_action
RSSI (Signalstärke) hat sich verändert.
Sendungsabsichten Aktion, die darauf hinweisen, dass a
Supplicant_State_Changed_Action
Die Verbindung zum Supplicant war
etabliert oder verloren.
Sendungsabsichten Aktion, die dieses Wi-Fi anzeigen
WiFi_State_Changed_action
wurde aktiviert, deaktiviert, aktiviert,
Deaktivieren oder unbekannt.
Die Netzwerk -IDs der konfigurierten Netzwerke
Network_ids_changed_action
hätte sich verändern können.
Sendungsabsichten Aktion, die anzeigen, dass die
Action_background_data_seting_changed Einstellung für die Hintergrunddatenverbrauch hat
Werte geändert.
Sendungsabsichten, die darauf hinweisen, dass eine Änderung in
Connectivity_action
Die Netzwerkkonnektivität ist aufgetreten.
Broadcast -Aktion: Der Benutzer hat die umgeschaltet
Action_airplane_mode_changed
Telefon in oder aus dem Flugzeugmodus.

Anhang C: Zukünftige Überlegungen Dieser Anhang verdeutlicht bestimmte Teile dieser Android
1.6 Kompatibilitätsdefinition und in einigen Fällen erwartete oder geplante Änderungen für a diskutieren
zukünftige Version der Android -Plattform. Dieser Anhang dient nur zu Informations- und Planungszwecken, und
ist nicht Teil der Kompatibilitätsdefinition für Android 1.6.
1. Nicht-Telephone-Geräte
Android 1.6 ist ausschließlich für Telefone gedacht. Telefoniefunktionalität ist nicht optional. Zukünftige Versionen
Von der Android-Plattform wird erwartet, dass sie die Telefonie optional macht (und somit nicht-Telefon-Android zulässt
Geräte), aber nur Telefone sind mit Android 1.6 kompatibel.
2. Bluetooth -Kompatibilität
Die Android 1.6 -Veröffentlichung von Android unterstützt keine Bluetooth -APIs, daher aus Sicht der Kompatibilität
Bluetooth setzt keine Überlegungen für diese Version der Plattform auf. Eine zukünftige Version jedoch
von Android wird Bluetooth -APIs einführen. Zu diesem Zeitpunkt wird die Unterstützung von Bluetooth obligatorisch für
Kompatibilität.
Infolgedessen empfehlen wir dringend, dass Android 1.6 -Geräte Bluetooth enthalten, damit dies der Fall ist
kompatibel mit zukünftigen Versionen von Android, die Bluetooth benötigen.
3. Erforderliche Hardwarekomponenten
Alle Hardwarekomponenten in Abschnitt 8 (einschließlich WLAN, Magnetometer/Kompass, Beschleunigungsmesser usw.) sind
Erforderlich und kann nicht weggelassen werden. Zukünftige Versionen von Android werden voraussichtlich einige (aber nicht alle) von machen
Diese Komponenten optional, zusammen mit entsprechenden Werkzeugen, damit Entwickler von Drittanbietern diese verarbeiten können
Änderungen.
4. Probenanwendungen
Das Kompatibilitätsdefinitionsdokument für eine zukünftige Version von Android wird ein umfangreicheres und umfassender sein
Repräsentative Liste der Anwendungen als die in Abschnitt 4 oben aufgeführten. Für Android 1.6 die
Die in Abschnitt 4 aufgeführten Anwendungen müssen getestet werden.
5. Touchscreens
Zukünftige Versionen der Kompatibilitätsdefinition ermöglichen es möglicherweise, dass Geräte Touchscreens weglassen.
Derzeit ist ein Großteil der Implementierung von Android Framework jedoch die Existenz von a
Touch-Screen; Das Auslassen eines Touchscreen würde wesentlich alle aktuellen Android-Anwendungen von Drittanbietern brechen.
In Android 1.6 ist für die Kompatibilität ein Touchscreen erforderlich.

6. Leistung
Zukünftige Versionen von CTS werden auch die CPU -Auslastung und -verlust der folgenden Messung messen
Komponenten einer Implementierung:
• 2D -Grafiken
• 3D -Grafiken
• Video-Wiedergabe
• Audiowiedergabe
• Bluetooth A2DP -Wiedergabe

Kompatibilitätsdefinition für Android 1.6

Dokumentübersicht