Définition de la compatibilité avec Android 2.3

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

Sommaire

1. Introduction
2. Ressources
3. Logiciel
4. Compatibilité du packaging des applications
5. Compatibilité multimédia
6. Compatibilité des outils pour les développeurs
7. Compatibilité matérielle
7.1. Écran et graphismes
7.2. Périphériques de saisie
7.3. Capteurs
7.4. Connectivité des données
7.5. Caméras
7.6. Mémoire et stockage
7.7. USB
8. Compatibilité des performances
9. Compatibilité des modèles de sécurité
10. Tests de compatibilité des logiciels
11. Logiciels pouvant être mis à jour
12. 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.3.

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.3. 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.3, les implémentations d'appareils DOIVENT respecter les exigences présentées dans cette définition de compatibilité, y compris les documents incorporés par référence.

Lorsque cette définition ou les tests logiciels décrits dans la section 10 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 dans la mesure du possible 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 logiciels 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 au-delà de la suite de tests de compatibilité. Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par ce document.

Veuillez noter que cette définition de compatibilité est émise pour correspondre à la mise à jour 2.3.3 d'Android, qui correspond au niveau d'API 10. Cette définition remplace la définition de compatibilité pour les versions d'Android 2.3 antérieures à la version 2.3.3. (c'est-à-dire que les versions 2.3.1 et 2.3.2 sont obsolètes.) Les futurs appareils Android compatibles exécutant Android 2.3 DOIVENT être livrés avec la version 2.3.3 ou ultérieure.

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.3: http://source.android.com/docs/compatibility/2.3/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. Fonctionnalités hors connexion HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
  11. Balise vidéo HTML5: http://dev.w3.org/html5/spec/Overview.html#video
  12. API de géolocalisation HTML5/W3C: http://www.w3.org/TR/geolocation-API/
  13. API Webdatabase HTML5/W3C: http://www.w3.org/TR/webdatabase/
  14. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
  15. Spécification de la machine virtuelle Dalvik: disponible dans le code source Android, à l'adresse dalvik/docs
  16. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  17. Notifications: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  18. Ressources d'application: http://code.google.com/android/reference/available-resources.html
  19. Guide de style des icônes de la barre d'état: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  20. Gestionnaire de recherche: http://developer.android.com/reference/android/app/SearchManager.html
  21. Toasts: http://developer.android.com/reference/android/widget/Toast.html
  22. Fonds d'écran animés: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  23. Documentation de référence des outils (pour adb, aapt et ddms): http://developer.android.com/guide/developing/tools/index.html
  24. Description du fichier APK Android: http://developer.android.com/guide/topics/fundamentals.html
  25. Fichiers manifestes: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  26. Outil de test du singe: https://developer.android.com/studio/test/other-testing-tools/monkey
  27. Liste des fonctionnalités matérielles Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
  28. Compatibilité avec plusieurs écrans: http://developer.android.com/guide/practices/screens_support.html
  29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  31. Espace de coordonnées du capteur: http://developer.android.com/reference/android/hardware/SensorEvent.html
  32. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
  33. Protocole NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
  34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
  39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
  40. API d'orientation de l'appareil photo: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  42. Documentation de référence sur la sécurité et les autorisations Android: http://developer.android.com/guide/topics/security/security.html
  43. Applications pour Android: http://code.google.com/p/apps-for-android

Bon nombre de ces ressources sont dérivées directement ou indirectement du SDK Android 2.3 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.3 [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é.

Cette définition de compatibilité permet d'omettre certains types de matériel pour lesquels Android inclut des API par les implémentations d'appareils. Dans ce cas, les API DOIVENT toujours être présentes et se comporter de manière raisonnable. Consultez la section 7 pour connaître les exigences spécifiques à ce scénario.

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.3. 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.3, ce champ DOIT avoir la valeur entière 9.
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. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
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. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
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. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
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):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Par exemple :
acme/mydevice/generic/generic:2.3/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 ("_"). La valeur de ce champ DOIT être encodable en ASCII 7 bits.
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. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
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. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
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". La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
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". La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
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
  • Contacts
  • Adresse e-mail
  • Galerie
  • GlobalSearch
  • Lanceur d'applications
  • Musique
  • Paramètres

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. Comme le code natif est fortement dépendant de la technologie de processeur sous-jacente, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans le NDK Android, dans le fichier docs/CPU-ARCH-ABIS.txt. Si une implémentation d'appareil est compatible avec une ou plusieurs ABI définies, elle DOIT implémenter la compatibilité avec le NDK Android, comme indiqué ci-dessous.

