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

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

Définition de la compatibilité avec Android 4.1

Définition de la compatibilité Android 4.1
Révision 3
Dernière mise à jour: 24 juin 2013
Copyright © 2012, Google Inc. Tous droits réservés.
compatibility@android.com
Table des matières
1. Introduction
2. Ressources
3. Logiciel
3.1. Compatibilité de l'API gérée
3.2. Compatibilité avec les API
3.2.1. Autorisations
3.2.2. Paramètres de compilation
3.2.3. Compatibilité des intents
3.2.3.1. Intents d'application principaux
3.2.3.2. Remplacements d'intent
3.2.3.3. Espaces de noms d'intent
3.2.3.4. Intents de diffusion
3.3. Compatibilité des API natives
3.3.1 Interfaces binaires d'application
3.4. Compatibilité Web
3.4.1. Compatibilité WebView
3.4.2. Compatibilité avec les navigateurs
3.5. Compatibilité comportementale des API
3.6. API Namespaces
3.7. Compatibilité des machines virtuelles
3.8. Compatibilité de l'interface utilisateur
3.8.1. Widgets
3.8.2. Notifications
3.8.3. Recherche
3.8.4. Toasts
3.8.5. Thèmes
3.8.6. Livres blancs
3 .8.7 Affichage des applications récentes
3.8.8. Gestion des entrées Paramètres
3.8.9. Contrôle à distance de l'écran de verrouillage
3.9 Device Administration
3.10 Accessibilité
3.11 Text-to-Speech
4. Compatibilité de l'empaquetage d'applications
5. Compatibilité multimédia
5.1. Codecs multimédias
5.2. Encodage vidéo
5.3. Enregistrement audio
5.4. Latence audio
5,5. Protocoles réseau
6. Compatibilité des outils de développement
7. Hacompatibilité matérielle
7.1. Écran et graphismes
7.1.1. Configuration de l'écran
7.1.2. Métriques
7.1.3 sur le Réseau Display. Orientation de l'écran
7.1.4. Accélération graphique 2D et 3D
7.1.5. Mode de compatibilité de l'ancienne application
7.1.6. Types d'écrans
7.1.7. Technologie d'écran
7.2. Dans Appareils
7.2.1. Clavier
7.2.2. Navigation sans contact
7.2.3. Touches de navigation
7.2.4. Saisies tactiles
7.2.5. Saisie tactile simulée
7.2.6. Microphone
7.3. Capteurs
7.3.1. Accéléromètre

7.3.1. Accéléromètre
7.3.2. Magnétomètre
7.3.3. GPS
7.3.4. Gyroscope
7.3.5. Baromètre
7.3.6. Thermomètre
7.3.7. Photomètre
7.3.8. Capteur de proximité
7.4. Connectivité des données
7.4.1. Téléphonie
7.4.2. IEEE 802.11 (Wi-Fi)
7.4.2.1. Wi-Fi Direct
7.4.3. Bluetooth
7.4.4. Communication en champ proche
7.4.5. Fonctionnalité réseau minimale
7.5. Cameras
7.5.1. Caméra arrière
7.5.2. Caméra avant
7.5.3. Comportement de l'API Camera
7.5.4. Orientation de l'appareil photo
7.6. Mémoire et stockage
7.6.1. Mémoire et stockage minimums
7.6.2. Shared Storage de l'application
7.7. USB
8. Compatibilité des performances
9. Compatibilité des modèles de sécurité
9.1. Autorisations
9.2. UID etisolation de processus
9.3. Autorisations de système de fichiers
9.4. Environnements d'exécution alternatifs
10. Tests de compatibilité des logiciels
10.1. Compatibility Test Suite
10.2. CTS Verifier
10.3. Applications de référence
11. ULogiciel pouvant être mis à jour
12. Contact Us
Annexe A - Procédure de test du Bluetooth

1. Introduction
Ce document énonce les exigences à respecter pour que les appareils
soient compatibles avec Android 4.1.
L'utilisation des mots "doit", "ne doit pas", "requis", "doit", "ne doit pas", "doit", "ne doit pas",
"recommandé", "peut" et "facultatif" est conforme à la norme IETF définie dans la RFC 2119
[Ressources, 1].
Dans ce document, un "implémentateur d'appareils" ou "implémentateur" désigne une personne ou une organisation qui développe une solution matérielle/logicielle exécutée sur Android 4.1.
Une "implémentation device
" ou "implémentation" est la solution matérielle/logicielle ainsi développée.
Pour être considérées comme compatibles avec Android 4.1, 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 au développeur de l'implémentation 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 l'implémentation 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 deviendra
considérablement plus difficile. Il incombe à l'implémentateur de garantir une compatibilité comportementale complète avec l'implémentation Android standard, y compris et au-delà de la Compatibility Test Suite.

Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par ce document.

2. Ressources
1.  Niveaux d'exigences de la RFC 2119 de l'IETF: http://www.ietf.org/rfc/rfc2119.txt
2.  Présentation du programme de compatibilité Android:
http://source.android.com/compatibility/index.html
3.  Projet Android Open Source: http://source.android.com/
4.  Définitions et documentation de l'API:
http://developer.android.com/reference/packages.html
5.  Documentation sur les autorisations Android:
http://developer.android.com/reference/android/Manifest.permission.html
6.  Documentation de référence android.os.Build:
http://developer.android.com/reference/android/os/Build.html
7.  Chaînes de version autorisées pour Android 4.1:
http://source.android.com/compatibility/4.1/versions.html
8.  Renderscript:
http://developer.android.com/guide/topics/graphics/renderscript.html
9.  Accélération matérielle:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
10.  Classe android.webkit.WebView:
http://developer.android.com/reference/android/webkit/WebView.html
11.  HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12.  Fonctionnalités hors connexion HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13.  Balise vidéo HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14.  API HTML5/Geolocation du W3C: http://www.w3.org/TR/geolocation-API/
15.  API de la base de données Web HTML5/W3C: http://www.w3.org/TR/webdatabase/
16.  API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
17.  Spécification de la machine virtuelle Dalvik: disponible dans le code source d'Android,à l'adresse
dalvik/docs
18.  AppWidgets:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19.  Notifications:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20.  Ressources d'application: http://code.google.com/android/reference/available-
resources.html
21.  Guide de style des icônes de la barre d'état:
http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22.  Gestionnaire de recherche:
http://developer.android.com/reference/android/app/SearchManager.html
23.  Toasts: http://developer.android.com/reference/android/widget/Toast.html
24.  Thèmes: http://developer.android.com/guide/topics/ui/themes.html

25.  Classe R.style: http://developer.android.com/reference/android/R.style.html
26.  Fonds d'écran animés: http://developer.android.com/resources/articles/live-
wallpapers.html
27.  Gestion des appareils Android:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  Classe android.app.admin.DevicePolicyManager:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  API Android Accessibility Service:
http://developer.android.com/reference/android/accessibilityservice/package-
summary.html
30.  API Android Accessibility:
http://developer.android.com/reference/android/view/accessibility/package-
summary.html
31.  Projet Eyes Free: http://code.google.com/p/eyes-free
32.  API Text-To-Speech:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.  Documentation de référence des outils (pour adb, aapt et dms):
http://developer.android.com/guide/developing/tools/index.html
34.  Description du fichier APK Android:
http://developer.android.com/guide/topics/fundamentals.html
35.  Fichiers manifestes: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36.  Outil de test du singe:
https://developer.android.com/studio/test/other-testing-tools/monkey
37.  Classe android.content.pm.PackageManager et fonctionnalités
de matériel:
http://developer.android.com/reference/android/content/pm/PackageManager.html
38.  Compatibilité avec plusieurs écrans:
http://developer.android.com/guide/practices/screens_support.html
39.  android.util.DisplayMetrics:
http://developer.android.com/reference/android/util/DisplayMetrics.html
40.  android.content.res.Configuration:
http://developer.android.com/reference/android/content/res/Configuration.html
41.  android.hardware.SensorEvent:
http://developer.android.com/reference/android/hardware/SensorEvent.html
42.  API Bluetooth:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43.  Protocole NDEF Push: http://source.android.com/compatibility/ndef-push-
protocol.pdf
44.  MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45.  MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46.  MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47.  MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48.  MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49.  MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50.  API d'orientation de l'appareil photo:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51.  android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52.  Android Open Accessories:
http://developer.android.com/guide/topics/usb/accessory.html
53.  API USB Host: http://developer.android.com/guide/topics/usb/host.html
54.  Documentation de référence sur la sécurité et les autorisations Android:
http://developer.android.com/guide/topics/security/security.html
55.  Applications pour Android: http://code.google.com/p/apps-for-android
56.  Classe android.app.DownloadManager:
http://developer.android.com/reference/android/app/DownloadManager.html
57.  Android File Transfer: http://www.android.com/filetransfer
58.  Formats multimédias Android: http://developer.android.com/guide/appendix/media-
formats.html
59.  Protocole Draft HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60.  Transfert de connexion NFC: http://www.nfc-
forum.org/specs/spec_list/#conn_handover
61.  Bluetooth Secure Simple Pairing Using NFC: http://www.nfc-
forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62.  API Wifi Multicast:
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

63.  Action Assist:
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64.  Spécification de recharge USB:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65.  Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66.  Audio USB Android:
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67.  Paramètres de partage NFC Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68.  Wifi Direct (Wifi P2P):
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69.  Client de contrôle à distance multimédia:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  API Motion Event:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  Configuration de la saisie tactile: http://source.android.com/tech/input/touch-
devices.html
De nombreuses ressources sont dérivées directement ou indirectement du SDK Android 4.1.
Elles 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é. Toutes les
informations techniques fournies dans les références ci-dessus sont considérées comme faisant partie de cette définition de compatibilité.

