Cette page a été traduite par l'API Cloud Translation.

Définition de la compatibilité Android 1.6

Définition de la compatibilité Android : Android 1.6
Android 1.6 r2
Google Inc.
compatibilité@android.com

1. Introduction
Ce document énumère les conditions qui doivent être remplies pour que les téléphones mobiles soient
compatible avec Android 1.6. Cette définition suppose une connaissance du programme de compatibilité Android
[Ressources, 1].
L'utilisation de "doit", "ne doit pas", "obligatoire", "doit", "ne doit pas", "devrait", "ne devrait pas", "recommandé",
"peut" et "facultatif" sont conformes à la norme IETF définie dans la RFC2119 [ Ressources , 2].
Tel qu'utilisé dans ce document, un « implémenteur de dispositif » ou « implémenteur » est une personne ou une organisation développant
une solution matérielle/logicielle fonctionnant sous Android 1.6. Une « implémentation de dispositif » ou une « implémentation » est la
solution matérielle/logicielle ainsi développée.
Pour être considéré comme compatible avec Android 1.6, les implémentations d'appareil :
1. DOIT répondre aux exigences présentées dans cette définition de compatibilité, y compris tous les documents
incorporé par référence.
2. DOIT réussir la suite de tests de compatibilité Android (CTS) disponible dans le cadre d'Android Open
Projet source [ Ressources , 3]. Le CTS teste la plupart des composants décrits dans ce document, mais pas tous .
document.
Lorsque cette définition ou le CTS est muet, ambigu ou incomplet, c'est la responsabilité de l'appareil
implémenteur pour assurer la compatibilité avec les implémentations existantes. Pour cette raison, Android Open
Source Project [ Ressources , 4] est à la fois la référence et l’implémentation préférée d’Android. Appareil
les implémenteurs sont fortement encouragés à baser leurs implémentations sur le code source « en amont »
disponible à partir du projet Android Open Source. Bien que certains composants puissent hypothétiquement être remplacés
avec des implémentations alternatives, cette pratique est fortement déconseillée, car la réussite des tests CTS deviendra
nettement plus difficile. Il est de la responsabilité du responsable de la mise en œuvre de garantir une compatibilité comportementale totale avec
l'implémentation Android standard, y compris et au-delà de la suite de tests de compatibilité.
2. Ressources
Cette définition de compatibilité fait référence à un certain nombre de ressources qui peuvent être obtenues ici.
1. Présentation du programme de compatibilité Android : https://sites.google.com/a/android.com/compatibility/
Comment ça fonctionne
2. Niveaux d'exigence IETF RFC2119 : http://www.ietf.org/rfc/rfc2119.txt
3. Suite de tests de compatibilité : http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite-cts
4. Projet Open Source Android : http://source.android.com/
5. Définitions et documentation de l'API : http://developer.android.com/reference/packages.html
6. Fournisseurs de contenu : http://code.google.com/android/reference/android/provider/package-
résumé.html
7. Ressources disponibles : http://code.google.com/android/reference/available-resources.html
8. Fichiers du manifeste Android : http://code.google.com/android/devel/bblocks-manifest.html
9. Référence des autorisations Android : http://developer.android.com/reference/android/
Manifeste.permission.html
10. Constantes de construction : http://developer.android.com/reference/android/os/Build.html
11. WebView : http://developer.android.com/reference/android/webkit/WebView.html
12. Extensions du navigateur Gears : http://code.google.com/apis/gears/

13. Spécification de la machine virtuelle Dalvik, trouvée dans le répertoire dalvik/docs d'un code source
vérifier; également disponible sur 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. Notifications : http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. Guide de style des icônes de la barre d'état : http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Gestionnaire de recherche : http://developer.android.com/reference/android/app/SearchManager.html
18. Toast : http://developer.android.com/reference/android/widget/Toast.html
19. Applications pour Android : http://code.google.com/p/apps-for-android
20. Description du fichier apk Android : http://developer.android.com/guide/topics/fundamentals.html
21. Pont de débogage Android (adb) : http://code.google.com/android/reference/adb.html
22. Service de surveillance de débogage Dalvik (ddms) : http://code.google.com/android/reference/ddms.html
23. Singe : http://developer.android.com/guide/developing/tools/monkey.html
24. Documentation sur l'indépendance de l'affichage :
25. Constantes de configuration : http://developer.android.com/reference/android/content/res/
Configuration.html
26. Afficher les métriques : http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Caméra : http://developer.android.com/reference/android/hardware/Camera.html
28. Espace de coordonnées du capteur : http://developer.android.com/reference/android/hardware/
SensorEvent.html
29. Référence sur la sécurité et les autorisations Android : http://developer.android.com/guide/topics/security/
sécurité.html
Beaucoup de ces ressources sont dérivées directement ou indirectement du SDK Android 1.6 et seront
fonctionnellement identique aux informations contenues dans la documentation de ce SDK. Dans tous les cas où cela
La définition de compatibilité n'est pas d'accord avec la documentation du SDK, la documentation du SDK est considérée
faisant autorité. Tous les détails techniques fournis dans les références incluses ci-dessus sont considérés par inclusion
pour faire partie de cette définition de compatibilité.
3. Logiciel
La plateforme Android comprend à la fois un ensemble d'API gérées (« hard ») et un ensemble d'API dites « soft »
tels que le système Intent, les API de code natif et les API d'application Web. Cette section détaille les difficultés et
des API logicielles qui font partie intégrante de la compatibilité, ainsi que certaines autres interfaces techniques et utilisateur pertinentes
comportements. Les implémentations de périphériques DOIVENT être conformes à toutes les exigences de cette section.
3.1. Compatibilité des API gérées
L'environnement d'exécution géré (basé sur Dalvik) est le principal véhicule pour les applications Android. Le
L'interface de programmation d'applications (API) Android est l'ensemble des interfaces de la plate-forme Android exposées à
applications exécutées dans l’environnement de machine virtuelle gérée. Les implémentations de périphériques DOIVENT fournir des
implémentations, y compris tous les comportements documentés, de toute API documentée exposée par Android
1.6 SDK, tel que :
1. API de base du langage Java Android [Ressources, 5].
2. Fournisseurs de contenu [Ressources , 6].
3. Ressources [Ressources, 7].
4. Attributs et éléments AndroidManifest.xml [Ressources, 8].

Les implémentations de périphériques NE DOIVENT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter
du comportement documenté, ou inclure des no-ops, sauf là où spécifiquement autorisé par cette compatibilité
Définition.
3.2. Compatibilité des API logicielles
En plus des API gérées de la section 3.1, Android inclut également un important « logiciel » d'exécution uniquement.
API, sous la forme d'éléments tels que les intentions, les autorisations et les aspects similaires des applications Android
qui ne peut pas être appliqué au moment de la compilation de l’application. Cette section détaille les API "soft" et le système
comportements requis pour la compatibilité avec Android 1.6. Les implémentations de périphériques DOIVENT répondre à toutes les
exigences présentées dans cette section.
3.2.1. Autorisations
Les implémenteurs de périphériques DOIVENT prendre en charge et appliquer toutes les constantes d'autorisation telles que documentées par le
Page de référence des autorisations [ Ressources , 9]. Notez que la section 10 répertorie les exigences supplémentaires liées à
le modèle de sécurité Android.
3.2.2. Paramètres de construction
Les API Android incluent un certain nombre de constantes sur la classe android.os.Build [Ressources, 10] qui sont
destiné à décrire le dispositif actuel. Pour fournir des valeurs cohérentes et significatives sur tous les appareils
implémentations, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs auxquelles
les implémentations de périphériques DOIVENT être conformes.
Paramètre
commentaires
La version du système Android actuellement en cours d'exécution, en version humaine.
android.os.Build.VERSION.RELEASE
format lisible. Pour Android 1.6, ce champ DOIT avoir la valeur chaîne
"1,6".
La version du système Android en cours d'exécution, dans un format
android.os.Build.VERSION.SDK
accessible au code d’application tiers. Pour Android 1.6, ce champ
DOIT avoir la valeur entière 4.
Une valeur choisie par le responsable de la mise en œuvre du périphérique désignant la version spécifique
du système Android en cours d'exécution, dans un format lisible par l'homme.
Cette valeur NE DOIT PAS être réutilisée pour les différentes versions livrées à la fin
Utilisateurs d'Android.os.Build.VERSION.INCREMENTAL. Une utilisation typique de ce champ est d'indiquer quel numéro de build ou
L'identifiant de changement de contrôle de source a été utilisé pour générer la version. Là
Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'il
NE DOIT PAS être nul ou une chaîne vide ("").
Une valeur choisie par le responsable de la mise en œuvre du dispositif identifiant le problème interne spécifique.
matériel utilisé par l'appareil, dans un format lisible par l'homme. Une utilisation possible
android.os.Build.BOARD
de ce champ est d'indiquer la révision spécifique de la carte alimentant le
appareil. Il n'y a aucune exigence sur le format spécifique de ce champ,
sauf qu'il NE DOIT PAS être nul ou une chaîne vide ("").
Une valeur choisie par le responsable de la mise en œuvre du périphérique identifiant le nom du
android.os.Build.BRAND
entreprise, organisation, individu, etc. qui a produit l'appareil, en
format lisible par l'homme. Une utilisation possible de ce champ est d'indiquer l'OEM

