À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

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

Définition de la compatibilité avec Android 1.6

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

1. Introduction
Ce document énonce les exigences à respecter pour que les téléphones mobiles soient
compatibles avec Android 1.6. Cette définition suppose que vous connaissez le programme de compatibilité Android
[Ressources, 1].
L'utilisation des mots "doit", "ne doit pas", "requis", "doit", "ne doit pas", "doit", "ne doit pas", "recommandé",
"peut" et "facultatif" est conforme à la norme IETF définie dans la RFC 2119 [Ressources, 2].
Dans ce document, un "implémentateur d'appareils" ou "implémentateur" désigne une personne ou une organisation qui développe une solution matérielle/logicielle exécutée sur Android 1.6.
Une "implémentation d'appareil" ou "implémentation" est la
solution matérielle/logicielle ainsi développée.
Pour être considérées comme compatibles avec Android 1.6, les implémentations d'appareils:
1. DOIVENT respecter les exigences présentées dans cette définition de la compatibilité, y compris les documents
intégrés par référence.
2. DOIVENT réussir les tests de la suite de compatibilité Android (CTS) disponibles dans le cadre du projet Android Open
Source Project [Ressources, 3].Le CTS teste la plupart des composants décrits dans ce
document, mais pas tous.
Lorsque cette définition ou la CTS est silencieuse, ambiguë ou incomplète, il incombe à l'implémentateur de l'appareil de garantir la compatibilité avec les implémentations existantes.
C'est pourquoi le Projet Android Open
Source [Ressources, 4] est à la fois l'implémentation de référence et privilégiée d'Android. Les implémentateurs d'
d'appareil sont vivement encouragés à baser leurs implémentations sur le code source "en amont"
disponible dans le projet Android Open Source. Bien que certains composants puissent être remplacés
par d'autres implémentations, cette pratique est fortement déconseillée, car réussir les tests CTS devient
beaucoup plus difficile. Il incombe à l'implémentateur de garantir une compatibilité comportementale totale avec l'implémentation Android standard, y compris 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 disponibles ici.
1. Présentation du programme de compatibilité Android: https://sites.google.com/a/android.com/compatibility/
how-it-works
2. Niveaux d'exigences de la norme IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. Compatibility Test Suite: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. Projet Android Open Source: 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-
summary.html
7. Ressources disponibles: http://code.google.com/android/reference/available-resources.html
8. Fichiers manifeste Android: http://code.google.com/android/devel/bblocks-manifest.html
9. Documentation sur les autorisations Android: http://developer.android.com/reference/android/
Manifest.permission.html
10. Constantes de compilation: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Extensions de navigateur Gears: http://code.google.com/apis/gears/

13. Spécification de la machine virtuelle Dalvik, disponible dans le répertoire dalvik/docs d'un code source
checkout. Disponible également sur la page 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. Apps For Android: http://code.google.com/p/apps-for-android
20. Description du fichier APK Android: 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. Monkey: 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. Display Metrics: 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. Documentation de référence sur la sécurité et les autorisations Android: http://developer.android.com/guide/topics/security/
security.html
De nombreuses ressources sont dérivées directement ou indirectement du SDK Android 1.6 et sont fonctionnellement identiques aux informations de la documentation de ce SDK.
Dans tous les cas où cette
définition de la compatibilité ne correspond pas à la documentation du SDK, la documentation du SDK est considérée comme
autoritative. Toutes les informations techniques fournies dans les références ci-dessus sont considérées comme faisant partie de cette définition de compatibilité.

3. Logiciel
La plate-forme Android comprend à la fois un ensemble d'API gérées ("dures") et un ensemble d'API dites "douces"
, telles que le système Intent, les API en code natif et les API d'application Web. Cette section détaille les API strictes et flexibles qui sont essentielles à la compatibilité, ainsi que certains autres comportements techniques et d'interface utilisateur pertinents.

Les implémentations d'appareils DOIVENT respecter 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 moyen de transport des applications Android. L'
API Android est l'ensemble des interfaces de la plate-forme Android exposées aux
applications exécutées dans l'environnement de VM géré. Les implémentations d'appareils DOIVENT fournir des implémentations complètes, y compris tous les comportements documentés, de toute API documentée exposée par le SDK Android 1.6, par exemple:
1.

API Java principales d'Android [Resources, 5].
2. Fournisseurs de contenu [Resources, 6].
3. Ressources [Resources, 7].
4. Attributs et éléments AndroidManifest.xml [Resources, 8].

Les implémentations d'appareils NE DOIVENT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ni inclure de no-ops, sauf dans les cas spécifiquement autorisés par cette définition de compatibilité.

3.2. Compatibilité des API souples
En plus des API gérées de la section 3.1, Android inclut également une API "souple"
importante, uniquement au moment de l'exécution, sous la forme d'éléments tels que les intents, les autorisations et d'autres aspects similaires des applications Android
qui ne peuvent pas être appliqués au moment de la compilation de l'application. Cette section détaille les API et les comportements système "soft" requis pour la compatibilité avec Android 1.6.
Les implémentations d'appareils DOIVENT respecter toutes les
exigences présentées dans cette section.
3.2.1. Autorisations
Les implémentateurs d'appareils DOIVENT prendre en charge et appliquer toutes les constantes d'autorisation, comme indiqué sur la
page de référence sur les autorisations [Ressources, 9]. Notez que la section 10 liste des exigences supplémentaires liées au
modèle de sécurité Android.
3.2.2. Paramètres de compilation
Les API Android incluent un certain nombre de constantes dans la classe android.os.Build [Resources, 10] qui sont destinées à décrire l'appareil actuel.
Pour fournir des valeurs cohérentes et significatives dans les implémentations d'appareils
, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs auxquelles les implémentations d'appareils
DOIVENT se conformer.
Paramètre
Commentaires
Version du système Android actuellement en cours d'exécution, au format lisible par l'homme.
android.os.Build.VERSION.RELEASE
Pour Android 1.6, ce champ DOIT avoir la valeur de chaîne
"1.6".
Version du système Android actuellement 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.
Valeur choisie par l'implémentateur de l'appareil pour désigner la version spécifique
du système Android en cours d'exécution, au format lisible par l'homme.
Cette valeur NE DOIT PAS être réutilisée pour différentes versions envoyées aux utilisateurs finaux
android.os.Build.VERSION.INCREMENTAL. Ce champ est généralement utilisé pour indiquer le numéro de build ou l'identifiant de modification de contrôle source utilisé pour générer le build.
Aucune exigence n'est imposée au format spécifique de ce champ, sauf qu'il ne doit pas être nul ni contenir la chaîne vide ("").
Valeur choisie par l'implémentateur de l'appareil pour identifier le matériel interne spécifique utilisé par l'appareil, au 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 l'
appareil. Aucune exigence n'est imposée concernant le format spécifique de ce champ,
à l'exception du fait qu'il NE DOIT PAS être nul ni la chaîne vide ("").
Valeur choisie par l'implémentateur de l'appareil pour identifier le nom de l'
android.os.Build.BRAND
entreprise, organisation, personne physique, etc. qui a produit l'appareil, au format
lisible par l'homme. Ce champ peut être utilisé pour indiquer l'OEM