3. Logiciel
3.1. Compatibilité des API gérées
L'environnement d'exécution géré (basé sur Dalvik) est le principal moyen de transport pour les applications Android
. L'API Android est l'ensemble des
interfaces de la plate-forme Android exposées aux applications exécutées dans l'environnement de VM
gérée. 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
4.1 [Resources, 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 si cela est
spécifiquement autorisé par cette définition de compatibilité.

Cette définition de compatibilité permet d'omettre certaines implémentations d'appareils pour certains types de matériel pour lesquels Android
inclut des API. 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 souples
En plus des API gérées de la section 3.1, Android inclut également une API "soft" importante 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.

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 dans la classe android.os.Build
[Resources, 6] destinées à décrire l'appareil actuel. Pour fournir des valeurs cohérentes et
significatives pour toutes 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
conformer.
Paramètre
Commentaires
Version du système Android actuellement en cours d'exécution, au format lisible. Ce champ DOIT contenir une
android.os.Build.VERSION.RELEASE
parmi les valeurs de chaîne définies dans [Resources, 7].
Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers.
android.os.Build.VERSION.SDK
Pour Android 4.1, ce champ DOIT avoir la valeur entière 16.

Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers.
android.os.Build.VERSION.SDK_INT
Pour Android 4.1, ce champ DOIT avoir la valeur entière 16.
Valeur choisie par l'implémentateur de l'appareil pour désigner la version spécifique du système Android
actuellement en cours d'exécution, au format lisible par l'homme. Cette valeur NE DOIT PAS être réutilisée pour différentes versions mises à la disposition des utilisateurs finaux de
android.os.Build.VERSION.INCREMENTAL
. 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 doit
NE PAS être nul ni la chaîne vide ("").
Valeur choisie par l'implémentateur de l'appareil pour identifier le matériel interne spécifique utilisé par l'appareil, au format
lisible par l'homme. Vous pouvez utiliser ce champ pour indiquer la version spécifique de la carte alimentant
android.os.Build.BOARD
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.,_-]+$".
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. Vous pouvez utiliser ce champ pour indiquer l'OEM
android.os.Build.BRAND
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.,_-]+$".
Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Consultez la section 3.3: Compatibilité de l'API native
android.os.Build.CPU_ABI
.
Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Consultez la section 3.3: Compatibilité de l'API
android.os.Build.CPU_ABI2
I native.
Valeur choisie par l'implémentateur de l'appareil pour identifier la configuration ou la révision spécifique du corps
android.os.Build.DEVICE
(parfois appelé "design industriel") de 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.,_-]+$".
Chaîne qui identifie de manière unique cette version. Il DOIT être raisonnablement lisible par l'humain. Elle DOIT suivre ce
modèle:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Par exemple:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
L'empreinte digitale 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'espace vide
, ils DOIVENT être remplacés dans l'empreinte de compilation par un autre caractère, tel que le caractère
underscore ("_"). La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits.
Nom du matériel (à partir de la ligne de commande du noyau ou de /proc). Il DOIT être raisonnablement lisible par l'
android.os.Build.HARDWARE
humain. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-
A-Z0-9.,_-]+$".
Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'humain. Il n'existe aucune exigence
android.os.Build.HOST
concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
Identifiant choisi par l'implémentateur de l'appareil pour faire référence à une version spécifique, au format lisible par l'homme. Ce
champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment
android.os.Build.ID
pertinente pour que les utilisateurs finaux puissent distinguer les builds logiciels. 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.,_-]+$".
Nom commercial du fabricant d'équipement d'origine (OEM) du produit. Il n'existe aucune exigence concernant
android.os.Build.MANUFACTURER
le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
Valeur choisie par l'implémentateur de l'appareil contenant le nom de l'appareil tel que connu par l'utilisateur final.
ANDROID.OS.BUILD.MODEL
doit porter le même nom que celui sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Il n'existe aucune
exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code du produit
android.os.Build.PRODUCT
(SKU). DOIVENT être lisibles par l'humain, mais ne sont pas nécessairement destinés à être vus 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.,_-]+$".
Numéro de série matériel, le cas échéant. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à
android.os.Build.SERIAL
l'expression régulière "^([a-zA-Z0-9]{0,20})$".
Liste de balises choisies par l'implémentateur de l'appareil, séparées par une virgule, qui permet de distinguer davantage le build. Par exemple, pour
android.os.Build.TAGS
, "unsigned,debug". 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.TIME
Valeur représentant le code temporel de la compilation.
Valeur choisie par l'implémentateur de l'appareil spécifiant la configuration d'exécution du build. Ce champ
DOIT avoir l'une des valeurs correspondant aux trois configurations d'exécution Android typiques: "user",
android.os.Build.TYPE
"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.,_-]+$".
Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatisé) qui a généré le build. Aucune exigence n'est imposée
android.os.Build.USER
au 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
Les implémentations d'appareils DOIVENT respecter le système d'intents à couplage lâche d'Android, comme décrit dans les sections ci-dessous.

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
se lie à un comportement correct et l'implémente pour chaque modèle d'intent spécifié.
3.2.3.1. Intents d'application principaux
Le projet Android en amont définit un certain nombre d'applications principales, telles que les contacts,
l'agenda, la galerie photo, le 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 de base:
Horloge
Navigateur
Agenda
Contacts
Galerie
Recherche globale
Lanceur
Musique
Paramètres
Les applications système Android de base incluent divers composants d'activité ou de service
qui sont considérés comme "publics". C'est-à-dire que l'attribut "android:exported" peut être absent ou
peut avoir la valeur "true".
Pour chaque activité ou service défini dans l'une des applications système Android de base qui n'est pas
marquée comme non publique via un attribut android:exported avec la valeur "false", les implémentations
de l'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 de base.
En d'autres termes, une implémentation de l'appareil PEUT remplacer les applications système Android de base.
Toutefois, si tel est le cas, l'implémentation de l'appareil DOIT prendre en charge tous les modèles d'intent définis
par chaque application système Android de base remplacée.
3.2.3.2. Forcer des intents
Étant donné qu'Android est une plate-forme extensible, les implémentations d'appareils DOIVENT permettre à chaque modèle d'intent
référencé dans la section 3.2.3.2 d'être remplacé par des applications tierces. L'implémentation Open Source d'Android en amont permet cela par défaut. Les implémentateurs d'appareils NE DOIVENT PAS associer des privilèges 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, sans s'y limiter, la désactivation de l'interface utilisateur "Sélecteur", qui permet à l'utilisateur de choisir parmi plusieurs
applications qui gèrent le même modèle d'intent.

Toutefois, les implémentations d'appareils PEUVENT fournir des activités par défaut pour des modèles d'URI
spécifiques (par exemple, http://play.google.com) si l'activité par défaut fournit un filtre plus spécifique
pour l'URI des données. Par exemple, un filtre d'intent spécifiant l'URI de données
"http://www.android.com" est plus spécifique que le filtre du navigateur pour "http://". Les implémentations de l'
appareil doivent fournir une interface utilisateur permettant aux utilisateurs de modifier l'activité
par défaut pour les intents.
3.2.3.3. Espaces de noms d'intent
Les implémentations d'appareils NE DOIVENT PAS inclure de composant Android qui respecte
de nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une chaîne ACTION, CATEGORY ou autre clé
dans l'espace de noms android.* ou com.android.*. Les implémentateurs d'appareils NE DOIVENT PAS
inclure de composants Android qui respectent de nouveaux modèles d'intent ou d'intent de diffusion
à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans un espace de package appartenant à
une autre organisation. Les implémentateurs d'appareils NE DOIVENT PAS modifier ni étendre les modèles Intent
utilisés par les applications principales listées dans la section 3.2.3.1. Les implémentations d'appareils PEUVENT
inclure des modèles d'intent à l'aide de namespaces clairement et manifestement associés à leur
propre organisation.
Cette interdiction est semblable à celle spécifiée pour les classes de langage Java dans la section
3.6.
3.2.3.4. Intents de diffusion
Les applications tierces s'appuient sur la plate-forme pour diffuser certains intents afin de les informer

des modifications apportées à l'environnement matériel ou logiciel. Les appareils Android compatibles
DOIVENT diffuser les intents 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é des API natives
3.3.1 Interfaces binaires d'application
Le code géré exécuté dans Dalvik peut être converti en code natif fourni dans le fichier
.apk de l'application en tant que fichier ELF .so compilé pour l'architecture matérielle de l'appareil appropriée.
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.html. 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 est compatible avec une ABI Android, elle:
DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler du 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 signaler avec précision l'ABI (Application Binary Interface) natif 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 de surface OpenGL native)
libjnigraphics.so
libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
libOpenMAXAL.so (compatibilité OpenMAX AL 1.0.1)
libandroid.so (compatibilité avec l'activité Android native)
Compatibilité avec 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 un défi. C'est pourquoi nous insistons sur le fait que les implémentateurs d'appareils sont TRÈS vivement encouragés à utiliser les implémentations
en amont des bibliothèques listées ci-dessus pour assurer la compatibilité.

3.4. Compatibilité Web
3.4.1. Compatibilité avec WebView
L'implémentation Open Source 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
la version en amont spécifique de WebKit dans l'implémentation de WebView. Plus précisément:
Les implémentations android.webkit.WebView des implémentations de l'appareil DOIVENT
être basées sur la version 534.30 de WebKit à partir de l'arborescence Android Open Source en amont
pour Android 4.1. Cette version inclut un ensemble spécifique de corrections de fonctionnalités et de sécurité
pour WebView. Les implémentateurs d'appareils PEUVENT inclure des personnalisations dans l'implémentation de
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/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
La valeur de la chaîne $(VERSION) DOIT être identique à celle de

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 à la langue actuellement configurée
de l'appareil.
La valeur de la chaîne $(MODEL) DOIT être identique à celle de
android.os.Build.MODEL
La valeur de la chaîne $(BUILD) DOIT être identique à celle de
android.os.Build.ID
Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.
Le composant WebView DOIT prendre en charge autant que possible la spécification HTML5
[Ressources, 11].
Les implémentations d'appareils doivent au minimum prendre en charge chacune des
API associées à HTML5 dans la WebView:
cache d'application/opération hors connexion [Ressources, 12]
la balise <video> [Ressources, 13]
géolocalisation [Resources, 14]
En outre, les implémentations d'appareils doivent prendre en charge l'API webstorage HTML5/W3C
[Ressources, 15] et DEVRAIENT prendre en charge l'API IndexedDB HTML5/W3C [Ressources,
16]. Notez que, à mesure que les organismes de normalisation du développement Web passent à
IndexedDB au lieu de webstorage, IndexedDB devrait devenir un composant
obligatoire dans une future 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 générale des utilisateurs.
Le navigateur autonome PEUT être basé sur une technologie de navigateur
autre que WebKit. Cependant, 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 inclure la compatibilité avec autant de fonctionnalités
HTML5 [Ressources, 11] que possible.
À minimun, les implémentations d'appareils DOIVENT prendre en charge
chacune de ces API associées à HTML5:
cache d'application/opération hors connexion [Ressources, 12]
la balise <video> [Ressources, 13]
géolocalisation [Ressources, 14]
En outre, les implémentations d'appareils DOIVENT prendre en charge l'API webstorage HTML5/W3C
[Ressources, 15] et DOIVENT prendre en charge l'API IndexedDB HTML5/W3C [Ressources,
16]. 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 future version d'Android.
3.5. Compatibilité comportementale 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 ni la sémantique du cycle de vie d'un type particulier
de composant système (tels 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) teste
des parties importantes de la plate-forme pour vérifier sa compatibilité comportementale, mais pas toutes . Il est de la
responsabilité de l'implémentateur de garantir 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 de l'
appareil NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) à ces espaces de noms de package:
java.*
javax.*
sun.*
android.*
com.android.*

Les modifications interdites incluent:
Les implémentations de l'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, ni en supprimant des classes ou des champs de classe.
Les implémentateurs de l'appareil PEUVENT modifier l'implémentation sous-jacente des API, mais
ces modifications NE DOIVENT PAS avoir d'incidence sur le comportement déclaré et la signature en langage Java
de toute API exposée publiquement.
Les implémentateurs de l'appareil 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 des 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 de
d'appareil 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 y faisant référence. Par exemple, les implémentateurs d'
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), l'
implémentateur DOIT accéder à source.android.com et commencer le processus de contribution
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é avec les machines virtuelles
Les implémentations d'appareils DOIVENT prendre en charge la spécification complète du bytecode
Dalvik Executable (DEX) et la sémantique de la machine virtuelle Dalvik [Resources, 17].
Les implémentations d'appareils DOIVENT configurer Dalvik pour allouer de la mémoire conformément
à la plate-forme Android en amont et comme spécifié dans le tableau suivant. (Consultez la
section 7.1.1 pour connaître les définitions de la taille et de la densité d'écran.)
Notez que les valeurs de mémoire spécifiées ci-dessous sont considérées comme des valeurs minimales, et que l'implémentation de l'appareil peut ALLOUER PLUS DE MÉMOIRE PAR APPLICATION.

Taille de l'écran
Densité de l'écran
Mémoire de l'application
smal  / normal / large
ldpi / mdpi
16 Mo
smal  / normal / large
tvdpi / hdpi
32 Mo
smal  / normal / large
xhdpi
64 Mo
xlarge
mdpi
32 Mo
xlarge
tvdpi / hdpi
64 Mo
xlarge
xhdpi
128 Mo
3.8. Compatibilité de l'interface utilisateur
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, 18]. La version de référence Open Source d'
Android inclut une application de lanceur qui inclut des affordances d'interface utilisateur permettant à l'utilisateur d'ajouter, d'afficher et de supprimer des AppWidgets de l'
écran d'accueil.

Les implémentations de l'appareil PEUVENT remplacer le lanceur de référence (par exemple, l'
écran d'accueil). Les autres lanceurs DOIVENT inclure une prise en charge intégrée des AppWidgets
et exposer des affordances 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, si ces éléments sont omis, l'implémentation 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 widgets d'application.

