Définition de la compatibilité avec Android 2.1

Copyright © 2010, Google Inc. Tous droits réservés.
compatibility@android.com

1. Introduction

Ce document énonce les exigences à respecter pour que les téléphones mobiles soient compatibles avec Android 2.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, 1].

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écutant Android 2.1. 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 2.1, les implémentations d'appareils:

  • DOIVENT respecter les exigences présentées dans cette définition de la compatibilité, y compris les documents incorporés par référence.
  • DOIT réussir la version la plus récente de la suite de tests de compatibilité (CTS) Android disponible au moment de l'implémentation du logiciel de l'appareil. (Le CTS est disponible dans le cadre du projet Android Open Source [Ressources, 2].) Le CTS teste de nombreux composants décrits dans ce document, mais pas tous.

Lorsque cette définition ou le CTS sont silencieux, ambigus ou incomplets, il incombe à l'implémentateur de l'appareil de s'assurer de la compatibilité avec les implémentations existantes. C'est pourquoi le Projet Android Open Source [Ressources, 3] est à la fois l'implémentation de référence et privilégiée d'Android. Les implémentateurs d'appareils sont fortement 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 est de la responsabilité de l'implémentateur de garantir une compatibilité comportementale totale avec l'implémentation Android standard, y compris et au-delà de la suite de tests de compatibilité. Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par ce document.

2. Ressources

  1. Niveaux d'exigences de la RFC 2119 de l'IETF: http://www.ietf.org/rfc/rfc2119.txt
  2. Présentation du programme de compatibilité Android: http://source.android.com/compatibility/index.html
  3. Projet Android Open Source: http://source.android.com/
  4. Définitions et documentation des API: http://developer.android.com/reference/packages.html
  5. Référence sur les autorisations Android: http://developer.android.com/reference/android/Manifest.permission.html
  6. Référence android.os.Build: http://developer.android.com/reference/android/os/Build.html
  7. Chaînes de version autorisées pour Android 2.1: http://source.android.com/docs/compatibility/2.1/versions.html
  8. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  10. Spécification de la machine virtuelle Dalvik: disponible dans le code source Android, à l'adresse dalvik/docs
  11. AppWidgets : http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. Notifications: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. Ressources d'application: http://code.google.com/android/reference/available-resources.html
  14. Guide de style des icônes de la barre d'état: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. Gestionnaire de recherche: http://developer.android.com/reference/android/app/SearchManager.html
  16. Toasts: http://developer.android.com/reference/android/widget/Toast.html
  17. Fonds d'écran animés: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. Applications pour Android: http://code.google.com/p/apps-for-android
  19. Documentation de référence des outils (pour adb, aapt et ddms): http://developer.android.com/guide/developing/tools/index.html
  20. Description du fichier APK Android: http://developer.android.com/guide/topics/fundamentals.html
  21. Fichiers manifestes: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. Outil de test du singe: https://developer.android.com/studio/test/other-testing-tools/monkey
  23. Compatibilité avec plusieurs écrans: http://developer.android.com/guide/practices/screens_support.html
  24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  25. android.util.DisplayMetrics : http://developer.android.com/reference/android/util/DisplayMetrics.html
  26. android.hardware.Camera : http://developer.android.com/reference/android/hardware/Camera.html
  27. Espace de coordonnées du capteur: http://developer.android.com/reference/android/hardware/SensorEvent.html
  28. Documentation de référence sur la sécurité et les autorisations Android: http://developer.android.com/guide/topics/security/security.html
  29. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

Bon nombre de ces ressources sont dérivées directement ou indirectement du SDK Android 2.1 et seront fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de la compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Tous les détails techniques fournis dans les références ci-dessus sont considérés comme faisant partie de cette définition de compatibilité.

3. Logiciel

La plate-forme Android comprend un ensemble d'API gérées, un ensemble d'API natives et un ensemble d'API dites "soft", telles que le système Intent et les API d'application Web. Cette section détaille les API dures et souples 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é avec les 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 d'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 2.1 [Ressources, 4].

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 avec une compatibilité douce

