Définition de la compatibilité avec Android 2.2

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

Sommaire

1. Introduction
2. Ressources
3. Logiciel
4. Compatibilité des logiciels de référence
5. Compatibilité du packaging d'applications
6. Compatibilité multimédia
7. Compatibilité des outils pour les développeurs
8. Compatibilité matérielle
9. Compatibilité des performances
10. Compatibilité des modèles de sécurité
11. Compatibility Test Suite
12. Logiciels pouvant être mis à jour
13. Nous contacter
Annexe A : Procédure de test Bluetooth

1. Introduction

Ce document énonce les exigences à respecter pour que les téléphones mobiles soient compatibles avec Android 2.2.

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.2. 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.2, 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 norme IETF RFC 2119: http://www.ietf.org/rfc/rfc2119.txt
  2. Présentation du programme de compatibilité Android: http://source.android.com/docs/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. Documentation de référence sur les autorisations Android: http://developer.android.com/reference/android/Manifest.permission.html
  6. Documentation de référence sur android.os.Build: http://developer.android.com/reference/android/os/Build.html
  7. Chaînes de version autorisées pour Android 2.2: http://source.android.com/docs/compatibility/2.2/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. Liste des fonctionnalités matérielles Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
  24. Compatibilité avec plusieurs écrans: http://developer.android.com/guide/practices/screens_support.html
  25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  27. android.hardware.Camera: 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
  30. 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.2 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.2 [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.2. 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.2, ce champ DOIT avoir la valeur entière 8.
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 les différents builds mis à la disposition des 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.2/ERC77/3359:userdebug/test-keys
L'empreinte ne DOIT PAS inclure de caractères d'espace. Si d'autres champs inclus dans le modèle ci-dessus contiennent des caractères d'espacement, ils DOIVENT être remplacés dans l'empreinte de compilation par un autre caractère, tel que le trait de soulignement ("_").
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 référencé dans la section 3.2.3.1 à ê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.

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 rappelons 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é 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. De même, une expérience Web complète est au cœur de l'expérience utilisateur Android. Les implémentations d'appareils DOIVENT inclure une version de android.webkit.WebView compatible avec le logiciel Android en amont et DOIVENT inclure un navigateur moderne compatible avec HTML5, comme décrit ci-dessous.

3.4.1. Compatibilité avec WebView

L'implémentation Open Source d'Android utilise le moteur de rendu WebKit pour implémenter android.webkit.WebView. Étant donné qu'il n'est pas possible de développer une suite de tests complète pour un système de rendu 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 :

  • Les implémentations android.webkit.WebView des implémentations de l'appareil DOIVENT être basées sur le build WebKit 533.1 de l'arborescence Open Source Android en amont pour Android 2.2. Cette version inclut un ensemble spécifique de fonctionnalités et de correctifs de sécurité pour WebView. Les implémentateurs d'appareils PEUVENT inclure des personnalisations dans l'implémentation WebKit. Toutefois, ces personnalisations NE DOIVENT PAS modifier le comportement de la WebView, y compris le comportement de rendu.
  • 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/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
    • 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.

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 être compatible avec la balise HTML5 <video>. Les API HTML5, comme toutes les API JavaScript, DOIVENT être désactivées par défaut dans une WebView, sauf si le développeur les active explicitement via les API Android habituelles.

3.4.2. Compatibilité avec les navigateurs

Les implémentations d'appareils DOIVENT inclure une application de navigateur autonome pour la navigation Web des utilisateurs. Le navigateur autonome PEUT être basé sur une technologie de navigateur autre que WebKit. Toutefois, même si une autre application de navigateur est fournie, le composant android.webkit.WebView fourni aux applications tierces DOIT être basé sur WebKit, comme décrit dans la section 3.4.1.

Les implémentations PEUVENT fournir une chaîne user-agent personnalisée dans l'application de navigateur autonome.

L'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers) DOIT prendre en charge autant que possible HTML5 [Ressources, 9]. Les implémentations d'appareils doivent au minimum prendre en charge la géolocalisation HTML5, le cache d'application et les API de base de données, ainsi que la balise <video> dans l'application du navigateur autonome.

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 dont les écrans sont classés comme à densité moyenne ou faible DOIVENT configurer Dalvik pour qu'il alloue au moins 16 Mo de mémoire à chaque application. Les implémentations d'appareils avec des écrans classés comme haute densité DOIVENT configurer Dalvik pour allouer au moins 24 Mo de mémoire à chaque application. Notez que les implémentations d'appareils peuvent allouer plus de mémoire que ces chiffres.

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].
  • Replica Island (disponible sur Android Market ; uniquement requis pour les implémentations d'appareils compatibles avec OpenGL ES 2.0)

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 implémenter toutes les API multimédias. Les implémentations d'appareils DOIVENT prendre en charge tous les codecs multimédias décrits ci-dessous et DOIVENT respecter les consignes de traitement du son décrites ci-dessous.

6.1. Codecs multimédias

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.

6.2. Enregistrement audio

Lorsqu'une application a utilisé l'API android.media.AudioRecord pour commencer à enregistrer un flux audio, les implémentations d'appareils DOIVENT échantillonner et enregistrer l'audio avec chacun de ces comportements:

  • Le traitement de réduction du bruit, le cas échéant, DOIT être désactivé.
  • Le contrôle automatique du gain, le cas échéant, DOIT être désactivé.
  • L'appareil DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près plates, en particulier ±3 dB, de 100 Hz à 4 000 Hz.
  • La sensibilité d'entrée audio DOIT être définie de sorte qu'une source de niveau de puissance acoustique (SPL) de 90 dB à 1 000 Hz génère une valeur efficace de 5 000 pour les échantillons 16 bits.
  • Les niveaux d'amplitude PCM DOIVENT suivre de manière linéaire les variations de SPL d'entrée sur une plage d'au moins 30 dB, allant de -18 dB à +12 dB par rapport à 90 dB SPL au niveau du micro.
  • La distorsion harmonique totale DOIT être inférieure à 1% de 100 Hz à 4 000 Hz pour un niveau d'entrée de 90 dB SPL.

Remarque:Bien que les exigences décrites ci-dessus soient indiquées comme "DEVRAIENT" pour Android 2.2, la définition de compatibilité d'une future version prévoit de les remplacer par "DOIT". Autrement dit, ces exigences sont facultatives dans Android 2.2, mais elles seront obligatoires dans une prochaine version. Les appareils existants et nouveaux exécutant Android 2.2 sont très fortement encouragés à respecter ces exigences dans Android 2.2, sans quoi ils ne pourront pas atteindre la compatibilité Android lors de la mise à niveau vers la future version.

6.3. Latence audio

La latence audio est généralement définie comme l'intervalle entre le moment où une application demande une opération de lecture ou d'enregistrement audio et le moment où l'implémentation de l'appareil commence réellement l'opération. De nombreuses classes d'applications s'appuient sur des latences courtes pour obtenir des effets en temps réel, tels que des effets sonores ou une communication VoIP. Les implémentations d'appareils DOIVENT répondre à toutes les exigences de latence audio décrites dans cette section.

Aux fins de cette section:

  • La "latence de sortie à froid" est définie comme l'intervalle entre le moment où une application demande la lecture audio et le moment où le son commence à être diffusé, lorsque le système audio était inactif et éteint avant la requête.
  • La "latence de sortie à chaud" est définie comme l'intervalle entre le moment où une application demande la lecture audio et le moment où le son commence à être diffusé, lorsque le système audio a été utilisé récemment, mais qu'il est actuellement inactif (c'est-à-dire silencieux).
  • La "latence de sortie continue" est définie comme l'intervalle entre le moment où une application émet un échantillon à lire et le moment où le haut-parleur lit physiquement le son correspondant, lorsque l'appareil lit actuellement de l'audio.
  • La "latence d'entrée à froid" est définie comme l'intervalle entre le moment où une application demande l'enregistrement audio et le moment où le premier échantillon est envoyé à l'application via son rappel, lorsque le système audio et le micro étaient inactifs et éteints avant la requête.
  • La "latence d'entrée continue" est définie comme étant le moment où un son ambiant se produit et où l'échantillon correspondant à ce son est envoyé à une application d'enregistrement via son rappel, lorsque l'appareil est en mode enregistrement.

En utilisant les définitions ci-dessus, les implémentations d'appareils DOIVENT présenter chacune de ces propriétés:

  • Latence de sortie à froid de 100 millisecondes ou moins
  • Latence de sortie à chaud de 10 millisecondes ou moins
  • une latence de sortie continue de 45 millisecondes ou moins
  • une latence d'entrée à froid de 100 millisecondes ou moins
  • une latence d'entrée continue de 50 millisecondes ou moins ;

Remarque:Bien que les exigences décrites ci-dessus soient indiquées comme "DOIT" pour Android 2.2, la définition de compatibilité d'une future version prévoit de les remplacer par "DOIT". Autrement dit, ces exigences sont facultatives dans Android 2.2, mais elles seront obligatoires dans une prochaine version. Les appareils existants et nouveaux exécutant Android 2.2 sont très fortement encouragés à respecter ces exigences dans Android 2.2, sans quoi ils ne pourront pas atteindre la compatibilité Android lors de la mise à niveau vers la future version.

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 liste les fonctionnalités matérielles que tous les appareils compatibles avec Android 2.2 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. [Ressources, 23]

8.1. Écran

Android 2.2 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 correctement sur diverses configurations matérielles [Resources, 24]. Les appareils DOIVENT implémenter correctement ces comportements, comme indiqué dans cette section.

Pour Android 2.2, 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 décrit dans la section 13 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.2. 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, 26].

8.1.4. Compatibilité d'écran déclarée

Les applications peuvent indiquer les tailles d'écran qu'elles acceptent via l'attribut <supports-screens> dans le fichier AndroidManifest.xml. Les implémentations d'appareils DOIVENT respecter correctement la compatibilité déclarée des applications pour les petits, moyens et grands écrans, comme décrit dans la documentation du SDK Android.

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, 25] (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 [Ressources, 25]

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, 25] correspondant au type de l'écran tactile spécifique de l'appareil
  • DOIT prendre en charge les pointeurs entièrement suivis de manière indépendante, si l'écran tactile est compatible avec plusieurs pointeurs

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
  • DOIT 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 à partir d'un PC hôte)

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 arrière. La caméra arrière 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.2 [Ressources, 27], 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 de l'appareil NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters(), à l'exception de celles documentées en tant que constantes sur android.hardware.Camera.Parameters. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres d'appareil photo standards si le matériel le permet, et NE DOIVENT PAS prendre en charge les types de paramètres d'appareil photo personnalisés.

