Définition de la compatibilité Android 2.2

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

Table des matières

1. Introduction

Ce document énumère les exigences qui doivent être remplies pour que les téléphones mobiles soient compatibles avec Android 2.2.

L'utilisation de "doit", "ne doit pas", "obligatoire", "doit", "ne doit pas", "devrait", "ne devrait pas", "recommandé", "peut" et "facultatif" est conforme à la norme IETF. défini dans la RFC2119 [ Resources, 1 ].

Tel qu'utilisé dans ce document, un « implémenteur de périphérique » ou « implémenteur » est une personne ou une organisation développant une solution matérielle/logicielle exécutant Android 2.2. Une « implémentation de dispositif » ou « implémentation » est la solution matérielle/logicielle ainsi développée.

Pour être considéré comme compatible avec Android 2.2, les implémentations d'appareil :

• DOIT répondre aux exigences présentées dans cette définition de compatibilité, y compris tous les documents incorporés par référence.
• DOIT réussir la version la plus récente de la suite de tests de compatibilité Android (CTS) disponible au moment de la mise en œuvre 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, mais pas tous, décrits dans ce document.

Lorsque cette définition ou le CTS est muet, ambigu ou incomplet, il incombe au responsable de la mise en œuvre du dispositif de garantir la compatibilité avec les implémentations existantes. Pour cette raison, le projet Android Open Source [ Ressources, 3 ] est à la fois la référence et l'implémentation privilégiée d'Android. Les développeurs d'appareils sont fortement encouragés à baser leurs implémentations sur le code source « en amont » disponible dans le projet Android Open Source. Bien que certains composants puissent hypothétiquement être remplacés par des implémentations alternatives, cette pratique est fortement déconseillée, car la réussite des tests CTS deviendra considérablement plus difficile. Il est de la responsabilité du responsable de la mise en œuvre de garantir une compatibilité comportementale totale avec l'implémentation Android standard, y compris et au-delà de la suite de tests de compatibilité. Notez enfin que certaines substitutions et modifications de composants sont explicitement interdites par ce document.

2. Ressources

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

Beaucoup de ces ressources sont dérivées directement ou indirectement du SDK Android 2.2 et seront fonctionnellement identiques aux informations contenues dans la documentation de ce SDK. Dans tous les cas où cette définition de compatibilité ou la suite de tests de compatibilité est en désaccord avec la documentation du SDK, la documentation du SDK fait autorité. Tous les détails techniques fournis dans les références incluses ci-dessus sont considérés par inclusion 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 matérielles et logicielles qui font partie intégrante de la compatibilité, ainsi que certains autres comportements techniques et d'interface utilisateur pertinents. Les implémentations de périphériques DOIVENT être conformes à toutes les exigences de cette section.

3.1. Compatibilité des API gérées

L'environnement d'exécution géré (basé sur Dalvik) est le principal véhicule pour les applications Android. L'interface de programmation d'applications (API) Android est l'ensemble des interfaces de la plate-forme Android exposées aux applications exécutées dans l'environnement de machine virtuelle gérée. Les implémentations d'appareil DOIVENT fournir des implémentations complètes, y compris tous les comportements documentés, de toute API documentée exposée par le SDK Android 2.2 [ Ressources, 4 ].

Les implémentations de périphériques NE DOIVENT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ou inclure des opérations sans opération, sauf lorsque cela est spécifiquement autorisé par cette définition de compatibilité.

3.2. Compatibilité des API logicielles

En plus des API gérées de la section 3.1, Android inclut également une API « logicielle » importante réservée à l'exécution, sous la forme d'éléments tels que des intentions, des autorisations et des 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 « logicielles » et les comportements système requis pour la compatibilité avec Android 2.2. Les implémentations de périphériques DOIVENT répondre à toutes les exigences présentées dans cette section.

3.2.1. Autorisations

Les implémenteurs de périphériques DOIVENT prendre en charge et appliquer toutes les constantes d'autorisation comme documenté par la page de référence des autorisations [ Ressources, 5 ]. Notez que la section 10 répertorie les exigences supplémentaires liées au modèle de sécurité Android.

3.2.2. Paramètres de construction

Les API Android incluent un certain nombre de constantes sur la classe android.os.Build [ Resources, 6 ] destinées à décrire l'appareil actuel. Pour fournir des valeurs cohérentes et significatives dans toutes les implémentations de périphérique, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs auxquelles les implémentations de périphérique DOIVENT se conformer.

3.2.3. Compatibilité des intentions

Android utilise les intentions pour réaliser une intégration faiblement couplée entre les applications. Cette section décrit les exigences liées aux modèles d'intention qui DOIVENT être respectées par les implémentations de périphérique. Par « honoré », cela signifie que l'implémenteur du périphérique DOIT fournir une activité ou un service Android qui spécifie un filtre d'intention correspondant et se lie à et implémente un comportement correct pour chaque modèle d'intention spécifié.

3.2.3.1. Intentions principales de l'application

Le projet Android en amont définit un certain nombre d'applications de base, telles qu'un numéroteur téléphonique, un calendrier, un carnet de contacts, un lecteur de musique, etc. Les responsables de la mise en œuvre des appareils PEUVENT remplacer ces applications par des versions alternatives.

Cependant, toutes ces versions alternatives DOIVENT respecter les mêmes modèles d'intention fournis par le projet en amont. Par exemple, si un appareil contient un lecteur de musique alternatif, il doit toujours respecter le modèle d'intention émis par des applications tierces pour sélectionner une chanson.

Les applications suivantes sont considérées comme des applications principales du système Android :