En plus des API gérées de la section 3.1, Android inclut également une API "soft" importante, uniquement au moment de l'exécution, sous la forme d'éléments tels que les intents, les autorisations et les 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 "soft" et les comportements système requis pour la compatibilité avec Android 2.1. Les implémentations d'appareils DOIVENT répondre à 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, 5]. 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 sur la classe android.os.Build [Resources, 6] 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
android.os.Build.VERSION.RELEASE Version du système Android actuellement en cours d'exécution, au format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans [Ressources, 7].
android.os.Build.VERSION.SDK Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 2.1, ce champ DOIT avoir la valeur entière 7.
android.os.Build.VERSION.INCREMENTAL 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érents builds envoyés aux utilisateurs finaux. L'utilisation typique de ce champ consiste à 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 concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
android.os.Build.BOARD 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. Ce champ peut être utilisé pour 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, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
android.os.Build.BRAND Valeur choisie par l'implémentateur de l'appareil pour identifier le nom de l'entreprise, de l'organisation, de l'individu, 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 concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").
android.os.Build.DEVICE Valeur choisie par l'implémentateur de l'appareil pour identifier la configuration ou la révision spécifique du corps (parfois appelé "conception industrielle") de l'appareil. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
android.os.Build.FINGERPRINT Chaîne qui identifie de manière unique ce build. Il DOIT être raisonnablement lisible par l'humain. Il DOIT suivre ce modèle :
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Par exemple :
acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys
L'empreinte 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 de soulignement ("_") dans l'empreinte.
android.os.Build.HOST Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'homme. 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 ("").
android.os.Build.ID Identifiant choisi par l'implémentateur de l'appareil pour faire référence à une version spécifique, au format lisible par l'humain. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent distinguer les builds logiciels. 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 ("").
android.os.Build.MODEL Valeur choisie par l'implémentateur de l'appareil contenant le nom de l'appareil tel que connu par l'utilisateur final. Il DOIT s'agir du même nom que celui sous lequel l'appareil est commercialisé et vendu aux 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 contenir la chaîne vide ("").
android.os.Build.PRODUCT 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 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 contenir la chaîne vide ("").
android.os.Build.TAGS Liste de tags choisis par l'implémentateur de l'appareil, séparés par une virgule, qui permet de distinguer davantage le build. Par exemple, "unsigned,debug". Ce champ NE DOIT PAS être nul ni la 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.
android.os.Build.TYPE 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 correspondant aux trois configurations d'exécution Android typiques: "user", "userdebug" ou "eng".
android.os.Build.USER Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatique) qui a généré le build. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni 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és par les implémentations d'appareils. Par "respecté", on entend que l'implémentateur de l'appareil DOIT fournir une activité ou un service Android qui spécifie un filtre d'intent correspondant, et qui se lie à chaque modèle d'intent spécifié et implémente le comportement correct.

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 d'adresses, un lecteur de musique, etc. Les implémentateurs d'appareils PEUVENT remplacer ces applications par d'autres versions.

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 applications suivantes sont considérées comme des applications système Android principales:

  • Horloge de bureau
  • Navigateur
  • Agenda
  • Calculatrice
  • Appareil photo
  • Contacts
  • Adresse e-mail
  • Galerie
  • GlobalSearch
  • Lanceur d'applications
  • LivePicker (c'est-à-dire l'application de sélection de fonds d'écran animés) : PEUT être omis si l'appareil n'est pas compatible avec les fonds d'écran animés, conformément à la section 3.8.5.
  • Messagerie (également appelée "MMS")
  • Musique
  • Téléphone
  • Paramètres
  • Magnétophone

Les applications système Android de base incluent divers composants Activity ou Service considérés comme "publics". Autrement dit, l'attribut "android:exported" peut être absent ou avoir la valeur "true".

Pour chaque activité ou service définie dans l'une des applications système Android principales qui n'est pas marquée comme non publique via un attribut android:exported avec la valeur "false", les implémentations d'appareil DOIVENT inclure un composant du même type implémentant les mêmes modèles de filtre d'intent que l'application système Android principale.

En d'autres termes, une implémentation d'appareil PEUT remplacer les applications système Android principales. Toutefois, si elle le fait, l'implémentation de l'appareil DOIT prendre en charge tous les modèles d'intent définis par chaque application système Android principale remplacée.

3.2.3.2. Forçages d'intents

Comme Android est une plate-forme extensible, les implémentateurs d'appareils DOIVENT autoriser chaque modèle d'intent défini dans les applications système principales à ê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, mais sans s'y limiter, 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.

Remarque: Cette section a été modifiée par l'Erratum EX6580.

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 composants Android qui respectent de nouveaux modèles d'intent ou de broadcast intent à 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 utilisés par les applications principales listées dans la section 3.2.3.1.

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 compatibles avec Android DOIVENT diffuser les intents de diffusion publique en réponse aux événements système appropriés. Les intents de diffusion sont décrits dans la documentation du SDK.

3.3. Compatibilité avec les 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 .so ELF compilé pour l'architecture matérielle de l'appareil appropriée. Les implémentations d'appareils DOIVENT prendre en charge le code exécuté dans l'environnement géré pour appeler le code natif, à l'aide de la sémantique standard de 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++
  • Prise en charge d'OpenGL, comme décrit ci-dessous

Les implémentations d'appareils DOIVENT être compatibles avec OpenGL ES 1.0. Les appareils qui ne disposent pas d'accélération matérielle DOIVENT implémenter OpenGL ES 1.0 à l'aide d'un moteur de rendu logiciel. Les implémentations d'appareils DOIVENT implémenter autant d'OpenGL ES 1.1 que le matériel de l'appareil le permet. Les implémentations d'appareils DOIVENT fournir une implémentation pour OpenGL ES 2.0, si le matériel est capable de fournir des performances raisonnables sur ces API.

Ces bibliothèques DOIVENT être compatibles avec le code source (c'est-à-dire avec l'en-tête) et avec le code 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 C GNU, 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é de l'en-tête, du binaire et du comportement.

Les implémentations d'appareils DOIVENT signaler avec précision l'interface binaire d'application (ABI) native compatible avec l'appareil, via l'API android.os.Build.CPU_ABI. L'ABI DOIT être l'une des entrées documentées dans la dernière version du NDK Android, dans le fichier docs/CPU-ARCH-ABIS.txt. Notez que d'autres versions du NDK Android peuvent prendre en charge d'autres ABI.

La compatibilité du code natif est difficile. C'est pourquoi nous tenons à rappeler que les implémentateurs d'appareils sont TRÈS fortement 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 [Resources, 8] pour leurs interfaces utilisateur. L'implémentation de WebView doit donc être compatible avec les implémentations Android. L'implémentation Open Source Android utilise le 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 spécifiquement :

  • WebView DOIT utiliser le build WebKit 530.17 de l'arborescence Open Source Android en amont pour Android 2.1. 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 être au format suivant:
    Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
    • La valeur de la chaîne $(VERSION) DOIT être identique à celle de android.os.Build.VERSION.RELEASE.
    • La valeur de la chaîne $(LOCALE) DOIT respecter les conventions ISO pour le code pays et la langue, et DOIT faire référence aux paramètres régionaux configurés actuellement sur l'appareil.
    • La valeur de la chaîne $(MODEL) DOIT être identique à celle de android.os.Build.MODEL.
    • La valeur de la chaîne $(BUILD) DOIT être identique à celle de android.os.Build.ID.

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.

La configuration de WebView DOIT prendre en charge la base de données HTML5, le cache d'application et les API de géolocalisation [Ressources, 9]. La WebView DOIT inclure la compatibilité avec la balise HTML5 <video> sous une forme ou une autre. L'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers) DOIT être compatible avec les mêmes fonctionnalités HTML5 que celles listées pour WebView.