et/ou l'opérateur qui a vendu l'appareil. Il n'y a aucune exigence sur le
format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ou vide
chaîne ("").
Une valeur choisie par le responsable de la mise en œuvre du dispositif identifiant le
configuration ou révision de la carrosserie (parfois appelée « industrielle)
android.os.Build.DEVICE
design") de l'appareil. Il n'y a aucune exigence sur le format spécifique
de ce champ, sauf qu'il NE DOIT PAS être nul ou la chaîne vide ("").
Chaîne qui identifie de manière unique cette build. Cela DEVRAIT être raisonnablement
lisible par l'homme. Il DOIT suivre ce modèle :
$(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)
Par exemple : acme/mydevicel/generic/generic:Donut/ERC77/
3359 : userdebug/test-keys
L'empreinte digitale NE DOIT PAS inclure d'espaces. Si d'autres champs inclus dans le
le modèle ci-dessus contient des espaces, ils DEVRAIENT être remplacés par l'ASCII
caractère de soulignement ("_") dans l'empreinte digitale.
Une chaîne qui identifie de manière unique l'hôte sur lequel la build a été construite, en langage humain.
android.os.Build.HOST
format lisible. Il n'y a aucune exigence sur le format spécifique de ce
champ, sauf qu'il NE DOIT PAS être nul ou une chaîne vide ("").
Un identifiant choisi par le responsable de la mise en œuvre du dispositif pour faire référence à un
version, dans un format lisible par l'homme. Ce champ peut être de la même manière que
android.os.Build.VERSION.INCREMENTAL, mais DEVRAIT être une valeur
android.os.Build.ID
destiné à être quelque peu significatif pour les utilisateurs finaux. Il n'y a pas
exigences sur le format spécifique de ce champ, sauf qu'il NE DOIT PAS
être null ou la chaîne vide ("").
Une valeur choisie par l'implémenteur du périphérique contenant le nom du
périphérique tel que connu de l'utilisateur final. Cela DEVRAIT être le même nom
android.os.Build.MODEL
sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Il n'y a pas
exigences sur le format spécifique de ce champ, sauf qu'il NE DOIT PAS
être null ou la chaîne vide ("").
Une valeur choisie par l'implémenteur du périphérique contenant le développement
nom ou nom de code de l'appareil. DOIT être lisible par l'homme, mais ce n'est pas le cas
android.os.Build.PRODUCT
nécessairement destiné à être consulté par les utilisateurs finaux. Il n'y a aucune exigence
sur le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ou le
chaîne vide ("").
Une liste de balises séparées par des virgules choisies par le responsable de l'implémentation du périphérique et qui
distinguer davantage la construction. Par exemple, « non signé,débogage ». Ce champ
android.os.Build.TAGS
NE DOIT PAS être nul ou une chaîne vide (""), mais une seule balise (telle que
"libération"), c'est bien.
android.os.Build.TIME
Une valeur représentant l’horodatage du moment où la génération a eu lieu.
Une valeur choisie par l'implémenteur du périphérique spécifiant le temps d'exécution
configuration de la construction. Ce champ DEVRAIT avoir l'une des valeurs
android.os.Build.TYPE
correspondant aux trois configurations typiques du runtime Android : "user",
"userdebug" ou "eng".
Un nom ou un ID utilisateur de l'utilisateur (ou de l'utilisateur automatisé) qui a généré le
android.os.Build.USER
construire. Il n'y a aucune exigence sur le format spécifique de ce champ,
sauf qu'il NE DOIT PAS être nul ou une chaîne vide ("").

3.2.3. Compatibilité des intentions
Android utilise les intentions pour réaliser une intégration faiblement couplée entre les applications. Cette section décrit
exigences liées aux modèles d’intention qui DOIVENT être respectées par les implémentations de périphériques. Par
"honoré", cela signifie que l'implémenteur de l'appareil DOIT fournir une activité, un service ou autre Android.
composant qui spécifie un filtre d'intention correspondant et se lie à et implémente le comportement correct pour chaque
modèle d’intention spécifié.
3.2.3.1. Intentions principales de l'application
Le projet Android en amont définit un certain nombre d'applications principales, telles qu'un numéroteur téléphonique, un calendrier,
carnet de contacts, lecteur de musique, etc. Les implémenteurs de périphériques PEUVENT remplacer ces applications par
versions alternatives.
Cependant, toutes ces versions alternatives DOIVENT respecter les mêmes modèles d'intention fournis par le système en amont.
projet. (Par exemple, si un appareil contient un lecteur de musique alternatif, il doit toujours respecter le modèle d'intention
émis par des applications tierces pour choisir une chanson.) Les implémentations de périphérique DOIVENT prendre en charge tous les modèles d'intention
répertoriés à l’Annexe A.
3.2.3.2. Remplacements d'intention
Comme Android est une plate-forme extensible, les implémenteurs de périphériques DOIVENT autoriser chaque modèle d'intention décrit dans
L'Annexe A doit être remplacée par des applications tierces. Le projet open source Android en amont
le permet par défaut ; les implémenteurs de périphériques NE DOIVENT PAS attacher de privilèges spéciaux aux applications système.
l'utilisation de ces modèles d'intention, ou empêcher des applications tierces de se lier à et d'en prendre le contrôle
ces modèles. Cette interdiction inclut spécifiquement la désactivation de l'interface utilisateur « Chooser » qui permet
l'utilisateur peut choisir entre plusieurs applications qui gèrent toutes le même modèle d'intention.
3.2.3.3. Espaces de noms d'intention
Les implémenteurs de périphériques NE DOIVENT PAS inclure de composant Android qui honore une nouvelle intention ou
Modèles d'intention de diffusion à l'aide d'une ACTION, d'une CATÉGORIE ou d'une autre chaîne de clé dans l'espace de noms Android.*.
Les implémenteurs de périphériques NE DOIVENT PAS inclure de composants Android qui respectent une nouvelle intention ou
Modèles d'intention de diffusion à l'aide d'une ACTION, d'une CATÉGORIE ou d'une autre chaîne de clé dans un espace de package
appartenant à une autre organisation. Les responsables de la mise en œuvre du dispositif NE DOIVENT PAS modifier ou étendre l'intention
modèles répertoriés dans les annexes A ou B.
Cette interdiction est analogue à celle spécifiée pour les classes du langage Java à la section 3.6.