• Horloge de bureau
• Navigateur
• Calendrier
• Calculatrice
• Caméra
• Contacts
• E-mail
• Galerie
• Recherche globale
• Lanceur
• LivePicker (c'est-à-dire l'application de sélection de Live Wallpaper ; PEUT être omise si l'appareil ne prend pas en charge Live Wallpapers, conformément à la section 3.8.5.)
• Messagerie (AKA "Mms")
• Musique
• Téléphone
• Paramètres
• Magnétophone

Les applications principales du système Android incluent divers composants d'activité ou de 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éfini dans l'une des applications principales du système Android qui n'est pas marqué comme non public via un attribut android:exported avec la valeur « false », les implémentations de périphérique DOIVENT inclure un composant du même type implémentant le même filtre d'intention. modèles en tant qu'application principale du système Android.

En d’autres termes, une implémentation d’appareil PEUT remplacer les applications principales du système Android ; cependant, si tel est le cas, l’implémentation du périphérique DOIT prendre en charge tous les modèles d’intention définis par chaque application principale du système Android remplacée.

3.2.3.2. Remplacements d'intention

Comme Android est une plate-forme extensible, les implémenteurs de périphériques DOIVENT permettre à chaque modèle d'intention référencé à la section 3.2.3.1 d'être remplacé par des applications tierces. Le projet open source Android en amont le permet par défaut ; les implémenteurs de dispositifs NE DOIVENT PAS attacher de privilèges spéciaux à l'utilisation par les applications système de ces modèles d'intention, ni empêcher les applications tierces de se lier à ces modèles et d'en prendre le contrôle. Cette interdiction inclut spécifiquement, mais sans s'y limiter, la désactivation de l'interface utilisateur « Chooser » qui permet à l'utilisateur de choisir entre plusieurs applications qui gèrent toutes le même modèle d'intention.

3.2.3.3. Espaces de noms d'intention

Les implémenteurs de périphériques NE DOIVENT PAS inclure de composant Android qui honore de nouveaux modèles d'intention ou d'intention de diffusion à l'aide d'une ACTION, d'une CATÉGORIE ou d'une autre chaîne de clé dans l'espace de noms android.*. Les responsables de la mise en œuvre des appareils NE DOIVENT PAS inclure de composants Android qui honorent de nouveaux modèles d'intention ou d'intention de diffusion à l'aide d'une ACTION, d'une CATÉGORIE ou d'une autre chaîne de clé dans un espace de package appartenant à une autre organisation. Les responsables de la mise en œuvre des appareils NE DOIVENT PAS modifier ou étendre les modèles d'intention utilisés par les applications principales répertoriées dans la section 3.2.3.1.

Cette interdiction est analogue à celle spécifiée pour les classes du langage Java à la section 3.6.

3.2.3.4. Intentions de diffusion

Les applications tierces s'appuient sur la plateforme pour diffuser certaines intentions afin de les informer des changements dans l'environnement matériel ou logiciel. Les appareils compatibles Android DOIVENT diffuser les intentions de diffusion publique en réponse aux événements système appropriés. Les intentions de diffusion sont décrites dans la documentation du SDK.

3.3. Compatibilité API native

Le code managé exécuté dans Dalvik peut appeler le code natif fourni dans le fichier .apk de l'application en tant que fichier ELF .so compilé pour l'architecture matérielle du périphérique approprié. Les implémentations de périphériques DOIVENT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler du code natif, en utilisant la sémantique standard Java Native Interface (JNI). Les API suivantes DOIVENT être disponibles pour le code natif :

• libc (bibliothèque C)
• libm (bibliothèque mathématique)
• Interface JNI
• libz (compression Zlib)
• liblog (journalisation Android)
• Prise en charge minimale du C++
• Prise en charge d'OpenGL, comme décrit ci-dessous

Les implémentations de périphériques DOIVENT prendre en charge OpenGL ES 1.0. Les appareils dépourvus d'accélération matérielle DOIVENT implémenter OpenGL ES 1.0 à l'aide d'un moteur de rendu logiciel. Les implémentations de périphériques DEVRAIENT implémenter autant d'OpenGL ES 1.1 que le matériel du périphérique le prend en charge. Les implémentations de périphériques DEVRAIENT fournir une implémentation pour OpenGL ES 2.0, si le matériel est capable de fournir des performances raisonnables sur ces API.

Ces bibliothèques DOIVENT être compatibles source (c'est-à-dire compatible en-tête) et compatible binaire (pour une architecture de processeur donnée) avec les versions fournies dans Bionic par le projet Android Open Source. Étant donné que les implémentations Bionic ne sont pas entièrement compatibles avec d'autres implémentations telles que la bibliothèque GNU C, les implémenteurs de périphériques DEVRAIENT utiliser l'implémentation Android. Si les implémenteurs de périphériques utilisent une implémentation différente de ces bibliothèques, ils DOIVENT garantir la compatibilité des en-têtes, des binaires et du comportement.

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

La compatibilité du code natif est un défi. Pour cette raison, il convient de répéter que les implémenteurs de périphériques sont TRÈS fortement encouragés à utiliser les implémentations en amont des bibliothèques répertoriées ci-dessus pour garantir 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 toutes les implémentations Android. De même, une expérience Web complète est au cœur de l’expérience utilisateur Android. Les implémentations d'appareil DOIVENT inclure une version d' android.webkit.WebView cohérente avec le logiciel Android en amont, et DOIVENT inclure un navigateur moderne compatible HTML5, comme décrit ci-dessous.

3.4.1. Compatibilité WebView

L'implémentation Android Open Source utilise le moteur de rendu WebKit pour implémenter android.webkit.WebView . Puisqu'il n'est pas possible de développer une suite de tests complète pour un système de rendu Web, les implémenteurs de périphériques DOIVENT utiliser la version spécifique en amont de WebKit dans l'implémentation de WebView. Spécifiquement:

• Les implémentations android.webkit.WebView des implémentations de périphériques DOIVENT être basées sur la version 533.1 WebKit de l'arborescence Android Open Source en amont pour Android 2.2. Cette version inclut un ensemble spécifique de fonctionnalités et de correctifs de sécurité pour WebView. Les implémenteurs de périphériques PEUVENT inclure des personnalisations à l'implémentation de WebKit ; cependant, de telles personnalisations NE DOIVENT PAS modifier le comportement de WebView, y compris le comportement de rendu.
• La chaîne de l'agent utilisateur signalée par WebView DOIT être dans ce format :
  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 la même que la valeur de android.os.Build.VERSION.RELEASE
  • La valeur de la chaîne $(LOCALE) DEVRAIT suivre les conventions ISO pour le code du pays et la langue, et DEVRAIT faire référence aux paramètres régionaux actuellement configurés du périphérique.
  • La valeur de la chaîne $(MODEL) DOIT être la même que la valeur de android.os.Build.MODEL
  • La valeur de la chaîne $(BUILD) DOIT être la même que la valeur de android.os.Build.ID

La configuration WebView DOIT inclure la prise en charge de la base de données HTML5, du cache d'application et des API de géolocalisation [ Ressources, 9 ]. La WebView DOIT inclure la prise en charge de la balise HTML5 <video> . Les API HTML5, comme toutes les API JavaScript, DOIVENT être désactivées par défaut dans une WebView, à moins que le développeur ne les active explicitement via les API Android habituelles.

3.4.2. Compatibilité du navigateur

Les implémentations d'appareil DOIVENT inclure une application de navigateur autonome pour la navigation Web des utilisateurs généraux. Le navigateur autonome PEUT être basé sur une technologie de navigateur autre que WebKit. Cependant, même si une autre application de navigateur est livré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 expédier une chaîne d'agent utilisateur 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) DEVRAIT inclure la prise en charge d'autant de HTML5 [ Ressources, 9 ] que possible. Au minimum, les implémentations d'appareil DOIVENT prendre en charge la géolocalisation HTML5, le cache d'application et les API de base de données ainsi que la balise <video> dans l'application de navigateur autonome.

3.5. Compatibilité comportementale des API

Les comportements de chacun des types d'API (gérés, logiciels, natifs et Web) doivent être cohérents avec l'implémentation préférée du projet open source Android en amont [ Ressources, 3 ]. Certains domaines spécifiques de compatibilité sont :

• Les appareils NE DOIVENT PAS modifier le comportement ou la signification d'une intention standard
• Les appareils NE DOIVENT PAS modifier le cycle de vie ou la sémantique du cycle de vie d'un type particulier de composant système (tel qu'un service, une activité, un fournisseur de contenu, etc.)
• Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation particulière