et/ou l'opérateur qui a vendu l'appareil. Aucune exigence n'est imposée au format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
Valeur choisie par l'implémentateur de l'appareil pour identifier la configuration ou la révision spécifique du corps (parfois appelée "conception industrielle
android.os.Build.DEVICE
") de l'appareil.

Aucune exigence n'est imposée concernant le format spécifique
de ce champ, sauf qu'il NE DOIT PAS être nul ni correspondre à la chaîne vide ("").
Chaîne qui identifie de manière unique ce build. Il doit être raisonnablement
lisible par l'humain. Il DOIT respecter le schéma suivant:
$(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)
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
modèle ci-dessus contiennent des espaces, ils DOIVENT être remplacés par le caractère ASCII
underscore ("_") dans l'empreinte.
Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'humain.
android.os.Build.HOST
Aucune exigence n'est imposée concernant le format spécifique de ce champ
, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
Identifiant choisi par l'implémentateur de l'appareil pour faire référence à une version spécifique, au format lisible par l'homme.
Ce champ peut être identique à
android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur
android.os.Build.ID
destinée à être quelque peu significative pour les utilisateurs finaux. Aucune
exigence n'est imposée au format spécifique de ce champ, sauf qu'il NE DOIT PAS
être nul ni contenir la chaîne vide ("").
Valeur choisie par l'implémentateur de l'appareil contenant le nom de l'
appareil tel qu'il est connu par l'utilisateur final. Ce nom DOIT être identique à celui de
android.os.Build.MODEL
sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Aucune
exigence n'est imposée au format spécifique de ce champ, sauf qu'il NE DOIT PAS
être nul ni la chaîne vide ("").
Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement
ou le nom de code de l'appareil. DOIT être lisible par l'humain, mais n'est pas nécessairement
android.os.Build.PRODUCT
destiné à être vu par les utilisateurs finaux. Aucune exigence
n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la
chaîne vide ("").
Liste de balises choisies par l'implémentateur de l'appareil, séparées par une virgule, qui
distingue davantage le build. Par exemple, "unsigned,debug". Ce champ
android.os.Build.TAGS
doit IMPÉRATIVEMENT être défini sur une valeur non nulle ou une chaîne vide (""), mais une seule balise (par exemple,
"release") est acceptable.
android.os.Build.TIME
Valeur représentant le code temporel de la compilation.
Valeur choisie par l'implémentateur de l'appareil spécifiant la configuration d'exécution
du build. Ce champ DOIT avoir l'une des valeurs
android.os.Build.TYPE
correspondant aux trois configurations d'exécution Android typiques: "user",
"userdebug" ou "eng".
Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatisé) qui a généré la version
android.os.Build.USER
. Aucun format spécifique n'est requis pour ce champ.
Sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").

3.2.3. Compatibilité des intents
Android utilise des intents pour réaliser une intégration lâche entre les applications. Cette section décrit les
exigences liées aux modèles d'intent qui DOIVENT être respectées par les implémentations d'appareils. Par "respecté", on entend que l'implémentateur de l'appareil DOIT fournir une activité, un service ou un autre composant Android qui spécifie un filtre d'intent correspondant, et qui se lie et implémente le comportement correct pour chaque modèle d'intent spécifié.

3.2.3.1. Intents d'application principaux
Le projet Android en amont définit un certain nombre d'applications principales, telles qu'un clavier téléphonique, un agenda,un carnet de contacts, un lecteur de musique, etc.
Les implémentateurs d'appareils PEUVENT remplacer ces applications par des versions alternatives.

Toutefois, ces versions alternatives DOIVENT respecter les mêmes modèles d'intent fournis par le projet en amont.
(Par exemple, si un appareil contient un autre lecteur de musique, il doit toujours respecter le modèle d'intent
émis par les applications tierces pour sélectionner un titre.) Les implémentations d'appareils DOIVENT prendre en charge tous les modèles d'intents
listés dans l'annexe A.
3.2.3.2. Forcement d'intents
Étant donné qu'Android est une plate-forme extensible, les implémentateurs d'appareils DOIVENT autoriser chaque modèle d'intent décrit dans l'
annexe A à être remplacé par des applications tierces. Le projet Open Source Android en amont
autorise cela par défaut. Les implémentateurs d'appareils NE DOIVENT PAS associer des droits spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de se lier à ces modèles et de les contrôler.

Cette interdiction inclut spécifiquement la désactivation de l'interface utilisateur "Chooser", qui permet à l'utilisateur de choisir parmi plusieurs applications qui gèrent toutes le même modèle d'intent.

3.2.3.3. Espaces de noms d'intent
Les implémentateurs d'appareils NE DOIVENT PAS inclure de composant Android qui respecte les nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans l'espace de noms android.*.
Les implémentateurs d'appareils NE DOIVENT PAS inclure de composant Android qui respecte les nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans un espace de package
appartenant à une autre organisation.

Les implémentateurs d'appareils NE DOIVENT PAS modifier ni étendre les modèles d'intent
listés dans les annexes A ou B.
Cette interdiction est semblable à celle spécifiée pour les classes de langage Java dans la section 3.6.

3.2.3.4. Intents de diffusion
Les applications tierces s'appuient sur la plate-forme pour diffuser certains intents afin de les informer des modifications apportées à l'environnement matériel ou logiciel.
Les appareils Android compatibles DOIVENT diffuser les intents
publics en réponse aux événements système appropriés. Une liste des intents de diffusion obligatoires est fournie dans l'
annexe B. Toutefois, notez que le SDK peut définir des intents de diffusion supplémentaires, qui DOIVENT également être
respectés.
3.3. Compatibilité des API natives
Le code géré exécuté dans Dalvik peut appeler le code natif fourni dans le fichier .apk de l'application en tant que fichier ELF
.so compilé pour l'architecture matérielle de l'appareil appropriée. Les implémentations d'appareils DOIVENT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler le code natif, à l'aide de la sémantique standard de l'interface Java Native Interface (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)
• Compatibilité minimale avec C++
• OpenGL ES 1.1
Ces bibliothèques DOIVENT être compatibles avec la source (c'est-à-dire avec l'en-tête) et avec le binaire (pour une architecture de processeur donnée) avec les versions fournies dans Bionic par le projet Android Open Source.
Étant donné que les implémentations Bionic ne sont pas entièrement compatibles avec d'autres implémentations telles que la bibliothèque GNU C, les implémentateurs d'appareils DOIVENT utiliser l'implémentation Android.

Si les implémentateurs d'appareils utilisent une implémentation différente de ces bibliothèques, ils doivent assurer la compatibilité des en-têtes et des binaires.

La compatibilité du code natif est difficile. C'est pourquoi nous tenons à répéter que les implémentateurs d'appareils sont
TRÈS vivement encouragés à utiliser les implémentations en amont des bibliothèques listées ci-dessus pour
assurer la compatibilité.
3.4. Compatibilité avec les 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. Par conséquent, l'implémentation WebView doit être compatible avec toutes les implémentations Android.
L'implémentation Open Source Android utilise la version du moteur de rendu WebKit pour implémenter la WebView.