Si une implémentation d'appareil prend en charge une ABI Android, elle:

  • DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler le code natif, à l'aide de la sémantique standard de Java Native Interface (JNI).
  • DOIT être compatible avec la source (c'est-à-dire avec l'en-tête) et avec le binaire (pour l'ABI) avec chaque bibliothèque requise de la liste ci-dessous
  • DOIT indiquer avec précision l'interface binaire d'application (ABI) native compatible avec l'appareil, via l'API android.os.Build.CPU_ABI.
  • DOIT signaler uniquement les ABI documentées dans la dernière version du NDK Android, dans le fichier docs/CPU-ARCH-ABIS.txt
  • DOIT être compilé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Open Source Android en amont

Les API de code natif suivantes DOIVENT être disponibles pour les applications qui incluent du code natif:

  • libc (bibliothèque C)
  • libm (bibliothèque mathématique)
  • Compatibilité minimale avec C++
  • Interface JNI
  • liblog (journalisation Android)
  • libz (compression zlib)
  • libdl (lecteur de liens dynamique)
  • libGLESv1_CM.so (OpenGL ES 1.0)
  • libGLESv2.so (OpenGL ES 2.0)
  • libEGL.so (gestion des surfaces OpenGL natives)
  • libjnigraphics.so
  • libOpenSLES.so (prise en charge de l'audio Open Sound Library)
  • libandroid.so (prise en charge des activités Android natives)
  • Prise en charge d'OpenGL, comme décrit ci-dessous

Notez que les futures versions du NDK Android peuvent prendre en charge des ABI supplémentaires. Si une implémentation d'appareil n'est pas compatible avec une ABI prédéfinie existante, elle NE DOIT PAS signaler la prise en charge d'une 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, un navigateur Web complet et moderne est essentiel à 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.3. 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.

Le composant WebView DOIT être compatible avec autant que possible de la technologie HTML5 [Ressources, 9]. Au minimum, les implémentations d'appareils DOIVENT prendre en charge chacune de ces API associées à HTML5 dans la WebView:

De plus, les implémentations d'appareils DOIVENT être compatibles avec l'API webstorage HTML5/W3C [Ressources, 13] et DEVRAIENT être compatibles avec l'API IndexedDB HTML5/W3C [Ressources, 14]. Notez que, à mesure que les organismes de normalisation du développement Web passent à IndexedDB plutôt qu'à WebStorage, IndexedDB devrait devenir un composant obligatoire dans une prochaine version d'Android.

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 utilisée, 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]. Au minimum, les implémentations d'appareils DOIVENT prendre en charge chacune de ces API associées à HTML5:

De plus, les implémentations d'appareils DOIVENT être compatibles avec l'API webstorage HTML5/W3C [Ressources, 13] et DEVRAIENT être compatibles avec l'API IndexedDB HTML5/W3C [Ressources, 14]. Notez que, à mesure que les organismes de normalisation du développement Web passent à IndexedDB plutôt qu'à WebStorage, IndexedDB devrait devenir un composant obligatoire dans une prochaine version d'Android.

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 ni la sémantique 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 standard.

La liste ci-dessus n'est pas exhaustive. La suite de tests de compatibilité (CTS) vérifie la compatibilité comportementale de certaines parties importantes de la plate-forme, mais pas de toutes. Il incombe à l'implémentateur de s'assurer de la compatibilité comportementale avec le projet Android Open Source. Pour cette raison, 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.

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" tel qu'il est utilisé dans le code source Android en amont. En d'autres termes, les implémentateurs d'appareils NE DOIVENT PAS exposer de nouvelles API ni modifier les API existantes dans les espaces de noms indiqués ci-dessus. Les implémentateurs d'appareils PEUVENT apporter des modifications internes uniquement, mais ces modifications NE DOIVENT PAS être annoncées ni exposées aux développeurs.

Les implémentateurs d'appareils PEUVENT ajouter des API personnalisées, mais ces API NE DOIVENT PAS se trouver dans un espace de noms appartenant à une autre organisation ou faisant référence à une autre organisation. Par exemple, les implémentateurs d'appareils NE DOIVENT PAS ajouter d'API à l'espace de noms com.google.* ou à un espace de noms similaire. Seul Google peut le faire. De même, Google NE DOIT PAS ajouter d'API aux espaces de noms d'autres entreprises. De plus, si une implémentation d'appareil inclut des API personnalisées en dehors du namespace Android standard, ces API DOIVENT être empaquetées dans une bibliothèque partagée Android afin que seules les applications qui les utilisent explicitement (via le mécanisme <uses-library>) soient affectées par l'augmentation de l'utilisation de la mémoire de ces API.

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

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 dont les écrans sont classés comme haute densité ou très haute densité DOIVENT configurer Dalvik pour qu'il alloue 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, 16]. 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, 17]. 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, 18] ou dans le guide de style des icônes de la barre d'état [Ressources, 19]. 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 [Resources, 20] 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, 21]) pour afficher des chaînes courtes non modales à l'utilisateur final, qui disparaissent après un court laps de temps. Les implémentations d'appareils DOIVENT afficher les toasts des applications aux utilisateurs finaux de manière très visible.

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, 22]. 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é 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, 23].

Les implémentations d'appareils NE DOIVENT PAS étendre les formats .apk [Ressources, 24], Android Manifest [Ressources, 25] ou bytecode Dalvik [Ressources, 15] 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.

5. 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. Les implémentations d'appareils DOIVENT inclure au moins une forme de sortie audio, comme des haut-parleurs, une prise casque, une connexion à des haut-parleurs externes, etc.