3.2.3.4. Intentions de diffusion
Les applications tierces s'appuient sur la plateforme pour diffuser certaines intentions afin de les informer des changements dans le
environnement matériel ou logiciel. Les appareils compatibles Android DOIVENT diffuser l'émission publique
Intentions en réponse aux événements système appropriés. Une liste des intentions de diffusion requises est fournie dans
Appendice B; cependant, notez que le SDK peut définir des intentions de diffusion supplémentaires, qui DOIVENT également être
honoré.
3.3. Compatibilité API native
Le code managé exécuté dans Dalvik peut appeler le code natif fourni dans le fichier .apk de l'application en tant qu'ELF
Fichier .so compilé pour l’architecture matérielle du périphérique appropriée. Les implémentations de périphériques DOIVENT inclure
prise en charge du code exécuté dans l'environnement géré pour appeler du code natif, à l'aide du standard Java
Sémantique de l'interface native (JNI). Les API suivantes doivent être disponibles pour le code natif :
• libc (bibliothèque C)
• libm (bibliothèque mathématique)
• Interface JNI
• libz (compression Zlib)
• liblog (journalisation Android)
• Prise en charge minimale du C++
• OpenGL ES 1.1
Ces bibliothèques DOIVENT être compatibles avec les sources (c'est-à-dire compatibles avec les en-têtes) et compatibles avec les binaires (pour un
architecture du processeur) avec les versions fournies dans Bionic par le projet Android Open Source. Depuis
les implémentations Bionic ne sont pas entièrement compatibles avec d'autres implémentations telles que GNU C
bibliothèque, les implémenteurs de périphériques DEVRAIENT utiliser l'implémentation Android. Si les responsables de la mise en œuvre du dispositif utilisent un
implémentation différente de ces bibliothèques, elles doivent assurer la compatibilité des en-têtes et des binaires.
La compatibilité du code natif est un défi. Pour cette raison, nous souhaitons répéter que les implémenteurs de dispositifs sont
TRÈS fortement encouragé à utiliser les implémentations en amont des bibliothèques répertoriées ci-dessus, pour aider
assurer la compatibilité.
3.4. Compatibilité des API Web
De nombreux développeurs et applications s'appuient sur le comportement de la classe android.webkit.WebView [ Ressources ,
11] pour leurs interfaces utilisateur, l'implémentation de WebView doit donc être compatible sur Android
mises en œuvre. L'implémentation Android Open Source utilise la version du moteur de rendu WebKit pour
implémenter le WebView.
Puisqu'il n'est pas possible de développer une suite de tests complète pour un navigateur Web, les implémenteurs d'appareils
DOIT utiliser la version amont spécifique de WebKit dans l'implémentation WebView. Spécifiquement:
• WebView DOIT utiliser la version 528.5+ WebKit de l'arborescence Android Open Source en amont pour
Android 1.6. Cette version inclut un ensemble spécifique de fonctionnalités et de correctifs de sécurité pour WebView.
• La chaîne de l'agent utilisateur signalée par WebView DOIT être dans ce format :
Mozilla/5.0 (Linux ; U ; Android 1.6 ; <langue>-<pays> ; <appareil
nom> ; Build/<build ID>) AppleWebKit/528.5+ (KHTML, comme Gecko)
Version/3.1.2 Safari mobile/525.20.1

◦ La chaîne "<device name>" DOIT être la même que la valeur de
android.os.Build.MODEL
◦ La chaîne « <build ID> » DOIT être la même que la valeur de android.os.Build.ID.
◦ Les chaînes "<langue>" et "<pays>" DEVRAIENT suivre les conventions habituelles pour
le code du pays et la langue, et DEVRAIT faire référence aux paramètres régionaux actuels de l'appareil au niveau du pays.
moment de la demande.
Les implémentations PEUVENT expédier une chaîne d'agent utilisateur personnalisée dans l'application de navigateur autonome. Qu'est-ce que c'est
de plus, le navigateur autonome PEUT être basé sur une technologie de navigateur alternative (telle que Firefox,
Opera, etc.) Cependant, même si une autre application de navigateur est livrée, le composant WebView
fourni aux applications tierces DOIT être basé sur WebKit, comme ci-dessus.
L'application de navigateur autonome DEVRAIT inclure la prise en charge de Gears [ Ressources, 12] et PEUT
inclure la prise en charge de tout ou partie de HTML5.
3.5. Compatibilité comportementale des API
Les comportements de chacun des types d'API (gérées, logicielles, natives et Web) doivent être cohérents avec les
implémentation préférée d'Android disponible à partir du projet Android Open Source.
Certains domaines spécifiques de compatibilité sont :
• Les appareils NE DOIVENT PAS modifier le comportement ou la signification d'une intention standard.
• Les appareils NE DOIVENT PAS modifier le cycle de vie ou la sémantique du cycle de vie d'un type particulier de système.
composant (tel que Service, Activité, ContentProvider, etc.)
• Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation particulière.
La liste ci-dessus n'est pas exhaustive et il incombe aux responsables de la mise en œuvre des appareils de garantir le comportement
compatibilité. Pour cette raison, les implémenteurs de périphériques DEVRAIENT utiliser le code source disponible via le
Projet Android Open Source lorsque cela est possible, plutôt que de réimplémenter des parties importantes du système.
La suite de tests de compatibilité (CTS) teste des parties importantes de la plate-forme pour vérifier leur compatibilité comportementale,
mais pas tout. Il est de la responsabilité de l'implémenteur d'assurer la compatibilité comportementale avec Android
Projet Open Source.
3.6. Espaces de noms d'API
Android suit les conventions d'espace de noms de package et de classe définies par la programmation Java
langue. Pour garantir la compatibilité avec les applications tierces, les implémenteurs de périphériques NE DOIVENT PAS faire
toute modification interdite (voir ci-dessous) de ces espaces de noms de packages :
•java.*
• javax.*
• soleil.*
• Android.*
• com.android.*
Les modifications interdites incluent :
• Les implémentations d'appareil NE DOIVENT PAS modifier les API exposées publiquement sur la plate-forme Android.
en modifiant les signatures de méthode ou de classe, ou en supprimant des classes ou des champs de classe.