La liste ci-dessus n'est pas exhaustive et il incombe aux responsables de la mise en œuvre des appareils de garantir la compatibilité comportementale. Pour cette raison, les implémenteurs de périphériques DEVRAIENT utiliser le code source disponible via le projet Android Open Source lorsque cela est possible, plutôt que de réimplémenter des parties importantes du système.

La suite de tests de compatibilité (CTS) teste des parties importantes de la plate-forme pour vérifier leur compatibilité comportementale, mais pas toutes. Il est de la responsabilité du responsable de la mise en œuvre de garantir la compatibilité comportementale avec le projet Android Open Source.

3.6. Espaces de noms d'API

Android suit les conventions d'espace de noms de package et de classe définies par le langage de programmation Java. Pour garantir la compatibilité avec les applications tierces, les implémenteurs de périphériques NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) à ces espaces de noms de packages :

• Java.*
• javax.*
• soleil.*
• Android.*
• com.android.*

Les modifications interdites incluent :

• Les implémentations d'appareil NE DOIVENT PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant les signatures de méthode ou de classe, ou en supprimant des classes ou des champs de classe.
• Les implémenteurs de périphériques PEUVENT modifier l'implémentation sous-jacente des API, mais de telles modifications NE DOIVENT PAS avoir d'impact sur le comportement déclaré et la signature en langage Java de toute API exposée publiquement.
• Les implémenteurs de périphériques NE DOIVENT PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes aux classes ou interfaces existantes) aux API ci-dessus.

Un « élément exposé publiquement » est toute construction qui n'est pas décorée du marqueur « @hide » dans le code source Android en amont. En d’autres termes, les implémenteurs de périphériques NE DOIVENT PAS exposer de nouvelles API ou modifier les API existantes dans les espaces de noms mentionnés ci-dessus. Les implémenteurs de périphériques PEUVENT apporter des modifications uniquement internes, mais ces modifications NE DOIVENT PAS être annoncées ou autrement exposées aux développeurs.

Les responsables de la mise en œuvre des appareils PEUVENT ajouter des API personnalisées, mais ces API NE DOIVENT PAS se trouver dans un espace de noms appartenant à ou faisant référence à une autre organisation. Par exemple, les implémenteurs de périphériques NE DOIVENT PAS ajouter d'API à 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 sociétés.

Si un implémenteur de périphérique propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple en ajoutant de nouvelles fonctionnalités utiles à une API existante ou en ajoutant une nouvelle API), l'implémenteur DEVRAIT visiter source.android.com et commencer le processus de contribution aux modifications et code, selon les informations sur ce site.

Notez que les restrictions ci-dessus correspondent aux conventions standard 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 de périphériques DOIVENT prendre en charge la spécification complète du bytecode Dalvik Executable (DEX) et la sémantique de la machine virtuelle Dalvik [ Ressources, 10 ].

Les implémentations d'appareils avec des écrans classés comme densité moyenne ou faible DOIVENT configurer Dalvik pour allouer au moins 16 Mo de mémoire à chaque application. Les implémentations d'appareils avec des écrans classés comme haute densité DOIVENT configurer Dalvik pour allouer au moins 24 Mo de mémoire à chaque application. Notez que les implémentations de périphériques PEUVENT allouer plus de mémoire que ces chiffres.

3.8. Compatibilité de l'interface utilisateur

La plate-forme Android comprend certaines API de développement qui permettent aux développeurs de se connecter à l'interface utilisateur du système. Les implémentations d'appareil DOIVENT intégrer ces API d'interface utilisateur standard 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, une API et un cycle de vie correspondants qui permettent aux applications d'exposer un "AppWidget" à l'utilisateur final [ Ressources, 11 ]. La version de référence Android Open Source comprend une application Launcher 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 responsables de la mise en œuvre du périphérique PEUVENT substituer une alternative au lanceur de référence (c'est-à-dire l'écran d'accueil). Les lanceurs alternatifs DEVRAIENT inclure une prise en charge intégrée des AppWidgets et exposer les éléments de l'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur. Les lanceurs alternatifs PEUVENT omettre ces éléments d'interface utilisateur ; cependant, s'ils sont omis, le responsable de la mise en œuvre du périphérique 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'informer les utilisateurs d'événements notables [ Ressources, 12 ]. Les implémenteurs de dispositifs DOIVENT fournir une prise en charge pour chaque classe de notification ainsi définie ; plus précisément : sons, vibrations, lumière et barre d'état.

De plus, l'implémentation DOIT restituer correctement toutes les ressources (icônes, fichiers son, etc.) fournies dans les API [ Resources, 13 ] ou dans le guide de style des icônes de la barre d'état [ Resources, 14 ]. Les implémenteurs d'appareil PEUVENT fournir une expérience utilisateur alternative pour les notifications à celle fournie par l'implémentation de référence Android Open Source ; cependant, de tels systèmes de notification alternatifs DOIVENT prendre en charge les ressources de notification existantes, comme ci-dessus.

3.8.3. Recherche

Android inclut des API [ Ressources, 15 ] qui permettent aux développeurs d'incorporer la recherche dans leurs applications et d'exposer les données de leur application dans la recherche globale du système. De manière générale, 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 les résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour effectuer une recherche dans leurs propres applications et permettent aux développeurs de fournir des résultats à l'interface utilisateur de recherche globale commune.

Les mises en œuvre de dispositifs DOIVENT inclure une interface utilisateur de recherche unique, partagée à l'échelle du système, capable de suggestions en temps réel en réponse aux entrées de l'utilisateur. Les implémentations de périphériques DOIVENT implémenter les API qui permettent aux développeurs de réutiliser cette interface utilisateur pour fournir une recherche au sein de leurs propres applications. Les implémentations de périphériques 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 de recherche globale. Si aucune application tierce n'est installée et utilise cette fonctionnalité, le comportement par défaut DEVRAIT être d'afficher les résultats et les suggestions du moteur de recherche Web.

Les implémentations de périphériques PEUVENT proposer des interfaces utilisateur de recherche alternatives, mais DEVRAIENT inclure un bouton de recherche dédié, matériel ou logiciel, qui peut être utilisé à tout moment dans n'importe quelle application pour appeler le cadre de recherche, avec le comportement prévu dans la documentation de l'API.

3.8.4. Toasts

Les applications peuvent utiliser l'API "Toast" (définie dans [ Ressources, 16 ]) pour afficher de courtes chaînes non modales à l'utilisateur final, qui disparaissent après une brève période de temps. Les implémentations de périphériques DOIVENT afficher les toasts des applications aux utilisateurs finaux de manière à haute visibilité.

3.8.5. Fonds d'écran animés