5.1. Codecs multimédias

Les implémentations d'appareils DOIVENT prendre en charge les codecs multimédias, comme indiqué dans les sections suivantes. 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.

Les tableaux ci-dessous ne répertorient 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.

5.1.1. Décodeurs multimédias

Les implémentations d'appareils DOIVENT inclure une implémentation d'un décodeur pour chaque codec et format décrit dans le tableau ci-dessous. Notez que les décodeurs pour chacun de ces types de médias sont fournis par le projet Android Open Source en amont.

Audio
Nom Détails Format de fichier/conteneur
AAC LC/LTP 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+)
HE-AACv2 (AAC+ amélioré)
AMR-NB 4,75 à 12,2 kbit/s échantillonnés à 8 kHz 3GPP (.3gp)
AMR-WB 9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz 3GPP (.3gp)
MP3 Mono/Stéréo 8-320 kbit/s CBR (débit constant) ou VBR (débit variable) MP3 (.mp3)
MIDI 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   Ogg (.ogg)
Zone PCM linéaire 8 et 16 bits (débits jusqu'à la limite du matériel) WAVE (.wav)
Image
JPEG base+progressive  
GIF    
PNG    
BMP    
Vidéo
H.263   Fichiers 3GPP (.3gp)
H.264   Fichiers 3GPP (.3gp) et MPEG-4 (.mp4)
Profil MPEG4 simple   Fichier 3GPP (.3gp)

5.1.2. Encodeurs multimédias

Les implémentations d'appareils DOIVENT inclure des encodeurs pour autant de formats multimédias que possible listés dans la section 5.1.1. Toutefois, certains encodeurs ne sont pas adaptés aux appareils qui ne disposent pas de certains matériels facultatifs. Par exemple, un encodeur pour la vidéo H.263 n'a pas de sens si l'appareil ne dispose pas d'appareil photo. Les implémentations d'appareils DOIVENT donc implémenter des encodeurs multimédias conformément aux conditions décrites dans le tableau ci-dessous.

Pour en savoir plus sur les conditions dans lesquelles le matériel peut être omis par les implémentations d'appareils, consultez la section 7.

Audio
Nom Détails Format de fichier/conteneur Conditions
AMR-NB 4,75 à 12,2 kbit/s échantillonnés à 8 kHz 3GPP (.3gp) Les implémentations d'appareils qui incluent du matériel de micro et définissent android.hardware.microphone DOIVENT inclure des encodeurs pour ces formats audio.
AMR-WB 9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz 3GPP (.3gp)
AAC LC/LTP 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)
Image JPEG base+progressive   Toutes les implémentations d'appareils DOIVENT inclure des encodeurs pour ces formats d'image, car Android 2.3 inclut des API que les applications peuvent utiliser pour générer des fichiers de ces types de manière programmatique.
PNG    
Vidéo H.263   Fichiers 3GPP (.3gp) Les implémentations d'appareils qui incluent du matériel d'appareil photo et définissent android.hardware.camera ou android.hardware.camera.front DOIVENT inclure des encodeurs pour ces formats vidéo.

En plus des encodeurs listés ci-dessus, les implémentations d'appareils DOIVENT inclure un encodeur H.264. Notez que la définition de la compatibilité pour une future version prévoit de remplacer cette exigence par "MUST". Autrement dit, l'encodage H.264 est facultatif dans Android 2.3, mais sera obligatoire dans une prochaine version. Les appareils existants et nouveaux équipés d'Android 2.3 sont très fortement encouragés à respecter cette exigence dans Android 2.3, sinon ils ne pourront pas atteindre la compatibilité Android lors de la mise à niveau vers la future version.

5.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 "DÉSIRABLE" pour Android 2.3, la définition de compatibilité d'une future version prévoit de les remplacer par "OBLIGATOIRE". Autrement dit, ces exigences sont facultatives dans Android 2.3, mais elles seront obligatoires dans une prochaine version. Les appareils existants et nouveaux exécutant Android 2.3 sont très fortement encouragés à respecter ces exigences dans Android 2.3, sinon ils ne pourront pas atteindre la compatibilité Android lors de la mise à niveau vers la future version.

5.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 qui incluent du matériel de micro et déclarent android.hardware.microphone DOIVENT respecter toutes les exigences de latence audio décrites dans cette section. Consultez la section 7 pour en savoir plus sur les conditions dans lesquelles le matériel du micro peut être omis par les implémentations d'appareils.

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 "DÉSIRABLE" pour Android 2.3, la définition de compatibilité d'une future version prévoit de les remplacer par "OBLIGATOIRE". Autrement dit, ces exigences sont facultatives dans Android 2.3, mais elles seront obligatoires dans une prochaine version. Les appareils existants et nouveaux exécutant Android 2.3 sont très fortement encouragés à respecter ces exigences dans Android 2.3, sinon ils ne pourront pas atteindre la compatibilité Android lors de la mise à niveau vers la future version.