Les implémentations d'appareils PEUVENT inclure une caméra avant. Toutefois, si une implémentation d'appareil inclut une caméra avant, l'API de la caméra telle qu'implémentée sur l'appareil NE DOIT PAS utiliser la caméra avant par défaut. Autrement dit, l'API de l'appareil photo dans Android 2.2 est réservée aux caméras arrière uniquement, et les implémentations d'appareils NE DOIVENT PAS réutiliser ni surcharger l'API pour agir sur une caméra avant, le cas échéant. Notez que toutes les API personnalisées ajoutées par les implémentateurs d'appareils pour prendre en charge les caméras avant DOIVENT respecter les sections 3.5 et 3.6. Par exemple, si une sous-classe android.hardware.Camera ou Camera.Parameters personnalisée est fournie pour prendre en charge les caméras avant, elle NE DOIT PAS se trouver dans un espace de noms existant, comme décrit dans les sections 3.5 et 3.6. Notez que l'inclusion d'une caméra avant ne répond pas à l'exigence selon laquelle les appareils doivent inclure une caméra arrière.

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

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

8.12. GPS

Les implémentations d'appareils DOIVENT inclure un récepteur 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.2 peut être utilisé sur les appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android 2.2 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.

En plus des exigences ci-dessus, les implémentations d'appareils DOIVENT disposer d'au moins 128 Mo de mémoire disponible pour le noyau et l'espace utilisateur, en plus de toute mémoire dédiée aux composants matériels qui n'est pas sous le contrôle du noyau. Les implémentations d'appareils DOIVENT disposer d'au moins 1 Go d'espace de stockage non volatile disponible pour les données utilisateur. Notez que ces exigences plus élevées devraient devenir des valeurs minimales strictes dans une prochaine version d'Android. Les implémentations d'appareils sont fortement encouragées à respecter ces exigences dès maintenant, sinon elles risquent de ne pas être compatibles avec une future version d'Android.

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, cet espace de stockage DOIT avoir une taille d'au moins 2 Go, être au format FAT et être installé sur /sdcard (ou /sdcard DOIT être un lien symbolique vers l'emplacement physique s'il est installé ailleurs).