Étant donné qu'il n'est pas possible de développer une suite de tests complète pour un navigateur Web, les implémentateurs d'appareils
DOIVENT utiliser le build en amont spécifique de WebKit dans l'implémentation de WebView. Plus précisément:
• WebView DOIT utiliser la version WebKit 528.5 ou ultérieure de l'arborescence Open Source Android 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 user-agent signalée par la WebView DOIT respecter le format suivant:
Mozilla/5.0 (Linux; U; Android 1.6; <langue>-<pays>; <nom
de l'appareil>; Build/<ID de build>) AppleWebKit/528.5+ (KHTML, like Gecko)
Version/3.1.2 Mobile Safari/525.20.1

◦ La chaîne "<nom de l'appareil>" DOIT être identique à la valeur de
android.os.Build.MODEL
◦ La chaîne "<ID de build>" DOIT être identique à la valeur de android.os.Build.ID.
◦ Les chaînes "<langue>" et "<pays>" DOIVENT respecter les conventions habituelles pour le code pays et la langue, et DOIVENT faire référence aux paramètres régionaux actuels de l'appareil au moment de la requête.

Les implémentations PEUVENT fournir une chaîne user-agent personnalisée dans l'application de navigateur autonome. De plus, le navigateur autonome PEUT être basé sur une autre technologie de navigateur (Firefox,Opera, etc.).

Toutefois, même si une autre application de navigateur est fournie, le composant WebView
fourni aux applications tierces DOIT être basé sur WebKit, comme indiqué ci-dessus.
L'application de navigateur autonome DOIT être compatible avec Gears [Ressources, 12] et PEUT être compatible avec une partie ou la totalité de HTML5.

3.5. Compatibilité du comportement des API
Les comportements de chacun des types d'API (gérée, souple, native et Web) doivent être cohérents avec l'implémentation
recommandée d'Android disponible sur le projet Android Open Source.
Voici quelques domaines de compatibilité spécifiques:
• Les appareils NE DOIVENT PAS modifier le comportement ou la signification d'un intent standard
• Les appareils NE DOIVENT PAS modifier le cycle de vie ou la sémantique du cycle de vie d'un type particulier de composant système (tel que Service, Activity, 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 implémentateurs d'appareils de garantir la compatibilité du comportement.
C'est pourquoi les implémentateurs d'appareils DOIVENT utiliser le code source disponible via le
projet Android Open Source dans la mesure du possible, plutôt que de réimplémenter des parties importantes du système.
La suite de tests de compatibilité (CTS) vérifie la compatibilité comportementale de certaines parties importantes de la plate-forme,
mais pas de toutes. Il incombe à l'implémentateur de s'assurer de la compatibilité comportementale avec le
projet Android 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 le langage de programmation Java.
Pour assurer la compatibilité avec les applications tierces, les implémentateurs d'appareils NE DOIVENT PAS effectuer de modifications interdites (voir ci-dessous) sur les espaces de noms de package suivants:
• java.*
• javax.*
• sun.*
• android.*
• com.android.*

Les modifications interdites incluent les suivantes:
• Les implémentations d'appareils 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émentateurs d'appareils PEUVENT modifier l'implémentation sous-jacente des API, mais ces modifications NE DOIVENT PAS avoir d'incidence sur le comportement indiqué et la signature en langage Java de toute API exposée publiquement.

• Les implémentateurs d'appareils NE DOIVENT PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes à des classes ou interfaces existantes) aux API ci-dessus.

Un "élément exposé publiquement" est toute construction qui n'est pas décorée avec le repère "@hide" dans le code source Android en amont.
En d'autres termes, les implémentateurs d'appareils NE DOIVENT PAS exposer de nouvelles API ni modifier les API existantes dans les espaces de noms indiqués ci-dessus.
Les implémentateurs d'appareils PEUVENT apporter des modifications
internes uniquement, mais ces modifications NE DOIVENT PAS être annoncées ni exposées aux développeurs.
Les implémentateurs d'appareils PEUVENT ajouter des API personnalisées, mais ces API NE DOIVENT PAS se trouver dans un espace de noms appartenant à une autre organisation ou faisant référence à une autre organisation.
Par exemple, les implémentateurs d'appareils NE DOIVENT PAS ajouter d'API à l'espace de noms
com.google.* ou à un espace de noms similaire. Seul Google peut le faire. De même, Google NE DOIT PAS ajouter d'API aux espaces de noms d'autres entreprises.

Si un implémentateur d'appareil propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant
une nouvelle fonctionnalité utile à une API existante ou en ajoutant une nouvelle API), il DOIT consulter
source.android.com et commencer le processus d'envoi de modifications et de code, conformément aux
informations de ce site.
Notez que les restrictions ci-dessus correspondent aux conventions standards de dénomination des API dans le langage de programmation Java. Cette section vise simplement à renforcer ces conventions et à les rendre contraignantes
en les incluant dans cette définition de compatibilité.

3.7. Compatibilité avec les machines virtuelles
Un appareil Android compatible doit prendre en charge la spécification complète du bytecode Dalvik Executable (DEX) et la sémantique de la machine virtuelle Dalvik [Resources, 13].

3.8. Compatibilité de l'interface utilisateur
La plate-forme Android inclut certaines API de développement qui permettent aux développeurs de s'intégrer à l'interface utilisateur du système.
Les implémentations d'appareils DOIVENT intégrer ces API d'UI standards dans les interfaces utilisateur personnalisées qu'ils développent, comme expliqué ci-dessous.

3.8.1. Widgets
Android définit un type de composant, ainsi qu'une API et un cycle de vie correspondants, qui permettent aux applications d'exposer
un "AppWidget" à l'utilisateur final [Resources, 14]. La version de référence Open Source d'Android inclut une application de lanceur
qui comprend des éléments d'interface utilisateur permettant à l'utilisateur d'ajouter, d'afficher et de supprimer des
AppWidgets de l'écran d'accueil.
Les implémentateurs d'appareils PEUVENT remplacer le lanceur de référence (c'est-à-dire l'écran d'accueil).
Les autres lanceurs DOIVENT inclure une prise en charge intégrée des AppWidgets et exposer des éléments d'interface utilisateur
pour ajouter, afficher et supprimer des AppWidgets directement dans le lanceur. Les autres lanceurs PEUVENT
omettre ces éléments d'interface utilisateur. Toutefois, s'ils sont omis, l'implémentateur de l'appareil DOIT fournir une
application distincte accessible depuis le lanceur qui permet aux utilisateurs d'ajouter, d'afficher et de supprimer des
AppWidgets.

3.8.2. Notifications
Android inclut des API qui permettent aux développeurs d'informer les utilisateurs d'événements notables [Resources, 15]. Les implémentateurs d'appareils DOIVENT prendre en charge chaque classe de notification ainsi définie, en particulier les sons, la vibration, la lumière et la barre d'état.