Android définit un type de composant, une API et un cycle de vie correspondants qui permettent aux applications d'exposer un ou plusieurs "Live Wallpapers" à l'utilisateur final [ Ressources, 17 ]. Les fonds d'écran animés sont des animations, des motifs ou des images similaires avec des capacités de saisie limitées qui s'affichent comme 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é, à une fréquence d'images raisonnable et sans effets négatifs sur les autres applications. Si des limitations matérielles entraînent le blocage, le dysfonctionnement des fonds d'écran et/ou des applications, une consommation excessive d'énergie du processeur ou de la batterie, ou une exécution à des fréquences d'images inacceptablement basses, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. À titre d'exemple, certains fonds d'écran animés peuvent utiliser un contexte Open GL 1.0 ou 2.0 pour restituer leur contenu. Le fond d'écran animé ne fonctionnera pas de manière fiable sur du matériel qui ne prend pas en charge plusieurs contextes OpenGL, car l'utilisation du fond d'écran animé d'un contexte OpenGL 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, DEVRAIENT implémenter des fonds d'écran animés. Les implémentations d'appareils déterminées comme n'exécutant pas 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 logiciel de référence

Les responsables de la mise en œuvre des appareils DOIVENT tester la compatibilité de l'implémentation à l'aide des applications open source suivantes :

• Calculatrice (incluse dans le SDK)
• Lunar Lander (inclus dans le SDK)
• Les applications « Applications pour Android » [ Ressources, 18 ].
• Replica Island (disponible sur Android Market ; requis uniquement pour les implémentations d'appareils prenant en charge OpenGL ES 2.0)

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

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

• ApiDemos (inclus dans le SDK)
• Tests de fumée manuels (inclus dans CTS)

Chaque scénario de test dans les applications ci-dessus DOIT s'exécuter correctement sur l'implémentation du périphérique.

5. Compatibilité des emballages d'application

Les implémentations de périphériques DOIVENT installer et exécuter les fichiers Android ".apk" générés par l'outil "aapt" inclus dans le SDK Android officiel [ Ressources, 19 ].

Les implémentations d'appareils NE DOIVENT PAS étendre les formats .apk [ Ressources, 20 ], Android Manifest [ Ressources, 21 ] ou bytecode Dalvik [ Ressources, 10 ] de manière à empêcher ces fichiers de s'installer et de s'exécuter correctement sur d'autres appareils compatibles. . Les implémenteurs de périphériques doivent utiliser l'implémentation en amont de référence de Dalvik et le système de gestion des packages de l'implémentation de référence.

6. Compatibilité multimédia

Les implémentations de périphériques doivent implémenter pleinement toutes les API multimédias. Les implémentations de l'appareil doivent inclure la prise en charge de tous les codecs multimédias décrits ci-dessous et doivent répondre aux directives de traitement sonore décrites ci-dessous.

6.1. Codecs multimédias

Les implémentations de périphériques doivent prendre en charge les codecs multimédias suivants. Tous ces codecs sont fournis comme implémentations de logiciels dans l'implémentation Android préférée à partir du projet open source Android.

Veuillez noter que ni Google ni l'alliance Open Handsset ne font aucune représentation selon laquelle ces codecs ne sont pas grevés par des brevets tiers. Les personnes ayant l'intention d'utiliser ce code source dans les produits matériels ou logiciels sont informés que les implémentations de ce code, y compris dans les logiciels open source ou Shareware, peuvent nécessiter des licences de brevet des détenteurs de brevets concernés.

Notez que le tableau ci-dessus ne répertorie pas les exigences de débit binaire spécifiques pour la plupart des codecs vidéo. La raison en est qu'en pratique, le matériel de périphérique actuel ne prend pas nécessairement en charge les débits binaires qui mappent exactement aux débits binaires requis spécifiés par les normes pertinentes. Au lieu de cela, les implémentations de périphériques devraient prendre en charge le débit binaire le plus élevé sur le matériel, jusqu'aux limites définies par les spécifications.

6.2. Enregistrement audio

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

• Le traitement de réduction du bruit, s'il est présent, doit être désactivé.
• Le contrôle automatique du gain, s'il est présent, doit être désactivé.
• L'appareil doit présenter des caractéristiques d'amplitude approximativement plates en fonction de la fréquence; Plus précisément, ± 3 dB, de 100 Hz à 4000 Hz
• La sensibilité à l'entrée audio doit être définie de telle sorte qu'une source de niveau de puissance sonore (SPL) de 90 dB à 1000 Hz donne un RMS de 5000 pour des échantillons 16 bits.
• Les niveaux d'amplitude PCM doivent suivre linéairement les modifications de SPL d'entrée sur au moins une plage de 30 dB de -18 dB à +12 dB RE 90 dB SPL au microphone.
• La distorsion harmonique totale doit être inférieure à 1% de 100 Hz à 4000 Hz à un niveau d'entrée SPL de 90 dB.

Remarque: Bien que les exigences décrites ci-dessus soient indiquées comme "devraient" pour Android 2.2, la définition de compatibilité pour une future version est prévue pour les changer en "Must". Autrement dit, ces exigences sont facultatives dans Android 2.2 mais seront nécessaires par une future version. Les appareils existants et nouveaux qui exécutent Android 2.2 Android sont très fortement encouragés à répondre à ces exigences dans Android 2.2 , ou ils ne pourront pas atteindre la compatibilité Android lorsqu'ils sont mis à niveau vers la future version.

6.3. Latence audio

La latence audio est largement définie comme l'intervalle entre lorsqu'une application demande une lecture audio ou une opération d'enregistrement, et lorsque l'implémentation de l'appareil commence réellement l'opération. De nombreuses classes d'applications reposent sur de courtes latences pour réaliser des effets en temps réel tels que des effets sonores ou une communication VOIP. Les implémentations de l'appareil doivent répondre à toutes les exigences de latence audio décrites dans cette section.

Aux fins de cette section :

• "La latence de sortie de froid" est définie comme étant l'intervalle entre le moment où une application demande la lecture audio et quand le son commence à jouer, lorsque le système audio a été inactif et alimenté avant la demande
• "La latence de sortie chaude" est définie comme étant l'intervalle entre le moment où une application demande la lecture audio et quand le son commence à jouer, lorsque le système audio a été récemment utilisé mais est actuellement inactif (c'est-à-dire silencieux)
• La "latence de sortie continue" est définie comme étant l'intervalle entre le moment où une application émet un échantillon à jouer et lorsque l'orateur joue physiquement le son correspondant, tandis que l'appareil est actuellement en arrière
• La "latence d'entrée à froid" est définie comme étant l'intervalle entre le moment où une application demande l'enregistrement audio et lorsque le premier échantillon est livré à l'application via son rappel, lorsque le système audio et le microphone ont été inactifs et alimentés avant la demande
• La "latence d'entrée continue" est définie comme lorsqu'un son ambiant se produit et lorsque l'échantillon correspondant à ce son est livré à une application d'enregistrement via son rappel, tandis que l'appareil est en mode d'enregistrement

En utilisant les définitions ci-dessus, les implémentations de périphériques devraient présenter chacune de ces propriétés:

• latence de sortie à froid de 100 millisecondes ou moins
• latence de sortie chaude de 10 millisecondes ou moins
• latence de sortie continue de 45 millisecondes ou moins
• latence d'entrée à froid de 100 millisecondes ou moins
• latence d'entrée continue de 50 millisecondes ou moins