Les implémentations d'appareils qui incluent plusieurs chemins d'espace de stockage partagé (par exemple, un emplacement pour carte SD et un espace de stockage interne partagé) DOIVENT modifier les applications principales telles que le scanner multimédia et ContentProvider pour prendre en charge de manière transparente les fichiers placés dans les deux emplacements.

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, 30]. Les implémentations d'appareils DOIVENT implémenter les profils Bluetooth pertinents, tels que A2DP, AVRCP, OBEX, etc., en fonction de l'appareil.

La suite de tests de compatibilité inclut des cas qui couvrent le fonctionnement de base de l'API Bluetooth RFCOMM Android. Toutefois, comme le Bluetooth est un protocole de communication entre les appareils, il ne peut pas être entièrement testé par des tests unitaires exécutés sur un seul appareil. Par conséquent, les implémentations d'appareils DOIVENT également réussir la procédure de test Bluetooth manuelle décrite dans l'annexe A.

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

10.4. Environnements d'exécution alternatifs

Les implémentations d'appareils PEUVENT inclure des environnements d'exécution qui exécutent des applications à l'aide d'un autre logiciel ou d'une autre technologie que la machine virtuelle Dalvik ou le code natif. Toutefois, ces environnements d'exécution alternatifs NE DOIVENT PAS compromettre le modèle de sécurité Android ni la sécurité des applications Android installées, comme décrit dans cette section.