En outre, l'implémentation DOIT afficher correctement toutes les ressources (icônes, fichiers audio, etc.)
prévues dans les API [Resources, 7] ou dans le guide de style des icônes de la barre d'état [Resources, 16]. Les implémentateurs d'appareils PUISSENT proposer une expérience utilisateur alternative pour les notifications que celle fournie par l'implémentation Android Open Source de référence. Toutefois, ces systèmes de notification alternatifs DOIVENT prendre en charge les ressources de notification existantes, comme indiqué ci-dessus.

3.8.3. Recherche
Android inclut des API [Resources, 17] qui permettent aux développeurs d'intégrer la recherche dans leurs applications,
et d'exposer les données de leur application dans la recherche système globale. En général, cette fonctionnalité
consiste en une interface utilisateur unique, à l'échelle du système, qui permet aux utilisateurs de saisir des requêtes, d'afficher des suggestions
à mesure qu'ils saisissent du texte et d'afficher des résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour fournir une recherche dans leurs propres applications, et de fournir des résultats à l'interface utilisateur de recherche globale commune.

Les implémentations d'appareils DOIVENT inclure une interface utilisateur de recherche unique, partagée et à l'échelle du système, capable de fournir des suggestions en temps réel en réponse à l'entrée utilisateur.
Les implémentations d'appareils DOIVENT implémenter les API qui
permettent aux développeurs de réutiliser cette interface utilisateur pour fournir une recherche dans leurs propres applications.
Les implémentations d'appareils DOIVENT implémenter les API qui permettent aux applications tierces d'ajouter des suggestions
au champ de recherche lorsqu'il est exécuté en mode recherche globale. Si aucune application tierce n'est installée pour utiliser cette fonctionnalité, le comportement par défaut DOIT être l'affichage des résultats et des suggestions du moteur de recherche Web.

Les implémentations d'appareils PEUVENT inclure d'autres interfaces utilisateur de recherche, mais DOIVENT inclure un bouton de recherche dédié, physique ou logiciel, qui peut être utilisé à tout moment dans n'importe quelle application pour appeler le framework 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 des chaînes courtes non modales à l'utilisateur final, qui disparaissent au bout d'un court laps de temps.
Les implémentations d'appareils DOIVENT afficher les toasts des applications aux utilisateurs finaux de manière très visible.

4. Compatibilité logicielle de référence
Les implémentateurs d'appareils DOIVENT tester la compatibilité de l'implémentation à l'aide des applications open source suivantes:
• Calculatrice (inclue dans le SDK)
• Lunar Lander (inclue dans le SDK)
• ApiDemos (inclue dans le SDK)
• Les applications "Apps for Android" [Ressources, 19]
Chaque application ci-dessus DOIT se lancer et se comporter correctement sur l'implémentation pour que l'implémentation soit

considérée comme compatible.

5. Compatibilité de l'empaquetage d'applications
Les implémentations d'appareils 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 les formats .apk, Android Manifest ou bytecode Dalvik
de manière à empêcher l'installation et l'exécution correcte de ces fichiers sur d'autres
appareils compatibles. Les implémentateurs d'appareils DOIVENT utiliser l'implémentation en amont de référence de Dalvik,
et le système de gestion des paquets de l'implémentation de référence.
6. Compatibilité multimédia
Un appareil Android compatible doit prendre en charge les codecs multimédias suivants. Tous ces codecs sont
fournis en tant qu'implémentations logicielles dans l'implémentation Android privilégiée du projet Android Open
Source [Ressources, 4].
Veuillez noter que ni Google ni l'Open Handset Alliance ne font aucune déclaration indiquant que ces
codecs ne sont pas soumis à des brevets tiers. Les personnes qui souhaitent utiliser ce code source dans des produits matériels ou
logiciels sont informées que les implémentations de ce code, y compris dans des logiciels Open Source ou
shareware, peuvent nécessiter des licences de brevets de la part des titulaires de brevets concernés.
Audio
Nom
Détails de l'encodeur/décodeur
Fichiers compatibles
Contenu mono/stéréo dans n'importe quel
3GPP (.3gp) et
combinaison de débits binaires standards
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
jusqu'à 160 kbit/s et fichiers de taux d'échantillonnage. Non compatible avec les fichiers
entre 8 et 48 kHz
AAC (.aac)
contenu mono/stéréo dans
3GPP (.3gp) et
HE-AACv1
combinaison de débits binaires standards
MPEG-4 (.mp4, .m4a)
X
(AAC+)
jusqu'à 96 kbit/s et fichiers de fréquence d'échantillonnage. Non compatible avec les fichiers