Les implémentations d'appareils DOIVENT être capables d'afficher des widgets de 4 x 4 dans la taille de grille standard
. (Pour en savoir plus, consultez les consignes de conception des widgets d'application dans la documentation du SDK Android
[Ressources, 18].
3.8.2. Notifications
Android inclut des API qui permettent aux développeurs d'informer les utilisateurs d'événements notables
[Resources, 19], à l'aide des fonctionnalités matérielles et logicielles de l'appareil.
Certaines API permettent aux applications d'envoyer des notifications ou d'attirer l'attention à l'aide de matériel, en particulier du son, de la vibration et de la lumière.
Les implémentations d'appareils DOIVENT
prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK
, et dans la mesure du possible avec le matériel d'implémentation de l'appareil.
Par exemple, si une implémentation d'appareil inclut un vibreur, elle DOIT
implémenter correctement les API de vibration. Si une implémentation d'appareil ne dispose pas de matériel, les API
correspondantes DOIVENT être implémentées en tant que no-ops. Notez que ce comportement est
décrit plus en détail dans la section 7.
En outre, l'implémentation DOIT afficher correctement toutes les ressources (icônes, fichiers audio, etc.) fournies dans les API [Resources, 20] ou dans le guide de style des icônes de la barre d'état/système [Resources, 21].

Les implémentateurs d'appareils PEUVENT proposer une autre expérience utilisateur
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 4.1 est compatible avec les notifications enrichies, telles que les vues interactives pour les notifications en cours.
Les implémentations d'appareils DOIVENT afficher et exécuter correctement les notifications
enrichies, comme indiqué dans les API Android.
3.8.3. Recherche
Android inclut des API [Ressources, 22] 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.
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 fournir une recherche
dans leurs propres applications, et de fournir des résultats à l'interface utilisateur de recherche globale
commune.
Les implémentations d'appareils DOIVENT inclure une interface utilisateur de recherche unique, partagée et à l'échelle du système, capable de fournir des suggestions en temps réel en réponse à l'entrée utilisateur.
Les implémentations de
de l'appareil DOIVENT implémenter les API qui permettent aux développeurs de réutiliser cette interface utilisateur pour fournir une recherche dans leurs propres applications.
Les implémentations d'appareils
DOIVENT implémenter les API qui permettent aux applications tierces d'ajouter des suggestions au
champ de recherche lorsqu'il est exécuté en mode recherche globale. Si aucune application tierce n'est
installée et n'utilise cette fonctionnalité, le comportement par défaut DOIT être l'affichage des
résultats et des suggestions du moteur de recherche Web.
3.8.4. Toasts
Les applications peuvent utiliser l'API "Toast" (définie dans [Resources, 23]) pour afficher des chaînes courtes non modales
à l'utilisateur final, qui disparaissent après un court laps de temps. Les implémentations d'
de l'appareil DOIVENT afficher des toasts des applications aux utilisateurs finaux de manière très
visible.
3.8.5. Thèmes
Android fournit des "thèmes" comme mécanisme permettant aux applications d'appliquer des styles à l'ensemble d'une
activité ou d'une application. Android 3.0 a introduit un nouveau thème
"Holo" ou "holographique" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème Holo tel que défini par le SDK Android [Resources, 24].
Les implémentations de
de l'appareil NE DOIVENT PAS modifier les attributs du thème Holo exposés aux applications

[Resources, 25].
Android 4.0 a introduit un nouveau thème "Par défaut de l'appareil" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème de l'appareil tel que défini par l'implémentateur de l'appareil.

Les implémentations d'appareils PEUVENT modifier les attributs de thème
DeviceDefault exposés aux applications [Resources, 25].
3.8.6. 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, 26].
Les fonds d'écran animés sont des animations, des motifs ou des images similaires avec des fonctionnalités d'entrée 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 des fonds d'écran animés de manière fiable s'il peut exécuter tous les fonds d'écran
animés, sans aucune limitation de fonctionnalités, à une fréquence d'images raisonnable et sans
effet négatif sur d'autres applications. Si des limites matérielles entraînent le plantage, le dysfonctionnement, la consommation excessive de CPU ou de batterie, ou l'exécution à des fréquences d'images inacceptablement faibles des fonds d'écran
et/ou des applications, le matériel est considéré comme incapable d'exécuter un
fond d'écran dynamique.
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
ne prend pas en charge 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 dynamiques de manière fiable, comme décrit
ci-dessus, DOIVENT implémenter des fonds d'écran dynamiques. Les implémentations d'appareils déterminées comme ne pouvant pas
exécuter de manière fiable des fonds d'écran en direct, comme décrit ci-dessus, NE DOIVENT PAS implémenter de fonds d'écran en direct.
3.8.7. Affichage des applications récentes
Le code source Android 4.1 en amont inclut une interface utilisateur permettant d'afficher les applications récentes à l'aide d'une image miniature de l'état graphique de l'application au moment où l'utilisateur a quitté l'application pour la dernière fois.

Les implémentations d'appareils PEUVENT modifier ou
supprimer cette interface utilisateur. Toutefois, une future version d'Android est prévue pour
utiliser davantage cette fonctionnalité. Nous vous recommandons vivement d'utiliser l'interface utilisateur Android 4.1 en amont (ou une interface basée sur des miniatures similaire) pour les applications récentes. Sinon, elles risquent de ne pas être compatibles avec une
future version d'Android.

3.8.8. Paramètres de gestion des entrées
Android 4.1 est compatible avec les moteurs de gestion des entrées. Les API Android 4.1
permettent aux IME d'application personnalisés de spécifier des paramètres configurables par l'utilisateur. Les implémentations d'appareils
DOIVENT inclure un moyen pour l'utilisateur d'accéder aux paramètres de l'IME à tout moment lorsqu'un IME qui
fournit de tels paramètres utilisateur est affiché.
3.8.9. Télécommande de l'écran de verrouillage
Android 4.0 a introduit la prise en charge de l'API Remote Control, qui permet aux applications multimédias
de s'intégrer aux commandes de lecture affichées dans une vue à distance, comme l'écran de verrouillage de l'appareil
[Resources, 69]. Les implémentations d'appareils DOIVENT prendre en charge l'
intégration de commandes à distance sur l'écran de verrouillage de l'appareil.
3.9 Administration des appareils
Android 4.1 inclut des fonctionnalités qui permettent aux applications conscientes de la sécurité d'effectuer des fonctions d'administration des appareils au niveau du système, telles que l'application des règles relatives aux mots de passe ou l'effacement à distance, via l'API Android Device Administration [Resources,
27].

Les implémentations d'appareils DOIVENT fournir une implémentation de la classe
DevicePolicyManager [Resources, 28] et DOIVENT prendre en charge la gamme complète de
règles d'administration des appareils définies dans la documentation du SDK Android [Resources,
27].
Remarque:Certaines des exigences décrites ci-dessus sont indiquées comme "DÉSIRABLE" pour
Android 4.1. La définition de compatibilité d'une future version prévoit de remplacer ces
par "OBLIGATOIRE". C'est-à-dire que ces exigences sont facultatives dans Android 4.1, mais elles seront
obligatoires dans une future version. Nous recommandons vivement
aux appareils existants et nouveaux équipés d'Android 4.1 de respecter ces exigences dans Android 4.1, sans quoi ils ne seront pas
compatibles avec Android lors de la mise à niveau vers la future version.
3.10 Accessibilité
Android 4.1 fournit une couche d'accessibilité qui aide les utilisateurs handicapés à naviguer plus facilement sur leurs appareils.
En outre, Android 4.1 fournit des API de plate-forme qui permettent aux implémentations de services d'accessibilité

de recevoir des rappels pour les événements utilisateur et système
et de générer d'autres mécanismes de rétroaction, tels que la synthèse vocale, la rétroaction haptique
et la navigation avec le pavé tactile /le pavé directionnel [Resources, 29]. Lesimplémentations de l'appareil
DOIVENT fournir une implémentation du framework d'accessibilité Android cohérente
avec l'implémentation Android par défaut. Plus précisément, les implémentations d'appareils DOIVENT
respecter les exigences suivantes.
Les implémentations d'appareil DOIVENT prendre en charge les implémentations de services d'accessibilité tiers
via les API android.accessibilityservice [Resources,
30].
Les implémentations d'appareil DOIVENT générer des AccessibilityEvents et transmettre
ces événements à toutes les implémentations d'AccessibilityService enregistrées de manière
cohérente avec l'implémentation Android par défaut.
Les implémentations d'appareil DOIVENT fournir un mécanisme accessible à l'utilisateur pour activer
et désactiver les services d'accessibilité, et DOIVENT afficher cette interface en réponse
à l'intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
En outre, les implémentations d'appareils DOIVENT fournir une implémentation d'un
service d'accessibilité sur l'appareil et DOIVENT fournir un mécanisme permettant aux utilisateurs d'
activer le service d'accessibilité lors de la configuration de l'appareil. Une implémentation Open Source
d'un service d'accessibilité est disponible dans le projet Eyes Free [Ressources, 31].
3.11 Synthèse vocale
Android 4.1 inclut des API qui permettent aux applications d'utiliser les services de synthèse vocale (TTS)
et aux fournisseurs de services de fournir des implémentations de services de synthèse vocale
[Resources, 32]. Les implémentations d'appareils DOIVENT respecter ces exigences liées au framework Android TTS :
Les implémentations d'appareils DOIVENT prendre en charge les API du framework Android TTS et
DOIVENT inclure un moteur TTS compatible avec les langues disponibles sur l'
appareil.
Notez que le logiciel open source Android en amont inclut une implémentation de moteur TTS complète.
Les implémentations d'appareils DOIVENT prendre en charge l'installation de moteurs TTS tiers.
Les implémentations d'appareils DOIVENT fournir une interface accessible aux utilisateurs qui leur permet de sélectionner un moteur TTS à utiliser au niveau du système.

4. Compatibilité de l'empaquetage d'applications
Les implémentations d'appareils DOIVENT installer et exécuter les fichiers Android ".apk" générés par l'
outil "aapt" inclus dans le SDK Android officiel [Ressources, 33].
Les implémentations d'appareils NE DOIVENT PAS étendre les formats .apk [Resources, 34], Android
Manifest [Resources, 35], Dalvik bytecode [Resources, 17] ou bytecode renderscript
de manière à empêcher l'installation et l'exécution de ces fichiers de manière corrète
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 inclure au moins une forme de sortie audio, telle que
des haut-parleurs, une prise casque, une connexion d'enceintes externes, etc.
5.1. Codecs multimédias
Les implémentations d'appareils DOIVENT prendre en charge les principaux formats multimédias spécifiés dans la
documentation du SDK Android [Ressources, 58], sauf dans les cas explicitement autorisés dans ce
document. Plus précisément, les implémentations d'appareils DOIVENT prendre en charge les formats multimédias,les encodeurs, les décodeurs, les types de fichiers et les formats de conteneur définis dans les tableaux ci-dessous.
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 indiquant que ces codecs ne sont pas soumis à des brevets tiers.
Les personnes qui souhaitent utiliser ce code source dans des produits matériels ou logiciels sont informées que les implémentations de ce code, y compris dans des logiciels Open Source ou des sharewares, peuvent nécessiter des licences de brevets de la part des titulaires de brevets concernés.

Notez que ces tableaux ne répertorient pas les exigences de débit spécifiques pour la plupart des codecs vidéo
, car le matériel actuel des appareils n'est pas nécessairement compatible avec les débits qui correspondent
exactement aux débits requis spécifiés par les normes applicables. À la place, les implémentations d'appareils DOIVENT prendre en charge le débit le plus élevé possible sur le matériel, jusqu'à

les limites définies par les spécifications.