Remarque: Bien que les exigences décrites ci-dessus soient indiquées comme "devraient" pour Android 2.2, la définition de compatibilité pour une future version est prévue pour les changer en "Must". Autrement dit, ces exigences sont facultatives dans Android 2.2 mais seront nécessaires par une future version. Les appareils existants et nouveaux qui exécutent Android 2.2 Android sont très fortement encouragés à répondre à ces exigences dans Android 2.2 , ou ils ne pourront pas atteindre la compatibilité Android lorsqu'ils sont mis à niveau vers la future version.

7. Compatibilité des outils du développeur

Les implémentations de périphériques doivent prendre en charge les outils de développeur Android fourni dans le SDK Android. Plus précisément, les appareils compatibles Android doivent être compatibles avec:

• Android Debug Bridge (connu sous le nom de BAD) [ Ressources, 19 ]
  Les implémentations de périphériques doivent prendre en charge toutes les fonctions adb comme documentée dans le SDK Android. Le démon adb côté périphérique doit être inactif par défaut, mais il doit y avoir un mécanisme accessible à l'utilisateur pour activer le pont de débogage Android.
• Dalvik Debug Monitor Service (connu sous le nom de DDMS) [ Ressources, 19 ]
  Les implémentations de périphériques doivent prendre en charge toutes les fonctionnalités ddms comme documentée dans le SDK Android. Comme ddms utilise adb , la prise en charge ddms doit être inactive par défaut, mais doit être prise en charge chaque fois que l'utilisateur a activé le pont de débogage Android, comme ci-dessus.
• Singe [ ressources, 22 ]
  Les implémentations de l'appareil doivent inclure le cadre de singe et les rendre disponibles pour les applications à utiliser.

8. Compatibilité matérielle

Android est destiné à prendre en charge les implémenteurs de périphériques créant des facteurs et des configurations de formulaires innovants. Dans le même temps, les développeurs Android s'attendent à ce que certains matériels, capteurs et API sur tous les périphériques Android. Cette section répertorie les fonctionnalités matérielles que tous les appareils compatibles Android 2.2 doivent prendre en charge.

Si un appareil comprend un composant matériel particulier qui a une API correspondante pour les développeurs tiers, l'implémentation de l'appareil doit implémenter cette API telle que définie dans la documentation Android SDK. Si une API du SDK interagit avec un composant matériel qui est indiqué comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant:

• Les définitions de classe des API du composant doivent être présentes
• Les comportements de l'API doivent être mis en œuvre comme non optionnels d'une manière raisonnable
• Les méthodes de l'API doivent renvoyer les valeurs nulles là où la documentation du SDK
• Les méthodes API doivent renvoyer les implémentations sans opération de classes où les valeurs nulles ne sont pas autorisées par la documentation SDK

Un exemple typique d'un scénario où ces exigences s'appliquent est l'API de téléphonie: même sur les dispositifs non téléphoniques, ces API doivent être implémentées en tant que non-opérations raisonnables.

Les implémentations de périphériques doivent signaler avec précision les informations précises de configuration matérielle via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) sur la classe android.content.pm.PackageManager . [ Ressources, 23 ]

8.1. Afficher

Android 2.2 comprend des installations qui effectuent certaines opérations de mise à l'échelle et de transformation automatique dans certaines circonstances, pour s'assurer que les applications tierces s'exécutent assez bien sur une variété de configurations matérielles [ Resources, 24 ]. Les appareils doivent implémenter correctement ces comportements, comme détaillé dans cette section.

Pour Android 2.2, ce sont les configurations d'affichage les plus courantes:

Les implémentations de périphériques correspondant à l'une des configurations standard ci-dessus doivent être configurées pour signaler la taille de l'écran indiquée aux applications via la classe android.content.res.Configuration [ Resources, 24 ].

Certains packages .APK ont des manifestes qui ne les identifient pas comme soutenant une plage de densité spécifique. Lors de l'exécution de ces applications, les contraintes suivantes s'appliquent:

• Les implémentations de dispositifs doivent interpréter les ressources dans un .APK qui n'ont pas de qualification de densité comme défaut en "Medium" (appelé "MDPI" dans la documentation SDK.)
• Lorsque vous fonctionnez sur un écran de densité "faible", les implémentations de l'appareil doivent réduire les actifs moyens / MDPI d'un facteur de 0,75.
• Lorsque vous opérez sur un écran de densité "élevé", les implémentations de l'appareil doivent augmenter les actifs moyens / MDPI d'un facteur de 1,5.
• Les implémentations des appareils ne doivent pas mettre à l'échelle des actifs dans une plage de densité et doivent mettre à l'échelle les actifs par exactement ces facteurs entre les gammes de densité.

8.1.2. Configurations d'affichage non standard

Afficher les configurations qui ne correspondent pas à l'une des configurations standard répertoriées dans la section 8.1.1 nécessitent une considération et un travail supplémentaires pour être compatibles. Les implémenteurs de périphériques doivent contacter l'équipe de compatibilité Android comme décrit dans la section 13 pour obtenir des classifications pour le seau, la densité et le facteur de mise à l'échelle de la taille d'un écran. Lorsqu'ils sont fournis avec ces informations, les implémentations de périphériques doivent les implémenter comme spécifié.

Notez que certaines configurations d'affichage (telles que des écrans très grands ou très petits, et certains ratios d'aspect) sont fondamentalement incompatibles avec Android 2.2; Par conséquent, les implémenteurs de périphériques sont encouragés à contacter l'équipe de compatibilité Android le plus tôt possible dans le processus de développement.

8.1.3. Afficher les mesures

Les implémentations de périphériques doivent signaler les valeurs correctes pour toutes les mesures d'affichage définies dans android.util.DisplayMetrics [ Resources, 26 ].

8.1.4. Prise en charge de l'écran déclaré

Les applications peuvent indiquer les tailles d'écran qu'elles prennent en charge via l'attribut <supports-screens> dans le fichier AndroidManifest.xml. Les implémentations de l'appareil doivent honorer correctement la prise en charge indiquée des applications pour les petits, moyens et grands écrans, comme décrit dans la documentation du SDK Android.

8.2. Clavier

Implémentations d'appareils :