Les environnements d'exécution alternatifs DOIVENT eux-mêmes être des applications Android et respecter le modèle de sécurité Android standard, comme décrit ailleurs dans la section 10.

Les environnements d'exécution alternatifs NE DOIVENT PAS être autorisés à accéder aux ressources protégées par des autorisations non demandées dans le fichier AndroidManifest.xml de l'environnement d'exécution via le mécanisme <uses-permission>.

Les environnements d'exécution alternatifs NE DOIVENT PAS autoriser les applications à utiliser des fonctionnalités protégées par des autorisations Android limitées aux applications système.

Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android. Plus spécifiquement :

  • Les autres environnements d'exécution DOIVENT installer les applications via le PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).
  • Les environnements d'exécution alternatifs PEUVENT fournir un seul bac à sable Android partagé par toutes les applications utilisant l'environnement d'exécution alternatif.
  • Les environnements d'exécution alternatifs et les applications installées à l'aide d'un environnement d'exécution alternatif NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards d'ID utilisateur partagé et de certificat de signature.
  • Les environnements d'exécution alternatifs NE DOIVENT PAS se lancer avec, accorder ni être autorisés à accéder aux bacs à sable correspondant à d'autres applications Android.

Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec, ni être accordés, ni accorder à d'autres applications des droits de super-utilisateur (root) ou de tout autre ID utilisateur.

Les fichiers .apk des environnements d'exécution alternatifs PEUVENT être inclus dans l'image système d'une implémentation d'appareil, mais DOIVENT être signés avec une clé distincte de celle utilisée pour signer les autres applications incluses avec l'implémentation de l'appareil.