Type(s) de fichier /
Format /
Type
Encodage
Décodage
Détails
Conteneur
Codec
Formats
Compatibilité avec
OBLIGATOIRE
mono/stéréo/5.0/5.1*
MPEG-4
Obligatoire pour les implémentations d'appareils
contenu avec
Profil AAC
incluant du matériel de micro
OBLIGATOIRE
échantillonnage standard
(AAC LC)
et définir
3GPP
taux de 8 à 48
android.hardware.microphone.
(.3gp)
kHz.
MPEG-4
Compatibilité avec
(.mp4,
MPEG-4
mono/stéréo/5.0/5.1*
.m4a)
HE AAC
contenu avec
ADTS brut

OBLIGATOIRE
Profil
échantillonnage standard
AAC (.aac,
(AAC+)
taux de 16 à 48
décode en
kHz.
Android
3.1 ou version ultérieure,
Compatibilité avec
MPEG-4
OBLIGATOIRE pour l'encodage de l'appareil
en
mono/stéréo/5.0/5.1*
implémentations HE AAC v2
qui incluent
du contenu Android
avec
Profile
matériel de micro et

4.0 ou version ultérieure, échantillonnage standard ADIF
(amélioré
définir
pas
taux de 16 à 48
AAC+)
android.hardware.microphone
compatible)
kHz.

MPEG-TS
MPEG-4
(.ts, not
Audio
REQUIRED for device
Support for
seekable,
Object Type
implementations that include
mono/stereo content
Android
ER AAC
microphone hardware and
REQUIRED
with standard
3.0+)
ELD
define
sampling rates from
(Enhanced
android.hardware.microphone
16 to 48 kHz.
Low Delay
AAC)
OBLIGATOIRE
Obligatoire pour les implémentations d'appareils
4,75 à 12,2 kbit/s
AMR-NB
qui incluent du matériel de micro
OBLIGATOIRE
3GPP (.3gp)
échantillonné à 8 kHz
et définissent
android.hardware.microphone.
OBLIGATOIRE
Obligatoire pour les implémentations d'appareils
9 taux de 6,60
AMR-WB
qui incluent du matériel de micro
OBLIGATOIRE
kbit/s à 23,85 kbit/s
3GPP (.3gp)
et définissent
échantillonné à 16 kHz
android.hardware.microphone.
Mono/Stéréo (pas de multicanaux)

Audio
Taux d'échantillonnage jusqu'à
48 kHz (mais jusqu'à
44,1 kHz est
recommandé sur
les appareils avec
FLAC

obligatoire

sortie 44,1 kHz, car le
FLAC (.flac)

uniquement
(Android 3.1 et versions ultérieures)

échantillonneur à 44,1 kHz

n'inclut pas de filtre
passe-bas). 16 bits
recommandés ; aucun
dither appliqué pour 24
bits.
Mono/Stéréo 8-
320 kbit/s constant
MP3

OBLIGATOIRE
MP3 (.mp3)
(CBR) ou
débit
variable (VBR)
Type 0 et
MIDI Type 0 et 1.
1 (.mid,
DLS Version 1 et
.xmf, .mxmf)
2. XMF et mobile
RTTTL/RTX
MIDI

OBLIGATOIRE
XMF. Compatibilité avec les formats de sonnerie
(.rtttl, .rtx)

OTA (.ota)
RTTTL/RTX, OTA,
iMelody
et iMelody
(.imy)

Ogg (.ogg)
Vorbis

OBLIGATOIRE

Matroska
(.mkv)
PCM linéaire 8 bits et 16 bits** (fréquences
jusqu'à la limite du
matériel).Les appareils
DOIVENT être compatibles avec
PCM/WAVE
OBLIGATOIRE
OBLIGATOIRE
Fréquences d'échantillonnage WAVE (.wav)
pour l'enregistrement PCM brut
à 8 000,16 000 et
44 100 Hz

JPEG
OBLIGATOIRE
OBLIGATOIRE
Base+progressive
JPEG (.jpg)
GIF

OBLIGATOIRE

GIF (.gif)
Image
PNG
OBLIGATOIRE
OBLIGATOIRE

PNG (.png)
BMP

OBLIGATOIRE

BMP (.bmp)
WEBP
OBLIGATOIRE
OBLIGATOIRE

WebP (.webp)
OBLIGATOIRE
Obligatoire pour les implémentations d'appareils
3GPP
qui incluent du matériel photo et
(.3gp)
H.263
OBLIGATOIRE

définir android.hardware.camera
MPEG-4
ou
(.mp4)
android.hardware.camera.front.

3GPP
(.3gp)
OBLIGATOIRE
MPEG-4
(.mp4)
OBLIGATOIRE pour les implémentations d'appareils
MPEG-TS
qui incluent du matériel de caméra et
le profil de référence
Vidéo
H.264 AVC
OBLIGATOIRE
(.ts, AAC
définir android.hardware.camera
(BP)
audio uniquement,
ou
pas
android.hardware.camera.front.
seekable,
Android
3.0+)
MPEG-4

OBLIGATOIRE

3GPP (.3gp)
SP
WebM (.webm)
OBLIGATOIRE
et Matroska
VP8

(Android

(.mkv, Android
2.3.3+)
4.0+)
*Remarque: Seul le downmix du contenu 5.0/5.1 est obligatoire. L'enregistrement ou le rendu de plus de deux
canaux est facultatif. **Remarque: La capture PCM linéaire 16 bits est obligatoire. La capture au format PCM linéaire 8 bits
n'est pas obligatoire.
5.2 Encodage vidéo
Les implémentations d'appareils Android qui incluent une caméra arrière et déclarent
android.hardware.camera DOIVENT prendre en charge les profils d'encodage vidéo suivants.
HD (si compatible avec le

SD (basse qualité) SD (haute qualité)
matériel)
H.264 Baseline
H.264 Baseline
Codec vidéo
H.264 Baseline Profile
Profile
Profile
Vidéo
176 x 144 px
480 x 360 px
1 280 x 720 px
résolution
Cadre vidéo12 images/s
30 images/s
30 images/s
taux
500 kbit/s ou
Bitrate vidéo56 kbit/s
2 Mbit/s ou plus
plus
Codec audioAAC-LC
AAC-LC
AAC-LC

Audio
1 (mono)
2 (stéréo)
2 (stéréo)
canaux
Bitrate audio24 kbit/s
128 kbit/s
192 kbit/s
5.3. Enregistrement audio
Lorsqu'une application a utilisé l'API android.media.AudioRecord pour commencer à enregistrer
un flux audio, les implémentations d'appareils qui incluent un matériel de micro et
déclarent android.hardware.microphone DOIVENT échantillonner et enregistrer l'audio avec chacun de
ces comportements:
L'appareil DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près plates ;
plus précisément, ±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 sonore(SPL) de 90 dB à 1 000 Hz produise une valeur RMS de 2 500 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 au moins une plage de 30 dB allant de -18 dB à +12 dB par rapport à 90 dB de SPL au niveau du micro.
La distorsion harmonique totale DOIT être inférieure à 1% pour 1 kHz à un niveau d'entrée de SPL de 90 dB.

En plus des spécifications d'enregistrement ci-dessus, lorsqu'une application a commencé à
enregistrer un flux audio à l'aide de la source audio
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:
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é.
Remarque:Certaines des exigences décrites ci-dessus sont indiquées comme "DÉSIRABLE" pour
Android 4.1. La définition de compatibilité d'une future version prévoit de remplacer ces
exigences par "OBLIGATOIRE". C'est-à-dire que ces exigences sont facultatives dans Android 4.1, mais elles seront
obligatoires dans une future version. Nous recommandons vivement
aux appareils existants et nouveaux équipés d'Android 4.1 de respecter ces exigences dans Android 4.1, sans quoi ils ne seront pas
compatibles avec Android lors de la mise à niveau vers la future version.
5.4. Latence audio
La latence audio est définie de manière générale 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. Pour en savoir plus sur les conditions dans lesquelles le matériel du micro peut être omis par les implémentations d'appareils, consultez la section 7
.

Pour les besoins 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 lu, lorsque le système audio
est 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 lu, 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 sample à lire et le moment où le haut-parleur émet physiquement
le son correspondant, lorsque l'appareil est en train de lire 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 ont été
inactifs et éteints avant la requête.
La "latence d'entrée continue" est définie comme le moment où un son ambiant se produit et
le moment 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 millions d'i/s ou moins
latence de sortie à chaud de 10 millions d'i/s ou moins
latence de sortie continue de 45 millions d'i/s ou moins
latence d'entrée à froid de 100 millions d'i/s ou moins
latence d'entrée continue de 50 millions d'i/s ou moins
Remarque:Bien que les exigences décrites ci-dessus soient indiquées comme "DOIVENT" pour Android 4.1,

la définition de compatibilité pour une future version prévoit de les remplacer par "DOIVENT".
C'est-à-dire que ces exigences sont facultatives dans Android 4.1, mais devront être respectées dans une future
version. Nous recommandons vivement
aux appareils existants et nouveaux équipés d'Android 4.1 de respecter ces exigences dans Android 4.1, sans quoi ils ne seront pas
compatibles avec 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 compatibilité avec l'audio à faible latence en signalant la fonctionnalité "android.hardware.audio.low-
latency" via la classe android.content.pm.PackageManager.
[Resources, 37]
À 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.
5.5. Protocoles réseau
Les appareils DOIVENT être compatibles avec les protocoles réseau multimédias pour la lecture audio et vidéo, comme indiqué dans la documentation du SDK Android [Ressources, 58].
Plus précisément, les appareils
DOIVENT prendre en charge les protocoles de réseau multimédia suivants:
RTSP (RTP, SDP)
HTTP(S) progressive streaming
HTTP(S) Live Streaming draft protocol, version 3 [Resources, 59]
6. Compatibilité avec les outils de développement
Les implémentations d'appareils DOIVENT prendre en charge les outils de développement Android fournis dans le
SDK Android. Plus précisément, les appareils compatibles avec Android DOIVENT être compatibles avec:
Android Debug Bridge (connu sous le nom d'adb) [Ressources, 33]
Les implémentations d'appareil DOIVENT prendre en charge toutes les fonctions d'adb telles que documentées dans le
SDK Android. Le daemon adb côté appareil DOIT être inactif par défaut, et
un mécanisme accessible à l'utilisateur DOIT être disponible pour activer Android Debug
Bridge.
Service Dalvik Debug Monitor (également appelé dms) [Ressources, 33]
Les implémentations d'appareil DOIVENT prendre en charge toutes les fonctionnalités dms, 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é le pont de débogage Android, comme ci-dessus.
Monkey [Ressources, 36]
Les implémentations d'appareil DOIVENT inclure le framework Monkey et le rendre disponible pour les applications.

La plupart des systèmes Linux et des systèmes Apple Macintosh reconnaissent les appareils Android
à l'aide des outils standards du SDK Android, 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 comme
fournie 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
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é 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 en tant que no-ops de manière raisonnable
les méthodes d'API DOIVENT renvoyer des valeurs nulles lorsque cela est autorisé par la documentation du SDK
les méthodes d'API DOIVENT renvoyer des implémentations no-op de classes lorsque 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
Un exemple typique de scénario où ces exigences s'appliquent est l'API de téléphonie:
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 indiquer avec précision les informations de configuration matérielle
via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String)
de la classe android.content.pm.PackageManager. [Resources, 37]
7.1. Affichage et graphismes
Android 4.1 inclut des fonctionnalités qui ajustent automatiquement les éléments d'application et les mises en page de l'UI
en fonction de l'appareil, afin de s'assurer que les applications tierces s'exécutent correctement sur différentes configurations matérielles [Resources, 38].
Les appareils DOIVENT implémenter correctement
ces API et ces comportements, comme indiqué dans cette section.
Les unités référencées par les exigences de cette section sont définies comme suit :
"Taille de diagonale physique" : distance en pouces entre deux coins opposés
de la partie éclairée de l'écran.
"PPP" (points par pouce) : nombre de pixels compris dans une longueur linéaire
horizontale ou verticale de 1 pouce. Lorsque des valeurs de dpi sont indiquées, les valeurs de dpi horizontal et vertical doivent toutes deux se trouver 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".
Un "pixel indépendant de la densité" ("dp") est l'unité de pixel virtuel normalisée à un écran de 160
dpi, calculée comme suit: pixels = dps * (densité / 160).
7.1.1. Configuration de l'écran
Taille de l'écran
Le framework d'UI Android est compatible avec différentes tailles d'écran et permet aux
applications de interroger la taille de l'écran de l'appareil (également appelée "mise en page de l'écran") via
android.content.res.Configuration.screenLayout avec
SCREENLAYOUT_SIZE_MASK. Les implémentations d'appareils DOIVENT indiquer la taille d'écran correcte
, comme défini dans la documentation du SDK Android [Resources, 38] et déterminée par la plate-forme Android en amont.
Plus précisément, les implémentations d'appareils doivent indiquer la
taille d'écran correcte en fonction des dimensions d'écran
logiquesindépendantes de la densité de pixels (dp) suivantes.
Les appareils DOIVENT avoir une taille d'écran d'au moins 426 dp x 320 dp (taille "petite")
Les appareils qui indiquent une taille d'écran "normale" DOIVENT avoir une taille d'écran d'au moins 480
dp x 320 dp
Les appareils qui indiquent une taille d'écran "grande" DOIVENT avoir une taille d'écran d'au moins 640
dp x 480 dp
Les appareils qui indiquent une taille d'écran "très grande" DOIVENT avoir une taille d'écran d'au moins 960
dp x 720 dp
De plus, les appareils DOIVENT avoir une taille d'écran d'au moins 2,5 pouces en diagonale physique.