• Les implémenteurs de périphériques PEUVENT modifier l'implémentation sous-jacente des API, mais cela
les modifications NE DOIVENT PAS avoir d'impact sur le comportement déclaré et la signature du langage Java de tout
API exposées publiquement.
• Les implémenteurs de périphériques NE DOIVENT PAS ajouter d'éléments exposés publiquement (tels que des classes ou
interfaces, ou champs ou méthodes vers des classes ou interfaces existantes) vers les API ci-dessus.
Un « élément exposé publiquement » est toute construction qui n'est pas décorée du marqueur « @hide » dans le
code source Android en amont. En d’autres termes, les implémenteurs de périphériques NE DOIVENT PAS exposer de nouvelles API ou
modifier les API existantes dans les espaces de noms indiqués ci-dessus. Les implémenteurs de périphériques PEUVENT créer des
modifications, mais ces modifications NE DOIVENT PAS être annoncées ou autrement exposées aux développeurs.
Les implémenteurs de périphériques PEUVENT ajouter des API personnalisées, mais ces API NE DOIVENT PAS se trouver dans un espace de noms appartenant à
par ou en faisant référence à une autre organisation. Par exemple, les implémenteurs de périphériques NE DOIVENT PAS ajouter d'API au
com.google.* ou espace de noms similaire ; seul Google peut le faire. De même, Google NE DOIT PAS ajouter d'API à
les espaces de noms d'autres sociétés.
Si un implémenteur de périphérique propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple en ajoutant
nouvelle fonctionnalité utile à une API existante, ou ajout d'une nouvelle API), le responsable de la mise en œuvre DEVRAIT visiter
source.android.com et commencez le processus de contribution aux modifications et au code, conformément au
informations sur ce site.
Notez que les restrictions ci-dessus correspondent aux conventions standard de dénomination des API dans Java.
langage de programmation; cette section vise simplement à renforcer ces conventions et à les rendre contraignantes
grâce à l'inclusion dans cette définition de compatibilité.
3.7. Compatibilité des machines virtuelles
Un appareil Android compatible doit prendre en charge la spécification complète du bytecode Dalvik Executable (DEX) et
Sémantique de la machine virtuelle Dalvik [Ressources, 13].
3.8. Compatibilité de l'interface utilisateur
La plate-forme Android comprend certaines API de développement qui permettent aux développeurs de se connecter à l'utilisateur du système.
interface. Les implémentations d'appareil DOIVENT intégrer ces API d'interface utilisateur standard dans des interfaces utilisateur personnalisées
ils se développent, comme expliqué ci-dessous.
3.8.1. Widgets
Android définit un type de composant, l'API et le cycle de vie correspondants qui permettent aux applications d'exposer
un "AppWidget" à l'utilisateur final [Ressources , 14] . La version de référence Android Open Source comprend un
Application de lancement qui comprend des éléments d'interface utilisateur permettant à l'utilisateur d'ajouter, d'afficher et de supprimer
AppWidgets depuis l'écran d'accueil.
Les responsables de la mise en œuvre du périphérique PEUVENT substituer une alternative au lanceur de référence (c'est-à-dire l'écran d'accueil).
Les lanceurs alternatifs DEVRAIENT inclure la prise en charge intégrée des AppWidgets et exposer l'interface utilisateur
éléments pour ajouter, afficher et supprimer des AppWidgets directement dans le lanceur. Lanceurs alternatifs MAI
omettre ces éléments de l'interface utilisateur ; cependant, s'ils sont omis, l'implémenteur du périphérique DOIT fournir un
application distincte accessible depuis le lanceur qui permet aux utilisateurs d'ajouter, d'afficher et de supprimer
AppWidgets.

3.8.2. Notifications
Android inclut des API qui permettent aux développeurs d'informer les utilisateurs des événements notables [Ressources, 15]. Appareil
les implémenteurs DOIVENT fournir une prise en charge pour chaque classe de notification ainsi définie ; plus précisément : les sons,
vibration, lumière et barre d'état.
De plus, l'implémentation DOIT restituer correctement et toutes les ressources (icônes, fichiers son, etc.)
prévu dans les API [Ressources, 7], ou dans le guide de style des icônes de la barre d'état [Ressources , 16]. Appareil
les implémenteurs PEUVENT fournir une expérience utilisateur alternative pour les notifications à celle fournie par le
référence à l'implémentation Android Open Source ; cependant, ces systèmes de notification alternatifs DOIVENT
prendre en charge les ressources de notification existantes, comme ci-dessus.
3.8.3. Recherche
Android inclut des API [Ressources, 17] qui permettent aux développeurs d'intégrer la recherche dans leurs applications,
et exposer les données de leur application dans la recherche globale du système. D'une manière générale, cette fonctionnalité
se compose d'une interface utilisateur unique à l'échelle du système qui permet aux utilisateurs de saisir des requêtes et d'afficher des suggestions
au fur et à mesure que les utilisateurs tapent et affiche les résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour fournir
effectuer des recherches dans leurs propres applications et permettre aux développeurs de fournir des résultats à l'utilisateur commun de recherche globale
interface.
Les mises en œuvre de dispositifs DOIVENT inclure une interface utilisateur de recherche unique, partagée et à l'échelle du système, capable de
suggestions en temps réel en réponse aux entrées de l'utilisateur. Les implémentations de périphériques DOIVENT implémenter les API qui
permettre aux développeurs de réutiliser cette interface utilisateur pour effectuer des recherches au sein de leurs propres applications.
Les implémentations d'appareil DOIVENT implémenter les API qui permettent aux applications tierces d'ajouter des suggestions
à la zone de recherche lorsqu'il est exécuté en mode de recherche globale. Si aucune application tierce n'est installée,
utiliser cette fonctionnalité, le comportement par défaut DEVRAIT être d'afficher les résultats du moteur de recherche Web et
suggestions.
Les implémentations de périphériques PEUVENT proposer des interfaces utilisateur de recherche alternatives, mais DEVRAIENT inclure une interface matérielle ou logicielle.
bouton de recherche dédié, qui peut être utilisé à tout moment dans n'importe quelle application pour appeler le cadre de recherche,
avec le comportement prévu dans la documentation de l'API.
3.8.4. Toasts
Les applications peuvent utiliser l'API "Toast" (définie dans [ Ressources, 18]) pour afficher de courtes chaînes non modales au
utilisateur final, qui disparaissent après une brève période de temps. Les implémentations de périphériques DOIVENT afficher les Toasts de
applications aux utilisateurs finaux de manière à haute visibilité.
4. Compatibilité du logiciel de référence
Les implémenteurs de périphériques DOIVENT tester la compatibilité de l'implémentation à l'aide du logiciel open source suivant
applications:
• Calculatrice (incluse dans le SDK)
• Lunar Lander (inclus dans le SDK)
• ApiDemos (inclus dans le SDK)
• Les applications « Applications pour Android » [ Ressources, 19]
Chaque application ci-dessus DOIT se lancer et se comporter correctement lors de l'implémentation, pour que l'implémentation soit

considéré comme compatible.
5. Compatibilité des emballages d'application
Les implémentations d'appareil DOIVENT installer et exécuter les fichiers Android ".apk" générés par l'outil "aapt"
inclus dans le SDK Android officiel [ Ressources , 20].
Les implémentations d'appareils NE DOIVENT PAS étendre le bytecode .apk, Android Manifest ou Dalvik.
formats de manière à empêcher ces fichiers de s'installer et de s'exécuter correctement sur d'autres
appareils compatibles. Les implémenteurs de périphériques DEVRAIENT utiliser l'implémentation de référence en amont de Dalvik,
et le système de gestion des packages de l'implémentation de référence.
6. Compatibilité multimédia
Un appareil Android compatible doit prendre en charge les codecs multimédia suivants. Tous ces codecs sont
fourni en tant qu'implémentations logicielles dans l'implémentation Android préférée d'Android Open
Projet source [ Ressources , 4].
Veuillez noter que ni Google ni l'Alliance ouverte du combiné ne font aucune représentation que ces
Les codecs ne sont pas artisés par des brevets tiers. Ceux qui ont l'intention d'utiliser ce code source dans le matériel ou
Les produits logiciels sont informés que les implémentations de ce code, y compris dans les logiciels open source ou
Shareware, peut nécessiter des licences de brevet des détenteurs de brevets concernés.
l'audio
Nom
Détails du décodeur de l'encodeur
Fichiers pris en charge
Contenu mono / stéréo dans n'importe quel
3GPP (.3gp) et
combinaison de taux binaires standard
MPEG-4 (.mp4, .m4a)
AAC LC / LTP
X
Jusqu'à 160 kbps et dossiers d'échantillonnage. Aucun support pour RAW
entre 8 et 48 kHz
AAC (.AAC)
Contenu mono / stéréo dans n'importe quel
3GPP (.3gp) et
He-aacv1
combinaison de taux binaires standard
MPEG-4 (.mp4, .m4a)
X
(AAC +)
Jusqu'à 96 kbps et dossiers d'échantillonnage. Aucun support pour RAW
entre 8 et 48 kHz
AAC (.AAC)
Contenu mono / stéréo dans n'importe quel
He-aacv2
3GPP (.3gp) et
combinaison de taux binaires standard
(amélioré
MPEG-4 (.mp4, .m4a)
X
jusqu'à 96 kbps et taux d'échantillonnage
Aac +)
des dossiers. Aucun support pour RAW
entre 8 et 48 kHz
AAC (.AAC)
AMR-NB
4,75 à 12,2 kbps échantillonnés @
Fichiers 3GPP (.3GP)
X
X
8 kHz
AMR-WB
9 taux de 6,60 kbit / s à 23,85
-3GPP (.3GP) Fichiers
X
kbit / s échantillonné à 16 kHz
MP3
Fichiers mono / stéréo 8-320kbps mp3 constant (.mp3)
X
(CBR) ou le taux binaire variable (VBR)
Type 0 et 1 (.mid, .xmf,
MIDI TYPE 0 et 1. DLS Version 1
Midi
X
.mxmf). Aussi rtttl / rtx
et 2. XMF et Mobile XMF.
(.rtttl, .rtx), ota (.ota),

Prise en charge des formats de sonnerie
et imelody (.imy)
Rtttl / rtx, ota et imelody
Ogg vorbis
.ogg
X
PCM linéaire 8 et 16 bits (taux en hausse
PCM
X
VAGUE
Pour limiter le matériel)
Image
Des dossiers
Nom
Détails du décodeur de l'encodeur
Prise en charge
JPEG
X
X
base + progressive
GIF
X
PNG
X
X
PGB
X
Vidéo
Des dossiers
Nom
Détails du décodeur de l'encodeur
Prise en charge
3GPP (.3gp)
H.263
X
X
des dossiers
3GPP (.3gp)
H.264
X
et mpeg-4
(.mp4) fichiers
Mpeg4
X
Fichier 3GPP (.3GP)
PS
7. Compatibilité des outils du développeur
Les implémentations de périphériques doivent prendre en charge les outils de développeur Android fourni dans le SDK Android.
Plus précisément, les appareils compatibles Android doivent être compatibles avec:
• Android Debug Bridge ou ADB [Ressources , 21]
Les implémentations de périphériques doivent prendre en charge toutes les fonctions ADB comme documentée dans l'Android
SDK. Le démon ADB côté périphérique doit être inactif par défaut, mais il doit y avoir un utilisateur
Mécanisme accessible pour activer le pont Android Debug.
• Dalvik Debug Monitor Service ou DDMS [Ressources , 22]
Les implémentations de périphériques doivent prendre en charge toutes les fonctionnalités DDMS comme documentée dans le SDK Android.
Comme le DDMS utilise la BAD, la prise en charge des DDM doit être inactive par défaut, mais doit être prise en charge
Chaque fois que l'utilisateur a activé le pont de débogage Android, comme ci-dessus.

• Singe [Ressources, 23]
Les implémentations de l'appareil doivent inclure le cadre du singe et le rendre disponible pour
applications à utiliser.
8. Compatibilité matérielle
Android est destiné à prendre en charge les implémenteurs de périphériques créant des facteurs et des configurations de formulaires innovants.
Dans le même temps, les développeurs Android s'attendent à ce que certains matériels, capteurs et API dans tous
appareil. Cette section répertorie les fonctionnalités matérielles que tous les appareils compatibles Android 1.6 doivent prendre en charge. Dans
Android 1.6, la majorité des fonctionnalités matérielles (telles que le wifi, la boussole et l'accéléromètre) sont nécessaires.
Si un appareil comprend un composant matériel particulier qui a une API correspondante pour un tiers
Développeurs, l'implémentation de l'appareil doit implémenter cette API telle que définie dans le SDK Android
Documentation.
8.1. Afficher
Android 1.6 comprend des installations qui effectuent certaines opérations de mise à l'échelle et de transformation automatique
Certaines circonstances, pour garantir que les applications tierces s'exécutent assez bien sur le matériel
Configurations pour lesquelles elles n'étaient pas nécessairement explicitement conçues [Ressources, 24] . Les appareils doivent
Implémentez correctement ces comportements, comme détaillé dans cette section.
8.1.1. Configurations d'affichage standard
Ce tableau répertorie les configurations d'écran standard considérées comme compatibles avec Android:
Diagonale
Taille de l'écran
Densité d'écran
Type d'écran
Largeur (pixels)
Hauteur (pixels)
Plage de longueur
Groupe
Groupe
(pouces)
QVGA
240
320
2.6 - 3.0
Petit
Faible
Wqvga
240
400
3.2 - 3.5
Normale
Faible
Fwqvga
240
432
3,5 - 3.8
Normale
Faible
Hvga
320
480
3.0 - 3.5
Normale
Moyen
Wvga
480
800
3.3 - 4.0
Normale
Haut
Fwvga
480
854
3,5 - 4.0
Normale
Haut
Wvga
480
800
4.8 - 5.5
Grand
Moyen
Fwvga
480
854
5.0 - 5.8
Grand
Moyen
Les implémentations de périphériques correspondant à l'une des configurations standard ci-dessus doivent être configurées
Pour signaler la taille de l'écran indiquée aux applications via Android.Content.res.Configuration [ Ressources,
25] classe.
Certains packages .APK ont des manifestes qui ne les identifient pas comme soutenant une plage de densité spécifique.
Lors de l'exécution de ces applications, les contraintes suivantes s'appliquent:

• Les implémentations de l'appareil doivent interpréter toutes les ressources présentes comme défaut
"Medium" (connu sous le nom de "MDPI" dans la documentation SDK.)
• Lorsqu'il fonctionne sur un écran de densité "faible", les implémentations de l'appareil doivent réduire le moyen /
Actifs MDPI d'un facteur de 0,75.
• Lorsqu'il fonctionne sur un écran de densité "élevé", les implémentations de l'appareil doivent évoluer moyen /
Actifs MDPI d'un facteur de 1,5.
• Les implémentations des appareils ne doivent pas mettre à l'échelle des actifs dans une plage de densité et doivent évoluer
Actifs par exactement ces facteurs entre les gammes de densité.
8.1.2. Configurations d'affichage non standard
Afficher les configurations qui ne correspondent pas à l'une des configurations standard répertoriées dans la section 8.2.1 nécessitent
considération et travail supplémentaires pour être compatibles. Les implémenteurs de périphériques doivent contacter Android
Équipe de compatibilité comme prévu dans la section 12 pour obtenir des classifications pour le seau de taille d'écran, la densité,
et facteur de mise à l'échelle. Lorsqu'ils sont fournis avec ces informations, les implémentations de l'appareil doivent les implémenter
comme spécifié.
Notez que certains affichent des configurations (telles que des écrans très grands ou très petits, et certains ratios d'aspect)
sont fondamentalement incompatibles avec Android 1.6; Par conséquent
Contactez l'équipe de compatibilité Android le plus tôt possible dans le processus de développement.
8.1.3. Afficher les mesures
Les implémentations de périphériques doivent signaler les valeurs correctes pour toutes les mesures d'affichage définies dans
android.util.displayMetrics [Resources , 26].
8.2. Clavier
Implémentations d'appareils :
• Doit inclure la prise en charge du cadre de gestion des entrées (qui permet
Développeurs pour créer des moteurs de gestion des entrées - c'est-à-dire un clavier souple) comme détaillé à
développeur.android.com
• Doit fournir au moins une implémentation de clavier doux (que ce soit un dur
Le clavier est présent)
• Peut inclure des implémentations de clavier soft supplémentaires
• Peut inclure un clavier matériel
• ne doit pas inclure un clavier matériel qui ne correspond pas à l'un des formats spécifiés
Dans Android.Content.res.configuration [ Ressources, 25] (c'est-à-dire Qwerty, ou 12 touches)
8.3. Navigation sans contact
Implémentations d'appareils :
4
roue)
• Doit signaler via Android.Content.res.configuration [Ressources , 25] la valeur correcte pour le
matériel de l'appareil

8.4. Orientation de l'écran
Les appareils compatibles doivent prendre en charge l'orientation dynamique par des applications au portrait ou au paysage
orientation de l'écran. C'est-à-dire que l'appareil doit respecter la demande de l'application pour un écran spécifique
orientation. Les implémentations de l'appareil peuvent sélectionner l'orientation du portrait ou du paysage par défaut.
Les périphériques doivent signaler la valeur correcte de l'orientation actuelle de l'appareil, chaque fois que
android.content.res.configuration.orientation, android.view.display.getoritation (), ou d'autres API.
8.5. Saisie sur écran tactile
Implémentations d'appareils :
• Doit avoir un écran tactile
• Peut avoir un écran tactile capacatif ou résistif
• Doit signaler la valeur d'Android.Content.res.configuration [ Ressources, 25] reflétant
correspondant au type de l'écran tactile spécifique sur l'appareil
8.6. USB
Implémentations d'appareils :
• Doit implémenter un client USB, connecté à un hôte USB avec un port USB-A standard
• Doit implémenter le pont de débogage Android sur l'USB (comme décrit dans la section 7)
• Doit implémenter un client de stockage de masse USB pour le stockage amovible / multimédia est présent dans le
appareil
• Devrait utiliser le facteur de forme micro USB du côté de l'appareil
• doit mettre en œuvre la prise en charge de la spécification de stockage de masse USB (afin que soit amovible
ou un stockage fixe sur l'appareil est accessible à partir d'un PC hôte)
• Peut inclure un port non standard du côté de l'appareil, mais si c'est le cas, doit être expédié avec un câble capable de
Connexion du Pinout personnalisé au port USB-A standard
8.7. Clés de navigation
Les fonctions à domicile, à menu et à dos sont essentielles au paradigme de navigation Android. Appareil
Les implémentations doivent rendre ces fonctions à la disposition de l'utilisateur à tout moment, quelle que soit l'application
État. Ces fonctions doivent être implémentées via des boutons dédiés. Ils peuvent être mis en œuvre
en utilisant des logiciels, des gestes, un panneau tactile, etc., mais si c'est le cas, ils doivent toujours être accessibles et non obscurs ou
interférer avec la zone d'affichage de l'application disponible.
Les implémenteurs de périphériques doivent également fournir une clé de recherche dédiée. Les implémenteurs de périphériques peuvent également
Fournissez des clés d'envoi et de fin pour les appels téléphoniques.
8.8. Wifi
Les implémentations de périphériques doivent prendre en charge 802.11b et 802.11g et peuvent prendre en charge 802.11a.

8.9. Caméra
Les implémentations de l'appareil doivent inclure une caméra. La caméra incluse:
• Doit avoir une résolution d'au moins 2 mégapixels
• devrait avoir une mise au point automatique du matériel, soit un logiciel auto-focus implémenté dans la caméra
Conducteur (transparent au logiciel d'application)
• Peut avoir un matériel fixe ou EDOF (profondeur de champ étendue)
• Peut inclure un flash. Si l'appareil photo comprend un flash, la lampe flash ne doit pas être éclairée pendant un
android.hardware.camera.previewcallback L'instance a été enregistrée sur un aperçu de la caméra
surface.
Les implémentations de l'appareil doivent implémenter les comportements suivants pour les API liées à la caméra
[Ressources, 27] :
1. Si une application n'a jamais appelé Android.Hardware.Camera.Parameters.SetPreViewFormat (int),
alors l'appareil doit utiliser Android.hardware.pixelformat.ycbcr_420_sp pour les données d'aperçu
fourni aux rappels des applications.
2. Si une application enregistre une instance Android.Hardware.Camera.PreviewCallback et le
Système appelle la méthode onPreViewFrame () Lorsque le format d'aperçu est ycbcr_420_sp, le
Les données dans l'octet [] transmises dans onPreviewFrame () doivent en outre être dans le format de codage NV21.
(Il s'agit du format utilisé nativement par la famille de matériel 7k.) C'est-à-dire que NV21 doit être la valeur par défaut.
8.9.1. Caméras non autofocus
Si un appareil n'a pas de caméra automatique, l'implémentateur de l'appareil doit répondre aux exigences supplémentaires en
cette section. Les implémentations de l'appareil doivent implémenter l'API de la caméra complète incluse dans Android 1.6
Documentation du SDK d'une manière raisonnable, quelles que soient les capacités réelles du matériel de la caméra.
Pour Android 1.6, si la caméra manque de mise au point automatique, l'implémentation de l'appareil doit adhérer à ce qui suit:
1. Le système doit inclure une propriété système en lecture seule nommée "Ro.Workaround.noautofocus"
avec la valeur de "1". Cette valeur est destinée à être utilisée par des applications telles que le marché Android pour
identifier sélectivement les capacités de l'appareil et sera remplacé dans une future version d'Android par un
API robuste.
2. Si une application appelle Android.Hardware.Camera.Autofocus (), le système doit appeler le
Méthode de rappel onautofocus () sur n'importe quel enregistrement
android.hardware.camera.AutofoCuscallback, même si aucune se concentrer
arrivé. C'est pour éviter que les applications existantes se cassent en attendant toujours une mise au point automatique
rappel qui ne viendra jamais.
3. L'appel à la méthode AutoFocuscallback.onautofocus () doit être déclenché par le conducteur ou
Framework dans un nouvel événement sur le thread Looper Framework principal. C'est-à-dire, caméra.autofocus ()
Ne doit pas appeler directement AutofOcuscallback.onautofocus () car cela viole l'androïde
Modèle de filetage de framework et cassera les applications.
8.10. Accéléromètre
Les implémentations de l'appareil doivent inclure un accéléromètre à 3 axes et doivent être en mesure de livrer des événements à AT
au moins 50 Hz. Le système de coordonnées utilisé par l'accéléromètre doit se conformer au capteur Android
coordonner le système détaillé dans les API Android [Ressources , 28].

8.11. Boussole
Les implémentations de l'appareil doivent inclure une boussole à 3 axes et doivent être en mesure de livrer des événements au moins
10 Hz. Le système de coordonnées utilisé par la boussole doit se conformer aux coordonnées du capteur Android
Système tel que défini dans l'API Android [Ressources , 28].
8.12. GPS
Les implémentations de l'appareil doivent inclure un GPS et doivent inclure une forme de "GPS assisté"
Technique pour minimiser le temps de verrouillage GPS.
8.13. Téléphonie
Implémentations d'appareils :
• Doit inclure la téléphonie GSM ou CDMA
• Doit implémenter les API appropriées comme détaillé dans la documentation Android SDK à
développeur.android.com
Notez que cette exigence implique que les périphériques non téléphoniques ne sont pas compatibles avec Android 1.6; Android
1.6 Les appareils doivent inclure le matériel de téléphonie. Veuillez consulter l'annexe C pour plus d'informations sur le non-téléphone
dispositifs.
8.14. Commandes de volume
Les appareils compatibles Android doivent inclure un mécanisme pour permettre à l'utilisateur d'augmenter et de diminuer
Volume audio. Les implémentations de l'appareil doivent rendre ces fonctions à la disposition de l'utilisateur à tout moment,
Quel que soit l'état d'application. Ces fonctions peuvent être implémentées à l'aide de clés matérielles physiques,
Logiciels, gestes, panneau tactile, etc., mais ils doivent toujours être accessibles et non obscurs ou interférés
avec la zone d'affichage de l'application disponible (voir l'affichage ci-dessus).
Lorsque ces boutons sont utilisés, les événements clés correspondants doivent être générés et envoyés au
application de premier plan. Si l'événement n'est pas intercepté et coulé par l'application, alors appareil
L'implémentation doit gérer l'événement en tant que contrôle du volume du système.
9. Compatibilité des performances
L'un des objectifs du programme de compatibilité Android est d'assurer une expérience d'application cohérente pour
consommateurs. Les implémentations compatibles doivent non seulement s'assurer que les applications s'exécutent simplement correctement
l'appareil, mais qu'ils le font avec des performances raisonnables et une bonne expérience utilisateur globale.
Les implémentations de périphériques doivent répondre aux mesures de performances clés d'un appareil compatible Android 1.6,
Comme dans le tableau ci-dessous:
Métrique
Seuil de performance
commentaires

Ceci est testé par CTS.
Les applications suivantes
Le temps de lancement est mesuré comme le temps total pour
devrait être lancé dans le
Terminer le chargement de l'activité par défaut pour le
Application
temps spécifié.
application, y compris le temps nécessaire pour démarrer le
Temps de lancement
Navigateur: moins de 1300 ms
Processus Linux, chargez le package Android dans le
MMS / SMS: moins de 700 ms
Dalvik VM, et appelez OnCreate.
AlarmClock: moins de 650 ms
Plusieurs applications seront
Ceci est testé par CTS.
lancé. Relancer le
La première application simultanée devrait
Applications
Compléter en prenant moins que le
Temps de lancement d'origine.
10. Compatibilité du modèle de sécurité
Les implémentations de périphériques doivent implémenter un modèle de sécurité cohérent avec la sécurité de la plate-forme Android
modèle tel que défini dans la sécurité et le document de référence des autorisations dans les API [Resources, 29] dans le
Documentation du développeur Android. Les implémentations de l'appareil doivent prendre en charge l'installation de l'auto-signé
Demandes sans exiger aucune autorisation / certificats supplémentaires de tout tiers / autorités.
Plus précisément, les appareils compatibles doivent prendre en charge les mécanismes de sécurité suivants:
10.1. Autorisations
Les implémentations de l'appareil doivent prendre en charge le modèle d'autorisations Android tel que défini dans l'android
Documentation des développeurs [ Ressources , 9]. Plus précisément, les implémentations doivent appliquer chaque autorisation
défini comme décrit dans la documentation SDK; Aucune autorisation ne peut être omise, modifiée ou ignorée.
Les implémentations peuvent ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'identification d'autorisation ne soient pas dans le
Android. * Espace de noms.
10.2. Isolement des utilisateurs et des processus
Les implémentations de l'appareil doivent prendre en charge le modèle de sandbox de l'application Android, dans lequel chaque application
fonctionne comme un UID de style Unix unique et dans un processus distinct.
Les implémentations de l'appareil doivent prendre en charge l'exécution de plusieurs applications comme le même ID utilisateur Linux, fourni
que les applications sont correctement signées et construites, telles que définies dans la sécurité et les autorisations
Référence [ Ressources , 29].

10.3. Autorisations de système de fichiers
Les implémentations de l'appareil doivent prendre en charge le modèle d'autorisations d'accès aux fichiers Android tel que défini comme
défini dans la référence de sécurité et d'autorisations [Ressources , 29].
11. Suite de test de compatibilité
Les implémentations de l'appareil doivent passer la suite de test de compatibilité Android (CTS) [ Ressources, 3] disponibles
à partir du projet Open Source Android, en utilisant le logiciel d'expédition final sur l'appareil. En plus,
Les implémenteurs de périphériques doivent utiliser l'implémentation de référence dans l'arborescence open source Android comme
autant que possible, et doit assurer une compatibilité en cas d'ambiguïté dans les CT et pour tout
Remplémentations des parties du code source de référence.
Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bogues.
Le CTS sera versé indépendamment de cette définition de compatibilité et des révisions multiples de la
CTS peut être publié pour Android 1.6. Cependant, ces versions ne fixeront que des bogues comportementaux dans le CTS
tests et n'imposeront aucun nouveau test, comportement ou API pour une version de plate-forme donnée.
12. Contactez-nous
Vous pouvez contacter l'équipe de compatibilité Android à compatibilité@android.com pour des clarifications liées à
Cette définition de compatibiltiy et pour fournir des commentaires sur cette définition.

Annexe A: Intention de l'application requise
Remarque: Cette liste est provisoire et sera mise à jour à l'avenir.
Actions d'application
Schémas types mime
(aucun)
texte simple
http
texte/html
Navigateur
android.intent.action.view
https
application / xhtml + xml
application/
vnd.wap.xhtml + xml
(aucun)
android.intent.action.web_search
http
(aucun)
https
android.media.action.IMAGE_CAPTURE
android.media.action.still_image_camera
Caméra
android.media.action.video_camera
android.media.action.video_capture
vnd.android.cursor.dir /
android.intent.action.view
image
android.intent.action.get_content
vnd.android.cursor.dir /
android.intent.action.pick
vidéo
android.intent.action.attach_data
image/*
vidéo/*
android.intent.action.view
rsp
vidéo/mp4
vidéo / 3gp
android.intent.action.view
http
vidéo / 3gpp
vidéo / 3gpp2
android.intent.action.dial
Téléphone /
android.intent.action.view
tél.
Contacts
android.intent.action.Call
android.intent.action.dial
vnd.android.cursor.dir /
android.intent.action.view
personne

vnd.android.cursor.dir /
personne
vnd.android.cursor.dir /
android.intent.action.pick
téléphone
vnd.android.cursor.dir /
adresse postale
vnd.android.cursor.item /
personne
vnd.android.cursor.item /
android.intent.action.get_content
téléphone
vnd.android.cursor.item /
adresse postale
texte simple
E-mail
android.intent.action.send
image/*
vidéo/*
android.intent.action.view
mail à
android.intent.action.sendto
SMS
android.intent.action.view
smsto
Sms / mms android.intent.action.sendto
mms
mmsto
l'audio/*
application / ogg
Musique
android.intent.action.view
déposer
Application / X-OGG
Application / iTunes
audio / mp3
Audio / X-MP3
android.intent.action.view
http
audio / mpeg
Audio / MP4
Audio / MP4A-LATM
vnd.android.cursor.dir /
artiste
vnd.android.cursor.dir /
album
vnd.android.cursor.dir /
android.intent.action.pick
Lecture en cours
vnd.android.cursor.dir /
piste
nd.android.cursor.dir /
playlist
vnd.android.cursor.dir /
vidéo
médias/*
l'audio/*
android.intent.action.get_content
application / ogg
Application / X-OGG
vidéo/*

contenu
Emballer
android.intent.action.view
déposer
Installateur
emballer
déposer
android.intent.action.package_install
http
https
android.intent.action.all_apps
android.settings.settings
android.settings.wireless_settings
android.settings.airplane_mode_settings
android.settings.wifi_settings
android.settings.apn_settings
android.settings.bluetooth_settings
android.settings.date_settings
android.settings.locale_settings
Paramètres
android.settings.input_method_settings
com.android.settings.sound_settings
com.android.settings.display_settings
android.settings.security_setting
android.settings.location_source_settings
android.settings.internal_storage_settings
android.settings.memory_card_settings
android.intent.action.set_wallpaper
Recherche
android.intent.action.search
requête
android.intent.action.search_long_press
Voix
android.intent.action.voice_command
Gestion des contacts
Action d'intention
Description
Démarre une activité qui permet à l'utilisateur de choisir
Attach_image
un contact pour attacher une image à.
Utilisé
Extra_create_description
avec show_or_create_contact à
spécifiez une description exacte pour être

montré lors de l'incitation de l'utilisateur
Création d'un nouveau contact.
Utilisé
avec show_or_create_contact à
Extra_force_create
force à créer un nouveau contact si non
Contact de correspondance trouvé.
C'est l'intention qui est tirée lorsqu'un
Search_Suggestion_clicked
La suggestion de recherche est cliquée.
C'est l'intention qui est tirée lorsqu'un
Search_Suggestion_create_contet_clicked Recherche Suggestion pour créer un
Le contact est cliqué.
C'est l'intention qui est tirée lorsqu'un
Search_Suggestion_dial_number_clicked
Recherche de suggestion pour composer un numéro
est cliqué sur.
Prend en entrée un uri de données avec un mailto:
Show_or_create_contact
ou tel: schéma.

Annexe B: INSTRUCTIONS DE BRODICATION OBLIQUE REMARQUE: Cette liste est provisoire et sera
mis à jour à l'avenir.
Action d'intention
Description
Action de diffusion: ceci est diffusé une fois, après le
Action_boot_completed
Le système a terminé le démarrage.
Action de diffusion: ceci est diffusé une fois, quand un
Action_call_button
L'appel est reçu.
Action de diffusion: le "bouton de la caméra" était
Action_camera_button
pressé.
Action de diffusion: le courant
Action_configuration_changed
La configuration du périphérique (orientation, paramètres régionaux, etc.) a
modifié.
Action_date_changed
Action de diffusion: la date a changé.
Action de diffusion: indique une condition de mémoire faible
Action_device_storage_low
sur l'appareil
Action de diffusion: indique une condition de mémoire faible
Action_device_storage_ok
sur l'appareil n'existe plus
Action de diffusion: le casque câblé branché ou
Action_headset_plug
débranché.
Action de diffusion: une méthode d'entrée a été
Action_input_method_changed
modifié.
Action de diffusion: les médias externes ont été supprimés
Action_media_bad_removal
de l'emplacement de carte SD, mais Mount Point n'était pas
non monté.
Action de diffusion: le "bouton média" était
Action_media_button
pressé.
Action de diffusion: des médias externes sont présents, et
Être disque a vérifié le chemin vers le point de montage pour
Action_media_checking
Le support de vérification est contenu dans le
Intention.mdata Champ.
Action de diffusion: l'utilisateur a exprimé le désir de
Action_media_eject
Supprimer les supports de stockage externes.
Action de diffusion: les médias externes sont présents et
Action_media_mounted
monté à son point de montage.
Action de diffusion: les médias externes sont présents, mais c'est
en utilisant un FS incompatible (ou est vide) le chemin vers
Action_media_nofs
Le point de montage pour les supports de vérification est
contenu dans le champ Intent.mdata.
Action de diffusion: les médias externes ont été
ACTION_MEDIA_REMOVED
supprimé.
Action de diffusion: le scanner multimédia a terminé
Action_media_scanner_finished
scanner un répertoire.
Action de diffusion: demandez au scanner multimédia à
Action_media_scanner_scan_file
Analysez un fichier et ajoutez-le à la base de données des médias.

Action de diffusion: le scanner multimédia a commencé
Action_media_scanner_started
scanner un répertoire.
Action de diffusion: les médias externes sont non montés
Action_media_shared
Parce qu'il est partagé via un stockage de masse USB.
Action de diffusion: les médias externes sont présents mais
Action_media_unmountable
ne peut pas être monté.
Action de diffusion: les médias externes sont présents, mais
Action_media_unmounted
non monté à son point de montage.
Action de diffusion: un appel sortant est sur le point d'être
Action_new_outgout_call
mis.
Action de diffusion: un nouveau package d'applications a
Action_package_added
été installé sur l'appareil.
Action de diffusion: un package d'application existant
Action_package_changed
a été modifié (par exemple, un composant a été
activé ou désactivé.
Action de diffusion: l'utilisateur a effacé les données de
un paquet. Cela devrait être précédé
par action_package_restarted, après quoi
Action_package_data_cleared
Toutes ses données persistantes sont effacées et ce
diffusion envoyée. Notez que le package effacé
ne reçoit pas cette diffusion. Les données contient
le nom du package.
Action de diffusion: un package d'application existant
a été supprimé de l'appareil. Les données
ACTION_PACKAGE_REMOVED
Contient le nom du package. Le paquet
qui est installé ne reçoit pas cette intention.
Action de diffusion: une nouvelle version d'une application
Action_package_replaced
un package a été installé, remplaçant un
version qui a été précédemment installée.
Action de diffusion: l'utilisateur a redémarré un
Package, et tous ses processus ont été tués.
Tout l'état d'exécution qui lui est associé (processus,
Action_package_restarted
Les alarmes, les notifications, etc.) doivent être supprimées. Note
que le package redémarré ne reçoit pas cela
diffuser. Les données contient le nom du
emballer.
Action de diffusion: certains fournisseurs de contenu ont
parties de leur espace de noms où ils publient de nouveaux
Action_provider_changed
événements ou éléments que l'utilisateur peut être particulièrement
intéressé par.
Action_screen_off
Action de diffusion: envoyée après l'écran.
Action_screen_on
Action de diffusion: envoyé après que l'écran s'allume.
Action de diffusion: un ID utilisateur a été supprimé
ACTION_UID_REMOVED
du système.
Action de diffusion: l'appareil est entré en USB
ACTION_UMS_CONNECT
Mode de stockage de masse.

Action de diffusion: l'appareil a quitté USB
Action_ums_disconnected
Mode de stockage de masse.
Action de diffusion: envoyé lorsque l'utilisateur est présent
Action_user_present
Une fois l'appareil se réveille (par exemple lorsque le keyguard est
disparu).
Action de diffusion: le papier peint du système actuel
Action_wallpaper_changed
a changé.
Action_time_changed
Action de diffusion: le moment a été défini.
Action_time_tick
Action de diffusion: l'heure actuelle a changé.
Action_timezone_changed
Action de diffusion: le fuseau horaire a changé.
Action de diffusion: l'état de charge ou charge
Action_battery_changed
Le niveau de la batterie a changé.
Action de diffusion: indique une faible condition de batterie
Action_battery_low
sur l'appareil. Cette émission correspond au
Boîte de dialogue du système "Avertissement à faible batterie".
Action de diffusion: indique que la batterie est maintenant correcte
après avoir été bas. Ce sera envoyé
Action_battery_okay
après action_battery_low une fois la batterie
est remonté dans un état correct.
État du réseau
Action d'intention
Description
Action d'intention de diffusion indiquant que le
Réseau_state_changed_action
L'état de connectivité Wi-Fi a changé.
Action d'intention de diffusion indiquant que le
RSSI_CHANGED_ACTION
RSSI (force du signal) a changé.
Diffuser l'action de l'intention indiquant qu'un
Suppliant_state_changed_action
La connexion au suppliant a été
établi ou perdu.
Diffuser l'action de l'intention indiquant que le Wi-Fi
Wifi_state_changed_action
a été activé, désactivé, activer,
invalidie, ou inconnu.
Les ID réseau des réseaux configurés
Network_IDS_CHANGED_ACTION
aurait pu changer.
Action d'intention de diffusion indiquant que le
Action_background_data_setting_changed Le paramètre pour l'utilisation des données d'arrière-plan a
Valeurs modifiées.
L'intention de diffusion indiquant qu'un changement
Connectivity_Action
La connectivité réseau s'est produite.
Action de diffusion: l'utilisateur a changé le
Action_airplane_mode_changed
téléphone en mode avion ou hors de l'avion.

Annexe C: Considérations futures Cette annexe clarifie certaines parties de cet Android
1.6 Définition de compatibilité et dans certains cas discute des modifications prévues ou prévues destinées à un
Version future de la plate-forme Android. Cette annexe est à des fins d'information et de planification uniquement, et
ne fait pas partie de la définition de compatibilité pour Android 1.6.
1. Dispositifs non télphones
Android 1.6 est destiné exclusivement aux téléphones; La fonctionnalité de téléphonie n'est pas facultative. Versions futures
de la plate-forme Android devrait rendre la téléphonie en option (et donc permettre à Android non téléphonique
appareils), mais seuls les téléphones sont compatibles avec Android 1.6.
2. Compatibilité Bluetooth
La version Android 1.6 d'Android ne prend pas en charge les API Bluetooth, donc du point de vue de la compatibilité
Bluetooth n'impose aucune considération pour cette version de la plate-forme. Cependant, une future version
d'Android présentera les API Bluetooth. À ce stade, le support Bluetooth deviendra obligatoire pour
compatibilité.
Par conséquent, nous recommandons fortement que les appareils Android 1.6 incluent Bluetooth, afin qu'ils soient
Compatible avec les futures versions d'Android qui nécessitent Bluetooth.
3. Composants matériels requis
Tous les composants matériels de la section 8 (y compris le WiFi, le magnétomètre / la boussole, l'accéléromètre, etc.) sont
requis et ne peut être omis. Les versions futures d'Android devraient faire de certains (mais pas tous)
ces composants facultatifs, en tandem avec des outils correspondants pour les développeurs tiers pour gérer ces
changements.
4. Exemples d'applications
Le document de définition de compatibilité pour une future version d'Android comprendra un plus étendu et
Liste représentative des applications que celles énumérées dans la section 4 ci-dessus. Pour Android 1.6, le
Les applications répertoriées dans la section 4 doivent être testées.
5. Écrans tactiles
Les versions futures de la définition de compatibilité peuvent ou non permettre aux appareils d'omettre des écrans tactiles.
Cependant, une grande partie de l'implémentation du cadre Android suppose l'existence d'un
écran tactile; L'omission d'un écran tactile briserait considérablement toutes les applications Android tierces actuelles,
Ainsi, dans Android 1.6, un écran tactile est nécessaire pour la compatibilité.

6. Performance
Les versions futures de CTS mesureront également l'utilisation et les performances du processeur des éléments suivants
Composants d'une implémentation:
• Graphiques 2D
• Graphiques 3D
• Lecture vidéo
• Playage audio
• lecture Bluetooth A2DP

Définition de la compatibilité Android 1.6

Aperçu du document