Si une implémentation d'appareil répond aux exigences de cette section, elle PEUT signaler la prise en charge de l'audio à faible latence en signalant la fonctionnalité "android.hardware.audio.low-latency" via la classe android.content.pm.PackageManager. [Ressources, 27] À l'inverse, si l'implémentation de l'appareil ne répond pas à ces exigences, elle NE DOIT PAS indiquer la prise en charge de l'audio à faible latence.

6. 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, 23]
    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.
  • Service Dalvik Debug Monitor (ddms) [Ressources, 23]
    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 [Resources, 26]
    Les implémentations d'appareils DOIVENT inclure le framework Monkey et le mettre à la disposition des applications.

La plupart des systèmes Linux et des systèmes Apple Macintosh reconnaissent les appareils Android à l'aide des outils SDK Android standards, sans assistance supplémentaire. Toutefois, les systèmes Microsoft Windows nécessitent généralement un pilote pour les nouveaux appareils Android. (Par exemple, les nouveaux ID de fournisseur et parfois les nouveaux ID d'appareil nécessitent des pilotes USB personnalisés pour les systèmes Windows.) Si une implémentation d'appareil n'est pas reconnue par l'outil adb fourni dans le SDK Android standard, les implémentateurs d'appareils DOIVENT fournir des pilotes Windows permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb. Ces pilotes DOIVENT être fournis pour Windows XP, Windows Vista et Windows 7, en versions 32 bits et 64 bits.

7. Compatibilité matérielle

Android est conçu pour permettre aux implémentateurs d'appareils de créer des facteurs de forme et des configurations innovants. En même temps, les développeurs Android écrivent des applications innovantes qui s'appuient sur les différents matériels et fonctionnalités disponibles via les API Android. Les exigences de cette section établissent un équilibre entre les innovations disponibles pour les implémentateurs d'appareils et les besoins des développeurs pour s'assurer que leurs applications ne sont disponibles que sur les appareils sur lesquels elles s'exécutent correctement.

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écrit 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 complètes (telles que documentées par le SDK) pour les API du composant DOIVENT toujours ê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.
  • Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documenté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, 27]

7.1. Écran et graphismes

Android 2.3 inclut des fonctionnalités qui ajustent automatiquement les éléments d'application et les mises en page de l'interface utilisateur en fonction de l'appareil, afin de s'assurer que les applications tierces fonctionnent correctement sur diverses configurations matérielles [Resources, 28]. Les appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

7.1.1. Configurations d'écran

Les implémentations d'appareils PEUVENT utiliser des écrans de toutes dimensions en pixels, à condition qu'ils respectent les exigences suivantes:

  • La diagonale de l'écran doit mesurer au moins 6,35 cm.
  • La densité doit être d'au moins 100 ppp
  • Le format doit être compris entre 1,333 (4:3) et 1,779 (16:9).
  • La technologie d'affichage utilisée se compose de pixels carrés.

Les implémentations d'appareils avec un écran répondant aux exigences ci-dessus sont considérées comme compatibles, et aucune autre action n'est nécessaire. L'implémentation du framework Android calcule automatiquement les caractéristiques d'affichage telles que le bucket de taille d'écran et le bucket de densité. Dans la plupart des cas, les décisions du framework sont les bonnes. Si les calculs du framework par défaut sont utilisés, aucune autre action n'est requise. Les implémentateurs d'appareils qui souhaitent modifier les valeurs par défaut ou utiliser un écran qui ne répond pas aux exigences ci-dessus DOIVENT contacter l'équipe de compatibilité Android pour obtenir des conseils, comme indiqué dans la section 12.

Les unités utilisées dans les exigences ci-dessus sont définies comme suit:

  • La "taille diagonale physique" correspond à la distance en pouces entre deux coins opposés de la partie éclairée de l'écran.
  • "ppp" (points par pouce) correspond au nombre de pixels compris dans une plage linéaire horizontale ou verticale de 1 pouce. Lorsque des valeurs de dpi sont indiquées, les dpi horizontaux et verticaux doivent être compris dans la plage.
  • Le "format" correspond au rapport entre la dimension la plus longue de l'écran et la dimension la plus courte. Par exemple, un écran de 480 x 854 pixels correspond à 854 / 480 = 1,779, soit environ "16:9".

Les implémentations d'appareils DOIVENT utiliser uniquement des écrans avec une seule configuration statique. Autrement dit, les implémentations d'appareils NE DOIVENT PAS activer plusieurs configurations d'écran. Par exemple, comme une télévision standard prend en charge plusieurs résolutions telles que 1080p, 720p, etc., cette configuration n'est pas compatible avec Android 2.3. (Toutefois, la prise en charge de ces configurations est à l'étude et est prévue pour une future version d'Android.)

7.1.2. Métriques sur le Réseau Display

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

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

7.1.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 qui ne peuvent pas être physiquement pivotés PEUVENT répondre à cette exigence en utilisant le format letterbox pour les applications qui demandent le mode portrait, en n'utilisant qu'une partie de l'écran disponible.

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.

7.1.5. Accélération graphique 3D