Les appareils NE DOIVENT PAS modifier la taille d'écran indiquée à tout moment.
Les applications indiquent facultativement les tailles d'écran compatibles via l'attribut <supports-
screens> dans le fichier AndroidManifest.xml. Les implémentations d'appareils DOIVENT
correctement respecter la compatibilité déclarée des applications avec les écrans
de petite, moyenne, grande et très grande taille, comme décrit dans la documentation du SDK Android.
Format de l'écran
Le format DOIT être compris entre 1,3333 (4:3) et 1,85 (16:9).
Densité d'écran
Le framework d'UI Android définit un ensemble de densités logiques standards pour aider les développeurs d'applications à cibler les ressources d'application.
Les implémentations d'appareils DOIVENT
indiquer l'une des densités de framework Android logiques suivantes via les API
android.util.DisplayMetrics et DOIVENT exécuter des applications à cette densité
standard.
120 ppp, appelé "ldpi"
160 ppp, appelé "mdpi"
213 ppp, appelé "tvdpi"
240 ppp, appelé "hdpi"
320 ppp, appelé "xhdpi"
480 ppp, appelé "xxhdpi"
Les implémentations d'appareil DOIVENT définir la densité de framework Android standard qui
est numériquement la plus proche de la densité physique de l'écran, sauf si cette densité logique

est numériquement la plus proche de la densité physique de l'écran, sauf si cette densité logique
fait passer la taille d'écran indiquée en dessous de la taille minimale prise en charge. Si la densité de framework Android
standard la plus proche numériquement de la densité physique donne une taille d'écran
inférieure à la plus petite taille d'écran compatible prise en charge (320 dp de largeur),
les implémentations d'appareil DOIVENT indiquer la densité de framework Android
standard la plus basse suivante.
7.1.2. Métriques d'affichage
Les implémentations d'appareil DOIVENT indiquer les valeurs correctes pour toutes les métriques d'affichage définies dans
android.util.DisplayMetrics [Resources, 39].
7.1.3. Orientation de l'écran
Les appareils DOIVENT prendre en charge l'orientation dynamique des applications en mode portrait ou paysage.
C'est-à-dire que l'appareil doit respecter la requête
de l'application pour une orientation d'écran spécifique. Les implémentations de l'appareil PEUVENT sélectionner l'orientation
portrait ou paysage par défaut.
Les appareils DOIVENT indiquer la valeur correcte pour l'orientation actuelle de l'appareil, chaque fois qu'ils sont interrogés via android.content.res.Configuration.orientation,
android.view.Display.getOrientation() ou d'autres API.

Les appareils NE DOIVENT PAS modifier la taille ou la densité d'écran signalées lors du changement d'
orientation.
Les appareils DOIVENT indiquer les orientations d'écran compatibles (
android.hardware.screen.portrait et/ou android.hardware.screen.landscape)
et DOIVENT indiquer au moins une orientation compatible. Par exemple, un appareil avec un
écran en mode paysage à orientation fixe, comme un téléviseur ou un ordinateur portable, DOIT uniquement signaler
android.hardware.screen.landscape.
7.1.4. Accélération graphique 2D et 3D
Les implémentations d'appareils DOIVENT être compatibles avec OpenGL ES 1.0 et 2.0, comme indiqué
et détaillé dans la documentation du SDK Android. Les implémentations d'appareils DOIVENT également
prendre en charge Android Renderscript, comme indiqué dans la documentation du SDK Android
[Ressources, 8].
Les implémentations d'appareils DOIVENT également s'identifier correctement comme étant compatibles avec OpenGL ES 1.0 et 2.0.

Les API gérées (par exemple, via la méthode GLES10.getString()) DOIVENT indiquer la compatibilité avec
OpenGL ES 1.0 et 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) DOIVENT indiquer la compatibilité avec
OpenGL ES 1.0 et 2.0.
Les implémentations d'appareils PEUVENT implémenter toutes les extensions OpenGL ES souhaitées.
Toutefois, les implémentations d'appareils DOIVENT signaler via les API natives et gérées par OpenGL ES toutes les chaînes d'extension qu'elles prennent en charge, et inversement, elles NE DOIVENT PAS signaler les chaînes d'extension qu'elles ne prennent pas en charge.

Notez qu'Android 4.1 permet aux applications de spécifier de manière facultative qu'elles
nécessitent des formats de compression de texture OpenGL spécifiques. Ces formats sont généralement
spécifiques au fournisseur. Android 4.1 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 acceptent, via la méthode getString() de l'
API OpenGL.
Android 4.1 inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle pour les graphiques 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue à l'aide d'une balise de fichier manifeste android:hardwareAccelerated ou d'appels d'API directs [Resources, 9].

Dans Android 4.1, les implémentations d'appareils DOIVENT activer l'accélération matérielle par défaut et DOIVENT la désactiver si le développeur le demande en définissant android:hardwareAccelerated="false" ou en désactivant l'accélération matérielle
directement via les API Android View.

En outre, les implémentations d'appareils DOIVENT présenter un comportement conforme à la documentation du SDK Android
sur l'accélération matérielle [Ressources, 9].
Android 4.1 inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES accélérées par matériel en tant que cibles de rendu dans une hiérarchie d'UI.
Les implémentations d'appareils DOIVENT être compatibles avec l'API TextureView et DOIVENT présenter un comportement

cohérent avec l'implémentation Android en amont.

7.1.5. Ancien mode de compatibilité des applications
Android 4.1 spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un
mode équivalent à une taille d'écran "normale" (largeur de 320 dp) pour le bénéfice des anciennes
applications qui n'ont pas été développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille de l'écran.
Les implémentations d'appareils DOIVENT prendre en charge le mode de compatibilité des anciennes applications
tel qu'implémenté par le code Open Source Android en amont. C'est-à-dire que les implémentations d'appareils NE DOIVENT PAS modifier les déclencheurs ou les seuils à partir desquels le mode de compatibilité est activé, et NE DOIVENT PAS modifier le comportement du mode de compatibilité lui-même.

7.1.6. Types d'écrans
Les écrans d'implémentation de l'appareil sont classés en deux types :
Implémentations d'écrans à pixels fixes : l'écran est un seul panneau qui ne prend en charge que la largeur et la hauteur d'un seul pixel.
Implémentations d'écrans à pixels variables : l'écran est un seul panneau qui peut prendre en charge une largeur et une hauteur de plusieurs pixels.
En règle générale, l'écran est physiquement intégré
à l'appareil. Exemples : téléphones mobiles, tablettes, etc.
Implémentations d'écran à pixels variables : l'implémentation de l'appareil n'a pas d'écran intégré et inclut un port de sortie vidéo tel que VGA, HDMI ou un port sans fil pour l'affichage, ou dispose d'un écran intégré pouvant modifier les dimensions des pixels.

Exemples : téléviseurs, boîtiers décodeurs, etc.
Implémentations d'appareils à pixels fixes
Les implémentations d'appareils à pixels fixes PEUVENT utiliser des écrans de toutes dimensions de pixels,
à condition qu'ils répondent aux exigences définies dans cette définition de compatibilité.
Les implémentations à pixels fixes PEUVENT inclure un port de sortie vidéo à utiliser avec un écran
externe. Toutefois, si cet écran est utilisé pour exécuter des applications, l'appareil DOIT respecter
les exigences suivantes:
L'appareil DOIT indiquer la même configuration d'écran et les mêmes métriques d'affichage que l'écran à pixels fixes, comme indiqué dans les sections 7.1.1 et 7.1.2.
L'appareil DOIT indiquer la même densité logique que l'écran à pixels fixes.
L'appareil DOIT indiquer des dimensions d'écran identiques ou très proches de celles de l'écran à pixels fixes.

Par exemple, une tablette de 7 pouces de diagonale avec une résolution de 1 024 x 600 pixels est considérée comme une implémentation d'écran mdpi de grande taille à pixels fixes.
S'il contient un port de sortie vidéo
qui affiche en 720p ou 1080p, l'implémentation de l'appareil DOIT mettre à l'échelle la sortie
afin que les applications ne soient exécutées que dans une grande fenêtre mdpi, que l'écran à pixels fixes ou le port de sortie vidéo soit utilisé ou non.