3.5. Compatibilité du comportement des API

Les comportements de chacun des types d'API (gérés, souples, natifs et Web) doivent être cohérents avec l'implémentation privilégiée du projet Open Source Android en amont [Ressources, 3]. 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. Il incombe aux implémentateurs de l'appareil 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) teste des parties importantes de la plate-forme pour vérifier sa compatibilité comportementale, mais pas toutes. Il est de la responsabilité de 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 apporter de modifications interdites (voir ci-dessous) à ces espaces de noms de packages:

  • java.*
  • javax.*
  • sun.*
  • android.*
  • com.android.*

Les modifications interdites incluent les suivantes:

  • Les implémentations d'appareils NE DOIVENT PAS modifier les API publiques exposées sur la plate-forme Android en modifiant les signatures de méthode ou de classe, ni 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 effectuer 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 disponibles sur 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é des machines virtuelles

Les implémentations d'appareils DOIVENT prendre en charge la spécification complète du bytecode Dalvik Executable (DEX) et la sémantique de la machine virtuelle Dalvik [Resources, 10].

Les implémentations d'appareils DOIVENT configurer Dalvik pour qu'il alloue au moins 16 Mo de mémoire à chaque application sur les appareils dont les écrans sont classés comme à densité moyenne ou faible. Les implémentations d'appareils DOIVENT configurer Dalvik pour qu'il alloue au moins 24 Mo de mémoire à chaque application sur les appareils dont les écrans sont classés comme haute densité. Notez que les implémentations d'appareils PEUVENT allouer plus de mémoire que ces chiffres, mais elles ne sont pas tenues de le faire.