• Doit inclure la prise en charge du cadre de gestion des entrées (qui permet aux développeurs tiers de créer des moteurs de gestion des entrées - c'est-à-dire un clavier souple) comme détaillé sur Developer.Android.com
• Doit fournir au moins une implémentation du clavier souple (peu importe si un clavier dur est présent)
• Peut inclure des implémentations de clavier souples supplémentaires
• Peut inclure un clavier matériel
• Ne doit pas inclure un clavier matériel qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard [ Resources, 25 ] (c'est-à-dire Qwerty ou 12 key)

8.3. Navigation sans contact

Implémentations d'appareils :

• Peut omettre une option de navigation non touchée (c'est-à-dire peut omettre un trackball, un d-pad ou une roue)
• Doit signaler la valeur correcte pour android.content.res.Configuration.navigation [ Resources, 25 ]

8.4. Orientation de l'écran

Les dispositifs compatibles doivent prendre en charge l'orientation dynamique par applications à l'orientation du portrait ou du paysage. C'est-à-dire que l'appareil doit respecter la demande de l'application pour une orientation d'écran spécifique. Les implémentations de l'appareil peuvent sélectionner l'orientation du portrait ou du paysage par défaut.

Les périphériques doivent signaler la valeur correcte de l'orientation actuelle de l'appareil, chaque fois que vous êtes interrogé via le android.content.res.configuration.orientation, Android.view.display.getOrientation (), ou d'autres API.

8.5. Entrée à l'écran tactile

Implémentations d'appareils :

• Doit avoir un écran tactile
• Peut avoir un écran tactile capacatif ou résistif
• Doit signaler la valeur de android.content.res.Configuration [ Ressources, 25 ] reflétant correspondant au type de l'écran tactile spécifique sur l'appareil
• Devrait prendre en charge les pointeurs entièrement suivis indépendamment, si l'écran tactile prend en charge plusieurs pointeurs

8.6. USB

Implémentations d'appareils :

• Doit implémenter un client USB, connecté à un hôte USB avec un port USB-A standard
• Doit implémenter le pont de débogage Android sur l'USB (comme décrit dans la section 7)
• Doit implémenter la spécification de stockage de masse USB, pour permettre à un hôte connecté à l'appareil d'accéder au contenu du volume / sdcard
• Devrait utiliser le facteur de forme micro USB côté périphérique
• Peut inclure un port non standard côté périphérique, mais si c'est le cas, il faut expédier avec un câble capable de connecter le Pinout personnalisé au port USB-A standard
• Doit implémenter la prise en charge de la spécification de stockage de masse USB (afin que le stockage amovible ou fixe sur l'appareil soit accessible à partir d'un PC hôte)

8.7. Touches de navigation

Les fonctions à domicile, à menu et à dos sont essentielles au paradigme de navigation Android. Les implémentations de l'appareil doivent rendre ces fonctions à la disposition de l'utilisateur à tout moment, quel que soit l'état d'application. Ces fonctions doivent être implémentées via des boutons dédiés. Ils peuvent être mis en œuvre à l'aide de logiciels, de gestes, de panneaux tactiles, etc., mais si c'est le cas, ils doivent toujours être accessibles et non obscurs ou interférer avec la zone d'affichage de l'application disponible.

Les implémenteurs de périphériques doivent également fournir une clé de recherche dédiée. Les implémenteurs de périphériques peuvent également fournir des clés d'envoi et de fin pour les appels téléphoniques.

8.8. Réseau de données sans fil

Les implémentations de périphériques doivent inclure la prise en charge du réseau de données à grande vitesse sans fil. Plus précisément, les implémentations de périphériques doivent inclure la prise en charge d'au moins une norme de données sans fil capable de 200kbit / sec ou plus. Des exemples de technologies qui satisfont à cette exigence comprennent Edge, HSPA, EV-DO, 802.11g, etc.

Si une implémentation de périphérique comprend une modalité particulière pour laquelle le SDK Android comprend une API (c'est-à-dire WiFi, GSM ou CDMA), l'implémentation doit prendre en charge l'API.

Les appareils peuvent implémenter plus d'une forme de connectivité de données sans fil. Les appareils peuvent implémenter la connectivité des données filaires (comme Ethernet), mais doivent néanmoins inclure au moins une forme de connectivité sans fil, comme ci-dessus.

8.9. Caméra

Les implémentations de l'appareil doivent inclure une caméra orientée vers l'arrière. La caméra arrière incluse:

• Doit avoir une résolution d'au moins 2 mégapixels
• Devrait avoir le matériel automatique du matériel, soit un logiciel automatique implémenté dans le pilote de la caméra (transparent vers le logiciel d'application)
• Peut avoir une mise à pied fixe ou un matériel EDOF (profondeur de champ étendue)
• Peut inclure un flash. Si l'appareil photo comprend un flash, la lampe flash ne doit pas être éclairée tandis qu'une instance Android.Hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de l'appareil photo, à moins que l'application ait explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un Camera.Parameters OBJET. Notez que cette contrainte ne s'applique pas à l'application de caméra système intégrée de l'appareil, mais uniquement aux applications tierces à l'aide de Camera.PreviewCallback .

Les implémentations de périphériques doivent implémenter les comportements suivants pour les API liées à la caméra:

1. Si une application n'a jamais appelé Android.Hardware.Camera.Parameters.SetPreViewFormat (INT), le périphérique 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 dans le format d'octet [] dans OnPreViewFrame () doivent être en outre dans le format d'encodage NV21. (Il s'agit du format utilisé nativement par la famille de matériel 7k.) C'est-à-dire que NV21 doit être la valeur par défaut.

Les implémentations de périphériques doivent implémenter l'API de la caméra complète incluse dans la documentation SDK Android 2.2 [ Ressources, 27 ]), que le périphérique comprenne une autofocus matérielle ou d'autres capacités. Par exemple, les caméras qui manquent d'autofocus doivent toujours appeler toutes les instances android.hardware.Camera.AutoFocusCallback (même si cela n'a aucune pertinence pour une caméra non autofocus.)

Les implémentations de périphériques doivent reconnaître et honorer chaque nom de paramètre défini comme une constante sur la classe android.hardware.Camera.Parameters , si le matériel sous-jacent prend en charge la fonctionnalité. Si le matériel de l'appareil ne prend pas en charge une fonctionnalité, l'API doit se comporter comme documentée. À l'inverse, les implémentations de périphériques ne doivent pas honorer ou reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() autres que celles documentées comme constantes sur android.hardware.Camera.Parameters . Autrement dit, les implémentations de périphériques doivent prendre en charge tous les paramètres de caméra standard si le matériel le permet et ne doit pas prendre en charge les types de paramètres de caméra personnalisés.

Les implémentations de l'appareil peuvent inclure une caméra frontale. Cependant, si une implémentation de périphérique comprend une caméra frontale, l'API de la caméra telle qu'implémentée sur l'appareil ne doit pas utiliser la caméra frontale par défaut. Autrement dit, l'API de la caméra dans Android 2.2 est destiné uniquement aux caméras orientées vers l'arrière, et les implémentations de l'appareil ne doivent pas réutiliser ou surcharger l'API pour agir sur une caméra frontale, si l'on est présent. Notez que toutes les API personnalisées ajoutées par les implémenteurs de périphériques pour prendre en charge les caméras frontales doivent respecter les sections 3.5 et 3.6; Par exemple, si une sous-classe android.hardware.Camera ou Camera.Parameters est fournie pour prendre en charge les caméras frontales, elle ne doit pas être située dans un espace de noms existant, comme décrit par les sections 3.5 et 3.6. Notez que l'inclusion d'une caméra frontale ne répond pas aux exigences selon lesquelles les appareils incluent une caméra orientée vers l'arrière.

8.10. Accéléromètre

Les implémentations de l'appareil doivent inclure un accéléromètre à 3 axes et doivent être capables de livrer des événements à 50 Hz ou plus. Le système de coordonnées utilisé par l'accéléromètre doit se conformer au système de coordonnées du capteur Android comme détaillé dans les API Android (voir [ Resources, 28 ]).

8.11. Boussole

Les implémentations de l'appareil doivent inclure une boussole à 3 axes et doivent être en mesure de livrer des événements 10 Hz ou plus. Le système de coordonnées utilisé par la boussole doit se conformer au système de coordonnées du capteur Android tel que défini dans l'API Android (voir [ Resources, 28 ]).

8.12. GPS

Les implémentations de l'appareil doivent inclure un récepteur GPS et doivent inclure une forme de technique "GPS assistée" pour minimiser l'heure de verrouillage GPS.

8.13. Téléphonie

Android 2.2 peut être utilisé sur des appareils qui n'incluent pas le matériel de téléphonie. Autrement dit, Android 2.2 est compatible avec des appareils qui ne sont pas des téléphones. Cependant, si une implémentation de périphérique inclut la téléphonie GSM ou CDMA, elle doit implémenter le support complet de l'API pour cette technologie. Les implémentations de périphériques qui n'incluent pas le matériel de téléphonie doivent implémenter les API complètes en tant que non-opérations.

Voir également la section 8.8, Réseautage de données sans fil.

8.14. Mémoire et stockage

Les implémentations de l'appareil doivent avoir au moins 92 Mo de mémoire disponibles pour le noyau et l'espace utilisateur. Le 92 Mo doit s'ajouter à toute mémoire dédiée aux composants matériels tels que la radio, la mémoire, etc., ce n'est pas sous le contrôle du noyau.

Les implémentations de l'appareil doivent avoir au moins 150 Mo de stockage non volatile disponible pour les données utilisateur. C'est-à-dire que la partition /data doit être d'au moins 150 Mo.

Au-delà des exigences ci-dessus, les implémentations de périphériques devraient avoir au moins 128 Mo de mémoire disponible pour le noyau et l'espace utilisateur, en plus de toute mémoire dédiée aux composants matériels qui ne sont pas sous le contrôle du noyau. Les implémentations de l'appareil doivent avoir au moins 1 Go de stockage non volatile disponible pour les données utilisateur. Notez que ces exigences plus élevées sont prévues pour devenir des minimums difficiles dans une future version d'Android. Les implémentations des appareils sont fortement encouragées à répondre à ces exigences maintenant, sinon elles peuvent ne pas être éligibles à la compatibilité d'une future version d'Android.

8.15. Stockage partagé de l'application

Les implémentations de l'appareil doivent offrir un stockage partagé pour les applications. Le stockage partagé fourni doit avoir une taille d'au moins 2 Go.

Les implémentations de périphérique doivent être configurées avec un stockage partagé monté par défaut, "Out of the Box". Si le stockage partagé n'est pas monté sur le chemin Linux /sdcard , le périphérique doit inclure un lien symbolique Linux de /sdcard au point de montage réel.

Les implémentations de périphérique doivent appliquer comme documenté android.permission.WRITE_EXTERNAL_STORAGE sur ce stockage partagé. Le stockage partagé doit autrement être écrit par toute application qui obtient cette autorisation.

Les implémentations de l'appareil peuvent avoir du matériel pour un stockage amovible accessible aux utilisateurs, comme une carte numérique sécurisée. Alternativement, les implémentations de périphériques peuvent allouer le stockage interne (non amovible) en tant que stockage partagé pour les applications.

Quelle que soit la forme du stockage partagé utilisé, le stockage partagé doit implémenter un stockage de masse USB, comme décrit dans la section 8.6. Comme expédié de la boîte, le stockage partagé doit être monté avec le système de fichiers FAT.

Il est illustratif de considérer deux exemples courants. Si une implémentation de l'appareil comprend un emplacement de carte SD pour satisfaire l'exigence de stockage partagé, une carte SD à format gras 2 Go de taille ou plus doit être incluse avec l'appareil comme les utilisateurs et doit être monté par défaut. Alternativement, si une implémentation de périphérique utilise un stockage fixe interne pour satisfaire cette exigence, ce stockage doit être de 2 Go de taille ou plus, formaté en graisse et monté sur /sdcard (ou /sdcard doit être un lien symbolique vers l'emplacement physique s'il est monté ailleurs.)

Les implémentations de périphériques qui incluent plusieurs chemins de stockage partagées (telles qu'un emplacement de carte SD et un stockage interne partagé) devraient modifier les applications de base telles que le scanner multimédia et le contenuProvider pour prendre en charge transparente les fichiers placés dans les deux endroits.

8.16. Bluetooth

Les implémentations de l'appareil doivent inclure un émetteur-récepteur Bluetooth. Les implémentations de périphériques doivent activer l'API Bluetooth basée sur RFCOMM comme décrit dans la documentation SDK [ Resources, 30 ]. Les implémentations de périphériques doivent implémenter les profils Bluetooth pertinents, tels que A2DP, AVRCP, OBEX, etc., le cas échéant pour l'appareil.

La suite de test de compatibilité comprend des cas qui couvrent le fonctionnement de base de l'API Bluetooth Android RFCOMM. Cependant, comme Bluetooth est un protocole de communication entre les appareils, il ne peut pas être entièrement testé par des tests unitaires fonctionnant sur un seul appareil. Par conséquent, les implémentations de l'appareil doivent également passer la procédure de test Bluetooth basée sur l'homme décrite à l'annexe A.

9. Compatibilité des performances

L'un des objectifs du programme de compatibilité Android est de permettre une expérience d'application cohérente aux consommateurs. Les implémentations compatibles doivent garantir non seulement que les applications s'exécutent simplement correctement sur l'appareil, mais qu'elles le font avec des performances raisonnables et une bonne expérience utilisateur globale. Les implémentations de l'appareil doivent respecter les mesures de performances clés d'un périphérique compatible Android 2.2 défini dans le tableau ci-dessous:

10. Compatibilité du modèle de sécurité

Les implémentations de périphériques doivent implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android tel que défini dans la sécurité et le document de référence des autorisations dans les API [ Resources, 29 ] dans la documentation du développeur Android. Les implémentations de l'appareil doivent prendre en charge l'installation d'applications auto-signées sans nécessiter d'autorisations / certificats supplémentaires à des tiers / autorités. Plus précisément, les dispositifs compatibles doivent prendre en charge les mécanismes de sécurité décrits dans les sous-sections suivantes.

10.1. Autorisations

Les implémentations de périphériques doivent prendre en charge le modèle des autorisations Android telles que définies dans la documentation du développeur Android [ Resources, 29 ]. Plus précisément, les implémentations doivent appliquer chaque autorisation définie comme décrit dans la documentation SDK; Aucune autorisation ne peut être omise, modifiée ou ignorée. Les implémentations peuvent ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne soient pas dans l'espace de noms Android.

10.2. UID et isolement de processus

Les implémentations de périphériques doivent prendre en charge le modèle de sandbox de l'application Android, dans laquelle chaque application s'exécute comme un UID de style Unix unique et dans un processus distinct. Les implémentations de périphériques doivent prendre en charge l'exécution de plusieurs applications en tant que même ID utilisateur Linux, à condition que les applications soient correctement signées et construites, telles que définies dans la référence de sécurité et les autorisations [ Resources, 29 ].

10.3. Autorisations du système de fichiers

Les implémentations de périphériques doivent prendre en charge le modèle d'autorisations d'accès aux fichiers Android tel que défini comme défini dans la référence de sécurité et les autorisations [ Resources, 29 ].

10.4. Environnements d'exécution alternatifs

Les implémentations de périphériques peuvent inclure des environnements d'exécution qui exécutent des applications à l'aide d'un autre logiciel ou technologie que la machine virtuelle Dalvik ou le code natif. Cependant, ces environnements d'exécution alternatifs ne doivent pas compromettre le modèle de sécurité Android ou la sécurité des applications Android installées, comme décrit dans cette section.

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

Les temps d'exécution alternatifs ne doivent pas avoir accès aux ressources protégées par les autorisations non demandées dans le fichier AndroidManifest.xml de l'exécution via le mécanisme <uses-permission> .

Les temps d'exécution alternatifs ne doivent pas permettre aux demandes d'utiliser des fonctionnalités protégées par les autorisations Android restreintes aux applications système.

Des temps d'exécution alternatifs doivent respecter le modèle Android Sandbox. Spécifiquement:

• Les cours d'exécution alternatifs devraient installer des applications via le PackageManager dans des bacs de sable Android séparés (c'est-à-dire des ID utilisateur Linux, etc.)
• Des temps d'exécution alternatifs peuvent fournir un seul bac à sable Android partagé par toutes les applications à l'aide de l'exécution alternative.
• Des temps d'exécution alternatifs et des applications installées à l'aide d'un autre temps d'exécution ne doivent pas réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standard de l'ID utilisateur partagé et du certificat de signature
• Les cours d'exécution alternatifs ne doivent pas être lancés avec, accorder ou avoir accès aux bacs à sable correspondant à d'autres applications Android.

Des temps d'exécution alternatifs ne doivent pas être lancés, être accordés ou accorder à d'autres demandes de privilèges du superutilisateur (racine) ou de tout autre ID utilisateur.

Les fichiers .APK des temps d'exécution alternatifs peuvent être inclus dans l'image système d'une implémentation de périphérique, mais doivent être signés avec une clé distincte de la clé utilisée pour signer d'autres applications incluses avec l'implémentation de l'appareil.

Lors de l'installation d'applications, les temps d'exécution alternatifs doivent obtenir le consentement des utilisateurs pour les autorisations Android utilisées par l'application. Autrement dit, si une application doit utiliser une ressource d'appareil pour laquelle il y a une autorisation Android correspondante (comme la caméra, le GPS, etc.), l'exécution alternative doit informer l'utilisateur que l'application pourra accéder à cette ressource . Si l'environnement d'exécution n'enregistre pas les capacités d'application de cette manière, l'environnement d'exécution doit répertorier toutes les autorisations détenues par le runtime lui-même lors de l'installation d'une application en utilisant ce runtime.

11. Suite de test de compatibilité

Les implémentations de l'appareil doivent passer la suite de tests de compatibilité Android (CTS) [ Ressources, 2 ] disponibles à partir du projet Open Source Android, en utilisant le logiciel d'expédition final sur l'appareil. De plus, les implémenteurs de périphériques doivent utiliser autant que possible l'implémentation de référence dans l'arbre open source Android et doivent assurer la compatibilité des cas d'ambiguïté dans CTS et pour toute réimplémentation des parties du code source de référence.

Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bogues. Le CTS sera versé indépendamment de cette définition de compatibilité, et plusieurs révisions du CTS peuvent être publiées pour Android 2.2. Les implémentations de l'appareil doivent passer la dernière version CTS disponible au moment où le logiciel de périphérique est terminé.

12. Logiciel de mise à jour

Les implémentations de l'appareil doivent inclure un mécanisme pour remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer des mises à niveau "en direct" - c'est-à-dire qu'un redémarrage de l'appareil peut être nécessaire.

Toute méthode peut être utilisée, à condition qu'il puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes satisfera à cette exigence:

• Téléchargements en direct (OTA) avec mise à jour hors ligne via le redémarrage
• Mises à jour "attachés" sur USB à partir d'un PC hôte
• "Offline" mise à jour via un redémarrage et mise à jour à partir d'un fichier sur un stockage amovible

Le mécanisme de mise à jour utilisé doit prendre en charge les mises à jour sans essuyer les données utilisateur. Notez que le logiciel Android en amont comprend un mécanisme de mise à jour qui satisfait à cette exigence.

Si une erreur est trouvée dans une implémentation de dispositif après sa sortie, mais dans sa durée de vie raisonnable de produit déterminée en consultation avec l'équipe de compatibilité Android pour affecter la compatibilité des applications Thid-Parts, l'implémentateur de périphérique doit corriger l'erreur via un logiciel Mise à jour disponible qui peut être appliquée par le mécanisme qui vient d'être décrit.

13. Contactez-nous

Vous pouvez contacter les auteurs de documents à compatibilité@android.com pour des clarifications et pour soulever tous les problèmes que vous pensez que le document ne couvre pas.

Annexe A - Procédure de test Bluetooth

La suite de test de compatibilité comprend des cas qui couvrent le fonctionnement de base de l'API Bluetooth Android RFCOMM. Cependant, comme Bluetooth est un protocole de communication entre les appareils, il ne peut pas être entièrement testé par des tests unitaires fonctionnant sur un seul appareil. Par conséquent, les implémentations de l'appareil doivent également passer la procédure de test Bluetooth basée sur l'homme décrit ci-dessous.

La procédure de test est basée sur l'application d'échantillon BluetoothChat incluse dans l'arborescence du projet open-source Android. La procédure nécessite deux appareils:

• une implémentation de candidature candidate exécutant la version logicielle à tester
• Une implémentation de périphérique distincte déjà connue pour être compatible et d'un modèle de la mise en œuvre de l'appareil en cours d'implémentation

La procédure de test ci-dessous fait référence à ces appareils comme les appareils "candidat" et "connu", respectivement.

Configuration et installation

1. Construire bluetoothchat.apk via «faire des échantillons» à partir d'une arborescence de code source Android.
2. Installez Bluetoothchat.apk sur l'appareil connu.
3. Installez Bluetoothchat.apk sur l'appareil candidat.

Tester le contrôle Bluetooth par les applications

1. Lancez BluetoothChat sur l'appareil candidat, tandis que Bluetooth est désactivé.
2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

Test Pairing and Communication

1. Launch the Bluetooth Chat app on both devices.
2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
5. Close the BluetoothChat app on both devices by pressing Home .
6. Unpair each device from the other, using the device Settings app.

Test Pairing and Communication in the Reverse Direction

1. Launch the Bluetooth Chat app on both devices.
2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
4. Send 10 or messages from each device, and verify that the other device receives them correctly.
5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

Test Re-Launches

1. Re-launch the Bluetooth Chat app on both devices.
2. Send 10 or messages from each device, and verify that the other device receives them correctly.

Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.