Les implémentations d'appareils DOIVENT être compatibles avec OpenGL ES 1.0, comme l'exigent les API Android 2.3. Pour les appareils qui ne disposent pas d'accélération matérielle 3D, une implémentation logicielle d'OpenGL ES 1.0 est fournie par le projet Android Open Source en amont. Les implémentations d'appareils DOIVENT être compatibles avec OpenGL ES 2.0.

Les implémentations PEUVENT omettre la prise en charge d'OpenGL ES 2.0. Toutefois, si la prise en charge est omise, les implémentations d'appareils NE DOIVENT PAS indiquer qu'elles sont compatibles avec OpenGL ES 2.0. Plus précisément, si les implémentations d'un appareil ne sont pas compatibles avec OpenGL ES 2.0:

  • Les API gérées (par exemple, via la méthode GLES10.getString()) NE DOIVENT PAS signaler la prise en charge d'OpenGL ES 2.0.
  • Les API OpenGL natives C/C++ (c'est-à-dire celles disponibles pour les applications via libGLES_v1CM.so, libGLES_v2.so ou libEGL.so) NE DOIVENT PAS signaler la prise en charge d'OpenGL ES 2.0.

À l'inverse, si une implémentation d'appareil est compatible avec OpenGL ES 2.0, elle DOIT signaler cette compatibilité avec précision via les routes que nous venons de lister.

Notez qu'Android 2.3 permet aux applications de spécifier facultativement qu'elles nécessitent des formats de compression de texture OpenGL spécifiques. Ces formats sont généralement propres au fournisseur. Android 2.3 n'exige pas d'implémentations d'appareils pour implémenter un format de compression de texture spécifique. Toutefois, ils DOIVENT signaler avec précision tous les formats de compression de texture qu'ils prennent en charge, via la méthode getString() de l'API OpenGL.

7.2. Périphériques d'entrée

Android 2.3 prend en charge un certain nombre de modalités d'entrée utilisateur. Les implémentations d'appareils DOIVENT prendre en charge les périphériques d'entrée utilisateur comme indiqué dans cette section.

7.2.1. 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, 30] (c'est-à-dire QWERTY ou 12 touches)

7.2.2. Navigation non tactile

Implémentations de l'appareil:

  • PEUT omettre une option 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, 30]
  • DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification du texte, compatible avec les moteurs de gestion des entrées. Le code Open Source Android en amont inclut un mécanisme de sélection adapté aux appareils qui ne disposent pas d'entrées de navigation non tactiles.

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

7.2.4. 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, 30] 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

7.3. Capteurs

Android 2.3 inclut des API permettant d'accéder à différents types de capteurs. Les implémentations d'appareils peuvent généralement omettre ces capteurs, comme indiqué dans les sous-sections suivantes. Si un appareil inclut un type de capteur 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écrit dans la documentation du SDK Android. Par exemple, les implémentations d'appareils:

  • DOIT indiquer avec précision la présence ou l'absence de capteurs selon la classe android.content.pm.PackageManager. [Ressources, 27]
  • DOIT renvoyer une liste précise des capteurs compatibles via SensorManager.getSensorList() et des méthodes similaires
  • DOIT se comporter de manière raisonnable pour toutes les autres API de capteurs (par exemple, en renvoyant "true" ou "false" selon les cas lorsque les applications tentent d'enregistrer des écouteurs, en n'appelant pas les écouteurs de capteurs lorsque les capteurs correspondants ne sont pas présents, etc.)

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android doit être considéré comme faisant autorité.

Certains types de capteurs sont synthétiques, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (Exemples : capteur d'orientation et capteur d'accélération linéaire.) Les implémentations d'appareils DOIVENT implémenter ces types de capteurs lorsqu'ils incluent les capteurs physiques requis.

Les API Android 2.3 introduisent la notion de capteur "streaming", qui renvoie des données en continu, et non seulement lorsque les données changent. Les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques pour toute API indiquée par la documentation du SDK Android 2.3 comme étant un capteur de streaming.

7.3.1. Accéléromètre

Les implémentations d'appareils DOIVENT inclure un accéléromètre à trois axes. Si une implémentation d'appareil inclut un accéléromètre à trois axes, elle:

  • DOIT pouvoir envoyer des événements à 50 Hz ou plus
  • DOIT respecter le système de coordonnées des capteurs Android tel que décrit dans les API Android (voir [Ressources, 31])
  • DOIT être capable de mesurer de la chute libre jusqu'à deux fois la gravité (2 g) ou plus sur n'importe quel vecteur tridimensionnel
  • Doit avoir une précision d'au moins 8 bits
  • La déviation standard doit être inférieure ou égale à 0,05 m/s².

7.3.2. Magnétomètre

Les implémentations d'appareils DOIVENT inclure un magnétomètre à trois axes (boussole). Si un appareil inclut un magnétomètre à trois axes, il:

  • DOIT pouvoir envoyer des événements à 10 Hz ou plus
  • DOIVENT respecter le système de coordonnées des capteurs Android tel que décrit dans les API Android (voir [Ressources, 31]).
  • DOIT être capable d'échantillonner une plage de champs magnétiques adaptée pour couvrir le champ géomagnétique
  • Doit avoir une précision d'au moins 8 bits
  • La déviation standard doit être inférieure ou égale à 0,5 µT.