3.8. Compatibilité de l'interface utilisateur

La plate-forme Android inclut certaines API pour les développeurs qui leur permettent 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'elles 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, 11]. 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 permettant d'ajouter, de configurer, d'afficher et de 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, de configurer, d'afficher et de supprimer des AppWidgets.

3.8.2. Notifications

Android inclut des API qui permettent aux développeurs d'avertir les utilisateurs d'événements notables [Resources, 12]. 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.) fournies dans les API [Ressources, 13] ou dans le guide de style des icônes de la barre d'état [Ressources, 14]. Les implémentateurs d'appareils PEUVENT proposer une expérience utilisateur alternative pour les notifications que celle fournie par l'implémentation Open Source Android de référence. Toutefois, ces systèmes de notification alternatifs DOIVENT prendre en charge les ressources de notification existantes, comme indiqué ci-dessus.

Android inclut des API [Ressources, 15] 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 au fur et à mesure de la saisie 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 proposer 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 utilisant cette fonctionnalité n'est installée, 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. Notifications toast

Les applications peuvent utiliser l'API "Toast" (définie dans [Resources, 16]) pour afficher de courtes chaînes non modales à l'utilisateur final, qui disparaissent après un bref laps de temps. Les implémentations d'appareils DOIVENT afficher les toasts des applications aux utilisateurs finaux de manière très visible.

3.8.5. Fonds d'écran animés

Android définit un type de composant, ainsi qu'une API et un cycle de vie correspondants, qui permettent aux applications d'exposer un ou plusieurs "fonds d'écran animés" à l'utilisateur final [Resources, 17]. Les fonds d'écran animés sont des animations, des motifs ou des images similaires avec des fonctionnalités de saisie limitées qui s'affichent en tant que fond d'écran, derrière d'autres applications.

Le matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à un débit d'images raisonnable et sans effet négatif sur d'autres applications. Si des limites matérielles provoquent le plantage et/ou le dysfonctionnement des fonds d'écran et/ou des applications, ou qu'elles consomment une puissance de processeur ou de batterie excessive, ou qu'elles s'exécutent à des fréquences d'images inacceptablement faibles, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte Open GL 1.0 ou 2.0 pour afficher leur contenu. Le fond d'écran animé ne s'exécute pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

Les implémentations d'appareils capables d'exécuter des fonds d'écran animés de manière fiable, comme décrit ci-dessus, DOIVENT implémenter des fonds d'écran animés. Les implémentations d'appareils déterminées à ne pas exécuter de fonds d'écran animés de manière fiable, comme décrit ci-dessus, NE DOIVENT PAS implémenter de fonds d'écran animés.

4. Compatibilité des logiciels 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 (inclus dans le SDK)
  • Lunar Lander (inclus dans le SDK)
  • Les applications "Applications pour Android" [Ressources, 18].

Chaque application ci-dessus DOIT se lancer et se comporter correctement dans l'implémentation pour que l'implémentation soit considérée comme compatible.

De plus, les implémentations d'appareils DOIVENT tester chaque élément de menu (y compris tous les sous-menus) de chacune de ces applications de test:

  • ApiDemos (inclus dans le SDK)
  • ManualSmokeTests (inclus dans CTS)

Chaque scénario de test des applications ci-dessus DOIT s'exécuter correctement sur l'implémentation de l'appareil.

5. Compatibilité du packaging 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, 19].

Les implémentations d'appareils NE DOIVENT PAS étendre les formats .apk [Resources, 20], Android Manifest [Resources, 21] ou bytecode Dalvik [Resources, 10] de manière à empêcher l'installation et l'exécution correctes 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

Les implémentations d'appareils DOIVENT prendre en charge les codecs multimédias suivants. Tous ces codecs sont fournis en tant qu'implémentations logicielles dans l'implémentation Android préférée du projet Android Open Source.