Implémentations d'appareils à pixels variables
Les implémentations d'appareils à pixels variables DOIVENT prendre en charge au moins l'une des résolutions suivantes : 1 280 x 720 ou 1 920 x 1 080 (c'est-à-dire 720p ou 1 080p).
Les implémentations d'appareils avec des écrans
à pixels variables NE DOIVENT PAS prendre en charge d'autres configurations ou modes d'écran. Les implémentations
d'appareils avec des écrans à pixels variables PEUVENT modifier la configuration ou le mode
de l'écran au moment de l'exécution ou du démarrage. Par exemple, un utilisateur d'un décodeur peut remplacer un écran
720p par un écran 1080p, et l'implémentation de l'appareil peut s'ajuster en conséquence.

En outre, les implémentations d'appareils avec des dimensions de pixel variables DOIVENT indiquer les buckets de configuration suivants pour ces dimensions de pixel:
1 280 x 720 (également appelé 720p) : taille d'écran "grande", densité "tvdpi" (213 dpi)
1 920 x 1 080 (également appelé 1080p) : taille d'écran "grande", densité "xhdpi" (320 dpi)
Pour plus de clarté, les implémentations d'appareils avec des dimensions de pixel variables sont limitées à
720p ou 1080p dans Android 4.1, et DOIVENT être configurées pour indiquer la taille d'écran et les buckets de densité, comme indiqué ci-dessus.

7.1.7. Technologie d'écran
La plate-forme Android inclut des API qui permettent aux applications d'afficher des graphiques riches sur
l'écran. Les appareils DOIVENT prendre en charge toutes ces API telles que définies par le SDK Android
, sauf si cela est spécifiquement autorisé dans ce document. Plus précisément:
Les appareils DOIVENT prendre en charge les écrans capables d'afficher des graphiques couleur 16 bits et
DOIVENT POURRAIENT prendre en charge les écrans capables d'afficher des graphiques couleur 24 bits.
Les appareils DOIVENT prendre en charge les écrans capables d'afficher des animations.
La technologie d'affichage utilisée DOIT avoir un format de pixel (PAR) compris entre 0,9

et 1,1. C'est-à-dire que le format des pixels DOIT être proche du carré (1, 0) avec une tolérance de 10%
.
7.2. Périphériques d'entrée
7.2.1. Clavier
Implémentations de l'appareil:
DOIVENT 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
http://developer.android.com
DOIVENT fournir au moins une implémentation de clavier virtuel (que
un clavier physique soit présent ou non)
PEUVENT inclure des implémentations de clavier virtuel supplémentaires
PEUVENT inclure un clavier physique
NE DOIVENT PAS inclure de clavier physique qui ne correspond pas à l'un des formats
spécifiés dans android.content.res.Configuration.keyboard [Resources, 40]
(c'est-à-dire QWERTY ou 12 touches)
7.2.2.
Navigation sans contact
Implémentations de l'appareil:
POURRA omettre une option de navigation sans contact (c'est-à-dire, peut omettre une boule de commande, un pavé directionnel ou une
roue)
DOIT indiquer la valeur correcte pour
android.content.res.Configuration.navigation [Resources, 40]
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
logiciel 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
à tout moment lors de l'exécution d'applications. Ces fonctions peuvent être implémentées via des
boutons physiques dédiés (tels que des boutons tactiles mécaniques ou capacitifs), ou
implémentées à l'aide de touches logicielles dédiées, de gestes, d'un écran tactile, etc. Android
4.1 prend en charge les deux implémentations.
Android 4.1 introduit la prise en charge de l'action d'assistance [Resources, 63]. Les implémentations d'appareils
DOIVENT mettre l'action d'assistance à la disposition de l'utilisateur à tout moment lorsqu'il
exécute des applications.Cette fonction PEUT être implémentée via des clés matérielles ou logicielles
.
Les implémentations d'appareil PEUVENT utiliser une partie distincte de l'écran pour afficher les
touches de navigation, mais si elles le font, elles DOIVENT respecter les exigences suivantes:
Les touches de navigation de l'implémentation de l'appareil DOIVENT utiliser une partie distincte de l'
écran, qui n'est pas disponible pour les applications, et NE DOIVENT PAS masquer ni interférer avec la partie de l'écran disponible pour les applications.
Les implémentations d'appareil DOIVENT mettre à la disposition des applications une partie de l'écran qui répond aux exigences définies dans la section 7.1.1.
Les implémentations d'appareil DOIVENT afficher les touches de navigation lorsque les applications ne spécifient pas de mode d'UI système ou spécifient SYSTEM_UI_FLAG_VISIBLE.
Les implémentations d'appareil DOIVENT présenter les touches de navigation dans un mode "discret" (par exemple, atténué) non intrusif lorsque les applications spécifient SYSTEM_UI_FLAG_LOW_PROFILE.

Les implémentations d'appareil DOIVENT masquer les touches de navigation lorsque les applications
spécifient SYSTEM_UI_FLAG_HIDE_NAVIGATION.
L'implémentation de l'appareil DOIT présenter une touche de menu aux applications lorsque
targetSdkVersion <= 10 et NE DOIT PAS présenter de touche de menu lorsque
targetSdkVersion > 10.
Les implémentations d'appareil DOIVENT mettre à disposition une partie de l'écran pour
les applications qui répondent aux exigences définies dans la section 7.1.1.
7.2.4. Saisie par écran tactile
Les implémentations d'appareils DOIVENT comporter un système de saisie par pointeurd'une certaine sorte (
souris ou tactile). Cependant, si une implémentation d'appareil n'est pas compatible avec un système d'entrée de pointeur
, elle NE DOIT PAS signaler la constante de fonctionnalité android.hardware.touchscreen ou
android.hardware.faketouch. Les implémentations d'appareils qui

incluent un système de saisie par pointeur:
DOIVENT prendre en charge les pointeurs entièrement suivis indépendamment, si le système de saisie de l'appareil
prend en charge plusieurs pointeurs
DOIVENT indiquer la valeur d'android.content.res.Configuration.touchscreen
[Resources, 40] ccorrespondant au type d'écran tactile spécifique de l'
appareil
Android 4.0 est compatible avec divers écrans tactiles, pavés tactiles et faux dispositifs
de saisie tactile. Les implémentations d'appareils à écran tactile sont associées à un
écran [Resources, 71] de sorte que l'utilisateur a l'impression de manipuler directement des
éléments à l'écran. Comme l'utilisateur touche directement l'écran, le système n'
a pas besoin d'affordances supplémentaires pour indiquer les objets manipulés. En
revanche, une interface tactile simulée fournit un système de saisie utilisateur qui s'approche d'un
sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande qui contrôle un
curseur à l'écran s'approche de la saisie tactile, mais nécessite que l'utilisateur pointe ou mette en surbrillance
l'élément, puis clique. De nombreux dispositifs d'entrée tels que la souris, le pavé tactile, la souris sans fil basée sur le gyroscope, le pointeur gyroscopique, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles factices.
Android 4.0 inclut la constante de fonctionnalité android.hardware.faketouch, qui
correspond à un dispositif d'entrée non tactile haute fidélité (c'est-à-dire basé sur un pointeur), tel qu'une
souris ou un pavé tactile, qui peut émuler de manière adéquate l'entrée tactile (y compris la prise en charge des gestes de base) et indique que l'appareil est compatible avec un sous-ensemble émulé des fonctionnalités de l'
écran tactile.

Les implémentations d'appareils qui déclarent la fonctionnalité de faux appui
DOIVENT respecter les exigences concernant les faux appuis de la section 7.2.5.
Les implémentations d'appareils DOIVENT signaler la fonctionnalité appropriée correspondant au type d'
entrée utilisé. Les implémentations d'appareils qui incluent un écran tactile (à un ou plusieurs doigts)
DOIVENT signaler la constante de fonctionnalité de plate-forme android.hardware.touchscreen. Les implémentations d'
appareils qui signalent la constante de fonctionnalité de plate-forme
android.hardware.touchscreen DOIVENT également signaler la constante de fonctionnalité de plate-forme
android.hardware.faketouch. Les implémentations d'appareils qui n'incluent pas d'
écran tactile (et qui ne reposent que sur un dispositif de pointage) NE DOIVENT PAS signaler de fonctionnalité
d'écran tactile et DOIVENT signaler uniquement android.hardware.faketouch s'ils répondent aux exigences de l'interface tactile simulée
de la section 7.2.5.
7.2.5.Saisie tactile factice
Les implémentations d'appareils qui déclarent prendre en charge android.hardware.faketouch
doivent indiquer les positions X et Y absolues de l'emplacement du pointeur et
afficher un pointeur visuel à l'écran [Resources, 70].
Les implémentations d'appareils qui déclarent prendre en charge android.hardware.faketouch
doivent indiquer les positions X et Y absolues de l'emplacement du pointeur et
afficher un pointeur visuel à l'écran [Resources, 70].
Les implémentations d'appareils qui déclarent prendre en charge android.hardware.faketouch
doivent indiquer les positions X et Y absolues de l'emplacement du pointeur et
afficher un pointeur visuel à l'écran [Resources, 70].
Les implémentations d'appareils qui déclarent prendre en charge android.hardware.faketouch
doivent indiquer les positions X et Y absolues de l'emplacement du pointeur et
afficher un pointeur visuel à l'écran [Resources, 70].
Les implémentations d'appareils qui déclarent prendre en charge android.hardware.faketouch
doivent indiquer les positions X et Y absolues de l'emplacement du pointeur et
afficher un pointeur visuel à l'écran [Resources, 70].
Les appareils qui déclarent prendre en charge android.hardware.faketouch.multitouch.distinct
doivent respecter les exigences de la saisie tactile factice ci-dessus et également prendre en charge le suivi distinct de deux ou plusieurs entrées de pointeur indépendantes.

7.2.6. Microphone
Les implémentations d'appareils PEUVENT omettre un micro. Toutefois, si une implémentation d'appareil
omet un micro, elle NE DOIT PAS signaler la constante de la fonctionnalité android.hardware.microphone
et doit implémenter l'API d'enregistrement audio en tant que no-ops, conformément à la section 7.
À l'inverse, les implémentations d'appareils qui disposent d'un micro:
DOIVENT signaler la constante de la fonctionnalité android.hardware.microphone
DOIVENT respecter les exigences de qualité audio de la section 5.4
DOIVENT respecter les exigences de latence audio de la section 5.5
7.3. Capteurs

Android 4.1 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 par classe
android.content.pm.PackageManager. [Resources, 37]
doit renvoyer une liste précise des capteurs compatibles via les méthodes
SensorManager.getSensorList() et 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 ne appelant pas d'écouteurs de capteurs lorsque les capteurs correspondants ne sont pas présents, etc.)
doit signaler toutes les mesures de capteur à l'aide des valeurs du système international d'unités (c'est-à-dire métrique) pertinentes pour chaque type de capteur, comme défini dans la documentation du SDK Android [Resources, 41].
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. (par exemple, le capteur d'orientation et le 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 4.1 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'
d'appareil DOIVENT fournir en continu des échantillons de données périodiques pour toute API
indiquée par la documentation du SDK Android 4.1 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 l'implémentation d'un appareil
inclut un accéléromètre à trois axes, elle:
DOIT pouvoir envoyer des événements à 120 Hz ou plus. Notez que, bien que la fréquence de l'
accéléromètre ci-dessus soit indiquée comme "DOIT" pour Android 4.1, la
définition de compatibilité pour une future version prévoit de la remplacer par
"DOIT". C'est-à-dire que ces normes sont facultatives dans Android 4.1, mais elles seront
obligatoires dans les futures versions. Les appareils existants et nouveaux exécutant Android 4.1 sont
très vivement encouragés à respecter ces exigences dans Android 4.1 afin
qu'ils puissent passer aux futures versions de la plate-forme.
DOIVENT respecter le système de coordonnées des capteurs Android, comme indiqué dans les
API Android (voir [Ressources, 41])
DOIVENT être capables de mesurer de la chute libre jusqu'à deux fois la gravité (2 g) ou plus sur
tout vecteur tridimensionnel
DOIVENT avoir une précision de 8 bits ou plus
DOIVENT avoir une déviation standard ne dépassant pas 0,05 m/s^2
7.3.2. Magnétomètre
Les implémentations d'appareils DOIVENT inclure un magnétomètre 3 axes (boussole). Si un
appareil inclut un magnétomètre à trois axes, il doit:
POURRA envoyer des événements à 10 Hz ou plus
POURRA respecter le système de coordonnées des capteurs Android, comme indiqué dans les
API Android (voir [Ressources, 41]).
POURRA échantillonner une plage de champs magnétiques adaptée pour couvrir le
champ géomagnétique
POURRA avoir une précision de 8 bits ou plus
POURRA avoir une déviation standard ne dépassant pas 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 de "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 l'implémentation d'un appareil inclut un gyroscope:

DOIT être compensé en température
DOIT être capable de mesurer les changements d'orientation jusqu'à 5,5*Pi
radians/seconde (soit environ 1 000 degrés par seconde)
DOIT être capable de générer des événements à 200 Hz ou plus. Notez que, bien que la
fréquence du gyroscope ci-dessus soit indiquée comme "DOIT" pour Android 4.1, la
définition de compatibilité pour une future version prévoit de la remplacer par
"DOIT". C'est-à-dire que ces normes sont facultatives dans Android 4.1, mais elles seront
obligatoires dans les futures versions. Les appareils existants et nouveaux exécutant Android 4.1 sont
très vivement encouragés à respecter ces exigences dans Android 4.1 afin
qu'ils puissent passer aux futures versions de la plate-forme.
DOIVENT avoir une précision de 12 bits ou plus
DOIVENT avoir une variance ne dépassant pas 1e-7 rad^2 / s^2 par Hz (variance par Hz,
ou rad^2 / s). La variance peut varier avec le taux d'échantillonnage, mais doit être
contrainte par cette valeur. En d'autres termes, si vous mesurez la variance du gyro
à une fréquence d'échantillonnage de 1 Hz, elle ne doit pas dépasser 1e-7 rad^2/s^2.
Les codes temporels doivent être aussi proches que possible du moment où l'événement matériel s'est produit.
La latence constante doit être supprimée.
7.3.5. Baromètre
Les implémentations de l'appareil PEUVENT inclure un baromètre (c'est-à-dire un capteur de pression de l'air ambiant). Si
l'implémentation d'un appareil inclut un baromètre, il doit:
MUST be able to deliver events at 5 Hz or greater
MUST have adequate precision to enable estimating altitude
MUST be temperature compensated
7.3.7. Thermomètre
Les implémentations de l'appareil PEUVENT, mais NE DOIVENT PAS, inclure un 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 4.1.)
7.3.7. Photomètre
Les implémentations de l'appareil PEUVENT inclure un photomètre (c'est-à-dire un capteur de luminosité ambiante).
7.3.8. Capteur de proximité
Les implémentations de l'appareil 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. C'est-à-dire que le capteur de proximité DOIT être orienté pour détecter les
objets à proximité 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'
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
7.4.1. Téléphonie
Le terme "téléphonie" utilisé par les API Android 4.1 et 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 pour
Android 4.1. En d'autres termes, les fonctionnalités et API de la "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
ces appareils utilisent ou non un réseau mobile pour la connectivité de données.

Android 4.1 PEUT être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. En d'autres termes,
Android 4.1 est compatible avec les appareils autres que les téléphones. Toutefois, si l'implémentation d'un appareil
inclut la téléphonie GSM ou CDMA, elle doit impérativement être entièrement compatible
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 l'intégralité des API en tant que no-ops.
7.4.2. IEEE 802.11 (Wi-Fi)
Les implémentations d'appareils Android 4.1 DOIVENT inclure la prise en charge d'une ou de plusieurs formes
de la norme 802.11 (b/g/a/n, etc.) Si l'implémentation d'un appareil inclut la prise en charge de la norme 802.11, elle
DOIT implémenter l'API Android correspondante.

Les implémentations d'appareils DOIVENT implémenter l'API multicast comme décrit dans la documentation du SDK
[Ressources, 62]. Lesimplémentations d'appareils qui incluent la compatibilité avec le Wi-Fi
DOIVENT prendre en charge le DNS multicast (mDNS). Les implémentations d'appareils NE DOIVENT PAS filtrer les paquets mDNS
(224.0.0.251) à tout moment de l'opération, y compris lorsque l'écran n'est pas dans un état
actif.
7.4.2.1. Wi-Fi Direct
Les implémentations d'appareils DOIVENT prendre en charge le Wi-Fi Direct (Wi-Fi peer-to-peer). Si
l'implémentation d'un appareil inclut la prise en charge de Wi-Fi Direct, elle DOIT implémenter l'
API Android correspondante, comme décrit dans la documentation du SDK [Resources, 68]. Si
une implémentation d'appareil est compatible avec le Wi-Fi direct, elle:
DOIT être compatible avec le fonctionnement régulier du Wi-Fi
DOIT être compatible avec le fonctionnement simultané du Wi-Fi et du Wi-Fi direct
7.4.3. Bluetooth
Les implémentations d'appareils DOIVENT inclure un émetteur-récepteur Bluetooth. Les implémentations d'
d'appareil qui incluent un émetteur-récepteur Bluetooth DOIVENT activer l'API Bluetooth basée sur RFCOMM, comme décrit dans la documentation du SDK [Resources, 42].
Les implémentations
de l'appareil 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 d'Android.
Cependant, 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
guidée par l'humain décrite dans l'annexe A.
7.4.4. Communication en champ proche
Les implémentations d'appareils DOIVENT inclure un transceiver et du matériel associé pour la
communication en champ proche (NFC). Si une implémentation d'appareil inclut du matériel NFC
, elle doit:
MUST report the android.hardware.nfc feature from the
android.content.pm.PackageManager.hasSystemFeature() method.
[Resources, 37]
DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC
standards suivantes :
DOIT être capable de jouer le rôle de 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)
IsoDep (ISO 14443-4)
NFC Forum Tag Types 1, 2, 3, 4 (définis par le NFC Forum)
DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC
standards suivantes :
Remarque : Bien que les normes NFC ci-dessous soient indiquées comme
RECOMMANDÉES pour Android 4.1, la définition de la compatibilité pour une future version prévoit de les remplacer par
OBLIGATOIRES. C'est-à-dire que ces normes sont facultatives dans
Android 4.1, mais elles seront obligatoires dans les futures versions. Les appareils existants et nouveaux
exécutant Android 4.1 sont très vivement encouragés à respecter ces
exigences dans Android 4.1 afin de pouvoir passer aux futures versions de la
plate-forme.
NfcV (ISO 15693)
DOIT être capable de transmettre et de recevoir des données via les normes et protocoles de pair à pair suivants:
ISO 18092
LLCP 1.0 (défini par le NFC Forum)
SDP 1.0 (défini par le NFC Forum)
Protocole NDEF Push [Ressources, 43]
SNEP 1.0 (défini par le NFC Forum)
doit inclure la prise en charge d'Android Beam [Ressources, 65]:
doit implémenter le serveur par défaut SNEP.
Les messages NDEF valides
reçus par le serveur SNEP par défaut DOIVENT être distribués aux applications
à l'aide de l'intent android.nfc.ACTION_NDEF_DISCOVERED. La désactivation de
Android Beam dans les paramètres NE DOIT PAS désactiver l'envoi du message NDEF
entrant.
Les implémentations d'appareil DOIVENT respecter l'intent
android.settings.NFCSHARING_SETTINGS pour afficher les paramètres de partage NFC

[Resources, 67].
DOIVENT implémenter le serveur NPP. Les messages reçus par le serveur NPP
DOIVENT être traités de la même manière que le serveur SNEP par défaut.
DOIVENT implémenter un client SNEP et tenter d'envoyer des NDEF P2P sortants
au serveur SNEP par défaut lorsque Android Beam est activé. Si aucun serveur SNEP par défaut n'est trouvé, le client DOIT essayer d'envoyer un message NDEF P2P sortant
à l'aide d'android.nfc.NfcAdapter.setNdefPushMessage, et
android.nfc.NfcAdapter.setNdefPushMessageCal back, et
android.nfc.NfcAdapter.enableForegroundNdefPush.
DOIT utiliser un geste ou une confirmation à l'écran, comme "Appuyer pour
Beam", avant d'envoyer des messages NDEF P2P sortants.
DOIT activer Android Beam par défaut
DOIT prendre en charge le transfert de connexion NFC vers Bluetooth lorsque l'appareil
prend en charge le profil Bluetooth Object Push.

Les implémentations d'appareils doivent
prendre en charge le transfert de connexion vers le Bluetooth lorsque vous utilisez
android.nfc.NfcAdapter.setBeamPushUris, en implémentant les spécifications
"Transfert de connexion version 1.2" [Ressources, 60] et "Association simple sécurisée Bluetooth à l'aide du NFC version 1.0" [Ressources, 61] du
Forum NFC.
Une telle implémentation de la SHOULD utilise les requêtes SNEP GET
pour échanger la requête de transfert ou sélectionner des enregistrements via NFC, et
DOIT utiliser le profil Bluetooth Object Push Profile pour le transfert de données Bluetooth réel.

doit rechercher toutes les technologies compatibles en mode découverte NFC.
doit être en mode découverte NFC lorsque l'appareil est actif, l'écran actif et l'écran de verrouillage déverrouillé.

(Notez que les liens publics ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum
citées ci-dessus.)
En outre, les implémentations d'appareils PEUVENT inclure la prise en charge des lecteurs/lecteurs-écrivains pour les
technologies MIFARE suivantes.
MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 44])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])
NDEF sur MIFARE Classic (NXP AN130511 [Ressources, 48], AN130411
[Resources, 49])
Notez que Android 4.1 inclut des API pour ces types de MIFARE. Si une implémentation d'appareil
est compatible avec MIFARE dans le rôle de lecteur/écrivain, elle doit:
MUST implement the corresponding Android APIs as documented by the
Android SDK
MUST report the feature com.nxp.mifare from the
android.content.pm.PackageManager.hasSystemFeature() method.
[Resources, 37] Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et qu'en tant que tel,
NE DOIT PAS implémenter les API Android correspondantes ni signaler la fonctionnalité
com.nxp.mifare, sauf si elle implémente également la prise en charge générale du NFC comme décrit dans cette section.
Si une implémentation d'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, 37],
et DOIT implémenter l'API NFC Android 4.1 en tant qu'opération sans effet.
Comme les classes android.nfc.NdefMessage et android.nfc.NdefRecord répresentent un
format de représentation des données indépendant du protocole, les implémentations d'appareils DOIVENT
implémenter ces API, même si elles n'incluent pas la prise en charge du NFC ni ne déclarent la fonctionnalité
android.hardware.nfc.