7.3.3. GPS

Les implémentations d'appareils DOIVENT inclure un récepteur GPS. Si l'implémentation d'un appareil inclut un récepteur GPS, elle DOIT inclure une forme de technique "GPS assisté" pour réduire le temps de verrouillage du GPS.

7.3.4. Gyroscope

Les implémentations d'appareils DOIVENT inclure un gyroscope (c'est-à-dire un capteur de changement angulaire). Les appareils NE DOIVENT PAS inclure de capteur de gyroscope, sauf si un accéléromètre à trois axes est également inclus. Si une implémentation d'appareil inclut un gyroscope:

  • DOIT être capable de mesurer les changements d'orientation jusqu'à 5,5*Pi radians/seconde (soit environ 1 000 degrés par seconde)
  • DOIT pouvoir envoyer des événements à 100 Hz ou plus
  • Doit avoir une précision d'au moins 8 bits

7.3.5. Le baromètre

Les implémentations d'appareils PEUVENT inclure un baromètre (c'est-à-dire un capteur de pression atmosphérique ambiante). Si une implémentation d'appareil inclut un baromètre, elle:

  • DOIT pouvoir envoyer des événements à 5 Hz ou plus
  • DOIT avoir une précision adéquate pour permettre d'estimer l'altitude

7.3.7. Thermomètre

Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS inclure de thermomètre (c'est-à-dire un capteur de température). Si une implémentation d'appareil inclut un thermomètre, elle DOIT mesurer la température du processeur de l'appareil. Il NE DOIT PAS mesurer d'autre température. (Notez que ce type de capteur est obsolète dans les API Android 2.3.)

7.3.7. Photomètre

Les implémentations d'appareils PEUVENT inclure un photomètre (c'est-à-dire un capteur de lumière ambiante).

7.3.8. Capteur de proximité

Les implémentations d'appareils PEUVENT inclure un capteur de proximité. Si une implémentation d'appareil inclut un capteur de proximité, elle DOIT mesurer la proximité d'un objet dans la même direction que l'écran. Autrement dit, le capteur de proximité DOIT être orienté pour détecter les objets proches de l'écran, car l'objectif principal de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si une implémentation d'appareil inclut un capteur de proximité avec une autre orientation, il NE DOIT PAS être accessible via cette API. Si une implémentation d'appareil est équipée d'un capteur de proximité, elle DOIT avoir une précision d'au moins 1 bit.

7.4. Connectivité des données

La connectivité réseau et l'accès à Internet sont des fonctionnalités essentielles d'Android. En outre, l'interaction d'un appareil à un autre ajoute une valeur significative aux appareils et applications Android. Les implémentations d'appareils DOIVENT respecter les exigences de connectivité des données de cette section.

7.4.1. Téléphonie

Le terme "téléphonie" utilisé par les API Android 2.3 et dans ce document fait spécifiquement référence au matériel lié à la mise en place d'appels vocaux et à l'envoi de messages SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent ou non être commutés par paquets, ils sont considérés comme indépendants de toute connectivité de données pouvant être implémentée à l'aide du même réseau à des fins d'Android 2.3. En d'autres termes, les fonctionnalités et API de "téléphonie" Android font spécifiquement référence aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir de messages SMS NE DOIVENT PAS signaler la fonctionnalité "android.hardware.telephony" ni ses sous-fonctionnalités, que ce soit ou non via un réseau mobile pour la connectivité de données.

Android 2.3 peut être utilisé sur les appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android 2.3 est compatible avec les appareils autres que les téléphones. Toutefois, si une implémentation d'appareil inclut la téléphonie GSM ou CDMA, elle DOIT implémenter une compatibilité complète avec l'API de 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.

7.4.2. IEEE 802.11 (Wi-Fi)

Les implémentations d'appareils Android 2.3 DOIVENT être compatibles avec une ou plusieurs formes de 802.11 (b/g/a/n, etc.) Si une implémentation d'appareil inclut la prise en charge de la norme 802.11, elle DOIT implémenter l'API Android correspondante.

7.4.3. Bluetooth

Les implémentations d'appareils DOIVENT inclure un émetteur-récepteur Bluetooth. Les implémentations d'appareils qui incluent un transceiver Bluetooth DOIVENT activer l'API Bluetooth basée sur RFCOMM, comme décrit dans la documentation du SDK [Ressources, 32]. 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.

7.4.4. Communication en champ proche