�� Non compatible avec les fichiers
entre 8 et 48 kHz
AAC (.aac)
AMR-NB
4,75 à 12,2 kbit/s échantillonnés à
Fichiers 3GPP (.3gp)
X
X
8 kHz
AMR-WB
9 taux de 6,60 kbit/s à 23,85 kbit/s
-Fichiers 3GPP (.3gp)
X
kbit/s échantillonnés à 16 kHz
MP3
Fichiers MP3 (.mp3) mono/stéréo de 8 à 320 kbit/s
X
(CBR) ou à débit variable (VBR)
Type 0 et 1 (.mid, .xmf,
MIDI type 0 et 1. DLS version 1
MIDI
X
.mxmf). Également RTTTL/RTX
et 2. XMF et Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Compatibilité avec les formats de sonnerie
et iMelody (.imy)
RTTTL/RTX, OTA et iMelody
Ogg Vorbis
.ogg
X
PCM linéaire 8 et 16 bits (fréquences jusqu'à la limite du matériel)
PCM
X
WAVE
Image
Fichiers
Nom
Détails de l'encodeur/décodeur
Compatible
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
Vidéo
Fichiers
Nom
Détails de l'encodeur/décodeur
Compatible
3GPP (.3gp)
H.263
X
X
fichiers
3GPP (.3gp)
H.264
X
et MPEG-4
(.mp4) fichiers
MPEG4
X
Fichier 3GPP (.3gp)
SP
7.
Compatibilité avec les outils de développement
Les implémentations d'appareils DOIVENT prendre en charge les outils de développement Android fournis dans le SDK Android.
Plus précisément, les appareils compatibles avec Android DOIVENT être compatibles avec:
• Android Debug Bridge ou adb [Resources, 21]
Les implémentations d'appareil DOIVENT prendre en charge toutes les fonctions adb, comme indiqué dans le SDK Android.
Le daemon adb côté appareil DOIT être inactif par défaut, mais un mécanisme accessible par l'
utilisateur doit être disponible pour activer Android Debug Bridge.
• Service de surveillance du débogage Dalvik ou ddms [Ressources, 22]
Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctionnalités ddms, comme indiqué dans le SDK Android.
Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge
lorsque l'utilisateur a activé Android Debug Bridge, comme ci-dessus.

• Monkey [Resources, 23]
Les implémentations d'appareils DOIVENT inclure le framework Monkey et le mettre à la disposition des applications.

8. Compatibilité matérielle
Android est conçu pour aider les implémentateurs d'appareils à créer des facteurs de forme et des configurations innovants.
En même temps, les développeurs Android s'attendent à ce que certains matériels, capteurs et API soient disponibles sur tous les appareils Android.
Cette section liste les fonctionnalités matérielles que tous les appareils compatibles avec Android 1.6 doivent prendre en charge. Dans
Android 1.6, la plupart des fonctionnalités matérielles (comme le Wi-Fi, la boussole et l'accéléromètre) sont requises.
Si un appareil inclut un composant matériel particulier associé à une API pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme défini dans la documentation du SDK Android.

8.1. Affichage
Android 1.6 inclut des fonctionnalités qui effectuent certaines opérations de scaling et de transformation automatiques dans certaines circonstances, afin de s'assurer que les applications tierces fonctionnent raisonnablement bien sur les configurations matérielles pour lesquelles elles n'ont pas nécessairement été conçues explicitement [Resources, 24].

Les appareils DOIVENT
implémenter correctement ces comportements, comme indiqué dans cette section.
8.1.1. Configurations d'affichage standards
Ce tableau liste les configurations d'écran standards considérées comme compatibles avec Android:
Diagonale
Taille de l'écran
Densité de l'écran
Type d'écran
Largeur (pixels)
Hauteur (pixels)
Plage de longueur
Groupe
Groupe
(pouces)
QVGA
240
320
2,6 à 3 pouces
Petit
Faible
WQVGA
240
400
3,2 à 3,5 pouces
Normal
Faible
FWQVGA
240
432
3,5 à 3,8 pouces
Normal
Faible
HVGA
320
480
3 à 3,5 pouces
Normal
Moyen
WVGA
480
800
3,3 à 4 pouces
Normal
Élevé
FWVGA
480
854
3,5 à 4 pouces
Normal
Élevé
WVGA
480
800
4,8 à 5,5 pouces
Grand
Moyen
FWVGA
480
854
5 à 5,8 pouces
Grand
Moyen
Les implémentations d'appareils correspondant à l'une des configurations standards ci-dessus DOIVENT être configurées
pour indiquer la taille d'écran indiquée aux applications via la classe android.content.res.Configuration [Resources,
25].
Certains packages .apk ont des fichiers manifestes qui ne les identifient pas comme compatibles avec une plage de densité spécifique.
Lors de l'exécution de telles applications, les contraintes suivantes s'appliquent:

• Les implémentations d'appareils DOIVENT interpréter toutes les ressources présentes comme étant par défaut
"medium" (connu sous le nom de "mdpi" dans la documentation du SDK).
• Lorsque vous utilisez un écran à densité "faible", les implémentations d'appareils DOIVENT réduire les éléments de taille moyenne/
mdpi d'un facteur de 0,75.
• Lorsque vous utilisez un écran à "haute" densité, les implémentations d'appareils DOIVENT mettre à l'échelle les éléments de densité moyenne/
mdpi d'un facteur 1,5.
• Les implémentations d'appareils NE DOIVENT PAS mettre à l'échelle les éléments dans une plage de densité et DOIVENT mettre à l'échelle
les éléments exactement selon ces facteurs entre les plages de densité.
8.1.2. Configurations d'affichage non standards
Les configurations d'affichage qui ne correspondent à aucune des configurations standards listées dans la section 8.2.1 nécessitent
une réflexion et un travail supplémentaires pour être compatibles. Les implémentateurs d'appareils DOIVENT contacter l'équipe de compatibilité Android
, comme indiqué dans la section 12, pour obtenir des classifications pour le bucket de taille d'écran, la densité et le facteur de mise à l'échelle.
Lorsque ces informations sont fournies, les implémentations d'appareils DOIVENT les implémenter
comme spécifié.
Notez que certaines configurations d'affichage (telles que les écrans très grands ou très petits, et certains formats)
sont fondamentalement incompatibles avec Android 1.6. Par conséquent, les implémentateurs d'appareils sont invités à
contacter l'équipe de compatibilité Android dès que possible au cours du processus de développement.
8.1.3. Métriques d'affichage
Les implémentations d'appareil DOIVENT indiquer les valeurs correctes pour toutes les métriques d'affichage définies dans
android.util.DisplayMetrics [Resources, 26].
8.2. Clavier
Implémentations de l'appareil:
• DOIVENT prendre en charge le framework de gestion des entrées (qui permet aux développeurs tiers de créer des moteurs de gestion des entrées, c'est-à-dire des claviers virtuels) comme indiqué sur
developer.android.com
• DOIVENT fournir au moins une implémentation de clavier virtuel (que le clavier physique soit présent ou non)
• PEUVENT inclure des implémentations de clavier virtuel supplémentaires
• PEUVENT inclure un clavier physique
• NE DOIVENT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans
android.content.res.Configuration [Resources, 25] (c'est-à-dire QWERTY ou 12 touches)
8.3.

Navigation sans contact
Implémentations de l'appareil:
• POURRA omettre les options de navigation sans contact (c'est-à-dire qu'il peut omettre un trackball, un pavé directionnel à 5 directions ou une roue)
• DOIT indiquer via android.content.res.Configuration [Resources, 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 des applications en mode portrait ou paysage
. C'est-à-dire que l'appareil doit respecter la requête de l'application pour une orientation d'écran
spécifique. Les implémentations d'appareils PEUVENT sélectionner l'orientation portrait ou paysage par défaut.
Les appareils DOIVENT indiquer la valeur correcte pour l'orientation actuelle de l'appareil, chaque fois qu'ils sont interrogés via
android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres API.
8.5. Saisie par écran tactile
Implémentations de l'appareil:
• DOIVENT comporter un écran tactile
• PEUVENT comporter un écran tactile capacitif ou résistif
• DOIVENT indiquer la valeur d'android.content.res.Configuration [Resources, 25] reflétant
correspondant au type d'écran tactile spécifique de l'appareil
8.6. USB
Implémentations de l'appareil:
• DOIVENT implémenter un client USB, connectable à un hôte USB avec un port USB-A standard
• DOIVENT implémenter Android Debug Bridge via USB (comme décrit dans la section 7)
• DOIVENT implémenter un client de stockage de masse USB pour le stockage amovible/multimédia présent dans l'
appareil
• DOIVENT utiliser le facteur de forme micro USB côté appareil
• DOIVENT implémenter la prise en charge de la spécification de stockage de masse USB (afin que l'accès au stockage amovible ou fixe de l'appareil soit possible depuis un PC hôte)
• PEUVENT inclure un port non standard côté appareil, mais dans ce cas DOIVENT être livrés avec un câble capable de
connecter le brochage personnalisé au port USB-A standard
8.7.
Touches de navigation
Les fonctions Accueil, Menu et Retour sont essentielles au paradigme de navigation Android. Les implémentations de l'
appareil DOIVENT mettre ces fonctions à la disposition de l'utilisateur en permanence, quel que soit l'état de l'
application. Ces fonctions DOIVENT être implémentées via des boutons dédiés. Ils PEUVENT être implémentés
à l'aide de logiciels, de gestes, d'un écran tactile, etc., mais dans ce cas, ils DOIVENT toujours être accessibles et ne pas masquer ni interférer avec la zone d'affichage de l'application disponible.

Les implémentateurs d'appareils DOIVENT également fournir une clé de recherche dédiée. Les implémentateurs d'appareils PEUVENT également
fournir des touches d'envoi et de fin pour les appels téléphoniques.
8.8. Wi-Fi
Les implémentations de l'appareil DOIVENT être compatibles avec les normes 802.11b et 802.11g, et PEUVENT être compatibles avec la norme 802.11a.

8.9. Caméra
Les implémentations d'appareils DOIVENT inclure une caméra. L'appareil photo inclus:
• DOIT avoir une résolution d'au moins 2 mégapixels
• DOIT avoir un autofocus matériel ou logiciel implémenté dans le pilote de l'appareil photo
(transparent pour le logiciel d'application)
• PEUT avoir un matériel à mise au point fixe ou EDOF (profondeur de champ étendue)
• PEUT inclure un flash. Si la caméra inclut un flash, la lampe de flash NE DOIT PAS être allumée lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de l'appareil photo.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra
[Resources, 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
fournies aux rappels d'application.
2. Si une application enregistre une instance android.hardware.Camera.PreviewCallback et que le système appelle la méthode onPreviewFrame() lorsque le format d'aperçu est YCbCr_420_SP, les données du byte[] transmises à onPreviewFrame() doivent également être au format d'encodage NV21.
(Il s'agit du format utilisé nativement par la famille de matériel 7k.)

En d'autres termes, NV21 DOIT être la valeur par défaut.
8.9.1. Caméras sans autofocus
Si un appareil ne dispose pas d'une caméra avec autofocus, l'implémentateur de l'appareil DOIT respecter les exigences supplémentaires de
cette section. Les implémentations d'appareils DOIVENT implémenter l'API Appareil photo complète incluse dans la documentation du SDK Android 1.6
de manière raisonnable, quelles que soient les fonctionnalités du matériel de l'appareil photo.
Pour Android 1.6, si la caméra ne dispose pas de mise au point automatique, l'implémentation de l'appareil DOIT respecter les points suivants:
1. Le système DOIT inclure une propriété système en lecture seule nommée "ro.workaround.noautofocus"
avec la valeur "1". Cette valeur est destinée à être utilisée par des applications telles qu'Android Market pour
identifier de manière sélective les fonctionnalités de l'appareil. Elle sera remplacée dans une prochaine version d'Android par une
API robuste.
2. Si une application appelle android.hardware.Camera.autoFocus(), le système DOIT appeler la méthode de rappel onAutoFocus() sur toutes les instances android.hardware.Camera.AutoFocusCallback enregistrées, même si aucune mise au point n'a eu lieu.

Cela permet d'éviter que les applications existantes ne plantent en attendant indéfiniment un rappel autofocus
qui n'arrivera jamais.
3. L'appel de la méthode AutoFocusCallback.onAutoFocus() DOIT être déclenché par le pilote ou le framework
dans un nouvel événement sur le thread Looper du framework principal. Autrement dit, Camera.autoFocus()
NE DOIT PAS appeler directement AutoFocusCallback.onAutoFocus() car cela enfreint le modèle de threads du framework Android
et casse les applications.
8.10. Accéléromètre
Les implémentations d'appareils DOIVENT inclure un accéléromètre à trois axes et DOIVENT pouvoir générer des événements à au moins 50 Hz. Le système de coordonnées utilisé par l'accéléromètre DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans la section [Resources, 28] de l'API Android.

8.11. Buse
Les implémentations d'appareils DOIVENT inclure une boussole à trois axes et DOIVENT pouvoir générer des événements à au moins
10 Hz. Le système de coordonnées utilisé par la boussole DOIT respecter le système de coordonnées des capteurs Android
tel que défini dans l'API Android [Resources, 28].
8.12. GPS
Les implémentations d'appareils DOIVENT inclure un GPS et DEVRAIENT inclure une forme de technique de "GPS assisté"
pour réduire le temps de verrouillage du GPS.
8.13. Téléphonie
Implémentations de l'appareil:
• DOIVENT inclure la téléphonie GSM ou CDMA
• DOIVENT implémenter les API appropriées, comme indiqué dans la documentation du SDK Android sur
developer.android.com
Notez que cette exigence implique que les appareils autres que les téléphones ne sont pas compatibles avec Android 1.6. Les appareils Android
1.6 DOIVENT inclure du matériel de téléphonie. Pour en savoir plus sur les appareils autres que les téléphones, consultez l'annexe C.

8.14. Commandes de volume
Les appareils compatibles avec Android DOIVENT inclure un mécanisme permettant à l'utilisateur d'augmenter et de diminuer le volume audio.
Les implémentations d'appareils DOIVENT mettre ces fonctions à la disposition de l'utilisateur à tout moment,
quel que soit l'état de l'application. Ces fonctions PEUVENT être implémentées à l'aide de touches physiques,de logiciels, de gestes, d'un écran tactile, etc., mais elles DOIVENT toujours être accessibles et ne pas masquer ni interférer avec la zone d'affichage de l'application disponible (voir "Affichage" ci-dessus).

Lorsque ces boutons sont utilisés, les événements de touche correspondants DOIVENT être générés et envoyés à l'application de premier plan.
Si l'événement n'est pas intercepté et ignoré par l'application, l'implémentation de device
DOIT gérer l'événement en tant que commande de volume système.
9. Compatibilité des performances
L'un des objectifs du programme de compatibilité Android est de garantir une expérience d'application cohérente pour les
consommateurs. Les implémentations compatibles doivent non seulement s'assurer que les applications s'exécutent correctement sur l'
appareil, mais aussi qu'elles le font avec des performances raisonnables et une bonne expérience utilisateur globale.
Les implémentations d'appareils DOIVENT respecter les métriques de performances clés d'un appareil compatible avec Android 1.6,
comme indiqué dans le tableau ci-dessous:
Métrique
Seuil de performances
Commentaires

Ceci est testé par CTS.
Les applications suivantes
Le temps de démarrage est mesuré comme le temps total pour
devraient se lancer dans le
terminer le chargement de l'activité par défaut pour l'
Application
heure spécifiée.
application, y compris le temps nécessaire pour démarrer le
Temps de démarrage
Navigateur: moins de 1 300 ms
processus Linux, charger le package Android dans la
MMS/SMS: moins de 700 ms
VM Dalvik et appeler onCreate.
AlarmClock: moins de 650 ms
Plusieurs applications seront
Cela est testé par CTS.
lancées. Le redémarrage de la première application simultanée doit se terminer en moins de temps que le lancement initial.

10. Compatibilité du modèle de sécurité
Les implémentations d'appareils DOIVENT implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android
, tel que défini dans le document de référence sur la sécurité et les autorisations des API [Resources, 29] dans la documentation pour les développeurs Android.
Les implémentations d'appareils DOIVENT prendre en charge l'installation d'applications
autosignées sans nécessiter d'autorisations/certificats supplémentaires de la part de 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 d'appareils DOIVENT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation pour les développeurs Android [Ressources, 9].
Plus précisément, les implémentations DOIVENT appliquer chaque autorisation
définie comme décrit dans la documentation du 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'ID d'autorisation ne figurent pas dans l'espace de noms
android.*.
10.2. Séparation des utilisateurs et des processus
Les implémentations d'appareils DOIVENT prendre en charge le modèle de bac à sable d'application Android, dans lequel chaque application
s'exécute en tant qu'UID unique de style Unix et dans un processus distinct.
Les implémentations d'appareils DOIVENT prendre en charge l'exécution de plusieurs applications avec le même ID utilisateur Linux, à condition
que les applications soient correctement signées et créées, comme défini dans la référence sur la sécurité et les autorisations
[Ressources, 29].

10.3. Autorisations du système de fichiers
Les implémentations d'appareils DOIVENT prendre en charge le modèle d'autorisations d'accès aux fichiers Android tel que défini dans la référence sur la sécurité et les autorisations [Resources, 29].

11. Compatibility Test Suite
Les implémentations d'appareils DOIVENT réussir les tests de la Compatibility Test Suite (CTS) Android [Resources, 3] disponibles
sur le projet Android Open Source, à l'aide du logiciel final fourni sur l'appareil. En outre, les implémentateurs d'appareils DOIVENT utiliser autant que possible l'implémentation de référence dans l'arborescence Open Source Android et DOIVENT assurer la compatibilité en cas d'ambiguïté dans CTS et pour toute réimplémentation de parties du code source de référence.

Le CTS est conçu pour s'exécuter sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs.
Le CTS sera versionné indépendamment de cette définition de la compatibilité, et plusieurs révisions du
CTS peuvent être publiées pour Android 1.6. Toutefois, ces versions ne corrigent que les bugs de comportement dans les tests CTS
et n'imposent aucun nouveau test, comportement ni API pour une version de plate-forme donnée.
12. Nous contacter
Vous pouvez contacter l'équipe de compatibilité Android à l'adresse compatibility@android.com pour obtenir des précisions sur
cette définition de la compatibilité et pour nous faire part de vos commentaires à ce sujet.

Annexe A: Intents d'application obligatoires
REMARQUE: Cette liste est provisoire et sera mise à jour à l'avenir.
Actions de l'application
Schémas Types MIME
(aucun)
texte brut
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
Appareil photo
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
rtsp
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/brut
E-mail
android.intent.action.SEND
image/*
vidéo/*
android.intent.action.VIEW
mailto
android.intent.action.SENDTO
sms
android.intent.action.VIEW
smsto
SMS / MMS android.intent.action.SENDTO
mms
mmsto
audio/*
application/ogg
Musique
android.intent.action.VIEW
fichier
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/
artistealbum
vnd.android.cursor.dir/
album
vnd.android.cursor.dir/
android.intent.action.PICK
en cours de lecture
vnd.android.cursor.dir/
morceau
nd.android.cursor.dir/
liste de lecture
vnd.android.cursor.dir/
vidéo
média/*
audio/*
android.intent.action.GET_CONTENT
application/ogg
application/x-ogg
vidéo/*

contenu
Package
android.intent.action.VIEW
fichier
Installateur
package
fichier
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_SETTINGS
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
query
android.intent.action.SEARCH_LONG_PRESS
Voice
android.intent.action.VOICE_COMMAND
Contacts Gestion
Action d'intention
Description
Démarre une activité qui permet à l'utilisateur de choisir
ATTACH_IMAGE
un contact auquel joindre une image.
Utilisé
avec EXTRA_CREATE_DESCRIPTION
avec SHOW_OR_CREATE_CONTACT pour
spécifier une description exacte à

afficher lorsque l'utilisateur est invité à
créer un contact.
Utilisé
avec SHOW_OR_CREATE_CONTACT pour
EXTRA_FORCE_CREATE
forcer la création d'un contact si aucun
contact correspondant n'est trouvé.
Il s'agit de l'intent déclenché lorsqu'un
SUGGESTION_RECHERCHE_CLIQUÉE
clic est effectué sur une suggestion de recherche.
C'est l'intent déclenché lorsqu'un utilisateur clique sur une
suggestion de recherche pour créer un
contact.
Il s'agit de l'intent déclenché lorsqu'une
suggestion de recherche pour composer un numéro
est sélectionnée.

Prend en entrée un URI de données avec un schéma mailto:
SHOW_OR_CREATE_CONTACT
ou tel:.

Annexe B: Intents de diffusion requisREMARQUE: Cette liste est provisoire et sera mise à jour à l'avenir.

Action d'intent
Description
Action de diffusion: diffusée une fois, après le démarrage du système
ACTION_BOOT_COMPLETED
.
Action de diffusion: elle est diffusée une seule fois, lorsqu'un appel
ACTION_CALL_BUTTON
est reçu.
Action de diffusion: le bouton de l'appareil photo a été enfoncé
ACTION_CAMERA_BUTTON
.
Action de diffusion: la configuration (orientation, paramètres régionaux, etc.) de l'appareil ACTION_CONFIGURATION_CHANGED

actuelle a changé.

ACTION_DATE_CHANGED
Action de diffusion: la date a changé.
Action de diffusion: indique une faible quantité de mémoire
ACTION_DEVICE_STORAGE_LOW
sur l'appareil
Action de diffusion: indique une faible quantité de mémoire
ACTION_DEVICE_STORAGE_OK
sur l'appareil n'existe plus
Action de diffusion: casque filaire branché ou
ACTION_HEADSET_PLUG
débranché.
Action de diffusion: un mode de saisie a été
ACTION_INPUT_METHOD_CHANGED
changé.
Action de diffusion: le support externe a été retiré
ACTION_MEDIA_BAD_REMOVAL
de l'emplacement de la carte SD, mais le point d'installation n'a pas été
désinstallé.
Action de diffusion: le bouton multimédia a été enfoncé.
ACTION_MEDIA_BUTTON

Action de diffusion: un support externe est présent et est en cours de vérification sur le disque. Le chemin d'accès au point d'installation pour
ACTION_MEDIA_CHECKING
le support de vérification est contenu dans le champ
Intent.mData.

Action de diffusion: l'utilisateur a exprimé le souhait de
ACTION_MEDIA_EJECT
retirer le support de stockage externe.
Action de diffusion: un support externe est présent et
ACTION_MEDIA_MOUNTED
est installé à son point d'installation.
Action de diffusion: un support externe est présent, mais utilise un système de fichiers incompatible (ou est vide). Le chemin d'accès au
ACTION_MEDIA_NOFS
point d'installation du support de vérification est
contenu dans le champ Intent.mData.

Action de diffusion: le contenu multimédia externe a été
ACTION_MEDIA_REMOVED
supprimé.
Action de diffusion: l'explorateur multimédia a terminé
ACTION_MEDIA_SCANNER_FINISHED
l'exploration d'un répertoire.
Action de diffusion: demandez au lecteur multimédia de
ACTION_MEDIA_SCANNER_SCAN_FILE
analyser un fichier et de l'ajouter à la base de données multimédia.

Action de diffusion: l'explorateur multimédia a commencé
ACTION_MEDIA_SCANNER_STARTED
à analyser un répertoire.
Action de diffusion: le support multimédia externe est démonté
ACTION_MEDIA_SHARED
, car il est partagé via un stockage de masse USB.
Action de diffusion: un support externe est présent, mais
ACTION_MEDIA_UNMOUNTABLE
ne peut pas être installé.
Action de diffusion: le support externe est présent, mais
ACTION_MEDIA_UNMOUNTED
n'est pas installé à son point d'installation.
Action de diffusion: un appel sortant est sur le point d'être
ACTION_NEW_OUTGOING_CALL
effectué.
Action de diffusion: un nouveau package d'application a été
ACTION_PACKAGE_ADDED
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 d'un package.
Cette action doit être précédée de ACTION_PACKAGE_RESTARTED, après quoi
ACTION_PACKAGE_DATA_CLEARED
toutes ses données persistantes sont effacées et cette diffusion est envoyée.

Notez que le package effacé
ne reçoit pas cette diffusion. Les données contiennent
le nom du package.
Action de diffusion: un package d'application existant
a été supprimé de l'appareil. Les données
ACTION_PACKAGE_REMOVED
contiennent le nom du package. Le package
en cours d'installation ne reçoit pas cet intent.
Action de diffusion: une nouvelle version d'un package
ACTION_PACKAGE_REPLACED
d'application a été installée, remplaçant une version
existante précédemment installée.
Action de diffusion: l'utilisateur a redémarré un
package et tous ses processus ont été arrêtés.
Tout l'état d'exécution qui lui est associé (processus,
ACTION_PACKAGE_RESTARTED
alarmes, notifications, etc.) doit être supprimé. Notez
que le package redémarré ne reçoit pas cette diffusion.
Les données contiennent le nom du package
.
Action de diffusion: certains fournisseurs de contenu ont des parties de leur espace de noms dans lesquelles ils publient de nouveaux événements ou éléments ACTION_PROVIDER_CHANGED qui peuvent intéresser particulièrement l'utilisateur.

ACTION_SCREEN_OFF
Action de diffusion: envoyée après l'extinction de l'écran.
ACTION_SCREEN_ON
Action de diffusion: envoyée après l'allumage de l'écran.
Action de diffusion: un ID utilisateur a été supprimé
ACTION_UID_REMOVED
du système.
Action de diffusion: l'appareil est passé en mode de stockage de masse USB
ACTION_UMS_CONNECTED
.

Action de diffusion: l'appareil a quitté le mode de stockage de masse USB
ACTION_UMS_DISCONNECTED
.
Action de diffusion: envoyée lorsque l'utilisateur est présent
ACTION_USER_PRESENT
après le réveil de l'appareil (par exemple, lorsque le verrouillage des touches est
disparu).
Action de diffusion: le fond d'écran système actuel
ACTION_WALLPAPER_CHANGED
a changé.
ACTION_TIME_CHANGED
Action de diffusion: l'heure a été définie.
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 le niveau de charge
ACTION_BATTERY_CHANGED
de la batterie a changé.
Action de diffusion: indique l'état de la batterie faible
ACTION_BATTERY_LOW
sur l'appareil. Cette diffusion correspond à la boîte de dialogue système
"Avertissement de batterie faible".
Action de diffusion: indique que la batterie est désormais correcte
après avoir été faible.
ACTION_BATTERY_OKAY
est envoyé après ACTION_BATTERY_LOW une fois que la batterie
est de nouveau en bon état.
État du réseau
Action d'intent
Description
Action d'intent de diffusion indiquant que l'
NETWORK_STATE_CHANGED_ACTION
état de la connectivité Wi-Fi a changé.
Action d'intent de diffusion indiquant que le RSSI (intensité du signal)
RSSI_CHANGED_ACTION
a changé.
Action d'intent de diffusion indiquant qu'une
SUPPLICANT_STATE_CHANGED_ACTION
connexion au demandeur a été établie ou perdue.

Action d'intent de diffusion indiquant que le Wi-Fi
WIFI_STATE_CHANGED_ACTION
a été activé, désactivé, en cours d'activation,
désactivé ou inconnu.
Les ID de réseau des réseaux configurés
NETWORK_IDS_CHANGED_ACTION
peuvent avoir changé.
Action d'intent de diffusion indiquant que le paramètre ACTION_BACKGROUND_DATA_SETTING_CHANGED pour la consommation des données en arrière-plan a changé de valeur.

Intent de diffusion indiquant qu'une modification de la connectivité réseau
CONNECTIVITY_ACTION
a eu lieu.
Action de diffusion: l'utilisateur a activé ou désactivé le mode Avion sur son
ACTION_AIRPLANE_MODE_CHANGED
téléphone.

Annexe C : Considérations futures : cet annexe clarifie certaines parties de la définition de la compatibilité d'Android 1.6 et, dans certains cas, décrit les modifications prévues ou planifiées pour une future version de la plate-forme Android.

Cet annexe est fournie à titre informatif et à des fins de planification uniquement. Elle
ne fait pas partie de la définition de la compatibilité pour Android 1.6.
1. Appareils autres que des téléphones
Android 1.6 est destiné exclusivement aux téléphones. La fonctionnalité de téléphonie n'est pas facultative. Les futures versions
de la plate-forme Android devraient rendre la téléphonie facultative (et donc permettre l'utilisation d'appareils Android
autres que des téléphones), mais seuls les téléphones sont compatibles avec Android 1.6.
2. Compatibilité Bluetooth
La version 1.6 d'Android n'est pas compatible avec les API Bluetooth. Par conséquent, du point de vue de la compatibilité
, le Bluetooth n'impose aucune considération pour cette version de la plate-forme. Toutefois, une future version
d'Android introduira des API Bluetooth. À ce stade, la compatibilité avec le Bluetooth deviendra obligatoire.

Par conséquent, nous vous recommandons vivement d'inclure le Bluetooth sur les appareils Android 1.6 afin qu'ils soient
compatibles avec les futures versions d'Android qui nécessitent le Bluetooth.
3. Composants matériels requis
Tous les composants matériels de la section 8 (y compris le Wi-Fi, le magnétomètre/la boussole, l'accéléromètre, etc.) sont
obligatoires et ne peuvent pas être omis. Les futures versions d'Android devraient rendre certains (mais pas tous) de
ces composants facultatifs, en tandem avec les outils correspondants permettant aux développeurs tiers de gérer ces
modifications.
4. Exemples d'applications
Le document de définition de la compatibilité d'une future version d'Android inclura une liste d'applications plus complète et plus représentative que celles listées dans la section 4 ci-dessus.
Pour Android 1.6, les applications
listées dans la section 4 doivent être testées.
5. Écrans tactiles
Les futures versions de la définition de compatibilité autoriseront peut-être ou non les appareils à omettre les écrans tactiles.
Toutefois, actuellement, une grande partie de l'implémentation du framework Android suppose l'existence d'un
écran tactile. L'absence d'un écran tactile entraînerait une interruption importante de toutes les applications Android tierces actuelles.
Par conséquent, sous Android 1.6, un écran tactile est requis pour la compatibilité.

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

Définition de la compatibilité avec Android 1.6

Plan du document