7.4.5. Fonctionnalité 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. Parm
i les technologies répondant à cette exigence, citons EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.
Les implémentations d'appareils où une norme de réseau physique (telle qu'Ethernet) est la principale connexion de données 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 sur le 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
DOIT avoir un autofocus matériel ou logiciel implémenté
dans le pilote de l'appareil photo (transparent pour le logiciel d'application)
PEUT avoir un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF)
PEUT inclure un flash. Si la caméra inclut un flash, la lampe de flash NE DOIT PAS être allumée
lorsqu'une instance de retour android.hardware.Camera.PreviewCal a été
enregistrée sur une surface d'aperçu de la caméra, 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
utilisant Camera.PreviewCallback.
7.5.2. Caméra avant
Les implémentations de l'appareil PEUVENT inclure une caméra avant. Si l'implémentation d'un appareil
inclut une caméra avant, elle:
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 Appareil photo d'Android 4.1 est compatible avec les caméras avant, et
les implémentations d'appareils DOIVENT configurer l'API pour qu'elle traite 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.
PEUT inclure des fonctionnalités (telles que la mise au point 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
aperçu de l'appareil photo, 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 la caméra
DOIT être en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.
Si l'application actuelle a demandé explicitement que l'affichage de la caméra
soit pivoté via une méthode de la classe
android.hardware.Camera.setDisplayOrientation() [Resources, 50]
, l'aperçu de la caméra DOIT être en miroir horizontalement par rapport à l'orientation spécifiée par l'application.
Sinon, l'aperçu DOIT être en miroir le long de l'axe horizontal par défaut de l'appareil.

doit refléter l'image affichée par la vue d'aperçu de la publication de la même manière que le flux d'images de l'aperçu de la caméra.
(Si l'implémentation de l'appareil n'est pas compatible avec la
postview, cette exigence ne s'applique évidemment pas.)
NE DOIT PAS refléter l'image finale capturée ni les flux vidéo renvoyés à
l'application, ni être stockés dans le stockage multimédia
7.5.3. Comportement des API de la caméra
Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra, pour les caméras avant et arrière:
1.
  Si une application n'a jamais appelé
android.hardware.Camera.Parameters.setPreviewFormat(int),
alors l'appareil DOIT utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données de prévisualisation
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. C'est-à-dire que 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 pour les caméras
avant et arrière. (Le décodeur vidéo matériel et la caméra peuvent
utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil doit
prendre en charge la conversion au format YV12.)
Les implémentations d'appareils DOIVENT implémenter l'API Camera complète incluse dans la documentation du SDK Android
4.1 [Resources, 51]), 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 toutes 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 arrières de l'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 comme
constante dans la classe android.hardware.Camera.Parameters, si le matériel sous-jacent
prend en charge la fonctionnalité. Si le matériel de l'appareil n'est pas compatible avec une fonctionnalité, l'API
doit se comporter comme indiqué dans la documentation. À l'inverse, les implémentations d'appareils NE DOIVENT PAS
respecter ni reconnaître les constantes de chaîne transmises à la méthode
android.hardware.Camera.setParameters() autres que celles documentées en tant que
constantes sur android.hardware.Camera.Parameters. C'est-à-dire que les implémentations d'appareils
DOIVENT prendre en charge tous les paramètres d'appareil photo standards si le matériel
le permet, et NE DOIVENT PAS prendre en charge les types de paramètres d'appareil photo personnalisés.
Les implémentations d'appareil DOIVENT diffuser l'intent Camera.ACTION_NEW_PICTURE
chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de la photo a été
ajoutée au Media Store.
Les implémentations d'appareil DOIVENT diffuser l'intent Camera.ACTION_NEW_VIDEO
chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de l'image a été
ajoutée au Media Store.
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 que la dimension
longue de l'appareil photo corresponde à 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. Autrement dit, cela s'applique aux appareils en mode paysage et en mode portrait.

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

Les implémentations d'appareils DOIVENT disposer d'au moins 350 Mo d'espace de stockage non volatile disponible
pour les données privées de l'application. C'est-à-dire que la partition /data doit être d'au moins 350 Mo.
Les API Android incluent un gestionnaire de téléchargement que les applications peuvent utiliser pour télécharger des fichiers de données
[Resources, 56]. L'implémentation de l'appareil du gestionnaire de téléchargement
DOIT être capable de télécharger des fichiers individuels d'au moins 100 Mo vers l'emplacement de "cache" par défaut
.
7.6.2. Espace de stockage partagé pour les applications
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é monté par défaut,
"prêt à l'emploi". Si l'espace de 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 cet espace de stockage partagé, comme indiqué dans la documentation.
Autrement, l'espace de 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) comme 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 (UMS) ou le protocole de transfert multimédia (MTP).
Les implémentations d'appareils PEUVENT utiliser le stockage de masse USB, mais DOIVENT utiliser le protocole de transfert multimédia.

Si l'implémentation de l'appareil est compatible avec le protocole de transfert multimédia:
L'implémentation de l'appareil DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer [Resources, 57].
L'implémentation de l'appareil DOIT indiquer une classe d'appareil USB de 0x00.
L'implémentation de l'appareil DOIT indiquer un nom d'interface USB de "MTP".

Si l'implémentation de l'appareil ne comporte pas de ports USB, elle DOIT fournir à un ordinateur hôte un
accès au contenu du stockage partagé par un autre moyen, tel qu'un système de fichiers
réseau.
Pour illustrer ce point, prenons deux exemples courants. Si l'implémentation d'un appareil inclut
un port de carte SD pour répondre aux exigences 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. Alternativement, si une implémentation d'appareil utilise un stockage interne fixe
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 lecteur multimédia et ContentProvider pour prendre en charge de manière transparente les fichiers placés dans les deux emplacements.

7.7. USB
Les implémentations d'appareils DOIVENT inclure un port client USB et DOIVENT inclure un
port hôte USB.
Si une implémentation d'appareil inclut un port client USB:
le port DOIT être connectable à un hôte USB avec un port USB-A standard
le port DOIT utiliser le facteur de forme micro USB côté appareil. Les
appareils existants et nouveaux exécutant Android 4.1 sont très vivement encouragés à respecter
ces exigences dans Android 4.1 afin de pouvoir passer aux futures
versions de la plate-forme
. Le port DOIT être centré au milieu d'un bord. Les implémentations d'appareils
DOIVENT placer le port en bas de l'appareil (selon l'orientation naturelle
) ou activer la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil
), afin que l'affichage s'affiche correctement lorsque l'appareil est orienté avec le port en bas.
Les appareils existants et nouveaux exécutant Android 4.1 sont très fortement
encouragés à respecter ces exigences dans Android 4.1 afin qu'ils puissent
passer aux futures versions de la plate-forme.
Si l'appareil dispose d'autres ports (tels qu'un port de recharge autre qu'USB), il DOIT être
sur le même bord que le port micro-USB.
Il DOIT permettre à un hôte connecté à l'appareil d'accéder au contenu du
volume de stockage partagé à l'aide du stockage de masse USB ou du protocole de transfert multimédia
.Il DOIT implémenter l'API et la spécification Android Open Accessory comme décrit dans la documentation du SDK Android, et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory [Resources, 52].
Il DOIT implémenter la classe audio USB comme décrit dans la documentation du SDK Android [Resources, 66].
Il DOIT implémenter la prise en charge de la spécification de recharge de la batterie USBification
[Resources, 64]. Les appareils existants et nouveaux exécutant Android 4.1 sont très
fortement encouragés à respecter ces exigences dans Android 4.1 afin qu'ils puissent
passer aux futures versions de la plate-forme.
Si une implémentation d'appareil inclut un port hôte USB:
Il PEUT utiliser un facteur de forme de port non standard, mais dans ce cas, il DOIT être fourni avec un câble ou
des câbles adaptant le port à l'USB-A standard.
Il DOIT implémenter l'API hôte USB Android comme décrit dans le SDK Android, et DOIT déclarer la prise en charge de la fonctionnalité matérielle
android.hardware.usb.host [Resources, 53].
Les implémentations d'appareil DOIVENT implémenter Android Debug Bridge.