Les implémentations d'appareils DOIVENT inclure un émetteur-récepteur et du matériel associé pour la technologie NFC (communication en champ proche). Si une implémentation d'appareil inclut du matériel NFC, elle:

  • DOIT signaler la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). [Ressources, 27]
  • DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes:
    • DOIT être en mesure de fonctionner en tant que lecteur/enregistreur NFC Forum (tel que défini par la spécification technique du NFC Forum NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS 6319-4)
      • NfcV (ISO 15693)
      • IsoDep (ISO 14443-4)
      • Types de tags NFC Forum 1, 2, 3 et 4 (définis par le forum NFC)
    • DOIT être capable de transmettre et de recevoir des données via les normes et protocoles peer-to-peer suivants:
      • ISO 18092
      • LLCP 1.0 (défini par le forum NFC)
      • SDP 1.0 (défini par le forum NFC)
      • NDEF Push Protocol [Resources, 33]
    • DOIT rechercher toutes les technologies compatibles en mode découverte NFC.
    • DOIT être en mode découverte NFC lorsque l'appareil est actif et que l'écran est allumé.

    (Notez que les liens publics ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum citées ci-dessus.)

    De plus, les implémentations d'appareils DOIVENT prendre en charge les technologies MIFARE largement déployées suivantes.

    Notez qu'Android 2.3.3 inclut des API pour ces types de cartes MIFARE. Si une implémentation d'appareil est compatible avec MIFARE, elle:

    • DOIT implémenter les API Android correspondantes, comme indiqué dans le SDK Android
    • DOIT signaler la fonctionnalité com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). [Resources, 27] Note that this is not a standard Android feature, and as such does not appear as a constant on the PackageManager class.
    • NE DOIT PAS implémenter les API Android correspondantes ni signaler la fonctionnalité com.nxp.mifare, sauf s'il implémente également la prise en charge générale de la technologie NFC, comme décrit dans cette section

    Si l'implémentation d'un appareil n'inclut pas de matériel NFC, elle NE DOIT PAS déclarer la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature() [Resources, 27] et DOIT implémenter l'API NFC Android 2.3 en tant qu'opération sans effet.

    Comme les classes android.nfc.NdefMessage et android.nfc.NdefRecord représentent un format de représentation de données indépendant du protocole, les implémentations d'appareils DOIVENT implémenter ces API, même si elles n'incluent pas la compatibilité avec la technologie NFC ni ne déclarent la fonctionnalité android.hardware.nfc.

    7.4.5. Capacité réseau minimale

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

    Les implémentations d'appareils où une norme de réseau physique (telle qu'Ethernet) constitue la connexion de données principale DOIVENT également prendre en charge au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi).

    Les appareils PEUVENT implémenter plusieurs formes de connectivité de données.

    7.5. Caméras

    Les implémentations d'appareils DOIVENT inclure une caméra arrière et PEUVENT inclure une caméra avant. Une caméra arrière est une caméra située sur le côté de l'appareil, à l'opposé de l'écran. Autrement dit, elle capture des scènes à l'arrière de l'appareil, comme une caméra traditionnelle. Une caméra avant est une caméra située du même côté de l'appareil que l'écran. Autrement dit, il s'agit d'une caméra généralement utilisée pour prendre une photo de l'utilisateur, par exemple pour les visioconférences et les applications similaires.

    7.5.1. Caméra arrière

    Les implémentations d'appareils DOIVENT inclure une caméra arrière. Si l'implémentation d'un appareil inclut une caméra arrière, elle:

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

    7.5.2. Caméra avant

    Les implémentations d'appareils PEUVENT inclure une caméra avant. Si l'implémentation d'un appareil inclut une caméra avant:

    • DOIT avoir une résolution d'au moins VGA (640 x 480 pixels)
    • NE DOIT PAS utiliser une caméra avant par défaut pour l'API Camera. Autrement dit, l'API de l'appareil photo dans Android 2.3 est compatible spécifiquement avec les caméras avant, et les implémentations d'appareils NE DOIVENT PAS configurer l'API pour traiter une caméra avant comme la caméra arrière par défaut, même si elle est la seule caméra de l'appareil.
    • PEUVENT inclure des fonctionnalités (comme le focus automatique, le flash, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.
    • DOIT refléter horizontalement (c'est-à-dire en miroir) le flux affiché par une application dans un CameraPreview, comme suit:
      • Si l'implémentation de l'appareil peut être pivotée par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via une entrée utilisateur), l'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.
      • Si l'application actuelle a explicitement demandé que l'écran de l'appareil photo soit pivoté via un appel à la méthode android.hardware.Camera.setDisplayOrientation() [Resources, 40], l'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application.
      • Sinon, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil.
    • DOIT refléter les données d'image renvoyées à tous les gestionnaires de rappel de l'appareil photo "postview", de la même manière que le flux d'images d'aperçu de l'appareil photo. (Si l'implémentation de l'appareil n'est pas compatible avec les rappels post-vue, cette exigence ne s'applique évidemment pas.)
    • NE DOIT PAS refléter les flux d'images fixes ou vidéo capturés renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia

    7.5.3. Comportement de l'API Camera

    Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées aux caméras, à la fois pour les caméras avant et arrière:

    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. Autrement dit, NV21 DOIT être la valeur par défaut.
    3. Les implémentations d'appareils DOIVENT prendre en charge le format YV12 (comme indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de l'appareil photo, à la fois pour les caméras avant et arrière. Notez que la définition de la compatibilité pour une future version prévoit de remplacer cette exigence par "MUST". Autrement dit, la prise en charge de YV12 est facultative dans Android 2.3, mais sera obligatoire dans une prochaine version. Les appareils existants et nouveaux exécutant Android 2.3 sont très fortement encouragés à répondre à cette exigence dans Android 2.3, sinon ils ne pourront pas atteindre la compatibilité Android lors de la mise à niveau vers la future version.

    Les implémentations d'appareils DOIVENT implémenter l'API Camera complète incluse dans la documentation du SDK Android 2.3 [Ressources, 41], 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). Notez que cela s'applique aux caméras avant. Par exemple, même si la plupart des caméras avant ne sont pas compatibles avec la mise au point automatique, les rappels d'API doivent toujours être "faussés" comme décrit.

    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.

    7.5.4. Orientation de l'appareil photo

    Les caméras avant et arrière, le cas échéant, DOIVENT être orientées de sorte à faire correspondre la dimension longue de la caméra à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils en mode paysage et en mode portrait.

    7.6. Mémoire et stockage

    La fonction de base d'Android 2.3 est d'exécuter des applications. Les implémentations d'appareils DOIVENT respecter les exigences de cette section afin de garantir un espace de stockage et une mémoire suffisants pour que les applications s'exécutent correctement.

    7.6.1. Mémoire et stockage minimums

    Les implémentations d'appareils DOIVENT disposer d'au moins 128 Mo de mémoire disponible pour le noyau et l'espace utilisateur. Les 128 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 1 Go d'espace de stockage non volatile disponible pour les données utilisateur. Notez que cette exigence plus élevée devrait devenir une valeur minimale stricte dans une future 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.

    Les API Android incluent un gestionnaire de téléchargement que les applications peuvent utiliser pour télécharger des fichiers de données. L'implémentation du Gestionnaire de téléchargement DOIT être capable de télécharger des fichiers individuels de 55 Mo ou plus. L'implémentation du Gestionnaire de téléchargement DOIT être capable de télécharger des fichiers de 100 Mo ou plus.

    7.6.2. 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 1 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.

    Quelle que soit la forme de stockage partagé utilisée, les implémentations d'appareils DOIVENT fournir un mécanisme permettant d'accéder au contenu du stockage partagé à partir d'un ordinateur hôte, tel que le stockage de masse USB ou le protocole Media Transfer.

    Prenons deux exemples courants pour illustrer ce point. Si l'implémentation d'un appareil inclut un port de carte SD pour répondre à l'exigence de stockage partagé, une carte SD au format FAT d'une taille d'au moins 1 Go 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 1 Go 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.

    7.7. 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. Compatibilité des performances

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

    9. 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, 42] 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.

    9.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, 42]. 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.*.

    9.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, 42].

    9.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, 42].

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

    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.

    10. Tests de compatibilité des logiciels

    Le projet Open Source Android inclut divers outils de test pour vérifier que les implémentations d'appareils sont compatibles. Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section.

    Toutefois, notez qu'aucun package de test logiciel n'est totalement complet. Pour cette raison, les implémentateurs d'appareils sont vivement encouragés à apporter le moins de modifications possible à l'implémentation de référence et privilégiée d'Android 2.3 disponible dans le projet Android Open Source. Cela réduit le risque d'introduire des bugs qui créent des incompatibilités nécessitant des retouches et des mises à jour potentielles de l'appareil.

    10.1. 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.3. 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é.

    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.

    10.2. Validateur CTS

    Les implémentations d'appareils DOIVENT exécuter correctement tous les cas applicables dans le vérificateur CTS. Le vérificateur CTS est inclus dans l'ensemble de tests de compatibilité. Il est destiné à être exécuté par un opérateur humain pour tester les fonctionnalités qui ne peuvent pas être testées par un système automatisé, comme le bon fonctionnement d'une caméra et de capteurs.

    Le vérificateur CTS propose des tests pour de nombreux types de matériel, y compris certains matériels facultatifs. Les implémentations d'appareils DOIVENT réussir tous les tests du matériel dont elles disposent. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le scénario de test de l'accéléromètre dans le vérificateur CTS. Les cas de test des fonctionnalités indiquées comme facultatives par ce document de définition de la compatibilité PEUVENT être ignorés ou omis.

    Chaque appareil et chaque build DOIVENT exécuter correctement le vérificateur CTS, comme indiqué ci-dessus. Toutefois, comme de nombreuses versions sont très similaires, les implémentateurs d'appareils ne sont pas censés exécuter explicitement le vérificateur CTS sur des versions qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui ne diffèrent d'une implémentation ayant réussi le test CTS Verifier que par l'ensemble de paramètres régionaux, de branding, etc. peuvent omettre le test CTS Verifier.

    10.3. Applications de référence

    Les implémentateurs d'appareils DOIVENT tester la compatibilité de l'implémentation à l'aide des applications Open Source suivantes:

    • Les applications "Applications pour Android" [Ressources, 43].
    • 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.

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

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