Veuillez noter que ni Google ni l'Open Handset Alliance ne font aucune déclaration selon laquelle 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 des sharewares, peuvent nécessiter des licences de brevets de la part des titulaires de brevets concernés.

Audio
Nom Encodeur Décodeur Détails Format de fichier/conteneur
AAC LC/LTP   X Contenu mono/stéréo avec n'importe quelle combinaison de débits standards jusqu'à 160 kbit/s et de taux d'échantillonnage compris entre 8 et 48 kHz 3GPP (.3gp) et MPEG-4 (.mp4, .m4a) Incompatible avec le format AAC brut (.aac)
HE-AACv1 (AAC+)   X
HE-AACv2 (AAC+ amélioré)   X
AMR-NB X X 4,75 à 12,2 kbit/s échantillonnés à 8 kHz 3GPP (.3gp)
AMR-WB   X 9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz 3GPP (.3gp)
MP3   X Mono/Stéréo 8-320 kbit/s CBR (débit constant) ou VBR (débit variable) MP3 (.mp3)
MIDI   X Types MIDI 0 et 1 Versions 1 et 2 de DLS XMF et Mobile XMF. Compatibilité avec les formats de sonnerie RTTTL/RTX, OTA et iMelody Types 0 et 1 (.mid, .xmf, .mxmf) Également RTTTL/RTX (.rtttl, .rtx), OTA (.ota) et iMelody (.imy)
Ogg Vorbis   X   Ogg (.ogg)
Zone   X PCM linéaire 8 et 16 bits (débits jusqu'à la limite du matériel) WAVE (.wav)
Image
JPEG X X base+progressive  
GIF   X    
PNG X X    
BMP   X    
Vidéo
H.263 X X   Fichiers 3GPP (.3gp)
H.264   X   Fichiers 3GPP (.3gp) et MPEG-4 (.mp4)
Profil MPEG4 simple   X   Fichier 3GPP (.3gp)

Notez que le tableau ci-dessus ne liste pas les exigences de débit spécifiques pour la plupart des codecs vidéo. En effet, en pratique, le matériel des appareils actuels n'est pas nécessairement compatible avec les débits qui correspondent exactement aux débits requis spécifiés par les normes applicables. Au lieu de cela, les implémentations d'appareils DOIVENT prendre en charge le débit le plus élevé possible sur le matériel, dans les limites définies par les spécifications.

7. Compatibilité des outils pour les développeurs

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 Android compatibles DOIVENT être compatibles avec:

  • Android Debug Bridge (connu sous le nom d'adb) [Ressources, 19]
    Les implémentations d'appareils 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 présent pour activer Android Debug Bridge.
  • Dalvik Debug Monitor Service (ddms) [Resources, 19]
    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 chaque fois que l'utilisateur a activé Android Debug Bridge, comme ci-dessus.
  • Monkey [Ressources, 22]
    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 répertorie les fonctionnalités matérielles que tous les appareils compatibles avec Android 2.1 doivent prendre en charge.

Si un appareil inclut un composant matériel particulier qui dispose d'une API correspondante 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. Si une API du SDK interagit avec un composant matériel déclaré comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant:

  • Les définitions de classe pour les API du composant DOIVENT être présentes.
  • Les comportements de l'API DOIVENT être implémentés comme des opérations sans action de manière raisonnable.
  • Les méthodes d'API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK l'autorise.
  • Les méthodes d'API DOIVENT renvoyer des implémentations sans opération de classes pour lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.

L'API Telephony est un exemple typique de scénario où ces exigences s'appliquent: même sur les appareils autres que les téléphones, ces API doivent être implémentées en tant que no-ops raisonnables.

Les implémentations d'appareils DOIVENT fournir des informations de configuration matérielle précises via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager.

8.1. Écran

Android 2.1 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 s'exécutent de manière raisonnable sur diverses configurations matérielles [Resources, 23]. Les appareils DOIVENT implémenter correctement ces comportements, comme indiqué dans cette section.

Pour Android 2.1, voici les configurations d'affichage les plus courantes:

Type d'écran Largeur (pixels) Hauteur (pixels) Plage de longueur diagonale (pouces) Groupe de tailles d'écran Groupe de densité d'écran
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 Moyenne
WVGA 480 800 3.3 à 4.0 Normale Élevée
FWVGA 480 854 3.5 à 4.0 Normale Élevée
WVGA 480 800 4,8 à 5,5 Grande Moyenne
FWVGA 480 854 5.0 - 5.8 Grande Moyenne

Les implémentations d'appareils correspondant à l'une des configurations standards ci-dessus DOIVENT être configurées pour signaler la taille d'écran indiquée aux applications via la classe android.content.res.Configuration [Resources, 24].

Certains packages .apk contiennent des fichiers manifestes qui ne les identifient pas comme compatibles avec une plage de densité spécifique. Lorsque vous exécutez de telles applications, les contraintes suivantes s'appliquent:

  • Les implémentations d'appareils DOIVENT interpréter les ressources d'un fichier .apk qui ne comportent pas de qualificatif de densité comme "medium" (connu sous le nom de "mdpi" dans la documentation du SDK).
  • Lorsque l'appareil fonctionne sur un écran à faible densité, les implémentations de l'appareil DOIVENT réduire les éléments de taille moyenne/mdpi d'un facteur de 0,75.
  • Lorsque l'appareil fonctionne sur un écran "haute" densité, les implémentations de l'appareil DOIVENT mettre à l'échelle les éléments de taille moyenne/mdpi d'un facteur de 1,5.
  • Les implémentations d'appareils NE DOIVENT PAS mettre à l'échelle les éléments au sein d'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 pas à l'une des configurations standards listées dans la section 8.1.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 2.1. 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 sur le Réseau Display

Les implémentations d'appareils DOIVENT indiquer les valeurs correctes pour toutes les métriques d'affichage définies dans android.util.DisplayMetrics [Ressources, 25].

8.2. Clavier

Implémentations de l'appareil:

  • DOIT inclure la prise en charge du 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
  • Vous devez fournir au moins une implémentation de clavier virtuel (que vous disposiez ou non d'un clavier physique).
  • PEUT inclure des implémentations de clavier virtuel supplémentaires
  • POURRA inclure un clavier physique
  • NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard [Ressources, 24] (c'est-à-dire QWERTY ou 12 touches)

8.3. Navigation non tactile

Implémentations de l'appareil:

  • PEUT omettre des options de navigation non tactile (par exemple, un trackball, un pavé directionnel ou une roue)
  • DOIT indiquer la valeur correcte pour android.content.res.Configuration.navigation [Resources, 24]

8.4. Orientation de l'écran

Les appareils compatibles DOIVENT prendre en charge l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la demande 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 pression tactile

Implémentations de l'appareil:

  • Doit être équipé d'un écran tactile
  • PEUT être équipé d'un écran tactile capacitif ou résistif
  • DOIT indiquer la valeur de android.content.res.Configuration [Resources, 24] correspondant au type de l'écran tactile spécifique de l'appareil

8.6. USB

Implémentations de l'appareil:

  • DOIT implémenter un client USB, connectable à un hôte USB via un port USB-A standard
  • DOIT implémenter Android Debug Bridge via USB (comme décrit dans la section 7)
  • DOIT implémenter la spécification de stockage de masse USB pour permettre à un hôte connecté à l'appareil d'accéder au contenu du volume /sdcard
  • DOIT utiliser le facteur de forme micro USB sur le côté de l'appareil
  • PEUT inclure un port non standard côté appareil, mais si tel est le cas, DOIT être fourni avec un câble permettant de connecter la sortie de broches personnalisée 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 d'appareils 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. Mise en réseau de données sans fil

Les implémentations d'appareils DOIVENT prendre en charge les réseaux de données haut débit sans fil. Plus précisément, les implémentations d'appareils DOIVENT prendre en charge au moins une norme de données sans fil capable de transmettre 200 kbit/s ou plus. EDGE, HSPA, EV-DO, 802.11g, etc. sont des exemples de technologies qui répondent à cette exigence.

Si une implémentation d'appareil inclut une modalité particulière pour laquelle le SDK Android inclut une API (par exemple, Wi-Fi, GSM ou CDMA), l'implémentation DOIT prendre en charge l'API.

Les appareils PEUVENT implémenter plusieurs types de connectivité de données sans fil. Les appareils PEUVENT implémenter une connectivité de données filaire (telle qu'Ethernet), mais DOIVENT néanmoins inclure au moins une forme de connectivité sans fil, comme indiqué ci-dessus.

8.9. Appareil photo

Les implémentations d'appareils DOIVENT inclure une caméra. La caméra incluse:

  • Doit avoir une résolution d'au moins 2 mégapixels
  • Le pilote de l'appareil photo DOIT implémenter la mise au point automatique matérielle ou logicielle (transparente pour le logiciel d'application).
  • POURRAIENT être équipés d'un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF)
  • POURRA 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, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application d'appareil photo système intégrée de l'appareil, mais uniquement aux applications tierces qui utilisent Camera.PreviewCallback.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra:

  1. Si une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int), 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.) Autrement dit, NV21 DOIT être la valeur par défaut.

Les implémentations d'appareils DOIVENT implémenter l'API Camera complète incluse dans la documentation du SDK Android 2.1 [Ressources, 26], que l'appareil inclue ou non un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo qui ne disposent pas d'autofocus DOIVENT toujours appeler les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucune pertinence pour un appareil photo sans autofocus).

Les implémentations d'appareils DOIVENT reconnaître et respecter chaque nom de paramètre défini en tant que constante sur la classe android.hardware.Camera.Parameters, si le matériel sous-jacent est compatible avec la fonctionnalité. Si le matériel de l'appareil n'est pas compatible avec une fonctionnalité, l'API doit se comporter comme indiqué dans la documentation. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters(), sauf celles documentées en tant que constantes sur android.hardware.Camera.Parameters, sauf si les constantes sont précédées d'une chaîne indiquant le nom de l'implémentateur de l'appareil. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres de caméra standards si le matériel le permet et NE DOIVENT PAS prendre en charge les types de paramètres de caméra personnalisés, sauf si les noms de paramètres sont clairement indiqués par un préfixe de chaîne comme étant non standards.

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 à 50 Hz ou plus. 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 les API Android (voir [Ressources, 27]).

8.11. Boussole

Les implémentations d'appareils DOIVENT inclure une boussole à trois axes et DOIVENT pouvoir générer des événements à 10 Hz ou plus. 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 (voir [Ressources, 27]).

8.12. GPS

Les implémentations d'appareils DOIVENT inclure un GPS et DEVRAIENT inclure une forme de technique "GPS assisté" pour réduire le temps de verrouillage du GPS.

8.13. Téléphonie

Android 2.1 peut être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android 2.1 est compatible avec les appareils autres que les téléphones. Toutefois, si l'implémentation d'un appareil inclut la téléphonie GSM ou CDMA, elle DOIT implémenter la prise en charge complète de l'API pour cette technologie. Les implémentations d'appareils qui n'incluent pas de matériel de téléphonie DOIVENT implémenter les API complètes en tant que no-ops.

Consultez également la section 8.8, "Mise en réseau de données sans fil".

8.14. Mémoire et stockage

Les implémentations d'appareils DOIVENT disposer d'au moins 92 Mo de mémoire disponible pour le noyau et l'espace utilisateur. Les 92 Mo doivent s'ajouter à toute mémoire dédiée aux composants matériels tels que la radio, la mémoire, etc. qui ne sont pas sous le contrôle du noyau.

Les implémentations d'appareils DOIVENT disposer d'au moins 150 Mo de stockage non volatile disponible pour les données utilisateur. Autrement dit, la partition /data doit être d'au moins 150 Mo.

Remarque: Cette section a été modifiée par l'Erratum EX6580.

8.15. Stockage partagé de l'application

Les implémentations d'appareils DOIVENT proposer un espace de stockage partagé pour les applications. L'espace de stockage partagé fourni doit être d'au moins 2 Go.

Les implémentations d'appareils DOIVENT être configurées avec un stockage partagé installé par défaut. Si le stockage partagé n'est pas installé sur le chemin d'accès Linux /sdcard, l'appareil DOIT inclure un lien symbolique Linux de /sdcard au point d'installation réel.

Les implémentations d'appareils DOIVENT appliquer l'autorisation android.permission.WRITE_EXTERNAL_STORAGE sur ce stockage partagé, comme indiqué dans la documentation. Sinon, le stockage partagé DOIT être accessible en écriture par toute application qui obtient cette autorisation.

Les implémentations d'appareils PEUVENT comporter du matériel pour le stockage amovible accessible par l'utilisateur, comme une carte Secure Digital. Les implémentations d'appareils peuvent également allouer de l'espace de stockage interne (non amovible) en tant qu'espace de stockage partagé pour les applications.

Quel que soit le type de stockage partagé utilisé, le stockage partagé DOIT implémenter le stockage de masse USB, comme décrit dans la section 8.6. Comme il est livré, l'espace de stockage partagé DOIT être installé avec le système de fichiers FAT.

Prenons deux exemples courants pour illustrer ce point. Si l'implémentation d'un appareil inclut un emplacement pour carte SD pour répondre à l'exigence de stockage partagé, une carte SD au format FAT de 2 Go ou plus DOIT être incluse avec l'appareil tel qu'il est vendu aux utilisateurs et DOIT être montée par défaut. Si une implémentation d'appareil utilise un stockage fixe interne pour répondre à cette exigence, ce stockage DOIT avoir une taille d'au moins 2 Go et être installé sur /sdcard (ou /sdcard DOIT être un lien symbolique vers l'emplacement physique s'il est installé ailleurs).

Remarque: Cette section a été ajoutée par l'Erratum EX6580.

8.16. Bluetooth

Les implémentations d'appareils DOIVENT inclure un émetteur-récepteur Bluetooth. Les implémentations d'appareils DOIVENT activer l'API Bluetooth basée sur RFCOMM, comme décrit dans la documentation du SDK [Ressources, 29]. Les implémentations d'appareils DOIVENT implémenter les profils Bluetooth pertinents, tels que A2DP, AVRCP, OBEX, etc., en fonction de l'appareil.

Remarque: Cette section a été ajoutée par l'Erratum EX6580.

9. Compatibilité des performances

L'un des objectifs du programme de compatibilité Android est de proposer une expérience d'application cohérente aux 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 2.1 définies dans le tableau ci-dessous:

Métrique Seuil de performances Commentaires
Heure de lancement de l'application Les applications suivantes doivent être lancées dans le délai spécifié.
  • Navigateur: moins de 1 300 ms
  • MMS/SMS: moins de 700 ms
  • AlarmClock: moins de 650 ms
 Le temps de lancement correspond au temps total nécessaire pour charger l'activité par défaut de l'application, y compris le temps nécessaire pour démarrer le processus Linux, charger le package Android dans la VM Dalvik et appeler onCreate.
Applications simultanées Lorsque plusieurs applications ont été lancées, le temps de relance d'une application déjà en cours d'exécution doit être inférieur au temps de lancement initial.  

10. Compatibilité des modèles 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 [Ressources, 28] de 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é décrits dans les sous-sections suivantes.

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 destinée aux développeurs Android [Ressources, 28]. 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 se trouvent pas dans l'espace de noms android.*.

10.2. UID et isolation 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 construites, comme défini dans la référence sur la sécurité et les autorisations [Ressources, 28].

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 [Ressources, 28].

11. Compatibility Test Suite

Les implémentations d'appareils DOIVENT réussir les tests de la suite de compatibilité Android (CTS) [Ressources, 2] 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 le CTS et pour toute réimplémentation de 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 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 2.1. Les implémentations d'appareils DOIVENT réussir les tests de la dernière version du CTS disponible au moment où le logiciel de l'appareil est finalisé.

12. Logiciels pouvant être mis à jour

Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer de mises à niveau "en direct". Autrement dit, un redémarrage de l'appareil peut être nécessaire.

N'importe quelle méthode peut être utilisée, à condition qu'elle puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes répond à cette exigence:

  • Téléchargements Over The Air (OTA) avec mise à jour hors connexion via le redémarrage
  • Mises à jour "partagée" via USB à partir d'un PC hôte
  • Mises à jour "hors connexion" via un redémarrage et une mise à jour à partir d'un fichier sur un espace de stockage amovible

Le mécanisme de mise à jour utilisé DOIT être compatible avec les mises à jour sans effacer les données utilisateur. Notez que le logiciel Android en amont inclut un mécanisme de mise à jour qui répond à cette exigence.

Si une erreur est détectée dans l'implémentation d'un appareil après sa sortie, mais dans la durée de vie raisonnable du produit déterminée en consultation avec l'équipe de compatibilité Android, et qu'elle affecte la compatibilité des applications tierces, l'implémentateur de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée conformément au mécanisme décrit ci-dessus.

13. Nous contacter

Vous pouvez contacter les auteurs du document à l'adresse compatibility@android.com pour obtenir des précisions et signaler les problèmes que vous pensez ne pas être couverts par le document.