Si une implémentation d'appareil
omet un port client USB, elle DOIT implémenter Android Debug Bridge
via un réseau local (tel qu'Ethernet ou 802.11)

8. Compatibilité des performances
Les implémentations d'appareils DOIVENT respecter les métriques de performances clés d'un appareil compatible avec Android 4.1
définies dans le tableau ci-dessous:
Métrique
Seuil de performances
Commentaires
Les applications suivantes
doivent se lancer dans le délai
spécifié.
Le temps de démarrage est mesuré comme le
temps total nécessaire pour terminer le chargement du
browser: moins de
activité par défaut pour l'application,
Application
1 300 ms
y compris le temps nécessaire pour démarrer le
temps de démarrage
Contacts: moins de
processus Linux, chargez le package Android
700 ms
dans la VM Dalvik et cal
Paramètres: moins de
onCreate.
700 ms
Lorsque plusieurs applications
ont été lancées, le re-
lancement d'une application déjà en cours d'exécution
Simultanément
après son lancement

Applications
doit
prendre moins de temps que le temps de lancement
initial.
9. Compatibilité du modèle de sécurité
Les implémentations d'appareils DOIVENT implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android
, tel que défini dans le document de référence sur la sécurité et les autorisations dans les API [Ressources, 54] de la documentation pour les développeurs Android.
Les implémentations d'appareils doivent être compatibles avec 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 être compatibles avec 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 [Resources, 54]. Plus précisément, les implémentations
DOIVENT appliquer chaque autorisation définie comme décrit dans la documentation du SDK. Aucune autorisation
ne doit ê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 de processus
Les implémentations d'appareil 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'appareil 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 documentation de référence sur la sécurité et les autorisations [Resources, 54].
9.3. Autorisations de système de fichiers
Les implémentations d'appareils DOIVENT prendre en charge le modèle d'autorisations d'accès aux fichiers Android tel que défini dans la référence sur la sécurité et les autorisations [Resources, 54].

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 autres environnements d'exécution DOIVENT être des applications Android et respecter le modèle de sécurité Android standard, comme décrit ailleurs dans la section 9.

Les autres environnements d'exécution 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 précisément:
Les environnements d'exécution alternatifs DOIVENT installer les applications via le PackageManager dans des bacs à sable Android distincts (c'est-à-dire des 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 DOIVENT
NE 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 être lancés avec, accorder ni être accordés à d'autres
applications des droits d'accès du 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 autres environnements d'exécution 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 de l'appareil pour laquelle une autorisation Android correspondante est disponible (telle que l'appareil photo, le GPS, etc.), le runtime 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, l'environnement d'exécution DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.

10. Tests de compatibilité logicielle
Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section.
Notez toutefois qu'aucun package de test logiciel n'est entièrement complet. C'est pourquoi 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 4.1
disponible sur le projet Android Open Source. Vous réduirez ainsi le risque d'
introduire des bugs qui créent des incompatibilités nécessitant des modifications et des mises à jour potentielles de l'appareil
.
10.1. Suite de tests de compatibilité
Les implémentations d'appareils DOIVENT réussir les tests de la suite de tests de compatibilité Android (CTS)
[Ressources, 2] disponible sur le projet Android Open Source, à l'aide du logiciel final
fourni sur l'appareil.De plus, les implémentateurs d'appareils DOIVENT utiliser l'
implémentation de référence dans l'arborescence Open Source Android dans la mesure du possible, 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 s'exécuter sur un appareil réel. Comme tout logiciel, le CTS peut
lui-même contenir des bugs. La version du CTS sera indépendante de cette définition de la compatibilité
. Plusieurs révisions du CTS peuvent être publiées pour Android 4.1. Les implémentations de Device
DOIVENT réussir les tests de la dernière version du CTS disponible au moment de la finalisation du logiciel Device
.
10.2. Outil de vérification CTS
Les implémentations d'appareils DOIVENT exécuter correctement tous les cas applicables dans l'outil de vérification CTS
. Le vérificateur CTS est inclus dans la suite 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 cas 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 tenus d'exécuter explicitement le vérificateur CTS sur les versions qui ne diffèrent que de manière insignifiante.
Plus précisément,
les implémentations d'appareils qui diffèrent d'une implémentation ayant réussi le test du vérificateur
CTS
uniquement en raison de l'ensemble de paramètres régionaux, de la marque, etc. PEUVENT omettre le test du vérificateur

CTS.
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:
Applications "Apps for Android" [Resources, 55]
Replica Island (disponible sur Android Market)
Chaque application ci-dessus DOIT se lancer et se comporter correctement sur l'implémentation pour que l'implémentation soit considérée comme compatible.

11. Logiciel pouvant être mis à jour
Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel
du 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.
Toute 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 un redémarrage
Mises à jour "Tethered" 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 stockage amovible
Le mécanisme de mise à jour utilisé DOIT prendre en charge les mises à jour sans effacer les données utilisateur. C'est-à-dire que le mécanisme de mise à jour doit préserver les données privées et partagées de l'application.

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 commercialisation, mais dans la durée de vie raisonnable du produit déterminée en consultation avec l'équipe de compatibilité Android, afin d'affecter 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 précédemment.

12. Contactez-nous
Vous pouvez contacter les auteurs du document à l'adresse compatibility@android.com pour obtenir des précisions
et signaler tout problème que vous pensez ne pas être couvert 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 d'Android. Cependant, 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 valide"
La procédure de test ci-dessous fait référence à ces appareils en tant qu'appareils "candidats" et "connus comme étant valides", 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.
Testez le contrôle 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
à activer le Bluetooth dans une boîte de dialogue
Tester l'association et la communication
1.  Lancez l'application Bluetooth Chat sur les deux appareils.
2.  Rendez l'appareil connu détectable dans BluetoothChat (à l'aide du
Menu)
3.  Sur l'appareil candidat, recherchez les appareils Bluetooth dans BluetoothChat
(à l'aide du menu) et associez-le à l'appareil connu comme bon
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.  Dissociez chaque appareil de l'autre à l'aide de l'application Paramètres de l'appareil.
Testez l'association et la communication dans l'
autre sens.
1.  Lancez l'application Bluetooth Chat sur les deux appareils.
2.  Rendez l'appareil candidat détectable depuis BluetoothChat (à l'aide du menu
).
3.  Sur l'appareil connu comme bon, recherchez les appareils Bluetooth dans BluetoothChat
(à l'aide du menu) et associez-vous à l'appareil candidat.
4.  Envoyez 10 messages ou plus depuis chaque appareil, puis 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.
Tester les relances
1.  Rélancez l'application Bluetooth Chat sur les deux appareils.
2.  Envoyez 10 messages ou plus depuis chaque appareil, puis vérifiez que l'autre appareil
les reçoit correctement.
Remarque: Certains des cas des tests ci-dessus se terminent par l'utilisation de la page d'accueil, et d'autres par l'utilisation de 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
terminées explicitement (lorsque l'utilisateur appuie sur "Retour", ce qui appelle la fonction finish()) et lorsqu'elles sont envoyées implicitement
en arrière-plan (lorsque l'utilisateur appuie sur "Accueil"). Chaque séquence de test doit être exécutée
comme décrit.