Lors de l'installation d'applications, les environnements d'exécution alternatifs DOIVENT obtenir le consentement de l'utilisateur pour les autorisations Android utilisées par l'application. Autrement dit, si une application doit utiliser une ressource d'appareil pour laquelle il existe une autorisation Android correspondante (telle que l'appareil photo, le GPS, etc.), l'environnement d'exécution alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource. Si l'environnement d'exécution n'enregistre pas les fonctionnalités de l'application de cette manière, il DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application à l'aide de cet environnement d'exécution.

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.2. 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.

Annexe A : Procédure de test Bluetooth

La suite de tests de compatibilité inclut des cas qui couvrent le fonctionnement de base de l'API Bluetooth RFCOMM Android. Toutefois, comme le Bluetooth est un protocole de communication entre les appareils, il ne peut pas être entièrement testé par des tests unitaires exécutés sur un seul appareil. Par conséquent, les implémentations d'appareils DOIVENT également réussir la procédure de test Bluetooth manuelle décrite ci-dessous.

La procédure de test est basée sur l'application exemple BluetoothChat incluse dans l'arborescence du projet Open Source Android. La procédure nécessite deux appareils:

  • une implémentation d'appareil candidate exécutant le build logiciel à tester
  • une implémentation d'appareil distincte déjà connue comme étant compatible, et d'un modèle de l'implémentation d'appareil testée, c'est-à-dire une implémentation d'appareil "connue comme étant correcte"

La procédure de test ci-dessous fait référence à ces appareils en tant qu'appareils "candidats" et "connus comme étant en bon état", respectivement.

Configuration et installation

  1. Créez BluetoothChat.apk via "make samples" à partir d'un arbre de code source Android.
  2. Installez BluetoothChat.apk sur l'appareil en bon état.
  3. Installez BluetoothChat.apk sur l'appareil candidat.

Tester la commande Bluetooth par les applications

  1. Lancez BluetoothChat sur l'appareil candidat, alors que le Bluetooth est désactivé.
  2. Vérifiez que l'appareil candidat active le Bluetooth ou invite l'utilisateur à l'activer dans une boîte de dialogue.

Tester l'association et la communication

  1. Lancez l'application Bluetooth Chat sur les deux appareils.
  2. Rendre l'appareil connu détectable dans BluetoothChat (à l'aide du menu).
  3. Sur l'appareil candidat, recherchez des appareils Bluetooth dans BluetoothChat (à l'aide du menu) et associez-le à l'appareil connu.
  4. Envoyez au moins 10 messages depuis chaque appareil et vérifiez que l'autre appareil les reçoit correctement.
  5. Fermez l'application BluetoothChat sur les deux appareils en appuyant sur Accueil.
  6. Désassociez chaque appareil de l'autre à l'aide de l'application Paramètres de l'appareil.

Tester l'association et la communication dans le sens inverse

  1. Lancez l'application Bluetooth Chat sur les deux appareils.
  2. Rendre l'appareil candidat visible dans BluetoothChat (à l'aide du menu).
  3. Sur l'appareil connu comme bon, recherchez des appareils Bluetooth dans BluetoothChat (à l'aide du menu) et associez-le à l'appareil candidat.
  4. Envoyez 10 messages ou plus depuis chaque appareil, et vérifiez que l'autre appareil les reçoit correctement.
  5. Fermez l'application Bluetooth Chat sur les deux appareils en appuyant plusieurs fois sur Retour pour accéder au lanceur d'applications.

Relance de tests

  1. Relancez l'application Bluetooth Chat sur les deux appareils.
  2. Envoyez 10 messages ou plus depuis chaque appareil, et vérifiez que l'autre appareil les reçoit correctement.

Remarque: certains des tests ci-dessus se terminent par l'utilisation de la touche Accueil, et d'autres par la touche Retour. Ces tests ne sont pas redondants et ne sont pas facultatifs. L'objectif est de vérifier que l'API et la pile Bluetooth fonctionnent correctement à la fois lorsque les activités sont arrêtées explicitement (lorsque l'utilisateur appuie sur "Retour", ce qui appelle finish()) et implicitement envoyées en arrière-plan (lorsque l'utilisateur appuie sur "Accueil"). Chaque séquence de test DOIT être effectuée comme décrit.